KDevelop UI cleanup initiative

[Jens Dagerbo]

I agree that my proposal is a bit far out, but I still think it's less nuts 
than it might at first appear. I fear I needlessly confused the issue by 
talking in general terms with a specific problem in mind. 

The only part I could think to treat like this is katepart. Read on.

> > Disregarding version issues, the solution might be as easy as this:
> > Let the embedding app decide for the part what ui.rc file it should work
> > with.
> > This would let the embedder (us) decide the layout of the part's menus
> > and override its shortcuts.
> > Is this doable? Maybe already today? Is the version problem solvable?
>
> As i already said, i have to disagree in this point.
> To get it together in few words: You want to tell the part what ui.rc it
> has to use? And you want this in order to tell it what shortcuts it shall
> use?

Not exclusively shortcuts. I was mostly thinking about the possibility to 
rearrange menus, push entries into submenus and get access to an xmlgui 
description of the editor context menu that could be extended to fit KDevelop 
better.

> As shortcuts are not stored in ui.rc file by default, i doubt this would
> work. But that's not the main point here. If i understand you correctly
> (thus my summary above is right), then this is totaly contrary to what
> XMLGUI+KParts is meant for:
>
> The embedder should need no clue of what it embeds - and vice versa. One
> could in theory come and port mozilla to be a kpart; and then use it as a
> replacement for the KHTML Part. Well, this is bloody theory; but it tells
> how it was meant.

While it may be true that in theory, we shouldn't "know" what part we embed, 
this is clearly not the case for the editor. You've seen the stunts we pull 
to get a half decent editor integration, right?

Not only do we play with the editor part through the KTE interfaces, we also 
connect to unpublished signals, and which is the topic of this discussion: we 
hunt down XMLGUI actions _by name_ to connect to them, or unplug them.

These are places where we break the nice encapuation of the framework, but 
they are things we currently need to do to get things to work. With this 
background, maintaining a kdevelop-specific katepartui.rc file and force 
katepart to use it isn't _that_ ugly, and it would let us do a lot of 
adjustments for our benefit, without changing stuff around runtime. 

(In current KDevelop, at least one action is looked for on ever part 
activation to remove it if it is found. I'll probably have to add more of 
these if we're to be able to stop katepart from overwrite files which have 
been changed on disk.)


> If we could do it like your suggestion, then we could simple create a
> common projectmanagerui.rc and feed every project manager with it. This
> won't work out for the same reasons: every project manager has different
> actions - so how could we create a ui that is sane for all of them?

Good thing that was never my intention to suggest then.


> Back to the default shortcuts: They are assigned in code. Actually in the
> KAction constructor. I have no clue where they are stored, if one changes
> them. But i doubt, that it is the ui.rc file ( because then they could be
> stored there right from the start ?!? )

You may doubt it (and I don't blame you), but it is in fact, fact. :)

I fully admit that feeding a katepart a different ui.rc file is a hack of 
proportions, but it is still cleaner that what we currently do, and from a 
quick glance actually seems to solve a lot of our immediate issues.

This point is of course very much moot if what I suggest here isn't doable 
even in theory...


> But maybe shortcuts should be "allocated" in a way, that the embedder is
> asked if a certain part can allocate a certain short cut of it's usage.
> Default implementation of course would allow every short cut to be
> allocated. KDevelop could then forbid some short cuts to be allocated by
> certain parts.

Yes, this doesn't sound too bad. Some mechanism like this might work. But this 
is KDE4 stuff at the very least and would take fundamental modifications to 
the framework.


jd