Re: argument types?

[Owen Taylor <otaylor redhat com>]

Tor Lillqvist <tml@sgic.fi> writes:

> A person, whose name I won't reveal for now as I didn't ask permission
> to forward this message, writes:

>  > I'm just working to compile "simple.c" with my preliminary port of GTK+
>  > to WIN16. 

GTK+ will not support 16 bit systems. Never. It's not a reason
for changing any code.
 
>  >   window = gtk_widget_new (gtk_window_get_type (),
>  > 			   "GtkObject::user_data", NULL,
>  > 			   "GtkWindow::type", GTK_WINDOW_TOPLEVEL,
>  > 			   "GtkWindow::title", "hello world",
>  > 			   "GtkWindow::allow_grow", FALSE,
>  > 			   "GtkWindow::allow_shrink", FALSE,
>  > 			   "GtkContainer::border_width", 10,
>  > 			   NULL);
>  > 
>  > GtkContainer::border_width:
> 
>  >  gtk_object_add_arg_type ("GtkContainer::border_width", GTK_TYPE_ULONG,
>  > GTK_ARG_READWRITE, ARG_BORDER_WIDTH);
> 
>  > Is defined as being GTK_TYPE_ULING, thus 32-Bit, while "10" for a
>  > 16-Bit-Compiler means an int, thus 16-Bit. This causes the application
>  > to crash.

>  > In my opinion the right thing to do would be to change the type of
>  > GtkContainer::border_width and everything else related to
>  > pixel-coordinares to be of type int. 
> 
> (Or "unsigned", in this case, I guess)

Actually, int. 

Unsigned integers for coordinates are broken, and
I'll probably be going through and changing everything for
1.4. E.g., if allocation.width = 1, and widget->border_width = 5, what is:

 int width = MAX (0, allocation.width - 2*widget->border_width)

hmmm, -9.

>  > In 32-Bit Systems this would still mean 32-Bit.
> 
>  > What would other programmers think about that?
> 
> This would indeed seem logical to me, too. One would think the same
> problem occurs on machines where integer literals are 32 bits and
> GTK_TYPE_ULONG is 64 bits? Are there some other issues involved I
> don't realize?

We don't have the problem much with GTK+, but it comes up a 
lot with GnomeCanvas which has double-valued. But the problem
hear really is restricted to the argument types, not the structure
of function parameters types. 

Changing this and similar arguments to GTK_TYPE_INT makes sense to me,
though note that this is a source-incompatible change, since some
people may properly be doing

 "border_width", (gulong)5

> I guess porting GTk+ to Win16 does seem a little insane at first, but
> apparently it isn't that hard (most difficulties are in GDK, where one
> cannot simply reuse the Win32 code), and apparently this person does
> have a good reason to do it... So, if relatively small (?) clean
> changes like this are needed, I think they could be included in the
> main sources.

Changes for 64 bits architectures may make sense. 16 bits 
does not make sense. If there is a good reason to port
to Win16, a separate source-code base will have to be maintained.

>  They probably will help when porting GTk+ to other, more
> "politically correct" non-Unix environments, too.


                                        Owen