KDevelop UI cleanup initiative

[Sascha Cunz]

On Sunday 30 May 2004 20:55, Jens Dagerbo wrote:
> 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.

[big snip]

Jens, i see your point; and i must admit, that the proposal of this kludge 
looks cleaner than the kludge we currently have.

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

It is exactly the same thing in theory :-)

> > 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. :)

This is nuts.

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

Point is, we must face the fact, that kdevelop is (along with Kontact and the 
KOffice suite) one among the biggest KDE Applications that have to use the 
framework. And i think, we currently fail to do a good job here.

KMail for example does not need to scope with it as much as we need to 
(because the composer window is not embedded into the main app). KOffice Apps 
mostly embed each other - so they are fine out of it. But what we depend on, 
is to use the framework (action system; xmlgui; kparts). Thus we should dig 
deeper into it; and posibly try to make it fit better for an application like 
KDevelop. I know of no application that has such big problems with XMLGUI as 
we have.

Cheers Sascha