Re: Re: kill the systray?
2013/9/25 Martin Gräßlin mgraess...@kde.org: 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: 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?
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 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?
2013/9/26 Aaron J. Seigo ase...@kde.org: 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 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 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: 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
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
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
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 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?
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 mgraess...@kde.org: 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, 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?
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?
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 notm...@gmail.com: 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, 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?
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 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, 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
