Support setting dock/clip/icon properties (or dragging) via mouse

[rjhorniii]

Lots of Windowmaker apps and dock apps make use of a three category mouse-icon interaction. Mouse actions outside the icon go to the compositor for background/window activity. Mouse actions in a border region of the icon go to the compositor for icon controls. Mouse actions inside an active area inside the border region of the icon go to the application running behind the icon. If there is no active area established by the application, all the actions inside the icon are used for icon controls. This is FYI for testing the mouse-icon interactions.

I've adjusted my icon sizes to make this easier to use on a high DPI large display, as shown in the example. This is from the Windowmaker wmCalClock dockapp (unmodified) with a larger icon size default and the original size icon images. The border region is the grey ramp shaded area around the date and time blocks. Mouse and keyboard actions inside the date and time areas are sent to the app, and the app updates the date and time values.

The default sizes are tricky to use on HIDI screens because by default the border region is just that small beveled edge portion. The active app area by default it the rest of the icon area. I expanded the default icon size so that there is a larger border area to use for icon re-positioning, etc.

[phkaeser]

Thanks for flagging that. This is a case where I'm thinking whether to deviate from Window Maker's behaviour.

1. ✅ Mouse actions outside the icon go to the compositor (background, or surface beneath/behind the icon) (same behaviour)
2. ✅ Mouse actions inside the (active) icon area go to the client that owns the icon surface (same behaviour)
3. But, for "icon controls", I'm considering to consistently use eg. "right-click" or a click with a modifier (eg. Alt-click) to invoke icon or dockapp controls.

While point 3 deviates from Window Maker behaviour, it would be significantly simpler to invoke icon controls; and suspect not losing much (or any?) functionality.

For deciding:

• Are there DockApps that act on mouse right-click?
• Are there DockApps that act on modifier+click, eg. Alt-left-click or similar?

(flagging as "Question")

[rjhorniii]

There are definitely dockapps that use right, center, left click and hover for different functions. I can think of several. One that I use heavily reacts to right, center, left, and hover.

Alt-click is a potential approach. I'll have to go look at the dockapp library to see whether any of them use alt.

The dockapp that I use heavily is the "wmbutton" dockapp. (https://www.dockapps.net/wmbutton) It presents a 3x3 grid of mini-icons inside the icon. That translates into 27 different applications that can be launched by clicking the correct mini-icon. It's much less clutter and screen real estate than 27 different icons. You just need to have good targeting control of your mouse. If you've forgotten what click to use, you hover over the mini-icon and it displays a tooltip. It's easily programmable. You associate a shell command with each mini-icon and click type in a configuration file.

I know that my muscle memory is very much oriented to thinking "border for icon grab/move" and "contents for application interaction". I'm not sure how long it would take for muscle memory to shift to think "alt for icon grab/move". Alt would deal with the Windowmaker default of the very small area of the bevel being the target for icon grab/move.

Icon interactions are more than just grab/move. Setting icon characteristics, associating executables with icons, choosing icons, choosing fonts, etc. is part of the icon interaction. Grab/move is just the most common thing that you do with icons.

[phkaeser]

Thanks for pointing the wmbutton behaviour; that does make the middle- or right-click ideas less ideal.

Concluding so far:

• Alt-drag is good to use for icon grab/move, since it lines up with Alt-drag for moving windows.
• Alt-left-click is a potential option for invoking the dock settings menu. To be clarified.
• In any case, the modifier should be configurable, not hardwired to "Alt".

[rjhorniii]

I'm still looking at various dockapps, but Alt-mouse activity looks reasonable.

• Somewhere in the windowmaker configurations is a MOD1 concept that is mappable and can be disabled on a window by window basis. The default is to map ALT to MOD1, but it can be a variety of function keys. So you often find a mix of ALT-<event> and MOD1-<event> in documentation depending upon the care taken by the writers and implementors.
• So far I'm finding lots of use of ALT-character entry within an icon to be an event sent to the application with the expectation that it will bring up a menu or perform some action. All of these have been characters from the keyboard, not mouse actions. That means that using ALT-<mouse event> is reasonable and conceptually consistent.
• Default for dock application menu is mouse-right-click and hold, and setting is one of the menu items. The dock icon doesn't have an active region so the entire icon responds. Is that what you meant by dock settings? Or did you mean dock settings preferences from Configure Window Maker? Or perhaps there's a section in the documentation with that title?
  Or did you mean the menu that sets docked application behavior. It's got menu items like dock position, launch, settings, kill, ...
  The current behavior is that mouse-right-click and hold brings up those menus when the cursor is in the border region. Mapping that to alt-right and holdwould be more consistent.

I'll confess that like most users I find most of this stuff by trying things live rather than reading the documentation. I should go reread the documentation.

[phkaeser]

Thanks for looking into this. Yes, I meant the menu that's brought up when right-clicking on the non-used surface. The menu contents vary by whether it's a dock, clip or regular icon; having "Dock position", "drawer", "Settings...", ... on the dock.

Updated the title to (imho) better catch the scope.