Rekonq default

Lubos Lunak l.lunak at suse.cz
Mon Feb 22 09:05:32 GMT 2010


Dne Ne 21. Ășnora 2010 13:27:35 Eike Hein napsal(a):
> On 02/21/2010 12:23 PM, Ingo Klöcker wrote:
> > I fully agree with Aaron on this. I don't want a set of chef's knifes
> > (each for its special purpose). I need a swiss army knife because of my
> > way of working.
> 
> That's nice and all, but that Swiss army knife hasn't really
> attracted a lot of developer attention lately. If Konqueror
> is the advanced file manager in the SC, why isn't it a true
> superset of Dolphin? It lacks things like Places integration
> or Nepomuk integration. Meanwhile Dolphin has caught up on
> features that used to be unique to Konqueror at first, like
> support for tabs.
> 
> What if keeping Konqueror unchanged is causing it to bitrot
> and die slowly? What if troops could be rallyed - and the
> value that is there retained, and the brand retained - by
> announcing a shift in focus to make it a web browser first
> and foremost?

 What if most people are much more comfortable reinventing their own wheel 
again instead of making the effort of understanding an existing codebase? It 
is so much more fun to start something of your own from scratch, write it 
exactly the way you want and solve all the problems you're bound to run into 
yourself instead of figuring out how somebody has already done all of that for 
you. The history is full of cases like this and you don't even need to leave 
the browsers area for examples. If Rekonq lives long enough to reach that 
point, one day people will rather start something from scratch again instead 
of helping Rekonq.

 Nobody is stopping anybody else from making Konqueror a better browser, 
except for people who couldn't be bothered to actually make that happen. 
Trying to throw away half of Konqueror to make it Rekonq #2 is not going to 
help anything.


 Lubos, who's really happy he didn't yield to all the suggestions to replace 
KWin with this flashy immature Compiz failure, coming mostly from people who 
never have or will contribute to either of these anyway.

-- 
 Lubos Lunak
 openSUSE Boosters team, KDE developer
 l.lunak at suse.cz , l.lunak at kde.org




More information about the kde-core-devel mailing list