You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@pivot.apache.org by Bill van Melle <bi...@gmail.com> on 2011/02/24 23:20:00 UTC
How to get a wrapped TextInput?
There are two text input controls (that I know of), TextInput and TextArea.
TextInput accepts a single line of text, but it is also only a single line
on the screen, with no provision for wrapping text instead of clumsily
horizontally scrolling. TextArea happily wraps text, but it also accepts
the Enter key to insert newlines into the content.
What I'm looking for is a control that accepts only a single line of input,
but wraps. It should not accept the Enter key, but instead allow that key to
close a dialog. I tried using a TextArea to which I added
a ComponentKeyListener with this override:
public boolean keyTyped(Component component, char character) {
if (character == Keyboard.KeyCode.ENTER) {
close(true);
return true;
}
return false;
}
That only partly works -- it closes the dialog when the Enter key is
pressed, but it also inserts a newline into the TextArea. I guess that's
the downside of no guaranteed ordering of listeners. However, even if I
move that logic to the keyPressed method instead, it doesn't help.
Am I missing something? I can, of course, post-process the input to remove
the newline, but that seems crufty.
(FWIW, the WPF control corresponding to both of these controls, TextBox,
lets me do this by setting attributes AcceptsReturn=False and
TextWrapping="Wrap".)
Re: How to get a wrapped TextInput?
Posted by Greg Brown <gk...@verizon.net>.
Can't speak to anyone else's intentions, but improved IDE support has come up a number of times in the past.
G
On Mar 3, 2011, at 4:24 PM, Bill van Melle wrote:
> On Fri, Feb 25, 2011 at 5:04 AM, Greg Brown <gk...@verizon.net> wrote:
> I agree. I really appreciate Eclipse's code completion features in Java, and I do miss having them when editing BXML.
>
> Is there any intention of ever making a bxml plugin for Eclipse? There are two aspects to that, of course -- IntelliSense and having a way of viewing the resulting output, part of what a true visual designer would do.
Re: How to get a wrapped TextInput?
Posted by Bill van Melle <bi...@gmail.com>.
On Fri, Feb 25, 2011 at 5:04 AM, Greg Brown <gk...@verizon.net> wrote:
>
> I agree. I really appreciate Eclipse's code completion features in Java,
> and I do miss having them when editing BXML.
Is there any intention of ever making a bxml plugin for Eclipse? There are
two aspects to that, of course -- IntelliSense and having a way of viewing
the resulting output, part of what a true visual designer would do.
Re: How to get a wrapped TextInput?
Posted by Greg Brown <gk...@verizon.net>.
> ...skins are a royal pain. I can sorta see how they provide an avenue to extravagant customization, like WPF control templates do. But to the average programmer, the distinction between component classes and their skins and which properties live where frequently seems arbitrary. Every time I want to set attributes on an object, I have to look two places in the javadocs, and use two different syntaxes in bxml.
...
> Sorry to rant like that, but the preceding paragraph spells out what I think is by far the greatest weakness of the Pivot framework.
I agree that this can be kind of a pain, but it does have benefits. The separation of styles and intrinsic properties provides us with the flexibility to vary skin implementations without breaking binary compatibility. FWIW, HTML has the same usability issue - some properties are specified as CSS styles, while others are simply element attributes.
Note that you can use the following syntax to set styles if you prefer:
<Label text="Hello World">
<styles color="#ff0000" font="Arial BOLD 24"/>
</Label>
This is more consistent with how values are set elsewhere in BXML. The JSON syntax is supported more for legacy reasons than anything else.
> Add to that the fact that there's no smart editor for bxml files, and the result is it takes me an order of magnitude longer to write a bxml file than it does to write the corresponding xaml file in WPF.
I agree. I really appreciate Eclipse's code completion features in Java, and I do miss having them when editing BXML.
> Meanwhile, I guess I should just submit a feature request? Seems like adding an "AcceptsEnter" property to TextAreaSkin ought to be a super easy change.
A feature request would be good - though a boolean "multiline" style might be clearer.
G
Re: How to get a wrapped TextInput?
Posted by Chris Bartlett <cb...@gmail.com>.
(Apologies for the delay, I thought I posted this the other day, but
obviously forgot).
This post from another thread has an example app which demonstrates that
subclassing components & skins need not be a difficult task.
http://apache-pivot-users.399431.n3.nabble.com/KeyListeners-on-ImageView-tp2600622p2602733.html
On 25 February 2011 13:23, Chris Bartlett <cb...@gmail.com> wrote:
> I'll try to post some example code ASAP to demonstrate subclassed
> components/skins with customised ComponentKeyListeners handling..
>
> Chris
>
Re: How to get a wrapped TextInput?
Posted by Bill van Melle <bi...@gmail.com>.
Thanks for the long and thoughtful reply, Chris.
I have no experience with WPF & XAML, so this might be a stupid question,
> but does it easily allow end users to make modifications to component
> behaviour? If so, perhaps that is something that Pivot can learn from.
>
Appearance, yes. There is a notion of a control template, which you can
replace (in xaml, typically) to entirely change how a control looks without
effecting its essential nature. E.g., you can change how a Button looks
when the user hovers over it or presses it, while leaving it be a Button in
all other regards. It's an extremely powerful facility, with an equally
steep learning curve. So I wouldn't use the word "easily".
> You mentioned that TextBox has 'AcceptsReturn' & 'TextWrapping' attributes,
> but what if it didn't? What would be the process for adding them yourself
> if you had to?
>
I would subclass TextBox. To implement AcceptsReturn, I'd declare what they
call a "Dependency Property" (maybe something like a Pivot notifying
property?) and then override OnKeyDown to intercept Enter and prevent the
base class from handling it. Or something like that. Hard to say for sure
without trying. TextWrapping would be much harder. There's a bunch of
methods to override relating to measuring and laying out and painting.
> If you find component functionality in WPF (or other GUI frameworks) that
> does not exist in Pivot, feel free to discuss it on the list, submit feature
> requests in JIRA or even provide patches to implement the behaviour.
>
Will do, and have done -- you may notice I regularly refer to WPF
equivalents in some of my messages.
As for documentation, some sort of automated tool that extracted the bean
properties of Foo and FooSkin and presented them in a simple format would be
much nicer than trying to find my way thru the current JavaDoc.
Re: How to get a wrapped TextInput?
Posted by Chris Bartlett <cb...@gmail.com>.
I'm sure others on the list might also be able to add to this thread, but
here are my comments.
On 25 February 2011 09:53, Bill van Melle <bi...@gmail.com> wrote:
> Thanks, I guess. But yowza, this is you as a Pivot implementor speaking,
> not very helpful advice to an end developer. Let's see, I need to
> understand enough about skins to be able to subclass one and get my subclass
> installed.
As I said, I really struggled with this side of things when I first started
using Pivot, and have since created my own subclasses of components and
skins that I reuse where required (almost exclusively to modify keyboard
handling). I will post some example code later to demonstrate that it need
not be a difficult thing to do.
Just because I am relatively vocal on the mailing lists doesn't make me any
kind of expert :) I'm just someone who has become more familiar with it
Pivot over time and contributed a little to the codebase..
> Then you quote a thread with a workaround that seems to require editing the
> Pivot sources. If I want to edit the sources, I'd just go and edit TextAreaSkin
> to add an "AcceptsEnter" property.
The workaround is due to a bug so is not representative of the normal course
of action. As far as I am aware, no other Pivot components suffers from a
similar issue, and can therefore be extended easily.
> I've tried to avoid learning too much about skins. I suspect I will
> eventually have to learn more, since I'm pondering creating a custom
> container class. But skins are a royal pain. I can sorta see how they
> provide an avenue to extravagant customization, like WPF control templates
> do.
>
As Pivot currently ships with only one Theme (Terra), it might make the
platform seem unnecessarily complex. If there were more themes or even just
some alternative skins for certain Components, it might help to clarify the
reasoning behind the related design decisions. Some additional
documentation and/or examples relating to this could be useful.
> But to the average programmer, the distinction between component classes
> and their skins and which properties live where frequently seems arbitrary.
>
>
Agreed, I have various items on my 'to do' list regarding reviews of
functionality of components & skins to ensure that the code is where it
belongs. This has mainly come from my need/desire to modify the keyboard
processing of various components.
As I understand things, code maintaining the 'model' of the Component should
be in a Component class, but the look and feel should be in one or more skin
classes. Part of the problem I had was that I was generally happy with the
'look' of a component, but altering the 'feel' (keyboard handling &
graphical effects) was not possible without creating my own subclasses or
skins. I had considered writing some generic code to strip off all Pivot
provided ComponentKeyListeners from components and then simply adding my own
in a single, easily maintainable place.
Every time I want to set attributes on an object, I have to look two places
> in the javadocs, and use two different syntaxes in bxml.
>
We have an open JIRA ticket relating to the javadoc side of things.
https://issues.apache.org/jira/browse/PIVOT-530
I have created a couple of utilities for my own use that allow me to more
easily browse the available properties (component) and styles (skin) for a
particular Component. As is often the case, I've not yet found the time to
tidy up the code and make it available for others to use, either as a
submission to Pivot or separately.
This post talks about a couple of changes that I was thinking of making to
BeanAdapter in order to simplify tooling, but I've been swamped the last few
weeks and have not even found the time to post a couple of follow ups to the
thread. (BeanAdapter is used internally by BXMLSerializer to create the
object graph)
http://apache-pivot-developers.417237.n3.nabble.com/Some-thoughts-on-BeanAdapter-tp2309139p2309139.html
I really feel that some simple tools would be greatly beneficial for
newcomers to Pivot and have every intention of helping out on that front as
soon as I can spare the time.
> Sorry to rant like that, but the preceding paragraph spells out what I
> think is by far the greatest weakness of the Pivot framework.
>
Feedback is welcomed, especially when it is constructive, so no need to
apologize :)
I have no experience with WPF & XAML, so this might be a stupid question,
but does it easily allow end users to make modifications to component
behaviour? If so, perhaps that is something that Pivot can learn from.
You mentioned that TextBox has 'AcceptsReturn' & 'TextWrapping' attributes,
but what if it didn't? What would be the process for adding them yourself
if you had to?
If you find component functionality in WPF (or other GUI frameworks) that
does not exist in Pivot, feel free to discuss it on the list, submit feature
requests in JIRA or even provide patches to implement the behaviour.
Meanwhile, I guess I should just submit a feature request? Seems like
> adding an "AcceptsEnter" property to TextAreaSkin ought to be a super easy
> change.
>
https://issues.apache.org/jira/browse/PIVOT
(I think the new JIRA requires you to register & log in before you can even
see a button to add a new ticket.)
Rather than just adding an equivalent of the WPF 'AcceptsEnter' attribute,
it might be more flexible to allow a Filter to be supplied to determine
which characters should be suppressed?
http://pivot.apache.org/2.0/docs/api/org/apache/pivot/util/class-use/Filter.html
Although, if it weren't for the TextArea subclassing bug, then this should
be simple to add by an end user if required.
To summarize, I have felt some of your pain and think that a number of
improvements can be made Pivot. I'll try to post some example code ASAP to
demonstrate subclassed components/skins with customised
ComponentKeyListeners handling..
Chris
Re: How to get a wrapped TextInput?
Posted by Bill van Melle <bi...@gmail.com>.
Thanks, I guess. But yowza, this is you as a Pivot implementor speaking,
not very helpful advice to an end developer. Let's see, I need to
understand enough about skins to be able to subclass one and get my subclass
installed. Then you quote a thread with a workaround that seems to require
editing the Pivot sources. If I want to edit the sources, I'd just go and
edit TextAreaSkin to add an "AcceptsEnter" property.
I've tried to avoid learning too much about skins. I suspect I will
eventually have to learn more, since I'm pondering creating a custom
container class. But skins are a royal pain. I can sorta see how they
provide an avenue to extravagant customization, like WPF control templates
do. But to the average programmer, the distinction between component
classes and their skins and which properties live where frequently seems
arbitrary. Every time I want to set attributes on an object, I have to look
two places in the javadocs, and use two different syntaxes in bxml. Add to
that the fact that there's no smart editor for bxml files, and the result is
it takes me an order of magnitude longer to write a bxml file than it does
to write the corresponding xaml file in WPF.
Sorry to rant like that, but the preceding paragraph spells out what I think
is by far the greatest weakness of the Pivot framework.
Meanwhile, I guess I should just submit a feature request? Seems like
adding an "AcceptsEnter" property to TextAreaSkin ought to be a super easy
change.
Re: How to get a wrapped TextInput?
Posted by Chris Bartlett <cb...@gmail.com>.
I just remembered that there is a bug preventing TextArea from being
subclassed.
https://issues.apache.org/jira/browse/PIVOT-690
See the thread listed in the ticket's comments for more info and a quick and
dirty workaround.
http://apache-pivot-developers.417237.n3.nabble.com/TextAreaSkin-tp2068356p2125940.html
Chris
On 25 February 2011 05:46, Chris Bartlett <cb...@gmail.com> wrote:
> Bill,
>
> I don't have a lot of time to reply right now, but can reply further if
> required a bit later.
>
> The bottom of this tutorial page describes event propagation in Pivot,
> although it is fairly brief.
> http://pivot.apache.org/tutorials/component-and-container.html
>
> ComponentKeyListeners for Pivot Components will generally be added to the
> Component's skin upon creation.
> So for TextArea, the ComponentKeyListeners will be in
> org.apache.pivot.wtk.skin.TextAreaSkin (rather than TerraTextAreaSkin).
> You will see TextAreaSkin#keyPressed(Component, int, KeyLocation) has the
> logic to process the ENTER key.
>
> The problem comes when you try to add your own ComponentKeyListeners to try
> to override this logic.
> If you just add your listener to a standard TextArea, it will be processed
> after any other listeners which were added before it. This means that the
> TextAreaSkin#keyPressed(...) code will already have run before your code
> gets a chance to do anything.
>
> For any given class, all of the listeners (ComponentKeyListeners or other
> kinds) added at a particular hierarchy will be executed in the order they
> were added to the class. If you want to override some logic in a listener, I
> think you will need to create subclass, add your listener to that, and
> ensure that you consume the event. When the event has been consumed it will
> no longer propagate up or down the hierarchy, and therefore can block the
> execution of other listeners.
>
> I really struggled with this when I was new to Pivot, but once I got used
> to creating subclasses as and when I needed them, it pretty much all came
> together.
>
> Chris
>
>
>
> On 25 February 2011 05:20, Bill van Melle <bi...@gmail.com>wrote:
>
>> There are two text input controls (that I know of), TextInput and
>> TextArea. TextInput accepts a single line of text, but it is also only a
>> single line on the screen, with no provision for wrapping text instead of
>> clumsily horizontally scrolling. TextArea happily wraps text, but it also
>> accepts the Enter key to insert newlines into the content.
>>
>> What I'm looking for is a control that accepts only a single line of
>> input, but wraps. It should not accept the Enter key, but instead allow that
>> key to close a dialog. I tried using a TextArea to which I added
>> a ComponentKeyListener with this override:
>>
>> public boolean keyTyped(Component component, char character) {
>> if (character == Keyboard.KeyCode.ENTER) {
>> close(true);
>> return true;
>> }
>> return false;
>> }
>>
>> That only partly works -- it closes the dialog when the Enter key is
>> pressed, but it also inserts a newline into the TextArea. I guess that's
>> the downside of no guaranteed ordering of listeners. However, even if I
>> move that logic to the keyPressed method instead, it doesn't help.
>>
>> Am I missing something? I can, of course, post-process the input to
>> remove the newline, but that seems crufty.
>>
>> (FWIW, the WPF control corresponding to both of these controls, TextBox,
>> lets me do this by setting attributes AcceptsReturn=False and
>> TextWrapping="Wrap".)
>>
>
>
Re: How to get a wrapped TextInput?
Posted by Chris Bartlett <cb...@gmail.com>.
Bill,
I don't have a lot of time to reply right now, but can reply further if
required a bit later.
The bottom of this tutorial page describes event propagation in Pivot,
although it is fairly brief.
http://pivot.apache.org/tutorials/component-and-container.html
ComponentKeyListeners for Pivot Components will generally be added to the
Component's skin upon creation.
So for TextArea, the ComponentKeyListeners will be in
org.apache.pivot.wtk.skin.TextAreaSkin (rather than TerraTextAreaSkin).
You will see TextAreaSkin#keyPressed(Component, int, KeyLocation) has the
logic to process the ENTER key.
The problem comes when you try to add your own ComponentKeyListeners to try
to override this logic.
If you just add your listener to a standard TextArea, it will be processed
after any other listeners which were added before it. This means that the
TextAreaSkin#keyPressed(...) code will already have run before your code
gets a chance to do anything.
For any given class, all of the listeners (ComponentKeyListeners or other
kinds) added at a particular hierarchy will be executed in the order they
were added to the class. If you want to override some logic in a listener, I
think you will need to create subclass, add your listener to that, and
ensure that you consume the event. When the event has been consumed it will
no longer propagate up or down the hierarchy, and therefore can block the
execution of other listeners.
I really struggled with this when I was new to Pivot, but once I got used to
creating subclasses as and when I needed them, it pretty much all came
together.
Chris
On 25 February 2011 05:20, Bill van Melle <bi...@gmail.com> wrote:
> There are two text input controls (that I know of), TextInput and TextArea.
> TextInput accepts a single line of text, but it is also only a single line
> on the screen, with no provision for wrapping text instead of clumsily
> horizontally scrolling. TextArea happily wraps text, but it also accepts
> the Enter key to insert newlines into the content.
>
> What I'm looking for is a control that accepts only a single line of input,
> but wraps. It should not accept the Enter key, but instead allow that key to
> close a dialog. I tried using a TextArea to which I added
> a ComponentKeyListener with this override:
>
> public boolean keyTyped(Component component, char character) {
> if (character == Keyboard.KeyCode.ENTER) {
> close(true);
> return true;
> }
> return false;
> }
>
> That only partly works -- it closes the dialog when the Enter key is
> pressed, but it also inserts a newline into the TextArea. I guess that's
> the downside of no guaranteed ordering of listeners. However, even if I
> move that logic to the keyPressed method instead, it doesn't help.
>
> Am I missing something? I can, of course, post-process the input to remove
> the newline, but that seems crufty.
>
> (FWIW, the WPF control corresponding to both of these controls, TextBox,
> lets me do this by setting attributes AcceptsReturn=False and
> TextWrapping="Wrap".)
>