Tray icon alternative on GNOME, etc.

simonbcn commented 6 years ago

Arch Linux GNOME Shell 3.28.1 variety 0.6.8

The tray icon isn't shown.

jlu5 commented 6 years ago

Per https://bugs.launchpad.net/variety/+bug/1634752, have you tried installing the indicator plugin @ https://extensions.gnome.org/extension/615/appindicator-support/?

simonbcn commented 6 years ago

That extension is broken in last Gnome Shell version: https://github.com/ubuntu/gnome-shell-extension-appindicator/issues/127

jlu5 commented 6 years ago

:\

~~I'm seriously considering hacking into the desktop context menu or making a floating desktop widget at this point.~~

edit 20180815: Haha no, broken in GNOME 3.28 https://jeremy.bicha.net/2018/02/12/gnome-tweaks-3-28-progress-report-2/

simonbcn commented 6 years ago

I think the "desktop context menu" is the best option.

agravelot commented 6 years ago

I'm also facing this issue on Archlinux

X11: http://i.imgur.com/sTBNvO4.png

Wayland: http://i.imgur.com/fwkBXTz.png

simonbcn commented 6 years ago

I think this application should work without any extension and in Wayland/X11 indistinctly.

jlu5 commented 6 years ago

I think this application should work without any extension and in Wayland/X11 indistinctly.

That's easier said than done - it's not our fault that GNOME decided to deprecate tray icons while barely considering the viewpoint of other developers.

Sure they're recommending "specialised integration APIs" but we are neither a media player nor a cloud sync solution.

The entire struggle to support just about every requested desktop while they change incompatibly is already frustrating enough. I can consider making an alternate UI but comments like that aren't helpful.

peterlevi commented 6 years ago

Ok, I admit I haven't read much about what the options are, and am a bit behind currently with the whole DE updates, X vs Wayland story, etc. after 2 years with OSX on my work PC and no updates to my home PC.

But let's try to collectively list all options we have:

1. Keep the AppIndicator approach.

Pros:

Already implemented
It does seem to work OK for me by default on a cleanly installed 18.04
Wheel over it is super convenient, and I would hate to lose it as an option
Cons:
Requires extension on GNOME 3 which seems to affect many people
Not integrating super nicely, looks a bit out of hand, somewhat ugly overall (e.g. Next / Previous / Pause could have been compact media-player-like icons)
In the current form it's way too long and inconvenient with how GNOME renders it.

2. Implement the controls directly in Variety's main UI, i.e. classic application approach

Pros:

Easy to do, will work everywhere, no need to use any DE-specific APIs and tricks, completely future-proof
It's usually easy to access the app window (e.g. by pinning to the dash)
Cons:
No quick-change option via the wheel
Window will obscure the wallpaper

3. Small control window that stays below all windows (similar to how Variety Slideshow's desktop window mode works)

Pros:

Fairly standard, will maybe work mostly everywhere (???), not tied to DE-specific APIs. Needs checking, variety-slideshow's desktop mode can be used for testing.
Can stay there as a semi-transparent unobtrusive control on the desktop at all times, allowing more interactivity directly there on the desktop
Wheeling over it can work
Potentially quotes and clock can be implemented the same way, avoiding some of the current bugs stemming from them being drawn on the image (and bringing new ones... :)
Can be moved around and can persist last position
Opens some new horizons with how Variety can "enrich" the desktop.
In some utopia territory, where I had unlimited time to work on Variety: We provide a pluginnable solution for movable desktop widgets based on embedded WebKit. We implement Variety's control window (with Next/Prev/Pause, etc.) as a plugin, along with quotes, clock, calendar and other useful things.

Cons:

"Show desktop" DE functionality will actually hide it. Can we avoid? E.g. listen for window events and unminimize when minimized. Needs researching.
Quite a lot of work, quite far from what we currently have
Potentially lots of complexity around multimonitor support
Variety now has several app windows (actually three with the Thumbs window), so which one do we show when the user activates the app, questions like these string up, but should be easy to resolve.

4. Desktop menu

Can we plug into it? Is it GNOME specific, what about other DEs? As far as I've seen Unity's desktop menu is "static", haven't seen apps plug themselves there?

Cons:

No wheel scrolling option, which is a bummer. I think this is a really important type of interactivity that we should definitely provide somehow.

5. Desktop widget

I think there is no standard DE-agnostic approach for desktop widgets, right?

6. Keep appindicator for Unity and other DEs, use whatever GNOME provides natively for tray menus

Pros:

Can probably get the current functionality without the ugliness, and it will work OTOB on GNOME
Cons:
Complexity. I definitely want to avoid the situation where we implement this functionality in a DE-specific manner for every DE (e.g. I guess KDE have their own idea about the same). get_wallpaper/set_wallpaper are supposedly a much simpler problem, and it's obvious how complex they are getting with time.

7. (Based off 3, kind of goes into utopia territory again). We actually use variety-slideshow's approach to draw the wallpaper as a fullscreen window on all monitors.

Pros:

We can handle events directly over that window, which means we can wheel-scroll directly over the image, and even popup controls when user moves mouse over the background.
This opens up the potential to resolve all "different wallpaper per monitor" feature requests that so many people reported, that couldn't be done with GNOME's native desktop background drawing.
Can get the nice blending effect that's available on GNOME to work on things like XFCE, LXDE, etc.

Cons:

Complexity. We are effectively dealing ourselves with all scaling, rendering, etc. This is A LOT of work.
We'll probably need to have a no-compositor fallback mode...
Contradicts with whatever standard "desktop" options the DE provides - e.g. mounted drive icons on desktop, trash icon, etc.
High resource usage?

Other options?

After writing all this, I'm kind of inclined to do some more experimentation with 3) - if we can get a "below-all-windows" interactive, undecorated, transparent window to stay on the desktop without getting minimized, and this works on all DEs, this opens lots of possibilities. A lot of the relevant work is already done in Variety Slideshow.

jlu5 commented 6 years ago

Keep the AppIndicator approach.

I did some experimentation and it looks like we're not completely screwed yet... If you pin Variety to the dash and right click it, the .desktop actions show up and work quite nicely. (I expect that Ubuntu GNOME behaves similarly) screenshot_20180815_132041

Implement the controls directly in Variety's main UI, i.e. classic application approach

Small control window that stays below all windows (similar to how Variety Slideshow's desktop window mode works)

I would opt for a mini-window with all the standard controls (Pause, Next, Previous), plus a button to open up the larger preferences window.

Desktop menu

I don't think this is an option for latest GNOME 3 anymore. And no, I don't think it's standardized either.

Desktop widget

I think option 3 is sort of what I had in mind when I was referring to "widget", though I could be massively wrong with my terminology. (I personally don't really use the desktop much anymore)

Keep appindicator for Unity and other DEs, use whatever GNOME provides natively for tray menus

I don't think GNOME provides such an API. They want people to use stuff like MPRIS and cloud storage APIs, but we're not really either of those. (Our controls might be media player-like, but that's really too much of a hack for my tastes)

(Based off 3, kind of goes into utopia territory again). We actually use variety-slideshow's approach to draw the wallpaper as a fullscreen window on all monitors.

Whaaaat?! -1 from me for reinventing multiple wheels :P (Multi-monitor support would be nice, but I think we should abstract that out differently)

After writing all this, I'm kind of inclined to do some more experimentation with 3) - if we can get a "below-all-windows" interactive, undecorated, transparent window to stay on the desktop without getting minimized, and this works on all DEs, this opens lots of possibilities. A lot of the relevant work is already done in Variety Slideshow.

I agree that this is the best approach. +1 for interactive and below other windows, but I'm fairly neutral on transparency and removing window decorations (possible compatibility issues with some WMs?). In any case if the control window is small enough the portion covered won't matter much - and maybe we want common decorations so that the window can be easily hidden/minimized?

peterlevi commented 6 years ago

You underestimate how many people prefer their desktop completely clean off of any distractions. I'm myself one actually :). If I'm going to be looking at a pretty picture, I want to see it in its full glory without obstructions. Maybe even a single icon would bug me. I'd certainly not want a fully-decorated window hanging constantly around. Hence what I see is a super-minimal mostly transparent widget, perhaps just a small single rounded icon (but prev/next/pause icons could also work) that can be dragged to any corner, handles mouse wheel for next/previous, and can be clicked to either 1. show a bigger list of options like those we provide now or 2. show the main window.

BTW, right now we have quite a lot of options in the menu that are not present in the preferences, and would be kind of out of place there, unless we design a new tab along the lines of "Current wallpaper". So option 2) is not really trivial.

Re: "multiple wheels", I liked that phrase :) Well, it is quite exact, I agree, and I wouldn't start in that direction, but it does open lots of possibilities that are not supported well by the current desktop-drawing system.

peterlevi commented 6 years ago

It's even possible, and maybe better, to use a completely transparent "action zone" (e.g. the rightmost 100px on every monitor) that gets highlighted only when the Preferences window is open (to show where it is), potentially its size and position can be configured, and handles wheel-scroll and right-click for a menu. So it's essentially providing a large "canvas" for interactivity without obstructing the picture at all.

But this all needs experimenting on different DEs before we can commit to it.

jlu5 commented 6 years ago

You underestimate how many people prefer their desktop completely clean off of any distractions. I'm myself one actually :). If I'm going to be looking at a pretty picture, I want to see it in its full glory without obstructions. Maybe even a single icon would bug me. I'd certainly not want a fully-decorated window hanging constantly around.

Yeah, it shows that I'm not a UX designer...

Hence what I see is a super-minimal mostly transparent widget, perhaps just a small single rounded icon (but prev/next/pause icons could also work) that can be dragged to any corner, handles mouse wheel for next/previous

Either style sounds good to me (one icon or media player like). Would it also work to have it be freely movable if you hold down the widget and drag it around?

and can be clicked to either 1. show a bigger list of options like those we provide now or 2. show the main window. BTW, right now we have quite a lot of options in the menu that are not present in the preferences, and would be kind of out of place there, unless we design a new tab along the lines of "Current wallpaper". So option 2) is not really trivial.

I think the Preferences window is fine as is, and that the widget should match the .desktop entry menu (which already includes a link to Preferences)

It's even possible, and maybe better, to use a completely transparent "action zone" (e.g. the rightmost 100px on every monitor) that gets highlighted only when the Preferences window is open (to show where it is), potentially its size and position can be configured, and handles wheel-scroll and right-click for a menu. So it's essentially providing a large "canvas" for interactivity without obstructing the picture at all.

I feel like this has more of a learning curve than it needs to (i.e. elements that look like they disappear but still respond to mouse controls). A small translucent widget should suit fine IMO

peterlevi commented 6 years ago

Tested briefly today and 3) is an option at least on 16.04 with Unity, I can intercept the window iconify event and bring it back, which handles the "Show Desktop" case well. I've committed the changes to variety-slideshow (when run with --mode=desktop), and this can be used to test in other environments.

But thinking about the problem, it does add quite a lot of complexity, and when I think more about it, I still prefer a classical tray icon and menu over a similar home-baked solution.

Tested again today on 18.04 on a very low-resolution screen, and while not perfect, the menu is completely functional and usable on an out-of-box setup, with the most important options being easily accessible just as on Unity. And it does work both under X11 and Wayland for me. There were issues with the thumb window positioning under Wayland, but that's a different problem.

I also notice that on non-Unity DEs we add two items at the top of the menu - Next and Previous, plus a separator, that are not necessary on GNOME 3, as the wheel scrolling works OK there. We can remove those, this will compact the menu a bit.

Can we test and summarize a bit more systematically what are the conditions that cause issues and how unavoidable they are? E.g. as far as I see, all is green under a fresh 18.04 install. What about Debian? I'm really mostly concerned about how things work under a default DE setup. We can never guarantee things would work on someone's customized desktop. The Linux desktop has once again become more fragmented than it's manageable from a developer's standpoint it seems...

jlu5 commented 5 years ago

I started experimenting with a way to force open the menu from the .desktop entry in the indicator-free-workaround branch, but that only seems to work consistently on Xorg. On Xorg it shows right under the cursor, but on Wayland it's flaky and the menu opens only half the time.

I think I'll try the floating widget idea next. edit: see the floating-window branch

tglman commented 5 years ago

Hi all,

I use gnome-shell with topIcons extension, and i can see the icon when i start the X session but not the Wayland session.

Regards

znmeb commented 5 years ago

@tglman (and everyone else) Topicons and its descendants like topicons plus aren't very well maintained. The fundamental issue, as well noted above, is that GNOME have deprecated the whole concept of a tray icon - isn't part of their user interface vocabulary any more. So varying extensions to display the "tray icons" are doomed.

I have the extension that works on Ubuntu 18.04, KStatusNotifierItem/AppIndicator Support. It works for some of my apps but not for Variety. I'm using the workaround - right-click on the dash icon to get the menu - on Arch with GNOME 3.32 and I'm fine with that.

tglman commented 5 years ago

Hi,

for the GNOME sys-tray icons someone could be interested to this tread: https://mail.gnome.org/archives/desktop-devel-list/2019-March/msg00020.html and maybe add some use cases there.

Regards

varietywalls / variety