[PATCH] toolbar and entry



I uploaded the file gtk-lupus-970112-0-patch.gz  to ftp.gimp.org/incoming
and to ftp://ftp.pluto.linux.it/pub/developers.

The README follows.

This is a *generality* patch.
Quoting from gtk.info:
 GTK provides some unique features. (At least, I know of no other widget
 library which provides them). For example, a button does not contain a
 label, it contains a child widget, which in most instances will be a
 label. However, the child widget can also be a pixmap, image or any
 combination possible the programmer desires. This flexibility is adhered
 to throughout the library.

So I added gtk_toolbar_(append|prepend|insert)_widget functions
(and fixed the child->(label|icon) == NULL bug): this let us add any
widget to the toolbar. In testgtk I added an entry, for example.
This exposes a bug/feature in the toolbar: all of the children
have the same size (that is the max size of a widget in the toolbar).
This was intended to nicely layout buttons, but we don't want to
limit the toolbar to buttons (hey, think of a word processor toolbar!).
Neverless we still want the *buttons* in the toolbar to have the same 
size: I suggest the requisition and allocation functions check the
type of the child widget and make it the same size if it's derived
from "GtkButton". I haven't implemented this yet. Any comments?

The gtk_toolbar_(append|prepend|insert)_item now returns the GtkWidget
they inserted: this is because we'd like to do something more with
the button other than connecting to the clicked signal.
A side effect is that this makes easier to do interpreted languages
wrappers, ie in perl you can write:
	$button = $toolbar->append_item($label, $tooltip, $icon);
	$button->signal_connect('clicked', ...);
... and there is no need to reimplement the handling of callback
and user_data.
I suggest widget implementors take into account this sort of things:
it's easy to make life easier (changing the return type of a couple
functions!).

The third change is the gtk_entry_set_max_length function that let's
you change any time the text_max_length (why allow it only in
the constructor? this isn't flexible enough fot real applications).

Please mail comments to: lupus@lettere.unipd.it.



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]