Fixed the GTK+ Combobox sizing issues for real this time.

combobox.go

@@ -7,7 +7,7 @@ import (
 	"sync"
 )
 
-// A Combobox is a drop-down list of items, of which at most one can be selected at any given time. You may optionally make the combobox editable to allow custom items. Initially, no item will be selected (and no text entered in an editable Combobox's entry field).
+// A Combobox is a drop-down list of items, of which at most one can be selected at any given time. You may optionally make the combobox editable to allow custom items. Initially, no item will be selected (and no text entered in an editable Combobox's entry field). What happens to the text shown in a Combobox if its width is too small is implementation-defined.
 type Combobox struct {
 	lock		sync.Mutex
 	created	bool

futureplans.md

@@ -55,6 +55,7 @@ twists of fate:
 - need a way to get ideal size for all controls on Windows, not just push buttons (Microsoft...)
 - Cocoa controls have padding around them; this padding is **opaque** so we can't just use the control's cell rect and some shuffling around
 - when programs that use this package are running, you will not be able to shut down/log off/etc. on Mac OS X because they indiscriminately respond to requests to close with "no" so as to give Go and our program which does not strictly play by NSApplication's rules a fair shot at proper cleanup; this is really a consequence of the way applications work in Cocoa...
+- non-editable comboboxes in GTK+ have extra stuff to make them wider than other controls and thus cut off slightly but noticeably if the window is too small despite having the correct width
 
 style changes:
 - make specific wording in documentation consistent (make/create, etc.)

gtkcalls_unix.go

@@ -13,15 +13,18 @@ import (
 // #include "gtk_unix.h"
 // static inline void gtkSetComboBoxArbitrarilyResizeable(GtkWidget *w)
 // {
-// 	// we can safely assume that the cell renderers of a GtkComboBoxText are a single GtkCellRendererText by default
-// 	// thanks mclasen and tristan in irc.gimp.net/#gtk+
+// 	/* we can safely assume that the cell renderers of a GtkComboBoxText are a single GtkCellRendererText by default */
+// 	/* thanks mclasen and tristan in irc.gimp.net/#gtk+ */
 // 	GtkCellLayout *cbox = (GtkCellLayout *) w;
 // 	GList *renderer;
 // 
 // 	renderer = gtk_cell_layout_get_cells(cbox);
-// 	g_object_set(renderer->data, "width-chars", 0, NULL);
+// 	g_object_set(renderer->data,
+// 		"ellipsize-set", TRUE,		/* with no ellipsizing or wrapping, the combobox won't resize */
+// 		"ellipsize", PANGO_ELLIPSIZE_END,
+// 		"width-chars", 0,
+// 		NULL);
 // 	g_list_free(renderer);
-// gtk_combo_box_set_popup_fixed_width(cbox, FALSE);
 // }
 import "C"
 
@@ -169,9 +172,9 @@ fmt.Printf("%p %s\n", c, fromgstr(C.g_type_name(t)))
 
 func gtk_combo_box_text_new_with_entry() *C.GtkWidget {
 	w := C.gtk_combo_box_text_new_with_entry()
-	C.gtkSetComboBoxArbitrarilyResizeable(w)
 	// we need to set the entry's width-chars to achieve the arbitrary sizing we want
 	// thanks to tristan in irc.gimp.net/#gtk+
+	// in my tests, this is sufficient to get the effect we want; setting the cell renderer isn't necessary like it is with an entry-less combobox
 	entry := togtkentry(C.gtk_bin_get_child((*C.GtkBin)(unsafe.Pointer(w))))
 	C.gtk_entry_set_width_chars(entry, 0)
 	return w

todo.md

@@ -25,7 +25,7 @@ super ultra important things:
 - make sure the preferred size of a Listbox is the minimum size needed to display everything on all platforms (capped at the screen height, of course?)
 	- same for Area, using the Area's size (this will be easier)
 - make sure the image drawn on an Area looks correct on all platforms (is not cropped incorrectly or blurred)
-- when resizing a GTK+ window smaller than a certain size, the controls inside will start clipping in bizarre ways (comboboxes will just cut off; the horizontal scrollbar in Area will disappear smoothly; etc.)
+- when resizing a GTK+ window smaller than a certain size, the controls inside will start clipping in bizarre ways (the horizontal scrollbar in Area will disappear smoothly; etc.)
 	- check my logs; someone in irc.gimp.net/#gtk+ answered this (or provided an answer)
 - see update 18 March 2014 in README
 - resizing seems to be completely and totally broken in the Wayland backend