not anymore ;) - Re: notebook api a pain...

On Wed, 2 Sep 1998, Michael K. Johnson wrote:

> Tim Janik writes:
> >On Mon, 31 Aug 1998, Michael K. Johnson wrote:
> >> The notebook API is a pain for certain uses.  In particular, if you
> >> want to keep track of a page you have added, you have to jump through
> >> hoops.  For example, I have an application where I need to add pages
> >> in no particular order, then remove them at random.  There is no real
> >> way to identify a page right now.  :-(
> >
> >not fully correct. you add a page by providing the (container) widget
> >that needs to appear as a notebook page later on. this widget pointer
> >is more or less the handle you'd like to have.
> Um, what did I say that was incorrect?

i intentionally didn't say "incorrect". what i meant was that there
is indeed a "handle" in existance, i.e. the widget pointer.
it just happened that the notebook API didn't export a function
to convert from widget pointer to page num, eventhough the functionality
was implemented end even exported through the object argument system
with the ::position argument.

> Certainly, that widget pointer could be used as the handle -- that is
> fine -- but what is important to me is that I *have* a handle, whether
> it is that pointer or not.  I want a handle of some sort that DOES NOT
> change when arbitrary pages are removed.  You have suggested one
> reasonable way to implement what I suggest.  That doesn't mean that
> what I wrote was incorrect; what I wrote (that there is no current
> facility for this) is perfectly correct.  The only way I can tell to
> do it is to happen to know that it is maintained internally as a
> linked list and figure it all out magically, which sucks.
> >there needs to be a function, though, that returns the current
> >page number for a given notebook child, i.e.
> >
> >gint gtk_notebook_get_page_num (GtkNotebook *notebook,
> >                                GtkWidget   *page);
> >
> >which will return -1 if page is not a child of the notebook, and its
> >position otherwise.
> Yes, that would work well.

it's in place already.

> michaelkjohnson


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