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.
