Re: GtkButtons and RUN_FIRST/RUN_LAST
- From: Owen Taylor <otaylor redhat com>
- To: Joel Becker <jlbec evilplan org>
- Cc: gtk-devel-list gnome org
- Subject: Re: GtkButtons and RUN_FIRST/RUN_LAST
- Date: 26 Oct 2001 17:54:50 -0400
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]