With all the excitement surrounding KDE 4 development at the moment people are starting to ask why they have not seen any updates on what KDE 4 will look like. KDE 4 - Understanding the Buzz answers these increasingly common questions by explaining the current status of KDE 4 development and why the exciting work so far is only visible to developers. "Before any new features can be added to KDE and projects like Plasma can get underway, the porting of KDE to Qt 4 has to be completed."
Free speech is a mutual understanding where everyone is allowed their say without being shouted down by people making personal attacks.
And it goes without saying that what I really don't undersand is people like you (AC). Perhaps it is wrong to allow people to post that don't provide an e-mail address.
Too bad that I was shouted down and, therefore didn't have the opportunity to discuss what I thought was an important issue. Now, this has gotten way off topic and way out of hand so I will not discuss it any further. I believe that I have already apologized to anyone that I inadvertently offended so there is really nothing more to say unless someone wants to actually discuss the issue raised in manyoso's posting.
"And I'm tired of some stupid incompetent cantankerous old wanker who does not understand the free software culture, does not understand the open source culture, does not understand what drives KDE developers"
No wonder you fucking losers are laughed at when you start spewing drivel like "free software culture", "does not understand the open source culture". You fucking retards don't speak for anybody except for your demented selfs. Do yourself a favor and get professional help.
I'ld like to say "Thank you" to Jhall for her great articles on kde. A part of the buzz that recently (and finally) surrounds KDE is due to her. The KDE PR machinery seems to finally have rumbled to a start.
A tour like this:
I am sure I saw an even cooler toor for GNOME 2.10 but I cannot find it in google. Physos was working on something for 3.4 I think but I never that that either...
Ok, that is a pretty easy URL-scheme :-) But I really didn't find them in google ;-)
this is why Jess is doing "this month in svn". she's spreading out the work of putting together such a tour for 3.5 by doing a bit each month rather than trying to cram for it the week before the release.
I found that really cool project, it would be great if KDE4 would integrate it, it´s Qt based and GPL.
Well... I dontt like it, I think programs could have a "kool" interface while still using KDE/Qt as base (take a look at k3b to see what I mean).
But.. for some users and companies.. I'm sure this is kind of a good thing, so yes... (arght, my soul is in pain)... yes... it is a good idea to support skinds.
> I don't like it
Don't you think it can be good for multimedia players like noatun for instance?
You don't even have to change 1 single line of code: you just select the right QStyle plugin, you create a .ini file and .png files et voila.
You can re-organize entirely your layouts, change widgets position and size, map all widgets with .png files just by editing a .ini file.
As I said before, I don't like it, BUT, I think it's a great idea.
So, now you're probally think: what the hell is he saying, this guy is nuts! Well... I don't like this kind of bloated interface, I prefer more simple, take amarok and k3b as an example, interface that dosen't scape very much from the overall look of programs, but that is for my taste! And I know most people like those bloated interface, and it would be very good for us to keep people satisfacted... so, I vote for this even that I don't want to use it ;)
Kind of, well, I know 3 or 4 people that would love it, so go ahead and make them happy as I am already happy.
Sorry if I was confuse.
YOU ARE FIRED
Pretty cool, in my opinion!
that sure is one way to boost the system requirements...
also there's a lot happening on kdom. As far as I understood kdom is a new layer that will serve as a base for khtml2, ksvg, mathml?, .. Apple already started adopting it for Webcore!
And once kdom and khtml2 are a bit more finished I suppose lots of merges will happen from Webcore back to kde now that webcore cvs history is available.
Also there is being worked on a abstraction layer for multimedia playback, it is called kdemm. Once it's finished you'll be able to choose between different backends (like gstreamer for instance)
Let me get this strait. The idea of the multimedia layer is that we get a layer on top of the existing backends? That would mean that an application is talking to kdemm, which is talking to Arts, which is talking to OSS, which is talking to the driver, which is talking to the hardware. Right? Damn... that's 4 layers to cross before the sound goes from the application to the actual hardware. Wouldn't it be better to sometimes just make a *choice* for a framework? Maybe, may be not
Anyway, I am completely ignorant about how this stuff actually works, so I probably should just shut up.
> Anyway, I am completely ignorant about how this stuff actually works, so I probably should just shut up.
Chances are, aRts will be gone for KDE4 and a completely new multimedia framework will be put in place.
> The idea of the multimedia layer is that we get a layer on top of the existing backends?
The idea isn't to have another layer in order to have another layer but to avoid another case of "We're stuck with an unmaintained or no-longer-optimal multimedia framework for the whole release cycle for binary compatibility reasons, i.e. for years to come.".
But I guess the kdemm concept will have to prove its viability anyway before it's released.
The idea of KDEMM is also to let the user have a choice. I for one am using xine as a backend for amarok, the only sound-app I am using. Systemsound is disabled and so on. But a friend of mine is doing streaming across networks or something like that and will need MAS for that (I hope MAS was the network-thing... not 100% sure). Well, why should I be forced to use a heavyweight soundserver with network-stuff and so on?
Furthermore KDEMM will make it easy for the application developer: The application will always call something like play->( soundfile ), no matter which backend the user is using...
In a perfect world situation KDE will ask the user once if he needs networkstuff or not and then choose the backend for him. Joe User doesn't know what gstreamer or xine or ... is so that layer should be hidden from him.
Last not least you never know what happens with gstreamer in 1 year from now. They broke binary compatibility ever 6 to 8 month in the past but KDE4 will need BC for about 3 to 5 years. Even if the gstreamer folks would release version 1.0 tomorrow, who would guarantee BC for 4 years? No one. With KDEMM you can work around this problem as the KDE-apps would use and link against KDEMM and not directly against gstreamer. Of course the very same is true for MAS, xine and so on.
The final point is that it might be that the day after the release of KDE 4.0 a super-cool light-weight all purpose soundsystem pops up and we all want to use it... Without KDEMM you couldn't use it but with it it is just another backend. Sure, you would have to wait until KDE provides the "bindings" for it, but that will happen pretty soon.
Wrapping one api on top of another has serious disadvantages too. Either the wrapping api completely exposes the underlying api, but perhaps with different semantics, and then it will be hard to port it to other underlying apis. Or it can expose a reasonable subset. In this case you will not get full access to functionality in the underlying API.
When the underlying API is stable, well thought out, and offers advanced features, my belief is that the best you can do is expose it and let application developers take advantage of it directly. Wrapping for portability comes with a price.
The "reasonable subset" is the idea and the way to go. For more special stuff than eg playing audio (notification, music) the single applications have to support the backend directly themselves.
well, multimedia is an interesting topic because 98% of applications only need a specific and very limited subset of functionality: play, pause, stop, record, etc... what is important to these applications is that it is easy to do this programmatically, that it's widely portable and that latency is low enough that the user doesn't notice the time between action and reaction.
these needs are very different than one sees in an actual media creation app, of course, where you want perfect latency handling ("no perceptible delay" isn't good enough anymore) and access to a wide and complex array of media functionality.
unfortunately for regular app developers, the best media systems are designed by people very familiar with media and so they tend to end up being complex beasts to deal with unless you too are a media developer.
by providing a thin layer we can get the ease of use necessary and the portability between media systems. by keeping the layer thin, it's also possible to keep it performant. and all media systems support the basics needed here (play, pause, etc)
by recommending a given media engine, we can also give something for serious content creation app developers to target.
so i think the path the kdemm developers are taking makes a TON of sense. given the above explanation, would you agree?
 64% of statistics are invented on the spot by winged mammals
> by providing a thin layer we can get the ease of use necessary and the portability between media systems. by keeping the layer thin, it's also possible to keep it performant. and all media systems support the basics needed here (play, pause, etc)
And the multimedia engine layer in amaroK proves that this is doable.
> [..]"We're stuck with an unmaintained or no-longer-optimal multimedia framework"[..]
Not only that. It's also this other mm framework offers something (for example multimedia over network) that _I_ need but I can't use it because KDE choosed something else.
> But I guess the kdemm concept will have to prove its viability anyway before it's released
A proper and sensible abstraction for KDEMM is the right way to go. Would you rather do something like play->(soundfile), or link directly and heavily into an MM framework like GStreamer? At the moment, using GStreamer means strapping yourself to it, using the C API and creating a lot of god-awful, unmaintainable code. You would end up in a worse situation than there is with arts at the moment.
There are certainly disadvantages to using wrappers and layers, but a rule about layers is that every one should add value. This one certainly does.
What about tenor? The pervasive search stuff sounds like it should be really cool but I haven't heard about it for some time - any details forthcoming, code, etc (yet)?
> What about tenor?
I'm also very interested. Especially since aseigo doesn't seem to work on it anymore because of Plasma.
I would also like to know if you would be willing to work with the kat (http://kat.sf.net) developers. They seem to be pretty far with their stuff and maybe it's a good basis for Tenor.
There's been a lot of discussion on the klink mailing list in the past couple days. It includes an answer to your question about kat. The mailing list seems to be mirrored here:
Wow, didn't even know that this list existed. Thanks alot for the link!!
just wondering what on earth this "plasma" is.
I read there site and to me it reads something like:
but anyone out there any idea what plasma "is"?
is it a totally new gui (like the windows vista hardware accelerated UI), or a team effort to add functions and optimize the current UI, or is it some sort of usability project with an addiction for eye candy? the "extender" function surely seems to hint in that direction. http://plasma.bddf.ca/cms/1069
I'd love to say that it is great and promising...
but I just have some trouble giving it a place somewhere in my mind. :P
It's a project that tries to unify the desktop and panels into one coherent unit.
For instance, superkaramba themes appear to sit on the desktop, but they're really just windows below everything else. Kdesktop itself doesn't know anything about the themes, so if I try to do something like, say, mark superkaramba themes as desktop windows (so that windows don't snap to them), the desktop (with icons turned on) will paint over superkaramba.
Similarly, stuff on the panel is largely separate from the desktop. Plasma aims to have them more integrated. An extender may pop up, and you may be able to drag it off onto the desktop. Kicker applets and karamba-like themes would be one-and-the-same. Stuff like that.
Basically, today KDE has a whole bunch of things that seem like they're all related (panel, desktop, superkaramba), but they're actually all separate applications that don't integrate as well as they could. Plasma is an effort to bring them together as they should be, in addition to taking them in new and interesting directions, for both usability and eye candy.
At least, that's my take. I do agree that aseigo tends to include a lot of hype when he talks, no offense intended. I think he talks to regular people too much. :)
that's a pretty good summary of the framework that will be plasma indeed. the only thing missing from it is what we aim to build on top of it, but that's stuff that can wait for now ... we're concentrating on getting to that framework in the first place at the moment, namely bringing all those separate pieces you mentioned together and making the look beautiful and work coherently.
> I think he talks to regular people too much
my therapist keeps telling me this, too. ;)
yes, i've been busy with plasma and a few other kde related tasks. but tenor hasn't been shelved by any means. we've recently been working on bringing kat and its team together with scott, ervin, myself, etc... it seems to be time again for tenor =)
oddly, i just blogged about it this morning, and then i come here and see this thread ... woah =)
As I understand, QT4 should be able to display TT fonts as well as Windows, however looking at the screenshots the fonts still look as ugly as ever.
Anyone have any further info?
Just because you saw a screenshot with antialiasing turned off doesn't mean Qt/KDE can't render anti-aliased fonts.
I use Windows TTF fonts under KDE 3.4 and they are very well rendered, crisp and smoothly anti-aliased.
Well looking at the screenshot in question, it appears that anti-aliasing is turned on, but that the kerning didn't look right.
I too use KDE 3.4 with anti-aliasing, and I still feel that the fonts don't look as nice as they do in Windows....
Do you understand about the Apple patent issue?
You need to build FreeType2 from source to have the fonts look as good as Windows. Perhaps we could talk to Apple about giving us a license.
I don't know about kerning. We were told that we would have correct font metrics for printing with Qt-4 but now I can't find anything about it. I have to presume that these font metrics issues are related. That without correct font metrics that we can't have correct kerning.
"as well as" is a funny thing when talking about antialiasing. There's no "correct" way to do it -- you have to make several decisions on how you want to antialias.
I believe what you want is "antialiased the same as", which is plausible. I personally don't like the antialiasing in OSX, so I hope it's not like that. I've never sat in front of an XP or Win2k machine, so I can't comment on their antialiasing. I like KDE/Qt/X's antialiasing.
> as well as" is a funny thing when talking about antialiasing.
Who is talking about anti-aliasing? Original poster talked about Font Kerning.
Take a look at the strings "unsermake" or "Desktop" in this screenshot:
IMHO the letter "s" is too far to the right. "Desktop" almost looks like
Heh. You're right... I failed to read the original comment closely enough. Sorry about that; I'm on a final coding rush for a project here, and I'm skimming news... I should have paid more attention before replying.
Kerning does look off in the screenshot.
Guys, you did also notice the strange, misrendered blocks of yellow as well yes? The fact that desktop wallpaper failed to render? This is completely pre alpha software that doesn't even build without a lot of effort. Judging what KDE4 fonts will be from this is just silly =)
> This is completely pre alpha software that doesn't even build without a lot of effort. Judging what KDE4 fonts will be from this is just silly =)
Of course. I know we are discussing pre-alpha code but AFAIK (and please correct me if I'm wrong) KDE isn't much involved in the font layout or rendering.
So I would expect to see the improvements of Qt4 in font rendering. Even in pre-alpha KDE screenshots.
>the strange, misrendered blocks of yellow
Oh! I just thought you used some strange, non standard color scheme:-)
Heh nope, that's what KDE default (plastik) looks like at the moment. Strange isn't it!
The important question is to why it looks so. Is it because the software used to display the font is not good enough, or is it simply the font who don't have the desired quality. Getting the hinting right in fonts are hard work, and one of the reasons good fonts are really expensive. The Bitstream fonts are not too bad, but the hinting are not all that great and sometimes they kind of break down like in the Screenshot. Compared to some commercial alternatives they still have some potential for improvement.
> Is it because the software used to display the font is not good enough, or is it simply the font who don't have the desired quality.
It would be great if the article writer would create a screenshot of the same directory in KDE 3.5. This could give us at least a hint if it is a problem in Qt4 or if Qt3 shows the same behavior.
I assume this article is not part of the "This month in SVN" series. Am I right?
Nope, 'This Month in SVN' is arriving for August before I go on holiday next week =). This short article is to explain a few things about Qt4 as a percursor to starting to monitor KDE4 development in the SVN series in months to come.