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

List:       kfm-devel
Subject:    Re: konqygui
From:       Simon Hausmann <tronical () gmx ! net>
Date:       1999-02-18 16:29:55
[Download RAW message or body]

On Thu, 18 Feb 1999, David Faure wrote:
[...snip...]
>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).

Of course it can!
But what I actually didn't like in regard to the html-example is that
a) the view as a part of it's shell-view is not directly accessible
b) and that's this view is (in regard to the interface) SEPARATED from the
let's-control-htmlview-remotely interface (although the visible view and the
class you'd like to "controll" are the SAME THING.)

Maybe I expressed it a bit too complicated.... Here's a perhaps better
description of what I think is not so nice about proposal two:

(taking the example of a html view in regard to proposal two)
The html view, which is ONE SINGLE THING (class) , has to be accessed through
TWO interfaces. If you want to access it's "properties" as a view you have to
"tell" the interface which embedds the view about it, which would be
KonqPartImpl.
But if you want to access the htmlview's html-related methods for example you'd
have to access it through it's own interface (and you'd get a reference to
such a interface by KonqPartImpl) .

>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".

s/persistent menus/part child mode/ :-))

If there'd be such a mode for parts we could not implement real persistent menus
by this, but we could avoid the rebuild of the *bars -> this way we can assign
the parent part (-> a KonqMainView) a KonqGui class/interface (I'm not quite
sure if I already explained all my thoughts about KonqGui, if not please let me
know and I'll try to do so) .

[...]
>[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".]

Yes, buttth: If you would embedd a KonqMainView into KoShell you'd still have a
Konqueror like the current one is :-)
(now "using" proposal ONE)

[...]
>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).

And imho the second proposal is a not so componentificated Konqueror, meaning
all the available interfaces do not really represent the internal structure of
Konqueror and the implemeting classes.
Want an example? -> <a href="goto_line_11">go here</a> :-)

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

:-) *agree*

>Now the question is
>* how to get Torben's opinion on the openparts problem

I already mailed him and cc'ed my mail here into kfm-devel.

[...]

David: Your summarize was ABSOLUTELY PERFECT!!!
I'm glad that I can't find _any_ missing statement, everything is included,
that's fantastic! Thanks!

(perhaps only Waldo's "html-inside-sticker" and
"konqueror-home-order-television-ads" statements, which were very funny!!!
:-))))

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