No. For key-action handling, you can think of it as a "skin delegate" for key-action handling. Some people may say that key-action handling is actually a controller responsibility though.
If you think of skin, it has a "install(Component)" method. It installs itself into the component. So a skin is really an add-on that happens to have an important role and most importantly, a place to attach the skin on the component object with an "initialization" protocol. So for other areas, like key-action handling, you can place your extension into user data (or use wtkx:define) and through a small extension to the serializer that is supported through its "createInstance" method, allows you to call an initialization process, essentially the "install(Component)" method. As long as you stick to public API, you can install these new behaviors and use user-data to provide configuration data e.g. keystroke-action pair specifications. I think offering code for inclusion is great. I was concerned that what I would like to see was too app specific. So another choice is bundling it into something that can be inserted into components (or whatever deployment model you wish to use) at the moment was the way I saw it easier to contribute without requiring a "consumer/programmer" to touch skins. There are 2-3 ways to your last question and I think the nice thing about pivot is you have a few ways to do this: skins, script, includes, subclassing and "component extensions." In other toolkits, you have fewer options and they are not flexible. I'll post the code. But I'll add some more javadoc first. -----Original Message----- From: Chris Bartlett [mailto:cbartlet...@googlemail.com] Sent: Friday, June 18, 2010 10:42 AM To: dev@pivot.apache.org Subject: Re: Pivot components & the keyboard Yes, I would certainly be interested seeing what you have done, and I'm sure others might also. Is your approach a way to move the functionality away from the skin classes? The various bits of component functionality that I described in my previous post are ones that I have either already written or plan to. My intention was to offer the code for inclusion in the Terra theme skins if it was wanted. However I have been thinking about how best to make use of the existing Pivot components whilst still being able to apply my own customizations. Chris On Fri, Jun 18, 2010 at 11:21 PM, aappddeevv <aappdde...@verizon.net> wrote: > Chris, > > I ran into this issue as well. It turns out that you can a tiny bit of > pluming and make this happen transparently across all components in pivot. > > I think pivot will have to make choices to provide closer-to-the-user-app > API to make an "easy" layer for folks, but I am not convinced that this is > the right point in the maturity of pivot to pick-winners yes despite our > desires for pivot to do so. I think this is a classic tension between > people > like us and the core library team. > > If you want, I can pass along the approach to add behaviors to component's > using a specific cross-cutting injection model and how to transparently > apply it to the components below. Its all configurable at the component > level which is where I think the capability needs to be at to create better > decoupling. > > The only issue really becomes whether the component supports the specific > behavior you want i.e. is there a selectAll-like method on a ListView. You > may have to write that "handler" yourself if its not in the component > already. This approach has code for working with keyboard handling today, > but I am finalizing the design pattern for common command > invocation/execution patterns. GregB made a change to the serializer for > the > API you need to deal with this. > > > > > -----Original Message----- > From: Chris Bartlett [mailto:cbartlet...@googlemail.com] > Sent: Friday, June 18, 2010 9:23 AM > To: dev@pivot.apache.org > Subject: Re: Pivot components & the keyboard > > Please see below for my comments having quickly reviewed all of the Pivot > components (from trunk) that I could think of. > I ignored TextArea as it is still under active development > Apologies in advance for the long list. > > Regards, > > Chris > > Can you provide some specific examples? Some (generic) keyboard shortcuts > > make sense at the component level, but others are specific to an > individual > > app. The easiest way to create application-specific shortcuts is to add > > entries to your main window's action mappings. See > > Window#getActionMappings() - it returns a sequence of > Window.ActionMapping > > that you can populate to associate keystrokes with actions. > > > > Greg > > > > > > > Navigation Containers > > > Accordion > - Ability to navigate between panels with keys > - Up/Down arrows to decrement/increment the selected panel index > - Home & End to select the first or last panel respectively > - Possibly require a modifier such as Control? > - Needs to be focusable first > > > Expander > - Spacebar to expand/collapse > - Needs to be focusable first > > > Panorama > - Ability to navigate with keys > - Up//Down/Left/Right > - Optional modifier key to adjust using an increased step size > - Needs to be focusable first > > > Rollup > - Spacebar to expand/collapse > - Needs to be focusable first > > > TabPane > - Control+Tab & Control+Shift+Tab > - Next & previous enabled tabs > - Needs to be focusable first > > > > Components (widgets) > > > LinkButton > - Space to select > - Needs to be focusable first > > > ListButton > - Alt+Down arrow to show the list > > > ListView > - Home & End to select (and scroll to) first/last item respectively > Use of a modifier to determine whether to jump to only enabled items > Would also need to respect the current Shift modifier to increase the > selection > - Control+A to select all items (on multi-select lists) > Use of a further modifier to determine whether to select only enabled items > - Modify the logic in TerraListViewSkin.keyReleased() so that the selection > loops back to the first matching item if there are no more matchin items > with a higher list index > - Addition of a style/property which would make list view selection with > the > up/down arrow keys loop from the first to the last item & vice versa > This behaviour is already implented in Spinner with the the 'circular' > property > -- If this is added, enable it for ListViews used internally within the > skins for the following components (which are unlikely to contain > relatively > small lists which would benefit) > ListButton > MenuBar > MenuButton > SuggestionPopup > > > RadioButton > - Ability to change focus within the button group with arrow keys > - Up and/or Left to focus on previous button > - Down and/or Right to focus on next button > - Home & End to focus on first & last button respectively > > > Slider > - Home & End to set the value to start/end respectively > > > TableView > - Home & End to select (and scroll to) first/last row respectively > Use of a modifier to determine whether to jump to only enabled rows > Would also need to respect the current Shift modifier to increase the > selection > - Control+A to select all rows (on multi-select lists) > Use of a further modifier to determine whether to select only enabled rows > - Select row matching a pressed key (as per ListView) > Loop the selection so that if there are 3 rows beginning with the letter > 'a' > and the last one is selected, the selection would jump to the first row of > the 3 > If the TableView is sorted, then use the sorted column as the source of the > value to be compared with the pressed key > If not, use first visible text column > If no visible text columns, either use a toString() or take no action > > > TextInput > - Control+Left/Right to position caret at start of previous/next word > - Shit+Control+Left/Right position the caret at start of previous/next word > and expand the selection span > > > TreeView > - Home & End to select (and scroll to) first/last node respectively > (without > expanding any branches) > (Use of a modifier to determine whether to jump to only enabled nodes) > - Control+A to select all items (on multi-select trees) > Use of a further modifier to determine whether to select only enabled nodes > - Select sibling matching a pressed key (as per ListView) > Loop the selection so that if there are 3 nodes beginning with the letter > 'a' and the last one is selected, the selection would jump to the first > node > of the 3 > - Left arrow > If selected node is an open branch, close it (existing functionality) > If selected node is a closed branch or a leaf, select the parent branch > - Control + Up/Down > Jump to the previous or next *sibling* of current node, ignoring any > visible > children in opened branches > >
