[WIP] a floating window widget for Variety #87
Conversation
These work equally fine in other DEs: Xfce, GNOME, etc.
On right click or any double click, the floating window will pop up the Variety menu. It supports dragging to move the icon when LMB is held, but that means we can't use a single left click to popup the menu (since that would make the window itself lose focus).
|
Here's what it looks like so far: https://www.dropbox.com/s/ytqcfdziuko7rew/variety-floating.mp4?dl=0 |
Client-initiated window movement doesn't seem to work there.
|
In Wayland I can't turn off decorations and still allow movement, but at least we have menu access now.
|
|
@peterlevi Any thoughts on this so far? |
|
@jlu5 Still haven't had a chance to look at the code, just ran the branch briefly, some initial thoughts:
Will try to find time in the next couple of days to take a look at the code. Thanks and regards, Peter. |
Tray icon does not work for me on Ubuntu 18.04 GNOME out of the box. So, I think we definitely want the floating icon to be visible on GNOME desktops.
Fair enough.
OK, I agree. Should that be tracked as a different issue?
My plan is to hide it from the window list once its display can be controlled in a more fine grained manner.
It shows at the center of the screen for me on Xfce. Maybe that's a better place? There's no guarantee that the tray is at the bottom right as many DEs offer configurable panel placement.
Oh right, that was added in GTK+ 3.22... I don't know what the equivalent is for older versions
This is very icon theme dependent. I actually like the Numix-Circle variant of the icon more than the stock one, since it has a more regular shape. I think opacity should definitely be configurable, and maybe size. There are only a few default sizes to pick from (and they are the ones that probably scale best), https://valadoc.org/gtk+-3.0/Gtk.IconSize.html
I couldn't get that working; raising the menu causes the widget to defocus, and we don't want any attempted drag action to pull up the menu. Maybe a delay would work here?
Cheers :) |
… is already started" This reverts commit d641c83.
|
Some more thoughts on preferences integration:
I know it probably makes sense to make the controls available in the preferences dialog, but I feel that only doing that is still a clunky solution. The dialog fills up quite a lot of the screen if someone wants to scroll between wallpapers and see how they look. |
Probably, though it's kind of a far-future wishlist one. There's multiple more important things than this.
Center I would consider the worst possible place - it'll be like an eye-sore for most users in the center of their beautiful wallpaper :)
I think whatever we use now for the "Add..." button. We had bugfixes targeting this.
Ok, no matter which icon variant we use, I'm pretty certain it should be a very toned down greyscale, flat-looking thing, and I think the default indicator icon fits this description better than the app icon. We may want to prepare a dedicated third one and so that it is also separately themeable.
What could work to solve several of the mentioned issues (Wayland, dragging vs left-clicking, size configuration) is a right-click menu item "Configure widget placement...", which would make the widget window decorated and allow the user to move and scale it. Thus we won't have to rely on custom code for dragging and won't need dedicated GUI options for size. |
I'm trying to say that we should not consider this icon as having "open" and "non-open" or "focused"/ "non-focused" states. It should only have "enabled" (therefore always shown), and "disabled" (therefore not shown) states. So the
I wouldn't hurry with this, unless we add it only when triggered from the control widget itself (and if we group all control-widget related menuitems in a single submenu). The right-click menu is already quite overloaded.
True, that's why I think this is a far-future wishlist item that's not so important. |
I don't really know what makes sense as a default then.
The indicator icon would have to be made scalable then (It's currently a .png)
That sounds fine, assuming that enabling / disabling decorations on runtime won't actually affect the window contents' position. (I do like the dragging ability on Xorg though - it just seems like an elegant, straightforward way to control it)
"focused" / "non-focused" wouldn't be a state per se, it would just be asking the WM to bring it to the top temporarily, if possible. Maybe this option can be removed once there's proper configuration, so far it's just been helpful for testing. I guess we're also assuming that intercepting iconify actually works on Wayland. I haven't tried yet but I'm skeptical; a lot of client-side window controls don't seem to work at all. (If we can't stick to the desktop properly, we'll need some other way of displaying it consistently...)
I just made the floating icon show the same menu as the indicator to reduce code duplication. edit: If we use a single option to show/hide the floating widget, would a subgroup still be needed? |
| if os.environ.get('XDG_SESSION_TYPE') != 'wayland': # Movement tracking doesn't work on Wayland :( | ||
| self.set_decorated(False) | ||
| self.set_accept_focus(True) | ||
| self.set_title('Variety') |
There was a problem hiding this comment.
Ideally we won't see the title anywhere, but probably still makes sense to use a descriptive one for this specific window - e.g. "Variety Control"
There was a problem hiding this comment.
The title is always shown on GNOME/Wayland since it doesn't seem undecorated windows are able to move themselves.
|
Checked the code, looks good to me so far. |
|
So, the status of this, several months later:
|
Would resolve #12 by creating a floating window for Variety (e.g. when the tray / indicator is not available).
TODO:
variety --floatingshould bring it back up.