Re: kill the systray?
On Thursday, September 26, 2013 12:19:11 Matthias Klumpp wrote: > Incompatibilities are okay, IMHO, as long as they really > provide improvements and are not just bikeshed about e.g. function > naming or wheel-reinventing of working specs. even then, it’s often best to just use what is already there and extend it as necessary. creating new things comes with huge costs, not just to us but in particular to our users and 3rd party app developers. users get to deal with chaos while everyone re-syncs their implementations; they get to deal with new bugs; and devel time spent on doing that could have been spent delivering new value to the user instead of re-providing the same features that already exist. 3rd party app devs now get to deal with yet another possible protocol / spec in a big feature matrix with different versions of different environments supporting different things. i think people hugely underestimate the cost of new specs. we need to show a respect for *platform development*. it’s not our own little sandbox / toybox, we’re not just adding new features here and there with no knock-on costs. in a phrase: we aren’t writing the next application, we’re working on platform definitions. so this new notification spec had better be the most amazing thing ever and come with hot chocolate and dancing butterflies. > > if that is indeed what happens and it becomes a GNOME Shell specific > > thing, i don’t think we should implement support for it for all the same > > reasons we’re not implementing support for Mir. > > Jup, we shouldn't do that then. But I can't see what is GNOME-specific > about it (yet). what is GNOME-specific: it is being developed for GNOME Shell and it will only be implemented there. meanwhile, we have existing specs that many others are using. > Meanwhile I will ask some people at GNOME about placing the "tray" > data at different positions and implementing a tray XDG spec in line > with GNOME design principles. so .. you want to make yet another system tray protocol? despite the fact that we have one that is used by other projects, including unity? if so, that has got to be the worst idea i’ve heard all week. we don’t need more specs just to satisfy one projects NIH or self-centered insistence that their design principles somehow invalidates all other things. because if we go down that road, then one project will design everything with no input from anyone else. all the other projects become vassals without any self-direction to that project. and seriously: fuck that. -- Aaron J. Seigo ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: kill the systray?
On Thursday, September 26, 2013 12:19:11 Matthias Klumpp wrote: > Maybe the persistent-notifications-after-reboot thing will be a > (solvable) issue. It's surely solvable, but is this really a problem? I don't think so, since usually, the user shuts down the system which means, she saw the notification already. To be honest, I don't think any notification is critical, most are fire-and-forget and are invalid and useless after a reboot anyway. For suspend, it's a complete non-issue. -- sebas http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9 ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: kill the systray?
2013/9/26 Aaron J. Seigo : > On Wednesday, September 25, 2013 23:06:42 Matthias Klumpp wrote: >> I also fear that, but this was a statement by single developers, which >> I don't think is true. > > it is the developer responsible for the component in question, and apparently > he’s already doing work to create new incompatibilities in the messaging spec. That is indeed bad if it comes from the person responsible for the feature. Incompatibilities are okay, IMHO, as long as they really provide improvements and are not just bikeshed about e.g. function naming or wheel-reinventing of working specs. So let's see what will be proposed at XDG. > if that is indeed what happens and it becomes a GNOME Shell specific thing, i > don’t think we should implement support for it for all the same reasons we’re > not implementing support for Mir. Jup, we shouldn't do that then. But I can't see what is GNOME-specific about it (yet). Maybe the persistent-notifications-after-reboot thing will be a (solvable) issue. We would still have a problem with applications which only provide a tray icon for interaction... It would be nice to solve that. Unfortunately, I am busy with AppStream and Listaller stuff, but I would love to help with the notification/tray/GNOME-KDE-XDG-communication issues. I think I will have some time in mid-October. Meanwhile I will ask some people at GNOME about placing the "tray" data at different positions and implementing a tray XDG spec in line with GNOME design principles. But I don't expect much success there - it's worth a try anyway ;-) Cheers, Matthias -- Debian Developer | Freedesktop-Developer KDE-Developer| GNOME-Contributor I welcome VSRE emails. See http://vsre.info/ ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: kill the systray?
On Wednesday, September 25, 2013 23:06:42 Matthias Klumpp wrote: > I also fear that, but this was a statement by single developers, which > I don't think is true. it is the developer responsible for the component in question, and apparently he’s already doing work to create new incompatibilities in the messaging spec. if that is indeed what happens and it becomes a GNOME Shell specific thing, i don’t think we should implement support for it for all the same reasons we’re not implementing support for Mir. -- Aaron J. Seigo ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: kill the systray?
On Thursday, 2013-09-26, Martin Gräßlin wrote: > On Thursday 26 September 2013 11:35:02 Marco Martin wrote: > > On Thursday 26 September 2013 01:27:54 Aaron J. Seigo wrote: > > > The only remaining problem then becomes Qt5. QSystemTrayIcon does not > > > support the DBus protocol .. it should, really, since the two largest > > > Linux > > > desktop envs built on Qt use it ;) > > > > back in the days i remember a big blocker was that qtgui must not depend > > from qtdbus > > That's probably still the case and I also thought that this might be the > case. But maybe we can do something with a plugin like the DBusMenu stuff? > Really awesome would be if we could enforce status notifiers through our > QPA plugin. Going through the QPA is probably the way forward. It is just one more of those things that where done through #ifdef in pre-QPA times that can now be better solved through new facilities. My guess would be an addition to QPlatformTheme, it has similar things like native dialog and native menu/menubar integration already. Cheers, Kevin -- Kevin Krammer, KDE developer, xdg-utils developer KDE user support, developer mentoring 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
Re: Re: kill the systray?
On Thursday 26 September 2013 11:35:02 Marco Martin wrote: > On Thursday 26 September 2013 01:27:54 Aaron J. Seigo wrote: > > The only remaining problem then becomes Qt5. QSystemTrayIcon does not > > support the DBus protocol .. it should, really, since the two largest > > Linux > > desktop envs built on Qt use it ;) > > back in the days i remember a big blocker was that qtgui must not depend > from qtdbus That's probably still the case and I also thought that this might be the case. But maybe we can do something with a plugin like the DBusMenu stuff? Really awesome would be if we could enforce status notifiers through our QPA plugin. Cheers Martin 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
Re: kill the systray?
On Thursday 26 September 2013 01:27:54 Aaron J. Seigo wrote: > > The only remaining problem then becomes Qt5. QSystemTrayIcon does not > support the DBus protocol .. it should, really, since the two largest Linux > desktop envs built on Qt use it ;) back in the days i remember a big blocker was that qtgui must not depend from qtdbus -- Marco Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Re: kill the systray?
2013/9/25 Martin Gräßlin : > On Thursday 26 September 2013 01:27:54 Aaron J. Seigo wrote: >> On Tuesday, September 24, 2013 17:06:14 Sebastian Kügler wrote: >> > 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? >> >> I just had a discussion on G+ with a couple of our friends with GNOME about >> this matter[1]. Apparently they are thinking of just dropping support for >> system tray icons altogether, and deprecating the API in Gtk+. If that does >> indeed happen, then that is a major step towards being able to kill support >> for it. > the bad part of the discussion is that it looks like they want to reinvent the > wheel and given some statements lately (e.g. GTK+ is just for developing for > GNOME Shell) I'm not every optimistic that they will even hardly think about > anything than their system. I also fear that, but this was a statement by single developers, which I don't think is true. It would make sense to at least try to discuss stuff and try to find a consent, and I am willing to try that (there would be no harm done if this attempt fails). There are some things which GNOME does great at time (notifications, IMHO) and which might be worth looking at and working on a common spec. The "problem" with GNOME is that it is now design-driven, and everyone and everything has to accept a subordinate role to that. So, in order to convince the GNOME folks, you have to give them a usecase which matches their design goals. >> The only remaining problem then becomes Qt5. QSystemTrayIcon does not >> support the DBus protocol .. it should, really, since the two largest Linux >> desktop envs built on Qt use it ;) > looks like we need to fix that for 5.3 :-) Indeed :-) Cheers, Matthias ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Re: kill the systray?
On Thursday 26 September 2013 01:27:54 Aaron J. Seigo wrote: > On Tuesday, September 24, 2013 17:06:14 Sebastian Kügler wrote: > > 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? > > I just had a discussion on G+ with a couple of our friends with GNOME about > this matter[1]. Apparently they are thinking of just dropping support for > system tray icons altogether, and deprecating the API in Gtk+. If that does > indeed happen, then that is a major step towards being able to kill support > for it. the bad part of the discussion is that it looks like they want to reinvent the wheel and given some statements lately (e.g. GTK+ is just for developing for GNOME Shell) I'm not every optimistic that they will even hardly think about anything than their system. > > The only remaining problem then becomes Qt5. QSystemTrayIcon does not > support the DBus protocol .. it should, really, since the two largest Linux > desktop envs built on Qt use it ;) looks like we need to fix that for 5.3 :-) Cheers Martin 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
Re: kill the systray?
On Tuesday, September 24, 2013 17:06:14 Sebastian Kügler wrote: > 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? I just had a discussion on G+ with a couple of our friends with GNOME about this matter[1]. Apparently they are thinking of just dropping support for system tray icons altogether, and deprecating the API in Gtk+. If that does indeed happen, then that is a major step towards being able to kill support for it. The only remaining problem then becomes Qt5. QSystemTrayIcon does not support the DBus protocol .. it should, really, since the two largest Linux desktop envs built on Qt use it ;) [1] https://plus.google.com/u/0/110564179941764460291/posts/GrfpS9GvLqX -- Aaron J. Seigo ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: kill the systray?
On Tuesday, September 24, 2013 10:46:24 Matthias Klumpp wrote: > Sorry, I confused the naming here... And I am aware offen the previous > discussion (followed it, but was not involved) I just think that it might > make sense to start a New attempt on this, now that everyone is working > towards wayland. Talking to Xfce is a good idea too, imho. I can ask around > on this. The issue is not political. We have a fine replacement for the system tray, and we have (maybe) a technical problem supporting the old one. I'll give the QWindow solution a try, so we'll see how far we can get with that. We don't really need much of it, except painting its contents on a QQuickItem, and given we're not the only ones doing a desktop in Qt5, there's a chance we succeed with that. :) The system tray is quite a lot of work to port, so you'll hear from me again once I'm making progress in that specific area. For now, we'll not pour the baby out with the bathwater. Thanks for the valuable input, everybody. Cheers, -- sebas http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9 ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: kill the systray?
On Tuesday, September 24, 2013 10:46:24 Matthias Klumpp wrote: > Sorry, I confused the naming here... And I am aware offen the previous > discussion (followed it, but was not involved) I just think that it might > make sense to start a New attempt on this, now that everyone is working > towards wayland. I would be very interested to see what GNOME Shell people are thinking about these days and see if they are any more ammenable to working with others on this than they were a couple years ago. > Talking to Xfce is a good idea too, imho. I can ask around Agreed; if you can do so, that would be appreciated. -- 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
Re: kill the systray?
On Tuesday 24 September 2013 20:48:23 Kevin Krammer wrote: > On Tuesday, 2013-09-24, Sebastian Kügler wrote: > > * Qt5 doesn't seem to have the API we need to do our xembed tricks > > anymore, > > > > especially QX11EmbedContainer is gone. If we even get it to work under > > > > X11, it seems entirely futile to expect this to be feasible in a Wayland > > world. > > I think QWindow::fromWinId(), added in Qt5.1, is the respective replacement. > The XCB QPA plugin, for example, supports that (the capabiliy is called > ForeignWindows). I just wanted to reply that it's for something else (thought it only reparents to the window without implementing the protocol), then started to read the code and yes it looks like xembed is supported by the xcb implementation of QWindow. QWindow *foreign = QWindow::fromWinId(idOfForeignWindow); foreign->setParent(idOfOurQQuickWindow); should do the trick. Cheers Martin 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
Re: kill the systray?
On Tuesday, 2013-09-24, Sebastian Kügler wrote: > * Qt5 doesn't seem to have the API we need to do our xembed tricks anymore, > especially QX11EmbedContainer is gone. If we even get it to work under > X11, it seems entirely futile to expect this to be feasible in a Wayland > world. I think QWindow::fromWinId(), added in Qt5.1, is the respective replacement. The XCB QPA plugin, for example, supports that (the capabiliy is called ForeignWindows). Cheers, Kevin P.S.: there was a discussion on the LXDE list about supporting statusnotifier items in their tray/panel as well. -- Kevin Krammer, KDE developer, xdg-utils developer KDE user support, developer mentoring 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
Re: kill the systray?
On Tuesday 24 September 2013, Aaron J. Seigo wrote: > 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). It's an interesting concept. and yeah, i don't see much other clean solutions besides having what is in the systray not a palsmoid strictly speaking. So, the only real difference for what the qml side is concerned, is having or not the "plasmoid" global object. that would mean: * forbid plasmoids that are intended to go in the systray to refer to "plasmoid" anywhere in the code. * if what changes in the mainscript, allow there, forbid in all other qml files * giving a plasmoid object never the less: and it would be the one of the systray itself. In the first two options i can see many very subtle bugs popping up, for plasmoid not being found in the context. the last one is interesting, even tough poses some interesting problem on what plasmoid properties mean: like "expanded" is usually when the applet is either in full view in the desktop or as a popupapplet with the popup menu open... but for what plasmoid in the systray is concerned, it is "expanded" only when both the systray popup is open *and* is displaying that plasmoid in particular hmm, interesting problem :p Cheers, Marco Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: kill the systray?
Sorry, I confused the naming here... And I am aware offen the previous discussion (followed it, but was not involved) I just think that it might make sense to start a New attempt on this, now that everyone is working towards wayland. Talking to Xfce is a good idea too, imho. I can ask around on this. Cheers, Matthias Am 24.09.2013 10:35 schrieb "Marco Martin" : > On Tuesday 24 September 2013, Matthias Klumpp wrote: > > GNOME embeds the tray Icons in it's norification area, supporting xembed > > right now. In future, they want a different notification system, which is > > used exclusively (design docs are available, i will look them up at home) > > However, I assume GTK+ will have a systray implementation (at least for > > Xfce), so it makes much sense to discuss post-x systray now and create a > > Freedesktop document for it - maybe just use DBusmenu... > > dbusmenu has nothing to do with systemtrays. > we do have a post-x systemtray and is StatusNotifier, the one that ubuntu > uses > as well. (so some gtk apps supports it upstream, some have patches on > ubuntu > side) > and yes, it has been discussed on freedesktop literally to death, years > ago. > > -- > Marco Martin > ___ > Plasma-devel mailing list > Plasma-devel@kde.org > https://mail.kde.org/mailman/listinfo/plasma-devel > ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: kill the systray?
On Tuesday 24 September 2013, Marco Martin wrote: > > Xfce), so it makes much sense to discuss post-x systray now and create a > > Freedesktop document for it - maybe just use DBusmenu... > > dbusmenu has nothing to do with systemtrays. or more precisely, it's ortogonal, we use it to do the icons' context menus, while the icons are statusnotifiers, on dbus as well -- Marco Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: kill the systray?
On Tuesday 24 September 2013, Matthias Klumpp wrote: > GNOME embeds the tray Icons in it's norification area, supporting xembed > right now. In future, they want a different notification system, which is > used exclusively (design docs are available, i will look them up at home) > However, I assume GTK+ will have a systray implementation (at least for > Xfce), so it makes much sense to discuss post-x systray now and create a > Freedesktop document for it - maybe just use DBusmenu... dbusmenu has nothing to do with systemtrays. we do have a post-x systemtray and is StatusNotifier, the one that ubuntu uses as well. (so some gtk apps supports it upstream, some have patches on ubuntu side) and yes, it has been discussed on freedesktop literally to death, years ago. -- Marco Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: kill the systray?
GNOME embeds the tray Icons in it's norification area, supporting xembed right now. In future, they want a different notification system, which is used exclusively (design docs are available, i will look them up at home) However, I assume GTK+ will have a systray implementation (at least for Xfce), so it makes much sense to discuss post-x systray now and create a Freedesktop document for it - maybe just use DBusmenu... Cheers, Matthias (Sorry for the not-inline reply, sent from my phone) Am 24.09.2013 09:51 schrieb "Martin Graesslin" : > On Tuesday 24 September 2013 18:04:55 Aaron J. Seigo wrote: > > > * 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. > which wouldn't be in time for Qt 5.2 anymore. So earliest is Qt 5.3 which > might be too late for our needs. > > > > > If we even get it to work under > > > > > > X11, it seems entirely futile to expect this to be feasible in a > Wayland > > > world. > > > > agreed ... > well for supporting legacy applications it would be needed in the same way > as > for supporting GTK+ application on X11. > > > > 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. > what's the status of the Ubuntu implementation? Is it that an app has to > explicitly link against it? > > > > 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. > I just tried to find some information on how they are using it and somehow > I'm > not sure whether the xembed systray is available at all in GNOME... > > > > 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? > sounds good to me. > > Cheers > Martin > ___ > Plasma-devel mailing list > Plasma-devel@kde.org > https://mail.kde.org/mailman/listinfo/plasma-devel > > ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: kill the systray?
On Tuesday 24 September 2013, Martin Graesslin wrote: > > 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. > > what's the status of the Ubuntu implementation? Is it that an app has to > explicitly link against it? as far i know yes, libappindicator or something like that > > 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. > > I just tried to find some information on how they are using it and somehow > I'm not sure whether the xembed systray is available at all in GNOME... iirc their position is that they don't want them at all, don't know if they do work anyways tough -- Marco Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: kill the systray?
On Tuesday 24 September 2013 18:04:55 Aaron J. Seigo wrote: > > * 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. which wouldn't be in time for Qt 5.2 anymore. So earliest is Qt 5.3 which might be too late for our needs. > > > If we even get it to work under > > > > X11, it seems entirely futile to expect this to be feasible in a Wayland > > world. > > agreed ... well for supporting legacy applications it would be needed in the same way as for supporting GTK+ application on X11. > > 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. what's the status of the Ubuntu implementation? Is it that an app has to explicitly link against it? > > 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. I just tried to find some information on how they are using it and somehow I'm not sure whether the xembed systray is available at all in GNOME... > > 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? sounds good to me. Cheers Martin 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
Re: kill the systray?
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
kill the systray?
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. If we even get it to work under X11, it seems entirely futile to expect this to be feasible in a Wayland world. * Embedding Plasmoids doesn't work in the new world, and notmart has not idea yet how to solve this 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? For the plasmoid embedding, we'll need this, and I can only think of hacky things (such as the panel containment helping out by talking to the systray, for example). Thoughts, opinions, what-do-I-miss? -- sebas http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9 ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
