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."

Comments

Speed and memory consumption

[LLuthor]

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.

Re:Speed and memory consumption

[Nasarius]

The slowness of remote access has absolutely nothing to do with "outperforming the premier Linux desktop". Such things work on a much lower level. VNC does suck compared to RDP, but look at NX.

Re:Stability, ease of use and speed

[Ganniterix]

I don't think that it is a major killer for KDE to be slightly less responsive. I think if linux wants to be taken more seriously by non-geek people, it has to drastically imporve the artwork in the GUI. Even the hard-core developers and internet geeks, as soon as screen shots are out... they hammer down servers to look out for the eye candy. A generic user does not even notice the slightly slower response time, but he will notice if Windows Vista looks better than KDE 4. So ... my two c.. I think KDE is taking a very good direction. Better art-work, means better eye-candy, and more attracting generic users. (I am making an enormous assumption that a generic user will still be able to run popular household applications on the Linux box ...)

Include CVS/SVN stuff in Konqueror!

[ardor]

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.

Re:C?

[Anonymous Coward]

Please not. GTK is horrible. Right now, I am writing some classes that astract the same behaviour for GTK and KDE

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_n ew(),"text", i,NULL);
        break;
            case ListBox::ColumnDef::CheckBox:
        col=gtk_tree_view_column_new_with_attributes
            (cols[i].name.c_str(),ren=gtk_cell_renderer_toggle _new(),"active", i,NULL);
        g_object_set_data(G_OBJECT(ren),columnkey,(void *)i); //Dangerous cast!
        g_signal_connect(ren,"toggled",G_CALLBACK(toggleCh eckBox),this);
        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.