UI states

> Gary,
>
> Questions more than thoughts :)  Are the Mouse*Outside states for mouse
> capture?  Otherwise, would there not be another owner?  Just checking.
> Are these symbols, or are you thinkng of reifying them so they can provide
> behavior?
>
> If you are planning a major revision, please telegraph that (or consider
> this a warning to keep it a secret<g>) so we can discuss questions of MVP
> or similar design considerations.
>
> At some point, I begin to wonder whether we should just go native via wx
> or a similar framework.  The good part about it for the Squeak in Pharo
> would be to force discipline of an event queue, input focus, modality when
> it applies, hopefully put an end to polling, etc.  I am not a knee-jerk
> believer in "native is faster."  In fact, I ended up emulating widgets in
> Dolphin specifically to get speed!  Perhaps one has to go to very large
> number of sub-widgets for that to matter, but it does eventually arise.
> Even with that concern, I think we would be better off using one native
> window per tool; whether or not each pane and control should be native is
> up to interpretation.  Not doing it because we haven't is not a great
> idea, nor is doing whether or not we should.  Comments?
>
> Bill
>
>
> ________________________________________
> From: [hidden email]
> [[hidden email]] On Behalf Of Gary Chambers
> [[hidden email]]
> Sent: Thursday, September 16, 2010 1:13 PM
> To: Pharo Development
> Subject: [Pharo-project] UI states
>
> 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.
>
> Regards, Gary
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project 

> Native would have these state (mostly).
> I think the "toolbox" set should support this (mostly there at the
> moment).
> In terms of Morphic this is mirrored *and* orthogonal to native stuff...
> I think what I proposed is pretty much the superset accross native
> platforms. Supporting that would, hopefully, reduce the "least common
> denominator" problem with respect to native controls.
>
> Regards, Gary
>
> ----- Original Message -----
> From: "Schwab,Wilhelm K" <[hidden email]>
> To: <[hidden email]>
> Sent: Thursday, September 16, 2010 6:34 PM
> Subject: Re: [Pharo-project] UI states
>
>
>> Gary,
>>
>> Questions more than thoughts :)  Are the Mouse*Outside states for mouse
>> capture?  Otherwise, would there not be another owner?  Just checking.
>> Are these symbols, or are you thinkng of reifying them so they can
>> provide behavior?
>>
>> If you are planning a major revision, please telegraph that (or consider
>> this a warning to keep it a secret<g>) so we can discuss questions of MVP
>> or similar design considerations.
>>
>> At some point, I begin to wonder whether we should just go native via wx
>> or a similar framework.  The good part about it for the Squeak in Pharo
>> would be to force discipline of an event queue, input focus, modality
>> when it applies, hopefully put an end to polling, etc.  I am not a
>> knee-jerk believer in "native is faster."  In fact, I ended up emulating
>> widgets in Dolphin specifically to get speed!  Perhaps one has to go to
>> very large number of sub-widgets for that to matter, but it does
>> eventually arise. Even with that concern, I think we would be better off
>> using one native window per tool; whether or not each pane and control
>> should be native is up to interpretation.  Not doing it because we
>> haven't is not a great idea, nor is doing whether or not we should.
>> Comments?
>>
>> Bill
>>
>>
>> ________________________________________
>> From: [hidden email]
>> [[hidden email]] On Behalf Of Gary Chambers
>> [[hidden email]]
>> Sent: Thursday, September 16, 2010 1:13 PM
>> To: Pharo Development
>> Subject: [Pharo-project] UI states
>>
>> 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.
>>
>> Regards, Gary
>>
>> _______________________________________________
>> Pharo-project mailing list
>> [hidden email]
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project 

> 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.
>

> 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.
>  
> Regards, Gary
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

> 2010/9/16 Gary Chambers <[hidden email]>:
>> 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
>> [hidden email]
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>
>
>
>
> --
> Best regards,
> Igor Stasenko AKA sig.
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project 

> Regards, Gary
>
> ----- Original Message ----- From: "Igor Stasenko" <[hidden email]>
> To: <[hidden email]>
> Sent: Thursday, September 16, 2010 10:53 PM
> Subject: Re: [Pharo-project] UI states
>
>
>> 2010/9/16 Gary Chambers <[hidden email]>:
>>>
>>> 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
>>> [hidden email]
>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>>
>>
>>
>>
>> --
>> Best regards,
>> Igor Stasenko AKA sig.
>>
>> _______________________________________________
>> Pharo-project mailing list
>> [hidden email]
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>

> On 20 September 2010 12:50, Gary Chambers <[hidden email]>
> 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" <[hidden email]>
>> To: <[hidden email]>
>> Sent: Thursday, September 16, 2010 10:53 PM
>> Subject: Re: [Pharo-project] UI states
>>
>>
>>> 2010/9/16 Gary Chambers <[hidden email]>:
>>>>
>>>> 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
>>>> [hidden email]
>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>>>
>>>
>>>
>>>
>>> --
>>> Best regards,
>>> Igor Stasenko AKA sig.
>>>
>>> _______________________________________________
>>> Pharo-project mailing list
>>> [hidden email]
>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>
>>
>> _______________________________________________
>> Pharo-project mailing list
>> [hidden email]
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>
>
>
>
> --
> Best regards,
> Igor Stasenko AKA sig.
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project