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
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: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Gary Chambers [gazzaguru2@btinternet.com] 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
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" <bschwab@anest.ufl.edu> To: <Pharo-project@lists.gforge.inria.fr> 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: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Gary Chambers [gazzaguru2@btinternet.com] 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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Would be nice to separate the concept/functionality of controls from appearance/feel too... seems a bit like player/costume from EToys but more focussed. Possible to do via Theme I think. Some refactoring required though (lol). Regards, Gary ----- Original Message ----- From: "Gary Chambers" <gazzaguru2@btinternet.com> To: <Pharo-project@lists.gforge.inria.fr> Sent: Thursday, September 16, 2010 6:59 PM Subject: Re: [Pharo-project] UI states
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" <bschwab@anest.ufl.edu> To: <Pharo-project@lists.gforge.inria.fr> 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: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Gary Chambers [gazzaguru2@btinternet.com] 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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
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.
Well, that'd be a big overhaul. May as well do something compatible with CSS3 perhaps? Regards, Gary ----- Original Message ----- From: "Igor Stasenko" <siguctua@gmail.com> To: <Pharo-project@lists.gforge.inria.fr> Sent: Thursday, September 16, 2010 10:53 PM Subject: Re: [Pharo-project] UI states
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.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
On 20 September 2010 12:50, Gary Chambers <gazzaguru2@btinternet.com> 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" <siguctua@gmail.com> To: <Pharo-project@lists.gforge.inria.fr> Sent: Thursday, September 16, 2010 10:53 PM Subject: Re: [Pharo-project] UI states
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.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ 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.
Indeed. Similar "parent" lookup kind of thing though. Sticking to standard CSS names for our Report Builder XML format iwas/is quite handy though. Regards, Gary ----- Original Message ----- From: "Igor Stasenko" <siguctua@gmail.com> To: <Pharo-project@lists.gforge.inria.fr> Sent: Monday, September 20, 2010 2:02 PM Subject: Re: [Pharo-project] UI states
On 20 September 2010 12:50, Gary Chambers <gazzaguru2@btinternet.com> 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" <siguctua@gmail.com> To: <Pharo-project@lists.gforge.inria.fr> Sent: Thursday, September 16, 2010 10:53 PM Subject: Re: [Pharo-project] UI states
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.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ 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.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Yes! Alain could you publish the event hierarchy of sophie that you extracted. On Sep 16, 2010, at 7:13 PM, Gary Chambers wrote:
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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
participants (4)
-
Gary Chambers -
Igor Stasenko -
Schwab,Wilhelm K -
Stéphane Ducasse