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" <[email protected]>
To: <[email protected]>
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" <[email protected]>
To: <[email protected]>
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: [email protected]
[[email protected]] On Behalf Of Gary Chambers
[[email protected]]
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
[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
_______________________________________________
Pharo-project mailing list
[email protected]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
