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

List:       kfm-devel
Subject:    Re: window.history - solutions (?)
From:       Simon Hausmann <sh () caldera ! de>
Date:       2001-03-01 16:13:23
[Download RAW message or body]

On Fri, Mar 02, 2001 at 11:34:57AM +0100, Tobias Anton wrote:
> On Wednesday 28 February 2001 21:43, Simon Hausmann wrote:
> > On Wed, Feb 28, 2001 at 08:26:23PM +0000, David Faure wrote:
> > > > 2. "ugly hack" (!)
> > > > Normally only the application "talks" with the embedded part.
> > > > With that solution we would just place an empty QList<HistoryEntry>
> > > > into the extension and if someone triggers a history.back
> > > > the extension emits a signal getHistoryList()... the khtmlpart
> > > > receives the signal and emit the same signal again
> > > > now konqueror has the signal and gets the historylist from KonqView
> > > > and calls gotHistoryList(QList<HistoryEntry>) in khtmlpart
> > > > ...khtmlpart calls gotHistoryList in the extension.....the extension
> > > > emits a signal so that the ecma binding "knows" that the QList
> > > > in the extension isn't empty anymore and accesses everything it needs.
> > > >
> > > >
> > > > I prefer the first solution..
> > > > Ideas?
> > >
> > > Why not add a signal for back, one for forward, and a setLength() /
> > > length() in BrowserHostExtension ?
> > > Isn't that what we agreed on previously ?
> > >
> > > If JS doesn't need the full list of all the URLs (which AFAIK would be
> > > some security issue), then why implement a solution around the whole list
> > > ? I'd rather see JS asking konqueror what it exactly needs, no ?
> >
> > Yes, that would be a nice solution. One problem though is how to access to
> > BHE from kjs? (I love abbreviations :)
> >
> > Like for example Konq itself does not implement the BHE :-}
> >
> > Back and foward we could indeed easily implement using signals (althoug
> > perhaps a generic goHistory( int ) (todo: better name) signal would do
> > aswell) . But querying the length of the history from a part is giving me
> > headaches :)
> >
> > A if-everything-fails 'solution' might be to do it the same way as we did
> > for window.open and the synchronious createNewWindow stuff: Add a signal
> > queryHistoryLength( int &length ) .
> Uh. Now this is giving me headaches.
> I don't like the signal thing here, because signals are not intended to query 
> information. From a design point of view, the behaviour is undefined if 
> multiple objects connect to that signal and reference parameters are ugly 
> anyway.

I agree with you from a (pragmatic) design point of view. Also please note
that I said 'if-everything-fails 'solution'' (note that I quoted 'solution')) .

The point about approach 1) is that we did not (up to now) store essential
information within the BE, as it's purely meant as interface for communication.
(the only real information we store in there is state information of actions,
which then again is a component associated information, unlike the navigation
history, which is independent from components as components change with the
URLs you visit)

The problem with storing information within the BE interface is that it can
easily get messy when you're having multiple BE instances (think of framesets)
and trying to synchronize information within those. That's why I do not like
the idea of storing a history list directly within the BE, as it's not really
clear _which_ BE implementation in the tree is meant to hold it and who's going
to take care of spreading around the information. (like for example you can't
let the BE spread the information down to 'child' BE's because the BE it is
a full implementation detail how the part stores its child components (the
ones holding possibly other BE implementations))

In addition I agree with David's point of rather implementing a solution for
controlling the history rather than implementing a solution around the
information/content of the history.

Bye,
 Simon

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