Xpad - Hiding/unhiding the window decorations - alternative

Registered by Arthur Borsboom on 2013-10-19

Toggling the window decorations on and off, might be a bit too complicated. This specification implements a alternative way of toggling the window decorations.

Blueprint information

Status:
Not started
Approver:
Arthur Borsboom
Priority:
Low
Drafter:
Szabolcs Szasz
Direction:
Needs approval
Assignee:
Arthur Borsboom
Definition:
Discussion
Series goal:
Accepted for trunk
Implementation:
Unknown
Milestone target:
milestone icon 5.1.0

Related branches

Sprints

Whiteboard

1. Overview

(I'm on Windows now, recalling vague memories of xpad, so this is more of a fairy-tale than a technical document...)

a) xpad has a nice option (a run-time toggle setting) for removing redundant window decorations from the note windows, in order to minimize screen estate usage. (Great feature especially for smaller laptop/mobile screens.)

The proposed feature below (and the description) is relevant only for this decorationless mode.

b) A common use case is to move around, resize or minimize notes. These operations are typically done by trivial mouse actions, using the window decorations of a particular note. (Note: moving, resizing etc. is more often necessary, again, on smaller laptop/mobile screens.)

c) For these actions of (b), you need to temporarily turn the decorations back on using the right-click (context) menu on a note, do the simple window action, and then probably turn the decorations back off (as configured), again, using the same pop-up menu (right-click).

This is prohibitively inconvenient, as the mode-toggle overhead is unreasonable compared to the original single mouse action. (Even more frustrating on smaller screens, because the more frequent note repositioning and the stronger need for decorationless mode increase the conflict cases.)

d) Proposed solution: allow ad-hoc per-note toggling of decorations with minimal user interaction overhead: either nothing (see: "Aftermath"), or a single extra click as the maximum.

The currently provided implementation requires a click on the note (where the mouse is anyway already pointing at) before doing the desired window operation (and another, to turn the decorations back off afterwards, if desired).

2. Testing

A) Decorations ON (for regressions testing)

1. Turn decorations ON.
2. Click around the notes. --> Nothing new happens, just the usual window raising/activation/focusing.

B) Decorations OFF

1. Turn decorations OFF.
2. Click a note. --> a) The note is activated/raised/focused, as usual to the window manager.
b) Decorations state does not change.
3. Click the note again. --> Decorations are turned ON, for that note only.
4. Move, resize, minimize the note. --> Works as usual.
5. Click the note. --> Decorations are turned back OFF.

C) Toggling around

1. Create several notes. Position them overlapping.
2. Do the click-switching as in case "B", for various notes, repeatedly.
--> Everything works as expected.

3. Implementation

The simplest & quickest approximation to try the feature is simply adding these lines to the beginning of xpad_pad_text_view_button_press_event(...), in xpad-pad.c:

   static gboolean last_decoration_state = FALSE;

   if (!xpad_settings_get_has_decorations (xpad_settings ()))
   {
      last_decoration_state = last_decoration_state ? FALSE : TRUE;
      gtk_window_set_decorated (GTK_WINDOW(pad), last_decoration_state);
   }

That's it.

4. Aftermath

- The ideal solution would be click-less: just hovering over a note window should temporarily add the decorations back, so any usual window operation can be done trivially. However, I couldn't quickly find a reasonable way to implement it.

- The above implementation is not perfect: sometimes the state change occurs already on the first click (test step B/2). By reading the code, one would expect that it always toggles on any click, but the windowing system (an XFCE4 installation here) seems to filter out "non-client" clicks, hiding them from our code, making it work almost as desired. :)

Fortunately, when it doesn't, flipping the state back costs just another click, which is negligible enough that the misbehavior has not become annoying for me even over prolonged use. (And I'm a picky user...)

(I have not investigated when and why some clicks are filtered out by the windowing system. But if that's a standard X feature, than a lucky fix could be as easy as toggling the decorations only when the note is already in focus. Then: if a note already in focus would not toggle state on a click, or always toggle state on any click, then a new approach would be needed.)

- If the issue above proves unfixable and/or an unacceptable price for some more convenient window handling, then a new config option ("allow toggle decorations on click") could be added to completely isolate the click-toggle behavior from maximalists, while still allowing it for pragmatists. :)

------------------------------------------------------

Should have: an option in the preferences, just In case of undesirable effects, or for people who like the old way
To investigate: "autohide" option for window decorations, just as is done for the toolbar.

(?)

Work Items

This blueprint contains Public information 
Everyone can see this information.

Subscribers

No subscribers.