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

List:       kfm-devel
Subject:    Re: konqygui
From:       David Faure <David.Faure () insa-lyon ! fr>
Date:       1999-02-18 8:56:56
[Download RAW message or body]

On Thu, Feb 18, 1999 at 03:29:30AM +0100, Michael Reiher wrote:
> David Faure wrote:
> > 
> [very large snip]
> 
> To bring the current discussion to one point: Wouldn´t all those
> problems be obsolete if we use some intelligent menu merging or dynamic
> menu building to avoid the menu rebuilt including heavy flickering on
> view change? 
> No need for neither a sub-kind-of-gui-hidden-focus mode nor specially
> treated kfm views or stuff like that.
> Or do I completly miss something?

You're right.
This is the conclusion Simon and I came up with yesterday night after a
long irc discussion. Let me summarize.

There were recently two proposals made to this list.

Proposal one :
 complete logical componentification (every view is a part; its methods 
 are accessible through the same interface, too; the active part (in 
 OpenParts) is the active view

Proposal two :
 a componentification on a higher level - a part can have several "views", 
 each being in its own mode...
 So these views are _NOT_ parts but still have their own interface.
 The goal is that several of them can be put in one KonqPart
 (so that switching between them is not a switch between parts)

The first one was made by me as a slight alteration of Simon's first
proposal, and I suggested the second one to solve the flickering problem
when a standard use of konqueror is done (I mean simple file management).

Comparing both solutions, Simon said :
"about the second proposal : on the one hand I like that this would solve
in somehow the common-gui problem in regard to openparts
I like the idea of when wanting to embed "anything" from konqueror
that one can "compose" it's view-window...
but here's what I prefer from the first proposal :
I like the flexibility and the way how Konqueror would get componentificated
with the first proposal for example a htmlview could be an a kind of 
separate component accessible via it's own interface with the last
proposal a html-view still remains quite unaccessible from the "outside"
[this last point is discussed right below]

Then we discussed the problem of scripting (remotely controlling a HTML
view, for instance), but the discussion was rather a misunderstanding :
Simon said scripting a HTML view couldn't be done in proposal two. In fact,
scripting can be done if the KonqView has an IDL interface.
So the question is : can a class have an IDL interface and be remotely
controlled even if it's not a part ? I think so (I had a look at kspread IDL : 
Table is in the IDL but is not a part, and I guess it can be scripted).

The idea behind the second proposal is to avoid switch between parts.
Either we say "we don't want to switch between parts for simple file
manager operations" because of the flickering problem, or we say "we
implement the persistent menus, and let it be a switch between parts".

It's a really DIFFICULT discussion", as we said, in the middle of it...

Embedding two views at a time in another application is still possible in
first proposal, it would mean embedding two parts, which involves that :
 a) the parent who embeds the views fully controls the part's geometry
 b) we still might write an KonqKMultipannerPart ;-) which does the
    layout-job _if_ someone wants this 

In fact, the choice between the two solutions is, imho, related to a GUI
problem too. The question is, do we want the following :

(1) an embeddable window split up into four views
- the left-upper one should contain an iconview
- the right-upper one an aktion-window playing a movie
- the right-lower one an ftp-tree
- the left-lower one an embedded part (a "plain" part, not a KonqView 
   or anything similar)

(2) Or, to read mail for instance, a window split up into three views :
one for showing the folders, one for the messages in the folder, one for
the message itself.
As Waldo told me : "a user opens a new window when he wants to read mail",
because reading mail might involve more than one view.
(Add in this argument the tree-view like in kfm II, bound to another view.)

The answer, is, in fact : we want to be able to do both (1) and (2). Right ?

(1) is no problem in both proposals. It's just 4 parts.

About (2) : in proposal one, those N views bound together are N parts, and
the controlling application has to 'export' N parts and deal with them ; in
proposal two, the N views are inside the same part, so the controlling app
only exports one part. Ok, this comparison doesn't tell which is best :)

In fact, (2) is possible in proposal one only if the following can be done :
The mail program (which would have a kind of QList of it's these three parts)
simply "says" (thought KonqMainView's interface)
"hey, move the first part here, the take this part and so on..."
The way how these parts(=components) communicate between each other
is actually a matter of the mail program :-)

It means that it's up to us to implement this functionality in KonqMainView :-D

[Personal comment on this (wasn't brought up last night) : but it means
that in koshell, you would only be able to embed ONE view from konqueror.
Currently when you embed konqueror you get two views if you click 
"split view".]

Next point of comparison was : if we want to emulate kfm II's tree view, a
tree view with only directories, following an icon view, can we do that in
proposal one, where views are supposed to be independent ?

The answer is yes :
if a KonqTreeView should make a KonqIconView follow it's "moves" he
simply has to access the KonqTreeView's interface :-)
or even better: he has to use a KonqView's openURL method in general
this way you could make a KonqTreeView follow everything :-)
And the other way round (when clicking on a tree view icon) :
the KonqTreeView calls the openURL method of it's assigned KonqView
So this is no problem, except that in a four-views window, the problem is
how the user chooses which tree follows what.

-------------------------------------

Finally, it looks like we can do what we want with both proposals. But
- the first one involves implementing something in openparts (persistent
    menu to solve the flickering problem)
- the second one is more complicated in terms of design (more classes).

So I think we can conclude that
"if we can solve that menu problem (if it's technically possible and if
Torben agrees), then let's go with proposal one. Otherwise, let's go for
proposal two".

Furthermore, other apps would benefit from the persistent menu
functionality, so it would be a good thing to do it anyway.

Now the question is
* how to get Torben's opinion on the openparts problem
* what do other people on this list think ?

Michael, it looks like you got to the same conclusion - a lot quicker than
us. [However, the discussion was good because we made sure what we wanted
to do in konqueror - from the user point of view -, and we made sure that
it could be done with both proposals].

-- 
 ____________________________________________________________________
|                                                                    |
|  David FAURE                                                       |
|  E-mail : David.Faure@insa-lyon.fr, faure@kde.org                  |
|  http://www.insa-lyon.fr/People/AEDI/dfaure/index.html             |
|____________________________________________________________________|

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