sane defaults

Anders Lund anders at
Fri Jan 14 15:09:37 GMT 2005

On Friday 14 January 2005 15:37, Allan Sandfeld Jensen wrote:
> On Friday 14 January 2005 12:06, Olivier Goffart wrote:
> > Le Vendredi 14 Janvier 2005 01:28, Anders Lund a écrit :
> > > On Friday 14 January 2005 01:11, Allan Sandfeld Jensen wrote:
> > > > We should remove the rellinks plugin entirely from CVS. It is not in
> > > > a release-worthy state and never has been (and never will probably).
> >
> > What's wrong with it ?
> > Most of bug has now be fixed.
> The real problem is the way it works, by just being installed it makes
> Konqueror slower even now that the O(n^2)  bug from KDE 3.3 was fixed.

It is using the DOM to access the DOM nodes (kinda how to do that). It does 
about nothing if there are no links in the document. If the plugin is not 
enabled I can't see how it can possibly make konqueror slow.

Of cause it would be faster if KHTML had built in support, nut hey, this is a 
plugin. It *needs* to query khtml for links, and parse those found. It does 
not make konqueror feel notacibly slower here. Most of the work it does would 
have to be done anyway.

> The problem with the toolbars is not only how it looks, but I also think
> that it should be integrated with the ordinary toolbar. For instance the
> current up button is sort-of relational, and when a relational link is
> available it should overload the current guesswork in up.

The whole deal with those links is that they are defined by the document. the 
related 'up' is no nessecary equal to '..'. So both 'up' buttons if present 
represent valid functions. I can't see why the documents definition of 'up' 
sould make the filsystem style '..' up less valid.

I'm not really a big fan of the static organisation of the toolbar, i'd prefer 
to see it promote whichever links there are, but that has some built in 
problems. The argument for the current toolbar was that the static 
organisation makes it easy to spot the present functionality, at least as far 
as the directly clickable actions is concerned.

> If we remove cut, copy and paste, we could use the area for a set of
> relational links. It should just be coordinated between KHTML and the
> imageviewers that also have prev/next buttons.

On the other hand, placing the documents relational navigation mixed with 
application actions is confusing and logically flawed.


jabber: anderslund at

More information about the kde-core-devel mailing list