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

List:       gtkmm
Subject:    Re: ImLib wrapper (was Re: [gtkmm] Gnome-- status)
From:       Guillaume Laurent <glaurent () worldnet ! fr>
Date:       1999-01-04 18:19:45
[Download RAW message or body]

Tero Pulkkinen <terop@assari.cc.tut.fi> writes:

> Karl Nelson <kenelson@ece.ucdavis.edu> writes:
> > Do you have any opposition to having everything be inline in the
> > gen_h file, then have gen_h strip out the C code?  (thus saving
> > us from having to match prameters in two places.)
> 
> Yes. :)

So do I.

> Better improve gensig to generate the same signatures in two places
> than to make them inline. (i.e. we should add more cases covered by gensig,
> so that normal function wrappers could be generated too...)

Tero, I think you misunderstood what Karl meant here. What he had in
mind was having gensig split a .gen_h containing only a class def with 
everything inlined into a .h with nothing inlined, and a .cc with the
actual code.

However, I still disagree with this because :

- it will make *huge* Java-like classes defs, even if most functions
  will be small (e.g. simply the wrapped gtk call).

- how then could we actually inline stuff when we really want to ?
  We're already twisting the C++ syntax enough in our gen_h as it is,
  I don't want having to mind about some special inline clause.

> > >we could have it like this:
> > >  Gtk_Collection box1,box;
> > >  box1 << button1 << button2;
> > >  box << box1 << button3;
> > 
> > Wouldn't this also be a valid constuction? (that looks a little more
> > organized.)
> > 
> >  Gtk_Collection box1,box;
> >  box << (box1 << button1 << button2) << button3;
> 
> yes.

BTW, let me clarify what I had in mind :

	box << box::start << button1 << button2 << box::end << button3

would equal to

	box.pack_start(button1);
	box.pack_start(button2);
	box.pack_end(button3);

> > >Though, it could be clearer :(
> > >maybe:
> > >  Gtk_Collection box1,box;
> > >  box1 = button1, button2;
> >           ^^^^^^^^^^^^^^^^
> >       wouldn't this be hard to implement.  

Not, but I really hate the look of it. It feels like "box equals to
button", not "put button into box".
 
> no. Note that the box1 must be some special type and operator=() and operator,
> is specified for those only:
>    Gtk_C_private operator=(Gtk_Collection &, Gtk_Widget&);
>    Gtk_C_private operator,(Gtk_C_private &, Gtk_Widget&);
> 
> This has the features that:
>   operator=() must always be first, so  box1,box2  will not
>   work. This way can also specify compile time checks for certain number of
>   buttons etc - like this:

I agree that it's nice to have compile time checks about various
things in Gtk-- which we can't have in gtk+, but on number of children 
in a container ??? What's the point ? Most containers don't implement
such a limit anyway, and those who do have it set a runtime.

>      box1 << button1, button2
>           << button3; // error, first and nth line must have same number of items
>      box1 << button1, button2
>           << button3, button4;  // ok...
> 
> see what nice tool this operator overloading can provide - excellent
> for inputting matrixes and things like that where all columns need to
> have same number of items.. (maybe we can utilize this in clist
> insertion for example)

But a box has nothing to do with a matrix whatsoever, more like a
single-dimension array. This syntax is indeed great for Gtk_Tables,
though, as in your example below. 

> if we did this really nasty, we could overload operator<<() for vbox
> and operator,() for hbox in boxes... - the first one would always be
> << :-) Then we'd have:
> 
> box << button1 , button2 
>     << button3, button4;
> 
> which would mean a vbox with 2 hboxes inside it... (this becomes too
> difficult to use? :)

Way too vorlon-ish, IMHO. This really feels like operator overloading
abuse.

> similarly it'd be really nice to be able to pack widgets like this:
> 
> table << button1, button2, button3
>       << button4, button5, button6
>       << button7, button8, button0;

This one I really like. It makes sense, and you have a visual
representation of your table in the code itself.
 
> but these of course need to work on handles and references both...  
> (I sometime wish there were some way to enforce that button1 needs to
> have same (or larger) lifetime than table on compile time resolution
> when passed as references... -- no runtime things like gc's :)

That's what we've always had. As long as it is packed in the table,
the table references it so it won't be destroyed until at least after
the table.

> * as much compile time checks as we can figure out -- if there's
>   restrictions of how many items there should be in a column (like in
>   clist?), we should enforce it in compile time :)

How could that be possible, since the amount of rows/columns in a
table or a clist is decided at runtime ?

-- 
					Guillaume.
					http://www.worldnet.fr/~glaurent

Received: from teal.ece.ucdavis.edu (kenelson@teal.ece.ucdavis.edu [169.237.32.142])
	by scarlet.ece.ucdavis.edu (8.8.7/8.8.7) with ESMTP id MAA03463
	for <kenelson@scarlet.ece.ucdavis.edu>; Mon, 4 Jan 1999 12:01:39 -0800 (PST)
Received: from teal.ece.ucdavis.edu (kenelson@localhost)
	by teal.ece.ucdavis.edu (8.8.7/8.8.7) with ESMTP id MAA10220;
	Mon, 4 Jan 1999 12:01:56 -0800 (PST)
Message-Id: <199901042001.MAA10220@teal.ece.ucdavis.edu>
X-face: 
 RinRV?cII^~g?cLc9;-D}8xnP^:6hX}*,%&@y"6p7xm^Z]V<7(`zzI!/#s%[2G'fTVC+b"*
 4eYfecJ4=,gHu4o_{Z[VG{Em*{tC^LKZ6eUDc?PI0@dk}3"kJ7*"y8*hMv\qz[C5djlU#AQh0Cq.%W
 @2kSd~S<<NcD7L4'O#`737_IEe02\s!gB6HW13]sD)'$+''!eRE7jPH\G(R&(+:Tu8bs[kr?ixX}x!
 -6`4*-B[UB_Wl!rZyL/$R(xi`vb"+t6osqR?gPX^r);Zpm'5(b/Rs[uGBN>&}]!;ZNm(wUE4=
X-url: http://www.ece.ucdavis.edu/~kenelson
To: Tero Pulkkinen <terop@assari.cc.tut.fi>
cc: gtkmm@modeemi.cs.tut.fi, kenelson@ece.ucdavis.edu,
        kenelson@ece.ucdavis.edu
Subject: Re: ImLib wrapper (was Re: [gtkmm] Gnome-- status) 
In-reply-to: Your message of "04 Jan 1999 18:10:06 PST."
             <xduaezznhnl.fsf@assari.cc.tut.fi> 
Date: Mon, 04 Jan 1999 12:01:55 -0800
From: Karl Nelson <kenelson@ece.ucdavis.edu>

In message <xduaezznhnl.fsf@assari.cc.tut.fi>Tero Pulkkinen writes
>Karl Nelson <kenelson@ece.ucdavis.edu> writes:

[INLINING]
>> Do you have any opposition to having everything be inline in the
>> gen_h file, then have gen_h strip out the C code?  (thus saving
>> us from having to match prameters in two places.)
>
>Yes. :)
>
>Better improve gensig to generate the same signatures in two places
>than to make them inline. (i.e. we should add more cases covered by gensig,
>so that normal function wrappers could be generated too...)
>
>inline really is problematic later when maintaining the library.

Hmmm.  I am definately not getting my point across, because we are arguing
the same point.

I would like us to write

GTK_WRAPPER  Gtk_Button : public Gtk_Bin
{
  Gtk_Button(GtkButton *castitem)
    :Gtk_Bin(GTK_BIN(castitem))
  {}

  Gtk_Button()
    :Gtk_Bin(GTK_BIN(gtk_type_new(c_class.get_type())))
  {}

  Gtk_Button(const _gtk_string &label)
    :Gtk_Bin(GTK_BIN(gtk_type_new(c_class.get_type())))
  {
    GtkWidget *button;
    GtkWidget *label_widget;

    button = GTK_WIDGET(gtkobj());
    label_widget = gtk_label_new (const_cast<gchar*>(label.gc_str()));
    gtk_misc_set_alignment (GTK_MISC (label_widget), 0.5, 0.5);
  
    gtk_container_add (GTK_CONTAINER (button), label_widget);
    gtk_widget_show (label_widget);

  }

  static bool isGtkButton(Gtk_Object *checkcast);
  {
    return GTK_IS_BUTTON(checkcast->gtkobj());
  }

  SIGNAL void pressed()
    {some_impl_method();}
  SIGNAL void released();
  SIGNAL void clicked();
  SIGNAL void enter();
  SIGNAL void leave();
  
  void set_relief(GtkReliefStyle newstyle)
  {
    gtk_button_set_relief(gtkobj(), newstyle);
  }

  GtkReliefStyle get_relief()
  {
    return gtk_button_get_relief(gtkobj());
  }
};

And mean that nothing is inline.  This should build all
of the extra signal initializations, construct the impl
methods (including the one which is non-default), and
construct the C file entirely from the class definition.
(this should be a full translation of Gtk_Button, so
you can go and compare to see what I am assuming the 
compiler will do.)

(If we really do want something to be inline, we would
use INLINE before the function definition.) 
This does mean we will end up writting in a peusdo code,
but the is preferable to hand groomed C++ we use now.


[WIDGET PACK]
>> >  Gtk_Collection box1,box;
>> >  box1 = button1, button2;
>>           ^^^^^^^^^^^^^^^^
>>       wouldn't this be hard to implement.  
>
>no. Note that the box1 must be some special type and operator=() and operator,
>is specified for those only:
>   Gtk_C_private operator=(Gtk_Collection &, Gtk_Widget&);
>   Gtk_C_private operator,(Gtk_C_private &, Gtk_Widget&);
>

You are right the order of presidence is such that = goes first.

>  operator=() must always be first, so  box1,box2  will not
>  work. This way can also specify compile time checks for certain number of
>  buttons etc - like this:
>     box1 << button1, button2
>          << button3; // error, first and nth line must have same number of it

I am assuming the box here is a special construction (not a HBox, VBox or
table).  

Since boxes must be V or H when constructed and can't change, you must 
be dynamically allocating boxes as you discover them.  I don't
much like that.  The user there may have meant...

  ________________________________
 |  ___________   ______________  |  
 | | button1   | |              | |  
 | |___________| |              | |  
 |  ___________  |   button3    | |
 | | button2   | |              | |
 | |___________| |______________| | 
 |________________________________|

Which the user should have written

  Gtk_HBox hbox;
  Gtk_VBox vbox;
 
  hbox << (vbox << button1 << button2 << Gtk_Box::end) 
       << button3 << Gtk_Box::end; 

(Yes this is much lower level, but I can directly see the 
gtk calls this would be making.)

Remember the user then needs to add some seperator space
and other such goodies.  Therefore, the order and numbering
must be unambigious.  That does give a good idea

  
  hbox << button1 << space(10) << border(5) << button2 << Gtk_box::end;

Means a box with 10 pixels spaceing between, then button2 with a border
of 5 pixels. 

>
>> Also we have the problem that buttons are containers so
>
>no, we cannot use those operators directly to a button for example, it
>needs to be some specific type we apply these operators to and which
>collects the list/tree or whatever and then we can "add()" that to the
>widget or something :) (thats why I used Gtk_Collection, and not
>Gtk_Button :)

I like things to uniform.  I would like << to mean add widget to
for all things.  Lists are a bit harder, because do we mean add
a item or a widget.  (Not having looked at it I don't know how
similar they are.)

One other arguement in this favor of just normal stream style, 
is the mixing , and << is generally
bad.  the presidence of these operators is widely different.  << is
above = and , is below =.

So

  box = button1, button2;   -> box.operator=(button1);box.operator,(button2);
  box = button1<<button2;   -> box.operator=(button1.operator<<(button2));

Not good! 

>
>if we did this really nasty, we could overload operator<<() for vbox
>and operator,() for hbox in boxes... - the first one would always be
><< :-) Then we'd have:
>
>box << button1 , button2 
>    << button3, button4;
>
>which would mean a vbox with 2 hboxes inside it... (this becomes too
>difficult to use? :)

Yuck.  A vbox with 2 hboxes is

  Gtk_VBox vbox;
  Gtk_HBox hbox1,hbox2;
  
  vbox << (hbox1 << button1 << button2 << Gtk_Box::end)
       << (hbox2 << button3 << button4 << Gtk_Box::end) << Gtk_Box::end;

Very straight forward.

>
>similarly it'd be really nice to be able to pack widgets like this:
>
>table << button1, button2, button3
>      << button4, button5, button6
>      << button7, button8, button0;
>

Hmmm.  How about
 
 Gtk_Table table(3,3);
 table << row(1) << button1 << button2 << button3 << endr
       << row(2) << button4 << button5 <<            endr // nothing in 3rd
       << row(3) << button7 << button8 << button0 << endr;

Or the same thing trasposed
 
 Gtk_Table table(3,3);
 table << col(1) << button1 << button4 << button7 << endc
       << col(2) << button2 << button5 << button8 << endc 
       << col(3) << button3 << skip(1) << button0 << endc;

However, I have no idea how to make this compile time safe any
more that our current system is. (It isnt!)  I wonder if we
can get this to look like TeX? ;-)

Basically I like plan old stream operations with no mixed operators.
We need to keep pounding this one out some more.

--Karl
  

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