Review Request 128626: silence contentHash deprecation warnings
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/128626/ --- Review request for KDE Frameworks and Plasma. Repository: kpackage Description --- - in test we actually want to use it for the purposes of the test - in kpackagetool we can use the new cryptographicHash func directly Diffs - autotests/plasmoidpackagetest.cpp 9b1cadec2296132c2ec4a7fc8142ec34cb3381f1 src/kpackagetool/kpackagetool.cpp 4f5b78761ced760f081b3449afc67790d25138a2 Diff: https://git.reviewboard.kde.org/r/128626/diff/ Testing --- builds & tests pass (sans appstream, which I guess I didn't break :P) Thanks, Harald Sitter
[Differential] [Closed] D2359: [libinput] Add support for gesture events
This revision was automatically updated to reflect the committed changes. Closed by commit rKWIN8a83a6fef56a: [libinput] Add support for gesture events (authored by graesslin). REPOSITORY rKWIN KWin CHANGES SINCE LAST UPDATE https://phabricator.kde.org/D2359?vs=5693&id=5726 REVISION DETAIL https://phabricator.kde.org/D2359 AFFECTED FILES autotests/libinput/CMakeLists.txt autotests/libinput/gesture_event_test.cpp autotests/libinput/mock_libinput.cpp autotests/libinput/mock_libinput.h debug_console.cpp debug_console.h input.cpp input.h libinput/connection.cpp libinput/connection.h libinput/events.cpp libinput/events.h pointer_input.cpp pointer_input.h EMAIL PREFERENCES https://phabricator.kde.org/settings/panel/emailpreferences/ To: graesslin, #kwin, #plasma_on_wayland, sebas Cc: plasma-devel, kwin, ali-mohamed, hardening, jensreuterberg, abetts, sebas
[Differential] [Closed] D2353: Change the default color in the color wallpaper plugin
This revision was automatically updated to reflect the committed changes. Closed by commit rPLASMAWORKSPACEd61bb962a1be: Change the default color in the color wallpaper plugin (authored by graesslin). REPOSITORY rPLASMAWORKSPACE Plasma Workspace CHANGES SINCE LAST UPDATE https://phabricator.kde.org/D2353?vs=5676&id=5727 REVISION DETAIL https://phabricator.kde.org/D2353 AFFECTED FILES wallpapers/color/contents/config/main.xml EMAIL PREFERENCES https://phabricator.kde.org/settings/panel/emailpreferences/ To: graesslin, #vdg, #plasma, sebas Cc: plasma-devel, ali-mohamed, jensreuterberg, abetts, sebas
[Differential] [Closed] D2234: [platforms/x11] Support output removal in nested setup
This revision was automatically updated to reflect the committed changes. Closed by commit rKWINa902ba8ea30d: [platforms/x11] Support output removal in nested setup (authored by graesslin). REPOSITORY rKWIN KWin CHANGES SINCE LAST UPDATE https://phabricator.kde.org/D2234?vs=5349&id=5728 REVISION DETAIL https://phabricator.kde.org/D2234 AFFECTED FILES plugins/platforms/x11/windowed/x11windowed_backend.cpp EMAIL PREFERENCES https://phabricator.kde.org/settings/panel/emailpreferences/ To: graesslin, #kwin, #plasma_on_wayland, sebas Cc: plasma-devel, kwin, ali-mohamed, hardening, jensreuterberg, abetts, sebas
Jenkins-kde-ci: plasma-workspace master kf5-qt5 » Linux,gcc - Build # 311 - Still Unstable!
GENERAL INFO BUILD UNSTABLE Build URL: https://build.kde.org/job/plasma-workspace%20master%20kf5-qt5/PLATFORM=Linux,compiler=gcc/311/ Project: PLATFORM=Linux,compiler=gcc Date of build: Mon, 08 Aug 2016 07:23:04 + Build duration: 17 min CHANGE SET Revision d61bb962a1be419c0f573cc315f5185e019d9223 by Martin Gräßlin: (Change the default color in the color wallpaper plugin) change: edit wallpapers/color/contents/config/main.xml JUNIT RESULTS Name: (root) Failed: 1 test(s), Passed: 8 test(s), Skipped: 0 test(s), Total: 9 test(s)Failed: TestSuite.screenpooltest COBERTURA RESULTS Cobertura Coverage Report PACKAGES 11/11 (100%)FILES 50/67 (75%)CLASSES 50/67 (75%)LINE 1973/5352 (37%)CONDITIONAL 1382/5478 (25%) By packages drkonqi.parser FILES 6/10 (60%)CLASSES 6/10 (60%)LINE 303/423 (72%)CONDITIONAL 478/616 (78%) drkonqi.tests.backtraceparsertest FILES 4/4 (100%)CLASSES 4/4 (100%)LINE 74/74 (100%)CONDITIONAL 33/50 (66%) kioslave.desktop FILES 2/3 (67%)CLASSES 2/3 (67%)LINE 113/168 (67%)CONDITIONAL 37/92 (40%) kioslave.desktop.tests FILES 1/1 (100%)CLASSES 1/1 (100%)LINE 66/66 (100%)CONDITIONAL 26/50 (52%) klipper FILES 12/13 (92%)CLASSES 12/13 (92%)LINE 256/384 (67%)CONDITIONAL 109/210 (52%) klipper.autotests FILES 4/4 (100%)CLASSES 4/4 (100%)LINE 630/693 (91%)CONDITIONAL 377/820 (46%) libtaskmanager FILES 5/16 (31%)CLASSES 5/16 (31%)LINE 139/3077 (5%)CONDITIONAL 88/3205 (3%) libtaskmanager.autotests FILES 2/2 (100%)CLASSES 2/2 (100%)LINE 150/150 (100%)CONDITIONAL 85/170 (50%) runners.bookmarks FILES 8/8 (100%)CLASSES 8/8 (100%)LINE 89/159 (56%)CONDITIONAL 34/96 (35%) runners.bookmarks.browsers FILES 4/4 (100%)CLASSES 4/4 (100%)LINE 88/93 (95%)CONDITIONAL 84/107 (79%) runners.bookmarks.tests FILES 2/2 (100%)CLASSES 2/2 (100%)LINE 65/65 (100%)CONDITIONAL 31/62 (50%)
[Differential] [Closed] D2352: Change default wallpaper plugin to org.kde.color
This revision was automatically updated to reflect the committed changes. Closed by commit rKSCREENLOCKERebd785d0ba22: Change default wallpaper plugin to org.kde.color (authored by graesslin). REPOSITORY rKSCREENLOCKER KScreenLocker CHANGES SINCE LAST UPDATE https://phabricator.kde.org/D2352?vs=5677&id=5729 REVISION DETAIL https://phabricator.kde.org/D2352 AFFECTED FILES kcfg/kscreenlockersettings.kcfg kcm/kcm.cpp EMAIL PREFERENCES https://phabricator.kde.org/settings/panel/emailpreferences/ To: graesslin, #plasma, #vdg Cc: bshah, plasma-devel, lesliezhai, ali-mohamed, jensreuterberg, abetts, sebas
[Differential] [Accepted] D2338: [Kickoff] Fix start row for drag not always being correct
broulik accepted this revision. broulik added a comment. This revision is now accepted and ready to land. There's still something off when I drag a bottom favorite to the top if often ends up in the wrong place or doesn't move at all. This is with and without this patch, so looks good to me. For 5.8 where I reworked the drag-drop stuff I'll look if this is still the case and fix it. :) REPOSITORY rPLASMADESKTOP Plasma Desktop REVISION DETAIL https://phabricator.kde.org/D2338 EMAIL PREFERENCES https://phabricator.kde.org/settings/panel/emailpreferences/ To: net147, bshah, #plasma, broulik Cc: plasma-devel, lesliezhai, ali-mohamed, jensreuterberg, abetts, sebas
[Differential] [Accepted] D2337: [Kickoff] Fix being unable to reorder entries in favorites menu after scrolling down
broulik accepted this revision. This revision is now accepted and ready to land. REPOSITORY rPLASMADESKTOP Plasma Desktop REVISION DETAIL https://phabricator.kde.org/D2337 EMAIL PREFERENCES https://phabricator.kde.org/settings/panel/emailpreferences/ To: net147, bshah, #plasma, broulik Cc: plasma-devel, lesliezhai, ali-mohamed, jensreuterberg, abetts, sebas
[Differential] [Request, 153 lines] D2369: Convert powerdevil backends to proper plugins
bshah created this revision. bshah added reviewers: Plasma, broulik. Restricted Application added a project: Plasma. Restricted Application added a subscriber: plasma-devel. REVISION SUMMARY This converts the powerdevil backends into proper plugins that are loaded at runtime instead of just hardcoding upowerbackend. And are also seperated from the powerdevil kded. This is first step to have other modules for example, wayland, hwcomposer etc. Logic for finding and loading backends is mostly inspired from the kscreen, currently it just loads upower backend because it is only module available. This logic can be changed when new backends are introduced in powedevil. TEST PLAN compiles, builds and installs backend module powerdevilupowerbackend.so into proper plugin path. Also verified with powerdevil kded that it gets loaded properly. REPOSITORY rPOWERDEVIL Powerdevil BRANCH bshah/proper-backends REVISION DETAIL https://phabricator.kde.org/D2369 AFFECTED FILES daemon/BackendConfig.cmake daemon/CMakeLists.txt daemon/backends/CMakeLists.txt daemon/backends/upower/powerdevilupowerbackend.h daemon/kdedpowerdevil.cpp daemon/kdedpowerdevil.h EMAIL PREFERENCES https://phabricator.kde.org/settings/panel/emailpreferences/ To: bshah, #plasma, broulik Cc: plasma-devel, lesliezhai, ali-mohamed, jensreuterberg, abetts, sebas
[Differential] [Updated, 147 lines] D2369: Convert powerdevil backends to proper plugins
bshah updated this revision to Diff 5732. bshah added a comment. remove unused stray function loadBackends REPOSITORY rPOWERDEVIL Powerdevil CHANGES SINCE LAST UPDATE https://phabricator.kde.org/D2369?vs=5731&id=5732 BRANCH bshah/proper-backends REVISION DETAIL https://phabricator.kde.org/D2369 AFFECTED FILES daemon/BackendConfig.cmake daemon/CMakeLists.txt daemon/backends/CMakeLists.txt daemon/backends/upower/powerdevilupowerbackend.h daemon/kdedpowerdevil.cpp daemon/kdedpowerdevil.h EMAIL PREFERENCES https://phabricator.kde.org/settings/panel/emailpreferences/ To: bshah, #plasma, broulik Cc: plasma-devel, lesliezhai, ali-mohamed, jensreuterberg, abetts, sebas
[Differential] [Accepted] D2369: Convert powerdevil backends to proper plugins
broulik accepted this revision.
broulik added a comment.
This revision is now accepted and ready to land.
Looks good to me.
> wayland
Wayland would still use upower but instead of having XRandRBrightness only
use sysfs, this needs some more thought on how we could split that in the
future, I guess.
INLINE COMMENTS
> kdedpowerdevil.cpp:83
> +const QStringList paths = QCoreApplication::libraryPaths();
> +QFileInfoList finfos;
> +for (const QString& path : paths) {
fileInfos
also call reserve() as you later iterate something and add an already known
number of items
> kdedpowerdevil.cpp:84
> +QFileInfoList finfos;
> +for (const QString& path : paths) {
> +QDir dir(path + QLatin1String("/kf5/powerdevil/"),
const QString &paths
> kdedpowerdevil.cpp:94
> +Q_FOREACH (const QFileInfo &f, finfos) {
> +if (f.baseName().toLower() ==
> QStringLiteral("powerdevilupowerbackend")) {
> +backendFileInfo = f;
compare with QLatin1String
> kdedpowerdevil.cpp:100
>
> -if (!interface) {
> -// Ouch
> +QPluginLoader* loader = new QPluginLoader(backendFileInfo.filePath(),
> m_core);
> +QObject *instance = loader->instance();
QPluginLoader *
> kdedpowerdevil.cpp:107
> } else {
> -// Let's go!
> +auto interface =
> qobject_cast(instance);
> qCDebug(POWERDEVIL) << "Backend loaded, loading core";
Check for interface being null (cast failed) maybe?
REPOSITORY
rPOWERDEVIL Powerdevil
BRANCH
bshah/proper-backends
REVISION DETAIL
https://phabricator.kde.org/D2369
EMAIL PREFERENCES
https://phabricator.kde.org/settings/panel/emailpreferences/
To: bshah, broulik, #plasma
Cc: plasma-devel, lesliezhai, ali-mohamed, jensreuterberg, abetts, sebas
Re: Selecting a Plasma logo
Hey Sebas, Thanks for understanding. As I mentioned before my intention is not necessarily that don't change my proposal but that we can create more proposals to show variety. We cannot settle just on 2 orignal proposals and then merge the two to see what comes out. I am pretty sure there many other ways of giving Plasma an identity and I would love to see more. My thoughts are that we keep on getting proposals, we don't really have a deadline and we can probably get many more people to come up with ideas. Art contests are generally about original artwork. It is not about "my way or the highway" but rather, "my way or any other highway." Because I am sure that there are more options than just two. Should we past this and not start an argument by requesting more logo proposals? We need to move forward. On August 5, 2016 at 7:07:17 AM, Sebastian Kügler (se...@kde.org) wrote: > Hi Andres, > > Sorry it took a few days to reply. > > On dinsdag 2 augustus 2016 07:45:10 CEST Andres Betts wrote: > > Let me explain the reasons about changing the logo and what stage this is > at. In my personal view, after working for some time on coming up with a > new logo proposal, we received a few comments and changes to it that, to > me, had no backing. One idea was shared that others wanted my proposal to > look closer, or have characteristics from the KDE logo. > > However, I am not of the preference of changing my proposal and adding > more > elements to it, because I thought about this long and hard and reduced the > proposal to the simplest of forms that conveyed a meaning. Adding elements > from the KDE logo, or the last Plasma logo doesn’t seem logical given that > the last logo really had no meaning behind it, so there is not much that > justifies its presence there. Some might argue that it is also about the > public not recognizing the logo and what it belongs to. > > > Well, that's not quite true. Especially the simplified arrow indicated > "shell", > something Plasma is all about. The three dots are elements for plugins, > scripting and (I think) containments. So the elements *do* have a meaning. > > “Changes” or modifications that happen “after” the contest is over are all > about simple edits. I consider my current logo to be in “beta” and only > bugs and simple edits could be made. For example, the thickness of a > border, or the sizes of the circles. I am not looking to strikingly change > or modify the logo I created because I consider it to be near final. > > > That's of course fine. My point was that if we pick a logo, and then > change it > afterwards, it's not the logo we picked. (I agree, simple edits are fine, > but > the comments weren't about simple edits, as far as understand.) > > However, if others want to make proposals that the Plasma team might like > better, maybe it is a better thing to create original proposals and not > change my proposal to be what you think should be there. If the Plasma > team > feels that my logo is not what they would like to have, then let’s not > modify it and find an original alternative created by different artists. > > > I disagree there. Plasma is a collaborative project, we do things > together. My > way of the highway is generally not the way we work, and I think it's > quite > natural to suggest changes, that is how we usually work. > > I think people may have been confused by you making the logo available > under a > license that allows changes, so we thought that it's OK to polish it some > more. If it isn't, that's also fine, but it explains where this confusion > comes > from. > > Personally, I find it unfortunate that you do not want any changes to the > logo. > I can undestand it, but given its basic design is quite popular, I think > it's > a shame to ask people not to change it. I respect your choice, however, so > I > guess that's how it is. > > Cheers, > -- > sebas > > Sebastian Kügler • http://vizZzion.org • http://www.kde.org > >
Re: Selecting a Plasma logo
Hey Sebastian, Let me explain the reasons about changing the logo and what stage this is at. In my personal view, after working for some time on coming up with a new logo proposal, we received a few comments and changes to it that, to me, had no backing. One idea was shared that others wanted my proposal to look closer, or have characteristics from the KDE logo. However, I am not of the preference of changing my proposal and adding more elements to it, because I thought about this long and hard and reduced the proposal to the simplest of forms that conveyed a meaning. Adding elements from the KDE logo, or the last Plasma logo doesn’t seem logical given that the last logo really had no meaning behind it, so there is not much that justifies its presence there. Some might argue that it is also about the public not recognizing the logo and what it belongs to. “Changes” or modifications that happen “after” the contest is over are all about simple edits. I consider my current logo to be in “beta” and only bugs and simple edits could be made. For example, the thickness of a border, or the sizes of the circles. I am not looking to strikingly change or modify the logo I created because I consider it to be near final. However, if others want to make proposals that the Plasma team might like better, maybe it is a better thing to create original proposals and not change my proposal to be what you think should be there. If the Plasma team feels that my logo is not what they would like to have, then let’s not modify it and find an original alternative created by different artists. On August 2, 2016 at 8:08:41 AM, Sebastian Kügler (se...@kde.org) wrote: On dinsdag 2 augustus 2016 14:11:25 CEST Thomas Pfeiffer wrote: > On 01.08.2016 15:11, Thomas Pfeiffer wrote: > > So, it looks like there are two variants which people are quite fond of, > > Ken's modifications of Andy's logo (his fourth), and of Alex's logo (his > > second). > > > > The second has the advantage that it has elements of the KDE logo in it > > and > > can therefore be associated with KDE most easily, > > whereas the fourth has a clearer association with a sun, and its > > simplicity > > allows for easy adaptation for different contexts while keeping its > > identity easily recognizable. > > > > The disadvantages of the second one are that the gears become a bit > > muddled > > in small sizes and it resembles the gear which is often used as a settings > > icon, the disadvantage of the fourth is that it vaguely resembles a > > speech bubble, reminding some people of an IM application logo. > > > > The VDG clearly favors Anditosan's logo, so Ken's fourth (which fixes the > > problem of being too "generic" as some of the Plasma team members > > feared) looks like the one which would sit best with both the VDG and the > > Plasma team. > > > > Therefore I'd like to propose to go with Ken's modification of Andy's logo > > (perhaps with one more round of fine-tuning by the VDG before shipping > > it). > > Are there any objections to that? > > We've just learned that Anditosan does want to see modifications of his logo > in the contest. He is open to modifying his logo after the contest if > needed, but he'd prefer to modify it himself instead of others creating > mashups. Why modify it after a contest? That would make the choice rather pointless, if it's going to be different aftwards anyway. Can you ask him to make the changes and send us the result, so we can judge based on that? > Therefore, Ken's modification (i.e. his fourth) is out of the question for > now. > > So either we take Andy's original logo (without the > ) and ask for > modifications in a second iteration afterwards, or we have to take something > not based on his logo (for example Ken's second). > > What will it be, then? -- sebas http://www.kde.org | http://vizZzion.org ___ Visual-design mailing list visual-des...@kde.org https://mail.kde.org/mailman/listinfo/visual-design
Re: unexpected "show desktop" shortcut (KDE4)
On Saturday, 6 August 2016 10:24:13 BST René J.V. Bertin wrote: > Hi, > > I hit an accidental and as yet unidentified shortcut and am now seeing a > "Show Desktop" entry in the task switcher. I'm 95% sure I deactivated the > "Show Desktop Icon" option in the task switcher settings. Is there a > shortcut to activate this option? > > To give an idea what keys I may have hit: I triggered this by a borked > attempt to use the hardware shortcut Fn-F2 (turns off backlighting); the Fn > key sits between the Ctrl and "Windows" keys. > > Thanks, > René Have you tried adding he "Show Desktop" widget to your taskbar as a permanent option? You can then right click the icon and choose your own shortcut keys -- Qt: 5.6.1 KDE Frameworks: 5.24.0 kf5-config: 1.0 KDE Plasma: 5.7.3 Kernel: 4.7.0-1-default "openSUSE Tumbleweed (20160730) (x86_64)"
Jenkins-kde-ci: plasma-workspace master kf5-qt5 » Linux,gcc - Build # 312 - Fixed!
GENERAL INFO BUILD SUCCESS Build URL: https://build.kde.org/job/plasma-workspace%20master%20kf5-qt5/PLATFORM=Linux,compiler=gcc/312/ Project: PLATFORM=Linux,compiler=gcc Date of build: Mon, 08 Aug 2016 08:52:10 + Build duration: 8 min 39 sec CHANGE SET Revision cb360c0a2b6181d10237916d8043c259224c9fb7 by Marco Martin: (take into account a primary screen) change: edit shell/autotests/screenpooltest.cpp JUNIT RESULTS Name: (root) Failed: 0 test(s), Passed: 9 test(s), Skipped: 0 test(s), Total: 9 test(s) COBERTURA RESULTS Cobertura Coverage Report PACKAGES 13/13 (100%)FILES 52/69 (75%)CLASSES 52/69 (75%)LINE 2061/5460 (38%)CONDITIONAL 1414/5572 (25%) By packages drkonqi.parser FILES 6/10 (60%)CLASSES 6/10 (60%)LINE 303/423 (72%)CONDITIONAL 478/616 (78%) drkonqi.tests.backtraceparsertest FILES 4/4 (100%)CLASSES 4/4 (100%)LINE 74/74 (100%)CONDITIONAL 33/50 (66%) kioslave.desktop FILES 2/3 (67%)CLASSES 2/3 (67%)LINE 113/168 (67%)CONDITIONAL 37/92 (40%) kioslave.desktop.tests FILES 1/1 (100%)CLASSES 1/1 (100%)LINE 66/66 (100%)CONDITIONAL 26/50 (52%) klipper FILES 12/13 (92%)CLASSES 12/13 (92%)LINE 256/384 (67%)CONDITIONAL 109/210 (52%) klipper.autotests FILES 4/4 (100%)CLASSES 4/4 (100%)LINE 630/693 (91%)CONDITIONAL 377/820 (46%) libtaskmanager FILES 5/16 (31%)CLASSES 5/16 (31%)LINE 139/3077 (5%)CONDITIONAL 88/3205 (3%) libtaskmanager.autotests FILES 2/2 (100%)CLASSES 2/2 (100%)LINE 150/150 (100%)CONDITIONAL 85/170 (50%) runners.bookmarks FILES 8/8 (100%)CLASSES 8/8 (100%)LINE 89/159 (56%)CONDITIONAL 34/96 (35%) runners.bookmarks.browsers FILES 4/4 (100%)CLASSES 4/4 (100%)LINE 88/93 (95%)CONDITIONAL 84/107 (79%) runners.bookmarks.tests FILES 2/2 (100%)CLASSES 2/2 (100%)LINE 65/65 (100%)CONDITIONAL 31/62 (50%) shell FILES 1/1 (100%)CLASSES 1/1 (100%)LINE 49/69 (71%)CONDITIONAL 17/64 (27%) shell.autotests FILES 1/1 (100%)CLASSES 1/1 (100%)LINE 39/39 (100%)CONDITIONAL 15/30 (50%)
Jenkins-kde-ci: plasma-workspace master kf5-qt5 » Linux,gcc - Build # 312 - Fixed!
GENERAL INFO BUILD SUCCESS Build URL: https://build.kde.org/job/plasma-workspace%20master%20kf5-qt5/PLATFORM=Linux,compiler=gcc/312/ Project: PLATFORM=Linux,compiler=gcc Date of build: Mon, 08 Aug 2016 08:52:10 + Build duration: 8 min 39 sec CHANGE SET Revision cb360c0a2b6181d10237916d8043c259224c9fb7 by Marco Martin: (take into account a primary screen) change: edit shell/autotests/screenpooltest.cpp JUNIT RESULTS Name: (root) Failed: 0 test(s), Passed: 9 test(s), Skipped: 0 test(s), Total: 9 test(s) COBERTURA RESULTS Cobertura Coverage Report PACKAGES 13/13 (100%)FILES 52/69 (75%)CLASSES 52/69 (75%)LINE 2061/5460 (38%)CONDITIONAL 1414/5572 (25%) By packages drkonqi.parser FILES 6/10 (60%)CLASSES 6/10 (60%)LINE 303/423 (72%)CONDITIONAL 478/616 (78%) drkonqi.tests.backtraceparsertest FILES 4/4 (100%)CLASSES 4/4 (100%)LINE 74/74 (100%)CONDITIONAL 33/50 (66%) kioslave.desktop FILES 2/3 (67%)CLASSES 2/3 (67%)LINE 113/168 (67%)CONDITIONAL 37/92 (40%) kioslave.desktop.tests FILES 1/1 (100%)CLASSES 1/1 (100%)LINE 66/66 (100%)CONDITIONAL 26/50 (52%) klipper FILES 12/13 (92%)CLASSES 12/13 (92%)LINE 256/384 (67%)CONDITIONAL 109/210 (52%) klipper.autotests FILES 4/4 (100%)CLASSES 4/4 (100%)LINE 630/693 (91%)CONDITIONAL 377/820 (46%) libtaskmanager FILES 5/16 (31%)CLASSES 5/16 (31%)LINE 139/3077 (5%)CONDITIONAL 88/3205 (3%) libtaskmanager.autotests FILES 2/2 (100%)CLASSES 2/2 (100%)LINE 150/150 (100%)CONDITIONAL 85/170 (50%) runners.bookmarks FILES 8/8 (100%)CLASSES 8/8 (100%)LINE 89/159 (56%)CONDITIONAL 34/96 (35%) runners.bookmarks.browsers FILES 4/4 (100%)CLASSES 4/4 (100%)LINE 88/93 (95%)CONDITIONAL 84/107 (79%) runners.bookmarks.tests FILES 2/2 (100%)CLASSES 2/2 (100%)LINE 65/65 (100%)CONDITIONAL 31/62 (50%) shell FILES 1/1 (100%)CLASSES 1/1 (100%)LINE 49/69 (71%)CONDITIONAL 17/64 (27%) shell.autotests FILES 1/1 (100%)CLASSES 1/1 (100%)LINE 39/39 (100%)CONDITIONAL 15/30 (50%)
[Differential] [Updated] D2369: Convert powerdevil backends to proper plugins
bshah marked an inline comment as done. bshah added a comment. Fixed issues.. REPOSITORY rPOWERDEVIL Powerdevil BRANCH bshah/proper-backends REVISION DETAIL https://phabricator.kde.org/D2369 EMAIL PREFERENCES https://phabricator.kde.org/settings/panel/emailpreferences/ To: bshah, #plasma, broulik Cc: plasma-devel, lesliezhai, ali-mohamed, jensreuterberg, abetts, sebas
[Differential] [Updated, 159 lines] D2369: Convert powerdevil backends to proper plugins
bshah updated this revision to Diff 5734. bshah marked 4 inline comments as done. bshah added a comment. fixed minor coding style issues and make code failsafe REPOSITORY rPOWERDEVIL Powerdevil CHANGES SINCE LAST UPDATE https://phabricator.kde.org/D2369?vs=5732&id=5734 BRANCH bshah/proper-backends REVISION DETAIL https://phabricator.kde.org/D2369 AFFECTED FILES daemon/BackendConfig.cmake daemon/CMakeLists.txt daemon/backends/CMakeLists.txt daemon/backends/upower/powerdevilupowerbackend.h daemon/kdedpowerdevil.cpp daemon/kdedpowerdevil.h EMAIL PREFERENCES https://phabricator.kde.org/settings/panel/emailpreferences/ To: bshah, #plasma, broulik Cc: plasma-devel, lesliezhai, ali-mohamed, jensreuterberg, abetts, sebas
[Differential] [Closed] D2338: [Kickoff] Fix start row for drag not always being correct
This revision was automatically updated to reflect the committed changes. Closed by commit rPLASMADESKTOP5eaadb75de3d: [Kickoff] Fix start row for drag not always being correct (authored by net147, committed by bshah). CHANGED PRIOR TO COMMIT https://phabricator.kde.org/D2338?vs=5642&id=5737#toc REPOSITORY rPLASMADESKTOP Plasma Desktop CHANGES SINCE LAST UPDATE https://phabricator.kde.org/D2338?vs=5642&id=5737 REVISION DETAIL https://phabricator.kde.org/D2338 AFFECTED FILES applets/kickoff/package/contents/ui/FavoritesView.qml EMAIL PREFERENCES https://phabricator.kde.org/settings/panel/emailpreferences/ To: net147, bshah, #plasma, broulik Cc: plasma-devel, lesliezhai, ali-mohamed, jensreuterberg, abetts, sebas
[Differential] [Closed] D2337: [Kickoff] Fix being unable to reorder entries in favorites menu after scrolling down
This revision was automatically updated to reflect the committed changes. Closed by commit rPLASMADESKTOP784b07f26ae8: [Kickoff] Fix being unable to reorder entries in favorites menu after… (authored by net147, committed by bshah). CHANGED PRIOR TO COMMIT https://phabricator.kde.org/D2337?vs=5641&id=5736#toc REPOSITORY rPLASMADESKTOP Plasma Desktop CHANGES SINCE LAST UPDATE https://phabricator.kde.org/D2337?vs=5641&id=5736 REVISION DETAIL https://phabricator.kde.org/D2337 AFFECTED FILES applets/kickoff/package/contents/ui/FavoritesView.qml EMAIL PREFERENCES https://phabricator.kde.org/settings/panel/emailpreferences/ To: net147, bshah, #plasma, broulik Cc: plasma-devel, lesliezhai, ali-mohamed, jensreuterberg, abetts, sebas
[Differential] [Closed] D2369: Convert powerdevil backends to proper plugins
This revision was automatically updated to reflect the committed changes. Closed by commit rPOWERDEVIL2e2faec92053: Convert powerdevil backends to proper plugins (authored by bshah). REPOSITORY rPOWERDEVIL Powerdevil CHANGES SINCE LAST UPDATE https://phabricator.kde.org/D2369?vs=5734&id=5738 REVISION DETAIL https://phabricator.kde.org/D2369 AFFECTED FILES daemon/BackendConfig.cmake daemon/CMakeLists.txt daemon/backends/CMakeLists.txt daemon/backends/upower/powerdevilupowerbackend.h daemon/kdedpowerdevil.cpp daemon/kdedpowerdevil.h EMAIL PREFERENCES https://phabricator.kde.org/settings/panel/emailpreferences/ To: bshah, #plasma, broulik Cc: plasma-devel, lesliezhai, ali-mohamed, jensreuterberg, abetts, sebas
Re: Discussion for libtaskmanager internals
On 08/05/2016 06:12 PM, Michail Vourlakos wrote: > Is this the intended behavior? Yes. A stable lifecycle in the view is achieved by the combination of two effects: The appearance of certain items causes items "earlier" in the lifecycle to be filtered out and sorting things into the same place (depending on options). In our applets that's fine to achieve the desired visual result. > I believe that a more friendly approach is needed in my use case for > example instead of 2 removals and 2 adds just an update in the values. > The launcher is already there, so updating its state to startup and then > to a window would be enough. None of the lifecycle stages are guaranteed to occur, nor is their order guaranteed, nor is it always possible to reliably relate them to each other because the metadata for each can be incomplete or unreliable. The code is therefore written for simplicity to treat these all as separate and collapse things by filtering and sorting where possible. It keeps all the models simple list models and the proxy that collapses-by-filtering and sorts relatively simple as well. Yes, replacing add+remove with change transactions would be desirable for some views, but it's not needed for the ones we ship, and would make the code a fair bit more complicated, which is why it's not a goal for now. Feel free to work on that and we iterate on getting it in - but you should look for feedback early and make sure you have the patience because it's likely to be a fairly long review process (high quality and clarity goals for this code). > Another important aspect in the TasksModel which bothers me is that each > item in the model does not have the same pair values. for example a > startup item does not have an "IsWindow" value, qml triggers "undefined" > for property "IsWindow" in its case and this is a way to ckeck its > existence, not by true or false but from the property's existence. > > Is this also the intended behavior? AbstractTasksModel implementations that don't implement particular data roles just fall through to QVariant() for them, which is undefined in Qt Quick. What you can do in your QML code is to check for true/false with the ===/==! operators, but I'd also accept a patch that implements "missing" data roles across all the AbstractTasksModel subclasses - I consider that a bit noisy and opted not to do it, but it's a personal style choice and I don't mind accomodating other styles. Feel free to submit a patch for this. > What I am proposing is that there shouldnt be adds and removals from > startup to window, only updates. The same is when there is a launcher, > only updates. I believe adds and removals should be only for new items, > for example when windows are not grouped together or are not grouped > with their launcher. I dont consider a startup different in the model > from the window or at least there should be a choice for the developer > if he wants to have two different items in the model for startup and window. See above - I agree it's nice to have for the optimal case, but the code is essentially written for simplicity and conservativeness (i.e. assume the optimal case won't be hit). I'm fine with someone doing additional engineering effort to optimize the optimal case, but since it will considerably complicate the code it needs to be reviewed very closely. Cheers, Eike
Re: Review Request 128473: Avoid recursive calls to QPlatformTheme::createPlatformSystemTrayIcon()
> On July 19, 2016, 4:02 a.m., David Edmundson wrote: > > KStatusNotifierItemPrivate::setLegacySystemTrayEnabled(bool enabled) > > already has a recursion check added in > > b45544f3d4dd9cb1873b92a609f45a68f5f6e471 (in knotifications) - which > > basically checks if we're using the KDE platform theme (albeit in a > > slightly weird way) > > > > Not saying yours is "worse" but we don't want two fixes in two places. > > > > Could you check you have that patch? and why it doesn't work? > > Martin Tobias Holmedahl Sandsmark wrote: > firstly, as you said, it checks in a weird way, which doesn't work, > that's why I thought it made more sense to fix it in the platform theme > itself which already knows that it is loaded and whether an SNI host is > available. > > (fwiw, qApp->platformName() is not correct either, that's what I thought > was the "proper" way to do it) > > Martin Tobias Holmedahl Sandsmark wrote: > patching around that also leads to no legacy tray icon being created at > all, which is obviously wrong. > > David Edmundson wrote: > Is it wrong? > > If you're logged in to a plasma session with the plasma integration > running it's a valid assumption that people will run Plasmashell. > > Without plasmashell you won't get the legacy tray icons appearing either. > > And if you're running a different shell..you shouldn't be using the > plasma integration in the first place. > > Martin Tobias Holmedahl Sandsmark wrote: > The legacy tray icons will work in cases where SNI won't, so breaking > that fallback is wrong in my opinion, but I agree it is better than the > alternative. > > Anyhow, this is a mess and the interdependencies on behaviour is bad. > IMHO it should be "fixed" in both places, the plasma-integration plugin > shouldn't rely on some shaky string magic logic in KSNI not to hang > applications. > > So if the only objection to this patch is that some applications a) under > X11 get a legacy tray icon instead of a SNI one if started too early instead > of hanging, b) under Wayland might not get a tray icon at all instead of just > hanging if started too early, I think this should go in. > > David Edmundson wrote: > >The legacy tray icons will work in cases where SNI won't > > How? If Plasmashell is running you get the SNIs. If plasmashell is not > running you don't get the legacy icons anyway. > > It's not going in until you can explain: > 1) why this is needed > 2) why the other patch doesn't work. > > Martin Tobias Holmedahl Sandsmark wrote: > > How? If Plasmashell is running you get the SNIs. If plasmashell is not > running you don't get the legacy icons anyway. > > Because they're very different technologies with very different kinds of > bugs? There's a reason the fallback is there already. > > and that's just the unintended ways it can fail, then you have users that > for some reasons intentionally don't run plasma-shell with the default > settings, use another tray solution, etc. > > > > 2) why the other patch doesn't work. > > The other patch won't work because it doesn't know if the plasma > integration plugin is loaded. it's also the wrong place to put those kinds of > checks, even if you would find a 100% bulletproof bug free way to detect > that. hardcoding in fixes for bugs in platform plugins (e. g. if another > platform plugin decides to do the same) is wrong. > > and as already demonstrated, it doesn't work well in practice. > > > > 1) why this is needed > > to avoid applications hanging/crashing, approach the zen of failing > gracefully, and in general make this a bit more robust. > > imho, this shouldn't even be using the same KSNI classes that > applications are supposed to use, it's a design error that leads to these > kinds of problems, but this makes it a bit more sane. > > > but this discussion was absurd several posts ago, and it's not getting > better... > > Martin Gräßlin wrote: > So could you please explain why the existing solution doesn't work and > why this is needed in addition? We just try to understand and whether there > are things we need to change in KNotifications. > > Btw. the fact that this will break SNIs during startup in a racy way on > Wayland is a reason for me to not make it go in. We need to start thinking > about the "can break in Wayland" cases more, after all there are people using > it productivly ;-) > > Martin Tobias Holmedahl Sandsmark wrote: > Sorry for the late reply, dayjob started up again. :-) > > > > So could you please explain why the existing solution doesn't work [...] > > I'll try to summarize: > > * It has the same race condition problem that you say this patch has, > only worse, as far as I can tell. If a SNI is unavailable on startup o
[Differential] [Request, 59 lines] D2371: [Wayland] Make it possible to have internal windows decorated
graesslin created this revision. graesslin added reviewers: KWin, Plasma on Wayland, sebas. Restricted Application added subscribers: kwin, plasma-devel. Restricted Application added projects: Plasma on Wayland, KWin. REVISION SUMMARY With this change KWin can create window decorations for internal windows. Thus it's also possible to move internal windows and resize them which is especially important for the debug console. REPOSITORY rKWIN KWin BRANCH internal-window-deco REVISION DETAIL https://phabricator.kde.org/D2371 AFFECTED FILES autotests/integration/internal_window.cpp input.cpp plugins/qpa/window.cpp pointer_input.cpp shell_client.cpp shell_client.h workspace.cpp EMAIL PREFERENCES https://phabricator.kde.org/settings/panel/emailpreferences/ To: graesslin, #kwin, #plasma_on_wayland, sebas Cc: plasma-devel, kwin, lesliezhai, ali-mohamed, hardening, jensreuterberg, abetts, sebas
[Differential] [Accepted] D2371: [Wayland] Make it possible to have internal windows decorated
sebas accepted this revision. sebas added a comment. This revision is now accepted and ready to land. Looks good to me. REPOSITORY rKWIN KWin BRANCH internal-window-deco REVISION DETAIL https://phabricator.kde.org/D2371 EMAIL PREFERENCES https://phabricator.kde.org/settings/panel/emailpreferences/ To: graesslin, #kwin, sebas, #plasma_on_wayland Cc: plasma-devel, kwin, lesliezhai, ali-mohamed, hardening, jensreuterberg, abetts, sebas
[Plasma Workspace Wallpapers] [Bug 366470] Add unsplash wallpapers to KDE
https://bugs.kde.org/show_bug.cgi?id=366470 Sebastian Kügler changed: What|Removed |Added CC||se...@kde.org Resolution|--- |WONTFIX Status|UNCONFIRMED |RESOLVED --- Comment #1 from Sebastian Kügler --- This is not something we really want to do. If anyone wants to submit a wallpaper, and it's good quality and the person will maintain it, that'd be fine. Adding a whole slew of wallpapers to Plasma from a 3rd party site isn't. That would really only open us up to shipping every single photo in the world, because somebody likes it. I think it's easy enough to add your own wallpapers, they can be done by a 3rd party. -- You are receiving this mail because: You are the assignee for the bug.
[Differential] [Closed] D2371: [Wayland] Make it possible to have internal windows decorated
This revision was automatically updated to reflect the committed changes. Closed by commit rKWIN981b31232335: [Wayland] Make it possible to have internal windows decorated (authored by graesslin). REPOSITORY rKWIN KWin CHANGES SINCE LAST UPDATE https://phabricator.kde.org/D2371?vs=5739&id=5740 REVISION DETAIL https://phabricator.kde.org/D2371 AFFECTED FILES autotests/integration/internal_window.cpp input.cpp plugins/qpa/window.cpp pointer_input.cpp shell_client.cpp shell_client.h workspace.cpp EMAIL PREFERENCES https://phabricator.kde.org/settings/panel/emailpreferences/ To: graesslin, #kwin, sebas, #plasma_on_wayland Cc: plasma-devel, kwin, lesliezhai, ali-mohamed, hardening, jensreuterberg, abetts, sebas
[Differential] [Request, 107 lines] D2372: Make powerdevil normal executable instead of kded module
bshah created this revision. bshah added reviewers: Plasma, broulik, graesslin. Restricted Application added a project: Plasma. Restricted Application added a subscriber: plasma-devel. REVISION SUMMARY This will allow kwin to grant permission to powerdevil which no other application should have. Previously used kded module is now replaced by the application which installs in LIBEXEC dir and started by desktop file in /etc/xdg/autostart TEST PLAN Restarted session, powerdevil starts and all functions work perfectly REPOSITORY rPOWERDEVIL Powerdevil BRANCH powerdevil-executable (branched from master) REVISION DETAIL https://phabricator.kde.org/D2372 AFFECTED FILES daemon/CMakeLists.txt daemon/kdedpowerdevil.cpp daemon/kdedpowerdevil.h daemon/main.cpp daemon/powerdevil.desktop daemon/powerdevil.desktop.cmake daemon/powerdevilapp.cpp daemon/powerdevilapp.h EMAIL PREFERENCES https://phabricator.kde.org/settings/panel/emailpreferences/ To: bshah, #plasma, broulik, graesslin Cc: plasma-devel, lesliezhai, ali-mohamed, jensreuterberg, abetts, sebas
[Differential] [Commented On] D2372: Make powerdevil normal executable instead of kded module
bshah added a comment. Something is wrong with this on wayland, I don't see battery and brightness applet and powerdevil executable seems to exit safely if I remove it.. Here is log of powerdevil executable https://ptpb.pw/9Jtd.. REPOSITORY rPOWERDEVIL Powerdevil REVISION DETAIL https://phabricator.kde.org/D2372 EMAIL PREFERENCES https://phabricator.kde.org/settings/panel/emailpreferences/ To: bshah, #plasma, broulik, graesslin Cc: plasma-devel, lesliezhai, ali-mohamed, jensreuterberg, abetts, sebas
[Plasma Workspace Wallpapers] [Bug 366470] Add unsplash wallpapers to KDE
https://bugs.kde.org/show_bug.cgi?id=366470 Martin Klapetek changed: What|Removed |Added CC||mklape...@kde.org --- Comment #2 from Martin Klapetek --- I believe the purpose of this report was to write a Wallpaper plugin that would fetch those images through the linked API, slideshow style even. -- You are receiving this mail because: You are the assignee for the bug.
[Differential] [Commented On] D1989: Introduce QQuickItem to nest kwin_wayland
graesslin added a comment. > - KeyPress events to send keys. > > However, keyevents are not working as it should, if i press 'a' it types something different. might be that this is just not possible to send key events like that. In general QKeyEvent delivers the keysym. That is the scan code translated through the keyboard layout. The nativeSccanCode should have the original value but I would not trust it completely. Maybe leave key events out for the moment as an we don't necessarily need key events. REPOSITORY rKWIN KWin REVISION DETAIL https://phabricator.kde.org/D1989 EMAIL PREFERENCES https://phabricator.kde.org/settings/panel/emailpreferences/ To: bdhruve, bshah, graesslin, #plasma_on_wayland Cc: bshah, graesslin, plasma-devel, kwin, lesliezhai, ali-mohamed, hardening, jensreuterberg, abetts, sebas
[Differential] [Closed] D2345: use a separate configuration per look and feel
This revision was automatically updated to reflect the committed changes. Closed by commit rPLASMAWORKSPACE2ddde5efc1e3: remove graphicsobject hack (authored by mart). CHANGED PRIOR TO COMMIT https://phabricator.kde.org/D2345?vs=5742&id=5743#toc REPOSITORY rPLASMAWORKSPACE Plasma Workspace CHANGES SINCE LAST UPDATE https://phabricator.kde.org/D2345?vs=5742&id=5743 REVISION DETAIL https://phabricator.kde.org/D2345 AFFECTED FILES shell/shellcorona.cpp EMAIL PREFERENCES https://phabricator.kde.org/settings/panel/emailpreferences/ To: mart, #plasma, davidedmundson Cc: davidedmundson, ivan, plasma-devel, lesliezhai, ali-mohamed, jensreuterberg, abetts, sebas
[Plasma Workspace Wallpapers] [Bug 366470] Add unsplash wallpapers to KDE
https://bugs.kde.org/show_bug.cgi?id=366470 --- Comment #3 from Richard Bos --- Indeed Martin. My idea is not to include each and every wallpaper, but to offer the source via ( wallpaper ) plugin(s). Either by making it easily available to the user, or as a dynamic wallpaper. -- Richard ps: if the above correction make sense, change the status to inprogress. -- You are receiving this mail because: You are the assignee for the bug.
[Differential] [Updated, 306 lines] D2345: use a separate configuration per look and feel
mart updated this revision to Diff 5742. mart added a comment. - remove graphicsobject hack REPOSITORY rPLASMAWORKSPACE Plasma Workspace CHANGES SINCE LAST UPDATE https://phabricator.kde.org/D2345?vs=5701&id=5742 BRANCH mart/separateLookAndFeelLayout REVISION DETAIL https://phabricator.kde.org/D2345 AFFECTED FILES shell/dbus/org.kde.PlasmaShell.xml shell/scripting/containment.cpp shell/shellcorona.cpp shell/shellcorona.h EMAIL PREFERENCES https://phabricator.kde.org/settings/panel/emailpreferences/ To: mart, #plasma, davidedmundson Cc: davidedmundson, ivan, plasma-devel, lesliezhai, ali-mohamed, jensreuterberg, abetts, sebas
[Differential] [Reopened] D2345: use a separate configuration per look and feel
mart reopened this revision. REPOSITORY rPLASMAWORKSPACE Plasma Workspace REVISION DETAIL https://phabricator.kde.org/D2345 EMAIL PREFERENCES https://phabricator.kde.org/settings/panel/emailpreferences/ To: mart, #plasma, davidedmundson Cc: davidedmundson, ivan, plasma-devel, lesliezhai, ali-mohamed, jensreuterberg, abetts, sebas
[Plasma Workspace Wallpapers] [Bug 366470] Add unsplash wallpapers to KDE
https://bugs.kde.org/show_bug.cgi?id=366470 --- Comment #4 from Sebastian Kügler --- Ah. Why in progress though? Who is working on it? -- You are receiving this mail because: You are the assignee for the bug.
[Differential] [Changed Subscribers] D2372: Make powerdevil normal executable instead of kded module
shumski added inline comments.
INLINE COMMENTS
> CMakeLists.txt:135
>
> -install(TARGETS kded_powerdevil DESTINATION ${PLUGIN_INSTALL_DIR}/kf5/kded)
> +install(TARGETS powerdevil DESTINATION ${CMAKE_INSTALL_FULL_LIBEXECDIR_KF5})
> +install(FILES ${CMAKE_CURRENT_BINARY_DIR}/powerdevil.desktop
PowerDevil isn't a Framework, so this var is wrong.
> powerdevil.desktop.cmake:1
> [Desktop Entry]
> Type=Service
Maybe autostart for this should be limited to Plasma only?
REPOSITORY
rPOWERDEVIL Powerdevil
REVISION DETAIL
https://phabricator.kde.org/D2372
EMAIL PREFERENCES
https://phabricator.kde.org/settings/panel/emailpreferences/
To: bshah, #plasma, broulik, graesslin
Cc: shumski, plasma-devel, lesliezhai, ali-mohamed, jensreuterberg, abetts,
sebas
[Differential] [Accepted] D2356: [shell] Add a dbus call to activate the "main" application launcher
mart accepted this revision.
mart added inline comments.
This revision is now accepted and ready to land.
INLINE COMMENTS
> shellcorona.cpp:1640
> +if (!applet->globalShortcut().isEmpty()) {
> +emit applet->activated();
> +return;
the way i can see it breaking is if an user has 2 menus with 2 different
shortcuts (extremely unlikely and weird, but i don't get surprised by anything
anymore)
it's fine for me, just to know the case exists
REPOSITORY
rPLASMAWORKSPACE Plasma Workspace
BRANCH
shell-dbus-launchermenu
REVISION DETAIL
https://phabricator.kde.org/D2356
EMAIL PREFERENCES
https://phabricator.kde.org/settings/panel/emailpreferences/
To: graesslin, #plasma, hein, mart
Cc: broulik, plasma-devel, lesliezhai, ali-mohamed, jensreuterberg, abetts,
sebas
[Differential] [Commented On] D2345: use a separate configuration per look and feel
mart added inline comments. INLINE COMMENTS > mart wrote in shellcorona.cpp:469 > plasmshell should have a slot for that invoked by the kcm? i could send the notifychange signal of kglobalsettings, but it's kinda ugly, as it uses an integer as parameter to specify what changed, which is defined in kdelibs4support I can add a new enum value, but it's still a dependency on kdelibs4support. This thing looks like it either needs a real replacement or other stuff (even file monitoring) should be used istead REPOSITORY rPLASMAWORKSPACE Plasma Workspace REVISION DETAIL https://phabricator.kde.org/D2345 EMAIL PREFERENCES https://phabricator.kde.org/settings/panel/emailpreferences/ To: mart, #plasma, davidedmundson Cc: davidedmundson, ivan, plasma-devel, lesliezhai, ali-mohamed, jensreuterberg, abetts, sebas
[Differential] [Commented On] D1989: Introduce QQuickItem to nest kwin_wayland
bdhruve added a comment. In https://phabricator.kde.org/D1989#44333, @graesslin wrote: > > - KeyPress events to send keys. > > > > However, keyevents are not working as it should, if i press 'a' it types something different. > > might be that this is just not possible to send key events like that. In general QKeyEvent delivers the keysym. That is the scan code translated through the keyboard layout. The nativeSccanCode should have the original value but I would not trust it completely. > > Maybe leave key events out for the moment as an we don't necessarily need key events. Ok, I will remove keyEvent stuff and add to-do item for that. Once that is done are there any issues in this code? REPOSITORY rKWIN KWin REVISION DETAIL https://phabricator.kde.org/D1989 EMAIL PREFERENCES https://phabricator.kde.org/settings/panel/emailpreferences/ To: bdhruve, bshah, graesslin, #plasma_on_wayland Cc: bshah, graesslin, plasma-devel, kwin, lesliezhai, ali-mohamed, hardening, jensreuterberg, abetts, sebas
Re: Selecting a Plasma logo
On Fri, Aug 5, 2016 at 3:40 PM, Andres Betts wrote: > Hey Sebas, > > Thanks for understanding. As I mentioned before my intention is not > necessarily that don't change my proposal but that we can create more > proposals to show variety. We cannot settle just on 2 orignal proposals and > then merge the two to see what comes out. I am pretty sure there many other > ways of giving Plasma an identity and I would love to see more. > > My thoughts are that we keep on getting proposals, we don't really have a > deadline and we can probably get many more people to come up with ideas. Art > contests are generally about original artwork. > > It is not about "my way or the highway" but rather, "my way or any other > highway." Because I am sure that there are more options than just two. > > Should we past this and not start an argument by requesting more logo > proposals? We need to move forward. > > > > On August 5, 2016 at 7:07:17 AM, Sebastian Kügler (se...@kde.org) wrote: >> >> Hi Andres, >> >> Sorry it took a few days to reply. >> >> On dinsdag 2 augustus 2016 07:45:10 CEST Andres Betts wrote: >> >> Let me explain the reasons about changing the logo and what stage this is >> at. In my personal view, after working for some time on coming up with a >> new logo proposal, we received a few comments and changes to it that, to >> me, had no backing. One idea was shared that others wanted my proposal to >> look closer, or have characteristics from the KDE logo. >> >> However, I am not of the preference of changing my proposal and adding >> more >> elements to it, because I thought about this long and hard and reduced the >> proposal to the simplest of forms that conveyed a meaning. Adding elements >> from the KDE logo, or the last Plasma logo doesn’t seem logical given that >> the last logo really had no meaning behind it, so there is not much that >> justifies its presence there. Some might argue that it is also about the >> public not recognizing the logo and what it belongs to. >> >> >> Well, that's not quite true. Especially the simplified arrow indicated >> "shell", >> something Plasma is all about. The three dots are elements for plugins, >> scripting and (I think) containments. So the elements *do* have a meaning. >> >> “Changes” or modifications that happen “after” the contest is over are all >> about simple edits. I consider my current logo to be in “beta” and only >> bugs and simple edits could be made. For example, the thickness of a >> border, or the sizes of the circles. I am not looking to strikingly change >> or modify the logo I created because I consider it to be near final. >> >> >> That's of course fine. My point was that if we pick a logo, and then >> change it >> afterwards, it's not the logo we picked. (I agree, simple edits are fine, >> but >> the comments weren't about simple edits, as far as understand.) >> >> However, if others want to make proposals that the Plasma team might like >> better, maybe it is a better thing to create original proposals and not >> change my proposal to be what you think should be there. If the Plasma >> team >> feels that my logo is not what they would like to have, then let’s not >> modify it and find an original alternative created by different artists. >> >> >> I disagree there. Plasma is a collaborative project, we do things >> together. My >> way of the highway is generally not the way we work, and I think it's >> quite >> natural to suggest changes, that is how we usually work. >> >> I think people may have been confused by you making the logo available >> under a >> license that allows changes, so we thought that it's OK to polish it some >> more. If it isn't, that's also fine, but it explains where this confusion >> comes >> from. >> >> Personally, I find it unfortunate that you do not want any changes to the >> logo. >> I can undestand it, but given its basic design is quite popular, I think >> it's >> a shame to ask people not to change it. I respect your choice, however, so >> I >> guess that's how it is. >> >> Cheers, >> -- >> sebas >> >> Sebastian Kügler • http://vizZzion.org • http://www.kde.org >> > Maybe it would be interesting to have an informal call between Plasma and you, to see why there's the feeling that something is missing in the original idea. Maybe it would be a better way for you to iterate your design in a direction you're more comfortable with? Aleix
Re: Discussion for libtaskmanager internals
See above - I agree it's nice to have for the optimal case, but the code is essentially written for simplicity and conservativeness (i.e. assume the optimal case won't be hit). I'm fine with someone doing additional engineering effort to optimize the optimal case, but since it will considerably complicate the code it needs to be reviewed very closely. Cheers, Eike Eike thank you very much for your comprehensive response... regards, Michail
[Differential] [Commented On] D2345: use a separate configuration per look and feel
davidedmundson added inline comments.
INLINE COMMENTS
> shellcorona.cpp:394
>
> //try to parse the items geometries
> KConfigGroup genericConf(&contConfig, QStringLiteral("General"));
I'm confused.
Should you be getting the current from the current Plasma::Applet* instances or
are you loading state from the config file?
REPOSITORY
rPLASMAWORKSPACE Plasma Workspace
REVISION DETAIL
https://phabricator.kde.org/D2345
EMAIL PREFERENCES
https://phabricator.kde.org/settings/panel/emailpreferences/
To: mart, #plasma, davidedmundson
Cc: davidedmundson, ivan, plasma-devel, lesliezhai, ali-mohamed,
jensreuterberg, abetts, sebas
[Differential] [Commented On] D2345: use a separate configuration per look and feel
mart added inline comments. INLINE COMMENTS > davidedmundson wrote in shellcorona.cpp:394 > I'm confused. > > Should you be getting the current from the current Plasma::Applet* instances > or are you loading state from the config file? I'm doing what i can there. every way to get items geometries is actually an hack, i think reading the config file is a bit more reliable, even if assumes how the config file is. otherwise it could get to the applet graphics object then map its geometry with containment graphics object geometry (however implementation detail, it would introduce an error as the geometry of the margins of the framesvg applet background wouldn't be included then) i can go for either of the approaches, none of them is perfect, but don't have strong preference there (while I do for the panel, as i think is the only way to ensure proper applets order) REPOSITORY rPLASMAWORKSPACE Plasma Workspace REVISION DETAIL https://phabricator.kde.org/D2345 EMAIL PREFERENCES https://phabricator.kde.org/settings/panel/emailpreferences/ To: mart, #plasma, davidedmundson Cc: davidedmundson, ivan, plasma-devel, lesliezhai, ali-mohamed, jensreuterberg, abetts, sebas
[Differential] [Requested Changes To] D2345: use a separate configuration per look and feel
davidedmundson requested changes to this revision.
davidedmundson added inline comments.
This revision now requires changes to proceed.
INLINE COMMENTS
> shellcorona.cpp:321
>
> QString dumpconfigGroupJS(const KConfigGroup &rootGroup, const QString
> &prefix)
> {
If we go with this patch
you should filter out ItemGeometries and AppletOrder here as you're making a
special case out of them.
Otherwise you're saving garbage data in the config which could conflict; one of
the new IDs could clash.
Also what's going to happen to activityId
> shellcorona.cpp:383
> int i = 0;
> foreach (DesktopView *view, m_desktopViewforId.values()) {
> Plasma::Containment *cont = view->containment();
No
you need to loop through containments() rather than the views
(same for panel section)
Otherwise:
- you're only saving the currently plugged in screens.
- this won't save the configuration for any applets in a system tray.
and when you do do the system tray you're going to have a huge problem:
system tray writes out SystrayContainmentId... you aren't going to know what
that is.
> mart wrote in shellcorona.cpp:394
> I'm doing what i can there.
> every way to get items geometries is actually an hack, i think reading the
> config file is a bit more reliable, even if assumes how the config file is.
> otherwise it could get to the applet graphics object then map its geometry
> with containment graphics object geometry (however implementation detail, it
> would introduce an error as the geometry of the margins of the framesvg
> applet background wouldn't be included then)
>
> i can go for either of the approaches, none of them is perfect, but don't
> have strong preference there (while I do for the panel, as i think is the
> only way to ensure proper applets order)
If every way is a hack, then maybe this feature shouldn't go in at all.
So the root issue is:
- for saving/restory applet geometry is handled by the containment which is in
completely arbitrary as it's done by that containment plugin.
- they use the ID of the applet for an index
- ID won't be the same
Brainstorming, there is an option.
*if* we assume dump and resume is always going to be from a clean setup we
could just expose setting initial id to applet scripting. It's already in
Plasma::Containment. it would fix all the problems without any hacks.
-
I can imagine this patch will destroy PMC if someone switched LNF twice as
you're hardcoding stuff in plasma-workspace based on behaviour of
plasma-desktop.
> shellcorona.cpp:467
> //enumerate config keys for containment
> KConfigGroup contConfig = cont->config();
> script += "//Panel containment configuration\n";
what about globalConfig()?
REPOSITORY
rPLASMAWORKSPACE Plasma Workspace
REVISION DETAIL
https://phabricator.kde.org/D2345
EMAIL PREFERENCES
https://phabricator.kde.org/settings/panel/emailpreferences/
To: mart, davidedmundson, #plasma
Cc: davidedmundson, ivan, plasma-devel, lesliezhai, ali-mohamed,
jensreuterberg, abetts, sebas
[Differential] [Request, 10 lines] D2374: [kded] fix monitoring for newly appearing outputs
sebas created this revision. sebas added a reviewer: Plasma. Restricted Application added a project: Plasma. Restricted Application added a subscriber: plasma-devel. REVISION SUMMARY This patch makes the kded daemon monitor also newly connected outputs, and leads to correctly initialize outputs from a docking station plugged in after session start. For "internal" display connector ports (HDMI, DisplayPort, etc. integrated in the system, we know from the start that they exist. These are marked disconnected. When plugging in a docking station, new outputs (that aren't previously known as disconnected) appear. daemon.cpp only monitors outputs that change connection state, so it doesn't consider newly added outputs. By listening to KScreen::Config::outputAdded, we can detect new output (connectors) as well, so we can trigger the applyConfig code path, which leads to restoring the config. BUG:366346 TEST PLAN - Reproduced the issue in https://bugs.kde.org/show_bug.cgi?id=366346 and confirmed it fixes the problem on my system (Lenovo Onelink+ docking station which shows the same behaviour). - Added debug calls and confirmed the new outputs are correctly set up. auto-testing this seems to be close to impossible. :/ REPOSITORY rKSCREEN KScreen BRANCH sebas/newdockoutputs REVISION DETAIL https://phabricator.kde.org/D2374 AFFECTED FILES kded/daemon.cpp EMAIL PREFERENCES https://phabricator.kde.org/settings/panel/emailpreferences/ To: sebas, #plasma Cc: plasma-devel, lesliezhai, ali-mohamed, jensreuterberg, abetts, sebas
[Powerdevil] [Bug 366402] Closing the lid triggers Sleep
https://bugs.kde.org/show_bug.cgi?id=366402 Weng Xuetian changed: What|Removed |Added CC||wen...@gmail.com --- Comment #5 from Weng Xuetian --- Just FYI: https://github.com/systemd/systemd/issues/3897 Looks like the commit mentioned above will be reverted. -- You are receiving this mail because: You are the assignee for the bug.
[Differential] [Updated, 10 lines] D2374: [kded] fix monitoring for newly appearing outputs
sebas updated this revision to Diff 5747. sebas added a comment. - use unique connection REPOSITORY rKSCREEN KScreen CHANGES SINCE LAST UPDATE https://phabricator.kde.org/D2374?vs=5746&id=5747 BRANCH sebas/newdockoutputs REVISION DETAIL https://phabricator.kde.org/D2374 AFFECTED FILES kded/daemon.cpp EMAIL PREFERENCES https://phabricator.kde.org/settings/panel/emailpreferences/ To: sebas, #plasma Cc: plasma-devel, lesliezhai, ali-mohamed, jensreuterberg, abetts, sebas
[Differential] [Updated, 82 lines] D2372: Make powerdevil normal executable instead of kded module
bshah updated this revision to Diff 5749. bshah marked 2 inline comments as done. bshah added a comment. - Don't install in kf5 libexec dir - Autostart powerdevil only in KDE - Make PowerDevilApp QGuiApplication instead of QObject REPOSITORY rPOWERDEVIL Powerdevil CHANGES SINCE LAST UPDATE https://phabricator.kde.org/D2372?vs=5741&id=5749 BRANCH powerdevil-executable (branched from master) REVISION DETAIL https://phabricator.kde.org/D2372 AFFECTED FILES daemon/CMakeLists.txt daemon/kdedpowerdevil.cpp daemon/kdedpowerdevil.h daemon/powerdevil.desktop daemon/powerdevil.desktop.cmake daemon/powerdevilapp.cpp daemon/powerdevilapp.h EMAIL PREFERENCES https://phabricator.kde.org/settings/panel/emailpreferences/ To: bshah, #plasma, broulik, graesslin Cc: shumski, plasma-devel, lesliezhai, ali-mohamed, jensreuterberg, abetts, sebas
Review Request 128633: Wether nor not install the private header?
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/128633/ --- Review request for Plasma and Sune Vuorela. Repository: prison Description --- Hi Sune, People might directly use Prison::QRCodeBarcode https://github.com/xiangzhai/qwx/blob/kf5/src/qrcodequick.cpp#L9 instead of via Prison::createBarcode so is it able to install the private header? Regards, Leslie Zhai Diffs - lib/CMakeLists.txt 95391cc Diff: https://git.reviewboard.kde.org/r/128633/diff/ Testing --- - prison/tests/test-prison - plasma-workspace/klipper - qwx/QRcodeQuick https://github.com/xiangzhai/qwx/blob/kf5/src/qrcodequick.h Thanks, Leslie Zhai
Re: Review Request 128633: Wether nor not install the private header?
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/128633/ --- (Updated 八月 9, 2016, 2:03 p.m.) Review request for Plasma and Sune Vuorela. Repository: prison Description --- Hi Sune, People might directly use Prison::QRCodeBarcode https://github.com/xiangzhai/qwx/blob/kf5/src/qrcodequick.cpp#L9 instead of via Prison::createBarcode so is it able to install the private header? Regards, Leslie Zhai Diffs - lib/CMakeLists.txt 95391cc Diff: https://git.reviewboard.kde.org/r/128633/diff/ Testing --- - prison/tests/test-prison - plasma-workspace/klipper - qwx/QRcodeQuick https://github.com/xiangzhai/qwx/blob/kf5/src/qrcodequick.h Thanks, Leslie Zhai
Re: Review Request 128633: Wether nor not install the private header?
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/128633/#review98213 --- I think it was a bug that the individual barcode headers was public in the qt4 based prison. Now that we are about to release a qt5 based prison, it is time to fix that bug. Basically, I don't want the interface to change depending on what supposed backends prison is compiled with. createBarcode can be queried, and the result tested for null pointers if a specific feature is not compiled in. At runtime. So things can be enabled/disabled as needed without requiring changes in other parts of the code. It is a very deliberate action to not install the headers any more. - Sune Vuorela On Aug. 9, 2016, 6:03 a.m., Leslie Zhai wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/128633/ > --- > > (Updated Aug. 9, 2016, 6:03 a.m.) > > > Review request for Plasma and Sune Vuorela. > > > Repository: prison > > > Description > --- > > Hi Sune, > > People might directly use Prison::QRCodeBarcode > https://github.com/xiangzhai/qwx/blob/kf5/src/qrcodequick.cpp#L9 instead of > via Prison::createBarcode > > so is it able to install the private header? > > Regards, > Leslie Zhai > > > Diffs > - > > lib/CMakeLists.txt 95391cc > > Diff: https://git.reviewboard.kde.org/r/128633/diff/ > > > Testing > --- > > - prison/tests/test-prison > - plasma-workspace/klipper > - qwx/QRcodeQuick https://github.com/xiangzhai/qwx/blob/kf5/src/qrcodequick.h > > > Thanks, > > Leslie Zhai > >
[Differential] [Planned Changes To] D2372: Make powerdevil normal executable instead of kded module
bshah planned changes to this revision. bshah added a comment. I just realized that this breaks the shortcuts, and I need to migrate older shortcuts over. REPOSITORY rPOWERDEVIL Powerdevil REVISION DETAIL https://phabricator.kde.org/D2372 EMAIL PREFERENCES https://phabricator.kde.org/settings/panel/emailpreferences/ To: bshah, #plasma, broulik, graesslin Cc: shumski, plasma-devel, lesliezhai, ali-mohamed, jensreuterberg, abetts, sebas
Re: Review Request 128633: Wether nor not install the private header?
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/128633/ --- (Updated Aug. 9, 2016, 6:49 a.m.) Status -- This change has been marked as submitted. Review request for Plasma and Sune Vuorela. Changes --- Submitted with commit 2b21133372c82374977878e4d55538c16df68e95 by Leslie Zhai to branch frameworks. Repository: prison Description --- Hi Sune, People might directly use Prison::QRCodeBarcode https://github.com/xiangzhai/qwx/blob/kf5/src/qrcodequick.cpp#L9 instead of via Prison::createBarcode so is it able to install the private header? Regards, Leslie Zhai Diffs - lib/CMakeLists.txt 95391cc Diff: https://git.reviewboard.kde.org/r/128633/diff/ Testing --- - prison/tests/test-prison - plasma-workspace/klipper - qwx/QRcodeQuick https://github.com/xiangzhai/qwx/blob/kf5/src/qrcodequick.h Thanks, Leslie Zhai
Re: Review Request 128633: Wether nor not install the private header?
> On 八月 9, 2016, 2:20 p.m., Sune Vuorela wrote: > > I think it was a bug that the individual barcode headers was public in the > > qt4 based prison. Now that we are about to release a qt5 based prison, it > > is time to fix that bug. > > > > Basically, I don't want the interface to change depending on what supposed > > backends prison is compiled with. > > > > createBarcode can be queried, and the result tested for null pointers if a > > specific feature is not compiled in. At runtime. So things can be > > enabled/disabled as needed without requiring changes in other parts of the > > code. > > > > It is a very deliberate action to not install the headers any more. agree ;-) https://github.com/xiangzhai/qwx/commit/acb0b78cc0885a7234dc1ea4f8284ef96df35ae2 - Leslie --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/128633/#review98213 --- On 八月 9, 2016, 2:49 p.m., Leslie Zhai wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/128633/ > --- > > (Updated 八月 9, 2016, 2:49 p.m.) > > > Review request for Plasma and Sune Vuorela. > > > Repository: prison > > > Description > --- > > Hi Sune, > > People might directly use Prison::QRCodeBarcode > https://github.com/xiangzhai/qwx/blob/kf5/src/qrcodequick.cpp#L9 instead of > via Prison::createBarcode > > so is it able to install the private header? > > Regards, > Leslie Zhai > > > Diffs > - > > lib/CMakeLists.txt 95391cc > > Diff: https://git.reviewboard.kde.org/r/128633/diff/ > > > Testing > --- > > - prison/tests/test-prison > - plasma-workspace/klipper > - qwx/QRcodeQuick https://github.com/xiangzhai/qwx/blob/kf5/src/qrcodequick.h > > > Thanks, > > Leslie Zhai > >
