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

List:       kde-i18n
Subject:    konqygui
From:       Simon Hausmann <tronical () gmx ! net>
Date:       1999-02-17 11:25:37
[Download RAW message or body]

Hi,

I think it might be perhaps good to give a more detailed description about the
gui problem in regard to the "componentification of konqueror" thread. This
might help everyone to
 a) understand the real problem
 b) and it might help to bring up new ideas (hopefully :)

I will now assume that everyone agrees with David's proposal/drawing and
therefore also agrees that KonqViews should be embeddable parts (in general) .

<introduction_about_how_parts_"behave">

Usually every Part is registered to a so called MainWindow
(OpenParts::MainWindow) , which is (seeing it from the c++ side, not from the
CORBA interface side) a KTMainWindow. This mainwindow kind of contains
the shared gui elements like the *bars (the mainwindow "owns" the *bar-managers)
and also "contains" (read: shows) embedded parts (and theoretically it can also
display "plain" QWidgets or stuff like that, just like a KTMainWindow) .
Now when the user clicks on any visible part which
 a) does not have the current focus
 b) accepts the focus (via a parts focuspolicy)
this part becomes the active part and therefore gets the "real" focus.
Beside this, pretty X specific stuff, the mainwindow is notified that the
active part changed.
Usually (!) the mainwindow will then clear the shared(!) gui elements (via the
*bar-managers which will notify the old active part) and then start rebuilding
them by telling the *bar-managers to rebuild them for the new active part. Now
the menubar and the toolbar managers will send an event to the new part, for the
menubar it's the "OpenPartsUI/CreateMenuBar" event and for the toolbar(s) it's
the "OpenPartsUI/CreateToolBar" event.
Usually a part mapps these events and builds up his menubar/toolbar(s) via
given references to menubars/toolbar-factories.

(I hope this is enough of internal stuff in order to understand the upcoming
problem :)

</introduction_about_how_parts_"behave">

Now our problem is, independend whether we want an all-in-one embeddable
konqueror part or not:
We will be in the situation that our embedded KonqViews (not matter
whether they're embedded in a mainwindow or just in an all-in-one part) will be
activated/deactivated by the user pretty often (just imagine how often you
switch between htmlview and iconview once in a session) .
This means the focus between the parts (->KonqViews are still parts) changes
often. In regard to the keyboard focus and all that X specific stuff this is
(of course) not problem, but in regard to the fact that
 a) we want one common and consistent gui
 b) every KonqView is a full-featured part
we have a problem:
In case a KonqView is an "standalone" part, meaning it's not part of a
big-standalone Konqueror but for example embedded in a KOffice app the just
activated part (KonqView) _has_ to build new *bars.
But in case a KonqView is part of an standalone Konqueror (either an all-in-one
konqueror part or a konqueror mainwindow) the new activated view will _NOT_
want a complete rebuild of the *bar structure from the users point of view,
this would be slow and ugly (flickering) .

The point is now
 a) how to distinguish the situations
 b) how to avoid a clearing and then rebuilding of *bars


I already have some ideas in my mind about how we might solve this (persistent
menus, additional openparts focus handling, and stuff like this) but my
thoughts are far from being finished, yet, and I think it's the best to describe
the situation to all people, maybe someone else has a nice idea :-)

(my newest idea is a kind of sub-focus for parts: If a part's focuspolicy is a
sub-focus it will get the focus if the users activates the part, but the
mainwindow will _not_ be notified about the part change)

Greetings,
 Simon (who has to get back to work now instead of "wasting" time for konqueror
        design thoughts ;)

--
Simon Hausmann - Tronical^Colorfast - <tronical@gmx.net> - IRCNet #colorfast

we have joy, we have fun, we have linux on our sun

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