Re: Gtk{Tree,List} replacement proposal
- From: Maciej Stachowiak <mjs eazel com>
- To: Havoc Pennington <hp redhat com>
- Cc: Jonathan Blandford <jrb redhat com>, gtk-devel-list gnome org
- Subject: Re: Gtk{Tree,List} replacement proposal
- Date: 05 Jul 2000 11:41:24 -0700
Havoc Pennington <hp@redhat.com> writes:
> Maciej Stachowiak <mjs@eazel.com> writes:
> >
> > Humorous confirmation anecdote - immediately after I sent this someone
> > emailed me privately and asked what the C means.
> >
>
> I don't think anyone knows what the C means - I don't know what it
> means myself, though I have some guess like "column" - but it hardly
> matters for using the widget, since the widget name also contains
> "List". I mean, who cares what the C means. ;-)
I think it means "column". It's true that no one really cares, except
when trying to figure out whether to use List or CList, and
fortunately, using List is almost never the right answer anyway. In
this case though, the only non-abbreviated part of the name
> My favorite renaming idea would be GtkTreeView/GtkTreeModel in the
> same way we did GtkTextView/GtkTextBuffer. GtkTreeModel would be the
> abstract base; I'm not sure what to call the subclasses.
I actually suggested this originally, but then I realized the issue
with naming the subclasses. Perhaps the abstract class could be given
a longer name, since users will mostly use the two subclasses so you'd
have:
GtkAbstractTreeModel
|
+---- GtkTreeModel
|
+---- GtkListModel
Then you only need to type the long name when you subclass.
> ("List " isn't needed in the name, since it's just a tree, and if you
> don't have child nodes it happens to become a list.)
I agree in the abstract, though it may cause developers to ask
"where's the list widget" :-).
- Maciej
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]