Comments for David Qiao's Blog http://www.jidesoft.com/blog Love being a Swing developer Tue, 24 Jan 2012 00:26:01 +0000 hourly 1 http://wordpress.org/?v=3.3.1 Comment on Analysing code size using JIDE TreeMap by Java desktop links of the week, January 24 | Jonathan Giles http://www.jidesoft.com/blog/2012/01/18/analysing-code-size-using-jide-treemap/comment-page-1/#comment-17927 Java desktop links of the week, January 24 | Jonathan Giles Tue, 24 Jan 2012 00:26:01 +0000 http://www.jidesoft.com/blog/?p=161#comment-17927 [...] David Qiao has posted two blog posts related to the Jide libraries. The first post is about improvements to the CellStyle feature in JIDE Grids. The second post is about analysing code using the Jide TreeMap component. [...] [...] David Qiao has posted two blog posts related to the Jide libraries. The first post is about improvements to the CellStyle feature in JIDE Grids. The second post is about analysing code using the Jide TreeMap component. [...]

]]> Comment on A great enhancement to the CellStyle feature in JIDE Grids by Java desktop links of the week, January 24 | Jonathan Giles http://www.jidesoft.com/blog/2012/01/17/152/comment-page-1/#comment-17926 Java desktop links of the week, January 24 | Jonathan Giles Tue, 24 Jan 2012 00:25:34 +0000 http://www.jidesoft.com/blog/?p=152#comment-17926 [...] Qiao has posted two blog posts related to the Jide libraries. The first post is about improvements to the CellStyle feature in JIDE Grids. The second post is about analysing code using the Jide TreeMap [...] [...] Qiao has posted two blog posts related to the Jide libraries. The first post is about improvements to the CellStyle feature in JIDE Grids. The second post is about analysing code using the Jide TreeMap [...]

]]> Comment on ExpandedTip – A must-have feature for your JTree and JList by Java desktop links of the week, November 28th | Jonathan Giles http://www.jidesoft.com/blog/2011/11/23/expanded-tip/comment-page-1/#comment-17901 Java desktop links of the week, November 28th | Jonathan Giles Sun, 27 Nov 2011 22:56:04 +0000 http://www.jidesoft.com/blog/?p=133#comment-17901 [...] JIDE Software has put out a new release of their software, taking the version numbers up to 3.3.0. One of the new features in the ExpandedTip API. [...] [...] JIDE Software has put out a new release of their software, taking the version numbers up to 3.3.0. One of the new features in the ExpandedTip API. [...]

]]> Comment on Meet our first JavaFX component by Java desktop links of the week, October 24 | Jonathan Giles http://www.jidesoft.com/blog/2011/10/04/meet-our-first-javafx-component/comment-page-1/#comment-17894 Java desktop links of the week, October 24 | Jonathan Giles Mon, 24 Oct 2011 06:22:35 +0000 http://www.jidesoft.com/blog/?p=118#comment-17894 [...] Software has released a free-to-use JavaFX RangeSlider control (that is, a Slider that has two thumbs rather than one). All I can say is keep up the great work! I [...] [...] Software has released a free-to-use JavaFX RangeSlider control (that is, a Slider that has two thumbs rather than one). All I can say is keep up the great work! I [...]

]]> Comment on Meet our first JavaFX component by JavaFX links of the week, October 24 // JavaFX News, Demos and Insight // FX Experience http://www.jidesoft.com/blog/2011/10/04/meet-our-first-javafx-component/comment-page-1/#comment-17893 JavaFX links of the week, October 24 // JavaFX News, Demos and Insight // FX Experience Mon, 24 Oct 2011 06:22:03 +0000 http://www.jidesoft.com/blog/?p=118#comment-17893 [...] Software has released a free-to-use JavaFX RangeSlider control (that is, a Slider that has two thumbs rather than one). All I can say is keep up the great work! I [...] [...] Software has released a free-to-use JavaFX RangeSlider control (that is, a Slider that has two thumbs rather than one). All I can say is keep up the great work! I [...]

]]> Comment on What’s wrong with Apple by David Qiao http://www.jidesoft.com/blog/2009/06/16/whats-wrong-with-apple/comment-page-1/#comment-7596 David Qiao Thu, 18 Jun 2009 17:40:59 +0000 http://www.jidesoft.com/blog/?p=73#comment-7596 Now all classes are under com.apple.laf. What does it mean? None of L&F related code are public? The only way to do the feature we want to do is to use a handful of properties? That's just not possible. After all, what is the criteria of a "public API"? As a matter of fact, I already asked some specific questions on the mailing list to make component vendor like us easier to do certai things. And the answer is no, they are not interesting supporting it. Saying that, I do understand why they don't want to support. The more public APIs, the more effort to support them later. We are in the same position as we are also component provider. Regarding Osvaldo's idea to use wrapper, sometimes it is just not possible. For example, we have to extend AquaTableHeaderUI to support column grouping feature. Right now we still extend the one in apple.laf so that the code works on both old and new Apple JDK because the old one is just deprecated. When Apple removes all classes from apple.laf, our code will break again. I don't really know how to use reflection or wrapper to workaround this potential issue. I guess we will just have to face the consequence. Now all classes are under com.apple.laf. What does it mean? None of L&F related code are public? The only way to do the feature we want to do is to use a handful of properties? That’s just not possible. After all, what is the criteria of a “public API”?

As a matter of fact, I already asked some specific questions on the mailing list to make component vendor like us easier to do certai things. And the answer is no, they are not interesting supporting it. Saying that, I do understand why they don’t want to support. The more public APIs, the more effort to support them later. We are in the same position as we are also component provider.

Regarding Osvaldo’s idea to use wrapper, sometimes it is just not possible. For example, we have to extend AquaTableHeaderUI to support column grouping feature. Right now we still extend the one in apple.laf so that the code works on both old and new Apple JDK because the old one is just deprecated. When Apple removes all classes from apple.laf, our code will break again. I don’t really know how to use reflection or wrapper to workaround this potential issue. I guess we will just have to face the consequence.

]]> Comment on What’s wrong with Apple by William Woody http://www.jidesoft.com/blog/2009/06/16/whats-wrong-with-apple/comment-page-1/#comment-7594 William Woody Thu, 18 Jun 2009 16:58:44 +0000 http://www.jidesoft.com/blog/?p=73#comment-7594 Apple noted in the release of 10.5 (back in October of 2007) that <i>all references to apple.laf.* are deprecated.</i> (<a href="http://developer.apple.com/releasenotes/Java/JavaLeopardRN/ResolvedIssues/ResolvedIssues.html" rel="nofollow">Source, search for "4907470" which is the Radar bug referring to this change</a>) Thus, it was not (nor, to the best of my knowledge was ever considered) a public API. As they noted, if there is functionality that you are not able to achieve in Java using the standard Swing UI (along with <a href="http://developer.apple.com/documentation/Java/Reference/Java_PropertiesRef/Articles/JavaSystemProperties.html" rel="nofollow">some random property settings</a> sprinkled through the code), you should file a bug at http://bugreport.apple.com, or you can also join the Java-dev mailing list at http://lists.apple.com. Apple noted in the release of 10.5 (back in October of 2007) that all references to apple.laf.* are deprecated. (Source, search for “4907470″ which is the Radar bug referring to this change) Thus, it was not (nor, to the best of my knowledge was ever considered) a public API.

As they noted, if there is functionality that you are not able to achieve in Java using the standard Swing UI (along with some random property settings sprinkled through the code), you should file a bug at http://bugreport.apple.com, or you can also join the Java-dev mailing list at http://lists.apple.com.

]]> Comment on What’s wrong with Apple by Fabrizio Giudici http://www.jidesoft.com/blog/2009/06/16/whats-wrong-with-apple/comment-page-1/#comment-7573 Fabrizio Giudici Thu, 18 Jun 2009 07:21:24 +0000 http://www.jidesoft.com/blog/?p=73#comment-7573 I'm sort of mid way. Osvaldo and Romain are right, you should expect troubles when you depend on private stuff. OTOH I perfectly understand that people working on L&F can be forced with tweaking with internals. I know that I'm depending on a couple of internal APIs of the NetBeans Platform and I'm surprised that they are still working after two years and several major releases. I do expect sooner or later they will break. But there is a specific problem with Apple. Hell, if you get the update, you loose the previous runtime (in contrast with Windows and Linux, where several runtimes can co-exist). So, troubles do happen automatically and you must react by the hour. The second problem is that everything happens without any preliminary warning. I suppose that the apple.laf trouble experienced by JIDE was not visible in the early access Apple released some time ago. In my case, I know in advance what's happening to the various APIs of NetBeans since the work is done in the open, so I can prepare myself in time. I’m sort of mid way. Osvaldo and Romain are right, you should expect troubles when you depend on private stuff. OTOH I perfectly understand that people working on L&F can be forced with tweaking with internals. I know that I’m depending on a couple of internal APIs of the NetBeans Platform and I’m surprised that they are still working after two years and several major releases. I do expect sooner or later they will break.

But there is a specific problem with Apple. Hell, if you get the update, you loose the previous runtime (in contrast with Windows and Linux, where several runtimes can co-exist). So, troubles do happen automatically and you must react by the hour. The second problem is that everything happens without any preliminary warning. I suppose that the apple.laf trouble experienced by JIDE was not visible in the early access Apple released some time ago. In my case, I know in advance what’s happening to the various APIs of NetBeans since the work is done in the open, so I can prepare myself in time.

]]> Comment on Slides for JavaOne 2009 by David Qiao http://www.jidesoft.com/blog/2009/06/06/slides-for-javaone-2009/comment-page-1/#comment-7571 David Qiao Thu, 18 Jun 2009 06:24:35 +0000 http://www.jidesoft.com/blog/?p=71#comment-7571 The cell merging on the header is a different story as the header is not a JTable. We used a new header called NestedTableHeader to achieve the cell merge feature on the header. You are right. Each L&F needs to have its own subclasses which sucks. This is exactly why I mentioned in the slide that we have to face certain limitations in order to be compatible JTable etc. The cell merging on the header is a different story as the header is not a JTable. We used a new header called NestedTableHeader to achieve the cell merge feature on the header. You are right. Each L&F needs to have its own subclasses which sucks. This is exactly why I mentioned in the slide that we have to face certain limitations in order to be compatible JTable etc.

]]> Comment on What’s wrong with Apple by David Qiao http://www.jidesoft.com/blog/2009/06/16/whats-wrong-with-apple/comment-page-1/#comment-7569 David Qiao Thu, 18 Jun 2009 06:04:31 +0000 http://www.jidesoft.com/blog/?p=73#comment-7569 AquaLookAndFeel was under apple.laf too. I would consider AquaLookAndFeel being a public API, right? The problem is everything was under the same package. How people know which one is public and which is not (even with public qualifier). Sun JDK is better because they have separate packages. I guess my point was, even we are using non-public, non-documented API, it is not that we are not aware of what are using but because we had to. We either don't use them and leave out the features only Mac, or we use them to make our users happy but face potential future broken code. Of course we will choose the latter. It is the same deal supporting Sun JDK except Sun JDK is a lot opener than Mac's. Anyway, good news is that we had a urgent patch release yesterday with the help from JIDE users. JIDE seems running just fine on both old JDK and the new JDK. I am happy :-) AquaLookAndFeel was under apple.laf too. I would consider AquaLookAndFeel being a public API, right? The problem is everything was under the same package. How people know which one is public and which is not (even with public qualifier). Sun JDK is better because they have separate packages.

I guess my point was, even we are using non-public, non-documented API, it is not that we are not aware of what are using but because we had to. We either don’t use them and leave out the features only Mac, or we use them to make our users happy but face potential future broken code. Of course we will choose the latter. It is the same deal supporting Sun JDK except Sun JDK is a lot opener than Mac’s.

Anyway, good news is that we had a urgent patch release yesterday with the help from JIDE users. JIDE seems running just fine on both old JDK and the new JDK. I am happy :-)

]]>