gideon TODO

[Bernd Gehrmann]

On Sunday 09 June 2002 20:51, you wrote:
> Hi!
>
> > > Maybe a "Code" menu?
> > > But my favorite solution would be to have the possibilty to create a
> > > new class *only* in this contexts where it makes sense (e.g. the class
> > > view or the Automake manager). And not somewhere in the main menubar
> > > where you have no coherence to which target you actually add this new
> > > class. But this is MHO
> >
> > A global action is something you can bind to a key combination. A context
> > menu item is not.
>
> And I think that "Create New Class" is not a global action, but affected to
> a file, a target or what ever.

For automake, you need a target as context in general, because there can
be multiple targets per directory (and that's not only theoretical, the KParts
based template uses it for example). So you have the make the choice how 
to provide the target to which the class should be added. That's of course
a design choice, and tastes may differ.

However, it is clear that when you only want to allow a "New class" menu
item *only* as a context menu entry, then the only place where such an item makes
sense is the automake manager (in other tree views you don't have a target
as context). We talked about it (last year at Linuxtag ;-) and decided that
the concept of an active target would be more efficient to use. You don't 
have to open the automake manager, find the affected target, and then go
through the context menu to open the new class dialog. I think an important
observation is that you don't switch between targets all the time. You work
on one target for a time, create some classes, and perhaps weeks later
you switch to a different target. In particular, authors of simple applications
(take a look at http://www.kdevelop.org/index.html?filename=users.html ;-)
often do not switch their target at all, because everything is in one binary,
in one directory.

> Cloning a class or overwriting a method for
> example is something else in my eyes because there you can chose an
> existing one. These actions would make sense in a global matter.

Hmm, cloning a class implies that you create header/implementation files
for the class, so I don't really see the difference.

Bernd.