Re: Review Request 117455: [kglobalaccel] Remove Component::showKCM
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117455/#review55804 --- David Faure changed the code with 1206a3eaaf31c5438011a53c4839e27249037ac0 to use QProcess. Should we still apply this patch or not? - Martin Gräßlin On April 9, 2014, 7:05 p.m., Martin Gräßlin wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117455/ --- (Updated April 9, 2014, 7:05 p.m.) Review request for Plasma. Repository: plasma-workspace Description --- [kglobalaccel] Remove Component::showKCM Component::showKCM was a method exported to DBus to wrap the invocation of kcmshell5 keys. According to lxr there is no application using this DBus method and it's not much use anyway as it doesn't open the keys KCM for the component. This removes the KIOWidgets dependency from kglobalaccel. Diffs - kglobalaccel/CMakeLists.txt b77f85edab091fd260fb9bddb1ddb43df445c5fe kglobalaccel/component.h 019c315374ecd226cb0820519a76bdbc3ced678c kglobalaccel/component.cpp 72a4980a3c26140bde692d376338da03dc67086e Diff: https://git.reviewboard.kde.org/r/117455/diff/ Testing --- Thanks, Martin Gräßlin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: RFC: plasma tooltips animations
On Monday 14 April 2014 19:12:50 Martin Gräßlin wrote: I think these problems are fixable. First obvious question: do Tooltips use PlasmaCore.Dialog? If yes I suggest that we move them to an own C++ implementation - Dialog is a beast in interaction and we might have taken it too far. KISS might help here, adding an XSync where a sync is needed, adding unit tests/integration tests against KWin could help, too. I did a very, very rough attempt in the branch mart/customTooltipDialog has no shadow, no transparency, sizing is kindof broken.. but that's *not* the point what i need, is several people testing it and see wether it gives the same problems as using a full dialog, i just need some people that keep it for a while and put the thing on a stress test (like going repeatedly with the mouse over all tooltip areas to change and move the tooltips around as fast as possible) and see if it's less crashy. then variants can be tried like making it transparent again, with shadows etc, to see if is one of those things that is causing problems. -- Marco Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Minutes Monday Plasma hangout
On Mon, Apr 7, 2014 at 12:55 PM, Marco Martin notm...@gmail.com wrote: jens * planning of wallpaper contest Any news on that^? Cheers -- Martin Klapetek | KDE Developer ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Plasma::PluginLoaderLLloadRunner()
Hi all, i just seen that in libplasma there is still a reference to krunner, so i would like to move it out. it's pluginloader.h - loadRunner() it's this used somewhere, like in the krunner repository/milou? the static method may even be moved somewhere in krunner or just yanked if not used. -- Marco Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 117563: React to containment status changes
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117563/ --- (Updated April 15, 2014, 12:16 p.m.) Review request for Plasma. Changes --- Apparently, I never understood what unhide was doing. This patch makes it possible to control when to show the panel when we're in auto-hide mode and uses it to react to the Containment::status changes, as well as the Plasma::Applet::activated signals. Now everything seems to be working correctly here. Repository: plasma-workspace Description --- At the moment the Panel didn't have any code to react status changes from the containment (and therefore its applets). This patch aims to add this, only problem being that it doesn't work. The unhide requested and unhiding messages are being displayed though. I've been looking for the code that does the actual display of the auto-hiding panels and I wasn't able to find it, help is welcome. Diffs (updated) - shell/panelview.h 056a1e4 shell/panelview.cpp 53d690a Diff: https://git.reviewboard.kde.org/r/117563/diff/ Testing --- Thanks, Aleix Pol Gonzalez ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 117563: React to containment status changes
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117563/#review55807 --- Ship it! seems good, not too much sure about method names shell/panelview.cpp https://git.reviewboard.kde.org/r/117563/#comment38858 i don't like adoptcontainment name that much. since is a reaction to containment change, would be better like containmentChange() (or better ideas for the name if any) - Marco Martin On April 15, 2014, 12:16 p.m., Aleix Pol Gonzalez wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117563/ --- (Updated April 15, 2014, 12:16 p.m.) Review request for Plasma. Repository: plasma-workspace Description --- At the moment the Panel didn't have any code to react status changes from the containment (and therefore its applets). This patch aims to add this, only problem being that it doesn't work. The unhide requested and unhiding messages are being displayed though. I've been looking for the code that does the actual display of the auto-hiding panels and I wasn't able to find it, help is welcome. Diffs - shell/panelview.h 056a1e4 shell/panelview.cpp 53d690a Diff: https://git.reviewboard.kde.org/r/117563/diff/ Testing --- Thanks, Aleix Pol Gonzalez ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Re: Re: An alternative for XEmbed
On Tue, Apr 15, 2014 at 7:17 AM, Martin Gräßlin mgraess...@kde.org wrote: On Monday 14 April 2014 23:38:55 Aleix Pol wrote: On Mon, Apr 14, 2014 at 8:09 PM, Martin Gräßlin mgraess...@kde.org wrote: On Monday 14 April 2014 20:04:48 Marco Martin wrote: On Monday 14 April 2014 19:51:02 Martin Gräßlin wrote: On Monday 14 April 2014 19:19:33 Aleix Pol wrote: Hi, I've been using Plasma Next for the last days, and I must say it's really annoying to get applications lost on close, because they don't appear on the system tray and they expect to. Can we maybe figure out some alternatives so that it's bearable? Sure. Install wmsystemtray and run it as: wmsystemtray --bg-color white --non-wmaker can we try to do that automaticly-ish out of the box? would be a tiny dependency anyways Really? It's a pretty ugly piece of software I wouldn't want to ship. It's more like we should put down somewhere docs to I lost my systray icon how to get it back?. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel Nice or ugly, I think we want to have an official way to support it. It's fine that it's separate because it's deprecated but we still don't want to disregard users that have needs of such feature... Right, that's why I wrote we should document that. But don't add it to the default set of software run in a Plasma Session. Cheers Martin Idea.. Can you somehow detect if an application wants to do XEmbed stuff? If it wants to while there is no wmsystemtray configured you should annoy the user and ask if we should enable the wmsystemtray for him automatically since an app wants to make use of it. Obviously if other apps also use xembed and wmsystemtray is enabled then you should not bother the user. I think this gives the best of both worlds. - wmsystemtray is gone by default but added when needed - those apps that still use xembed will remain working just fine - novice users don't have to bother about manually installing wmsystemtray You should definitely not place the burden of installing wmsystemtray on the user imho. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 117563: React to containment status changes
On April 15, 2014, 12:40 p.m., Marco Martin wrote: shell/panelview.cpp, line 759 https://git.reviewboard.kde.org/r/117563/diff/2/?file=266126#file266126line759 i don't like adoptcontainment name that much. since is a reaction to containment change, would be better like containmentChange() (or better ideas for the name if any) True, what was I thinking? Changed it to ::containmentChanged(). - Aleix --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117563/#review55807 --- On April 15, 2014, 12:16 p.m., Aleix Pol Gonzalez wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117563/ --- (Updated April 15, 2014, 12:16 p.m.) Review request for Plasma. Repository: plasma-workspace Description --- At the moment the Panel didn't have any code to react status changes from the containment (and therefore its applets). This patch aims to add this, only problem being that it doesn't work. The unhide requested and unhiding messages are being displayed though. I've been looking for the code that does the actual display of the auto-hiding panels and I wasn't able to find it, help is welcome. Diffs - shell/panelview.h 056a1e4 shell/panelview.cpp 53d690a Diff: https://git.reviewboard.kde.org/r/117563/diff/ Testing --- Thanks, Aleix Pol Gonzalez ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Re: Re: An alternative for XEmbed
2014-04-15 15:03 GMT+02:00 Mark Gaiser mark...@gmail.com: [...] Idea.. Can you somehow detect if an application wants to do XEmbed stuff? If it wants to while there is no wmsystemtray configured you should annoy the user and ask if we should enable the wmsystemtray for him automatically since an app wants to make use of it. Obviously if other apps also use xembed and wmsystemtray is enabled then you should not bother the user. I think this gives the best of both worlds. - wmsystemtray is gone by default but added when needed - those apps that still use xembed will remain working just fine - novice users don't have to bother about manually installing wmsystemtray You should definitely not place the burden of installing wmsystemtray on the user imho. It's more for putting pressure on the developers, I guess. If there is an easily accessible workaround, developers will not switch to a modern solution quickly, because a workaround is trivial to do for the users. Also, users don't put pressure on e.g. vendors of proprietary applications. What might make sense is that the distributor installs this stuff automatically in case some application is installed which won't ship without XEmbed stuff in the near future. It would be interesting to know how many apps would be affected by missing XEmbed-systray. If it's not many, adding and easy workaround is IMHO not a good idea. If there are more of these apps, I think adding your solution temporarily would make seome sense indeed. Cheers, Matthias ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: An alternative for XEmbed
On Mon, Apr 14, 2014 at 11:21 PM, Martin Gräßlin mgraess...@kde.org wrote: Sure. Install wmsystemtray and run it as: wmsystemtray --bg-color white --non-wmaker It also helps to have a window rule in KWin to make it a dock window and undecorated: [1] Description=Application settings for wmsystemtray desktop=-1 desktoprule=2 noborder=true noborderrule=2 skippager=true skippagerrule=2 skipswitcher=true skipswitcherrule=2 skiptaskbar=true skiptaskbarrule=2 type=2 typerule=2 wmclass=wmsystemtray0 wmsystemtray wmclasscomplete=true wmclassmatch=1 Cheers Martin P.S.: yes I want to write a blog post about it. I am going to put it in Plasma Next forums.. :) -- Bhushan Shah http://bhush9.github.io IRC Nick : bshah on Freenode ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 117563: React to containment status changes
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117563/#review55810 --- Ship it! Ship It! - Marco Martin On April 15, 2014, 12:16 p.m., Aleix Pol Gonzalez wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117563/ --- (Updated April 15, 2014, 12:16 p.m.) Review request for Plasma. Repository: plasma-workspace Description --- At the moment the Panel didn't have any code to react status changes from the containment (and therefore its applets). This patch aims to add this, only problem being that it doesn't work. The unhide requested and unhiding messages are being displayed though. I've been looking for the code that does the actual display of the auto-hiding panels and I wasn't able to find it, help is welcome. Diffs - shell/panelview.h 056a1e4 shell/panelview.cpp 53d690a Diff: https://git.reviewboard.kde.org/r/117563/diff/ Testing --- Thanks, Aleix Pol Gonzalez ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 117565: Expose the quit slot on KDBusService-enabled applications
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117565/#review55813 --- Not sure if exporting all Slots is what we want, but I think we do want to have Quit exposed in dbus. - Àlex Fiestas On April 14, 2014, 4:12 p.m., Aleix Pol Gonzalez wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117565/ --- (Updated April 14, 2014, 4:12 p.m.) Review request for KDE Frameworks and Plasma. Repository: kdbusaddons Description --- Makes it possible to use kquitapp again. So far quit wasn't being exposed because QCoreApplication::quit is not a scriptable slot, but a regular slot instead. Diffs - src/kdbusservice.cpp 497c774 Diff: https://git.reviewboard.kde.org/r/117565/diff/ Testing --- Now I have a way to close plasma-shell that doesn't lose all unsaved configuration. Thanks, Aleix Pol Gonzalez ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 117563: React to containment status changes
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117563/ --- (Updated April 15, 2014, 2:03 p.m.) Status -- This change has been marked as submitted. Review request for Plasma. Repository: plasma-workspace Description --- At the moment the Panel didn't have any code to react status changes from the containment (and therefore its applets). This patch aims to add this, only problem being that it doesn't work. The unhide requested and unhiding messages are being displayed though. I've been looking for the code that does the actual display of the auto-hiding panels and I wasn't able to find it, help is welcome. Diffs - shell/panelview.h 056a1e4 shell/panelview.cpp 53d690a Diff: https://git.reviewboard.kde.org/r/117563/diff/ Testing --- Thanks, Aleix Pol Gonzalez ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 117563: React to containment status changes
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117563/#review55815 --- This review has been submitted with commit dae9b75fe2a237635cbe921cb9e0e42357b3e1e7 by Aleix Pol to branch master. - Commit Hook On April 15, 2014, 12:16 p.m., Aleix Pol Gonzalez wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117563/ --- (Updated April 15, 2014, 12:16 p.m.) Review request for Plasma. Repository: plasma-workspace Description --- At the moment the Panel didn't have any code to react status changes from the containment (and therefore its applets). This patch aims to add this, only problem being that it doesn't work. The unhide requested and unhiding messages are being displayed though. I've been looking for the code that does the actual display of the auto-hiding panels and I wasn't able to find it, help is welcome. Diffs - shell/panelview.h 056a1e4 shell/panelview.cpp 53d690a Diff: https://git.reviewboard.kde.org/r/117563/diff/ Testing --- Thanks, Aleix Pol Gonzalez ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Alpha 2
Alpha 2 is scheduled for a week today but as I understand it much of what was kde-runtime is now in KF5. So a new KF5 release will be needed which is not due until May 1st. Talking to KF5's Kevin he doesn't want a sudden new KF5 release and I doubt it's possible to give a load of patches with it. Should we cancel Alpha 2 and wait for Beta on May 6th? Jonathan ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 117450: Add Milou to the default panel layout
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117450/ --- (Updated April 15, 2014, 3:22 p.m.) Status -- This change has been discarded. Review request for Plasma. Repository: plasma-desktop Description --- KRunner is hidden away as it is only accessible via a shortcut. It will be nice to have the plasmoid visible by default. It will not be an extra dependency as plasma-workspace already depends on Milou because of KRunner. Diffs - desktoppackage/contents/layout.js 303e7af Diff: https://git.reviewboard.kde.org/r/117450/diff/ Testing --- Thanks, Vishesh Handa ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: APIDox for Plasma Framework
On Tue, Apr 15, 2014 at 3:28 PM, Aurélien Gâteau agat...@kde.org wrote: Alex Merry wrote: On 12/04/14 12:48, Aleix Pol wrote: Hi, I just realized that we're not generating the API documentation for Plasma Framework here [1]. Maybe it would be worth adding? I think it currently just grabs everything in /frameworks on project.kde.org. Indeed, Allen told me just this. Just ask for plasma-frameworks to be moved from /playground/libs to /frameworks and it should appear on api.kde.org. Aurélien ___ Kde-frameworks-devel mailing list kde-frameworks-de...@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel Ok, I just requested the move. Aleix ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Alpha 2
On Tue, Apr 15, 2014 at 05:57:56PM +0200, Aleix Pol wrote: With your distribution maintainer hat on, do you think an alpha 2 would reach users? Only if distros could package it and if it is co-installable. Since it requires a more recent version of KF5 it's not at all easy for distros to package it, and I suspect there's still plenty of bits that aren't co-installablle. I'm working on the ubuntu release this week so not able to confirm all this but will get to it after Thursday. Jonathan ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: An alternative for XEmbed
On Tuesday 15 April 2014 15:30:44 Matthias Klumpp wrote: It's more for putting pressure on the developers, I guess. If there is an easily accessible workaround, developers will not switch to a modern solution quickly, because a workaround is trivial to do for the users. Also, users don't put pressure on e.g. vendors of proprietary applications. What might make sense is that the distributor installs this stuff automatically in case some application is installed which won't ship without XEmbed stuff in the near future. It would be interesting to know how many apps would be affected by missing XEmbed-systray. If it's not many, adding and easy workaround is IMHO not a good idea. If there are more of these apps, I think adding your solution temporarily would make seome sense indeed. Cheers, Matthias I agree with you, somebody should do an analysis of how things are right now and put all the documentation on a wiki page so we can come out with the best solution. Another thing to take into account is that there are patches for gtk2/3 + qt4 to use statusnotifier (by Ubuntu) and future version of Qt will use statusnotifier as well, meaning that given the correct environment we should be mostly fine. Thing is, I don't think anybody has even documented how to setup that environment (my wiki search skills suck). Cheers. 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: An alternative for XEmbed
On Tue, Apr 15, 2014 at 6:14 PM, Àlex Fiestas afies...@kde.org wrote: Another thing to take into account is that there are patches for gtk2/3 + qt4 to use statusnotifier (by Ubuntu) and future version of Qt will use statusnotifier as well, meaning that given the correct environment we should be mostly fine. For the record, on Kubuntu these Qt4 patches seems to have no effect with Plasma Next - I still don't get any SNIs for apps (like Clementine) :/ Nevertheless, is there any chance to get that patch upstream (to Qt4)? Otherwise it's just a small subset of users who will get proper systray icons. Cheers -- Martin Klapetek | KDE Developer ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: An alternative for XEmbed
On Monday, 2014-04-14, 20:09:14, Martin Gräßlin wrote: On Monday 14 April 2014 20:04:48 Marco Martin wrote: On Monday 14 April 2014 19:51:02 Martin Gräßlin wrote: On Monday 14 April 2014 19:19:33 Aleix Pol wrote: Hi, I've been using Plasma Next for the last days, and I must say it's really annoying to get applications lost on close, because they don't appear on the system tray and they expect to. Can we maybe figure out some alternatives so that it's bearable? Sure. Install wmsystemtray and run it as: wmsystemtray --bg-color white --non-wmaker can we try to do that automaticly-ish out of the box? would be a tiny dependency anyways Really? It's a pretty ugly piece of software I wouldn't want to ship. It's more like we should put down somewhere docs to I lost my systray icon how to get it back?. I am not sure what Marco was referring to, but maybe he meant have this rule file shipped by default? I.e. if a user launches that program it is handled well out-of-the-box. 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: An alternative for XEmbed
On Tuesday 15 April 2014 20:52:32 Kevin Krammer wrote: Really? It's a pretty ugly piece of software I wouldn't want to ship. It's more like we should put down somewhere docs to I lost my systray icon how to get it back?. I am not sure what Marco was referring to, but maybe he meant have this rule file shipped by default? I.e. if a user launches that program it is handled well out-of-the-box. yeah, having the rule by default would be good. about wmsystemtray, we should have an official recomendations for the distributions to have it packaged (not sure how much is widespread, maybe is enough already) -- Marco Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: An alternative for XEmbed
On Tuesday 15 April 2014 18:27:08 Martin Klapetek wrote: On Tue, Apr 15, 2014 at 6:14 PM, Àlex Fiestas afies...@kde.org wrote: Another thing to take into account is that there are patches for gtk2/3 + qt4 to use statusnotifier (by Ubuntu) and future version of Qt will use statusnotifier as well, meaning that given the correct environment we should be mostly fine. For the record, on Kubuntu these Qt4 patches seems to have no effect with Plasma Next - I still don't get any SNIs for apps (like Clementine) :/ There is a whitelist iirc Nevertheless, is there any chance to get that patch upstream (to Qt4)? Otherwise it's just a small subset of users who will get proper systray icons. Cheers 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: An alternative for XEmbed
On Tue, Apr 15, 2014 at 9:21 PM, Marco Martin notm...@gmail.com wrote: On Tuesday 15 April 2014 20:52:32 Kevin Krammer wrote: Really? It's a pretty ugly piece of software I wouldn't want to ship. It's more like we should put down somewhere docs to I lost my systray icon how to get it back?. I am not sure what Marco was referring to, but maybe he meant have this rule file shipped by default? I.e. if a user launches that program it is handled well out-of-the-box. yeah, having the rule by default would be good. about wmsystemtray, we should have an official recomendations for the distributions to have it packaged (not sure how much is widespread, maybe is enough already) -- Marco Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel I don't think we can just tell people to use wmsystemtray. We should find some way to integrate it, at least, maybe have a plasmoid that requests the space and puts it in a smart place or something. Aleix ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
