Re: GtkButtons and RUN_FIRST/RUN_LAST



Joel Becker <jlbec evilplan org> writes:

> On Fri, Oct 26, 2001 at 05:30:50PM -0400, Owen Taylor wrote:
> > OK, two comments here:
> > 
> >  - The new ::clicked semantic is _exactly_ designed to make doing
> >    this type of thing easy. Instead of setting things back 
> >    you can do your own thing and simply stop_emit.
> 
> 	Ok, that makes sense.  I saw the stop_emit thing.  But I still
> think folks are going to naively see the state as a foregone conclusion.
> Never mind the trace you see on a toggle button:
> 
> user_clicked(a)
> default_clicked(a)
>   default_toggled(a)
>   user_toggled(a)
> 
> So what yosh sees in a one-click-exit radio setup is:
> 
> user_clicked(a)
> {
>     gtk_main_quit();
> }
> default_clicked(a)
> {
>     set_state();
>     default_toggeld(a);
>     user_toggled(a)
>     {
>         update_my_result_var(a);
>     }
> }
> 
> 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...

Regards,
                                        Owen



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