Replies: 14 comments 14 replies
|
This could be the general tree structure that would hold all the dispatch functions. Names and branches are open to discussions ! Dispatcher tree main branches CLICK-METhe current and some new functions of Dispatchers populating the proposed tree. It would be great to have a good naming convention that :
Dispatcher tree functions CLICK-MEDispatcher tree functions with descriptionsCLICK-ME |
|
makes no sense to make such a breaking change. If anything, we could sort the dispatchers better in the docs. |
|
Since when do you mind breaking changes? |
|
Most breaking changes I do are small. This would change every bind command. |
|
there's a first to everything I think the proposed system is more consistent than your regularly scheduled drug trip |
|
Firstly, I want to say that for users of hyprland, dispatchers calls are the exposed API. It has to be available in a consistent and mindful way. Just like not having all functions under a same class in a unique .cpp file. There is a way to do this kind of changes gracefully.
Also, it would be a good idea to include layoutmsg, layers, binds... and any available call in hyprctl in a complete API revision. I think that at some point, a revision will be needed to reorganize hyprctl calls. It could be later, but with time, it will just be more complex and more scripts/plugins will be using a old and unintuitive API, making the change slower. Also, a intuitive API will enable users to do more in less time, drawing more users to use it. This API rewrite should be forward thinking, putting in place a structure that can be build upon for many years to come. It's not just about what calls that can be made right now, but also what functions will be added later. I see it as a building block to implement custom complex manipulation of the desktop in creative ways in the future by 3rd party applications. |
|
I have a user mindset, but if we could get a few plug-in devs in on this discussion, perhaps their view could help in identifying critical parts of the interface that are either unintuitive or inefficient. First in mind would be @fdev31 from pyprland. Edit, this is not something to rush. It's imperative that a deep thought process be involved as it's not something that should be done often. So lots of planning and conceptualization needs to be taking place here to have it "right" the first time. |
|
There are some inconsistent parts in the naming scheme for the API. I'll try to illustrate it with an example. Exemple 1, we have activewindow and clients. How should the active window be called : activewindow, activeclient, currentclient, selectedclient, focusedclient ? Active, current and focused are used in an interchangeable way across dispatcher calls, or that's how it seems to me. Calling both In a way, activewindow is the same as clients parsed to include only the "active" or "focuse" or "current" client. This exemple could be implemented as getting a list of clients with specific search :
The thing is, how specific should hyprctl be ? Should it just output all connected clients and let the user script lots of functions to get a specific value or should hyprctl just output the desired information ? Any of those can be done by parsing the json and manipulating it (or is it?). But it's not efficient nor concise. Having hyprctl respond in a concise way could prevent having to pool multiple query to hyprctl and process it's data to get a simple result that could be easier to get if the API where more elaborated. Also the project should have a guideline to decide on what terms should be used. Hyprland uses the term client or window, while Wayland talks about client. Should we just go with only clients ? Do we query for the active client or the focused client ? Is an active client/window a client that is currently on a visible workspace on display on a monitor, or is it the only client/window that has focus ? Should we differentiate clients that are displayed on a monitor from those on workspaces that are not "displayed" on a monitor ? I hope this can illustrate how the naming can be confusing for users in it's present state. |
|
Hi,
In short, I'm not sure - at this point in time - hyprland requires a sophisticated query language. The main points in my view are:
Edit: pattern matching would be nice too indeed, maybe with a syntax like: Edit 2: I think there are two options here on how to proceed:
|
|
Thanks for the reply. I was thinking about grouping all functions that are related to the subject of an action inside a master group (like all actions targeting a workspace would be workspace->action and for clients : client->action. But it may not be a priority for now, may become later if new functions keep being added. Like I said, there are currently 53 functions all for dispatcher. Yes, I do think the choice of words should be reviewed and this might be the priority. I described it as a "good naming convention". I'll try to look the terms used by dispatcher : if they are appropriate and if it's consistently used in the function's name and it's description. I think that would be a good start. |
|
Firsly, I'll look on the names of the dispatchers. For now, the term window is used even if we talk about clients. My findings where : The function name may or may not contain the subject of the action, on what the action is to be performed. If the action is directed to current|focused|active window, it should be implicit in the function's name. Also, should we change all functions so they can accept "current" as target of the action if they can ? I identified 22 actions and the number of occurences : There are 7 functions that don't have an action : There are 25 other terms that may reference to the target or subject of the action : I will give some comments on the dispatcher's name and even recommend a more fitting name. The recommended name is just to conform to current naming practice, it may not be the best name as I still think the subject of action should be under a group (like workspace->action)
|
|
I find it hard to navigate all those functions. Should we chart the elements of hyprland that can be interconnected ?
For example : Are there any more actions that can be performed on a window ? I only see 3 actions, the rest should be param or action subclass ? Edit: I removed focus from move actions of window, as focus should be it's own element? |
|
Mhm, I am not against a gradual move. We could add a config option akin to However, I'd rather step back from the discussion here:
If my input is absolutely necessary feel free to ping me, or when you all come to a consensus with a full proposal for a new system. |
|
I'm fine with current system, and am pretty against rewriting all of my config files. May just be me though. |
|
As long as old syntax would exist (don't break the userspace!) or some transition period would be applied I don't mind it. |
|
Vaxry can break user-space as long as he wants because the project is pre-1.0. |
pre, post, after 20 years (see vim 9), whenever and whatever he wants |
|
That depends on what he wants 1.0 to look like. |
|
Your config and scripts might be done, but I think lots of new users will be coming to Hyperland. There are more and more screenshots and video of hyprland ricing on the net. We could have an influx of new Linux user that wants to jump straight here without going to gnome or KDE first. I think that we are investing in attracting and keeping new users. If the scripting is simple with bash, that is great for a new user. A api that is not uniform will make reediting your config in a few years painful, requiring rereading the wiki again. While a good api should provide almost self explanatory functions that you don't need to guess how to write it or if it's named something else. But at the same time, I understand that we should do all we can so old configs and scripts work for those that spent the effort to do so. |
|
|
|
I can confidently suggest a scheme that does: These are the names I have chosen for socket event: {
### WINDOWS ###
windowFocus = {
event = "activewindow";
vars = [ "WINDOW_CLASS" "WINDOW_TITLE" ];
};
windowFocusV2 = {
event = "activewindowv2";
vars = [ "WINDOW_ADDRESS" ];
};
windowOpen = {
event = "openwindow";
vars =
[ "WINDOW_ADDRESS" "WORKSPACE_NAME" "WINDOW_CLASS" "WINDOW_TITLE" ];
};
windowClose = {
event = "movewindow";
vars = [ "WINDOW_ADDRESS" ];
};
windowMove = {
event = "movewindow";
vars = [ "WINDOW_ADDRESS" "WORKSPACE_NAME" ];
};
windowFloat = {
event = "changefloatingmode";
vars = [ "WINDOW_ADDRESS" "FLOAT_STATE" ];
};
windowFullscreen = {
event = "fullscreen";
vars = [ "FULLSCREEN_STATE" ];
};
windowMinimize = {
event = "minimize";
vars = [ "WINDOW_ADDRESS" "MINIMIZE_STATE" ];
};
windowUrgent = {
event = "urgent";
vars = [ "WINDOW_ADDRESS" ];
};
windowTitle = {
event = "windowtitle";
vars = [ "WINDOW_ADDRESS" ];
};
### LAYERS ###
layerOpen = {
event = "openlayer";
vars = [ "LAYER_NAMESPACE" ];
};
layerClose = {
event = "closelayer";
vars = [ "LAYER_NAMESPACE" ];
};
### WORKSPACES ###
workspaceFocus = {
event = "workspace";
vars = [ "WORKSPACE_NAME" ];
};
workspaceCreate = {
event = "createworkspace";
vars = [ "WORKSPACE_NAME" ];
};
workspaceDestroy = {
event = "destroyworkspace";
vars = [ "WORKSPACE_NAME" ];
};
workspaceMove = {
event = "moveworkspace";
vars = [ "WORKSPACE_NAME" "MONITOR_NAME" ];
};
### MONITORS ###
monitorFocus = {
event = "focusedmon";
vars = [ "MONITOR_NAME" "WORKSPACE_NAME" ];
};
monitorAdd = {
event = "monitoradded";
vars = [ "MONITOR_NAME" ];
};
monitorRemove = {
event = "monitorremoved";
vars = [ "MONITOR_NAME" ];
};
### MISCELLANEOUS ###
layoutChange = {
event = "activelayout";
vars = [ "KEYBOARD_NAME" "LAYOUT_NAME" ];
};
submapChange = {
event = "submap";
vars = [ "SUBMAP_NAME" ];
};
screencastChange = {
event = "screencast";
vars = [ "SCREENCAST_STATE" "SCREENCAST_OWNER" ];
};
} |
|
Messing with hyprctl is by far the best way to interact with Hyprland's API if your programming knowledge is not sufficient to make your own plugins - which I think is the case for a large majority of the userbase. As long as the old structure is somewhat supported (but discouraged), the new structure gradually making its way in is only an improvement, nothing else. |
|
Thanks for your input everyone. I understand that compatibility with current implementation is mandatory for an extended period of time, let's say until version 1.0 or 1.5. I like the idea of @spikespaz of nounVerb, but since an action may need precision, I'd propose nounVerbVariation. Having a variation could prevent most case of needing more than 2 param for a function. Like The term dispatch is to carry out (a duty or task) promptly (Collins) and has execute and perform as synonym. So for implementing a new revision of the API, it needs to work from bind and hyprctl. Since we have
While in bind's config, it would be (the example from wiki) : Also For hyprctl, we could allow spacing or not between noun and verb for shell completition but no space for bind commands.
We could also always use shorts for names : focus:fs workspace:ws monitor:m client:cl ? |
|
Well, we could do without Could be the case with So worst case would be |
|
Finally I have a proposition for a V2 API. Open to changes and comments ! It's almost all new dispatcher's names and they do not conflict with the old ones, so it could be implemented without breaking compatibility ! I made it in a wiki format and you may view the PR as it contains lots of information and view the wiki-page. It went down from 53 to 38 functions and should keep all the same functionality. Thanks for your time in giving your feedback. P.S. I failed at squashing the merge, sorry. |
|
What if I contributed a bash script that sed's your config files? Could be deployed on upgrade in AUR and stuff. My thinking is that if it were a seamless automatic transition (easily toggled off), it offers a good compromise. IMO the current names are very arbitrarily chosen without any style 😎. |
|
First, we need to discuss the changes and if every one thinks that it makes sens. Then we have to implement it and thoroughly test it. Only then can we think about pushing it to users. Also, it's not as easy as just a sed command, some actions require an opt:flag to implement a particular subtility. But it could work for most of the time. A script could be added to the wiki to help users migrate, independent of distribution. I haven't thought about the layouts or other parts of hyprland, but if we do green light a API revision, we should make sure all the rest is kept coherent . It is a lot of job, but for long term development and scalability, I do believe it to be worthwhile. Also, this is the first exposed part of hyprland to the user base as @NotAShelf mentioned and may reflect (to some) the project's ability to compete with other tiling manager or window manager. For long term usage, the user base will have to evaluate if hyprland is just a "nice experiment" to try out or if it is viable for deployment as their main tiling manager. A part of that decision may be 1) stability 2) features 3) ease of use : is it easy to maintain it's config and integrate new functions regularly in their config without having to re-read the wiki to make sens of what does what. Thanks for your support ! If I where to re-implement a bind config, I would never want to revert to API v1 after working with API v2, so I hope this gets attention. |
|
That's why it is a must to implement a major change as a separate socket and maintain both for a while, this extra workload & planification has to be considered. One fun & stil professional way of doing it it implementing it as a hidden unsupported unstable feature, so there could be a period where some plugin maintainers & other crazy people would give it a try, provide feedback, iterate over the API until it's great - it doesn't prevent from decent preparation & draft documents of course but it could still be developped incrementally with breaking change, since people would be warned - once it looks stable there is a final review & it becomes frozen / official / extend only. So that was my 2cents, it doesn't have to impact current user base, and once the new API is published we can give users some time to migrate (a year+ ?) providing them nice migration documents & correspondance tables. Once it's ready it will be a strong point for Hyprland to have the nicest API on top of having the best & smoothest animations ;) |
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
I would like to propose a rewrite of the Dispatchers functions.
Currently, there are many functions (edit: 53 functions as v0.31.0) bundled without a coherent hierarchy.
This makes it :
Dispatcher functions are important and having a good map of what functions are needed could lower the need for users to write custom hyprctl scripts for simple things that could be done easily with bind keys.
Proposition:
I hope to have a constructive discussion here and hopefully that collectively we could submit something to the developers for review.
Implementing will break compatibility with older versions of hyprwm unless we provide a deprecated interface that will be removed later on.
This is a discussion for users and developers to participate in.
How to proceed :
8.1 Have hyprctl dispatch --help display the tree of available functions
8.2 Have hyprctl dispatch branch,function --help display function's desctiption
Thanks and let's keep working hard to make hyprwm the best it can be !
All reactions