D19440: Exclude non-managed devices from plasma-nm
afiestas added a comment. Weirdly enough, I have never seen the veth connections in the KCM. The way I get to reproduce always this bug is: -Start NetworkMaanger -Start Docker -Run a container -Restart NetworkManager That would result in veth interfaces in the plasmoid. I do not know why a restart is required to reproduce the bug, but it makes me think that I might be missing something. REPOSITORY R116 Plasma Network Management Applet REVISION DETAIL https://phabricator.kde.org/D19440 To: afiestas, #plasma, jgrulich Cc: plasma-devel, jraleigh, GB_2, ragreen, Pitel, ZrenBot, lesliezhai, ali-mohamed, jensreuterberg, abetts, sebas, apol, mart
D19440: Exclude non-managed devices from plasma-nm
afiestas created this revision. afiestas added reviewers: Plasma, jgrulich. Herald added a project: Plasma. Herald added a subscriber: plasma-devel. Herald added 1 blocking reviewer(s): jgrulich. afiestas requested review of this revision. REVISION SUMMARY Some network devices are **not** managed by NetworkManager, for example any virtual device created by Docker, any routing devices, etc. This patch checks if the device is bring managed by NM or not before showing it into the applet. With most certainty, the patch is wrong or the check should be added elsewere, but I thought that would be nice to publish it so we can get the discussion going. TEST PLAN Load the applet with some 10 containers running. The 10 created veth interfaces should not be shown in the applet. REPOSITORY R116 Plasma Network Management Applet REVISION DETAIL https://phabricator.kde.org/D19440 AFFECTED FILES libs/models/networkmodel.cpp To: afiestas, #plasma, jgrulich Cc: plasma-devel, jraleigh, GB_2, ragreen, Pitel, ZrenBot, lesliezhai, ali-mohamed, jensreuterberg, abetts, sebas, apol, mart
Re: Review Request 125190: Daemonize the forked kwalletd process.
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/125190/#review85341 --- Ship it! The change looks good. - Àlex Fiestas On set. 12, 2015, 10:37 a.m., Xuetian Weng wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/125190/ > --- > > (Updated set. 12, 2015, 10:37 a.m.) > > > Review request for Plasma, Àlex Fiestas and Martin Klapetek. > > > Repository: kwallet-pam > > > Description > --- > > For example, if desktop is started by sddm, > - for kwalletd5, it will be a subprocess of sddm-helper. > - for kwalletd, there will be zombie subprocess of sddm-helper. > > Here we make use of the old trick to fork twice and collect the status of > intermediate process with waitpid to avoid zombie process. --nofork is used > for kwalletd case to avoid it fork yet another process. > > > Diffs > - > > pam_kwallet.c a84585e > > Diff: https://git.reviewboard.kde.org/r/125190/diff/ > > > Testing > --- > > No more zombie process, kwalletd and kwalletd5 become subprocess of pid 1. > > > Thanks, > > Xuetian Weng > > ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 123468: Add setting to adjust screen scaling
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/123468/#review83032 --- Would be nice to adjust gtk stuff as well, same values should work in theory. - Àlex Fiestas On jul. 26, 2015, 2:35 p.m., David Edmundson wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/123468/ --- (Updated jul. 26, 2015, 2:35 p.m.) Review request for Plasma. Repository: kscreen Description --- Single dialog alters both QT_DEVICE_PIXEL_RAITO and XRDB.DPI text scaling factor that used to reside in fonts KCM. A preview widget shows how this will look on the that monitor. Changes take affect after logout/login; not ideal but we're limited by the Qt QPA for now. Will try and fix that after. edit: having uploaded this I can see I have some whitespace left, please don't feel the need to tell me. Diffs - CMakeLists.txt e157a5e28e441a2e6dacb2d639cf6d120fb18c26 kcm/src/CMakeLists.txt 50bfdf037c331fe7c6763fb85c3b43857cbea5d5 kcm/src/previewwidget.h PRE-CREATION kcm/src/previewwidget.cpp PRE-CREATION kcm/src/scaling.ui PRE-CREATION kcm/src/scalingconfig.h PRE-CREATION kcm/src/scalingconfig.cpp PRE-CREATION kcm/src/stylepreview.ui PRE-CREATION kcm/src/widget.cpp 7fe96c1c8b21b19424ef4993dff9eb3985bcefdb Diff: https://git.reviewboard.kde.org/r/123468/diff/ Testing --- File Attachments the dialog https://git.reviewboard.kde.org/media/uploaded/files/2015/04/22/a8cab37c-24bf-4fb9-b50b-39bc34596938__snapshot1.png Thanks, David Edmundson ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 122008: Disable Intel swap interval for 5.2
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/122008/#review73816 --- Ship it! Would it be interesting to have a CMake option for this so people can test it out? Or is it so horribly broken? Besides that, if you think this should be disabled until +1 then so be it! - Àlex Fiestas On gen. 12, 2015, 7:57 a.m., Martin Gräßlin wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/122008/ --- (Updated gen. 12, 2015, 7:57 a.m.) Review request for kwin and Plasma. Repository: kwin Description --- The feature is pretty much untested as it depends on Qt 5.4 and this was not a requirement during the development of 5.2. On the other hand regressions in this feature are very severe as it can freeze the screen and by that render the system unusable. Given that it is better to disable for the 5.2 release as we don't know what could happen when distros start enabling Qt 5.4. It's better to stabilize the feature in the master branch for the 5.3 release which will hopefully have Qt 5.4 as a mandatory requirement. CCBUG: 342582 Diffs - glxbackend.cpp 78efa4ebc30dbad04e92129b643f27b67f59a3c7 Diff: https://git.reviewboard.kde.org/r/122008/diff/ Testing --- Thanks, Martin Gräßlin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Add your blog to the Qt planet
Hey! In the Randa sprint we discussed about how to promote all the awesome stuff we do better in the Qt community. One of the ideas we came up with was to add the blogs of our developers to the Qt planet. The process is like ours, so just clone the Qt repository www/planetqt and submit a code review at https://codereview.qt-project.org/#/admin/projects/www/planetqt I asked to the Qt community manager (in CC'd) and he said it was totally ok to add blogs of people for example working on plasma or applications. Basically anything cool done with Qt is ok! 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: Review Request 121915: Add lidClosedChanged signal to org.kde.Solid.PowerManagement
On gen. 9, 2015, 11:25 a.m., Àlex Fiestas wrote: Where do you plan to use this? We are not maintaining compatibility (so far) in our dbus apis, so why add this at all? Daniel Vrátil wrote: KScreen. For now we are listening to UPower, which IMO sucks and we should use PowerDevil instead (as it provides abstraction for alternative backends). This makes it just easier to monitor changes. Àlex Fiestas wrote: This has a few problems: 1-It couples KScreen more to PLasma by adding a runtime dependency (which is ok if you decide to do so) 2-It might create a deadlock since kscreen is a kded module asking to another module (powerdevil) for things. 3-We will depend on Powerdevil if we use kscreen in other places (sddm desperatly needs something like kscreen, or kscreen itself) 4-Adds a dependency to an api that is not stable (so far it has not been), we have changed it many times and I am sure we will change it again My recommendation for this will be to merge the new power management api in Solid and make kscreen depend on it. Solid already offers backends (so we don't have to implement this in kscreen) and we don't have to expose powerdevil internals. So this is a -1 from my side (if the only reason to add this is KSCreen). Martin Klapetek wrote: 2-It might create a deadlock since kscreen is a kded module asking to another module (powerdevil) for things. As dfaure explained in https://git.reviewboard.kde.org/r/121885/ QtDbus is really smart and in-process DBus calls are made into direct methods and should never deadlock. Which is cool :) Oh wow! One less problem to worry about then. We still need to be careful not to deadlock by doing sync calls between the same kded modules (happened already). - Àlex --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/121915/#review73569 --- On gen. 8, 2015, 12:04 p.m., Daniel Vrátil wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/121915/ --- (Updated gen. 8, 2015, 12:04 p.m.) Review request for Plasma and Solid. Repository: powerdevil Description --- There's no way to detect when lid has been closed other than listening to `changed` signal org.freedesktop.UPower and then polling the Powerdevil for new values. This patch adds a new signal to the PowerDevil interface to notify about the change and provide new value right away. Makes it much easier to use. Diffs - daemon/org.kde.Solid.PowerManagement.xml 53f77e5 daemon/powerdevilbackendinterface.h 702b66b daemon/powerdevilbackendinterface.cpp 6dd8c71 daemon/powerdevilcore.h e255703 daemon/powerdevilcore.cpp d51ab19 Diff: https://git.reviewboard.kde.org/r/121915/diff/ Testing --- Tested with qdbus-monitor, signal is emitted when laptop lid is closed/opened. Thanks, Daniel Vrátil ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 121915: Add lidClosedChanged signal to org.kde.Solid.PowerManagement
On gen. 9, 2015, 11:25 a.m., Àlex Fiestas wrote: Where do you plan to use this? We are not maintaining compatibility (so far) in our dbus apis, so why add this at all? Daniel Vrátil wrote: KScreen. For now we are listening to UPower, which IMO sucks and we should use PowerDevil instead (as it provides abstraction for alternative backends). This makes it just easier to monitor changes. This has a few problems: 1-It couples KScreen more to PLasma by adding a runtime dependency (which is ok if you decide to do so) 2-It might create a deadlock since kscreen is a kded module asking to another module (powerdevil) for things. 3-We will depend on Powerdevil if we use kscreen in other places (sddm desperatly needs something like kscreen, or kscreen itself) 4-Adds a dependency to an api that is not stable (so far it has not been), we have changed it many times and I am sure we will change it again My recommendation for this will be to merge the new power management api in Solid and make kscreen depend on it. Solid already offers backends (so we don't have to implement this in kscreen) and we don't have to expose powerdevil internals. So this is a -1 from my side (if the only reason to add this is KSCreen). - Àlex --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/121915/#review73569 --- On gen. 8, 2015, 12:04 p.m., Daniel Vrátil wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/121915/ --- (Updated gen. 8, 2015, 12:04 p.m.) Review request for Plasma and Solid. Repository: powerdevil Description --- There's no way to detect when lid has been closed other than listening to `changed` signal org.freedesktop.UPower and then polling the Powerdevil for new values. This patch adds a new signal to the PowerDevil interface to notify about the change and provide new value right away. Makes it much easier to use. Diffs - daemon/org.kde.Solid.PowerManagement.xml 53f77e5 daemon/powerdevilbackendinterface.h 702b66b daemon/powerdevilbackendinterface.cpp 6dd8c71 daemon/powerdevilcore.h e255703 daemon/powerdevilcore.cpp d51ab19 Diff: https://git.reviewboard.kde.org/r/121915/diff/ Testing --- Tested with qdbus-monitor, signal is emitted when laptop lid is closed/opened. Thanks, Daniel Vrátil ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 121915: Add lidClosedChanged signal to org.kde.Solid.PowerManagement
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/121915/#review73569 --- Where do you plan to use this? We are not maintaining compatibility (so far) in our dbus apis, so why add this at all? - Àlex Fiestas On gen. 8, 2015, 12:04 p.m., Daniel Vrátil wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/121915/ --- (Updated gen. 8, 2015, 12:04 p.m.) Review request for Plasma and Solid. Repository: powerdevil Description --- There's no way to detect when lid has been closed other than listening to `changed` signal org.freedesktop.UPower and then polling the Powerdevil for new values. This patch adds a new signal to the PowerDevil interface to notify about the change and provide new value right away. Makes it much easier to use. Diffs - daemon/org.kde.Solid.PowerManagement.xml 53f77e5 daemon/powerdevilbackendinterface.h 702b66b daemon/powerdevilbackendinterface.cpp 6dd8c71 daemon/powerdevilcore.h e255703 daemon/powerdevilcore.cpp d51ab19 Diff: https://git.reviewboard.kde.org/r/121915/diff/ Testing --- Tested with qdbus-monitor, signal is emitted when laptop lid is closed/opened. Thanks, Daniel Vrátil ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 121360: Rework Plasma's notification positioning code
On gen. 3, 2015, 8:08 p.m., Kai Uwe Broulik wrote:
applets/notifications/plugin/notificationshelper.cpp, line 51
https://git.reviewboard.kde.org/r/121360/diff/2/?file=337844#file337844line51
Use QScopedPointer
Martin Klapetek wrote:
What's wrong with properly used delete?
David Edmundson wrote:
better yet, make the mutex on the stack.
one less malloc == faster and less fragmented memory and you dont' have
to worry about the memory at all.
Martin Klapetek wrote:
I had it originally that way, however if you want to make it recursive,
you need to pass it to the constructor and the operator=() is private, so it
cannot be assigned to stack variable. So I made it a pointer.
But it's not like there's any need of management for it, it's simply
created in constructor and deleted in the destructor, nothing else to worry
about.
Martin Gräßlin wrote:
I had it originally that way, however if you want to make it recursive,
you need to pass it to the constructor and the operator=() is private, so it
cannot be assigned to stack variable.
That's not a problem, just initialize it in the initializer list of the
ctor.
Concerning the discussion on the management: I personally prefer
QScopedPointer for cases like this as it's just something less to worry about
and ideally you can get in a situation where one can use the default dtor
which (at least I have read so) is more optimized than a written one.
This this case QScopedPointer is proof for future changes in the code, while
delete it is easiert to screw it up (new return, move code around, etc).
- Àlex
---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/121360/#review73046
---
On gen. 6, 2015, 1:32 p.m., Martin Klapetek wrote:
---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/121360/
---
(Updated gen. 6, 2015, 1:32 p.m.)
Review request for Plasma and Kai Uwe Broulik.
Bugs: 339732
https://bugs.kde.org/show_bug.cgi?id=339732
Repository: plasma-workspace
Description
---
There can easily be situations where the popups could overlap one another or
result in strange animations. This patch rewrites the notifications so that
all actions such as show/reposition/hide are handled from a one single place
and every action is properly queued and protected around, which makes it more
robust, more predictive and less chaotic. There's also a slight delay between
every action so it's also visually much more cleaner and easier to see what's
going on.
Diffs
-
applets/notifications/plugin/notificationshelper.h af8f6fa
applets/notifications/plugin/notificationshelper.cpp 425f0d6
dataengines/notifications/notificationsengine.cpp d4b7f19
applets/notifications/package/contents/ui/NotificationPopup.qml 8eb1912
Diff: https://git.reviewboard.kde.org/r/121360/diff/
Testing
---
Tested whole day plus stress-tested with something like for i in {1..200}; do
notify-send $i - $RANDOM $RANDOM sdf sdf sdfwefhsdjfnskdfbkwefnos igodsfgn
sodifgj asodfgnsdlfgdf g; done executed from 4 terminals at once, all works
fine and as expected.
Thanks,
Martin Klapetek
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 121429: Use out-of-band communication between ksld and greeter
On des. 15, 2014, 10:45 p.m., Àlex Fiestas wrote: Code looks good. Could you perhaps add an integration test for this? Since we are abstracted by the socket it should be possible. If it is too much work feel free to push it. Martin Gräßlin wrote: what do you want the integration test to test? I certainly can start the daemon but I'm not sure what it would give us as the only way to return from it requires a password. And that's what the test application in tests already does. Àlex Fiestas wrote: Well, this patch adds a lot of new logic that can be tested, since it does not have unit test (and doing them in ksmserver migh prove difficult) we can test the code with an integraiton test. I see lots of socket logic I see logic in addAllowedWindow And also the biggest method setKsldSocket which has 2 lambdas that (afaik) can't be tested in any other way. Martin Gräßlin wrote: The point is I don't see how to do an integration test for it. If we pull up everything the screen is locked, like locked. It needs a damn password to be entered to get unlocked. I just don't see how this could be integration tested. If you see how to integration test it please provide the code for it. As I said, if it is too much work just push it :p. - Àlex --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/121429/#review72103 --- On des. 15, 2014, 9:29 a.m., Martin Gräßlin wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/121429/ --- (Updated des. 15, 2014, 9:29 a.m.) Review request for Plasma, Àlex Fiestas and David Edmundson. Repository: plasma-workspace Description --- The screenlocker_greet needs to tell the parent ksld process which windows it created. Ksld sends input events to these windows. So far this was based on an X property on the window. Unfortunately ksld didn't validate whether the windows tagged with this property belong to the screenlocker_greet process it started. With this change the communication for announcing windows is moved away from the X11 protocol and instead a custom Wayland protocol is used. Ksld starts a KWaylandServer when the greet process gets started. It creates anonymous unix sockets for the connection and passes one filedescriptor to the started greeter process. The check for the X property is removed in ksld and instead only windows ids passed through the Wayland socket connection are accepted. Diffs - ksmserver/screenlocker/ksldapp.cpp 22698ce37e9d4be17126111b3ded8133f7c3baa6 ksmserver/screenlocker/lockwindow.h 9938d201269c89a24c9c0bd6275aa5f731bb5535 ksmserver/screenlocker/lockwindow.cpp 3aa963a59e21636862f5ca59e220bbea3bd41ff9 ksmserver/screenlocker/protocols/ksld.xml PRE-CREATION ksmserver/screenlocker/waylandserver.h PRE-CREATION ksmserver/screenlocker/waylandserver.cpp PRE-CREATION ksmserver/screenlocker/greeter/greeterapp.h b92b13b63365a9026dba5d71b772dcd8c9ee3d3b ksmserver/screenlocker/greeter/greeterapp.cpp 30d1821bdba38028959f3457e900a1b32e628192 ksmserver/screenlocker/greeter/main.cpp 12e570107d0cba851b8978131d730b27924529bb ksmserver/screenlocker/ksldapp.h 095424c9845c134aa156917aeb6c8ddf31e8d25a CMakeLists.txt c6d89c14b05f5639937aee5692d305fa2faed974 ksmserver/screenlocker/CMakeLists.txt 5378a10df2be70cee95b5612c23046eae639f610 ksmserver/screenlocker/greeter/CMakeLists.txt 10c473488f08354096f68784b9240392a444af5f Diff: https://git.reviewboard.kde.org/r/121429/diff/ Testing --- Running ksmserver with the patch. Lock/unlock working, my exploit is failing. Thanks, Martin Gräßlin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 121429: Use out-of-band communication between ksld and greeter
On des. 15, 2014, 10:45 p.m., Àlex Fiestas wrote: Code looks good. Could you perhaps add an integration test for this? Since we are abstracted by the socket it should be possible. If it is too much work feel free to push it. Martin Gräßlin wrote: what do you want the integration test to test? I certainly can start the daemon but I'm not sure what it would give us as the only way to return from it requires a password. And that's what the test application in tests already does. Well, this patch adds a lot of new logic that can be tested, since it does not have unit test (and doing them in ksmserver migh prove difficult) we can test the code with an integraiton test. I see lots of socket logic I see logic in addAllowedWindow And also the biggest method setKsldSocket which has 2 lambdas that (afaik) can't be tested in any other way. - Àlex --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/121429/#review72103 --- On des. 15, 2014, 9:29 a.m., Martin Gräßlin wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/121429/ --- (Updated des. 15, 2014, 9:29 a.m.) Review request for Plasma, Àlex Fiestas and David Edmundson. Repository: plasma-workspace Description --- The screenlocker_greet needs to tell the parent ksld process which windows it created. Ksld sends input events to these windows. So far this was based on an X property on the window. Unfortunately ksld didn't validate whether the windows tagged with this property belong to the screenlocker_greet process it started. With this change the communication for announcing windows is moved away from the X11 protocol and instead a custom Wayland protocol is used. Ksld starts a KWaylandServer when the greet process gets started. It creates anonymous unix sockets for the connection and passes one filedescriptor to the started greeter process. The check for the X property is removed in ksld and instead only windows ids passed through the Wayland socket connection are accepted. Diffs - ksmserver/screenlocker/ksldapp.cpp 22698ce37e9d4be17126111b3ded8133f7c3baa6 ksmserver/screenlocker/lockwindow.h 9938d201269c89a24c9c0bd6275aa5f731bb5535 ksmserver/screenlocker/lockwindow.cpp 3aa963a59e21636862f5ca59e220bbea3bd41ff9 ksmserver/screenlocker/protocols/ksld.xml PRE-CREATION ksmserver/screenlocker/waylandserver.h PRE-CREATION ksmserver/screenlocker/waylandserver.cpp PRE-CREATION ksmserver/screenlocker/greeter/greeterapp.h b92b13b63365a9026dba5d71b772dcd8c9ee3d3b ksmserver/screenlocker/greeter/greeterapp.cpp 30d1821bdba38028959f3457e900a1b32e628192 ksmserver/screenlocker/greeter/main.cpp 12e570107d0cba851b8978131d730b27924529bb ksmserver/screenlocker/ksldapp.h 095424c9845c134aa156917aeb6c8ddf31e8d25a CMakeLists.txt c6d89c14b05f5639937aee5692d305fa2faed974 ksmserver/screenlocker/CMakeLists.txt 5378a10df2be70cee95b5612c23046eae639f610 ksmserver/screenlocker/greeter/CMakeLists.txt 10c473488f08354096f68784b9240392a444af5f Diff: https://git.reviewboard.kde.org/r/121429/diff/ Testing --- Running ksmserver with the patch. Lock/unlock working, my exploit is failing. Thanks, Martin Gräßlin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 121429: Use out-of-band communication between ksld and greeter
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/121429/#review72103 --- Ship it! Code looks good. Could you perhaps add an integration test for this? Since we are abstracted by the socket it should be possible. If it is too much work feel free to push it. - Àlex Fiestas On des. 15, 2014, 9:29 a.m., Martin Gräßlin wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/121429/ --- (Updated des. 15, 2014, 9:29 a.m.) Review request for Plasma, Àlex Fiestas and David Edmundson. Repository: plasma-workspace Description --- The screenlocker_greet needs to tell the parent ksld process which windows it created. Ksld sends input events to these windows. So far this was based on an X property on the window. Unfortunately ksld didn't validate whether the windows tagged with this property belong to the screenlocker_greet process it started. With this change the communication for announcing windows is moved away from the X11 protocol and instead a custom Wayland protocol is used. Ksld starts a KWaylandServer when the greet process gets started. It creates anonymous unix sockets for the connection and passes one filedescriptor to the started greeter process. The check for the X property is removed in ksld and instead only windows ids passed through the Wayland socket connection are accepted. Diffs - ksmserver/screenlocker/ksldapp.cpp 22698ce37e9d4be17126111b3ded8133f7c3baa6 ksmserver/screenlocker/lockwindow.h 9938d201269c89a24c9c0bd6275aa5f731bb5535 ksmserver/screenlocker/lockwindow.cpp 3aa963a59e21636862f5ca59e220bbea3bd41ff9 ksmserver/screenlocker/protocols/ksld.xml PRE-CREATION ksmserver/screenlocker/waylandserver.h PRE-CREATION ksmserver/screenlocker/waylandserver.cpp PRE-CREATION ksmserver/screenlocker/greeter/greeterapp.h b92b13b63365a9026dba5d71b772dcd8c9ee3d3b ksmserver/screenlocker/greeter/greeterapp.cpp 30d1821bdba38028959f3457e900a1b32e628192 ksmserver/screenlocker/greeter/main.cpp 12e570107d0cba851b8978131d730b27924529bb ksmserver/screenlocker/ksldapp.h 095424c9845c134aa156917aeb6c8ddf31e8d25a CMakeLists.txt c6d89c14b05f5639937aee5692d305fa2faed974 ksmserver/screenlocker/CMakeLists.txt 5378a10df2be70cee95b5612c23046eae639f610 ksmserver/screenlocker/greeter/CMakeLists.txt 10c473488f08354096f68784b9240392a444af5f Diff: https://git.reviewboard.kde.org/r/121429/diff/ Testing --- Running ksmserver with the patch. Lock/unlock working, my exploit is failing. Thanks, Martin Gräßlin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Starting KWin in Plasma startup process
Hi there I have been working in KSMServer, mostly doing some refactoring in order to split the X11 code (session management) into its own process. The part I am splitting out right now (startup.cpp, startup.h) has a lot of specific code for Launching the Window Management and that is the reason of this email. Right now KSMServer executes the WM before anything else, once the WM is started (process is executed), other things are done (Autostart0). My idea for KWin is for it to handle startup by itself, and idea of how to do that: -Leverage systemd when available. -startkde.sh For this to happen we need to make sure that KWin does not talk synchronously to any component that might or might not be there when KWin starts (kded, klauncher...). What do you think? 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: Auto-hiding panels
On Tuesday 14 October 2014 10:43:42 Martin Klapetek wrote: I'd like to change this for Plasma panels to not have any resistance or very minimal one, basically get it into a state that slamming the mouse against a screen edge will show the panel easily, without requiring an additional push. I think we should ask VDG about this, it is a change in behavior and look and feel after all! 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 120526: Strip PowerDevilCore, PowerDevilUI and PowerDevil's kded from kdelibs4support
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/120526/#review68180 --- Looks good, the qDebug though has to be ported to QCDebug so we can avoid spamming kded process with our logs. - Àlex Fiestas On oct. 8, 2014, 7:42 p.m., Hrvoje Senjan wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/120526/ --- (Updated oct. 8, 2014, 7:42 p.m.) Review request for Plasma, Solid, Àlex Fiestas, and Lukáš Tinkl. Repository: powerdevil Description --- there's still some usage left in the kcm subdir, i'll look into that one also soon. also, will open a review to convert to qCDebug Diffs - kcmodule/common/actioneditwidget.h e73fb44 kcmodule/common/actioneditwidget.cpp d6c5e6c kcmodule/global/CMakeLists.txt 77bbd07 kcmodule/global/GeneralPage.cpp cdad263 kcmodule/global/generalPage.ui 2b5585c kcmodule/profiles/CMakeLists.txt 1a13bb3 daemon/powerdevilcore.h 36f4004 daemon/powerdevilcore.cpp b178cdf daemon/powerdevilkeyboardbrightnesslogic.cpp 7709fda daemon/powerdevilpolicyagent.h 41e8e6b daemon/powerdevilpolicyagent.cpp d217e92 daemon/powerdevilprofilegenerator.cpp 67ef77c daemon/powerdevilscreenbrightnesslogic.cpp 8da7dff kcmodule/common/CMakeLists.txt 9319067 kcmodule/common/ErrorOverlay.h a2249c0 kcmodule/common/ErrorOverlay.cpp adad48f daemon/actions/bundled/runscriptconfig.cpp dc705af daemon/actions/bundled/suspendsession.cpp 6704134 daemon/actions/bundled/suspendsessionconfig.h cf94b87 daemon/actions/bundled/suspendsessionconfig.cpp 95df0e0 daemon/actions/dpms/CMakeLists.txt c53f0aa daemon/actions/dpms/powerdevildpmsaction.cpp be079f4 daemon/actions/dpms/powerdevildpmsactionconfig.h b6271ff daemon/actions/dpms/powerdevildpmsactionconfig.cpp 823a9bf daemon/backends/hal/powerdevilhalbackend.h b282634 daemon/backends/hal/powerdevilhalbackend.cpp 69e8ce0 daemon/backends/upower/login1suspendjob.cpp ce63c2e daemon/backends/upower/powerdevilupowerbackend.h beb12aa daemon/backends/upower/powerdevilupowerbackend.cpp f0fb73c daemon/backends/upower/upowersuspendjob.cpp 933de17 daemon/kdedpowerdevil.cpp 5d6b91c daemon/powerdevilaction.cpp f16394c daemon/powerdevilactionpool.h 93ade44 daemon/powerdevilactionpool.cpp 970aa18 daemon/powerdevilbackendinterface.h abf7618 daemon/powerdevilbackendinterface.cpp f157a73 daemon/powerdevilbackendloader.cpp 8259a13 daemon/BackendConfig.cmake 54094e0 daemon/CMakeLists.txt 544cffe daemon/actions/bundled/CMakeLists.txt 4632267 daemon/actions/bundled/brightnesscontrol.cpp 34dc578 daemon/actions/bundled/brightnesscontrolconfig.h 33120c3 daemon/actions/bundled/dimdisplay.cpp fc26585 daemon/actions/bundled/dimdisplayconfig.h 14b7879 daemon/actions/bundled/dimdisplayconfig.cpp 1b880ce daemon/actions/bundled/handlebuttonevents.cpp 6072507 daemon/actions/bundled/keyboardbrightnesscontrol.cpp 7b1dfdc daemon/actions/bundled/keyboardbrightnesscontrolconfig.h c546fd7 daemon/actions/bundled/runscriptconfig.h 7ad61cf Diff: https://git.reviewboard.kde.org/r/120526/diff/ Testing --- builds, kded is succesfully initialized, reducing/increasing brightness work Thanks, Hrvoje Senjan ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: plasmashell never emits setStage('desktop');
On Saturday 13 September 2014 10:07:09 Marco Martin wrote: Also this code could use some refactoring... It is really really really complex. Not really, at least not more than it needs to be: is pretty simple: it keeps track of the applets that had the startupcompleted constraint called on them and on itself, emits the signal when everybody is. Signaling that the qml is ready and keeping track centrally that all containments everywhere, and all their applets have indeed their qml ready as well, has to pass trough quite long hoops, not much to be done around that. Well for a newcomer it is, lots of huge methods, Containment being an Applet, Applet having special cases for Containments lots of friend classes etc. I am not saying that all the logic inside is not needed, what I am saying is that for a newcomer trying to fix a bug the code is too complex and we might want to refactor it bit a bit if possible and when desirable. Anyway, will try to hunt the bug down! 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: Notes for SLC BoF
On Thursday 11 September 2014 11:14:13 Marco Martin wrote: * Aleix proposed to work on a generic sharing framework that would be used by it, or optionally directly by applications +1, we might want to take a look at grillo https://wiki.gnome.org/action/show/Projects/Grilo?action=showredirect=Grilo 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
plasmashell never emits setStage('desktop');
Hi there
As many of you might have noticed KSplash is reaching a timeout instead of
finishing gracefully, this is because it waits (until timeout) for plasmashell
to send setStage('desktop') but it is never happening.
I have placed a breakpoint to the only place in plasmashell.cpp where we call
the dbus method and indeed that lambda is never called.
Looking further in the problem I have been able to check that one of my
containments is never ready. I tried to debug this myself but Containment
seems a really complex piece of code, after 2h I have to give up :/
Could somebody with knowledge please look why Containments are never ready?
Also this code could use some refactoring... It is really really really
complex.
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: VDG suggestions and wishes about the system tray
On Thursday 28 August 2014 12:14:28 Sebastian Kügler wrote: I agree that it could be tried, but I wouldn't be surprised if for Plasma, we come to a different conclusion. There's a certain difference in the audiences between Unity and Plasma Is there? I don't really know what is our audience, even less what is theirs. I honestly thought we were competing for more or less the same audience, at least I am. 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 119822: QScreen backend for libkscreen
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119822/#review64727 --- Besides the nitpits, here is a concern I have. KScreen is a library that should be used only by components of the shell (kwin, plasma, kscreen), the idea is to have a library that manipulates lowlevel stuff directly so we can control how we do things (events and what not). Because of this having a qscreen backend enabled by default (even if it is only in platforms where we don't have a backend) imho is a no-go. We can't relay on abstractions. That said, I do think that having a qscreen backend is an excellent fallback to test the shell in non supported platforms while we develop a proper backend, but we have to find a way of doing so qscreen backend is not used by accident. To archieve this I see 2 options: 1-Load qscreen backend only via KSCREEN_BACKEND env 2-Improve backendloader and backends to make sure we use the proper backend in every case. I think I will go for 1 at the moment, and we can figure out how to do the backend loading later on. What do you think? autotests/testqscreenbackend.cpp https://git.reviewboard.kde.org/r/119822/#comment45277 If we don't have a config even though we correctly configured the backend, should not we fail? a QSKIP might be unnoticed (specially in jenkins). autotests/testqscreenbackend.cpp https://git.reviewboard.kde.org/r/119822/#comment45278 Q_FOREACH autotests/testqscreenbackend.cpp https://git.reviewboard.kde.org/r/119822/#comment45276 Shouldn't it be qscreen? also, why the conditional at all? backends/qscreen/CMakeLists.txt https://git.reviewboard.kde.org/r/119822/#comment45279 Is X11 used in qscreenbackend? tests/testpnp.cpp https://git.reviewboard.kde.org/r/119822/#comment45280 Why is this tool needed at all? Also the copy pasted code is a no-go we should find a better solution, for example implementing streams on each object so we can simply do qDebug() config - Àlex Fiestas On ago. 18, 2014, 9:31 a.m., Sebastian Kügler wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119822/ --- (Updated ago. 18, 2014, 9:31 a.m.) Review request for Plasma and Solid. Repository: libkscreen Description --- This patch adds a QScreen backend to libkscreen. This is useful to avoid a dependency on XRandR (at build time) and a running X server at runtime. The backend itself is read-only and kept simple. It only reports the basic necessities (which is what QScreen provides). The changes are kept to the backends/qscreen directory, so no API has been touched. The changes outside of that directory are autotests, tests, and a fallback to the qscreen backend non non-X11 platforms. The latter will automatically make libkscreen work on Wayland (as far as QScreen allows us to, so r-o). This case otherwise just crashes, and the XRandR backend can't work. If the user specifies the backend using the KSCREEN_BACKEND env var, it will be respected, the automatism only triggers when no backend is explicitely specified. I've also added apidocs in some files, but again, no functional changes. The plan is to augment this also with a native Wayland backend, which will take a bit longer to complete (more complex, it's r-w, I have to learn Wayland APIs). That backend is work-in-progress in the sebas/wayland branch. The QScreen backend allows us to test and run our code under Wayland, without crashing, so we can continue the port while a native Wayland backend is conceived. You can find the code for this QScreen backend in sebas/qscreen if you'd like to give it a try. Diffs - autotests/CMakeLists.txt 18b93c0 autotests/testqscreenbackend.cpp PRE-CREATION backends/CMakeLists.txt a827ee8 backends/abstractbackend.h 7ffe627 backends/qscreen/CMakeLists.txt PRE-CREATION backends/qscreen/qscreenbackend.h PRE-CREATION backends/qscreen/qscreenbackend.cpp PRE-CREATION backends/qscreen/qscreenconfig.h PRE-CREATION backends/qscreen/qscreenconfig.cpp PRE-CREATION backends/qscreen/qscreenoutput.h PRE-CREATION backends/qscreen/qscreenoutput.cpp PRE-CREATION backends/qscreen/qscreenscreen.h PRE-CREATION backends/qscreen/qscreenscreen.cpp PRE-CREATION src/CMakeLists.txt 4606862 src/backendloader.cpp d6ccdff src/config.h 10a8f1e tests/CMakeLists.txt 86efedc tests/testplugandplay.cpp PRE-CREATION tests/testpnp.h PRE-CREATION tests/testpnp.cpp PRE-CREATION Diff: https://git.reviewboard.kde.org/r/119822/diff/ Testing --- * Ran autotest testqscreenbackend under X11 and Wayland -- all
Re: Review Request 119669: Fix broken creation of kstartupconfigfiles
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119669/#review64233 --- Ship it! Once issue is fix, good to go! startkde/kstartupconfig/kdostartupconfig.cpp https://git.reviewboard.kde.org/r/119669/#comment44890 Add const if string is not modified down the line. - Àlex Fiestas On ago. 8, 2014, 4:09 p.m., David Edmundson wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119669/ --- (Updated ago. 8, 2014, 4:09 p.m.) Review request for Plasma. Repository: plasma-workspace Description --- Fix broken creation of kstartupconfigfiles kstartupconfigfiles contains a list of files to compare mtimes on to see if we need to rebuild kstartupconfig. This wasn't being created correctly so we failed to rebuild if any configs updated. This was broken in Qt5 porting: -const QStringList dirs = KGlobal::dirs()-kfsstnd_prefixes().split( KPATH_SEPARATOR, QString::SkipEmptyParts); +const QStringList dirs = QStandardPaths::standardLocations(QStandardPaths::GenericDataLocation); Diffs - startkde/kstartupconfig/kdostartupconfig.cpp af6062c Diff: https://git.reviewboard.kde.org/r/119669/diff/ Testing --- Checked output of kstartupconfigfiles was sane. Updated ksplashrc, ran kstartupconfig5 (NOT kdostartupconfig5) checked kstartupconfig was regenerated. Thanks, David Edmundson ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Using more of our CI, Coverage and cppcheck
On Monday 28 July 2014 15:46:56 Aleix Pol wrote: From the wiki: [1] Do we need special powers to change these? Aleix [1] And add this option in the configuraiotn of your CI build: http://quickgit.kde.org/?p=websites%2Fbuild-kde-org. [DEFAULT] configureExtraArgs=-DBUILD_COVERAGE=ON Yes, you can send patch to ben. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Using more of our CI, Coverage and cppcheck
Hi there! During this weekend Ben and I have enabled the code-coverage in plasma- framework, my personal idea is to enable it in most projects. We should not go loco with code coverage, we stand where we stand and adding test non-stop will not fix anything. What we can do though is use this tool to make sure we don't make the situation worse, and to check which parts might need special love. http://build.kde.org/job/plasma-framework_master_qt5/665/Variation=All,label=LINBUILDER/cobertura/ Also, most projects have cppcheck enabled, this thing is usually right so we want to to make it happy: http://build.kde.org/job/plasma-framework_master_qt5/665/Variation=All,label=LINBUILDER/cppcheckResult/ If you want to enable it in more projects, look at: https://techbase.kde.org/Development/Tutorials/Unittests#Coverage_tools_and_CI Cheers! ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 118804: Register ksmserver as logind session leader
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/118804/#review60716 --- According to Lennart we should not call TakeControl, so I guess that while we wait for kdbus we should discard this review? - Àlex Fiestas On June 19, 2014, 7:03 p.m., Elias Probst wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/118804/ --- (Updated June 19, 2014, 7:03 p.m.) Review request for Plasma. Bugs: 335390 https://bugs.kde.org/show_bug.cgi?id=335390 Repository: plasma-workspace Description --- This is an initial (not yet working) attempt to fix bug#335390. After some discussion in #systemd, it seems there's some more work needed outside of ksmserver. Will have to figure out the next actions to be taken to continue on this. See also my mail on systemd-devel: http://lists.freedesktop.org/archives/systemd-devel/2014-June/020238.html Diffs - ksmserver/screenlocker/logind.cpp dcfc7f321b3cf29ef68aac8006aa37f5e4e00956 Diff: https://git.reviewboard.kde.org/r/118804/diff/ Testing --- - Copy /usr/lib/systemd/system/systemd-logind.service to /etc/systemd/system/systemd-logind.service - Set Environment=SYSTEMD_LOG_LEVEL=debug in the [Service] section of /etc/systemd/system/systemd-logind.service - Run systemctl daemon-reload - Reboot (also possible without a reboot, but far more complicated and requires to terminate the X session anyways, so a reboot is the most straightforward solution) To test - apply patch + rebuild plasma-workspace - kill ksmserver - Run journalctl -n 20 -f -u systemd-logind to monitor logind - Run tail -f ~/.xsession-errors or journalctl --user -n 20 -f --user-unit ksmserver (for systemd user-session users) to monitor ksmserver's output - restart ksmserver Thanks, Elias Probst ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 118792: PowerDevil: Show the brightness OSD on pressing the brightness key
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/118792/#review60243 --- Ship it! Good to go, please be extra careful making sure the OSD is not always shown when the brightness changes - Àlex Fiestas On June 17, 2014, 11:20 a.m., Vishesh Handa wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/118792/ --- (Updated June 17, 2014, 11:20 a.m.) Review request for Plasma, Solid and Àlex Fiestas. Repository: powerdevil Description --- See title Diffs - daemon/actions/bundled/brightnesscontrol.cpp 59bbbcc Diff: https://git.reviewboard.kde.org/r/118792/diff/ Testing --- Thanks, Vishesh Handa ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 117839: [kglobalaccel] Update X11 appTime from key press events
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117839/#review57299 --- Ship it! Code looks good. - Àlex Fiestas On April 28, 2014, 1:47 p.m., Martin Gräßlin wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117839/ --- (Updated April 28, 2014, 1:47 p.m.) Review request for Plasma. Repository: plasma-workspace Description --- [kglobalaccel] Update X11 appTime from key press events KGlobalAccelD sends the current appTime through DBus to the application and KF5::GlobalAccel updates the appTime from the timestamp. This is needed for following actions to succeed. E.g. KWin needs the updated appTime for grabbing the keyboard following the kill window shortcut. To get the current timestamp we just use the timestamp of the key press event delivered to kglobalacceld. Diffs - kglobalaccel/kglobalaccel_x11.cpp 454c62e17ac0fb188bbbf2bcefcf42241d7f4ec1 Diff: https://git.reviewboard.kde.org/r/117839/diff/ Testing --- Tested with ctrl+alt+esc Thanks, Martin Gräßlin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: plasma-framework in kdereview
On Friday 25 April 2014 12:34:32 Marco Martin wrote: Hi all, since it was done earlier this week, better announce it formally, so everybody can actually do the -review part ;) the plasma-framework repository has been moved in kdereview, headed hopefully in frameworks. what it contains: * libplasma: it's the old plasma library that used to be in kdelibs * QML plugins that depend from libplasma, they are old too, and come from kde- runtime * libplasmaquick: a library that depends from libplasma and QtQuick: it's completely for internal use right now (just like the majority of the qtquick library) eventually it may become public in the future, so it doesn't install any header, not part of the public api. * at least one plasma theme: the shipped QML components don't really work without it, so one is core * there was the plasma shell: has been removed and moved to plasma-workspace, decreasing dependencies Moving plasma-framework to frameworks means that we will loose flexibility since we won't be able to break api/abi. So, do we really have to move it there? Imho would be prudent to keep it somewhere else where api/abi stability is not mandatory. Also, right now there is only one user of this framework (plasma-desktop), I would wait until at least we have 2 more shells based on it to commit to any stability. 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: 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: 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 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: Review Request 117464: [kglobalaccel] Remove notification support
On April 10, 2014, 9:47 a.m., Martin Klapetek wrote: This means the notification right now has nothing more than debug purpose. Wasn't there some accessibility reason for that notification? Because you can also have audio notification and others (custom plugins to KNotifications), not just popups. Martin Gräßlin wrote: I tried to figure out the reason on why there should be the notification. But neither the commits nor the mailing list thread shed light on it. But also for accessibility I don't really see a reason to have a notification when the global shortcut got triggered. Something should happen when you click it, e.g. Present Windows starts. Why would one want an additional feedback on yo, you just activated Present Windows? It is for accessibility reasons so we could use knotifyd as a sort of text-to-speech. This is now not needed at all and imho it should be removed. We need somebody to take charge of accessibility in Qt5 world (kde-wise). - Àlex --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117464/#review55338 --- On April 10, 2014, 6:20 a.m., Martin Gräßlin wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117464/ --- (Updated April 10, 2014, 6:20 a.m.) Review request for Plasma, Aleix Pol Gonzalez and Aurélien Gâteau. Repository: plasma-workspace Description --- [kglobalaccel] Remove notification support KGlobalAccel emitted notifications when: * a shortcut is pressed * a new shortcut is registered Both are configured with no action at all. Thus the notification is not of much use. Why it shouldn't show a popup had been discussed on kcd [1]. This means the notification right now has nothing more than debug purpose. While this might be a valid usecase it doesn't make much sense to do this with KNotification - for this see Aaron's mail [2]. Also e.g. KWin dropped all notifications for debug purposes for the same reason. If there is a need for a kind of notification on global shortcut triggered or a new registered global shortcut this could also be easily emulated by adding an explicit signal to the DBus interface. This removes the KNotificiation dependency. [1] http://lists.kde.org/?t=12646324942r=1w=2n=16 [2] http://lists.kde.org/?l=kde-core-develm=126463340225306w=2 Diffs - kglobalaccel/CMakeLists.txt b77f85edab091fd260fb9bddb1ddb43df445c5fe kglobalaccel/globalshortcutsregistry.cpp 41a351b47a66c24f2e25d0d0d1df9c8a9b6616ef kglobalaccel/kglobalaccel.notifyrc aec41137180c18a89e21a537b9e73da715b5f55d kglobalaccel/kglobalacceld.h cb058acd0e1d50c47f3cab0cd9e0a061fd0d7a67 kglobalaccel/kglobalacceld.cpp 86d54695a4b75dc20b46ba4c9ada398d96093a53 Diff: https://git.reviewboard.kde.org/r/117464/diff/ Testing --- Thanks, Martin Gräßlin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 117359: move phonon kcm and platform plugin to plasma-workspace
On April 3, 2014, 4:19 p.m., Aleix Pol Gonzalez wrote: Can you create the patch with --find-copies-harder? It will be much easier to review. Harald Sitter wrote: I am not sure how that would help as this is a cross-repo move from kde-runtime (: The kcm should go to plasma-desktop (since it is desktop only atm), the plugin should go to -workspace since it affects all form factors. - Àlex --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117359/#review54948 --- On April 3, 2014, 3:31 p.m., Harald Sitter wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117359/ --- (Updated April 3, 2014, 3:31 p.m.) Review request for Plasma and Àlex Fiestas. Repository: plasma-workspace Description --- import phonon KCM and phonon platform plugin - both ported away from deprecated classes - the kcm additionally had a cleanup of phonon private header copies - backendselection in the KCM was ported to a native Qt solution for phonon4qt5 - the platform plugin has just about all pointless features removed leading up to what may (or may not) be a platform plugin in a future phonon5 API - all direct ALSA handling was removed (e.g. the kded phononserver), we prefer PulseAudio device control over anything else, and short of that we'll expect the actual backend to provide a list of possible outputs Diffs - phonon/kcm/Messages.sh PRE-CREATION phonon/kcm/CMakeLists.txt PRE-CREATION CMakeLists.txt 28ad201 phonon/CMakeLists.txt PRE-CREATION phonon/platform_kde/phononbackend.desktop PRE-CREATION phonon/platform_kde/phonon.notifyrc PRE-CREATION phonon/platform_kde/kiomediastream_p.h PRE-CREATION phonon/platform_kde/kiomediastream.cpp PRE-CREATION phonon/platform_kde/kiomediastream.h PRE-CREATION phonon/platform_kde/kdeplatformplugin.cpp PRE-CREATION phonon/platform_kde/kdeplatformplugin.h PRE-CREATION phonon/platform_kde/debug.cpp PRE-CREATION phonon/platform_kde/debug.h PRE-CREATION phonon/platform_kde/Messages.sh PRE-CREATION phonon/platform_kde/CMakeLists.txt PRE-CREATION phonon/kcm/testspeakerwidget.cpp PRE-CREATION phonon/kcm/main.cpp PRE-CREATION phonon/kcm/testspeakerwidget.h PRE-CREATION phonon/kcm/main.h PRE-CREATION phonon/kcm/listview-background.png PRE-CREATION phonon/kcm/kcm_phonon.desktop PRE-CREATION phonon/kcm/devicepreference.ui PRE-CREATION phonon/kcm/devicepreference.cpp PRE-CREATION phonon/kcm/devicepreference.h PRE-CREATION phonon/kcm/backendselection.ui PRE-CREATION phonon/kcm/backendselection.cpp PRE-CREATION phonon/kcm/backendselection.h PRE-CREATION phonon/kcm/audiosetup.ui PRE-CREATION phonon/kcm/audiosetup.h PRE-CREATION phonon/kcm/audiosetup.cpp PRE-CREATION Diff: https://git.reviewboard.kde.org/r/117359/diff/ Testing --- - build install - kcm change device order change backend order Thanks, Harald Sitter ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
kde-workspace has been split (for frameworks)
Hi there. kde-workspace has been successfully split into the following repositories: powerdevil khotkeys kinfocenter kmenuedit ksysguard kwin kwrited libksysguard oxygen plasma-desktop plasma-workspace systemsettings All repositories but powerdevil are under kde/workspace, powerdevil is in extragear. kde-build-structure has been updated so all tools should work as usual. To get kdesrc-build working make sure you use at least 4c435231cb490 Finally, the CI is still not setup it will be done as soon as possible. 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
kde-workspace split incoming!
Hi everybody! We are done doing CMake on kde-workspace so we have asked sysadmin team to create the new repositories. Once that's done we will freeze kde- workspace/master and proceed to split and setup everything (kdesrc-build, build.kde.org etc). We will try to send a last reminder of the freeze just before it happens (I guess sysadmins will do so anyway) so you can be prepared for it. 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: Review Request 116931: Make sure kdeinit starts kded
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116931/#review53532 --- kdeinit should be launching kded, if not what has changed? - Àlex Fiestas On March 20, 2014, 4:04 p.m., Alex Merry wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116931/ --- (Updated March 20, 2014, 4:04 p.m.) Review request for Plasma and Sebastian Kügler. Repository: kde-workspace Description --- Make sure kdeinit starts kded We now have to explicitly tell kdeinit to start kded using the --kded option (as of https://git.reviewboard.kde.org/r/116928/). Diffs - plasma-workspace/startkde/startkde.cmake 86abf5b68dc5717d9fc257e0d442242fc18d3058 Diff: https://git.reviewboard.kde.org/r/116931/diff/ Testing --- Thanks, Alex Merry ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 116931: Make sure kdeinit starts kded
On March 20, 2014, 4:29 p.m., Àlex Fiestas wrote: kdeinit should be launching kded, if not what has changed? Alex Merry wrote: https://git.reviewboard.kde.org/r/116928/ changes it to not load it by default, so that applications running outside of Plasma don't run it just because they wanted a kioslave. It should still be auto-started if anything tries to use one of its D-Bus interfaces, though. good stuff! - Àlex --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116931/#review53532 --- On March 20, 2014, 7:31 p.m., Alex Merry wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116931/ --- (Updated March 20, 2014, 7:31 p.m.) Review request for Plasma and Sebastian Kügler. Repository: kde-workspace Description --- Make sure kdeinit starts kded We now have to explicitly tell kdeinit to start kded using the --kded option (as of https://git.reviewboard.kde.org/r/116928/). Diffs - plasma-workspace/startkde/startkde.cmake 86abf5b68dc5717d9fc257e0d442242fc18d3058 Diff: https://git.reviewboard.kde.org/r/116931/diff/ Testing --- Thanks, Alex Merry ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 116869: Completely remove the legacy ksmserver shutdown effect
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116869/#review53325 --- Ship it! Looks good. - Àlex Fiestas On March 18, 2014, 7:46 a.m., Martin Gräßlin wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116869/ --- (Updated March 18, 2014, 7:46 a.m.) Review request for kwin, Plasma, Àlex Fiestas, and Teo Mrnjavac. Repository: kde-workspace Description --- Completely remove the legacy ksmserver shutdown effect Painting was already disabled in the effect inside ksmserver, thus it was more or less dead code. Let's remove it completely. This also allows to remove the temporary hack inside KWin's logout effect. Diffs - kwin/effects/logout/logout.cpp 599efcd2156800ec1d8bfa8fb99bb7b074628fdb ksmserver/tests/test.cpp b69bc6ee065bcafc671b7fd44a98f7e832d8b1bd ksmserver/shutdowndlg.h 9a33a046d1a634bedf3a7367ee16b60836771d9d ksmserver/shutdowndlg.cpp feeedbeb5ea4b80c79ed4105fed4784bc70c ksmserver/shutdown.cpp e193ef73b6e540db72b3133e148d4c248929362a Diff: https://git.reviewboard.kde.org/r/116869/diff/ Testing --- Thanks, Martin Gräßlin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 116872: [kwin] Adjust CMakeLists.txt to allow standalone built of KWin
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116872/#review53341 --- Ship it! Some more extra cmake-fu is needed to make it work perfect, but it is a good start. - Àlex Fiestas On March 18, 2014, 1:45 p.m., Martin Gräßlin wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116872/ --- (Updated March 18, 2014, 1:45 p.m.) Review request for kwin, Plasma, Àlex Fiestas, and Aleix Pol Gonzalez. Repository: kde-workspace Description --- [kwin] Adjust CMakeLists.txt to allow standalone built of KWin Preparation step before splitting: * adds project(KWIN) * lists all KWin dependencies KWin can be built standalone if cmake is run with: -DKWIN_BUILD_OXYGEN=OFF -DKWIN_BUILD_KAPPMENU=OFF Oxygen because it needs liboxygen - for standalone clients/oxygen needs to be moved out of KWin. KAppmenu because it includes the DBus xml file. Diffs - kwin/CMakeLists.txt d3dcead729f924ae4ebce733e000d24c71bc19bd Diff: https://git.reviewboard.kde.org/r/116872/diff/ Testing --- Thanks, Martin Gräßlin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 116796: Show brightness OSD only on user input
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116796/#review53272 --- Ship it! Ship It! - Àlex Fiestas On March 16, 2014, 9:20 p.m., Martin Klapetek wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116796/ --- (Updated March 16, 2014, 9:20 p.m.) Review request for Plasma and Àlex Fiestas. Repository: kde-workspace Description --- As discussed at the Plasma sprint, we want to show the OSD only on user input as a way of feedback to the action the user just did. Diffs - powerdevil/daemon/actions/bundled/brightnesscontrol.cpp 228645b Diff: https://git.reviewboard.kde.org/r/116796/diff/ Testing --- Thanks, Martin Klapetek ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 116796: Show brightness OSD only on user input
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116796/#review53271 --- I can't test it but it looks good. I wonder, can this be put in powerdevil from 4.13? - Àlex Fiestas On March 16, 2014, 9:20 p.m., Martin Klapetek wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116796/ --- (Updated March 16, 2014, 9:20 p.m.) Review request for Plasma and Àlex Fiestas. Repository: kde-workspace Description --- As discussed at the Plasma sprint, we want to show the OSD only on user input as a way of feedback to the action the user just did. Diffs - powerdevil/daemon/actions/bundled/brightnesscontrol.cpp 228645b Diff: https://git.reviewboard.kde.org/r/116796/diff/ Testing --- Thanks, Martin Klapetek ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 116625: Oxygen as default font
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116625/#review52895 --- Ship it! Sorry for the delay, good to go. - Àlex Fiestas On March 6, 2014, 10:29 a.m., Sebastian Kügler wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116625/ --- (Updated March 6, 2014, 10:29 a.m.) Review request for Plasma and Àlex Fiestas. Repository: kde-workspace Description --- Make Oxygen the default font This has three portions: the fonts itself, installation of them including fontconfig bits, and setting font defaults in kdeglobals. Oxygen Font 0.4 Imported from oxygen-font repository. The startkde portion contains the bits to write out a kdeglobals default file if it doesn't exist with font settings applied. Usually, with install prefix set to /usr, the installed oxygen font is found automatically by fontconfig. If we're installed to a different prefix, we need to point fontconfig at the font. We do that by linking it from either XDG_DATA_HOME or ~/.fonts/ and updating fontconfig with it. The latter is irrelevant for systems that install into /usr. Diffs - CMakeLists.txt 0135bb1f7475862451775928adf5dc20167424e0 fonts/CMakeLists.txt PRE-CREATION fonts/oxygen/COPYING-GPL+FE.txt PRE-CREATION fonts/oxygen/GPL.txt PRE-CREATION fonts/oxygen/Oxygen-Sans-Bold.ttf PRE-CREATION fonts/oxygen/Oxygen-Sans.ttf PRE-CREATION fonts/oxygen/OxygenMono-Regular.ttf PRE-CREATION fonts/oxygen/README PRE-CREATION startkde.cmake 53d1bc6a2098f634c5f386f95e1a1c504b554303 Diff: https://git.reviewboard.kde.org/r/116625/diff/ Testing --- Logged into session with clean config. Font settings are applied correctly throughout. Thanks, Sebastian Kügler ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 116633: Change default font settings to Oxygen font
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116633/#review52579 --- Ship it! Before pushing it, contact with the sysadmins to make sure they have Oxygen 0.4 in the CI system. otherwise it looks ok. - Àlex Fiestas On March 6, 2014, 4:36 p.m., Sebastian Kügler wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116633/ --- (Updated March 6, 2014, 4:36 p.m.) Review request for Plasma and Àlex Fiestas. Repository: frameworkintegration Description --- Change default font settings to Oxygen font Depend on kde:oxygen-fonts being installed. oxygen-fonts installs a file called OxygenFontConfig.cmake, which is used for checking the dependency is available. Diffs - CMakeLists.txt e249554 src/platformtheme/kfontsettingsdata.cpp 62990ce Diff: https://git.reviewboard.kde.org/r/116633/diff/ Testing --- Started kate without a kdeglobals file being present, fonts are picked up correctly. Thanks, Sebastian Kügler ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
[kde-runtime/frameworks] kglobalaccel: Workaround for a bug that prevents | to be written
Git commit 7352de1b593ab933adb6dbee7ccc349cbe0e89b6 by Àlex Fiestas.
Committed on 07/03/2014 at 15:12.
Pushed by afiestas into branch 'frameworks'.
Workaround for a bug that prevents | to be written
Do not get alarm, I'm trying to hunt this bug down,
but working without | is driving me crazy, and after
all we need to be able to dogfood plasma next.
CCMAIL: plasma-devel@kde.org
M +5-0kglobalaccel/globalshortcutsregistry.cpp
http://commits.kde.org/kde-runtime/7352de1b593ab933adb6dbee7ccc349cbe0e89b6
diff --git a/kglobalaccel/globalshortcutsregistry.cpp
b/kglobalaccel/globalshortcutsregistry.cpp
index 2c87147..db03ba7 100644
--- a/kglobalaccel/globalshortcutsregistry.cpp
+++ b/kglobalaccel/globalshortcutsregistry.cpp
@@ -314,6 +314,11 @@ bool GlobalShortcutsRegistry::registerKey(int key,
GlobalShortcut *shortcut)
return false;
}
+if (QKeySequence(key).toString() == Shift+\\) {
+kDebug() Not registering QKeySequence(key).toString()
Because breaks |;
+return false;
+}
+
kDebug() Registering key QKeySequence(key).toString() for
shortcut-context()-component()-uniqueName() :
shortcut-uniqueName();
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 116633: Change default font settings to Oxygen font
On March 6, 2014, 1:55 p.m., Mark Gaiser wrote: How will this work with other non KDE apps (like Chrome), will they simply pickup the Oxygen font? I'm asking because fonts are working just fine now. If i open a GTK app in KDE it shows the fonts in the same manner as a KDE app would show them. That is consistent and quite likable :) Sebastian Kügler wrote: They won't pick up the font. Nothing we can do about that in Plasma. Needs the distro or the Chrome developers to do it. The Oxygen Widget style for GTK could probably pick it up, though. This is unrelated to this patch, however. Mark Gaiser wrote: Well, if this patch gives the user a broken consistency (Chrome is being used by lots of people, including KDE folks) then i think it might be best to keep the defaults consistent and keep it at sans-serif. That would at least keep the default consistent. Another approach might be (don't know if that's done already) to generate a local user font.conf which changes the default sans-serif font to whatever font is set in KDE's font settings. Note: Chrome is just a sane example here. Others would be gparted, firefox, fill in any gtk app Martin Gräßlin wrote: @Mark: well it's orthogonal to this change. We need to start somewhere the transition. If we block the first patch because it introduces inconsistancies, we will never be able to adress it. Thus I think it's the right approach to start with the what we have control over. Aleix Pol Gonzalez wrote: @Mark: Nobody assures Chrome will be using Sans Serif either, this patch doesn't make a difference in this regard... Mark Gaiser wrote: @Martin, @Aleix; To be clear, I'm not against this change at all. I'm only against the result it will have. Sure, you need to start somewhere. In this case that would be assuring that all applications follow the font settings that are in kde's font settings. How one should tackle that, i don't know. I guess it's possible with a local fonts.conf file. @Aleix not a strong argument. GUI interfaces almost always use the default font settings. My exact point is that those defaults _won't_ change for GTK apps with this patch. Well supporting gtk app's is as simple as writing the configuration file like or kcm-gtk-style does. If chromium is not reading that and rather using their own config file (which I doubt) then it would be their bug, not ours. Also, imho we should ask KDE/PLasma distributions to set this settings by default distro-wise. - Àlex --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116633/#review52255 --- On March 6, 2014, 4:36 p.m., Sebastian Kügler wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116633/ --- (Updated March 6, 2014, 4:36 p.m.) Review request for Plasma and Àlex Fiestas. Repository: frameworkintegration Description --- Change default font settings to Oxygen font Depend on kde:oxygen-fonts being installed. oxygen-fonts installs a file called OxygenFontConfig.cmake, which is used for checking the dependency is available. Diffs - CMakeLists.txt e249554 src/platformtheme/kfontsettingsdata.cpp 62990ce Diff: https://git.reviewboard.kde.org/r/116633/diff/ Testing --- Started kate without a kdeglobals file being present, fonts are picked up correctly. Thanks, Sebastian Kügler ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 116633: Change default font settings to Oxygen font
On March 6, 2014, 1:55 p.m., Mark Gaiser wrote: How will this work with other non KDE apps (like Chrome), will they simply pickup the Oxygen font? I'm asking because fonts are working just fine now. If i open a GTK app in KDE it shows the fonts in the same manner as a KDE app would show them. That is consistent and quite likable :) Sebastian Kügler wrote: They won't pick up the font. Nothing we can do about that in Plasma. Needs the distro or the Chrome developers to do it. The Oxygen Widget style for GTK could probably pick it up, though. This is unrelated to this patch, however. Mark Gaiser wrote: Well, if this patch gives the user a broken consistency (Chrome is being used by lots of people, including KDE folks) then i think it might be best to keep the defaults consistent and keep it at sans-serif. That would at least keep the default consistent. Another approach might be (don't know if that's done already) to generate a local user font.conf which changes the default sans-serif font to whatever font is set in KDE's font settings. Note: Chrome is just a sane example here. Others would be gparted, firefox, fill in any gtk app Martin Gräßlin wrote: @Mark: well it's orthogonal to this change. We need to start somewhere the transition. If we block the first patch because it introduces inconsistancies, we will never be able to adress it. Thus I think it's the right approach to start with the what we have control over. Aleix Pol Gonzalez wrote: @Mark: Nobody assures Chrome will be using Sans Serif either, this patch doesn't make a difference in this regard... Mark Gaiser wrote: @Martin, @Aleix; To be clear, I'm not against this change at all. I'm only against the result it will have. Sure, you need to start somewhere. In this case that would be assuring that all applications follow the font settings that are in kde's font settings. How one should tackle that, i don't know. I guess it's possible with a local fonts.conf file. @Aleix not a strong argument. GUI interfaces almost always use the default font settings. My exact point is that those defaults _won't_ change for GTK apps with this patch. Àlex Fiestas wrote: Well supporting gtk app's is as simple as writing the configuration file like or kcm-gtk-style does. If chromium is not reading that and rather using their own config file (which I doubt) then it would be their bug, not ours. Also, imho we should ask KDE/PLasma distributions to set this settings by default distro-wise. Just to make my point clear, I'm not against this review but I think it should be followed by another one configuring other toolkits fonts :) - Àlex --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116633/#review52255 --- On March 6, 2014, 4:36 p.m., Sebastian Kügler wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116633/ --- (Updated March 6, 2014, 4:36 p.m.) Review request for Plasma and Àlex Fiestas. Repository: frameworkintegration Description --- Change default font settings to Oxygen font Depend on kde:oxygen-fonts being installed. oxygen-fonts installs a file called OxygenFontConfig.cmake, which is used for checking the dependency is available. Diffs - CMakeLists.txt e249554 src/platformtheme/kfontsettingsdata.cpp 62990ce Diff: https://git.reviewboard.kde.org/r/116633/diff/ Testing --- Started kate without a kdeglobals file being present, fonts are picked up correctly. Thanks, Sebastian Kügler ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
[kde-runtime/frameworks] kioexec: This basically makes kioexec work, by finishing the port
Git commit 84317812ee91ff504644aa999d2e681266b412a1 by Àlex Fiestas.
Committed on 05/03/2014 at 18:54.
Pushed by afiestas into branch 'frameworks'.
This basically makes kioexec work, by finishing the port
It is quite embarassing from our part (if you ask me) that we had this
in this state. It clearly shows that nobody has been running
kde-runtime from frameworks.
Please, start using the proper kde-runtime (until today kdesrc-build
pointed to kde-runtime/master).
CCMAIL: plasma-devel@kde.org
M +36 -33 kioexec/main.cpp
M +4-3kioexec/main.h
http://commits.kde.org/kde-runtime/84317812ee91ff504644aa999d2e681266b412a1
diff --git a/kioexec/main.cpp b/kioexec/main.cpp
index 7f4d1e7..6aeb5f7 100644
--- a/kioexec/main.cpp
+++ b/kioexec/main.cpp
@@ -38,7 +38,6 @@
#include klocale.h
#include KLocalizedString
#include KStandardDirs
-#include kcmdlineargs.h//remove it
#include kdeversion.h
#include kaboutdata.h
#include kstartupinfo.h
@@ -52,24 +51,19 @@ static const char description[] =
I18N_NOOP(KIO Exec - Opens remote files, watches modifications, asks
for upload);
-KIOExec::KIOExec()
+KIOExec::KIOExec(const QStringList args, bool tempFiles, const QString
suggestedFileName)
: mExited(false)
{
-KCmdLineArgs *args = KCmdLineArgs::parsedArgs();
-if (args-count() 1)
-KCmdLineArgs::usageError(i18n('command' expected.\n));
-
-tempfiles = args-isSet(tempfiles);
-if ( args-isSet( suggestedfilename ) )
-suggestedFileName = args-getOption( suggestedfilename );
+mTempFiles = tempFiles;
+mSuggestedFileName = suggestedFileName;
expectedCounter = 0;
jobCounter = 0;
-command = args-arg(0);
+command = args.first();
qDebug() command= command;
-for ( int i = 1; i args-count(); i++ )
+for ( int i = 1; i args.count(); i++ )
{
-QUrl url = args-url(i);
+QUrl url(args.value(i));
url = KIO::NetAccess::mostLocalUrl( url, 0 );
//kDebug() url= url.url() filename= url.fileName();
@@ -87,7 +81,7 @@ KIOExec::KIOExec()
{
if ( !url.isValid() )
KMessageBox::error( 0L, i18n( The URL %1\nis malformed ,
url.url() ) );
-else if ( tempfiles )
+else if ( mTempFiles )
KMessageBox::error( 0L, i18n( Remote URL %1\nnot allowed with
--tempfiles switch , url.url() ) );
else
// We must fetch the file
@@ -116,9 +110,8 @@ KIOExec::KIOExec()
}
}
}
-args-clear();
-if ( tempfiles )
+if ( mTempFiles )
{
slotRunApp();
return;
@@ -218,7 +211,7 @@ void KIOExec::slotRunApp()
if ( (KDE::stat( src, buff ) == 0)
((*it).time != buff.st_mtime) )
{
-if ( tempfiles )
+if ( mTempFiles )
{
if ( KMessageBox::questionYesNo( 0L,
i18n( The supposedly
temporary file\n%1\nhas been modified.\nDo you still want to delete it?,
dest.toDisplayString(QUrl::PreferLocalFile)),
@@ -242,7 +235,7 @@ void KIOExec::slotRunApp()
}
}
-if ((!dest.isLocalFile() || tempfiles) exit_code == 0) {
+if ((!dest.isLocalFile() || mTempFiles) exit_code == 0) {
// Wait for a reasonable time so that even if the application
forks on startup (like OOo or amarok)
// it will have time to start up and read the file before it gets
deleted. #130709.
qDebug() sleeping...;
@@ -258,26 +251,36 @@ void KIOExec::slotRunApp()
int main( int argc, char **argv )
{
-/* K4AboutData aboutData( kioexec, kioexec, ki18n(KIOExec),
- *KDE_VERSION_STRING, ki18n(description), KAboutData::License_GPL,
- *ki18n((c) 1998-2000,2003 The KFM/Konqueror Developers));
- *aboutData.addAuthor(ki18n(David Faure),KLocalizedString(),
fa...@kde.org);
- *aboutData.addAuthor(ki18n(Stephan Kulow),KLocalizedString(),
co...@kde.org);
- *aboutData.addAuthor(ki18n(Bernhard
Rosenkraenzer),KLocalizedString(), b...@arklinux.org);
- *aboutData.addAuthor(ki18n(Waldo Bastian),KLocalizedString(),
bast...@kde.org);
- *aboutData.addAuthor(ki18n(Oswald Buddenhagen),KLocalizedString(),
o...@kde.org);
- *aboutData.setProgramIconName(kde);
- */
-QCommandLineParser parser;
-/*parser.addOption(QCommandLineOption(QStringList() tempfiles ,
i18n(Treat URLs as local files and delete them afterwards)));
-parser.addOption(QCommandLineOption(QStringList() suggestedfilename
file name , ki18n(Suggested file name for the downloaded file)));
-parser.addOption(QCommandLineOption(QStringList() +command,
i18n(Command to execute)));
-parser.addOption(QCommandLineOption(QStringList() +[URLs],
i18n(URL(s) or local file(s) used for 'command'))); */
QApplication app( argc, argv);
+KAboutData aboutData( kioexec
Re: Minutes Monday Plasma hangout
On Monday 17 February 2014 13:26:11 Sebastian Kügler wrote: Plasma Meeting February, 17th, 2014 Present: Alex Fiestas, David Edmundson, Giorgos Tsiapaliokas, Marco Martin, Martin Grässlin, Martin Klapetek, Jens Reuterberg, Antonis Tsiapaliokas, Sebastian Kügler, Vishesh Handa, Alex: - finished wallet work (it's secure now!) - works on kdeinit now (benchmarking and profiling to make it lighter) I want to benchmark it to decide if it is still worth it or not, not to *make it lighter*. If it turns out that it is not needed anymore then I want make it small so only kio uses it, and probably move it to kio. 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 115726: Deafult for not executing kwalletmanager once a wallet is open
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115726/ --- (Updated Feb. 17, 2014, 4:12 p.m.) Status -- This change has been marked as submitted. Review request for KDE Runtime, kde-workspace and Plasma. Repository: kde-runtime Description --- Given that in 4.13 we want people to use pam to open the wallet it makes little sense to execute the wallet automatically. Other commits changing the default have been pushed to kwallet and kwalletmanager This review goes together with: https://git.reviewboard.kde.org/r/115727/ https://git.reviewboard.kde.org/r/115728/ Diffs - kwalletd/CMakeLists.txt 9c5ca92 kwalletd/kwallet-4.13.upd PRE-CREATION Diff: https://git.reviewboard.kde.org/r/115726/diff/ Testing --- Thanks, Àlex Fiestas ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 115728: Deafult for not executing kwalletmanager once a wallet is open
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115728/ --- (Updated Feb. 17, 2014, 4:24 p.m.) Status -- This change has been marked as submitted. Review request for KDE Runtime, kde-workspace and Plasma. Repository: kwalletmanager Description --- Given that in 4.13 we want people to use pam to open the wallet it makes little sense to execute the wallet automatically. Other commits changing the default have been pushed to runtime and kwallet Diffs - src/konfigurator/konfigurator.cpp b9f6edb src/manager/kwalletmanager.cpp 355fda7 Diff: https://git.reviewboard.kde.org/r/115728/diff/ Testing --- Thanks, Àlex Fiestas ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Review Request 115726: Deafult for not executing kwalletmanager once a wallet is open
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115726/ --- Review request for KDE Runtime, kde-workspace and Plasma. Repository: kde-runtime Description --- Given that in 4.13 we want people to use pam to open the wallet it makes little sense to execute the wallet automatically. Other commits changing the default have been pushed to kwallet and kwalletmanager Diffs - kwalletd/CMakeLists.txt 9c5ca92 kwalletd/kwallet-4.13.upd PRE-CREATION Diff: https://git.reviewboard.kde.org/r/115726/diff/ Testing --- Thanks, Àlex Fiestas ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Review Request 115728: Deafult for not executing kwalletmanager once a wallet is open
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115728/ --- Review request for KDE Runtime, kde-workspace and Plasma. Repository: kwalletmanager Description --- Given that in 4.13 we want people to use pam to open the wallet it makes little sense to execute the wallet automatically. Other commits changing the default have been pushed to runtime and kwallet Diffs - src/konfigurator/konfigurator.cpp b9f6edb src/manager/kwalletmanager.cpp 355fda7 Diff: https://git.reviewboard.kde.org/r/115728/diff/ Testing --- Thanks, Àlex Fiestas ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 115726: Deafult for not executing kwalletmanager once a wallet is open
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115726/ --- (Updated Feb. 13, 2014, 5:13 p.m.) Review request for KDE Runtime, kde-workspace and Plasma. Repository: kde-runtime Description (updated) --- Given that in 4.13 we want people to use pam to open the wallet it makes little sense to execute the wallet automatically. Other commits changing the default have been pushed to kwallet and kwalletmanager This review goes together with: https://git.reviewboard.kde.org/r/115727/ https://git.reviewboard.kde.org/r/115728/ Diffs - kwalletd/CMakeLists.txt 9c5ca92 kwalletd/kwallet-4.13.upd PRE-CREATION Diff: https://git.reviewboard.kde.org/r/115726/diff/ Testing --- Thanks, Àlex Fiestas ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 115448: Fix multiscreen popup positioning
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115448/#review48832 --- Ship it! Code looks good. src/declarativeimports/core/dialog.cpp https://git.reviewboard.kde.org/r/115448/#comment34471 What does it represent then? - Àlex Fiestas On Feb. 3, 2014, 3:47 p.m., David Edmundson wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115448/ --- (Updated Feb. 3, 2014, 3:47 p.m.) Review request for Plasma. Repository: plasma-framework Description --- Fix multiscreen popup positioning Diffs - src/declarativeimports/core/dialog.h fd6b0d0 src/declarativeimports/core/dialog.cpp 8ce848f Diff: https://git.reviewboard.kde.org/r/115448/diff/ Testing --- Thanks, David Edmundson ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Release schedule for Plasma Next
On Wednesday 29 January 2014 16:52:51 Martin Graesslin wrote: I suggest to significantly increase the number of intermediate releases. One month between RC and final is too long. +1 I would prefer to have a series of release candidates and a release candidate should be exactly that: a candidate which could be the release. Given the schedule I don't think that the Release Candidate would count as that, but rather as another beta without any RCs. In the time of the release candidates I would like to see us focusing on quality by only addressing issues which are release-critical. Large work to fix a bug which could end up in yet another layer of regressions should not be done. Given that I would suggest to not put a final release date into it. It should be the first release candidate which has no release-critical bug fixes [1] (idea stolen from Debian). Or in short: it's done when it's done and not when we hit the date ;-) I love this idea, if we make a perfect RC1 then during the next weeks we can release the final version. If we still have critical bugs we release RC2. So as what Eike already suggested: first versions should be Alphas, afterwards I suggest more betas and more release candidates. Is Alpha unstable code? A release that contains known critical bugs? why do we release them? Are distros going to package Alphas? Is Beta unstable code? A release that contains known critical bugs? why do we release them? Are distros going to package Betas? I'm sure that the answer to those questions depends on the user, and no matter what communication effort we do people will continue having their definitions of betas and alphas. Personally I think we should do a number of pre-releases without any special name, and the moment we think Plasma2 is stable we tag RC1. Cheers. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: When should there be a screen brightness OSD?
On Tuesday 21 January 2014 22:55:14 Thomas Pfeiffer wrote: On Tuesday 21 January 2014 22:45:44 Kai Uwe Broulik wrote: Hi, +1 as well! Especially it popping up on session start where the compositor isn't fully ready. :/ So to summarize: - never ever show it when the brightness changes automatically (session start, mouse movement, screen timeout, ...) - if user changes, it show the OSD on the primary/internal monitor as this is probably the affected one When dragging the slider in the battery monitor it shouldn't be shown either, the slider (and the dimming screem, of course) provides the feedback already. Cheers, Kai Uwe +1, that sounds exactly like it should behave! Funny thing, I fixed this behavior in one previous release and then in the next release it regressed, nobody fixed it then. I can take a look and fix it for 4.11.6, it shouldn't be *that* hard. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Plasma on Wayland summary
Hi there In the Plasma sprint Martin Gräßlin and I sit down and check how many things of kde-workspace beside KWin need work in order to run under Wayland. Most of the work is quite easy to do some times just adding some #ifdef will do the trick. The only areas that seem to require a special amount of work are those related to configure hardware: -Mouse -Keyboard -Screen (randr and dpms) Also there are some tricky things we will have to deal with (probably by extending KWin): -clipboard -kidletime Full list in: http://community.kde.org/Plasma/Next/Wayland Cheers ! ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Splitting kde-workspace and kde-runtime proposal
In the plasma sprint we have done a session to plan what we are going to do with kde-workspace/kde-runtime repositories, here is the proposal we came with. We are going to create 2 new repos called plasma-desktop and plasma-workspace, we decided to use plasma as a prefix so in the future we can have more workspaces and desktops without being in the awkward situation of having one wrongly labeled as KDE while others are not (thinking on for example having Razorqt/lxde as part of KDE in the future). Current kde-workspace and kde- runtime will be kept for history reasons. plasma-desktop will hold all specific pieces tied to the desktop experience, for example the touchpadenabler only makes sense on laptops. plasma-workspace will contain all bits that are generic enough to be of interest for more than one form factor, for example we need appmenu in both, tablet and desktop. Additionally we want to split optional dependencies (kinfocenter for example) and other projects that are quite big. Some of the new repositories we want to create are: powerdevil kwin oxygen (containing a full Oxygen experience) ksysguard kinfocenter klipper... A full list of the proposed new repositories can be found at [1]. Finally some other bits could be merged with some Frameworks, it is the case for example of solid-hardware and solid-networkstatus that should be moved to solid. Again, this is a proposal so please! send any feedback you might have. Cheers. [1] http://community.kde.org/Plasma/Tokamak7/split_proposal ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Summary of bugtracker situation discussion
On Sunday 19 January 2014 12:39:03 David Edmundson wrote: On Sun, Jan 19, 2014 at 8:48 AM, Martin Graesslin mgraess...@kde.org wrote: Hi Christoph, during the Plasma sprint we discussed the bug situation and want to get your feedback on our ideas. In case there is a team mailing list please feel free to forward the mail. Our goal is to improve the situation with Plasma 2. We have to admit that we have failed with the current bugzilla situation and that we are probably not able to clean that up. One of the problems we identified is that we just get way too many bug reports to be able to handle. All bugs and all wishlist items end up in the product plasma. That's just too much. Our idea here is to focus, focus and focus. The Plasma team only dedicates itself to maintain the essential parts (to be defined, e.g. taskmanager, digital clock, launcher...) everything else (e.g. comic strip) should not end up in the product plasma but in a different product or in many products. This could depend on what the maintainers of the products want. With that change in place we should be able to reduce the number of incoming bug reports to a level that we could start caring. Our idea in that regard is that each of our essential components has a maintainer who looks into the bug reports. Another idea is also to reduce the number of incoming crashers. One thing we had seen in the past is that 3rd party applets easily crash the system (hello python). We don't care about those. We could implement this by a system like what Linux kernel uses: 3rd party module means the system is tainted and the crash report gets discarded. That might filter out some legit crashes, but those will be reported again. On the field of wishlist items we thought about not accepting any ideas for new plasmoids any more. We only care about the essential modules and thus are not interested in developing new non-essential plasmoids. So all incoming wishlist items for new plasmoids could be just closed with a standardized message. Last but not least we also had some ideas for the current situation. We don't think it's possible to ask the maintainers of essential modules to go through the Plasma 1 bugs and check whether they are still valid. Given the terrible state we would scare anybody away from becoming maintainer. So we need to improve that. One idea is to mass close everything which had been reported against a version before 4.11. 4.11 is our long-term release and everything else is unmaintained. This could cause some uncomfortable situations with our users but if we draft a well written message our users might be able to understand it. The second idea in that area is that we only care about the Plasmoids written in QML from the Plasma 1 times. I would prefer to consider it as; there are too many reports for us to triage, so we will send the reporter message them a message asking them to triage their own bug. They should test if it still applies in the new Plasma and reopen on the new product accordingly. Till then we will close it. In practice it amounts to the same thing, but it comes across better. Exactly my thoughts. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Systemtray breakout notes
On Thursday 16 January 2014 19:38:30 Mark Gaiser wrote: The XEmbed systemtray mechanism will not be supported anymore, instead we will attempt to merge support for statusnotifieritems into Qt (for QSystemTray). Other desktops are going a similar route. Please don't use excuses as Other desktops are going a similar route.. They might, but they suck at doing it in my opinion. I'm guessing you aim at windows 8 and perhaps gnome here. Otherwise, please do share more details. We are only dropping XEmded, this doesn't mean dropping all application system trays but only the ones that don't support any modern way of doing it. Meaning that only old apps, Java, and some other old stuff will break. As for other apps using statusnotifier the idea is to merge this in the taskbar (or at least try and see what happens) and save the systemtray only for things that belong to the system, system being whatever we want it to be. BTW, the reason to drop XEmbded is that it is too complicated to integrate it right and even if we do it literally doesn't scale (since the windows have fixed size), so the result is something like this: http://www.omgubuntu.co.uk/wp-content/uploads/2013/01/search.jpg Notice the dropbox icon. So let's see if we can move systemtray forward on freedesktop, we might need to implement GNOME's in case they are not using statusnotifier (iirc gnome- shell is has support for it already). ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Notes from KRunner Breakout
One missing point, it will be possible to change the interface of Milou, so if somebody wants to write a task oriented GUI (old katapoult was mentioned) it will a matter of throwing some QMl files :p ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Login Manager Story
On Wednesday 15 January 2014 21:20:57 Sebastian Kügler wrote: Our idea of direction so far is to provide a set of QML files so that both can integrate well visually, and revisit the situation after this summer. This will cover only distributions using lightdm or SDDM (kdm has no support for qml). ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: DataEngines and models
On Friday 27 December 2013 20:27:48 Marco Martin wrote: On Friday 27 December 2013 09:50:46 Àlex Fiestas wrote: So, if DataEngines are needed (I do not doubt that) let's continue having them but let's stop pretending they are not public API or that they are meant only for a quick hack. We don't want hacks do we? :p +1 for de-hackify them ;) my point is that adding official api to put actual models in them (would be the same thing as imports, having to set the roleNames and all) that would make possible to turn some of the current dataengines that have quite cosmic hacks to emulate models in some of their sources but not all. wether to choose for new stuff, probably time will tell, but should be possible to clean a lot currently existing ones Okz, my email was more intended for possible third-party readers that might misinterpret the previous email (the hack part). Cheerz ! ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
[kde-workspace] ksplash/ksplashqml: [ksplash] Make KPlashQML stages ready to be run asynchronously
Git commit c1d668f167a9bd3ac4db1475564dea49e8f7adac by Àlex Fiestas.
Committed on 17/12/2013 at 18:12.
Pushed by afiestas into branch 'master'.
[ksplash] Make KPlashQML stages ready to be run asynchronously
Since we ported to DBus we are using ASync calls to send the
QDBusMessages that indicate to KSplash that a new stage has happened.
Since we are using an async method we can't take into account the order
anymore.
I tried changing all calls to be sync and then KSplash works correctly
which shows that we are starting the session correctly but it is better
if we keep these calls async because you know, the future is async.
CCMAIL: plasma-devel@kde.org
M +5-14 ksplash/ksplashqml/SplashApp.cpp
M +1-0ksplash/ksplashqml/SplashApp.h
http://commits.kde.org/kde-workspace/c1d668f167a9bd3ac4db1475564dea49e8f7adac
diff --git a/ksplash/ksplashqml/SplashApp.cpp b/ksplash/ksplashqml/SplashApp.cpp
index 20bde13..893bf1b 100644
--- a/ksplash/ksplashqml/SplashApp.cpp
+++ b/ksplash/ksplashqml/SplashApp.cpp
@@ -74,20 +74,11 @@ void SplashApp::timerEvent(QTimerEvent * event)
void SplashApp::setStage(const QString stage)
{
-if (stage == QLatin1String(initial) m_stage 0)
-setStage(0); // not actually used
-else if (stage == QLatin1String(kded) m_stage 1)
-setStage(1);
-else if (stage == QLatin1String(confupdate) m_stage 2)
-setStage(2);
-else if (stage == QLatin1String(kcminit) m_stage 3)
-setStage(3);
-else if (stage == QLatin1String(ksmserver) m_stage 4)
-setStage(4);
-else if (stage == QLatin1String(wm) m_stage 5)
-setStage(5);
-else if (stage == QLatin1String(desktop) m_stage 6)
-setStage(6);
+if (m_stages.contains(stage)) {
+return;
+}
+m_stages.append(stage);
+setStage(m_stages.count());
}
void SplashApp::setStage(int stage)
diff --git a/ksplash/ksplashqml/SplashApp.h b/ksplash/ksplashqml/SplashApp.h
index 3ba3147..e720998 100644
--- a/ksplash/ksplashqml/SplashApp.h
+++ b/ksplash/ksplashqml/SplashApp.h
@@ -47,6 +47,7 @@ private:
int m_stage;
QListSplashWindow * m_windows;
bool m_testing;
+QStringList m_stages;
QBasicTimer m_timer;
QDesktopWidget *m_desktop;
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel
[kde-workspace] ksmserver: [ksmserver] Port the shutdowndlg, HUGE hack just to make it work
Git commit 63197074b17e042d2d99973488358a14afae8560 by Àlex Fiestas.
Committed on 17/12/2013 at 17:34.
Pushed by afiestas into branch 'master'.
[ksmserver] Port the shutdowndlg, HUGE hack just to make it work
Please, somebody else should properly port this, I have done the minimum
required work to allow the dialog to work.
CCMAIL: plasma-devel@kde.org
M +19 -13 ksmserver/shutdowndlg.cpp
M +4-4ksmserver/themes/contour/ContourButton.qml
M +4-4ksmserver/themes/contour/main.qml
M +5-5ksmserver/themes/default/ContextMenu.qml
M +9-9ksmserver/themes/default/KSMButton.qml
M +4-4ksmserver/themes/default/MenuItem.qml
M +86 -86 ksmserver/themes/default/main.qml
http://commits.kde.org/kde-workspace/63197074b17e042d2d99973488358a14afae8560
diff --git a/ksmserver/shutdowndlg.cpp b/ksmserver/shutdowndlg.cpp
index 6ad428d..00704e4 100644
--- a/ksmserver/shutdowndlg.cpp
+++ b/ksmserver/shutdowndlg.cpp
@@ -162,11 +162,12 @@ void KSMShutdownFeedback::logoutCanceled()
Q_DECLARE_METATYPE(Solid::PowerManagement::SleepState)
+#include QVBoxLayout
KSMShutdownDlg::KSMShutdownDlg( QWidget* parent,
bool maysd, bool choose,
KWorkSpace::ShutdownType sdtype,
const QString theme)
- : QDialog( parent, Qt::Popup ) //krazy:exclude=qclasses
+ : QDialog( parent/*, Qt::Popup */) //krazy:exclude=qclasses
// this is a WType_Popup on purpose. Do not change that! Not
// having a popup here has severe side effects.
{
@@ -181,8 +182,13 @@ KSMShutdownDlg::KSMShutdownDlg( QWidget* parent,
KDialog::centerOnScreen(this, -3);
+ setMinimumSize(300, 200);
//kDebug() Creating QML view;
-m_view = new QQuickView(windowHandle());
+QVBoxLayout *vbox = new QVBoxLayout(this);
+m_view = new QQuickView( );
+QWidget *windowContainer = QWidget::createWindowContainer(m_view, this);
+vbox-addWidget(windowContainer);
+windowContainer-setSizePolicy(QSizePolicy::Preferred,
QSizePolicy::Preferred);
QQmlContext *context = m_view-rootContext();
context-setContextProperty(QStringLiteral(maysd), maysd);
context-setContextProperty(QStringLiteral(choose), choose);
@@ -223,22 +229,23 @@ KSMShutdownDlg::KSMShutdownDlg( QWidget* parent,
setModal( true );
// window stuff
-m_view-setFlags(Qt::X11BypassWindowManagerHint);
-//m_view-setFrameShape(QFrame::NoFrame);
-//m_view-setAttribute(Qt::WA_TranslucentBackground);
+// setFlags(Qt::X11BypassWindowManagerHint);
+// windowContainer-setFrameShape(QFrame::NoFrame);
+windowContainer-setAttribute(Qt::WA_TranslucentBackground);
+setAttribute(Qt::WA_TranslucentBackground);
setAttribute(Qt::WA_TranslucentBackground);
setStyleSheet(QStringLiteral(background:transparent;));
-//QPalette pal = m_view-palette();
-//pal.setColor(backgroundRole(), Qt::transparent);
-//m_view-setPalette(pal);
-//m_view-setHorizontalScrollBarPolicy(Qt::ScrollBarAlwaysOff);
-//m_view-setVerticalScrollBarPolicy(Qt::ScrollBarAlwaysOff);
+QPalette pal = windowContainer-palette();
+pal.setColor(backgroundRole(), Qt::transparent);
+windowContainer-setPalette(pal);
+//setHorizontalScrollBarPolicy(Qt::ScrollBarAlwaysOff);
+//setVerticalScrollBarPolicy(Qt::ScrollBarAlwaysOff);
// engine stuff
KDeclarative kdeclarative;
kdeclarative.setDeclarativeEngine(m_view-engine());
kdeclarative.initialize();
kdeclarative.setupBindings();
-m_view-installEventFilter(this);
+windowContainer-installEventFilter(this);
QString fileName =
QStandardPaths::locate(QStandardPaths::GenericDataLocation,
QStringLiteral(ksmserver/themes/%1/main.qml).arg(theme));
if (QFile::exists(fileName)) {
@@ -253,8 +260,7 @@ KSMShutdownDlg::KSMShutdownDlg( QWidget* parent,
connect(rootObject, SIGNAL(rebootRequested2(int)), SLOT(slotReboot(int)) );
connect(rootObject, SIGNAL(cancelRequested()), SLOT(reject()));
connect(rootObject, SIGNAL(lockScreenRequested()), SLOT(slotLockScreen()));
-m_view-show();
-//m_view-setFocus();
+
adjustSize();
}
diff --git a/ksmserver/themes/contour/ContourButton.qml
b/ksmserver/themes/contour/ContourButton.qml
index ee82205..5176c6a 100644
--- a/ksmserver/themes/contour/ContourButton.qml
+++ b/ksmserver/themes/contour/ContourButton.qml
@@ -22,7 +22,7 @@ Inherits:
PlasmaCore.FrameSvgItem
Imports:
-QtQuick 1.0
+QtQuick 2.0
org.kde.plasma.core
org.kde.qtextracomponents
@@ -53,9 +53,9 @@ Signals:
This handler is called when there is a click.
**/
-import QtQuick 1.0
-import org.kde.plasma.core 0.1 as PlasmaCore
-import org.kde.qtextracomponents 0.1
+import QtQuick 2.0
+import org.kde.plasma.core 2.0 as PlasmaCore
+import org.kde.qtextracomponents 2.0
PlasmaCore.FrameSvgItem {
id: button
diff --git a/ksmserver/themes/contour/main.qml
b
[plasma-framework] src/shell: [plasma-shell] Mute all debug output when started from autostart
Git commit dfcfad1182e51d5165bd8d289a33253aba7b8776 by Àlex Fiestas. Committed on 17/12/2013 at 18:44. Pushed by afiestas into branch 'master'. [plasma-shell] Mute all debug output when started from autostart This enables other developers to use journalctl/~.xsession-errors and do not drown on warnings. CCMAIL: plasma-devel@kde.org M +1-1src/shell/plasma-shell.desktop http://commits.kde.org/plasma-framework/dfcfad1182e51d5165bd8d289a33253aba7b8776 diff --git a/src/shell/plasma-shell.desktop b/src/shell/plasma-shell.desktop index f6c4229..0d6d231 100644 --- a/src/shell/plasma-shell.desktop +++ b/src/shell/plasma-shell.desktop @@ -1,5 +1,5 @@ [Desktop Entry] -Exec=plasma-shell +Exec=plasma-shell --shut-up X-DBUS-StartupType=Unique Name=Plasma Desktop Workspace Name[de]=Plasma-Arbeitsflächenbereich ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
[plasma-framework] src/shell: [plasma-shell] Add an option to suppress any output (--shut-up)
Git commit c047dd5f686c5850fdb2638854885bd76151ef93 by Àlex Fiestas.
Committed on 17/12/2013 at 18:33.
Pushed by afiestas into branch 'master'.
[plasma-shell] Add an option to suppress any output (--shut-up)
The amount of warnings that plasma-shell has, makes it super hard to
make use of tools like journalctl or to grep ~/.xsession-errors.
We need these tools to diagnose possible bugs in the session start or
any other software that redirects stderr or those places.
We can remove this option once all the Warnings are fixed, specially
the one in Qt: https://codereview.qt-project.org/#change,73943
CCMAIL: plasma-devel@kde.org
M +12 -0src/shell/main.cpp
http://commits.kde.org/plasma-framework/c047dd5f686c5850fdb2638854885bd76151ef93
diff --git a/src/shell/main.cpp b/src/shell/main.cpp
index f6c797d..e073d00 100644
--- a/src/shell/main.cpp
+++ b/src/shell/main.cpp
@@ -32,6 +32,11 @@ static const char description[] = Plasma Shell;
static const char version[] = 2.0;
static QCommandLineParser parser;
+void noMessageOutput(QtMsgType type, const char *msg)
+{
+ Q_UNUSED(type);
+ Q_UNUSED(msg);
+}
int main(int argc, char** argv)
{
QApplication app(argc, argv);
@@ -54,11 +59,15 @@ int main(int argc, char** argv)
QStringLiteral(Recent number of
crashes),
QStringLiteral(n));
+QCommandLineOption shutup(QStringList() QStringLiteral(s)
QStringLiteral(shut-up),
+ QStringLiteral(Shuts up the output));
+
parser.addVersionOption();
parser.addHelpOption();
parser.addOption(dbg);
parser.addOption(win);
parser.addOption(crash);
+parser.addOption(shutup);
parser.process(app);
@@ -68,6 +77,9 @@ int main(int argc, char** argv)
QQmlDebuggingEnabler enabler;
}
+if (parser.isSet(shutup)) {
+qInstallMsgHandler(noMessageOutput);
+}
Plasma::PluginLoader::setPluginLoader(new ShellPluginLoader);
ShellManager::setCrashCount(parser.value(crash).toInt());
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Plasma Sprint Dates!
On Wednesday 11 December 2013 17:18:40 Sebastian Kügler wrote: * arrange stuff locally (is office big enough, plans for food and accommodation, make sure chocolate supply is green, etc.) * Meet, hack, have fun The office will be ready to host ~20 people sprints by then, so something less to worry about (unless we end up being 40 people xD) Cheers. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: bug mails on the mailinglist
On Monday 09 December 2013 22:50:28 Martin Graesslin wrote: Hi, could we please get the bug mails away from the list? Those who are interested can either look at the bug tracker or just follow the bug user. Having bug mails sent to the list is a bad idea. Been there, done that, don't want to go there again :-D Sorry for the spamming :/ ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Monday meeting
On Sunday 08 December 2013 18:47:47 Martin Graesslin wrote: I love to soliloquize, so I will do the hangout nevertheless :-D Was the meeting done? if not, will it happen today (Tuesday) ? ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: kded5 and kde-workspace
On Wednesday 20 November 2013 20:47:54 Àlex Fiestas wrote: Hey there Today I have been porting powerdevil and while doing it found out that kded5 was not loading any modules and many kde-workspace projects were using org.kde.kded instead of the one ended with .kded5 Tomorrow I'd like to push a local commit that changes all org.kde.kded for org.kde.kded5 (which we will have to change again but more about that in a later email), and will effectively make kde-workspace and plasma-framework depend on kded5. In order to make kded5 load modules, you have to have KDE_SESSION_VERSION set to 5, so add that to your set kde5 environment script. So please, adapt your environment asap, I'd like to push this tomorrow so we can do testing of the kf5 KDEDModules instead of kded4. Cheers ! Change pushed, please set KDE_SESSION_VERSION to 5 so we can get some testing to kded ! ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
kded5 and kde-workspace
Hey there Today I have been porting powerdevil and while doing it found out that kded5 was not loading any modules and many kde-workspace projects were using org.kde.kded instead of the one ended with .kded5 Tomorrow I'd like to push a local commit that changes all org.kde.kded for org.kde.kded5 (which we will have to change again but more about that in a later email), and will effectively make kde-workspace and plasma-framework depend on kded5. In order to make kded5 load modules, you have to have KDE_SESSION_VERSION set to 5, so add that to your set kde5 environment script. So please, adapt your environment asap, I'd like to push this tomorrow so we can do testing of the kf5 KDEDModules instead of kded4. Cheers ! ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Moving KScreen and libkscreen to extragear
On Wednesday 13 November 2013 22:56:37 Christoph Feck wrote: On Wednesday 13 November 2013 21:16:01 Ben Cooksley wrote: Based on Alex's request, I have now moved libkscreen and kscreen to their relevant locations in Extragear. Multiple screen support was one of the weak spots left in KDE 4. Nice to see it's finally fixed. Thanks to everyone involved! Next in queue: Screenlocker ;) Btw, is the plan to move KScreen to the Workspace for the Plasma 2 release? It really shouldn't be an extra, but a standard component. But I am not sure if the plan is to split the Workspace repo or rather unify it (including Plasma-NM components, etc.). The plan is (I think) to split it in different repos, also I'd like to have shorter releases for kscreen/bluedevil etc. If the whole *new* kde-workspace has shorter releases, then we can release together, we'll see. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Semi-modal sidebar paradigm
On Monday 04 November 2013 16:40:09 Marco Martin wrote: Hi all, since i was getting the activity switcher and widget explorer at least a bit in shape in plasma2, i was experimenting with an idea we were toying a bit around at the last tokamak. Identifying all pieces of ui in the workspace that are completely modeal, like splash, lockscreen/user switching.. and give them all a consistent look and feel. also identify things that are semi-modal, that are workspacey but don't take the whole attention. that they could be, add widgets, switch activity, alt+tab, krunner, maybe kickoff (something else?) one idea was to have a sidebar that takes the whole screen height but as less width as possible. for better being able to comment, i did some prototypes, already in plasma2: http://im9.eu/picture/tg1706 http://im9.eu/picture/jj1706 (contents of the sidebars quickly ported from plasma1, so they can/should be made way prettier that that) on KWin, i quickly hacked this as a new tabbox plugin (well, plus an hack for left alignment, that should probably go in the qml api, todo if/when porting to kwin5) http://im9.eu/picture/nv1706 The blur effect is also different to have more readability, absolutely needed if we continue to have big areas with a plasma background (looks less transparent but more phisically similar to frosted glass that is not only backlit but has some incident light as well) but that's for another thread ;) comments/ideas/opinions? Imho this is the kind of thing that requires further investigation, deploy it on real users computers and see how they feel about it etc. Personally I have been playing with vertical panels with content for a long time and I have mixed feelings. As an example the vertical plasmoid picker doesn't feel good to me while the notification centre in osx feels good. I also played with the KTp contact list and with a shortcut it worked quite well (and felt nice). With smaller panels such one with app's (icons only) or the ktp plasmoids I haven't had that feeling. Cheers. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Removing kcontrol/randr
On Wednesday 16 October 2013 17:26:16 you wrote: Hi all, I hope we all agree that for Plasma2 kscreen is our solution for multiple monitors. Because of that I intend to delete the old configuration module and kded found in kcontrol/randr from our master branch. I will do so by Monday if nobody objects. If someone objects he/she is invited to port it to KF5 :-) Cheers Martin Send my regards to kcontrol/randr befiore you nuke it. Eventually we have to nuke kephal, I have a branch (pushed I think?) which almost removes it. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 111899: Make QGuiPlatformPlugin react to iconChanges
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/111899/ --- (Updated Aug. 6, 2013, 7:02 a.m.) Review request for Plasma and Olivier Goffart. Description --- When KDE changes the iconSize, send a StyleChange event to QToolbar and QMainWindow (this one is required for QToolBar that are children of it). Diffs - qguiplatformplugin_kde/qguiplatformplugin_kde.cpp cc74dc0 Diff: http://git.reviewboard.kde.org/r/111899/diff/ Testing --- Played a while with assistant, designer and quasselclient, seems to work fine. Thanks, Àlex Fiestas ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Keyboard detection and a test request
I did something like this related with bluetooth, I used udev to detect the devices (which imho is the right layer) and it worked great with no false positives. What I did was: -Detect if any keyboard was present -Detect Mouse/touchpad you have a Qt wrapper of udev in kdelibs/solid. Cheerz. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Keyboard detection and a test request
On Friday 21 June 2013 17:41:57 Ivan Čukić wrote: What I did was: -Detect if any keyboard was present -Detect Mouse/touchpad you have a Qt wrapper of udev in kdelibs/solid. Great to know, will try it out later. Though I'm wondering whether this could lead to recognizing the devices that don't work with X. Anyhow, Aaron's idea to track the device property and this are the most viable choices for keyboard detection. Note that Xorg uses udev underneath, and its little what Xorg adds on top as far as I know. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Battery Monitor revamp
For what is worth (and from the Solid side of things). Batteries have improved a lot since last time we discussed this issue, back on the days a high CPU round of 10min would drain huge percentage of the power in your battery, hence the estimation was really bad. Additionally the estimation was done in most of the cases in the software side so calculation was always bogus. Now days the situation has changed though. Batteries are way smarter than they used to be, even the stupid ones are kinda smart though. In most laptops sold in the last years you can find batteries that implement SBS (Smart Battery System) or similar (there is another one I can't recall). Additionally battery capacity has grown a lot while cpu power requirements have decreased (specially since Intel Sandy Bridge) so a CPU pike of 10mins will not affect that much the estimation time (and systems like SBS are smart enough to prevent that). Maybe usability wise showing the remaining time is not recommendable or it is confusing, but technically the situation has clearly changed and the remaining time can now be shown accurately. Cheerz. On Mon, May 27, 2013 at 10:53 AM, Kai Uwe Broulik k...@privat.broulik.dewrote: I feel better when I see it more accurately. My experience shows that battery icons are usually way too pessimistic or way too optimistic. Now it shows two of five bars although the battery is still half full. And once it goes 20% or below it is red although 20% means half an hour of battery life left. I'd be fine with dropping the overlay if we had 10 linear steps for the icon rather than 5 which are unequally distributed. Aaron J. Seigo ase...@kde.org schrieb: On Sunday, May 26, 2013 18:53:24 Kai Uwe Broulik wrote: On the desktop it would work that way, yes. But I really want to have the percentage shown in the panel but don't know how that could work better like out of curiosity: what is the value of having the exact % always shown in the main UI? the battery steps show roughly how much it is charged, and if one wants to check more fine grained you can tap on the icon or mouse over it .. other than the good feeling of knowing something to the single %, what is the actual use case for this? -- 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 ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Removing noKephal branch
Hey there Long time ago I pushed a branch called noKephal to kde-workspace with the intention of removing the internal library and replace it with QDesktopWidget (which kephal uses underneath). At this point, it makes little sense to continue with the work since for Qt5 we want to use QScreen, and I guess that lot will change in the unified shell+plasma-framework. Additionally modifying this delicate code in the release where we'll change focus to Qt5 does not make much sense. I thought on leaving it there just as a reference but I'm unsure how useful it will be. So, any argument against removing the branch? Cheers. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 109648: Implement the implicitWidth/implicitHeight of the chat plasmoid
On March 21, 2013, 7:11 p.m., Marco Martin wrote: Ship It! Marco, can you bring some light into David ramblings? Any doc on implicit/preferred/minimum width? - Àlex --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/109648/#review29653 --- On March 21, 2013, 5:37 p.m., Aleix Pol Gonzalez wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/109648/ --- (Updated March 21, 2013, 5:37 p.m.) Review request for Plasma, Telepathy and David Edmundson. Description --- Implements those 2 properties, aliasing to the similar preferredWidth/Height. When I have Icon-Only tasks + Chat plasmoid in a panel, their growth rendered unpredictable. Implementing the implicit seems to solve this problem. Diffs - chat/org.kde.ktp-chat/contents/ui/main.qml e11269e Diff: http://git.reviewboard.kde.org/r/109648/diff/ Testing --- I was reproducing the problem regularly since a couple of days, then now I cannot reproduce anymore. There's no testing per se, though... Thanks, Aleix Pol Gonzalez ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 109049: Fix favicon support for chrome bookmarks on krunner
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/109049/#review27876 --- Ship it! Tested the patch with chromiium 24.0.1312.70 (181759) worked fine. Code wise it looks fine as well. - Àlex Fiestas On Feb. 21, 2013, 7:29 p.m., Marco Gulino wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/109049/ --- (Updated Feb. 21, 2013, 7:29 p.m.) Review request for kde-workspace and Plasma. Description --- As reported by an user ( https://bugs.kde.org/show_bug.cgi?id=305633 ), chrome bookmarks database changed, and favicon wasn't shown anymore (not either the default star icon). I added the functionality back, and added a safety guard for displaying the default icon if something similar happens again. (note: I didn't set the bugs field here, since that bug was already closed, and was about something else). Diffs - plasma/generic/runners/bookmarks/faviconfromblob.h cff4835 plasma/generic/runners/bookmarks/faviconfromblob.cpp 93c720c plasma/generic/runners/bookmarks/fetchsqlite.h 8b181df plasma/generic/runners/bookmarks/fetchsqlite.cpp 871deff Diff: http://git.reviewboard.kde.org/r/109049/diff/ Testing --- with chrome as default browser, install the plugin, restart krunner, type bookmarks to view all bookmarks: proper favicon is shown. Removing the database query fix, but leaving the safety guard, and cleaning favicon cache (to have again a broken feature case), the default icon is shown. Thanks, Marco Gulino ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 109049: Fix favicon support for chrome bookmarks on krunner
On Feb. 20, 2013, 1:06 a.m., Àlex Fiestas wrote: I guess this will break compatibility with old versions then? if so, do you know from which version will it work? If this was not long ago, can we check the version and keep supporting the old and the new one? Àlex Fiestas wrote: Code-wise the patch looks fine. Marco Gulino wrote: You're right, there's a compatibility break, and we can't even know starting from which version, since it's an internal database not documented (I might try looking around, but I don't expect to find much). If it makes sense, I might conditionally choose the right query depending on the schema found (assuming the new table didn't exist in the previous version, which makes sense). I also noticed that the new table is meant to support multiple icon sizes, so I might add an order by clause to choose the wider one as default. To be clear, personally I'd be fine if we drop support for some old Chromium version, thing is those guys bump versions like crazy (today we are at chromium 20 and tomorrow we are at 30), so we need to know how old is this change to be able to decide if we want to drop support for older versions. - Àlex --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/109049/#review27760 --- On Feb. 19, 2013, 10:42 p.m., Marco Gulino wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/109049/ --- (Updated Feb. 19, 2013, 10:42 p.m.) Review request for kde-workspace and Plasma. Description --- As reported by an user ( https://bugs.kde.org/show_bug.cgi?id=305633 ), chrome bookmarks database changed, and favicon wasn't shown anymore (not either the default star icon). I added the functionality back, and added a safety guard for displaying the default icon if something similar happens again. (note: I didn't set the bugs field here, since that bug was already closed, and was about something else). Diffs - plasma/generic/runners/bookmarks/faviconfromblob.cpp 93c720c Diff: http://git.reviewboard.kde.org/r/109049/diff/ Testing --- with chrome as default browser, install the plugin, restart krunner, type bookmarks to view all bookmarks: proper favicon is shown. Removing the database query fix, but leaving the safety guard, and cleaning favicon cache (to have again a broken feature case), the default icon is shown. Thanks, Marco Gulino ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 109049: Fix favicon support for chrome bookmarks on krunner
On Feb. 20, 2013, 1:06 a.m., Àlex Fiestas wrote: I guess this will break compatibility with old versions then? if so, do you know from which version will it work? If this was not long ago, can we check the version and keep supporting the old and the new one? Àlex Fiestas wrote: Code-wise the patch looks fine. Marco Gulino wrote: You're right, there's a compatibility break, and we can't even know starting from which version, since it's an internal database not documented (I might try looking around, but I don't expect to find much). If it makes sense, I might conditionally choose the right query depending on the schema found (assuming the new table didn't exist in the previous version, which makes sense). I also noticed that the new table is meant to support multiple icon sizes, so I might add an order by clause to choose the wider one as default. Àlex Fiestas wrote: To be clear, personally I'd be fine if we drop support for some old Chromium version, thing is those guys bump versions like crazy (today we are at chromium 20 and tomorrow we are at 30), so we need to know how old is this change to be able to decide if we want to drop support for older versions. Marco Gulino wrote: Hopefully not :P I think I found the commit date on chromium git server: http://git.chromium.org/gitweb/?p=git/chromium.git;a=commit;h=eded41c5c28bf94e128b6ab4cdd8030fb8b6d2f3 The commit date is august 2012, so maybe it's a september/october release? For 4.11 we can drop it, but not for 4.10. Ideal solution will be supporting both though, this seems like a recent change. Also, this up to the maintainer (I'm not) but supporting both will always be preferred :p - Àlex --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/109049/#review27760 --- On Feb. 19, 2013, 10:42 p.m., Marco Gulino wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/109049/ --- (Updated Feb. 19, 2013, 10:42 p.m.) Review request for kde-workspace and Plasma. Description --- As reported by an user ( https://bugs.kde.org/show_bug.cgi?id=305633 ), chrome bookmarks database changed, and favicon wasn't shown anymore (not either the default star icon). I added the functionality back, and added a safety guard for displaying the default icon if something similar happens again. (note: I didn't set the bugs field here, since that bug was already closed, and was about something else). Diffs - plasma/generic/runners/bookmarks/faviconfromblob.cpp 93c720c Diff: http://git.reviewboard.kde.org/r/109049/diff/ Testing --- with chrome as default browser, install the plugin, restart krunner, type bookmarks to view all bookmarks: proper favicon is shown. Removing the database query fix, but leaving the safety guard, and cleaning favicon cache (to have again a broken feature case), the default icon is shown. Thanks, Marco Gulino ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 109049: Fix favicon support for chrome bookmarks on krunner
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/109049/#review27760 --- I guess this will break compatibility with old versions then? if so, do you know from which version will it work? If this was not long ago, can we check the version and keep supporting the old and the new one? - Àlex Fiestas On Feb. 19, 2013, 10:42 p.m., Marco Gulino wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/109049/ --- (Updated Feb. 19, 2013, 10:42 p.m.) Review request for kde-workspace and Plasma. Description --- As reported by an user ( https://bugs.kde.org/show_bug.cgi?id=305633 ), chrome bookmarks database changed, and favicon wasn't shown anymore (not either the default star icon). I added the functionality back, and added a safety guard for displaying the default icon if something similar happens again. (note: I didn't set the bugs field here, since that bug was already closed, and was about something else). Diffs - plasma/generic/runners/bookmarks/faviconfromblob.cpp 93c720c Diff: http://git.reviewboard.kde.org/r/109049/diff/ Testing --- with chrome as default browser, install the plugin, restart krunner, type bookmarks to view all bookmarks: proper favicon is shown. Removing the database query fix, but leaving the safety guard, and cleaning favicon cache (to have again a broken feature case), the default icon is shown. Thanks, Marco Gulino ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 109049: Fix favicon support for chrome bookmarks on krunner
On Feb. 20, 2013, 1:06 a.m., Àlex Fiestas wrote: I guess this will break compatibility with old versions then? if so, do you know from which version will it work? If this was not long ago, can we check the version and keep supporting the old and the new one? Code-wise the patch looks fine. - Àlex --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/109049/#review27760 --- On Feb. 19, 2013, 10:42 p.m., Marco Gulino wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/109049/ --- (Updated Feb. 19, 2013, 10:42 p.m.) Review request for kde-workspace and Plasma. Description --- As reported by an user ( https://bugs.kde.org/show_bug.cgi?id=305633 ), chrome bookmarks database changed, and favicon wasn't shown anymore (not either the default star icon). I added the functionality back, and added a safety guard for displaying the default icon if something similar happens again. (note: I didn't set the bugs field here, since that bug was already closed, and was about something else). Diffs - plasma/generic/runners/bookmarks/faviconfromblob.cpp 93c720c Diff: http://git.reviewboard.kde.org/r/109049/diff/ Testing --- with chrome as default browser, install the plugin, restart krunner, type bookmarks to view all bookmarks: proper favicon is shown. Removing the database query fix, but leaving the safety guard, and cleaning favicon cache (to have again a broken feature case), the default icon is shown. Thanks, Marco Gulino ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request: powerdevil dbus interface - screenBrightnessChanged Signal
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/107398/#review22317 --- Add Dario Freddi as reviewer and wait until he gives the ship it pls. - Àlex Fiestas On Nov. 21, 2012, 9:18 a.m., Greg T wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/107398/ --- (Updated Nov. 21, 2012, 9:18 a.m.) Review request for Plasma. Description --- the upower powerdevilbackend doesnt emit a screenBrightnessChanged signal when you change the brightness without the brightnessKeys. I've just moved the signal to the setBrightness function. Now the powermanagement/PowerDevil dataengine gets also updated properly with the current brightness (this fixes the bugs). This addresses bugs 302111 and 302160. http://bugs.kde.org/show_bug.cgi?id=302111 http://bugs.kde.org/show_bug.cgi?id=302160 Diffs - powerdevil/daemon/backends/upower/powerdevilupowerbackend.cpp 3d0926fab8dac334d56d5cce430691e501b6f8c7 Diff: http://git.reviewboard.kde.org/r/107398/diff/ Testing --- works on my laptop when I set the screen brightness with the batterymonitor plasmoid Thanks, Greg T ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request: powerdevil dbus interface - screenBrightnessChanged Signal
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/107398/#review22330 --- Now that I think about it, ltinkl can review this as well ! - Àlex Fiestas On Nov. 21, 2012, 5:21 p.m., Greg T wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/107398/ --- (Updated Nov. 21, 2012, 5:21 p.m.) Review request for Plasma and Dario Freddi. Description --- the upower powerdevilbackend doesnt emit a screenBrightnessChanged signal when you change the brightness without the brightnessKeys. I've just moved the signal to the setBrightness function. Now the powermanagement/PowerDevil dataengine gets also updated properly with the current brightness (this fixes the bugs). This addresses bugs 302111 and 302160. http://bugs.kde.org/show_bug.cgi?id=302111 http://bugs.kde.org/show_bug.cgi?id=302160 Diffs - powerdevil/daemon/backends/upower/powerdevilupowerbackend.cpp 3d0926fab8dac334d56d5cce430691e501b6f8c7 Diff: http://git.reviewboard.kde.org/r/107398/diff/ Testing --- works on my laptop when I set the screen brightness with the batterymonitor plasmoid Thanks, Greg T ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Workspace Next Sprint Organization
On Friday, May 11, 2012 09:55:30 AM Marco Martin wrote: then whatever the results are is something that we can walk trough the implementation of it, what's doable, not so much, what will require changes in the platform and so on (at akademy?) Indeed, Akademy is close enough to delay some discussions until it, we should take that into account. Notmart you better come ! or you will make me a very very very sad hacker :( ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Workspace Next Sprint Organization
When I come back from SFO I will start together with Aleix the arragements for the sprint, fromm the top of my head: -Whiteboards -Projectors -Food -Car -Write how to get there So I'm going to add to that list: -Webcam, Microphone. We will have wired internet connection so it should be stable enough for having any voip conference. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Workspace Next Sprint Organization
On Friday, May 11, 2012 11:23:29 PM Kevin Ottens wrote: Would it be possible to also add to the list: - Markers both for the whiteboards and black ones for paper - A shitload of sticky notes in different sizes and colors - Quite some Blu-Tack, Patafix or equivalent[*] Those for sure - Flipboards Are those the ones with paper instead of boards? ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
