Mac Widgets for Java – 0.9.3

November 29, 2008

iappscrollbars-promo-new

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.

Advertisements

12 Responses to “Mac Widgets for Java – 0.9.3”

  1. Zack Says:

    Great stuff Ken. You’ve made developing swing apps fun again. :)

  2. Ken Says:

    Glad to hear Zack!

  3. K Says:

    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!


  4. […] 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 […]

  5. Jeremy Says:

    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. :)

  6. Ken Says:

    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

  7. Jonathan Says:

    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

  8. Ken Says:

    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

  9. James Says:

    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

  10. Ken Says:

    Hi James,

    Thanks, glad you like the library. As for the splitpane, such a component already exists:

    MacWidgetFactory.createSplitPaneForSourceList(sourceList, anotherComponent)

    -Ken

  11. Christian Says:

    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

  12. Ken Says:

    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


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: