That's a good point. I'll add some more javadocs to the classes to show usage scenarios. Given pivot's current position, it is too application specific which is why it is bundled as a code-based extension (perhaps not the right word). I am not recommending this go into pivot today because I think the action framework in there today will evolve over time and needs motivation across a wide range of applications. For a UI framework, my personal view is that you have to eventually pick a path to drive marketplace acceptance--just not today for pivot because it is still new. I think this is the "spoon-feeding" view of the world. This is a separate, product marketing discussion.
I was just responding to Chris's comments around how to add a flexible key-binding capability (some default for a wide range of objects) easily to other components and still be reusable. As commented, however, specific keystrokes and the specific mechanism of typing together keystrokes and actions are application specific as well. The keystroke for tabbing between tab panes is different in apps, web browsers and IDEs. Having the semantic action already programmed (changing the current tab pane) is good, but making it rigidly tied to the keystroke is probably less good. Yes, there is nothing new because there can be nothing new without changing core pivot. To library writers, I would expect that point of view. However, as a consumer of the library, I just add one line of code/script/xml (or none at all) and get full keystroke-action binding. That's a nice thing. That's really all I am advocating...when something needs to be added, have multiple paths to deploy it. For example, serializer subclassing provides a different path that was important enough to spend time sending emails to this list and in the end, I hope, to warrant the time reading the emails. Bindable only works on the root object of the serializer and does not have the proper link to the component to initialize off of it (if I remember the issue correctly). In fact, pivot also uses the Bindable interface to tag an object that is requesting a bind() to be automatically applied to it in addition to calling initialize(). If you extend the Bindable concept to every object and make it so that it does not require source code access to make the initialize happen, then that works for me. In fact, as initialization logic, Bindable imposes a number of constraints on your objects and deployment model. I agree that for API, it should be pivot. I'll blame this on my IDE :-) Perhaps as a working example, I'll send out pivotpad the application although it's a simple app. At least I have line numbering working! -----Original Message----- From: Greg Brown [mailto:gkbr...@mac.com] Sent: Sunday, June 20, 2010 10:31 AM To: dev@pivot.apache.org Subject: Re: Pivot components & the keyboard Not sure if you are suggesting adding something like this to the platform or not, but based on what I have seen so far I think it may be a bit too application-specific. A couple of the features seem to rely heavily on Component user data, which is entirely the domain of the application (the platform itself should not have any dependency on it). Also, I'm still not entirely clear on what advantage the @PivotComponentExtension annotation offers over the existing Bindable approach. It is also tied specifically to Component, so (as-is) it couldn't be added to org.apache.pivot.beans. Finally, at least one of the classes uses java.util.List and java.util.ArrayList. In general, we prefer to use the classes from org.apache.pivot.collections rather than those from java.util in platform code. In any case, some concrete examples of how this might be used in practice would be helpful (specifically, some BXML and Java code that demonstrates how these classes are applied). I think that would make it much easier to understand the higher level intent. G On Jun 19, 2010, at 2:25 PM, aappddeevv wrote: > I've attached the zip to this email with a few example classes: one for > general purpose keystroke handling and another for inherited styles. I don't > know if zip files works well or not for this email list though. I placed > more comments in the command binding class than the other one. There are > several approaches for attaching behavior to components and that's described > in the javadoc. The tabpane bindings version I use is also included but it > the same thing can be programmed without a subclass. This tabpane version is > all java code but you could also have used script and/or script includes. > > The serializer class uses an "injection initialization" approach. The idea > behind some of my chatter on the list is to put this approach on par with > scripting and java code programming initialization. Some changes in the > serializer were needed to allow this to happen. Scripting, includes and > standard listener programming already works by default of course. > > The approaches to enabling common behavior all have different pro/cons > around deployment to clients and ease-of-reuse. The serializer relies on > fixes that are not in the general release yet so it cannot be used. It > paints a picture of a transparent approach to configuring behavior. Again, > all with pros and cons. > > > > > > -----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 >> >> > <pivot-notes.zip>
