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
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
