Re: [gtk-list] Re: announce: yet another gtk+ C++ wrapper (no caps as Owen suggest)

[Tero Pulkkinen <terop students cc tut fi>]

Mario Motta <mmotta@guest.net> writes:
> Speaking philosophically: i know gtk-- and i like that
> Signal => SignalProxy approach, one of the best i saw since
> i use and study GUI (yes was in 1986 with M$ SDK 2.0
> and those flat black&white Athena Widgets, i'm more old
> than you could believe) but we are programmers and let's be
> pragmatics:
> - you say that gtk-- is a "thin" layer above Gtk+, if a remember well
> libgtkmm.so is as large as libgtk.so, what you mean "thin" ?

Thin means it uses about the same abstractions as previous layer.
=> the implementation of it is simple.

> - we should know what benefits a wrapper gives related to wrapped,

I hope people do know them, I've tried to tell them at the web page:
* easier to use inheritance
  (have you noticed gtk+ applications rarely derive from widgets, but
  gtk-- applications do it all the time..)
* type safety
  (signal system, virtual functions, consts, strings, bools have all
   increased type safety of the interface - there's still some work to
   do in this area...)
* C++ syntax for things
  This doesnt sound too much of advantage, but its quite important for
  many people. In this area there's some work to do too - there has
  been quite good proposals in gtkmm list to improve this one.
* C++-style memory management
  This is much better in gtk-- than in many other C++ widget libraries.
  (the trick is to not move widget ownership to containers - allows
  storing widgets in stack for example and let C++'s
  constructors/destructors/scopes handle it properly)
  (btw, copying widgets is forbidden in gtk--. This isnt however
  not enforced yet, but absolutely should be!)

There's also several problems in gtk--:
* certain wrappers are quite poor - Gtk_Gc, Gtk_Style, Gtk_Container
  interface isnt yet really what it should be etc.. there might be
  other rarely used wrappers that doesnt work like they should.. 
* Too little applications have been done with gtk-- still.
  Some serious problems will still be found in the future.

> - wich is the code reduction factor ? 

I believe gtk-- programs are half smaller than similar gtk+ programs.
(this is because more use of inheritance and virtual functions, instead of
just using widgets).

> - How many lines need a test-wrapper program related to testgtk?
> - how is fast in signal dispatching ? 

which one?

there's at least 4 different cases:
1) signals with nothing to do with gtk+. These are *really* fast.
   should be like 1 function call + 1 virtual function call and 1 normal
   method call per each handler... (someone measured this
   compared to what Qt uses and this was like 7-8 times faster, I think
   this is quite much faster than what gtk+'s signals are)
2) signal emissions coming from gtk+ (proxy stuffs -- this isnt too slow, 
   about 1-2 function calls more than gtk+'s similar)
3) virtual function calls coming from gtk+ (proxy stuffs -- again 3-4 function
   calls slower than gtk+'s virtual function call) (this one currently
   has one hash table lookup, which makes it more expensive)
4) emit forwarded from C++ function object to gtk+ (this is just one function
   call extra...)

Then there's the normal tools provided by C++, virtual functions, normal
member functions etc.. These have no overhead compared to C++'s :-)

The speed of signal dispatching is currently fast enough in gtk-- that
it has no effect on the final efficiency of the applications using gtk--.

> (if you want i can show you how gtk+ is able to erase and substitute with a
> GtkWidget* the famous "this" hidden first arg of C++ member call)

hmm... I didnt understand what you mean in this one... 

> Continuing to discuss without those type of information is useless
> and better to continue to speak philosophically: - is my personal
> opinion (and i read something about during this thread) that the
> gtk-- makers were so satisfied with that signal mechanism that
> stopped to use C++ as C++ and used it only as a better C, that was a
> short track and made unuseless to do examples and tests mainly
> because they would have resulted in a gtk+ clones.

The project started from "better C" approach - originally it was just
direct mapping from C functions to classes and some macros to do the
functionality of signals. After that, it has been slowly transformed
to use more C++ style interface and typesafety has been
increased. This should be still continued and transformed to look even
more like what gtk+'s interface would have been if it were written in
C++ originally.

originally there were no additional typesafety compared to gtk+ - but
it even at that point did implement most of gtk+'s interface.

There's still much to do - many places the gtk+'s interface is
still visible -- and it should be.

> - Having gtk+ documentation and applying names conversion is enough
> easy to use gtk--, but in my opinion a wrapper should make something
> more, for instance

> the core of M$ API is made of about 1000 functions, the VCL core (a C++
> wrapper)  allows the user make same things with not more than 200 mantaining
> same flexibility and same speed and being much more safe.

Yup, this kind of wrappers are also needed. Gtk-- is not one of those and
never tried to be one. Gtk+ does have many widgets and many methods and
functions. This is fine for low level interfaces like gtk+ and gtk-- are. 
Higher level library should radically cut down the number of widgets
and raise abstraction level, cut down amount of functions and types
programmers need to know.

(ugh, this is too long again :)

-- 
-- Tero Pulkkinen -- terop@modeemi.cs.tut.fi --