Bill, You raise a couple of different points, for now I will just chip in quickly where I might be of assistance.
On 18 March 2011 06:23, Bill van Melle <[email protected]> wrote: > ... not long ago Chris invited me to discuss things from there or elsewhere > that I thought might benefit Pivot, so here I am. > Yep, I certainly feel that highlighting the comparative strengths, weaknesses and features of Pivot and its 'peers' can be a useful thing, but as I'm sure you are aware, you are likely to get a better response on any mailing list when providing constructive criticism in a non-inflammatory way. (Apologies if that comes across as patronizing, it is not meant to be) I am not in a position to look at your BXML right now, but will try to ASAP, and will reply again then if I have any useful suggestions. Without wishing to go too far off topic... In order to make some of my BXML less verbose, I have subclassed Pivot Containers and added certain defaults and custom properties. One example of this is what I called a StripPane, which is simply a subclassed TablePane which maintains an ordered list of Components and has an orientation property. When the orientation property is 'horizontal' the TablePane will contain a single row, and n columns if there are n components. Changing the orientation to 'vertical' will cause the columns and row to be removed, before a single new column is added, along with n rows. Along with a 2nd quick hack (which I can explain another time) to give me full control over the sizes of the tablepane's cells (absolute/relative -1,n*,n etc) this essentially gives me an enhanced BoxPane, but without requiring huge amounts of markup. Perhaps something like this could simplify things for you without requiring you to create custom containers from scratch. The approach works fine for me but smells hacky and is not ideal. For instance as I simply subclassed TablePane (through laziness) it is easy to treat the StripPane as a regular TablePane and mess things up royally. > * The XAML editor has Intellisense. That means there are autocompletion > hints on property names, and easy access to their documentation. In Pivot, > I have to be constantly flipping thru the javadoc just to remember how to > spell things and which components have which properties, and whether it's a > component property or a style property. After a while I get better at the > spelling part (though capitalization sometimes trips me up), but remembering > which components have what property I'm not fluent in yet. > We have discussed the property/style/javadoc side of things before. I will try to get a simple tool posted to the list over the next few days which might help out with that. > * There's a visual designer, so in most cases I don't have to run my app to > see whether I got it right, or at least close. The Pivot plugin for Eclipse > helps a tiny bit, but only for standalone bxml files, which is a rarity for > me -- most of the time I have a backing class. > I have gone through a few iterations of a BXML viewer tool which simply polls a BXML file for changes and then reloads and displays it, or whatever errors occurred. It has evolved into something a little more complex now, but even the simple version would work with fine with classes implementing the Bindable interface, and allowed me to create small, functionaly independent chunks of BXML with behavior that could be tested by just loading into the viewer. * Events are a bit simpler. That's mostly Java's fault, not Pivot's, but it > still is a learning issue. In WPF, if I want to be notified when my control > is resized, I add a single method (or even a closure) to the control; I > don't have to write a ComponentListener with 11 (!) methods, 10 of which go > unused. I can also see all the supported events in a single place in the > documentation, rather than having to scan thru the javadoc of multiple > listeners. > Um, are you aware of the Adapters which are provided for most Listeners with 2 or more methods? They have minimal/no-op method bodies and are intended to be extended, meaning you just override the methods that you actually need. http://pivot.apache.org/2.0/docs/api/org/apache/pivot/wtk/ComponentListener.Adapter.html Pivot's Listeners seem to follow a naming convention (not sure if it is formal or documented anywhere) whereby the class that defines the 'events' is used first, followed by a descriptive word categorizing the group of events (where applicable) and then the word 'Listener' eg ComponentMouseButtonListener <- mouse button events defined at the Component level TablePaneListener <- events relating to the TablePane model We have a JIRA task for creating a custom Doclet which might well include detailing all the listeners along with properties, attributes, default skin, styles etc. https://issues.apache.org/jira/browse/PIVOT-530 So when there are things from WPF that I think would make Pivot more usable, > I hope I can bring them up. Earlier I've mentioned such things as a > ScalingPane (something I could really use right now and have no idea how to > implement myself) and simpler markup for document spans of text (which you > fixed in 2.0.1, thank you). I often hesitate to do so, lest you feel I'm > casting aspersions on Pivot. I'm probably coming off as way to much of a > WPF fanboy as it is, which is unfortunate, since I and my colleagues get mad > at Microsoft all the time... > I don't remember having seen anyone 'shot down' on the mailing lists for filing JIRA feature requests, bug reports or similar, so I hope you don't feel too hesitant about posting in the future. I imagine that many of those who have posted to the mailing list first did so to report a bug (I did). As mentioned at the top of my reply - stating that 'framework X achieves Y by doing Z, but Pivot doesn't do X' is fine. Hopefully such an email will take the form of asking if it is possible to achieve X with Pivot and that will lead to a discussion of whether X is indeed required, can be achieved another way, whether its inclusion would fit into the Pivot, and how it might affect compatibility (etc etc). I'm not suggesting that every feature request will always be accepted, but any idea should get a fair hearing and some justification for why it might be rejected. Chris
