Re: Review Request 120566: Remove CMake cruft.
On Oct. 12, 2014, 11:37 p.m., Aleix Pol Gonzalez wrote: What do you mean by toggle find_package? -DCMAKE_DISABLE_FIND_PACKAGE_Phonon4Qt5. This is consistent approach with other optional dependencies. - Michael --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/120566/#review68294 --- On Oct. 12, 2014, 6:47 p.m., Michael Palimaka wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/120566/ --- (Updated Oct. 12, 2014, 6:47 p.m.) Review request for Plasma. Repository: plasma-workspace Description --- Since we can toggle find_package natively, we no longer need these old manual switches. Diffs - phonon/CMakeLists.txt fee6f287e4b75fdb83356e5c868f43ac30f76392 Diff: https://git.reviewboard.kde.org/r/120566/diff/ Testing --- Builds enabled/disabled as expected. Thanks, Michael Palimaka ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 120568: Save the default browser into the group [Default Applications]
On Oct. 12, 2014, 8:51 p.m., David Faure wrote: kcms/componentchooser/componentchooserbrowser.cpp, line 102 https://git.reviewboard.kde.org/r/120568/diff/1/?file=318115#file318115line102 No, I am very much against this. The whole point of use the right KDE app is to use the right KDE app, not to fire up kfmclient_html for everything including text files, images, calligra documents etc. The html suffix is especially wrong since it would try to use khtmlpart or webkitpart for all of this (explicit mimetype on the command-line). At least using kde-open would work for all mimetypes, but this is slower (one more intermediate process) than letting the calling app use KRun directly. I know that gnome saves the webbrowser as x-scheme-handler/http, but I have always considered this a mistake (and we discussed it at length on the xdg list, so the status quo will remain). One solution would be to keep this code (with kde-open) but then special case if the http scheme handler is kde-open then use KRun directly in the kio code that looks up x-scheme-handler stuff (grep says: KRun and DesktopExecParser). Luc Menut wrote: Sadly, there is no agreement on the way to save the user preference regarding default browser. In this situation, mimeapps.list / x-scheme-handler/http became de facto a standard, even on xdg.lists.freedesktop.org by non-gnome guys. So, currently, KDE's users have to set this manually. kfmclient_html.desktop is probably not the right choice, but I think that we should really improve this point in KF5 or Plasma, even if it isn't perfect. If everyone else wants to fire up a browser when clicking on a link to a .odt file, that's their choice. I still maintain that we can do better, thanks to KIO. Improving: yes, and I described how. Make a desktop file for kde-open, use that when the user selects use KIO in the GUI (which is the default, so KDE-based distros should also set this by default), and short-circuit that in KRun and/or DesktopExecParser to avoid the kde-open indirection. - David --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/120568/#review68292 --- On Oct. 12, 2014, 8:40 p.m., Luc Menut wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/120568/ --- (Updated Oct. 12, 2014, 8:40 p.m.) Review request for Plasma and David Faure. Repository: plasma-desktop Description --- Save the default browser by writing x-scheme-handler/http and x-scheme-handler/https into the group [Default Applications] in the file mimeapps.list . Nowadays, many applications look at user preferences for x-scheme-handler/http to determine the default browser, so setting this value would increase interoperability with these applications. regards, Luc Menut - Mageia PS: I don't have write access to kde git, so could you commit the change if the patch looks fine. Thanks. Diffs - kcms/componentchooser/componentchooserbrowser.cpp 61af1fd Diff: https://git.reviewboard.kde.org/r/120568/diff/ Testing --- Thanks, Luc Menut ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 120568: Save the default browser into the group [Default Applications]
On Oct. 13, 2014, 1:16 a.m., Aleix Pol Gonzalez wrote: Wouldn't it make sense to have this within KToolInvocation? It's responsible for chosing what's the default browser already. In any case we want it in sync. Yes, if we always set x-scheme-handler/http, then ktoolinvocation_x11.cpp can read that instead of BrowserApplication. But that's basically compatibility the other way around (KDE apps reading the scheme-handler setting set by other environments), so that's for a separate patch (this one is about KDE workspace setting scheme-handler for non-KDE apps to see). - David --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/120568/#review68295 --- On Oct. 12, 2014, 8:40 p.m., Luc Menut wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/120568/ --- (Updated Oct. 12, 2014, 8:40 p.m.) Review request for Plasma and David Faure. Repository: plasma-desktop Description --- Save the default browser by writing x-scheme-handler/http and x-scheme-handler/https into the group [Default Applications] in the file mimeapps.list . Nowadays, many applications look at user preferences for x-scheme-handler/http to determine the default browser, so setting this value would increase interoperability with these applications. regards, Luc Menut - Mageia PS: I don't have write access to kde git, so could you commit the change if the patch looks fine. Thanks. Diffs - kcms/componentchooser/componentchooserbrowser.cpp 61af1fd Diff: https://git.reviewboard.kde.org/r/120568/diff/ Testing --- Thanks, Luc Menut ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Fwd: Plasma Framework problems
On Sunday 12 October 2014, David Edmundson wrote: Assuming we don't have a time machine our options are: - revert this commit and release plasma-framework 5.3.1 really quickly Please go with this option... I need approval from Marco and other David. David eh no, that commit was correct. that code was moved in a plugin, so it must not be in two places. either it stays as is , or the plugin is removed from plasma-workspace, causing other similar problems of synchronization between p-f and p-w -- Marco Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Should favourites be shared between launchers, and launcher instances?
On Sunday 12 October 2014, Ivan Čukić wrote: i was thinking about an api for the scripting interface to do the defaults.. if preferred:// is used it would be less needed, but could still be useful. Is there a particular need for it to be scripted instead of being in a global config file? I'd say that reading a config file is a bit faster than actually executing a javascript function to set the defaults at runtime. a config file is fine too, is just another different thing that distributions would have to customize.. fine if is well documented, makes the process a bit more complicated tough -- Marco Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Plasma 5.1 beta tars
On Sun, Oct 12, 2014 at 05:34:33AM +1100, Michael Palimaka wrote: On 09/27/2014 02:13 AM, Michael Palimaka wrote: On 09/26/2014 08:28 AM, Jonathan Riddell wrote: New in this release.. - standard version number 5.0.95 for all Does this mean the stuff in extragear is moving to workspace? Any more thoughts about this? Are libkscreen, libmm-qt, libnm-qt now considered to be part of Plasma 5 proper - or are they still just extra software that happens to be released at the same time (and now with the same version number)? They're part of Plasma 5 proper and will remain so until the maintainers want to move them to KF5 or elsewhere. Jonathan ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Plasma 5.1.0
On Thursday, October 09, 2014 21:36:58 Albert Astals Cid wrote: El Dijous, 9 d'octubre de 2014, a les 14:26:48, Jonathan Riddell va escriure: Plasma 5.1.0 tars up now at http://starsky.19inch.net/~jr/tmp/plasma-5.1.0/ and coming soon to depot sha256 sums at https://www.kde.org/info/source-plasma-5.1.0.inc Release due on Tuesday. 4.14.2 release is also on Tueday, maybe i should move it to wednesday? I think that would make sense. I'm prepping the Plasma 5.1.0 release notes now. If need be, we can also push that one one day forward. Cheers, -- sebas http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9 ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 120471: Add Registry::sync() signal
On Oct. 8, 2014, 9:46 a.m., Martin Gräßlin wrote: src/client/registry.cpp, line 119 https://git.reviewboard.kde.org/r/120471/diff/4/?file=316845#file316845line119 this would crash - please use a test case for it. The destroy is intended to be used to clean up cleanly in case the Wayland connection died. So calling into any wayland client library call would crash. There should be a test for destroy handling, please extend that one. I just added a WaylandPointer (see http://commits.kde.org/kwayland/e213c4717ffba42952753540e27200a93d814cf4 ) which makes the whole process much easier. Declare your wl_callback as: WaylandPointerwl_callback, wl_callback_destroy callback; and then just do in ::release(): d-callback.release(); and in ::destroy(): d-callback.destroy(); - Martin --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/120471/#review68073 --- On Oct. 7, 2014, 11:12 a.m., Sebastian Kügler wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/120471/ --- (Updated Oct. 7, 2014, 11:12 a.m.) Review request for kwin, Plasma and Martin Gräßlin. Repository: kwayland Description --- Add Registry::sync() signal Emitted when the Wayland display is done flushing the initial interface callbacks, announcing wl_display properties. This can be used to compress events. Note that this signal is emitted only after announcing interfaces, such as outputs, but not after receiving callbacks of interface properties, such as the output's geometry, modes, etc.. This signal is emitted from the wl_display_sync callback. For this, we add a wl_callback_listener to the registry's Private, enqueue its events properly, if necessary, and trigger the signal through a callback mechanism similar to the wl_registry callbacks. This signal allows users of the API to find out when the signal emissions, such as outputAnnounced, etc. for all currently existing interfaces is complete. Diffs - autotests/client/test_wayland_registry.cpp 571be0f src/client/registry.h 9e63a2b src/client/registry.cpp 22f9484 Diff: https://git.reviewboard.kde.org/r/120471/diff/ Testing --- tests in libkscreen exercise this feature, it works as expected, meaning I can notify when all initial synchronization is done. Thanks, Sebastian Kügler ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
5.1 Errata
As discussed at hangout, if you know of bugs which users should be aware of please add them to https://community.kde.org/Plasma/5.1_Errata Jonathan ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Minutes Monday Plasma Hangout
Minutes Plasma Hangout, 13-10-2014 Present: Aleix, David, Kai Uwe, Marco, Martin G., Martin K., Jonathan, Harald, Jens, Sebastian For updates on TODO/status, see also Kanban board at: https://todo.kde.org/?controller=boardaction=showproject_id=13 David: - Investigating breakage of new Plasma with older frameworks - discussing solution, problem is about a codepath duplication in a plugin and hardcoded Aleix: - Please let him know if there are problems with moving repos to workspace - Attended Qt DevDays last week - Has RR about making QIconItem use TextureNode Kai Uwe: - investigating where porting to Animator would make sense in Plasma (to reduce CPU load) Marco: - bug hunting and fixing - especially bugs with single screen, should work fine now Martin G: - Attended XDC (see blog at http://blog.martin-graesslin.com/blog/2014/10/xdc-2014/ ) - will work on subcompositor next - Keeps focus on Wayland Jonathan: - Working on release bits (information, mainly) Harald: - Blue Systems is creating weekly isos again now - based on Kubuntu production packages with CI - working on PA mixer Martin K: - Bug triaging - Working on KAccounts Jens: - Looking for a dev to work on systemsettings - Discussing changes in Oxygen between Qt4 and Qt5 version Sebastian: - Worked on promo - KWayland addition of wl_display_sync in API almost done - to make sure 5.1 gets out, then back to Wayland kscreen, - perhaps bit of pluginloader -- sebas http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9 ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 120565: Save the default file manager into the group [Default Applications]
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/120565/#review68305 --- Ship it! Looks correct. The addition to Added Applications is obsoleted by this, I guess you're keeping it for old implementations, that's fine. Hmm, well, kservice/src/kbuildsycoca/kmimeassociations.cpp is such an old implementation, it doesn't read Default Applications yet :-) That's something else you might want to fix ;) - David Faure On Oct. 12, 2014, 6:03 p.m., Luc Menut wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/120565/ --- (Updated Oct. 12, 2014, 6:03 p.m.) Review request for Plasma and David Faure. Repository: plasma-desktop Description --- Save the default file manager (inode/directory) by writing into the group [Default Applications] in the file mimeapps.list, as per the mime-apps spec 1.0.1 . http://standards.freedesktop.org/mime-apps-spec/mime-apps-spec-1.0.1.html#default keditfiletype (kde-cli-tools) already saves the default application for a given mimetype (including inode/directory for file manager) in [Default Applications] since http://quickgit.kde.org/?p=kde-cli-tools.gita=commith=32bf8f704f174f2652aadf442b07fb10c597a327 regards, Luc Menut - Mageia PS: I don't have write access to kde git, so could you commit the change if the patch looks fine. Thanks. Diffs - kcms/componentchooser/componentchooserfilemanager.cpp b23bfa0 Diff: https://git.reviewboard.kde.org/r/120565/diff/ Testing --- Thanks, Luc Menut ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 120276: Initial port to frameworks for the comic dataengine.
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/120276/#review68304 --- dataengines/comic/CMakeLists.txt https://git.reviewboard.kde.org/r/120276/#comment47615 Is the KDELibs4Support needed only because of the KStandardDirs? If yes, then let's port away from that as well, it's easy enough dataengines/comic/CMakeLists.txt https://git.reviewboard.kde.org/r/120276/#comment47606 These two could be merged into one dataengines/comic/comic_package.cpp https://git.reviewboard.kde.org/r/120276/#comment47609 These should use the brackets dataengines/comic/comic_package_plugin.cpp https://git.reviewboard.kde.org/r/120276/#comment47607 I think this should just go into comic_package.cpp to follow all the other exports, then this file can be removed dataengines/comic/comicproviderkross.cpp https://git.reviewboard.kde.org/r/120276/#comment47611 This should use the brackets dataengines/comic/comicproviderkross.cpp https://git.reviewboard.kde.org/r/120276/#comment47610 Remove if not needed dataengines/comic/comicproviderwrapper.cpp https://git.reviewboard.kde.org/r/120276/#comment47612 The coding style is no spaces inside ()s (I know it's not your code, but since you're touching it already, let's fix it) Also, do we need all this kind of information actually printed in the log? dataengines/comic/comicproviderwrapper.cpp https://git.reviewboard.kde.org/r/120276/#comment47613 No spaces in ()s dataengines/comic/comicproviderwrapper.cpp https://git.reviewboard.kde.org/r/120276/#comment47614 No spaces in ()s - Martin Klapetek On Oct. 12, 2014, 6:06 p.m., Andrei Amuraritei wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/120276/ --- (Updated Oct. 12, 2014, 6:06 p.m.) Review request for Plasma, David Edmundson, Marco Martin, and Sebastian Kügler. Repository: kdeplasma-addons Description --- comic DataEngine initial port to frameworks. Diffs - dataengines/comic/comicproviderkross.h 46a9072 dataengines/comic/comicproviderkross.cpp 9820f05 dataengines/comic/comicproviderwrapper.h 81eee68 dataengines/CMakeLists.txt 04c7985 dataengines/comic/CMakeLists.txt 8e382e6 dataengines/comic/cachedprovider.h baac8a9 dataengines/comic/cachedprovider.cpp caca25e dataengines/comic/comic.h 8cc3969 dataengines/comic/comic.cpp 7130f44 dataengines/comic/comic_package.h 32be381 dataengines/comic/comic_package.cpp 6d2ff0b dataengines/comic/comic_package_plugin.cpp d997947 dataengines/comic/comicprovider.h 630ee8d dataengines/comic/comicprovider.cpp ab248a5 dataengines/comic/comicproviderwrapper.cpp 48ced42 Diff: https://git.reviewboard.kde.org/r/120276/diff/ Testing --- Building from source, compiles 100%, some deprecated warnings. DataEngine shows up in plasmaengineexplorer and detects installed .comic packages. This is the initial port, still need to review code to fix issues like whitespaces around ( or the deprecated parts. Thanks notmart, d_ed, sebas, bshas etc for helping. Thanks, Andrei Amuraritei ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
[Powerdevil] [Bug 339391] system hangs during suspend-to-ram (must poweroff), while pm-suspend works.
https://bugs.kde.org/show_bug.cgi?id=339391 Vincent Petry pvinc...@yahoo.fr changed: What|Removed |Added CC||pvinc...@yahoo.fr --- Comment #2 from Vincent Petry pvinc...@yahoo.fr --- I know this is not related to KDE but wanted to point out that I randomly got the same issue, also on a Dell XPS 13. Using openSUSE Factory with kernel 3.16.4-1.g7a8842b-desktop. I also have no swap space set. I've enabled it now and we'll see whether it solves the issue in the long run. Roberto, did you report this issue in other places ? Kernel bug ? -- You are receiving this mail because: You are the assignee for the bug. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
[Powerdevil] [Bug 339391] system hangs during suspend-to-ram (must poweroff), while pm-suspend works.
https://bugs.kde.org/show_bug.cgi?id=339391 --- Comment #3 from Vincent Petry pvinc...@yahoo.fr --- This is with KDE 4.14.1-1.2.x86_64. Note that before switching to openSUSE Factory I used openSUSE 13.1 and it worked correctly there, so possibly a regression. -- You are receiving this mail because: You are the assignee for the bug. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
[Powerdevil] [Bug 339391] system hangs during suspend-to-ram (must poweroff), while pm-suspend works.
https://bugs.kde.org/show_bug.cgi?id=339391 --- Comment #4 from Roberto figj...@libero.it --- Hi Vincent, I have not reported anywhere, because I was thinking about an hardware problem. It is unlikely that linux cannot shutdown a system... What do you think? -- You are receiving this mail because: You are the assignee for the bug. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
[Powerdevil] [Bug 339391] system hangs during suspend-to-ram (must poweroff), while pm-suspend works.
https://bugs.kde.org/show_bug.cgi?id=339391 --- Comment #5 from Vincent Petry pvinc...@yahoo.fr --- I'm not sure. We'd need to find how powerdevil is doing the suspending. You said that pm-suspend always work ? I haven't tried it yet but will later. If pm-suspend works and not powerdevil we need to look at what happens in between, maybe find related logs which could contain clues. -- You are receiving this mail because: You are the assignee for the bug. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
[Powerdevil] [Bug 339391] system hangs during suspend-to-ram (must poweroff), while pm-suspend works.
https://bugs.kde.org/show_bug.cgi?id=339391 --- Comment #6 from Roberto figj...@libero.it --- In my case also pm-suspend doesn't work, see Comment #1 above. In fact, I think powerdevil calls pm-suspend via dbus, so it's the same. I've noticed that standby and shutdown work if the system is just powered on, while if you wait some time (half an hour or something like this) then they no longer work. -- You are receiving this mail because: You are the assignee for the bug. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
[Powerdevil] [Bug 339391] system hangs during suspend-to-ram (must poweroff), while pm-suspend works.
https://bugs.kde.org/show_bug.cgi?id=339391 Lukáš Tinkl lu...@kde.org changed: What|Removed |Added Resolution|FIXED |--- Status|RESOLVED|REOPENED Ever confirmed|0 |1 --- Comment #7 from Lukáš Tinkl lu...@kde.org --- PowerDevil uses systemd's login1 interface, so if pm-suspend (which is something different) works, then systemd is to blame. If neither pm-suspend works, it must be a kernel or even HW issue. -- You are receiving this mail because: You are the assignee for the bug. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Plasma 5.1 Changes
Hi, For the release notes, I've extracted the new and improved stuff in 5.1 from the mailinglist, please have a look at https://community.kde.org/Plasma/5.1_Changes and add what you think is missing. Thanks, -- sebas http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9 ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
wallpapers on lock screen
Hi all, this is already 5.2 stuff, but just to discuss. we still have one burned-in fixed wallpaper for the lock screen, so at this point it should get a bit of attention. one thing i'm not sure to do if i want to have again the possibility to put widgets in the lock screen as it was in kde4. there may be interests on it, but on the other hand i am not seeing much complaints that at the moment is missing. on either case, should be very easy to recycle the complete wallpaper mechanism of plasmashell, even the qml only wallpapers (that if animated.. yay, screensavers!) just to see what path to take do design and implement correctly, if just boring wallpapers or full widgets. -- Marco Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
[Powerdevil] [Bug 339391] system hangs during suspend-to-ram (must poweroff), while pm-suspend works.
https://bugs.kde.org/show_bug.cgi?id=339391 --- Comment #8 from Roberto figj...@libero.it --- Vincent, could you please test pm-suspend? -- You are receiving this mail because: You are the assignee for the bug. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: wallpapers on lock screen
I think by default it should use the (current visible) desktop wallpaper in the lockscreen. Then there could be two options - select custom wallpaper or use the current but blurred (Harald has PoC of this and imo it's really cool). Cheers -- Martin Klapetek | KDE Developer ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: wallpapers on lock screen
On Monday 13 October 2014, Martin Klapetek wrote: I think by default it should use the (current visible) desktop wallpaper in the lockscreen. Then there could be two options - select custom wallpaper or use the current but blurred (Harald has PoC of this and imo it's really cool). working code, something usable or just hardcoded? -- Marco Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: wallpapers on lock screen
On 13.10.2014 16:44, Martin Klapetek wrote: I think by default it should use the (current visible) desktop wallpaper in the lockscreen. I think that's a bad default for security/privacy reasons. The purpose of the lock screen is to avoid exposing system state while the system is unattended; customization is system state, and moreover custom wallpapers are even user data. The lock screen should be generic and not pick up any user settings by default for that reason (except those needed to interact with the lock screen itself, e.g. the keyboard layout). This is before we get into the fact that Plasma wallpapers are technically code plugins and can be dynamic and even interactive - *actually* picking up the current wallpaper would require kwin participation o composite correctly, or running a second instance of the plugin, and then you run into the difficulty of syncing config and/or state correctly anyway. Just supporting images would be an incomplete hack. Still, adding the functionality to pick up the current or a custom wallpaper is fine if done correctly, of course, but not as a default IMHO. Cheers -- Martin Klapetek | KDE Developer Cheers, Eike ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
[Powerdevil] [Bug 339391] system hangs during suspend-to-ram (must poweroff), while pm-suspend works.
https://bugs.kde.org/show_bug.cgi?id=339391 Christoph Feck christ...@maxiom.de changed: What|Removed |Added See Also||https://bugs.kde.org/show_b ||ug.cgi?id=339911 -- You are receiving this mail because: You are the assignee for the bug. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: wallpapers on lock screen
On Monday 13 October 2014, Eike Hein wrote: Still, adding the functionality to pick up the current or a custom wallpaper is fine if done correctly, of course, but not as a default IMHO. instead of some automagic and default i was more thinking about some option in the ordinary wallpaper settings use this in the lockscreen maybe unchecked by default -- Marco Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: wallpapers on lock screen
On Mon, Oct 13, 2014 at 4:09 PM, Marco Martin notm...@gmail.com wrote: Hi all, this is already 5.2 stuff, but just to discuss. we still have one burned-in fixed wallpaper for the lock screen, so at this point it should get a bit of attention. one thing i'm not sure to do if i want to have again the possibility to put widgets in the lock screen as it was in kde4. there may be interests on it, but on the other hand i am not seeing much complaints that at the moment is missing. on either case, should be very easy to recycle the complete wallpaper mechanism of plasmashell, even the qml only wallpapers (that if animated.. yay, screensavers!) just to see what path to take do design and implement correctly, if just boring wallpapers or full widgets. To be honest, I like it best if the designers (that is, the lookandfeel package creators) get to design the whole thing, because the look is part of the lookandfeel. I understand that some people really like that idea though, I think the best would be to have some kind of checkbox in the wallpaper chosing dialog or lockscreen kcm that says use wallpaper for the lockscreen but I'm still afraid that this will complicate the code, given that it will require moving wallpaper-rendering code over to the lf theme. Aleix ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: wallpapers on lock screen
On Monday 13 October 2014, Aleix Pol wrote: I understand that some people really like that idea though, I think the best would be to have some kind of checkbox in the wallpaper chosing dialog or lockscreen kcm that says use wallpaper for the lockscreen but I'm still afraid that this will complicate the code, given that it will require moving wallpaper-rendering code over to the lf theme. not really, just the lockscreen view would load the qml files used for system wallpapers now, and then they should just automagically work by default would just be the image wallpaper that by default uses the image specified in the plasma theme, so would still be lf package dependent -- Marco Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: wallpapers on lock screen
On 13.10.2014 17:19, Marco Martin wrote: not really, just the lockscreen view would load the qml files used for system wallpapers now, and then they should just automagically work by default would just be the image wallpaper that by default uses the image specified in the plasma theme, so would still be lf package dependent And what if the user uses a slide show with a couple of custom pictures? You'd need to both sync that config *and* what image it's currently on, if the idea here is a smooth visual transi- tion without perceived glitches. And if not ... why add a hack that only works in a constrained scenario instead of across the customization options we actually have? Cheers, Eike ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Re: wallpapers on lock screen
On Monday 13 October 2014 16:44:30 Martin Klapetek wrote: I think by default it should use the (current visible) desktop wallpaper in the lockscreen. for privacy reasons the current configured wallpaper should not be used in the lock screen (or splash screen or whatever). Having a checkbox also use on lock screen sounds like a good solution, though. Cheers Martin signature.asc Description: This is a digitally signed message part. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: wallpapers on lock screen
On Mon, Oct 13, 2014 at 5:11 PM, Marco Martin notm...@gmail.com wrote: On Monday 13 October 2014, Eike Hein wrote: Still, adding the functionality to pick up the current or a custom wallpaper is fine if done correctly, of course, but not as a default IMHO. instead of some automagic and default i was more thinking about some option in the ordinary wallpaper settings use this in the lockscreen maybe unchecked by default +1 Aleix ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: wallpapers on lock screen
On Monday 13 October 2014, Eike Hein wrote: On 13.10.2014 17:19, Marco Martin wrote: not really, just the lockscreen view would load the qml files used for system wallpapers now, and then they should just automagically work by default would just be the image wallpaper that by default uses the image specified in the plasma theme, so would still be lf package dependent And what if the user uses a slide show with a couple of custom pictures? You'd need to both sync that config *and* what image it's currently on, if the idea here is a smooth visual transi- tion without perceived glitches. yes, in the case of slideshow or other weird custom animated backgrounds can still somewhat be synced, but only so far -- Marco Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: wallpapers on lock screen
On 13.10.2014 17:23, Marco Martin wrote: yes, in the case of slideshow or other weird custom animated backgrounds can still somewhat be synced, but only so far An implementation alternative would be what Mac OS X does, maybe: OS X used to have a lock screen with a generic wallpaper, but as of Mountain Lion it uses whatever was on the background at the time the screen gets locked. On Qt 5.4 we could: - Dump whatever the QQuickItem containing the wallpaper currently shows into a temp file (there's convenient API now for dumping QQuickItems into offscreen buffers). - Use it in the lockscreen if the option is enabled. That would bypass the syncing problem entirely and simply give us a static shot of the background at lock time. Props for somehow suspending and resuming dynamic wallpapers like the slide show while locked, if the plugin API allows for that, so there's no sync problem on unlock, too. Cheers, Eike ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: wallpapers on lock screen
On Monday 13 October 2014, Eike Hein wrote: On 13.10.2014 17:23, Marco Martin wrote: yes, in the case of slideshow or other weird custom animated backgrounds can still somewhat be synced, but only so far An implementation alternative would be what Mac OS X does, maybe: OS X used to have a lock screen with a generic wallpaper, but as of Mountain Lion it uses whatever was on the background at the time the screen gets locked. does it always show just that? is it configurable? -- Marco Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: wallpapers on lock screen
On 13.10.2014 17:36, Marco Martin wrote: On Monday 13 October 2014, Eike Hein wrote: On 13.10.2014 17:23, Marco Martin wrote: yes, in the case of slideshow or other weird custom animated backgrounds can still somewhat be synced, but only so far An implementation alternative would be what Mac OS X does, maybe: OS X used to have a lock screen with a generic wallpaper, but as of Mountain Lion it uses whatever was on the background at the time the screen gets locked. does it always show just that? is it configurable? It's not easily configurable, but it seems third-party apps exist for it: http://superuser.com/questions/571464/how-do-i-change-the-lock-screen-image-on-os-x Cheers, Eike ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: wallpapers on lock screen
Hi, apparently OSX 10.8 Mountain Lion uses the current user's wallpaper, dimmed, whereas 10.9 Mavericks uses a generic gray background with Apple logo (with no way of changing that - apart from replacing a couple of system files) Cheers ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Re: wallpapers on lock screen
On Monday 13 October 2014 17:29:55 Eike Hein wrote: On 13.10.2014 17:23, Marco Martin wrote: yes, in the case of slideshow or other weird custom animated backgrounds can still somewhat be synced, but only so far An implementation alternative would be what Mac OS X does, maybe: OS X used to have a lock screen with a generic wallpaper, but as of Mountain Lion it uses whatever was on the background at the time the screen gets locked. On Qt 5.4 we could: - Dump whatever the QQuickItem containing the wallpaper currently shows into a temp file (there's convenient API now for dumping QQuickItems into offscreen buffers). - Use it in the lockscreen if the option is enabled. That would bypass the syncing problem entirely and simply give us a static shot of the background at lock time. please keep in mind that screens might get added while the screen is locked. Cheers Martin signature.asc Description: This is a digitally signed message part. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: wallpapers on lock screen
Sry for a late reply (sick and been sleeping) but the one Harald Sitter and I fiddled with during Akademy was kinda nice where it used a blurred version of your wallpaper. 1) It didn't reveal the nature of your wallpaper (we tested, extensively) 2) It creates the sensation of fading to desktop when unlocked. If it IS somehow a security issue I don't know but it was way cooler than having a random wallpaper set by default which made the login process from a lock screen feel jerky and out of phase. On Monday 13 October 2014 17.11.20 Marco Martin wrote: On Monday 13 October 2014, Eike Hein wrote: Still, adding the functionality to pick up the current or a custom wallpaper is fine if done correctly, of course, but not as a default IMHO. instead of some automagic and default i was more thinking about some option in the ordinary wallpaper settings use this in the lockscreen maybe unchecked by default ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: wallpapers on lock screen
On Mon, Oct 13, 2014 at 6:06 PM, Jens Reuterberg j...@ohyran.se wrote: 1) It didn't reveal the nature of your wallpaper (we tested, extensively) knock yourselves out guessing :P http://imgur.com/a/1bHH5 HS ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: wallpapers on lock screen
On 13.10.2014 17:48, Martin Gräßlin wrote: please keep in mind that screens might get added while the screen is locked. Right, so plasmashell would have to initialize it, dump the wallpaper and get it to the lockscreen. Cheers Martin Cheers, Eike ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
The usage statistics [kactivities, baloo, ktp, plasma]
Hi all,
As promised, starting a discussion on how we can use the usage statistics
gathered by kactivitymanagerd (kamd in the rest of the text). And the design
of the API to cover the use-cases.
The point is to discuss all of this and put the summaries on the etherpad page
at https://notes.kde.org/p/KActivities_Usage_Statistics
1. Use-cases
=
The main ideas I had while developing Lancelot (some overlap with those that
Eike and David have):
- Automatically deduced favourite applications for the users that didn't set
them up (not important whether they actually end up in the favourites section,
or are used just for sorting in krunner or something).
- The same as the above, but for documents (per-application, and global) or
contacts or ...
- Replacing the 'recent documents' with something more meaningful (kinda a
subset of the previous item)
- Tasks applet and launchers could show the list of important (or recent)
documents opened in a specific application.
- ** more advanced ** Deducing which things belong to each other based on the
fact they have been often used together and similar.
2. What is currently there
=
(mostly copied from the mail I sent Eike some time ago)
- It supports tracking for open/close, focus-in/out, modified and accessed
events (from the API side, handled by KActivities::ResourceInstance class in a
pretty RAII manner :) )
- Every event has the activity in which it occurred (usedActivity field),
application that triggered the event (initiatingAgent) and the timestamps (and
the URL of the thing - targettedResource - a document, a contact, ...). The
names are a bit cumbersome, they are taken from the ontology that was designed
for this purpose. You can write Agent, Activity, Resource for the sake of
brevity.
- Apart from that, it also keeps the scores for the things.
Vishesh asked for the formula for the scoring - see appendix 1.
Applications that supported this in 4.x were (I'm probably missing a few):
Dolphin, Gwenview, Calligra (modulo Kexi), Okular, Kate, KWrite and Vim in
konsole. I have no idea whether the patches remained in Qt5 ports.
3. What will be needed
Integration with baloo. It will require patches on both sides if we are to
support all the use-cases without cross-queries. We will need accessible file
types via sqlite (on baloo side) and baloo identifiers or something on kamd
side.
One of the things that I think will be needed is some kind of additional
payload that the applications will be able to store alongside the resource
event. We'll see after we collect the use-cases.
4. Reading API
===
This needs to be designed. I would not be surprised if the API ends up being
similar to baloo's querying system since it seems we will have quite a diverse
set of use-cases. Although, it should provide a proper live data model for the
results.
Appendix 1: Formula for the resource scoring:
===
LaTeX formatted:
S = \sum _{i = 1} ^ n
e^{-d_i} e^{k_i \log(l_i)}
Haskell-like formatted, whichever you find easier to read :)
sum [
exp (-di) * exp ( ki * log li ) | i - [1..n]
]
where d_i is the time that passed since the i-th event, k_i coefficient
depending on the type of the event, l_i length of the event (time distance
between open and close for example, or focus in and out)
It can be rewritten to look prettier (exp log = id and so on), but this
conveys the meaning in a nicer way by separating the terms according to their
meaning.
The main ideas behind the formula are:
- score degrades with the time, so if a document was kept open in okular for
an hour yesterday, it will have a significantly higher score than a document
that was kept open for a whole day a year ago;
- different events have different meanings;
- event time interval is measured on a logarithmic scale, so that there is a
greater difference between 1hr and 2hrs, than between 11hrs and 12hrs;
- can be calculated quickly by only processing new events since the last
score update.
--
Cheerio,
Ivan
KDE, ivan.cukic at kde.org, http://ivan.fomentgroup.org/
gpg key id: 850B6F76, keyserver.pgp.com
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel
[Powerdevil] [Bug 339391] system hangs during suspend-to-ram (must poweroff), while pm-suspend works.
https://bugs.kde.org/show_bug.cgi?id=339391 --- Comment #9 from Vincent Petry pvinc...@yahoo.fr --- The version on which it worked was openSUSE 13.1 x86_64 with KDE 4-4.11.5 and kernel 3.11.10-21-desktop. And it's now broken on openSUSE Factory x86_64 with KDE 4.14.1-1.2 and kernel 3.16.4-1.g7a8842b-desktop I'll do some tests and post results. -- You are receiving this mail because: You are the assignee for the bug. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 120550: Use the same strategy as FrameSvgItem and IconItem in QIconItem
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/120550/ --- (Updated Oct. 13, 2014, 5:54 p.m.) Review request for KDE Frameworks, Plasma, David Edmundson, and Marco Martin. Repository: kdeclarative Description --- Moves the caching types used in Plasma Workspace into a QuickAddons submodule. Adopts them in QIconItem by moving it from a QPainterItem to a QQuickPainter item. Uses the same strategies used in Plasma Framework for caching the textures. Diffs - src/qmlcontrols/kquickcontrolsaddons/CMakeLists.txt 2977812 src/qmlcontrols/kquickcontrolsaddons/qiconitem.h 839a33f src/qmlcontrols/kquickcontrolsaddons/qiconitem.cpp 0eb46b1 src/quickaddons/CMakeLists.txt PRE-CREATION src/quickaddons/imagetexturescache.h PRE-CREATION src/quickaddons/imagetexturescache.cpp PRE-CREATION src/quickaddons/managedtexturenode.h PRE-CREATION src/quickaddons/managedtexturenode.cpp PRE-CREATION tests/qiconitem_test.qml PRE-CREATION src/CMakeLists.txt eb0dfd3 Diff: https://git.reviewboard.kde.org/r/120550/diff/ Testing --- I added some manual test (that was impossible to run before the patch). Also tested it in KRunner and Muon Discover, which use the component. Everything still works. Thanks, Aleix Pol Gonzalez ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
[Powerdevil] [Bug 339391] system hangs during suspend-to-ram (must poweroff), while pm-suspend works.
https://bugs.kde.org/show_bug.cgi?id=339391 --- Comment #10 from Vincent Petry pvinc...@yahoo.fr --- Created attachment 89117 -- https://bugs.kde.org/attachment.cgi?id=89117action=edit Successful pm-suspend log Tried pm-suspend three times and it worked fine. See attached log. Next up: make it crash then get the log. -- You are receiving this mail because: You are the assignee for the bug. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
[Powerdevil] [Bug 339391] system hangs during suspend-to-ram (must poweroff), while pm-suspend works.
https://bugs.kde.org/show_bug.cgi?id=339391 --- Comment #11 from Vincent Petry pvinc...@yahoo.fr --- Hmmm... suspend to ram worked now from KDE. Here is the list of programs I have opened, for reference: - kopete: disconnected - wifi - owncloud sync client - kmail - konsole And in case it matters, I have the vboxdrv module loaded at all times. Also note: I have enabled the swap partition, but it didn't prevent it to crash. My filesystem is btrfs. -- You are receiving this mail because: You are the assignee for the bug. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
[Powerdevil] [Bug 339391] system hangs during suspend-to-ram (must poweroff), while pm-suspend works.
https://bugs.kde.org/show_bug.cgi?id=339391 --- Comment #12 from Roberto figj...@libero.it --- Vincent: let the PC with power on for one hour or more, and then try pm-suspend -- You are receiving this mail because: You are the assignee for the bug. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
[Powerdevil] [Bug 339391] system hangs during suspend-to-ram (must poweroff), while pm-suspend works.
https://bugs.kde.org/show_bug.cgi?id=339391 --- Comment #13 from Vincent Petry pvinc...@yahoo.fr --- I've now started the following: - skype - kopete: connected - apache 2 - mysql - thunderbird Talk about murphy's law or heisenbug... suspend to ram now still works properly. I'm pretty sure it will hang again when I least expect it. Roberto, if you managed to hang it again, can you post pm-suspend.log ? I'll do the same as soon as I can reproduce the issue again, as you say maybe it will happen after a few hours. You mentioned that in your case pm-suspend also crashed once, so it is likely that the problem is on the kernel side. Please let me know whether you also had some of the apps I mentioned above loaded (including vboxdrv), in case it's all related. -- You are receiving this mail because: You are the assignee for the bug. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 120550: Use the same strategy as FrameSvgItem and IconItem in QIconItem
On Oct. 13, 2014, 1:35 p.m., Marco Martin wrote: src/quickaddons/managedtexturenode.h, line 52 https://git.reviewboard.kde.org/r/120550/diff/2/?file=318205#file318205line52 even if will always remain just this member, just to me sure, it should be in a dpointer Aleix Pol Gonzalez wrote: I don't think it's a good idea to add a d-pointer there. It's a class to encapsulate the object, I don't see why we should store more things in there. If needs changed, then I'd suggest to create another class. if it's exported, i prefer a dpointer anyways - Marco --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/120550/#review68307 --- On Oct. 13, 2014, 5:54 p.m., Aleix Pol Gonzalez wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/120550/ --- (Updated Oct. 13, 2014, 5:54 p.m.) Review request for KDE Frameworks, Plasma, David Edmundson, and Marco Martin. Repository: kdeclarative Description --- Moves the caching types used in Plasma Workspace into a QuickAddons submodule. Adopts them in QIconItem by moving it from a QPainterItem to a QQuickPainter item. Uses the same strategies used in Plasma Framework for caching the textures. Diffs - src/qmlcontrols/kquickcontrolsaddons/CMakeLists.txt 2977812 src/qmlcontrols/kquickcontrolsaddons/qiconitem.h 839a33f src/qmlcontrols/kquickcontrolsaddons/qiconitem.cpp 0eb46b1 src/quickaddons/CMakeLists.txt PRE-CREATION src/quickaddons/imagetexturescache.h PRE-CREATION src/quickaddons/imagetexturescache.cpp PRE-CREATION src/quickaddons/managedtexturenode.h PRE-CREATION src/quickaddons/managedtexturenode.cpp PRE-CREATION tests/qiconitem_test.qml PRE-CREATION src/CMakeLists.txt eb0dfd3 Diff: https://git.reviewboard.kde.org/r/120550/diff/ Testing --- I added some manual test (that was impossible to run before the patch). Also tested it in KRunner and Muon Discover, which use the component. Everything still works. Thanks, Aleix Pol Gonzalez ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Plasma 5.1.0
El Dilluns, 13 d'octubre de 2014, a les 11:01:49, Sebastian Kügler va escriure: On Thursday, October 09, 2014 21:36:58 Albert Astals Cid wrote: El Dijous, 9 d'octubre de 2014, a les 14:26:48, Jonathan Riddell va escriure: Plasma 5.1.0 tars up now at http://starsky.19inch.net/~jr/tmp/plasma-5.1.0/ and coming soon to depot sha256 sums at https://www.kde.org/info/source-plasma-5.1.0.inc Release due on Tuesday. 4.14.2 release is also on Tueday, maybe i should move it to wednesday? I think that would make sense. I'm prepping the Plasma 5.1.0 release notes now. If need be, we can also push that one one day forward. Ok, let's move 4.14.2 to wednesday then. Cheers, Albert Cheers, ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
[Powerdevil] [Bug 339391] system hangs during suspend-to-ram (must poweroff), while pm-suspend works.
https://bugs.kde.org/show_bug.cgi?id=339391 --- Comment #14 from Roberto figj...@libero.it --- In my case the pm-suspend log is the same when it works and when it doesn't: pm-suspend always finishes the procedure without errors or crashes, but sometimes at the end the system hangs instead of actually suspend (or shutdown). -- You are receiving this mail because: You are the assignee for the bug. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
[Powerdevil] [Bug 339391] system hangs during suspend-to-ram (must poweroff), while pm-suspend works.
https://bugs.kde.org/show_bug.cgi?id=339391 --- Comment #15 from Vincent Petry pvinc...@yahoo.fr --- Good to know. I have now set pm_trace to 1 to hopefully capture more info from the next crash, if it happens. See https://wiki.ubuntu.com/DebuggingKernelSuspend -- You are receiving this mail because: You are the assignee for the bug. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: 5.1 Errata
Can anyone confirm that this bug exists in 5.1? I don't think the fix made it in time, but I wanted to check before adding it to the errata. https://bugs.kde.org/show_bug.cgi?id=339849 Thanks much, Andrew On Mon, Oct 13, 2014 at 3:54 AM, Jonathan Riddell j...@jriddell.org wrote: As discussed at hangout, if you know of bugs which users should be aware of please add them to https://community.kde.org/Plasma/5.1_Errata Jonathan ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: wallpapers on lock screen
On 13.10.2014 17:21, Martin Gräßlin wrote: On Monday 13 October 2014 16:44:30 Martin Klapetek wrote: I think by default it should use the (current visible) desktop wallpaper in the lockscreen. for privacy reasons the current configured wallpaper should not be used in the lock screen (or splash screen or whatever). Having a checkbox also use on lock screen sounds like a good solution, though. What happens if this is unchecked? Greetings, Clemens. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Fwd: Plasma Framework problems
On Monday 13 of October 2014 13:07:35 Marco Martin wrote: On Sunday 12 October 2014, David Edmundson wrote: On 12 Oct 2014 18:04, šumski hrvoje.sen...@gmail.com wrote: On Sunday 12 of October 2014 11:58:44 David Edmundson wrote: I'll report back when I've confirmed this and then we can work out how we proceed. Reverting a3932843386a29faa3c62bf2934a173a3781d56c does indeed make everything work. Assuming we don't have a time machine our options are: - revert this commit and release plasma-framework 5.3.1 really quickly Please go with this option... I need approval from Marco and other David. after a quick chat with David E this morning, I would revert that patch (and then remove the plugin in plasma-workspace master) *but* this only if there will be a 5.3.1 (there should be a fix in kwindowsystem as well as far i understood, so would be good a 5.3.1 release with both fixes) this sounds like a good plan (though i don't know if reverting in plasma- workspace is needed, and why only master, 5.1.0 is not out yet) though kwindowsystem is uploaded 2 days ago to 5.3.0 dir Cheers, Hrvoje 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: wallpapers on lock screen
On 13.10.2014 17:21, Eike Hein wrote: On 13.10.2014 17:19, Marco Martin wrote: not really, just the lockscreen view would load the qml files used for system wallpapers now, and then they should just automagically work by default would just be the image wallpaper that by default uses the image specified in the plasma theme, so would still be lf package dependent And what if the user uses a slide show with a couple of custom pictures? You'd need to both sync that config *and* what image it's currently on, if the idea here is a smooth visual transi- tion without perceived glitches. And if not ... why add a hack that only works in a constrained scenario instead of across the customization options we actually have? Why not simply have the checkbox use default wallpaper in the lockscreen kcm? Unchecked, it would allow for picking a background yourself. Greetings, Clemens. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: wallpapers on lock screen
On 13.10.2014 22:50, ctoenn...@interstel.de wrote: Why not simply have the checkbox use default wallpaper in the lockscreen kcm? Unchecked, it would allow for picking a background yourself. I think we're kind of, of sort of discussing three different things at the same time: a) The ability to have the user's current desktop background in the lock screen. Notes on that: - If it's supposed to be generic (i.e. works with all wallpaper type plugins), it's difficult to establish sync. - Dumping the actually rendered wallpaper into a file and showing it in the lock screen could be one way to go, but hard because of display hotplug. - Dumping also means no animated wallpapers on the lock screen. - If instead we only want to support it for Image wallpapers, the config logically has to be part of that plugin, otherwise things get messy (e.g. if the option to use the wallpaper is in the lock screen config, it makes no sense if the wallpaper plugin isn't Image - so you'd have to read configs across products to make it conditional, and the user would have low insight into what's going on). b) Whether doing 'a' *by default* is a good idea or not. Notes on that: - Thumbs down from me for the privacy/securty angle. - Blurring the wallpaper heavily mitigates this to some degree. It still makes my spider sense tingle, but I could maybe sleep at night. :P c) The option to set a custom wallpaper for the lock screen. This is in some sense entirely independent of the above. I think we want to allow this in principle; the difficulty is in UI design - if 'a' requires us to stick a Also use on lock screen into the Image plugin's wallpaper config it fighrs with a wallpaper picker in the Lock Screen KCM, and there's also the issue of having the former in the wall- paper config in cases where the lock screen design from the look and feel package doesn't care about backgrounds. Further, wallpapers are per-activity, ... This is one of these situations where suporting all the different features we have in concert ends up being diffi- cult. There's some radical solutions: - Give up on 'a' and 'b' entirely and just do 'c'. - Throw out all wallpaper plugins except Image. This is why $competitor sometimes gets blamed for having too few features, but has few features for a reason - it's easy to lock yourself into sudoku puzzles with many features. Greetings, Clemens. Cheers, Eike ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: wallpapers on lock screen
On Mon, Oct 13, 2014 at 4:09 PM, Marco Martin notm...@gmail.com wrote: Hi all, this is already 5.2 stuff, but just to discuss. we still have one burned-in fixed wallpaper for the lock screen, so at this point it should get a bit of attention. one thing i'm not sure to do if i want to have again the possibility to put widgets in the lock screen as it was in kde4. there may be interests on it, but on the other hand i am not seeing much complaints that at the moment is missing. Personally I think what the VDG designed ends up looking a lot better than letting users drag some clocks and some post-it notes across the desktop. Changing what is shown is currently is do-able with look and feel packages, I don't think we need to create a second implementation in addition to that. on either case, should be very easy to recycle the complete wallpaper mechanism of plasmashell, even the qml only wallpapers (that if animated.. yay, screensavers!) I'd quite like to use the wallpaper plugins from SDDM too; which means exposing WallpaperInterface in a slightly different manner than you'd probably be wanting to use for the lock screen, as I can't go via a Containment. just to see what path to take do design and implement correctly, if just boring wallpapers or full widgets. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 120550: Use the same strategy as FrameSvgItem and IconItem in QIconItem
On Oct. 13, 2014, 1:35 p.m., Marco Martin wrote: src/quickaddons/managedtexturenode.h, line 52 https://git.reviewboard.kde.org/r/120550/diff/2/?file=318205#file318205line52 even if will always remain just this member, just to me sure, it should be in a dpointer Aleix Pol Gonzalez wrote: I don't think it's a good idea to add a d-pointer there. It's a class to encapsulate the object, I don't see why we should store more things in there. If needs changed, then I'd suggest to create another class. Marco Martin wrote: if it's exported, i prefer a dpointer anyways Can we please discuss this? I really don't think we want to be so cheap when it comes to memory usage. This means that each node in the scene will take a payload for no much reason. - Aleix --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/120550/#review68307 --- On Oct. 13, 2014, 5:54 p.m., Aleix Pol Gonzalez wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/120550/ --- (Updated Oct. 13, 2014, 5:54 p.m.) Review request for KDE Frameworks, Plasma, David Edmundson, and Marco Martin. Repository: kdeclarative Description --- Moves the caching types used in Plasma Workspace into a QuickAddons submodule. Adopts them in QIconItem by moving it from a QPainterItem to a QQuickPainter item. Uses the same strategies used in Plasma Framework for caching the textures. Diffs - src/qmlcontrols/kquickcontrolsaddons/CMakeLists.txt 2977812 src/qmlcontrols/kquickcontrolsaddons/qiconitem.h 839a33f src/qmlcontrols/kquickcontrolsaddons/qiconitem.cpp 0eb46b1 src/quickaddons/CMakeLists.txt PRE-CREATION src/quickaddons/imagetexturescache.h PRE-CREATION src/quickaddons/imagetexturescache.cpp PRE-CREATION src/quickaddons/managedtexturenode.h PRE-CREATION src/quickaddons/managedtexturenode.cpp PRE-CREATION tests/qiconitem_test.qml PRE-CREATION src/CMakeLists.txt eb0dfd3 Diff: https://git.reviewboard.kde.org/r/120550/diff/ Testing --- I added some manual test (that was impossible to run before the patch). Also tested it in KRunner and Muon Discover, which use the component. Everything still works. Thanks, Aleix Pol Gonzalez ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 120471: Add Registry::sync() signal
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/120471/ --- (Updated Oct. 14, 2014, 2:17 a.m.) Review request for kwin, Plasma and Martin Gräßlin. Changes --- * Use WaylandPointer to store and manage lifecycle of wl_callback * If a callback is underway, also add it to the proper queue in setEventQueue() * Clean up the test's object lifecycle so it doesn't get in the way of following tests I'm getting a spurious failure in testWaylandOutput when run from make test, but never when running the test binary individually, I don't know if this is related. WaylandPointer is a nice and handy tool. Repository: kwayland Description --- Add Registry::sync() signal Emitted when the Wayland display is done flushing the initial interface callbacks, announcing wl_display properties. This can be used to compress events. Note that this signal is emitted only after announcing interfaces, such as outputs, but not after receiving callbacks of interface properties, such as the output's geometry, modes, etc.. This signal is emitted from the wl_display_sync callback. For this, we add a wl_callback_listener to the registry's Private, enqueue its events properly, if necessary, and trigger the signal through a callback mechanism similar to the wl_registry callbacks. This signal allows users of the API to find out when the signal emissions, such as outputAnnounced, etc. for all currently existing interfaces is complete. Diffs (updated) - autotests/client/test_wayland_registry.cpp 571be0f src/client/registry.h 9e63a2b src/client/registry.cpp 207cdef Diff: https://git.reviewboard.kde.org/r/120471/diff/ Testing --- tests in libkscreen exercise this feature, it works as expected, meaning I can notify when all initial synchronization is done. Thanks, Sebastian Kügler ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 120471: Add Registry::sync() signal
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/120471/#review68340 --- Ship it! looks good - Martin Gräßlin On Oct. 14, 2014, 4:17 a.m., Sebastian Kügler wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/120471/ --- (Updated Oct. 14, 2014, 4:17 a.m.) Review request for kwin, Plasma and Martin Gräßlin. Repository: kwayland Description --- Add Registry::sync() signal Emitted when the Wayland display is done flushing the initial interface callbacks, announcing wl_display properties. This can be used to compress events. Note that this signal is emitted only after announcing interfaces, such as outputs, but not after receiving callbacks of interface properties, such as the output's geometry, modes, etc.. This signal is emitted from the wl_display_sync callback. For this, we add a wl_callback_listener to the registry's Private, enqueue its events properly, if necessary, and trigger the signal through a callback mechanism similar to the wl_registry callbacks. This signal allows users of the API to find out when the signal emissions, such as outputAnnounced, etc. for all currently existing interfaces is complete. Diffs - autotests/client/test_wayland_registry.cpp 571be0f src/client/registry.h 9e63a2b src/client/registry.cpp 207cdef Diff: https://git.reviewboard.kde.org/r/120471/diff/ Testing --- tests in libkscreen exercise this feature, it works as expected, meaning I can notify when all initial synchronization is done. Thanks, Sebastian Kügler ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Re: wallpapers on lock screen
On Monday 13 October 2014 22:47:10 ctoenn...@interstel.de wrote: On 13.10.2014 17:21, Martin Gräßlin wrote: On Monday 13 October 2014 16:44:30 Martin Klapetek wrote: I think by default it should use the (current visible) desktop wallpaper in the lockscreen. for privacy reasons the current configured wallpaper should not be used in the lock screen (or splash screen or whatever). Having a checkbox also use on lock screen sounds like a good solution, though. What happens if this is unchecked? if we go for this solution it would be the default wallpaper otherwise. Cheers Martin signature.asc Description: This is a digitally signed message part. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Review Request 120577: Remove shutdown option from lockscreen's look and feel
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/120577/ --- Review request for Plasma and Aleix Pol Gonzalez. Repository: plasma-workspace Description --- Logging out from the locked screen is impossible. Logging out means interaction with the session due to the session manager. The session manager asks all applications to quit and applications are allowed to ask for example saving changes. The session manager stopps the logout in this case and asks the window manager to focus this window and the session manager will only continue the logout once the application resolved the situation. At any time in this process the user is still able to abort the logout! Switching to the application which needs interaction is impossible, though as the screen is still locked. The result is a seemingly frozen system as the logout cannot continue and there is no indication what is going on. Of course the lock screen cannot unlock the session for the logout as that would circumvent the security. If the lock screen would unlock one would just have to click the button and abort the logout really fast to have the system unlocked. So this is clearly not an option. The result is: we cannot implement this functionality in a working and secure manner, so it's better to remove it. Diffs - lookandfeel/contents/lockscreen/LockScreen.qml 7d730cf1ebd8241dfe1c00a2bef86ec4a3f0212d Diff: https://git.reviewboard.kde.org/r/120577/diff/ Testing --- run kscreenlocker_greeter --testing and locked the screen - button is gone. Thanks, Martin Gräßlin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
