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