You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@pivot.apache.org by Greg Brown <gk...@mac.com> on 2010/09/11 15:22:34 UTC
New TextArea component is ready for testing
Hi all,
The new plain-text TextArea is now checked in to trunk. I have tested it in our existing demo and tutorial applications, but I'm sure I probably missed a few things. Any feedback would be very much appreciated.
Thanks!
Greg
Re: New TextArea component is ready for testing
Posted by Greg Brown <gk...@mac.com>.
> other tests, I've just seen in all focusable Text components TextInput,
> TextArea and TextPane) that the Select All (<CTRL>A) is handled in the right
> way :-)
>
> I was thinking to propose the same behavior also for Lists, Tables, Trees
> (when enabled and with multiple selection and not in edit) but I've seen
> that many applications handle this in different ways, for example Outlook vs
> Excel, so probably this really makes sense (as a default) only for editable
> Text components, what do you think ?
Agreed that this is application-specific.
> In TextInput navigation between words (<CTRL> left/right arrow) is not
> working
That's because it hasn't been implemented in TextInput. :-) Feel free to submit a JIRA ticket for this.
> selection should be from the starting position (first triggered keys
> combination) to the current cursor position, and any time the same
> combination is triggered the cursor should move and so the selection
> changes, and what is not selected should become selected, and vice versa.
I won't say that this is exactly "by design", but it is intentional. The current selection behavior was easiest to implement (note that it is also the same behavior as in previous releases). It's not ideal, but I think it is good enough for now. We can revisit it in a future update.
Re: New TextArea component is ready for testing
Posted by Sandro Martini <sa...@gmail.com>.
Hi to all,
other tests, I've just seen in all focusable Text components TextInput,
TextArea and TextPane) that the Select All (<CTRL>A) is handled in the right
way :-)
I was thinking to propose the same behavior also for Lists, Tables, Trees
(when enabled and with multiple selection and not in edit) but I've seen
that many applications handle this in different ways, for example Outlook vs
Excel, so probably this really makes sense (as a default) only for editable
Text components, what do you think ?
In TextInput navigation between words (<CTRL> left/right arrow) is not
working
Then, in all text components the selection of text during navigation between
words (<SHIFT> <CTRL> left/right arrow) has some problems, and this is more
simple to try than to explain here :-), but I'll try the same a quick
explain:
selection should be from the starting position (first triggered keys
combination) to the current cursor position, and any time the same
combination is triggered the cursor should move and so the selection
changes, and what is not selected should become selected, and vice versa.
Tell me if you need more info.
>> - Home/End keys: go to start/end of the current line for text elements,
>> and first/last element in others (Lists, Tables, Trees)
>
>Agreed. If we're not currently doing that in ListView, TableView, and
TreeView, we certainly can.
Ok, I'll wait to see these features in trunk so I can try/test them :-)
>> - <CTRL><Home> / <CTRL><End>: go to the start/end of the document (all
>> the text inside the component for text components) ... verify if this
>> makes sense also for others like (Lists, Tables, Trees) to go to
>> first/last element ... for consistency between components maybe yes
>
>For TextArea, this sounds like a good idea.
Great, when editing text this is really useful, at least for lazy people
like me :-)
>However, since Home and End would already do the same thing in ListView,
TableView, and TreeView, it doesn't seem to apply there.
Yes, I agree, and we are always in time to do it if someone ask ...
>> - Page Up/Down: go up/down by n elements (bounded by first/last), where n
>> is the size of the current page (for example in a List or a Table with
>> size 20 elements the page here could be 20) ...
>
>Not sure this makes sense. Page up/down is currently handled by ScrollPane,
which, in most cases, will be used to host a list, table, or tree. So I
think the current behavior is probably OK.
>We could certainly revisit this later, though.
Ok, I can wait to see this (it's not so important), so we can see what users
say or if they'll require it ...
>> Note that moving in that data set up/down (to last/first or via page
>> down/up) could trigger some event like "ask (usually to the server) more
>> data".
>
>This is best left to the application. A custom model can easily handle
this.
Good, I have many (web :-( ) applications that handle tons of paged data, so
I should be able to do the same with Pivot (even if with Pivot there it's
less required) ...
>I think this should be left to the application. Changing the selection due
to scrolling is, in my opinion, bad UI practice.
after thinking better on it, probably Greg has reason.
>That is by design. Allowing null values made the implementation more
complex than it needed to be (since >the empty string can be used for the
same purpose). The same is not necessarily true for TextPane, >though we may
want to revisit this and also not allow null values for the "document"
property.
I agree, so what do you think on a clear method (could already exist, I
haven't looked at the code, sorry), and maybe give also a singleton,
immutable EMPTY document in this case ?
and maybe a similar thing for empty texts (if it's not too overweight) ?
>>> - Page Up/Down: go up/down by n elements (bounded by first/last), where
>>> n is
>>> the size of the current page (for example in a List or a Table with size
>>> 20
>>> elements the page here could be 20) ...
>>
>> Not sure this makes sense. Page up/down is currently handled by
>> ScrollPane, which, in most cases, will >be used to host a list, table, or
>> tree. So I think the current behavior is probably OK. We could certainly
>> >revisit this later, though.
>
>Might it make sense to have TextArea override scrollToVisible() to
>also update the position of the caret? Though as I think about it,
>I'm not sure that would come into play here anyway...
>
after thinking on it some other time, for sure this makes sense when a
TextArea in in edit mode.
And in my opinion even on List, Table, Tree when I have many elements (for
example 100 or higher), with this feature I could move inside elements in a
fast way without using the mouse but only using the keyboard, and it's
really a time saver in data-entry applications.
To simplify things maybe only when is enabled and selection mode is Single.
Uh, another fast navigation tip come to mind (I've seen this time ago in
many applications, but with different <CTRL> <other key> combinations) ...
for fast selection/deselection of an element (inside List, Table, Tree),
what do you think on<CTRL><Enter> ?
And maybe on Tree there is another operation that at the moment doesn't have
a shortcut: open/close a node, suggestions ? Do you like <Enter> for this ?
With this new shortcuts we could handle many operation without mouse ...
Comments ?
Sorry for the long post, but with this now I have no more ideas on this
subject at the moment ...
Bye,
Sandro
--
View this message in context: http://apache-pivot-developers.417237.n3.nabble.com/New-TextArea-component-is-ready-for-testing-tp1457209p1487418.html
Sent from the Apache Pivot - Developers mailing list archive at Nabble.com.
Re: New TextArea component is ready for testing
Posted by Sandro Martini <sa...@gmail.com>.
Hi Chris,
I agree completely with you :-) , because in my opinion this is one the the
MAIN reasons that a developer choose a RIA framework versus a Web framework:
fast interaction with users (and what better than data input and navigation
between elements ?), and not only Flash-like effects (but I'm not against
them :-) ).
I like your shortcuts for Trees, and you handle much cases than my (simple)
proposal ...
To the next post ...
Bye,
Sandro
--
View this message in context: http://apache-pivot-developers.417237.n3.nabble.com/New-TextArea-component-is-ready-for-testing-tp1457209p1487960.html
Sent from the Apache Pivot - Developers mailing list archive at Nabble.com.
Re: New TextArea component is ready for testing
Posted by Greg Brown <gk...@mac.com>.
Can you describe a use case for this? It seems like something that could easily be implemented at the application level.
On Sep 16, 2010, at 9:08 AM, Sandro Martini wrote:
>
> Hi Chris,
> thanks for the ticket ( https://issues.apache.org/jira/browse/PIVOT-638 ),
> I've just add a link to this thread, for easy recover some info ...
>
>> Uh, another fast navigation tip come to mind (I've seen this time ago in
>> many applications, but with different <CTRL> <other key> combinations) ...
>> for fast selection/deselection of an element (inside List, Table, Tree),
>> what do you think on<CTRL><Enter> ?
>> And maybe on Tree there is another operation that at the moment doesn't
>> have a shortcut: open/close a node, suggestions ? Do you like <Enter> for
>> this ?
>> With this new shortcuts we could handle many operation without mouse ...
>
> Comments on this ?
> Or do you prefer to wait for the 2.1 (as some of other proposed features in
> this thread) ?
>
>
> Sandro
>
> --
> View this message in context: http://apache-pivot-developers.417237.n3.nabble.com/New-TextArea-component-is-ready-for-testing-tp1457209p1487905.html
> Sent from the Apache Pivot - Developers mailing list archive at Nabble.com.
Re: TreeView keyboard behavior (was: New TextArea component is ready
for testing)
Posted by Greg Brown <gk...@mac.com>.
> Left arrow will close the selected node if it is a branch and is open
> Right arrow will expand/open the selected node if it is a branch and is
> closed
TreeView currently supports both of these.
> Left arrow will jump to the parent branch of the selected node if it is not
> a branch, or is a closed branch
It does not support this, though it probably should - both Windows and OS X behave this way.
> Right arrow will change the selection from the selected node to the first
> child node if the selection is a branch and is open
I see that Windows Explorer behaves this way, but the Mac Finder does not. So I could go either way on this.
Re: New TextArea component is ready for testing
Posted by Chris Bartlett <cb...@gmail.com>.
On 16 September 2010 20:08, Sandro Martini <sa...@gmail.com> wrote:
>
> Hi Chris,
> thanks for the ticket ( https://issues.apache.org/jira/browse/PIVOT-638 ),
> I've just add a link to this thread, for easy recover some info ...
>
You beat me to it!
Below is a bit off topic, so apologies & skip as desired.
> > And maybe on Tree there is another operation that at the moment doesn't
> > have a shortcut: open/close a node, suggestions ? Do you like <Enter> for
> > this ?
I have created a custom subclass of TreeView (along with a custom skin) to
enhance the usability from the keyboard. In it, I replicated the behaviour
that can be found in Windows Explorer.
(I don't have it in front of me, but from memory)
Left arrow will close the selected node if it is a branch and is open
Left arrow will jump to the parent branch of the selected node if it is not
a branch, or is a closed branch
Right arrow will expand/open the selected node if it is a branch and is
closed
Right arrow will change the selection from the selected node to the first
child node if the selection is a branch and is open
I also added Control+Right to fully expand all nodes below the selection,
and Control+Left to collapse the entire tree to just the root nodes.
Control+Up/Down to jump between nodes at the same level, bypassing children
in expanded branches
Chris
Re: New TextArea component is ready for testing
Posted by Sandro Martini <sa...@gmail.com>.
Hi Chris,
thanks for the ticket ( https://issues.apache.org/jira/browse/PIVOT-638 ),
I've just add a link to this thread, for easy recover some info ...
> Uh, another fast navigation tip come to mind (I've seen this time ago in
> many applications, but with different <CTRL> <other key> combinations) ...
> for fast selection/deselection of an element (inside List, Table, Tree),
> what do you think on<CTRL><Enter> ?
> And maybe on Tree there is another operation that at the moment doesn't
> have a shortcut: open/close a node, suggestions ? Do you like <Enter> for
> this ?
> With this new shortcuts we could handle many operation without mouse ...
Comments on this ?
Or do you prefer to wait for the 2.1 (as some of other proposed features in
this thread) ?
Sandro
--
View this message in context: http://apache-pivot-developers.417237.n3.nabble.com/New-TextArea-component-is-ready-for-testing-tp1457209p1487905.html
Sent from the Apache Pivot - Developers mailing list archive at Nabble.com.
Re: New TextArea component is ready for testing
Posted by Greg Brown <gk...@mac.com>.
> One possibility action mappings as you mention, but a first step might just
> be to refactor out as much logic as possible from the ComponentKeyListener
> methods into public methods that a user can easily call from their own key
> handlers or actions. Simple examples might be things like 'select all' and
> 'deselect all'.
FYI, there is already a selectAll() method; deselect all would simply be setSelection(0, 0).
>> FWIW, I think the priority right now should be getting a stable 2.0 release
>> out the door. We're seeing a lot of new interest in Pivot at the moment, and
>> there is a lot of great stuff in this release that these developers will be
>> able to take advantage of. We don't have to try to squeeze everything in
>> right now - the changes we have already made for 2.0 will give us a very
>> solid foundation for moving forward.
>>
> I totally agree. Far less verbose BXML thanks in itself is almost a reason
> to push out 2.0 right now :)
Yup. :-) The new namespace binding stuff and stylesheet support is also nice, as are the other enhancements to BXMLSerializer and Bindable.
Re: New TextArea component is ready for testing
Posted by Chris Bartlett <cb...@gmail.com>.
On 16 September 2010 20:23, Greg Brown <gk...@mac.com> wrote:
> I agree that robust keyboard handling is important, especially in text
> input components. Unfortunately, different platforms have different
> conventions for keyboard shortcuts, and these can be difficult to
> generalize. A complete generalization might make use of action mappings or
> something similar. However, I have tried to keep it simple for now and
> address the most common use cases. We can always come back to it later in a
> future release.
>
During my upcoming documentation of keystrokes (
https://issues.apache.org/jira/browse/PIVOT-637) I was planning on also
seeing if there are any simple improvements that could be made.
One possibility action mappings as you mention, but a first step might just
be to refactor out as much logic as possible from the ComponentKeyListener
methods into public methods that a user can easily call from their own key
handlers or actions. Simple examples might be things like 'select all' and
'deselect all'.
>
> FWIW, I think the priority right now should be getting a stable 2.0 release
> out the door. We're seeing a lot of new interest in Pivot at the moment, and
> there is a lot of great stuff in this release that these developers will be
> able to take advantage of. We don't have to try to squeeze everything in
> right now - the changes we have already made for 2.0 will give us a very
> solid foundation for moving forward.
>
> I totally agree. Far less verbose BXML thanks in itself is almost a reason
to push out 2.0 right now :)
>
> On Sep 16, 2010, at 9:09 AM, Chris Bartlett wrote:
>
> > No danger of us sitting idle post Pivot 2.0 even just relying on the
> backlog
> > of issues/tasks/improvements that I have yet to get into JIRA!
> >
> > I need to find time to play with the new component before commenting on
> the
> > functionality, but as you might have noticed, I strongly favour the use
> of
> > the keyboard over a mouse/trackball/trackpad, and as such have come
> across
> > various issues (to me, maybe not to others) with the keyboard handling in
> > Pivot components and Pivot in general.
> >
> > Due to the nature of this component, the user's fingers will be in
> contact
> > with the keyboard much more than other components. As such I feel that
> it
> > would benefit from having as much practical functionality as possible
> > available via keyboard 'shortcuts'.
> >
> > I am yet to write a proper Pivot application 'in anger' having so far
> been
> > limited to small tools while evaluating and learning about Pivot. Before
> I
> > do, I will need to iron these issues out, but can most likely do that via
> > sub-classing rather than requiring changes to Pivot. I'll happily
> > contribute any changes I make if a mailing list discussion suggests they
> are
> > wanted.
> >
> > Chris
> >
> > On 16 September 2010 19:53, Greg Brown <gk...@mac.com> wrote:
> >
> >> That is interesting.
> >>
> >> My suggestion is to leave the current behavior as is and revisit it in a
> >> later release, if necessary. As I mentioned, it is the same behavior as
> in
> >> earlier releases and doesn't seem to have caused a problem for users
> yet.
> >>
> >> Besides, we have to leave *something* to do for Pivot 2.1 and beyond.
> ;-)
> >>
> >>
> >> On Sep 16, 2010, at 8:40 AM, Chris Bartlett wrote:
> >>
> >>> I thought this is what the ScrollLock key was for, but wasn't aware
> that
> >>> Apple keyboards don't have one.
> >>> http://en.wikipedia.org/wiki/Scroll_lock
> >>>
> >>> I think that in some applications Page Up/Down will reposition the
> caret,
> >>> but by using a modifier such as Control with Page Up/Down, it would
> >> merely
> >>> scroll the viewport.
> >>>
> >>> Chris
> >>>
> >>> On 16 September 2010 19:26, Greg Brown <gk...@mac.com> wrote:
> >>>
> >>>> The easiest solution would probably be to have it override the page
> >> up/down
> >>>> key press events and determine what the next line should be based on
> the
> >>>> viewport height.
> >>>>
> >>>> However, as I mentioned in the other thread, I'm not sure that
> changing
> >> the
> >>>> caret position just because the viewport changes is good UI design.
> The
> >> text
> >>>> editor I use on the Mac (SubEthaEdit) doesn't do it - just like
> Pivot's
> >>>> TextArea/TextPane, you can scroll the caret out of view using either
> >> page
> >>>> up/down or the scrollbar; however, any key press will scroll it back
> to
> >>>> visible.
> >>>>
> >>>> Eclipse does reposition the caret on page up/down, but not when the
> user
> >>>> scrolls manually, which, to me, seems inconsistent. However, like the
> >>>> others, a key press brings it back into view.
> >>>>
> >>>> G
> >>>>
> >>>> On Sep 15, 2010, at 9:36 PM, Todd Volkert wrote:
> >>>>
> >>>>>>> - Page Up/Down: go up/down by n elements (bounded by first/last),
> >> where
> >>>> n is
> >>>>>>> the size of the current page (for example in a List or a Table with
> >>>> size 20
> >>>>>>> elements the page here could be 20) ...
> >>>>>>
> >>>>>> Not sure this makes sense. Page up/down is currently handled by
> >>>> ScrollPane, which, in most cases, will be used to host a list, table,
> or
> >>>> tree. So I think the current behavior is probably OK. We could
> certainly
> >>>> revisit this later, though.
> >>>>>
> >>>>> Might it make sense to have TextArea override scrollToVisible() to
> >>>>> also update the position of the caret? Though as I think about it,
> >>>>> I'm not sure that would come into play here anyway...
> >>>>
> >>>>
> >>
> >>
>
>
Re: New TextArea component is ready for testing
Posted by Greg Brown <gk...@mac.com>.
I agree that robust keyboard handling is important, especially in text input components. Unfortunately, different platforms have different conventions for keyboard shortcuts, and these can be difficult to generalize. A complete generalization might make use of action mappings or something similar. However, I have tried to keep it simple for now and address the most common use cases. We can always come back to it later in a future release.
FWIW, I think the priority right now should be getting a stable 2.0 release out the door. We're seeing a lot of new interest in Pivot at the moment, and there is a lot of great stuff in this release that these developers will be able to take advantage of. We don't have to try to squeeze everything in right now - the changes we have already made for 2.0 will give us a very solid foundation for moving forward.
On Sep 16, 2010, at 9:09 AM, Chris Bartlett wrote:
> No danger of us sitting idle post Pivot 2.0 even just relying on the backlog
> of issues/tasks/improvements that I have yet to get into JIRA!
>
> I need to find time to play with the new component before commenting on the
> functionality, but as you might have noticed, I strongly favour the use of
> the keyboard over a mouse/trackball/trackpad, and as such have come across
> various issues (to me, maybe not to others) with the keyboard handling in
> Pivot components and Pivot in general.
>
> Due to the nature of this component, the user's fingers will be in contact
> with the keyboard much more than other components. As such I feel that it
> would benefit from having as much practical functionality as possible
> available via keyboard 'shortcuts'.
>
> I am yet to write a proper Pivot application 'in anger' having so far been
> limited to small tools while evaluating and learning about Pivot. Before I
> do, I will need to iron these issues out, but can most likely do that via
> sub-classing rather than requiring changes to Pivot. I'll happily
> contribute any changes I make if a mailing list discussion suggests they are
> wanted.
>
> Chris
>
> On 16 September 2010 19:53, Greg Brown <gk...@mac.com> wrote:
>
>> That is interesting.
>>
>> My suggestion is to leave the current behavior as is and revisit it in a
>> later release, if necessary. As I mentioned, it is the same behavior as in
>> earlier releases and doesn't seem to have caused a problem for users yet.
>>
>> Besides, we have to leave *something* to do for Pivot 2.1 and beyond. ;-)
>>
>>
>> On Sep 16, 2010, at 8:40 AM, Chris Bartlett wrote:
>>
>>> I thought this is what the ScrollLock key was for, but wasn't aware that
>>> Apple keyboards don't have one.
>>> http://en.wikipedia.org/wiki/Scroll_lock
>>>
>>> I think that in some applications Page Up/Down will reposition the caret,
>>> but by using a modifier such as Control with Page Up/Down, it would
>> merely
>>> scroll the viewport.
>>>
>>> Chris
>>>
>>> On 16 September 2010 19:26, Greg Brown <gk...@mac.com> wrote:
>>>
>>>> The easiest solution would probably be to have it override the page
>> up/down
>>>> key press events and determine what the next line should be based on the
>>>> viewport height.
>>>>
>>>> However, as I mentioned in the other thread, I'm not sure that changing
>> the
>>>> caret position just because the viewport changes is good UI design. The
>> text
>>>> editor I use on the Mac (SubEthaEdit) doesn't do it - just like Pivot's
>>>> TextArea/TextPane, you can scroll the caret out of view using either
>> page
>>>> up/down or the scrollbar; however, any key press will scroll it back to
>>>> visible.
>>>>
>>>> Eclipse does reposition the caret on page up/down, but not when the user
>>>> scrolls manually, which, to me, seems inconsistent. However, like the
>>>> others, a key press brings it back into view.
>>>>
>>>> G
>>>>
>>>> On Sep 15, 2010, at 9:36 PM, Todd Volkert wrote:
>>>>
>>>>>>> - Page Up/Down: go up/down by n elements (bounded by first/last),
>> where
>>>> n is
>>>>>>> the size of the current page (for example in a List or a Table with
>>>> size 20
>>>>>>> elements the page here could be 20) ...
>>>>>>
>>>>>> Not sure this makes sense. Page up/down is currently handled by
>>>> ScrollPane, which, in most cases, will be used to host a list, table, or
>>>> tree. So I think the current behavior is probably OK. We could certainly
>>>> revisit this later, though.
>>>>>
>>>>> Might it make sense to have TextArea override scrollToVisible() to
>>>>> also update the position of the caret? Though as I think about it,
>>>>> I'm not sure that would come into play here anyway...
>>>>
>>>>
>>
>>
Re: New TextArea component is ready for testing
Posted by Chris Bartlett <cb...@gmail.com>.
No danger of us sitting idle post Pivot 2.0 even just relying on the backlog
of issues/tasks/improvements that I have yet to get into JIRA!
I need to find time to play with the new component before commenting on the
functionality, but as you might have noticed, I strongly favour the use of
the keyboard over a mouse/trackball/trackpad, and as such have come across
various issues (to me, maybe not to others) with the keyboard handling in
Pivot components and Pivot in general.
Due to the nature of this component, the user's fingers will be in contact
with the keyboard much more than other components. As such I feel that it
would benefit from having as much practical functionality as possible
available via keyboard 'shortcuts'.
I am yet to write a proper Pivot application 'in anger' having so far been
limited to small tools while evaluating and learning about Pivot. Before I
do, I will need to iron these issues out, but can most likely do that via
sub-classing rather than requiring changes to Pivot. I'll happily
contribute any changes I make if a mailing list discussion suggests they are
wanted.
Chris
On 16 September 2010 19:53, Greg Brown <gk...@mac.com> wrote:
> That is interesting.
>
> My suggestion is to leave the current behavior as is and revisit it in a
> later release, if necessary. As I mentioned, it is the same behavior as in
> earlier releases and doesn't seem to have caused a problem for users yet.
>
> Besides, we have to leave *something* to do for Pivot 2.1 and beyond. ;-)
>
>
> On Sep 16, 2010, at 8:40 AM, Chris Bartlett wrote:
>
> > I thought this is what the ScrollLock key was for, but wasn't aware that
> > Apple keyboards don't have one.
> > http://en.wikipedia.org/wiki/Scroll_lock
> >
> > I think that in some applications Page Up/Down will reposition the caret,
> > but by using a modifier such as Control with Page Up/Down, it would
> merely
> > scroll the viewport.
> >
> > Chris
> >
> > On 16 September 2010 19:26, Greg Brown <gk...@mac.com> wrote:
> >
> >> The easiest solution would probably be to have it override the page
> up/down
> >> key press events and determine what the next line should be based on the
> >> viewport height.
> >>
> >> However, as I mentioned in the other thread, I'm not sure that changing
> the
> >> caret position just because the viewport changes is good UI design. The
> text
> >> editor I use on the Mac (SubEthaEdit) doesn't do it - just like Pivot's
> >> TextArea/TextPane, you can scroll the caret out of view using either
> page
> >> up/down or the scrollbar; however, any key press will scroll it back to
> >> visible.
> >>
> >> Eclipse does reposition the caret on page up/down, but not when the user
> >> scrolls manually, which, to me, seems inconsistent. However, like the
> >> others, a key press brings it back into view.
> >>
> >> G
> >>
> >> On Sep 15, 2010, at 9:36 PM, Todd Volkert wrote:
> >>
> >>>>> - Page Up/Down: go up/down by n elements (bounded by first/last),
> where
> >> n is
> >>>>> the size of the current page (for example in a List or a Table with
> >> size 20
> >>>>> elements the page here could be 20) ...
> >>>>
> >>>> Not sure this makes sense. Page up/down is currently handled by
> >> ScrollPane, which, in most cases, will be used to host a list, table, or
> >> tree. So I think the current behavior is probably OK. We could certainly
> >> revisit this later, though.
> >>>
> >>> Might it make sense to have TextArea override scrollToVisible() to
> >>> also update the position of the caret? Though as I think about it,
> >>> I'm not sure that would come into play here anyway...
> >>
> >>
>
>
Re: New TextArea component is ready for testing
Posted by Greg Brown <gk...@mac.com>.
That is interesting.
My suggestion is to leave the current behavior as is and revisit it in a later release, if necessary. As I mentioned, it is the same behavior as in earlier releases and doesn't seem to have caused a problem for users yet.
Besides, we have to leave *something* to do for Pivot 2.1 and beyond. ;-)
On Sep 16, 2010, at 8:40 AM, Chris Bartlett wrote:
> I thought this is what the ScrollLock key was for, but wasn't aware that
> Apple keyboards don't have one.
> http://en.wikipedia.org/wiki/Scroll_lock
>
> I think that in some applications Page Up/Down will reposition the caret,
> but by using a modifier such as Control with Page Up/Down, it would merely
> scroll the viewport.
>
> Chris
>
> On 16 September 2010 19:26, Greg Brown <gk...@mac.com> wrote:
>
>> The easiest solution would probably be to have it override the page up/down
>> key press events and determine what the next line should be based on the
>> viewport height.
>>
>> However, as I mentioned in the other thread, I'm not sure that changing the
>> caret position just because the viewport changes is good UI design. The text
>> editor I use on the Mac (SubEthaEdit) doesn't do it - just like Pivot's
>> TextArea/TextPane, you can scroll the caret out of view using either page
>> up/down or the scrollbar; however, any key press will scroll it back to
>> visible.
>>
>> Eclipse does reposition the caret on page up/down, but not when the user
>> scrolls manually, which, to me, seems inconsistent. However, like the
>> others, a key press brings it back into view.
>>
>> G
>>
>> On Sep 15, 2010, at 9:36 PM, Todd Volkert wrote:
>>
>>>>> - Page Up/Down: go up/down by n elements (bounded by first/last), where
>> n is
>>>>> the size of the current page (for example in a List or a Table with
>> size 20
>>>>> elements the page here could be 20) ...
>>>>
>>>> Not sure this makes sense. Page up/down is currently handled by
>> ScrollPane, which, in most cases, will be used to host a list, table, or
>> tree. So I think the current behavior is probably OK. We could certainly
>> revisit this later, though.
>>>
>>> Might it make sense to have TextArea override scrollToVisible() to
>>> also update the position of the caret? Though as I think about it,
>>> I'm not sure that would come into play here anyway...
>>
>>
Re: New TextArea component is ready for testing
Posted by Chris Bartlett <cb...@gmail.com>.
I thought this is what the ScrollLock key was for, but wasn't aware that
Apple keyboards don't have one.
http://en.wikipedia.org/wiki/Scroll_lock
I think that in some applications Page Up/Down will reposition the caret,
but by using a modifier such as Control with Page Up/Down, it would merely
scroll the viewport.
Chris
On 16 September 2010 19:26, Greg Brown <gk...@mac.com> wrote:
> The easiest solution would probably be to have it override the page up/down
> key press events and determine what the next line should be based on the
> viewport height.
>
> However, as I mentioned in the other thread, I'm not sure that changing the
> caret position just because the viewport changes is good UI design. The text
> editor I use on the Mac (SubEthaEdit) doesn't do it - just like Pivot's
> TextArea/TextPane, you can scroll the caret out of view using either page
> up/down or the scrollbar; however, any key press will scroll it back to
> visible.
>
> Eclipse does reposition the caret on page up/down, but not when the user
> scrolls manually, which, to me, seems inconsistent. However, like the
> others, a key press brings it back into view.
>
> G
>
> On Sep 15, 2010, at 9:36 PM, Todd Volkert wrote:
>
> >>> - Page Up/Down: go up/down by n elements (bounded by first/last), where
> n is
> >>> the size of the current page (for example in a List or a Table with
> size 20
> >>> elements the page here could be 20) ...
> >>
> >> Not sure this makes sense. Page up/down is currently handled by
> ScrollPane, which, in most cases, will be used to host a list, table, or
> tree. So I think the current behavior is probably OK. We could certainly
> revisit this later, though.
> >
> > Might it make sense to have TextArea override scrollToVisible() to
> > also update the position of the caret? Though as I think about it,
> > I'm not sure that would come into play here anyway...
>
>
Re: New TextArea component is ready for testing
Posted by Greg Brown <gk...@mac.com>.
The easiest solution would probably be to have it override the page up/down key press events and determine what the next line should be based on the viewport height.
However, as I mentioned in the other thread, I'm not sure that changing the caret position just because the viewport changes is good UI design. The text editor I use on the Mac (SubEthaEdit) doesn't do it - just like Pivot's TextArea/TextPane, you can scroll the caret out of view using either page up/down or the scrollbar; however, any key press will scroll it back to visible.
Eclipse does reposition the caret on page up/down, but not when the user scrolls manually, which, to me, seems inconsistent. However, like the others, a key press brings it back into view.
G
On Sep 15, 2010, at 9:36 PM, Todd Volkert wrote:
>>> - Page Up/Down: go up/down by n elements (bounded by first/last), where n is
>>> the size of the current page (for example in a List or a Table with size 20
>>> elements the page here could be 20) ...
>>
>> Not sure this makes sense. Page up/down is currently handled by ScrollPane, which, in most cases, will be used to host a list, table, or tree. So I think the current behavior is probably OK. We could certainly revisit this later, though.
>
> Might it make sense to have TextArea override scrollToVisible() to
> also update the position of the caret? Though as I think about it,
> I'm not sure that would come into play here anyway...
Re: New TextArea component is ready for testing
Posted by Todd Volkert <tv...@gmail.com>.
>> - Page Up/Down: go up/down by n elements (bounded by first/last), where n is
>> the size of the current page (for example in a List or a Table with size 20
>> elements the page here could be 20) ...
>
> Not sure this makes sense. Page up/down is currently handled by ScrollPane, which, in most cases, will be used to host a list, table, or tree. So I think the current behavior is probably OK. We could certainly revisit this later, though.
Might it make sense to have TextArea override scrollToVisible() to
also update the position of the caret? Though as I think about it,
I'm not sure that would come into play here anyway...
Re: New TextArea component is ready for testing
Posted by Greg Brown <gk...@mac.com>.
> excuse me, on other point proposed what do you think (for example the little
> problems I found on TextPane) ?
We can certainly attempt to update TextPane for consistency with TextArea - however, this is one of the reasons I suggested we might want to make TextPane non-editable for this release. As I mentioned in the other thread, I think there is a lot we can do to simplify TextPane, and doing so should make implementing some of these changes easier in the long run.
> - Home/End keys: go to start/end of the current line for text elements, and
> first/last element in others (Lists, Tables, Trees)
Agreed. If we're not currently doing that in ListView, TableView, and TreeView, we certainly can.
> - <CTRL><Home> / <CTRL><End>: go to the start/end of the document (all the
> text inside the component for text components) ... verify if this makes
> sense also for others like (Lists, Tables, Trees) to go to first/last
> element ... for consistency between components maybe yes
For TextArea, this sounds like a good idea. However, since Home and End would already do the same thing in ListView, TableView, and TreeView, it doesn't seem to apply there.
> - Page Up/Down: go up/down by n elements (bounded by first/last), where n is
> the size of the current page (for example in a List or a Table with size 20
> elements the page here could be 20) ...
Not sure this makes sense. Page up/down is currently handled by ScrollPane, which, in most cases, will be used to host a list, table, or tree. So I think the current behavior is probably OK. We could certainly revisit this later, though.
> Note that moving in that data set up/down (to last/first or via page
> down/up) could trigger some event like "ask (usually to the server) more
> data".
This is best left to the application. A custom model can easily handle this.
>> You mean when SelectMode is NONE, or when the component is disabled?
> If the component is not focusable (or disabled) probably it's better to not
> change its selection inside, and move only the current view on it with
> scrollbars.
Correct - if the component is disabled, it can't respond to keyboard input, so this would be the responsibility of the host container (i.e. ScrollPane).
> Otherwise (in any of selection modes ... maybe NOT for SelectMode NONE , on
> this we should make some tests to see what is better) reset the current
> selection on position (and select the target element where there is a
> selectable element) ... for example you can see this behavior on many
> products, like Outlook, Excel, etc ...
I think this should be left to the application. Changing the selection due to scrolling is, in my opinion, bad UI practice.
Re: New TextArea component is ready for testing
Posted by Sandro Martini <sa...@gmail.com>.
Hi Greg,
excuse me, on other point proposed what do you think (for example the little
problems I found on TextPane) ?
Now I'll try to simplify some points, with some general rules (for all
components that accept input, but maybe some of them are only for those
containing many data like Lists, Tables, Trees):
- Home/End keys: go to start/end of the current line for text elements, and
first/last element in others (Lists, Tables, Trees)
- <CTRL><Home> / <CTRL><End>: go to the start/end of the document (all the
text inside the component for text components) ... verify if this makes
sense also for others like (Lists, Tables, Trees) to go to first/last
element ... for consistency between components maybe yes
- Page Up/Down: go up/down by n elements (bounded by first/last), where n is
the size of the current page (for example in a List or a Table with size 20
elements the page here could be 20) ...
Note that moving in that data set up/down (to last/first or via page
down/up) could trigger some event like "ask (usually to the server) more
data".
On Lists It's true that giving the initial letter goes to the first element
with it, but for example if I'd want to go to the first element and I don't
know the letter (in "Kitchen Sink" many Lists doesn't start with "A") I have
to try until I find that right ... but on List this makes sense, I like it.
Instead, on Tables and Trees this method is not valid.
So my proposal is to ADD handling of previous key combinations to have more
range positioning on elements.
In case of Edit mode I don't know the behaviors just described, if they are
still correct ... but maybe yes, we could think to trigger an event and let
the developer handle it (if wanted), otherwise go with the behaviors just
seen. In this way if a User is editing a row in a data table, the developer
could handle an event like "ask edit mode ?" and maybe ignore it.
> You mean when SelectMode is NONE, or when the component is disabled?
If the component is not focusable (or disabled) probably it's better to not
change its selection inside, and move only the current view on it with
scrollbars.
Otherwise (in any of selection modes ... maybe NOT for SelectMode NONE , on
this we should make some tests to see what is better) reset the current
selection on position (and select the target element where there is a
selectable element) ... for example you can see this behavior on many
products, like Outlook, Excel, etc ...
Really I think this is a little but important feature because in this way we
could let users do (fast) navigation inside components, all with keystrokes
(a great time saver respect to the mouse): precise positioning with arrows
(up/down), paging positioning via page keys, and first/last positioning via
home/end (or <ctrl>home/<ctrl><end> depending on cases) keys, really useful
with much data ... you like it ?
I hope to be more clear now :-) , if not, tell me ...
One time it will be clear what to do, tell me and I'll create a ticket for
this, with some of these info as description.
Comments ?
Sandro
--
View this message in context: http://apache-pivot-developers.417237.n3.nabble.com/New-TextArea-component-is-ready-for-testing-tp1457209p1479469.html
Sent from the Apache Pivot - Developers mailing list archive at Nabble.com.
Re: New TextArea component is ready for testing
Posted by Greg Brown <gk...@mac.com>.
> --- if the component is not editable, reset the current selection and
> move the cursor/the selection to the target element of the page up/down
> (depending on the size of the current "page" in the component)
...
> -- note, I'd apply this behavior also on Lists, Tables and Trees
I'm having a hard time envisioning exactly what you are describing. Could you provide a more concrete example?
> -- note that Lists, Tables and Trees does not handle Home / End keys when
> NOT in edit mode ... and even this I'd make uniform with other components.
You mean when SelectMode is NONE, or when the component is disabled?
Re: New TextArea component is ready for testing
Posted by Sandro Martini <sa...@gmail.com>.
Hi Greg,
sorry but was too late this night, now I'll try to better explain ...
>> TextArea: run text_area_test.bxml
>> java.lang.IndexOutOfBoundsException
>>
> It would be great if you could isolate the steps to produce this problem.
I'll try in next days, but playing a little (in random ways) with it seems
to break it in easy way ... but probably could be a char counter that's not
updated when some char is deleted or something like this ... I'll try to
send you more detail as soon as possible.
In the TextArea (run text_area_test.bxml ):
- Home / End here right
-- if possible, add the navigation with <ctrl><home> and <ctrl><end> as
proposed for the TextPane
- Page Up / Down, same as seen down for the TextPane
In the TextPane (run TextPaneDemo.java):
- if I press Home/End The cursor goes NOT to start/end of the current line
but to the start/end of the text contained in the document, and this is not
a standard behavior (but I agree that probably here it's more complex to
understand what is the current line) ...
-- desired behavior: start/end of the current line with home/end keys, and
start/end of all the text with <ctrl><home> and <ctrl><end>, more in line
with standard keystrokes (at least on Windows)
- usage of custom colors, KO ... you can see it running for example adding
as VM Arguments (in eclipse) something like this:
-Dorg.apache.pivot.wtk.skin.terra.location=TerraTheme_ubuntu.json
-- this is the only component with this behavior currently ...
- usage of Page Up/Down keys:
the current behavior (here and in many other places) is that scrollbars
(when present) scroll to the desired position, and this is OK when the
component is not editable and not selectable
-- desired behavior (at least in my opinion, but this is common in many
environments, for example in all Microsoft Office applications, Outlook,
etc, and if I remember well also in many others), when the component is
selectable:
--- if the component is not editable, reset the current selection and
move the cursor/the selection to the target element of the page up/down
(depending on the size of the current "page" in the component)
--- if the component is editable, maybe the previous behavior could be
right, or maybe some event could be fired to let developer know that the
user is asking to exit edit mode on the current element ...
-- I think this is a little but important feature because in this way I
could do (fast) navigation inside components all with keystrokes: precise
positioning with arrows (up/down), paging positioning via page keys, and
first/last positioning via home/end keys, really useful with much data ...
you like it ?
-- of course you can see the current behavior in the "Kitchen Sink" in
many combinations, and I hope to test soon the new behavior there :-)
-- note, I'd apply this behavior also on Lists, Tables and Trees, in the
same conditions as explained upper. If you want we can discuss this more in
detail (I think it will be a good time saver for users of applications, so
maybe a dedicated JIRA issue as improvement could be created, tell me), also
on the users mailing list ... but at the moment I can't forward it, can you
do it for me (if you think it's a good idea) ? Thanks ...
-- note that Lists, Tables and Trees does not handle Home / End keys when
NOT in edit mode ... and even this I'd make uniform with other components.
We have to see if handle here also the <ctrl><home> and <ctrl><end>
combinations maybe this not dependent to edit mode ... but probably for this
combination the best could to not implement here (if there will be already
home/end).
Probably a dedicated ticket with all this discussion inside should be
created ... tell me if I have to create it.
Tell me if you need more info.
Bye,
Sandro
--
View this message in context: http://apache-pivot-developers.417237.n3.nabble.com/New-TextArea-component-is-ready-for-testing-tp1457209p1478763.html
Sent from the Apache Pivot - Developers mailing list archive at Nabble.com.
Re: New TextArea component is ready for testing
Posted by Greg Brown <gk...@mac.com>.
Hi Sandro,
Thanks for the feedback. Comments below:
> - page Up / Down, moved scrollbar but not the cursor, and if Not editable
> elements this is good, but in editable elements would be better to have the
> cursor go the the new position
This is by design. You'd see the same behavior if you manually drag the scrollbars. However, as soon as you type something, the caret should scroll into position.
> - after playing a little with chars in the demo, if I delete some char (for
> example to have less lines shown) and then I try Start / end other times, I
> get this:
It would be great if you could isolate the steps to produce this problem.
> TextPane: run TextPaneDemo.java
FYI, TextPane wasn't significantly modified as part of this update. The only real changes are the class name(s) and the removal of plain text functionality from what used to be TextArea and is now called TextPane.
> As a general note, I see that (at least in Windows) the default shortcut to
> go to the first character of a (maybe long, multi-line) text in <CTRL>
> <Home>, and to go the the last character is <CTRL><End>, but nothing seems
> to handle this, is there a reason (not multi-platform behavior for example)
> ?
Home and End are currently wired up to move the caret to the beginning or end of the line. That's how text inputs work in Windows so I assumed that text areas also worked the same way. What happens on Windows when you press Home or End in a multi-line text area? I know I could test this myself, but then I'd have to start up my Windows VM and I am being lazy. :-)
> As, sorry a last thing I've seen some time ago, probably this is wanted or
> not handled because it's a Demo:
> in the Suggestion Demo, anytime I delete a previous char (using the
> BACKSPACE key), the query is not repeated (with all remaining chars), this
> is wanted ? Or there is a programmable timeout to do this ?
It was intentional. I could have coded the app to update the suggestions on delete as well, but I chose to go with the Mac convention, which only updates when characters are entered. In other words, it is an app-specific decision as to what the correct behavior should be.
G
Re: New TextArea component is ready for testing
Posted by Sandro Martini <sa...@gmail.com>.
Hi Greg,
done some tests, here some info:
TextArea: run text_area_test.bxml
- usage of custom colors, Ok
- Home / End keys move cursor to Start and End of the current line, right
- page Up / Down, moved scrollbar but not the cursor, and if Not editable
elements this is good, but in editable elements would be better to have the
cursor go the the new position
- after playing a little with chars in the demo, if I delete some char (for
example to have less lines shown) and then I try Start / end other times, I
get this:
java.lang.IndexOutOfBoundsException
at org.apache.pivot.wtk.TextArea.getCharacterAt(TextArea.java:870)
at org.apache.pivot.wtk.skin.TextAreaSkin.keyPressed(TextAreaSkin.java:865)
at
org.apache.pivot.wtk.Component$ComponentKeyListenerList.keyPressed(Component.java:526)
at org.apache.pivot.wtk.Component.keyPressed(Component.java:2772)
at
org.apache.pivot.wtk.ApplicationContext$DisplayHost.processKeyEvent(ApplicationContext.java:1198)
at java.awt.Component.processEvent(Component.java:6044)
at
org.apache.pivot.wtk.ApplicationContext$DisplayHost.processEvent(ApplicationContext.java:667)
at java.awt.Component.dispatchEventImpl(Component.java:4630)
at java.awt.Component.dispatchEvent(Component.java:4460)
at
java.awt.KeyboardFocusManager.redispatchEvent(KeyboardFocusManager.java:1850)
at
java.awt.DefaultKeyboardFocusManager.dispatchKeyEvent(DefaultKeyboardFocusManager.java:712)
at
java.awt.DefaultKeyboardFocusManager.preDispatchKeyEvent(DefaultKeyboardFocusManager.java:990)
at
java.awt.DefaultKeyboardFocusManager.typeAheadAssertions(DefaultKeyboardFocusManager.java:855)
at
java.awt.DefaultKeyboardFocusManager.dispatchEvent(DefaultKeyboardFocusManager.java:676)
at java.awt.Component.dispatchEventImpl(Component.java:4502)
at java.awt.Container.dispatchEventImpl(Container.java:2099)
at java.awt.Window.dispatchEventImpl(Window.java:2478)
at java.awt.Component.dispatchEvent(Component.java:4460)
at java.awt.EventQueue.dispatchEvent(EventQueue.java:599)
at
java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:269)
at
java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:184)
at
java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:174)
at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:169)
at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:161)
at java.awt.EventDispatchThread.run(EventDispatchThread.java:122)
TextPane: run TextPaneDemo.java
- usage of custom colors, KO, the background is always white (and probably
the default foreground color of the text is always black)
- Home / End keys move cursor to Start and End of all the text ... probably
would be better to do as in TextArea (start / end of the current line)
- also here page Up / Down, moved scrollbar but not the cursor, and if Not
editable elements this is good, but in editable elements would be better to
have the cursor go the the new position
As a general note, I see that (at least in Windows) the default shortcut to
go to the first character of a (maybe long, multi-line) text in <CTRL>
<Home>, and to go the the last character is <CTRL><End>, but nothing seems
to handle this, is there a reason (not multi-platform behavior for example)
?
With long (focusable, with a cursor inside, also if not editable) could be
really useful.
Comments ?
I'm sorry to not give you some more info but I haven't time to look at the
code ...
As, sorry a last thing I've seen some time ago, probably this is wanted or
not handled because it's a Demo:
in the Suggestion Demo, anytime I delete a previous char (using the
BACKSPACE key), the query is not repeated (with all remaining chars), this
is wanted ? Or there is a programmable timeout to do this ?
Thanks a lot.
Bye,
Sandro
--
View this message in context: http://apache-pivot-developers.417237.n3.nabble.com/New-TextArea-component-is-ready-for-testing-tp1457209p1476581.html
Sent from the Apache Pivot - Developers mailing list archive at Nabble.com.
Re: New TextArea component is ready for testing
Posted by Greg Brown <gk...@mac.com>.
That is by design. Allowing null values made the implementation more complex than it needed to be (since the empty string can be used for the same purpose). The same is not necessarily true for TextPane, though we may want to revisit this and also not allow null values for the "document" property.
On Sep 15, 2010, at 9:20 AM, Chris Bartlett wrote:
> One quick thing is that setText(null) now throws an
> IllegalArgumentException, but previously it would clear the existing text.
>
> I'll take a proper look ASAP & report back.
>
> Chris
>
> On 11 September 2010 20:22, Greg Brown <gk...@mac.com> wrote:
>
>> Hi all,
>>
>> The new plain-text TextArea is now checked in to trunk. I have tested it in
>> our existing demo and tutorial applications, but I'm sure I probably missed
>> a few things. Any feedback would be very much appreciated.
>>
>> Thanks!
>> Greg
>>
>>
Re: New TextArea component is ready for testing
Posted by Chris Bartlett <cb...@gmail.com>.
One quick thing is that setText(null) now throws an
IllegalArgumentException, but previously it would clear the existing text.
I'll take a proper look ASAP & report back.
Chris
On 11 September 2010 20:22, Greg Brown <gk...@mac.com> wrote:
> Hi all,
>
> The new plain-text TextArea is now checked in to trunk. I have tested it in
> our existing demo and tutorial applications, but I'm sure I probably missed
> a few things. Any feedback would be very much appreciated.
>
> Thanks!
> Greg
>
>