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

List:       kfm-devel
Subject:    Re: konqygui
From:       Michael Reiher <michael.reiher () gmx ! de>
Date:       1999-02-18 1:50:07
[Download RAW message or body]

Uuhhh, whatīs going on here? I was only two days away!:)

David Faure wrote:
> 
> On Wed, Feb 17, 1999 at 12:25:37PM +0100, Simon Hausmann wrote:
> > 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) .
Hmm, yes sounds good!

> >
> > <introduction_about_how_parts_"behave">
> (...)
> > </introduction_about_how_parts_"behave">
> 
> Thanks for the explanations.
> It really looks like this is good only for koffice documents (well, the
> views of those documents), not for konqueror normal (html & filemanager) views.
> 
> > 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) .
> Yup, and it's not only when switching between view modes, it also when switching
> >from left view to right view, which happens even more often when you have
> two views !
> 
> I have an idea, following to my remark above : there are two completely
> different things we want to do :
> * use several 'normal' views, often : the HTML and filemanager views
> * use, sometimes, another app. embedded in konqueror, for reading mail, ...
> 
> Why not do a KonqView, only one, that can contain several ... hum...
> "sub-views", those being either HTML, Icons, ...
> And kfmgui will be able to embed other views, i.e. from other apps.
> 
> Let's go for another drawing, I'll let you do the IDL.  :)
> 
> I had yet another namespace problem, so I will name the IDL interface for a
> "view" (previously "KonqView") as "KonqPart".
> 
>              KonqPart   - the IDL interface
>                |
>           -------------------------------------------
>           |                    |                    |
>         KonqPartImpl      "OutlookLike"View        ...
> 
> 
> KonqPartImpl the implementation of KonqPart as done in konqueror (I'm very
> bad at finding names). (Do we really need two names here ?)
> The holding of KonqParts in KonqGui could be done just like a koffice app,
> then. Some sort of MDI. Because when using konqueror as a file manager /
> web browser, it would be always in the same window.
> 
> A KonqPartImpl holds several KonqViews, arranged in a KMultiPanner or whatever widget.
> This enables to keep the same Part (in terms of IDL / openparts), while
> browsing, and therefore reduces flicker a lot.
> 
> The different kinds of KonqView would be organised this way :
> 
>                   KonqView
>                      |
>           ------------------------
>           |                      |
>          KfmView              HTMLView
>           |
>       -----------------------
>       |           |         |
>      IconView  TreeView    ...
> 
> What do you think ?
> 
> Of course, this doesn't solve the problem whether KfmGui is a part too -
> but then I think it could be, if you implement the menu-merging solution.
Wouldnīt menu merging solve all the above problems as well? 
I somehow donīt really like that particular approach. If you have a
mailreader (to take again our famous example:) embedded you will also
switch very often between this and the file or even better the HTML
browser. I think Netscape and KMail both display mail via their HTML
widget! I would rather go one step back again and create equaly treated
views for all tasks(icon view, tree view, HTML view, foreign views) and
try to find a solution for the menuproblem. 
So wouldnīt it be possible to make the views tell the
what-ever-is-itīs-current-name-mainwindow what menues theyīd like to
have? (Somewhere else here was a proposal to make only the "View" menu
view specific. Thatīs IMHO also too limiting. For the mail view for
instance a "Messages" menu might be useful.) So the view would just say:
I want a Messages menu with these and that items, further these items in
the Options menu and that in the File menu. On activition the main
window would take those entries and setup the menu accordingly (merge
with a basic set of menus), and remove them on deactivition. 
Or maybe the menubar could even store the menu structure of all
registered views internally and then built the basic menus dynamically
and add additional menus when activating the views. 
Something else what just comes to my mind in connection and what Iīd
consider useful is that some menus shouldnīt be removed on focus loss of
the view. If for instance kmail provides a widget to display the
contents of mail folders. The tree to display the folders and the HTML
widget to display the message text are the standard views. The view
embedded from kmail provides a Messages menu with among others a Reply
entry in it. But if it gets removed when switching e.g. to the HTML
view(some poeple might want to scroll:) you canīt Reply anymore. Unless
you activate the kmail view again. So it would be good if the Messages
menu is visible as long as the kmail view is _visible_.

BTW: Am I right that currently the views built the _complete_ menubar
themself? 

Michael

-- 
Michael Reiher  
     Student at Dresden University of Technology
          Department of Computer Science
               email: michael.reiher@gmx.de

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