[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-freeqt
Subject:    Re: [freeqt] Further Thoughts
From:       Karl Nelson <kenelson () ece ! ucdavis ! edu>
Date:       1999-03-11 23:11:01
[Download RAW message or body]

In message <19990311153440.A30608@thelonious.new.ox.ac.uk>Jo Dillon writes
>Roy Wood (roy@centricsystems.ca) spake thusly:
>> One of the more interesting things suggested here recently related to the 
>> view of Harmony as a "free" framework for developing X-based 
>> applications.  This seems like an interesting idea, since most of the 
>> other similar things I've looked at don't really measure up to what Qt 
>> offers.  I'd be interested in hearing what other people have to say about 
>> this, especially if they have any experience with GTK--, wxWindows, JX, 
>> etc.
>> 
>> My somewhat ignorant impression is that GNOME/GTK/GDK has a lot of 
>> momentum, but it is really a C-based, non-OOP API.  wxWindows is an (yuk) 
>
>  It's C-based but highly OOP - it has a sort of inheritance/virtual-functions-
>in-C approach. Not too bad, though it doesn't beat a C++ widget set from
>the point of a view of a C++ programmer ;)

I do have a word or two to say on this subject.  Gtk is indeed very
OO, but it need not be the level at which the extensions are made.  
Everyone assumes that to add a new widget to Gtk you must use C.  That
is not true.  You can using nothing but C++ methods derived a new widget
in Gtk--.  In most cases this is as easy as doing the following

  class MyButton: public Gtk_Button
    {
     protected:
       gint expose_event_impl(GdkEvent *)
          {/* code for the event */}
       void realize_impl()
          { Gtk_Button::realize(); // fall back on gtk+ method
            /* new code */
          }
     public:
        MyButton():Gtk_Button() {}
        my_new_method()  {}
    };

Now I do admit at times you must interact with the Gtk+ structures and
such, but will not too much more work that can also be covered up.  
Also there can be methods added to export that widget back to C.  
(No one has needed it yet, so we haven't bothered.)

Basically if you do really want to expand up to a full framework
(which Gtk-- currently isn't) it is certainly possible.  And then
you get the benifits of Gnome.  (I really would like to see the
abstractions made to interact between KDE and Gnome, but I am
not holding my breath.)

The one underlying problem I have found with the Gtk system is
that there is no abstraction in the drawing tool to rendering engines.
Therefore, the printer tool, drawing kit and canvas all use different
style commands, making rendering to a printer a difficult job.  I
hope that they will fix this at some time in the future, else 
some group should go ahead and make a unifed drawing kit.  (printer,
GL, X, Win, gnome canvas)

>
>> MFC-like approach to an OOP framework.  JX sounds like the best of the 
>
>  Yes - wxWindows wraps native widgets. Ick!
>
>> bunch, though it is relatively unknown (I love Code Crusader and Code 
>> Medic though-- wow).
>> 
>> Any other packages I should look at?  Any comments?
>
>  Well, I believe fltk has been mentioned here and is well worth looking
>at. 

I have also worked with Fltk and can say it is well worth spending the
time to look it over.  Personally I found it a little small for my tastes,
so I looked at using the more flexible Qt.  (But ended up writting for
Gtk-- because I disliked the Qt license at the time.)  

Perhaps you could incorperate the Gtk-- type signal system into Fltk
to give it a bit more power.  (The single callbacks always bothered me.)

Hope this information is of some use.

--Karl 
  Gtk-- Contributor

[prev in list] [next in list] [prev in thread] [next in thread]