Re: 6 API-ish issues

[Thomas Leonard <tal00r ecs soton ac uk>]

Owen Taylor <otaylor redhat com> wrote:

> Over the last few weeks, a number of API-related issues have shown up
> that are either:
> 
>  - Small enough that they might be worth sneaking in
>  - Important enough that they might be worth sneaking in
> 
> I'd like to solicit feedback about the following bugs, either positive
> ("Without this change, my life is meaningless!") or negative
> ("What idiot would make this change after you've declared an API
> freeze???")

>  * 68174 GtkEntry focus/selection problem
> 
>    Bug wants gtk_widget_grab_focus (entry) not to select the text in the
>    entry. I think you generally want the selection, but should we
>    force apps to do that themselves? Is there ever a
>    reason for an _app_ to know that it should't select the text
>    in one particular case?
> 
>    (The main objections is wanting to maintain the contents of PRIMARY,
>    the solution here is to train users to use the clipboard...)
> 
>      http://bugzilla.gnome.org/show_bug.cgi?id=68174

I hit this problem too in several places.

First, we allow the user to start typing a file name to move the cursor to
that file (possibly because they want to add it to the selection).
However, as soon as the entry appears:

- The entire pathname in the entry was selected, even though we wanted the
  cursor at the end so they could add to it.

- The current selection was lost.

We fixed this by connecting to the "grab-focus" signal; the handler does
this:

	class = GTK_WIDGET_CLASS(gtk_type_class(GTK_TYPE_WIDGET));
	class->grab_focus(minibuffer);
	gtk_signal_emit_stop_by_name(GTK_OBJECT(minibuffer),
					"grab_focus");

which seems to fix the problem.

Another problem is when you try to open a dialog box that acts on the
selection, eg:

- Opening the Copy dialog box in ROX-Filer causes the selection to be
  lost. However, when we added a selected-but-no-longer-primary state to
  the filer selection (at the request of Gtk+-1.2 users) that fixed the
  problems for 2.0 as well.

Generally, I'd prefer it if Gtk+ didn't try to select the text itself, as
it's easy enough to code it where it's needed.

This sometimes applies to tabbing, too. Eg, tabbing into a pathname box
should normally either put the cursor at the end, or only select the last
component of the path. It should not select the complete string. I guess
this can be worked around in a similar way, though.

Perhaps a don't-auto-select property for entries would be useful...

One other problem with GtkEntries is that you can't (as far as I can see)
give the keyboard focus to an entry by clicking on it. If you click with
the left or middle buttons then the selection (in the entry) is lost;
clicking with the right button works but pops up a menu too. I think that
focussing an entry with the selection shouldn't clear the selection.

A final problem is that the new text widget doesn't yet support the
selected-but-no-longer-primary state. Thus, opening the Save Selection box
in the text editor clears the selection!

My current fix is to copy the selected text to a buffer and save that.
However, this is still annoying because a) the user loses their selection
b) they can't see what they're saving and c) if they change the selection
before saving then it doesn't save what they expect it to. Still, I guess
it's too late to fix this for 2.0.

Anyway, it would be nice to see these issues fixed, but we're prepared to
work around them, as always ;-)


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