Re: RFC: Enabling users to report issues with Plasma widgets
first It would be nice to have an info / help page for the plasmoid. Each application has an about page if it is helpful or not, when each plasmoid has an about page it feels more like an signle application as it is and not part of something else. second I reported a lot of bugs in the last month and my biggest problem was not to fill the bug report this is really simple and easy to understand the biggest problem was, that you have to know in which repository/product you have to report the bug. do you know where the puzzle widget is, in which product? So for this an about page where you can say report bug and the product, component is already filled would be a BIG improvement for the user AND for the developer. With an about page I would also know how is the developer, link to the git repository and how is the plasmoid called. e.g. I have big problems what Kicker and Kickof is, cause you only see it in the code (I use german language). I'm not a fan of an additional button cause I think the config parge would be a good place AND a lot of plasmoids only have there the shortcut tab and that's it so an about page there would be not that problem. cheers Andreas Kainz 2016-04-05 7:54 GMT+02:00 Martin Graesslin : > On Monday, April 4, 2016 7:06:40 PM CEST Friedrich W. H. Kossebau wrote: > > Hi, > > > > challenge: > > 1. take your favourite Plasma widget > > 2. find a bug or idea for an improvement with it > > 3. report it to the maintainer of the widget > > > > 1. & 2. are easy. > > But 3. is not easy at all. > > > > Question: > > Are endusers supposed to report issues with Plasma widgets and get in > > contact with its developers, designers, translators? > > > > If "of course, yes" then they need to be enabled & encouraged to do so. > > At least every XMLGUI-based QWidget app has "Help">"Report Bug...". IMHO > > there should be something similar for Widgets. And something like "About" > > info as well, to know who to talk to or where the widget is from and the > > version. > > > > Right now an enduser has no single clue in the UI where to go to with any > > widget issues. As a widget developer I experience that as a big burden, > > because it prevents feedback from the average enduser. Which sucks. > > > > Please comment on this. Once I know your ideas about that, I would > consider > > pushing this further to the VDG, so they can draft a nice UX for that, > one > > without bloating the UI but still being discoverable and useable. > > Speaking now with the experience from KWin (which has a dedicated info page > per effect): > * cannot remember that I ever got contacted directly by a user due to the > about information > * bug reports hardly reference an effect plugin directly. Users cannot and > should not know where the bug is, whether it's in the plugin or in the > infrastructure > * our devs don't care about it. I don't know in how many reviews I pointed > out > that I'm not the author of the newly added effect > > So with the experience of the 40 plugins in KWin I think the possible gains > presented here do not justify the addition of code and UI elements. > > The only real argument I see is honor those who deserve honor. If we want > to > show in 3rd party plasmoids that they are 3rd party, we need them. But not > for > bugs, translators, designers. > > Cheers > Martin > ___ > Plasma-devel mailing list > Plasma-devel@kde.org > https://mail.kde.org/mailman/listinfo/plasma-devel > > ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: RFC: Enabling users to report issues with Plasma widgets
On Monday, April 4, 2016 7:06:40 PM CEST Friedrich W. H. Kossebau wrote: > Hi, > > challenge: > 1. take your favourite Plasma widget > 2. find a bug or idea for an improvement with it > 3. report it to the maintainer of the widget > > 1. & 2. are easy. > But 3. is not easy at all. > > Question: > Are endusers supposed to report issues with Plasma widgets and get in > contact with its developers, designers, translators? > > If "of course, yes" then they need to be enabled & encouraged to do so. > At least every XMLGUI-based QWidget app has "Help">"Report Bug...". IMHO > there should be something similar for Widgets. And something like "About" > info as well, to know who to talk to or where the widget is from and the > version. > > Right now an enduser has no single clue in the UI where to go to with any > widget issues. As a widget developer I experience that as a big burden, > because it prevents feedback from the average enduser. Which sucks. > > Please comment on this. Once I know your ideas about that, I would consider > pushing this further to the VDG, so they can draft a nice UX for that, one > without bloating the UI but still being discoverable and useable. Speaking now with the experience from KWin (which has a dedicated info page per effect): * cannot remember that I ever got contacted directly by a user due to the about information * bug reports hardly reference an effect plugin directly. Users cannot and should not know where the bug is, whether it's in the plugin or in the infrastructure * our devs don't care about it. I don't know in how many reviews I pointed out that I'm not the author of the newly added effect So with the experience of the 40 plugins in KWin I think the possible gains presented here do not justify the addition of code and UI elements. The only real argument I see is honor those who deserve honor. If we want to show in 3rd party plasmoids that they are 3rd party, we need them. But not for bugs, translators, designers. 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
Jenkins-kde-ci: plasma-workspace master kf5-qt5 » Linux,gcc - Build # 15 - Still Unstable!
GENERAL INFO BUILD UNSTABLE Build URL: https://build.kde.org/job/plasma-workspace%20master%20kf5-qt5/PLATFORM=Linux,compiler=gcc/15/ Project: PLATFORM=Linux,compiler=gcc Date of build: Tue, 05 Apr 2016 03:14:55 + Build duration: 38 min CHANGE SET Revision 7186616b94ec04b1415a7f4bcacbbb692f1807c0 by Friedrich W. H. Kossebau: ([weather] code style: align ion headers) change: edit dataengines/weather/ions/envcan/ion_envcan.h change: edit dataengines/weather/ions/bbcukmet/ion_bbcukmet.h change: edit dataengines/weather/ions/wetter.com/ion_wettercom.h change: edit dataengines/weather/ions/noaa/ion_noaa.h Revision 9ba58ca796df5f92650e4539d9b499cf37bb2e99 by Friedrich W. H. Kossebau: ([weather] inline init() methods of all ions) change: edit dataengines/weather/ions/noaa/ion_noaa.cpp change: edit dataengines/weather/ions/envcan/ion_envcan.cpp change: edit dataengines/weather/ions/wetter.com/ion_wettercom.cpp change: edit dataengines/weather/ions/wetter.com/ion_wettercom.h change: edit dataengines/weather/ions/envcan/ion_envcan.h change: edit dataengines/weather/ions/bbcukmet/ion_bbcukmet.h change: edit dataengines/weather/ions/noaa/ion_noaa.h change: edit dataengines/weather/ions/bbcukmet/ion_bbcukmet.cpp Revision 4c1b063e9190c5f78d5a652cc489cda46937da32 by Friedrich W. H. Kossebau: ([weather] more comparison with qlatin1strings) change: edit dataengines/weather/ions/noaa/ion_noaa.cpp change: edit dataengines/weather/ions/envcan/ion_envcan.cpp change: edit dataengines/weather/ions/wetter.com/ion_wettercom.cpp change: edit dataengines/weather/ions/bbcukmet/ion_bbcukmet.cpp JUNIT RESULTS Name: (root) Failed: 2 test(s), Passed: 6 test(s), Skipped: 0 test(s), Total: 8 test(s)Failed: TestSuite.org.kde.plasma.analogclock-testFailed: TestSuite.org.kde.plasma.kickoff-test COBERTURA RESULTS Cobertura Coverage Report PACKAGES 9/9 (100%)FILES 42/47 (89%)CLASSES 42/47 (89%)LINE 1661/2088 (80%)CONDITIONAL 1206/1802 (67%) By packages drkonqi.parser FILES 6/10 (60%)CLASSES 6/10 (60%)LINE 303/423 (72%)CONDITIONAL 478/541 (88%) drkonqi.tests.backtraceparsertest FILES 4/4 (100%)CLASSES 4/4 (100%)LINE 74/74 (100%)CONDITIONAL 33/50 (66%) kioslave.desktop FILES 1/1 (100%)CLASSES 1/1 (100%)LINE 90/131 (69%)CONDITIONAL 34/50 (68%) kioslave.desktop.tests FILES 1/1 (100%)CLASSES 1/1 (100%)LINE 66/66 (100%)CONDITIONAL 26/50 (52%) klipper FILES 12/13 (92%)CLASSES 12/13 (92%)LINE 256/384 (67%)CONDITIONAL 109/146 (75%) klipper.autotests FILES 4/4 (100%)CLASSES 4/4 (100%)LINE 630/693 (91%)CONDITIONAL 377/742 (51%) runners.bookmarks FILES 8/8 (100%)CLASSES 8/8 (100%)LINE 89/159 (56%)CONDITIONAL 34/56 (61%) runners.bookmarks.browsers FILES 4/4 (100%)CLASSES 4/4 (100%)LINE 88/93 (95%)CONDITIONAL 84/107 (79%) runners.bookmarks.tests FILES 2/2 (100%)CLASSES 2/2 (100%)LINE 65/65 (100%)CONDITIONAL 31/60 (52%)___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Jenkins-kde-ci: plasma-workspace master kf5-qt5 » Linux,gcc - Build # 14 - Still Unstable!
GENERAL INFO BUILD UNSTABLE Build URL: https://build.kde.org/job/plasma-workspace%20master%20kf5-qt5/PLATFORM=Linux,compiler=gcc/14/ Project: PLATFORM=Linux,compiler=gcc Date of build: Tue, 05 Apr 2016 02:08:20 + Build duration: 39 min CHANGE SET Revision 8ad4293ee835dbef7da2e5bc30c30632aaac4019 by Friedrich W. H. Kossebau: ([weather] this is C++, no need for (void) as parameter list with methods) change: edit dataengines/weather/ions/envcan/ion_envcan.h change: edit dataengines/weather/ions/wetter.com/ion_wettercom.cpp change: edit dataengines/weather/ions/wetter.com/ion_wettercom.h change: edit dataengines/weather/ions/bbcukmet/ion_bbcukmet.h change: edit dataengines/weather/ions/noaa/ion_noaa.cpp change: edit dataengines/weather/ions/envcan/ion_envcan.cpp change: edit dataengines/weather/ions/bbcukmet/ion_bbcukmet.cpp change: edit dataengines/weather/ions/noaa/ion_noaa.h Revision 84f845328545b6428f5781165d759d1f61d5678b by Friedrich W. H. Kossebau: ([weather] use QHash for all kjob-based tables) change: edit dataengines/weather/ions/wetter.com/ion_wettercom.h change: edit dataengines/weather/ions/noaa/ion_noaa.h change: edit dataengines/weather/ions/bbcukmet/ion_bbcukmet.h Revision 8c2ce965145949deaec79e5ba16d2b47eb34be7c by Friedrich W. H. Kossebau: ([weather] Align code of http calls to data providers) change: edit dataengines/weather/ions/wetter.com/ion_wettercom.h change: edit dataengines/weather/ions/wetter.com/ion_wettercom.cpp change: edit dataengines/weather/ions/bbcukmet/ion_bbcukmet.h change: edit dataengines/weather/ions/bbcukmet/ion_bbcukmet.cpp change: edit dataengines/weather/ions/noaa/ion_noaa.cpp change: edit dataengines/weather/ions/envcan/ion_envcan.cpp Revision 45c6b54dd98ae3de83f23eee4553e68333e6fdd4 by Friedrich W. H. Kossebau: ([weather] cleanup includes) change: edit dataengines/weather/ions/noaa/ion_noaa.cpp change: edit dataengines/weather/ions/bbcukmet/ion_bbcukmet.cpp change: edit dataengines/weather/ions/ion.h change: edit dataengines/weather/ions/wetter.com/ion_wettercom.h change: edit dataengines/weather/ions/envcan/ion_envcan.h change: edit dataengines/weather/ions/bbcukmet/ion_bbcukmet.h change: edit dataengines/weather/ions/noaa/ion_noaa.h change: edit dataengines/weather/ions/envcan/ion_envcan.cpp change: edit dataengines/weather/ions/wetter.com/ion_wettercom.cpp Revision 716d9beb80a7ef2243388a8bea0e65cad05a13ef by Friedrich W. H. Kossebau: (fix typo in comment) change: edit dataengines/weather/ions/ion.cpp Revision 2f9dd0d6cca0325f234c6c9d31f28ba1e77fccc3 by Friedrich W. H. Kossebau: (fix slot signature normalization) change: edit dataengines/weather/weatherengine.cpp Revision ed5b3fa9a0081fd917fea7331749bde466492350 by Friedrich W. H. Kossebau: ([weather] code style: no else after return) change: edit dataengines/weather/ions/wetter.com/ion_wettercom.cpp change: edit dataengines/weather/ions/envcan/ion_envcan.cpp change: edit dataengines/weather/ions/bbcukmet/ion_bbcukmet.cpp change: edit dataengines/weather/ions/noaa/ion_noaa.cpp JUNIT RESULTS Name: (root) Failed: 2 test(s), Passed: 6 test(s), Skipped: 0 test(s), Total: 8 test(s)Failed: TestSuite.org.kde.plasma.analogclock-testFailed: TestSuite.org.kde.plasma.kickoff-test COBERTURA RESULTS Cobertura Coverage Report PACKAGES 9/9 (100%)FILES 42/47 (89%)CLASSES 42/47 (89%)LINE 1661/2088 (80%)CONDITIONAL 1206/1802 (67%) By packages drkonqi.parser FILES 6/10 (60%)CLASSES 6/10 (60%)LINE 303/423 (72%)CONDITIONAL 478/541 (88%) drkonqi.tests.backtraceparsertest FILES 4/4 (100%)CLASSES 4/4 (100%)LINE 74/74 (100%)CONDITIONAL 33/50 (66%) kioslave.desktop FILES 1/1 (100%)CLASSES 1/1 (100%)LINE 90/131 (69%)CONDITIONAL 34/50 (68%) kioslave.desktop.tests FILES 1/1 (100%)CLASSES 1/1 (100%)LINE 66/66 (100%)CONDITIONAL 26/50 (52%) klipper FILES 12/13 (92%)CLASSES 12/13 (92%)LINE 256/384 (67%)CONDITIONAL 109/146 (75%) klipper.autotests FILES 4/4 (100%)CLASSES 4/4 (100%)LINE 630/693 (91%)CONDITIONAL 377/742 (51%) runners.bookmarks FILES 8/8 (100%)CLASSES 8/8 (100%)LINE 89/159 (56%)CONDITIONAL 34/56 (61%) runners.bookmarks.browsers FILES 4/4 (100%)CLASSES 4/4 (100%)LINE 88/93 (95%)CONDITIONAL 84/107 (79%) runners.bookmarks.tests FILES 2/2 (100%)CLASSES 2/2 (100%)LINE 65/65 (100%)CONDITIONAL 31/60 (52%)___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Review Request 127575: Plasma 5.7 "Skylight" Wallpaper
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/127575/ --- Review request for Plasma. Repository: breeze Description --- New wallpaper for Plasma 5.7 Similar to the 5.6 wallpaper, but using perspective and reflections. Source and Splash also attached. Diffs - wallpapers/Next/contents/images/1024x768.png 60e1205 wallpapers/Next/contents/images/1280x1024.png 36a9130 wallpapers/Next/contents/images/1280x800.png c33e594 wallpapers/Next/contents/images/1440x900.png 2c75b54 wallpapers/Next/contents/images/1600x1200.png 5ddaf72 wallpapers/Next/contents/images/1638x1024.png a3c7492 wallpapers/Next/contents/images/1680x1050.png eddc47e wallpapers/Next/contents/images/1920x1080.png ab6d950 wallpapers/Next/contents/images/2560x1440.png 5c78e9d wallpapers/Next/contents/images/2560x1600.png eeb08a1 wallpapers/Next/contents/images/3200x1800.png 7340567 wallpapers/Next/contents/images/3200x2000.png fd1a62c wallpapers/Next/contents/screenshot.png a6d2b7b Diff: https://git.reviewboard.kde.org/r/127575/diff/ Testing --- File Attachments splash.png https://git.reviewboard.kde.org/media/uploaded/files/2016/04/05/450ecd4d-8bbe-48fe-b22a-578ab1968089__splash.png desktopWallpaper-skylight-1.0-kvermette.png https://git.reviewboard.kde.org/media/uploaded/files/2016/04/05/41f45619-7a37-45dc-a374-27980227414c__2560x1600.png desktopWallpaper-skylight-1.0-kvermette.svg https://git.reviewboard.kde.org/media/uploaded/files/2016/04/05/b19f3502-0204-44f8-a742-f79ff9701f41__desktopWallpaper-skylight-1.0-kvermette.svg Thanks, Ken Vermette ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: A Plasma Vision draft
On the one hand I fell in love with the word "nimble" (We have to do something cool based on words like "nimble" and "swift" one day - I don't know what but I will bribe you till you do it Sebas, we can't let those two words get to some marketing department somewhere) On the other David has some good points - "performant" although fiddly is a better word I think. Also this thread is GOLD - keep the critique coming everyone I am taking notes like paper is going out of style. On Tuesday, 5 April 2016 00:17:59 CEST David Edmundson wrote: > On Mon, Apr 4, 2016 at 11:48 PM, Sebastian Kügler wrote: > > On Monday 04 April 2016 17:29:58 Thomas Pfeiffer wrote: > > > On Montag, 4. April 2016 15:04:30 CEST Jonathan Riddell wrote: > > > > I'm not convinced performant is a word although it seems to be used > > > > for computer jargon > > > > http://english.stackexchange.com/questions/38945/what-is-wrong-with-the-wo > > > > > > rd -performant > > > > > > It is clearly jargon. As Jens already said, the question is: Can we > > > > afford > > > > > the jargon or not? We think we can, but there are certainly also good > > > arguments against it. > > > > I don't like it. How about "nimble", it expresses power and speed in a > > positively sounding adjective. > > What I like about "performant" is it doesn't just mean fast *. > It covers a broader range of metrics, and the text beneath it in Detail 3 > goes on about code quality and usability which "nimble" doesn't really > cover in itself. > > David > > *or at least it would if it was a proper word > > > -- > > sebas > > > > Sebastian Kügler•http://vizZzion.org•http://www.kde.org > > ___ > > 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: A Plasma Vision draft
On Mon, Apr 4, 2016 at 11:48 PM, Sebastian Kügler wrote: > On Monday 04 April 2016 17:29:58 Thomas Pfeiffer wrote: > > On Montag, 4. April 2016 15:04:30 CEST Jonathan Riddell wrote: > > > I'm not convinced performant is a word although it seems to be used > > > for computer jargon > > > > > > > http://english.stackexchange.com/questions/38945/what-is-wrong-with-the-wo > > > rd -performant > > > > It is clearly jargon. As Jens already said, the question is: Can we > afford > > the jargon or not? We think we can, but there are certainly also good > > arguments against it. > > I don't like it. How about "nimble", it expresses power and speed in a > positively sounding adjective. > What I like about "performant" is it doesn't just mean fast *. It covers a broader range of metrics, and the text beneath it in Detail 3 goes on about code quality and usability which "nimble" doesn't really cover in itself. David *or at least it would if it was a proper word > -- > sebas > > Sebastian Kügler•http://vizZzion.org•http://www.kde.org > ___ > 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: A Plasma Vision draft
On Monday 04 April 2016 17:29:58 Thomas Pfeiffer wrote: > On Montag, 4. April 2016 15:04:30 CEST Jonathan Riddell wrote: > > I'm not convinced performant is a word although it seems to be used > > for computer jargon > > > > http://english.stackexchange.com/questions/38945/what-is-wrong-with-the-wo > > rd -performant > > It is clearly jargon. As Jens already said, the question is: Can we afford > the jargon or not? We think we can, but there are certainly also good > arguments against it. I don't like it. How about "nimble", it expresses power and speed in a positively sounding adjective. -- sebas Sebastian Kügler•http://vizZzion.org•http://www.kde.org ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Kirigami issues with latest master
On Mon, Apr 04, 2016 at 02:51:07PM -0700, Dirk Hohndel wrote: > - on iOS the git log of Kirigami tells me I should now have a back button > but I don't see it on my iPhone. I'm still investigating this one, > though, not sure if this app error or an issue with the code in > Kirigami. Does this ever happen to you where you feel like you should try just one more thing before sending a bug report, but then you send it anyway. And then you try it and of course it turns out you were wrong? Yeah, that one. So of course it was app error. I forgot to bundle the new BackButton.qml file with the application image. But now that I have it working I have two concerns. a) the back button becomes really small, depending on the settings for scaling the title bar. I guess that's to be expected, I just thought I'd point it out b) if you are deeper into the page stack, the bread crumbs reasonably scroll horizontally to show the title of the current page; unfortunately that pushes the back button out of view :-( At least that one should be easy to fix... Thanks as always /D ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Kirigami issues with latest master
So with the latest master, a lot of the things I've been hoping for have been improved or added. I love the speed of progress. Couple of things that I noticed - the overscroll looks much better now that the title bar comes down with it - but then things behave a bit oddly. It doesn't jump back up until you scroll almost to the bottom of the list (or whatever it is that you scroll). That's wrong, I think. It should jump back to the top the moment you start scrolling down. Or at the most after you scrolled down maybe a quarter screen. - Also, as I think was mentioned either here or on the Subsurface list, it would be even better if it jumped back to the top if there is no user input for a few second (I'll say five, but one could of course argue what the right number might be - on iOS the git log of Kirigami tells me I should now have a back button but I don't see it on my iPhone. I'm still investigating this one, though, not sure if this app error or an issue with the code in Kirigami. /D ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
breeze icons cleanup
Hi, as Plasma 5.6 support stylesheet and this feature is awesome I start massive cleanup at the breeze-icons repository. e.g. http://commits.kde.org/breeze-icons/d4e254b1e15b2a377fd2cb3d63a2fec14964e177 the applet icons are now 2.5 mb instead of 6.7 mb so the previews should be available much faster. The goal is to clean up the repository AND to guarantie that every Icon use stylesheet stuff in the right way. I hope in the future not only Plasma can draw there icons but also KDE and GTK Applications can generate the png files according to the stylesheet information from the color scheme. The colored icons are optimized with the QT application svg cleaner and the monochrome icons will be optimized by hand (50 % is done). 28 mb -> KF5.20 release 17 mb -> master cheers Andreas_K ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: RFC: Enabling users to report issues with Plasma widgets
Hi, I would propose we add a "Help" drop-down menu button to the bottom left corner of the plasmoid config dialog similar to what DrKonqi or the widget-based KCMs have and place a Help (userbase link?), About this plasmoid and Report bug entry there. Perhaps even a About Plasma / KDE as I've heard people complain about how hard it is to find out the Plasma version number itself? Cheers, Kai Uwe ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: RFC: Enabling users to report issues with Plasma widgets
On Montag, 4. April 2016 19:06:40 CEST Friedrich W. H. Kossebau wrote: > Hi, > > challenge: > 1. take your favourite Plasma widget > 2. find a bug or idea for an improvement with it > 3. report it to the maintainer of the widget > > 1. & 2. are easy. > But 3. is not easy at all. > > Question: > Are endusers supposed to report issues with Plasma widgets and get in > contact with its developers, designers, translators? > > If "of course, yes" then they need to be enabled & encouraged to do so. > At least every XMLGUI-based QWidget app has "Help">"Report Bug...". IMHO > there should be something similar for Widgets. And something like "About" > info as well, to know who to talk to or where the widget is from and the > version. > > Right now an enduser has no single clue in the UI where to go to with any > widget issues. As a widget developer I experience that as a big burden, > because it prevents feedback from the average enduser. Which sucks. > > Please comment on this. Once I know your ideas about that, I would consider > pushing this further to the VDG, so they can draft a nice UX for that, one > without bloating the UI but still being discoverable and useable. > > > Motivation: > By accident I discovered people talking on a forum about problems with the > Addons Weather widget. I was going to tell them to pretty-please instead > report their problems to upstream. Preparing that reply I then saw that lots > of insider information is needed to get from the displayed widget name in > the Plasma workspace to bugs.kde.org and then a product&component combo (if > that even exists, only created the one for the Weather widget while looking > for it, dumdidum). And contacting the developer or translator also needs > lot of research before. I fully agree that we need an "info page" for Plasmoids just like for any other application. My first gut reaction would be to make it available from the settings, so that we don't have to add another context menu / plasmoid toolbar item. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Kirigami 1.0 feedback
On Monday 04 April 2016, Dirk Hohndel wrote: > > As I already stated in my reply to sebas: Yes, you have convinced me that > > a back button makes sense for iOS. And yes, having it somewhere in > > between other buttons doesn't feel right, so the usual top-left corner > > makes sense. I don't think it should be forced into every application, > > though. There should be a global option to show it everywhere > > 100% agree. This should be optional so an iOS app can choose to have one. > But doesn't have to have one if its UI works without. in the last revision, it stuffs a back button in the titlebar in ios (only in ios atm) not controllable yet, but can be used to give a try -- Marco Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
RFC: Enabling users to report issues with Plasma widgets
Hi, challenge: 1. take your favourite Plasma widget 2. find a bug or idea for an improvement with it 3. report it to the maintainer of the widget 1. & 2. are easy. But 3. is not easy at all. Question: Are endusers supposed to report issues with Plasma widgets and get in contact with its developers, designers, translators? If "of course, yes" then they need to be enabled & encouraged to do so. At least every XMLGUI-based QWidget app has "Help">"Report Bug...". IMHO there should be something similar for Widgets. And something like "About" info as well, to know who to talk to or where the widget is from and the version. Right now an enduser has no single clue in the UI where to go to with any widget issues. As a widget developer I experience that as a big burden, because it prevents feedback from the average enduser. Which sucks. Please comment on this. Once I know your ideas about that, I would consider pushing this further to the VDG, so they can draft a nice UX for that, one without bloating the UI but still being discoverable and useable. Motivation: By accident I discovered people talking on a forum about problems with the Addons Weather widget. I was going to tell them to pretty-please instead report their problems to upstream. Preparing that reply I then saw that lots of insider information is needed to get from the displayed widget name in the Plasma workspace to bugs.kde.org and then a product&component combo (if that even exists, only created the one for the Weather widget while looking for it, dumdidum). And contacting the developer or translator also needs lot of research before. Cheers Friedrich ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
[Differential] [Closed] D1314: Workaround problems with Qt::QueuedConnection
This revision was automatically updated to reflect the committed changes. Closed by commit rKSCREENLOCKERe9984e21b798: Workaround problems with Qt::QueuedConnection (authored by graesslin). REPOSITORY rKSCREENLOCKER KScreenLocker CHANGES SINCE LAST UPDATE https://phabricator.kde.org/D1314?vs=3126&id=3129 REVISION DETAIL https://phabricator.kde.org/D1314 AFFECTED FILES autotests/ksldtest.cpp ksldapp.cpp EMAIL PREFERENCES https://phabricator.kde.org/settings/panel/emailpreferences/ To: graesslin, Plasma, sebas Cc: sebas, plasma-devel ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Kirigami 1.0 feedback
> On Apr 4, 2016, at 08:08, Thomas Pfeiffer wrote: > > On Sonntag, 3. April 2016 23:35:29 CEST Dirk Hohndel wrote: >>> >> My current thinging is that I may end up doing just that in the iOS >> version. Having a back button somewhere that isn't a corner feels very >> weird when I play with it. I see why you don't want a button in a bottom >> corner. So I think I will just implement my own back key in >> Subsurface-mobile and only enable this on iOS and have it in the top left >> corner. I wish Kirigami would consider that ALL Kirigami apps that run on >> iOS will have this very same situation and just add the standard back >> button on iOS in its standard position - but it's your project, your >> choice. > > As I already stated in my reply to sebas: Yes, you have convinced me that a > back button makes sense for iOS. And yes, having it somewhere in between > other > buttons doesn't feel right, so the usual top-left corner makes sense. > I don't think it should be forced into every application, though. There > should > be a global option to show it everywhere 100% agree. This should be optional so an iOS app can choose to have one. But doesn't have to have one if its UI works without. /D ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 127260: Experiment: cache svg icons from icon theme
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/127260/ --- (Updated April 4, 2016, 8:47 a.m.) Status -- This change has been marked as submitted. Review request for Plasma. Changes --- Submitted with commit 944c7e60dc3d2331bab1c0389cb7fa784a711985 by Marco Martin to branch master. Repository: plasma-framework Description --- this attempts to cache as well svg icons from the icon theme (invalidating as well when the icon theme is updated) still to be done, to figure out to invalidate cache when the icon theme is changed in the two cases: * theme changed with plasmashell running * theme changed with plasma shell not running Diffs - autotests/CMakeLists.txt d475ac3 autotests/data/icons/test-theme-two/apps/22/tst-plasma-framework-test-icon.svg PRE-CREATION autotests/data/icons/test-theme-two/index.theme PRE-CREATION src/plasma/private/theme_p.h 69a8934 src/plasma/private/theme_p.cpp 98bccab src/plasma/svg.cpp 6c9c75c Diff: https://git.reviewboard.kde.org/r/127260/diff/ Testing --- Thanks, Marco Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Kirigami 1.0 feedback
On Monday 04 April 2016, Thomas Pfeiffer wrote: > Yes, I agree. Let iOS users have their hard-to reach button, they're used > to it anyway and - as Robert Helling's post on the Subsurface mailing list > hints o - many or most of them have probably already adapted the way they > hold their devices to it. > Plus, if we pull down the title bar when overscrolling, the back button > would also be moved to the center, wouldn't it? it does in the latest attempt i did now (didn't add a back button there yet). testing and comments of the usual apk(tm) welcome http://notmart.org/misc/kirigami/QtApp-debug.apk -- Marco Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Plasma mobile future development meeting datetime
By popular choice on doodle [1], Final date for meeting is 8th April 13:30 CEST. Thanks, See you there in #plasma [1] http://doodle.com/poll/8x983kg6s5p6hw48 -- Bhushan Shah http://bhush9.github.io IRC Nick : bshah on Freenode ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Plasma Wayland image update
http://jriddell.org/2016/04/04/plasma-wayland-image-update/ It’s your fortnightly update to the Plasma Wayland image. Rather pleasingly window decorations are the right colour and I can resize windows. Jonathan ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: A Plasma Vision draft
On Montag, 4. April 2016 15:04:30 CEST Jonathan Riddell wrote: > I'm not convinced performant is a word although it seems to be used > for computer jargon > > http://english.stackexchange.com/questions/38945/what-is-wrong-with-the-word > -performant It is clearly jargon. As Jens already said, the question is: Can we afford the jargon or not? We think we can, but there are certainly also good arguments against it. > The main part which surprises me is the user profile for professional > users. I guess you've thought about who that includes and who it > excludes? How does it differentiate us from the competition? By definition, we don't exclude anybody. Anybody _can_ use Plasma, for whatever they want. The focus on professional users (using Merriam-Webster's first simple definition of professional as "relating to a job that requires special education, training, or skill") gives us the advantage of making clear that Plasma is for getting a job done. That doesn't mean it cannot be used for recreational tasks, but the focus is on productivity. For example, any office suite I know is clearly made for professional use, but that doesn't keep people from using them at home. Yet if someone asks for a feature in an office suite that only makes sense in a recreational context, they will probably have a hard time convincing office suite makers to put significant effort into it, and I think that's a good thing. We want the same for Plasma. When someone asks us to implement feature X, we should ask back "Please explain how this feature makes you more productive", and if all they can come up with is "But I like it that way!", we can point to our vision and say "Sorry, not our focus". How does it differentiate us from the competition? In the desktop area maybe not so much (since most desktops seem to be geared towards professional productivity), but most mobile operating systems appear to be foremost environments for media consumption, and became productive tools more or less by accident. We can focus on productivity right from the start (Plasma Active did a lot in that direction, for example), allowing us to occupy a "niche" more easily (yes, Blackberry tries that, too, but due to their size, they need a far bigger niche to thrive in than we do). Hope that helps, Thomas ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
[Differential] [Closed] D1312: Add auto test for grace time
This revision was automatically updated to reflect the committed changes. Closed by commit rKSCREENLOCKERbd17972c8f89: Add auto test for grace time (authored by graesslin). CHANGED PRIOR TO COMMIT https://phabricator.kde.org/D1312?vs=3124&id=3128#toc REPOSITORY rKSCREENLOCKER KScreenLocker CHANGES SINCE LAST UPDATE https://phabricator.kde.org/D1312?vs=3124&id=3128 REVISION DETAIL https://phabricator.kde.org/D1312 AFFECTED FILES CMakeLists.txt autotests/CMakeLists.txt autotests/ksldtest.cpp ksldapp.h EMAIL PREFERENCES https://phabricator.kde.org/settings/panel/emailpreferences/ To: graesslin, Plasma, bshah Cc: plasma-devel, sebas ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
[Differential] [Closed] D1311: Add autotest to verify that screen starts to lock on idle timeout
This revision was automatically updated to reflect the committed changes. Closed by commit rKSCREENLOCKERd65e7b49c95a: Add autotest to verify that screen starts to lock on idle timeout (authored by graesslin). REPOSITORY rKSCREENLOCKER KScreenLocker CHANGES SINCE LAST UPDATE https://phabricator.kde.org/D1311?vs=3121&id=3127 REVISION DETAIL https://phabricator.kde.org/D1311 AFFECTED FILES autotests/CMakeLists.txt autotests/ksldtest.cpp ksldapp.h EMAIL PREFERENCES https://phabricator.kde.org/settings/panel/emailpreferences/ To: graesslin, Plasma, bshah Cc: plasma-devel, sebas ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
[Differential] [Accepted] D1311: Add autotest to verify that screen starts to lock on idle timeout
bshah accepted this revision. bshah added a reviewer: bshah. This revision is now accepted and ready to land. REPOSITORY rKSCREENLOCKER KScreenLocker BRANCH idle-test REVISION DETAIL https://phabricator.kde.org/D1311 EMAIL PREFERENCES https://phabricator.kde.org/settings/panel/emailpreferences/ To: graesslin, Plasma, bshah Cc: plasma-devel, sebas ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 127260: Experiment: cache svg icons from icon theme
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/127260/#review94242 --- Ship it! Ship It! - David Edmundson On April 1, 2016, 4:20 p.m., Marco Martin wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/127260/ > --- > > (Updated April 1, 2016, 4:20 p.m.) > > > Review request for Plasma. > > > Repository: plasma-framework > > > Description > --- > > this attempts to cache as well svg icons from the icon theme (invalidating as > well when the icon theme is updated) > > still to be done, to figure out to invalidate cache when the icon theme is > changed in the two cases: > * theme changed with plasmashell running > * theme changed with plasma shell not running > > > Diffs > - > > autotests/CMakeLists.txt d475ac3 > > autotests/data/icons/test-theme-two/apps/22/tst-plasma-framework-test-icon.svg > PRE-CREATION > autotests/data/icons/test-theme-two/index.theme PRE-CREATION > src/plasma/private/theme_p.h 69a8934 > src/plasma/private/theme_p.cpp 98bccab > src/plasma/svg.cpp 6c9c75c > > Diff: https://git.reviewboard.kde.org/r/127260/diff/ > > > Testing > --- > > > Thanks, > > Marco Martin > > ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Jenkins-kde-ci: plasma-workspace master kf5-qt5 » Linux,gcc - Build # 13 - Still Unstable!
GENERAL INFO BUILD UNSTABLE Build URL: https://build.kde.org/job/plasma-workspace%20master%20kf5-qt5/PLATFORM=Linux,compiler=gcc/13/ Project: PLATFORM=Linux,compiler=gcc Date of build: Mon, 04 Apr 2016 15:05:43 + Build duration: 10 min CHANGE SET Revision 2f5a091ca9fa8661c15a1c8a3bc815f646f84601 by Friedrich W. H. Kossebau: ([weather bbcukmet] Translate data credit string) change: edit dataengines/weather/ions/bbcukmet/ion_bbcukmet.cpp JUNIT RESULTS Name: (root) Failed: 2 test(s), Passed: 6 test(s), Skipped: 0 test(s), Total: 8 test(s)Failed: TestSuite.org.kde.plasma.analogclock-testFailed: TestSuite.org.kde.plasma.kickoff-test COBERTURA RESULTS Cobertura Coverage Report PACKAGES 9/9 (100%)FILES 42/47 (89%)CLASSES 42/47 (89%)LINE 1661/2088 (80%)CONDITIONAL 1206/1802 (67%) By packages drkonqi.parser FILES 6/10 (60%)CLASSES 6/10 (60%)LINE 303/423 (72%)CONDITIONAL 478/541 (88%) drkonqi.tests.backtraceparsertest FILES 4/4 (100%)CLASSES 4/4 (100%)LINE 74/74 (100%)CONDITIONAL 33/50 (66%) kioslave.desktop FILES 1/1 (100%)CLASSES 1/1 (100%)LINE 90/131 (69%)CONDITIONAL 34/50 (68%) kioslave.desktop.tests FILES 1/1 (100%)CLASSES 1/1 (100%)LINE 66/66 (100%)CONDITIONAL 26/50 (52%) klipper FILES 12/13 (92%)CLASSES 12/13 (92%)LINE 256/384 (67%)CONDITIONAL 109/146 (75%) klipper.autotests FILES 4/4 (100%)CLASSES 4/4 (100%)LINE 630/693 (91%)CONDITIONAL 377/742 (51%) runners.bookmarks FILES 8/8 (100%)CLASSES 8/8 (100%)LINE 89/159 (56%)CONDITIONAL 34/56 (61%) runners.bookmarks.browsers FILES 4/4 (100%)CLASSES 4/4 (100%)LINE 88/93 (95%)CONDITIONAL 84/107 (79%) runners.bookmarks.tests FILES 2/2 (100%)CLASSES 2/2 (100%)LINE 65/65 (100%)CONDITIONAL 31/60 (52%)___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: A Plasma Vision draft
I really like it. ++ It's distilled quite nicely into being a genuinely useful product without being too restrictive. David ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Kirigami 1.0 feedback
On Sonntag, 3. April 2016 23:35:29 CEST Dirk Hohndel wrote: > > Is deleting a dive using the context drawer so unwieldy that it has to be > > avoided at all cost? > > I actually have found that it's good that you challenge my ideas here... > I looked at a bunch of Android and iOS apps and at how they initiate > actions. Almost no one uses a context menu for actions. It's for odds and > ends, if it exists at all. And remarkably often it's stuff that's > redundant or should better be done a different way. > > iOS Mail app has in the "view mail" screen (I guess comparable to our dive > view) 5 buttons (no kidding) at the bottom (flag, file, delete, reply, > start new mail), and three buttons in the top (back, previous, next). > > No guestures at all besides scrolling. > > Gmail on iOS has five buttons spread around in the top and along the top > right (back, file, delete, star, reply), plus a context menu in the top > right corner (right in the middle between all the buttons) which then > opens as a kind of drawer from the top to add six more buttons, oddly > covering two of the existing buttons. It frankly doesn't feel like a > context menu at all, but like a "here are some more buttons"-button. > > Gmail on Android has four buttons on top: one on the left (back), three > grouped towards the right (file, delete, mark-unread), then a context menu > in the top corner (this one opens to a desktop style drop down menu with > six text selections that all seem things you rarely do... so perfect for a > context menu, I guess). Then there is another button to star a message > at the end of the subject line, another button below that (are you still > with me?) in the third row with the auther to reply and (I kid you not) a > second context menu with five more options, several of which are redundant > with some of the other buttons and even entries in the other context menu. The "desktop style dropdown menu" (it's officially called "overflow") was the first thing where we thought "Hey, we can do waaay better than that!", because there is no other way to open it than reaching one of the hardest-to-reach points on the screen. The menu drawer can be opened comfortably by edge swipe, but the overflow is hidden behind a tiny button. That was the reason why we decided to use another drawer for the contextual actions, with all the niceties it brings with it. > Do they even have UI designers over there? Wow. They do, and I'm sure they have very good ones, but they make some decisions that I for the life of me cannot explain. I can only blame it on "design for committee" and hope that no individual designer ever wanted to end up with some of these things. > G+ app. > Android. Four buttons bottom row, fifth "main" button above that to the > right. Another button on top (search), next to it the context menu (only > three entries: "refresh" (should be gesture), "send feedback", and "help" > (why are these in a context menu andnot the global menu) and in the other > corner their global drawer with another five entries in one mode and a > little button to switch to a different mode with four more options. > > Holy poop. The G+ app is a mystery to me as well. I bet at least 80% of what people do with it is scroll through their feed, 18% are split between commenting and writing posts, and the remaining 2% are for some administrative tasks. I have no idea why one needs so many buttons for that, especially given that if there is any app where "content is king" should be the mantra, it's this one. Maybe the designers refuse to accept that communities and collections aren't as cool as they think they are and feel they can make people use them more by shoving them in their faces. > Interestingly the layout on iOS is almost identical, only the global > drawer is needlessly different and has some things that it doesn't have on > Android and in return is missing somethings it has on Android. Yay consistency! > Why am I listing all this. > > Because I need people to challenge me so Subsurface-mobile doesn't end up > a disaster like this. We really wanted to keep as many controls out of the way as possible, and keep only the frequently used ones in the main UI. > - maximum of three buttons, all in the bottom row. SOLD. Except. See below. > - one or two menus, global drawer consisten wherever you are, context > drawer if we really need it - I really hope I can avoid needing it at > all > - where possible smart gestures to help (like swiping list entries to > reveal actions on them) > > BUT (and you knew there would be one): Swipe for "back key" is hard for > us. We can't really do it when looking at dive details, and it feels > really alien to iOS users. And the back key on iOS is always, always, > always, in every app, even the crazy ones, in the top left corner. > > My current thinging is that I may end up doing just that in the iOS > version. Having a back button somewhere that isn't a corner feels
Jenkins-kde-ci: plasma-workspace master kf5-qt5 » Linux,gcc - Build # 12 - Still Unstable!
GENERAL INFO BUILD UNSTABLE Build URL: https://build.kde.org/job/plasma-workspace%20master%20kf5-qt5/PLATFORM=Linux,compiler=gcc/12/ Project: PLATFORM=Linux,compiler=gcc Date of build: Mon, 04 Apr 2016 14:17:31 + Build duration: 44 min CHANGE SET Revision 75476af33fe295e84cdcde20043032b2fc381b1c by Friedrich W. H. Kossebau: ([Weather dataengine] Do not install CamelCase forward header Ion for now) change: edit dataengines/weather/ions/CMakeLists.txt Revision f03482f6073fa14ee3fc6e9353a7be34a468f1dc by Friedrich W. H. Kossebau: ([Weather] Remove no longer used custom DataEngineConsumer class) change: delete dataengines/weather/ions/dataengineconsumer.h Revision 84fe5785bd1520f17a801cfe2e263c8ba872b273 by Friedrich W. H. Kossebau: ([weather bbcukmet] Update to BBC's new json-based search and modified) change: edit dataengines/weather/ions/bbcukmet/ion_bbcukmet.cpp Revision 68b767046e9b185a38232b634559200c3832ea88 by Friedrich W. H. Kossebau: ([weather bbcukmet] Handle cases where min. or max. temperatures are not) change: edit dataengines/weather/ions/bbcukmet/ion_bbcukmet.cpp Revision 00d6c8f9483495539725b160ed1d41016c19dba2 by Friedrich W. H. Kossebau: ([weather bbcukmet] Trivial fix for the "clear sky" typo) change: edit dataengines/weather/ions/bbcukmet/ion_bbcukmet.cpp Revision 7c66c48d7f3929917d8b8fbad9bfc19ca980347b by Friedrich W. H. Kossebau: ([weather bbcukmet] Fix for crash bug #332392 and error handling) change: edit dataengines/weather/ions/bbcukmet/ion_bbcukmet.cpp change: edit dataengines/weather/ions/bbcukmet/ion_bbcukmet.h Revision 0057f920d14d3664d9ea03d33916c4a0d83dbc8c by Friedrich W. H. Kossebau: ([weather bbcukmet] Update Credit) change: edit dataengines/weather/ions/bbcukmet/ion_bbcukmet.cpp Revision cf5cca38788407f80d07080fb72e55308a02f0f1 by Friedrich W. H. Kossebau: ([weather bbcukmet] Readd bbcukmet ion to build & install) change: edit dataengines/weather/ions/CMakeLists.txt JUNIT RESULTS Name: (root) Failed: 2 test(s), Passed: 6 test(s), Skipped: 0 test(s), Total: 8 test(s)Failed: TestSuite.org.kde.plasma.analogclock-testFailed: TestSuite.org.kde.plasma.kickoff-test COBERTURA RESULTS Cobertura Coverage Report PACKAGES 9/9 (100%)FILES 42/47 (89%)CLASSES 42/47 (89%)LINE 1661/2088 (80%)CONDITIONAL 1206/1802 (67%) By packages drkonqi.parser FILES 6/10 (60%)CLASSES 6/10 (60%)LINE 303/423 (72%)CONDITIONAL 478/541 (88%) drkonqi.tests.backtraceparsertest FILES 4/4 (100%)CLASSES 4/4 (100%)LINE 74/74 (100%)CONDITIONAL 33/50 (66%) kioslave.desktop FILES 1/1 (100%)CLASSES 1/1 (100%)LINE 90/131 (69%)CONDITIONAL 34/50 (68%) kioslave.desktop.tests FILES 1/1 (100%)CLASSES 1/1 (100%)LINE 66/66 (100%)CONDITIONAL 26/50 (52%) klipper FILES 12/13 (92%)CLASSES 12/13 (92%)LINE 256/384 (67%)CONDITIONAL 109/146 (75%) klipper.autotests FILES 4/4 (100%)CLASSES 4/4 (100%)LINE 630/693 (91%)CONDITIONAL 377/742 (51%) runners.bookmarks FILES 8/8 (100%)CLASSES 8/8 (100%)LINE 89/159 (56%)CONDITIONAL 34/56 (61%) runners.bookmarks.browsers FILES 4/4 (100%)CLASSES 4/4 (100%)LINE 88/93 (95%)CONDITIONAL 84/107 (79%) runners.bookmarks.tests FILES 2/2 (100%)CLASSES 2/2 (100%)LINE 65/65 (100%)CONDITIONAL 31/60 (52%)___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Use-cases for ASCII-art kwin backend (Re: Minutes Monday Plasma Meeting)
Am Montag, 4. April 2016, 12:42:39 CEST schrieb Sebastian Kügler: > * april-fool: https://phabricator.kde.org/D1283 - might work as easter egg, > opinions? Use-cases: * nice gimmick for Plasma demo points on fairs/events (as eye catcher or talk starter), if separate (virtual) machine is available * one-time press material (they like to talk about non-daily stuff) Surely needs careful twisting of message sent :) Cheers Friedrich ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Kirigami 1.0 feedback
On Montag, 4. April 2016 13:05:15 CEST Sebastian Kügler wrote: > On Sunday, April 03, 2016 11:35:29 PM Dirk Hohndel wrote: > > BUT (and you knew there would be one): Swipe for "back key" is hard for > > us. We can't really do it when looking at dive details, and it feels > > really alien to iOS users. And the back key on iOS is always, always, > > always, in every app, even the crazy ones, in the top left corner. > > > > My current thinging is that I may end up doing just that in the iOS > > version. Having a back button somewhere that isn't a corner feels very > > weird when I play with it. I see why you don't want a button in a bottom > > corner. So I think I will just implement my own back key in > > Subsurface-mobile and only enable this on iOS and have it in the top left > > corner. I wish Kirigami would consider that ALL Kirigami apps that run on > > iOS will have this very same situation and just add the standard back > > button on iOS in its standard position - but it's your project, your > > choice. > > I can see that making sense, though. "that" means: on ios, top-left has a > back button, all other target OSes have this functionality native, > elsewhere (Android, for example, has the back button). > > To me, that is consistent enough across OSes, while still respecting OS- > specific mechanisms. Yes, I agree. Let iOS users have their hard-to reach button, they're used to it anyway and - as Robert Helling's post on the Subsurface mailing list hints o - many or most of them have probably already adapted the way they hold their devices to it. Plus, if we pull down the title bar when overscrolling, the back button would also be moved to the center, wouldn't it? ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: A Plasma Vision draft
In all fairness Thomas mentioned that too :D But we thought "oh computer stuff works, lets keep it" plus its a nice catch-all word isn't it... Don't know of an alternative to it without adding a lot of extra word faffing tbh. (Anyone who knows: HALP!) During CERN professionals came up as an example of what we wanted to aim to, now we may have gone in a tad hard for that (since I like exclusions as a way to define ourselves) - either that or we are stuck with "enthusiasts" (which means nothing at all) or "hobbyists" (which is not a grand group to be connected to when it comes to words I feel - I may be wrong of course these are just my reasonings) On Monday, 4 April 2016 15:04:30 CEST Jonathan Riddell wrote: > On 4 April 2016 at 14:58, Jens Reuterberg wrote: > > Thanks for feedback! :) > > > >> First, it looks very professional, nice :) > >> one thing tough , is the underline of the words, the red underline may > >> look > >> like a spellcheck error (i'm wondering if something else could be used > >> instead of an underline, like bullets, those icons in small, or just a > >> background..) > > > > Yes now that you say it it does look like a spelling check going on :D Ok > > ok this calls for some experimentation. Will edit that > > > > But the text? What do you think about the text? > > I'm not convinced performant is a word although it seems to be used > for computer jargon > > http://english.stackexchange.com/questions/38945/what-is-wrong-with-the-word > -performant > > The main part which surprises me is the user profile for professional > users. I guess you've thought about who that includes and who it > excludes? How does it differentiate us from the competition? > > 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
Plasma 5.7 schedule
Plasma 5.7 schedule is up at https://community.kde.org/Schedules/Plasma_5 incase anyone missed it. repo freeze start of June feature freeze mid-june release end of June Three months to go, good luck :) Jonathan ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: A Plasma Vision draft
On Monday 04 April 2016, Jens Reuterberg wrote: > Thanks for feedback! :) > > > First, it looks very professional, nice :) > > one thing tough , is the underline of the words, the red underline may > > look like a spellcheck error (i'm wondering if something else could be > > used instead of an underline, like bullets, those icons in small, or > > just a background..) > > Yes now that you say it it does look like a spelling check going on :D Ok > ok this calls for some experimentation. Will edit that > > But the text? What do you think about the text? i like the text :) -- Marco Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Kirigami 1.0 feedback
On Mon, Apr 04, 2016 at 03:40:50PM +0200, Marco Martin wrote: > On Sunday 03 April 2016, you wrote: > > > the patch is fine, but I would prefer the property to be called "opened" > > > that even if doesn't shound great, is the name of an analogous property > > > for OverlayDrawer, so i would like to keep the naming consistent. can > > > you adapt it? or i can push then rename > > > > I'm on my phone at the airport and don't know when I'll have internet for > > my computer again, so feel free to apply the patch as is and the rename > > the property... > > uh, actually the opened property was already there ;) I tried to use it and it didn't work. I must have missed something. Let me try again. > just pushed the "snap" behavior in the overlay sheet that you suggested Just saw that but haven't played with the latest binary, yet. > > > the blurred part may be not possible (i guess that functionality on ios > > > blurs the homescreen, that would have to be done by the operating system > > > itself) > > > > Well, doesn't need to be blurred home screen. Could be the blurred copy of > > what you are moving. Or just an oddly shaded area. Just so it looks > > intentional. > > pushed an alternative version that should behave better (will have the > background image instead of the current gray rectangle) ditto > > That works. In the current version that I sent and with the way > > Subsurface-mobile uses it it works as bread crumbs. Only if you are > > scrolled down on dive list (which hides the crumbs), then a tap "up there" > > gets you back to the top of the list. Which shows the title bar, which > > then works as bread crumbs again since you are already at the top. > > > > It did feel quite intuitive to me. > > i'll probably put the "scroll to top" behavior in the entry of the current > page That would be a nice compromise... Then add the iOS only upper left back button and most of my issues are addressed. Oh, wait, the up to three buttons instead of just one action button... /D ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: A Plasma Vision draft
MORE IRC stuff posted for safekeeping: [16:04] "for multiple device classes" and "computer users" could be better coupled, "device" can be all kind of things, but is first in text, while "computer" might be more bound to "desktop computer" and comes second. that part IMHO needs rework [16:04] or "devices" On Monday, 4 April 2016 16:05:25 CEST Jens Reuterberg wrote: > Ok so some good criticism from IRC that I thought I should document here for > posterity: > > [15:57] - criticism: "Plasma is not good enough for professional > use" [15:58] - people complaining "but this is supposed to be a > just for fun thing, nothing serious! I hate you now!" > [15:58] jensreu: point #3 : This is plasma vision and in 3rd detail > you say.. "A perfomant desktop..." > [15:58] We can meet both with sensible arguments, just needs to be > thought through > [15:59] jensreu: so I would rephrase 3rd detail completely... just > not sure how > [16:01] bshah: would "performant user interface" work better? > [16:01] depends on if we consider Plasma technology or user > interface.. > [16:01] sebas: yeah true, should we soften the "professional" bit? > [16:02] yes, please try (not sure it'll work, but I'm curious what > you can come up with) > > > On Monday, 4 April 2016 15:45:30 CEST Jens Reuterberg wrote: > > Hey, so me and Thomas have been hard at work on this for a while now and I > > think we are at a good point to show what we got. > > > > Please remember that THIS IS JUST A DRAFT! Nothing is set in stone even if > > the document looks fancy (the PNG attached to this email) > > Below is the raw text of it. > > > > /Jens > > > > The Vision is split into three subsections: > > Vision, Details and and three key points. > > The actual Vision: > > Plasma is created to be the primary user interface for multiple device > > classes providing a stable, performant, usable and above all productive > > environment for professional computer users. > > Plasma's feature set is selected for its usefulness in a productive > > context > > with a constant care to user privacy. > > > > Detail 1: Plasma not only promises to never invade its users' privacy > > itself, but also protect against other parties' attempts to spy on them. > > Security is a precondition to privacy, all privacy measures are useless in > > an insecure system. > > Detail 2: Our target audience works with their devices in a professional > > setting. Productivity is key for them and their user interface must give > > them an efficient and swift way of completing tasks. > > Detail 3: A perfomant desktop is the base of any productive environment > > and > > code quality, usability and aesthetic value are relevant to the > > experience. > > Nothing in the interface exists on its own merits but for what it brings > > to > > the user. > > > > The Three Key points: > > Private, Professional, Performant. > > ___ > 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: A Plasma Vision draft
Ok so some good criticism from IRC that I thought I should document here for posterity: [15:57] - criticism: "Plasma is not good enough for professional use" [15:58] - people complaining "but this is supposed to be a just for fun thing, nothing serious! I hate you now!" [15:58] jensreu: point #3 : This is plasma vision and in 3rd detail you say.. "A perfomant desktop..." [15:58] We can meet both with sensible arguments, just needs to be thought through [15:59] jensreu: so I would rephrase 3rd detail completely... just not sure how [16:01] bshah: would "performant user interface" work better? [16:01] depends on if we consider Plasma technology or user interface.. [16:01] sebas: yeah true, should we soften the "professional" bit? [16:02] yes, please try (not sure it'll work, but I'm curious what you can come up with) On Monday, 4 April 2016 15:45:30 CEST Jens Reuterberg wrote: > Hey, so me and Thomas have been hard at work on this for a while now and I > think we are at a good point to show what we got. > > Please remember that THIS IS JUST A DRAFT! Nothing is set in stone even if > the document looks fancy (the PNG attached to this email) > Below is the raw text of it. > > /Jens > > The Vision is split into three subsections: > Vision, Details and and three key points. > The actual Vision: > Plasma is created to be the primary user interface for multiple device > classes providing a stable, performant, usable and above all productive > environment for professional computer users. > Plasma's feature set is selected for its usefulness in a productive context > with a constant care to user privacy. > > Detail 1: Plasma not only promises to never invade its users' privacy > itself, but also protect against other parties' attempts to spy on them. > Security is a precondition to privacy, all privacy measures are useless in > an insecure system. > Detail 2: Our target audience works with their devices in a professional > setting. Productivity is key for them and their user interface must give > them an efficient and swift way of completing tasks. > Detail 3: A perfomant desktop is the base of any productive environment and > code quality, usability and aesthetic value are relevant to the experience. > Nothing in the interface exists on its own merits but for what it brings to > the user. > > The Three Key points: > Private, Professional, Performant. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: A Plasma Vision draft
Thanks for feedback! :) > First, it looks very professional, nice :) > one thing tough , is the underline of the words, the red underline may look > like a spellcheck error (i'm wondering if something else could be used > instead of an underline, like bullets, those icons in small, or just a > background..) Yes now that you say it it does look like a spelling check going on :D Ok ok this calls for some experimentation. Will edit that But the text? What do you think about the text? ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: A Plasma Vision draft
On 4 April 2016 at 14:58, Jens Reuterberg wrote: > Thanks for feedback! :) > >> First, it looks very professional, nice :) >> one thing tough , is the underline of the words, the red underline may look >> like a spellcheck error (i'm wondering if something else could be used >> instead of an underline, like bullets, those icons in small, or just a >> background..) > > Yes now that you say it it does look like a spelling check going on :D Ok ok > this calls for some experimentation. Will edit that > > But the text? What do you think about the text? I'm not convinced performant is a word although it seems to be used for computer jargon http://english.stackexchange.com/questions/38945/what-is-wrong-with-the-word-performant The main part which surprises me is the user profile for professional users. I guess you've thought about who that includes and who it excludes? How does it differentiate us from the competition? Jonathan ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
[Differential] [Accepted] D1314: Workaround problems with Qt::QueuedConnection
sebas accepted this revision. sebas added a reviewer: sebas. sebas added a comment. This revision is now accepted and ready to land. Bah, but okay. :/ REPOSITORY rKSCREENLOCKER KScreenLocker BRANCH no-qt-queued-connection REVISION DETAIL https://phabricator.kde.org/D1314 EMAIL PREFERENCES https://phabricator.kde.org/settings/panel/emailpreferences/ To: graesslin, Plasma, sebas Cc: sebas, plasma-devel ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: A Plasma Vision draft
On Monday 04 April 2016, Jens Reuterberg wrote: > Hey, so me and Thomas have been hard at work on this for a while now and I > think we are at a good point to show what we got. > > Please remember that THIS IS JUST A DRAFT! Nothing is set in stone even if > the document looks fancy (the PNG attached to this email) > Below is the raw text of it. > First, it looks very professional, nice :) one thing tough , is the underline of the words, the red underline may look like a spellcheck error (i'm wondering if something else could be used instead of an underline, like bullets, those icons in small, or just a background..) -- Marco Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Writing to plasma-desktop-appletsrc with init scripts.
Hey all, I'm having a bit of an issue trying to make something work in my environment. Basically, I want widgets to be disabled by default. But if a user chooses to do so, they can unlock the widgets and make their changes. Then, on logout, the widget will automatically be locked again for them so they don't accidentally remove it the next day. So to do that I'd like to use init scripts (/usr/share/kde4/apps/plasma-desktop/init/00-defaultLayout.js) to pass something directly into plasma-desktop-appletsrc when a user first logs in. Specifically, I want to add this to the bottom of the file: [General] immutability[$i]=2 This will lock widgets by default but will allow the users to unlock it (immutability=1) temporarily to add/move widgets. Then the next time they log back in it will be locked (immutability=2) again for them. So, is there some way I can easily easily set immutability[$i]=2 under the [General] section of plasma-desktop-appletsrc? Thanks in advance! ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
[Differential] [Accepted] D1250: [server] Workaround for QtWayland bug https://bugreports.qt.io/browse/QTBUG-52192
sebas accepted this revision. sebas added a reviewer: sebas. This revision is now accepted and ready to land. REPOSITORY rKWAYLAND KWayland BRANCH subsurface-incorrect-mapping REVISION DETAIL https://phabricator.kde.org/D1250 EMAIL PREFERENCES https://phabricator.kde.org/settings/panel/emailpreferences/ To: graesslin, Plasma, sebas Cc: plasma-devel, sebas ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Kirigami 1.0 feedback
On Sunday 03 April 2016, you wrote: > > the patch is fine, but I would prefer the property to be called "opened" > > that even if doesn't shound great, is the name of an analogous property > > for OverlayDrawer, so i would like to keep the naming consistent. can > > you adapt it? or i can push then rename > > I'm on my phone at the airport and don't know when I'll have internet for > my computer again, so feel free to apply the patch as is and the rename > the property... uh, actually the opened property was already there ;) just pushed the "snap" behavior in the overlay sheet that you suggested > > the blurred part may be not possible (i guess that functionality on ios > > blurs the homescreen, that would have to be done by the operating system > > itself) > > Well, doesn't need to be blurred home screen. Could be the blurred copy of > what you are moving. Or just an oddly shaded area. Just so it looks > intentional. pushed an alternative version that should behave better (will have the background image instead of the current gray rectangle) > That works. In the current version that I sent and with the way > Subsurface-mobile uses it it works as bread crumbs. Only if you are > scrolled down on dive list (which hides the crumbs), then a tap "up there" > gets you back to the top of the list. Which shows the title bar, which > then works as bread crumbs again since you are already at the top. > > It did feel quite intuitive to me. i'll probably put the "scroll to top" behavior in the entry of the current page -- Marco Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Review Request 127571: [taskmanager] Stop parsing executables as .desktop files
---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/127571/
---
Review request for Plasma.
Repository: plasma-desktop
Description
---
When a binary is launched via an absolute path, then launcherUrl is not
empty because of [1], even though it is not a .desktop file.
Consequently, when a user right-clicks on the task item, plasmashell
attempts to parse the executable as a .desktop configuration file.
Since this file is obviously not a .desktop file, parsing it as such
will fail, and KConfig floods ~/.xsession-errors with lots of errors.
This can quickly add hundreds of megabytes per right-click...
This patch resolves the problem by not constructing a KDesktopFile if
the launcherUrl is not a .desktop file.
An alternative (and more general) way to get rid of the symptoms is to
modify KDesktopFile / KConfig to stop parsing on the first error and
write the launcherUrl to the error log (or at the very least limit the
number of displayed errors). However, it can be argued that you should
not pass a non-.desktop file to KDesktopFile.
[1]
https://quickgit.kde.org/?p=kde-workspace.git&a=commit&h=3a4b9c85fc21d14838ceac04bb0a70656ee7c701
Diffs
-
applets/taskmanager/plugin/backend.cpp 07ddfbe
Diff: https://git.reviewboard.kde.org/r/127571/diff/
Testing
---
The following steps demonstrate the issue, and confirms that the patch fixes
the bug.
1. Create a simple GUI program, as follows:
```
// Compile: clang++ `pkg-config --cflags --libs Qt5Widgets` app.cpp -o app -g
-fPIE
#include
#include
int main(int argc, char **argv) {
QApplication app(argc, argv);
QLabel label("Some GUI app");
label.show();
return app.exec();
}
```
2. Run the program via an absolute path: $PWD/app.sh
3. Right-click on the task item in the task bar (i.e. the program that you just
launched).
4. Look at ~/.xsession-errors and observe that the following lines were added.
>
"KConfigIni: In file /tmp/some-qt-app/app, line 1: " Invalid entry (missing '=')
"KConfigIni: In file /tmp/some-qt-app/app, line 2: " Invalid entry (missing '=')
"KConfigIni: In file /tmp/some-qt-app/app, line 3: " Invalid entry (missing '=')
"KConfigIni: In file /tmp/some-qt-app/app, line 4: " Invalid entry (missing '=')
"KConfigIni: In file /tmp/some-qt-app/app, line 5: " Invalid entry (missing ']')
"KConfigIni: In file /tmp/some-qt-app/app, line 6: " "Invalid escape sequence
\"\\A\"."
"KConfigIni: In file /tmp/some-qt-app/app, line 6: " "Invalid escape sequence
\"\\\u0001\"."
... hundreds of similar lines
5. Compile plasma-desktop with this patch and restart plasmashell.
6. Repeat step 2 and 3.
7. Look at ~/.xsession-errors and observe that the errors are gone.
Thanks,
Rob Wu
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel
[Differential] [Updated] D1311: Add autotest to verify that screen starts to lock on idle timeout
graesslin added a dependent revision: D1312: Add auto test for grace time. REPOSITORY rKSCREENLOCKER KScreenLocker REVISION DETAIL https://phabricator.kde.org/D1311 EMAIL PREFERENCES https://phabricator.kde.org/settings/panel/emailpreferences/ To: graesslin, Plasma Cc: plasma-devel, sebas ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
[Differential] [Updated] D1312: Add auto test for grace time
graesslin added a dependent revision: D1314: Workaround problems with Qt::QueuedConnection. REPOSITORY rKSCREENLOCKER KScreenLocker BRANCH grace-time-test REVISION DETAIL https://phabricator.kde.org/D1312 EMAIL PREFERENCES https://phabricator.kde.org/settings/panel/emailpreferences/ To: graesslin, Plasma, bshah Cc: plasma-devel, sebas ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
[Differential] [Updated] D1314: Workaround problems with Qt::QueuedConnection
graesslin added dependencies: D1312: Add auto test for grace time, D1311: Add autotest to verify that screen starts to lock on idle timeout. REPOSITORY rKSCREENLOCKER KScreenLocker REVISION DETAIL https://phabricator.kde.org/D1314 EMAIL PREFERENCES https://phabricator.kde.org/settings/panel/emailpreferences/ To: graesslin, Plasma Cc: plasma-devel, sebas ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
[Differential] [Updated] D1312: Add auto test for grace time
graesslin added a dependency: D1311: Add autotest to verify that screen starts to lock on idle timeout. REPOSITORY rKSCREENLOCKER KScreenLocker BRANCH grace-time-test REVISION DETAIL https://phabricator.kde.org/D1312 EMAIL PREFERENCES https://phabricator.kde.org/settings/panel/emailpreferences/ To: graesslin, Plasma, bshah Cc: plasma-devel, sebas ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
[Differential] [Updated] D1311: Add autotest to verify that screen starts to lock on idle timeout
graesslin added a dependent revision: D1314: Workaround problems with Qt::QueuedConnection. REPOSITORY rKSCREENLOCKER KScreenLocker REVISION DETAIL https://phabricator.kde.org/D1311 EMAIL PREFERENCES https://phabricator.kde.org/settings/panel/emailpreferences/ To: graesslin, Plasma Cc: plasma-devel, sebas ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
[Differential] [Request, 11 lines] D1314: Workaround problems with Qt::QueuedConnection
graesslin created this revision. graesslin added a reviewer: Plasma. Restricted Application added a project: Plasma. Restricted Application added a subscriber: plasma-devel. REVISION SUMMARY For unknown reasons our signals with Qt::QueuedConnection are not delivered with Qt 5.6 if the context object is this (KSldApp instance). If we use a different context object (e.g. the sender) it works. The lack of signals not working triggered quite a few bugs, like - grace time not working - global shortcuts not working BUG: 361008 BUG: 361007 REPOSITORY rKSCREENLOCKER KScreenLocker BRANCH no-qt-queued-connection REVISION DETAIL https://phabricator.kde.org/D1314 AFFECTED FILES autotests/ksldtest.cpp ksldapp.cpp EMAIL PREFERENCES https://phabricator.kde.org/settings/panel/emailpreferences/ To: graesslin, Plasma Cc: plasma-devel, sebas ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
[Differential] [Abandoned] D957: Fix userActivity signal when running in kwin_wayland
graesslin abandoned this revision. graesslin added a comment. newer version: https://phabricator.kde.org/D1314 REPOSITORY rKSCREENLOCKER KScreenLocker REVISION DETAIL https://phabricator.kde.org/D957 EMAIL PREFERENCES https://phabricator.kde.org/settings/panel/emailpreferences/ To: graesslin, Plasma Cc: ivan, plasma-devel, sebas ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
[Differential] [Accepted] D1312: Add auto test for grace time
bshah accepted this revision. bshah added a reviewer: bshah. This revision is now accepted and ready to land. REPOSITORY rKSCREENLOCKER KScreenLocker BRANCH grace-time-test REVISION DETAIL https://phabricator.kde.org/D1312 EMAIL PREFERENCES https://phabricator.kde.org/settings/panel/emailpreferences/ To: graesslin, Plasma, bshah Cc: plasma-devel, sebas ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
[Differential] [Commented On] D957: Fix userActivity signal when running in kwin_wayland
graesslin added inline comments. INLINE COMMENTS ksldapp.cpp:612 no it's not the same. It's using Qt::QueuedConnection instead of Qt::AutoConnection. REPOSITORY rKSCREENLOCKER KScreenLocker REVISION DETAIL https://phabricator.kde.org/D957 EMAIL PREFERENCES https://phabricator.kde.org/settings/panel/emailpreferences/ To: graesslin, Plasma Cc: ivan, plasma-devel, sebas ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
[Differential] [Request, 68 lines] D1312: Add auto test for grace time
graesslin created this revision. graesslin added a reviewer: Plasma. Restricted Application added a project: Plasma. Restricted Application added a subscriber: plasma-devel. REVISION SUMMARY This adds a test case for unlocking the screen through user activity during grace time. After the screen is locked user acitivity is simulated using the xtest extension. In addition also a case without grace time is tested. REPOSITORY rKSCREENLOCKER KScreenLocker BRANCH grace-time-test REVISION DETAIL https://phabricator.kde.org/D1312 AFFECTED FILES CMakeLists.txt autotests/CMakeLists.txt autotests/ksldtest.cpp ksldapp.h EMAIL PREFERENCES https://phabricator.kde.org/settings/panel/emailpreferences/ To: graesslin, Plasma Cc: plasma-devel, sebas ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
[Differential] [Accepted] D1282: Subcompositor support in KWin
sebas accepted this revision. sebas added a reviewer: sebas. This revision is now accepted and ready to land. REPOSITORY rKWIN KWin BRANCH subcompositor-arc REVISION DETAIL https://phabricator.kde.org/D1282 EMAIL PREFERENCES https://phabricator.kde.org/settings/panel/emailpreferences/ To: graesslin, Plasma, sebas Cc: plasma-devel, sebas ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Jenkins-kde-ci: plasma-workspace master kf5-qt5 » Linux,gcc - Build # 11 - Still Unstable!
GENERAL INFO
BUILD UNSTABLE
Build URL:
https://build.kde.org/job/plasma-workspace%20master%20kf5-qt5/PLATFORM=Linux,compiler=gcc/11/
Project: PLATFORM=Linux,compiler=gcc
Date of build: Mon, 04 Apr 2016 10:43:30 +
Build duration: 21 min
CHANGE SET
Revision 093b622e855a0f269f782c744812b8235a4222f3 by scripty: (SVN_SILENT made
messages (.desktop file) - always resolve ours)
change: edit templates/ion-dataengine/src/ion-%{APPNAMELC}.desktop
JUNIT RESULTS
Name: (root) Failed: 2 test(s), Passed: 6 test(s), Skipped: 0 test(s), Total: 8
test(s)Failed: TestSuite.org.kde.plasma.analogclock-testFailed:
TestSuite.org.kde.plasma.kickoff-test
COBERTURA RESULTS
Cobertura Coverage Report
PACKAGES 9/9 (100%)FILES 42/47 (89%)CLASSES 42/47 (89%)LINE 1661/2088
(80%)CONDITIONAL 1206/1802 (67%)
By packages
drkonqi.parser
FILES 6/10 (60%)CLASSES 6/10 (60%)LINE 303/423 (72%)CONDITIONAL
478/541 (88%)
drkonqi.tests.backtraceparsertest
FILES 4/4 (100%)CLASSES 4/4 (100%)LINE 74/74 (100%)CONDITIONAL
33/50 (66%)
kioslave.desktop
FILES 1/1 (100%)CLASSES 1/1 (100%)LINE 90/131 (69%)CONDITIONAL
34/50 (68%)
kioslave.desktop.tests
FILES 1/1 (100%)CLASSES 1/1 (100%)LINE 66/66 (100%)CONDITIONAL
26/50 (52%)
klipper
FILES 12/13 (92%)CLASSES 12/13 (92%)LINE 256/384
(67%)CONDITIONAL 109/146 (75%)
klipper.autotests
FILES 4/4 (100%)CLASSES 4/4 (100%)LINE 630/693 (91%)CONDITIONAL
377/742 (51%)
runners.bookmarks
FILES 8/8 (100%)CLASSES 8/8 (100%)LINE 89/159 (56%)CONDITIONAL
34/56 (61%)
runners.bookmarks.browsers
FILES 4/4 (100%)CLASSES 4/4 (100%)LINE 88/93 (95%)CONDITIONAL
84/107 (79%)
runners.bookmarks.tests
FILES 2/2 (100%)CLASSES 2/2 (100%)LINE 65/65 (100%)CONDITIONAL
31/60 (52%)___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Kirigami 1.0 feedback
On Sunday, April 03, 2016 11:35:29 PM Dirk Hohndel wrote: > BUT (and you knew there would be one): Swipe for "back key" is hard for > us. We can't really do it when looking at dive details, and it feels > really alien to iOS users. And the back key on iOS is always, always, > always, in every app, even the crazy ones, in the top left corner. > > My current thinging is that I may end up doing just that in the iOS > version. Having a back button somewhere that isn't a corner feels very > weird when I play with it. I see why you don't want a button in a bottom > corner. So I think I will just implement my own back key in > Subsurface-mobile and only enable this on iOS and have it in the top left > corner. I wish Kirigami would consider that ALL Kirigami apps that run on > iOS will have this very same situation and just add the standard back > button on iOS in its standard position - but it's your project, your > choice. I can see that making sense, though. "that" means: on ios, top-left has a back button, all other target OSes have this functionality native, elsewhere (Android, for example, has the back button). To me, that is consistent enough across OSes, while still respecting OS- specific mechanisms. -- sebas http://www.kde.org | http://vizZzion.org ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Minutes Monday Plasma Meeting
On 04/04/2016 07:42 PM, Sebastian Kügler wrote: * Planning bug day (with Jens and Bhushan) We've (Sho_, bshah, jensreu) scheduled a planning meeting about the Bug Day on April 12th at noon in #plasma - feel free to swing by if you want to join the planning! Cheers, Eike ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Jenkins-kde-ci: plasma-desktop master kf5-qt5 » Linux,gcc - Build # 14 - Failure!
GENERAL INFO BUILD FAILURE Build URL: https://build.kde.org/job/plasma-desktop%20master%20kf5-qt5/PLATFORM=Linux,compiler=gcc/14/ Project: PLATFORM=Linux,compiler=gcc Date of build: Mon, 04 Apr 2016 10:43:15 + Build duration: 2 min 38 sec CHANGE SET Revision ecd9ea6719abaa0311fdaddf988a2b10b612605a by scripty: (SVN_SILENT made messages (.desktop file) - always resolve ours) change: edit runners/plasma-desktop/plasma-runner-plasma-desktop.desktop change: edit runners/kwin/plasma-runner-kwin.desktop ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Minutes Monday Plasma Meeting
Minutes Plasma 'hangout', 4-4-2016, 12:00 CET Present: mgraesslin, kbroulik, bshah, Sho, notmart, Riddell, jensreuterberg, sebas mgraesslin: * subcompositor support working better, KWin review is up https:// phabricator.kde.org/D1282 ** OpenGL support is hacked in, but not implemented correctly yet (no WindowQuads) ** input still missing ** many bugs in Qt found with workarounds implemented in KWayland *** https://bugreports.qt.io/browse/QTBUG-51640 *** https://bugreports.qt.io/browse/QTBUG-52092 *** https://bugreports.qt.io/browse/QTBUG-52118 *** https://bugreports.qt.io/browse/QTBUG-52192 * Input events added to debug console - comparable to xev * april-fool: https://phabricator.kde.org/D1283 - might work as easter egg, opinions? * investigating a few screenlocker issues, apparently no Qt::QueuedConnection is working kbroulik: * will represent KDE at http://luga.de/Aktionen/LIT-2016/abstracts.html#kde bshah: * Plasma Mobile planning meeting: http://doodle.com/poll/8x983kg6s5p6hw48 -- please join! * Working on new imaging / OS stack for Plasma mobile (bare Cyanogenmod + Debian chroot) jensreuterberg: * doing print / promo material * finished Plasma vision draft promo package Sho: * working towards feature parity for libtaskmanager on wayland * Bugfixing * Planning bug day (with Jens and Bhushan) notmart: * New systray: better reordering of items with less javascript, notifications always in first position to keep old behavior * added tests to https://git.reviewboard.kde.org/r/127260/ ** thinking at an alternative way to load system icons via Plasma::Svg * kirigami, better behavior for Sheet component * work to make kirigami gallery builable on Android, preliminar: http:// notmart.org/misc/kirigami/QtApp-debug.apk * global drawer: a single scroll view for landscape mode * better behavior for the autohide of titlebar Riddell: * Plasma 5.6.1 is out * 5.6.2 due tomorrow * Neon builds for stable and unstable branches are being built ( http:// files.kde.org/neon/ ) * Plasma release schedule is done (5.7 is freezing start of June, release end of June) * https://community.kde.org/Schedules/Plasma_5 sebas: * refactoring of kwin's drm backend merged ( https://phabricator.kde.org/D1168 ) * fixed a glitch in desktop grid ( https://phabricator.kde.org/D1209 ) * rough implementation of DPMS in kscreen-doctor (wayland-only) * about to merge dpms branch into libkscreen (part of kscreen-doctor, will be reviewed later on) * Wrote Dot story about Plasma sprint ( https://dot.kde.org/2016/03/23/plasma-team-gets-physical ) * installed new laptop * reviewed lots of patches * working with Thomas and Lydia to finalize / cement KDE vision -- sebas http://www.kde.org | http://vizZzion.org ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
[Differential] [Accepted] D1220: [Applet / Wallpaper Configuration] Load config page with initial cfg properties already set
mart accepted this revision. mart added a reviewer: mart. This revision is now accepted and ready to land. REPOSITORY rPLASMADESKTOP Plasma Desktop REVISION DETAIL https://phabricator.kde.org/D1220 EMAIL PREFERENCES https://phabricator.kde.org/settings/panel/emailpreferences/ To: broulik, Plasma, mart Cc: plasma-devel, sebas ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
[Differential] [Accepted] D1221: [Slideshow Wallpaper] Fix seconds always set to 1 when opening config dialog
mart accepted this revision. mart added a reviewer: mart. This revision is now accepted and ready to land. REPOSITORY rPLASMAWORKSPACE Plasma Workspace REVISION DETAIL https://phabricator.kde.org/D1221 EMAIL PREFERENCES https://phabricator.kde.org/settings/panel/emailpreferences/ To: broulik, Plasma, mart Cc: plasma-devel, sebas ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Jenkins-kde-ci: plasma-workspace master kf5-qt5 » Linux,gcc - Build # 10 - Still Unstable!
GENERAL INFO BUILD UNSTABLE Build URL: https://build.kde.org/job/plasma-workspace%20master%20kf5-qt5/PLATFORM=Linux,compiler=gcc/10/ Project: PLATFORM=Linux,compiler=gcc Date of build: Mon, 04 Apr 2016 08:39:11 + Build duration: 11 min CHANGE SET Revision d0c70ea70047e48793a10eae90aa14ff146679ec by Marco Martin: (Models import not used anymore) change: edit applets/systemtray/package/contents/ui/items/AbstractItem.qml JUNIT RESULTS Name: (root) Failed: 2 test(s), Passed: 6 test(s), Skipped: 0 test(s), Total: 8 test(s)Failed: TestSuite.org.kde.plasma.analogclock-testFailed: TestSuite.org.kde.plasma.kickoff-test COBERTURA RESULTS Cobertura Coverage Report PACKAGES 9/9 (100%)FILES 42/47 (89%)CLASSES 42/47 (89%)LINE 1661/2088 (80%)CONDITIONAL 1206/1802 (67%) By packages drkonqi.parser FILES 6/10 (60%)CLASSES 6/10 (60%)LINE 303/423 (72%)CONDITIONAL 478/541 (88%) drkonqi.tests.backtraceparsertest FILES 4/4 (100%)CLASSES 4/4 (100%)LINE 74/74 (100%)CONDITIONAL 33/50 (66%) kioslave.desktop FILES 1/1 (100%)CLASSES 1/1 (100%)LINE 90/131 (69%)CONDITIONAL 34/50 (68%) kioslave.desktop.tests FILES 1/1 (100%)CLASSES 1/1 (100%)LINE 66/66 (100%)CONDITIONAL 26/50 (52%) klipper FILES 12/13 (92%)CLASSES 12/13 (92%)LINE 256/384 (67%)CONDITIONAL 109/146 (75%) klipper.autotests FILES 4/4 (100%)CLASSES 4/4 (100%)LINE 630/693 (91%)CONDITIONAL 377/742 (51%) runners.bookmarks FILES 8/8 (100%)CLASSES 8/8 (100%)LINE 89/159 (56%)CONDITIONAL 34/56 (61%) runners.bookmarks.browsers FILES 4/4 (100%)CLASSES 4/4 (100%)LINE 88/93 (95%)CONDITIONAL 84/107 (79%) runners.bookmarks.tests FILES 2/2 (100%)CLASSES 2/2 (100%)LINE 65/65 (100%)CONDITIONAL 31/60 (52%)___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
[Differential] [Request, 52 lines] D1311: Add autotest to verify that screen starts to lock on idle timeout
graesslin created this revision. graesslin added a reviewer: Plasma. Herald added a project: Plasma. Herald added a subscriber: plasma-devel. REVISION SUMMARY This adds a new auto test to verify that gets locked when the idle timeout is reached. Unfortunately we cannot just modify the configuration as the minimum idle timout possible through the configuration is one minute and we don't want to wait that long on the CI system. Thus two new methods are exposed to modify the internal idle id from the auto test. TEST PLAN Tested with an Xvfb REPOSITORY rKSCREENLOCKER KScreenLocker BRANCH idle-test REVISION DETAIL https://phabricator.kde.org/D1311 AFFECTED FILES autotests/CMakeLists.txt autotests/ksldtest.cpp ksldapp.h EMAIL PREFERENCES https://phabricator.kde.org/settings/panel/emailpreferences/ To: graesslin, Plasma Cc: plasma-devel, sebas ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
[Differential] [Closed] D1250: [server] Workaround for QtWayland bug https://bugreports.qt.io/browse/QTBUG-52192
This revision was automatically updated to reflect the committed changes. Closed by commit rKWAYLAND85209f3da17e: [server] Workaround for QtWayland bug https://bugreports.qt.io/browse/QTBUG… (authored by graesslin). REPOSITORY rKWAYLAND KWayland CHANGES SINCE LAST UPDATE https://phabricator.kde.org/D1250?vs=3004&id=3118 REVISION DETAIL https://phabricator.kde.org/D1250 AFFECTED FILES autotests/client/test_wayland_subsurface.cpp src/server/surface_interface.cpp src/server/surface_interface_p.h EMAIL PREFERENCES https://phabricator.kde.org/settings/panel/emailpreferences/ To: graesslin, Plasma, sebas Cc: plasma-devel, sebas ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
[Differential] [Closed] D1261: [server] Don't emit unmapped if the Surface wasn't mapped
This revision was automatically updated to reflect the committed changes. Closed by commit rKWAYLAND62a43f0c0cc8: [server] Don't emit unmapped if the Surface wasn't mapped (authored by graesslin). REPOSITORY rKWAYLAND KWayland CHANGES SINCE LAST UPDATE https://phabricator.kde.org/D1261?vs=3022&id=3117 REVISION DETAIL https://phabricator.kde.org/D1261 AFFECTED FILES autotests/client/test_wayland_surface.cpp src/server/surface_interface.cpp EMAIL PREFERENCES https://phabricator.kde.org/settings/panel/emailpreferences/ To: graesslin, Plasma, sebas Cc: plasma-devel, sebas ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
[Differential] [Closed] D1281: [server] Add damage tracking feature to SurfaceInterface
This revision was automatically updated to reflect the committed changes. Closed by commit rKWAYLAND506bf3a31225: [server] Add damage tracking feature to SurfaceInterface (authored by graesslin). CHANGED PRIOR TO COMMIT https://phabricator.kde.org/D1281?vs=3053&id=3119#toc REPOSITORY rKWAYLAND KWayland CHANGES SINCE LAST UPDATE https://phabricator.kde.org/D1281?vs=3053&id=3119 REVISION DETAIL https://phabricator.kde.org/D1281 AFFECTED FILES autotests/client/test_wayland_surface.cpp src/server/surface_interface.cpp src/server/surface_interface.h src/server/surface_interface_p.h EMAIL PREFERENCES https://phabricator.kde.org/settings/panel/emailpreferences/ To: graesslin, Plasma, sebas Cc: sebas, plasma-devel ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
[Differential] [Closed] D1248: [autotest] Add test case for mapping/unmapping surfaces in a sub-surface tree
This revision was automatically updated to reflect the committed changes. Closed by commit rKWAYLAND6e9560662afe: [autotest] Add test case for mapping/unmapping surfaces in a sub-surface tree (authored by graesslin). REPOSITORY rKWAYLAND KWayland CHANGES SINCE LAST UPDATE https://phabricator.kde.org/D1248?vs=3001&id=3116 REVISION DETAIL https://phabricator.kde.org/D1248 AFFECTED FILES autotests/client/test_wayland_subsurface.cpp EMAIL PREFERENCES https://phabricator.kde.org/settings/panel/emailpreferences/ To: graesslin, Plasma, bshah Cc: plasma-devel, sebas ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
[Differential] [Updated] D1281: [server] Add damage tracking feature to SurfaceInterface
graesslin marked 3 inline comments as done. REPOSITORY rKWAYLAND KWayland BRANCH surface-tracked-damage REVISION DETAIL https://phabricator.kde.org/D1281 EMAIL PREFERENCES https://phabricator.kde.org/settings/panel/emailpreferences/ To: graesslin, Plasma, sebas Cc: sebas, plasma-devel ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
