Re: Review Request 126249: Fix apidoc format
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/126249/#review91465 --- Ship it! Ship It! - David Faure On Jan. 23, 2016, 10:25 a.m., Frederik Schwarzer wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/126249/ > --- > > (Updated Jan. 23, 2016, 10:25 a.m.) > > > Review request for kdelibs and David Faure. > > > Repository: kio > > > Description > --- > > A full-stop within the first sentence (short description) breaks the line > there. See e.g. > http://api.kde.org/frameworks-api/frameworks5-apidocs/kio/html/namespaceKIO.html#a17631774b47cddb0127d8a3c1fc2315c > > > Diffs > - > > src/core/storedtransferjob.h 3f267c9 > src/core/transferjob.h 6d78793 > > Diff: https://git.reviewboard.kde.org/r/126249/diff/ > > > Testing > --- > > > Thanks, > > Frederik Schwarzer > >
Re: Review Request 126851: Places data engine: Rename model role name "index" to "id"
> On Jan. 23, 2016, 1:22 nachm., Kai Uwe Broulik wrote: > > id isn't particularly better either as that's also a reserved QML keyword. > > > > Also, you can access any role with a name clash by accessing it through > > "model", ie. model.index > > Daniel Faust wrote: > id is the first thing that came to mind, of cause it could be called > something else as well. (suggestions?) > > I know that I can access the model role through the model variable, but I > want to access the ListView's index variable. Right. Perhaps "itemIndex" / "placeIndex" instead? It also seems that "id" and "index" aren't the same thing? So we shouldn't just remove the one in favor of the other. - Kai Uwe --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/126851/#review91476 --- On Jan. 23, 2016, 1:14 nachm., Daniel Faust wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/126851/ > --- > > (Updated Jan. 23, 2016, 1:14 nachm.) > > > Review request for kde-workspace and Plasma. > > > Repository: plasma-workspace > > > Description > --- > > I wrote a qml applet using the places data engine and noticed that I can't > access the index variable of ListView items because it gets overwritten by > the places model. > This patch renames the "index" role name to "id" in order to avoid this > naming conflict. > > > Diffs > - > > dataengines/places/org.kde.places.operations 98a951d > dataengines/places/placeservice.cpp e0c93c5 > dataengines/places/placesproxymodel.h 467fe83 > dataengines/places/placesproxymodel.cpp 5ea807b > > Diff: https://git.reviewboard.kde.org/r/126851/diff/ > > > Testing > --- > > I couldn't find any other model that is using the places data engine so I > hope renaming the model role is fine. > The provided model still works and I tested the "Setup Device" and "Teardown > Device" operations of the service. > The operations "Show" and "Hide" don't seem to work anyway and the others > were not tested. > > > Thanks, > > Daniel Faust > >
Jenkins-kde-ci: kdelibs KDE-4.14 latest-qt4 » Linux,gcc - Build # 55 - Still Unstable!
GENERAL INFO BUILD UNSTABLE Build URL: https://build.kde.org/job/kdelibs%20KDE-4.14%20latest-qt4/PLATFORM=Linux,compiler=gcc/55/ Project: PLATFORM=Linux,compiler=gcc Date of build: Sat, 23 Jan 2016 07:23:05 + Build duration: 32 min CHANGE SET Revision 52d0a81376e95e7d800f79faca363bdbeabcdfc1 by scripty: (SVN_SILENT made messages (.desktop file)) change: edit knotify/tests/knotifytest.notifyrc change: edit kparts/tests/notepad.desktop JUNIT RESULTS Name: (root) Failed: 1 test(s), Passed: 163 test(s), Skipped: 0 test(s), Total: 164 test(s)Failed: TestSuite.kdecore-kmimetype_nomimetypes COBERTURA RESULTS Cobertura Coverage Report By packages
Re: Review Request 126851: Places data engine: Rename model role name "index" to "id"
> On Jan. 23, 2016, 2:22 p.m., Kai Uwe Broulik wrote: > > id isn't particularly better either as that's also a reserved QML keyword. > > > > Also, you can access any role with a name clash by accessing it through > > "model", ie. model.index id is the first thing that came to mind, of cause it could be called something else as well. (suggestions?) I know that I can access the model role through the model variable, but I want to access the ListView's index variable. - Daniel --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/126851/#review91476 --- On Jan. 23, 2016, 2:14 p.m., Daniel Faust wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/126851/ > --- > > (Updated Jan. 23, 2016, 2:14 p.m.) > > > Review request for kde-workspace and Plasma. > > > Repository: plasma-workspace > > > Description > --- > > I wrote a qml applet using the places data engine and noticed that I can't > access the index variable of ListView items because it gets overwritten by > the places model. > This patch renames the "index" role name to "id" in order to avoid this > naming conflict. > > > Diffs > - > > dataengines/places/org.kde.places.operations 98a951d > dataengines/places/placeservice.cpp e0c93c5 > dataengines/places/placesproxymodel.h 467fe83 > dataengines/places/placesproxymodel.cpp 5ea807b > > Diff: https://git.reviewboard.kde.org/r/126851/diff/ > > > Testing > --- > > I couldn't find any other model that is using the places data engine so I > hope renaming the model role is fine. > The provided model still works and I tested the "Setup Device" and "Teardown > Device" operations of the service. > The operations "Show" and "Hide" don't seem to work anyway and the others > were not tested. > > > Thanks, > > Daniel Faust > >
Re: Review Request 126851: Places data engine: Rename model role name "index" to "id"
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/126851/ --- (Updated Jan. 23, 2016, 3 p.m.) Review request for kde-workspace and Plasma. Changes --- Rename "id" to "placeIndex" Repository: plasma-workspace Description --- I wrote a qml applet using the places data engine and noticed that I can't access the index variable of ListView items because it gets overwritten by the places model. This patch renames the "index" role name to "id" in order to avoid this naming conflict. Diffs (updated) - dataengines/places/org.kde.places.operations 98a951d dataengines/places/placeservice.cpp e0c93c5 dataengines/places/placesproxymodel.h 467fe83 dataengines/places/placesproxymodel.cpp 5ea807b Diff: https://git.reviewboard.kde.org/r/126851/diff/ Testing --- I couldn't find any other model that is using the places data engine so I hope renaming the model role is fine. The provided model still works and I tested the "Setup Device" and "Teardown Device" operations of the service. The operations "Show" and "Hide" don't seem to work anyway and the others were not tested. Thanks, Daniel Faust
Re: Review Request 126851: Places data engine: Rename model role name "index" to "id"
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/126851/#review91476 --- id isn't particularly better either as that's also a reserved QML keyword. Also, you can access any role with a name clash by accessing it through "model", ie. model.index - Kai Uwe Broulik On Jan. 23, 2016, 1:14 nachm., Daniel Faust wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/126851/ > --- > > (Updated Jan. 23, 2016, 1:14 nachm.) > > > Review request for kde-workspace and Plasma. > > > Repository: plasma-workspace > > > Description > --- > > I wrote a qml applet using the places data engine and noticed that I can't > access the index variable of ListView items because it gets overwritten by > the places model. > This patch renames the "index" role name to "id" in order to avoid this > naming conflict. > > > Diffs > - > > dataengines/places/org.kde.places.operations 98a951d > dataengines/places/placeservice.cpp e0c93c5 > dataengines/places/placesproxymodel.h 467fe83 > dataengines/places/placesproxymodel.cpp 5ea807b > > Diff: https://git.reviewboard.kde.org/r/126851/diff/ > > > Testing > --- > > I couldn't find any other model that is using the places data engine so I > hope renaming the model role is fine. > The provided model still works and I tested the "Setup Device" and "Teardown > Device" operations of the service. > The operations "Show" and "Hide" don't seem to work anyway and the others > were not tested. > > > Thanks, > > Daniel Faust > >
Review Request 126851: Places data engine: Rename model role name "index" to "id"
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/126851/ --- Review request for kde-workspace and Plasma. Repository: plasma-workspace Description --- I wrote a qml applet using the places data engine and noticed that I can't access the index variable of ListView items because it gets overwritten by the places model. This patch renames the "index" role name to "id" in order to avoid this naming conflict. Diffs - dataengines/places/org.kde.places.operations 98a951d dataengines/places/placeservice.cpp e0c93c5 dataengines/places/placesproxymodel.h 467fe83 dataengines/places/placesproxymodel.cpp 5ea807b Diff: https://git.reviewboard.kde.org/r/126851/diff/ Testing --- I couldn't find any other model that is using the places data engine so I hope renaming the model role is fine. The provided model still works and I tested the "Setup Device" and "Teardown Device" operations of the service. The operations "Show" and "Hide" don't seem to work anyway and the others were not tested. Thanks, Daniel Faust
Re: Review Request 126249: Fix apidoc format
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/126249/#review91464 --- Ping? - Frederik Schwarzer On Dec. 5, 2015, 8:38 a.m., Frederik Schwarzer wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/126249/ > --- > > (Updated Dec. 5, 2015, 8:38 a.m.) > > > Review request for kdelibs. > > > Repository: kio > > > Description > --- > > A full-stop within the first sentence (short description) breaks the line > there. See e.g. > http://api.kde.org/frameworks-api/frameworks5-apidocs/kio/html/namespaceKIO.html#a17631774b47cddb0127d8a3c1fc2315c > > > Diffs > - > > src/core/storedtransferjob.h 3f267c9 > src/core/transferjob.h 6d78793 > > Diff: https://git.reviewboard.kde.org/r/126249/diff/ > > > Testing > --- > > > Thanks, > > Frederik Schwarzer > >
Re: Review Request 120127: Don't show overwrite dialog if file name is empty
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/120127/#review91466 --- Ship it! Ship It! - David Faure On Sept. 12, 2014, 8:09 a.m., Ignaz Forster wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/120127/ > --- > > (Updated Sept. 12, 2014, 8:09 a.m.) > > > Review request for kdelibs. > > > Repository: kdelibs > > > Description > --- > > Programs using KFileDialog's setConfirmOverwrite(true) (e.g. LibreOffice with > KDE4 integration, Mozilla products with KDE4 integration, several components > of the PIM suite) will trigger the following strange behaviour: > If the file name in the save file dialog is empty and the user selects > "Save", the dialog will ask if you want to overwrite the current directory > (instead of just ignoring the empty input). > > By moving the query below the directory checks the order is correct again, > showing the overwrite confirmation dialog only if the field contains a unique > filename. > > Looking at the code this also affects Frameworks 5 / kio, though I haven't > tested it yet. > > > Diffs > - > > kfile/kfilewidget.cpp fc9b169 > > Diff: https://git.reviewboard.kde.org/r/120127/diff/ > > > Testing > --- > > > Thanks, > > Ignaz Forster > >
Re: Review Request 126249: Fix apidoc format
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/126249/ --- (Updated Jan. 23, 2016, 11:20 a.m.) Status -- This change has been marked as submitted. Review request for kdelibs and David Faure. Repository: kio Description --- A full-stop within the first sentence (short description) breaks the line there. See e.g. http://api.kde.org/frameworks-api/frameworks5-apidocs/kio/html/namespaceKIO.html#a17631774b47cddb0127d8a3c1fc2315c Diffs - src/core/storedtransferjob.h 3f267c9 src/core/transferjob.h 6d78793 Diff: https://git.reviewboard.kde.org/r/126249/diff/ Testing --- Thanks, Frederik Schwarzer
Jenkins-kde-ci: kdelibs KDE-4.14 stable-qt4 » Linux,gcc - Build # 53 - Still Unstable!
GENERAL INFO BUILD UNSTABLE Build URL: https://build.kde.org/job/kdelibs%20KDE-4.14%20stable-qt4/PLATFORM=Linux,compiler=gcc/53/ Project: PLATFORM=Linux,compiler=gcc Date of build: Sat, 23 Jan 2016 12:58:43 + Build duration: 17 min CHANGE SET Revision 32dc425f4ca616fef7a5f193bf79d38f0465f8bf by David Faure: (Fix KDirNotify signal emission in kio_file to send full URLs rather than) change: edit kioslave/file/file.cpp JUNIT RESULTS Name: (root) Failed: 1 test(s), Passed: 163 test(s), Skipped: 0 test(s), Total: 164 test(s)Failed: TestSuite.kdecore-kmimetype_nomimetypes COBERTURA RESULTS Cobertura Coverage Report By packages
Re: Review Request 122249: libksysguard: add Kill Window to End Process button and show correct keyboard shortcut
> On Jan. 23, 2016, 5:31 p.m., Gregor Mi wrote: > > > If someone has changed the shortcut, they should know what shortcut they > > > set it to, right? So having the tooltip just say "To kill a specific > > > window, press the "Kill Window" shortcut (Ctrl-Alt-Esc by default)" > > > should do the trick, right? > > > > In principle, I agree with you here. :) But... > > > > I have these premises in mind: > > > > 1. There might be a situation where the user can't remember what he has > > done. > > 2. I prefer precise over approximate information if it is reasonable easy > > to get (by fixing this https://git.reviewboard.kde.org/r/122981/ it is now > > easily possible and the patch is already written) > > 3. Somewhere I read that tooltips are to be avoided where possible => this > > patch factors some information out of a tooltip which in itself is > > desirable. > > 4. For the user, the discoverability of the feature after applying this > > patch is better than before (though not perfect, sure). > > Thomas Pfeiffer wrote: > 2. If we can get the current shortcut, why can't we get it for the > tooltip? > 3. Wait, are we talking about different tooltips? I do _not_ mean the one > you get when clicking the ? icon in the window decoration. Those should be > avoided because few people even notice that button. What I mean is the thing > that pops up when hovering over a control. Those are strongly encouraged in > the HIG, in fact they should be used on every control where the function > isn't clear from the label. > 4. Clicking a button just to get explained how to use a shortcut is just > not good. When users click a button (unless it's a help button), they expect > something to happen. And still: We're putting something in the UI which is > used only a single time (afterwards the user knows that the function exists) 2. "Put it into the tooltip": Yes, sure this can and should be done. But also see point 5. 3. "Tooltips": oh, I indeed meant the Tooltips which you say are strongly encouraged in the HIG. My mistake, thanks for clearing that! 4a. "Clicking a button": the original idea was that clicking the button actually triggers the function but for current technical reasons it was postponed. So, adding the menu item now might motivate someone to go a step further and implement the rest. One step at a time. 4b. "only used a single time": I myself am a user and due to the outstanding stability of the desktop I keep forgetting these shortcuts. ;-) Seriously, often I found myself in a situation where I knew there is a shortcut but could not remember which (and previously I was lost completely because I did not know that the killing window function exists at all). By now I think I will never forget it, though. :) 5. Funnily, the first time I actually saw that the shortcut is documented in the toolip was when I began to change the code to prepare this RR to make the shortcut more visible. :) Sure, this only a single user report but I don't think I am the only who does not read the whole tooltip. - Gregor --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/122249/#review91486 --- On April 20, 2015, 10:24 p.m., Gregor Mi wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/122249/ > --- > > (Updated April 20, 2015, 10:24 p.m.) > > > Review request for KDE Base Apps, Martin Gräßlin, John Tapsell, and Thomas > Pfeiffer. > > > Repository: libksysguard > > > Description > --- > > Current situation: > The "End Process..." button has a tooltip which says "To target a specific > window to kill, press Ctrl+Alt+Esc at any time." The keyboard shortcut is > hardcoded. > > New: > Replace the "End Process..." button with a drop-down button and a action > named "Kill a specific window..." > > > Diffs > - > > CMakeLists.txt 66899e577a03786d894423a8f1ce5b3aeed6de8a > processui/CMakeLists.txt 7f87b85e0201e63d69070a71203bbb34851a79c6 > processui/ProcessWidgetUI.ui e50f55cf1813b00d49b1716023df487ffbd536e3 > processui/ksysguardprocesslist.cpp 450ca600b8aed7ca611ec638610b6c524c96080c > > Diff: https://git.reviewboard.kde.org/r/122249/diff/ > > > Testing > --- > > > File Attachments > > > New End Process button with drop down arrow > > https://git.reviewboard.kde.org/media/uploaded/files/2015/01/28/16301e88-e21b-4358-9a63-a85dae5722bd__screenshot_default1.png > new submenu > > https://git.reviewboard.kde.org/media/uploaded/files/2015/04/10/eeaecc88-20bc-46d6-9c65-50ba4a7c182a__submenu.png > > > Thanks, > > Gregor Mi > >
Re: Review Request 122249: libksysguard: add Kill Window to End Process button and show correct keyboard shortcut
> On Jan. 23, 2016, 5:31 p.m., Gregor Mi wrote: > > > If someone has changed the shortcut, they should know what shortcut they > > > set it to, right? So having the tooltip just say "To kill a specific > > > window, press the "Kill Window" shortcut (Ctrl-Alt-Esc by default)" > > > should do the trick, right? > > > > In principle, I agree with you here. :) But... > > > > I have these premises in mind: > > > > 1. There might be a situation where the user can't remember what he has > > done. > > 2. I prefer precise over approximate information if it is reasonable easy > > to get (by fixing this https://git.reviewboard.kde.org/r/122981/ it is now > > easily possible and the patch is already written) > > 3. Somewhere I read that tooltips are to be avoided where possible => this > > patch factors some information out of a tooltip which in itself is > > desirable. > > 4. For the user, the discoverability of the feature after applying this > > patch is better than before (though not perfect, sure). 2. If we can get the current shortcut, why can't we get it for the tooltip? 3. Wait, are we talking about different tooltips? I do _not_ mean the one you get when clicking the ? icon in the window decoration. Those should be avoided because few people even notice that button. What I mean is the thing that pops up when hovering over a control. Those are strongly encouraged in the HIG, in fact they should be used on every control where the function isn't clear from the label. 4. Clicking a button just to get explained how to use a shortcut is just not good. When users click a button (unless it's a help button), they expect something to happen. And still: We're putting something in the UI which is used only a single time (afterwards the user knows that the function exists) - Thomas --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/122249/#review91486 --- On April 20, 2015, 10:24 p.m., Gregor Mi wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/122249/ > --- > > (Updated April 20, 2015, 10:24 p.m.) > > > Review request for KDE Base Apps, Martin Gräßlin, John Tapsell, and Thomas > Pfeiffer. > > > Repository: libksysguard > > > Description > --- > > Current situation: > The "End Process..." button has a tooltip which says "To target a specific > window to kill, press Ctrl+Alt+Esc at any time." The keyboard shortcut is > hardcoded. > > New: > Replace the "End Process..." button with a drop-down button and a action > named "Kill a specific window..." > > > Diffs > - > > CMakeLists.txt 66899e577a03786d894423a8f1ce5b3aeed6de8a > processui/CMakeLists.txt 7f87b85e0201e63d69070a71203bbb34851a79c6 > processui/ProcessWidgetUI.ui e50f55cf1813b00d49b1716023df487ffbd536e3 > processui/ksysguardprocesslist.cpp 450ca600b8aed7ca611ec638610b6c524c96080c > > Diff: https://git.reviewboard.kde.org/r/122249/diff/ > > > Testing > --- > > > File Attachments > > > New End Process button with drop down arrow > > https://git.reviewboard.kde.org/media/uploaded/files/2015/01/28/16301e88-e21b-4358-9a63-a85dae5722bd__screenshot_default1.png > new submenu > > https://git.reviewboard.kde.org/media/uploaded/files/2015/04/10/eeaecc88-20bc-46d6-9c65-50ba4a7c182a__submenu.png > > > Thanks, > > Gregor Mi > >
Jenkins-kde-ci: kdelibs KDE-4.14 latest-qt4 » Linux,gcc - Build # 56 - Still Unstable!
GENERAL INFO BUILD UNSTABLE Build URL: https://build.kde.org/job/kdelibs%20KDE-4.14%20latest-qt4/PLATFORM=Linux,compiler=gcc/56/ Project: PLATFORM=Linux,compiler=gcc Date of build: Sat, 23 Jan 2016 12:58:43 + Build duration: 35 min CHANGE SET Revision 32dc425f4ca616fef7a5f193bf79d38f0465f8bf by David Faure: (Fix KDirNotify signal emission in kio_file to send full URLs rather than) change: edit kioslave/file/file.cpp JUNIT RESULTS Name: (root) Failed: 1 test(s), Passed: 163 test(s), Skipped: 0 test(s), Total: 164 test(s)Failed: TestSuite.kdecore-kmimetype_nomimetypes COBERTURA RESULTS Cobertura Coverage Report By packages
Re: Review Request 122249: libksysguard: add Kill Window to End Process button and show correct keyboard shortcut
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/122249/#review91486 --- > If someone has changed the shortcut, they should know what shortcut they set > it to, right? So having the tooltip just say "To kill a specific window, > press the "Kill Window" shortcut (Ctrl-Alt-Esc by default)" should do the > trick, right? In principle, I agree with you here. :) But... I have these premises in mind: 1. There might be a situation where the user can't remember what he has done. 2. I prefer precise over approximate information if it is reasonable easy to get (by fixing this https://git.reviewboard.kde.org/r/122981/ it is now easily possible and the patch is already written) 3. Somewhere I read that tooltips are to be avoided where possible => this patch factors some information out of a tooltip which in itself is desirable. 4. For the user, the discoverability of the feature after applying this patch is better than before (though not perfect, sure). - Gregor Mi On April 20, 2015, 10:24 p.m., Gregor Mi wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/122249/ > --- > > (Updated April 20, 2015, 10:24 p.m.) > > > Review request for KDE Base Apps, Martin Gräßlin, John Tapsell, and Thomas > Pfeiffer. > > > Repository: libksysguard > > > Description > --- > > Current situation: > The "End Process..." button has a tooltip which says "To target a specific > window to kill, press Ctrl+Alt+Esc at any time." The keyboard shortcut is > hardcoded. > > New: > Replace the "End Process..." button with a drop-down button and a action > named "Kill a specific window..." > > > Diffs > - > > CMakeLists.txt 66899e577a03786d894423a8f1ce5b3aeed6de8a > processui/CMakeLists.txt 7f87b85e0201e63d69070a71203bbb34851a79c6 > processui/ProcessWidgetUI.ui e50f55cf1813b00d49b1716023df487ffbd536e3 > processui/ksysguardprocesslist.cpp 450ca600b8aed7ca611ec638610b6c524c96080c > > Diff: https://git.reviewboard.kde.org/r/122249/diff/ > > > Testing > --- > > > File Attachments > > > New End Process button with drop down arrow > > https://git.reviewboard.kde.org/media/uploaded/files/2015/01/28/16301e88-e21b-4358-9a63-a85dae5722bd__screenshot_default1.png > new submenu > > https://git.reviewboard.kde.org/media/uploaded/files/2015/04/10/eeaecc88-20bc-46d6-9c65-50ba4a7c182a__submenu.png > > > Thanks, > > Gregor Mi > >
Re: Review Request 122249: libksysguard: add Kill Window to End Process button and show correct keyboard shortcut
> On April 20, 2015, 10:36 p.m., Thomas Pfeiffer wrote: > > What would likely be confusing is that the two button modes have different > > interaction flows: The "End Process" mode requires to first select a > > process and then press the button to work, whereas the "Kill specific > > window" mode requires to first press the button and then select the window > > to kill, and users have no easy way to understand how each one works and > > why they work differently. > > > > The ellipsis in the label "End Process..." adds to that confusion. It > > indicates that further input is necessary before the action can take > > effect. While the button does open a dialog to confirm killing the selected > > process, ellipses are actually reserved for actions where a dialog asks for > > new information, such as the "Save As..." button, not for actions that > > require confirmation. > > > > To avoid this confusion, it should be possible to also click "End > > Process..." even if no processes has been selected, whuch would then ask > > the user to select the process to kill. This could theoretically be done > > similarly to the "Kill specific window" function: Click the "End > > Process..." button and then click the process in the list that you want to > > end. Alternatively, if no process had been selected when "End Process..." > > is clicked, a dialog could be opened where the process to kill would be > > selected. Of course the current flow of ending a process could and should > > still work. > > Gregor Mi wrote: > Thanks for the feedback! The ellipsis in "End Process..." is the original > design. According to your explanation this was wrong in the first place. What > about removing the ellipses in both menu items so we will end up with "End > Process" and "Kill a specific window"? > > Thomas Pfeiffer wrote: > "Kill specific window" does always need additional input until it really > does something, doesn't it? As I understood it merely changes the cursor to > the kill cursor and then the user has to select the window to kill, right? > > Gregor Mi wrote: > Erm, right. To be exact, "Kill specific window..." only shows a message > box. But in the end - after the user presses the keyboard shortcut - the user > has to select a window. So this seems to be a special case. The intention > behind all this is to increase the discoverability of the hidden xkill > feature. > > Gregor Mi wrote: > > To avoid this confusion, it should be possible to also click "End > Process..." even if no processes has been selected, whuch would then ask the > user to select the process to kill. > > If "End Process" is clicked with no processes selected, there will be a > message box which says that the user has to select one more more processes > first. > > > This could theoretically be done similarly to the "Kill specific > window" function: Click the "End Process..." button and then click the > process in the list that you want to end. > > I think "Kill specific windows" should be considered as the special case > here. Changing or extending the "End Process" workflow would introduce more > complexity to the code. > > > Alternatively, if no process had been selected when "End Process..." is > clicked, a dialog could be opened where the process to kill would be > selected. Of course the current flow of ending a p>rocess could and should > still work. > > This would be a topic for another RR. > > Summary of final changes for this RR: > > - I would change the "End Process..." to "End Process" (remove ellipsis). > Ok? > - I am not sure if the ellipsis of "Kill specific window..." should be > removed or not. > > Thomas Pfeiffer wrote: > To be honest: The more I think about this feature, the less sense it > makes to me in general. > What is XKill's usecase anyway? If an application works normally, one can > just quit it normally. If an application is frozen, KWin quite reliably > detects that when trying to close the window and allows to kill the process. > Usually "End process" is used for applications that do not have a window > (either because they don't have a GUI in the first place or because the > window has disappeared but the process is still there), in which case xkill > would not help anyway. > Yes, there may be some situations where it's useful, but they are really > corner cases. Yes, very few people know it's there, but very few people miss > the function, either. I heve never wished there was a way to hard kill a > window without using the Close button in the windeco, and I have never met > one who did. > > So we're complicating the GUI with a split button only to explain a > feature to users which the vast majority of them don't need in the first > place. > > If I have missed the "killer usecase for xkill" which makes it necessary > to make it a lot more
Re: Review Request 122249: libksysguard: add Kill Window to End Process button and show correct keyboard shortcut
> On Jan. 23, 2016, 5:31 p.m., Gregor Mi wrote: > > > If someone has changed the shortcut, they should know what shortcut they > > > set it to, right? So having the tooltip just say "To kill a specific > > > window, press the "Kill Window" shortcut (Ctrl-Alt-Esc by default)" > > > should do the trick, right? > > > > In principle, I agree with you here. :) But... > > > > I have these premises in mind: > > > > 1. There might be a situation where the user can't remember what he has > > done. > > 2. I prefer precise over approximate information if it is reasonable easy > > to get (by fixing this https://git.reviewboard.kde.org/r/122981/ it is now > > easily possible and the patch is already written) > > 3. Somewhere I read that tooltips are to be avoided where possible => this > > patch factors some information out of a tooltip which in itself is > > desirable. > > 4. For the user, the discoverability of the feature after applying this > > patch is better than before (though not perfect, sure). > > Thomas Pfeiffer wrote: > 2. If we can get the current shortcut, why can't we get it for the > tooltip? > 3. Wait, are we talking about different tooltips? I do _not_ mean the one > you get when clicking the ? icon in the window decoration. Those should be > avoided because few people even notice that button. What I mean is the thing > that pops up when hovering over a control. Those are strongly encouraged in > the HIG, in fact they should be used on every control where the function > isn't clear from the label. > 4. Clicking a button just to get explained how to use a shortcut is just > not good. When users click a button (unless it's a help button), they expect > something to happen. And still: We're putting something in the UI which is > used only a single time (afterwards the user knows that the function exists) > > Gregor Mi wrote: > 2. "Put it into the tooltip": Yes, sure this can and should be done. But > also see point 5. > > > 3. "Tooltips": oh, I indeed meant the Tooltips which you say are strongly > encouraged in the HIG. My mistake, thanks for clearing that! > > > 4a. "Clicking a button": the original idea was that clicking the button > actually triggers the function but for current technical reasons it was > postponed. So, adding the menu item now might motivate someone to go a step > further and implement the rest. One step at a time. > > 4b. "only used a single time": I myself am a user and due to the > outstanding stability of the desktop I keep forgetting these shortcuts. ;-) > Seriously, often I found myself in a situation where I knew there is a > shortcut but could not remember which (and previously I was lost completely > because I did not know that the killing window function exists at all). By > now I think I will never forget it, though. :) > > 5. Funnily, the first time I actually saw that the shortcut is documented > in the toolip was when I began to change the code to prepare this RR to make > the shortcut more visible. :) Sure, this only a single user report but I > don't think I am the only who does not read the whole tooltip. > > Ken Vermette wrote: > As I see it here, the current solution isn't good and I'd argue against > changing things just because they feel stale. Mainly you're trading one > less-than-ideal solution (using a tooltip) in exhange for a solution which is > more complicated and bloats the UI. Why do we need to go so far out of our > way to advertise XKill when we are capable of killing apps from the monitor? > Users of the monitor familliar with the system chould not have purely > informational menus burned into the main UI. > > Split buttons are also abused regularly, and it's not clear what the "V" > menu offers until activated. Why would someone who won't stop for a tooltip > know to press the "V" button? What if they assume it's for other actions like > pause, suspend, and resuming the selected process? Users *still* won't click > it if that's the case. This is essentially a much more convoluted tooltip > which works under the assumption users will investigate it because it's > disguised as functionality. > > I also dislike that it advertised as a feature and not a help option, and > users with a crashing/frozen application will only be more frusterated if > they think they have a solution - and are instead given a manual. Nowhere > else do we use this pattern. Information should NEVER be disquised as > functionality; it **severly** degrades user trust. Imagine if every > application did this - would you use a system which kept popping up with info > boxes instead of doing the work? Especially when you *need* the system to > take care of a problem and the system tells you "I can't do this, try doing > this" - I can think of no better way to shatter a users trust; one thing is > already broken, we should not make it feel
Re: Review Request 122249: libksysguard: add Kill Window to End Process button and show correct keyboard shortcut
> On Jan. 23, 2016, 5:31 p.m., Gregor Mi wrote: > > > If someone has changed the shortcut, they should know what shortcut they > > > set it to, right? So having the tooltip just say "To kill a specific > > > window, press the "Kill Window" shortcut (Ctrl-Alt-Esc by default)" > > > should do the trick, right? > > > > In principle, I agree with you here. :) But... > > > > I have these premises in mind: > > > > 1. There might be a situation where the user can't remember what he has > > done. > > 2. I prefer precise over approximate information if it is reasonable easy > > to get (by fixing this https://git.reviewboard.kde.org/r/122981/ it is now > > easily possible and the patch is already written) > > 3. Somewhere I read that tooltips are to be avoided where possible => this > > patch factors some information out of a tooltip which in itself is > > desirable. > > 4. For the user, the discoverability of the feature after applying this > > patch is better than before (though not perfect, sure). > > Thomas Pfeiffer wrote: > 2. If we can get the current shortcut, why can't we get it for the > tooltip? > 3. Wait, are we talking about different tooltips? I do _not_ mean the one > you get when clicking the ? icon in the window decoration. Those should be > avoided because few people even notice that button. What I mean is the thing > that pops up when hovering over a control. Those are strongly encouraged in > the HIG, in fact they should be used on every control where the function > isn't clear from the label. > 4. Clicking a button just to get explained how to use a shortcut is just > not good. When users click a button (unless it's a help button), they expect > something to happen. And still: We're putting something in the UI which is > used only a single time (afterwards the user knows that the function exists) > > Gregor Mi wrote: > 2. "Put it into the tooltip": Yes, sure this can and should be done. But > also see point 5. > > > 3. "Tooltips": oh, I indeed meant the Tooltips which you say are strongly > encouraged in the HIG. My mistake, thanks for clearing that! > > > 4a. "Clicking a button": the original idea was that clicking the button > actually triggers the function but for current technical reasons it was > postponed. So, adding the menu item now might motivate someone to go a step > further and implement the rest. One step at a time. > > 4b. "only used a single time": I myself am a user and due to the > outstanding stability of the desktop I keep forgetting these shortcuts. ;-) > Seriously, often I found myself in a situation where I knew there is a > shortcut but could not remember which (and previously I was lost completely > because I did not know that the killing window function exists at all). By > now I think I will never forget it, though. :) > > 5. Funnily, the first time I actually saw that the shortcut is documented > in the toolip was when I began to change the code to prepare this RR to make > the shortcut more visible. :) Sure, this only a single user report but I > don't think I am the only who does not read the whole tooltip. > > Ken Vermette wrote: > As I see it here, the current solution isn't good and I'd argue against > changing things just because they feel stale. Mainly you're trading one > less-than-ideal solution (using a tooltip) in exhange for a solution which is > more complicated and bloats the UI. Why do we need to go so far out of our > way to advertise XKill when we are capable of killing apps from the monitor? > Users of the monitor familliar with the system chould not have purely > informational menus burned into the main UI. > > Split buttons are also abused regularly, and it's not clear what the "V" > menu offers until activated. Why would someone who won't stop for a tooltip > know to press the "V" button? What if they assume it's for other actions like > pause, suspend, and resuming the selected process? Users *still* won't click > it if that's the case. This is essentially a much more convoluted tooltip > which works under the assumption users will investigate it because it's > disguised as functionality. > > I also dislike that it advertised as a feature and not a help option, and > users with a crashing/frozen application will only be more frusterated if > they think they have a solution - and are instead given a manual. Nowhere > else do we use this pattern. Information should NEVER be disquised as > functionality; it **severly** degrades user trust. Imagine if every > application did this - would you use a system which kept popping up with info > boxes instead of doing the work? Especially when you *need* the system to > take care of a problem and the system tells you "I can't do this, try doing > this" - I can think of no better way to shatter a users trust; one thing is > already broken, we should not make it feel
Re: Review Request 122249: libksysguard: add Kill Window to End Process button and show correct keyboard shortcut
> On Jan. 23, 2016, 5:31 p.m., Gregor Mi wrote: > > > If someone has changed the shortcut, they should know what shortcut they > > > set it to, right? So having the tooltip just say "To kill a specific > > > window, press the "Kill Window" shortcut (Ctrl-Alt-Esc by default)" > > > should do the trick, right? > > > > In principle, I agree with you here. :) But... > > > > I have these premises in mind: > > > > 1. There might be a situation where the user can't remember what he has > > done. > > 2. I prefer precise over approximate information if it is reasonable easy > > to get (by fixing this https://git.reviewboard.kde.org/r/122981/ it is now > > easily possible and the patch is already written) > > 3. Somewhere I read that tooltips are to be avoided where possible => this > > patch factors some information out of a tooltip which in itself is > > desirable. > > 4. For the user, the discoverability of the feature after applying this > > patch is better than before (though not perfect, sure). > > Thomas Pfeiffer wrote: > 2. If we can get the current shortcut, why can't we get it for the > tooltip? > 3. Wait, are we talking about different tooltips? I do _not_ mean the one > you get when clicking the ? icon in the window decoration. Those should be > avoided because few people even notice that button. What I mean is the thing > that pops up when hovering over a control. Those are strongly encouraged in > the HIG, in fact they should be used on every control where the function > isn't clear from the label. > 4. Clicking a button just to get explained how to use a shortcut is just > not good. When users click a button (unless it's a help button), they expect > something to happen. And still: We're putting something in the UI which is > used only a single time (afterwards the user knows that the function exists) > > Gregor Mi wrote: > 2. "Put it into the tooltip": Yes, sure this can and should be done. But > also see point 5. > > > 3. "Tooltips": oh, I indeed meant the Tooltips which you say are strongly > encouraged in the HIG. My mistake, thanks for clearing that! > > > 4a. "Clicking a button": the original idea was that clicking the button > actually triggers the function but for current technical reasons it was > postponed. So, adding the menu item now might motivate someone to go a step > further and implement the rest. One step at a time. > > 4b. "only used a single time": I myself am a user and due to the > outstanding stability of the desktop I keep forgetting these shortcuts. ;-) > Seriously, often I found myself in a situation where I knew there is a > shortcut but could not remember which (and previously I was lost completely > because I did not know that the killing window function exists at all). By > now I think I will never forget it, though. :) > > 5. Funnily, the first time I actually saw that the shortcut is documented > in the toolip was when I began to change the code to prepare this RR to make > the shortcut more visible. :) Sure, this only a single user report but I > don't think I am the only who does not read the whole tooltip. > > Ken Vermette wrote: > As I see it here, the current solution isn't good and I'd argue against > changing things just because they feel stale. Mainly you're trading one > less-than-ideal solution (using a tooltip) in exhange for a solution which is > more complicated and bloats the UI. Why do we need to go so far out of our > way to advertise XKill when we are capable of killing apps from the monitor? > Users of the monitor familliar with the system chould not have purely > informational menus burned into the main UI. > > Split buttons are also abused regularly, and it's not clear what the "V" > menu offers until activated. Why would someone who won't stop for a tooltip > know to press the "V" button? What if they assume it's for other actions like > pause, suspend, and resuming the selected process? Users *still* won't click > it if that's the case. This is essentially a much more convoluted tooltip > which works under the assumption users will investigate it because it's > disguised as functionality. > > I also dislike that it advertised as a feature and not a help option, and > users with a crashing/frozen application will only be more frusterated if > they think they have a solution - and are instead given a manual. Nowhere > else do we use this pattern. Information should NEVER be disquised as > functionality; it **severly** degrades user trust. Imagine if every > application did this - would you use a system which kept popping up with info > boxes instead of doing the work? Especially when you *need* the system to > take care of a problem and the system tells you "I can't do this, try doing > this" - I can think of no better way to shatter a users trust; one thing is > already broken, we should not make it feel
Re: Review Request 122249: libksysguard: add Kill Window to End Process button and show correct keyboard shortcut
> On Jan. 23, 2016, 5:31 p.m., Gregor Mi wrote: > > > If someone has changed the shortcut, they should know what shortcut they > > > set it to, right? So having the tooltip just say "To kill a specific > > > window, press the "Kill Window" shortcut (Ctrl-Alt-Esc by default)" > > > should do the trick, right? > > > > In principle, I agree with you here. :) But... > > > > I have these premises in mind: > > > > 1. There might be a situation where the user can't remember what he has > > done. > > 2. I prefer precise over approximate information if it is reasonable easy > > to get (by fixing this https://git.reviewboard.kde.org/r/122981/ it is now > > easily possible and the patch is already written) > > 3. Somewhere I read that tooltips are to be avoided where possible => this > > patch factors some information out of a tooltip which in itself is > > desirable. > > 4. For the user, the discoverability of the feature after applying this > > patch is better than before (though not perfect, sure). > > Thomas Pfeiffer wrote: > 2. If we can get the current shortcut, why can't we get it for the > tooltip? > 3. Wait, are we talking about different tooltips? I do _not_ mean the one > you get when clicking the ? icon in the window decoration. Those should be > avoided because few people even notice that button. What I mean is the thing > that pops up when hovering over a control. Those are strongly encouraged in > the HIG, in fact they should be used on every control where the function > isn't clear from the label. > 4. Clicking a button just to get explained how to use a shortcut is just > not good. When users click a button (unless it's a help button), they expect > something to happen. And still: We're putting something in the UI which is > used only a single time (afterwards the user knows that the function exists) > > Gregor Mi wrote: > 2. "Put it into the tooltip": Yes, sure this can and should be done. But > also see point 5. > > > 3. "Tooltips": oh, I indeed meant the Tooltips which you say are strongly > encouraged in the HIG. My mistake, thanks for clearing that! > > > 4a. "Clicking a button": the original idea was that clicking the button > actually triggers the function but for current technical reasons it was > postponed. So, adding the menu item now might motivate someone to go a step > further and implement the rest. One step at a time. > > 4b. "only used a single time": I myself am a user and due to the > outstanding stability of the desktop I keep forgetting these shortcuts. ;-) > Seriously, often I found myself in a situation where I knew there is a > shortcut but could not remember which (and previously I was lost completely > because I did not know that the killing window function exists at all). By > now I think I will never forget it, though. :) > > 5. Funnily, the first time I actually saw that the shortcut is documented > in the toolip was when I began to change the code to prepare this RR to make > the shortcut more visible. :) Sure, this only a single user report but I > don't think I am the only who does not read the whole tooltip. > > Ken Vermette wrote: > As I see it here, the current solution isn't good and I'd argue against > changing things just because they feel stale. Mainly you're trading one > less-than-ideal solution (using a tooltip) in exhange for a solution which is > more complicated and bloats the UI. Why do we need to go so far out of our > way to advertise XKill when we are capable of killing apps from the monitor? > Users of the monitor familliar with the system chould not have purely > informational menus burned into the main UI. > > Split buttons are also abused regularly, and it's not clear what the "V" > menu offers until activated. Why would someone who won't stop for a tooltip > know to press the "V" button? What if they assume it's for other actions like > pause, suspend, and resuming the selected process? Users *still* won't click > it if that's the case. This is essentially a much more convoluted tooltip > which works under the assumption users will investigate it because it's > disguised as functionality. > > I also dislike that it advertised as a feature and not a help option, and > users with a crashing/frozen application will only be more frusterated if > they think they have a solution - and are instead given a manual. Nowhere > else do we use this pattern. Information should NEVER be disquised as > functionality; it **severly** degrades user trust. Imagine if every > application did this - would you use a system which kept popping up with info > boxes instead of doing the work? Especially when you *need* the system to > take care of a problem and the system tells you "I can't do this, try doing > this" - I can think of no better way to shatter a users trust; one thing is > already broken, we should not make it feel
Re: Review Request 122249: libksysguard: add Kill Window to End Process button and show correct keyboard shortcut
> On Jan. 23, 2016, 5:31 p.m., Gregor Mi wrote: > > > If someone has changed the shortcut, they should know what shortcut they > > > set it to, right? So having the tooltip just say "To kill a specific > > > window, press the "Kill Window" shortcut (Ctrl-Alt-Esc by default)" > > > should do the trick, right? > > > > In principle, I agree with you here. :) But... > > > > I have these premises in mind: > > > > 1. There might be a situation where the user can't remember what he has > > done. > > 2. I prefer precise over approximate information if it is reasonable easy > > to get (by fixing this https://git.reviewboard.kde.org/r/122981/ it is now > > easily possible and the patch is already written) > > 3. Somewhere I read that tooltips are to be avoided where possible => this > > patch factors some information out of a tooltip which in itself is > > desirable. > > 4. For the user, the discoverability of the feature after applying this > > patch is better than before (though not perfect, sure). > > Thomas Pfeiffer wrote: > 2. If we can get the current shortcut, why can't we get it for the > tooltip? > 3. Wait, are we talking about different tooltips? I do _not_ mean the one > you get when clicking the ? icon in the window decoration. Those should be > avoided because few people even notice that button. What I mean is the thing > that pops up when hovering over a control. Those are strongly encouraged in > the HIG, in fact they should be used on every control where the function > isn't clear from the label. > 4. Clicking a button just to get explained how to use a shortcut is just > not good. When users click a button (unless it's a help button), they expect > something to happen. And still: We're putting something in the UI which is > used only a single time (afterwards the user knows that the function exists) > > Gregor Mi wrote: > 2. "Put it into the tooltip": Yes, sure this can and should be done. But > also see point 5. > > > 3. "Tooltips": oh, I indeed meant the Tooltips which you say are strongly > encouraged in the HIG. My mistake, thanks for clearing that! > > > 4a. "Clicking a button": the original idea was that clicking the button > actually triggers the function but for current technical reasons it was > postponed. So, adding the menu item now might motivate someone to go a step > further and implement the rest. One step at a time. > > 4b. "only used a single time": I myself am a user and due to the > outstanding stability of the desktop I keep forgetting these shortcuts. ;-) > Seriously, often I found myself in a situation where I knew there is a > shortcut but could not remember which (and previously I was lost completely > because I did not know that the killing window function exists at all). By > now I think I will never forget it, though. :) > > 5. Funnily, the first time I actually saw that the shortcut is documented > in the toolip was when I began to change the code to prepare this RR to make > the shortcut more visible. :) Sure, this only a single user report but I > don't think I am the only who does not read the whole tooltip. As I see it here, the current solution isn't good and I'd argue against changing things just because they feel stale. Mainly you're trading one less-than-ideal solution (using a tooltip) in exhange for a solution which is more complicated and bloats the UI. Why do we need to go so far out of our way to advertise XKill when we are capable of killing apps from the monitor? Users of the monitor familliar with the system chould not have purely informational menus burned into the main UI. Split buttons are also abused regularly, and it's not clear what the "V" menu offers until activated. Why would someone who won't stop for a tooltip know to press the "V" button? What if they assume it's for other actions like pause, suspend, and resuming the selected process? Users *still* won't click it if that's the case. This is essentially a much more convoluted tooltip which works under the assumption users will investigate it because it's disguised as functionality. I also dislike that it advertised as a feature and not a help option, and users with a crashing/frozen application will only be more frusterated if they think they have a solution - and are instead given a manual. Nowhere else do we use this pattern. Information should NEVER be disquised as functionality; it **severly** degrades user trust. Imagine if every application did this - would you use a system which kept popping up with info boxes instead of doing the work? Especially when you *need* the system to take care of a problem and the system tells you "I can't do this, try doing this" - I can think of no better way to shatter a users trust; one thing is already broken, we should not make it feel *more* broken. Finally, xkill is a separate utility entirely, I question if it should be
Re: Review Request 122249: libksysguard: add Kill Window to End Process button and show correct keyboard shortcut
> On Jan. 23, 2016, 5:31 p.m., Gregor Mi wrote: > > > If someone has changed the shortcut, they should know what shortcut they > > > set it to, right? So having the tooltip just say "To kill a specific > > > window, press the "Kill Window" shortcut (Ctrl-Alt-Esc by default)" > > > should do the trick, right? > > > > In principle, I agree with you here. :) But... > > > > I have these premises in mind: > > > > 1. There might be a situation where the user can't remember what he has > > done. > > 2. I prefer precise over approximate information if it is reasonable easy > > to get (by fixing this https://git.reviewboard.kde.org/r/122981/ it is now > > easily possible and the patch is already written) > > 3. Somewhere I read that tooltips are to be avoided where possible => this > > patch factors some information out of a tooltip which in itself is > > desirable. > > 4. For the user, the discoverability of the feature after applying this > > patch is better than before (though not perfect, sure). > > Thomas Pfeiffer wrote: > 2. If we can get the current shortcut, why can't we get it for the > tooltip? > 3. Wait, are we talking about different tooltips? I do _not_ mean the one > you get when clicking the ? icon in the window decoration. Those should be > avoided because few people even notice that button. What I mean is the thing > that pops up when hovering over a control. Those are strongly encouraged in > the HIG, in fact they should be used on every control where the function > isn't clear from the label. > 4. Clicking a button just to get explained how to use a shortcut is just > not good. When users click a button (unless it's a help button), they expect > something to happen. And still: We're putting something in the UI which is > used only a single time (afterwards the user knows that the function exists) > > Gregor Mi wrote: > 2. "Put it into the tooltip": Yes, sure this can and should be done. But > also see point 5. > > > 3. "Tooltips": oh, I indeed meant the Tooltips which you say are strongly > encouraged in the HIG. My mistake, thanks for clearing that! > > > 4a. "Clicking a button": the original idea was that clicking the button > actually triggers the function but for current technical reasons it was > postponed. So, adding the menu item now might motivate someone to go a step > further and implement the rest. One step at a time. > > 4b. "only used a single time": I myself am a user and due to the > outstanding stability of the desktop I keep forgetting these shortcuts. ;-) > Seriously, often I found myself in a situation where I knew there is a > shortcut but could not remember which (and previously I was lost completely > because I did not know that the killing window function exists at all). By > now I think I will never forget it, though. :) > > 5. Funnily, the first time I actually saw that the shortcut is documented > in the toolip was when I began to change the code to prepare this RR to make > the shortcut more visible. :) Sure, this only a single user report but I > don't think I am the only who does not read the whole tooltip. > > Ken Vermette wrote: > As I see it here, the current solution isn't good and I'd argue against > changing things just because they feel stale. Mainly you're trading one > less-than-ideal solution (using a tooltip) in exhange for a solution which is > more complicated and bloats the UI. Why do we need to go so far out of our > way to advertise XKill when we are capable of killing apps from the monitor? > Users of the monitor familliar with the system chould not have purely > informational menus burned into the main UI. > > Split buttons are also abused regularly, and it's not clear what the "V" > menu offers until activated. Why would someone who won't stop for a tooltip > know to press the "V" button? What if they assume it's for other actions like > pause, suspend, and resuming the selected process? Users *still* won't click > it if that's the case. This is essentially a much more convoluted tooltip > which works under the assumption users will investigate it because it's > disguised as functionality. > > I also dislike that it advertised as a feature and not a help option, and > users with a crashing/frozen application will only be more frusterated if > they think they have a solution - and are instead given a manual. Nowhere > else do we use this pattern. Information should NEVER be disquised as > functionality; it **severly** degrades user trust. Imagine if every > application did this - would you use a system which kept popping up with info > boxes instead of doing the work? Especially when you *need* the system to > take care of a problem and the system tells you "I can't do this, try doing > this" - I can think of no better way to shatter a users trust; one thing is > already broken, we should not make it feel
