Ars Technica is reporting on the tagging of KDE 4.0.0 in an article titled, "KDE 4.0.0 tagged in preparation for release." In this report, Ars Technica briefly explains the importance of the tagging process as well as what one can expect with the upcoming KDE 4.0.0 release. "Although the 4.0 release has many rough edges, it also showcases a tremendous number of innovative new features and technologies." 4.0 is scheduled for release at the end of next week.
Dot Categories:
Comments
I feel Ars (and Ryan Paul) is doing a great job writing about KDE, in an objective and decent manner, and I must say I really look forward to meeting (some of) them at the Release Event...
Of course, I should add to that they are also doing a great job at spreading tech info in general - I always enjoy their articles... Many of them are a must-read for tech enthusiasts.
Well. Uhm. I'm still a bit confused about what to think now of what is soon to be released as KDE 4.0. Are they really serious about those black boxes everywhere? The taskbar for instance looks really ugly in my opinion. Will there be no way to change its color back to sth. more acceptable like a dark blue? Likewise what about the other applets on the desktop like the clock. Will they all be in black? Ugh. In this case I'd rather stick with KDE 3.5 for the time being. Don't take this wrong please. I know there's lots of new technology underneath the surface and this is just the beginning, but from an end-users' point-of-view KDE 4.0 means right now: Less features, less customizability. 3-D functions, effects etc also work relatively sluggish right now. For instance I would expect that I can seamlessly resize and rotate the anolog clock applet without any jumps. Not at all even though I own a fairly decent PC. Perhaps this all works out but right now I wouldnt recommend KDE 4.0 to any end-user.
The desktop is themable, but you'll need also more than one theme to be able to change it.
And sure, Plasma at this point is less customisable than KDE 3.5's kdesktop. It's completely new and will gain more features over time.
As to the speed of resizing applets, that's not a big deal right now, as it's fast enough -- it doesn't need to be completely smooth to make the desktop workable, it just has to work. You don't resize applets all the time.
I'm excited that Plasma will make it easier in the future to customize the desktop even further. However, because it less customizable today, I'm sticking with 3.5 today, and I imagine many will. That isn't a knock on the development of KDE 4, just a reflection of the current state.
yeah, i fully expect some people will do this. you can, of course, still run other kde4 apps in your 3.5 so you don't have to give up everything. kde is more than a desktop environment and things are welded together, after all =)
this is probably a trivial question, but :
i expect running kde4 apps on a kde3 desktop to increase memory usage, right (for kde4 libs not present before) ?
if so, what would be an approximate estimate, how much additional ram would require first launched kde4 application on a kde3 desktop compared to kde4 desktop ?
(note that i explicitly noted first app ;) )
well, I can't give a precise approximation, but it won't be very much. I'd say 20 mb, 30 mb... something like that. Maybe even less.
I'm using kde4 applications with kde 3.5 on a 1.5 ghz 256 mb ram laptop and don't notice any slow down of my computer experience because of that.
If I understood it correctly then the present taskbar won't be as it is now in RC2 on release. Aaron at one point said that it's just provisional and that much time wasn't invested in the present taskbar. He said that that would change by release.
If you are expecting the functionality of KDE 3.5x then I would advise you to have it install alongside 4.0. I personally haven't decided to make a total shift until all my favourite apps have been ported to 4.0 and working at least as good as they are on KDE 3.5x but I will certainly be using KDE 4.0 on a daily basis.
Well, for starters this is will be the first major KDE release that I have not compiled from source. Suse has spoilt me (-: I love all that black. I wish I could have more. The only two things I miss now are a weather applet/plasmoid and the applications' real name on the KDE 3 style menu. I hate the generic naming of apps. I spent a lot of time learning what the different applications were to now have to switch to generic names like 'document viewer' and 'image viewer'. Call them by their given names - Okular! Gwenview! Be proud! You deserve it. Suffice to I now use KDE4 exclusively on Suse. It is just a matter of time and space till I uninstall KDE3. Thanks KDE devs! /rant
Why should a beginner know what Okular or Gwenview is if there is no description in the menu?
One word: explore!
Why would a beginner open those apps?
Surely it would just, for example, click on a PDF file in their file manager and, thanks to sensible default actions, Okular would magically appear?
it :-)
beginners always open apps to see what they are and learn. Seems to me the new approach is to dumb the system down.
Just imagine a beginner looking for Firefox. Why would anyone click on something like "Webbrowser" when they're looking for Firefox? ;) After all, who would expect just generic names? Nobody who has not used KDE before.
Even beginners expect to find certain programs and look for them by name.
IMO default should be description and app name. For example: Firefox (Webbrowser) or Amarok (Music Player). Of course option should exist to change it to show only app name.
I second that
I second that too!
I can't think of a better way to introduce new users, which is one of the most important things KDE has to do to grow further.
http://bugs.kde.org/show_bug.cgi?id=155362
Even more feedback is welcome :)
"description and app name"
Goes without saying, why should they do it any other way?
Usability? I spit on "usability"!
"usability" or "decide how others should work" was clearly not the reason for the decision to go with the generic aka describing name. It was more the question what may work well and if users will accept it. There where multiple points I/we did look at;
1) What needs to be really configurable and what doesn't. Goal here is/was to don't provide a checkbox for every single combination of solutions by picking a default and look if that's enough. Related to the name vs. description vs. description (name) vs. name (description) case; seems there is just no easy solution for this :-/
2) The traditional KDE3 style menu does even contain already a hack to e.g. display "OpenOffice.org Presentation" (the name) rather then "Presentation" (the description). One of the problems here was, that the generic name is used different between e.g. KDE and Gnome. While we define only the application name, so e.g. "kspread" as name and "Spreadsheet" as description, others prefer do use the generic name as appname+description field, e.g. "Gnumeric Spreadsheet" as generic name and "Spreadsheet" as description. That makes it rather difficult to just choose e.g. "description (name)" without looking somehow broken :-/
So, all in all: something that can be made better with an idea how to make it better :)
Eh, please, this is KDE not gnome.
You are obviously entangled in some heated discussion behind the scenes
which I don't want to know about.
Description;name or name;description is the only variations that makes sense.
> You are obviously entangled in some heated discussion behind the scenes which I don't want to know about.
Oh, you should know about them cause one of the goals of an open project is also to be transparent on such things what I tried to achieve by explaining the way that was leading to the result.
But beside transparency participation is another great thing an open project is able to provide. E.g. with your reply you already did participate since that's feedback and without such kind of feedback it would be rather difficult to know what ppl expect and how things should be solved.
> Description;name or name;description is the only variations that makes sense.
and that's now a decision you made behind the scenes cause there may ppl who may not agree there. Guess that's the "problem" about beeing human with an own idea how things should be. What helps most here is btw earlier participation and talks.
In the menu-case such kind of feedback was just missing and that's why it is how it is now. But since we saw within that thread already very good feedback, it's now easier to take them into account.
KDE 4 Kickoff does list app names also.
There is, in fact, a weather plasmoid. The data engine is installed by default, and the widget part is at http://websvn.kde.org/trunk/playground/base/plasma/applets/weather/ (you may need to run cmake in the playground/base/plasma directory for the build to work).
Thanks, I was hoping Suse would spoil me rotten and have a rpm for me. I might head back to compiling soon tho.
SUSE has a playground-base.rpm actually.
There is a playground package and it includes the weather applet.
Yeah, I couldn't get the weather plasmoid in time for extragear. It's in the playground for the time being.
> I love all that black. I wish I could have more.
hint: POWER button. Hit it.
the jumps are due to the compositing. this happens with compiz, too. it bugs the HECK out of me as well. i'm not sure what the solution will end up being, but apparently composition managers do not deal well with canvasy apps like plasma.
when i run a non-compositing window manager things are silky smooth.
blarg.
you have no idea (or.. maybe you do =) how frustrating it is after compiz and what not having been out there for the last few years how much composite, argb, etc support in x.org and its drivers just flat out *sucks*.
it's The Way for the future (non-composited displays just won't be around in years to come, i'm sure of it; there are too many advantages) so we shouldn't deviate .... but i wish x.org was a bit more ... robust in the area.
nvidia's new driver they released at the end of december works properly with argb, though! hooray for the small wins =) and that's exactly how it's like to go; a lot of my near future will consist of trying to find ways to stack up more and more of these little wins by exposing the weaknesses and working with those responsible for those pieces of software to address the issues. not exactly my idea of "fun", but .. yeah. needs to get done.
Just as KDE apps were needed to help insure that the KDElibs are really "ready," so too I guess KDE is going to help make x.org "ready." While it surely will be a challenging/annoying road, we'll be grateful in the end!
"it's The Way for the future (non-composited displays just won't be around in years to come, i'm sure of it; there are too many advantages) so we shouldn't deviate"
But doesn't composting slow things down and take up a lot of memory? To me those are huge disadvantages. I sure hope it will be possible to turn it off or better yet put it in a separate package that can be uninstalled if we don't want it; that way there wont be code sitting in memory that isn't used for anything. I'm sure there are a lot of people out there that don't have the latest computers (like my wife) and won't use KDE4 if it makes their computer run much slower.
Of course you can turn it off.
well, compositing does those things now, but theoretically, it should actually speed up things. "Just" needs a proper X.org and driver architecture, which we simply don't have right now...
And we never will, unless KDE and/or Trolltech takes over it.
The division of Linux, X and KDE is the way that MS can "conquer by division".
Now that KDE 4.0 is here I can ask why you are removing features form it? I know that plasma (is there an option to remove desktop toolbox from the top right corner...) and kwin effects (...and put present windows trigger there?) are not complete and ready yet, but what about other stuff which is present in KDE3?
For example, in file dialog there are no more owner, group and permissions columns or "folder first", "separate folders" and "case sensitive" options, WHY?
Apps are not exceptions. Look at gwenview, it's all nice, but it has only 30% features of the older version which I use currently.
...
Regards
Because KDE4 and KDE3 are different, not progressions of the same software. To run a KDE3 app, you need the KDE3 libraries and they run fine. That applies if you're running them under KDE3, Gnome or KDE4. Or anything else other than KDE3. If you like KDE3, stay with it: as a distinct environment with many users, it isn't going anywhere. That said, quite a bit of developers will move on to KDE4.
This is open source, and software packages are maintained by their level of use. Old Linux kernels are actively patched by their developer and userbase. Yes, the majority of developers and users tend to run the lastest thing, but KDE3 is not going to go away. If you prefer it, stick with it... many other people -- both users and maintenance developers -- will as well. It's okay. This is not a commercial venture where last year's model suddenly becomes unavailable. You (and some others) labor under a misconception that because KDE4 exists, KDE3 is going to go away.
You aren't the only one: aseigo even addressed the same thing in his blog recently ( http://aseigo.blogspot.com/2008/01/talking-bluntly.html ). Open source just works differently than the cycle you seem to expect and that exists in the commercial world.
Remember that you are using a release candidate and not a final version. Wait until KDE 4.0 is launched then you can complain. Concerning plasma, it's said many times that plasma is still under heavy development and that KDE 4.0 is only the first of a series. Still I am sure that more polisching will be done before the release.
> Wait until KDE 4.0 is launched then you can complain.
well, isn't that a bit late if he wants to change something in KDE 4.0? :-)
Since it has been tagged, it is precisely too late.
There will be zero changes to KDE 4.0 at this point, though I'm sure there will be plenty of changes to KDE 4.x
Haha I love that. Someone who complains about something in a beta is often told to wait for the final release. If he does so though, it's too late to do anything about it. Brilliant!
>I can ask why you are removing features form it?
>Apps are not exceptions. Look at gwenview
In most cases the answer is simple, the features are not ported yet. Some features may even requre a revirite, depending on the changes done to the application. Its simply a time ting.
As for applications, look at Okular. It has more features than its KDE3 predecessor, KPdf. The same is true for several other applications too, so there are lot of exceptions.
Both gwennview and Konsole have been rewritten, that's why features are missing. their authors know and want to add those back, but that'll just take a while.
each of the examples you give are all for the same reason: they are new bits of code. the file dialog views are new (based on the m/v stuff in qt4, shared with konq & dolphin to boot); this new view will certainly increase in feature capacity over time.
gwenview was also very much a rewrite. the kde3 ui was tossed out to take a new run at how to present the same kinds of functionality but with a much nicer approach.
the down side to doing this is that you lose some features with the old code.
you'll find that apps/components that didn't need to do this usually have *more* features than they did in kde3. okular is a good example of that (it was kpdf; renamed because it's more than pdf's now). then there are the completely new apps, like marble.
so we're not removing features at all. a lot of features have actually been added, and where there are feature regressions due to rewritten or refactored code those will catch up (and likely surpass) their kde3 counterparts with time.
it would have been awesome if we could have magically kept every feature of every app and component, but these were prices we paid for being able to go further in the future.
oh, as for talking about kwin effects not being there yet, those are also brand new in kde. see, more features! ;)
So. I just did a LOT of reading. I read your posts, your blog, etc etc. It all now becomes finally(!) much clearer to me how to make sense of this all. Thanks for patiently explaining all this to me and all the KDE end-users. Not very common really in open source software to get such detailed answers.
The conclusions I've drawn for KDE end-users right now:
1) If you happily use KDE 3.5 right now as an end-user for day-to-day work and wouldnt like to miss out on features and customizability, stay right now with KDE 3.5. It isnt even a "bad" thing to do, but expected by the developers and perfectly OK. It's not a commercial product, where everyone expects you to drop the old stuff no matter what and shell out all your money for the new and shiny version.
2) If you are interested in taking a glimpse at the future of the KDE desktop, install KDE 4.0.0 in parallel or use KDE 3.5 with new apps or KDE 4.0 with old apps.
3) KDE 4.0.0 has lots of under-the-hood changes right now that make it much easier for developers to implement new features. So we can expect a gradual shift and each user can decide individually when KDE 4.x.y is good enough to switch. Again, this is not due to KDE 4.0.0 somehow not being ready right now, but the expected "behavior" of an Open Source product in contrast to a commercial product.
exactly. =)