The KDE Community is happy to release the third beta for KDE 4.0. This beta, aimed at further polishing of the KDE codebase, also marks the freeze of the KDE Development Platform. We are joined in this release by the KOffice project which releases its 4th alpha release, bringing many improvements in OpenDocument support, a KChart Flake shape and much more to those willing to test. Read on for more.
Since the last beta, most of KDE has been frozen for new features, instead receiving the necessary polish and bugfixing. The components which were exempt from this freeze saw significant improvements as planned, and Aaron Seigo notes, "It is amazing to see the Plasma community growing. The pace of development is amazing, and we're getting really close to having all the features we want for KDE 4.0 available. After that, we have a solid foundation for implementing new and exciting user interface concepts for the Free Desktop".
KDE 4 is the next generation of the popular KDE Desktop Environment which seeks to fulfil the need for a powerful yet easy to use desktop for both personal and enterprise computing. The aim of the KDE project for the 4.0 release is to put the foundations in place for future innovations on the Free Desktop. The many newly introduced technologies incorporated in the KDE libraries will make it easier for developers to add rich functionality to their applications, combining and connecting different components in any way they want.
Comments
I think the BIG problem with KDE project is :
What is KDE ?
It's a set of libraries (kdelib)
It's a window manager (kwin)
It's a desktop ( plasma, with menu, taskbar, pannel etc...)
It's a set of applications ( konqueror, kontact, koffice, games, edu, etc... )
And more.
And the problem is that from one part to another, there are HUGE difference in stability : see for instance, openSuse wich includes some KDE4 soft in there oficial realeese. WTF ? It's only beta and is included in stable realeese ? Yes, because it's, in my opinion, ready for it. But other parts are not even existing yet ( quanta, many apps on KDE-apps, wich even if not part of KDE, are important in a kde environement etc... ) and other in the middle, alpha or beta quality.
So, when you release all of this, what do you base your name on ? the libs? they are tagged realised already. The desktop, or widget theme, it's alpha (or was until the beta3)
And last : If like me, you use a KDE4 build of your distro, it can add or fix some bugs. IE, mandriva and open suse will work and crash on uterly different things and soft, when they both have a KDE4 beta 2 ...
I dare say that taking the goods in both distrib, and forgeting plasma, konqueror and oxygen ( wich are show stopper in the official agenda ), beta2 is exactly a beta.
It's the applications developers job to port the applications to the new frameworks, not the framework providers, said in an eerie, sort of abstract kind of way.
So go whine to the Quanta developers about porting to KDE 4.
I think he makes a good point, just perhaps not really well phrased.
If we look at the libs, it's certainly pretty stable, beta-quality, almost-ready stuff. It seems that KDE developers measure the readiness of KDE 4.0 in this, hence it getting tagged as beta 3 now. KDE4-the-framework is in a decent state.
However, users, and beta testers of software will probably measure things completely differently, for example by how mature KDE4-the-desktop is or how mature KDE4-the-collection-of-user-software is. Both of these are severely bleeding so far -- the desktop admittedly so (see a comment somewhere here by Jos), the software... hmm. I guess we are exposed to this aspect of it much more and therefore spend our time complaining about the fact that pretty much nothing works beyond being able to open the whatever program, or perhaps play a round of Konquest or KMahjongg...
I personaly don't care if Quanta is not ported to "4" when kde 4 is released. I can go on with the 3.5 build ( if only I used quanta ). The same for Kopete, wich I use quite often.
The point I try to take to sun light is that diferent KDE components are in different states. So what would you base your release greek letter on ?
The thing is, KDE will be released with some missing bits and routh edges, but if you don't whant them, either :
- whait for a later release, wich will be the same as waiting for the first released to be delayed.
- use KDE 4 with some KDE 3 apps (oh, and even GNOME (yes, this other damn fu**ing desktop) ) if you are not satisfied with their KDE4 counterpart.
and about this :
> ... or perhaps play a round of Konquest or KMahjongg...
You forgot Kpat, wich is in my opinion the most polished KDE 4 thing today ^^
Also like Kalzium in its current state, and Kstars in kde4 is _for me_ more stable than in kde3.
Oh, and a last thing : you may whant to change oxygen to a less buggy widget theme, it will fix (as of beta _2_ ) a lot of bugs. (because some widgets arent drawn, you think "where is this button? oh, such a basic feature isn't available !" But changing the widget theme, buttons magicaly appear and everything sudenly sucks less )
You seem to have been living under a rock for some time.
KDE 4.0 is (afaik) so that the different technologies in KDE can start maturing (decibel, phonon, etc.), and most KDE developers suggest that if you want a (polished) desktop with, you wait for 4.1.
And the betas aren't "decided" by how stable they are, but more how long it has been since feature freeze, etc.
Ummm, actually the file dialog IS finished. Everything in kdelibs is, bar some bug polishing, the removal of KDEPrint, and the special cases of kate and khtml. That's why we're tagging the final version of kdelibs next week.
Now, if there's features that you want that are no longer there, that's another matter. Previews are still there (you turned them on in settings yet?), so's the edit bar too if you look for it (not immediately obvious I'll grant you). So what are you missing that leads you to conclude it's not ready yet?
John.
Yes, right-clicking to get to the traditional lineedit is not obvious, perhaps this behaviour could be set to default in kconfig somewhere?
Also I note that it is difficult to revert, and that trying to type '/' then return to view files in the root folder does not work. And are the verbose 'Home Folder' etc prefixes to the paths *really* necessary?
Do we just file these as bugs in bugs.kde.org ?
> right-clicking to get to the traditional lineedit is not obvious
mouse over the breadrumb, move to the far right, click. there's even a visual indicator. right click is unnecessary.
> and are the verbose 'Home Folder' etc prefixes to the paths *really*
> necessary?
no in the line edit mode, no.. that shoudl be fixed indeed.
> Do we just file these as bugs in bugs.kde.org ?
yes, or provide patches which are even better =)
> that shoudl be fixed indeed.
i just committed a fix for this as revision #726807.
and now, time to take nap. my body thinks it is still in munich =)
> yes, or provide patches which are even better =)
I'll have a look on the weekend to see how easy that is as I'd love to contribute in some way. Problem is I'm a physicist and I think/write fortran and python so any c++ patch might be a bit of a mongrel!
In case anyone else fancies a crack at it, there is also a small problem where long filenames are not always abbreviated (...'ed) in the dialog.
"Yes, right-clicking to get to the traditional lineedit is not obvious, perhaps this behaviour could be set to default in kconfig somewhere?"
Yes please, let us have a way to configure line edit to be the default behavior. It's so much quicker to type the location of a file then click through the filesystem. I still don't see what's wrong with using an 'up' button instead of the road block to typing in a path that is the breadcrumb, but I'm cool with it as long as I can configure it away.
What I built yesterday seems OK regarding File -> Open in Kate, at least it is up to Beta. Apparently not showing preview is default but it can be enabled.
OTOH, File -> Open in KWrite resulted in a crash. This would seem to be Alpha.
There are other issues! The Quick Access Navigation Panel had "media:/" as a default. This is still a useless 'feature'. Is this to make it look more like Windows? Well I have a lot of HD partitions and I have no idea which one to look on. It appears to me that what is needed is: "removableMedia:/" so that we can have access to those devices without having to search through all of the HD partitions.
However, I do agree that what has been released as Beta 3 is really the final Alpha. I say this because the desktop doesn't work yet. I can't find a menu. Is there supposed to be one?
To those that are dissatisfied with the state of KDE 4.0, simply substract 0.1 from the version number: In this way, the 4.0.x series becomes beta releases, 4.1 the first (real) release and the schedule is pushed back 6 months like so many requests.
Seriously. What the current release is labeled as is quite unimportant. What matters is the insane amount of work that goes into KDE4, and that, not the labeling, is what will make KDE4 great.
Personally i think KDE 4.0 will be much more complete (relatively) than KDE 3.0 was.
The "Release when it is ready" plan does not work well. Look at projects like emacs or the hurd, they release once every blue moon. When you have a target date, along with freeze schedules, then efforts can be coordinated to release the code. Even if the project is late, the target date serves a purpose by helping focus efforts on stabilization.
If there is no target date, then what happens is that people keep adding features, and every time the code is getting stable, someone else comes along and adds an unstable feature.
One way to get around that, is by going modular, where every component has its own release schedule, but that has problems as well. Especially with a big project like switching QT version, that becomes difficult.
Another way, is the way the kernel is done: have tons of branches, each with some particular feature or bug fix. The branches as they become ready get merged. This way mainstream will only contain stuff that has been tested to some degree. While this could be done in the future, this is difficult when you are changing the platform like they are doing for kde4.
"Look at projects like emacs or the hurd, they release once every blue moon."
Yeah, that was a real good example, of nothing. Hurd has really never had a proper release, nothing other than development releases. And it's been in development for what, 15 years or something. It does not really go anywhere.
And Emacs, judging by version numbers it has had lots of, and frequent releases in the past(newer cared about it, so i haven't followed its history either so I may be mistaken). Current stable release is 22.1 or something. The fact that nothing much has been happening it the last years, does have more to do with the maturity of the codebase and the lack of new fetures. Than the release early and often paradigm. Besides from the user trends seen, it's steadily losing ground compared to other editors. So it may even fade into obscurity, where it imho belongs.
Best post in this thread.
He obviously has worked on codebases, unlike the armchair quarterbacks round here, bitching.
KDE 4.0 is a stepping stone to a replacement for 3.5.8 but it is not a replacement.
Some people seem to have a fundamental problem with not upgrading when there is a higher number release! Early adopters of 4.x will take some pain but those early adopters are needed to take the 4.x forward. The release date serves to focus development on a specific goal and is needed.
Getting the 4.0 out the door without some favourite apps or functionality is still the quickest way to get them done eventually rather than wait for the whole desktop experience to be complete so that everyone can upgrade from 3.5.8 at the same time.
I just updated KDE 4 beta 3 from Opensuse 10.3 (3.94.1) and it is working great!!
Major things are working without much issues: dolphin, konsole, systemsettings. Even the panel started to show up 8-).
I already watched movies, heard MP3's, and prepared a presentation with NO crash!!
The KDE 4 team is doing a great job!!
"End User" testing to me means:
* All components either upgraded or compatible (installing won't kill my KNewsTicker or KPager or whatever) with 3.5
* If something new replaces something old, there is an upgrade process that does not require user interaction
* There are binary packages that upgrade existing KDE binary installs, and preferably a YUM repository for FC5 and greater at least.
We need to submit this story into the tech media outlets. There are many cool screenshots here to get people excited about KDE4 :)
http://www.kde.org/announcements/announce-4.0-beta3.php
You can Digg it here:
http://digg.com/linux_unix/KDE_4_0_Beta_3_Released
http://digg.com/linux_unix/KDE_4_Beta_3_Ready_for_Testing
kubuntu says it has packages but I can't see some packages such as dolphin and konqueror. Anyone know what's up?
The kubuntu packages are fairly poor. The desktop will not even start with kubuntu's packages. You're better off following techbases instructions to compile them from source... its actually not that hard.
Konqueror seems to be in kde4base, dolphin I don't know because I can't stand it and didn't look for it yet.
That may be the first time I've seen apps properly showing on the taskbar in KDE 4. It may seem small, but the biggest complaint I've heard from beta testers so far is the lack of functionality in the taskbar/panels.
Yes, since it is ok to have many bugs, problems and missing features. But if you cannot switch windows or if it is just to complicated, than you cannot test over a longer time ;) At least this was my problem.
After all, Beta 1 and 2 was not for beta testers, I think/hope they won't choose that name for Alphas/TPs again for the next release cycle ;) This one is the first version worth a test for me, the announcement also contains informations for Bug reporters.
Greetings
Felix
I really appreciate the great work of the KDE folks. But that doesn't stop me from being concerned about the current state of development and how it is "marketed". At least Beta 1+2 were far from Beta quality (as some others already said) - which is understandable, since a LOT of new cool stuff is being developed, and that takes its time. When the first Beta came out, I was really eager to get my hands on it, start testing and contribute to the project by reporting bugs, but I got frustrated within a few minutes since basically nothing useful worked. Beta 2 was a bit better, but still not really testable. Now (given that I don't have a flat rate) I'm reluctant to even download Beta 3.
Don't get me wrong, this is NOT bashing. I am really grateful for all the awesome work, and I'm a big fan of the K. Consider this a petition to the developers not to stick to the release plan at all cost, but maybe rather release a few more Betas that are actually testable, so that things really actually DO get tested by "black box" users before the final release.
Point is, it simply depends on what you consider beta quality or not. The libraries where rather complete in the previous betas, and most applications as well. The basic workspace, plasma, on the other hand, wasn't. But I've always stressed that point in the release announcements.
Really, it's mostly plasma which makes you (and all others here) complain about the bad quality of KDE 4.0 betaX.
What I consider Beta quality is everything that can be tested in a non-critical production environment. That is, on my home PC as my primary DE for private purposes. And if the user interface doesn't work, that criteria isn't met. In other words, it's very frustrating. And I think this is valid criticism.
Anyway, thanks for the information, that really cheers me up. I'm quite confident that 4.0 will be the greatest KDE release ever.
"I'm quite confident that 4.0 will be the greatest KDE release ever."
Actually, quite the opposite: it will likely be one of the worst. I'd wait for 4.1 or 4.2 before it gets to the same level as KDE3.5.x.
But thats only because KDE 3.5 is such a solid release. You apparently are not familiar with the early KDE 3 releases, I think KDE 4.0 will beat those. :)
hi
i just want to say that im using svn from 4 days ago... (beta 3 with a bit more progress) and is excellent... the quality is incredible, is so stable that is very usable already... im using it as my main DE right now, im also thinking in removing KDE 3.5 already, i actually don't need it anymore... sure, is not feature complete yet but KDE 4 is already usable for me and i can't wait for the final release :)
keep up the great work KDE team
I know this has been brought up time and time again, yet I haven't heard much of a developer response.
In literally every KDE 4 screenshot I've ever seen, there are these huge toolbars, most prevalent in Dolphin screenshots. The icons are fairly large, have text labels, and perhaps worst of all, they have tons of dead/empty/white space around them.
I know this is a subjective matter of taste and all, but I know there are plenty of people who like to maximize the space for the actual content in their application, and minimize the screen real estate that the interface takes up.
I'm curious why the interface takes up so much space, and if there is a way within Oxygen to configure this, or will we just have to wait for others to develop other styles all together?
Right click on those icons, then switch off the text (or show only the text, whatever you prefer), and choose the icon size to your liking.
I find the buttons with icons+text default for most apps really useful, it goes together with a general cleanup of toolbars. They're also much easier to hit with the mouse or touchpad.
Having icons+text is not Oxygen related. It is the same for all styles
But in Oxygen we will try to make the distance from icon to text smaller. No promisses though. I don't know yet if it's even possible in a friendly way.
Hmm, rather then (just) minimizing the distance, why not make the font for the labels 1 or 2px smaller? Would achieve the same effect to make the buttons easier to hit, but would look better and wast _a little_ less space.
"But in Oxygen we will try to make the distance from icon to text smaller. No promisses though. I don't know yet if it's even possible in a friendly way."
That's very surprising - could you give a brief technical reason for this, if you have time? I'm intrigued - it seems like such a simple change, and I wonder what the hurdles could be. Is it some inflexibility in KStyle/ QStyle etc ... ?
Maybe this is related to the fact, that fonts usually contain a lot of characters, which go vertically beyond the top (or bottom) of the "normal" alphabet characters (A-Za-z) and text widgets usually have to size so big that all caracters of the font COULD be displayed, even when actually not needed.
I had a similar problem with some line based report generator with which it was not possible to minimize the space between some text and a barcode below.
My solution was to edit the font with some font editor software, remove a lot of caracters, move or reseize some others and edit the global font characteristics values, such that no character got below or above an "A".
The default behaviour of toolbars is large icons + text. This is to make the functionality in toolbars more apparent, and discourage app developers from putting 30 icons in the toolbar (which makes the whole interface look cluttered).
This is a global KDE option and you can easily switch back to the small, icon only view that was the default in KDE3.
But will there still be so much empty space around each icon?
Judging by quickly comparing it to the amount of space around the icons in KDE3 with it set to text under the icons, there doesn't seem to be really that much of a change in the amount of space used for that setting.
I presonally prefer text alongside the icons. It still discourages the flooding of the toolbar with icons, but saves more area in the application for actual usage, and doesn't leave as much dead space to the right of the list of toolbar buttons (though as a default for everyone, it may be better to go with under from a usability perspective).
I completely agree with the comments about the dead space in KDE. I've been complaining about this since about the start of KDE3. When I'm working on a windows machine at work, first thing I do is reduce the width of the scrollbars, reduce the size of the min, max buttons / bar. Yet, these features are almost impossible to do. KDE 3.5.8, and I still cannot reduce the amount of space wasted by a scrollbar I never use (god gave us the mouse wheel for a reason).
Its not just that, but the space wasted everywhere - between buttons, round tabs, between toolbar entries etc.
I always want the most out of my desktop real estate, and KDE just doesn't deliver. Another example, the other day I was writing a little ruby script at work on notepad++. Went home and wanted to continue working on it in Kate, but had forgot to commit it. Remoted desktop into work, copied the text and pasted it into Kate. On desktop that was exactly the same size, 1280x1024, notepad++ wasn't maximised, kate was, yet the lines of code were almost all wrapping on kate, but weren't anywhere near on n++.
Sorry to sound like I'm ranting, I'm really not, I just cannot believe so few people see this as a massive issue when it comes to producing a working env. I love KDE to bits, I just cannot use it for anything more than a hobby when its so detrimental to my productivity.
The scrollbars width depends on the widget styles. Polyester allows you to change the scrollbar width. The title bar height again depends on the window decorations used. Since window decorations & styles are just KDE modules implemented in C++, different widget styles & window decorations have different levels of customization available.
Regarding the space, that should depends on the widget styles also. But even if I use the default Plastik and customized my toolbars to remove line separators, there's almost no redundant space left, IMO.
I would also like to take the chance to rants about Windows then.
Several missing features regarding windows management that absolutely killed my productivity in Windows are
1. Missing windows setting such as shading, always on top and the ability to change the behavior under actions such as double clicking, mouse wheels, Alt + drags.
2. The ability to assign window shortcuts. For example, I like to set Win+K to be my konqueror window, Win+E for my emacs windows so that I can focus them anywhere/anytime, even if they are minimized or on a different desktop.
3. The ability to set window size, geometry, decorations based on the applications or on the windows name. For example, I like to open konsole to be only of size 600x480. I want my dolphin windows to be maximized vertically upon start since I usually display files in a listing not as icons, and many other uses.
So as a test case, try doing this in Windows. Copy 10 segments of text from a maximized webbrowser to a non-maximized editor. You will have to fiddle around with clicking taskbars to get focus since your if you want to focus your webbrowser, you have to click it, which then de-focus your editor, and since your editor cannot be always on top, to get back to your editor, you have to click the taskbar or cycle through the window task list with alt-tabs.
Bottom lines ? I just can't believe, even when I'm high, stoned, and having the greatest sex of my life, that so few people see Windows as having a massive detrimental effects to their productivity.
You don't have nVidia card and driver, have you?
They give you shading and auto focus and such.
Actually, WinXp is not about WinXP, it's about WinXP
modders, tweakers and hackers.
Your absolutely right. And its not only wasted (work)space, because of big
plump (or neat - it doesn't matter here) icons and widgets, that makes me
feel a chance was missed. The chance to become (stay) a (the) professional desktop.
Attention turned to eyecandy, Dolphin instead of Konqi as the default FM,
icon-views instead of tree-views etc. The latter is a good example.
There is - known for ages, think of genealogical trees - nothing what
compares to tree-views when it comes to map hierarchical systems.
And thats what our current file systems are. But then it was argued,
some would have difficulties with treeviews:
A. Seigo: "... but if we can avoid a treeview that would be great as
most people and trees don't get along ..." - So here is a decision,
made not by the accurate solution but caused by the customization to
an (imaginary) average user. But you cannot map a hierarchical system
with a flat (icon)view regardless of 'breadcrumb-navigation' ... You can
not abstract from the essential.
And what was wrong with the approach, to provide a user with the
essential features but let him also choose some quite usefull simplification
or nice eyecandy. That is what i would think of as a professional approach.
The reverse - even if its really nice - it's not.
I would not care if only the defaults would change (even though i think it's
the wrong turn), but here priorities had changed. And the doubtless great efforts
that were made to those eyecandy and simplifications should have gone more into
the great and outstanding features KDE has had - Konqueror to name it. But also
Kate or Quanta, or KDE-wordTrans - not only because of my bad English ...
Right, there was work done too - but i'm talking about priorities and tendencies.
And if those features and applications are as good as they could be now, then
a community would arise, building superkaramba or the like, to make their workplace nicer ...
IMHO
a) Dolphin has a tree view; and b) there has not been some huge shift in focus from functionality to "eye-candy" - both are worked on, but Qt4 makes eye-candy so easy to create that taking advantage of it is practically effortless.
Looking at the composite screenshot ( http://www.kde.org/announcements/announce_4.0-beta3/kwin-composite.png ) it appears that the Konsole window has the background of the console area alpha-blended, but not the text? If so, that's definitely going to be a nice feature, though adding a slight amount of blur to whats underneath might make it easier to read the text when theres text under it (though I'm pretty sure I first heard of that method on the blog of the guy working on KWin-Composite, so probably don't need to tell him what he told me ;). Yet another feature I'm going to be excited for, a Composite Manager that doesn't forget about the whole Window Management thing! Though hopefully by the time I get around to upgrading to 4.0 there will be better r300 support for Composite & AIGLX.
Oh my! I nearly forgot the most important part of my post: Thank you to all the KDE contributors for your underappreciated work! The KDE Community has really created quite an amazing project.
KWin does indeed already have the ability to blur what's below a semi-translucent ability -- the effect simply wasn't enabled in the screenshot. :)
I can't believe how many of you are bashing the developers.
They are making an amazing job, it's indeed true that some applications are just ports, so what? Don't you use them every damn day in KDE 3.5.8?
I can't understand all that people, I mean, they basely port everything to Qt 4, then they added new feature, wrote a new technologies like Phonon, Plasma and Solid, Added Composite support to Kwin, created a new theme, and it's not just gnome theme or domino engine, it's actually a lot of work, have you ever seen all the work on the icons?
And because they couldn't add features to 2 or 3 applications and didn't have time to completely port 2, you're fucking in every single commit digest.
KDE folks, just ignore them, you are (and always had) making an amazing job with KDE 4, cheers to all of you.