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

List:       kfm-devel
Subject:    idea about keyboard traversal in khtml
From:       Simon Hausmann <shaus () helios ! Med ! Uni-Magdeburg ! DE>
Date:       2000-04-20 21:49:27
[Download RAW message or body]

Hi,


I just noticed that khtml (khtmlview) has some nice code for keyboard
traversal (like traversing over the links) .

While looking at the code in khtmlview I wondered: Why not implement this
as a separate aggregate component (thus making it configurable and making
khtmlview more lightweight) . AFAICS all the stuff the keyboard traversal
needs could be handled/implemented in a separate object by making use of
Qt's event (filter) concept and by using the Qt object model to add the
aggregate object as child object, thus making it queryable.


(this reminds me of all the *Hook methods in KHTMLPart -- couldn't they be
implemented using event filters, too? (thus not making it a requirement to
inherit from KHTMLPart in order to be able to use it?)


I mean: All this (the hook stuff and the keyboard traversal code) reminds
me very much of Torben's KOM design, back in the CORBA days :-) . In these
days we would have implemented this stuff as aggregate objects, following
the idea of components to extend the functionality ( adding new
interfaces) without inheritting from the encapsulated implementation.

Yes, we dropped KOM, but I still think that the Qt object model provides
100% the same functionality (plus additional stuff like the Qt property
system) . (we can add new interfaces for example, simply by making the
extension a child qobject. that makes it queryable via QObject::child,
which is something we use in Konqueror since the first days after the
CORBA-to-plain-Qt port, at KDE-two :-)

I admit that I liked that design a lot.


What do you think? Does that make sense? Wouldn't it make things more
lightweight?


Bye,
 Simon

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