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

List:       kfm-devel
Subject:    Re: window.history - solutions (?)
From:       Nikolas Zimmermann <wildfox () kde ! org>
Date:       2001-02-28 20:39:09
[Download RAW message or body]

On Wednesday 28 February 2001 21:26, David Faure wrote:
> On Wednesday 28 February 2001 19:54, Nikolas Zimmermann wrote:
> > Hi there,
> >
> > i've looked where the whole history stuff in konqi
> > is "saved". It's in the KonqView class....
> >
> > to do nice functions via JS like history.back
> > or forward...or even length i would need that list....
>
> Not necessarily the whole list.
>
> > now the question is how to acces that list
> > i got 2 ideas.
> >
> > 1. "mem eater" (?)
> > As we can access the KParts::BrowserExtension
> > from the ecma bindings (via part->browserExtension())
> > i thought we could add a QList<HistoryEntry> into that Extension
> > and everytime we visit a new site the KonqView
> > will "send" his new m_lstHistory to the extension...we will have
> > the same list in KonqView and the BrowserExtension so that
> > we could use it via JS....now Simon told me that it's bad to store
> > something in the extension...never mind .....let's see your opinion
>
> "Never mind" Simon's opinion ? Simon is a very wise man, you should
> listen to him more :)

hey i didn't mean that, i'd never ever say anything bad on Simon (;))
i meant, that he meant it's bad to .... ....but let's see on what we'll agree
:))))
Simon is very wise :) - old apache ;)

>
> > 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 ?
hmm
i'd say that's a good idea....i'll prepare a patch for that then

>
> 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 ?
>
> Haven't checked BrowserHostExtension for a while, so I may forget
> something important...

-- 
Nikolas Zimmermann
wildfox@kde.org

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