Re: Gtk{Tree,List} replacement proposal



Maciej Stachowiak <mjs@eazel.com> writes:

> Havoc Pennington <hp@redhat.com> writes:
> 
> > Maciej Stachowiak <mjs@eazel.com> writes: 
> > > Why do you think it's way too long? 
> > 
> > Because I don't feel like typing it.
> 
> Emacs has nice symbol completion if you use ETAGS.
>  
> > Wait, I'm using C++ now... ;-)
> > 
> > > I came up with some stats for Owen
> > > a while back and there were a lot of classes in current Gtk 1.3
> > > (30-ish total?) that have names longer than this, as long, or shorter
> > > by no more than two characters (and no, it's not that heavily
> > > overbalanced to the short end).
> > > 
> > 
> > Two wrongs, right, etc.
> 
> I don't think any of the existing names are wrong. My point is that no
> one so far has bitched about the horrendously long names in Gtk+ as
> far as I have seen. People _have_ had trouble with some of the
> abbreviations not being terribly clear - for instance I've seen people
> ask what the C in CList and CTree means on several occasions. And I
> definitely think that C is more obvious than the TL in TLView.

Note that most of your examples of long class names don't have large
chunks of API. As GtkTreeListView does. Also, the number of '_'
correlates to the number of words.

the >= 40 character names in the 80 or so classes in GTK+ are
currently:

40 gtk_text_iter_backward_indexable_segment
40 gtk_text_line_previous_could_contain_tag
41 gtk_button_box_get_child_ipadding_default
41 gtk_button_box_set_child_ipadding_default
42 gtk_font_selection_dialog_get_preview_text
42 gtk_font_selection_dialog_set_preview_text
42 gtk_text_layout_move_iter_to_previous_line
43 gtk_radio_button_new_with_label_from_widget

GtkTreeListView would add:

42 gtk_tree_list_view_column_set_title_active
43 gtk_tree_list_view_column_get_justification
43 gtk_tree_list_view_column_set_justification
43 gtk_tree_list_view_columns_set_title_active
44 gtk_tree_list_view_column_get_preferred_size

Just for one widget... just to prove my point that it 
is a loong class name. But, more than being long, my
contention would be that gtk_tree_list_view loses
coherency.

I see 'TL' as just a name - not an abbreviation. It doesn't
necessarily matter what it stands for, and allows people to group
together a group of related classes and data structures

 GtkTLView
 GtkTLCell
 GtkTLModel
 GtkTLNode

Etc. In fact, I was a little suprised to see GtkTreeView, not
GtkTLViewTree.

GtkTreeListView takes away the sense of 'a name'. And also,
what's a tree-list? If we were spelling it out, I would
expect GtkTreeOrListView.

I wouldn't object to havoc's suggestion of just going with GtkTree*
everywhere except for GtkListModel. The only real problem is confusion
with the existing GtkCTree and GtkTree. (And the problem that people
probably, in general, don't think of lists as special cases of trees.)

(Which we accepted for GtkText on the grounds that the existing
GtkText was going away. And GtkTree needs to go away too.)

But, I think GtkTL* works pretty well.

Regards,
                                        Owen




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