2010/9/16 Gary Chambers <[email protected]>:
I might be nice for the appearance of all controls, windows etc. to
adhere
to a standard set of UI states as identified:
Enabled
Enabled Mouse over
Enabled Mouse down inside
Enabled Mouse down outside (*)
Enabled Selected
Enabled Selected Mouse over
Enabled Selected Mouse down inside
Enabled Selected Mouse down outside (*)
Disabled
Disabled Mouse over (*)
Disabled Mouse down inside (*)
Disabled Mouse down outside (*)
Disabled Selected
Disabled Selected Mouse over (*)
Disabled Selected Mouse down inside (*)
Disabled Selected Mouse down outside (*)
And repeat for additional "inactive" (non-primary/top window)
(*) indicates a nice to have, rather than strictly necessary...
Thoughts appreciated beforehand. Anything missing, suggestions for
fallback
(don't want to have to do all for everything)?...
Perhpas worth a tutorial/help/etc. for those making new widgets.
I'm sure I discussed this with Igor before, but not sure I had a
response.
We discussed a lot before, so i am also not sure if we touched this
topic before :)
My own (1 year old) idea about states is different.
In short: a widget state is better to describe not by a set of flags
(disabled/enabled, mouse over/out etc etc),
but with stack of modes, where topmost mode (on stack) having a
greater preference above those which follow.
Then you can easily control the widget appearance depending on modes.
An example.
By default, you rendering a button using blue color.
When mouse is over it, you render it with light-blue color.
When button is disabled, you render it with gray color, regardless if
mouse over or not over it.
From the above description, its easy to compose a right stack of
modes, which affecting the widget appearance:
initially, a stack is empty( we assume default mode on stack)
- default mode (blue background)
when mouse enters a widget, you simply pushing a new mode on widget's
mode stack:
- mouse over(light-blue)
- default mode (blue background)
and when it leaves, in response to such event, you simply removing the
corresponding mode from stack:
- default mode (blue background)
But one things with disabled dome, that you want a 'disabled mode' to
be always on top of the mode stack,
regardless of any other modes, which means that you likely don't wanna
have:
- mouse over(light-blue)
- disabled(gray)
- default mode (blue background)
but always want
- disabled(gray)
- mouse over(light-blue)
...
- default mode (blue background)
so, a color, attached to it is always takes a preference.
To deal with this, we need just one more rule: each mode having a
priority , or (weight),
and a simple rule, that when you pushing a mode with lower priority
than currently on top of the stack,
you insert it after the mode of highest priority you met, so then,
when you have it like following:
- disabled(100)
- default (0)
and mouse enters the widget, you making a 'mouseover' mode to have >0
but < 100 priority value,
so it is always pushed after disabled.
- disabled(100)
- mouseover(1)
- default (0)
in addition to that, in my experimental project, i can attach any
attribute to mode(s), so it is more like
a set of css rules (a:hover, a:link ...) , so i can even say that in
disabled mode i don't even want to react on
a mouse enter/leave events so i don't need to be bothered by using
priorities, because mouseover mode is
never get pushed on mode stack.
The next thing, what i'd like to tell more about modes and styles:
to render a widget, i start looking for some property (like background
color) along the mode stack.
And if topmost mode does not defining it, then i going down the stack
and querying this property for next mode.
Then finally, if its defined nowhere, it goes down to default mode,
where it should answer a default value.
In this way i have a quite flexible way to define a styles. I can
change a various properties for one mode, but leave the rest
untouched.
More on top of that, i am even can modify a property value(s),
returned by mode with sits down the stack.. but i think this is too
much
for this mail.
I just wanted to show you how much more flexibility you can get by
using this model :)
Regards, Gary
_______________________________________________
Pharo-project mailing list
[email protected]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
--
Best regards,
Igor Stasenko AKA sig.
_______________________________________________
Pharo-project mailing list
[email protected]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
