I actually like the idea of making such "add-ons" public, but I think they might be better suited to a "Pivot cookbook" than a repository of custom components. I envision something along the lines of the Pivot tutorial, but a bit more targeted (e.g. "how do I build a combo box?", "how do I write a custom tree node renderer?", etc.). I would want this to be a place where the community can post their own examples in addition to any we might post.
The reason I like this approach is that, in general, these things *are* supported by the platform - we just can't support every possible permutation out of the box. This way, developers can see how such features are actually built, which will help build their understanding of other ways in which the platform can be customized. To your point about being patient: I agree. But it is difficult. :-) I also don't see any harm in being proactive where we can. So, in my opinion, the more we can do to promote Pivot, the better. G On Feb 23, 2010, at 7:29 AM, Todd Volkert wrote: > That's a good point Noel. I actually created > http://code.google.com/p/pivot-contrib/ a couple of weeks ago just to backup > a layout container that I was working on that was too app-specific to be in > the platform. I don't like the idea of putting stuff like that > (app-specific add-ons) in the platform, but there's no legal reason to put > it on Google Code either... it's almost as if we could create a separate > hierarchy in SVN that lived off the trunk and never got released where we > could put stuff like this. Then if newbies wanted widget X, and someone had > built it before in this playground, we could just point the newbie there, > and they could fork it and build it themselves. > > I know Niclas created "skunk" as a sibling to "trunk", but I'm not sure > that's appropriate, as I think it was meant for experimental features that > may be included in the trunk some day... > > In any case, what do others think? > -T > > On Tue, Feb 23, 2010 at 3:19 AM, Noel Grandin <[email protected]> wrote: > >> Hi >> >> Pivot is still showing normal early stage adoption i.e. a trickle of >> interest. These things tend to ramp in bursts, so my counsel would >> simply be to be patient. >> >> I agree on the SWT issue - I don't think porting Pivot to SWT would >> improve adoption. SWT already has JFace, Nebula and various other >> additional widget libraries. >> >> On the other hand, Pivot is a great example of how good Swing could be >> if it was allowed to evolve :-) >> >> I do notice that we're getting various conversations along the lines of >> >> Newbie: "X is very easy to do with toolkit Y" >> Pivot-guru: "You could implement X on top of component C" >> Newbie: "That's too hard! Can't you just add it?" >> Pivot-guru: "Adding that feature doesn't really fit into our architecture" >> >> Which is reasonable, but maybe we should be implementing these features >> in some kind of extras package until we have a good enough idea of how >> to fit the features into the main codebase? >> >> -- Noel >> >> On 2010-02-23 00:14, Greg Brown wrote: >>> Though we have only gotten two responses on the SWT question, it seems as >> though an SWT port may not be the best way to move Pivot forward. Michael >> made some great suggestions. What do others think? What can we do to help >> raise awareness of and interest in Pivot as a viable alternative to other >> Java-based UI technologies? >>> >>> >> >>
