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

List:       kfm-devel
Subject:    Re: konqueror components (was Re: konqueror issues)
From:       Simon Hausmann <tronical () gmx ! net>
Date:       1999-02-16 11:27:15
[Download RAW message or body]

On Mon, 15 Feb 1999, David Faure wrote:
>> interface KfmView : OpenParts::Part, KfmGui
>> {
>>   void openURL( in string url );
>>   string url();
>> 
>>   What else can be here?
>
>All the stuff that is currently repeated in kiconcontainer and kfmfinder
>(see the comment in my last commit (or below) about this)
>
>Want a list ? Here it is :)
>
>  virtual void setBgColor( const QColor& _color );
[...snip....snip...]

Ah, yeah, I agree with this.

>> }
>> 
>> interface IconView : KfmView
>> {
>>   view specific stuff
>> }
>> 
>> interface TreeView : KfmView
>> {
>>   view specific stuff
>> }
>> 
>> interface HTMLView : KfmView
>> {
>>   view specific stuff
>> }
>
>I agree with this. Currently IconView is called kiconcontainer and doesn't
>inherit from kfmview, but is a standalone class used by kfmview. This
>explains the ugly code that can be found in kfmview right now :
>
>void KfmView::fetchFocus()
>{
>  switch( m_viewMode )
>  {
>  case FINDER:
>    m_pFinder->setFocus();
>    break;
>  case HOR_ICONS:
>  case VERT_ICONS:
>    m_pIconView->setFocus();
>    break;
>  case HTML:
>    m_pBrowser->setFocus();
>    break;
>  case NOMODE:
>    break;
>  }
>
>This could be easily solved by a common parent for all types of view, be it 
>KfmView itself or something else.

I agree.
When I wrote about a KfmView interface I did not really mean the current KfmView
class but (as you named it) a common parent for all types of views:
 a) making it an embeddable part
 b) providing the standard konqueror gui (for consistency)
 c) providing standard view interface methods

>> And then there's (the current) KfmGui, renamed to KfmMainView to avoid
>> name conflicts with the already defined interface:
>
>I don't understand the renaming.
>KfmGui is not a main view, it's a set of view.
>The code below seems to agree with it, so I guess it's just a matter of renaming.
>
>> interface KfmMainView : OpenParts::Part, KfmGui
>> {
>>   (...all the current stuff...)
>> 
>>   addView( in KfmView view ); //this is for the kmultipanner/qsplitter-guys ;)
>>   KfmView view();
>> 
>>   plus some other stuff
>> }

Uhm, my explanations were pretty misleading ;-) . Here's a more detailed
explanation what I actually meant : 

I think of KfmMainView as a kind of mixture of the _current_ KfmGui
and KfmView, meaning it as a general interface to all views. For example
KfmMainView should do all the view-management (hello qsplitter :) .

When I was talking about KfmGui (not the _current_ KfmGui) I mean it as general
class/interface which provides _the_ konqueror GUI as is : The main toolbar, the
location toolbar, the file/edit/bookmarks/options/help menus.

Every view type inherits from this gui class in order to make sure all views
provide the standard konqeror gui in case they get embedded as standalone view.

In addition KfmMainView also inherits from KfmGui (obviously) .

Now imho there are only two questions/design issues/things left:
a) the view menu:
 I think the only visible (read: gui) difference between all view types are a
 few entries in the view menu.
 In order to give kfm views a chance to provide such entries (because usually
 they shouldn't "modify" the *bars directly but instead let their "parent"
 KfmGui do this) KfmGui might contain a virtual method which
 1) has to be implemented by every view type
 2) gets called upon creating of the menus
 The prototype might perhaps look like this (in IDL)
 void createViewMenu( OpenPartsUI::Menu menu ); 

b) Activation/Deactivation | Focus in regard to views in KfmMainView
 Usually (also depending on the shell/mainwindow) views inside KfmMainView
 would be handled as separate parts. But I think in the very special case of
 KfmMainView this should not be so. IMHO the best would be if :
 1) all views and KfmMainWindow would share the same KfmGui
 2) when a view gets the focus the menus should stay as is (read: stay the same
    as the menus of KfmMainView)

The question is: how to implement this? How to tell a view that, if it's part of
KfmMainView, it has to use KfmMainView's KfmGui and not "itself" .
(well, this is perhaps trivial ... ;-)

><snipped>
>I will have to think a bit more about the second part...
>Is there a difference with the proposal above ?

Uhm, I'm not quite sure if I understood your question....


Ciao
 Simon


--
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]