You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@pivot.apache.org by Chris Bartlett <cb...@googlemail.com> on 2010/06/17 21:46:20 UTC
Pivot components & the keyboard
With regard to keyboard usage, have Pivot components been written with any
particular guidelines or OS style behaviour in mind?
I favour keyboard navigation in applications and would like to enrich my
Pivot apps with numerous keyboard shortcuts at the component level. Many
would be based on what I have seen or used in other apps and various OSs,
but some are just ones that I created to meet my own needs.
If there is a resource detailing the preferred keyboard based functionality
& associated key combinations, then I'll take a look at that and filter the
patches accordingly.
In order to submit patches for the various shortcuts, is it preferable to
open a single jira ticket covering all effected components or one ticket per
component?
Regards,
Chris
Re: Pivot components & the keyboard
Posted by Greg Brown <gk...@mac.com>.
Not a problem. Thanks for the clarification. :-)
On Jun 18, 2010, at 1:33 PM, aappddeevv wrote:
> Not meant to be divisive but a recognition the separation between focus,
> needs and economics often creates an intentional gap or a temporary gap but
> needs to fulfilled to meet specific end-user needs.
>
> Never assumed it was going sour. Tension and issues are never inherently bad
> but just trade-offs on gaps and planning points to "consumers" of core
> libraries like pivot. I can see, however, where the word tension in this
> context may have implied something negative.
>
> Thanks for allowing me to clarify my comments.
>
>
> -----Original Message-----
> From: Greg Brown [mailto:gkbrown@mac.com]
> Sent: Friday, June 18, 2010 10:32 AM
> To: dev@pivot.apache.org
> Subject: Re: Pivot components & the keyboard
>
>> I think this is a classic tension between people
>> like us and the core library team.
>
> No offense meant, but this comes across as a bit divisive. There hasn't even
> been any real discussion of this issue yet - why would you assume that there
> would be tension?
>
> I'm not saying there won't be any disagreement about approach (to this issue
> or others like it), but I'd suggest that we actually have the discussion
> before assuming that it is going to go sour. ;-)
>
RE: Pivot components & the keyboard
Posted by aappddeevv <aa...@verizon.net>.
Not meant to be divisive but a recognition the separation between focus,
needs and economics often creates an intentional gap or a temporary gap but
needs to fulfilled to meet specific end-user needs.
Never assumed it was going sour. Tension and issues are never inherently bad
but just trade-offs on gaps and planning points to "consumers" of core
libraries like pivot. I can see, however, where the word tension in this
context may have implied something negative.
Thanks for allowing me to clarify my comments.
-----Original Message-----
From: Greg Brown [mailto:gkbrown@mac.com]
Sent: Friday, June 18, 2010 10:32 AM
To: dev@pivot.apache.org
Subject: Re: Pivot components & the keyboard
> I think this is a classic tension between people
> like us and the core library team.
No offense meant, but this comes across as a bit divisive. There hasn't even
been any real discussion of this issue yet - why would you assume that there
would be tension?
I'm not saying there won't be any disagreement about approach (to this issue
or others like it), but I'd suggest that we actually have the discussion
before assuming that it is going to go sour. ;-)
Re: Pivot components & the keyboard
Posted by Greg Brown <gk...@mac.com>.
> I think this is a classic tension between people
> like us and the core library team.
No offense meant, but this comes across as a bit divisive. There hasn't even been any real discussion of this issue yet - why would you assume that there would be tension?
I'm not saying there won't be any disagreement about approach (to this issue or others like it), but I'd suggest that we actually have the discussion before assuming that it is going to go sour. ;-)
Re: Pivot components & the keyboard
Posted by Greg Brown <gk...@mac.com>.
I haven't given this a lot of thought yet, but the primary challenge here is cross-platform compatibility. While "Control-A" may work for Windows users, Mac users are accustomed to "Command-A". I suspect that some of these keyboard shortcuts may be appropriate for the skin while others may be best left to the application.
It shouldn't be terribly difficult to add your own handlers - all you need to do is create an instance of the appropriate listener interface and attach it to your component. This is often done via anonymous inner classes or inline script, but it could also be done via a non-anonymous class if you want to share the logic across multiple components:
public class TestButtonPressListener implements ButtonPressListener {
@Override
public void buttonPressed(Button button) {
Alert.alert("You clicked me!", button.getWindow());
}
}
<Window title="Event Listener Test" maximized="true"
xmlns:bxml="http://pivot.apache.org/bxml"
xmlns:tests="org.apache.pivot.tests"
xmlns="org.apache.pivot.wtk">
<BoxPane>
<PushButton buttonData="1">
<buttonPressListeners>
<tests:TestButtonPressListener/>
</buttonPressListeners>
</PushButton>
<PushButton buttonData="2">
<buttonPressListeners>
<tests:TestButtonPressListener/>
</buttonPressListeners>
</PushButton>
</BoxPane>
</Window>
Now, the downside to this is that a new instance of the listener is created for each button. It would be more efficient to create a single instance of the listener and share that across multiple components. That isn't currently supported, but it could be accomplished via a hypothetical addition to BeanSerializer:
<Window title="Event Listener Test" maximized="true"
xmlns:bxml="http://pivot.apache.org/bxml"
xmlns:tests="org.apache.pivot.tests"
xmlns="org.apache.pivot.wtk">
<bxml:define>
<tests:TestButtonPressListener bxml:id="myListener"/>
</bxml:define>
<BoxPane>
<PushButton buttonData="1">
<buttonPressListeners>
<bxml:value id="myListener"/>
</buttonPressListeners>
</PushButton>
<PushButton buttonData="2">
<buttonPressListeners>
<bxml:value id="myListener"/>
</buttonPressListeners>
</PushButton>
</BoxPane>
</Window>
Note the use of the <bxml:value> element. This tag would act like the "$" dereference operator used in attributes, but for elements. For scalar properties the "$" syntax is sufficient, because they can be set via attribute. However, there is currently no way to add a page-level variable to a sequence or listener list, so this might be a worthwhile addition to the platform independent of the current discussion.
G
On Jun 18, 2010, at 10:42 AM, Chris Bartlett wrote:
> 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 <aa...@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:cbartlett.x@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
>>
>>
RE: Pivot components & the keyboard
Posted by aappddeevv <aa...@verizon.net>.
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:cbartlett.x@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 <aa...@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:cbartlett.x@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
>
>
Re: Pivot components & the keyboard
Posted by Chris Bartlett <cb...@googlemail.com>.
Thanks for sharing your work.
I'll take a look at it as soon as I have time.
(The zip made it through to the list)
On Sun, Jun 20, 2010 at 1:25 AM, aappddeevv <aa...@verizon.net> 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:cbartlett.x@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 <aa...@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:cbartlett.x@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
> >
> >
>
Re: Pivot components & the keyboard
Posted by Greg Brown <gk...@mac.com>.
> I don't disagree with your comments. ...
> I don't think you need every possible approach directly in pivot.
OK, thanks for clarifying. I agree that not every approach should or needs to be directly supported by the platform. However, the platform shouldn't preclude other approaches, and should enable them when possible (and within reason).
G
Re: Pivot components & the keyboard
Posted by Sandro Martini <sa...@gmail.com>.
Hi to all,
> However, some small changes allow other major approaches! I've only advocated for making those small changes so that another approach is not too hard to make happen.
Probably my mind focus is not-so-much as library writer, but generally
speaking I'm near the suggested approach.
Maybe not supporting in a direct way some "strange" usage, but keep
the door open for extensions, and maybe in a later release see what to
do with them: keep, remove, include some useful parts in code
("cleaning" and "pivotizing" them before), etc ... comments ?
Probably having a complete (minimal) example here to see and discuss would help.
Bye,
Sandro
RE: Pivot components & the keyboard
Posted by aappddeevv <aa...@verizon.net>.
I don't disagree with your comments. My comments were merely to highlight
how Bindable works and how other initialization approaches may need to exist
*and* should be seen as similar in concept--I was not picking on Bindable.
I don't think you need every possible approach directly in pivot.
However, some small changes allow other major approaches! I've only
advocated for making those small changes so that another approach is not too
hard to make happe. I am not advocating that the bigger pattern should be
directly supported by pivot. And these small changes are actually are a step
ahead of say, xaml processing, just as scripting in the serializer is a step
ahead.
The power of pivot is that it has a few options here versus only one
option...that's a good thing.
Thanks for your thoughts.
-----Original Message-----
From: Greg Brown [mailto:gkbrown@mac.com]
Sent: Sunday, June 20, 2010 12:56 PM
To: dev@pivot.apache.org
Subject: Re: Pivot components & the keyboard
> 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
Generally, the Bindable object will be the component, so it doesn't need a
reference to it (beyond "this").
> 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()
They go hand-in-hand. initialize() is called to notify the object that
binding has taken place.
> 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.
The sole purpose of Bindable is to ensure that bind() gets called by
BeanSerializer. initialize() is called to let the bindable object know that
this has taken place. Other objects (that don't have bindings) don't need a
special notification method because they can simply use the constructor for
this.
A big part of the Pivot philosophy is "using the right tool for the job".
Inheritance is a major part of OO design, and Pivot is designed around OO
concepts. So subclassing is a "tool" that you are encouraged to take
advantage of in Pivot development, not avoid. BXML exists solely to make it
easier to construct object hierarchies. We think that XML is a more natural
fit than procedural code for this. However, it is not meant to replace
coding altogether.
Re: Pivot components & the keyboard
Posted by Greg Brown <gk...@mac.com>.
> 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
Generally, the Bindable object will be the component, so it doesn't need a reference to it (beyond "this").
> 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()
They go hand-in-hand. initialize() is called to notify the object that binding has taken place.
> 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.
The sole purpose of Bindable is to ensure that bind() gets called by BeanSerializer. initialize() is called to let the bindable object know that this has taken place. Other objects (that don't have bindings) don't need a special notification method because they can simply use the constructor for this.
A big part of the Pivot philosophy is "using the right tool for the job". Inheritance is a major part of OO design, and Pivot is designed around OO concepts. So subclassing is a "tool" that you are encouraged to take advantage of in Pivot development, not avoid. BXML exists solely to make it easier to construct object hierarchies. We think that XML is a more natural fit than procedural code for this. However, it is not meant to replace coding altogether.
RE: Pivot components & the keyboard
Posted by aappddeevv <aa...@verizon.net>.
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:gkbrown@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:cbartlett.x@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 <aa...@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:cbartlett.x@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>
Re: Pivot components & the keyboard
Posted by Greg Brown <gk...@mac.com>.
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:cbartlett.x@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 <aa...@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:cbartlett.x@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>
RE: Pivot components & the keyboard
Posted by aappddeevv <aa...@verizon.net>.
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:cbartlett.x@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 <aa...@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:cbartlett.x@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
>
>
Re: Pivot components & the keyboard
Posted by Chris Bartlett <cb...@googlemail.com>.
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 <aa...@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:cbartlett.x@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
>
>
RE: Pivot components & the keyboard
Posted by aappddeevv <aa...@verizon.net>.
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:cbartlett.x@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
Re: Pivot components & the keyboard
Posted by Noel Grandin <no...@gmail.com>.
Chris, most of those look like useful suggestions.
Could you log an entry in JIRA so we don't lose track of them?
Thanks, Noel Grandin
On Fri, Jun 18, 2010 at 15:23, Chris Bartlett
<cb...@googlemail.com> wrote:
> 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
>
Re: Pivot components & the keyboard
Posted by Chris Bartlett <cb...@googlemail.com>.
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
Re: Pivot components & the keyboard
Posted by Greg Brown <gk...@mac.com>.
They are at the window level. You can enable or disable the actions based on the currently focused component, though.
On Jun 17, 2010, at 6:51 PM, aappddeevv wrote:
> Are those action mappings only at the Window level? Is there away to
> _easily_ scope them to a specific component?
>
> I just hit this issue when trying to map different keystrokes to actions in
> 3 different components and just started to write a new "component service"
> to configure and enable mappings on any component.
>
>
> -----Original Message-----
> From: Greg Brown [mailto:gkbrown@mac.com]
> Sent: Thursday, June 17, 2010 4:21 PM
> To: dev@pivot.apache.org
> Subject: Re: Pivot components & the keyboard
>
>> With regard to keyboard usage, have Pivot components been written with any
>> particular guidelines or OS style behaviour in mind?
>
> Not specifically. However, we have attempted to draw inspiration from the
> various major OSes and adhere to platform-specific conventions where
> possible. For example, multiple selection uses the Control key on Windows
> and Linux and the Command key on the Mac.
>
>> I favour keyboard navigation in applications and would like to enrich my
>> Pivot apps with numerous keyboard shortcuts at the component level. Many
>> would be based on what I have seen or used in other apps and various OSs,
>> but some are just ones that I created to meet my own needs.
>>
>> If there is a resource detailing the preferred keyboard based
> functionality
>> & associated key combinations, then I'll take a look at that and filter
> the
>> patches accordingly.
>
> 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
>
RE: Pivot components & the keyboard
Posted by aappddeevv <aa...@verizon.net>.
Are those action mappings only at the Window level? Is there away to
_easily_ scope them to a specific component?
I just hit this issue when trying to map different keystrokes to actions in
3 different components and just started to write a new "component service"
to configure and enable mappings on any component.
-----Original Message-----
From: Greg Brown [mailto:gkbrown@mac.com]
Sent: Thursday, June 17, 2010 4:21 PM
To: dev@pivot.apache.org
Subject: Re: Pivot components & the keyboard
> With regard to keyboard usage, have Pivot components been written with any
> particular guidelines or OS style behaviour in mind?
Not specifically. However, we have attempted to draw inspiration from the
various major OSes and adhere to platform-specific conventions where
possible. For example, multiple selection uses the Control key on Windows
and Linux and the Command key on the Mac.
> I favour keyboard navigation in applications and would like to enrich my
> Pivot apps with numerous keyboard shortcuts at the component level. Many
> would be based on what I have seen or used in other apps and various OSs,
> but some are just ones that I created to meet my own needs.
>
> If there is a resource detailing the preferred keyboard based
functionality
> & associated key combinations, then I'll take a look at that and filter
the
> patches accordingly.
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
Re: Pivot components & the keyboard
Posted by Greg Brown <gk...@mac.com>.
> With regard to keyboard usage, have Pivot components been written with any
> particular guidelines or OS style behaviour in mind?
Not specifically. However, we have attempted to draw inspiration from the various major OSes and adhere to platform-specific conventions where possible. For example, multiple selection uses the Control key on Windows and Linux and the Command key on the Mac.
> I favour keyboard navigation in applications and would like to enrich my
> Pivot apps with numerous keyboard shortcuts at the component level. Many
> would be based on what I have seen or used in other apps and various OSs,
> but some are just ones that I created to meet my own needs.
>
> If there is a resource detailing the preferred keyboard based functionality
> & associated key combinations, then I'll take a look at that and filter the
> patches accordingly.
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