Review Request 124702: Set component display name for all actions
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/124702/ --- Review request for Plasma and Martin Gräßlin. Repository: plasma-desktop Description --- Each action needs component display name to be set, otherwise it's always empty and the application display name is used as fallback (introduced in https://git.reviewboard.kde.org/r/124208). Using fallback leads to broken KCM for keyboard shortcuts (see https://git.reviewboard.kde.org/r/124208/#review83642). Diffs - kcms/keys/kglobalshortcutseditor.cpp 553b10d Diff: https://git.reviewboard.kde.org/r/124702/diff/ Testing --- Thanks, Jan Grulich ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 124702: Set component display name for all actions
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/124702/#review83718 --- Ship it! Ship It! - David Edmundson On Aug. 11, 2015, 8:56 p.m., Jan Grulich wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/124702/ --- (Updated Aug. 11, 2015, 8:56 p.m.) Review request for Plasma and Martin Gräßlin. Repository: plasma-desktop Description --- Each action needs component display name to be set, otherwise it's always empty and the application display name is used as fallback (introduced in https://git.reviewboard.kde.org/r/124208). Using fallback leads to broken KCM for keyboard shortcuts (see https://git.reviewboard.kde.org/r/124208/#review83642). Diffs - kcms/keys/kglobalshortcutseditor.cpp 553b10d Diff: https://git.reviewboard.kde.org/r/124702/diff/ Testing --- Thanks, Jan Grulich ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
phabricator setup for Plasma Mobile: task tracking
Hi all, Some news on the phabricator setup for Plasma Mobile. We want to use phabricator here to track tasks, designs and patch review. Task tracking Phabricator has so-called Workboards, these are kanban-style board which can contain tasks. The board has 4 columns, and tasks move from left to right during completion. I've set up the following lanes (which is in line with how we've been using Kanban board in Plasma for some time, it's a bit waterfalley, but I think with some added agility, these would work fine. The columns (or stages) are: - Todo: A task is open and not has already being worked on - Design: A feature has been designed, but not implemented yet - Implementation: An existing design is being implemented - Review: A feature has been developed, but is not fully integrated and shipped in the dev version - A feature is done and integrated in the development version of the reference OS image Of course, there's some overlap between especially the design and implementation stages, but I think it's a good way to get ourselves more into design-driven development. Especially the last stages mean that we do not just want some commits to have happened, but that we verify that a feature is available and functional in the reference image. (This last step is something we traditionally often forget, as the OS integration bit is usually in the hand of a Linux Distro team.) The stages may differ a bit for different workboard, see Plasma Docs board for example doesn't have a design stage, there it's todo, writing, review and done -- it makes more sense in this context. A specific task can belong to one or more projects. One such project is Plasma Mobile (rather generic). Then, there is a number of sub projects which can contain more detailed tasks. This two-level setup allows us to also get a complete picture of sub-tasks such as more complex design tasks (the HIG would be a good example here) or things as documentation (which also is something we need to handle in a more structured way). Tasks can have sub-tasks and blockers (tasks that need to be done before this one can be tackled). I haven't completely figured out which roles these would play, but I guess that's something we can find out once we're getting a bit more used to it. Therefore, it's good to reflect on the usage and that we all think about how we can use this tool more effectively. One idea that this feature may be very useful for is the scenario of a big task. In different stages, the task can change the project, so for example, in its design phase, it would belong to Plasma Mobile (PM) and Plasma Design, while in a later phase, it could belong to Plasma Mobile and a Plasma CI (I just made this up), so during the lifecycle of the task, it moves across multiple workboards, and becomes visible to different people. My first feeling is that tasks that are very detailed should probably be only in the subprojects, bigger tasks that are also meaningful in a general context should also be under the Plasma Mobile project, but as I said, we may want to refine that. For now, I've set up the following Plasma subprojects (which each have their own work board): Plasma Mobile - tracks general progress on the mobile UI and implementation https://phabricator.kde.org/project/board/28/ Plasma Docs - tracks progress and of documenting everything https://phabricator.kde.org/project/board/31/ Plasma Design - tracks design tasks https://phabricator.kde.org/project/board/32/ Plasma Mobile SDK - tracks tasks specific to the SDK https://phabricator.kde.org/project/board/30/ I've started adding features that we have discussed in the past weeks, please feel free to amend the workboard with items you may have on your list. I will look into the code review functionality next. Cheers, -- sebas http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9 ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 124695: Drop build option KWIN_BUILD_EGL
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/124695/#review83690 --- Ship it! Two notes: a) no idea how epoxy works, but it doesn't link any GL library itself here (it's an epoxy build time dependency, though) b) fglrx doesn't support EGL - though rather irrelevant since EGL from MESA will just be installed (as qt5-base dependency already) and not used, afaics there actually is a way to build a GLX system only. - Thomas Lübking On Aug. 11, 2015, 8:29 vorm., Martin Gräßlin wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/124695/ --- (Updated Aug. 11, 2015, 8:29 vorm.) Review request for kwin and Plasma. Repository: kwin Description --- It doesn't make much sense any more as we get EGL linked and included through epoxy anyway. Even more on Wayland it's just plain stupid to have EGL disabled. So removing the option just simplifies our code base without any disadvantages. Diffs - libkwineffects/kwinglutils.cpp 66634d6795d43020e9f323af9c24d8bfae9bf4aa libkwineffects/kwinconfig.h.cmake 3e34723aea5baf519c16f53afef3b21ab43efe7c dbusinterface.cpp 01079a1b2a97c83e4624deafb288349ea3952c7f backends/x11/x11windowed_backend.cpp 3ba9e5cd3932574daff2062a289dfd00745fa776 backends/wayland/CMakeLists.txt a1670a34b1f6519f6fb37bc041516bf3aec508e1 CMakeLists.txt 4d2aeed4f5ee9d0765e1b902ac51859e0ae1150b libkwineffects/kwinglutils_funcs.h eea28c5ae4225939a3d7fe72167fea4bfe028298 libkwineffects/kwinglutils_funcs.cpp 4e763b7bb1c4e156b52639dd357c92c5f28e9937 options.cpp 39efd9de53024fb7f11d042b7877a4583350b651 scene_opengl.cpp 85c0b104785ee2f06b1698d8e8020e0615fdab88 Diff: https://git.reviewboard.kde.org/r/124695/diff/ Testing --- Thanks, Martin Gräßlin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 124695: Drop build option KWIN_BUILD_EGL
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/124695/ --- (Updated Aug. 11, 2015, 9:16 a.m.) Status -- This change has been marked as submitted. Review request for kwin and Plasma. Changes --- Submitted with commit c24e315a9ba7eb6b1c975bfdb5b54f83c7023a62 by Martin Gräßlin to branch master. Repository: kwin Description --- It doesn't make much sense any more as we get EGL linked and included through epoxy anyway. Even more on Wayland it's just plain stupid to have EGL disabled. So removing the option just simplifies our code base without any disadvantages. Diffs - libkwineffects/kwinglutils.cpp 66634d6795d43020e9f323af9c24d8bfae9bf4aa libkwineffects/kwinconfig.h.cmake 3e34723aea5baf519c16f53afef3b21ab43efe7c dbusinterface.cpp 01079a1b2a97c83e4624deafb288349ea3952c7f backends/x11/x11windowed_backend.cpp 3ba9e5cd3932574daff2062a289dfd00745fa776 backends/wayland/CMakeLists.txt a1670a34b1f6519f6fb37bc041516bf3aec508e1 CMakeLists.txt 4d2aeed4f5ee9d0765e1b902ac51859e0ae1150b libkwineffects/kwinglutils_funcs.h eea28c5ae4225939a3d7fe72167fea4bfe028298 libkwineffects/kwinglutils_funcs.cpp 4e763b7bb1c4e156b52639dd357c92c5f28e9937 options.cpp 39efd9de53024fb7f11d042b7877a4583350b651 scene_opengl.cpp 85c0b104785ee2f06b1698d8e8020e0615fdab88 Diff: https://git.reviewboard.kde.org/r/124695/diff/ Testing --- Thanks, Martin Gräßlin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 124692: Add new entities for sebas and plasma-pa
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/124692/#review83686 --- Ship it! Please ensure with David Faure that this can stlk go into 5.13, and also that Plasma 5.4 depends on 5.13. Otherwise people won't be able to generate the doc. Temporary workaround: don't use the entities in plasma-pa until Plasma 5.5. - Luigi Toscano On Ago. 11, 2015, 2:45 a.m., Sebastian Kügler wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/124692/ --- (Updated Ago. 11, 2015, 2:45 a.m.) Review request for Plasma and Luigi Toscano. Repository: kdoctools Description --- Add an entity fo me (sebas) and for plasma-pa. Diffs - src/customization/en/user.entities 6eaf9dc56af1e81bc6e2ee9b1f03e4100dfbae24 src/customization/entities/contributor.entities 3fafc4ad3a7903b00abee9468c691f36e19313fa Diff: https://git.reviewboard.kde.org/r/124692/diff/ Testing --- builds and is able to build my plasma-pa docbook. Thanks, Sebastian Kügler ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Review Request 124694: Drop build option KWIN_PLASMA_ACTIVE
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/124694/ --- Review request for kwin and Plasma. Repository: kwin Description --- The build option wasn't used for 5.x at all and in this way doesn't make any sense nowadays. We want to have a converged desktop which also means that the window manager should be able to switch to a different form factor with a full feature set (plug in external screen to smartphone and it should be full desktop). A trimmed down KWin with compiled out functionality cannot do that. Also the need for trimmed down KWin becomes less and less important given the improved hardware we target nowadays. This change got triggered by the announcement to close down the Plasma Active mailinglist [1], which shows that having a build option called Plasma Active is no longer needed. [1] http://permalink.gmane.org/gmane.comp.kde.devel.active/4343 Diffs - CMakeLists.txt 4d2aeed4f5ee9d0765e1b902ac51859e0ae1150b Diff: https://git.reviewboard.kde.org/r/124694/diff/ Testing --- Thanks, Martin Gräßlin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Review Request 124695: Drop build option KWIN_BUILD_EGL
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/124695/ --- Review request for kwin and Plasma. Repository: kwin Description --- It doesn't make much sense any more as we get EGL linked and included through epoxy anyway. Even more on Wayland it's just plain stupid to have EGL disabled. So removing the option just simplifies our code base without any disadvantages. Diffs - libkwineffects/kwinglutils.cpp 66634d6795d43020e9f323af9c24d8bfae9bf4aa libkwineffects/kwinconfig.h.cmake 3e34723aea5baf519c16f53afef3b21ab43efe7c dbusinterface.cpp 01079a1b2a97c83e4624deafb288349ea3952c7f backends/x11/x11windowed_backend.cpp 3ba9e5cd3932574daff2062a289dfd00745fa776 backends/wayland/CMakeLists.txt a1670a34b1f6519f6fb37bc041516bf3aec508e1 CMakeLists.txt 4d2aeed4f5ee9d0765e1b902ac51859e0ae1150b libkwineffects/kwinglutils_funcs.h eea28c5ae4225939a3d7fe72167fea4bfe028298 libkwineffects/kwinglutils_funcs.cpp 4e763b7bb1c4e156b52639dd357c92c5f28e9937 options.cpp 39efd9de53024fb7f11d042b7877a4583350b651 scene_opengl.cpp 85c0b104785ee2f06b1698d8e8020e0615fdab88 Diff: https://git.reviewboard.kde.org/r/124695/diff/ Testing --- Thanks, Martin Gräßlin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 124695: Drop build option KWIN_BUILD_EGL
On Aug. 11, 2015, 9:10 vorm., Thomas Lübking wrote: Two notes: a) no idea how epoxy works, but it doesn't link any GL library itself here (it's an epoxy build time dependency, though) b) fglrx doesn't support EGL - though rather irrelevant since EGL from MESA will just be installed (as qt5-base dependency already) and not used, afaics there actually is a way to build a GLX system only. Martin Gräßlin wrote: concerning a: yes that's just a miswording from my side. What I wanted to express is that we don't link it explicitly any more since the switch to epoxy concerning b: is that still the case? I would have assumed that with the new driver architecture they also got EGL working? it may be in the pipe, but 15.5 (latest on AUR, but flagged outdated 3 weeks ago) still just symlinks the MESA libraries - and so far google says no to me. *shrug* - Thomas --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/124695/#review83690 --- On Aug. 11, 2015, 9:16 vorm., Martin Gräßlin wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/124695/ --- (Updated Aug. 11, 2015, 9:16 vorm.) Review request for kwin and Plasma. Repository: kwin Description --- It doesn't make much sense any more as we get EGL linked and included through epoxy anyway. Even more on Wayland it's just plain stupid to have EGL disabled. So removing the option just simplifies our code base without any disadvantages. Diffs - libkwineffects/kwinglutils.cpp 66634d6795d43020e9f323af9c24d8bfae9bf4aa libkwineffects/kwinconfig.h.cmake 3e34723aea5baf519c16f53afef3b21ab43efe7c dbusinterface.cpp 01079a1b2a97c83e4624deafb288349ea3952c7f backends/x11/x11windowed_backend.cpp 3ba9e5cd3932574daff2062a289dfd00745fa776 backends/wayland/CMakeLists.txt a1670a34b1f6519f6fb37bc041516bf3aec508e1 CMakeLists.txt 4d2aeed4f5ee9d0765e1b902ac51859e0ae1150b libkwineffects/kwinglutils_funcs.h eea28c5ae4225939a3d7fe72167fea4bfe028298 libkwineffects/kwinglutils_funcs.cpp 4e763b7bb1c4e156b52639dd357c92c5f28e9937 options.cpp 39efd9de53024fb7f11d042b7877a4583350b651 scene_opengl.cpp 85c0b104785ee2f06b1698d8e8020e0615fdab88 Diff: https://git.reviewboard.kde.org/r/124695/diff/ Testing --- Thanks, Martin Gräßlin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 124694: Drop build option KWIN_PLASMA_ACTIVE
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/124694/#review83692 --- Ship it! and, most important, you can still turn off the parts by hand (if you've special usecases for kwin outside plasma, ie. lxqt etc.) - Thomas Lübking On Aug. 11, 2015, 6:52 vorm., Martin Gräßlin wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/124694/ --- (Updated Aug. 11, 2015, 6:52 vorm.) Review request for kwin and Plasma. Repository: kwin Description --- The build option wasn't used for 5.x at all and in this way doesn't make any sense nowadays. We want to have a converged desktop which also means that the window manager should be able to switch to a different form factor with a full feature set (plug in external screen to smartphone and it should be full desktop). A trimmed down KWin with compiled out functionality cannot do that. Also the need for trimmed down KWin becomes less and less important given the improved hardware we target nowadays. This change got triggered by the announcement to close down the Plasma Active mailinglist [1], which shows that having a build option called Plasma Active is no longer needed. [1] http://permalink.gmane.org/gmane.comp.kde.devel.active/4343 Diffs - CMakeLists.txt 4d2aeed4f5ee9d0765e1b902ac51859e0ae1150b Diff: https://git.reviewboard.kde.org/r/124694/diff/ Testing --- Thanks, Martin Gräßlin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 124695: Drop build option KWIN_BUILD_EGL
On Aug. 11, 2015, 11:10 a.m., Thomas Lübking wrote: Two notes: a) no idea how epoxy works, but it doesn't link any GL library itself here (it's an epoxy build time dependency, though) b) fglrx doesn't support EGL - though rather irrelevant since EGL from MESA will just be installed (as qt5-base dependency already) and not used, afaics there actually is a way to build a GLX system only. concerning a: yes that's just a miswording from my side. What I wanted to express is that we don't link it explicitly any more since the switch to epoxy concerning b: is that still the case? I would have assumed that with the new driver architecture they also got EGL working? - Martin --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/124695/#review83690 --- On Aug. 11, 2015, 10:29 a.m., Martin Gräßlin wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/124695/ --- (Updated Aug. 11, 2015, 10:29 a.m.) Review request for kwin and Plasma. Repository: kwin Description --- It doesn't make much sense any more as we get EGL linked and included through epoxy anyway. Even more on Wayland it's just plain stupid to have EGL disabled. So removing the option just simplifies our code base without any disadvantages. Diffs - libkwineffects/kwinglutils.cpp 66634d6795d43020e9f323af9c24d8bfae9bf4aa libkwineffects/kwinconfig.h.cmake 3e34723aea5baf519c16f53afef3b21ab43efe7c dbusinterface.cpp 01079a1b2a97c83e4624deafb288349ea3952c7f backends/x11/x11windowed_backend.cpp 3ba9e5cd3932574daff2062a289dfd00745fa776 backends/wayland/CMakeLists.txt a1670a34b1f6519f6fb37bc041516bf3aec508e1 CMakeLists.txt 4d2aeed4f5ee9d0765e1b902ac51859e0ae1150b libkwineffects/kwinglutils_funcs.h eea28c5ae4225939a3d7fe72167fea4bfe028298 libkwineffects/kwinglutils_funcs.cpp 4e763b7bb1c4e156b52639dd357c92c5f28e9937 options.cpp 39efd9de53024fb7f11d042b7877a4583350b651 scene_opengl.cpp 85c0b104785ee2f06b1698d8e8020e0615fdab88 Diff: https://git.reviewboard.kde.org/r/124695/diff/ Testing --- Thanks, Martin Gräßlin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Plasma 5.4 beta out now
9 days until final tag https://www.kde.org/announcements/plasma-5.3.95.php Jonathan ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Plasma Mobile Vision, intended personas meeting notes
Also, don't confuse the vision statement with a marketing product vision. The vision statement is mainly inward-facing, so we can look at it and measure our deeds against it, not so much outward-facing. For marketing and communication, we'd likely reword these things slightly, either for cover-your-ass reasons, or to make it more eloquent, interesting or catchy. Sold! I am all for it, as long as we don't use it for marketing purposes. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Plasma Mobile Vision, intended personas meeting notes
On Tuesday, August 11, 2015 01:09:15 Michael Bohlender wrote: Great work guys! I love the part about privacy and I can identify with the rest of the vision. Cool, thanks for reading it critically and for the feedback. Some minor things: It provides a seamless experience across multiple devices. I guess your primarily mean devices running other Plasma Experiences (Desktop / PMC / whatever the future brings) Or do you want to explicitly include more? No, but we also don't have to. We can try to be perfect and exact in the wording, but then the text would be three times as long, bringing it to a length that nobody on the Internet reads. I think it's clear, if you think about it, that this integration also depends on other devices, so that the integration is not a given. Also, don't confuse the vision statement with a marketing product vision. The vision statement is mainly inward-facing, so we can look at it and measure our deeds against it, not so much outward-facing. For marketing and communication, we'd likely reword these things slightly, either for cover-your-ass reasons, or to make it more eloquent, interesting or catchy. Also the wording is not perfect. It sound like plasma mobile will be on multiple devices that provide a seamless experience when used together. That's what we wanted to express, though. :-) Think what we can bring t the table with kdeconnect, for example... Plasma Mobile implements open standards, and -- unlike Android -- it is developed in a transparent process that is open for the community to participate in. I am undecided on the unlike Android part. Could you share your reasoning for including it? We decided to include it since it's important to set us apart. We've used the template that Andres and Thomas presented during Akademy, and went from there. I understand the reservations to name a competitor, but then, this is exactly what people will ask and what we should make very straightforward to understand. In a TV ad, I'd probably refrain from naming Android as competitor, in a vision statement, it helps to understand the independence and privacy awareness that we're trying to communicate. -- 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: Plasma Mobile Vision, intended personas meeting notes
Ten thumbs up! (just need 4 more people to get to ten thumbs) So exciting, Andrew On Mon, Aug 10, 2015, 1:01 PM Jens Reuterberg wrote: PRESENT: Ivan, Sebas, Thomas and Jens MEETING GOAL: write up a vision statement for Plasma Mobile and talk about the early work of the Plasma Mobile HIG and design goals. The vision we ended with, after much debate of different wordings, what should and shouldn't be included in a vision statement was VISION STATEMENT: Plasma Mobile aims to become a complete software system for mobile devices. It is designed to give privacy-aware users back the full-control over their information and communication. Plasma Mobile takes a pragmatic approach and is inclusive to 3rd party software, allowing the user to choose which applications and services to use. It provides a seamless experience across multiple devices. Plasma Mobile implements open standards, and -- unlike Android -- it is developed in a transparent process that is open for the community to participate in. NOTES ON VISION STATEMENT: We wanted the vision statement to reflect not the projects current position but our future goals in full. A system for actual users with a focus on privacy, control of information and your own system and working in the open as a community using open source. We also included information about our pragmatism and how the phone intends to be easily adaptable to different apps from other eco-systems and also our intent to make it a pairing with desktops. PERSONAS: We also talked about future Personas that we want to work towards when creating user stories and scenarios and settled fairly quickly on Berna (the office worker) and Susan (the recreational user). (1) DESIGN NOTES: Further notes of interest during the meeting where a few bullet points concerning future design goals for individual apps which will reach the HIG in the end 1) All applications should be private by default - no sending data in the default configuration, must not phone home 2) Applications should try to include security and control of info. Should be apparent not hidden. This is not an excuse for geeky design. 3) Applications should always aim for integration between devices, for example using kdeconnect FUTURE COMMUNICATION: We also brainstormed on communication taglines for the project that will be narrowed down further as time goes by (and should probably be a case for the KDE Promo team) - centering mostly on user self control over his or her information and communication but also communication ideas concerning pragmatism. Pragmatic to the bone Think Similar This is your phone, no one elses Plasma's Satellite Your phone. Your stuff. Your Plasma Mobile. Plasma Mobile. Yours. Yours For your eyes only. Yours truly. All in all a very productive meeting. - 1) https://techbase.kde.org/Projects/Usability/Principles/KDE4_Personas ___ 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: [kubuntu-devel] Re: git moves
On Tue, Aug 11, 2015 at 01:18:20PM +0200, Valentin Rusu wrote: * Jonathan Riddell j...@jriddell.org [2015-08-05 18:11:56 +0200]: some changes to pkg-kde git today: I added kwallet-pam to plasma Why not include the kwallet-pam module in the kwallet framework? The src/runtime would be the perfect place for that module and users would have all the required pieces together. If nobody is against this merging - and to be sure I copy kde-frameworks-devel - then it's a matter of importing the kwallet-map repo into a directory under kwallet/src/runtime. I could help with that. This is a change in Plasma release tars (rather than Kubuntu packaging) and it was added there because Martin K said it was ported and should be released, and I think his motivation was just that enough people bugged him that he made Alex's work compile. But nobody is around who especially wants to maintain it so if you want to move it into wallet framework that would be very welcome. Jonathan ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 124692: Add new entities for sebas and plasma-pa
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/124692/ --- (Updated Aug. 11, 2015, 10:51 a.m.) Status -- This change has been marked as submitted. Review request for Plasma and Luigi Toscano. Changes --- Submitted with commit 149bd4cbc8de5a2646daf06a2234f323edd26ed9 by Sebastian Kügler to branch master. Repository: kdoctools Description --- Add an entity fo me (sebas) and for plasma-pa. Diffs - src/customization/en/user.entities 6eaf9dc56af1e81bc6e2ee9b1f03e4100dfbae24 src/customization/entities/contributor.entities 3fafc4ad3a7903b00abee9468c691f36e19313fa Diff: https://git.reviewboard.kde.org/r/124692/diff/ Testing --- builds and is able to build my plasma-pa docbook. Thanks, Sebastian Kügler ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 124625: Filter out non-desktop formfactors in Kickoff's application model
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/124625/#review83698 --- Ship it! Ship It! - Kai Uwe Broulik On Aug. 5, 2015, 9 nachm., Sebastian Kügler wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/124625/ --- (Updated Aug. 5, 2015, 9 nachm.) Review request for Plasma. Repository: plasma-desktop Description --- Filter out non-desktop formfactors in Kickoff's application model Diffs - applets/kickoff/core/applicationmodel.cpp 95f5712 Diff: https://git.reviewboard.kde.org/r/124625/diff/ Testing --- Made sure a an app with X-KDE-FormFactors=handset,tablet doesn't show up, made sure others do show up Thanks, Sebastian Kügler ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 124625: Filter out non-desktop formfactors in Kickoff's application model
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/124625/ --- (Updated Aug. 11, 2015, 11:17 a.m.) Status -- This change has been marked as submitted. Review request for Plasma. Changes --- Submitted with commit e10923384b21fe0976338d0b784beeeac84bc63f by Sebastian Kügler to branch master. Repository: plasma-desktop Description --- Filter out non-desktop formfactors in Kickoff's application model Diffs - applets/kickoff/core/applicationmodel.cpp 95f5712 Diff: https://git.reviewboard.kde.org/r/124625/diff/ Testing --- Made sure a an app with X-KDE-FormFactors=handset,tablet doesn't show up, made sure others do show up Thanks, Sebastian Kügler ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 124633: Parse formfactor in KService and KPluginInfo
On Aug. 6, 2015, 7:13 a.m., David Faure wrote: If the goal is to query this property for the K menu for instance, aren't you missing an accessor in KService? OK, on the other hand, if this is the only user, then property(...) would do too, but still, compile-time checking is more robust. About ksycocathreadtest: I just pushed many fixes for it, does it pass for you now? Sebastian Kügler wrote: My primary concern was to make sure FormFactors is not lost in conversion. Adding API in KPluginInfo was more a side-effect of this (for symmetry reasons with surrounding code). I don't care so much for an accessor also in KService. The ksycocathreadtest now succeeds, thanks. OK to commit this? - Sebastian --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/124633/#review83476 --- On Aug. 5, 2015, 10:41 p.m., Sebastian Kügler wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/124633/ --- (Updated Aug. 5, 2015, 10:41 p.m.) Review request for KDE Frameworks, Plasma, Alex Richardson, and David Faure. Repository: kservice Description --- Parse formfactor in KService and KPluginInfo Add an accessor QStringList KPluginInfo::formFactors() This corresponds to the X-KDE-FormFactors value in the .desktop file, and to the FormFactors value in the KPlugin block of the json metadata. We already have this in KPluginMetaData, this patch brings KPluginInfo and KService in line with that. Previously, the keys would not be recognized, and thus be missing from the KPluginMetaData if created through a KPluginInfo or a KService. This patch fixes this inconsistent behaviour. Also bump the sycoca version. Diffs - autotests/fakeplugin.desktop 200f023 autotests/fakeplugin.json de4aed9 autotests/kplugininfotest.cpp d99b92a autotests/kservicetest.h 380cf7b autotests/kservicetest.cpp 2c71331 src/services/kplugininfo.h 7b98576 src/services/kplugininfo.cpp 56dc0b4 src/services/kservice.cpp 3639a28 src/services/kservice_p.h bf59f38 src/sycoca/ksycoca.cpp 32d1689 Diff: https://git.reviewboard.kde.org/r/124633/diff/ Testing --- Added new tests, no problems. ksycocathreadtest currently fails, but this is unrelated (also in master without this patch). Thanks, Sebastian Kügler ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 124625: Filter out non-desktop formfactors in Kickoff's application model
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/124625/#review83696 --- If there are no more issues, I'd like to ship this. - Sebastian Kügler On Aug. 5, 2015, 9 p.m., Sebastian Kügler wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/124625/ --- (Updated Aug. 5, 2015, 9 p.m.) Review request for Plasma. Repository: plasma-desktop Description --- Filter out non-desktop formfactors in Kickoff's application model Diffs - applets/kickoff/core/applicationmodel.cpp 95f5712 Diff: https://git.reviewboard.kde.org/r/124625/diff/ Testing --- Made sure a an app with X-KDE-FormFactors=handset,tablet doesn't show up, made sure others do show up Thanks, Sebastian Kügler ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Review Request 124697: Make Wayland a hard build time dependency
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/124697/ --- Review request for kwin and Plasma. Repository: kwin Description --- As discussed on release-team ml [1] the following dependencies are mandatory: * KF5Wayland * Wayland::Cursor * Wayland::Egl * xkbcommon [1] https://mail.kde.org/pipermail/release-team/2015-July/008725.html Drop cmakedefine HAVE_XKB No longer needed, we always depend on xkbcommon now. Drop cmakedefine HAVE_WAYLAND_CURSOR Now a required build-dep. Drop cmakedefine HAVE_WAYLAND Now a required build dependency. Drop cmakedefine HAVE_WAYLAND_EGL Now a required build dependency. Make X11_XCB a build dependency of X11 windowed backend Let's rather not build the plugin if we don't have the dependency then building it without OpenGL support. Simplifies the code a bit and makes the backend overall more useful and goes along with e.g. the Wayland one which has EGL also as a hard dependency for the plugin. Diffs - CMakeLists.txt 056801feaa40b8bc24e56b5d132a3e02e66b6782 abstract_backend.cpp 28564e3e03a68f78c58d351b0a2eb1f66a088879 abstract_client.cpp 45976224394a8a467836bbe72596057446c95051 abstract_egl_backend.h c266521d3a870b4bd110435fa6c5f8e5d4e72e33 abstract_egl_backend.cpp 5ef3adaa7216c314b56c594167805da232f6a499 backends/CMakeLists.txt 809ac64edbce6df001c22395a9a991d324008d92 backends/wayland/CMakeLists.txt 7f643df2e13bc40172ea3ed5140b9aea5563b0b6 backends/wayland/wayland_backend.cpp 57a805eafa470e1fb06cd318bf557c0cd5c2e38c backends/x11/CMakeLists.txt 9ce72fad1a7800f7e9b0c085a363f8eb256b7d24 backends/x11/x11windowed_backend.cpp 95a5b70ecfa32358af934950f2c723cd9b8a03af composite.cpp 1db4790b50d99401c175e90852f5e4958f53fc8c config-kwin.h.cmake 6128c0ccae23453e2f5cf2918dee0d733aaec4d9 effects.cpp 81c6ede571f6f995eee62e999633bcbc07599914 events.cpp 3ce3f917c9a7854613244dd36cf0dc27e908d559 geometry.cpp f63e85165b9e6c605e5ed740bb61f1ec02acecc7 input.h c9ef924737b542b9d844fcb8e5b4989e02bf812d input.cpp 3e464486aa56a7edaa36371747b6c158a03c96c2 layers.cpp d8328ccafd89706eb463f5dd120b82b7288c86bb scene.h 9e412da1d0a9c54adf9d3f412aeb1eece0b3 scene.cpp 09b7ec4a3d5a0af3b976657f9b035a5bfecdc8f3 scene_opengl.cpp 3e9b849ea7e6884386944188d9d6f4d38d74090f scene_qpainter.cpp e6829138f00f4529bf13b3733f34b0e694056e9a screens.cpp 226a2eca05d386b7f8b778b21019dc2d976c1197 scripting/scripting_model.cpp 8b595f7c2ba3132bb574c48bae6d4823d9bc0366 shadow.cpp 56bc97f91c204ec14d8eb8dc6ac5a4ac253e3436 thumbnailitem.cpp 8b984558720ea974afb91aa55269ae514b44479f toplevel.h eb46eb4f7571fbde8034308903cd730af2b17854 toplevel.cpp 4740c8f873439dd6ce08d99de7ee8028ec52ebfe workspace.cpp 9568b83b04112c28cd99ec60d472d5944a9d7f1b Diff: https://git.reviewboard.kde.org/r/124697/diff/ Testing --- Thanks, Martin Gräßlin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 124633: Parse formfactor in KService and KPluginInfo
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/124633/#review83697 --- Ship it! - David Faure On Aug. 5, 2015, 10:41 p.m., Sebastian Kügler wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/124633/ --- (Updated Aug. 5, 2015, 10:41 p.m.) Review request for KDE Frameworks, Plasma, Alex Richardson, and David Faure. Repository: kservice Description --- Parse formfactor in KService and KPluginInfo Add an accessor QStringList KPluginInfo::formFactors() This corresponds to the X-KDE-FormFactors value in the .desktop file, and to the FormFactors value in the KPlugin block of the json metadata. We already have this in KPluginMetaData, this patch brings KPluginInfo and KService in line with that. Previously, the keys would not be recognized, and thus be missing from the KPluginMetaData if created through a KPluginInfo or a KService. This patch fixes this inconsistent behaviour. Also bump the sycoca version. Diffs - autotests/fakeplugin.desktop 200f023 autotests/fakeplugin.json de4aed9 autotests/kplugininfotest.cpp d99b92a autotests/kservicetest.h 380cf7b autotests/kservicetest.cpp 2c71331 src/services/kplugininfo.h 7b98576 src/services/kplugininfo.cpp 56dc0b4 src/services/kservice.cpp 3639a28 src/services/kservice_p.h bf59f38 src/sycoca/ksycoca.cpp 32d1689 Diff: https://git.reviewboard.kde.org/r/124633/diff/ Testing --- Added new tests, no problems. ksycocathreadtest currently fails, but this is unrelated (also in master without this patch). Thanks, Sebastian Kügler ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 124694: Drop build option KWIN_PLASMA_ACTIVE
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/124694/ --- (Updated Aug. 11, 2015, 11:22 a.m.) Status -- This change has been marked as submitted. Review request for kwin and Plasma. Changes --- Submitted with commit 2635243650f88322e5bfd124859cdc622c619fc0 by Martin Gräßlin to branch master. Repository: kwin Description --- The build option wasn't used for 5.x at all and in this way doesn't make any sense nowadays. We want to have a converged desktop which also means that the window manager should be able to switch to a different form factor with a full feature set (plug in external screen to smartphone and it should be full desktop). A trimmed down KWin with compiled out functionality cannot do that. Also the need for trimmed down KWin becomes less and less important given the improved hardware we target nowadays. This change got triggered by the announcement to close down the Plasma Active mailinglist [1], which shows that having a build option called Plasma Active is no longer needed. [1] http://permalink.gmane.org/gmane.comp.kde.devel.active/4343 Diffs - CMakeLists.txt 4d2aeed4f5ee9d0765e1b902ac51859e0ae1150b Diff: https://git.reviewboard.kde.org/r/124694/diff/ Testing --- Thanks, Martin Gräßlin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 124694: Drop build option KWIN_PLASMA_ACTIVE
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/124694/#review83700 --- Ship it! Ship It! - Sebastian Kügler On Aug. 11, 2015, 6:52 a.m., Martin Gräßlin wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/124694/ --- (Updated Aug. 11, 2015, 6:52 a.m.) Review request for kwin and Plasma. Repository: kwin Description --- The build option wasn't used for 5.x at all and in this way doesn't make any sense nowadays. We want to have a converged desktop which also means that the window manager should be able to switch to a different form factor with a full feature set (plug in external screen to smartphone and it should be full desktop). A trimmed down KWin with compiled out functionality cannot do that. Also the need for trimmed down KWin becomes less and less important given the improved hardware we target nowadays. This change got triggered by the announcement to close down the Plasma Active mailinglist [1], which shows that having a build option called Plasma Active is no longer needed. [1] http://permalink.gmane.org/gmane.comp.kde.devel.active/4343 Diffs - CMakeLists.txt 4d2aeed4f5ee9d0765e1b902ac51859e0ae1150b Diff: https://git.reviewboard.kde.org/r/124694/diff/ Testing --- Thanks, Martin Gräßlin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 124633: Parse formfactor in KService and KPluginInfo
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/124633/ --- (Updated Aug. 11, 2015, 11:05 a.m.) Status -- This change has been marked as submitted. Review request for KDE Frameworks, Plasma, Alex Richardson, and David Faure. Changes --- Submitted with commit 6d82a824b3a7e5e87b4691439ecba064a75fa8a1 by Sebastian Kügler to branch master. Repository: kservice Description --- Parse formfactor in KService and KPluginInfo Add an accessor QStringList KPluginInfo::formFactors() This corresponds to the X-KDE-FormFactors value in the .desktop file, and to the FormFactors value in the KPlugin block of the json metadata. We already have this in KPluginMetaData, this patch brings KPluginInfo and KService in line with that. Previously, the keys would not be recognized, and thus be missing from the KPluginMetaData if created through a KPluginInfo or a KService. This patch fixes this inconsistent behaviour. Also bump the sycoca version. Diffs - autotests/fakeplugin.desktop 200f023 autotests/fakeplugin.json de4aed9 autotests/kplugininfotest.cpp d99b92a autotests/kservicetest.h 380cf7b autotests/kservicetest.cpp 2c71331 src/services/kplugininfo.h 7b98576 src/services/kplugininfo.cpp 56dc0b4 src/services/kservice.cpp 3639a28 src/services/kservice_p.h bf59f38 src/sycoca/ksycoca.cpp 32d1689 Diff: https://git.reviewboard.kde.org/r/124633/diff/ Testing --- Added new tests, no problems. ksycocathreadtest currently fails, but this is unrelated (also in master without this patch). Thanks, Sebastian Kügler ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 124469: ConsoleKit2 support for screenlocker
On Aug. 10, 2015, 2:12 p.m., David Edmundson wrote:
Ship It!
Thanks for the review. I don't have push rights, would you mind doing that for
me? Thanks!
- Eric
---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/124469/#review83659
---
On Aug. 10, 2015, 1:59 p.m., Eric Koegel wrote:
---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/124469/
---
(Updated Aug. 10, 2015, 1:59 p.m.)
Review request for Plasma.
Repository: plasma-workspace
Description
---
ConsoleKit2 has the same API as systemd-logind for Lock, Unlock,
PrepareForSleep, and Inhibit. This patch adds the functionality
for ConsoleKit2 while attempting to minimize code duplication.
Diffs
-
ksmserver/screenlocker/logind.h 9983673
ksmserver/screenlocker/logind.cpp 5335b15
Diff: https://git.reviewboard.kde.org/r/124469/diff/
Testing
---
dbus-send --system --dest=org.freedesktop.ConsoleKit --type=method_call
--print-reply --reply-timeout=2000 /org/freedesktop/ConsoleKit/Manager
org.freedesktop.ConsoleKit.Manager.ListInhibitors
method return sender=:1.1 - dest=:1.80 reply_serial=2
array [
struct {
string suspend
string NetworkManager
string NetworkManager needs to turn off networks
string delay
uint32 0
uint32 3473
}
struct {
string
handle-power-key:handle-suspend-key:handle-hibernate-key:handle-lid-switch
string PowerDevil
string KDE handles power events
string block
uint32 1000
uint32 9587
}
struct {
string suspend
string Screen Locker
string Ensuring that the screen gets locked before going to sleep
string delay
uint32 1000
uint32 9508
}
]
Verified ConsoleKit2 does delay suspending until both delay locks are removed.
Thanks,
Eric Koegel
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 124697: Make Wayland a hard build time dependency
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/124697/#review83711 --- Generally fine with the change, but some present oddities were exposed by it. abstract_client.cpp (line 517) https://git.reviewboard.kde.org/r/124697/#comment57931 Why are these functions in AbstractClient itfp.? Looks like shell-client-only feature. abstract_egl_backend.h (line 94) https://git.reviewboard.kde.org/r/124697/#comment57932 same here? (also applies to all inner special code - why abstracts if they contain specific code already) abstract_egl_backend.cpp (line 59) https://git.reviewboard.kde.org/r/124697/#comment57933 eg. cleanup should likely (? doesn't sound that performance critical) be virtual and EglWaylandBackend calls the wayland specific code and then AbstractEglBackend::cleanup() I'm sure there's a reason for this, but it looks a bit like bad design and hacked in :-\ - Thomas Lübking On Aug. 11, 2015, 12:01 nachm., Martin Gräßlin wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/124697/ --- (Updated Aug. 11, 2015, 12:01 nachm.) Review request for kwin and Plasma. Repository: kwin Description --- As discussed on release-team ml [1] the following dependencies are mandatory: * KF5Wayland * Wayland::Cursor * Wayland::Egl * xkbcommon [1] https://mail.kde.org/pipermail/release-team/2015-July/008725.html Drop cmakedefine HAVE_XKB No longer needed, we always depend on xkbcommon now. Drop cmakedefine HAVE_WAYLAND_CURSOR Now a required build-dep. Drop cmakedefine HAVE_WAYLAND Now a required build dependency. Drop cmakedefine HAVE_WAYLAND_EGL Now a required build dependency. Make X11_XCB a build dependency of X11 windowed backend Let's rather not build the plugin if we don't have the dependency then building it without OpenGL support. Simplifies the code a bit and makes the backend overall more useful and goes along with e.g. the Wayland one which has EGL also as a hard dependency for the plugin. Diffs - CMakeLists.txt 056801feaa40b8bc24e56b5d132a3e02e66b6782 abstract_backend.cpp 28564e3e03a68f78c58d351b0a2eb1f66a088879 abstract_client.cpp 45976224394a8a467836bbe72596057446c95051 abstract_egl_backend.h c266521d3a870b4bd110435fa6c5f8e5d4e72e33 abstract_egl_backend.cpp 5ef3adaa7216c314b56c594167805da232f6a499 backends/CMakeLists.txt 809ac64edbce6df001c22395a9a991d324008d92 backends/wayland/CMakeLists.txt 7f643df2e13bc40172ea3ed5140b9aea5563b0b6 backends/wayland/wayland_backend.cpp 57a805eafa470e1fb06cd318bf557c0cd5c2e38c backends/x11/CMakeLists.txt 9ce72fad1a7800f7e9b0c085a363f8eb256b7d24 backends/x11/x11windowed_backend.cpp 95a5b70ecfa32358af934950f2c723cd9b8a03af composite.cpp 1db4790b50d99401c175e90852f5e4958f53fc8c config-kwin.h.cmake 6128c0ccae23453e2f5cf2918dee0d733aaec4d9 effects.cpp 81c6ede571f6f995eee62e999633bcbc07599914 events.cpp 3ce3f917c9a7854613244dd36cf0dc27e908d559 geometry.cpp f63e85165b9e6c605e5ed740bb61f1ec02acecc7 input.h c9ef924737b542b9d844fcb8e5b4989e02bf812d input.cpp 3e464486aa56a7edaa36371747b6c158a03c96c2 layers.cpp d8328ccafd89706eb463f5dd120b82b7288c86bb scene.h 9e412da1d0a9c54adf9d3f412aeb1eece0b3 scene.cpp 09b7ec4a3d5a0af3b976657f9b035a5bfecdc8f3 scene_opengl.cpp 3e9b849ea7e6884386944188d9d6f4d38d74090f scene_qpainter.cpp e6829138f00f4529bf13b3733f34b0e694056e9a screens.cpp 226a2eca05d386b7f8b778b21019dc2d976c1197 scripting/scripting_model.cpp 8b595f7c2ba3132bb574c48bae6d4823d9bc0366 shadow.cpp 56bc97f91c204ec14d8eb8dc6ac5a4ac253e3436 thumbnailitem.cpp 8b984558720ea974afb91aa55269ae514b44479f toplevel.h eb46eb4f7571fbde8034308903cd730af2b17854 toplevel.cpp 4740c8f873439dd6ce08d99de7ee8028ec52ebfe workspace.cpp 9568b83b04112c28cd99ec60d472d5944a9d7f1b Diff: https://git.reviewboard.kde.org/r/124697/diff/ Testing --- Thanks, Martin Gräßlin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 124675: Fix Bug 311991 - Taskbar buttons for minimized apps should not use disabled state
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/124675/ --- (Updated Aug. 11, 2015, 5:14 p.m.) Review request for Plasma. Changes --- Don't comment out code. Instead set the 'enabled' property to true. Bugs: 311991 https://bugs.kde.org/show_bug.cgi?id=311991 Repository: plasma-desktop Description --- This fixes Bug 311991. Though I am not sure if there are side effects which I am not aware of. Diffs (updated) - applets/taskmanager/package/contents/ui/Task.qml f655801ab1f7b1a9a915f35149c858f0ede22a29 Diff: https://git.reviewboard.kde.org/r/124675/diff/ Testing --- Thanks, Gregor Mi ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 124675: Fix Bug 311991 - Taskbar buttons for minimized apps should not use disabled state
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/124675/#review83715 --- ok, well lets follow the designers in that bug report. *If* their decision is to go with this patch, then from my side it's fine. - David Edmundson On Aug. 11, 2015, 5:14 p.m., Gregor Mi wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/124675/ --- (Updated Aug. 11, 2015, 5:14 p.m.) Review request for Plasma. Bugs: 311991 https://bugs.kde.org/show_bug.cgi?id=311991 Repository: plasma-desktop Description --- This fixes Bug 311991. Though I am not sure if there are side effects which I am not aware of. Diffs - applets/taskmanager/package/contents/ui/Task.qml f655801ab1f7b1a9a915f35149c858f0ede22a29 Diff: https://git.reviewboard.kde.org/r/124675/diff/ Testing --- Thanks, Gregor Mi ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Plasma Mobile Vision, intended personas meeting notes
On Tuesday 11 August 2015 11:13:57 Sebastian Kügler wrote: Some minor things: It provides a seamless experience across multiple devices. I guess your primarily mean devices running other Plasma Experiences (Desktop / PMC / whatever the future brings) Or do you want to explicitly include more? No, but we also don't have to. We can try to be perfect and exact in the wording, but then the text would be three times as long, bringing it to a length that nobody on the Internet reads. I think it's clear, if you think about it, that this integration also depends on other devices, so that the integration is not a given. I agree with Sebas that we don't have to fear someone pointing a gun at our chest and saying But you said 'devices', so I demand a great experience even with my Windows PC!. That said, we still can change it to something like across Plasma-powered devices if we would like to emphasize Plasma as the common element connecting them. So, while I would not include Plasma in that sentence just for the sake of correctness, I _would_ include it if the community feels that it strengthens our vision. Also, don't confuse the vision statement with a marketing product vision. The vision statement is mainly inward-facing, so we can look at it and measure our deeds against it, not so much outward-facing. For marketing and communication, we'd likely reword these things slightly, either for cover-your-ass reasons, or to make it more eloquent, interesting or catchy. Good point. If we indeed want two different versions, however, we should come up with the outward-facing one soon as well, so we don't have to hold back talking about it publicly. Plus, we have to be aware that even the inward-facing vision will be public, even if it's only on our Wiki. Also the wording is not perfect. It sound like plasma mobile will be on multiple devices that provide a seamless experience when used together. That's what we wanted to express, though. :-) Think what we can bring t the table with kdeconnect, for example... As stated above: If the community could identify even better with a vision that explicitly emphasized a cross-Plasma experience, that's fine. Plasma Mobile implements open standards, and -- unlike Android -- it is developed in a transparent process that is open for the community to participate in. I am undecided on the unlike Android part. Could you share your reasoning for including it? We decided to include it since it's important to set us apart. We've used the template that Andres and Thomas presented during Akademy, and went from there. I understand the reservations to name a competitor, but then, this is exactly what people will ask and what we should make very straightforward to understand. In a TV ad, I'd probably refrain from naming Android as competitor, in a vision statement, it helps to understand the independence and privacy awareness that we're trying to communicate. Explicitly stating your main competitor(s) can help to focus on what you aim to measure up against, so it can make sense to make it clear. That said, this merely expresses the view we shared at the end of our meeting (as there were good arguments for it), it's not set in stone. If the majority of the community would prefer not to explicitly compete with Android, (for example because you feel that we would target an audience that doesn't currently use Android), we can still change it or leave it out completely, of course. I'm glad that people seem to agree with the vision at large. We can still fine-tune some bits here and there if we agree that this would improve it even further. We can still update it at any point in time, though. A vision is a living document that should always reflect how the community feels at a given point, after all, not something you write once and then must never touch again. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
[Powerdevil] [Bug 351209] Brightness setting for On Battery works only for a very low brightness level
https://bugs.kde.org/show_bug.cgi?id=351209 --- Comment #3 from a.prono...@gmail.com --- In my case it will not be lowered. When I said that there is a dependency between the AC and battery brightness, I meant that AC brightness level has to be sth like 10 times larger than the battery brightness in order for the battery brightness to be changed. -- You are receiving this mail because: You are the assignee for the bug. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
[Powerdevil] [Bug 351209] Brightness setting for On Battery works only for a very low brightness level
https://bugs.kde.org/show_bug.cgi?id=351209 --- Comment #1 from a.prono...@gmail.com --- It also seems that the max level for which brightness will still be adjusted depends on the screen brightness when AC is unplugged. Example: If I lower the brightness using Fn keys before unplugging, the brightness will NOT be adjusted even if set to a low level in the settings On Battery. -- You are receiving this mail because: You are the assignee for the bug. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
[Powerdevil] [Bug 351209] New: Brightness setting for On Battery works only for a very low brightness level
https://bugs.kde.org/show_bug.cgi?id=351209 Bug ID: 351209 Summary: Brightness setting for On Battery works only for a very low brightness level Product: Powerdevil Version: 5.3.90 Platform: Ubuntu Packages OS: Linux Status: UNCONFIRMED Severity: normal Priority: NOR Component: general Assignee: plasma-devel@kde.org Reporter: a.prono...@gmail.com After enabling Screen brightness control in the On battery profile, the brightness when running on battery does not change automatically unless the Level is set to a very low value (sth around 10%). For such low value, unplugging AC will indeed affect brightness. If the level is set to any higher value, e.g. 50%, unplugging AC will not affect brightness at all. Brightness settings for On AC Power profile work without problems for any brightness level. This behavior can be observed using udeavadm monitor, which for the low level value shows for AC unplug event: KERNEL[2565.602739] change /devices/pci:00/:00:02.0/backlight/acpi_video0 (backlight) UDEV [2565.604719] change /devices/pci:00/:00:02.0/backlight/acpi_video0 (backlight) If higher level is set, udev only reports setting brightness when plugging IN the AC, but not when unplugging. Keyboard backlight also does not seem to work for the On Battery profile, while it does work for On AC power. Reproducible: Always Steps to Reproduce: 1. Enable Screen brightness for On Battery profile and set the level to 50% 2. Unplug AC 3. Observe that the brightness did not change 4. Plug in AC 5. Set brightness level to around 5% 6. Unplug AC 7. Observe that brightness has been changed Actual Results: As in the steps, brightness is not affected for certain level settings. Expected Results: Brightness should be adjusted no matter what level is set. Running Ubuntu 15.10 with KDE 5.3.95. -- You are receiving this mail because: You are the assignee for the bug. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
[Powerdevil] [Bug 351209] Brightness setting for On Battery works only for a very low brightness level
https://bugs.kde.org/show_bug.cgi?id=351209 Kai Uwe Broulik k...@privat.broulik.de changed: What|Removed |Added CC||k...@privat.broulik.de Resolution|--- |WONTFIX Status|UNCONFIRMED |RESOLVED --- Comment #2 from Kai Uwe Broulik k...@privat.broulik.de --- If the current brightness is lower than the one configured for On Battery, the brightness will not be raised when unplugging AC. This is intended behavior. -- You are receiving this mail because: You are the assignee for the bug. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
