Re: Review Request 129414: KMessageWidget: fix layout when word-wrap is enabled without actions
> On Nov. 16, 2016, 1:10 nachm., Christoph Feck wrote: > > Could you add a screen shot that shows actually wrapped text? > > Christoph Feck wrote: > Thanks, so the close icon is vertically centered. > > Heiko, do you agree that the close icon would look better if it was also > top-aligned like the message icon? > > Heiko Tietze wrote: > Better you align it vertically with the left-hand topic icon meaning at > top. That would be also place this icon according the usual position. > > Elvis Angelaccio wrote: > This is how it looks with top vertical alignment: > http://i.imgur.com/i1nrxmN.png Perfect (this is in particular relevant for more than two lines). - Heiko --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/129414/#review100879 --- On Nov. 16, 2016, 1:47 nachm., Elvis Angelaccio wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/129414/ > --- > > (Updated Nov. 16, 2016, 1:47 nachm.) > > > Review request for KDE Frameworks, KDE Usability and Christoph Feck. > > > Repository: kwidgetsaddons > > > Description > --- > > If we enable word-wrap on a vanilla KMessageWidget (with no additional tool > buttons added), the close button is placed on row number 1 (in the grid > layout), resulting in wasted space (see first messagewidget in the > screenshots). > > This patch places the close button on row number 1 only when we actually have > other buttons in the messagewidget. This way we save space in the normal case. > > > Diffs > - > > src/kmessagewidget.cpp e8b25f6427534a4991bb1dfe9f820cb651238e18 > tests/kmessagewidgettest.cpp 441e961ac9b851ccc713ab1713e797bd20389efd > > Diff: https://git.reviewboard.kde.org/r/129414/diff/ > > > Testing > --- > > Manual testing in the (expanded) kmessagewidgettest. > > > File Attachments > > > Before: wasted space in the first messagewidget > > https://git.reviewboard.kde.org/media/uploaded/files/2016/11/16/e2fb5bce-e249-44fc-9ece-d49c0cf656e1__Spectacle.E12435.png > After: no wasted space in the first messagewidget > > https://git.reviewboard.kde.org/media/uploaded/files/2016/11/16/09986a2d-f1be-48ad-92f0-87d264873ad9__Spectacle.J13060.png > Before (with text wrapped) > > https://git.reviewboard.kde.org/media/uploaded/files/2016/11/16/ab594606-7f90-4ca8-949d-9baafd448252__Spectacle.X22288.png > After (with text wrapped) > > https://git.reviewboard.kde.org/media/uploaded/files/2016/11/16/f574d6e6-7c92-443a-b1de-345cb3ed3ad3__Spectacle.J21199.png > > > Thanks, > > Elvis Angelaccio > >
Re: Review Request 129414: KMessageWidget: fix layout when word-wrap is enabled without actions
> On Nov. 16, 2016, 1:10 nachm., Christoph Feck wrote: > > Could you add a screen shot that shows actually wrapped text? > > Christoph Feck wrote: > Thanks, so the close icon is vertically centered. > > Heiko, do you agree that the close icon would look better if it was also > top-aligned like the message icon? Better you align it vertically with the left-hand topic icon meaning at top. That would be also place this icon according the usual position. - Heiko --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/129414/#review100879 --- On Nov. 16, 2016, 1:47 nachm., Elvis Angelaccio wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/129414/ > --- > > (Updated Nov. 16, 2016, 1:47 nachm.) > > > Review request for KDE Frameworks, KDE Usability and Christoph Feck. > > > Repository: kwidgetsaddons > > > Description > --- > > If we enable word-wrap on a vanilla KMessageWidget (with no additional tool > buttons added), the close button is placed on row number 1 (in the grid > layout), resulting in wasted space (see first messagewidget in the > screenshots). > > This patch places the close button on row number 1 only when we actually have > other buttons in the messagewidget. This way we save space in the normal case. > > > Diffs > - > > src/kmessagewidget.cpp e8b25f6427534a4991bb1dfe9f820cb651238e18 > tests/kmessagewidgettest.cpp 441e961ac9b851ccc713ab1713e797bd20389efd > > Diff: https://git.reviewboard.kde.org/r/129414/diff/ > > > Testing > --- > > Manual testing in the (expanded) kmessagewidgettest. > > > File Attachments > > > Before: wasted space in the first messagewidget > > https://git.reviewboard.kde.org/media/uploaded/files/2016/11/16/e2fb5bce-e249-44fc-9ece-d49c0cf656e1__Spectacle.E12435.png > After: no wasted space in the first messagewidget > > https://git.reviewboard.kde.org/media/uploaded/files/2016/11/16/09986a2d-f1be-48ad-92f0-87d264873ad9__Spectacle.J13060.png > Before (with text wrapped) > > https://git.reviewboard.kde.org/media/uploaded/files/2016/11/16/ab594606-7f90-4ca8-949d-9baafd448252__Spectacle.X22288.png > After (with text wrapped) > > https://git.reviewboard.kde.org/media/uploaded/files/2016/11/16/f574d6e6-7c92-443a-b1de-345cb3ed3ad3__Spectacle.J21199.png > > > Thanks, > > Elvis Angelaccio > >
Re: Review Request 129414: KMessageWidget: fix layout when word-wrap is enabled without actions
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/129414/#review100877 --- Ship it! Ship It! - Heiko Tietze On Nov. 16, 2016, 11:48 vorm., Elvis Angelaccio wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/129414/ > --- > > (Updated Nov. 16, 2016, 11:48 vorm.) > > > Review request for KDE Frameworks, KDE Usability and Christoph Feck. > > > Repository: kwidgetsaddons > > > Description > --- > > If we enable word-wrap on a vanilla KMessageWidget (with no additional tool > buttons added), the close button is placed on row number 1 (in the grid > layout), resulting in wasted space (see first messagewidget in the > screenshots). > > This patch places the close button on row number 1 only when we actually have > other buttons in the messagewidget. This way we save space in the normal case. > > > Diffs > - > > src/kmessagewidget.cpp e8b25f6427534a4991bb1dfe9f820cb651238e18 > tests/kmessagewidgettest.cpp 441e961ac9b851ccc713ab1713e797bd20389efd > > Diff: https://git.reviewboard.kde.org/r/129414/diff/ > > > Testing > --- > > Manual testing in the (expanded) kmessagewidgettest. > > > File Attachments > > > Before: wasted space in the first messagewidget > > https://git.reviewboard.kde.org/media/uploaded/files/2016/11/16/e2fb5bce-e249-44fc-9ece-d49c0cf656e1__Spectacle.E12435.png > After: no wasted space in the first messagewidget > > https://git.reviewboard.kde.org/media/uploaded/files/2016/11/16/09986a2d-f1be-48ad-92f0-87d264873ad9__Spectacle.J13060.png > > > Thanks, > > Elvis Angelaccio > >
Re: Review Request 129405: KCollapsibleGroupBox: don't hide widgets, override focus policy instead
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/129405/#review100856 --- Ship it! Looks good from the usability POV, hidden items should kept invisible whether or not expanded. Some random thoughts: Enabled state should be respected correctly; as you write "focus policy" make sure the tab sequence works well. And finally we should define a behaviour when all children are hidden: I'd recommend to still show the expander and just accept the possible zero content. Alignment is relevant too meaning the anchored control must not have a large space to the collapsed list with hidden items. - Heiko Tietze On Nov. 15, 2016, 11:06 vorm., Elvis Angelaccio wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/129405/ > --- > > (Updated Nov. 15, 2016, 11:06 vorm.) > > > Review request for KDE Frameworks, KDE Usability, Christoph Feck, and David > Edmundson. > > > Repository: kwidgetsaddons > > > Description > --- > > Currently it's not possible to hide widgets in a KCollapsibleGroupBox, > because the groupbox hides all chidren on collapse event and shows them on > expand event. > > The rationale was explained in this comment: "when collapsed hide contents to > save resources and more importantly get it out the focus chain" > > The focus chain problem can be solved by overriding/restoring the focus > policy of children widgets, without changing their visibility. > > > Diffs > - > > autotests/kcollapsiblegroupbox_test.h > b7f538217f480ea48bc28f098c7968fe21dda676 > autotests/kcollapsiblegroupbox_test.cpp > 4c458c4f700e498c178a637c29d6cc78ab8c267c > src/kcollapsiblegroupbox.cpp 273110e995cb25f28a815cb28125c4678ca2ab28 > tests/kcollapsiblegroupboxtest.cpp 5a2900e63e42fa81f909c7d1fff0d07033edb025 > > Diff: https://git.reviewboard.kde.org/r/129405/diff/ > > > Testing > --- > > Test app has been expanded with an hidden checkbox > > * Make sure the new checkbox stays hidden after expanding the groupbox. > * With both groups collapsed, make sure the tab-focus goes from the first > group to the second one (skipping the 7 checkboxes in the first group). > > > File Attachments > > > Before: hidden checkbox is visible > > https://git.reviewboard.kde.org/media/uploaded/files/2016/11/15/25c50bd2-aa00-42ea-b9b5-38f3d1abddff__Spectacle.d20127.png > After: hidden checkbox is hidden > > https://git.reviewboard.kde.org/media/uploaded/files/2016/11/15/815551e3-9987-4851-8025-50d44989f600__Spectacle.W20858.png > > > Thanks, > > Elvis Angelaccio > >
Re: Review Request 129405: KCollapsibleGroupBox: don't hide widgets, override focus policy instead
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/129405/#review100850 --- Picture, or it didn't happen :-) (before/after would be nice) - Heiko Tietze On Nov. 15, 2016, 9:53 vorm., Elvis Angelaccio wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/129405/ > --- > > (Updated Nov. 15, 2016, 9:53 vorm.) > > > Review request for KDE Frameworks, KDE Usability, Christoph Feck, and David > Edmundson. > > > Repository: kwidgetsaddons > > > Description > --- > > Currently it's not possible to hide widgets in a KCollapsibleGroupBox, > because the groupbox hides all chidren on collapse event and shows them on > expand event. > > The rationale was explained in this comment: "when collapsed hide contents to > save resources and more importantly get it out the focus chain" > > The focus chain problem can be solved by overriding/restoring the focus > policy of children widgets, without changing their visibility. > > > Diffs > - > > autotests/kcollapsiblegroupbox_test.h > b7f538217f480ea48bc28f098c7968fe21dda676 > autotests/kcollapsiblegroupbox_test.cpp > 4c458c4f700e498c178a637c29d6cc78ab8c267c > src/kcollapsiblegroupbox.cpp 273110e995cb25f28a815cb28125c4678ca2ab28 > tests/kcollapsiblegroupboxtest.cpp 5a2900e63e42fa81f909c7d1fff0d07033edb025 > > Diff: https://git.reviewboard.kde.org/r/129405/diff/ > > > Testing > --- > > Test app has been expanded with an hidden checkbox > > * Make sure the new checkbox stays hidden after expanding the groupbox. > * With both groups collapsed, make sure the tab-focus goes from the first > group to the second one (skipping the 7 checkboxes in the first group). > > > Thanks, > > Elvis Angelaccio > >
Re: Review Request 129251: Remove Shift+Del as secondary shortcut for Cut
> On Okt. 24, 2016, 11 vorm., Albert Astals Cid wrote: > > -1 it's an established shortcut for cut too. even > > https://en.wikipedia.org/wiki/Table_of_keyboard_shortcuts lists it in "Cut > > the selection and store it in the clipboard" > > Elvis Angelaccio wrote: > Ah, sorry I didn't know that. Still, the conflict is caused by kconfig > itself and it's being worked around by applications. What should we do then? > > Heiko Tietze wrote: > This question was asked last year on the mailing list > https://mail.kde.org/pipermail/kde-guidelines/2015-June/thread.html#877. > Shift+Del dates back to the medieval ages but was never reverted and is still > in our HIG. The discussion didn't end with a solution. And I strongly suggest > to have a generic solution that works in all programs. Btw, Krusader uses > Shift+Del for permanently delete files. > > Elvis Angelaccio wrote: > Thanks for the link. So if I understand the issue correctly, we should > first agree upon another primary shortcut for "Force Delete" and replace > Shift+Del with that, at least in KConfig. What about Meta+Del like Thomas > suggested? > > Heiko Tietze wrote: > 1. Do we want to retain IBM shortcuts used for decades? Yes, keep > shift+del as alternative to ctrl+X; No, drop the unknown shortcut. > 2a. If 1)=Yes, do we want to have a similar shortcut for permanently > delete? Yes, meta+del/alt+del... No, use something completely different and > app specific > 2b. If 1)=No, do we want to have an easy shortcut for destructive > functions? Yes, use ctrl+del for convenience. No, make it hard to > unintentionally run destructive functions; rather use > shift+alt+del/ctrl+alt+del or the like. > > (My take is 2b and No; but it has to work in _every_ KDE app unless the > app defines its own behavior) > > Albert Astals Cid wrote: > My suggestion is: > > * Cut is Ctrl+X and Shift+Delete by default > * DeleteFile is Shift+Delete by default > > **if** both Cut and DeleteFile are used in the same action collection we > disable Shift+Delete from Cut (only if it's there by default and it was not > the user that set it on purpose) > > That should be *doable* hopefully. > > Mark Gaiser wrote: > I would not do that. It would be unexpected behavior when the user > deletes a file (in for instance dolphin) and expects it to end up in the > trash. With your suggestion it would be permanantly deleted. > Regardless of the shortcut, every other modern OS (win and mac) uses the > delete key to "move to trash" and a +delete key to permanantly > remove the file. > > Lets stick to the established commands over time where Shift+del is > permanent delete, not cut text. Other apps should _not_ use that key > combination for a task that isn't permanently deleting something. > > Just my 2ct. > > Heiko Tietze wrote: > Let's do a quick poll: > https://plus.google.com/107566594492891737454/posts/QJzpApTeSFg > > Albert Astals Cid wrote: > > I would not do that. It would be unexpected behavior when the user > deletes a file (in for instance dolphin) and expects it to end up in the > trash. With your suggestion it would be permanantly deleted. > > Why would with my suggestion end up permanently deleted instead of trash? > > Albert Astals Cid wrote: > > Lets stick to the established commands over time where Shift+del is > permanent delete > > I don't know man, i already cited wikipedia proving you wrong, what more > do you want? > > Luigi Toscano wrote: > IMHO the poll should be better placed for example on forums.kde.org, or > woth some tool that does not require a google account. > > That said, even if different, we should have a global shortcut for > permanent deletion as now, or we will end up with bugs to have all apps > provide the same shortcut anyway. > > Heiko Tietze wrote: > >IMHO the poll should be better placed for example on forums.kde.org > > Don't understand a quick poll like this as a final and definite survey. > It's quickly done, addresses a lot of average users (guess more than on the > forums or via blog->planet), and adds one more insight. > > Mark Gaiser wrote: > Hi Albert, > > You said "DeleteFile is Shift+Delete by default" which lead me to think > that pressing "delete" was going to do that action. Sorry my bad. > > Regarding the shift+delete and wikipedia. I highly doubt what wikipedia > says is true. I know with 100% certainty that shift+delete is permanently &
Re: Review Request 129251: Remove Shift+Del as secondary shortcut for Cut
> On Okt. 24, 2016, 11 vorm., Albert Astals Cid wrote: > > -1 it's an established shortcut for cut too. even > > https://en.wikipedia.org/wiki/Table_of_keyboard_shortcuts lists it in "Cut > > the selection and store it in the clipboard" > > Elvis Angelaccio wrote: > Ah, sorry I didn't know that. Still, the conflict is caused by kconfig > itself and it's being worked around by applications. What should we do then? > > Heiko Tietze wrote: > This question was asked last year on the mailing list > https://mail.kde.org/pipermail/kde-guidelines/2015-June/thread.html#877. > Shift+Del dates back to the medieval ages but was never reverted and is still > in our HIG. The discussion didn't end with a solution. And I strongly suggest > to have a generic solution that works in all programs. Btw, Krusader uses > Shift+Del for permanently delete files. > > Elvis Angelaccio wrote: > Thanks for the link. So if I understand the issue correctly, we should > first agree upon another primary shortcut for "Force Delete" and replace > Shift+Del with that, at least in KConfig. What about Meta+Del like Thomas > suggested? > > Heiko Tietze wrote: > 1. Do we want to retain IBM shortcuts used for decades? Yes, keep > shift+del as alternative to ctrl+X; No, drop the unknown shortcut. > 2a. If 1)=Yes, do we want to have a similar shortcut for permanently > delete? Yes, meta+del/alt+del... No, use something completely different and > app specific > 2b. If 1)=No, do we want to have an easy shortcut for destructive > functions? Yes, use ctrl+del for convenience. No, make it hard to > unintentionally run destructive functions; rather use > shift+alt+del/ctrl+alt+del or the like. > > (My take is 2b and No; but it has to work in _every_ KDE app unless the > app defines its own behavior) > > Albert Astals Cid wrote: > My suggestion is: > > * Cut is Ctrl+X and Shift+Delete by default > * DeleteFile is Shift+Delete by default > > **if** both Cut and DeleteFile are used in the same action collection we > disable Shift+Delete from Cut (only if it's there by default and it was not > the user that set it on purpose) > > That should be *doable* hopefully. > > Mark Gaiser wrote: > I would not do that. It would be unexpected behavior when the user > deletes a file (in for instance dolphin) and expects it to end up in the > trash. With your suggestion it would be permanantly deleted. > Regardless of the shortcut, every other modern OS (win and mac) uses the > delete key to "move to trash" and a +delete key to permanantly > remove the file. > > Lets stick to the established commands over time where Shift+del is > permanent delete, not cut text. Other apps should _not_ use that key > combination for a task that isn't permanently deleting something. > > Just my 2ct. > > Heiko Tietze wrote: > Let's do a quick poll: > https://plus.google.com/107566594492891737454/posts/QJzpApTeSFg > > Albert Astals Cid wrote: > > I would not do that. It would be unexpected behavior when the user > deletes a file (in for instance dolphin) and expects it to end up in the > trash. With your suggestion it would be permanantly deleted. > > Why would with my suggestion end up permanently deleted instead of trash? > > Albert Astals Cid wrote: > > Lets stick to the established commands over time where Shift+del is > permanent delete > > I don't know man, i already cited wikipedia proving you wrong, what more > do you want? > > Luigi Toscano wrote: > IMHO the poll should be better placed for example on forums.kde.org, or > woth some tool that does not require a google account. > > That said, even if different, we should have a global shortcut for > permanent deletion as now, or we will end up with bugs to have all apps > provide the same shortcut anyway. >IMHO the poll should be better placed for example on forums.kde.org Don't understand a quick poll like this as a final and definite survey. It's quickly done, addresses a lot of average users (guess more than on the forums or via blog->planet), and adds one more insight. - Heiko --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/129251/#review100230 --- On Okt. 24, 2016, 10:47 vorm., Elvis Angelaccio wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://git.re
Re: Review Request 129251: Remove Shift+Del as secondary shortcut for Cut
> On Okt. 24, 2016, 11 vorm., Albert Astals Cid wrote: > > -1 it's an established shortcut for cut too. even > > https://en.wikipedia.org/wiki/Table_of_keyboard_shortcuts lists it in "Cut > > the selection and store it in the clipboard" > > Elvis Angelaccio wrote: > Ah, sorry I didn't know that. Still, the conflict is caused by kconfig > itself and it's being worked around by applications. What should we do then? > > Heiko Tietze wrote: > This question was asked last year on the mailing list > https://mail.kde.org/pipermail/kde-guidelines/2015-June/thread.html#877. > Shift+Del dates back to the medieval ages but was never reverted and is still > in our HIG. The discussion didn't end with a solution. And I strongly suggest > to have a generic solution that works in all programs. Btw, Krusader uses > Shift+Del for permanently delete files. > > Elvis Angelaccio wrote: > Thanks for the link. So if I understand the issue correctly, we should > first agree upon another primary shortcut for "Force Delete" and replace > Shift+Del with that, at least in KConfig. What about Meta+Del like Thomas > suggested? > > Heiko Tietze wrote: > 1. Do we want to retain IBM shortcuts used for decades? Yes, keep > shift+del as alternative to ctrl+X; No, drop the unknown shortcut. > 2a. If 1)=Yes, do we want to have a similar shortcut for permanently > delete? Yes, meta+del/alt+del... No, use something completely different and > app specific > 2b. If 1)=No, do we want to have an easy shortcut for destructive > functions? Yes, use ctrl+del for convenience. No, make it hard to > unintentionally run destructive functions; rather use > shift+alt+del/ctrl+alt+del or the like. > > (My take is 2b and No; but it has to work in _every_ KDE app unless the > app defines its own behavior) > > Albert Astals Cid wrote: > My suggestion is: > > * Cut is Ctrl+X and Shift+Delete by default > * DeleteFile is Shift+Delete by default > > **if** both Cut and DeleteFile are used in the same action collection we > disable Shift+Delete from Cut (only if it's there by default and it was not > the user that set it on purpose) > > That should be *doable* hopefully. > > Mark Gaiser wrote: > I would not do that. It would be unexpected behavior when the user > deletes a file (in for instance dolphin) and expects it to end up in the > trash. With your suggestion it would be permanantly deleted. > Regardless of the shortcut, every other modern OS (win and mac) uses the > delete key to "move to trash" and a +delete key to permanantly > remove the file. > > Lets stick to the established commands over time where Shift+del is > permanent delete, not cut text. Other apps should _not_ use that key > combination for a task that isn't permanently deleting something. > > Just my 2ct. Let's do a quick poll: https://plus.google.com/107566594492891737454/posts/QJzpApTeSFg - Heiko --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/129251/#review100230 --- On Okt. 24, 2016, 10:47 vorm., Elvis Angelaccio wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/129251/ > --- > > (Updated Okt. 24, 2016, 10:47 vorm.) > > > Review request for KDE Frameworks, KDE Usability and Matthew Dawson. > > > Bugs: 357747 > https://bugs.kde.org/show_bug.cgi?id=357747 > > > Repository: kconfig > > > Description > --- > > This patch removes Shift+Del as secondary shortcut for the Cut action. This > shortcut was set back in 2001. > > Reasons for removing it: > > * The expected standard behavior for this shortcut is "Permanently delete" > * For the reason above, it is also set as primary shortcut for the > `DeleteFile` action. This causes conflicts in applications. > * For the reason above, many applications (e.g. Dolphin or Digikam) already > resolve this conflict on their own. > > Credits to Jan for the investigation: > https://bugs.kde.org/show_bug.cgi?id=347373#c2 > > > Diffs > - > > src/gui/kstandardshortcut.cpp 92eb091382c7ab2110240cef21f29268be787250 > > Diff: https://git.reviewboard.kde.org/r/129251/diff/ > > > Testing > --- > > Using Shift+Del in Gwenview now works as expected. > > > Thanks, > > Elvis Angelaccio > >
Re: Review Request 129251: Remove Shift+Del as secondary shortcut for Cut
> On Okt. 24, 2016, 11 vorm., Albert Astals Cid wrote: > > -1 it's an established shortcut for cut too. even > > https://en.wikipedia.org/wiki/Table_of_keyboard_shortcuts lists it in "Cut > > the selection and store it in the clipboard" > > Elvis Angelaccio wrote: > Ah, sorry I didn't know that. Still, the conflict is caused by kconfig > itself and it's being worked around by applications. What should we do then? > > Heiko Tietze wrote: > This question was asked last year on the mailing list > https://mail.kde.org/pipermail/kde-guidelines/2015-June/thread.html#877. > Shift+Del dates back to the medieval ages but was never reverted and is still > in our HIG. The discussion didn't end with a solution. And I strongly suggest > to have a generic solution that works in all programs. Btw, Krusader uses > Shift+Del for permanently delete files. > > Elvis Angelaccio wrote: > Thanks for the link. So if I understand the issue correctly, we should > first agree upon another primary shortcut for "Force Delete" and replace > Shift+Del with that, at least in KConfig. What about Meta+Del like Thomas > suggested? 1. Do we want to retain IBM shortcuts used for decades? Yes, keep shift+del as alternative to ctrl+X; No, drop the unknown shortcut. 2a. If 1)=Yes, do we want to have a similar shortcut for permanently delete? Yes, meta+del/alt+del... No, use something completely different and app specific 2b. If 1)=No, do we want to have an easy shortcut for destructive functions? Yes, use ctrl+del for convenience. No, make it hard to unintentionally run destructive functions; rather use shift+alt+del/ctrl+alt+del or the like. (My take is 2b and No; but it has to work in _every_ KDE app unless the app defines its own behavior) - Heiko --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/129251/#review100230 --- On Okt. 24, 2016, 10:47 vorm., Elvis Angelaccio wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/129251/ > --- > > (Updated Okt. 24, 2016, 10:47 vorm.) > > > Review request for KDE Frameworks, KDE Usability and Matthew Dawson. > > > Bugs: 357747 > https://bugs.kde.org/show_bug.cgi?id=357747 > > > Repository: kconfig > > > Description > --- > > This patch removes Shift+Del as secondary shortcut for the Cut action. This > shortcut was set back in 2001. > > Reasons for removing it: > > * The expected standard behavior for this shortcut is "Permanently delete" > * For the reason above, it is also set as primary shortcut for the > `DeleteFile` action. This causes conflicts in applications. > * For the reason above, many applications (e.g. Dolphin or Digikam) already > resolve this conflict on their own. > > Credits to Jan for the investigation: > https://bugs.kde.org/show_bug.cgi?id=347373#c2 > > > Diffs > - > > src/gui/kstandardshortcut.cpp 92eb091382c7ab2110240cef21f29268be787250 > > Diff: https://git.reviewboard.kde.org/r/129251/diff/ > > > Testing > --- > > Using Shift+Del in Gwenview now works as expected. > > > Thanks, > > Elvis Angelaccio > >
Re: Review Request 129251: Remove Shift+Del as secondary shortcut for Cut
> On Okt. 24, 2016, 11 vorm., Albert Astals Cid wrote: > > -1 it's an established shortcut for cut too. even > > https://en.wikipedia.org/wiki/Table_of_keyboard_shortcuts lists it in "Cut > > the selection and store it in the clipboard" > > Elvis Angelaccio wrote: > Ah, sorry I didn't know that. Still, the conflict is caused by kconfig > itself and it's being worked around by applications. What should we do then? This question was asked last year on the mailing list https://mail.kde.org/pipermail/kde-guidelines/2015-June/thread.html#877. Shift+Del dates back to the medieval ages but was never reverted and is still in our HIG. The discussion didn't end with a solution. And I strongly suggest to have a generic solution that works in all programs. Btw, Krusader uses Shift+Del for permanently delete files. - Heiko --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/129251/#review100230 --- On Okt. 24, 2016, 10:47 vorm., Elvis Angelaccio wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/129251/ > --- > > (Updated Okt. 24, 2016, 10:47 vorm.) > > > Review request for KDE Frameworks, KDE Usability and Matthew Dawson. > > > Bugs: 357747 > https://bugs.kde.org/show_bug.cgi?id=357747 > > > Repository: kconfig > > > Description > --- > > This patch removes Shift+Del as secondary shortcut for the Cut action. This > shortcut was set back in 2001. > > Reasons for removing it: > > * The expected standard behavior for this shortcut is "Permanently delete" > * For the reason above, it is also set as primary shortcut for the > `DeleteFile` action. This causes conflicts in applications. > * For the reason above, many applications (e.g. Dolphin or Digikam) already > resolve this conflict on their own. > > Credits to Jan for the investigation: > https://bugs.kde.org/show_bug.cgi?id=347373#c2 > > > Diffs > - > > src/gui/kstandardshortcut.cpp 92eb091382c7ab2110240cef21f29268be787250 > > Diff: https://git.reviewboard.kde.org/r/129251/diff/ > > > Testing > --- > > Using Shift+Del in Gwenview now works as expected. > > > Thanks, > > Elvis Angelaccio > >
Re: Review Request 128680: [KCharSelect] Add ToolButton for disabling characters not available in selected font
> On Sept. 4, 2016, 2:34 vorm., Christoph Feck wrote: > > Andreas, any idea which icon the action could use? > > Andreas Kainz wrote: > I would use visibility and hint to show/hide the font's that are not > available in the selected font. will the font change to "not selected" grayed > out when you show all characters also the ones that aren't available? > > Christoph Feck wrote: > "visibility" and "hint" is the same icon, but one of them crossed-out. If > I use both of them, it is confusing, because the tool button itself has a > selected state (sunken frame and selected background). > > So I see two options: > 1) use the "hint" icon, and make the button unselected by default. > Selecting it, the unavailable characters are then grayed out. > 2) use the "visibility" icon, and make the button selected by default. > Unselecting it, the unavailable characters are then grayed out. > > Which would you prefer? The code currently uses the unselected button for > the default (do not gray-out unavailable characters) but I can reverse it. > > Regarding your question, I have difficulties to parse it. Let me try to > answer from what I understood: If font-merging is enabled, but none of the > installed fonts have glyphs for a specific character, then this character is > rendered as an rectangle box. The character cell is not disabled, so you will > be able to select the character (e.g. to copy/paste it), even if you have no > font with this character. Third option is to have a less obtrusive visualization (going back to your first proposal) that makes the toggle button obsolete. But I have no idea how to do so since graying out is the opposite of unobtrusive. It depends heavily on the workflow meaning whether or not users should be able to deal with those characters at all. - Heiko --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/128680/#review98855 --- On Sept. 1, 2016, 4:45 nachm., Christoph Feck wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/128680/ > --- > > (Updated Sept. 1, 2016, 4:45 nachm.) > > > Review request for KDE Frameworks, KDE Usability and Andreas Kainz. > > > Bugs: 97420 > https://bugs.kde.org/show_bug.cgi?id=97420 > > > Repository: kwidgetsaddons > > > Description > --- > > Adds a toolbutton to the right of the font combobox to control the "font > merging" property of QFont. When selected, characters which are not available > in the font are disabled. > > Seeking feedback about: > - placement of the button > - used icon (currently "format-text-strikethrough"; it shows an S character > which could stand for "substitution") > - action name and tooltip (see line 477 and 479) > - and code changes ;) > > I was unsure if the toolbutton could have a popup menu showing three options: > 1) show characters from all fonts > 2) disable characters not available in font > 3) hide characters not available in font > > but I did not implement it, because it felt odd not being able to see _which_ > characters are not available in the font. > > > Diffs > - > > src/kcharselect.cpp 30ddd34 > src/kcharselect_p.h db0259c > > Diff: https://git.reviewboard.kde.org/r/128680/diff/ > > > Testing > --- > > > File Attachments > > > Character table with font substitution (default) > > https://git.reviewboard.kde.org/media/uploaded/files/2016/08/15/7220dddb-ca1b-42a2-966c-791925156baf__snapshot1.png > Character table with dimming substituted characters > > https://git.reviewboard.kde.org/media/uploaded/files/2016/08/15/67c02866-b12c-4080-b6a4-22e29006448b__snapshot2.png > > > Thanks, > > Christoph Feck > >
Re: Review Request 128680: [KCharSelect] Add ToolButton for dimming characters not available in selected font
> On Aug. 25, 2016, 1:59 a.m., Christoph Feck wrote: > > Ping? Can someone please review? It already missed the tr deadline for > > 5.26, but maybe we can get this into 5.27. As far as I understand the change it will show tofu'ed characters in their intended appearance (the example is misleading here) but disable the item so it looks differently and cannot be selected. * The dialog is quite confusing right now. Since the font name is selected after this pseudo-hierarchical organization, along with the font size that is rather a zoom, I would say adding another button is not diminishing the overall UX. Users will basically search and not browse all the fancy characters. And I agree that a split- or menu button is not needed. * The icon have to be something else, of course. You may ask Andreas Kainz for that. * For the text you could say "Highlight applicable characters" and "The currently selected font may not include all unicode characters, which will be dimmed when this option is checked.". But take this as just an idea. * Btw: What will be the default? Suggest On. * Code: - + What happens when you search for something with having the dim feature enabled? I recommend to also not hide but dim those results. + How do you discriminate the non-applicable chars from the non-printable? o Today I can select the alien chars and add them to the clipboard. Perhaps my target has a different font and for some reason I don't want to change it. This workflow will not be supported anymore when the items are disabled. Very far-fetched workflow, however. Just to mention. - Heiko --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/128680/#review98615 --- On Aug. 15, 2016, 3:12 a.m., Christoph Feck wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/128680/ > --- > > (Updated Aug. 15, 2016, 3:12 a.m.) > > > Review request for KDE Frameworks and KDE Usability. > > > Bugs: 97420 > https://bugs.kde.org/show_bug.cgi?id=97420 > > > Repository: kwidgetsaddons > > > Description > --- > > Adds a toolbutton to the right of the font combobox to control the "font > merging" property of QFont. When selected, characters which are not available > in the font are dimmed (i.e. look disabled). > > Seeking feedback about: > - placement of the button > - used icon (currently "format-text-strikethrough"; it shows an S character > which could stand for "substitution") > - action name and tooltip (see line 477 and 479) > - and code changes ;) > > I was unsure if the toolbutton could have a popup menu showing three options: > 1) show characters from all fonts > 2) dim characters not available in font > 3) hide characters not available in font > > but I did not implement it, because it felt odd not being able to see _which_ > characters are not available in the font. > > > Diffs > - > > src/kcharselect.cpp 45c1e99 > > Diff: https://git.reviewboard.kde.org/r/128680/diff/ > > > Testing > --- > > > File Attachments > > > Character table with font substitution (default) > > https://git.reviewboard.kde.org/media/uploaded/files/2016/08/15/7220dddb-ca1b-42a2-966c-791925156baf__snapshot1.png > Character table with dimming substituted characters > > https://git.reviewboard.kde.org/media/uploaded/files/2016/08/15/67c02866-b12c-4080-b6a4-22e29006448b__snapshot2.png > > > Thanks, > > Christoph Feck > >
Re: Review Request 128019: Remove F1 as standard shortcut for Help
> On May 26, 2016, 7:49 a.m., Heiko Tietze wrote: > > What function would you like to invoke with F1? Close app? > > Albert Astals Cid wrote: > None, give it back to the apps so they can do whatever it wants with it, > like let's say F2 or F9 It was a rhetorical question. Default keys must not get assigned freely. Especially F1 is burnt forever. BTW: F2 is used for rename, or rather start editing. - Heiko --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/128019/#review95809 --- On May 26, 2016, 10:04 p.m., Albert Astals Cid wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/128019/ > --- > > (Updated May 26, 2016, 10:04 p.m.) > > > Review request for KDE Frameworks and KDE Usability. > > > Repository: kconfig > > > Description > --- > > F1 is too important and too easy to trigger for something like Help, that be > honest you don't need a shortcut for (since you don't invoke Help that often). > > > Diffs > - > > src/gui/kstandardshortcut.cpp 6be6309 > > Diff: https://git.reviewboard.kde.org/r/128019/diff/ > > > Testing > --- > > > Thanks, > > Albert Astals Cid > > ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 128019: Remove F1 as standard shortcut for Help
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/128019/#review95809 --- What function would you like to invoke with F1? Close app? - Heiko Tietze On May 25, 2016, 11:01 p.m., Albert Astals Cid wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/128019/ > --- > > (Updated May 25, 2016, 11:01 p.m.) > > > Review request for KDE Frameworks and KDE Usability. > > > Repository: kconfig > > > Description > --- > > F1 is too important and too easy to trigger for something like Help, that be > honest you don't need a shortcut for (since you don't invoke Help that often). > > > Diffs > - > > src/gui/kstandardshortcut.cpp 6be6309 > > Diff: https://git.reviewboard.kde.org/r/128019/diff/ > > > Testing > --- > > > Thanks, > > Albert Astals Cid > > ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 126523: Use a KMessageWidget in KNewPasswordDialog
> On Feb. 29, 2016, 10:23 p.m., Andreas Kainz wrote: > > hi, heiko fill a bug report cause you cant see the x icon > > https://bugs.kde.org/show_bug.cgi?id=357210 but I am not sure that > > knewpassworddialog use an icon cause there is no x icon. is this icon used > > from KNewPasswordDialog? can it be colored in white #f2f2f2. > > > > thanks for the feedback. maybe you can answer on the bug report. > > Elvis Angelaccio wrote: > Hi. The problem is the X icon/button in this screenshot: > https://git.reviewboard.kde.org/r/126523/file/2643/ > > Andreas Kainz wrote: > yes is it really an icon? > > Elvis Angelaccio wrote: > Mmm you're right. Doesn't look like an icon from Breeze: > > > `closeAction->setIcon(q->style()->standardIcon(QStyle::SP_DialogCloseButton));` > (from kmessagewidget.cpp) > > So it's an icon coming from the `QStyle`. I guess you should ask some > Plasma guy to have a look... What else if not an icon? Anyway it was removed from the dialog - and probably from all message panels as well. - Heiko --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/126523/#review92946 --- On Feb. 1, 2016, 6:47 p.m., Elvis Angelaccio wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/126523/ > --- > > (Updated Feb. 1, 2016, 6:47 p.m.) > > > Review request for KDE Frameworks, KDE Usability, Kai Uwe Broulik, Christoph > Feck, and David Faure. > > > Repository: kwidgetsaddons > > > Description > --- > > Currently a KNewPasswordDialog makes use of a KTitleWidget to display > messages to the user about the password status (e.g. "password too short", > etc.). This looks out of place, and so does the associated icon (see > screenshots in RR 125619: https://git.reviewboard.kde.org/r/125619/ ) > > This patch replaces the KTitleWidget with a KMessageWidget. I also > "downgraded" some of the previous "error" red icons to a > `KMessageWidget::Warning` type (the orange one in the screenshots), because > those kind of messages may be displayed before the user even started typing > something as password. > > > Diffs > - > > src/knewpassworddialog.cpp 1d7ca33ac010a2a1d0971a152d0bef23f78c414d > src/knewpassworddialog.ui 2b492d2a2984296105959d366a1d5306c80af54f > > Diff: https://git.reviewboard.kde.org/r/126523/diff/ > > > Testing > --- > > The KMessageWidgets behaves exactly like the KTitleWidget before: initially > is hidden, then is displayed as soon as the user interacts with the password > fields. > > > File Attachments > > > pwd-dialog-1.png > > https://git.reviewboard.kde.org/media/uploaded/files/2015/12/26/f4870422-d064-4da9-b216-056fe5bec665__pwd-dialog-1.png > pwd-dialog-2.png > > https://git.reviewboard.kde.org/media/uploaded/files/2015/12/26/3d8b6c2c-6717-4608-b61c-18ef9b224706__pwd-dialog-2.png > pwd-dialog-3.png > > https://git.reviewboard.kde.org/media/uploaded/files/2015/12/26/3a71ff56-f540-405a-9f3e-868e8d652687__pwd-dialog-3.png > > > Thanks, > > Elvis Angelaccio > > ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 126523: Use a KMessageWidget in KNewPasswordDialog
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/126523/#review90137 --- Ship it! Perfect use of the message panel. However, the red close icon does not work (well) with colored backgrounds. - Heiko Tietze On Dec. 26, 2015, 10:18 a.m., Elvis Angelaccio wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/126523/ > --- > > (Updated Dec. 26, 2015, 10:18 a.m.) > > > Review request for KDE Frameworks, KDE Usability, Kai Uwe Broulik, and > Christoph Feck. > > > Repository: kwidgetsaddons > > > Description > --- > > Currently a KNewPasswordDialog makes use of a KTitleWidget to display > messages to the user about the password status (e.g. "password too short", > etc.). This looks out of place, and so does the associated icon (see > screenshots in RR 125619: https://git.reviewboard.kde.org/r/125619/ ) > > This patch replaces the KTitleWidget with a KMessageWidget. I also > "downgraded" some of the previous "error" red icons to a > `KMessageWidget::Warning` type (the orange one in the screenshots), because > those kind of messages may be displayed before the user even started typing > something as password. > > > Diffs > - > > src/knewpassworddialog.cpp 1d7ca33ac010a2a1d0971a152d0bef23f78c414d > src/knewpassworddialog.ui 2b492d2a2984296105959d366a1d5306c80af54f > > Diff: https://git.reviewboard.kde.org/r/126523/diff/ > > > Testing > --- > > The KMessageWidgets behaves exactly like the KTitleWidget before: initially > is hidden, then is displayed as soon as the user interacts with the password > fields. > > > File Attachments > > > pwd-dialog-1.png > > https://git.reviewboard.kde.org/media/uploaded/files/2015/12/26/f4870422-d064-4da9-b216-056fe5bec665__pwd-dialog-1.png > pwd-dialog-2.png > > https://git.reviewboard.kde.org/media/uploaded/files/2015/12/26/3d8b6c2c-6717-4608-b61c-18ef9b224706__pwd-dialog-2.png > pwd-dialog-3.png > > https://git.reviewboard.kde.org/media/uploaded/files/2015/12/26/3a71ff56-f540-405a-9f3e-868e8d652687__pwd-dialog-3.png > > > Thanks, > > Elvis Angelaccio > > ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-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 > > ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 126523: Use a KMessageWidget in KNewPasswordDialog
> On Dec. 27, 2015, 9:21 a.m., Heiko Tietze wrote: > > Perfect use of the message panel. However, the red close icon does not work > > (well) with colored backgrounds. > > Kai Uwe Broulik wrote: > Do we even need the close button to begin with? It's not like it > appearing is really under your direct control anyway. > > Thomas Pfeiffer wrote: > I agree with Kai: No need for a close button there, since the message > widget disappears anyway as soon as the user fixes the problem. Not so sure. Popups should have means to get closed manually. Otherwise you may argue that plasma notifications also do not need any close interaction. And the HIG talks about the option to dismiss the panel. So either we change it everywhere and update the HIG or we find a good reason why it is not neccessary here. My position is clear: Don't use color as the primary indicator, i.e. do not color the whole icon. Colored decorations are okay. - Heiko --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/126523/#review90137 --- On Dec. 26, 2015, 10:18 a.m., Elvis Angelaccio wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/126523/ > --- > > (Updated Dec. 26, 2015, 10:18 a.m.) > > > Review request for KDE Frameworks, KDE Usability, Kai Uwe Broulik, and > Christoph Feck. > > > Repository: kwidgetsaddons > > > Description > --- > > Currently a KNewPasswordDialog makes use of a KTitleWidget to display > messages to the user about the password status (e.g. "password too short", > etc.). This looks out of place, and so does the associated icon (see > screenshots in RR 125619: https://git.reviewboard.kde.org/r/125619/ ) > > This patch replaces the KTitleWidget with a KMessageWidget. I also > "downgraded" some of the previous "error" red icons to a > `KMessageWidget::Warning` type (the orange one in the screenshots), because > those kind of messages may be displayed before the user even started typing > something as password. > > > Diffs > - > > src/knewpassworddialog.cpp 1d7ca33ac010a2a1d0971a152d0bef23f78c414d > src/knewpassworddialog.ui 2b492d2a2984296105959d366a1d5306c80af54f > > Diff: https://git.reviewboard.kde.org/r/126523/diff/ > > > Testing > --- > > The KMessageWidgets behaves exactly like the KTitleWidget before: initially > is hidden, then is displayed as soon as the user interacts with the password > fields. > > > File Attachments > > > pwd-dialog-1.png > > https://git.reviewboard.kde.org/media/uploaded/files/2015/12/26/f4870422-d064-4da9-b216-056fe5bec665__pwd-dialog-1.png > pwd-dialog-2.png > > https://git.reviewboard.kde.org/media/uploaded/files/2015/12/26/3d8b6c2c-6717-4608-b61c-18ef9b224706__pwd-dialog-2.png > pwd-dialog-3.png > > https://git.reviewboard.kde.org/media/uploaded/files/2015/12/26/3a71ff56-f540-405a-9f3e-868e8d652687__pwd-dialog-3.png > > > Thanks, > > Elvis Angelaccio > > ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 125619: Refactor KNewPasswordDialog class
> On Nov. 16, 2015, 12:56 p.m., Heiko Tietze wrote: > > Ship It! > > Elvis Angelaccio wrote: > I'm assuming that yours is a ship-it only from the usability side, right? Yes, UX only. No design comment from my side, but still with all of the previous considerations. - Heiko --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/125619/#review88425 --- On Nov. 19, 2015, 11:04 a.m., Elvis Angelaccio wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/125619/ > --- > > (Updated Nov. 19, 2015, 11:04 a.m.) > > > Review request for KDE Frameworks and Christoph Feck. > > > Repository: kwidgetsaddons > > > Description > --- > > Follow-up of the KNewPasswordWidget review. > By introducing a KNewPasswordWidget in the .ui file, we can: > > - remove the code that has been moved to KNewPasswordWidget > - enable the KNewPasswordWidget additional features > > The only feature that is currently not available is the ability to remove the > strength bar. Do we want to allow developers to show a KNewPasswordDialog > without a strenght bar? > > > Diffs > - > > src/knewpassworddialog.h 1ac7b2151f1e88681a15ce21465449cedb871f1e > src/knewpassworddialog.cpp 9b79524f03937dbd2da04ddca6bccc29825b044b > src/knewpassworddialog.ui 55a1f62cf4ba6d6c87b2c47742ba3bcd531ebfe8 > > Diff: https://git.reviewboard.kde.org/r/125619/diff/ > > > Testing > --- > > Trying to insert a password which is too short or too weak or empty, works as > expected. > > > File Attachments > > > knewpassworddialog1.png > > https://git.reviewboard.kde.org/media/uploaded/files/2015/10/13/62bf21f6-1dcf-46c3-8b1d-146500b5f629__knewpassworddialog1.png > knewpassworddialog2.png > > https://git.reviewboard.kde.org/media/uploaded/files/2015/10/13/b2e2666f-ce19-4df3-b6ba-25c13fc370ae__knewpassworddialog2.png > knewpassworddialog3.png > > https://git.reviewboard.kde.org/media/uploaded/files/2015/10/13/b9536088-0cc4-470b-a211-6db4ca79aa2f__knewpassworddialog3.png > knewpassworddialog4.png > > https://git.reviewboard.kde.org/media/uploaded/files/2015/10/13/4f826716-9ed2-4ecb-8cbe-4fb50abf1086__knewpassworddialog4.png > > > Thanks, > > Elvis Angelaccio > > ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 125619: Refactor KNewPasswordDialog class
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/125619/#review88425 --- Ship it! Ship It! - Heiko Tietze On Okt. 13, 2015, 1:33 nachm., Elvis Angelaccio wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/125619/ > --- > > (Updated Okt. 13, 2015, 1:33 nachm.) > > > Review request for KDE Frameworks, KDE Usability, Christoph Feck, and David > Faure. > > > Repository: kwidgetsaddons > > > Description > --- > > Follow-up of the KNewPasswordWidget review. > By introducing a KNewPasswordWidget in the .ui file, we can: > > - remove the code that has been moved to KNewPasswordWidget > - enable the KNewPasswordWidget additional features > > The only feature that is currently not available is the ability to remove the > strength bar. Do we want to allow developers to show a KNewPasswordDialog > without a strenght bar? > > > Diffs > - > > src/knewpassworddialog.h 1ac7b2151f1e88681a15ce21465449cedb871f1e > src/knewpassworddialog.cpp bd7459acf3c72bc6dc0711da6086213d5111d5c3 > src/knewpassworddialog.ui 55a1f62cf4ba6d6c87b2c47742ba3bcd531ebfe8 > > Diff: https://git.reviewboard.kde.org/r/125619/diff/ > > > Testing > --- > > Trying to insert a password which is too short or too weak or empty, works as > expected. > > > File Attachments > > > knewpassworddialog1.png > > https://git.reviewboard.kde.org/media/uploaded/files/2015/10/13/62bf21f6-1dcf-46c3-8b1d-146500b5f629__knewpassworddialog1.png > knewpassworddialog2.png > > https://git.reviewboard.kde.org/media/uploaded/files/2015/10/13/b2e2666f-ce19-4df3-b6ba-25c13fc370ae__knewpassworddialog2.png > knewpassworddialog3.png > > https://git.reviewboard.kde.org/media/uploaded/files/2015/10/13/b9536088-0cc4-470b-a211-6db4ca79aa2f__knewpassworddialog3.png > knewpassworddialog4.png > > https://git.reviewboard.kde.org/media/uploaded/files/2015/10/13/4f826716-9ed2-4ecb-8cbe-4fb50abf1086__knewpassworddialog4.png > > > Thanks, > > Elvis Angelaccio > > ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 125619: Refactor KNewPasswordDialog class
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/125619/#review86807 --- Nice work. I would add information where the request comes from (e.g. "Dolphin wants to create a folder") and perhaps what account is referenced (e.g. or user's email address at the web page). The visual esthetics, in particular the big match icon, may be appreciated by someone else. - Heiko Tietze On Okt. 13, 2015, 1:33 nachm., Elvis Angelaccio wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/125619/ > --- > > (Updated Okt. 13, 2015, 1:33 nachm.) > > > Review request for KDE Frameworks, KDE Usability, Christoph Feck, and David > Faure. > > > Repository: kwidgetsaddons > > > Description > --- > > Follow-up of the KNewPasswordWidget review. > By introducing a KNewPasswordWidget in the .ui file, we can: > > - remove the code that has been moved to KNewPasswordWidget > - enable the KNewPasswordWidget additional features > > The only feature that is currently not available is the ability to remove the > strength bar. Do we want to allow developers to show a KNewPasswordDialog > without a strenght bar? > > > Diffs > - > > src/knewpassworddialog.h 1ac7b2151f1e88681a15ce21465449cedb871f1e > src/knewpassworddialog.cpp bd7459acf3c72bc6dc0711da6086213d5111d5c3 > src/knewpassworddialog.ui 55a1f62cf4ba6d6c87b2c47742ba3bcd531ebfe8 > > Diff: https://git.reviewboard.kde.org/r/125619/diff/ > > > Testing > --- > > Trying to insert a password which is too short or too weak or empty, works as > expected. > > > File Attachments > > > knewpassworddialog1.png > > https://git.reviewboard.kde.org/media/uploaded/files/2015/10/13/62bf21f6-1dcf-46c3-8b1d-146500b5f629__knewpassworddialog1.png > knewpassworddialog2.png > > https://git.reviewboard.kde.org/media/uploaded/files/2015/10/13/b2e2666f-ce19-4df3-b6ba-25c13fc370ae__knewpassworddialog2.png > knewpassworddialog3.png > > https://git.reviewboard.kde.org/media/uploaded/files/2015/10/13/b9536088-0cc4-470b-a211-6db4ca79aa2f__knewpassworddialog3.png > knewpassworddialog4.png > > https://git.reviewboard.kde.org/media/uploaded/files/2015/10/13/4f826716-9ed2-4ecb-8cbe-4fb50abf1086__knewpassworddialog4.png > > > Thanks, > > Elvis Angelaccio > > ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: [kde-guidelines] Re: Shift+Delete shortcut for cut standard action
Any decision on that? Zombifying this topic will lead to 'solution' #2 (wrongdoing clients). Both #1 and #4 have disadvantages, I cannot estimate if distributed equally. And #3 could be added to the HIG right now: * Consider to provide an option to override default shortcut for cut per strg+del, e.g. in order to forcefully empty the trash. But make sure ctrl+X is always available. We could also ask the community - I'd set-up a quick poll. Cheers, Heiko. Am 04.06.2015 09:41:22, schrieb Thomas Lübking: On Donnerstag, 4. Juni 2015 07:50:00 CEST, Arjun AK wrote: On June 3, 2015 10:41:00 PM IST, Heiko Tietze wrote: On Wednesday 03 June 2015, 17:18:16 Thomas Lübking wrote: ... If not SHIFT+DEL, then what else would you recommend? Some more information here: - The Apple shortcut to * delete[1] is Cmd+Del (⌘+Del), * (forcefully) empty the trash is Cmd+Shift(+Option)+Delete. - The command key is semantically equal to the Meta/Windows key, but it's IBM counterpart in shortcuts would be Ctrl. - The Option key is Alt/AltGr - Ctrl+Delete is taken by Delete word forward - Meta/Windows+Delete should be available - though it might be a neat Alt+F4 replacement ;-) - Cmd+Shift+Option+Delete (the afaik only thing that forces deletion by emptying the trash) would be available, but is oc. a do not use me combo. Nevertheless, Shift+Del *is* a popular shortcut to bypass the trashcan and if you ask ordinary users what it does (not poll whether it should be cut or delete, there's no good answer) I doubt you'll hear as single cuts selection To talk ppl. out of that, one could perhaps 1. define something like Meta+Del or Ctrl+Shift+Del as standard primary shortcurt for force deletion, 2. have wrongdoing clients to keep their Shift+Del behavior as alternate shortcut, but 3. (of course) allow users to deactivate that (without having to come up with an alternative) in order to resolve this conflict (if they want to use CUA shortcuts) and 4. announce the new shortcut (ie. eg. display move to trash in Dolphin's rmb menu when pressing Meta) and tell everybody this is the legit shortcut to force deletion, Dolphin et al. do wrong to mimic MS Cheers, Thomas [1] to trash, Mac users better don't bypass anything ;-P ___ kde-guidelines mailing list kde-guideli...@kde.org https://mail.kde.org/mailman/listinfo/kde-guidelines @user-prompt.com -- Dipl.-Psych. Dr. Heiko Tietze Research Project Management T +49 30 6098548-22 | M +49 179 1268509 User Prompt GmbH | Psychologic IT Expertise Grünberger Str. 49, 10245 Berlin | www.user-prompt.com HRB 142277 | AG Berlin Charlottenburg | Geschäftsführer Björn Balazs Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe
Re: [Kde-hardware-devel] 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 ___ Kde-hardware-devel mailing list Kde-hardware-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-hardware-devel
Re: [kde-guidelines] Shift+Delete shortcut for cut standard action
On Wednesday 03 June 2015, 17:18:16 Thomas Lübking wrote: CC'ing kde-guidelines. FYI, Shift+Del is IBMs common user access variant[5]... (for Cut) And therefore it is reflected in our guideline https://techbase.kde.org/Projects/Usability/HIG/Keyboard_Shortcuts Action Key Altern. Comment Cut Ctrl+X Shift+DeleteCut the selected area and store it in the clipboard Dolphin is doing wrong with Shift+Del for delete, Krusader doesn't use Shift+Del and Kate (katepart?) applies Cut to it by default. So far my first tests... Thanks Thomas, for bringing this up here. Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe
Re: Review Request 123806: [klipper] Ignore empty / blank entries
On Mai 16, 2015, 4:37 nachm., Christoph Feck wrote: klipper/klipper.kcfg, line 32 https://git.reviewboard.kde.org/r/123806/diff/3/?file=369517#file369517line32 It would be immensely useful, if Klipper also showed leading/trailing whitespace, i.e. for items that aren't completely whitespace. Firefox loves to add leading whitespace when copying double-clicked text, but Klipper does not show this in the menu. Christoph Feck wrote: See bug 159267. Patrick Eigensatz wrote: Question if we should make an option to replace whitespaces generally. Like: [ ] Allow history items to consist only of whitespaces [ ] Display whitespace characters with symbols The checkboxes would be independent, so it would be possible to see tabs and spaces **AND** the user would still be able select if he wants to see blank entries. Seems like the best solution to me. :) Heiko Tietze wrote: Did my pic before reading your last comment. Consider to use either a checkbox above the radio buttons, just instead of the title, or replace it all by a dropdown menu. Please don't use my bad English as a reference. The mockup illustrates only the alignment idea.  Patrick Eigensatz wrote: Heiko, I see your concerns on grouping and aligning; I could change the design and create a seperate patch and a seperate view request. Hmm, if we use radio buttons it won't be possible to have symbolic placeholders **and** ignore blank entries... How would you solve this? Thank you If an option is not exclusive the checkbox comes into play. But I don't think you can have both features. And finally I agree that the solution in #123821 is good and a simple checkbox 'Trim whitespace characters' would be sufficient. However, the grouping and the alignment has still room for improvements. To be honest the whole feature is not 'simple by default', which should be our first concern. - Heiko --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/123806/#review80466 --- On Mai 16, 2015, 6:11 nachm., Patrick Eigensatz wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/123806/ --- (Updated Mai 16, 2015, 6:11 nachm.) Review request for kde-workspace, KDE Usability and Patrick Eigensatz. Bugs: 159267 and 192922 https://bugs.kde.org/show_bug.cgi?id=159267 https://bugs.kde.org/show_bug.cgi?id=192922 Repository: plasma-workspace Description --- [PATCH] plasma-workspace: klipper: Fix #192922 Ignore blank entries QString::isEmpty() is used to check if the string only consists of whitespace characters. If it does, the creation of the HistoryStringItem fails. Diffs - klipper/klipper.cpp 798b49f klipper/klipper.kcfg a03dd16 klipper/klipper.h 6952b11 klipper/historyitem.cpp 36cbe61 klipper/generalconfig.ui f513e9c klipper/configdialog.cpp 2fe8206 Diff: https://git.reviewboard.kde.org/r/123806/diff/ Testing --- Thanks, Patrick Eigensatz
Re: Review Request 123806: [klipper] Ignore empty / blank entries
On Mai 16, 2015, 4:37 nachm., Christoph Feck wrote: klipper/klipper.kcfg, line 32 https://git.reviewboard.kde.org/r/123806/diff/3/?file=369517#file369517line32 It would be immensely useful, if Klipper also showed leading/trailing whitespace, i.e. for items that aren't completely whitespace. Firefox loves to add leading whitespace when copying double-clicked text, but Klipper does not show this in the menu. Christoph Feck wrote: See bug 159267. Patrick Eigensatz wrote: Question if we should make an option to replace whitespaces generally. Like: [ ] Allow history items to consist only of whitespaces [ ] Display whitespace characters with symbols The checkboxes would be independent, so it would be possible to see tabs and spaces **AND** the user would still be able select if he wants to see blank entries. Seems like the best solution to me. :) Did my pic before reading your last comment. Consider to use either a checkbox above the radio buttons, just instead of the title, or replace it all by a dropdown menu. Please don't use my bad English as a reference. The mockup illustrates only the alignment idea.  - Heiko --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/123806/#review80466 --- On Mai 16, 2015, 6:11 nachm., Patrick Eigensatz wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/123806/ --- (Updated Mai 16, 2015, 6:11 nachm.) Review request for kde-workspace, KDE Usability and Patrick Eigensatz. Bugs: 159267 and 192922 https://bugs.kde.org/show_bug.cgi?id=159267 https://bugs.kde.org/show_bug.cgi?id=192922 Repository: plasma-workspace Description --- [PATCH] plasma-workspace: klipper: Fix #192922 Ignore blank entries QString::isEmpty() is used to check if the string only consists of whitespace characters. If it does, the creation of the HistoryStringItem fails. Diffs - klipper/klipper.cpp 798b49f klipper/klipper.kcfg a03dd16 klipper/klipper.h 6952b11 klipper/historyitem.cpp 36cbe61 klipper/generalconfig.ui f513e9c klipper/configdialog.cpp 2fe8206 Diff: https://git.reviewboard.kde.org/r/123806/diff/ Testing --- Thanks, Patrick Eigensatz
Re: Review Request 123806: [klipper] Ignore empty / blank entries
On Mai 15, 2015, 7:31 nachm., Martin Gräßlin wrote: thanks for rebasing! I just had a look at the bug report and have to agree with comment #1: I do from time to time copy on purpose whitespaces (yes I'm weird). I also tend to copy newlines and I do want to have them in the history. If I understand your commit description correctly this feature would break. Given that I think we need more input on whether we want to break that feature or whether we want to create a config option for it. Patrick Eigensatz wrote: Hi Martin! Yes, this feature would break. However, if you copy more than one whitespace sequence you won't be able to identify them in the klipper menu. But your concerns are right. I could try to implement an option for this, although I've never done this before and I would surely need some assistance... Kai Uwe Broulik wrote: I also sometimes copy whitespace but then I immediately paste it in, so I wouldn't need it in the history, its representation in the history could probably be improved, if so desired. Perhaps add the usability group to this review request so they can have a look at this. Thomas Lübking wrote: I usually copy whitespaces and newlines w/ the primary selection buffer (for RMB) to click and paste commands when there's no WM ;-) As for distinguishing entries in the history, whitespaces could be replaces w/ something printable like · or ? resp. ?? Maybe in a different color to hint that this is a placeholder? Patrick Eigensatz wrote: I think the idea of (colored) placeholders is great! I've started to create an option in the configuration dialog, we could add an option for whitespace placeholders, too. Thomas Pfeiffer wrote: This is indeed one of the cases where having something configurable is a good idea. While hardly any regular user is likely to want to copy only whitespace, apparently this is an important feature for developers, so it should not be taken from them. It should be turned off by default, however, because presumably developers are more likely to hunt for the option to turn it on than regular users are to hunt for the option to turn it off. As for making whitespace placeholders configurable: That is too much. Either it is useful to have placeholders or it isn't, there isn't one group of people for whom it is useful and another for whom it isn't. Since the main usecase for copying only whitespace is in coding, where the actual number of whitespace characters often is relevant, it appears to make sense to have placeholders. I would not use a printable character as a placeholder, though, because then it won't be distinguishable from the actual character. Can't we maybe just use a different color for the whitespaces (but only in cases where there are only whitespaces)? Kai Uwe Broulik wrote: We could enable styledText for such cases and then use arbitrary html formatting for colors. However, I think there are even Unicode characters that look like blocks with TAB and similar written in them. Thomas Pfeiffer wrote: I'm fine with anything that isn't a regular character. Patrick Eigensatz wrote: I remember there is a programming language called Whitespace only consisting of space/tab/newline. Whitespace IDEs highlight those chars somehow. I think we might change the background color of a char, for example spaces are marked green and so on... (Using HTML formatting? I'm not sure what is possible here...) (The point to do this *only* where there are only whitespaces is important!) I'm currently trying to develop the configuration setting Ignore whitespace characters to but I'm new to Qt and KDE development in general. Thomas Pfeiffer wrote: I'd call it Ignore selections that contain only whitespace, because we're not ignoring whitespaces completely. Thomas Lübking wrote: I'm fine with anything that isn't a regular character. Oh, cool - RB screwed it. Run kcharselect and select Symbole and Symbole für Steuerzeichen (anybody around not german? =) There're special glyphs for non-printable characters. I added them to my former post, but RB apparently replaced them w/ nothing :-( eg. U+2424 (newline) and U+2420 (space) Patrick Eigensatz wrote: You're right on this one! ;-) Thomas Pfeiffer wrote: Okay, Patrick (or anyone else who can run Master), I'd like you to do something called guerilla usability testing: Once the placeholder feature has been implemented, please do the following: Take a machine with Klipper open and a line with the placeholders in it to a few people who - are used to coding or writing a markup language - ideally are at least somewhat familiar with Klipper - are not not involved in this review request and ask them what they think they
Re: Review Request 123806: [klipper] Ignore empty / blank entries
they see there. If all of them at least _guess_ it's whitespace, we've won. If some of them think it's something else, we have to go back to the drawing board. Unicode actually gives us a few options here. In addition to the characters Thomas mentioned, we also have U+2423 (open box, graphic for space) and U+2422 (blank symbol, graphic for space). And if all of those fail, we can still try colors. Could you do that? We don't want to introduce something which only we think works, so this would be really helpful. It's also interesting/fun to do and doesn't cost much time. Thanks! Patrick Eigensatz wrote: Hi Thomas! Indeed! The test seems to be fun! U+2423 seems almost perfect for spaces! But as I told you, I'm new to Qt and I'm new to KDE development and I'm not sure if I can write all this code alone, but I hope to do so... Patrick Eigensatz wrote: I already run into some troubles reading the code. Inside the *Klipper* class, there seems to be the method *loadSettings()* respectively *saveSettings()*. They use functions from a namespace called *KlipperSettings*. But this namespace is nowhere defined. Often, a file called klippersettings.h is included, but in this git commit, this file does not exist... Thank you for your help :) Jeremy Whiting wrote: Patrick, First off, welcome to the community! To answer your question though, the klippersettings.h and it's matching .cpp file are autogenerated files from the .kcfg file. More information can be found here: https://techbase.kde.org/Development/Tutorials/Using_KConfig_XT You should be able to find them in your build folder somewhere. Heiko Tietze wrote: One option to show those charcters in dialogs is to use the regular expression \t (tab), \n (new line), and space as it. That's what Kate does at replace 'escape sequences'. Kate and similar text editors show tabs by this 'much greater than' symbol ? (U+226B) in documents. No idea how Kate handles newline and spaces but Libreoffice, for instance, takes the usual pilcrow symbol (U+00B6) http://en.wikipedia.org/wiki/Pilcrow and a 'middle dot' U+00B7 for spaces (Wikipedia knows more subsitutes http://en.wikipedia.org/w/index.php?title=Whitespace_characteraction=viewsection=4#Substitutes). Libreoffice applys an arrow for tabs, guess it's the 'halfwidth righwards arrow' U+FFEB (it's rather U+21E5 ? rightwards arrow to bar http://en.wikipedia.org/wiki/Tab_key#Unicode). Calligra might draw the arrow since its length depends on the tab width. Another option is to show the html/xml equivalents Tab; NewLine; nbsp; which would be useful for people who regularly deal with that type of representation. To summarize RegEx and HTML are good for developers, visual replacements for people who are familiar with office suites. But unfortunately I do not have a favorite here, all have advantages and disadvantages. And clutter the tool with options makes no sense to me. However if you want to offer the option to show the whitespaces this selection could include the way it is represented (a menu with none, html style, regex style, office style). Last but not least I want to point out that there are much more non-printable characters. E.g. Arab has a couple of zero width white spaces. It could be a use case to type the letters first and add those spacers later. I'm pretty sure we will miss something. Martin Gräßlin wrote: html and regex have the disadvantage that one cannot know what one has now. What's the difference between I copied \n and I copied a newline? It's visually difficult to destinguish. Given that I think (U+00B6) and friends are the better solution for representing them visually. Patrick Eigensatz wrote: I think there is a problem, if we only replace a tab by '\t' and so on, we might write whitespace italic; Which, however, is not very nice if you copy for example idented code containing newlines because you would have both (italic '\n' and normal '\n') in the klipper history. I think the pilcrow symbol (never knew how this Zeilenumbruchsanzeige was really called), the arrow and the open box are good possibilities to represent those whitespace characters. @Jeremy: Thank you, I'll have a look at how to build the files from .kcfg file ;) Patrick Eigensatz wrote: Is this approach okay? Obviously, the first option Ignore the clipboard if it contains only whitespace characters would disable Display whitespace characters using symbolic placeholders and vice versa.  The checkbox captions do not meet the HIG. In particular you have to check something to disable it (rather uncheck by default and write Show foo) and indent subordinate items (both
Re: [Kde-hardware-devel] Review Request 122048: Don't suspend when closing the lid and an external monitor is connected
On Jan. 14, 2015, 12:29 nachm., Sebastian Kügler wrote: I really like this feature. However, I think that UI wise, it looks a bit unpolished. It adds two checkboxes with long texts, that even I, being a domain expert, need some thinking to understand. I wonder if we should offer these actions at all, or whether we should enable the features by default. They do seem useful, I can construct a use-case pretty easily, but we may get away without the UI options, still keeping the config keys, perhaps. Then wait until someone complains or reports unexpected behavior, and then rethink adding the options. Inline, a few niggles about naming when reading the code and trying to understand it, nothing really major. Kai Uwe Broulik wrote: That's why I added the usability group. :) You are right that actually neither of these features really needs to be optional. Turning off that Do not inhibit on lid close (I guess nobody really knew from the UI what that really does anyway) is just tupid in my opinion. Why would you ever *not* want your notebook to suspend when you, all by yourself, close the lid?! That's no automatism interrupting you, it's you closing the lid. Usecases I could imagine you not wanting to suspend when closing the lid is while watching a movie on your TV or when you put your notebook into a docking station, but that's what the other option is for. Using your laptop as a jukebox on a party might want you to play music, close it so nobody spills beer on the keyboard and not have it suspend (Amarok eg. allows to inhibit suspend during playback) but I think most people would just opt to having the lid opened a bit rather than messing with complicated settings they probably don't know exist in the first place. Usability team, what do you think? Do we need settings for either of them? It makes sense to hide options that nobody will use. But as you said there might be some use cases. So what's about a setting like 'use it in this way (on/off)' but 'allow application to override (on/off)'. I have OpenGL antialiasing or the like in mind. So my suggestion is Close lid: [Hibernate/Suspend/Shut down/Start Activity] [x] Allow applications to override setting This makes KScreen responsible to handle the issue when an external display is connected. About the label, HIG for checkboxes contains the advice Checking a check box should always enable an option or change the state of an option to on. Checking a negative or disabling option is a double negative and causes confusion and errors. (https://techbase.kde.org/Projects/Usability/HIG/Check_Box) - Heiko --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/122048/#review74001 --- On Jan. 13, 2015, 11:16 nachm., Kai Uwe Broulik wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/122048/ --- (Updated Jan. 13, 2015, 11:16 nachm.) Review request for Solid, KDE Usability, Àlex Fiestas, and Daniel Vrátil. Repository: powerdevil Description --- Less sensational headline: Skip lid action when external monitor is connected. This brings the KScreen killer feature in the 4.x times back. Now you can watch movies and safely close the lid again! The confusing Never prevent an action on lid close is also moved to the main page since it only affects the lid action and is used nowhere else. I'm not happy with the wording but inhibition is a difficult thing to describe for the average user. Diffs - CMakeLists.txt 27f162c PowerDevilSettings.kcfg 1bc7ce1 daemon/CMakeLists.txt f1e6efb daemon/actions/bundled/handlebuttonevents.h 8ea23f6 daemon/actions/bundled/handlebuttonevents.cpp ac280f4 daemon/actions/bundled/handlebuttoneventsconfig.h a55bca7 daemon/actions/bundled/handlebuttoneventsconfig.cpp 92f0cef kcmodule/global/GeneralPage.cpp 5d9ff10 kcmodule/global/generalPage.ui 26204cb Diff: https://git.reviewboard.kde.org/r/122048/diff/ Testing --- Laptop only, monitor option on - Suspend Laptop only, monitor option off - Suspend TV connected, monitor option on - No action TV connected, monitor option off - Suspend PM enabled, inhibit option on - Suspend PM disabled, inhibit option on - No suspend PM enabled, inhibit option off - Suspend PM disabled, inhibit option off - Suspend File Attachments Config option https://git.reviewboard.kde.org/media/uploaded/files/2015/01/13/e0956548-0a0f-4c41-b3dd-68a5f17815a5__powerdevilstuff.png Thanks, Kai Uwe Broulik
Re: Review Request 110266: Cleanp Places Panel context menu
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/110266/#review31877 --- Of course the changes do improve the menu and I believe your proposal would be helpful. But I would like to discuss the following points: * Adding a header to menus is not commonly used. And I'm not sure why I need to know where I have clicked right now. Relating to design: icons with varying indent make visual noise. * 'Hide' is applied per checkbox, i.e. the action will be executed later (or in respect to the Show all checkbox). Strange behaviour. * 'Edit...': Do I edit the label (usually a rename action via F2), or do I edit the reference/link (trash://), or do I edit the appearance of the item? And the dots (aka ellipsis) points to additional input that will get requested from the user in a dialog shown after click on the item. Strange again because it's easier to remove a bookmark and add it again. Managing bookmarks relates to sorting, grouping, naming, etc. * Add entry... Same problem with ellipsis. * Placing the generic items at the end is a good idea. But do novices or even non-experts know how where to find those important information? What we need is a styleguide that applies to all KDE applications. It defines not only how menus look like but as well when items are disabled or hidden, for instance, how to deal with standard functions, and how to label stuff - all in general. And we need to have specific guidelines for the application itself. That means which function is provided and why, who uses it and in which situation, how does it fit into general look and feel, and so on. For instance: The panel Places provides bookmarks for fast access to user defined folders. Users can add bookmarks either per drag and drop or per menu. Items can be removed, renamed, and resorted. The list of bookmarks follow the visual guideline of lists with medium length. (incomplete example, just for illustration of the idea) Following this, either 'trash' and 'removable media' should be moved into a different panel unless user copy the item into the Places panel (which makes the actual dropdown menu very simple) or the requirements need overhaul. - Heiko Tietze On May 2, 2013, 8:05 a.m., Kai Uwe Broulik wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/110266/ --- (Updated May 2, 2013, 8:05 a.m.) Review request for kdelibs, KDE Usability, Aaron J. Seigo, and Frank Reininghaus. Description --- This is a follow-up review request for Review 109015 which does the same for Dolphin. This patch cleans up the places panel context menu by: - Removing the term Entry and the entry name in every single item. To still have easy context, I added a menu title instead. - General actions such as Show all and Add Entry are removed from item context menus (they're not related to the item) See screenshot for direct comparison of old and new. You can still add an entry, even if the list is full, by scrolling to the bottom of the list where there is always an empty spot to click on. To me it sounds logical to add an entry at the end anyway. (Dolphin doesn't directly have this problem since you can always click the group titles (Devices, Places, Search For, …) which are not considered an item and thus spawn the general context menu) For Frameworks 5 it would of course be great to merge Dolphin's places panel duplication back into kdelibs to provide a unified user experience and reduce maintenance cost. (Or write a new one based on QML, :P) Diffs - kfile/kfileplacesmodel.cpp a73274c kfile/kfileplacesview.cpp 117a9ed Diff: http://git.reviewboard.kde.org/r/110266/diff/ Testing --- Tested in the Open File dialog of Kolourpaint. Looks nice, works. File Attachments Comparison (left old, right new) http://git.reviewboard.kde.org/media/uploaded/files/2013/05/02/kdelibsplaces.png Thanks, Kai Uwe Broulik
