the topic of this post doesn't refer to usability, really, so much as it does to "software that works". we're at the point where we need to start making kde4 usable on a day to day basis. that means fixing the bugs that most of us have to this point been working around and/or ignoring because there were bigger fish to fry.
yesterday someone started bitching in #kde4-devel how so many things weren't working as expected and how frustrating that was. they are right: it is frustrating. there are no desktop icons (they are coming), khtml is fubarred at the moment so launching konqi with the webbrowsing profile dies spectacularly, etc.. these are big issues, but most of the problems are actually pretty small there's an easy solution to them: fix it. example:
this morning my cat crashed konqueror with his tail. i'm not sure what key he hit exactly, but it brought konqi down. the fix was a two liner and didn't take 10 minutes to track down and set right. turns out it was due to a new wrinkle introduced by the model/view stuff.
there have been a huge number of changes to the code base over the last year and a half. this is going to result in various instabilities and annoyances. most of them are likely to be fairly minor. i'd like to encourage my fellow developers to take the time to fix those little annoyances as they appear.
it'll make kde4 a more welcome home to those who are less about the infrastructure and more about the applications. =)
Subscribe to:
Post Comments (Atom)
6 comments:
I thought KHTML was being progressed to WebKit or are the die hards (who I figure don't want to relinquish control) continuing development with the hope of merging the benefits of WebKit back in and then mainly trying to keep up with WebKit (which seems like unnecessary work for something that's GPL'd)
@Dave Taylor: the whole khtml / webkit vis-a-vis kde4 integration remains an organizational and technical work in progress.
there's still a number of things to work out at this point. perhaps a bit on the unfortunate side given how close we are to 4.0, but that's life in free software.
Very unfortunate given that KHTML was to provide uniform rendering throughout and now there is this battle but I guess the best solution (politically rather than technically) would be to provide an abstraction (more work for politics sake) that would allow one to choose their favourite HTML renderer and then let the meritocracy decide what is better (I have a fair idea but in the interests of civility I shall avoid that).
I wonder if there is going to be similar political problems between window managers. The well supported yet buggy Beryl/Compiz (incidentally with no attractive effects but that's subjective) and the OpenGL extended Kwin.
@Dave Tayler: that abstraction actually already exists, so no big deal there.
as for the window managers, it'll be interesting to see how it pans out but, to be honest compiz/beryl are probably the most overrated pieces of software in the free software stack today. they are neat, they are cool and composition techniques are bringing a few nice features but people are way too obsessed over these window managers.
@aseigo: maybe they're overrated, but also maybe that means that userbase is expecting something new in the desktop world...
Anyway, cheering that kwin_composite now has the window fire effect (which is duplicating a beryl feature, for example) seems to people like duplicating the work... And if the same is going to be done for every beryl plugin... Is it really worth it?
(yeah, I know you're not into kwin_composite developing, sorry for the OT).
Thanks for the hard work!
@rafa: yes, window managers have been duplication of effort ever since the first fork of twm =) that's just a reality of them: there's a certain amount of stuff they all need to do, and over time the definition of that grows. that means that duplication of effort grows over time.
it would be great if people could get together and define common plugin intefaces, but that's a far harder topic than it sounds on the surface of it when it comes to window managers.
as for is it worth it to duplicate features beryl has in kwin, well... that's been true of every kwin feature that you find in other window managers.
it's worth it for two reasons:
a) first class integration with kde
b) kwin is actually a good window manager first and foremost, as in it manages windows properly and is very stable
that latter is a highly non-trivial thing to achieve (ask the writers of other window managers who have achieved the same level of maturity in their work) and trading that for eye candy would be an even bigger loss of time and effort.
again, i'm really not sure why the projects that were there first (in this case kwin) are seen as the duplications of effort.
the compiz/beryl projects are the late comers. if we, or rather they, really wanted to avoid dupe of effort they'd adopt existing window managers. of course, their goal is to do wild, crazy and neat-o things without the constraints imposed by existing, stable window managers (which have commitments to their own code and user bases).
so ... it is.
things don't have to be perfectly efficient at the local level for them to be efficient at the global level. this is a case where we probably just need to be satisfied with a certain amount of innefficiency because it's as good as it can get.
Post a Comment