[kde-linux] State of Konqueror ?
kevin.krammer at gmx.at
Fri Jan 18 00:10:09 UTC 2008
On Friday 18 January 2008, Jonathan Wilson wrote:
> I think some of you said these things already but I'll say them again . . .
> On Thursday 17 January 2008 14:18:34 Anne Wilson wrote:
> > There have been many complaints that konqueror is too big, too
> > complicated, too configurable,
> Ridiculous. If you don't want to set any configurable options, then simply
> DON'T go browsing through the settings menu - use the defaults. If people
> can't find what they consider to be "basic" options because there's "too
> many" to browse through (I'll maybe agree with that), perhaps these "Basic"
> options could be left "out in the open" and the rest hidden under
> an "Advanced" button.
Most complaints I have heard of are not actually options or configurability
(even if those are the words used to describe the actual problem), but more a
difficulty to work with the "multiple personality" feature, a.k.a. profiles,
e.g. parts of the GUI (menus, toolbars) changing when "clicking the wrong
link/button", stuff like this.
> > For those of us that like its configurability, we get to keep
> > konqueror.
> Forks are good for who? Can't we give these users a program that's a shell
> with fewer options that is still really running the Konqeror engine ++ in
> the background? Otherwise, what third parties are ever going to develop
> plugins for /two/ KDE file managers?
It's not a fork. Actually the developers are doing exactly what you are
suggesting, sharing the actual functionality and just presenting it
Think about it as some kind of re-use like in Kontact, where the mail
component is basically KMail not running in its usual stand-alone shell but
in the integration shell.
> I'm probably way out of touch but I thought Apple was contributing
> improvements to KTHML or whatever back to Konqueror/KDE? Or is that way old
> news and Safari is based on something proprietary now?
Apple never directly contributed to KHTML as far as I know, In the beginning
they confirmed to the LGPL licence by basically having their version
accessible as a whole, thus putting the effort of figuring out the actual
differences to the KHTML developers.
I think at a later point this somewhat improved, i.e. they created a
collection of differences (patches), but still a lot of them in one go
without any comments.
They then began hosting WebKit as a kind of project they created, i.e. making
most of it (still continued using internal variation) read-only accessible
from outside in real-time.
Then they allowed write-access to those parts that WebKit uses to adopt to
platforms (sometimes referred to as backend), basically allowing platform
adapter providers (Nokia, Trolltech) to develop their code in a central
location, but they would still not allow access to the engine code.
I think around summer of last year (2007) they solved this as well, publishing
policies when a contributor would allowed to do what, including contributing
to the core and their developers have the same policies applied as well, i.e.
just being an Apple employee no longer guarantees instant read/write access
Since this change WebKit is pratically a new free software project on its own,
which is a really good thing and probably currently the best achievable
solution, but, again, not the same thing as actively contributing to KHTML,
more the opposite.
Kevin Krammer, KDE developer, xdg-utils developer
KDE user support, developer mentoring
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 189 bytes
Desc: This is a digitally signed message part.
More information about the kde-linux