From: "Thomas Dybdahl Ahle" [EMAIL PROTECTED] > søn, 31 08 2008 kl. 05:23 -0400, skrev Freddie Unpenstein: >> 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. > Most of the time I believe that separated tabs and pages are > unintuitive,
Most of the time, I believe you're right. If we had a split notebook, I'd expect the "normal" usage to be what we now know and love as GtkNotebook. > however for two cases I believe it is currently nessesary > as a hack: When you don't want a border around your pages, For some reason I thought you could already turn that off... Hmmm...... > and when you > want widgets next to the tabs (like the close button in older firefox). My Firefox still does that... Have they changed that for the newer one? It must have kept the old setting on mine when I upgraded, then, I guess... Close buttons on tabs is something that I detest with a passion even on decent computers. I love being able to simply click on the close button three times and have three tabs close, rather than having to chase the close buttons across the tab bar. ;) There've also been some VERY bad implementations of in-tab close buttons...! One of the worse I've see causes the tab to grow to accommodate the close button, which is shown on mouse over, causing all the tabs after it to jump around like they're on drugs. Firefox doesn't do that, but still, a close button at the end of the tab-bar is especially painful on my slow system where it can take half a minute before anything actually happens. ;) > While the former is being resolved in the latest gtk's using a new > property, I don't see much progress for the latter. That's where my comment at the end was aimed. Splitting the two, even if you go and put them right back together again in the normal case, allows for all sorts of edge cases to be handled cleanly. Arbitrary buttons before and after the button bar, widgets that are common to every page can be placed around the part that does the swapping, and cases where it makes sense to share pages between tabs. > In my app, PyChess, I use one notebook for tabs and 5 for pages, which > switch synchronously. This is done in order to preserve the > VPaned/HPaned layout through pages. Can't say I've seen it to be sure I understand what you're saying about the V/H Paned layout factor... However... In the simplest case, I'd like to be able to create tabs and pages individually; switching to a tab would emit a tab switched signal with a gpointer as user_data. The default handler would then interpret that as the notebook page to be presented, and the usual functions for adding pages would link them thusly. You could, however, intercept the tab switched signal and handle the value stored in the tab however you wished. For example, you could have a notebook with shared pages as I'm doing, or just one page in which you place a bunch of widgets, one of which would be another notebook with the actual pages those tabs refer to, or any combination thereof. In my case, I'd have the tab switched handler let the default handler run unmollested if GTK_IS_NOTEBOOK_PAGE(user_data) is true, but handle it specially by loading it into a shared page otherwise. As far as I can see, all it needs is for the tab switched signal to be interceptable, and a new API function that will present a page without disturbing the tab bar. Can anyone think of a reason why a change like that would break anything? Then all that'd be needed would be to allow buttons alongside the tab bar, and we'd all be happy. ;) Fredderic _______________________________________________ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
