GTK provides the facility to have a GtkNotebook without tabs. But as far as I can tell, it doesn't provide the facility to have tabs without the notebook pages. It seems somehow strange to me, and causes people to hack together their own button bars that function vaguely like Notebook tabs but nowhere near as functional, consistent, or in many cases accessible either. My question is whether there's a better way to achieve the same functionality.
At present, I'm creating two GtkNotebook's, the upper one is just for the tabs, while the lower one has the pages. There are two pages pre-built and are used to present almost all pages the notebook needs to contain by using the regular load/save/revert mechanics to flip data records as needed. A few other special-use pages are then also added in as needed, and the whole lot are re-orderable through the facilities built into the notebook widget. Somewhat annoyingly, tabs are mostly referenced by their associated child widget, and you have to have a child widget in order to add a tab. So for each tab I set the child as an un-shown simple widget, onto which I attach the relevant data record using g_object_set_data(). The tab switched signal then simply presents the relevant page and loads it with data from the data record. Now, I thought of using a list, but notebook tabs are not only significantly lighter, but seem much more natural as well; there's that direct visual association between the name on the tab and the content of the page, plus they look a whole lot nicer. Once there's a few more pages it might make sense to rotate the tabs to the side, but more than a dozen or so doesn't make a lot of sense to my application at all anyhow. So can I have my tabs, and my pages too? What other widget is there that's better suited than a list, when notebook tabs are almost perfect? My personal feeling is that GtkNotebook should be a GtkBox that by default, contains a GtkNotebookTabs widget and a GtkNotebookPages widget. The GtkBox itself should possess the functionality to change which edge the tabs are on (by flipping child order and changing layout direction), with appropriate signals used to let child widgets (such as thee tab bar) know when it needs to change its layout direction (in the default case, the opposite to the parent box's direction, but always keeping normal child order). But I suppose that's somewhat of a dream, along with similarly merging the Gtk[HV]Separators and any other widget that has both a H and V version. (Was there ever actually a practical reason for doing that, other than to show off the wonders of object derivation..? Personally I think separators should be a function of GtkBox rather than a distinct widget entirely; something like gtk_box_enable_separator_before|after(), so it can automatically merge them as needed.) Fredderic _______________________________________________ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
