Slashdot Log In
Guillaume Laurent On GTK And The New Inti
Posted by
Hemos
on Thu Aug 10, 2000 07:03 AM
from the good-times-bad-times dept.
from the good-times-bad-times dept.
KS writes: "Old time GNOME hacker and Slashdot familiar Guillaume Laurent has finally written up an explanation on why he left the GTK-- project. In summary, he disagrees with some of the fundamental features of GTK-- but sees a bright future for Red Hat's Inti. I don't know why but I always find these sorts of things eye opening." Update: 08/10 02:50 PM by H :Guillaume wrote me asking me to mention the an update to the story.
This discussion has been archived.
No new comments can be posted.
Guillaume Laurent On GTK And The New Inti
|
Log In/Create an Account
| Top
| 149 comments
(Spill at 50!) | Index Only
| Search Discussion
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
(1)
|
2
(1)
|
2
I completely agree... (Score:5)
#include <objgtk.h>
class MainWin : public Window
{
public:
MainWin();
gint OnDeleteEvent(void);
void OnHelloButtonClicked(void);
private:
Button *hello_button;
};
MainWin::MainWin()
{
SetupTable(3, 3);
SetTitle("Hello, World");
SetUSize(300, 150);
SetPosition(GTK_WIN_POS_CENTER);
hello_button = new Button("Hello!");
hello_button->ConnectClicked(CALLBACK(OnHelloButt
Add(hello_button, 1, 2, 1, 2);
}
gint MainWin::OnDeleteEvent(void)
{
OG_Quit();
return FALSE;
}
void MainWin::OnHelloButtonClicked(void)
{
g_message("Hello!");
}
int main(int argc, char *argv[])
{
OG_Init(&argc, &argv);
MainWin *mainwin = new MainWin;
mainwin->Show();
OG_Main();
return(0);
}
Anyway, as soon as this got on Freshmeat, I received some responses (a first!), some encouraging (including some w/ patches, etc.), and one from Karl admonishing me for duplicating his work and urging me to give up ObjGTK and join the Gtk-- project. Now, Karl was very courteous and he did have some points -- a lot of my complaints were really stylistic issues which could presumably be fixed, and Gtk-- had some features which I could not easily duplicate (at the time they were starting to adopt libsigc++, which Guillaume apparently thinks is badly written, but regardless was a very useful idea which worked perfectly in this context. They also had the aforementioned stack-heap duality, whereas all my widgets were on the heap. The implementation of this was so awful I can barely describe it, let alone duplicate it). ObjGTK, although it was fully documented and somewhat useful, was incomplete (hey, I had only been working on it for two weeks), and Gtk-- had classes for almost every GTK+ type and then some. And so after a few such e-mails, I removed ObjGTK from the net and subscribed to the Gtk-- mailing list.
At this point my C++-wrapper development in Linux was pretty much over. I observed the mailing list for a couple of weeks, decided that the first thing I wanted to do was work on the documentation (at this point Gtk-- had no reference documentation and a couple of short programs acting as a tutorial), and quickly foundered. The source was very hard to work through. The headers seemed to be in three places at once, and the methods themselves were sometimes designed so circumlocutiously that it was almost impossible to tell what they did. It was hard to separate the "real" code which I was supposed to be writing from the code which was auto-generated from the GTK+ header files. And, my naive intentions of "fixing" the style issues were undoable; Gtk--'s conventions were simply too deeply rooted and too at-odds with my "simple"
style of programming.
My last run-in with Linux GUI programming was when I had the urge to continue working with an old program which had a GUI interface. I had originally written it in GTK+, then ported it to ObjGTK+ as a test of the latter's capabilities. Now since ObjGTK was dead, I figured the next logical step would be to re-write it in Gtk--. I downloaded the latest libsigc++ and libgtkmm, and got cracking. The first thing I started to write was the toolbar code. I scanned the Gtk-- documentation, found some methods which seemed appropriate, and started writing. It didn't compile because the methods didn't seem to exist. Flummoxed, I sent a message to the Gtk-- mailing list, and recieved a reply from Karl stating that yes, those methods didn't exist anymore, and giving me an example of the "better" way to write toolbar code, which was basically about 50 lines of horrible template code (in contrast to 40 or so lines of GTK+ code, or 20 of ObjGTK).
That was the last straw for me...not because of the bad documentation or the weird style standards, but because of how much this situation reminded me of the chapter in the "UNIX Hater's Handbook" where the UNIX style (make it easy to program) was contrasted with the Lisp style (make it easy to use). In my mind, Karl had become too obsessed with keeping to his academic theoretical perfection, and had disregarded the thing which make an API worthwhile, namely usability.
Looking back I suppose one could see Gtk-- as a shame, a deplorable situation that should never have happened. Personally, I disagree. When I worked with QT, I found it easy to use but I thought their pre-processor approach was terrible. Libsigc++ was a much more elegant solution to the problem which we have Karl to thank for. Likewise, I heavily disagree with another poster here who claimed that pointers are better than references. Pointers create unsafe interfaces, whereas with a reference you are always guaranteed to be passing an object which actually exists. ObjGTK+ used pointers exclusively, and if I re-did it today I would definitely change that.
I look forward to working with Inti; from the descriptions I've read it sounds like a good balance. I'm glad that it's there now since I no longer have the kind of free time I had in college to work on Open Source projects. Maybe soon I'll reorganize my schedule, subscribe to the Inti mailing list and start pestering them with stylistic issues
-W.W.
Re:Reinventing QT ... (Score:3)
Two wrongs don't make a right - and this is two wrongs. We don't want KDE dead and we have no reason to take revenge on KDE.
Red Hat spent a lot of money in the early days rolling out a proprietary CDE release that was supposed to be their cash cow.
Sorry, but this isn't true. Proprietary software is not and has never been a major part in Red Hat's business plans.
At that time, there was no free and good user interface available, CDE was a kind of standard, so it got included, because a proprietary solution seemed to be better than no solution at all. We're glad that this is no longer necessary.
They had it all positioned, along with ApplixWare, etc
If we bought ApplixWare, somebody forgot to tell me.
to take over the Linux market
If that was our intention, why would we GPL our installers and permit distributions to just copy Red Hat Linux and add/remove/change some stuff?
Can't be about acceptance - SuSE don't GPL their installer and yet they're widely accepted.
If you had had a look at Red Hat Linux in the last couple of years, you would have noticed that we aren't including any proprietary software with the exception of Netscape (because it's important and there's no good free replacement, though Konqueror and Mozilla are getting there).
We don't want proprietary software.
Along came KDE and Lesstif, which drew all the energy away from the closed-source stuff that Red Hat had and all the shrinkwrapped boxes printed up for at great cost. Red Hat ended up taking a bath as result, out of reaction they hyped up Gnome as a counter-attack.
Entirely untrue. Red Hat chose to support Gnome because of Qt (1.x)'s restrictive license. The Qt 2.x license is not a problem, the old license was.
By the time Qt 2.0 was released and the license problem was fixed, Gnome was already usable and at a point where simply dumping it wouldn't have made sense. (Yes, I personally still prefer KDE, but Gnome isn't bad, and it would be a pity to see it go.).
Next time, please take the time to check the facts before posting.
Re:Reinventing QT ... (Score:3)
Such as? We aren't perfect, but we're trying.
Red Hat will not be happy until it owns the Linux market. Not just in the sense of most market share, but they want all market share.
Entirely untrue.
We'd be stupid if we wanted that, even from a pure business point of view (hey, all those people being paid by Mandrake, SuSE, Caldera and all are FREE developers for us!).
Similarily, why would we GPL all our developments if we wanted to shut everyone else out?
they would have been better off to try to create some great Windows rip off. Then they could make it proprietary.
We could make our installer proprietary. Do we?
We could have made rpm proprietary. Do we?
The day Red Hat starts making proprietary software without a good reason (such as having to do NDAs to be able to get a solution at all, which is bad, but the lesser of 2 evils with the alternative being forcing users on Windoze), I'm out of here, and so are a number of other developers. It won't happen.
FLTK (Score:4)
Qt was pretty good - close second, but it's not LGPL and you need to pay for the windows version.
Fltk is just cleaner. MFC was the worst, closely followed by swing.
C++ (Score:3)
On a related note, using C for GTK+ was driven by more than just a love of C. It was also a practical decision because it makes it easier to use GTK with other non C programming languages, such as perl, or TCL. The only major criticism I'd have was that they didn't write a GTK-- style system simultaneously. However, I don't really care about that since I prefer my GTK+ straight anyway.
A zillion one-man projects... (Score:3)
Which means free software programmers should think very hard before staring their own project. Is your own better design ideas really so much better, that they outweight the advantage of sharing the work with other programmers in an existing project? And don't overestimate your own programmimng ability, like most programmers do.
Sometimes the answer is yes. This might be one of them. But most times, it is not.
Re:inti type safety.. (Score:4)
No.
Looking at the headers available at http://sources.redhat.com/inti/inti-manual/ [redhat.com] I see that each class member representing a signal is a SignalProxy, which seems to be quite like the signalling facilities provided by libsigc++. Looking at the definitition of SignalProxy, its connect method is parameterized for both the type of the signalled object and the member being connected to.
--
"Where, where is the town? Now, it's nothing but flowers!"
Re:FLTK (Score:3)
Not sure what it is, perhaps the JX toolkit?
Re:Reinventing QT ... (Score:3)
Redhat releases all of their software GPL. TriTeal and CDE date to before there were ANY desktop environments for Linux, beyond FVWM.
RedHat didn't include KDE/QT until the licensing was sorted out, because they support the GPL.
---- ----
Happily insane (Score:3)
If by your remark you intended to imply and mean that programming in C (as opposed to C++) is insane, then fine, I am Happily insane.
I learned C programming not from the books (though I had both K&R and H&S handy as references to look up stuff) but from actually diving in and doing it. Having started in 1982, I've had quite a bit of time to progress to the point I am today with C programming skills. I also had the foundation of several years of assembly programming before then.
I did not learn C from the books. I didn't read them. They didn't make sense the way they were written. Obviously they were not written for me, a very experienced programmer from the mainframe legacy with already several languages of experience. Those books appeared to be written for someone somewhere between "newbie" and "academic". They were not written for a working programmer.
I have yet to find any programming book for any programming language which is written for an audience with specific experiences to draw on, and specific questions that need to be answered about the new language. I was lucky with C because it became quite clear with a few experiments with pointers, and dumping the generated assembly code, and testing out some kernel calls (in TOPS-20 at the time), that C was just "portable assembly code". Neither K&R nor H&S explained things that way. Nor has any other book explained the basis and concepts of their language in terms all experienced programmers could catch on to quicky.
Learning a new language by the book is for newbies only!
Now how does this affect C++? Unlike my relation between assembly and C, C++ has no already existant basis to learn it from. While I do object oriented design and then code it in assembly (did that even before I learned C) and in C, I do not comprehend that way C++ has approached the OO principles in its language design. I have tried languages like CLU (from back in the early 1980's) and Java, but they were too slow to commit to and I soon abandoned them because by projects were real, not abstract. None of the C++ books I have looked at are oriented to explaining C++'s particular OO language philosophy. Even Stroustrup's own book didn't cover it the way I needed it.
While these books probably would work fine for a "newbie" who can spend the next couple years trying, failing, and learning from failure, they do no good for me. I cannot just stop all programming and spend the time as a "newbie" to learn something new. Every time I might even think of something I could do in C++ (or some other language I might learn) it is so temping to go do it in C because I can whip it right out faster than in the new language, debug it quickly, and have it totally kick ass on the computer.
While I do know of some specific shortcomings of C++ and could use those to say that C++ is not the best choice of language, I also know that shortcomings exist in C as well. But I have worked around them. Specific shortcomings aren't the point, anyway. If you want to know why it is so many people have not transitioned from C to C++, might I suggest surveying C++ programmers and ask them how many years experience they have had programming in C, and compare that with the results of a similar survey of C programmers. You can start with my 18 years experience programming in C.
If you still want to convert C programmers to use C++ then I suggest writing a book ... a short one, that explains every concept in C++ ... not just language syntax, but practical concepts ... clearly and concisely. Don't drag it out for newbies; focus on experienced C programmers. Explain how it is that C++ takes basic OO design concepts and puts them into a programming language. Explain how C++ behaves with each concept at higher abstract as well as lower real levels. Include a full reference section. And make sure there are examples of whole programs, not just snippets everywhere. Maybe then you might see more converts. But until someone does this, I doubt you will see very many.
Now if you do want to see an example of how I program in C, visit http://phil.ipal.org/freeware/avlmap/ [ipal.org] and take a look. I suppose this merits my "insane" label.
Reinventing QT ... (Score:3)
For an object oriented framework class library, QT is pretty darn nice. Not just in theory, but in actuallity (see KDE 2.0 beta). Its had several years to mature as well, whereas Inti is brand new and will undoubtedly go thru all the same growing pains.
At any rate...I find it hard to get excited about yet another framework (Inti) when there is a perfectly acceptable and mature one available (QT).
Re:Clarification please (Score:3)
Now, to stay on-topic: Personally I have no problem using the C API to GTK+, but much of the next generation of programmers will never know how to use it. I think a useful C++ wrapper to GTK+ is a good thing, and if Qt's is better then they should study it and use it's good points.
Re:Reinventing QT ... (Score:4)
Not quite true.
While we're not exactly the biggest supporters of KDE and Qt, we do contribute to them, and we're including them.
There's no point in the whole KDE/GNOME flamewars.
Both have their good and bad points and nice applications (I guess most people who are not fanatics of either one are using a couple of GNOME applications from KDE or vice versa) - so why not give users the choice?
This includes giving C++ programmers the choice to have a sane interface to gtk+ (such as Inti). It's not an attempt to kill of Qt.
(FYI: Yes, I have programmed in both, prefer Qt, and think gtk+ needs a more Qt'ish API for people who like C++.)