Making launch configurations more usable

[Andreas Pakulat]

On 24.02.10 22:04:30, Alexander Dymo wrote:
> Thanks for going through this. I didn't expect anyone reading all these 
> lengthy comments :)

Well, I'm the author of the code and additionally I'm one of the two
persons having "designed" it, so I had to comment :) 

> > > * 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.
> 
> I have two sessions now. One is "kdevplatform+kdevelop+ruby+php" with just one 
> launch (kdevelop app). Another is my work project (without a launch as I can't 
> launch rails projects yet).
> In both cases for me there's no need for per-project launch configurations.

Hmm. Hmm.... One definitive problem with session-wide launch configs
only is that its not possible to share them between developers - if we
really drop that completely. And thats something I use a lot with fellow
developers at work for the java-project(s). Another case is using
kdevelop with our c++ codebase where I currently (and possibly also in
the future) have one session for the 3-4 builds of the last version and
its simply nice to be able to open one of them inside the session that I
usually use to work on the next version (which is in a separate
sourcedir too). 

> > > ** app templates still need to be able to provide default launch
> > > configuration
> > 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.
> But we need to do this. No user will be able to launch the project without 
> default launch configurations. 

Yes, apparently we need something that sets up a launch config for a
newly created project. The thing is we actually also need something for
an imported project. Ideally it would work the same way as that keeps
the app-templates simple and clean and makes maintaining them easier :) 

> And I don't think that supporting old launch configurations is that much of a 
> problem.

The problem is with an app-template suddenly not having a launch config
anymore because the newer version of kdevelop uses a different format.

> > > * as a top-level items in the leftmost tree we need to have application
> > > types (like in eclipse)
> > No way.
> Hehe, why?

Why do we need them? Whats the problem with the combobox? Actually, I
personally don't care too much, this particular thing is something that
mostly comes from Vladimir. I don't use the launch-config dialog in
eclipse to setup new launches as Eclipse makes it possible to do so
without opening the dialog which is much better.

> > > * 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.
> All launches I created have this "New launch configuration name". I didn't 
> know how to edit them (renaming in the treeview is so subtle).

Last I tried its automatically in edit-mode and even selected. Sorry but
a dialog on a dialog is just wrong.

Apart from that, inline-editing in a treeview is something that gets
more and more widely used and people are accustomed to it. So unless you
present me data that its something thats bad, I'll keep my opinion that
its not :P

One thing the tree lacks is a context menu and also keyboard-actions
though, I admit that. This would probably make some things more obvious

> So, for me naming should be explicit action done in launch
> configuration settings (right part of the dialog).

Lets see it in a .ui file please, I have bad imagination for gui stuff
:)

> > > == Native Application Configuration ==
> > > ** there should not be the current bug when typing a character doesn't do
> > > anything (if there's no completion entry)
> > Complain to Nokia.
> 
> No, we need to automatically open a popup list of all possible completions. 
> Just like our quick open dialog does.

Yes, complain to Nokia or implement it with KCompletion. QCompleter
simply doesn't support this - unless you do everything manually.

> > > * 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.
> 
> Actually it's not true. We do use shell to launch. And I think it's a good 
> idea to do so.

No we don't and thats a good thing. test.sh will work if its executable
, but not if its not executable.

> > > * 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.
>
> Ok, but I mostly referred that you can't know whether you use kdesu or 
> kdesudo.

Right, but which difference does this make? Both ask for a password,
both allow to run as root. Why would a user care about kdesu vs.
kdesudo?

> > > * move remote debugging explanations from what's this to inline microcopy
> > > * provide micropy for "Debugging shell" option as well
> > What is "microcopy"?
> Small text near the widget. We can use the text which is there in what's this 
> entry. I just want it inline. 

Hmm, I don't see enough space in there, would need a screenshot to do a
proper judgement.

> > > == UI ==
> > > * tabs for "Launch", "Debug", "Profile", etc.
> > 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)
> Ok, then we'd need "Execute" child item, just to make it more obvious that we 
> have the same config for executing and debugging.

Agree.

> > > == Suggestions ==
> > > * user-settable shortcuts for launch configurations
> > To activate them as "current" or to directly run/debug them? 
> To directly run/debug.

Agree.


> > 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.
> 
> So, I propose to do at least these before 4.0:
> 1. provide default launch configs for app templates (I do believe this is a 
> release showstopper)

I don't believe that, however as long as someone else does the work I
don't object to that. Its "just" three templates anyway (all others are
in kdesdk).

> 2. Go through debugger options and remove unused ones and inline document 
> others
> 3. Put all gdb options to sliding-down "Advanced" section
> 4. Prefill gdb box with "gdb"

Ok.

> 5. Change "project target" lineedit into a combobox

Whats the advantage? Or are you just thinking of re-using previously
used targets?

> 6. Add "Execute" item to the tree (which would be selected by default when you 
> select parent launch configuration item)

Ok.

Andreas

-- 
Your own qualities will help prevent your advancement in the world.