[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-core-devel
Subject:    Re: Accelerators for KParts
From:       Simon Hausmann <shaus () helios ! med ! Uni-Magdeburg ! DE>
Date:       2000-03-22 15:21:38
[Download RAW message or body]



On Wed, 22 Mar 2000, David Sweet wrote:

> > 
> > 
> > But, hmmm, yes, you're right, it'd be cool if we had some sort of
> > mechanism to "detect" accelerator conflicts. how? :)
> 
> Accelerators could go in the XML GUI file, then when the part's XML file
> is merged with the shell's XML file conflicts could be resolved according to
> some rules.  Rule suggestions:
> 	1) Accelerators for the containing application (Konqueror) could take
> precedence over accelerators for the part so that the part would just have no
> accelerator when there is a conflict (there are always at least menu entries
> for any application function, so the user won't lose access to the function).  	
> 	2) Part accelerators could get a SHIFT modifier prefixed to them so
> that CTRL+Key_G --> SHIFT+CTRL+Key_G when the part is embedded in a shell that
> already uses CTRL+Key_G.
> 	3) All part accelerators could get a SHIFT prefixed to their
> accelerators.


That sounds cool IMHO.

And yes, we will soon be able to define action properties in the XML, too
(which will then override the buildin ones, and which will enable us to 
implement "accel merging" :-)

The only problem is: In order to implement this, QAction needs to get Qt
properties, which is impossible, as we still don't know anything regarding
libqk and possible modifications on qaction.cpp/h .

*sigh*


Bye,
 Simon

[prev in list] [next in list] [prev in thread] [next in thread]