Re: RFC - Removing System Bell KCM
On Monday 12 May 2014, Martin Gräßlin wrote: I don't think it's something relevant anymore, and I'm not entirely convinced this code even works. I thought it's still used by the accessibility code. If that's not the case: go, go, go! yes, good point,should be checked if is used in any ways for accessibility reasons. i have no objections otherwise, but accessibility is important (controls for it may even be stuffed in the accessibility kcm if that's the case) -- Marco Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Where we are now... (VDG)
On Sunday 11 May 2014, Jens Reuterberg wrote: (ok third time trying to send this email - so I'm loosing confidence in my technical ability here) Ok so, via Andrew The Mythical Design Machine Lake - heres a screen shot of where Plasma Next is now. Yes - we in the VDG are the awesomeness and you can buy us candy now. http://wstaw.org/m/2014/05/11/loving_it.png Ok, now I'm all wet :p so of all that, let's see what we have, what we don't and how we can make shippable * plasma theme: check * wallpaper: once is ready, where we do put it? * widget style: we have the qtcurve settings, i failed as well to contact the (supposedly new) maintainers * icons: those should also be imported somewhere * am i missing something? -- Marco Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Where we are now... (VDG)
On Mon, May 12, 2014 at 10:22 AM, Marco Martin notm...@gmail.com wrote: so of all that, let's see what we have, what we don't and how we can make shippable * plasma theme: check * wallpaper: once is ready, where we do put it? * widget style: we have the qtcurve settings, i failed as well to contact the (supposedly new) maintainers * icons: those should also be imported somewhere * am i missing something? windeco - that's also done for aurorae, I'm unsure where though (breeze repo?) Cheers -- Martin Klapetek | KDE Developer ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Where we are now... (VDG)
On Monday 12 May 2014, Martin Klapetek wrote: (supposedly new) maintainers * icons: those should also be imported somewhere * am i missing something? windeco - that's also done for aurorae, I'm unsure where though (breeze repo?) breze repo (so already ok for release) contains: * cursors * aurorae windeco * qml style -- Marco Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Where we are now... (VDG)
There's an issue with the cursors though and that is that they only exist in one size right now which is causing merry hell for people with HDPI screens On Monday 12 May 2014 10.48.05 Marco Martin wrote: On Monday 12 May 2014, Martin Klapetek wrote: (supposedly new) maintainers * icons: those should also be imported somewhere * am i missing something? windeco - that's also done for aurorae, I'm unsure where though (breeze repo?) breze repo (so already ok for release) contains: * cursors * aurorae windeco * qml style ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Where we are now... (VDG)
On Monday 12 May 2014, Jens Reuterberg wrote: There's an issue with the cursors though and that is that they only exist in one size right now which is causing merry hell for people with HDPI screens i'm looking to see if generating a double size version may be scriptable enoough -- Marco Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Review Request 118094: Sort screens in plasma from left to right
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/118094/ --- Review request for Plasma, Aleix Pol Gonzalez and Martin Gräßlin. Repository: plasma-workspace Description --- Even though numbered outputs have their flaws, we still use them pretty much everywhere and everywhere we use outputs numbered from left to right, so let's use the same in Plasma. This seems to fix most of my multiscreen issues now, namely bug 334500. Also: mgraesslin I don't know - having primary as 0 is a bit strange mgraesslin 1, 2, 3, 0 mgraesslin ? mgraesslin that was from left to right Diffs - shell/shellcorona.cpp b0b139d Diff: https://git.reviewboard.kde.org/r/118094/diff/ Testing --- Thanks, Martin Klapetek ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: RFC: Change Krunner's default key shortcut for Next
Collecting the input So Ctrl+space Meta+space are already reserved, Alt+space is only problem for Gnome as it's used there but we don't intend to run KRunner in Gnome so we are fine. So if there are no objections, I'll change the primary shortcut to Alt+space while keeping Alt+F2 as a secondary one. Cheers -- Martin Klapetek | KDE Developer ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 118061: Plasma-mobile: Add an initial shell package
On May 10, 2014, 5:45 a.m., Aleix Pol Gonzalez wrote: Wouldn't it be better to let the Desktop settle down a bit before we start to fork things out? Actually we should find ways to share code and not having to actually fork these, which is really counter-productive. Marco Martin wrote: That's the whole point of having shell packages. One thing that may be improved in the future is introducing a fallback mechanism between packages to not have to copy all, but i'm quite on the fence to that, and i wouldn't do it if not after it has to be provn really, really necessary. And without attempts now I'll never really know for sure what is missing in the whole mechanism. Furthermore, the gsoc on active is *now* and not in a few months time, the mediacenter gscoc is *now* and not in a few months time. Aleix Pol Gonzalez wrote: Well, we already have a buggy fork in plasmate. I've seen problems that I've fixed to plasma-shell appearing over there. I don't see why Active is going to be different. Aleix Pol Gonzalez wrote: FWIW, we don't need to inherit from different shells, we can actually share code through QML components too. Well, I think both plasmate and active/mediacenter cases are totally different.. Plasmoidviewer shares similar code with desktop shell but I don't think active/mediacenter/any other shell will share code with the desktop. - Bhushan --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/118061/#review57664 --- On May 10, 2014, 9:55 p.m., Antonis Tsiapaliokas wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/118061/ --- (Updated May 10, 2014, 9:55 p.m.) Review request for Plasma. Repository: plasma-mobile Description --- Add a copy of desktop shell package but remove the stuff that we don't need. Like the contextmenu, panelconfiguration and the toolbox Diffs - CMakeLists.txt c7e3797 activeshellpackage/CMakeLists.txt PRE-CREATION activeshellpackage/package/contents/activitymanager/ActivityBrowser.qml PRE-CREATION activeshellpackage/package/contents/activitymanager/ActivityCreationDialog.qml PRE-CREATION activeshellpackage/package/contents/activitymanager/ActivityDeletionDialog.qml PRE-CREATION activeshellpackage/package/contents/activitymanager/ActivityItem.qml PRE-CREATION activeshellpackage/package/contents/activitymanager/ActivityList.qml PRE-CREATION activeshellpackage/package/contents/activitymanager/ActivityManager.qml PRE-CREATION activeshellpackage/package/contents/activitymanager/ControlButton.qml PRE-CREATION activeshellpackage/package/contents/activitymanager/Heading.qml PRE-CREATION activeshellpackage/package/contents/activitymanager/StoppedActivityItem.qml PRE-CREATION activeshellpackage/package/contents/activitymanager/WindowPreview.qml PRE-CREATION activeshellpackage/package/contents/applet/AppletError.qml PRE-CREATION activeshellpackage/package/contents/applet/CompactApplet.qml PRE-CREATION activeshellpackage/package/contents/applet/DefaultCompactRepresentation.qml PRE-CREATION activeshellpackage/package/contents/configuration/AppletConfiguration.qml PRE-CREATION activeshellpackage/package/contents/configuration/ConfigCategoryDelegate.qml PRE-CREATION activeshellpackage/package/contents/configuration/ConfigurationContainmentActions.qml PRE-CREATION activeshellpackage/package/contents/configuration/ConfigurationContainmentAppearance.qml PRE-CREATION activeshellpackage/package/contents/configuration/ConfigurationShortcuts.qml PRE-CREATION activeshellpackage/package/contents/configuration/ContainmentConfiguration.qml PRE-CREATION activeshellpackage/package/contents/configuration/MouseEventInputButton.qml PRE-CREATION activeshellpackage/package/contents/defaults PRE-CREATION activeshellpackage/package/contents/explorer/AppletDelegate.qml PRE-CREATION activeshellpackage/package/contents/explorer/Tooltip.qml PRE-CREATION activeshellpackage/package/contents/explorer/WidgetExplorer.qml PRE-CREATION activeshellpackage/package/contents/layout.js PRE-CREATION activeshellpackage/package/contents/loader.qml PRE-CREATION activeshellpackage/package/contents/views/Desktop.qml PRE-CREATION activeshellpackage/package/contents/views/Panel.qml PRE-CREATION activeshellpackage/package/metadata.desktop PRE-CREATION qmlpackages/CMakeLists.txt d277441 Diff: https://git.reviewboard.kde.org/r/118061/diff/ Testing --- Thanks, Antonis Tsiapaliokas
Re: Review Request 118094: Sort screens in plasma from left to right
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/118094/ --- (Updated May 12, 2014, 12:39 p.m.) Review request for Plasma, Aleix Pol Gonzalez and Martin Gräßlin. Repository: plasma-workspace Description (updated) --- Even though numbered outputs have their flaws, we still use them pretty much everywhere and everywhere we use outputs numbered from left to right, so let's use the same in Plasma. This seems to fix most of my multiscreen issues now, namely bug 334500 and bug 334502. Also: mgraesslin I don't know - having primary as 0 is a bit strange mgraesslin 1, 2, 3, 0 mgraesslin ? mgraesslin that was from left to right Diffs - shell/shellcorona.cpp b0b139d Diff: https://git.reviewboard.kde.org/r/118094/diff/ Testing --- Thanks, Martin Klapetek ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 118061: Plasma-mobile: Add an initial shell package
On May 10, 2014, 12:15 a.m., Aleix Pol Gonzalez wrote: Wouldn't it be better to let the Desktop settle down a bit before we start to fork things out? Actually we should find ways to share code and not having to actually fork these, which is really counter-productive. Marco Martin wrote: That's the whole point of having shell packages. One thing that may be improved in the future is introducing a fallback mechanism between packages to not have to copy all, but i'm quite on the fence to that, and i wouldn't do it if not after it has to be provn really, really necessary. And without attempts now I'll never really know for sure what is missing in the whole mechanism. Furthermore, the gsoc on active is *now* and not in a few months time, the mediacenter gscoc is *now* and not in a few months time. Aleix Pol Gonzalez wrote: Well, we already have a buggy fork in plasmate. I've seen problems that I've fixed to plasma-shell appearing over there. I don't see why Active is going to be different. Aleix Pol Gonzalez wrote: FWIW, we don't need to inherit from different shells, we can actually share code through QML components too. Bhushan Shah wrote: Well, I think both plasmate and active/mediacenter cases are totally different.. Plasmoidviewer shares similar code with desktop shell but I don't think active/mediacenter/any other shell will share code with the desktop. Alright, then maybe I'm being overprotective. I understand plasmoidviewer is a special case (although I believe it shouldn't be forking plasma-shell code). Either way, if this is the way it's going to be it would be good to remind how important it is to share code. As for the review, consider my comment discarded. - Aleix --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/118061/#review57664 --- On May 10, 2014, 4:25 p.m., Antonis Tsiapaliokas wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/118061/ --- (Updated May 10, 2014, 4:25 p.m.) Review request for Plasma. Repository: plasma-mobile Description --- Add a copy of desktop shell package but remove the stuff that we don't need. Like the contextmenu, panelconfiguration and the toolbox Diffs - CMakeLists.txt c7e3797 activeshellpackage/CMakeLists.txt PRE-CREATION activeshellpackage/package/contents/activitymanager/ActivityBrowser.qml PRE-CREATION activeshellpackage/package/contents/activitymanager/ActivityCreationDialog.qml PRE-CREATION activeshellpackage/package/contents/activitymanager/ActivityDeletionDialog.qml PRE-CREATION activeshellpackage/package/contents/activitymanager/ActivityItem.qml PRE-CREATION activeshellpackage/package/contents/activitymanager/ActivityList.qml PRE-CREATION activeshellpackage/package/contents/activitymanager/ActivityManager.qml PRE-CREATION activeshellpackage/package/contents/activitymanager/ControlButton.qml PRE-CREATION activeshellpackage/package/contents/activitymanager/Heading.qml PRE-CREATION activeshellpackage/package/contents/activitymanager/StoppedActivityItem.qml PRE-CREATION activeshellpackage/package/contents/activitymanager/WindowPreview.qml PRE-CREATION activeshellpackage/package/contents/applet/AppletError.qml PRE-CREATION activeshellpackage/package/contents/applet/CompactApplet.qml PRE-CREATION activeshellpackage/package/contents/applet/DefaultCompactRepresentation.qml PRE-CREATION activeshellpackage/package/contents/configuration/AppletConfiguration.qml PRE-CREATION activeshellpackage/package/contents/configuration/ConfigCategoryDelegate.qml PRE-CREATION activeshellpackage/package/contents/configuration/ConfigurationContainmentActions.qml PRE-CREATION activeshellpackage/package/contents/configuration/ConfigurationContainmentAppearance.qml PRE-CREATION activeshellpackage/package/contents/configuration/ConfigurationShortcuts.qml PRE-CREATION activeshellpackage/package/contents/configuration/ContainmentConfiguration.qml PRE-CREATION activeshellpackage/package/contents/configuration/MouseEventInputButton.qml PRE-CREATION activeshellpackage/package/contents/defaults PRE-CREATION activeshellpackage/package/contents/explorer/AppletDelegate.qml PRE-CREATION activeshellpackage/package/contents/explorer/Tooltip.qml PRE-CREATION activeshellpackage/package/contents/explorer/WidgetExplorer.qml PRE-CREATION activeshellpackage/package/contents/layout.js PRE-CREATION activeshellpackage/package/contents/loader.qml PRE-CREATION
Re: Review Request 118094: Sort screens in plasma from left to right
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/118094/#review57757 --- That's not correct. Primary, at least, needs to have special treatment and get the 0-named containment assigned always, which is what the current naming is about. As for the rest of the screens it's probably best to sort them rather than keeping them as they come like now. Furthermore, you'll want also to insert the new screens in the correct position then, and shift the rest of the screens. - Aleix Pol Gonzalez On May 12, 2014, 10:39 a.m., Martin Klapetek wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/118094/ --- (Updated May 12, 2014, 10:39 a.m.) Review request for Plasma, Aleix Pol Gonzalez and Martin Gräßlin. Repository: plasma-workspace Description --- Even though numbered outputs have their flaws, we still use them pretty much everywhere and everywhere we use outputs numbered from left to right, so let's use the same in Plasma. This seems to fix most of my multiscreen issues now, namely bug 334500 and bug 334502. Also: mgraesslin I don't know - having primary as 0 is a bit strange mgraesslin 1, 2, 3, 0 mgraesslin ? mgraesslin that was from left to right Diffs - shell/shellcorona.cpp b0b139d Diff: https://git.reviewboard.kde.org/r/118094/diff/ Testing --- Thanks, Martin Klapetek ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: RFC: Change Krunner's default key shortcut for Next
Do it. Sooner we do it, the earlier we'll know if there's any problems. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Minutes Monday Plasma hangout
Present: Antonis, David, Ivan, Jens, Jonathan, Marco, Martin G., Martin K., Vishesh, Sebastian Antonis - has started the work to port Plasma Active to Plasma Next, - started with a forked shell package David: - Has been doing SDDM fixes, merge pending - Some files in plasma-framework need relicensing (GPL - LGPL) Ivan: - has brought back resource linking with Activities (more features than in 4.x) - working on the resource model for QML Jens: - Is having breakfast - Work going on on categorizing systemsettings - Starting with promo work for Plasma - Mouse cursors work progressing Jonathan: - Worked on Baloo and Milou translations - Even more translations - co-installability of artwork Marco: - Various bugfixes in Plasma - Configuration for systemtray applets - Will work on moving applets between containments Martin G: - Working on annoying rendering bugs - Other bugfixes - Upstreamed client-side-decoration bugs to GTK devs Martin K: - Bugfixing and triaging in Frameworks and Plasma - Fixes in calendar and clock - Work on regressions in on-screen positioning of notifications Vishesh: - Ported runners away from kde4support - Ported some missing runners - Fixed some krunner bugs - Work on Baloo user feedback Sebastian: - Formats KCM implemented, in review now - Testing Neon5, have laptop for that purpose now - Various bugfixes and cleanups - Plasma 2 / Next / 5 naming discussion -- sebas http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9 ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 118089: Fix build: add spaces in string concatenation
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/118089/#review57759 --- Ship it! Ship It! - Sebastian Kügler On May 12, 2014, 12:40 a.m., Alexander Potashev wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/118089/ --- (Updated May 12, 2014, 12:40 a.m.) Review request for Plasma. Repository: plasma-desktop Description --- Without the space, C++ compiler (e.g. GCC 4.7.3) treats /DISABLED_FONTS as a string literal suffix instead of string concatenation. Diffs - kcms/kfontinst/dbus/Folder.cpp ba9b45f Diff: https://git.reviewboard.kde.org/r/118089/diff/ Testing --- Successful build using kdesrc-build. Thanks, Alexander Potashev ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 118094: Sort screens in plasma from left to right
On May 12, 2014, 1:04 p.m., Aleix Pol Gonzalez wrote: That's not correct. Primary, at least, needs to have special treatment and get the 0-named containment assigned always, which is what the current naming is about. As for the rest of the screens it's probably best to sort them rather than keeping them as they come like now. Furthermore, you'll want also to insert the new screens in the correct position then, and shift the rest of the screens. That's not correct. Primary, at least, needs to have special treatment and get the 0-named containment assigned always, which is what the current naming is about. Why? As for the rest of the screens it's probably best to sort them rather than keeping them as they come like now. They are sorted from left to right...or what sorting you have in mind? Furthermore, you'll want also to insert the new screens in the correct position then, and shift the rest of the screens. Yes. - Martin --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/118094/#review57757 --- On May 12, 2014, 12:39 p.m., Martin Klapetek wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/118094/ --- (Updated May 12, 2014, 12:39 p.m.) Review request for Plasma, Aleix Pol Gonzalez and Martin Gräßlin. Repository: plasma-workspace Description --- Even though numbered outputs have their flaws, we still use them pretty much everywhere and everywhere we use outputs numbered from left to right, so let's use the same in Plasma. This seems to fix most of my multiscreen issues now, namely bug 334500 and bug 334502. Also: mgraesslin I don't know - having primary as 0 is a bit strange mgraesslin 1, 2, 3, 0 mgraesslin ? mgraesslin that was from left to right Diffs - shell/shellcorona.cpp b0b139d Diff: https://git.reviewboard.kde.org/r/118094/diff/ Testing --- Thanks, Martin Klapetek ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 118094: Sort screens in plasma from left to right
On May 12, 2014, 11:04 a.m., Aleix Pol Gonzalez wrote: That's not correct. Primary, at least, needs to have special treatment and get the 0-named containment assigned always, which is what the current naming is about. As for the rest of the screens it's probably best to sort them rather than keeping them as they come like now. Furthermore, you'll want also to insert the new screens in the correct position then, and shift the rest of the screens. Martin Klapetek wrote: That's not correct. Primary, at least, needs to have special treatment and get the 0-named containment assigned always, which is what the current naming is about. Why? As for the rest of the screens it's probably best to sort them rather than keeping them as they come like now. They are sorted from left to right...or what sorting you have in mind? Furthermore, you'll want also to insert the new screens in the correct position then, and shift the rest of the screens. Yes. Because if the user has set up his first containment with all panels, we expect him to have it in the screen he explicitly said it's the primary one. This way he'll be able to put the most attention to the screen he selected and get the notifications, the task manager and whatnot. Assuming all this goes to the left-most screen and disregarding the primary setting is not acceptable, considering the current design. - Aleix --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/118094/#review57757 --- On May 12, 2014, 10:39 a.m., Martin Klapetek wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/118094/ --- (Updated May 12, 2014, 10:39 a.m.) Review request for Plasma, Aleix Pol Gonzalez and Martin Gräßlin. Repository: plasma-workspace Description --- Even though numbered outputs have their flaws, we still use them pretty much everywhere and everywhere we use outputs numbered from left to right, so let's use the same in Plasma. This seems to fix most of my multiscreen issues now, namely bug 334500 and bug 334502. Also: mgraesslin I don't know - having primary as 0 is a bit strange mgraesslin 1, 2, 3, 0 mgraesslin ? mgraesslin that was from left to right Diffs - shell/shellcorona.cpp b0b139d Diff: https://git.reviewboard.kde.org/r/118094/diff/ Testing --- Thanks, Martin Klapetek ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Layout.js in shell package is not working
Hello, In a desktop shell package layout.js is not working as it should. Its failing at this line, var desktop = new Activity with error message telling Activity is not undefined. So changing wallpaper plugin of desktop or adding applet with addWidget is not possible. What is solution of this? Thanks -- 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-shell] [Bug 328593] Dual screen has regressed in plasma-shell
https://bugs.kde.org/show_bug.cgi?id=328593 Bug 328593 depends on bug 334502, which changed state. Bug 334502 Summary: Panel positions in multiscreen are not remembered/placed depending on mouse position https://bugs.kde.org/show_bug.cgi?id=334502 What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |INVALID -- You are receiving this mail because: You are on the CC list for the bug. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
[plasma-shell] [Bug 328593] Dual screen has regressed in plasma-shell
https://bugs.kde.org/show_bug.cgi?id=328593 Bug 328593 depends on bug 334502, which changed state. Bug 334502 Summary: Panel positions in multiscreen are not remembered/placed depending on mouse position https://bugs.kde.org/show_bug.cgi?id=334502 What|Removed |Added Status|RESOLVED|REOPENED Resolution|INVALID |--- -- You are receiving this mail because: You are on the CC list for the bug. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Layout.js in shell package is not working
i guess notmart has changed something on plasma scripting , try to read this : http://mail.kde.org/pipermail/plasma-devel/2014-March/029614.html 2014-05-12 13:20 GMT+02:00 Bhushan Shah bhus...@gmail.com: Hello, In a desktop shell package layout.js is not working as it should. Its failing at this line, var desktop = new Activity with error message telling Activity is not undefined. So changing wallpaper plugin of desktop or adding applet with addWidget is not possible. What is solution of this? Thanks -- 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-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Layout.js in shell package is not working
On Mon, May 12, 2014 at 5:04 PM, Nowardev-Team nowar...@gmail.com wrote: i guess notmart has changed something on plasma scripting , try to read this : http://mail.kde.org/pipermail/plasma-devel/2014-March/029614.html Yeah but thing is it is not updated in the plasma desktop shell.. notmart right? -- 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
Dual Monitors
Is there a tool for configuring multiple monitors in Plasma2? as kscreen appears to be gone? -- Lindsay signature.asc Description: This is a digitally signed message part. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 118094: Sort screens in plasma from left to right
On May 12, 2014, 1:04 p.m., Aleix Pol Gonzalez wrote: That's not correct. Primary, at least, needs to have special treatment and get the 0-named containment assigned always, which is what the current naming is about. As for the rest of the screens it's probably best to sort them rather than keeping them as they come like now. Furthermore, you'll want also to insert the new screens in the correct position then, and shift the rest of the screens. Martin Klapetek wrote: That's not correct. Primary, at least, needs to have special treatment and get the 0-named containment assigned always, which is what the current naming is about. Why? As for the rest of the screens it's probably best to sort them rather than keeping them as they come like now. They are sorted from left to right...or what sorting you have in mind? Furthermore, you'll want also to insert the new screens in the correct position then, and shift the rest of the screens. Yes. Aleix Pol Gonzalez wrote: Because if the user has set up his first containment with all panels, we expect him to have it in the screen he explicitly said it's the primary one. This way he'll be able to put the most attention to the screen he selected and get the notifications, the task manager and whatnot. Assuming all this goes to the left-most screen and disregarding the primary setting is not acceptable, considering the current design. does that need to be 0-based for that? It sounds like two orthogonal things. One is to have a sane ordering by going e.g. left to right, the other is honoring the primary screen for placing the main containment. - Martin --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/118094/#review57757 --- On May 12, 2014, 12:39 p.m., Martin Klapetek wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/118094/ --- (Updated May 12, 2014, 12:39 p.m.) Review request for Plasma, Aleix Pol Gonzalez and Martin Gräßlin. Repository: plasma-workspace Description --- Even though numbered outputs have their flaws, we still use them pretty much everywhere and everywhere we use outputs numbered from left to right, so let's use the same in Plasma. This seems to fix most of my multiscreen issues now, namely bug 334500 and bug 334502. Also: mgraesslin I don't know - having primary as 0 is a bit strange mgraesslin 1, 2, 3, 0 mgraesslin ? mgraesslin that was from left to right Diffs - shell/shellcorona.cpp b0b139d Diff: https://git.reviewboard.kde.org/r/118094/diff/ Testing --- Thanks, Martin Klapetek ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Dual Monitors
In data lunedì 12 maggio 2014 22:05:47, Lindsay Mathieson ha scritto: Is there a tool for configuring multiple monitors in Plasma2? as kscreen appears to be gone? Since recently, plasmashell uses libkscreen. Whether the user-facing UI was ported yet I don't know, I defer this to the more expert people in the list. ;) -- Luca Beltrame - KDE Forums team KDE Science supporter GPG key ID: 6E1A4E79 signature.asc Description: This is a digitally signed message part. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Dual Monitors
On Mon, 12 May 2014 02:09:38 PM Luca Beltrame wrote: Since recently, plasmashell uses libkscreen. Whether the user-facing UI was ported yet I don't know, I defer this to the more expert people in the list. Thanks, I'll see what pops up :) NB - Plasma2 (via project neon) is unbelievably slow on my PC, a good 10-20 seconds to bring up the KDE menu etc, though it is faster the second time. All screens are very slow the first time round. Is this normal at this stage? - Intel i5, nvidia with the binary blob. thanks, -- Lindsay signature.asc Description: This is a digitally signed message part. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Dual Monitors
On Mon, May 12, 2014 at 2:05 PM, Lindsay Mathieson lindsay.mathie...@gmail.com wrote: Is there a tool for configuring multiple monitors in Plasma2? as kscreen appears to be gone? Gone isn't the right word. It is not ported/not in Neon yet though. You can run kcmshell4 kcm_kscreen to launch it David ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Where we are now... (VDG)
On Monday 12 May 2014, Jens Reuterberg wrote: There's an issue with the cursors though and that is that they only exist in one size right now which is causing merry hell for people with HDPI screens ok, now i automated the generation a bit and the cursors have also a doubled version. there is no version in between yet, because that i fear will have to be redrawn (the author may be happy even by just scaling i don't know -- Marco Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Dual Monitors
On Mon, May 12, 2014 at 2:25 PM, Lindsay Mathieson lindsay.mathie...@gmail.com wrote: On Mon, 12 May 2014 02:09:38 PM Luca Beltrame wrote: Since recently, plasmashell uses libkscreen. Whether the user-facing UI was ported yet I don't know, I defer this to the more expert people in the list. Thanks, I'll see what pops up :) NB - Plasma2 (via project neon) is unbelievably slow on my PC, a good 10-20 seconds to bring up the KDE menu etc, though it is faster the second time. All screens are very slow the first time round. Is this normal at this stage? - Intel i5, nvidia with the binary blob. Definitely not ideal. The fact that we have debug builds of Qt is part of the reasons for the slowness and this will go away when we make a release. It is not the only reason, there is definitely some work left to do. David ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 118094: Sort screens in plasma from left to right
On May 12, 2014, 11:04 a.m., Aleix Pol Gonzalez wrote: That's not correct. Primary, at least, needs to have special treatment and get the 0-named containment assigned always, which is what the current naming is about. As for the rest of the screens it's probably best to sort them rather than keeping them as they come like now. Furthermore, you'll want also to insert the new screens in the correct position then, and shift the rest of the screens. Martin Klapetek wrote: That's not correct. Primary, at least, needs to have special treatment and get the 0-named containment assigned always, which is what the current naming is about. Why? As for the rest of the screens it's probably best to sort them rather than keeping them as they come like now. They are sorted from left to right...or what sorting you have in mind? Furthermore, you'll want also to insert the new screens in the correct position then, and shift the rest of the screens. Yes. Aleix Pol Gonzalez wrote: Because if the user has set up his first containment with all panels, we expect him to have it in the screen he explicitly said it's the primary one. This way he'll be able to put the most attention to the screen he selected and get the notifications, the task manager and whatnot. Assuming all this goes to the left-most screen and disregarding the primary setting is not acceptable, considering the current design. Martin Gräßlin wrote: does that need to be 0-based for that? It sounds like two orthogonal things. One is to have a sane ordering by going e.g. left to right, the other is honoring the primary screen for placing the main containment. Well, what do you think this number is for? - Aleix --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/118094/#review57757 --- On May 12, 2014, 10:39 a.m., Martin Klapetek wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/118094/ --- (Updated May 12, 2014, 10:39 a.m.) Review request for Plasma, Aleix Pol Gonzalez and Martin Gräßlin. Repository: plasma-workspace Description --- Even though numbered outputs have their flaws, we still use them pretty much everywhere and everywhere we use outputs numbered from left to right, so let's use the same in Plasma. This seems to fix most of my multiscreen issues now, namely bug 334500 and bug 334502. Also: mgraesslin I don't know - having primary as 0 is a bit strange mgraesslin 1, 2, 3, 0 mgraesslin ? mgraesslin that was from left to right Diffs - shell/shellcorona.cpp b0b139d Diff: https://git.reviewboard.kde.org/r/118094/diff/ Testing --- Thanks, Martin Klapetek ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Dual Monitors
On Monday 12 May 2014, David Edmundson wrote: NB - Plasma2 (via project neon) is unbelievably slow on my PC, a good 10-20 seconds to bring up the KDE menu etc, though it is faster the second time. All screens are very slow the first time round. Is this normal at this stage? - Intel i5, nvidia with the binary blob. Definitely not ideal. The fact that we have debug builds of Qt is part of the reasons for the slowness and this will go away when we make a release. It is not the only reason, there is definitely some work left to do. yes, but still, the described situation is not normal, here it's not remotely that slow even when running from an usb stick on an old atom netbook, where i test it sometimes just to see how it goes on extremely crappy hardware -- Marco Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 118063: New Formats KCM
On May 11, 2014, 6:59 p.m., John Layt wrote: kcms/formats/kcmformats.cpp, line 204 https://git.reviewboard.kde.org/r/118063/diff/1/?file=272244#file272244line204 Why are you writing all these entries here? If all they have set is the global then all we need to export is LANG, so only writing out lcGlobal should be enough. If there's no overrides we should always be deleting them. Sebastian Kügler wrote: Hm, LANG will be set from the Translations KCM, and affects that, no? (I might be off here, that's how I understand it.) This brings me back a bit to the way this KCM works, it's used to override settings specified elsewhere, if necessary. I think in combination with the Translations KCM, a clean separation makes sense, but I'm not 100% sure that's achievable. Effectively, with the current version of code, we have a few scenarios: - Language set from distro installer, however. User's happy, doesn't touch the KCM - User sets Language in the Translations KCModule, which sets LANG (in the same fashion as we do here), LC_* is not set, so everything falls back to LANG - we're peachy - User sets Language, but wants something else changed, configures that in the Formats KCM, and it's applied by exporting LC_*, - we're fine again The Translations KCM probably the first one we should show when the category in systemsettings is opened, as it allows a very Global setting: LANG is changed, affects translations, and additionally all the formatting because LC_* not set means fall back to LANG. Ah, here we get to the difference between LANG and LANGUAGE and LC_* and the override hierarchy (see http://www.gnu.org/savannah-checkouts/gnu/libc/manual/html_node/Locale-Categories.html). LANG is the global default locale to use, with LC_* and LANGUAGE used to override that default for certain functions. The LANGUAGE override is a GNU gettext extension that allows you to define a priority list of languages to be used in the translation system, whereas LANG and LC_* only allow a single locale code at a time. For example, QLocale::uiLanguages() returns the list of whatever is held in LANGUAGE, otherwise whatever is in LC_MESSAGES, otherwise whatever is in LANG, otherwise defaulting to the C locale (en_US). Defining how that relationship between LANG and LANGUAGE will work in the config GUI is the tricky part. My original plan was to treat them completely separately: * The LANGUAGE envvar configures the gui translation systems, i.e. gettext and KLocalizedString, and QTranslator. The Translations kcm would configure it from a list of available translation catalogs installed, usually only 1 or 2, with en_US as the fallback. startkde would always export a LANGUAGE value, defaulting to the system LANG if no LANGUAGE value set in the kcm. It would also export the first value in the LANGUAGE list as LC_MESSAGES * The LANG and LC_* envvars configure the localization system, i.e. date formatting, number formatting, etc in glibc and ICU and QLocale. The kcm configures them from a list of available locale files installed, usually several hundred. These locale files contain month and day name translations separate to the gui translation system. startkde would export a value for LANG or LC_* only if set in the kcm. This would give users maximum flexibility while perhaps making it clearer why just selecting say an Arabic locale doesn't give you an Arabic gui translation. However I'm rethinking that a bit now, as while by default most users would never need to change anything after their initial distro install, I could see those users who do need to change being confused/annoyed at having to do it in two separate places. Having the two kcms messing with each others settings also seems a no-no to me, so the only alternative is to merge them. One other reason for the original approach was the rather problematic Languages tab in the old Locale kcm which I was copying for Translations. It uses a KActionSelector widget which shows side-by-side lists of Available Languages and Preferred Languages: you move the languages you want from Available to Preferred and then adjust the order. Problem is this takes up a lot of space so needs a separate pane or tab, but most of this space and functionality is wasted on most users who only have 1 or 2 KDE language packs installed: its a gui optimised for the 0.1% corner case of someone with dozens of languages installed who's regularly modifying them. There's also a debate about what the Available Languages list should show given we are setting LANGUAGES now for all apps under the workspace including gettext ones: do we list just the KDE language packs, or also all languages installed into /usr/share/locale, or all possible languages? One possibility is to throw away all the old code and have a single list of Preferred Languages, with a small + button to pop
Re: Plasma Next Beta 1
On Sat, May 10, 2014 at 08:24:30PM +0200, šumski wrote: Yeah. Thus also kfilemetadata (so this baloo tar is unbuildable - not just cause master branch is packaged instead of frameworks one ;-) And since the WIP kde-baseapps is here (somehow this would fit more with Applications releases than Plasma?), IMHO, one could possibly include Kate, Konsole and plasma-nm (with required libs) - though libs target to be part of KF5? kfilemetadata added 924a6450f7d37132d8cb7afc025cd58b4c4aa562e1ddee82976f14f60df861c6 milou added 33fec64b34a9f7bebffd422e3f221cf6461fc49355f5081cf04b5612d752325d baloo remade from frameworks branch daa5fcb94d18f54e082d09dd32131f161dcd7e3f99e0b54eaa7f9a280fb0940a kde-baseapps removed sysadmin ticket filed to update, files also at.. http://starsky.19inch.net/~jr/tmp/plasma-4.96.0/ Jonathan ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 118094: Sort screens in plasma from left to right
On May 12, 2014, 11:04 a.m., Aleix Pol Gonzalez wrote: That's not correct. Primary, at least, needs to have special treatment and get the 0-named containment assigned always, which is what the current naming is about. As for the rest of the screens it's probably best to sort them rather than keeping them as they come like now. Furthermore, you'll want also to insert the new screens in the correct position then, and shift the rest of the screens. Martin Klapetek wrote: That's not correct. Primary, at least, needs to have special treatment and get the 0-named containment assigned always, which is what the current naming is about. Why? As for the rest of the screens it's probably best to sort them rather than keeping them as they come like now. They are sorted from left to right...or what sorting you have in mind? Furthermore, you'll want also to insert the new screens in the correct position then, and shift the rest of the screens. Yes. Aleix Pol Gonzalez wrote: Because if the user has set up his first containment with all panels, we expect him to have it in the screen he explicitly said it's the primary one. This way he'll be able to put the most attention to the screen he selected and get the notifications, the task manager and whatnot. Assuming all this goes to the left-most screen and disregarding the primary setting is not acceptable, considering the current design. Martin Gräßlin wrote: does that need to be 0-based for that? It sounds like two orthogonal things. One is to have a sane ordering by going e.g. left to right, the other is honoring the primary screen for placing the main containment. Aleix Pol Gonzalez wrote: Well, what do you think this number is for? Just re-read and realized my answer is not very helpful there. The internal Corona containment id is what we're sorting here and 0 refers to the first containment, 1 to the second and so forth. This way, when we restore, we match 0 with primary, 1 with the first reported one, and so forth. Having them sorted from left to right (or top to bottom) makes sense because it makes the behavior more predictable but the screen number doesn't indicate where the screen is placed. - Aleix --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/118094/#review57757 --- On May 12, 2014, 10:39 a.m., Martin Klapetek wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/118094/ --- (Updated May 12, 2014, 10:39 a.m.) Review request for Plasma, Aleix Pol Gonzalez and Martin Gräßlin. Repository: plasma-workspace Description --- Even though numbered outputs have their flaws, we still use them pretty much everywhere and everywhere we use outputs numbered from left to right, so let's use the same in Plasma. This seems to fix most of my multiscreen issues now, namely bug 334500 and bug 334502. Also: mgraesslin I don't know - having primary as 0 is a bit strange mgraesslin 1, 2, 3, 0 mgraesslin ? mgraesslin that was from left to right Diffs - shell/shellcorona.cpp b0b139d Diff: https://git.reviewboard.kde.org/r/118094/diff/ Testing --- Thanks, Martin Klapetek ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 118094: Sort screens in plasma from left to right
On May 12, 2014, 1:04 p.m., Aleix Pol Gonzalez wrote: That's not correct. Primary, at least, needs to have special treatment and get the 0-named containment assigned always, which is what the current naming is about. As for the rest of the screens it's probably best to sort them rather than keeping them as they come like now. Furthermore, you'll want also to insert the new screens in the correct position then, and shift the rest of the screens. Martin Klapetek wrote: That's not correct. Primary, at least, needs to have special treatment and get the 0-named containment assigned always, which is what the current naming is about. Why? As for the rest of the screens it's probably best to sort them rather than keeping them as they come like now. They are sorted from left to right...or what sorting you have in mind? Furthermore, you'll want also to insert the new screens in the correct position then, and shift the rest of the screens. Yes. Aleix Pol Gonzalez wrote: Because if the user has set up his first containment with all panels, we expect him to have it in the screen he explicitly said it's the primary one. This way he'll be able to put the most attention to the screen he selected and get the notifications, the task manager and whatnot. Assuming all this goes to the left-most screen and disregarding the primary setting is not acceptable, considering the current design. Martin Gräßlin wrote: does that need to be 0-based for that? It sounds like two orthogonal things. One is to have a sane ordering by going e.g. left to right, the other is honoring the primary screen for placing the main containment. Aleix Pol Gonzalez wrote: Well, what do you think this number is for? Aleix Pol Gonzalez wrote: Just re-read and realized my answer is not very helpful there. The internal Corona containment id is what we're sorting here and 0 refers to the first containment, 1 to the second and so forth. This way, when we restore, we match 0 with primary, 1 with the first reported one, and so forth. Having them sorted from left to right (or top to bottom) makes sense because it makes the behavior more predictable but the screen number doesn't indicate where the screen is placed. that's up to us to decide. Numbering screens doesn't make sense (TM). So if we want to use numbering we should use something which makes sense. Ordering by left to right or by available outputs could make sense. My prefered solution were that all numbering get's removed and replaced by a useful metric such as output identifiers. - Martin --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/118094/#review57757 --- On May 12, 2014, 12:39 p.m., Martin Klapetek wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/118094/ --- (Updated May 12, 2014, 12:39 p.m.) Review request for Plasma, Aleix Pol Gonzalez and Martin Gräßlin. Repository: plasma-workspace Description --- Even though numbered outputs have their flaws, we still use them pretty much everywhere and everywhere we use outputs numbered from left to right, so let's use the same in Plasma. This seems to fix most of my multiscreen issues now, namely bug 334500 and bug 334502. Also: mgraesslin I don't know - having primary as 0 is a bit strange mgraesslin 1, 2, 3, 0 mgraesslin ? mgraesslin that was from left to right Diffs - shell/shellcorona.cpp b0b139d Diff: https://git.reviewboard.kde.org/r/118094/diff/ Testing --- Thanks, Martin Klapetek ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Dual Monitors
On Mon, May 12, 2014 at 2:05 PM, Lindsay Mathieson lindsay.mathie...@gmail.com wrote: Is there a tool for configuring multiple monitors in Plasma2? as kscreen appears to be gone? -- Lindsay ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel I ported KScreen last friday. I'm running it here locally and seems to work alright. Aleix ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 118094: Sort screens in plasma from left to right
On May 12, 2014, 1:04 p.m., Aleix Pol Gonzalez wrote: That's not correct. Primary, at least, needs to have special treatment and get the 0-named containment assigned always, which is what the current naming is about. As for the rest of the screens it's probably best to sort them rather than keeping them as they come like now. Furthermore, you'll want also to insert the new screens in the correct position then, and shift the rest of the screens. Martin Klapetek wrote: That's not correct. Primary, at least, needs to have special treatment and get the 0-named containment assigned always, which is what the current naming is about. Why? As for the rest of the screens it's probably best to sort them rather than keeping them as they come like now. They are sorted from left to right...or what sorting you have in mind? Furthermore, you'll want also to insert the new screens in the correct position then, and shift the rest of the screens. Yes. Aleix Pol Gonzalez wrote: Because if the user has set up his first containment with all panels, we expect him to have it in the screen he explicitly said it's the primary one. This way he'll be able to put the most attention to the screen he selected and get the notifications, the task manager and whatnot. Assuming all this goes to the left-most screen and disregarding the primary setting is not acceptable, considering the current design. Martin Gräßlin wrote: does that need to be 0-based for that? It sounds like two orthogonal things. One is to have a sane ordering by going e.g. left to right, the other is honoring the primary screen for placing the main containment. Aleix Pol Gonzalez wrote: Well, what do you think this number is for? Aleix Pol Gonzalez wrote: Just re-read and realized my answer is not very helpful there. The internal Corona containment id is what we're sorting here and 0 refers to the first containment, 1 to the second and so forth. This way, when we restore, we match 0 with primary, 1 with the first reported one, and so forth. Having them sorted from left to right (or top to bottom) makes sense because it makes the behavior more predictable but the screen number doesn't indicate where the screen is placed. Martin Gräßlin wrote: that's up to us to decide. Numbering screens doesn't make sense (TM). So if we want to use numbering we should use something which makes sense. Ordering by left to right or by available outputs could make sense. My prefered solution were that all numbering get's removed and replaced by a useful metric such as output identifiers. As we also export the screen number to the plasmoids, it's useful if it actually corresponds with something the plasmoids can use, like QScreen (even if shit). So I would propose to let screen numbers be just that - screen numbered in left-to-right order and then match containments with actual screen identifiers, either screen name (from edid) or the xrandr name like DVI-D-0 and then match those. This actually guarantees things will stay consistent even if you change order of your screens and generally makes things more deterministic. I would also propose to take the primary screen into account and make it the default desktop (where panels and notifications and whatnot get placed) after first run. In case user changes his primary output, I would switch the panel only if there is no other panel/configured stuff on the other screen, but I'm not so sure about this. But either way, even if we switch the screens, we just match the primary containment with the new screen identifier, so all will just work. I also volunteer to do all this of course. - Martin --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/118094/#review57757 --- On May 12, 2014, 12:39 p.m., Martin Klapetek wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/118094/ --- (Updated May 12, 2014, 12:39 p.m.) Review request for Plasma, Aleix Pol Gonzalez and Martin Gräßlin. Repository: plasma-workspace Description --- Even though numbered outputs have their flaws, we still use them pretty much everywhere and everywhere we use outputs numbered from left to right, so let's use the same in Plasma. This seems to fix most of my multiscreen issues now, namely bug 334500 and bug 334502. Also: mgraesslin I don't know - having primary as 0 is a bit strange mgraesslin 1, 2, 3, 0 mgraesslin ? mgraesslin that was from left to right Diffs -
Re: Qt Quick Controls style
I just tested it with our fresh QML version of kde-nm-connection editor and I found two issues: 1) Headers in TableView don't have visible sort indicators 2) Menu and Toolbar don't have icons, not sure whether this is an issue, but when I use default style, I have Icon + Text + Shortcut in each menu item and just Icon in toolbar item. With this style I have Text + Shortcut in menu item and just Text in Toolbar item. I have the latest version from Andrew's scratch repo, but I'm not sure whether is there a newer version somewhere. You can see how it looks here [1] and how it looks with the default style [2]. [1] - http://imgur.com/MCKDBYQ [2] - http://imgur.com/YX0fCXm Cheers, Jan -- Jan Grulich Red Hat Czech, s.r.o jgrul...@redhat.com ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 118094: Sort screens in plasma from left to right
On May 12, 2014, 1:04 p.m., Aleix Pol Gonzalez wrote: That's not correct. Primary, at least, needs to have special treatment and get the 0-named containment assigned always, which is what the current naming is about. As for the rest of the screens it's probably best to sort them rather than keeping them as they come like now. Furthermore, you'll want also to insert the new screens in the correct position then, and shift the rest of the screens. Martin Klapetek wrote: That's not correct. Primary, at least, needs to have special treatment and get the 0-named containment assigned always, which is what the current naming is about. Why? As for the rest of the screens it's probably best to sort them rather than keeping them as they come like now. They are sorted from left to right...or what sorting you have in mind? Furthermore, you'll want also to insert the new screens in the correct position then, and shift the rest of the screens. Yes. Aleix Pol Gonzalez wrote: Because if the user has set up his first containment with all panels, we expect him to have it in the screen he explicitly said it's the primary one. This way he'll be able to put the most attention to the screen he selected and get the notifications, the task manager and whatnot. Assuming all this goes to the left-most screen and disregarding the primary setting is not acceptable, considering the current design. Martin Gräßlin wrote: does that need to be 0-based for that? It sounds like two orthogonal things. One is to have a sane ordering by going e.g. left to right, the other is honoring the primary screen for placing the main containment. Aleix Pol Gonzalez wrote: Well, what do you think this number is for? Aleix Pol Gonzalez wrote: Just re-read and realized my answer is not very helpful there. The internal Corona containment id is what we're sorting here and 0 refers to the first containment, 1 to the second and so forth. This way, when we restore, we match 0 with primary, 1 with the first reported one, and so forth. Having them sorted from left to right (or top to bottom) makes sense because it makes the behavior more predictable but the screen number doesn't indicate where the screen is placed. Martin Gräßlin wrote: that's up to us to decide. Numbering screens doesn't make sense (TM). So if we want to use numbering we should use something which makes sense. Ordering by left to right or by available outputs could make sense. My prefered solution were that all numbering get's removed and replaced by a useful metric such as output identifiers. Martin Klapetek wrote: As we also export the screen number to the plasmoids, it's useful if it actually corresponds with something the plasmoids can use, like QScreen (even if shit). So I would propose to let screen numbers be just that - screen numbered in left-to-right order and then match containments with actual screen identifiers, either screen name (from edid) or the xrandr name like DVI-D-0 and then match those. This actually guarantees things will stay consistent even if you change order of your screens and generally makes things more deterministic. I would also propose to take the primary screen into account and make it the default desktop (where panels and notifications and whatnot get placed) after first run. In case user changes his primary output, I would switch the panel only if there is no other panel/configured stuff on the other screen, but I'm not so sure about this. But either way, even if we switch the screens, we just match the primary containment with the new screen identifier, so all will just work. I also volunteer to do all this of course. sounds like a good proposal to me. What do you think Aleix? - Martin --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/118094/#review57757 --- On May 12, 2014, 12:39 p.m., Martin Klapetek wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/118094/ --- (Updated May 12, 2014, 12:39 p.m.) Review request for Plasma, Aleix Pol Gonzalez and Martin Gräßlin. Repository: plasma-workspace Description --- Even though numbered outputs have their flaws, we still use them pretty much everywhere and everywhere we use outputs numbered from left to right, so let's use the same in Plasma. This seems to fix most of my multiscreen issues now, namely bug 334500 and bug 334502. Also: mgraesslin I don't know - having primary as
Re: Review Request 117984: Try to prioritize photos taken by a camera-like device
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117984/ --- (Updated May 12, 2014, 2:14 p.m.) Status -- This change has been marked as submitted. Review request for Plasma. Repository: plasma-mediacenter Description --- The list of images that we get from Baloo has lot of noise because it usually contains small images from data files of software, games and so on. We do two things- * Ignore images unless they are wider than 500 pixels * Make images with EXIF data appear first by giving them preference in sorting by date/time Diffs - plugins/baloosearch/audiosearchresulthandler.h 11b7219 plugins/baloosearch/audiosearchresulthandler.cpp de98bb7 plugins/baloosearch/baloosearchmediasource.h 93e3d80 plugins/baloosearch/baloosearchmediasource.cpp 4180b1e plugins/baloosearch/imagesearchresulthandler.h 200451e plugins/baloosearch/imagesearchresulthandler.cpp 272b476 plugins/baloosearch/searchresulthandler.h 0df0ba2 plugins/baloosearch/searchresulthandler.cpp 78e41ea plugins/baloosearch/videosearchresulthandler.h 146efca plugins/baloosearch/videosearchresulthandler.cpp 1295b30 Diff: https://git.reviewboard.kde.org/r/117984/diff/ Testing --- Photos are fetched, the ones from my recent trip to Kashmir show up first ;) Thanks, Shantanu Tushar ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Qt Quick Controls style
On Mon, May 12, 2014 at 3:49 PM, Jan Grulich jgrul...@redhat.com wrote: I just tested it with our fresh QML version of kde-nm-connection editor and I found two issues: Personally I think you're still far better off using QWidgets for anything outside plasma space. Your life will be much easier. 1) Headers in TableView don't have visible sort indicators Have you set sortIndicatorVisible: true on the tableView it defaults to false. If it's still broken please file a bug here with a simple reproducible case: https://bugreports.qt-project.org/secure/Dashboard.jspa 2) Menu and Toolbar don't have icons, not sure whether this is an issue, but when I use default style, I have Icon + Text + Shortcut in each menu item and just Icon in toolbar item. With this style I have Text + Shortcut in menu item and just Text in Toolbar item. I'm not sure if that's a bug on our side or not. I'll look. David ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Qt Quick Controls style
On Mon, May 12, 2014 at 3:49 PM, Jan Grulich jgrul...@redhat.com wrote: I just tested it with our fresh QML version of kde-nm-connection editor and I found two issues: 1) Headers in TableView don't have visible sort indicators It seems [2] is showing the sort indicator. Does it only not work with the qtcurve theme? Can you see if that theme works in oxygen-demo? ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Qt Quick Controls style
On Monday 12 of May 2014 16:32 David Edmundson wrote: On Mon, May 12, 2014 at 3:49 PM, Jan Grulich jgrul...@redhat.com wrote: I just tested it with our fresh QML version of kde-nm-connection editor and I found two issues: 1) Headers in TableView don't have visible sort indicators It seems [2] is showing the sort indicator. Does it only not work with the qtcurve theme? Can you see if that theme works in oxygen-demo? ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel I have set sortIndicatorVisible to true and it works with qtcurve theme and also in oxygen-demo, so I guess something is missing in Breeze style, because I'm able to change sorting order, but I don't see indicators. Jan -- Jan Grulich Red Hat Czech, s.r.o jgrul...@redhat.com ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 118094: Sort screens in plasma from left to right
On May 12, 2014, 11:04 a.m., Aleix Pol Gonzalez wrote: That's not correct. Primary, at least, needs to have special treatment and get the 0-named containment assigned always, which is what the current naming is about. As for the rest of the screens it's probably best to sort them rather than keeping them as they come like now. Furthermore, you'll want also to insert the new screens in the correct position then, and shift the rest of the screens. Martin Klapetek wrote: That's not correct. Primary, at least, needs to have special treatment and get the 0-named containment assigned always, which is what the current naming is about. Why? As for the rest of the screens it's probably best to sort them rather than keeping them as they come like now. They are sorted from left to right...or what sorting you have in mind? Furthermore, you'll want also to insert the new screens in the correct position then, and shift the rest of the screens. Yes. Aleix Pol Gonzalez wrote: Because if the user has set up his first containment with all panels, we expect him to have it in the screen he explicitly said it's the primary one. This way he'll be able to put the most attention to the screen he selected and get the notifications, the task manager and whatnot. Assuming all this goes to the left-most screen and disregarding the primary setting is not acceptable, considering the current design. Martin Gräßlin wrote: does that need to be 0-based for that? It sounds like two orthogonal things. One is to have a sane ordering by going e.g. left to right, the other is honoring the primary screen for placing the main containment. Aleix Pol Gonzalez wrote: Well, what do you think this number is for? Aleix Pol Gonzalez wrote: Just re-read and realized my answer is not very helpful there. The internal Corona containment id is what we're sorting here and 0 refers to the first containment, 1 to the second and so forth. This way, when we restore, we match 0 with primary, 1 with the first reported one, and so forth. Having them sorted from left to right (or top to bottom) makes sense because it makes the behavior more predictable but the screen number doesn't indicate where the screen is placed. Martin Gräßlin wrote: that's up to us to decide. Numbering screens doesn't make sense (TM). So if we want to use numbering we should use something which makes sense. Ordering by left to right or by available outputs could make sense. My prefered solution were that all numbering get's removed and replaced by a useful metric such as output identifiers. Martin Klapetek wrote: As we also export the screen number to the plasmoids, it's useful if it actually corresponds with something the plasmoids can use, like QScreen (even if shit). So I would propose to let screen numbers be just that - screen numbered in left-to-right order and then match containments with actual screen identifiers, either screen name (from edid) or the xrandr name like DVI-D-0 and then match those. This actually guarantees things will stay consistent even if you change order of your screens and generally makes things more deterministic. I would also propose to take the primary screen into account and make it the default desktop (where panels and notifications and whatnot get placed) after first run. In case user changes his primary output, I would switch the panel only if there is no other panel/configured stuff on the other screen, but I'm not so sure about this. But either way, even if we switch the screens, we just match the primary containment with the new screen identifier, so all will just work. I also volunteer to do all this of course. Martin Gräßlin wrote: sounds like a good proposal to me. What do you think Aleix? Why do plasmoids need to know the order of the screens left-to-right? As far as I understand a plasmoid needs to have the tools to place things around it or even in the same screen, but how things are sorted is not responsible to the plasmoid but to the corona. I would also propose to take the primary screen into account and make it the default desktop (where panels and notifications and whatnot get placed) after first run. So you just want to remove any multiscreen support in Plasma Shell and squeeze everything in the primary screen? - Aleix --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/118094/#review57757 --- On May 12, 2014, 10:39 a.m., Martin Klapetek wrote: --- This is an automatically generated e-mail. To reply, visit:
Re: Review Request 118094: Sort screens in plasma from left to right
On May 12, 2014, 11:04 a.m., Aleix Pol Gonzalez wrote: That's not correct. Primary, at least, needs to have special treatment and get the 0-named containment assigned always, which is what the current naming is about. As for the rest of the screens it's probably best to sort them rather than keeping them as they come like now. Furthermore, you'll want also to insert the new screens in the correct position then, and shift the rest of the screens. Martin Klapetek wrote: That's not correct. Primary, at least, needs to have special treatment and get the 0-named containment assigned always, which is what the current naming is about. Why? As for the rest of the screens it's probably best to sort them rather than keeping them as they come like now. They are sorted from left to right...or what sorting you have in mind? Furthermore, you'll want also to insert the new screens in the correct position then, and shift the rest of the screens. Yes. Aleix Pol Gonzalez wrote: Because if the user has set up his first containment with all panels, we expect him to have it in the screen he explicitly said it's the primary one. This way he'll be able to put the most attention to the screen he selected and get the notifications, the task manager and whatnot. Assuming all this goes to the left-most screen and disregarding the primary setting is not acceptable, considering the current design. Martin Gräßlin wrote: does that need to be 0-based for that? It sounds like two orthogonal things. One is to have a sane ordering by going e.g. left to right, the other is honoring the primary screen for placing the main containment. Aleix Pol Gonzalez wrote: Well, what do you think this number is for? Aleix Pol Gonzalez wrote: Just re-read and realized my answer is not very helpful there. The internal Corona containment id is what we're sorting here and 0 refers to the first containment, 1 to the second and so forth. This way, when we restore, we match 0 with primary, 1 with the first reported one, and so forth. Having them sorted from left to right (or top to bottom) makes sense because it makes the behavior more predictable but the screen number doesn't indicate where the screen is placed. Martin Gräßlin wrote: that's up to us to decide. Numbering screens doesn't make sense (TM). So if we want to use numbering we should use something which makes sense. Ordering by left to right or by available outputs could make sense. My prefered solution were that all numbering get's removed and replaced by a useful metric such as output identifiers. Martin Klapetek wrote: As we also export the screen number to the plasmoids, it's useful if it actually corresponds with something the plasmoids can use, like QScreen (even if shit). So I would propose to let screen numbers be just that - screen numbered in left-to-right order and then match containments with actual screen identifiers, either screen name (from edid) or the xrandr name like DVI-D-0 and then match those. This actually guarantees things will stay consistent even if you change order of your screens and generally makes things more deterministic. I would also propose to take the primary screen into account and make it the default desktop (where panels and notifications and whatnot get placed) after first run. In case user changes his primary output, I would switch the panel only if there is no other panel/configured stuff on the other screen, but I'm not so sure about this. But either way, even if we switch the screens, we just match the primary containment with the new screen identifier, so all will just work. I also volunteer to do all this of course. Martin Gräßlin wrote: sounds like a good proposal to me. What do you think Aleix? Aleix Pol Gonzalez wrote: Why do plasmoids need to know the order of the screens left-to-right? As far as I understand a plasmoid needs to have the tools to place things around it or even in the same screen, but how things are sorted is not responsible to the plasmoid but to the corona. I would also propose to take the primary screen into account and make it the default desktop (where panels and notifications and whatnot get placed) after first run. So you just want to remove any multiscreen support in Plasma Shell and squeeze everything in the primary screen? Being ordered from left to right doesn't help anything. I have dual setup (primary is my fixed display) - panels are on my primary I unplug - laptop becomes primary and all my stuff moves there. Stuff on my secondary screen correctly disappears. I plug back in so a new screen[0] exists - my panel is moved to the bigger screen If it was ordered left to right my panel would either
Re: Review Request 118094: Sort screens in plasma from left to right
On May 12, 2014, 1:04 p.m., Aleix Pol Gonzalez wrote: That's not correct. Primary, at least, needs to have special treatment and get the 0-named containment assigned always, which is what the current naming is about. As for the rest of the screens it's probably best to sort them rather than keeping them as they come like now. Furthermore, you'll want also to insert the new screens in the correct position then, and shift the rest of the screens. Martin Klapetek wrote: That's not correct. Primary, at least, needs to have special treatment and get the 0-named containment assigned always, which is what the current naming is about. Why? As for the rest of the screens it's probably best to sort them rather than keeping them as they come like now. They are sorted from left to right...or what sorting you have in mind? Furthermore, you'll want also to insert the new screens in the correct position then, and shift the rest of the screens. Yes. Aleix Pol Gonzalez wrote: Because if the user has set up his first containment with all panels, we expect him to have it in the screen he explicitly said it's the primary one. This way he'll be able to put the most attention to the screen he selected and get the notifications, the task manager and whatnot. Assuming all this goes to the left-most screen and disregarding the primary setting is not acceptable, considering the current design. Martin Gräßlin wrote: does that need to be 0-based for that? It sounds like two orthogonal things. One is to have a sane ordering by going e.g. left to right, the other is honoring the primary screen for placing the main containment. Aleix Pol Gonzalez wrote: Well, what do you think this number is for? Aleix Pol Gonzalez wrote: Just re-read and realized my answer is not very helpful there. The internal Corona containment id is what we're sorting here and 0 refers to the first containment, 1 to the second and so forth. This way, when we restore, we match 0 with primary, 1 with the first reported one, and so forth. Having them sorted from left to right (or top to bottom) makes sense because it makes the behavior more predictable but the screen number doesn't indicate where the screen is placed. Martin Gräßlin wrote: that's up to us to decide. Numbering screens doesn't make sense (TM). So if we want to use numbering we should use something which makes sense. Ordering by left to right or by available outputs could make sense. My prefered solution were that all numbering get's removed and replaced by a useful metric such as output identifiers. Martin Klapetek wrote: As we also export the screen number to the plasmoids, it's useful if it actually corresponds with something the plasmoids can use, like QScreen (even if shit). So I would propose to let screen numbers be just that - screen numbered in left-to-right order and then match containments with actual screen identifiers, either screen name (from edid) or the xrandr name like DVI-D-0 and then match those. This actually guarantees things will stay consistent even if you change order of your screens and generally makes things more deterministic. I would also propose to take the primary screen into account and make it the default desktop (where panels and notifications and whatnot get placed) after first run. In case user changes his primary output, I would switch the panel only if there is no other panel/configured stuff on the other screen, but I'm not so sure about this. But either way, even if we switch the screens, we just match the primary containment with the new screen identifier, so all will just work. I also volunteer to do all this of course. Martin Gräßlin wrote: sounds like a good proposal to me. What do you think Aleix? Aleix Pol Gonzalez wrote: Why do plasmoids need to know the order of the screens left-to-right? As far as I understand a plasmoid needs to have the tools to place things around it or even in the same screen, but how things are sorted is not responsible to the plasmoid but to the corona. I would also propose to take the primary screen into account and make it the default desktop (where panels and notifications and whatnot get placed) after first run. So you just want to remove any multiscreen support in Plasma Shell and squeeze everything in the primary screen? David Edmundson wrote: Being ordered from left to right doesn't help anything. I have dual setup (primary is my fixed display) - panels are on my primary I unplug - laptop becomes primary and all my stuff moves there. Stuff on my secondary screen correctly disappears. I plug back in so a new screen[0] exists - my panel is moved to
Re: Review Request 118092: Left and right movement in All music
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/118092/#review57797 --- components/listbrowser/ListBrowser.qml https://git.reviewboard.kde.org/r/118092/#comment40236 As this only puts focus on the tab bar, you have to press left/right twice to make it work. Instead one press of the key should work. - Shantanu Tushar On May 12, 2014, 4:29 a.m., Sujith Haridasan wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/118092/ --- (Updated May 12, 2014, 4:29 a.m.) Review request for Plasma, Shantanu Tushar and Sinny Kumari. Bugs: 334148 http://bugs.kde.org/show_bug.cgi?id=334148 Repository: plasma-mediacenter Description --- Left and right movement in All Music - Songs section. Now user can navigate left and right when in the songs section. And this is applicable only to the songs section. Diffs - components/listbrowser/ListBrowser.qml 202d406 Diff: https://git.reviewboard.kde.org/r/118092/diff/ Testing --- 1) Use down arrow key to reach songs. 2) Press left/right arrow key. 3) Press left/right arrow key(for some reason we have to press the same key twice). 4) User reaches Artists if pressed left or Albums if pressed right. Thanks, Sujith Haridasan ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 118089: Fix build: add spaces in string concatenation
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/118089/ --- (Updated May 12, 2014, 8:19 p.m.) Status -- This change has been marked as submitted. Review request for Plasma. Repository: plasma-desktop Description --- Without the space, C++ compiler (e.g. GCC 4.7.3) treats /DISABLED_FONTS as a string literal suffix instead of string concatenation. Diffs - kcms/kfontinst/dbus/Folder.cpp ba9b45f Diff: https://git.reviewboard.kde.org/r/118089/diff/ Testing --- Successful build using kdesrc-build. Thanks, Alexander Potashev ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 118089: Fix build: add spaces in string concatenation
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/118089/#review57817 --- This review has been submitted with commit 9d8bcb355a1d8f67892c5a5e1b9273f4909d0c48 by Alexander Potashev to branch master. - Commit Hook On May 12, 2014, 12:40 a.m., Alexander Potashev wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/118089/ --- (Updated May 12, 2014, 12:40 a.m.) Review request for Plasma. Repository: plasma-desktop Description --- Without the space, C++ compiler (e.g. GCC 4.7.3) treats /DISABLED_FONTS as a string literal suffix instead of string concatenation. Diffs - kcms/kfontinst/dbus/Folder.cpp ba9b45f Diff: https://git.reviewboard.kde.org/r/118089/diff/ Testing --- Successful build using kdesrc-build. Thanks, Alexander Potashev ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Dual Monitors
On Mon, 12 May 2014 03:04:35 PM David Edmundson wrote: Gone isn't the right word. It is not ported/not in Neon yet though. You can run kcmshell4 kcm_kscreen to launch it That worked, thanks. Doesn't stick though, monitor alignment resets after login/logout, and panels/widgets seem to randomly rearrange. I see from other posts though that this is a work in progress. -- Lindsay signature.asc Description: This is a digitally signed message part. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Dual Monitors
On Mon, 12 May 2014 03:11:16 PM Marco Martin wrote: NB - Plasma2 (via project neon) is unbelievably slow on my PC, a good 10-20 seconds to bring up the KDE menu etc, though it is faster the second time. All screens are very slow the first time round. Is this normal at this stage? - Intel i5, nvidia with the binary blob. Definitely not ideal. The fact that we have debug builds of Qt is part of the reasons for the slowness and this will go away when we make a release. It is not the only reason, there is definitely some work left to do. yes, but still, the described situation is not normal, here it's not remotely that slow even when running from an usb stick on an old atom netbook, where i test it sometimes just to see how it goes on extremely crappy hardware I did a bit more testing, changing from lightdm to kdm, fiddling with the compositor settings, didn't seem to make a difference. It definitely improves the longer I use it, but seems to start from scratch after re logging in. I did notice that kbuildsycoca5 is pegging the cpu, up to 100% of a core at times. Not all the time, but obviously in response to graphical events, e.g opening the kde menu. -- Lindsay signature.asc Description: This is a digitally signed message part. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Qt Quick Controls style
Thanks for testing and reporting this Jan. The style needs to be tested like this to uncover any issues and so that we'll eventually have a fully functional, first class Qt Quick Controls style. Thanks again! Andrew On Mon, May 12, 2014 at 7:43 AM, Jan Grulich jgrul...@redhat.com wrote: On Monday 12 of May 2014 16:32 David Edmundson wrote: On Mon, May 12, 2014 at 3:49 PM, Jan Grulich jgrul...@redhat.com wrote: I just tested it with our fresh QML version of kde-nm-connection editor and I found two issues: 1) Headers in TableView don't have visible sort indicators It seems [2] is showing the sort indicator. Does it only not work with the qtcurve theme? Can you see if that theme works in oxygen-demo? ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel I have set sortIndicatorVisible to true and it works with qtcurve theme and also in oxygen-demo, so I guess something is missing in Breeze style, because I'm able to change sorting order, but I don't see indicators. Jan -- Jan Grulich Red Hat Czech, s.r.o jgrul...@redhat.com ___ 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: Qt Quick Controls style
Oh and the style is now officially housed in the Breeze project repo: g...@git.kde.org:breeze.git Thanks much On Mon, May 12, 2014 at 7:43 AM, Jan Grulich jgrul...@redhat.com wrote: On Monday 12 of May 2014 16:32 David Edmundson wrote: On Mon, May 12, 2014 at 3:49 PM, Jan Grulich jgrul...@redhat.com wrote: I just tested it with our fresh QML version of kde-nm-connection editor and I found two issues: 1) Headers in TableView don't have visible sort indicators It seems [2] is showing the sort indicator. Does it only not work with the qtcurve theme? Can you see if that theme works in oxygen-demo? ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel I have set sortIndicatorVisible to true and it works with qtcurve theme and also in oxygen-demo, so I guess something is missing in Breeze style, because I'm able to change sorting order, but I don't see indicators. Jan -- Jan Grulich Red Hat Czech, s.r.o jgrul...@redhat.com ___ 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: Breeze QML window decoration
On Mon, May 5, 2014 at 6:54 AM, Martin Gräßlin wrote: On Sunday 04 May 2014 22:28:23 Andrew Lake wrote: Based on the design we came up with in the VDG forum, I completed a first go at doing up a Aurorae QML window decoration. I added it to the 'working' branch of the Breeze repo. As far as I can tell it works about as well as the Plastik QML decoration. some feedback after running the deco for most of today: * in maximized state there is still a round corner in top left and top right * I experience a slight flicker when mouse over buttons * there's a config dialog (which looks like forked from Plastik) which is not updated in the deco? Maybe remove? * Changing button sizes has no effect - this is important for accessibility I made a few updates that should fix most of these issues now. Thanks for everyone's patience. Andrew ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Where we are now... (VDG)
On Mon, May 12, 2014 at 1:22 AM, Marco Martin wrote: so of all that, let's see what we have, what we don't and how we can make shippable * plasma theme: check * wallpaper: once is ready, where we do put it? * widget style: we have the qtcurve settings, i failed as well to contact the (supposedly new) maintainers * icons: those should also be imported somewhere * am i missing something? The full list in the Breeze project repo is: * colors - ready to ship (still need to set as default) * cursors - ready to ship as default (I assume this is being set as default) * widget styles: qtcurve settings - ready to ship (Also need to ship QtCurve as an included style like Fusion and MS Window 9x. Still need to figure out how to get QtCurve to use it by default since its settings UI is not yet in Qt5 port.) * widget styles: Qt Quick controls style - A few bug fixes remain but should be ready to ship * window decoration: Aurorae QML - ready to ship * window decoration: Aurorae svg - ready to ship * wallpapers: once they're ready I say put 'em here. We'll need to get them selected and a default chosen before the artwork freeze on May 29th (is that date still right?) Not in the Breeze project repo: * plasma theme - ready to ship (probably a few minor fixes before artwork freeze) * icons - with the actions complete pretty well fleshed out and everything else baselined on Flattr, I'm thinking we're closing in on something very much shippable. If it's not already done, we still need to disable the oxygen background gradient since, far as I can tell, that's still our default window decoration and widget style for the first release. Hope this helps! Andrew ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 118063: New Formats KCM
On May 11, 2014, 5:59 p.m., John Layt wrote: kcms/formats/kcmformats.cpp, line 204 https://git.reviewboard.kde.org/r/118063/diff/1/?file=272244#file272244line204 Why are you writing all these entries here? If all they have set is the global then all we need to export is LANG, so only writing out lcGlobal should be enough. If there's no overrides we should always be deleting them. Sebastian Kügler wrote: Hm, LANG will be set from the Translations KCM, and affects that, no? (I might be off here, that's how I understand it.) This brings me back a bit to the way this KCM works, it's used to override settings specified elsewhere, if necessary. I think in combination with the Translations KCM, a clean separation makes sense, but I'm not 100% sure that's achievable. Effectively, with the current version of code, we have a few scenarios: - Language set from distro installer, however. User's happy, doesn't touch the KCM - User sets Language in the Translations KCModule, which sets LANG (in the same fashion as we do here), LC_* is not set, so everything falls back to LANG - we're peachy - User sets Language, but wants something else changed, configures that in the Formats KCM, and it's applied by exporting LC_*, - we're fine again The Translations KCM probably the first one we should show when the category in systemsettings is opened, as it allows a very Global setting: LANG is changed, affects translations, and additionally all the formatting because LC_* not set means fall back to LANG. John Layt wrote: Ah, here we get to the difference between LANG and LANGUAGE and LC_* and the override hierarchy (see http://www.gnu.org/savannah-checkouts/gnu/libc/manual/html_node/Locale-Categories.html). LANG is the global default locale to use, with LC_* and LANGUAGE used to override that default for certain functions. The LANGUAGE override is a GNU gettext extension that allows you to define a priority list of languages to be used in the translation system, whereas LANG and LC_* only allow a single locale code at a time. For example, QLocale::uiLanguages() returns the list of whatever is held in LANGUAGE, otherwise whatever is in LC_MESSAGES, otherwise whatever is in LANG, otherwise defaulting to the C locale (en_US). Defining how that relationship between LANG and LANGUAGE will work in the config GUI is the tricky part. My original plan was to treat them completely separately: * The LANGUAGE envvar configures the gui translation systems, i.e. gettext and KLocalizedString, and QTranslator. The Translations kcm would configure it from a list of available translation catalogs installed, usually only 1 or 2, with en_US as the fallback. startkde would always export a LANGUAGE value, defaulting to the system LANG if no LANGUAGE value set in the kcm. It would also export the first value in the LANGUAGE list as LC_MESSAGES * The LANG and LC_* envvars configure the localization system, i.e. date formatting, number formatting, etc in glibc and ICU and QLocale. The kcm configures them from a list of available locale files installed, usually several hundred. These locale files contain month and day name translations separate to the gui translation system. startkde would export a value for LANG or LC_* only if set in the kcm. This would give users maximum flexibility while perhaps making it clearer why just selecting say an Arabic locale doesn't give you an Arabic gui translation. However I'm rethinking that a bit now, as while by default most users would never need to change anything after their initial distro install, I could see those users who do need to change being confused/annoyed at having to do it in two separate places. Having the two kcms messing with each others settings also seems a no-no to me, so the only alternative is to merge them. One other reason for the original approach was the rather problematic Languages tab in the old Locale kcm which I was copying for Translations. It uses a KActionSelector widget which shows side-by-side lists of Available Languages and Preferred Languages: you move the languages you want from Available to Preferred and then adjust the order. Problem is this takes up a lot of space so needs a separate pane or tab, but most of this space and functionality is wasted on most users who only have 1 or 2 KDE language packs installed: its a gui optimised for the 0.1% corner case of someone with dozens of languages installed who's regularly modifying them. There's also a debate about what the Available Languages list should show given we are setting LANGUAGES now for all apps under the workspace including gettext ones: do we list just the KDE language packs, or also all languages installed into /usr/share/locale, or all possible languages?
Re: Review Request 118063: New Formats KCM
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/118063/ --- (Updated May 13, 2014, 2:15 a.m.) Review request for Plasma and John Layt. Changes --- LANG is used as global setting. Bugs: 331930 https://bugs.kde.org/show_bug.cgi?id=331930 Repository: plasma-desktop Description --- The current Locale KCM is almost entirely broken. The way forward is to split it into localization options (this, Formats), and translaticons. This patch implements a new Formats KCM which writes out an environment suitable for QLocale to pick it up. It's a rewrite of the current KCM, since: - everything under the hood is different (KLocale is gone, QLocale takes over) - everything above the hood is different, in QLocale, everything is deduced from the country / region Now this includes feature regressions compared to the old KCM, but not all of these features can be done at all on top of QLocale right now, so we have to set up what we can. This KCM caches the settings in a config file, but most importantly, it writes out a script with export instructions, which can be picked up by startkde. This is all done according to John's suggestions, and I have a patch for startkde to pick up the settings here. It all works fine (on my machine). Many more details about the implementation can be found in the plasma-devel thead Locale settings in Plasma Next, started by John on February, 23rd 2014. Diffs (updated) - kcms/formats/kcmformats.cpp PRE-CREATION kcms/formats/kcmformats.h PRE-CREATION kcms/formats/formats.desktop PRE-CREATION kcms/formats/Messages.sh PRE-CREATION kcms/formats/CMakeLists.txt PRE-CREATION kcms/CMakeLists.txt ed86efa kcms/formats/kcmformatswidget.ui PRE-CREATION Diff: https://git.reviewboard.kde.org/r/118063/diff/ Testing --- Tried all kinds of different combinations, applied them, made sure they're exported correctly in the script. File Attachments new Formats KCM in kcmshell5 https://git.reviewboard.kde.org/media/uploaded/files/2014/05/09/873980fe-04f2-4d75-9074-2aa676723061__formatskcm.png Formats KCM in systemsettings https://git.reviewboard.kde.org/media/uploaded/files/2014/05/09/86a830ed-2d5d-4bdd-ba82-71ec73e6ce2c__formatskcmss.png Thanks, Sebastian Kügler ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
