Re: GtkButtons and RUN_FIRST/RUN_LAST

[Manish Singh <yosh gimp org>]

On Fri, Oct 26, 2001 at 05:54:50PM -0400, Owen Taylor wrote:
> 
> Joel Becker <jlbec evilplan org> writes:
> > What he wanted was "when clicked, set my variable to the selected item,
> > then exit".  What he gets is "Start the exit, but as the signal unwinds
> > my variable gets set anyway".  Right behavior, kinda screwey semantic.
> > I have the feeling someone will get bitten by this out-of-order run.
> 
> Note that such a UI does _not_ work one bit with our current keynav
> since to go from option 1 to option 3 you need to go through option 2.
> 
> Creating a user interface where selecting a radio button does
> something without requiring an additional "move forward" step
> is awful UI design, and supporting it doesn't bother me much ;-)
> 
> Especially if the option I wanted was already selected - I'd 
> never figure out how to get the UI to do anything...

Yeah, I realize that. The jury's still out whether to use that behavior
or not.

Thing is, when you're setting up 1500 machines, having to do 1 mouseclick
vs. 2 saves you a lot of time. I can also envision this being useful in a
touch screen situation, or anywhere you want a radio button "look" but an
action button "feel". It does make sense in certain situations.

At this point, everything works for me with current GTK+, so I'm not
really as concerned as I was before, but something still doesn't sit right
about the states not being resolved in a ::clicked user handler.

-Yosh