Java desktop links of the week, October 18

Welcome to another week of Java desktop links 🙂

This week I think is actually quite a good week of links. Whilst the quantity of links is somewhat low, there is great quality and depth to what is being done in the Java desktop world at the moment, and it’s quite fun to read what everyone is up to. Keep up the great work folks! Now, on with the links.

Swing

JavaFX

  • Coming up on November 10 is the next Silicon Valley JavaFX Users Group talk, which is also broadcast in video live to those not in the Silicon Valley area. The November talk is Stephen Chin reprising the talk he and I gave at JavaOne on JavaFX 2.0 using alternative languages (for those unwilling to wait until November 10, you can find the slides we used on my blog). He will also be giving more details on project Visage, the fork of the JavaFX Script compiler to support the JavaFX Script language on JavaFX 2.0 and alternate GUI toolkits.
  • Martin Ryzl has put up a screencast on how to use new data sources in JavaFX Composer in the NetBeans 6.10 M1 IDE.
  • IBM DeveloperWorks has an article up on how to ‘use JavaFX to quickly create applications‘, with the subtitle of ‘JavaFX + Eclipse IDE = Easy GUI’
  • Last week I mentioned that Kim Topley has released a new book about JavaFX 1.3. This week there is an excerpt from this book available at InformIT. It covers JavaFX effects and blends.

That’s us for another week. Like I said, there wasn’t alot of links, but I hope you found one or two of them interesting. Catch you all in a weeks time.

13 thoughts on “Java desktop links of the week, October 18”

  1. i wonder if i am alone in actually quite liking gridbaglayout? i just find it conceptually quite simple and useful for the stuff i tend to do.

    perhaps i don’t do complex enough guis.

    1. I used to use GBL as well, but after MigLayout not anymore. it’s not about complex layouts, but about ease of use; ML makes much more sense when writing layout code than GBL. “Add component, growX, wrap to new line, add component, spanX(2), add component, dockEast, etc”.

      1. > I used to use GBL as well, but after MigLayout not anymore

        fair point, miglayout looks like it does GBL + borderlayout + far more in a nicer way.

        the big problem i have though, which i doubt any layout manager can really solve is complex and subtle bugs in the swing component rendering — e.g. components inside a jscrollpane having the lower pixels cut off, not getting the correct events on showing etc.

        for the swing guis of http://intrinsarc.com/evolve/screenshots I had to find quite a few work arounds…

  2. I’m also a big fan of Gridbaglayout. However if you want to get the most out of it, wrap it in a fluent helper class. You can literally save hundreds of lines of code!

    Code Usage looks like:
    JPanel panel = new JPanel();
    GridBagHelper helper = new GridbagHelper(panel);

    helper
    .add(someComponent).add(someOtherComponent)
    .newRow()
    .gridwidth(2).weightx(1).fillHoriz().add(reallyLongComponent)
    ;

    1. I did use GBL with a helper class, and that may take it close to MigLayout in basic usability (not counting the advanced layout things like docking, grouping, etc), there still is the fact that GBL has some real issues when it comes to handling certain situations like when components have less room than expected (they are not scaled down then, but immediately collapsed to 0 width).

      GroupLayout is also a good LM, however the code is absolutely unreadable for humans. And as long as there is no standalone designer (AFAIK only NetBeans and a commercial IDE have one) it is not an option.

      Do note that I have no part in the development of MigLayout; I simply am pleased to have switched to it. And yes, it too has “gotchas”. Nothing is perfect.

  3. Gridbaglayout may be one of the most used layout managers – until GroupLayout and MigLayout, et. al., came on the scene, so it might be used more in ‘legacy’ code, but it was never my favorite and I don’t know anybody who enjoyed it. It was a necessary evil until something better came along.

    1. what i really like about designgridlayout is that it is uses objects instead of cryptic constraints. i may be wrong, but i think it’s the only layout manager designed in the OO paradigm FWIW.

      1. I’m not seeing the OO part, maybe you can clarify. I do see a fluent interface
        row().add(xxx).add(yyy)

        What is good is that you have methods to specify the contraints. I prefer that for ML as well:
        add(xxx, new CC().spanX(2).growY())

        The idea of DGL is great, but IMHO limited to fairly regular layouts. And it still isn’t perfect: in the examples there are a lot of components vertically off.

        1. Yes, DGL is “limited”, but how many applications are exclusively made of atypical layouts?

          Regarding “vertically off components”, this is because you didn’t read the text accompanying the screenshots 😉 DGL proposes the smart vertical resize so that no JTable/JList can show truncated rows, of course this has side-effects, but if you don’t like it this way, you can easily disable that feature.

          1. No I did not indeed. Not intentionally, I was just gazing over the examples and saw some components vertically lined out wrong (tops not aligned). I would have discarded DGL as a candidate on that, if I were searching for a LM, even though there is a text beside it.

        2. >I’m not seeing the OO part, maybe you can clarify.
          >I do see a fluent interface row().add(xxx).add(yyy)

          from memory (and it’s been over a year since i used it in detail), the fluent interface is a thin layer over the object layer. i preferred the object layer, as i make a tool for configuring structure, and it works well with the objects in that layer.

          from https://designgridlayout.dev.java.net/nonav/site/usage.html

          you can either use this:
          IRow row = layout.row().grid();
          row.add(button());
          row.add(button());

          or this:
          layout.row().grid().add(button()).add(button());

          for programming code directly, i prefer the latter. for understanding and advanced or generated code I prefer the former.

Leave a Reply