Making launch configurations more usable

[Andreas Pakulat]

On 24.02.10 00:29:55, Alexander Dymo wrote:
> 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

How do you know that? In fact, I don't have any session-specific launch
configs, they're all inside the project as they _belong_ to the project.
I strongly object removing that.

> ** app templates still need to be able to provide default launch configuration

That would only be possible by knowing the config-file-layout for launch
configs and internals of the config-type. I find that somewhat
problematic to expose, especially in the light of app-templates created
outside of kdevelop (our control) as we can't easily change the
config-layout anymore.

For buildsystem-using app-templates it would be possible to have some
kind of default-target that we could hand over to a launch-config-type
to generate a config. But that doesn't work for script projects...

> *** maybe describe "default" launch config in .kdev4 file and create launch 
> config in the session based on default config

That is problematic as we can't delete stuff from the foo.kdev4 in the
project dir currently. So it should probably rather be in the
template-file and be handed over to the launch-config-type or controller
to generate the config in the project.

> * as a top-level items in the leftmost tree we need to have application types 
> (like in eclipse)

No way. 

> == Naming ==
> * launch name should be automatically choosen depending on current 
> configuration

This only works when using the context-menu option to create a config as
one cannot know what the target or executable will be when creating one
in the dialog. And having the name non-editable is not good either as it
makes it impossible to have different launch configs for the same app
but different env/arguments setup.

> ** <exe | target> <args> [ <env if not default> <working dir only if that's 
> the only diff from other configs> ]

Far to long IMHO, as you'd have to use the complete path given as
executable or the complete path. The target name can be ambigious
(especially on global configs with multiple projects) just as well as
the executable name.

> * name should not be editable (or at least user should never be asked to give 
> launch the name)

Definetly a no to the first part. If you can find a way to generate
non-sucking launch-names from the parameters the second part would be
probably ok.

> == Native Application Configuration ==
> * "Project Target" lineedit should work exactly like quickopen line edit
> ** show all possible values (executables, targets)

It already does.

> ** offer completion/filtering

It already does.

The only problem is that Qt's completion stuff is completely broken for
anything but a plain google-like searchfield. On the other hand
KCompletion would need us to implement a lot of logic as it has no
pre-made functions to complete from a given model (wich QCompletion
supports). Thats why the completion currently requires you to know at
least a starting-item.

> ** there should not be the current bug when typing a character doesn't do 
> anything (if there's no completion entry)

Complain to Nokia.

> * s/Native Application/Application
> ** reasons: it's not clear what "native" is. scripts can also be launched as 
> native apps

I object. An application is also foo.sh, but its not launchable by the
execute plugin. If you have a better name instead of Native that says
"execute as process in your system without a shell" please share it.

> * need to be able to create a new environment without closing this dialog

FACK, been on my todo-list since ages. Needs to be done in a way that
all places gain this, i.e. a new widget that can be used instead of the
plain combobox.

> * not clear whether "Build and install as superuser" option uses kdesu or sudo

IMHO as KDevelop is a KDE app its clear that it uses the kde-versions of su and
sudo. But if you want to add an explaining comment to the
tooltip/whatsthis please do so. 

> == GDB Configuration
> * prefill "Debugger Executable" field with "gdb" when gdb is chosen

+1 always confuses me :)

> * move all gdb configs except for "Debugger Executable" to "Advanced" and hide 
> them

Most of them don't even work :)

> * move remote debugging explanations from what's this to inline microcopy
> * provide micropy for "Debugging shell" option as well

What is "microcopy"?

> * the dialog should never be empty on the right
> ** new launch configuration should be automatically proposed instead

You mean a button that creates one? Where does it create it global or
project?

> * we need to always have greyed out "<New launch configuration>" child item 
> for every configuration type

I've recently implemented this for my custombuildsystem plugin and its
really easy (didn't know how easy back when I wrote the code, else we
would have it already). So +1

> ** this way we no longer need the "+" button
> ** remove button should be somewhere on the right

Hmm, I think it can also be below the tree, additionally context-menu
and Del button should work for deletion.

> == 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

I'd prefer the second, I don't like the tab-ui of eclipse very much.
And if you build and install valgrind plugin you'll suddenly have arrows
on the tab-list (as each valgrind-tool has a separate config page)

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

To activate them as "current" or to directly run/debug them? Personally
I'd like to drop the "current launch config". IMHO Eclipse way of doing
that part is quite Ok, except for the "takes the current selection after
initially starting eclipse, but never again later on". So what I think
we should have is the launch-configs in a submenu under Debug and also
under Launch. And a toolbar button with dropdown. Both the toolbarbutton
and Debug/Launch menu entries are directly executable which simply
launches the last-used config.

> * do we still have floating debugger toolbar?

No.

> * what happens to the debugger settings if you choose another debugger
> ** they should be remembered and not conflict with others

I'm not 100% sure about the separation right now, but I think each
debugger-type gets its own config-group. 

> -----------------------------------------------------------------
> Mockup of the configuration tree:
> 
> - Launch As Application
>   - ruby foo.rb
>   - ruby foo_test.rb -n bar

    - /usr/local/bin/kdevelop --nocrashhandler -s custombuildsystem
    - /home/andreas/kdevelop/bin/kdevelop workdir: /home/andreas/temp/

Doesn't work for me, even if there wouldn't be the fact that I want to
keep global+project in the tree and don't want the app-types as
tree-items.

Additionally I'd like to note that most of this will have to wait for
4.1 IMHO, most of the changes are too big to push them this late in the
cycle.

Andreas

-- 
You are fighting for survival in your own sweet and gentle way.