Why does KDE work so well? Benjamin Meyer thinks he knows why, and he explains his thoughts in this Tribute to KDE. Benjamin is the lead developer of Kaim (screenshots), and has been working hard at porting this application from being Qt-only to a fully-fledged KDE application. In doing so, he has come in contact with the KDE development community and processes. Benjamin's experiences have led him to conclude that KDE's CVS culture, release strategy, and focus on consistency lead to polished, mature applications.
Dot Categories:
Comments
> Still not as fast as Qt for a C++ programmer.
> And that's just a one-time handicap. The big
> difference comes in the long run, when actually
> using them.
To be honest, it took me much longer to learn QT than GTK+ (and I'm still learning).
And yes, I'm telling you the truth.
> After you had learn GTK+ itself, right ?
> Honestly, how many classes are defined in your
> current project ?
(???????????????????)
And one has to learn C++ because he/she can use classes or QT.
What's your point?
> And you are still wrong, although that's less of an issue.
What about Delphi classes then?
A TComponent is large yet nobody complains about it and happily continues to do RAD.
you want multiple inheritance if you want a class to be a child of two parents. That situation happens a lot
imagine you have an object you have to register in some list, and therefore it should inherit the foo class. but you also want it to have to be a bar (for similar or other reasons), so you also want to inherit from the bar class.
. i am a beginning c++ programmer, just learned about mult. inh. (for dcop objects that also have to be widgets, otherwise you have to make two objects with almost the same interface.) , and i can say i encountered a lot of situations before where i could have used mult. inh. but i did not because i did not know it could be done in c++.
maybe you can do similar things with interfaces ...
At 66 to 75 characters C wins, although if you leave out ".h" and "std::" C++ is only 68 (why does the word iostream have to be so dang long!?).
You can't leave out "std::" (well with g++ you currently can but that won't last), unless you add "using namespace std" before referring to cout :-).
Are you sure?
Why don't you check this comparative?
and you will know which one use more code..
Ramiro
It is less efficient when coding. But the final result will be just as efficient as any code "real" OOP languages produce.
The ONLY efficiency in programming is the programmer's efficiency. And by "programmer" I mean all those people who write, modify, add to, and especially, maintain, the program. Who cares how many cycles a program shaves off of execution when few people can maintain it?
You know, it's possible to write object-oriented programs using assembler. So why isn't anyone doing it? Surely OOP in assembler must be extremely efficient...
inheriting from a gtk widget:
#ifndef __GTK_DIAL_H__
#define __GTK_DIAL_H__
#include
#include
#include
#ifdef __cplusplus
extern "C" {
#endif /* __cplusplus */
#define GTK_DIAL(obj) GTK_CHECK_CAST obj, gtk_dial_get_type (), GtkDial)
#define GTK_DIAL_CLASS(klass) TK_CHECK_CLASS_CAST (klass, gtk_dial_get_type (), GtkDialClass)
#define GTK_IS_DIAL(obj) GTK_CHECK_TYPE obj, gtk_dial_get_type ())
typedef struct _GtkDial GtkDial;
typedef struct _GtkDialClass GtkDialClass; struct _GtkDial
{
GtkWidget widget; /* update policy (GTK_UPDATE_[CONTINUOUS/DELAYED/DISCONTINUOUS]) */
guint policy : 2; /* Button currently pressed or 0 if none */
guint8 button; /* Dimensions of dial components */
gint radius;
gint pointer_width; /* ID of update timer, or 0 if none */
guint32 timer; /* Current angle */
gfloat angle; /* Old values from adjustment stored so we know when something changes */
gfloat old_value;
gfloat old_lower;
gfloat old_upper; /* The adjustment object that stores the data for this dial */
GtkAdjustment *adjustment;
};
struct _GtkDialClass
{
GtkWidgetClass parent_class;
};
GtkWidget* gtk_dial_new(GtkAdjustment *adjustment);
guint gtk_dial_get_type(void);
GtkAdjustment* gtk_dial_get_adjustment(GtkDial *dial);
void gtk_dial_set_update_policy(GtkDial , dial,GtkUpdateType policy); void gtk_dial_set_adjustment (GtkDial dial, GtkAdjustment *adjustment);
#ifdef __cplusplus
}
#endif /* __cplusplus */
#endif /* __GTK_DIAL_H__ */
#include
#include
#include
#include #include "gtkdial.h" #define SCROLL_DELAY_LENGTH 300
#define DIAL_DEFAULT_SIZE 100
/* Local data */
static GtkWidgetClass *parent_class = NULL; guint
gtk_dial_get_type ()
{
static guint dial_type = 0; if (!dial_type)
{
GtkTypeInfo dial_info =
{
"GtkDial",
sizeof (GtkDial),
sizeof (GtkDialClass),
(GtkClassInitFunc) gtk_dial_class_init,
(GtkObjectInitFunc) gtk_dial_init,
(GtkArgSetFunc) NULL,
(GtkArgGetFunc) NULL,
}; dial_type = gtk_type_unique (gtk_widget_get_type (), &dial_info);
} return dial_type;
} static void
gtk_dial_class_init (GtkDialClass *class)
{
GtkObjectClass *object_class;
GtkWidgetClass *widget_class; object_class = (GtkObjectClass*) class;
widget_class = (GtkWidgetClass*) class; parent_class = gtk_type_class (gtk_widget_get_type ());
object_class->destroy = gtk_dial_destroy; widget_class->realize = gtk_dial_realize;
widget_class->expose_event = gtk_dial_expose;
widget_class->size_request = gtk_dial_size_request;
widget_class->size_allocate = gtk_dial_size_allocate;
widget_class->button_press_event = gtk_dial_button_press;
widget_class->button_release_event = gtk_dial_button_release;
widget_class->motion_notify_event = gtk_dial_motion_notify;
}
static void gtk_dial_init (GtkDial *dial)
{
...
--------------------------
Inheriting a widget with Qt:
class QDial: QWidget
{
QDial(QWidget * parent): QWidget(parent)
{
...
=========================
I see a difference!
I do not invent this, this is pasted from the tutorial of gtk:
http://www.gtk.org/tutorial/sec-creatingawidgetfromscratch.html
When you see this amount of code necessary in gtk to handle the OOP, you understand that:
- a gtk programmer spends lot of time on doing unuseful things (inheritance in C instead of just C++)
- a gtk programmer needs to get this complicated stuff right
- the C compiler can't check the OO things, you rely on the programmer
- a lot of things that should be automatic are left to the programmer
> In fact: writing small programs in GTK+ needs less code than QT.
this is not true.
I am writing an article about this that should be ready in a few month to prove it.
> Creating GTK+ objects takes more time,
Yes, two hours to write the code where 5 lines of C++ will do it. Are you going to tell me that usually, you don't create objects ?
> but Gob can make it as simple as C++.
What is Gob ?
A gtk object generator ?
The only thing gtk is really good at is wrapping.
Because it is C, it is easy to wrap a gtk and program with a _good_ language (good in the sense of suited to the task).
> Are you going to tell me that usually, you don't create objects ?
I doubt he would, but yet that's most probably the case. A typical GTK+ program has only a handful of huge classes. A C++ program can exercise the OO paradigm much better.
> What is Gob ?
GTK+ Object Builder
http://www.5z.com/jirka/gob.html
> Because it is C, it is easy to wrap a gtk and program with a _good_ language
Not even :-). OK, it's probably true with scripting languages like Python.
I just copy and paste things from a template and rename some things...
> Yes, two hours to write the code where 5 lines of
> C++ will do it. Are you going to tell me that usually,
> you don't create objects ?
I only create objects for large programs.
But GTK+ doesn't require you to inherid things.
Ever heard of copy and paste?
Renaming things takes less than 3 minutes.
In fact, all the objects I write never look as messy as that code above.
They have newlines and identications.
If you write C++ code without newlines and identications it will look messy and unmaintainable too.
> I only create objects for large programs.
And in C++ you can create some whenever you want. You have no idea how far tiny helper classes can get you.
> But GTK+ doesn't require you to inherid things.
Yes it does, you have to inherit GtkObject.
> Ever heard of copy and paste?
> Renaming things takes less than 3 minutes.
This is becoming hilarious. :-)
> In fact, all the objects I write never look as messy as that code above.
> They have newlines and identications.
Riiight.
When it comes to this point of denial I think we can end this thread.
> Yes it does, you have to inherit GtkObject.
No it doesn't.
GtkWidget *win;
win = gtk_window_new (GTK_WINDOW_TOPLEVEL);
gtk_window_show (win);
And voila: a window without inheriting an object.
> Riiight.
> When it comes to this point of denial I think
> we can end this thread.
You don't agree? Remove the idents and newlines from your C++ code and see what it will look like!
> No it doesn't.
Helloooo, we're talking about how to create a new class here. Not instantiate an object.
> You don't agree? Remove the idents and newlines from your C++ code and see what it will look like!
ROTFL. Yes, absolutely, you're right, anything it takes to end this thread. Yes, you're using a great tool. There.
> Helloooo, we're talking about how to create a
> new class here. Not instantiate an object.
And I was talking about instantiate an object, noy about how to derive a class. :)
Now I *really* wish I could see the look on the face of someone who, having read the whole thread, stumbles on this final statement of yours.
Something like this? o_0
BTW, a lot of the above code is not neccesary.
#include
#include
#include
Completely useless. Can be replaced with:
#include
or
#include
#ifdef __cplusplus
extern "C" {
#endif /* __cplusplus */
Only useful in C libraries. Useless in programs.
guint policy : 2; /* Button currently pressed or 0 if none */
guint8 button; /* Dimensions of dial components */
gint radius;
gint pointer_width; /* ID of update timer, or 0 if none */
guint32 timer; /* Current angle */
gfloat angle; /* Old values from adjustment stored so we know when something changes */
gfloat old_value;
gfloat old_lower;
gfloat old_upper; /* The adjustment object that stores the data for this dial */
GtkAdjustment *adjustment;
You forgot to include these fields in your C++ class.
These fields have nothing to do with inheritance, but the internals of the widget.
GtkAdjustment* gtk_dial_get_adjustment(GtkDial *dial);
void gtk_dial_set_update_policy(GtkDial , dial,GtkUpdateType policy); void gtk_dial_set_adjustment (GtkDial dial, GtkAdjustment *adjustment);
Idem dito.
#include
#include
#include
Useless.
#include does it all.
I do not pretend the above gtk code was optimised to be small, nor that the kde code is an exact equivalent. But it gives the general idea of what gtk vs kde programming is.
There were some problem of copy/paste, this is why the code is not properly indented. The original looks better, as you can check with the url.
About copy/pasting code, don't you know that it is dangerous ? Especially in gtk where the compiler can't check anything. If you get one struct wrong, I guess the whole code is fucked-up. True ?
Also, you need to realise that what I have just copied in the previous message is _the official gtk tutorial_. This is what people are faced with when they want to learn gtk.
If you think the above code is not good, then correct the tutorial. You tell me about gob, but there is no mention of gob in the tutorial. If I want to program in gtk, I will produce code like that because this is what this tutorial told me.
Compare with Qt: the tutorial can be done in 2 days. A new C++ programmer should have no problem producing a qt application in one week. Qt has only one new concept, signal and slots, which is easy learned. The remaining of Qt is so clean that it could be the basis of an OO lesson.
The same goes for the kde tutorial.
The tutorial of gtk is very long, you need probably more than one week to finish it. No C beginner can do it. There are lot of concepts in here to understand. You need to understand the OO abstraction, there are references to XWindow, there are many macros you are afraid to understand how they work, you must supply by hand a lot of information and there are many things you just do but don't understand.
I wonder why there are that many gtk application out there when I read this.
An intersting shot would be to take the Qt tutorial and examples, and to rewrite them in gtk. Then compare the results in terms of ease of read, ease of programming, source size, ...
I am doing exactly this right now with gtk and I am having a lot of fun.
Notice also that except for the gimp and perhaps nautilus, there are very few ambitious project written from scratch in gtk.
This is very different from kde where you have some very ambitious projects, most of them written from scratch, that can compete (and even sometimes beat) gnome projects. And they are done by very few developers (we didn't waste 13 million $ in a filemanager!).
Ask yourself why!
> About copy/pasting code, don't you know that it
> is dangerous ? Especially in gtk where the
> compiler can't check anything. If you get one
> struct wrong, I guess the whole code is fucked
> up. True ?
Yes, I realize that. But I know exactly what to rename.
Even though the compiler doesn't check anything, Gtk+ will.
It will give warnings like "WARNING: class FooBar is smaller than it's parent" and then you know you did something wrong.
> Also, you need to realise that what I have just
> copied in the previous message is _the official
> gtk tutorial_. This is what people are faced
> with when they want to learn gtk.
I know that. And that's one of the reasons why idents and newlines are so important.
> If you think the above code is not good, then
> correct the tutorial.
I never said that. I only said it looks messy because it lacks newlines and idents.
> You tell me about gob,
> but there is no mention of gob in the tutorial.
Of course not. Gob is relatively new and the tutorial is outdated.
And Gob is not part of GTK+.
> Qt has only one new concept, signal and slots,
> which is easy learned. The remaining of Qt is
> so clean that it could be the basis of an OO
> lesson.
I learned GTK+' signal system quite easily you know.
And I still don't see much difference between GTK+ signals, QT Signals and Delphi Events.
> No C beginner can do it.
I did.
> I wonder why there are that many gtk
> application out there when I read this.
And I wonder why there are so many QT programs out there when I read the tutorial.
It took me days to find out that I need moc to be able to create QT classes.
And I still have to find out how signal slots work.
> This is very different from kde where you have
> some very ambitious projects, most of them
> written from scratch, that can compete (and
> even sometimes beat) gnome projects.
The opposite is also true. Some Gnome projects can compete/beat KDE projects.
And both can compete/beat Windows and MacOS software and FooBar 2.0 in l33t mode with the flying turtles.
> And they
> are done by very few developers (we didn't
> waste 13 million $ in a filemanager!).
Eazel spend 13 million $ for the sake of Nautilus and GNOME.
That's a deed that shows their kindness and good faith.
And now you're bitching about it? C'mon!
Just for the record :
> Completely useless. Can be replaced with:
> #include
> or
> #include
and drive up your compile times through the roof.
This is explicitly advised against (even in C++ :-).
We're waiting for gcc 3.0 with pre-compiled headers...
AFAIK they are scheduled for 3.1 or later, not 3.0.
AAAAAARRRGHHHH!!!!
(*falls down a big, black hole*)
... compared to ObjC.
ObjectiveC = C with about 5 other things to learn it is a simple powerful language with way more flexible approach to OO than C++, no gigantic templates, and simple easy to maintain code. GNUStep is a framework built out of ObjC and it is very high quality.
ObjC is why basically 4 people working part time have been able to create GNUStep with **NO** corporate backing (no Trolltech or Redhat or foundation to underwrite things). Before either KDE or GNOME people gloat too much they should go and READ some of the GNUStep code. Like the workspace manager - sure it's alpha and not that functional: **ONE** guy maintains it in his spare time. Please note how FEW lines of code are in it as well. Before you complain about lack of documentation READ the code. No C Java or C++ developper can honestly say that they can't understand ObjC after 5 minutes.
Oh and whipdeedoo on the cross platform stuff, GNUStep has run on a half dozen Unix platforms, Windows, MacOSX, and OpenStep for years now. It's also got a bridge to Java, and Guile and there's and ObjC<->Python project too ... This is all with fewer developpers than there are female senior citizens on the KDE mailing list.
You say because GNUStep can create a DE with fewer developers ObjectiveC is better than C++. But you ignore that KDE is much more than just a bare DE. It has a browser, mail klient, media players, music creating applications, network transparent sound server, many games, ...
(By the way, shouldn't KDE use K or K++ instead? :-)
Yes, ObjC is a very nice language. I played with it a few years ago. I even added regexp support to GnuStep string class.
Unfortunately, ObjC is also completely dead, which is quite a shame. And speaking of overhead, it also has quite a lot. But you're right, there's no question it beats C++ hands down as far as ease of use is concerned. The OO model is also quite powerful.
I'm working on Objective-C bindings for Qt/KDE, and I'll try and get them done in time for KDE 2.2. I think KDE and the GNUStep Foundation Kit should make a good combination. Quite a lot of the really good stuff in GNUStep is in the Foundation kit, as opposed to the Appkit side. I don't think Objective-C is dead because it is now the native language of Mac OS X, and Apple have at least one full time maintainer, making sure it doesn't die on them :-).
-- Richard
hmm... moz is C++. sorry, but bzzzt.
So is M$ stuff, for that matter (with MFC though, which hardly counts) :-).
and the linux kernel is C and rock-solid.
actually, most things at microsoft are written in C. only more recent projects have been done with C++. Windows is C.
Do you want to write an OS instead in this well structured, coordinated, single-distributed form. Then you should run, not walk over to www.FreeBSD.org and start contributing.
Yeah I agree with you but what's the starting point for newbies.
There is a lot of OS design book but few of books how to implement that design.
Really I agree with you, there are a lot of OS design books, which teach you lot about scheduling and interprocess communication and the like, but
they never get down to explaining how to really code one.
I am also deeply interested in making an OS. Will you and anybody reading this help me in any way you can.
By the way, if you want to get a list of interrupts for the PC, I think
one should visit
http://www.pobox.com/~ralf
I suggest you read Tannenbaum's book, which not only talks about the details of implementing an OS (Minix) but actually does it and includes the source code. You should also not that Ralf Brown's interupt list is mainly about software interupts (ie. DOS system calls) and almost totally useless to anyone trying to write an OS of their own.
Rich.
send me sample code,books,tools,documets regading writing an OS