Re: MVC and GTK

[Paul Barton-Davis <pbd Op Net>]

>If you want to simulate this, just change the state of the button
>back. There will be a tiny flicker, but since the user pressed
>the button and expected something to happen that isn't a problem.

this is the kind of thing that gets written up in reviews in trade
magazines in the niche i'm working in. i'd rather not :)

>Remember, that in any case, this sort of thing is a horrible UI for
>the user. If the button is sensitive, then they should be allowed to
>change it.  The only excuse for wanting to do this would be if the act
>of changing the button encountered an error.

I don't agree at all here, though perhaps the right thing is to
implement a wholly different kind of button. Buttons are Controls, and
sometimes Views as well (mostly just toggle buttons). The whole
concept of "sensitive => it does what the user expects" ignores the
possibility that the Button is a C+V and that the underlying object
has much more complicated semantics than "when i tell you to do this
you will". I consider that pressing buttons with h/w like semantics
should obey h/w like behaviour: sometimes, it just doesn't do anything
(because of some other control being set). there may or may not need
to be an error message, depending on how unintuitive the failure to
act is for the user.
 
>>         gtk_signal_emit_stop_by_name (GTK_OBJECT(button), 
>> 				      "button_press_event");
>> }
>> 
>> then we have a handler for the state change as shown above. 
>
>This is absolutely evil. Don't do it. If you doubt me on that,
>in your app, tab to the button and hit the space bar...

heh. there is a line of code that is duplicating itself all over my
code:
	
	foobar->unset_flags (GTK_CAN_FOCUS);

you've probably seen my comments about focus here before. i don't like
it, though my case in relatively unique. my GUI's sometimes have
several hundred focusable widgets in them: the notion that you can
navigate them from the keyboard is laughable. handling keyboard focus
is something that in my case needs to be done by an
application-specific handler, not a generic idea of "focus". its been
quite a pain to get this to work, but its slowly emerging within
ardour (my digital audio workstation app). if i could turn off focus
handling completely within GTK, I probably would.

did i complain enough about prelight as well ? the amount of code i
have to add to turn this off is crazy too. again, toggle buttons are
the worst offender: there is only one prelight state, yet the button
could be active or not, causing considerable confusion if the button
is activated and the mouse pointer left over it: you never see the
active state displayed till the mouse pointed is moved.

>IMO, alternative ways of setting up togglebuttons would add
>a lot of complexity that isn't needed, except in some sense
>of ideological purity, and would be less convenient for the
>common case.

Very true.

>An observation I've heard about Swing is that Model-View is convenient
>for the big widgets, and a pain for the little widgets.

Also very true, though I think the distinction is more dependent on
what the widgets are controlling than their size. It just so happens
that "big" widgets tend to control more stateful/semantically-complex
Models than little widgets do.

>For GTK+-2.0, we'll be introducing Model-View widgets for 
>the multi-line text edit and list/tree widgets, but I don't
>see making things like GtkToggleButton Model-View.

"Yay!" for the list/tree widgets. They are a much better example of a
place where there are MVC design problems, though actually, I've
generally managed to deal with this with the Large Hammer To The Head
approach: 

void
on_change ()

{
	clist->freeze ();
	clist->clear ();
	refill_clist ();
	clist->thaw ();
}

not very efficient, but i haven't encountered a case yet where its a
problem. 

thanks for your continuing thoughts on all this.

--p