[Breeze] [Bug 384129] Rename colors from British to American English
https://bugs.kde.org/show_bug.cgi?id=384129 --- Comment #3 from Heiko Tietze <tietze.he...@gmail.com> --- Not my idea, but LibreOffice translates color names and KDE could do that too with Breeze_EN-GB.col. -- You are receiving this mail because: You are the assignee for the bug.
Re: KCM for network configuration
On 10/13/2016 10:57 AM, Jan Grulich wrote: > So what do you think? > > [1] - https://jgrulich.fedorapeople.org/kcm_network.png Awesome, really nice! A few nitpicks: * a little bit more vertical space between the controls * the checkbox needs a label like "[ ] Enable" or better "Visibility: [ ] Hidden Network" * Random has ellipsis indicating that there is more interaction; not sure if that's true for generation of a random number And remarks: * years ago we had the goal to get rid of tabs * I wonder how you deal with the not so happy paths; left list is unexpected concise But good work anyway. Most users will likely be very happy with your solution. Cheers, Heiko signature.asc Description: OpenPGP digital signature
Re: Review Request 128400: Configuration option for System Tray's icon size
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/128400/#review97202 --- Please add a screenshot. But actually I wonder why size matters. Aren't icons adjusted according the panel height anymore? That would by a minus one. - Heiko Tietze On July 8, 2016, 8:56 a.m., John Salatas wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/128400/ > --- > > (Updated July 8, 2016, 8:56 a.m.) > > > Review request for Plasma and KDE Usability. > > > Repository: plasma-workspace > > > Description > --- > > I didn't like the recent changes in systray icon size related to bug #364431, > so I created this patch in order to make the systray's icon size user > configurable > > > Diffs > - > > applets/systemtray/package/contents/code/IconSizeTools.js PRE-CREATION > applets/systemtray/package/contents/config/main.xml 65a7029 > applets/systemtray/package/contents/ui/ConfigGeneral.qml 4fcfcf6 > applets/systemtray/package/contents/ui/main.qml a66ea69 > > Diff: https://git.reviewboard.kde.org/r/128400/diff/ > > > Testing > --- > > Tested in KDE Neon Developer Stable (as of July 7, 2016) > > > Thanks, > > John Salatas > > ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
[Powerdevil] [Bug 358957] laptop won't hybrid-suspend when Plasma is running
https://bugs.kde.org/show_bug.cgi?id=358957 Heiko Tietze <tietze.he...@gmail.com> changed: What|Removed |Added CC||tietze.he...@gmail.com --- Comment #7 from Heiko Tietze <tietze.he...@gmail.com> --- My first thought was to agree with the checkbox. But actually it's an intermediate method suspending to both RAM and disk. If you could place the checkbox at either hibernate or suspend it makes no sense. By the way: I like the description in the Arch wiki with "Suspend to RAM/disk/both". From the usability POV even a third option (aka radio button) is not a good solution. Strictly speaking it's not an exclusive setting. "Both" implies rather to have checkboxes for RAM (or hibernate) and disk (aka suspend, I may have mixed the terms), and checking both means hybrid-suspense. If I understand the underlying functionality right it works exactly in this way: you have the current state in both RAM and on disk allowing to wake-up quickly from RAM with the safety of a backup on disk when you run of of 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
Re: Review Request 126960: [Calendar] Add proper back/forward buttons and a "Today" button
---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/126960/#review92071
---
File Attachment: How about this? #2 - How about this? #2
<https://git.reviewboard.kde.org//r/126960/#fcomment499>
Bug 299174 - Remove "week number" from system tray calendar for improved
readability
https://bugs.kde.org/show_bug.cgi?id=299174
(I disagree with the idea to remove it. But some ideas have been stressed
in this thread.)
- Heiko Tietze
On Feb. 4, 2016, 11:19 p.m., Kai Uwe Broulik wrote:
>
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/126960/
> ---
>
> (Updated Feb. 4, 2016, 11:19 p.m.)
>
>
> Review request for Plasma and KDE Usability.
>
>
> Bugs: 336124, 348362 and 358536
> http://bugs.kde.org/show_bug.cgi?id=336124
> http://bugs.kde.org/show_bug.cgi?id=348362
> http://bugs.kde.org/show_bug.cgi?id=358536
>
>
> Repository: plasma-framework
>
>
> Description
> ---
>
> This removes the custom label-based triangles and replaces them with proper
> ToolButtons using proper icons. It also adds a "Today" button to return to
> the current day. Also, tooltips that reflect the actual action ("Previous
> Month", "Previous Year", "Previous Decade", depending on the zoom level) were
> added.
>
>
> Diffs
> -
>
> src/declarativeimports/calendar/qml/DaysCalendar.qml 3ab16eb
> src/declarativeimports/calendar/qml/MonthView.qml c876e3b
>
> Diff: https://git.reviewboard.kde.org/r/126960/diff/
>
>
> Testing
> ---
>
> Works.
>
> The weekday names look a bit awkward now
>
>
> File Attachments
>
>
> Screenshot
>
> https://git.reviewboard.kde.org/media/uploaded/files/2016/02/01/a065dfcf-ca75-4d50-81aa-4d725245344e__Screenshot_20160201_234605.png
> How about this?
>
> https://git.reviewboard.kde.org/media/uploaded/files/2016/02/04/d80b6161-3da3-4669-ba7c-19f62edbf542__Screenshot_20160205_001739.png
> How about this? #2
>
> https://git.reviewboard.kde.org/media/uploaded/files/2016/02/04/73f2ada9-48cd-4b22-8ef2-5d37f2238442__Screenshot_20160205_001754.png
>
>
> Thanks,
>
> Kai Uwe Broulik
>
>
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 126593: [Task Manager] Add Jump List actions to grouped tasks
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/126593/#review91809 --- Hard to say if those items have to be placed at top or bottom. First impression is to have them rather at the bottom. But according the HIG "Place options that represent general options (e.g. All, None) at the beginning of the list." this patch is good. - Heiko Tietze On Jan. 1, 2016, 6:41 p.m., Kai Uwe Broulik wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/126593/ > --- > > (Updated Jan. 1, 2016, 6:41 p.m.) > > > Review request for Plasma and KDE Usability. > > > Repository: plasma-desktop > > > Description > --- > > This just adds the jump list actions to the top of the menu as with all the > other tasks. > > Is it better if we place the jump list actions below the list of windows? > > > Diffs > - > > applets/taskmanager/plugin/backend.cpp f83ae09 > > Diff: https://git.reviewboard.kde.org/r/126593/diff/ > > > Testing > --- > > Works > > > File Attachments > > > Jump List Action group > > https://git.reviewboard.kde.org/media/uploaded/files/2016/01/01/c0479186-77e7-4d33-bb6a-49b4abaf96f1__jumplistactionongroup.jpg > > > Thanks, > > Kai Uwe Broulik > > ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 126300: Plasma Search KCM: display the runner descriptions
> On Jan. 24, 2016, 8:58 p.m., Jonathan Marten wrote: > > Ping anyone? > > Kai Uwe Broulik wrote: > Please if you fixed an issue raised mark is as fixed so the "open issues" > count drops, making it easier to see what has changed. After it's zero and > you already got a "Ship It" (see above, "Fix it", covered behind there's the > "Ship it") feel free to commit. UX is not an exact science. I might be wrong, and always want to get at least one other opinion. But anyway, ship it. - Heiko --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/126300/#review91537 --- On Jan. 10, 2016, 4:33 p.m., Jonathan Marten wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/126300/ > --- > > (Updated Jan. 10, 2016, 4:33 p.m.) > > > Review request for Plasma and KDE Usability. > > > Repository: plasma-desktop > > > Description > --- > > In Plasma 5 this KCM only lists the names of the available runners, with no > explanation of what they do. In its previous incarnation in KDE4 (the > dropdown list from the runner config button), the descriptions were > displayed. This change restores them. > > > Diffs > - > > kcms/runners/kcm.h f1239ee > kcms/runners/kcm.cpp 4af82de > > Diff: https://git.reviewboard.kde.org/r/126300/diff/ > > > Testing > --- > > Built plasma-desktop with this change, checked appearance of KCM in Breeze, > Oxygen and older styles. > > > File Attachments > > > Screenshot before > > https://git.reviewboard.kde.org/media/uploaded/files/2015/12/10/caf0a4d7-ab8d-410a-9409-ae6935d24929__plasmasearch-before-r126300.png > Screenshot after > > https://git.reviewboard.kde.org/media/uploaded/files/2015/12/10/0b695a2b-4307-4a70-9a9b-4c3bb80f7955__plasmasearch-after-r126300.png > Long lines elided > > https://git.reviewboard.kde.org/media/uploaded/files/2016/01/10/193898fa-d860-4263-b2c1-e060a89522dc__plasmasearch-elided-r126303.png > > > Thanks, > > Jonathan Marten > > ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 126300: Plasma Search KCM: display the runner descriptions
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/126300/#review91549 --- Ship it! Ship It! - Heiko Tietze On Jan. 10, 2016, 4:33 p.m., Jonathan Marten wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/126300/ > --- > > (Updated Jan. 10, 2016, 4:33 p.m.) > > > Review request for Plasma and KDE Usability. > > > Repository: plasma-desktop > > > Description > --- > > In Plasma 5 this KCM only lists the names of the available runners, with no > explanation of what they do. In its previous incarnation in KDE4 (the > dropdown list from the runner config button), the descriptions were > displayed. This change restores them. > > > Diffs > - > > kcms/runners/kcm.h f1239ee > kcms/runners/kcm.cpp 4af82de > > Diff: https://git.reviewboard.kde.org/r/126300/diff/ > > > Testing > --- > > Built plasma-desktop with this change, checked appearance of KCM in Breeze, > Oxygen and older styles. > > > File Attachments > > > Screenshot before > > https://git.reviewboard.kde.org/media/uploaded/files/2015/12/10/caf0a4d7-ab8d-410a-9409-ae6935d24929__plasmasearch-before-r126300.png > Screenshot after > > https://git.reviewboard.kde.org/media/uploaded/files/2015/12/10/0b695a2b-4307-4a70-9a9b-4c3bb80f7955__plasmasearch-after-r126300.png > Long lines elided > > https://git.reviewboard.kde.org/media/uploaded/files/2016/01/10/193898fa-d860-4263-b2c1-e060a89522dc__plasmasearch-elided-r126303.png > > > Thanks, > > Jonathan Marten > > ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 126688: RFC: [Device Notifier] Provide inline feedback
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/126688/#review91408 --- Ship it! Ship It! - Heiko Tietze On Jan. 11, 2016, 4:19 p.m., Kai Uwe Broulik wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/126688/ > --- > > (Updated Jan. 11, 2016, 4:19 p.m.) > > > Review request for Plasma and KDE Usability. > > > Repository: plasma-workspace > > > Description > --- > > Instead of showing a detached status bar with the device name, show the > message below the device. > > When removing a device, device notifier will pop up and a "You can now safely > remove this device" message will show up; after 5 seconds the message and the > device will disappear. When trying to unmount a device and it fails, device > notifier will show up with an error message that will stay there until device > notifier is closed or another message appears. > > This review consists of two patches: one for fixing the device notifications > engine's wording (I'm open to better verbalizations) and one for the device > notifier > > > Diffs > - > > applets/devicenotifier/package/contents/ui/DeviceItem.qml a410e25 > applets/devicenotifier/package/contents/ui/FullRepresentation.qml 9e9aa25 > applets/devicenotifier/package/contents/ui/StatusBar.qml ba827c3 > applets/devicenotifier/package/contents/ui/devicenotifier.qml 29cdaca > dataengines/devicenotifications/ksolidnotify.h fac8cc1 > dataengines/devicenotifications/ksolidnotify.cpp 3935ba3 > > Diff: https://git.reviewboard.kde.org/r/126688/diff/ > > > Testing > --- > > There a still a couple of glitches: > - the layout doesn't properly reset at times (eg. the delegate height doesn't > update) or fails to show certain items (also looks like a Qt bug) > - sometimes the delegates suddenly overlap each other beacuse the section > thing gets confused when the one item is already gone in the model (looks > like a Qt bug) > - the "no devices" heading doesn't know that there's still a pseudo-device > there > - it cannot actually highlight the device that was safely removed (it's no > longer part of the model and thus has no index), we could do a hack for this > though > - the message doesn't disappear reliably or spontaneously re-appears > - depending on your screen dpi you sometimes get a black and white Info icon > but the error thing is always red, there's a smaller variant for the former > but not the latter apparently, also it seems we lack a proper "task done" > icon, Oxygen had one > > > File Attachments > > > Failed to mount > > https://git.reviewboard.kde.org/media/uploaded/files/2016/01/09/8e7142b2-38a9-4867-a067-0e6cdbcaa076__devicenotifierinlinefeedback1.png > Safely remove > > https://git.reviewboard.kde.org/media/uploaded/files/2016/01/09/a43199cf-36a3-4337-9843-cb7375462c57__devicenotifierinlinefeedback2.png > Emblem icon > > https://git.reviewboard.kde.org/media/uploaded/files/2016/01/10/607af6d4-7533-4b1f-b483-182afe9b4173__devicenotifierinlinefeedback3.png > Emblem-error > > https://git.reviewboard.kde.org/media/uploaded/files/2016/01/11/cf96b627-535d-404a-9330-61b171ebda3b__devicenotifierinlinefeedback4.png > emblem-information > > https://git.reviewboard.kde.org/media/uploaded/files/2016/01/11/1ee27871-65f8-4fc2-ae43-1c31a197578d__devicenotifierinlinefeedback5.png > > > Thanks, > > Kai Uwe Broulik > > ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 126730: cleanup sddm kcm
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/126730/#review90988 --- Yes, this KCM is not designed according the HIG. It could look like this http://i.imgur.com/TVAZBFl.png. Enhancement idea to the existing HIG is a horizontal splitter left of "more" that allows to enlarge either the upper area to see more than just a few items in the list or to have more space for the advanced options. About the content I wonder why someone would want to change the cursor at this point of the login. And User would be some kind of restriction allowing only a range of users to login, if I get this right. Makes not much sense to me, however. But anyway, it would be added below the other stuff - my mockup cuts the content there for lazyness purpose :-). A remark regarding the existing KCM: it takes a lot of space and probably I'm not the only one who tries to resize the left part. My suggestion is to add a vertical splitter. And maybe the right part for customization could be smaller by default. PS: KCMs should indicate if the execution needs elevated user rights. No idea how at the moment. - Heiko Tietze On Jan. 13, 2016, 12:21 vorm., andreas kainz wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/126730/ > --- > > (Updated Jan. 13, 2016, 12:21 vorm.) > > > Review request for Plasma and Heiko Tietze. > > > Repository: sddm-kcm > > > Description > --- > > remove the webpage and the author in the overview cause this is shown in the > preview section. > > > Diffs > - > > src/themesdelegate.cpp 1b528a0 > src/ui/advanceconfig.ui e7fcb97 > src/ui/themeconfig.ui 33cc685 > > Diff: https://git.reviewboard.kde.org/r/126730/diff/ > > > Testing > --- > > after this cleanup there is one point open but therefore I need someone with > real coding skills. > > KCM HIG > https://community.kde.org/KDE_Visual_Design_Group/System_Settings_Application > > don't use tabs -> add an more button. > > So you have an select area and an preview area as in my point of view the > Auto Login is an "standard setting" I would add the auto login section on > bottom of the select area. > On the bottom page you have an botton > - use userdefined background > - advanced setting > - import from file (now not available) > - import from GHNS (now not available) > > > File Attachments > > > sddm-kcm.png > > https://git.reviewboard.kde.org/media/uploaded/files/2016/01/13/483cf282-99b2-4c26-ab51-0d415d3fdf5e__sddm-kcm.png > > > Thanks, > > andreas kainz > > ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 126730: cleanup sddm kcm
> On Jan. 13, 2016, 9:52 a.m., Heiko Tietze wrote: > > Yes, this KCM is not designed according the HIG. It could look like this > > http://i.imgur.com/TVAZBFl.png. Enhancement idea to the existing HIG is a > > horizontal splitter left of "more" that allows to enlarge either the upper > > area to see more than just a few items in the list or to have more space > > for the advanced options. > > About the content I wonder why someone would want to change the cursor at > > this point of the login. And User would be some kind of restriction > > allowing only a range of users to login, if I get this right. Makes not > > much sense to me, however. But anyway, it would be added below the other > > stuff - my mockup cuts the content there for lazyness purpose :-). > > > > A remark regarding the existing KCM: it takes a lot of space and probably > > I'm not the only one who tries to resize the left part. My suggestion is to > > add a vertical splitter. And maybe the right part for customization could > > be smaller by default. > > > > PS: KCMs should indicate if the execution needs elevated user rights. No > > idea how at the moment. > > andreas kainz wrote: > thanks for your comment I like your KCM Style when I know more about cpp > and qml I will come back and look that I can make the SDDM KCM like you wrote. PS: I'm flattered to be a trusted reviewer, but addressing "usability" may get more opinions. - Heiko --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/126730/#review90988 --- On Jan. 13, 2016, 7:50 p.m., andreas kainz wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/126730/ > --- > > (Updated Jan. 13, 2016, 7:50 p.m.) > > > Review request for Plasma and Heiko Tietze. > > > Repository: sddm-kcm > > > Description > --- > > remove the webpage and the author in the overview cause this is shown in the > preview section. > > > Diffs > - > > src/themesdelegate.cpp 1b528a0 > src/ui/advanceconfig.ui e7fcb97 > src/ui/themeconfig.ui 33cc685 > > Diff: https://git.reviewboard.kde.org/r/126730/diff/ > > > Testing > --- > > after this cleanup there is one point open but therefore I need someone with > real coding skills. > > KCM HIG > https://community.kde.org/KDE_Visual_Design_Group/System_Settings_Application > > don't use tabs -> add an more button. > > So you have an select area and an preview area as in my point of view the > Auto Login is an "standard setting" I would add the auto login section on > bottom of the select area. > On the bottom page you have an botton > - use userdefined background > - advanced setting > - import from file (now not available) > - import from GHNS (now not available) > > > File Attachments > > > sddm-kcm.png > > https://git.reviewboard.kde.org/media/uploaded/files/2016/01/13/483cf282-99b2-4c26-ab51-0d415d3fdf5e__sddm-kcm.png > > > Thanks, > > andreas kainz > > ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 126688: RFC: [Device Notifier] Provide inline feedback
> On Jan. 11, 2016, 8:12 nachm., Kai Uwe Broulik wrote: > > Someone suggested to style it like this: https://i.imgur.com/nPVhWr9.png > > > > While I'm not a huge fan of that excessive green background I agree that > > perhaps the message should be more prominently displayed, ie. moving back > > to showing the icon next to the message and maybe adding a faint highlight > > behind the item. > > Heiko Tietze wrote: > Better than coloring or higlighting parts of the UI you improve > positioning and spacing of controls. That means in this case to indent the > device information. > > Kai Uwe Broulik wrote: > Indent what? where? Sorry, I was completely wrong. The term 'style' put me to the wrong track, but actually you wanted to indicate the selection. Well done. - Heiko --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/126688/#review90936 --- On Jan. 11, 2016, 4:19 nachm., Kai Uwe Broulik wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/126688/ > --- > > (Updated Jan. 11, 2016, 4:19 nachm.) > > > Review request for Plasma and KDE Usability. > > > Repository: plasma-workspace > > > Description > --- > > Instead of showing a detached status bar with the device name, show the > message below the device. > > When removing a device, device notifier will pop up and a "You can now safely > remove this device" message will show up; after 5 seconds the message and the > device will disappear. When trying to unmount a device and it fails, device > notifier will show up with an error message that will stay there until device > notifier is closed or another message appears. > > This review consists of two patches: one for fixing the device notifications > engine's wording (I'm open to better verbalizations) and one for the device > notifier > > > Diffs > - > > applets/devicenotifier/package/contents/ui/DeviceItem.qml a410e25 > applets/devicenotifier/package/contents/ui/FullRepresentation.qml 9e9aa25 > applets/devicenotifier/package/contents/ui/StatusBar.qml ba827c3 > applets/devicenotifier/package/contents/ui/devicenotifier.qml 29cdaca > dataengines/devicenotifications/ksolidnotify.h fac8cc1 > dataengines/devicenotifications/ksolidnotify.cpp 3935ba3 > > Diff: https://git.reviewboard.kde.org/r/126688/diff/ > > > Testing > --- > > There a still a couple of glitches: > - the layout doesn't properly reset at times (eg. the delegate height doesn't > update) or fails to show certain items (also looks like a Qt bug) > - sometimes the delegates suddenly overlap each other beacuse the section > thing gets confused when the one item is already gone in the model (looks > like a Qt bug) > - the "no devices" heading doesn't know that there's still a pseudo-device > there > - it cannot actually highlight the device that was safely removed (it's no > longer part of the model and thus has no index), we could do a hack for this > though > - the message doesn't disappear reliably or spontaneously re-appears > - depending on your screen dpi you sometimes get a black and white Info icon > but the error thing is always red, there's a smaller variant for the former > but not the latter apparently, also it seems we lack a proper "task done" > icon, Oxygen had one > > > File Attachments > > > Failed to mount > > https://git.reviewboard.kde.org/media/uploaded/files/2016/01/09/8e7142b2-38a9-4867-a067-0e6cdbcaa076__devicenotifierinlinefeedback1.png > Safely remove > > https://git.reviewboard.kde.org/media/uploaded/files/2016/01/09/a43199cf-36a3-4337-9843-cb7375462c57__devicenotifierinlinefeedback2.png > Emblem icon > > https://git.reviewboard.kde.org/media/uploaded/files/2016/01/10/607af6d4-7533-4b1f-b483-182afe9b4173__devicenotifierinlinefeedback3.png > Emblem-error > > https://git.reviewboard.kde.org/media/uploaded/files/2016/01/11/cf96b627-535d-404a-9330-61b171ebda3b__devicenotifierinlinefeedback4.png > emblem-information > > https://git.reviewboard.kde.org/media/uploaded/files/2016/01/11/1ee27871-65f8-4fc2-ae43-1c31a197578d__devicenotifierinlinefeedback5.png > > > Thanks, > > Kai Uwe Broulik > > ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 126688: RFC: [Device Notifier] Provide inline feedback
> On Jan. 11, 2016, 8:12 p.m., Kai Uwe Broulik wrote: > > Someone suggested to style it like this: https://i.imgur.com/nPVhWr9.png > > > > While I'm not a huge fan of that excessive green background I agree that > > perhaps the message should be more prominently displayed, ie. moving back > > to showing the icon next to the message and maybe adding a faint highlight > > behind the item. Better than coloring or higlighting parts of the UI you improve positioning and spacing of controls. That means in this case to indent the device information. - Heiko --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/126688/#review90936 --- On Jan. 11, 2016, 4:19 p.m., Kai Uwe Broulik wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/126688/ > --- > > (Updated Jan. 11, 2016, 4:19 p.m.) > > > Review request for Plasma and KDE Usability. > > > Repository: plasma-workspace > > > Description > --- > > Instead of showing a detached status bar with the device name, show the > message below the device. > > When removing a device, device notifier will pop up and a "You can now safely > remove this device" message will show up; after 5 seconds the message and the > device will disappear. When trying to unmount a device and it fails, device > notifier will show up with an error message that will stay there until device > notifier is closed or another message appears. > > This review consists of two patches: one for fixing the device notifications > engine's wording (I'm open to better verbalizations) and one for the device > notifier > > > Diffs > - > > applets/devicenotifier/package/contents/ui/DeviceItem.qml a410e25 > applets/devicenotifier/package/contents/ui/FullRepresentation.qml 9e9aa25 > applets/devicenotifier/package/contents/ui/StatusBar.qml ba827c3 > applets/devicenotifier/package/contents/ui/devicenotifier.qml 29cdaca > dataengines/devicenotifications/ksolidnotify.h fac8cc1 > dataengines/devicenotifications/ksolidnotify.cpp 3935ba3 > > Diff: https://git.reviewboard.kde.org/r/126688/diff/ > > > Testing > --- > > There a still a couple of glitches: > - the layout doesn't properly reset at times (eg. the delegate height doesn't > update) or fails to show certain items (also looks like a Qt bug) > - sometimes the delegates suddenly overlap each other beacuse the section > thing gets confused when the one item is already gone in the model (looks > like a Qt bug) > - the "no devices" heading doesn't know that there's still a pseudo-device > there > - it cannot actually highlight the device that was safely removed (it's no > longer part of the model and thus has no index), we could do a hack for this > though > - the message doesn't disappear reliably or spontaneously re-appears > - depending on your screen dpi you sometimes get a black and white Info icon > but the error thing is always red, there's a smaller variant for the former > but not the latter apparently, also it seems we lack a proper "task done" > icon, Oxygen had one > > > File Attachments > > > Failed to mount > > https://git.reviewboard.kde.org/media/uploaded/files/2016/01/09/8e7142b2-38a9-4867-a067-0e6cdbcaa076__devicenotifierinlinefeedback1.png > Safely remove > > https://git.reviewboard.kde.org/media/uploaded/files/2016/01/09/a43199cf-36a3-4337-9843-cb7375462c57__devicenotifierinlinefeedback2.png > Emblem icon > > https://git.reviewboard.kde.org/media/uploaded/files/2016/01/10/607af6d4-7533-4b1f-b483-182afe9b4173__devicenotifierinlinefeedback3.png > Emblem-error > > https://git.reviewboard.kde.org/media/uploaded/files/2016/01/11/cf96b627-535d-404a-9330-61b171ebda3b__devicenotifierinlinefeedback4.png > emblem-information > > https://git.reviewboard.kde.org/media/uploaded/files/2016/01/11/1ee27871-65f8-4fc2-ae43-1c31a197578d__devicenotifierinlinefeedback5.png > > > Thanks, > > Kai Uwe Broulik > > ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 126356: change minimum size of clipboard
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/126356/#review90832 --- I'm not so sure if plasmoids started from desktop and panel have to be equal (if at all than I'd care about the caption). For what reason, familiarity? And the final size in the last picture (clipboardMinimumSize.png) is way too small to suit user's needs. That is here to browse through and read the content. For example 'dd if=/dev/zero of=/dev/s...' thrills only the bravest. The size of clipboard-new.png is okay. The current size for the panel based plasmoid is reasonable and similar to other plasmoids like the notification. And it fits the general visual style of Breeze. But that's only a two cent option. (BTW: I read in several postings that Breeze becomes very breezy with too large marigins and spaces.) Whether What I rather would expect is that a desktop plugin shows the list permanently and has means for resizing. Actually what is shown in the last screenshot but with a better default size. Took me some time to figure out how to achieve this (was aware of the option only because of the screenshot): One has to long click the icon! And there is no way back. tl;dr: (sorry for all my considerations; writing down all thoughts while testing is somewhat verbose) * same height is okay but not really necessary * default size should be large enough to read the labels * users should be able to minimize as much as possible, so yes to the patch if it's not the default - Heiko Tietze On Jan. 9, 2016, 9:54 p.m., andreas kainz wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/126356/ > --- > > (Updated Jan. 9, 2016, 9:54 p.m.) > > > Review request for Plasma and Heiko Tietze. > > > Repository: plasma-workspace > > > Description > --- > > if you use clipboard on the desktop the minimum window height is heigher than > you use clipboard from the panel (drop down window). As the user can define > the width and height for the desktop plasmoid the minimum allowed height > should be at least the same than the drop down window in the panel. so I > change the minimumHeig to 16. > > > Diffs > - > > applets/clipboard/contents/ui/clipboard.qml 97230c1 > > Diff: https://git.reviewboard.kde.org/r/126356/diff/ > > > Testing > --- > > > File Attachments > > > old before with 26 min height > > https://git.reviewboard.kde.org/media/uploaded/files/2015/12/15/cdc4e222-a954-4f92-816f-521f35aab7c7__clipboard-alt_.png > new after with 16 min height > > https://git.reviewboard.kde.org/media/uploaded/files/2015/12/15/50773744-a980-4091-8ef2-7eec516cb597__clipboard-new_.png > screenshot > > https://git.reviewboard.kde.org/media/uploaded/files/2016/01/09/566b420b-df44-44d4-86b3-b9f2d441aed8__clipboardMinimumSize.png > > > Thanks, > > andreas kainz > > ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 126647: [Task Manager] Provide media controls in tooltips
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/126647/#review90685 --- The blurred shadow looks wrong. As reference I would use the HIG about images https://techbase.kde.org/Projects/Usability/HIG/Layout/Image "Use a semi-transparent background behind the (was: caption text) controls to preserve contrast for legibility." Perhaps you can adjust dark/bright according the system theme. Alternatively (actually this would have been my first thought) you could place the controls right of the callout text and have the album art instead of the icon. By doing so the callout size and control's position remain as usual. - Heiko Tietze On Jan. 5, 2016, 11:40 nachm., Kai Uwe Broulik wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/126647/ > --- > > (Updated Jan. 5, 2016, 11:40 nachm.) > > > Review request for Plasma, KDE Usability and Eike Hein. > > > Bugs: 352126 > https://bugs.kde.org/show_bug.cgi?id=352126 > > > Repository: plasma-desktop > > > Description > --- > > This adds media player controls to the tooltip of a media player, using the > already existing mpris dataengine this was pretty straightforward to > implement. > > When album art is available, no window thumbnails will be shown, instead the > album art. There will be a close button on the album art closing the first > window. Multiple windows for a player is uncommon and you can still access > them all by clicking the task manager entry. > > Interestingly enough, Amarok does not expose its album art through MPris. > Also, if it wouldn't crash whilst doing so, you could control Amarok when > it's main window is closed if you have a launcher pinned to your task > manager, basically rendering its tray icon obsolete. > > > Diffs > - > > applets/taskmanager/package/contents/ui/Task.qml 2a6 > applets/taskmanager/package/contents/ui/ToolTipDelegate.qml 972dd62 > applets/taskmanager/package/contents/ui/ToolTipWindowMouseArea.qml > PRE-CREATION > > Diff: https://git.reviewboard.kde.org/r/126647/diff/ > > > Testing > --- > > Works with VLC and Audacious, does not work with Dragon as the player > announces itself as "dragonplayer" while its Desktop file says "dragon" > > > File Attachments > > > VLC with album art > > https://git.reviewboard.kde.org/media/uploaded/files/2016/01/05/3058dacb-1dfd-464d-a1ec-be90bc9e58a8__mpristaskmanagerreview1.png > Amarok without album art > > https://git.reviewboard.kde.org/media/uploaded/files/2016/01/05/6799d6f6-d505-4f56-9531-3013a3e34ae6__mpristaskmanagerreview2.png > > > Thanks, > > Kai Uwe Broulik > > ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 126621: [Task Manager] Add support for Unity Launcher API
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/126621/#review90524 --- Pretty cool stuff. Guess there will some greediness from other launchers. On the first glance I read the tool as a launcher for Unity, which would be weird. So I suggest to think about renaming, maybe just without the space. - Heiko Tietze On Jan. 3, 2016, 11:18 nachm., Kai Uwe Broulik wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/126621/ > --- > > (Updated Jan. 3, 2016, 11:18 nachm.) > > > Review request for Plasma, KDE Usability, Craig Drummond, Eike Hein, and > Lukáš Tinkl. > > > Bugs: 343632 > https://bugs.kde.org/show_bug.cgi?id=343632 > > > Repository: plasma-desktop > > > Description > --- > > This adds support for the Unity Launcher API [1] with which applications can > show a progress indicator, a number badge as well as demand the user's > attention. > > This functionality has been present in the Icon Tasks applet [2] in Plasma 4 > times. libunity must be present for most applications to actually use this. > > I did not want to pollute libtaskmanager with this, so I made it a plugin in > the Task Manager applet, which should also be fairly trivial to update to the > new Launcher API that Unity 8 is going to use [3], or if we come up with our > own solution at some point, maybe. > > The primary focus is still the icons only task manager as the Unity API works > on a per-application/per-launcher basis rather than per-window, however, > where it makes sense the functonality is also offered to the traditional task > manager. A downside of this is that (in the current implementation, anyways) > in case you do not group your tasks and you have multiple windows of the same > task open, it will show the same information on all entries. > > For progress it gradually fills up the background of the task (VDG: I need a > better graphic here, I currently abuse the "hover" tasks SVG, also I find the > "+2" badge less than optimal) in all cases. The badges are only shown if 1) > the cell is large enough 2) the label is *not* shown (ie. icon tasks manager > or the regular one in very narrow). The badge is just a circle in theme > highlight color, not an actual SVG - it cuts off part of the icon to provide > more contrast. The "urgent" state just highlights the entry as if it > requested attention, there's no wiggle animation and this is nowhere > integrated with the window manager, also I did not find an application that > used this, so I have no idea how it's used by them. > > A video with the regular task manager on the top, a regular task manager and > an icon tasks applet in the left panel and an icon tasks applet on the > desktop (the latter is broken in the video, fixed in this patch) can be found > here [4]. > > (There's still a ton of qDebug in the code at this point) > > [1] https://wiki.ubuntu.com/Unity/LauncherAPI > [2] http://kde-apps.org/content/show.php/Icon+Tasks?content=144808 > [3] > http://bazaar.launchpad.net/~unity-team/unity8/trunk/files/head:/plugins/Unity/Launcher/ > [4] https://www.youtube.com/watch?v=aBPGjlP6Wd8 > > > Diffs > - > > applets/taskmanager/CMakeLists.txt 3c94cb7 > applets/taskmanager/package/contents/ui/Task.qml 2a6 > applets/taskmanager/plugin/taskmanagerplugin.cpp 1be1fed > applets/taskmanager/plugin/unitylauncher/unitylauncherbackend.h > PRE-CREATION > applets/taskmanager/plugin/unitylauncher/unitylauncherbackend.cpp > PRE-CREATION > applets/taskmanager/plugin/unitylauncher/unitylauncheritem.h PRE-CREATION > applets/taskmanager/plugin/unitylauncher/unitylauncheritem.cpp PRE-CREATION > > Diff: https://git.reviewboard.kde.org/r/126621/diff/ > > > Testing > --- > > I started a download in Chromium and got progress as well as a badge > indicating how many download jobs were in progress. Thunderbird also > registered a launcher on DBus but it never actually set a badge although I > had unread mail. > > > File Attachments > > > Unity Launchers > > https://git.reviewboard.kde.org/media/uploaded/files/2016/01/03/c4c552a5-0449-47b1-a7f2-35ac20886cd0__unitylauncherstuff.png > Two unrelated windows > > https://git.reviewboard.kde.org/media/uploaded/files/2016/01/03/3817426d-42e7-4aca-9478-2774f6908589__twounrelatedlaunchers.png > > > Thanks, > > Kai Uwe Broulik > > ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 126544: [Kickoff] Hide history tab if empty
> On Dec. 28, 2015, 2:02 p.m., Aleix Pol Gonzalez wrote: > > Maybe show it as disabled at least? It's weird that UI structure change > > every now and then. I agree with the idea to avoid changing UI structure. However, to disable isn't good for tabs. Here is what we wrote in the tabcontrol HIG: * Do not disable a tab when it doesn't apply to the current context; disable the controls on the page. * Make tabs closable if their pages contain documents, but not if their pages contain application's user interface. -> I recommend to neither hide nor deaktivate the tab. - Heiko --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/126544/#review90210 --- On Dec. 28, 2015, 2:01 p.m., Kai Uwe Broulik wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/126544/ > --- > > (Updated Dec. 28, 2015, 2:01 p.m.) > > > Review request for Plasma, KDE Usability and Eike Hein. > > > Bugs: 347633 > https://bugs.kde.org/show_bug.cgi?id=347633 > > > Repository: plasma-desktop > > > Description > --- > > This hides the "History" tab if it is empty. > > This can permanently happen if you use disable tracking in activity settings > or administrative means. > > > Diffs > - > > applets/kickoff/package/contents/ui/FavoritesView.qml 5b7a2cf > applets/kickoff/package/contents/ui/FullRepresentation.qml c2f5ad8 > applets/kickoff/package/contents/ui/RecentlyUsedView.qml 7169622 > > Diff: https://git.reviewboard.kde.org/r/126544/diff/ > > > Testing > --- > > Button comes and goes as I add and remove history entries. > > When I clear the history, it switches to the Favorites view so you don't end > up with a broken view. > > It doesn't seem to track application launches through Kickoff but I think > this is unrelated. > > > File Attachments > > > No history tab > > https://git.reviewboard.kde.org/media/uploaded/files/2015/12/28/3f2f0697-b5ce-420a-bfc9-8e949b345439__hiddenhistory.jpg > > > Thanks, > > Kai Uwe Broulik > > ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 126515: [DrKonqi] RFC: Support showing a StatusNotifierItem instead of bringing up the dialog right away
> On Dec. 25, 2015, 4:37 p.m., Kai Uwe Broulik wrote: > > Usability: I envisioned this to be used for auto-restarting shell services > > and not to be used by applications. > > Another interesting thought could be enabling this by default for all > > applications but for regular applications trigger a desktop notification > > (with report bug / restart app) together with the tray icon. > > > > Mockup: http://wstaw.org/m/2015/12/25/drkonqipassive.png If I understand right the auto-restart notification does not have any restart button (which wouldn't make sense) but just the report bug interaction. When the user is presented with either restart or report in case of regular apps, and the notification disapears when the button is clicked, he or she would likely rather restart than going through the debug dialog (that usually lacks on debug info). Simple solution is to show the SNI with restart option only. And even more simple is to leave the crash handling to the app. - Heiko --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/126515/#review90100 --- On Dec. 25, 2015, 4:24 p.m., Kai Uwe Broulik wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/126515/ > --- > > (Updated Dec. 25, 2015, 4:24 p.m.) > > > Review request for KDE Frameworks, Plasma, KDE Usability, and Martin Gräßlin. > > > Repository: plasma-workspace > > > Description > --- > > This adds a new "--passive" option to DrKonqi where it will only show a > StatusNotifierItem rather than bringing up the crash dialog right away. > > This can be useful for auto-restarting shell services (like plasmashell, > krunner, kded) to improve the perceived quality of the product. > > On Windows RT, for example, the guidelines even explicitly say "rather just > dump the user on the home screen than telling him something went wrong, so he > can just quickly start the app again instead of being annoyed by an error > message". On iOS you also just get dropped on the home screen. Windows > desktop shows a "Searching for a solution" dialog which was *the* major > annoyance when something crashed, rather than the actual crash. > > Video here: https://www.youtube.com/watch?v=t0ZLs-juYKc > > > Diffs > - > > drkonqi/statusnotifier.cpp PRE-CREATION > drkonqi/statusnotifier.h PRE-CREATION > drkonqi/CMakeLists.txt eaeaad4 > drkonqi/main.cpp 7cbaae7 > > Diff: https://git.reviewboard.kde.org/r/126515/diff/ > > > Testing > --- > > I crashed plasmashell, it restarted so fast that you didn't even have a black > screen inbetween, just the panel restarting. Afterwards I got a SNI which > opened DrKonqi when tapped. > > The SNI disappears after 1 minute because if you didn't bother to look after > it by then, you probably forgot what you did to cause the crash anyway :) > > > Thanks, > > Kai Uwe Broulik > > ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
[Breeze] [Bug 356863] New: Blur when docked/maximized
https://bugs.kde.org/show_bug.cgi?id=356863 Bug ID: 356863 Summary: Blur when docked/maximized Product: Breeze Version: 5.5.1 Platform: Other OS: Linux Status: UNCONFIRMED Severity: normal Priority: NOR Component: general Assignee: plasma-devel@kde.org Reporter: tietze.he...@gmail.com The edge of windows get a blur when docked to a panel. This blur looks unprecise, I always catch myself checking if the form isn't placed underneath the panel. The issue is illustrated in the screen shot. Reproducible: Always >qdbus org.kde.KWin /KWin org.kde.KWin.supportInformation Version === KWin version: 5.5.1 Qt Version: 5.5.1 Qt compile version: 5.5.1 XCB compile version: 1.11.1 Operation Mode: X11 only Decoration == Plugin: org.kde.breeze Theme: Blur: 0 onAllDesktopsAvailable: false alphaChannelSupported: true closeOnDoubleClickOnMenu: false decorationButtonsLeft: 0, 2 decorationButtonsRight: 6, 3, 4, 5 borderSize: 3 gridUnit: 10 font: Noto Sans,10,-1,5,50,0,0,0,0,0 smallSpacing: 2 largeSpacing: 10 Options === focusPolicy: 0 nextFocusPrefersMouse: false clickRaise: true autoRaise: false autoRaiseInterval: 0 delayFocusInterval: 0 shadeHover: false shadeHoverInterval: 250 separateScreenFocus: false placement: 4 focusPolicyIsReasonable: true borderSnapZone: 10 windowSnapZone: 10 centerSnapZone: 0 snapOnlyWhenOverlapping: false rollOverDesktops: false focusStealingPreventionLevel: 2 legacyFullscreenSupport: false operationTitlebarDblClick: 5000 operationMaxButtonLeftClick: 5000 operationMaxButtonMiddleClick: 5015 operationMaxButtonRightClick: 5014 commandActiveTitlebar1: 0 commandActiveTitlebar2: 30 commandActiveTitlebar3: 2 commandInactiveTitlebar1: 4 commandInactiveTitlebar2: 30 commandInactiveTitlebar3: 2 commandWindow1: 7 commandWindow2: 8 commandWindow3: 8 commandWindowWheel: 31 commandAll1: 10 commandAll2: 3 commandAll3: 14 keyCmdAllModKey: 16777250 showGeometryTip: true condensedTitle: false electricBorderMaximize: false electricBorderTiling: false electricBorderCornerRatio: 0.25 borderlessMaximizedWindows: false killPingTimeout: 5000 hideUtilityWindowsForInactive: true inactiveTabsSkipTaskbar: false autogroupSimilarWindows: false autogroupInForeground: true compositingMode: 1 useCompositing: true compositingInitialized: true hiddenPreviews: 1 unredirectFullscreen: false glSmoothScale: 2 colorCorrected: false xrenderSmoothScale: false maxFpsInterval: 1666 refreshRate: 0 vBlankTime: 600 glStrictBinding: false glStrictBindingFollowsDriver: true glCoreProfile: true glPreferBufferSwap: 112 glPlatformInterface: 2 Screen Edges desktopSwitching: false desktopSwitchingMovingClients: false cursorPushBackDistance: 1x1 timeThreshold: 150 reActivateThreshold: 350 actionTopLeft: 0 actionTop: 0 actionTopRight: 0 actionRight: 0 actionBottomRight: 0 actionBottom: 0 actionBottomLeft: 0 actionLeft: 0 Screens === Multi-Head: no Active screen follows mouse: yes Number of Screens: 2 Screen 0: - Name: HDMI1 Geometry: 0,0,1920x1080 Refresh Rate: 60 Screen 1: - Name: eDP1 Geometry: 1920,180,1600x900 Refresh Rate: 60 Compositing === Compositing is active Compositing Type: OpenGL OpenGL vendor string: Intel Open Source Technology Center OpenGL renderer string: Mesa DRI Intel(R) Haswell Mobile OpenGL version string: 3.3 (Core Profile) Mesa 11.0.7 OpenGL platform interface: EGL OpenGL shading language version string: 3.30 Driver: Intel GPU class: Haswell OpenGL version: 3.3 GLSL version: 3.30 Mesa version: 11.0.7 X server version: 1.18 Linux kernel version: 4.2.5 Direct rendering: Requires strict binding: no GLSL shaders: yes Texture NPOT support: yes Virtual Machine: no OpenGL 2 Shaders are used Painting blocks for vertical retrace: no Loaded Effects: --- zoom slidingpopups kwin4_effect_login slide screenshot minimizeanimation kwin4_effect_windowaperture flipswitch desktopgrid coverswitch kwin4_effect_fade kwin4_effect_maximize presentwindows highlightwindow kwin4_effect_dialogparent blur contrast logout windowgeometry startupfeedback screenedge kscreen Currently Active Effects: - blur contrast Effect Settings: zoom: zoomFactor: 1.2 mousePointer: 0 mouseTracking: 0 enableFocusTracking: false followFocus: true focusDelay: 350 moveFactor: 20 targetZoom: 1 slidingpopups: fadeInTime: 150 fadeOutTime: 250 kwin4_effect_login: slide: screenshot: minimizeanimation: kwin4_effect_windowaperture: flipswitch: tabBox: true tabBoxAlternative: false duration: 200 angle: 30 xPosition: 0.3301311302185 yPosition: 1 windowTitle: true desktopgrid: zoomDuration: 300 border: 10 desktopNameAlignment: 0 layoutMode: 0 customLayoutRows: 2 usePresentWindows: true coverswitch: animationDuration: 200 animateSwitch: true animateStart: true animateStop: true reflection: true windowTitle:
[Breeze] [Bug 356863] Blur when docked/maximized
https://bugs.kde.org/show_bug.cgi?id=356863 Heiko Tietze <tietze.he...@gmail.com> changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |WORKSFORME --- Comment #4 from Heiko Tietze <tietze.he...@gmail.com> --- "Drop shadow" is the perfect keyword to dig the web and to find this thread https://www.reddit.com/r/kde/comments/2nshc1/panel_shadow_in_plasma_5/ with the solution: |For anyone coming across this thread, this is what worked for me: |(1) xprop -remove _KDE_NET_WM_SHADOW |(2) click the panel from which you want to remove the shadow I'm too lazy to read all the posts about drop shadows but obviously I'm not the only one who dislike this "feature". No idea for what it is good for. So I vote for removing it. -- 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
[Breeze] [Bug 356863] Blur when docked/maximized
https://bugs.kde.org/show_bug.cgi?id=356863 --- Comment #1 from Heiko Tietze <tietze.he...@gmail.com> --- Created attachment 96165 --> https://bugs.kde.org/attachment.cgi?id=96165=edit KMail docked to the (upper) panel KMail docked to the (upper) panel -- 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
[Breeze] [Bug 356863] Blur when docked/maximized
https://bugs.kde.org/show_bug.cgi?id=356863 --- Comment #2 from Heiko Tietze <tietze.he...@gmail.com> --- Created attachment 96166 --> https://bugs.kde.org/attachment.cgi?id=96166=edit KMail free floating KMail free floating -- 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
[kwin] [Bug 356863] Blur when docked/maximized
https://bugs.kde.org/show_bug.cgi?id=356863 Heiko Tietze <tietze.he...@gmail.com> changed: What|Removed |Added Product|Breeze |kwin Component|general |general -- You are receiving this mail because: You are the assignee for the bug. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 125968: WIP: Install .plasmoid file when dropping it onto containment
> On Nov. 5, 2015, 10:31 p.m., Thomas Pfeiffer wrote: > > Nice feature! > > There definitely has to be a way to uninstall a Plasmoid, however. Can't we > > show an uninstall button when hovering over a Plasmoid in the widget > > gallery? > > > > Also, the labeling of the pupop menu when dropping on the desktop is > > unfortunate in general, as it is not self-explanatory at all. > > What are those heading for, anyway? A context menu should only contain only > > action items. > > I know this is a general problem with this menu (which I have not noticed > > yet because apparently I never dropped anything on the desktop recently > > which opens such a menu), but you should start here by just using a single > > entry "Install Wigdet" instead of "Plasma Package" and "Install". > > Heiko Tietze wrote: > It makes sense to use the default context menu for drag operations with > Move, Copy, Link - and Install in case of plasmoids (I wouldn't just disable > this item since it's very rarely used). > > Users might expect to be able having wallpapers installed via drag and > drop and perhaps also ordinary packages. > > The notification text is too long, redundant and not informative. But > that might be the return value from the installation process. > > Kai Uwe Broulik wrote: > > It makes sense to use the default context menu for drag operations with > Move, Copy, Link > > How should that work? Where should the thing end up if I move/copy/link? > If you have a FolderView containment you should get that menu, I think. > > Users might expect to be able having wallpapers installed via drag and > drop and perhaps also ordinary packages. > > At least for wallpapers, I have that planned, also. You can already drop > JPEG files and the like and use them as a wallaper, only makes sense to be > able to drop wallpaper packages as well. Ordinary packages I'd rather not > since we cannot provide this for every package format out there (eg. Kickoff > also only allows to uninstall applications via packagekit iirc) > > But that might be the return value from the installation process. > > It is, I'm hoping for an improved API so I can provide a better error > message. >How should that work? Where should the thing end up if I move/copy/link? The context menu that pops up after drag 'n drop operations should provide the Install additonally. Other operations work like for any other file, i.e. just move/copy/link the .plasmoid file to the desktop, folder view or whatever. - Heiko --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/125968/#review88067 --- On Nov. 5, 2015, 8:23 p.m., Kai Uwe Broulik wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/125968/ > --- > > (Updated Nov. 5, 2015, 8:23 p.m.) > > > Review request for Plasma and KDE Usability. > > > Repository: plasma-framework > > > Description > --- > > This allows to drop a .plasmoid file on a panel or desktop and have it > automatically installed and placed there. > > Video: https://www.youtube.com/watch?v=5MnWnt_u5dU > > > Diffs > - > > src/scriptengines/qml/CMakeLists.txt 2aedf0b > src/scriptengines/qml/plasmoid/containmentinterface.cpp 772031f > > Diff: https://git.reviewboard.kde.org/r/125968/diff/ > > > Testing > --- > > Works, as long as the applet is not yet installed > > 1.) How can I properly check the install status? The docs just say "returns a > KJob allowing to track installation progress". I don't see a way to check for > "applet already installed" (should update existing one if newer?) or > "installation failed". In the former case I just want to add the already > installed applet > > 1a.) btw since we no longer have a tooltip in the widget explorer, there's no > way to uninstall user-installed applets :/ Perhaps a delete button with undo > like in the wallpaper selection should be added > > 2.) How can I get the pluginId of the applet? KPackage::metadata() is > deprecated. Perhaps the KJob should be able to tell me eventually? > > 3.) How can I get the path to the installed package to get the info for 2. > > 4.) Not sure about linking KNotifications here > > 5.) I want an icon for the action :) > > Please disregard the qDebug()s > > > Thanks, > > Kai Uwe Broulik > > ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 125968: WIP: Install .plasmoid file when dropping it onto containment
> On Nov. 5, 2015, 10:31 p.m., Thomas Pfeiffer wrote: > > Nice feature! > > There definitely has to be a way to uninstall a Plasmoid, however. Can't we > > show an uninstall button when hovering over a Plasmoid in the widget > > gallery? > > > > Also, the labeling of the pupop menu when dropping on the desktop is > > unfortunate in general, as it is not self-explanatory at all. > > What are those heading for, anyway? A context menu should only contain only > > action items. > > I know this is a general problem with this menu (which I have not noticed > > yet because apparently I never dropped anything on the desktop recently > > which opens such a menu), but you should start here by just using a single > > entry "Install Wigdet" instead of "Plasma Package" and "Install". It makes sense to use the default context menu for drag operations with Move, Copy, Link - and Install in case of plasmoids (I wouldn't just disable this item since it's very rarely used). Users might expect to be able having wallpapers installed via drag and drop and perhaps also ordinary packages. The notification text is too long, redundant and not informative. But that might be the return value from the installation process. - Heiko --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/125968/#review88067 --- On Nov. 5, 2015, 8:23 p.m., Kai Uwe Broulik wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/125968/ > --- > > (Updated Nov. 5, 2015, 8:23 p.m.) > > > Review request for Plasma and KDE Usability. > > > Repository: plasma-framework > > > Description > --- > > This allows to drop a .plasmoid file on a panel or desktop and have it > automatically installed and placed there. > > Video: https://www.youtube.com/watch?v=5MnWnt_u5dU > > > Diffs > - > > src/scriptengines/qml/CMakeLists.txt 2aedf0b > src/scriptengines/qml/plasmoid/containmentinterface.cpp 772031f > > Diff: https://git.reviewboard.kde.org/r/125968/diff/ > > > Testing > --- > > Works, as long as the applet is not yet installed > > 1.) How can I properly check the install status? The docs just say "returns a > KJob allowing to track installation progress". I don't see a way to check for > "applet already installed" (should update existing one if newer?) or > "installation failed". In the former case I just want to add the already > installed applet > > 1a.) btw since we no longer have a tooltip in the widget explorer, there's no > way to uninstall user-installed applets :/ Perhaps a delete button with undo > like in the wallpaper selection should be added > > 2.) How can I get the pluginId of the applet? KPackage::metadata() is > deprecated. Perhaps the KJob should be able to tell me eventually? > > 3.) How can I get the path to the installed package to get the info for 2. > > 4.) Not sure about linking KNotifications here > > 5.) I want an icon for the action :) > > Please disregard the qDebug()s > > > Thanks, > > Kai Uwe Broulik > > ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 125968: WIP: Install .plasmoid file when dropping it onto containment
> On Nov. 5, 2015, 10:31 p.m., Thomas Pfeiffer wrote: > > Nice feature! > > There definitely has to be a way to uninstall a Plasmoid, however. Can't we > > show an uninstall button when hovering over a Plasmoid in the widget > > gallery? > > > > Also, the labeling of the pupop menu when dropping on the desktop is > > unfortunate in general, as it is not self-explanatory at all. > > What are those heading for, anyway? A context menu should only contain only > > action items. > > I know this is a general problem with this menu (which I have not noticed > > yet because apparently I never dropped anything on the desktop recently > > which opens such a menu), but you should start here by just using a single > > entry "Install Wigdet" instead of "Plasma Package" and "Install". > > Heiko Tietze wrote: > It makes sense to use the default context menu for drag operations with > Move, Copy, Link - and Install in case of plasmoids (I wouldn't just disable > this item since it's very rarely used). > > Users might expect to be able having wallpapers installed via drag and > drop and perhaps also ordinary packages. > > The notification text is too long, redundant and not informative. But > that might be the return value from the installation process. > > Kai Uwe Broulik wrote: > > It makes sense to use the default context menu for drag operations with > Move, Copy, Link > > How should that work? Where should the thing end up if I move/copy/link? > If you have a FolderView containment you should get that menu, I think. > > Users might expect to be able having wallpapers installed via drag and > drop and perhaps also ordinary packages. > > At least for wallpapers, I have that planned, also. You can already drop > JPEG files and the like and use them as a wallaper, only makes sense to be > able to drop wallpaper packages as well. Ordinary packages I'd rather not > since we cannot provide this for every package format out there (eg. Kickoff > also only allows to uninstall applications via packagekit iirc) > > But that might be the return value from the installation process. > > It is, I'm hoping for an improved API so I can provide a better error > message. > > Heiko Tietze wrote: > >How should that work? Where should the thing end up if I move/copy/link? > > The context menu that pops up after drag 'n drop operations should > provide the Install additonally. Other operations work like for any other > file, i.e. just move/copy/link the .plasmoid file to the desktop, folder view > or whatever. > > Marco Martin wrote: > if the desktop is a folderview, yes. > on a normal desktop or on a panel the move/copy/link operations don't > apply since there isn't anywhere to copy/move to Sure, there it has to be only one context menu too with create a note, an icon (which is just a shortcut, right?), and install (if it is a plasmoid). BTW: this context menu should be harmonized with the default; the header is strange. - Heiko --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/125968/#review88067 --- On Nov. 5, 2015, 8:23 p.m., Kai Uwe Broulik wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/125968/ > --- > > (Updated Nov. 5, 2015, 8:23 p.m.) > > > Review request for Plasma and KDE Usability. > > > Repository: plasma-framework > > > Description > --- > > This allows to drop a .plasmoid file on a panel or desktop and have it > automatically installed and placed there. > > Video: https://www.youtube.com/watch?v=5MnWnt_u5dU > > > Diffs > - > > src/scriptengines/qml/CMakeLists.txt 2aedf0b > src/scriptengines/qml/plasmoid/containmentinterface.cpp 772031f > > Diff: https://git.reviewboard.kde.org/r/125968/diff/ > > > Testing > --- > > Works, as long as the applet is not yet installed > > 1.) How can I properly check the install status? The docs just say "returns a > KJob allowing to track installation progress". I don't see a way to check for > "applet already installed" (should update existing one if newer?) or > "installation failed". In the former case I just want to add the already > installed applet > > 1a.) btw since we no longer have a
Re: Review Request 124675: Fix Bug 311991 - Taskbar buttons for minimized apps should not use disabled state
> On Oct. 25, 2015, 10:05 p.m., Thomas Pfeiffer wrote: > > As always: If you want design or usability input, please provide a > > screenshot. We cannot read the code. Thanks. > > Eike Hein wrote: > Thomas, all this does is not grey out the text in Task Manager button > labels when a window is minimized. See also the long discussion in the > referenced bug ticket. > > Thomas Pfeiffer wrote: > Thanks, I just wanted to make sure what it specifically does. > In that case, I am against the patch as it is. There should be some way > of distinguishing minimized from non-minimized tasks. > I agree with the problem, but I do not agree with the solution. > > Would it be possible to instead of hardcoded greying-out (which I also > agree is not the right representation, because greying out is reserved for > disabled controls) allow the Plasma theme to define the visual representation? > In the Breeze theme, it would make sense (as suggested in the bug thread) > to use a different color for the highlight bar instead of changing the > representation of the task. Other themes might choose differen > representations, or just don't distinguish them at all. > > Heiko Tietze wrote: > Other solutions: size (e.g. make the button smaller), text (brackets for > instance), position (special area outside the normal task bar), subtile grey > out (icon only), or add some decorator to the icon. The color might work well > - and would probably be the easiest way, but I'm afraid of the desire to show > more states like maximized, docked, active, different virtual screen etc. > with the need to remember all the colors. Personally I'd like the position > very much since minimizing a window means to not include it into the > workflow, more or less. It's like the most missing feature of minimizing into > tray. However that would be quite a big change. > > Eike Hein wrote: > Changing size or position is jarring because it causes a lot of movement > on the bar. Desaturating the icon is unpopular with users too, since the > color information is desired to recognize an icon quickly. > > Christoph Feck wrote: > If I understand the bug report correctly, the issue was with the icon > only, so the text graying could be kept, and the icon graying removed. > > Gregor Mi wrote: > See e.g. comment 33 "Faded text and colours makes this difficult". So it > is also about the text. > > Martin Klapetek wrote: > Fwiw, I, as an ordinary user, do not see any difference between the > window being minimalized and the window not being on top (active window). My > laptop screen is small~ish (13") and I always work in maximized windows. > Therefore, representing the minimized state in the taskbar in any way bears > absolutely no value for me, because if I want to swtich to any other window, > it makes no difference if it just moves in the stack of visible windows or if > the window is unminimized. The goal is to get the window to the top/make it > an active window, I do not care where it comes from. Or, more importantly, I > do not need to care. > > Have we considered a usecase like that? I kind of question the whole > usefulness of representing the minimized state, switching to it makes no > difference besides the unminimizing animation, it just makes it harder to > find. I mean, I've never looked at the taskbar searching Konsole and thought > to myself "ah right, Konsole is now minimized, so now what?". What would our > personas do? Why is it so important to be able to tell if the window is > minimized or not? > > Eli MacKenzie wrote: > My own use-case for a visible minimized state is as a flag. As far as I > know there is no means to associate arbitrary data to a taskbar entry, so > I'll minimize a window when it is "flagged". For example, if a browser window > stays minimized "too long" I'll know I have to go bookmark some of its tabs > and close it. I tend to remain logged in for months at a time. > > FWIW I have a 24" 16:10 monitor and use maximized windows. > > Gregor Mi wrote: > Thanks for the input. If I may summarize: we have the ordinary user view > vs. the power user view: > - For the ordinary (or impaired) user a long-outstanding issue would be > fixed. > - The power user would like to keep a feature to be enabled by default. > How will this be moderated? Simplest solution is to accept your patch (aka opt-in the minimized state). Ship it. - Heiko --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.or
Re: Review Request 124675: Fix Bug 311991 - Taskbar buttons for minimized apps should not use disabled state
> On Oct. 25, 2015, 10:05 p.m., Thomas Pfeiffer wrote: > > As always: If you want design or usability input, please provide a > > screenshot. We cannot read the code. Thanks. > > Eike Hein wrote: > Thomas, all this does is not grey out the text in Task Manager button > labels when a window is minimized. See also the long discussion in the > referenced bug ticket. > > Thomas Pfeiffer wrote: > Thanks, I just wanted to make sure what it specifically does. > In that case, I am against the patch as it is. There should be some way > of distinguishing minimized from non-minimized tasks. > I agree with the problem, but I do not agree with the solution. > > Would it be possible to instead of hardcoded greying-out (which I also > agree is not the right representation, because greying out is reserved for > disabled controls) allow the Plasma theme to define the visual representation? > In the Breeze theme, it would make sense (as suggested in the bug thread) > to use a different color for the highlight bar instead of changing the > representation of the task. Other themes might choose differen > representations, or just don't distinguish them at all. Other solutions: size (e.g. make the button smaller), text (brackets for instance), position (special area outside the normal task bar), subtile grey out (icon only), or add some decorator to the icon. The color might work well - and would probably be the easiest way, but I'm afraid of the desire to show more states like maximized, docked, active, different virtual screen etc. with the need to remember all the colors. Personally I'd like the position very much since minimizing a window means to not include it into the workflow, more or less. It's like the most missing feature of minimizing into tray. However that would be quite a big change. - Heiko --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/124675/#review87384 --- On Oct. 23, 2015, 11:16 a.m., Gregor Mi wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/124675/ > --- > > (Updated Oct. 23, 2015, 11:16 a.m.) > > > Review request for Plasma, KDE Usability and Jens Reuterberg. > > > 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: Review Request 125678: Introduce User Switcher plasmoid
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/125678/#review87305 --- Ship it! Ship It! - Heiko Tietze On Oct. 19, 2015, 9:22 p.m., Kai Uwe Broulik wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/125678/ > --- > > (Updated Oct. 19, 2015, 9:22 p.m.) > > > Review request for Plasma and KDE Usability. > > > Repository: kdeplasma-addons > > > Description > --- > > It is prety common in other desktop environments to have something that > allows switching between users and logout/shutdown quickly. It is inspired by > the Fast User Switch plasmoid from kde-apps.org [1] > > [1] http://kde-apps.org/content/show.php?content=127462 > > > Diffs > - > > applets/CMakeLists.txt 4079726 > applets/userswitcher/CMakeLists.txt PRE-CREATION > applets/userswitcher/Messages.sh PRE-CREATION > applets/userswitcher/package/contents/config/config.qml PRE-CREATION > applets/userswitcher/package/contents/config/main.xml PRE-CREATION > applets/userswitcher/package/contents/ui/ListDelegate.qml PRE-CREATION > applets/userswitcher/package/contents/ui/configGeneral.qml PRE-CREATION > applets/userswitcher/package/contents/ui/main.qml PRE-CREATION > applets/userswitcher/package/metadata.desktop PRE-CREATION > > Diff: https://git.reviewboard.kde.org/r/125678/diff/ > > > Testing > --- > > When the applet opens, it updates. It grows a maximum of half the screen > height, should there be more users currently logged in, the list can be > scrolled. Switching users works, both with and without locking the screen, > depending on user's settings. Opening new sessions, locking the screen and > shutting down also work. > > The applet doesn't have any settings, the label probably needs tweaking so > its sizing policy is similar to the digital clock so the two look reasonable > next to each other. > > > File Attachments > > > Plasmoid in action > > https://git.reviewboard.kde.org/media/uploaded/files/2015/10/17/05d93363-9b15-4c77-abe0-6f8ed9b3cab7__userswitcherplasmoid3.png > Applet in larger panel and desktop > > https://git.reviewboard.kde.org/media/uploaded/files/2015/10/19/49290a8d-8ce3-4ab4-89a8-76990ca73084__userswitcherplasmoid4.png > Applet settings > > https://git.reviewboard.kde.org/media/uploaded/files/2015/10/19/704a5450-2aa9-4250-92a8-6deed29ac859__userswitcherplasmoid5.png > > > Thanks, > > Kai Uwe Broulik > > ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 125678: Introduce User Switcher plasmoid
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/125678/#review87099 --- Someone asked on the mailing list to keep the user icon. Agreed (having disabled people in mind), but please optional and disabled by default. - Heiko Tietze On Oct. 17, 2015, 6:11 p.m., Kai Uwe Broulik wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/125678/ > --- > > (Updated Oct. 17, 2015, 6:11 p.m.) > > > Review request for Plasma and KDE Usability. > > > Repository: kdeplasma-addons > > > Description > --- > > It is prety common in other desktop environments to have something that > allows switching between users and logout/shutdown quickly. It is inspired by > the Fast User Switch plasmoid from kde-apps.org [1] > > [1] http://kde-apps.org/content/show.php?content=127462 > > > Diffs > - > > applets/userswitcher/package/metadata.desktop PRE-CREATION > applets/userswitcher/package/contents/ui/main.qml PRE-CREATION > applets/userswitcher/package/contents/ui/ListDelegate.qml PRE-CREATION > applets/userswitcher/Messages.sh PRE-CREATION > applets/CMakeLists.txt 4079726 > applets/userswitcher/CMakeLists.txt PRE-CREATION > > Diff: https://git.reviewboard.kde.org/r/125678/diff/ > > > Testing > --- > > When the applet opens, it updates. It grows a maximum of half the screen > height, should there be more users currently logged in, the list can be > scrolled. Switching users works, both with and without locking the screen, > depending on user's settings. Opening new sessions, locking the screen and > shutting down also work. > > The applet doesn't have any settings, the label probably needs tweaking so > its sizing policy is similar to the digital clock so the two look reasonable > next to each other. > > > File Attachments > > > Plasmoid in action > > https://git.reviewboard.kde.org/media/uploaded/files/2015/10/17/05d93363-9b15-4c77-abe0-6f8ed9b3cab7__userswitcherplasmoid3.png > > > Thanks, > > Kai Uwe Broulik > > ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 125678: Introduce User Switcher plasmoid
> On Oct. 18, 2015, 9:26 a.m., Heiko Tietze wrote: > > Nice user switcher. Question is whether or not the user icon is to show in > > the panel (clutters IMHO, so done right) and what happens when you click > > one of the global functions. The Lock/Logout plasmoid shows a confirmation > > bar with reboot, shut down, and log out (the latter enabled by default). Is > > this bar shown for leave? And actually I'd rather keep plasmoids simple and > > remove all features that are not directly related to user sessions. So it > > should be taken into consideration to remove Lock and Leave... (maybe add > > just logout). > > > > And last but not least you could think about the sort order. If there are > > really more than one instance of the same user as in your screenshot, the > > current user may want to switch between own instances. > > > > PS: New users may expect such a dialog for activities. Does mixing sessions > > and activities make sense? > > Kai Uwe Broulik wrote: > > Question is whether or not the user icon is to show in the panel > > I was thinking about it but decided against it because, yes, it clutters > it. > > Is this bar shown for leave? > > Yes, pressing "Leave..." will open the Shutdown/Reboot/Logout dialog, > that part is actually taken from the lock logout applet :) > > not directly related to user sessions > > Locking the screen and logging off is related to the *current* session. > > remove Lock and Leave... > > I don't think telling someone "if you want to switch to the other user, > click here, but if you want to just log out or lock the screen, click here, > here, and here" (kickoff menu eg) > > If there are really more than one instance of the same user as in your > screenshot, the current user may want to switch between own instances > > Makes sense, ie. sort the current user's sessions first, then the rest > alphabetically? Or by VT (F1, F2, ..)? However, the sort order is not > determined by the plasmoid but the separate model (Review 124980) and would > (eventually) affect the regular user switcher and the one on the lock screen. | Yes, pressing "Leave..." will open the Shutdown/Reboot/Logout dialog, that part is actually taken from the lock logout applet :) OT: This confirmation bar shows "logout" (not "leave") by default, even when I clicked shutdown in the refering plasmoid. Waiting for other replies... - Heiko --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/125678/#review87002 --- On Oct. 17, 2015, 6:11 p.m., Kai Uwe Broulik wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/125678/ > --- > > (Updated Oct. 17, 2015, 6:11 p.m.) > > > Review request for Plasma and KDE Usability. > > > Repository: kdeplasma-addons > > > Description > --- > > It is prety common in other desktop environments to have something that > allows switching between users and logout/shutdown quickly. It is inspired by > the Fast User Switch plasmoid from kde-apps.org [1] > > [1] http://kde-apps.org/content/show.php?content=127462 > > > Diffs > - > > applets/userswitcher/package/metadata.desktop PRE-CREATION > applets/userswitcher/package/contents/ui/main.qml PRE-CREATION > applets/userswitcher/package/contents/ui/ListDelegate.qml PRE-CREATION > applets/userswitcher/Messages.sh PRE-CREATION > applets/CMakeLists.txt 4079726 > applets/userswitcher/CMakeLists.txt PRE-CREATION > > Diff: https://git.reviewboard.kde.org/r/125678/diff/ > > > Testing > --- > > When the applet opens, it updates. It grows a maximum of half the screen > height, should there be more users currently logged in, the list can be > scrolled. Switching users works, both with and without locking the screen, > depending on user's settings. Opening new sessions, locking the screen and > shutting down also work. > > The applet doesn't have any settings, the label probably needs tweaking so > its sizing policy is similar to the digital clock so the two look reasonable > next to each other. > > > File Attachments > > > Plasmoid in action > > https://git.reviewboard.kde.org/media/uploaded/files/2015/10/17/05d93363-9b15-4c77-abe0-6f8ed9b3cab7__userswitcherplasmoid3.png > > > Thanks, > > Kai Uwe Broulik > > ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 125678: Introduce User Switcher plasmoid
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/125678/#review87002 --- Nice user switcher. Question is whether or not the user icon is to show in the panel (clutters IMHO, so done right) and what happens when you click one of the global functions. The Lock/Logout plasmoid shows a confirmation bar with reboot, shut down, and log out (the latter enabled by default). Is this bar shown for leave? And actually I'd rather keep plasmoids simple and remove all features that are not directly related to user sessions. So it should be taken into consideration to remove Lock and Leave... (maybe add just logout). And last but not least you could think about the sort order. If there are really more than one instance of the same user as in your screenshot, the current user may want to switch between own instances. PS: New users may expect such a dialog for activities. Does mixing sessions and activities make sense? - Heiko Tietze On Oct. 17, 2015, 6:11 p.m., Kai Uwe Broulik wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/125678/ > --- > > (Updated Oct. 17, 2015, 6:11 p.m.) > > > Review request for Plasma and KDE Usability. > > > Repository: kdeplasma-addons > > > Description > --- > > It is prety common in other desktop environments to have something that > allows switching between users and logout/shutdown quickly. It is inspired by > the Fast User Switch plasmoid from kde-apps.org [1] > > [1] http://kde-apps.org/content/show.php?content=127462 > > > Diffs > - > > applets/userswitcher/package/metadata.desktop PRE-CREATION > applets/userswitcher/package/contents/ui/main.qml PRE-CREATION > applets/userswitcher/package/contents/ui/ListDelegate.qml PRE-CREATION > applets/userswitcher/Messages.sh PRE-CREATION > applets/CMakeLists.txt 4079726 > applets/userswitcher/CMakeLists.txt PRE-CREATION > > Diff: https://git.reviewboard.kde.org/r/125678/diff/ > > > Testing > --- > > When the applet opens, it updates. It grows a maximum of half the screen > height, should there be more users currently logged in, the list can be > scrolled. Switching users works, both with and without locking the screen, > depending on user's settings. Opening new sessions, locking the screen and > shutting down also work. > > The applet doesn't have any settings, the label probably needs tweaking so > its sizing policy is similar to the digital clock so the two look reasonable > next to each other. > > > File Attachments > > > Plasmoid in action > > https://git.reviewboard.kde.org/media/uploaded/files/2015/10/17/05d93363-9b15-4c77-abe0-6f8ed9b3cab7__userswitcherplasmoid3.png > > > Thanks, > > Kai Uwe Broulik > > ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 125061: Moved indexing checkbox to the top of the KCM
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/125061/#review84901 --- The design does not fit the (preliminary) KCM guidelines [1] and has a questionale workflow as Vishesh commented wrt. the checkbox plus the stacked lists are not a common design. To solve the problkem I'm thinking about using the awesome filelight graph to visualize folders with the option to exclude (grey out) section. Just as the basic idea. Opinions? My review is based on http://i.imgur.com/RBWxutv.png [1] https://community.kde.org/KDE_Visual_Design_Group/System_Settings_Application - Heiko Tietze On Sept. 5, 2015, 8:03 nachm., Ovidiu-Florin BOGDAN wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/125061/ > --- > > (Updated Sept. 5, 2015, 8:03 nachm.) > > > Review request for Plasma and KDE Usability. > > > Repository: plasma-desktop > > > Description > --- > > IMHO this way it is more logical. > > > Diffs > - > > kcms/baloo/configwidget.ui 512e4a5 > > Diff: https://git.reviewboard.kde.org/r/125061/diff/ > > > Testing > --- > > > Thanks, > > Ovidiu-Florin BOGDAN > > ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 124585: Add pretty user switcher
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/124585/#review83339 --- I would rather add a distict button for new session. But anyway please check the keyboard access. The current screen needs tab to switch between buttons (with tab between) and sessions (and arrow keys there) whereas the default log screen navigates with just left/right (and focuses the password input if relevant). And I wonder what happens when you have more sessions/users as can be shown on one screen. My expecxtation is some kind of chevron to indicate that there is more and to scroll through the list. - Heiko Tietze On Aug. 1, 2015, 10:38 nachm., Kai Uwe Broulik wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/124585/ --- (Updated Aug. 1, 2015, 10:38 nachm.) Review request for Plasma and KDE Usability. Repository: plasma-workspace Description --- This adds a user switcher dialog borrowing elements from the lock screen and log out dialog. I never understood why KRunner was used for that. It is not yet hooked up to the system (would make KRunner's switchUser interface forward that to KSMServer so everybody using it (eg. kickoff) would continue to work without adjustments). To test it run qdbus org.kde.ksmserver /KSMServer openSwitchUserDialog When it opens it defaults to New Session, from an interaction POV the list view behaves like the one on the lock screen. It locks the screen when switching users only when the user has enabled the lock screen (might need a separate option for that?) That unconditional locking on session switching has turned out to be a major annoyance. Diffs - ksmserver/CMakeLists.txt a0c8852 ksmserver/org.kde.KSMServerInterface.xml 3680ed7 ksmserver/server.h 2176aa1 ksmserver/server.cpp b73b792 ksmserver/switchuserdialog.h PRE-CREATION ksmserver/switchuserdialog.cpp PRE-CREATION lookandfeel/contents/components/UserList.qml 778d8ea lookandfeel/contents/components/UserSelect.qml 007a118 lookandfeel/contents/userswitcher/UserSwitcher.qml e69de29 Diff: https://git.reviewboard.kde.org/r/124585/diff/ Testing --- Looks pretty, switching to a new or existing session works. Btw, weren't we able to click outside the dialog to dismiss it in 4.x? Seems broken for the logout dialog as well. File Attachments User switcher https://git.reviewboard.kde.org/media/uploaded/files/2015/08/01/03dc2669-bee4-43a5-be11-350ba72417a6__fancyswitchuser1.jpg User switcher with icons https://git.reviewboard.kde.org/media/uploaded/files/2015/08/01/bb4d5a64-2ac5-4f61-9fd7-38d222a1f74f__fancyswitchuser2.jpg Thanks, Kai Uwe Broulik ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 124485: Add missing traffic monitor
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/124485/#review83033 --- Ship it! Why are the graphs such unrealistic shaped? Looks like heavy filtering. If Thomas and Jens granted usability I will check the ship it here. But please discuss also the scaling method. When it is adopted to the current speed the actual graph is not really informative; if the y-axis' scaling is fix to the max. bandwidth it might be a problem in case of other bottlenecks. I suggest to (optionally) scale by the max measured value therefore. - Heiko Tietze On Juli 27, 2015, 10:17 vorm., Jan Grulich wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/124485/ --- (Updated Juli 27, 2015, 10:17 vorm.) Review request for Network Management, Plasma and KDE Usability. Bugs: 268022 http://bugs.kde.org/show_bug.cgi?id=268022 Repository: plasma-nm Description --- See summary. Diffs - applet/contents/ui/ConnectionItem.qml ff722a7 Diff: https://git.reviewboard.kde.org/r/124485/diff/ Testing ---  Thanks, Jan Grulich ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 124449: [digital-clock] Introduce new layouting state for small panels
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/124449/#review82890 --- Ship it! Yes, the pipe is less obtrusive and well-known as separator. Nice solution. - Heiko Tietze On Juli 24, 2015, 10:27 vorm., Martin Klapetek wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/124449/ --- (Updated Juli 24, 2015, 10:27 vorm.) Review request for Plasma and KDE Usability. Bugs: 348072 https://bugs.kde.org/show_bug.cgi?id=348072 Repository: plasma-workspace Description --- One of the most reported bugs wrt digital clock is that the second line text (date or timezone) is unreadable on small panels so this adds new state to the clock applet that lays things horizontally when the panel is too small to show text with the small font (set in system settings). When there is a date displayed, a delimiter is put in between to allow easier and faster spotting the time (as on a first glance there is just a bunch of numbers, so quickly orienteering is super important). I used the dot symbol first but then went for pipe which I think looks more clean; see screenshots for comparison. I've made a quick video showing the state changes, see https://www.youtube.com/watch?v=t7w0k8H22h4 - it shows the bullet delimiter and a bit wrong spacing which is now fixed. Diffs - applets/digital-clock/package/contents/ui/DigitalClock.qml 9506078 Diff: https://git.reviewboard.kde.org/r/124449/diff/ Testing --- Everything works as it used and now with small panel things are layed horizontally, see video above. File Attachments Delimiters https://git.reviewboard.kde.org/media/uploaded/files/2015/07/24/e0aa0799-ca56-4bdb-b4e6-b8db6622ff10__clock-delimiters.png Thanks, Martin Klapetek ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 124409: Begin fading the OSD immediately
On Juli 21, 2015, 7:03 vorm., Heiko Tietze wrote: Nice presentation, as always. But I'm not so sure that the realization of fading out quickly meets the needs from 'OSD is disturbing'. The second when the OSD is shown is still annoying (interaction during the fading might restart) and those who want to 'read' it need to reactivate the OSD. The issue could be solved by some kind of 'dismiss' or 'don't show again' interaction. Another simple way is to hide immediately on any key down, on mouse click etc. If that all is not possible at the OSD itself, perhaps because of security issues, a dialog (KCM) could help. And last but least please consider to bind this feature to activities. Martin Gräßlin wrote: Another simple way is to hide immediately on any key down, on mouse click etc. If that all is not possible at the OSD itself, perhaps because of security issues For technical reasons the OSD is not able to recognize any (global) key or mouse click events on Wayland and on X11 only with a huge amount of nasty code. Also I don't think that this is a solution to the annoying - if I watch a video and change the volume through kdeconnect I don't have a keyboard. Anyway I would dismiss the annoying argument all together. If I compare to the amount of OSDs my TV, audio receiver is putting on the screen this is a really good OSD. Martin Klapetek wrote: The second when the OSD is shown is still annoying and those who want to 'read' it need to reactivate the OSD I'm confused by that - does that say that the second it is on display is too much (annoying) but not enough to read it? Can you perhaps file a bug and specify exactly what is annoying and we can discuss over there? I tried to point out that we have two goals here: read information and don't disturb. In case of volume the feedback as position on the slider (or kind of progress bar) is perceived in milliseconds but when you got an email you might want to read sender and subject. And if the user is elder it might take more time to grasp what happens. - Heiko --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/124409/#review82745 --- On Juli 20, 2015, 8:19 nachm., Kai Uwe Broulik wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/124409/ --- (Updated Juli 20, 2015, 8:19 nachm.) Review request for Plasma and KDE Usability. Repository: plasma-workspace Description --- This makes the OSD begin fading out over a long period of time immediately after it has shown. Makes the OSD less annoying while currently reading something or watching a video. See https://www.youtube.com/watch?v=HxmpwG-2saE Diffs - lookandfeel/contents/osd/Osd.qml 2288ec1 shell/osd.cpp 0573d51 Diff: https://git.reviewboard.kde.org/r/124409/diff/ Testing --- Works. Quite enjoyable. As suggested by mklapetek Thanks, Kai Uwe Broulik ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 124409: Begin fading the OSD immediately
On Juli 21, 2015, 7:03 vorm., Heiko Tietze wrote: Nice presentation, as always. But I'm not so sure that the realization of fading out quickly meets the needs from 'OSD is disturbing'. The second when the OSD is shown is still annoying (interaction during the fading might restart) and those who want to 'read' it need to reactivate the OSD. The issue could be solved by some kind of 'dismiss' or 'don't show again' interaction. Another simple way is to hide immediately on any key down, on mouse click etc. If that all is not possible at the OSD itself, perhaps because of security issues, a dialog (KCM) could help. And last but least please consider to bind this feature to activities. Martin Gräßlin wrote: Another simple way is to hide immediately on any key down, on mouse click etc. If that all is not possible at the OSD itself, perhaps because of security issues For technical reasons the OSD is not able to recognize any (global) key or mouse click events on Wayland and on X11 only with a huge amount of nasty code. Also I don't think that this is a solution to the annoying - if I watch a video and change the volume through kdeconnect I don't have a keyboard. Anyway I would dismiss the annoying argument all together. If I compare to the amount of OSDs my TV, audio receiver is putting on the screen this is a really good OSD. Martin Klapetek wrote: The second when the OSD is shown is still annoying and those who want to 'read' it need to reactivate the OSD I'm confused by that - does that say that the second it is on display is too much (annoying) but not enough to read it? Can you perhaps file a bug and specify exactly what is annoying and we can discuss over there? Heiko Tietze wrote: I tried to point out that we have two goals here: read information and don't disturb. In case of volume the feedback as position on the slider (or kind of progress bar) is perceived in milliseconds but when you got an email you might want to read sender and subject. And if the user is elder it might take more time to grasp what happens. Martin Klapetek wrote: Ah, you're getting confused OSD with notifications. This does not apply to notifications at all, this is only the volume/brigthness/etc changes. If you limit the scope to very simple notification the solution might be okay (personally I fully agree with the faster the better). But didn't Martin Graesslin blog about what kind of OSD should be shown on the lock screen including the idea of email like on Android? What's about the information of time left watching a video, perhaps after you forward a few seconds via KDEConnect? - Heiko --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/124409/#review82745 --- On Juli 20, 2015, 8:19 nachm., Kai Uwe Broulik wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/124409/ --- (Updated Juli 20, 2015, 8:19 nachm.) Review request for Plasma and KDE Usability. Repository: plasma-workspace Description --- This makes the OSD begin fading out over a long period of time immediately after it has shown. Makes the OSD less annoying while currently reading something or watching a video. See https://www.youtube.com/watch?v=HxmpwG-2saE Diffs - lookandfeel/contents/osd/Osd.qml 2288ec1 shell/osd.cpp 0573d51 Diff: https://git.reviewboard.kde.org/r/124409/diff/ Testing --- Works. Quite enjoyable. As suggested by mklapetek Thanks, Kai Uwe Broulik ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 124409: Begin fading the OSD immediately
On Juli 21, 2015, 7:03 vorm., Heiko Tietze wrote: Nice presentation, as always. But I'm not so sure that the realization of fading out quickly meets the needs from 'OSD is disturbing'. The second when the OSD is shown is still annoying (interaction during the fading might restart) and those who want to 'read' it need to reactivate the OSD. The issue could be solved by some kind of 'dismiss' or 'don't show again' interaction. Another simple way is to hide immediately on any key down, on mouse click etc. If that all is not possible at the OSD itself, perhaps because of security issues, a dialog (KCM) could help. And last but least please consider to bind this feature to activities. Martin Gräßlin wrote: Another simple way is to hide immediately on any key down, on mouse click etc. If that all is not possible at the OSD itself, perhaps because of security issues For technical reasons the OSD is not able to recognize any (global) key or mouse click events on Wayland and on X11 only with a huge amount of nasty code. Also I don't think that this is a solution to the annoying - if I watch a video and change the volume through kdeconnect I don't have a keyboard. Anyway I would dismiss the annoying argument all together. If I compare to the amount of OSDs my TV, audio receiver is putting on the screen this is a really good OSD. Martin Klapetek wrote: The second when the OSD is shown is still annoying and those who want to 'read' it need to reactivate the OSD I'm confused by that - does that say that the second it is on display is too much (annoying) but not enough to read it? Can you perhaps file a bug and specify exactly what is annoying and we can discuss over there? Heiko Tietze wrote: I tried to point out that we have two goals here: read information and don't disturb. In case of volume the feedback as position on the slider (or kind of progress bar) is perceived in milliseconds but when you got an email you might want to read sender and subject. And if the user is elder it might take more time to grasp what happens. Martin Klapetek wrote: Ah, you're getting confused OSD with notifications. This does not apply to notifications at all, this is only the volume/brigthness/etc changes. Heiko Tietze wrote: If you limit the scope to very simple notification the solution might be okay (personally I fully agree with the faster the better). But didn't Martin Graesslin blog about what kind of OSD should be shown on the lock screen including the idea of email like on Android? What's about the information of time left watching a video, perhaps after you forward a few seconds via KDEConnect? Martin Gräßlin wrote: This is not about lock screen. Email notification on a lock screen needs a completely different solution than OSD. Martin Klapetek wrote: The OSD currently does four things and four things only - it shows up on volume change, screen brigthness change, keyboard brightness change and keyboard layout change. Everything else is a notification, which is the small bubble in bottom-left part of the screen and is different in every possible aspect than the OSD, which is what this patch adjusts. Okay, thanks for clarification. - Heiko --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/124409/#review82745 --- On Juli 20, 2015, 8:19 nachm., Kai Uwe Broulik wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/124409/ --- (Updated Juli 20, 2015, 8:19 nachm.) Review request for Plasma and KDE Usability. Repository: plasma-workspace Description --- This makes the OSD begin fading out over a long period of time immediately after it has shown. Makes the OSD less annoying while currently reading something or watching a video. See https://www.youtube.com/watch?v=HxmpwG-2saE Diffs - lookandfeel/contents/osd/Osd.qml 2288ec1 shell/osd.cpp 0573d51 Diff: https://git.reviewboard.kde.org/r/124409/diff/ Testing --- Works. Quite enjoyable. As suggested by mklapetek Thanks, Kai Uwe Broulik ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 124246: Improve sticky notes
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/124246/#review82080 --- Didn't test the workflow so just about the screenshot. Alignment looks somewhat strange. According https://techbase.kde.org/Projects/Usability/HIG/Alignment the right position is left for the longest label and all other to its right edge. Furthermore the checkbox as introduction to the function is weird. If non-custom means black you could simply omit the checkbox. Probably you adjust b/w in respect to the background. Hence the color would rather fit an indented child below the checkbox. I wonder why font size and color can be set but no other option. Either it's too much (who needs to set color to green or change the default font) or not enough (why not have comic font). - Heiko Tietze On Juli 4, 2015, 11:43 vorm., Kai Uwe Broulik wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/124246/ --- (Updated Juli 4, 2015, 11:43 vorm.) Review request for Plasma and KDE Usability. Repository: kdeplasma-addons Description --- This patch adds the following improvements to the sticky notes applet: - A config dialog with previews of the individual colors, the ability to change the font size, and font color - are there any other important options the 4.x one had? - Ctrl+Mousewheel to change font size, I always used this feature in 4.x and was disappointed that it would not actually save the font size - Focus the input field when expanding the applet (eg. when it is in a panel, click the note, start typing) - Drag and drop support so you can now drag files and text snippets into the sticky note - Better keyboard navigation: you can now place a sticky note in your panel, assign a shortcut to it, press it, note down your thoughts, and close the note again Diffs - applets/notes/package/contents/config/config.qml PRE-CREATION applets/notes/package/contents/config/main.xml 596dfc0 applets/notes/package/contents/ui/configAppearance.qml PRE-CREATION applets/notes/package/contents/ui/main.qml 1f1022c applets/notes/plugin/documenthandler.h 41cf704 applets/notes/plugin/documenthandler.cpp 79c276e Diff: https://git.reviewboard.kde.org/r/124246/diff/ Testing --- Changing the font size from the config dialog and mousewheeling seems to work without screwing up your existing formatting. Unfortunately the config dialog is quite difficult to get to since right clicking the text area yields the standard copy/paste menu and I failed to manually add another item for the applet config there File Attachments Config dialog https://git.reviewboard.kde.org/media/uploaded/files/2015/07/04/1d244f32-79e6-435c-a906-1acddede0aa3__stickylove3.png Thanks, Kai Uwe Broulik ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 124234: Add option to always show all system tray icons
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/124234/#review82024 --- Nice addition. I was checking if users are able to realize the setting - and it is obvious since the drop down is hidden. However the layout of the checkbox is not really nice. Add more space to the details below and indent the siblings. Maybe it's worth to think about an alternativ text to allow accordance with the configurability of the dropdowns. E.g. 'Personalized tray icons', and enable/checked means you can change the details below. - Heiko Tietze On Juli 2, 2015, 9:23 nachm., Kai Uwe Broulik wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/124234/ --- (Updated Juli 2, 2015, 9:23 nachm.) Review request for Plasma and KDE Usability. Bugs: 349812 https://bugs.kde.org/show_bug.cgi?id=349812 Repository: plasma-workspace Description --- This adds an option to always show all system tray icons and never collapse them into the popup. I've seen a couple of people already requesting this. Diffs - applets/systemtray/package/contents/config/main.xml 8e8996c applets/systemtray/package/contents/ui/ConfigEntries.qml 8b6ec28 applets/systemtray/package/contents/ui/TaskDelegate.qml 221c6e7 applets/systemtray/package/contents/ui/main.qml e794d1c applets/systemtray/plugin/host.h bd9728b applets/systemtray/plugin/host.cpp 5c897fa Diff: https://git.reviewboard.kde.org/r/124234/diff/ Testing --- Enabled and disabled the option and tray icons along with the arrow came and went, started music player and media controller properly appeared and disappeared, started and quit KMail and its icon properla appeared and disappeared with both options. File Attachments Settings dialog (disabled) https://git.reviewboard.kde.org/media/uploaded/files/2015/07/02/50ae2a2e-8052-4d87-85c3-5ad8aa1da1f4__trayalways_dialog.png Settings dialog (enabled) https://git.reviewboard.kde.org/media/uploaded/files/2015/07/02/d79b67e9-9950-4fb7-97a9-b89b93caeeb7__trayalways_dialogenabled.png System Tray (disabled) https://git.reviewboard.kde.org/media/uploaded/files/2015/07/02/1b122131-88b0-410c-8532-8dbb74cad5db__trayalways_disabled.png System Tray (enabled) https://git.reviewboard.kde.org/media/uploaded/files/2015/07/02/3668a352-65c1-4d34-94d8-bc7141ce784e__trayalways_enabled.png Better dialog layout https://git.reviewboard.kde.org/media/uploaded/files/2015/07/02/cf2a921d-a4e3-4e94-b19d-3c6b0d3f3335__trayalways_dialogbetter.png Dim System Tray https://git.reviewboard.kde.org/media/uploaded/files/2015/07/02/57d2c759-97f8-4c44-9f00-c08558de9a9d__trayalways_passive.png Thanks, Kai Uwe Broulik ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 124037: Allow to cancel critical battery timer
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/124037/#review81330 --- Simple cancel without a countdown makes not much sense. Do I have bone-breaking 10sec or more? Or is it the small progressbar right hand? It would be good to have some text as well. By the way: ellipsis in this widget are not so good (guess the full text is shown in a tooltip). I'd recommend Battery-low condition as title plus sub text remaining: 2%/~10min and shutdown in: 10s with the option to cancel, if relevant. Does the safety shutdown pops-up again or is it the user's duty now to care about saving stuff? I'm not sure if overriding safety features is a good idea in general. - Heiko Tietze On Juni 8, 2015, 5:30 nachm., Kai Uwe Broulik wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/124037/ --- (Updated Juni 8, 2015, 5:30 nachm.) Review request for Plasma, Solid and KDE Usability. Repository: powerdevil Description --- To prevent David from eventually breaking his bones tumbling down the stairs rushing for his AC adapter, this adds a Cancel button to the battery critical notification that allows to cancel the timeout for automatic suspend/shutdown. Diffs - daemon/powerdevilcore.h 50e6a50 daemon/powerdevilcore.cpp e90a960 Diff: https://git.reviewboard.kde.org/r/124037/diff/ Testing --- Got a Cancel button only when it was configured to do something, clicking the button from both popup and history cancelled the timeout. (Unfortunately the notification doesn't fit into the popup at all now) File Attachments Notification with close button https://git.reviewboard.kde.org/media/uploaded/files/2015/06/07/f99c0164-4436-462f-974b-ddc5df0ce500__powerdevilcanceltimeout.png Thanks, Kai Uwe Broulik ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 123888: [krunner] Bring back history
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/123888/#review80764 --- It's not intuitive to type 'pla' and get a list (with radio buttons!) that contains 'dolphin'. Expanding the dropdown without content should show previous search items and 'pla' could prioritize stuff from the history. And I'm wondering how this option is configured by the user. - Heiko Tietze On Mai 23, 2015, 11:40 nachm., Kai Uwe Broulik wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/123888/ --- (Updated Mai 23, 2015, 11:40 nachm.) Review request for Plasma, KDE Usability and Vishesh Handa. Bugs: 335731 https://bugs.kde.org/show_bug.cgi?id=335731 Repository: plasma-workspace Description --- This turns KRunner's TextField into an editable ComboBox to provide a history. When a result is invoked, the query string is prepended to the history, query strings are only added once. ComboBox provides letter-by-letter auto completion. Diffs - krunner/view.h 1ad5075 krunner/view.cpp 8640e1d lookandfeel/contents/runcommand/RunCommand.qml 4c6eb30 Diff: https://git.reviewboard.kde.org/r/123888/diff/ Testing --- Somehow I have a feeling it doesn't always save the history or nukes it at times. It also has some shortcomings due to ComboBox: 1.) You cannot use the arrow keys to cycle between entries (when the popup's not opened) because arrow keys navigate through results 2.) forceActiveFocus() on the ComboBox will not activate the embedded TextField - when you had opened the popup there's a slight chance the input field won't get focussed I'll prepare a Qt patch for this. 3.) Before Qt 5.4.2 (not sure if my patch ended up in 5.4.1) pressing space in the edit combobox will open the popup, not insert a space (nasty show stopper) 4.) Plasma's edtiable ComboBox looks a bit strange imho 5.) Plasma's editable ComboBox doesn't support clearButtonShown 6.) Plasma's ComboBox has strange bullets and margins in it, that's probably a bug in Plasma Style (need to look what Desktop style does differently from us) 7.) ComboBox doesn't have a cursorPosition, I'll prepare a Qt patch for this. File Attachments History popup https://git.reviewboard.kde.org/media/uploaded/files/2015/05/23/7ad7e5eb-4874-4f9f-9796-738fa2ac9ed5__krunnerhistory.png Auto completion https://git.reviewboard.kde.org/media/uploaded/files/2015/05/23/18714844-ef28-4cdd-af00-e6685caece9b__krunnerautocompletion.png Thanks, Kai Uwe Broulik ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 123671: add visibleWhileDesktopShown property
On Mai 7, 2015, 11:23 vorm., Marco Martin wrote: I think i would like more either all panels always shown or always hidden. however I'm fine, given the discussion on this if this mechanism is used instead. just a question: wouldn't make more sense to use this in a private component of the show desktop applet instead of giving api for everything? I feel the use case so far is quite limited to a potential single applet. If then more applets come out that would need this, it could be moved in bindings (of which i would prefer in appletinterface rather than appletquickitem) Sebastian Kügler wrote: I've talked with Heiko and Thomas about hiding the panel, and they were pretty clear that hiding the panel is an oversight (especially when triggered from a widget in the panel). I'm strongly for not introducing a whole bunch of API for the distinction comes from panel or not, but keep the panel visible regardless. This keeps behaviour more consistent and seems to be the common/traditional expectation how a panel should behave in the show desktop feature. Kai Uwe Broulik wrote: +1 for just keeping the panels visible and be done with it :) Heiko Tietze wrote: Plasmoids and fix panels are sticky things that must not get minimized or greyed out. The latter is the fact for conkys, for instance, when window/task switcher (alt+tab) is shown. So +1 for the issue (I cannot validate the solution). Thomas Lübking wrote: It's not like the usability team was not explicitly attached to the review request that introduced this and explicitly (exclusively) asked what to do with panels :-P Ok, when we show all panels unconditionally there're some concerns (ultimately probably only one) also raised by Thomas P. in the original request: clicking entries in the taskbar will not make the corresponding window visible unless (as of present condition) it's set to be kept above or the window is *actually* minmized (where the latter will break the showing desktop state) - this might be unexpected inconsistency? Possible solutions: a) the taskbar is adjusted to break the showing desktop state whenever any entry is clicked b) keep above windows are *not* kept visible while showing the desktop c) well, that's just the way is is, buddy d) the taskbar disables itself while showing the desktop (a) would get us very close to the former behavior and ppl. coming up with KWin unminimizes all windows instead of one after i minimized all bugs (b) would eg. hide yakuake (though it and krunner can still set themself transient for the desktop what will keep them above the desktop all the time (c) ;-) (d) would maybe make most sense? keep above windows can in general still be activated/raised (like yakuake through its global shortcut) but without a special access, they're are lost once you click the dektop (until the state is broken, of course) Thomas Pfeiffer wrote: Oversight might not be the right word, rather idea not thought completely through. I must admit that I had missed the issue that people who switched to this mode via the Plasmoid in a panel couldn't get back in the same way if the panel was hidden. And by the time I replied to Sebas' email I'd already forgotten the issue with clicking a window in the task manager. So much to think about... Both issues (not being able to exit the made the same way it was started and having windows not visibly appear when clicking a taskbar entry) are quite serious. Having two different modes depending on how it was started would probably add more to the confusion than it would help, though (also the problem with the hidden windows would then still persist if the mode was triggered from the panel). Would it be possible to break the show desktop mode as soon as one clicks a taskbar entry? Thomas Lübking wrote: The state can be broken anytime by either KWin or any client (incl. the taskbar), ie. either the taskbar breaks it or kwin breaks it whenever there's a forceful call to activate a window (as usually performed by taskbars and pagers) Itr, please bear in mind https://bugs.kde.org/show_bug.cgi?id=67406 The fundamental question here is: Should one be implicitly kicked out of this mode by an opening window? If the answer is no, would it be seen as inconsistent (a problem) that activating a window through the taskbar does, but starting one via krunner or even kickoff does *not* break the state (KWin does not really know whether a window opens because you just started a process or something (daemon) just started a process or a running process feels it's time to annoy you with a dialog; kickoff/krunner could explicitly break it on running a command, though) Status quo
Re: Review Request 123671: add visibleWhileDesktopShown property
On Mai 7, 2015, 11:23 vorm., Marco Martin wrote: I think i would like more either all panels always shown or always hidden. however I'm fine, given the discussion on this if this mechanism is used instead. just a question: wouldn't make more sense to use this in a private component of the show desktop applet instead of giving api for everything? I feel the use case so far is quite limited to a potential single applet. If then more applets come out that would need this, it could be moved in bindings (of which i would prefer in appletinterface rather than appletquickitem) Sebastian Kügler wrote: I've talked with Heiko and Thomas about hiding the panel, and they were pretty clear that hiding the panel is an oversight (especially when triggered from a widget in the panel). I'm strongly for not introducing a whole bunch of API for the distinction comes from panel or not, but keep the panel visible regardless. This keeps behaviour more consistent and seems to be the common/traditional expectation how a panel should behave in the show desktop feature. Kai Uwe Broulik wrote: +1 for just keeping the panels visible and be done with it :) Plasmoids and fix panels are sticky things that must not get minimized or greyed out. The latter is the fact for conkys, for instance, when window/task switcher (alt+tab) is shown. So +1 for the issue (I cannot validate the solution). - Heiko --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/123671/#review80028 --- On Mai 7, 2015, 11:14 vorm., Thomas Lübking wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/123671/ --- (Updated Mai 7, 2015, 11:14 vorm.) Review request for Plasma and Marco Martin. Bugs: 346837, 346933 and 347212 http://bugs.kde.org/show_bug.cgi?id=346837 http://bugs.kde.org/show_bug.cgi?id=346933 http://bugs.kde.org/show_bug.cgi?id=347212 Repository: plasma-framework Description --- plasmoids only need to add Plasmoid.visibleWhileDesktopShown: true; to ensure their panel (and thus them) remains visible while showing the desktop This is achieved by setting the panel transient for the (first found, under them and visible) desktop type window. This is mostly relevant for the showdesktop plasmoid (for now) Notice that all bugs are only CC, we need this to be used in the showdesktop plasmoid. Diffs - src/plasmaquick/appletquickitem.h dffbcf3 src/plasmaquick/appletquickitem.cpp 0748a8d src/plasmaquick/private/appletquickitem_p.h a1ec683 Diff: https://git.reviewboard.kde.org/r/123671/diff/ Testing --- added/removed (multiple) showdesktop plasmoids - panel transient for correct desktop window (and visible) unless the last is gone (they seem to be deleted with a short random delay?) Thanks, Thomas Lübking ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 123539: Improve visibility of running widget checkmark
On April 27, 2015, 10:02 nachm., andreas kainz wrote: colors maybe green and white as used in the mount symbol Graphics should be theme aware. Please make sure badges are readable with Breeze Dark or Wonton Soup. - Heiko --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/123539/#review79609 --- On April 27, 2015, 9:35 nachm., Kai Uwe Broulik wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/123539/ --- (Updated April 27, 2015, 9:35 nachm.) Review request for Plasma, KDE Usability and Andrew Lake. Bugs: 342112 https://bugs.kde.org/show_bug.cgi?id=342112 Repository: plasma-desktop Description --- As suggested by Andrew show a badge kind of thing with the number of running applets inside. Diffs - desktoppackage/contents/explorer/AppletDelegate.qml 2e53c1e desktoppackage/contents/explorer/WidgetExplorer.qml f164c18 Diff: https://git.reviewboard.kde.org/r/123539/diff/ Testing --- After fixing a nasty bug in the model it shows the proper number now. It also doesn't break if you happen to have 10 or more widgets of the same kind. I did not know what kind of font color to use. File Attachments Badge in action https://git.reviewboard.kde.org/media/uploaded/files/2015/04/27/1b8483bb-fe3b-4701-92d3-02b437e63843__widgetexplorernumber2.jpg Thanks, Kai Uwe Broulik ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 122452: [shell] Emit dbus signals in org.kde.osdService
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/122452/#review76325 --- Ship it! Design with transparent background is nice. But please consider multiple notifications. For instance, You got 5 new mails, You have been mentioned on IRC, plus the loudness indicator. It would be nice to not only show the last item but to implement a carousell pattern. - Heiko Tietze On Feb. 10, 2015, 10:07 vorm., Martin Gräßlin wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/122452/ --- (Updated Feb. 10, 2015, 10:07 vorm.) Review request for Plasma and Martin Klapetek. Repository: plasma-workspace Description --- Emitting dbus signals allows interested parties to be notified about OSD changes. E.g. the lock screen might want to show the OSD values, but blocks the actual OSD, so it needs to be informed about changes to react on them. [lookandfeel] Split mainItem of Osd into a dedicated OsdItem Allows to reuse the content of the Osd in other parts without having it to be a Dialog. [screenlocker] Support OnScreenDisplay messages KSld connects to the DBus signals for the OnScreenDisplay and forwards them to the greeter application through the private Wayland protocol. The idea here is to not have the greeter connect to the DBus as in future it would be preferable if the greeter cannot connect to DBus. The lookandfeel package might expose an object called onScreenDisplay. Whenever an OSD message is recieved by the greeter it looks for such an object and updates the osd specific properties. The default breeze lookandfeel package integrates the OsdItem from the same lookandfeel package. Diffs - ksmserver/screenlocker/greeter/greeterapp.h 4a90fafee810940c3f932c8e2bfed10459adc425 ksmserver/screenlocker/greeter/greeterapp.cpp a23b5625adc99661ab07534403ee23d005581c03 ksmserver/screenlocker/protocols/ksld.xml bfb32190bf2529a14b39fac4c7e6029a5df811d0 ksmserver/screenlocker/waylandserver.h 5a8ed2249152277b505fe7a944b1b7251ef995d3 ksmserver/screenlocker/waylandserver.cpp 746032e1a7b1bad3625b9f0a156de059e5fba31a lookandfeel/contents/lockscreen/LockScreen.qml 1c4e4a510dd9196ae2b36bc355490580c06a78a6 lookandfeel/contents/osd/Osd.qml b63338c2f94c074b405bba5509623ef38eef5350 lookandfeel/contents/osd/OsdItem.qml PRE-CREATION shell/osd.h 356b073b2b9c88e57c324701ae47e0e969b75a51 shell/osd.cpp b5d40ab3539bbbe37386fa6ecf4a1f8cb130c100 Diff: https://git.reviewboard.kde.org/r/122452/diff/ Testing --- File Attachments Lock screen with volume OSD https://git.reviewboard.kde.org/media/uploaded/files/2015/02/06/7e2f82a5-4ec4-46cc-9697-7cead41d2a45__missing-tasks-applet1.png With background https://git.reviewboard.kde.org/media/uploaded/files/2015/02/09/05e26071-2b79-4c75-85af-68cff6e163ee__missing-tasks-applet1.png Thanks, Martin Gräßlin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 122452: [shell] Emit dbus signals in org.kde.osdService
On Feb. 20, 2015, 9:39 vorm., Heiko Tietze wrote: Design with transparent background is nice. But please consider multiple notifications. For instance, You got 5 new mails, You have been mentioned on IRC, plus the loudness indicator. It would be nice to not only show the last item but to implement a carousell pattern. Martin Gräßlin wrote: Heiko: this is just the OSD, not notificatons. For the notifications I created a forum thread in VDG, with not much feedback so far. And I thought you want to get the feedback here :-). - Heiko --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/122452/#review76325 --- On Feb. 10, 2015, 10:07 vorm., Martin Gräßlin wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/122452/ --- (Updated Feb. 10, 2015, 10:07 vorm.) Review request for Plasma and Martin Klapetek. Repository: plasma-workspace Description --- Emitting dbus signals allows interested parties to be notified about OSD changes. E.g. the lock screen might want to show the OSD values, but blocks the actual OSD, so it needs to be informed about changes to react on them. [lookandfeel] Split mainItem of Osd into a dedicated OsdItem Allows to reuse the content of the Osd in other parts without having it to be a Dialog. [screenlocker] Support OnScreenDisplay messages KSld connects to the DBus signals for the OnScreenDisplay and forwards them to the greeter application through the private Wayland protocol. The idea here is to not have the greeter connect to the DBus as in future it would be preferable if the greeter cannot connect to DBus. The lookandfeel package might expose an object called onScreenDisplay. Whenever an OSD message is recieved by the greeter it looks for such an object and updates the osd specific properties. The default breeze lookandfeel package integrates the OsdItem from the same lookandfeel package. Diffs - ksmserver/screenlocker/greeter/greeterapp.h 4a90fafee810940c3f932c8e2bfed10459adc425 ksmserver/screenlocker/greeter/greeterapp.cpp a23b5625adc99661ab07534403ee23d005581c03 ksmserver/screenlocker/protocols/ksld.xml bfb32190bf2529a14b39fac4c7e6029a5df811d0 ksmserver/screenlocker/waylandserver.h 5a8ed2249152277b505fe7a944b1b7251ef995d3 ksmserver/screenlocker/waylandserver.cpp 746032e1a7b1bad3625b9f0a156de059e5fba31a lookandfeel/contents/lockscreen/LockScreen.qml 1c4e4a510dd9196ae2b36bc355490580c06a78a6 lookandfeel/contents/osd/Osd.qml b63338c2f94c074b405bba5509623ef38eef5350 lookandfeel/contents/osd/OsdItem.qml PRE-CREATION shell/osd.h 356b073b2b9c88e57c324701ae47e0e969b75a51 shell/osd.cpp b5d40ab3539bbbe37386fa6ecf4a1f8cb130c100 Diff: https://git.reviewboard.kde.org/r/122452/diff/ Testing --- File Attachments Lock screen with volume OSD https://git.reviewboard.kde.org/media/uploaded/files/2015/02/06/7e2f82a5-4ec4-46cc-9697-7cead41d2a45__missing-tasks-applet1.png With background https://git.reviewboard.kde.org/media/uploaded/files/2015/02/09/05e26071-2b79-4c75-85af-68cff6e163ee__missing-tasks-applet1.png Thanks, Martin Gräßlin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 122505: Warn about brightness getting too low
On Feb. 10, 2015, 11:50 nachm., Thomas Pfeiffer wrote: Basic rule from design for safety: Don't use a warning if you can prevent the dangerous action completely. In this case that means: Setting the brightness to zero should only be possible via keyboard, because that ensures recoverability. Don't display any warning. Instead, when the slider reaches the minimum, display a hint saying To prevent switching off the screen by accident, setting the brightness lower than [sensible value]% is only possible using the keyboard. That way, it's not possible to maneuver yourself in an unrecoverable position but people who like to switch off their screen backlight can still do so using the keyboard. And we don't need to show a scary warning, but a helpful hint instead. Emmanuel Pescosta wrote: What about adding an option to Adcanced Power Management Settings that allows the user to change between safe/full screen brightness range (default: safe, minimum is 5% of the hw range)? [x] Use the full screen brightness range provided by your hardware (Warning: 0% may turn your screen off) So the warning in the widget can be avoided and the default behavior is the same as on most other operating systems (0% != screen off). My 2 cents ;) Martin Klapetek wrote: In my opinion, adding (yet another) option just complicates things more. same as on most other operating systems (0% != screen off). I can't speak for Windows, but my OS X definitely turns screen off when you go to 0%. Martin Klapetek wrote: Oh now I can speak for Windows :) -- https://msdn.microsoft.com/en-us/library/windows/hardware/ff569755%28v=vs.85%29.aspx -- Brightness levels are represented as single-byte values in the range from zero to 100 where zero is off and 100 is the maximum brightness that a laptop computer supports [...] however, a laptop computer is not required to support a level of zero.. So it's fully hardware/driver dependent, just like it is on Linux. Emmanuel Pescosta wrote: Just tested it on Windows: Turning off the screen by only using the brightness slider or the brightness buttons doesn't work, the dedicated screen on/off button is the only way to turn it off (http://goo.gl/3CLDGP Fn+F6) Martin Klapetek wrote: Yes, which matches what I said above about Windows. Some drivers on Linux also don't turn backlight off when you set 0%. Emmanuel Pescosta wrote: 0% means backlight off on this notebook, but the user interface doesn't allow to turn it off on Windows (maybe they check if a screen off/on key is available?) When I test it with Powerdevil, then the screen turns off when I drag the slider to 0%. So there is a difference between 0% on the UI and 0% on the hardware side on Windows. I'd like to suppport Thomas position be mentioning Android's behaviour: you switch off the backlight by hardware key but adjust the setting differently per slider. Two use cases, two ways of interaction. If we only could discuss all settings in such a depth... ;-) - Heiko --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/122505/#review75824 --- On Feb. 9, 2015, 10:25 nachm., Kai Uwe Broulik wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/122505/ --- (Updated Feb. 9, 2015, 10:25 nachm.) Review request for Plasma and KDE Usability. Repository: plasma-workspace Description --- Some graphics drivers, notably Intel, turn off the backlight completely when brightness reached zero, which is also in the spec (0 = off, 1 = very dim) but imho that's unexpected. To prevent the user from accidentally turnign the screen off, especially when keyboard brightness controls don't work, which sadly still happens quite often, the slider breaks free from the user's drag (by becoming disable for two (perhaps 1 is enough?) seconds, so we also catch the mouse wheel case) and displays a warning (which stays there until screen brightness is dialed up again). Diffs - applets/batterymonitor/package/contents/ui/BrightnessItem.qml 546ab58 applets/batterymonitor/package/contents/ui/PopupDialog.qml a2acf31 Diff: https://git.reviewboard.kde.org/r/122505/diff/ Testing --- Works pretty well, I just realized I forgot the mousewheel-on-trayicon case. Also, I'm open to wording suggestions since it sounds more like we suck, sorry about that. (Note in the screenshot I used the mouse wheel, hence the displayed 4% rather than 5) File Attachments Screenshot
Re: Review Request 122488: Improved calendar navigation
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/122488/#review75641 --- Awesome! But please take care of alternative access (keyboard, mouse wheel) and accessibilty. - Heiko Tietze On Feb. 8, 2015, 8:52 nachm., Kai Uwe Broulik wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/122488/ --- (Updated Feb. 8, 2015, 8:52 nachm.) Review request for Plasma and KDE Usability. Repository: plasma-framework Description --- This improves the calendar navigation by providing a Year overview showing all 12 months in a grid, and a Decade overview showing the current decade in a grid. A lot of code has just been moved around. The overviews use a QML ListModel owing to laziness. See https://www.youtube.com/watch?v=7SaBhRa32ds for a screencast (I love that mouse click effect!) Diffs - src/declarativeimports/calendar/calendar.cpp a766acb src/declarativeimports/calendar/daydata.h 39ac086 src/declarativeimports/calendar/daysmodel.h ec88837 src/declarativeimports/calendar/daysmodel.cpp 1a6f454 src/declarativeimports/calendar/qml/DayDelegate.qml 6a3747e src/declarativeimports/calendar/qml/DaysCalendar.qml 67b3a2e src/declarativeimports/calendar/qml/MonthView.qml 6eaa8db src/declarativeimports/calendar/calendar.h ea20bf5 Diff: https://git.reviewboard.kde.org/r/122488/diff/ Testing --- I changed the selection to be persistent during navigation; other than that, should work as before, with the new overviews. Thanks, Kai Uwe Broulik ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 122488: Improved calendar navigation
On Feb. 8, 2015, 10:59 nachm., Heiko Tietze wrote: Awesome! But please take care of alternative access (keyboard, mouse wheel) and accessibilty. Kai Uwe Broulik wrote: The calendar lacks any keyboard input and accessibility support whatsoever, so this should be added separately later. It would be easy to solve when every control gets a label (as the HIG demands). Like Year: 2012 or Month: January, and the dropdown expands on focus or when the hotkey is pressed with access by cursor up/down. - Heiko --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/122488/#review75641 --- On Feb. 8, 2015, 8:52 nachm., Kai Uwe Broulik wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/122488/ --- (Updated Feb. 8, 2015, 8:52 nachm.) Review request for Plasma and KDE Usability. Repository: plasma-framework Description --- This improves the calendar navigation by providing a Year overview showing all 12 months in a grid, and a Decade overview showing the current decade in a grid. A lot of code has just been moved around. The overviews use a QML ListModel owing to laziness. See https://www.youtube.com/watch?v=7SaBhRa32ds for a screencast (I love that mouse click effect!) Diffs - src/declarativeimports/calendar/calendar.cpp a766acb src/declarativeimports/calendar/daydata.h 39ac086 src/declarativeimports/calendar/daysmodel.h ec88837 src/declarativeimports/calendar/daysmodel.cpp 1a6f454 src/declarativeimports/calendar/qml/DayDelegate.qml 6a3747e src/declarativeimports/calendar/qml/DaysCalendar.qml 67b3a2e src/declarativeimports/calendar/qml/MonthView.qml 6eaa8db src/declarativeimports/calendar/calendar.h ea20bf5 Diff: https://git.reviewboard.kde.org/r/122488/diff/ Testing --- I changed the selection to be persistent during navigation; other than that, should work as before, with the new overviews. Thanks, Kai Uwe Broulik ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 121449: Rename Human Input Devices to just Input Devices
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/121449/#review71816 --- Isn't the term HID very common? Human interface device (or input) to distinguish it from network cable, or the like, that are rather for the pets to play with. But I don't stick to the name. - Heiko Tietze On Dez. 11, 2014, 2:43 nachm., Martin Klapetek wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/121449/ --- (Updated Dez. 11, 2014, 2:43 nachm.) Review request for Plasma and KDE Usability. Repository: systemsettings Description --- The Human part feels strange (even though technically correct). Putting just Input devices is stil correct and feels more natural Diffs - categories/settings-hardware-input.desktop ddc3204 Diff: https://git.reviewboard.kde.org/r/121449/diff/ Testing --- Thanks, Martin Klapetek ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: new systemsettings categorization landed
Hi Vishesh all, I agree that it makes more sense to place it with the desktop stuff. Maybe we had application = file in mind? The only argument against desktop behavior is that this topic gets somewhat bulky. And I'm not sure that users will associate all the modules including file search with the caption. For balancing we should consider to split the topic perhaps like this Application Features * Accessibility * File Search * Activities Desktop Behavior * Global Workspace Options * Desktop Effects * Screen Edges * Virtual Desktops What do you think? Cheers, Heiko. Am 01.07.2014 17:09:31, schrieb Vishesh Handa: Hey guys. I don't understand why File Search (formerly Desktop Search) should go under Applications. Current application which can be used to search for files - Dolphin. Current workspace stuff which can be used to search - KRunner, Milou, Kickoff and Kicker. It seems rather odd for it to be under applications. Could someone please elaborate on the rationale behind it? I've tried reading the forums, but I haven't really found much. On Tue, Jul 1, 2014 at 1:11 PM, Sebastian Kügler se...@kde.org wrote: Hey, So as the subject suggests, I've just landed the new categorization for systemsettings. Changes are all over the place, so if you just update single repositories, your systemsettings will be quite empty. If you're re-running kdesrc-build, you'll find a mess with old and new categorized intermixed (is intermixed a word? If not, we should make it one.) A clean installation will give you the desired results, but you can also just delete all categories before running kdesrc-build: rm `kf5-config --prefix`/share/kservices5/settings* (Use at your own risk.) After that, running kde-src build should get you into the new systemsettings state. If you notice anything strange, please refer to this thread and discuss your issues there: http://forum.kde.org/viewtopic.php?f=285t=121053start=60 If you notice that I did something wrong when turning the huge graphic into changes to .desktop files, please let me know, and I'll fix it. Special thanks goes to our interaction and visual designers who did the research for this new categorization. I personally think it's a big improvement. Going forward, there's a lot of work ahead, and this is only the beginning. We need to overhaul KCMs, we need to simplify settings, modernize UIs, and we will likely also introduce a new shell (which we can do gradually with the different view plugins in systemsettings). For an experiment, try the sebas/quick branch in systemsettings. This new categorization is only the first step, and we decided to push this into 5.0, since it's a user-visible change, and we can keep things rather more stable from here on out. 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 -- Vishesh Handa ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 118290: Streamline Comment fields of KCMs
On May 26, 2014, 10:38 a.m., Christoph Feck wrote: kcms/dateandtime/clock.desktop, line 107 https://git.reviewboard.kde.org/r/118290/diff/1/?file=274665#file274665line107 Is there a guideline for using the '' character vs. and? I suggest to always use the word (which you also use e.g. for Login and Logout) to make it consistent. David Edmundson wrote: There's a guideline on no abbreviations. I think counts as one. Sebastian Kügler wrote: Ah, yes. Missed that one. I added a short hint to the HIG: Avoid abbreviations (including ampersand instead of 'and'), acronyms, and tech-babble. - Heiko --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/118290/#review58456 --- On May 26, 2014, 10:52 p.m., Sebastian Kügler wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/118290/ --- (Updated May 26, 2014, 10:52 p.m.) Review request for Plasma and KDE Usability. Repository: plasma-desktop Description --- Streamline Comment fields of KCMs This patch applies a common language and type-setting to the systemsettings modules in kde-workspace. Considerations: - The comment field might repeat the name, or give more detail about the specific settings on this page, this makes sense with how systemsettings and kcmshell present it - Mentioning the words settings, configure, options, etc. is avoided -- it is clear from the context that these are settings and options. - Title-case throughout in line with human interface guidelines, see http://techbase.kde.org/Projects/Usability/HIG/Capitalization - The comment ends up being the title, so the - tech slang is avoided as much as possible, but left in where really necessary (hi Phonon), there were a few mentions of ~KDE Settings, which don't make sense in a properly branded universe. - I've left the Name field mostly untouched, as that one is key for the user to find the right module in systemsettings' icon view and in the sidebars The same treatment needs to be done for a bunch of other KCMs that we end up installing from other repos. This is a good start, however. Diffs - kcms/access/kcmaccess.desktop f859504 kcms/autostart/autostart.desktop 5a1048e kcms/bell/bell.desktop 906aff7 kcms/colors/colors.desktop 409f665 kcms/componentchooser/componentchooser.desktop 214c4f1 kcms/dateandtime/clock.desktop acaca1a kcms/desktoppaths/desktoppath.desktop da351d9 kcms/desktoptheme/desktoptheme.desktop 602f04c kcms/emoticons/emoticons.desktop bbbd24a kcms/fonts/fonts.desktop 99a88c4 kcms/formats/formats.desktop 8a95b61 kcms/hardware/display/display.desktop 0d8b7e6 kcms/hardware/joystick/joystick.desktop e5ff24a kcms/icons/icons.desktop 1dfcf8c kcms/input/cursortheme.desktop 4a5feed kcms/input/mouse.desktop 5df856e kcms/kded/kcmkded.desktop 76e299d kcms/keyboard/kcm_keyboard.desktop 01f9542 kcms/keys/keys.desktop 30a4bc8 kcms/kfontinst/kcmfontinst/fontinst.desktop 6b13725 kcms/knotify/kcmnotify.desktop cd25cd4 kcms/ksmserver/kcmsmserver.desktop c461be7 kcms/ksplash/ksplashthememgr.desktop 711fbc3 kcms/launch/kcmlaunch.desktop fbb3ca6 kcms/phonon/kcm_phonon.desktop 46eecff kcms/spellchecking/spellchecking.desktop 92a76cf kcms/standard_actions/standard_actions.desktop 54a3ea8 kcms/style/style.desktop fd19bc4 kcms/workspaceoptions/workspaceoptions.desktop 3e31866 Diff: https://git.reviewboard.kde.org/r/118290/diff/ Testing --- Thanks, Sebastian Kügler ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Notifications in Next
Am 24.03.2014 16:13:12, schrieb Thomas Pfeiffer: That sounds to me like it makes sense. CC'ing Heiko to see if he spots a problem with it I might have missed. @autistici.org @autistici.org The HIG should be restrictive in my opinion. It requires notification to be small with only a few lines. Scrollbars violates this requirement by design, but its better than resizing the panel. Another idea is to abbreviate the text merciless, perhaps with ellipsis. App dev that makes text verbose should care about the action on click, that means I expect to read the full text in this case. About SNI and notification we should define clearly when something belongs to a particular category. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 110389: Add Configure button to notifications that opens KNotify settings for the app that emitted the notification
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/110389/#review32386 --- Nice feature, if it works overall. Is there a question for usability except the fact that we need guidelines on notification along with its configuration in general? - Heiko Tietze On May 12, 2013, 2:10 p.m., Kai Uwe Broulik wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/110389/ --- (Updated May 12, 2013, 2:10 p.m.) Review request for Plasma and KDE Usability. Description --- Depends on Review 110407 This patch adds a configure button to notifications that, when clicked, open the KNotify settings for the app that emitted the notification. This makes it much easier to turn off a notification you do not want and you have no clue where to turn it off (no novice user would know that you can actually turn these off, not even speaking of where) I asked Olivier Goffart for permission to use his notifyrc lookup code that is licensed GPLv2 in this LGPLv2 code. We need to do this because according to the specs the application name passed to the notification system is […] the optional name of the application sending the notification. This should be the application's formal name[…]. An example would be FredApp E-Mail Client, rather than fredapp-email-client. So KNotify had to be modified to not only expose KDE Power Management System to the dataengine but also its internal name powerdevil. For illustration how it works, see here: http://666kb.com/i/cdzg50m1huwc1k751.jpg ;-) Diffs - plasma/generic/applets/notifications/contents/ui/LastNotificationPopup.qml df63ae6 plasma/generic/applets/notifications/contents/ui/NotificationDelegate/NotificationDelegate.qml 64d9298 plasma/generic/applets/notifications/contents/ui/Notifications.qml c5be0a3 plasma/generic/dataengines/notifications/CMakeLists.txt e8d66e0 plasma/generic/dataengines/notifications/notificationaction.cpp 390cc16 plasma/generic/dataengines/notifications/notifications.operations bb5d0c6 plasma/generic/dataengines/notifications/notificationsengine.h 4644c8e plasma/generic/dataengines/notifications/notificationsengine.cpp 77f5db2 Diff: http://git.reviewboard.kde.org/r/110389/diff/ Testing --- Works, in both the popup and history. Tested with: - Amarok: Shows configure button properly - PowerDevil: Shows configure button properly - Konsole: Shows configure button properly - Free Space Notifier: Shows configure button properly - KDialog: Does not show configure button, as expected - QDBusViewer to issue a notification using the FDO DBus iface: Does not show configure button, as expected (it does, when your passed appName happens to match an application, which is rather nice, though) File Attachments A few notifications with and without configure option http://git.reviewboard.kde.org/media/uploaded/files/2013/05/12/notificationconfigure1.png Thanks, Kai Uwe Broulik ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
