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

List:       kde-i18n
Subject:    Re: konq_mainview discussion
From:       Simon Hausmann <tronical () gmx ! net>
Date:       1999-03-01 17:34:35
[Download RAW message or body]

On Mon, 01 Mar 1999, David Faure wrote:
>[Discussion about view-mode switching, see konq_mainview around line 715]
>
>I agree with
>// Simon:
>// Well, IMHO: do not really remove the view but instead:
>// 1) only replace the view variable
>// 2) attach it to the opFrame (the old one will be detached automatically)
>// I hope you don't mind me doing this change. We can still revert it, ok?
>(and I removed the commented code from konq_mainview)
>
>but detach() or attach() have the same result : core dump
>(I tried adding detach() to my version of this code, core dump...)
>
>#0  0x4005eaf3 in OPPartIf::removeChild (this=0x8162238, child=0x8165508) at opPart.cc:244
[...]
Okok, it's just my buggy code ;-)
I will fix this ASAP.
Ah, no, wait, I think we should better go for KfmRun ASAP, or?
Anyone wants to do this? Otherwise I will. (but this might take a few days
because I got some exams waiting in front of the door ;)

>(to reproduce, enter http://www in the toolbar URL - you might need to do
>Ctrl+O Esc first, because of a focus bug.)

Yeah, this focus bug is something _really_ horrible. However I was not yet able
to find a solution to this.
Anyone with a decent understanding of X-focus stuff here?
I have a guess (but I have really no clue/knowlegde about this) :
Mmmmaybe this is related to the focus-handling in OPFrame (::focusInEvent) ??
<shout>
S O S
</shout>
:-)

>--------------
>
>However I'm not sure about :
>
>    if (sViewName == "KonquerorHTMLView")
>//      vView = Konqueror::View::_duplicate( new KonqHTMLView );
>      vView = Konqueror::View::_duplicate( m_vHTMLView );
>    else
>//      vView = Konqueror::View::_duplicate( new KonqKfmIconView );
>      vView = Konqueror::View::_duplicate( m_vKfmIconView );
>
>I thought it might save a lot of memory if MainView doesn't create a
>HTMLView, a IconView, and so on, at startup. konqueror_1 did that, but I
>don't think it's a good idea. We only display one at a time.
>
>Also because you can have TWO icon views in a mainview, can't you ?
>So you can't simply use two global vars m_v*View.

Okey, you're absolutely right, I fully agree!

>--------------
>
>//  EMIT_EVENT( m_vHTMLView, Konqueror::eventOpenURL, eventURL );
>  EMIT_EVENT( m_vKfmTreeView, Konqueror::eventOpenURL, eventURL );
>//  EMIT_EVENT( m_vKfmIconView, Konqueror::eventOpenURL, eventURL );
>Hum, probably better use KfmRun, as you said...
>But then KfmRun needs to know the view mode the user wants, to make the
>difference between icon view, tree view, ... we'll see.

Ah, have a look at the old KfmView and KfmRun -> it's easy :-)
We simply do a primitive filtering for mimetypes we actually implement
("inode/directory" and "text/html" ) .

And this brings to me another point in regard to a possible view plugin
interface (read: how to find out which apps in the registry do support
embedding either as Konqueror View or as plain Part) :
I thought of extending the .kdelnk files of every application which supports
this (in contrary to create yet another extra directory in the kde directory
tree for apps supporting embedding) . 
The rest should be quite self explaining, or? :)
What do you think?

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]