Re: [gtkmm] Talk about a major rewrite

[Murray Cumming <murrayc usa net>]

On Tue, 2002-07-30 at 23:42, P. Christeas wrote:
> 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. 

Have we heard about these bugs already? Are you talking about gtkmm 1.2
or gtkmm2?

> 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, 

It's LGPL'd.

> we can copy-paste that into 
> C++ functions.

Not going to happen, not in this project anyway.

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

Do you have any evidence of this. I don't believe it.

> - Some gtk+ functions are buggy. Gtkmm inherits the bugs.

GTK+ bugs get fixed. It's better to fix the bugs in GTK+ rather than
copy the GTK+ code and fix the bugs in your copy.

> - If gtk+ changes, gtkmm has to change, too (most of the times).

GTK+ usually has good reasons for changing.

> - Gtk+ tries to implement an object model in palin C. Gtkmm wraps around 
> that. This is a mess.

Define "mess". It works, and is not very visible to the gtkmm coder.

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

If GTK+ has lifetime problems then they should be fixed like any other
bug. GTK+ has quite a simple object lifetime system.

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

Projects need to have clear descriptions and aims, and if you think that
they need to exist because another project does not meet your needs then
you need clearly describe the problems that it solves.

> - I am thinking of some projects I want to open. I need a stable

gtkmm2 will be stable soon. A new project would not be stable for a long
time.

> and 
> efficient interface myself.

Prove that gtkmm is not "efficient" compared to GTK+. If you found any
part that needed to be optimised then we would optimise it.

> I hated it when an app I wrote couldn't run, 
> because of obscure gtkmm behaviour. I'll discuss more about that later.

It would be simpler to discuss bugs when you discover them, so that they
can be confirmed.

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

I think this is immensely foolish. I would take you more seriously if
this wasn't the first time that we had heard from you or if you had any
thing to back up or explain your claims.

-- 
Murray Cumming
murrayc usa net
www.murrayc.com