2010/9/16 Gary Chambers <gazzaguru2@btinternet.com>:
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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.