Separate roll-up and roll-down keys

[realsimix]

Hi,

there is one thing on my wish list which I would like to propose as enhancement:

For now windows roll-up and roll-down can be done with a single mouse button, by default button 2.

What I would like to see is separate keys to roll-up and roll-down. Then one could define mouse button 4 and 5 to make the mouse wheel roll up and down a window.

Would it be possible to implement this without too much work?

That would be really great!

Thanks, Simon

[gijsbers]

This idea is difficult to implement, because icewm was designed with a large number of predefined tasks and a single event to trigger them. If you are willing to combine the scroll mouse with a modifier like Control, then it may be done in a icesh script and a binding in keys.

[realsimix]

I'm not sure I've explained it clearly.

I try it again: by default I can move to mouse pointer to the title bar. Then, I can maximise the window with double button 1, or I can roll-up/down the window with double button 2.

Now, instead of button two I simply like to use single "button" 4 and 5 to roll up and down. I guess it means we need two functions, TitleBarRollupButton and TitleBarRolldownButton, and then assign mouse button 4 and 5 to it.

Or is the problem that we don't produce a double click with the mouse wheel then?

[gijsbers]

The problem is that we already have 500 preferences. People continually want to add more for various minor particular reasons, but they all need to be understood, managed, documented, and communicated to users who usually don't need to change them. I would rather remove one every day, than add another. So if you can formulate an elegant way to extend the existing behavior without adding more options then that can be considered.

[realsimix]

The following would come close: YFrameTitleBar::handleClick() could be enhanced to handle 1 count mouse buttons if they are number 4 or 5. If so, do actionRollup to toggle rollup state. It could even be enhanced to also act on button 5 if button 4 is configured and the other way around.

That way every turning on the wheel would toggle rollup state.

Would this be possible or is it then already too much magic in YFrameTitleBar::handleClick()?

[gijsbers]

Like this?

[realsimix]

Thanks a lot, yes, that's exactly what I meant! Looks like I have to create a build environment as a next step to test.

While we are at it, a single click with button 1 to the title bar brings the window to the front (like Alt+F1). Now, do you see a way to do the opposite by a single click with button 2 to the title bar (like Alt+F3)? I see that button 1 and 3 with count 1 are both defined there, would you mind adding button 2 there with the function to lower the window (sending it to the background)?

[gijsbers]

Doesn't Alt + left mouse on the titlebar work for you?

[realsimix]

Well, using modifiers may work normally but when working with nested X sessions (in our case using the NX libraries), the Alt modifiers may be taken by the root window and not go trough to the nested sessions. That's where it's nice to have button 2 for it. That way you can bring to the front, send back the window, roll up / down with only the mouse.

I think some other WMs like XFCE do the same and only now I started to realize how I'm used to it :-)

[gijsbers]

Try setting LowerOnClickWhenRaised.

[realsimix]

The mouse wheel for roll-up/down works perfect now, thanks!

I've also tried LowerOnClickWhenRaised and it works well. However, this seems to be a deprecated feature because I saw this

DEPRECATE(lowerOnClickWhenRaised == true);

I also tried to make button 2 send windows to the back with a single click but only if button 2 is not configured for titleRollupButton or titleMaximizeButton. So my shy question is, would the patch below be acceptable as it seems to work well and it shouldn't have negative effects with the default configuration?

--- icewm-2.3.3/src/wmtitle.cc.orig 2021-04-28 00:27:38.000000000 +0200
+++ icewm-2.3.3/src/wmtitle.cc  2021-04-28 15:06:46.593733037 +0200
@@ -168,6 +168,13 @@ void YFrameTitleBar::handleClick(const X
                 }
             }
         }
+        else if (up.button == Button2 &&
+             titleRollupButton != Button2 &&
+             titleMaximizeButton != Button2 &&
+             ISMASK(KEY_MODMASK(up.state), 0, ControlMask))
+        {
+            action = actionLower;
+        }
         else if (inrange<unsigned>(up.button, Button4, Button5) &&
                  inrange<unsigned>(titleRollupButton, Button4, Button5))
         {

[realsimix]

Does the proposed patch look correct? I'm not sure about the ISMASK() line, does it make sense this way?

[realsimix]

The change I propose does only extend some functionality without change in default configuration. It brings a useful feature in line with other DEs and I don't think it disturbs anyone. It simply sends windows to the background with single click on the title bar with button 2 but only as long as button 2 is not configured to do something else, like being titleRollupButton or titleMaximizeButton.

[gijsbers]

It looks too inelegant and hackerish to me. It's cumbersome to understand, document, explain and maintain.

[gijsbers]

This case can be seen as a consequence of the way key bindings are defined in IceWM. A more general design would allow to specify a binding as the combination of:

• a context like window, root, titlebar, frame button, where a context is the combination of a location + a state, like rolled up, minimized, normal.
• an event to trigger the binding, like the key or mouse + modifiers.
• an action or response to this context + binding.

Now you have these very fixed predefined preferences like KeyWinRollup, where it is prescribed that it is a key event which triggers a rollup of a window, so you can't define it as a mouse binding or restrict it to a titlebar or a frame button. And you you have preferences like TitleBarRollupButton, where the event must be a button, the location must be the titlebar, and the response is also fixed, namely a rollup. Then the preferences file predefines a large number of these fixed context + event + actions. A more general design would allow the user to define any context, any event, with any action. Then the existing Key, Button and Mouse bindings can be defined as part of that.

[realsimix]

I understand it would mean a big redesign to make this more configurable. In the mean time I'll use my hackerish patch which works for me :)