Re: 6 API-ish issues

[Owen Taylor <otaylor redhat com>]

Thomas Leonard <tal00r ecs soton ac uk> writes:

> > Thinking about this some more, it would be a real pain to not select
> > since the ::grab-focus action signal needs to select the contents of
> > the target widget; so, it's almost impossible for the entry to
> > tell whether a call to ->grab_focus() comes from the user or programmer.
> > 
> > Considering that I think the right thing to do is virtually always to
> > select, and making gtk_widget_grab_focus() not select would be quite
> > hard to implement, I think it's pretty clear that we should leave
> > it the way it is for now.
> > 
> > Maybe in a future version, we can add some
> > gtk_entry_focus_without_selecting() call.
> 
> I don't think this helps. Whether the contents of an entry should be
> selected depends on what it's used for, not how the focus entered it.
> 
> Eg, in ROX-Filer's pathname box (which shows the current directory and
> filename), the text should never be automatically selected. Not from a
> grab_focus; not from a Tab; not from a mouse click.
> 
> I quite like Tim's solution:
> 
> typedef enum
> {
> 	GTK_TEXT_SELECTION_NONE,
> 	GTK_TEXT_SELECTION_FOCUS,
> 	GTK_TEXT_SELECTION_THEMABLE
> } GtkTextSelectionType;
> 
> Themable would be the default, presumably. Actually, I'm not sure there's
> much need for 'Focus'. If the default theme always selects, then this
> would only even change the behaviour for someone who had explicity
> disabled auto-selection (ie, because they hate it). Also, if a programmer
> really wants to force the selection then they can do that manually.

Themeable doesn't (to me) make sense. Themes are about appearance, not
about behavior. Behavior really should be mostly predictable by the
application writer if we're going to have a will integrated user 
interface.

There may be specialized applications, where people are playing tricks
with GtkEntry where turning off the focus-in behavior is desirable.
I'm hesitant to make it easy to do, because the result will be
that some application authors will turn it off for their entries
because they don't like the behavior, and then their won't be consistency
and users will lose.
 
> However, it's currently quite difficult to make an entry that doesn't
> destroy the primary selection, even if you remove the selection as soon as
> the entry gets the focus. (although it is possible to hack around it)

I think for the vast majority of users, we will get a lot more mileage 
by trying to make CLIPBOARD work really well, and keynav work really
well, then trying to optimize for PRIMARY.

I guess it might make sense to add a X-head GtkSetting:

 gtk-select-on-focus-in 

(Defaulting to TRUE). In this case, it would turn off selection on focus-in
entirely. If you are a primary-selection-loving lots-of-mousing person,
then you probably won't miss it.

Regards,
                                        Owen