Talked about this in the Nimdow IRC channel yesterday but thought I'd formalize it as a proper feature request. Most people likely show multiple pieces of information on their status bars, and sometimes it would be nice to have these clickable (e.g. click the volume icon to change volume or click the CPU usage to bring up a window with htop). To make the information as versatile as possible I think that it should contain the character in the string that was clicked, the position of that character on screen, and the offset into the character. This would allow being able to align a pop-up to the entry, but also easily figure out which thing was clicked from even the most basic bash scripts. Another option would be to use an ASCII character like 0x1F - Unit separator to allow the user to tell Nimdow how the bar is separated into units and get the position and offset of the unit instead of the character. This would make it trivial to figure out which thing was clicked, and also would allow alignment to the unit as a whole instead of just the character.
How these clicks are communicated back to the script is another interesting question. One option would be some sort of IPC through a socket or a FIFO, however this might be hard to consume from a bash script, and in other programming languages it could require extra packages. Another way to handle this would be to set a X11 hint on the root window with the last click, and clear it whenever the text on the bar is updated. This way scripts can read the property easily with xprop and whatever program was written to write a hint to the root window probably already has the library for reading one as well. The script would also be able to get the click immediately with the -spy option of xprop. Of course the easiest would probably be to have a script that is run when you click the bar, and the positions can be passed as arguments. The only downside of this would be that it would then potentially have to read out the contents of bar and parse it to know what was clicked (but this should be less of an issue if the unit separator was implemented).
Let me know what you think, I could take a crack at implementing this if you'd like.
Talked about this in the Nimdow IRC channel yesterday but thought I'd formalize it as a proper feature request. Most people likely show multiple pieces of information on their status bars, and sometimes it would be nice to have these clickable (e.g. click the volume icon to change volume or click the CPU usage to bring up a window with htop). To make the information as versatile as possible I think that it should contain the character in the string that was clicked, the position of that character on screen, and the offset into the character. This would allow being able to align a pop-up to the entry, but also easily figure out which thing was clicked from even the most basic bash scripts. Another option would be to use an ASCII character like
0x1F - Unit separatorto allow the user to tell Nimdow how the bar is separated into units and get the position and offset of the unit instead of the character. This would make it trivial to figure out which thing was clicked, and also would allow alignment to the unit as a whole instead of just the character.How these clicks are communicated back to the script is another interesting question. One option would be some sort of IPC through a socket or a FIFO, however this might be hard to consume from a bash script, and in other programming languages it could require extra packages. Another way to handle this would be to set a X11 hint on the root window with the last click, and clear it whenever the text on the bar is updated. This way scripts can read the property easily with
xpropand whatever program was written to write a hint to the root window probably already has the library for reading one as well. The script would also be able to get the click immediately with the-spyoption ofxprop. Of course the easiest would probably be to have a script that is run when you click the bar, and the positions can be passed as arguments. The only downside of this would be that it would then potentially have to read out the contents of bar and parse it to know what was clicked (but this should be less of an issue if the unit separator was implemented).Let me know what you think, I could take a crack at implementing this if you'd like.