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.
It'll be like a second Christmas!
Silicon & Charybdis McLuhan Kildall Papert Kay
What linux needs for the desktop market is an easy to use, and simple desktop. The problem with this on current installs is the lack of communication between desktop and kernel etc.
:|
For example, Sometimes, sound on linux can be an absolute bitch to get going. Even something as trivial as playing an AVI caused me *way* too much drama. Not that I couldn't get it to work, but then if I wanted sound to work with other things, I need to use a sound daemon. Fair enough, thats not too hard - but then the audio/video sync was out because of the latency in the sound daemon.
The point is, that as long as simple issues like playing a video become mammoth tasks, then the average person will just stick with something simpler. Hell, 90% of the time I can just install Windows and everything will work right out of the box.
This is what needs to be worked on. While all the technical side of things on Linux just rocks, I doubt that many people have worked on the 'end user experiance' because at the moment, it just sucks.
There is a reason Apple is gaining market share - as well as mind share - and it's the OS that does it. I can do the majority of things I can do on a linux system (console and X side), and have a nice, pretty and *FUNCTIONAL* GUI for everything else. The end user experiance is second to none. This is what Linux should be looking at - not making 'sweeping changes' that you still need to spend a week on getting to run just right
Sendmail is like emacs: A nice operating system, but missing an editor and a MTA.
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.
Just getting bigger not better is my first impression. My PC is often faster and more responsive under W2K then under Suse/KDE. It only can get worse with even more gimmicks.
I guess the acid test for KDE 4 (as for KDE 3) will be KBear, then - the strangely named fpt client with the strange user interface that seems to come with each release whether you want it or not.
Will it run this time? Or will it revert to its lovable self and crash shortly after starting up, taking the kicker down with it?
Madames et Messieurs, faites vos jeux!
Las qué passoun
tournoun pas maï
KDE has C bindings which are just a wrapper around the C++ interface, which accomplishes the same thing as what you're suggesting. Guess what, no-one uses them, because C++ is far nicer to program in than C. If you really want to, you can program a KDE application in C. On the saner side the API also has bindings for perl, python and java, and probably more.
I am trolling
Man have you seen a real new user try to use a windows installation package. They get to about the second or third next and freeze... You would be suprised at how many times I get asked to do this task or how many (real) mum and dad users don't install because it is too complicated. The interface for most Linux installers is way too intimidating.. I use synaptic and its great for experts but I would not put in front of a new user. From an interface perspective its hard to go past klik (or the MacOSX disk image packages) It is a very promising technology that I am sure will catch on in the near future. Also the Khotstuff mentioned in the article is very cool... As for QuakeIII: I seriously don't remember having to do any of this when I installed Quake3... Except for making the installer executable. But you have identified a few key issues. I would go a little further and say what is natural and easy to Windows users is definately not what regular people concider easy and natural. Its probably easier and more natural than linux but it is not easy and natural by any stretch of the imagination. It's something that most users have difficulty realising you were taught windows at school or from friends. Yes I am a linux zealot. I also take teach people who have had NO contact with computers before.
In other words, if you want to prevent Linux marketshare from dropping to below 1%, make it as unusable as possible.
I don't quite understand why this should work, but hey, I've got some great ideas on how to decrease the usability of Linux!
The Tao of math: The numbers you can count are not the real numbers.
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
That would be unbelievably stupid. Gnome is in the middle of culture wars over trying to move into this century's technology - either Java or C#/mono, because most on the project realize how high the costs of sticking with C are.
2) Work with GNOME, Trolltech and Free Desktop and produce a common widget theme engine. I don't care if an app runs QT or GTK, I don't care if it's part of KDE or GNOME. I do care that the average Linux desktop looks severely schizophrenic and unpredictable from one app to the next.
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.
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
You're right in general that Qt is higher-level than GTK+, since Qt is a C++ API. Of course this has disadvantages too; for example language bindings for Qt are much harder. Gtkmm is worth a look: it's at the same level at Qt (in terms of abstration), but doesn't need MOC. And it plays nice with the STL too.
... would load a Commodore 64 binary file named SIG from device 8, the first 1541 drive.
Completely non-portable, you insensitive clod. Still, those of us reading Slashdot from a C64 might be tempted to load and run your binary SIG, thus potentially spreading a virus.
At least you could do:
10 DOPEN#1,"SIG"
20 INPUT#1,S$
30 DCLOSE#1
40 PRINT S$
Just as non-portable, but would actually work and not cause a security nightmare from running untrusted binaries. We 64 users have enough trouble with CSS not to have security issues on top of everything else.
sigs, as if you care.
Well that's not quite fair. At the same time, you're also comparing two different programming languages.
If you want to compare c++ interface with c++ interface, you could look at gtkmm.
Malike Bamiyi wanted my assistance.
- Comment 1
- Comment 2
- Comment 3
- Comment 4
- Comment 5
- Comment 6
The guy is called ClintJCL: one of his posts. You can find the same post in his blog, but he says, that he just copied it fromThe problem here isn't Gtk+. It's C.
And you cheated by writing the Qt example in C++, but the Gtk+ example in C. If you want to make them equal, write the Qt example in C, too -- oh, wait, you can't even use Qt from C!
Everybody I know writing GUI apps uses a higher-level language. Why you'd write a GUI app in C or C++ is beyond me.
Take Python, for example. Try writing the same code in PyQt and PyGTK -- both of which are very popular for writing apps these days. PyGTK is very Pythonic; PyQt requires you to write C++ method signatures to bind any events.
The first step in writing a program is to write it at the appropriate abstraction level. Writing a GUI app in C is just dumb; use something like Python. Of course, the Qt folks seem to think C++ is correct for *everything*, so even if you use Python you have to use C++.
Gtk+: You can use any programming language you want, and it feels like a native library anywhere.
Qt: You can use any programming language you want, except C, and it feels like a C++ library anywhere.