[KDE Usability] Review Request 120171: Add option to allow execution as well as opening of scripts and desktop files

Tue Sep 16 07:59:04 BST 2014

> On Sept. 14, 2014, 11:22 vorm., Frank Reininghaus wrote:
> > I had planned to work on this for quite some time, but there was always something that looked more urgent, so I never got round to it. I apprecitate that you took this effort now, and I'm sure that many users will appreciate it too!
> > 
> > I strongly recommend to add the usability team as reviewers to this request though, to discuss with them what the best solution for this issue is. I am not sure if we really want to provide that many options to the user. Adding more options always looks great at first sight, but they may confuse the user, make the settings dialog less usable, and they add more code paths, which make the long-term maintenance harder and possibly lead to lots of new subtle bugs. 
> > 
> > In particular, the "embedded terminal" and "external terminal" options offer very similar functionality, so it seems questionable if we really want both. Even more so if one of them ("embedded") requires more changes to the code and a new "do you want to replace the running program" dialog, and will most likely introduce new bugs (in my experience, any change to the terminal panel is likely to cause unexpected problems, which may be very hard to fix, see, e.g., https://bugs.kde.org/show_bug.cgi?id=305085 ).
> > 
> > Moreover, I think it might be worth considering to offer all options in the "What do you want to do" dialog already (Execute/Open/Open in terminal/Cancel), but these are just my 2 cents - this should really be discussed with the usability team.
> 
> Arjun Ak wrote:
>     >In particular, the "embedded terminal" and "external terminal" options offer very similar functionality
>     
>     The embedded terminal can execute only one program at a time. User will have to wait for it finish execution before he can run another one.
> 
> Thomas Pfeiffer wrote:
>     "Usability person" here, thanks for pinging us.
>     
>     Let's see what we're trying to accomplish here.
>     My take is that this feature is foremost useful for executables which do not need any further input from the user (and the user would not need the stdout output). Just click it, run it, done.
>     If that is what we're aiming for, then just defaulting to "background" is completely sufficient.
>     If people want to run the application interactively, they'd have to go the traditional route and enter the command directly in the terminal.
>     
>     If we also want to support interactive shell execution with this, then of course we'd need the option to run it in a visible terminal. However, I don't see this being a global choice. People would still run executables that don't need any interaction in the background, but run those that need further input (or where they need to see the output) in a visible terminal.
>     
>     Therefore, I agree with Frank that the "Execute in" sub-options add to the complexity of the UI without adding much value.
>     
>     Personally, I would suggest aiming this feature only at executables that can run in the background just fine, and have users type it into the terminal themselves if they need additional input or output.
>     If you absolutely want to support input/output, I fear this choice has to be made in the dialog itself (so it would only work with the "Always Ask" option to be useful.

I'm not sure that your considerations meet all use cases. Or perhaps I don't understand the feature at all. What is an 'executable' that opens as a file? I guess a document that has been registered to an application, or a file with executable flag set. And if I chose "Open file" what happens in case of a real executable? In respect to use cases: Doesn't users want to configure such behavior for every type of file/document individually?

However, I have two comments to the prototypes:

The text "A program is running. Do you want to replace it?" might be misleading. Use the real program name, if possible, and text something like "Do you want to stop/kill/terminate it?" Perhaps users want to wait for the process too (and build a stack of executions thereby).

Second comment is about the configuration. The subordinate radio button group looks weird and is not according to the HIG style. A solution would be to put all suboptions into a dropdown and place this right of the "execute in" item. And, of course, disable the dropdown unless the "Execute in" option is selected.

- Heiko

-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/120171/#review66452
-----------------------------------------------------------

On Sept. 15, 2014, 10:12 nachm., Arjun Ak wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/120171/
> -----------------------------------------------------------
> 
> (Updated Sept. 15, 2014, 10:12 nachm.)
> 
> 
> Review request for Dolphin, KDE Usability and David Faure.
> 
> 
> Bugs: 275405
>     http://bugs.kde.org/show_bug.cgi?id=275405
> 
> 
> Repository: kde-baseapps
> 
> 
> Description
> -------
> 
> This patch allows the user to execute (in background, within the embedded terminal, external terminal) or open an executable file (scripts, desktop files...). When the user clicks on an executable file, a [dialog](https://git.reviewboard.kde.org/media/uploaded/files/2014/09/12/0fa53887-666f-4121-9ec6-9f323d633d03__dialog.png) pops up which contains options to either open it or execute it. Clicking on execute runs the program in the background (dolphin's current behaviour).
> 
> The [settings dialog](https://git.reviewboard.kde.org/media/uploaded/files/2014/09/12/cd4d14d3-dd82-4c2c-8c0a-c2a428c78903__settings.png) has further options to fine-tune how the file is executed. The program can either be executed in the background or inside the embedded konsole or in an external terminal.
> 
> In case there is a process already running in the embedded terminal, with [user's permission](https://git.reviewboard.kde.org/media/uploaded/files/2014/09/12/c5d7843a-099a-43d4-a2e1-6ce429623866__replace.png) it will be terminated and the selected program will be started.
> 
> 
> See also:
> https://git.reviewboard.kde.org/r/118939/
> 
> 
> Diffs
> -----
> 
>   dolphin/src/views/executablefileopendialog.cpp PRE-CREATION 
>   dolphin/src/dolphinviewcontainer.cpp a11ba42 
>   dolphin/src/settings/dolphin_generalsettings.kcfg 849a9c7 
>   dolphin/src/settings/general/behaviorsettingspage.h 7a9c2f0 
>   dolphin/src/settings/general/behaviorsettingspage.cpp cbbde1d 
>   dolphin/src/views/executablefileopendialog.h PRE-CREATION 
>   dolphin/src/CMakeLists.txt 6f256a2 
>   dolphin/src/dolphinmainwindow.h 9d4c003 
>   dolphin/src/dolphinmainwindow.cpp 95b08af 
>   dolphin/src/dolphinviewcontainer.h 31612f1 
> 
> Diff: https://git.reviewboard.kde.org/r/120171/diff/
> 
> 
> Testing
> -------
> 
> 
> File Attachments
> ----------------
> 
> Dialog
>   https://git.reviewboard.kde.org/media/uploaded/files/2014/09/12/0fa53887-666f-4121-9ec6-9f323d633d03__dialog.png
> settings
>   https://git.reviewboard.kde.org/media/uploaded/files/2014/09/12/cd4d14d3-dd82-4c2c-8c0a-c2a428c78903__settings.png
> Replace current program
>   https://git.reviewboard.kde.org/media/uploaded/files/2014/09/12/c5d7843a-099a-43d4-a2e1-6ce429623866__replace.png
> 
> 
> Thanks,
> 
> Arjun Ak
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.kde.org/mailman/private/kfm-devel/attachments/20140916/93250678/attachment.htm>
-------------- next part --------------
_______________________________________________
kde-usability mailing list
kde-usability at kde.org
https://mail.kde.org/mailman/listinfo/kde-usability