Mac Widgets for Java – 0.9.3
November 29, 2008
I’ve just released Mac Widgets for Java 0.9.3. The major addition is iApp style scroll bars, which you can learn how to use here. You’ll find the full list of enhancements and fixes here.
In the next few posts, I’ll be talking about the SkinnableScrollBarUI delegate and supporting infrastructure I created to support creating the iApp scroll bars.
Exploding Pixels 
November 30, 2008 at 6:30 am
Great stuff Ken. You’ve made developing swing apps fun again. :)
December 1, 2008 at 12:39 pm
Glad to hear Zack!
December 1, 2008 at 2:21 pm
Very cool!
I’ve only played around with 0.9.3 for about thirty minutes, but a couple of questions came to mind (forgive me if they’re blatantly simplistic or answered elsewhere).
One: Any plans for drag-n-drop to/from a SourceList?
Two: If you don’t mind explaining, why did you choose to make SourceListItem a class instead of an interface? It would seem that having it as an interface would be more flexible for adding things to a SourceList (and then a DefaultSourceListItem could be provided as a concrete class for simply situations).
Thanks, and, once again, very cool work!
December 1, 2008 at 5:45 pm
[…] Orr has announced release 0.9.3 of Mac Widgets for Java. Major new addition in this release – iApp style scroll bars. Is it me, or […]
December 1, 2008 at 11:43 pm
Nicely done. I am curious about your decision to make the SkinnableScrollBarUI delegate. Also why the static calls to make JScrollPanes: why not just make UI’s instead? I hope these are questions addressed in future posts. :)
December 2, 2008 at 12:25 am
Hi Jeremy,
I’m not sure I understand your question about my decision to create a scroll bar UI delegate (SkinnableScrollBarUI)?
In general, I prefer to limit the number of classes I create, so when possible, I make them configurable such that I don’t need a sub-class. In this case, I didn’t need a specific IAppScrollBarUI because I made a more general class that took a ScrollBarSkin, which provided all the necessary painters.
And don’t worry, I wasn’t over engineering! I plan to add additional skins for HUD style scroll bars.
The static methods are just stateless convenience methods.
Does that address your questions?
-Ken
December 2, 2008 at 6:39 am
Nice work on this!
On Google Code, I filed an issue I ran into while integrating it into my application that had to do with flickering. Any feedback on that issue or the other one (which is an RFE) would be appreciated. Thanks!
– Jon
December 12, 2008 at 1:25 pm
Hi K,
Sorry for the delayed response to your comment, which was flagged as spam for some reason!
Re. Are there plans to add drag-and-drop support to SourceList?
Not at the moment, but if that’s something you’d like to see, I encourage you to submit an enhancement request here.
Re. Why isn’t SourceListItem an interface?
Good question. The API for SourceList evolved somewhat, so I’m not 100% sure that the current implementation is the ideal implementation (feed back on your use case is welcome, kenneth.orr@gmail.com). I think your probably right though, that SourceListItem should in fact be an interface. Having a concrete implementation forces people to map from SourceListItems to their real data, which is wasteful. I’ll think about this some more and try and make the API more developer-friendly.
-Ken
January 26, 2009 at 7:59 am
Hi, I just wanted to say i think this work is great and that another good addition would be a split pane with a thin splitter to go with the Source List.
Thanks
-James
January 26, 2009 at 12:25 pm
Hi James,
Thanks, glad you like the library. As for the splitpane, such a component already exists:
MacWidgetFactory.createSplitPaneForSourceList(sourceList, anotherComponent)
-Ken
February 12, 2009 at 9:18 am
Hi Ken,
what was the reason that you decided against building JavaBeans? I am using NetBeans as an IDE and would like to add your nice components into my palette. Are there possibly any plans in that direction?
You wrote about why you have chosen that design (was it to rebuild cocoas design?) but I wonder why you decided against a design tightly integrated into java.
I find creating and using your components very complicated because of the design.
Thanks for the components,
Christian
February 12, 2009 at 1:49 pm
Hi Christian,
I chose a component-oriented approach, which is different than Swing’s inheritance based design. I did this mainly to help keep the API simple and easy to use.
I do understand that the approach I’ve chosen can have the opposite effect I was intending when developers want to use visual design tools. There has been another request for better integration into design tools, so it is something I’m thinking about. I was contemplating writing adapter classes for use with design tools, but I’m not sure whether this is the right approach.
One thing I’ve been doing in order to alleviate some of the tension you mention is to introduce UI delegates whenever possible that can be used on standard Swing components. For example, there is now a SourceListTreeUI that can be installed on a regular JTree. This doesn’t address the entire problem though, as the developer doesn’t have access to the convenient API provided by SourceList.
Feel free to provide further thoughts on the matter.
-Ken