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 <[email protected]> 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
