Stephan Kulow (KDE 3.2 release coordinator) and Ralf Nolden announced a preliminary KDE 3.2 release schedule and asked everyone to check with the personal schedule. Every planned feature should be entered into the KDE 3.2 feature plan before September 1st, 2003 and has to be implemented before September 29th, 2003. An Alpha 1 release is expected for release after the KDE developer conference 2003 in Nove Hrady on September 1st, 2003. Provided that only one Beta release on October 6th, 2003 is necessary, the final KDE 3.2 release is planned on December 8th, 2003.
Dot Categories:
Comments
Wow! KDE 3.2 would make a great Christmas-present.
Hope you guys make it in time!
The plan looks great. With more than a month for the final bug fixes. I have the feeling that one beta will not be enough, just because the integration in the PIM area will be very involved, but we will see. Even if it is released early next year, it is great news. For most users this is irrelevant, because most of the distros will release around september/october anyways, and KDE 3.2 will be out for the following release (march/april 2004).
Having the Nove Hrady meeting as a discussion forum right before the release cycle is gonna help so much. Cheers, thankyous and congrats !
Is it still likely that KWallet will make it? Only 2.5 months left, and no commit since many many months...
its being talked about...
measure twice cut once...
with something as important as a safe place to store creditcard # and passwords, i would hope some thought was putinto it.
Cheers
-ian reinhart geiser
Personally, I'd appreciate even a very simple kind of KWallet for Konqueror just to save username&password combinations. It's particularly annoying having to retype them in every dialogue/form! Then a really secure system could come later.
I'm gutting everything that is there and redoing it. I will commit in a large chunk, most likely by the end of the month for the bulk of it. I'm developing it locally for now.
Wow! Great, I'm willing to start using it. I was just about to code the part of my app related to password storage, but I may wait till then.
Will it be KDE 4.0 or KDE 3.3? /me hopes Qt 4.0-final comes out sometime in the middle of 2004. That would mean a right time for KDE 4.0. If it comes out later than that, perhaps a quick release of KDE 3.3 would be better.
KDE will be called KDE 4.0 as soon as it requires Qt 4. That's it. :)
Cheers,
Daniel
Why?
We should have at least another 2 years of Qt 3. Most companies upgrade about once every 2-3 years, some will put off almost 5.... To rush a major upgrade so often only allows us to damage our userbase.
I have just moved my last client from KDE 2.2.2 here. They are now on KDE 3.1.2.
Remember we are not trying to cater to kids in their basement any more, those of us trying to make money off of this need a stable longterm project.
Just my 2c
-ian reinhart geiser
> Why?
I know reasons. There are many desirable things that may require a new major release (because they will most likely break binary compatibility), like
- a solution for reflection of API classes, so languages like Python and C# can access all KDE APIs all the time without the need for wrappers. Basically the functionality of COM or CLR, but hopefully nicer
- a standard for binary compatibility with the goal that you can just copy a binary (for your CPU) on your computer, execute it and it runs. Or that more complex apps can use something like autopackage.org. The goal would be easy installation and less work for vendors/projects that create external KDE apps. Basically a Windows-like situation....
- a new multimedia system
The problem with all 3 issues is that I don't know a good solution for any of them. But if at least two of them could be solved, that would easily justify a new major release.
AFAIK the only thing that justifies a new major release is binary and source compatibility changes within the KDE libraries.
as for the three points you enumerated, the second one is not in the purview of KDE as much as it is the OSes it runs on. a new multimedia system may not necessarily destroy the old API; it may fit in transparently or even just keep the old API for compatibility (something I'd hope would happen even in a major release) and provide a new preferred API. this preserves compatibility and avoids a major release.
as for the reflection/clr point, this is the one most likely to create problems if it requires any sort of vast internal changes. but if it is provided as an add-on layer then we may once again be in the clear.
ian is very, very right about maintaining long period of compatibility. not doing so hurts our users and tech companies and contractors who depend on KDE for their liveliehood (yes, those exist, and yes, there are more and more of them popping up).
of course, this isn't an excuse to avoid progress in KDE where necessary. rather, this is a great ballancing act that the entire KDE team must chart through with prudence. i do not envy the release dude(tte).
I understand the concerns, but IMHO at least the first two points hurt even more.
Number 1 prevents people from using more languages that may make them more productive. Right now when using a scripting language you feel like a second-class citizen. It also hurts future compatibility - C++ will not be the right language forever. I would feel much better if I knew that the stuff I am working on today will not be obsolete in 5 years because there is no way to use the C++ code by whatever language has displaced it then. And I am pretty sure that I won't use C++ in 5 years. I don't know whether it will be a future version of Java, or C#, or Pike, or maybe something else, but certainly not C++. I am ready to switch as soon as they are feature complete, fast and stable enough.
And the longer KDE's APIs are not future-proof, the more work will it be to make them (as they are growing all the time).
Number 2 hurts because it makes it impossible for most users to install software that has not been distributed with/for their specific distribution. And it hurts vendors since it increases the cost to support KDE (BTW this is not the OS/distributions fault: only KDE can give instructions on how to build KDE using which tools in order to make KDE apps compatible among distributions - it's unlikely that distributors will create suc a standard).
All this talk is irrelevant right now, of course, since there's no solution yet for any of these problems.
> Number 1 prevents people from using more
> languages that may make them more productive.
agreed; language support is nice. but let's be a wee bit realistic here: even when there are language options people usually pick just a few of them for the vast majority of work. and no, we don't need to build into our libs some magic future proofing. what we "need" is a layer that talks to our native libraries that exposes and easy-to-bind set of interfaces. i keep hearing rumours of such things from various binding people, so we'll see.
> And I am pretty sure that I won't use C++ in 5 years
just like nobody uses C anymore ;-)
> know whether it will be a future version of Java, or C#,
> or Pike, or maybe something else,
Ruby? =)
> Number 2 hurts because it makes it impossible for
> most users to install software that has
> not been distributed with/for their specific distribution.
of course. but KDE can't say, "SuSe, you will now start using gcc x.y, XFree86 a.b with extensions foo and bar, provide these versions of these specific libraries ...." let's not even get onto the topic of systems like Solaris. we can recommend tools and libraries (and we already do) but we can't force the vendors to comply. the LSB is an important tool in this direction. and before anyone decides to whip out their LSB hate on me, i suggest they look long, hard and with rational minds at the evolution of the LSB because then you'll perhaps realize that while it isn't there yet, it is quite far along the trail and it has massive buy-in which is what really counts.
of course, a new version of KDE, minor or major, is not going to fix this. even if KDE started shipping a complete OS it would only further the problem by adding one more derivative to the mix.
>what we "need" is a layer that talks to our native libraries that exposes and
>easy-to-bind set of interfaces.
That would have similar problems as the current language bindings: they are always at least one step behind. And it's also a lot of work. What we need, IMHO, is to use that kind of layer as primary API for all languages, including C++. COM and QSA's use of Qt slots show that this can be possible without less comfort for the C++ developer.
> Ruby? =)
Only type-safe languages for me...
> we can recommend tools and libraries (and we already do) but we can't force the
> vendors to comply.
We can't force them, but we could promote those distributions that follow the standard. And I think as soon as 2-3 distributions support it and developers are starting to release their software as convenient binaries, the users would want their distribution to adopt it.
(BTW part of the problem is that such a thing needs a lot of other requirements, like LSB, or KDE needs a lot more wrappers for system-near functions that would otherwise be specified by the LSB - and it's a good thing to make KDE more platform-like, I would like to write a server or a web site using the KDE libs)
I´m glad to see references to Pike.
Anybody tried to get Qt/KDE wrappers for Pike?
I´m not quite happy with Gtk (even when wrapped in a OO language like Pike becomes pretty usable). But I wasn´t able to hack the ugly Perl mess to get it working.
> Only type-safe languages for me...
Hey now... Ruby is more type-safe than C, C++, or Java. Maybe you are thinking of staticly-typed languages, which Ruby is not. However, it *is* strongly-typed - more so than C++, where a reinterpret_cast or C-style cast can bypass the type system.
I won't whip out my LSB hate because I don't hate the LSB. But, I do have an engineer's skepticism.
I do NOT see how the LSB or the FSH will ever solve this problem. Didn't say that it wasn't possible, only that I don't see it. :-)
You are welcome to read my comments on: [email protected]:
http://www.desktoplinuxconsortium.org/pipermail/dlc-discuss/2003-April/t...
Please join the list and comment on what was said:
http://www.desktoplinuxconsortium.org/mailman/listinfo/dlc-discuss
Note that there has been only one posting (which was OT) since the thread I started.
I think that they just don't get it. They will not solve the problem because they don't see that there is a problem to be solved. Actually, it is a problem CREATED by the distros. Just look at how RedHat slices and dices packages -- installing the parts in what appear to be very obscure locations.
What we need is (to be able to have) a set of generic KDE RPMs that will install on any LSB system subject only to the normal requirement that all needed libraries (with versions >= the requirement) are present. If that were possible, then applications could easily be installed from a standard RPM.
Until that will work, the LSB is useless, and I don't really understand what they are doing.
I can see enhancements that could be made to RPM (or KPackage) that might make this possible (or easier), but what we have now is distro fragmentation just the same as the fragmentation that killed UNIX on the desktop. :-(
But the only real solution that I can see is a GNU distro for Linux that will set the standard for where things should be installed.
--
JRT
> ian is very, very right about maintaining long period of compatibility. not doing so hurts our users and tech companies and contractors who depend on KDE for their liveliehood (yes, those exist, and yes, there are more and more of them popping up).
Why not just install multiple versions of the libraries concurrently and implement a thin layer that auto-magically manages them --- something like Microsoft's new Strong Binding in Longhorn.
Microsoft has broken binary compatability between different releases of their system dll's for years, but Windows users get the all the benefits of having binary compatablity. The only downside of this was "DLL Hell"-- conflicts between different versions of the same dll which caused apps to be broken. Strong binding fixes this.
It's should be obvious that even with "auto-magical fixes" like "Strong Binding" (heh) this is simply bad design and shouldn't be necessary at all.
> - a solution for reflection of API classes
Obviously not all languages are reflective, however I've been toying with ideas for some kind of decent component model for a while now. No time to experiment though :)
One idea I had was to do something like Swig, but in multiple directions, ie not just C++ -> scripting languages. It would work a bit like GStreamer by connecting the elements, so for instance if you don't have a plug in for direct binding C++ to Ruby, it would first bind it into GObject, then from GObject into Ruby. Inefficient yes, but OTOH I believe that doing automagic bindings with the ability to do manual overrides produces bindings of a far superior quality to that of COM.
The main problem is that this would not be contract based, ie no component activation. But I'm not really convinced that it's hugely useful anyway. Outside of embedding spreadsheets in word processors etc, which could be done using IPC, I see little real world usage of it. COM mostly defines interfaces specific to an implementation, and where plugin style code is used (shell, urlmon, ole embedding) it's rarely implemented.....
Of course, COM is widely used, and this is just my ranting :)
> - a standard for binary compatibility
Well the LSB is attempting to specify the ABI of many libraries, but I'm not sure how useful that is. Beyond glibc symbol version sets, the ABIs are versioned via libtool anyway. And projects like KDE and GNOME take binary compat very seriously now, which is good.
Basically the problem is more one of dependancy management, ie being able to request a set of ABIs and know they are present.
> with the goal that you can just copy a binary (for your CPU) on your computer, > execute it and it runs.
Sure. If all its dependancies are present. But we can already do this today, with a little bit of work. Just need to make it super easy for developers to know about, and get the word out.....
> Or that more complex apps can use something like autopackage
Let's hope so eh? :) This is not a KDE issue though, it's separate to the desktops in my view....
> - a new multimedia system
That can be phased in next to aRts, don't have to scrap the old one to use a new one. GStreamer! :) But I know you already like that software.... bloat isn't really an issue here. Neither arts nor GStreamer are exactly huge by todays standards. Why not have two?
> OTOH I believe that doing automagic bindings with the ability to do manual
> overrides produces bindings of a far superior quality to that of COM.
I would rather have a single interface than learning a new one for each language.
And if each language has a different interface it must have its own API docs etc..
>> with the goal that you can just copy a binary (for your CPU) on your computer, > >execute it and it runs.
> Sure. If all its dependancies are present. But we can already do this today, with a >little bit of work. Just need to make it super easy for developers to know about, and
The difficulty is to a) get all distributors compile KDE with the same compiler version, flags etc and b) to find abstractions for everything that is currenlty outside of KDE's scope (either by requiring something like LSB, or by writing KDE wrappers).
> I would rather have a single interface than learning a new one for each
> language.
> And if each language has a different interface it must have its own
> API docs etc..
Yes, that is the downside. The problem with things like COM though is you need to suddenly use non-native strings, can't use language features like iterators etc
> The difficulty is to a) get all distributors compile KDE with the
> same compiler version, flags etc
Once we are past the ABI break, that shouldn't be a big problem anymore.... and this was a one off.
> b) to find abstractions for everything that is currenlty outside of KDE's
> scope (either by requiring something like LSB, or by writing KDE wrappers).
Well I don't really understand this part, why do you need to add another layer to everything? That doesn't imply greater stability.
> Yes, that is the downside. The problem with things like COM though is you need to
> suddenly use non-native strings, can't use language features like iterators etc
That would be part of the language binding to the component model. A developer using Python should not, of course, have to convert their strings into a QString first. This will not always be possible, but if there is a nicer language-specific way to design the APIs you can always add better wrappers later. But no one should be required to use them, because they cant be always available.
> Well I don't really understand this part, why do you need to add another layer to
> everything? That doesn't imply greater stability.
KDE's APIs are not complete. Many apps need POSIX or possibly even more OS-specific syscalls. When your app, for example, needs a list of processes it has to parse the /proc file system. And when the /proc interface changes this is as bad as a change in one of KDE's lib for binary compapatibility.
So there are three possibilities:
- KDE needs to require certain properties of the OS, like the /proc file system (listing them would be a huge amount of work...)
- the KDE compatibility standard must be build on top of other layers, like LSB
- KDE must forbid apps to use non-KDE APIs if they want to stay compatible. Maintaining binary compatibility would be only KDE's responsibility then. This implies, of course, that KDE needs to wrap a lot of interfaces that are not accessible by the existing APIs.
> That would be part of the language binding to the component model.
Yes, I suppose you are right. Designing a component model that fully takes advantage of every languages features though is not really possible, you would always be accused of "dumbing down" like the accusations against .NET (which is a nice way to do things imho, but perhaps not politically acceptable).
> And when the /proc interface changes this is as bad as a change in one of KDE's > lib for binary compapatibility.
So, the kernel developers should "get" binary compatability too. I don't think it's KDEs place to abstract every little thing - binary compatability is everybodies task, I don't think KDE/GNOME should be attempting to cover up others lack of correctness here.
> So, the kernel developers should "get" binary compatability too. I don't think
> it's KDEs place to abstract every little thing - binary compatability is
> everybodies task, I don't think KDE/GNOME should be attempting to cover
> up others lack of correctness here.
Yes, BC in/by the kernel would be nice, but there are other reasons for offering all POSIX functionality with KDE APIs (a single API for everything, less problems when porting to non-Linux systems...).
I wholeheartedly agree. Unless there is a compelling reason for switching to a new Qt codebase, the KDE project would be better off having a long release cycle in the 3.* series, providing API compatibility, so that people can develop on KDE without having to port to a new API in six months :-)
All KDE needs to do after 3.2 is work on polish.
This means make it easier to use, add more things like the control panel, make it easier to install programs, perhaps make it possible to upgrade KDE at the click of a button instead of having people go through hell to upgrade it.
Oh and SVG Icons, Fonts, Widgets etc, we need to make the KDE interface run as SVG and phase out pixels. The Xwin guys are working on the backend, KDE needs to have the frontend ready to actually take advantage of hardware rendered vector graphics.
Overall KDE just needs polish, all the major issues with KDE are over, we dont really need more software, we just need to improve the current software.
Finish and improve Kopete, Polish the interface, go SVG to make it modern, work on figuring out how to make KDE the easiest to use interface on the planet, add useful features, take a few ideas from Apple and Microsoft, and just make it ready for the tidal wave of casual users who will switch to Linux in the next few years.
KDE 4.0 should be released to compete with Longhorn in 2005, hopefully by this time the interface will be fully SVG, everything will be polished, transgaming will have games working, programs will be easy to install, and hopefully the fonts and alpha channel will be working and not just cheap software hacks.
When this happens, Linux will be set to compete with Longhorn on the desktop, KDE team should position itself to beat Longhorn and whatever Apple comes up with next, this means KDE developers should focus on innovation, so we have the Konquerer browser? Add some features to it that no other browser has, INNOVATE.
Innovation is the only way Windows users will use Linux, its the only way Linux will compete with Longhorn, hopefully some developers are reading this, INNOVATION is the key, you want Microsoft to copy us, not us copying Microsoft.
I think KDE is functional, the only thing thats missing right now is innovative new features, and polish.
Dont copy Apple or Microsoft, currently KDE is looking like a Windows clone, its fine to take good ideas from Windows, but after KDE 3.2 I'd think its time to innovate, come up with our own ideas, and make Linux the easiest to use OS by 2005.
The Slicker project seems to be a good start, its innovative, and could have potential to make Linux easier to use than Windows.
http://slicker.sourceforge.net/
Believe me if the KDE team and Linux does not innovate, and decides to copy Windows Longhorn after we see how it looks, No ones going to switch to Linux, why use something which is trying its best to copy something else?
Linux and KDE needs an identity, I think its currently as functional as Windows, it has all the software anyone ever needs, now whats needed are features that no other OS has.
My suggestion would be to focus on polish for the 3.3 release, also I'd focus on making KDE more modern by switching to SVG.
Hopefully in 2004-5, I will see KDE 3.3 come out and be the easiest to use interface out there, with features Microsoft nor Apple have, if this happens I think Linux will have a good chance as a Windows replacement.
I see alot of developers talking about working on the backend, thats the problem with Gnome development, Gnome 1.3/2.0/2.2, it all looks alike, I dont see it being any easier to use, in fact it seems like it gets harder to use every time I try it.
I think the future of Linux will be on the desktop, Gnome currently is so awkward that I dont see anyone picking Gnome over WindowsXP or OSX, KDE has a chance.
The only thing a normal person cares about when they use Linux on the desktop is how intuitive it is, and what features it has.
> I think its currently as functional as Windows, it has all the software anyone ever needs
You're so wrong. Oh, and you forgot to mention when you will start to send patches.
I have done some Linux development. Alot of the ideas I have I'm not capable of doing, considering that I am not a master of C++, I dont know how Xrender works, or how libSVG works, I just know how to innovate.
We have enough coders, a coder with no vision is just a machine cranking out code, we need vision.
It's bad that KDE 3.2 will not have kexi! When shall we have it? Whenever it comes out, converting my more than 27 MS-Access programs into native kexi programs will start in full swing. Thanks for the good work kde developers
1. Kexi is part of KOffice, not KDE. It will not be in KOffice 1.3
2. If it's not in KO 1.3, it *may* still be released separately when it is finished
Hello friends,
Can we expect a major UI overhaul in KDE-3.2? Also, are fonts and font rendering much improved? Right now they are horrible. My fonts don't look anti-aliased and they are sometimes disturbingly misaligned in some window decorations. Furthemore, how about kde-multimedia, can we expect significant improvement or changes in KDE-3.2?
In addition, apart from new integration of tools, new features and bug fixes, are they any major enhancements being made to KDE's fundamental architecture? I'm talking about kdelibs, kparts, dcop and basically any other fundamental rewrites that can make KDE much responsive, much faster and utilize better memory/system resources. Perhaps, even lighter though I admittedly doubt this.
I apologize for all the trivial questions but I'm just curious. Of late, the news has been about new features and new apps, which are well appreciated and welcomed. But not much has been said about the improvement being made, if any, to KDE's underlying architecture. Maybe not much needs to be said about it. Maybe it ain't broke, so there's no need to fix it. *shrugs*
I'd also like to commend the developers, the administrators and the community, in general. You're all doing a great job.
Regards,
Mystilleef
> Also, are fonts and font rendering much improved? Right now they are horrible. My fonts don't look anti-aliased and they are sometimes disturbingly misaligned in some window decorations.
Font rendering done by KDE? You don't want a new KDE version but install other fonts/fix your system.
Are you using TrueType fonts? I have no problems with my fonts. They look as good or better than my windows machines. If you are using bitmap fonts, yeah I will agree with you!
Hello again,
I thought the KDE fonts where all bitmap fonts. The fonts on kde look a tad different from, say, that of XFCE or Gnome. In other words, the fonts look much smoother on XFCE or Gnome than on KDE, at least on my system. So I'm confident it's not a problem with my system fonts. Because of this anomaly, I was under the impression that KDE had a perculiar rendering technique that makes the fonts on KDE look a little rough on the edges on my system. Fortunately, I'm wrong. I'd check to see if I haven't configure something right in KDE or if I've improperly setup my font server. :?
Regards,
Mystilleef
Fonts on Linux can be a bit of a pain. You can run bitmap fonts, Adobe Type 1 and now True Type. Antialiasing came available early in XFree 4x. X manage this and QT was about the first program to support the xrender extention. So something like a year and a half ago KDE had antialiased fonts. Gnome just recently got them. I seem to recall something a while back about an early solution they had where they sort of hacked some of the code to get it done. I don't know if the current install is at all non standard but I am wondering how it shows up right there and not on KDE unless you simply have selected bitmap fonts on KDE and GNOME has good fonts.
Now would be a good time to ask what your distro is if this is set up so badly. Anybody for conspiracy theories? ;-) I'm guessing if you were to grab a Knoppix CD you'd be amazed at all the improvments suddenly in KDE in 3.1.2.
Hello again,
Hmmm...very strange. I use Gentoo Linux, arguably the best distro for a responsive and well installed KDE. I also currently use KDE-3.1.1a. I'll be updating to version 3.1.2 most probably this weekend. I use the Verdana font, a true type font provided in XFREE 4x. The rough edges are almost invisible to the eye, except on close inspection or if I use a font larger than 12. I'm pretty sure I enable the anti-aliasing option in KDE's Kcontrol.
Now that I know it's problem specific to my system, I'll try haunt down the reason for this strange behaviour. I also need to mention that there is sometimes no difference between certain fonts. For example, on my system there is no difference between symbol, verdana, and helectiva,[b]especially on KDE[/b] if I'm not mistaken. This is just one example, there are several fonts that look exactly the same. I'm begining to suspect this has something to do with my font configurations. I'll check that out when I get back home.
Reagrds,
Mystilleef
> Hmmm...very strange. I use Gentoo Linux, arguably the best distro for a responsive and well installed KDE.
Well then your problems will largely depend on the last time you rsynced and emerged. Gentoo has been moving toward a single font configuration in /etc/X11/ from XF86Config and XftConfig to fs/config. Even worse is the fact that for some reason ghostscript builds with hard coded font paths and refuses to use any newly listed path so that things display one way and print another if you've added new font paths. As good as Gentoo is this is a bit of a mess. I've been back and forth trying to resolve the font issues with little satistaction. At least they look great on screen and the Corel fonts I directly imported into my default Type 1 font directory work great for KDE apps. Of course I can't read a printed email. Some day I'll spend some more time and get it sorted out but for now it's not really that much to do with KDE as with growing pains with X and Gentoo attempting to resolve them. Ironically previous builds of XFree and Ghostscript worked virtually perfectly.
Next time I have time to work on it when I can see straight I may just blitz bugzilla because I think people have found these problems on the forums and not reported them.
for Gentoo, type in a shell:
fc-cache
All my fonts work great
I had this problem, I'd forgotten to do rc-update add xfs default
> Can we expect a major UI overhaul in KDE-3.2?
In some parts, like kcontrol.
> Also, are fonts and font rendering much improved?
KDE itself doesn't do any font rendering. So we can't improve it. It's all handled by the freetype library. KDE/qt/GNOME/gtk access freetype through another library called xft2.
> My fonts don't look anti-aliased
Might be a configuration problem, but nothing KDE developers can do about it. Up to the distro maker.
> disturbingly misaligned in some window decorations
Perhaps a problem with the font (improper baseline/ascent/decent) or xft/freetype.
> Furthemore, how about kde-multimedia, can we expect significant improvement or changes in KDE-3.2?
juk is being added in kde 3.2. again, bigger changes will happen in kde 4.0-- perhaps a removal of aRts for something else. It's a long time until then, we'll see :)
> In addition, apart from new integration of tools, new features and bug fixes, are they any major enhancements being made to KDE's fundamental architecture? I'm talking about kdelibs, kparts, dcop and basically any other fundamental rewrites that can make KDE much responsive, much faster and utilize better memory/system resources.
We can't really do much until kde 4.0 in this department except for optimizations. This is because we need to keep binary and wire compatability with KDE 3.0-KDE 3.2.
Of course, there is ongoing work on things like dbus and other freedesktop.org standards.
Hello,
Thanks for your insight. I, like everyone else, look forward to improved versions of KDE. :)
Regards,
Mystilleef
I'm not sure why you say that. I'm thrilled to be using KDE these days, I think it's quite wonderful. I'm sure there are improvements that can be made, but I see it as being quite nice in appearance and functionality. I always look forward to what the KDE folks are doing, but I trust them to do a good job.
Hello,
I'm as thrilled as you are to be a fanatic KDE user. It is simply the best and most powerful Desktop Environment I've used. And I spend every opportunity I get encouraging and commending the KDE devs and community alike. There efforts are much appreciated. However, it is almost an unwritten consensus that KDE needs a user interface update,overhaul, redirection or redesign. Especially with the introduction of Keramic as KDE's default theme. Keramic while initially attractive becomes clunky, bulky, unnatural, somewhat unresponsive and just plain annoying with time.
But the joy of using KDE lies in the power it bestows upon its users. The multifarious options, customizability and configurability empowered me to immediately customize my KDE sytle and window decoration to suit a simple, slim and sleek elegant design(latest version of 'dotNET' for sytle and latest version of 'MKUltra' for windows decoration). After a few tweaks and within a few minutes my windows were much more responsive and a sight to look at.
Contents within widgets are sometimes improperly scaled. An arrow, a picture or a font should fit nicely and naturally within its frame and approximately equidistant from the borders that encapsulate it, regardless of fonts size or type. Only today the directional arrow on Korganisers calender looked oversized for the widget that contained it. Not a big deal, but it is annoyingly distracting and sometimes ruins the pleasant environment KDE kindly spoils you with.
I could go on, but I won't. Once again, KDE is the best desktop environment I've experienced and I genuinely wish it improves as it matures. It is almost 30% faster than XP on my system. And provides me with more tools, choices and tweaks that other desktop environments can only dream off. I simply love it.
Regards,
Mystilleef
Rest assured, it _will_ improve. It improves all the time. I remember running the first beta of 2.0, and I was almost chocked by how slow and buggy it was. Prettier than 1.x, yes, but insanely slow. It improved rapidly, to say the least.
> Can we expect a major UI overhaul in KDE-3.2?
this is really a trickier goal than most people give it credit for. we have people (aka users) who are used to the way KDE is today, and we have many areas that should be improved. how do we maintain enough familiarity that we don't disenfranchise users but still improve? how many person hours will it take to do it right? how much time do we actually have, both in terms of GUI designers/developers/testers and in terms of the patience of our user base? how much real world data do we have to base changes on? how fast can we collect and interpret said data? IMHO the interface will likely evolve at a manageable pace, not go through massive revolutions... this is an elephant we have on our hands, and there's only one sane way to eat such a beast that i know of: one bite at a time. some bites will be bigger than others, but i don't think the project is ready to swallow the whole thing in one go.
Sounds reasonable to me.
Regards,
Mystilleef
Heck, we don't need a major UI haul. I'd be happy with some tweeks and polish:
1) Reducing toolbar and menu clutter. The OS X KOffice screenshots show this clearly. Far too much crap in the default setup, looks especially garish on the otherwise elegant OS X setup. Let's just say this: more apps should look like Quanta and fewer should like like Kivio.
2) More font sensitivity. I have a 133dpi flat panel, and as a result run larger than usual fonts. KDE handles my setup better that pretty much every other GUI (blows away Windows in this department) but still has rough edges. For example, there are several places (menus, kate sidebar) that have non-adjustable 16-pixel icon bars. 16 pixel icons look positively comical on this screen. Many windows will open up with important widgets (okay/cancel buttons) hidden until the window is resized.
3) Adoption of an HIG. Heck, large parts of Apple's HIG are equally applicable to KDE. In fact, KDE has always reminded me a lot of a messy version of classic MacOS. That's a compliment, because getting the little details right is a lot less work then getting the overall paradigm right. I think KDE has the right foundation, but still needs work on that polish.
PS> I'm saying this as someone who uses KDE and only KDE. In fact, I use maybe 3 non-KDE apps regularly, so the progress of development of KDE is rather important to me :)