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

List:       kfm-devel
Subject:    Konq: History functionality and the Views
From:       Simon Hausmann <tronical () gmx ! net>
Date:       1999-06-14 11:11:42
[Download RAW message or body]

Hi,

I noticed a problem and I'm asking for Opinions.

We have three kind of sources where Views, displayed in the MainView, can
come from:
- the builtin views
- plugin views, available through kded
- "anonymous" views, coming from a remote process and being inserted via
  MainView::insertView

The first two ones aren't interesting for now, but the ones of the third
kind give me headaches ;) . The problem with them is: We don't really know
where they are from, but in fact we _have_ to know it, because otherwise
we can't use them with the current way we handle the history
functionality.
Got the problem?
When such a view is inserted, everything is fine. But when the view mode
is switched and this view gets destroyed we are lost. Well, it saved it's
state in the HistoryEntry, but that doesn't help us when it comes to
restoring the view, just because the user pressed the back button for
example.
For the first kinds of views it's no problem, because we saved their
viewname (or servicetype(s) -> to be changed soon) and we know that we can
re-create them with this information from either kded or just allocate
their implementation directly because they're builtin ones.
But with the third, as already mentioned, we're in real trouble.

Two solutions come to my mind:

1) We can base our way of creating views more on factories. For plugin
   views this is done anyway, but not for builtin ones, yet, because we
   simply didn't need it. But know we might need it, because we could say:
   When a view is inserted, we always want to know a factory which is able
   to create the same kind of view again and again. By adding a factory
   object as argument to MainView::insertView we'd have a general solution
   (and of course we'd need to create factories for the builtin views and
   use them) .
   Perhaps we could even simplify this a little bit and have only two
   kinds of factories:
    a) one of builtin views _and_ plugin views
    b) one of "anonymous" views ;)
   I said "perhaps", meaning it's just a random thought :-))

2) The other way would be in somehow easier, but I fear it would eat more
   memory.
   By simply not destroying the view but separating it completely
   (->removing it from the child list of it's parent;hide()'ing; etc.)
   and saving the reference in the internal history entry (->and making
   sure not to drop the KOM reference counter, in order to avoid a
   destruction) we could solve the problem. But that would eat memory,
   obviously.
   A way how to "partly" solve this would be to keep only the "anonymous"
   views alive and to continue destroying the other kinds (just like the
   current way) , plus saving extra information in the internal history
   entry about the kind of view, so that we can decide, upon restoring,
   whether we have a builtin view/plugin view or a still alive view
   object.

Another "killer" approach would perhaps be to disable the functionality of
allowing clients to insert such "anonymous" views, but IMHO this is in
conflict with goal of the open design of Konqueror.

What do you think? Suggestions? Finetunes to the above described ways?
Alternative solutions?

Ciao,
  Simon

--
Simon Hausmann       <hausmann@kde.org>
http://www.kde.org/  <tronical@gmx.net>

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