Re: 6 API-ish issues

[Tim Janik <timj gtk org>]

On Thu, 31 Jan 2002, Thomas Leonard wrote:

> > 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.

i second that, i have a bunch of entries in beast where focussing
really isn't desired. extreme cases where focussing is especially
annoying are:

- button3 click on the arrows of a spinner, the value gets selected
  just to be changed that very same moment
- data entry masks, these dialogs, if they have an entry as their
  first focussable widget, claim the primary selection, which makes it
  impossible to keep e.g. a selected string in an xterm and paste that
  into a couple fields which need updating

> 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.

right, i think the current situation with auto-focussing is too invasive,
it should happen on demand. 

> 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)

well, i think we really need to take a look at the usage cases here:
1) focus an entry and delete its contents or overwrite them, auto-focussing
   the entry speeds this up
2) popping up a dialog and pasting the primary selection into a field,
   auto-focussing effectively fights the user here, as it destroys the
   primary selection. i personally find this far worse than the advatages
   gained from (1)
3) editing values inbetween two (or more) paste operations. if editing
   means "change contents of an entry or a spinner", this is also fought
   by auto-focus stealing the primary and can be quite irritating since
   it's unexpected (i'm running into this on a daily basis now, and still
   get confused by it)

on the bottom line, i've come to the conclusion that the inconvenience
impact on (2) and (3) are _at least_ twice as much the benefit gained
from (1) (and then, i don't focus entry to delete its contents that often)

> -- 
> Thomas Leonard			http://rox.sourceforge.net
> tal00r ecs soton ac uk		tal197 users sourceforge net

---
ciaoTJ