Re: kde-workspace master becomes Qt5-based
On Thursday 19 September 2013 19:30:52 Sebastian Kügler wrote: Hi all, We're planning to merge the frameworks-scratch branch of kde-workspace into master next Monday. That means if you're building your Plasma yourself from Git (and you're not yet ready for Plasma2 ;)), you should switch to the KDE/4.11 branch. The build will fail otherwise, so you will notice. This was a public service announcement. (And you can ask questions here.) Follow-up: frameworks-scratch got just merged into master. Please do not push into the frameworks-scratch branch any more! 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: KDE framework 5 - a humble idea
Thank you, i will post a link to the scenario document as soon as i get back home after work. 2013/9/23 Aaron J. Seigo ase...@kde.org On Monday, September 23, 2013 14:45:53 Michele Andrea Kipiel wrote: is there a preferred way to share documents in the mailing list? is an ubuntu one link an acceptable option? as long as it is available without requiring special software installed or an account, it doesn’t particularly matter where it is stored. -- Aaron J. Seigo ___ 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: Review Request 112727: Shrink (fancy) unhide trigger when entered while FS window is active
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/112727/#review40664 --- no idea whether that's acceptable shouldn't be much of an issue. KWindowSystem is emitting a signal, isn't it? activeWindowChanged() - Martin Gräßlin On Sept. 14, 2013, 4:36 p.m., Thomas Lübking wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/112727/ --- (Updated Sept. 14, 2013, 4:36 p.m.) Review request for Plasma, Aaron J. Seigo and Martin Gräßlin. Description --- Drawback: the next trigger will go unfancied (would require listening to active window changes, no idea whether that's acceptable) but that's still much better than occluding 30 outer px of a window (see bug and http://forum.kde.org/viewtopic.php?f=111t=112163) Notice that a) nor auto unhiding neither hinting happens at all while there's a(n active) fullscreen window - this is unchanged (see early exit in patched branch) b) the patch does nothing if you don't attempt to enter the occluded area of a fullscreen window (so not even the next hinting will be affected) This addresses bug 217560. http://bugs.kde.org/show_bug.cgi?id=217560 Diffs - plasma/desktop/shell/panelview.cpp dcd051a Diff: http://git.reviewboard.kde.org/r/112727/diff/ Testing --- m_unhideTrigger shrinks and the next unhide is not indicated (but the panel appears), subsequent indication remains unaffected. Thanks, Thomas Lübking ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: kde-workspace master becomes Qt5-based
El Dimarts, 24 de setembre de 2013, a les 11:34:45, Martin Gräßlin va escriure: On Thursday 19 September 2013 19:30:52 Sebastian Kügler wrote: Hi all, We're planning to merge the frameworks-scratch branch of kde-workspace into master next Monday. That means if you're building your Plasma yourself from Git (and you're not yet ready for Plasma2 ;)), you should switch to the KDE/4.11 branch. The build will fail otherwise, so you will notice. This was a public service announcement. (And you can ask questions here.) Follow-up: frameworks-scratch got just merged into master. Please do not push into the frameworks-scratch branch any more! Can this be blocked more efficiently in the git repo instead of relying on people to do the right thing? Cheers, Albert Cheers Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Re: kde-workspace master becomes Qt5-based
On Tuesday 24 September 2013 13:51:57 Albert Astals Cid wrote: El Dimarts, 24 de setembre de 2013, a les 11:34:45, Martin Gräßlin va escriure: On Thursday 19 September 2013 19:30:52 Sebastian Kügler wrote: Hi all, We're planning to merge the frameworks-scratch branch of kde-workspace into master next Monday. That means if you're building your Plasma yourself from Git (and you're not yet ready for Plasma2 ;)), you should switch to the KDE/4.11 branch. The build will fail otherwise, so you will notice. This was a public service announcement. (And you can ask questions here.) Follow-up: frameworks-scratch got just merged into master. Please do not push into the frameworks-scratch branch any more! Can this be blocked more efficiently in the git repo instead of relying on people to do the right thing? Ben already did that. Which means kudos to our awesome sysadmins! 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: Review Request 112674: Bugfix: Make the calculator applet calculate correctly
Hi Paul, On Wednesday, September 11, 2013 18:03:57 Paul Rohrbach wrote: Thank you for accepting the patch :). But I can't commit it, because I don't have commit rights. As you've probably seen, I've committed the patch for you to the corresponding branches. Thanks a lot for your contribution (and keep 'em coming! :)). 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
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
