Menu
▾
▴
Re: [Adobe-source-devel] asl-users: ADAM cell for default focus in a layout
|
From: Sean P. <sea...@ma...> - 2010-02-23 18:34:25
|
A few comments - set_default_focus isn't part of the standard terminology: <http://stlab.adobe.com/wiki/index.php/Layout_Terminology> There is nothing in the layout library that deals with focus - this is completely external to Eve. I had started some work on dealing with focus before I left Adobe but didn't have a chance to complete it. There is a single invariant that should hold for focus: you need to be able cycle the focus through all currently visible elements that want focus (note that on a Mac, which elements want focus can be changed in the preferences - I tend to keep my systems setting to let you tab through all controls). Maintaining this invariant is actually a bit tricky if you want to allow some way to specify what is focused next. The solution I had come up with is that the focus "ring" starts as an inorder traversal of the layout, skipping non-visible items, that circles back from the last to the first item. The only allowable operation on this cycle is to splice a give range to a particular position. This will always maintain a cycle. Having an attribute that lets you specify the default focus is questionable because this would let you specify an item that isn't currently visible. However, one could define it to be that the default focus moves to the first defaulted item in the view or the first item if a defaulted item is not visible. Anytime a focus item is hidden, the focus needs to re-find the default (or first visible). This would mean that you could have multiple defaults (say one per view). I'd like to see some UI study on any logic for setting focus beyond the above simple rule. I've seen applications remember the focus and found that a bit questionable because it means to navigate from the keyboard you really need to pay close attention, likewise, any programmatic setting of the focus would seem to work against keyboard navigation. We also know that relying on focus for UI behaviors often breaks accessibility. So my first questions would be - "why do you want to programmatically set the focus? have you done a UI study and accessibility review of this solution?" Foster is correct that the focus doesn't belong in the main sheet (but it could be in the layout sheet which can hold UI behaviors and is a full Adam sheet in recent builds). Before adding a standard "focus cell" though to the layout sheet, I'd want to get answers to the above questions. Declaring the layout sheet (or a portion of one) separate from the layout would be fairly trivial, just use a sheet description and then feed the same sheet to the layout parser. If anyone want to work on the more general problem of a mechanism for compositing sheets so you can share logic, let me know - I'd love to discuss it! Sean On Feb 23, 2010, at 9:24 AM, Foster Brereton wrote: > It belongs on the view side. Ideally the only components that exist > in the > model are the ones necessary to construct the command you are > getting the > parameters for via the UI. I say "ideally" because the property > model sheet > is a convenient place to put things related to UI state, like the > default > focus, dynamic button names, etc. I've been thinking about this some > and > wonder if we need separate sheets for the command and UI properties? > That > way the same property model sheet could be used in differing UIs > (e.g., a > dialog and a panel, akin to Photoshop's adjustment dialog/panels in > CS4.) > > This is a general question, so I'm including the SF mailing list in > on it as > well. Thoughts? > > Blessings, > Foster > > > On 22/02/10 10:28 PM, "Kumar Lomash" <kl...@ad...> wrote: > >> Hi, >> >> EVE layouts have a ‘set_default_focus’ flag which tells the EVE >> engine to give >> focus to a certain widget when the layout is shown. The problem with >> specifying this in EVE files is that we cannot decide this based on >> current >> application state, unless of course we bind it an ADAM cell which >> we can >> update dynamically, before layout is created. >> >> From a design perspective, is there an issue if UI specific >> parameters like >> default focus are dependent on ADAM cells? From a model-view >> separation >> perspective, where should the default focus flag reside – in the >> model or in >> the view? >> >> Regards, >> Lomash > > -- > Foster T. Brereton <ἰχθύς>< Ro > 3:21-26 > Computer Scientist 2 --- Photoshop Engineering --- Adobe Systems > "What 99 percent of programmers need to know is not how to build > components but how to use them." -- Alexander Stepanov > > > ------------------------------------------------------------------------------ > Download Intel® Parallel Studio Eval > Try the new software tools for yourself. Speed compiling, find bugs > proactively, and fine-tune applications for parallel performance. > See why Intel Parallel Studio got high marks during beta. > http://p.sf.net/sfu/intel-sw-dev > _______________________________________________ > Adobe-source-devel mailing list > Ado...@li... > https://lists.sourceforge.net/lists/listinfo/adobe-source-devel |
