[gtkmm] Talk about a major rewrite



Hi all.
I'm just another programmer, writting programs with gtkmm. Last week I got 
desperate enough to send this e-mail.
I have come accross a whole series of bugs and pitfalls of gtkmm. I think 
there is no hope of dealing with them, because many of them relate to gtk+ 
itself. 
My suggestion is to re-write gtkmm, so that it only has C++ code (and not 
wrap around gtk+). Since all gtk+ code is GPL'd, we can copy-paste that into 
C++ functions.
This mail is just a summary. I'm willing to write a whole series of 
mails-docs etc to discuss my view. Here are some points to answer your first 
questions:
- Qt won't do because of licensing. I also want some features for me; Qt is 
not open-source like that.
- Some other interfaces are clearly written, but they don't have the gtk+ 
completeness.
- Gtkmm wraps around C functions. That is bad for performance.
- Some gtk+ functions are buggy. Gtkmm inherits the bugs.
- If gtk+ changes, gtkmm has to change, too (most of the times).
- Gtk+ tries to implement an object model in palin C. Gtkmm wraps around 
that. This is a mess.
- The gtk+ object model is still a good framework and design to start with, 
in a purely C++ environment.
- What bothered me is the way gtkmm tries to track data losses and 
references. If gtk+ handles it wrong, gtkmm can't help and that is a deadend.
- IMHO this mess I describe is the reason gtkmm is not very popular. Qt is 
and shows some path to follow.
- I could (thoretically) write that thing myself and let you go on with 
gtkmm. It wouldn't be fair, however, if my work made yours obsolete.
- I am thinking of some projects I want to open. I need a stable and 
efficient interface myself. I hated it when an app I wrote couldn't run, 
because of obscure gtkmm behaviour. I'll discuss more about that later.
Anyway, thanks for your time if you have read it all down to this line.

It's Summer and I'm taking my holidays. You can think of my suggestion and 
talk about it. All I wait for now is your comments (the core team 
preferably). As from September we could talk about the real implementation. 

P. Christeas



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]