On 20 September 2010 12:50, Gary Chambers <[email protected]> wrote: > Well, that'd be a big overhaul. May as well do something compatible with > CSS3 perhaps? >
Yeah this would be a lot of work :) Concerning CSS3, this i thinks is orthogonal, since in CSS you actually describing the style(s) of element (morph in our case), depending on their context and/or state. While i was talking mostly about managing the morph states, not the way how you managing the style information attached to them. > Regards, Gary > > ----- Original Message ----- From: "Igor Stasenko" <[email protected]> > To: <[email protected]> > Sent: Thursday, September 16, 2010 10:53 PM > Subject: Re: [Pharo-project] UI states > > >> 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 > > > _______________________________________________ > 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
