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

List:       kfm-devel
Subject:    Re: window.history - solutions (?)
From:       Tobias.Anton () t-online ! de (Tobias Anton)
Date:       2001-03-01 9:35:33
[Download RAW message or body]

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'd like to propose the following two solutions:
a) We simply define an ABC and provide a setHistoryObject(ABC *) function in 
BHE
b) We use the QList API and provide a setHistoryObject(QList */&) function in 
BHE

Now that i don't know Simon's opinion about Niko's 1. idea, i also don't know 
why it could possibly be a bad idea to do this too. It looks pretty 
straightforward to me.

I've got a patch for approach a) ready as a patch here, so there's not much 
work left.

Tobias

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