Fix for Bug 45195: Cannot close terminal emulation with Ctrl+D anymore (major)

[Ellis Whitehead]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Tuesday 01 October 2002 17:42, David Faure wrote:
> On Tuesday 01 October 2002 17:29, Ellis Whitehead wrote:
> > On Tuesday 01 October 2002 17:08, Oswald Buddenhagen wrote:
> > > On Tue, Oct 01, 2002 at 04:56:12PM +0200, Ellis Whitehead wrote:
> > > > This means that Ctrl+D will always be overridden when TEWidget has
> > > > the keyboard focus, no matter what program it's embedded in.
> > >
> > > i don't like the idea that you limit this to ctrl-d. about any
> > > ctrl-<key> should be passed through.
> >
> > The important question for me is whether any accels should be overridden
> > at all.
>
> Yes, I definitely agree that they should.
> The key event should go to the focus widget first (here the konsole part,
> and in case of Ctrl+D it should catch it). The mainwindow stuff should only
> be looked at afterwards, for shortcut not handled by the focus widget.

Ok.  In the case of TEWidget though, Ctrl+D isn't defined a KDE accelerator, 
and thus the KDE IDE has no way of knowing about it.

> > If so, this patch can go in, and it would be no problem to make the
> > accel override apply more broadly.
>
> I'm not sure how, but I'd like this to be much more general, somehow:
> any widget should be able to catch shortcuts before the mainwindow sees
> them. It looks like this means we have to use AccelOverride almost
> everywhere, in parts and widgets ?

Yes, maybe, but I think I finally have a simple solution: KAccel inserts 
itself as an eventFilter for it's watch widget and looks for 
QEvent::AccelOverride events.  If it receives a shortcut that's in it's own 
collection, it indicates that the event should be overridden, and triggers 
it's own accelerator.  In most cases (i.e. where there is no conflict) this 
will be the same accelerator that Qt would have triggered.

In case you're interested in some more of the details, when a key is pressed 
the sequence of method calls looks something like this:

	QApplication::x11ProcessEvent
	QWidget::x11EventFilter (if any filters are installed into qApp)
	QWidget::x11Event (for the event window)
	QAccelManager::dispatchAccelEvent (here Qt accelerators are processed)
	if keypress matches accel shortcut,
		QWidget::event:AccelOverride (for the chain from focus widget to toplevel)
		if not overridden, trigger SLOT and end event sequence
	QApplication::notify
	QObject::eventFilter
	QObject::event
	QWidget::keyPressEvent

What I've been trying to figure out is how to get the desired accel handling 
without completely skipping the Qt accel mechanism.  Qt makes a number of 
checks that I don't understand (such as testWFlags(WSubWindow)) before 
executing accels, but I'm sure that they're important. *grin*  I'm not sure 
that the solution I mentioned won't introduce new bugs by inadvertently 
skipping some of Qt's checks?

Anyway, I will probably have a patch ready tomorrow.

Cheers,
Ellis
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQE9mh//uM2+lxOp6nwRAo4ZAKDJSToHck6Vj0Jvfkx+aFYAHRMmCgCg31j/
dwOHvQ0GPxFK65Dh5eg0yDQ=
=BtSi
-----END PGP SIGNATURE-----