Re: argument types?
- From: Owen Taylor <otaylor redhat com>
- To: gtk-devel-list redhat com
- Subject: Re: argument types?
- Date: 08 Sep 1999 15:10:21 -0400
Tor Lillqvist <firstname.lastname@example.org> 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)
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)
> > 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
> 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 someone has a good reason to port
to Win16, they'll have to maintain their own tree.
> They probably will help when porting GTk+ to other, more
> "politically correct" non-Unix environments, too.
] [Thread Prev