Making launch configurations more usable

Alexander Dymo alexander.dymo at gmail.com
Tue Feb 23 22:29:55 UTC 2010


During the hacksprint I and Niko reviewed launch configurations UI. 

Our main goal was finding the ways to improve usability. We think that while 
current UI has all the features we need, it may not be easy for users to 
figure out how to create the launch configurations themselves.

So, here are the result of our review. Comments are very welcome :)


== General ==
* we don't need per-project config, per-session configuration is perfectly 
enough
** app templates still need to be able to provide default launch configuration
*** maybe describe "default" launch config in .kdev4 file and create launch 
config in the session based on default config
* as a top-level items in the leftmost tree we need to have application types 
(like in eclipse)


== Naming ==
* launch name should be automatically choosen depending on current 
configuration
** <exe | target> <args> [ <env if not default> <working dir only if that's 
the only diff from other configs> ]
** by default it should show "<new launch configuration>" which should be 
automatically replaced by proper name once the user sets the executable/target
* name should not be editable (or at least user should never be asked to give 
launch the name)


== Native Application Configuration ==
* "Project Target" lineedit should work exactly like quickopen line edit
** show all possible values (executables, targets)
** offer completion/filtering
** there should not be the current bug when typing a character doesn't do 
anything (if there's no completion entry)
* s/Native Application/Application
** reasons: it's not clear what "native" is. scripts can also be launched as 
native apps
* need to be able to create a new environment without closing this dialog
* not clear whether "Build and install as superuser" option uses kdesu or sudo


== GDB Configuration
* prefill "Debugger Executable" field with "gdb" when gdb is chosen
* move all gdb configs except for "Debugger Executable" to "Advanced" and hide 
them
* move remote debugging explanations from what's this to inline microcopy
* provide micropy for "Debugging shell" option as well


== Create Configuration Workflow ==
* usecase to fix: modify config, try deleting it - get "save?" question
* the dialog should never be empty on the right
** new launch configuration should be automatically proposed instead
* we need to always have greyed out "<New launch configuration>" child item 
for every configuration type
** this way we no longer need the "+" button
** remove button should be somewhere on the right


== UI ==
* tabs for "Launch", "Debug", "Profile", etc.
** tabs solve the problem of debug being the only child and making an 
impression that this configuration is for debug only
** if not tabs, "Run/Execute" should be in the tree
* combobox inside Debug tab to choose debugger type


== Suggestions ==
* user-settable shortcuts for launch configurations


== Questions ==
* does remote debugging work?
* do we still have floating debugger toolbar?
* what happens to the debugger settings if you choose another debugger
** they should be remembered and not conflict with others
** if i get back previous debugger, i get my settings back



-----------------------------------------------------------------
Mockup of the configuration tree:

- Launch As Application
  - ruby foo.rb
  - ruby foo_test.rb -n bar
  - <click here to create new launch configuration>
- Launch in a Web browser
  - Firefox: http://localhost:3000
  - <click here to create new launch configuration>




More information about the KDevelop-devel mailing list