Re: Divided notebooks...

["Freddie Unpenstein" <fredderic excite com>]

From: "Thomas Dybdahl Ahle" [lobais gmail com]

> 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