Slashdot Mirror
KDE 4 Promises Large Changes
HatofPig writes "As the dust settles from aKademy 2005, the annual KDE conference, it's a good time to take a look at what the KDE developers are working on. Though KDE 3.5 isn't even out yet, developers are already working on KDE 4. Plenty of work has already gone into porting existing code to Qt4, the GUI toolkit upon which KDE is based, and KDE developers are working on projects that could radically change how the world's most popular free desktop looks and works."
These need to be the main focus of KDE now. There's tons of features but it needs to be faster and more rock solid.
It's a nuisance when Windows Explorer on an average Athlon is slightly more responsive than Linux and KDE on an AMD64 x2. Also Konqueror struggles with some pages, rendering them really slowly.
If there are any KDE devs reading this:
PLEASE PLEASE OPTIMIZE FOR MEMORY USAGE!
Its really sad that Windows with all its services and stuff uses 1/2 the RAM of KDE alone.
LL
In the past, I've successfully made myself a "KDE lite" by getting rid of the biggest resource hog: the desktop and the window manager. OpenBox (At least: version 2, I assume version 3 is just the same) honours the same windowmanager hints, and can (could?) offer a system tray as well.
.xinitrc (or an .xsession, I usually have a symlink from the first to the second), which starts openbox at the end
In a nutshell:
* Make a
* Start docker (The OpenBox system tray replacement), kicker, klipper, and whatever other kde components you want to launch.
Tadaa. Done. KDE-lite.
Surely you're looking for XFCE? I'm not convinced that making the software more "lightweight" is a good argument, that's clearly not what they're aiming for. Although if there's actual structural problems, or bugs, causing the OTT memory usage, yes, those should be dealt with.
Albeit, Slashdot isn't quite the place to be pushing KDE and *nix if you want it to get seen by Joe Sixpack.
Actually, a friend at school was messing around on my laptop, and was amazed with all the stuff that KDE 3.4 could do and it's bundled apps. His jaw dropped at Amarok (auto lyric downloading, Wiki entry on the band, smart playlist, native iPod support, etc.) and was even more amazed when I told him about stuff like K3b's built in DVD ripping, KAudioCreator CD ripping, Kopete supporting all those protocals in one window, and plenty of other stuff. It's worth showing to people.
-Clinton
Silicon & Charybdis McLuhan Kildall Papert Kay
Because, unless I am very much mistaken, it would require that almost all of the project be re-written or thrown away and started on again. You can still have a radical change without having to throw away all of the code that's already been written. Also, they are porting the whole of the KDE project from the Qt3 toolkit to Qt4, since Qt4 is not backward-compatible with Qt3, so in a sense, they are changing the toolkit - but they are porting to one that is very, very similar to the one they use now. ;) What's wrong with Qt anyway that might make you want to port away from it? You might say that it's GPL and not LGPL, which might discourage proprietary developers who don't want to fork out for the alternative license, but that's about it, anything else is really just a matter of preference.
The write-up also seemed rather sparse in details, so while I am writing this post I may as well chuck in a few links:
Interesting interview with Aaron Seigo
Another good interview with Zack Rusin
Official site for KDE Plasma, the KDE4 desktop.
In Windows I use TortoiseCVS/SVN. It absolutely rocks. Using Cervisia after using Tortoise is anything but pleasant. I don't want to offend the Cervisia devs with this, but I would be glad if a new Cervisia release would integrate in Konqueror like Tortoise does with Explorer.
This sig does not contain any SCO code.
And yet the #1 reason lots of other people won't use KDE is because it doesn't work exactly like Windows. The KDE developers are stuck in a catch-22 situation - if KDE resembles Windows in any manner, people flame them for just copying a poor desktop, and if they try and do something new, people flame them for doing things differently to Windows. Either way, they can't win. Even the compromise they have now - default to Windows-like and offer the ability to configure it differently - isn't enough for some people.
Bogtha Bogtha Bogtha
Please not. GTK is horrible. Right now, I am writing some classes that astract the same behaviour for GTK and KDE
n ew(),"text", i,NULL);e _new(),"active", i,NULL); //Dangerous cast!h eckBox),this);
Here is the KDE version for adding the columns to a table widget:
table->insertColumns(0,cols.size());
QStringList names;
for(size_t i=0;isetColumnLabels(names);
Short,nice,readable,whatever you want. If I make a mistake, the compiler will tell me.
Here is the GTK version:
for(size_t i=0;icols.size();i++){
GtkTreeViewColumn *col=0;
GtkCellRenderer *ren;
switch(cols[i].type){
case ListBox::ColumnDef::StaticText:
col=gtk_tree_view_column_new_with_attributes
(cols[i].name.c_str(),ren=gtk_cell_renderer_text_
break;
case ListBox::ColumnDef::CheckBox:
col=gtk_tree_view_column_new_with_attributes
(cols[i].name.c_str(),ren=gtk_cell_renderer_toggl
g_object_set_data(G_OBJECT(ren),columnkey,(void *)i);
g_signal_connect(ren,"toggled",G_CALLBACK(toggleC
break;
}
gtk_tree_view_append_column (treeview,col);
}
It is twice as long, is not type safe, checkboxes won't toggle aunless you add a callback, and the documentation is very twisted: Look at example for "active": "active" gboolean : Read / Write
The toggle state of the button.
Default value: FALSE
If you read that, do you understand that you have to set "active" to the column number of the checkbox column? On the PARENT of the cellrenderer object?
Notice how the KDE version does not mention what the column contains. The GTK version does. In both cases, I have to specify it later, when I set the column data. Why do I need to tell it twice to GTK?
And this is not an unfortunate choice, but the general case. FOr QT/KDE, I read the docs, and I implement. For GTK, I read the docs, delve trough examples until I find something similar, crash atthe first trys because all the casts make compiler typechecking useless, and the resulting code is in general twice as long.
Please, kill the ugly beast that is GTK.
1) is correct, but also pretty ironic, given that there are so much zealots who say exactly this (too much prefs stuff in the control center) and then say "edit bla.conf" when anyone asks how to get sound working (provided the zealots don't quit with a "RTFM"). The advanced options shouldn't disappear completely (like GNOME did). Instead, they should be hidden behind an "Advanced options...." button. For example, the Windows desktop settings behave this way; the most common options are visible immediately, but for editing graphics driver options or setting the monitor refresh rate etc. one has to go to the Advanced Options part.
2) There is already something for GNOME/KDE integration: a GTK theme engine based on Qt. Thus, GTK apps look like Qt/KDE ones. Of course, its only useful if you use KDE...
This sig does not contain any SCO code.
kbear never got into any official KDE release. The instability of the project is full responsability of its author and the project itself seems dead for almost 2 years now.
Why did you have to mix kbear (as any other independent app) with KDE itself? Just because its made for KDE?
Would this mean that if I, eventually, developed a nice calculator for windows that says 2+2=69 instantly Windows would be so buggy that 2+2=69?
And yet the #1 reason lots of other people won't use KDE is because it doesn't work exactly like Windows.
Yes, you have a point there. If you copy something, then any difference to the real thing will be noticed more, the closer you copy. Essentially, you can make a 100% clone, or you can make your own thing, anything inbetween will be perceived as bad.
The way KDE does it, nobody is really happy with it. I figure it's "good enough" for a large share of people, and since many of them are ex-windos users and have grown up to live with "good enough" being all they should ever expect - it kinda works.
5 years ago, there was much hope for the Linux desktop. Today, even I seriously consider buying myself a Mac. And that's after my main machine has been a Linux machine for over 10 years now.
Either way, they can't win.
Learn a lesson from the real leader in computer desktop UI. Copy the Mac or come up with your own alternative. Do things because they are good things and not because windos does them.
Ah crap, I tried convincing the Gnome UI group when it was formed (and I was an early member) and couldn't. Now we have two badly copied windos-like UIs for Linux. And we all pretend to be surprised that it's not making as much progress taking over the desktop world.
Hello? You can't overtake anyone if all you ever do is drive slipstream.
Assorted stuff I do sometimes: Lemuria.org
" What linux needs for the desktop market is an easy to use, and simple desktop."
Yea, it's called Gnome.
Gnome is getting pretty good, but compared to Windows or OS X the point at which the windows-icons-mouse-pointer paradigm falls down still comes much sooner than in Windows or OS X
Linux is nice, and serves me as a Unix zealot quite well for a home desktop, but I still haven't seen a Linux distribution in which it is as easy to install an application as in the mainstream OSes.
"For example, Sometimes, sound on linux can be an absolute bitch to get going."
What does this have to do with the desktop?
I (like most people with computers) have a large collection of music on my computer, because it's so much easier to manage than a giant pile of CDs. Listening to music from one's computer is a common use for desktop machines these days. There's no way in hell a consumer or non-power-user is going to knowingly choose an OS with such weak audio abilities that it can only play one sound at once without the assistance of some program which makes the sound choppy and/or laggy on certain hardware. I have set up dmixer on my computer which should mean that I should be able do away with those awful sound daemons, and some people have those new fangled cards with a hardware mixer, but the obsolete sound daemons have become so entrenched that they're still required for the respective desktop environments and their applications to function properly.
There is no stable ABI for vendors to create hardware drivers to, the ABI is in a constant state of flux along with the rest of the kernel and drivers compiled for a certain version are progressively more unlikely to work with each successive minor version of the kernel. The situation is nearly as bad for open source drivers which need regular maintenance to remain in sync with the audio API. It's no wonder most hardware vendors don't want to touch Linux with a stick.
The situation with sound in Linux is confusing, fragmented and in many ways just plain broken. I don't know what you do with your desktop, but it's obviously not typical if you don't consider sound to be important.
"The point is, that as long as simple issues like playing a video become mammoth tasks,"
What does this have to do with the desktop?
You don't suppose all those millions of ATA DVD drives being sold are finding their way into servers do you?
Wake up Buck, you've arrived in the 21st century. Playing videos and listening to sounds is actually commonplace nowadays, in fact a nice screen for playing videos was why I chose a midsize laptop instead of a subnotebook, and last I looked there are increasing numbers of wide screens coming onto the market. I'm pretty sure sales of wide screen laptops and monitors isn't booming because of people wanting to put 6 xterms on screen at once.
None of your complaints have anything to do with the desktop. You are wanting applications and drivers.
None of his complaints have very much to do with the GUI but they are certainly related to the experience of trying to use a Linux machine as a desktop operating system.
Few people (except those like me whose brains seem to be running some variant of Unix in muscle memory) are going to choose a desktop that limits their computers abilities. Everything seems pretty straightforward to me and I feel empowered rather than limited by Linux, but I'm a wee bit of a nerd and few of my non-nerd friends who've sampled Linux have kept at it even with remote tech support at their bidding.
You are right with aRts. Unfortunately, there are little alternatives. esd has serious sync problems (just ask the Ubuntu devs). dmix is nowhere near stable. I hope something better comes, like a new sound daemon, or a stable dmix.
:) ). What I would like to see: for example, User X gets a MPEG-4 AVI. gstreamer doesn't know how to handle this, so it starts to look for a codec with the matching FOURCC. It doesn't find one. Result: gstreamer-based Kaffeine shows a message box "couldn't play video because playback software is missing." And then, under "Details": "no installed codec is able to play video with the FOURCC 'DIVX'." Yes, thats Kaffeine and not KDE itself, but Kaffeine is often bundled with KDE desktops, so this setup would be very nice.
About streaming capabilities: a desktop absolutely NEEDS a multimedia infrastructure like gstreamer. OK, its not KDEs job to install it, nor handling the infrastructe (after all, gstreamer already exists). It doesn't even have to be an integral part of the desktop.
But what is actually needed? A way to configure the damn thing! I mean something like an easy way to change the sources & sinks with the control center, having a list of all installed codecs, maybe with an "Install new codec" button for easy install and so on. This would actually be a BIG advantage of a Linux desktop over Windows, since DirectShow isn't easy to configure, and if it gets messed up with broken codecs, you better get prepared for a full Windows reinstall. gstreamer is in many ways better than DirectShow (except seeking, this works more reliable with DShow), so we shouldn't miss the chance of using this advantage.
In a Nutshell: KDE shouldn't require gstreamer, but it should include optional support, with autodetection for gstreamer presence, thus enabling all gstreamer-related stuff when its there.
Why gstreamer? Why not xine or mplayer? gxine is very nice, and xine-based Kaffeine rocks, yeah. But there are legal problems. Anybody remembers the MPEG-4 license problems? gstreamer is much safer, since the plugins can be binary, closed-source (useful! for example, DivX could exist as a binary codec, and Cyberlink could create a DVD decoder - finally, watching DVDs without cracking them).
The problem with most package managers is that its not easy to find out what codecs are needed. Hell, most users don't even know what a codec is. In Windows, the media player automatically tries to download a suitable codec, and if there isn't any, it prints out an error message (which is not very helpful
This sig does not contain any SCO code.