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

List:       kfm-devel
Subject:    Re: Bug#4656: konqueror : Default keys to delete files
From:       Dawit Alemayehu <adawit () kde ! org>
Date:       2000-06-29 3:52:04
[Download RAW message or body]


On Sun, 18 Jun 2000, David Faure wrote:
> On Sat, Jun 17, 2000 at 09:59:04PM -0400, Dawit Alemayehu wrote:
> > On Sat, 17 Jun 2000, David Faure wrote:
> > > > I propose to put the following shorcuts under the edit menu
> > > > (so that Windows users can do a easier transition):
> > > > 
> > > > Move to trash    Del
> > > > Delete           Shift+Del
> > > > Shred            Ctrl+Shift+Del
> > > 
> > > IIRC there was a problem with Del, that's why I chose Ctrl+Del.
> > > The problem being: when one hit 'del' to correct a URL in the location bar,
> > > it triggered the action. That may be a flaw in the accel mechanism
> > > (they are be triggered whichever widget has the focus), but... well...
> > > this goes deep down into Qt AFAIK.
> > > 
> > > Oh... how much this triggers bad memories from kfm.... :(
> > > 
> > > Does anyone else know if there is a way to avoid triggering the
> > > "del" action when the focus is in the location bar ?
> > 
> > Okay I run one test on this and it does not make sense.  Since we now use
> > KComboBox in konqy,  I trapped the "Delete" key after manually performing the
> > delete action.  I returned from the ::keyPressed method consuming the event
> > ( e-accept() ).  However I get the same result, i.e. it tries to delete the
> > entry in the icon-view.
> Maybe the accel triggering happens BEFORE the event is sent to widgets ?

Well I finally had a chance to take a closer look at this.  It turns out the
problem is QAccel.  It actually consumes the key events associated with the
accelerators after emitting an activated(..) signal.  Hence, the event is never
propagated past the top level widget.  Actually the emition of the activated
signal  is also a problem.  I have attached a patch that will help solve this
issue at the source rather than hacking around.  This patch should also work for
other apps that need the same flexibility to accomplish the same things.  The
only problem is that it has little chance of making it into an official Qt
release because it breaks binary compatiability!!  Should I simply send a bug
report to the trolls with this patch attached and let them find a better way to deal
with it ??  Or does anyone else know a BC way of doing this ??

BTW, with this patch all we had to do to stop accelerator key events in konqy's
combobox is to re-implement the enable Accelerator function and return false
if the combobox had focus :))

Regards,
Dawit A.


["qt-copy.tgz" (application/x-gzip)]

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