For discussion, NO MERGE : Dispatcher v2 API 1st proposition

[johnr14]

The current API of dispatcher is not optimal, it's not uniform, uses too many types of different actions and has poor predictability for function's name.

Left unchanged, it is a irritant to new user and will get worse with time if the complexity of hyprland keeps growing in a far future. Those changes can be postponed, but having a API revision after release 1.0 wouldn't be the best.

As no names where kept and thus no collision with previous API occurs, this could be implemented without breaking anything.

Old API could be discouraged and eventually be deprecated and removed after a notice and appropriate elapsed time.

The term window is deprecated in favor of client as Wayland namely use clients. However Wayland does interchange the term window and client a lot in it's documentation but it says this about it's architecture : "is how clients actually render under wayland", "the rendering happens in the client, and the client just sends a request to the compositor to indicate the region that was updated ", "the compositor receives generic Wayland buffers from the clients". Could revert to windows if maintainers or users strongly wish for it.

This proposition is an attempt to consolidate the wording used in the dispatcher's functions name with a naming convention that :

    1. would help understand what a function does without having to read it's description.
    2. be uniform
         2.1 for the type of action it performs
         2.2 for the subject of the action
         2.3 for the target of the action
         2.4 for the passing of arguments, mandatory and optional

All names are in a format of : nounVerbVariation.

The number of dispatchers action verbs went down from 22 to 9.

Lots of param where defined. Params use the opt:param syntax, may or may not be kept depending on difficulty to implement.

A few examples are added for groups and special workspace.

Discussed in #3805

First proposition, please check for :

1. if it makes any sens to change the API
2. coherence and logic
3. omissions
4. ease of use
5. efficiency
6. orthography and syntax after first 3 :)

This is in no way implemented in bind or hyprctl and is used to illustrate how the API could be redesigned.

Thanks for your time in pondering on how to make hyprland even greater and please add your comments. I did try to finish in a rush and may have made a few "oops". I'll try to squash the request, hope it works.

[johnr14]

Please view as a wiki-page for now. Thanks

If you know how I could squash this, please tell.

[TuxMC-sys]

Please view as a wiki-page for now. Thanks

If you know how I could squash this, please tell.

Is this what you're looking for?