pivot-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chris Bartlett <cbartlet...@gmail.com>
Subject Re: How to get a wrapped TextInput?
Date Fri, 25 Feb 2011 06:23:01 GMT
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 <bill.van.melle@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.

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)

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.
(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?
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..


View raw message