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 differently. 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 to everything. 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. Cheers, Kevin -- Kevin Krammer, KDE developer, xdg-utils developer KDE user support, developer mentoring
Attachment:
signature.asc
Description: This is a digitally signed message part.
___________________________________________________ This message is from the kde-linux mailing list. Account management: https://mail.kde.org/mailman/listinfo/kde-linux. Archives: http://lists.kde.org/. More info: http://www.kde.org/faq.html.