kill the systray?

[Aaron J. Seigo]

On Tuesday, September 24, 2013 17:06:14 Sebastian Kügler wrote:
> Hey,
> 
> Now that I have your attention ;), I'd like to discuss the future of the
> system tray. I'm porting it right now to Qt5/KF5, and running into some
> problems.
> 
> Quick background: The systemtray widget in Plasma supports three kinds of
> "Items", traditional, xembed-based systray icons, dbus statusnotifiers and
> embedded plasmoids. It's a bit of an odd widget (well, almost its own OS
> ;)), with different implementations that put all of the above three into
> one system tray. So far so good.
> 
> Two problems:
> 
> * Qt5 doesn't seem to have the API we need to do our xembed tricks anymore,
>   especially QX11EmbedContainer is gone.

it’s missing more than gone; i’ve heard several times that someone or another 
was working on it.

>   If we even get it to work under
> X11, it seems entirely futile to expect this to be feasible in a Wayland
> world.

agreed ... 

> * Embedding Plasmoids doesn't work in the new world, and notmart has not
> idea yet how to solve this

i’m sort of happy about this; it always was a hack that went against the 
overall design of things.

i’m tempted to say “just make the containment handle the system tray” but that 
leads to several new kinds of problems that, while they will only affect a 
small % of people, should be avoided.

taking a quick step back, the real issue is that we would like selected 
Plasmoids  to be able to offer a system tray version of themselves.

tbh, this really sounds like a perfect job for QML packages. as the  
systemtray itself is a plasmoid, it should be able to offer access to the same 
API that a stand-alone plasmoid would  offer.

in this approach, the battery (e.g.) would be split into two packages (or 
become a hybrid package?). when loaded as a plasmoid, everything would be as 
normal.

when loaded as a systemtray package, a different mainscript would be loaded 
that would otherwise use the exact same QML. it just wouldn’t be a plasmoid 
anymore and  the system tray itself would be responsible for loading these 
altered packages.

as i write this, the idea of a hybrid package becomes more and more desirable 
sounding. with a different main script, it should be possible to launch the 
same UI but without it being an actual plasmoid.

this would also change how plasmoids advertise they can be in the system tray: 
they would add Plasma/Systemtray (or whatever) to their ServiceTypes. there 
would be a PackageStructure for these that would load an alternate mainscript 
(which could be defined in the metadata.desktop just as we have now).

this also opens the door for extending the system tray with things that aren’t  
plasmoids. not sure that’s a purely good thing ;)

> When I asked Martin if he knew a way to do the xembed, he replied (being
> Martin ;)) asking if we can just kill it and quoted starwars. I wonder: Can
> we kill it yet?

if Gtk+ supported status notifiers natively, then i’d say “yes”. it doesn’t, so 
anyone who uses a Gtk+ application with a system tray icon will suddenly not 
be able to access it. i’m pretty sure that’s going to cause  problems.

as the GNOME devs are currently porting to Wayland as well, now would be a 
good time to find out what they plan to do with their xembed system tray.

oh, and the tasks widget ought  to gain support for application based status  
notifiers (so that the system tray can opt out of them) as well as skiplists. 
what i’d really like to see is this become a part of the wayland specific 
support that  we can build around the “every window has an associated .desktop 
file” thing. Martin?

-- 
Aaron J. Seigo
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/plasma-devel/attachments/20130924/01f03b12/attachment.sig>