Shortcut Clashes (Re: Direction of KDevelop4)

[Fracassi at t-online.de]

On Monday 12 September 2005 15:57, Andras Mantia wrote:
> On Monday 12 September 2005 16:46, Adam Treat wrote:
> > On Monday September 12 2005 9:27 am, Andras Mantia wrote:
> > > On Monday 12 September 2005 15:56, Adam Treat wrote:
> > > One of the reasons of the mess in the UI is the KPart and XMLGUI
> > > framework and the fact that there are independent plugins. This can
> > > cause:
> > > - long menus with unneeded items
> > > - conflicting shortcuts
> > >
> > > Solution? I don't know if there is a good solution. :-(
> >
> > The time to start brainstorming is on the horizon ;)

> Yes. A way to deal is that we remove unneeded entries/actions. But this
> can be done only for parts we know. So we know that if the Kate part is
> loaded, we don't need the (random pickup) View -> Switch to command
> line. But if a random part is loaded, we don't know what we need or we
> don't need.
>  Conflicting shortcuts might be easier to solve: on part loading iterate
> through the shortcuts and if they conflict with some main KDevelop
> shortcut, than disable them. The problem: there are only a few (if
> there are any) KDevelop shortcuts, almost all of them are in plugins.
> What if the debugger plugin wants to use F7, the search plugin wants to
> use it as well, and Katepart already uses it? Either we know which
> plugin is the most important and gets F7, or the first one is served
> with it.
> Other ideas are welcome. ;-)

I already presented this idea over a year ago, but someone told me that it 
would need too much infrastructure, and had to wait until KDE4. Seems that 
the time is better now.

My proposal is exactly reversed than Andras'. I would prefer that the 
shortcuts are dictated from the framework, and not the parts. This would make 
it easier to get consistant shortcuts in applications. Ultimately the  scheme 
can be extended to the whole KDE, which would make shortcut-themes possible.

Description:
The KPart registers any action (with a default shortcut) which it offers. 
The embedding application then checks wether it "knows" about the action in 
which case it assigns a Shortcut to the action. If the action is unknown to 
the embedding app, the supplied default shortcut is used if it doesn't clash 
with any other shortcut. (It has to be decided if the embedding app or the 
part takes precedence in this case, I think the framework has better chances 
to prevent clashes)

The same thing should then be done on the Framework level, that means in our 
example, that KDevelop registers all its actions (its own, and the ones 
it provides through KParts) with KDE (or some variant of KHotkeys.) which 
works exactly as above.

What does this architecture archive? 
It avoids Shortcut clashes.
It would make it possible to globaly use Shortcut -Themes.
The embedding app can override the shortcuts of its Parts, but doesn't have to 
do so.

Where is the catch?
The whole thing depends on the registration of the Actions, which would need 
suitable names. These names have to be standardized, so that the same Action 
gets the same shortcut throughout the app (framework). Let's say that we want 
to register an Shortcut for Paste then the embeding app has to know about the 
name the KPart has used to register Paste.
The Problem is that a suitable Standard has to be found and agreed upon KDE - 
wide (Or even on freedesktop.org), like it is done with icons, menu entrys, 
mouse cursor icons, etc.

Well just an idea, please tell me what you think of it.

Fabio