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

Bye,
 Simon