File Exchange Pick of the Week

Our best user submissions

GUI Layout (Part 6) 5

Posted by Jiro Doke,

Jiro's pick this week is UISplitPane by Yair.

This is another GUI-related pick, following from previous entries - Part 1, Part 2, Part 3, Part 4, Part 5.

Yair is a long-time contributor to the MATLAB community and has created numerous files that utilize MATLAB to its fullest extent. This entry, with some help from Java, brings you a very useful GUI capability: resizing of components within a figure. Now, you can interactively resize various components in your GUI, just like with MATLAB Desktop components. Here's an animated GIF included with his submission:

Note: As Yair clearly states in his submission, it uses some undocumented/unsupported MATLAB functionalities, so the behavior may change in the future.


Have you ever extended MATLAB's capabilities with other technologies? Tell us about it here.

Get the MATLAB code

Published with MATLAB® 7.8


Comments are closed.

5 CommentsOldest to Newest

Tim replied on : 1 of 5
I have been scared off using this and Yair's other excellent Java-based contributions by the ML warnings that generally pop up when I try to use them. I don't want to write an application that relies on this cool functionality only to find that it breaks with the next Matlab release. I might also add that while Java has obviously made ML easier to develop and maintain by Mathworks, from a user point of view (ie a non-Java programmer), I find it a collossal pain in the proverbial, in ML and elsewhere. From obscure and inscrutable ML graphics errors popping up when doing something that works fine on Mondays Wednesdays and Fridays after 3pm but falls over at other times or on other PCs, to clunky looking user interfaces, to sluggish performance. And then when some bright spark like Yair starts to exploit Java capabilities in ML, his users get hit with warnings that it may all fall over at some point in the future ! As this is an official ML blog, it would be nice to get the official word from development as to whether Java-based stuff will work in the future or not. If not, then we are better off not using it (or publicising it here). End of rant. PS Keep up the good work Yair. :-)
Yair Altman replied on : 2 of 5
First I'd like to thank Jiro for picking UISplitPane. Of all my file Exchange submissions, this has been the most challenging. Especially challenging, and this somewhat answers Tim's understandable concerns, was my attempt to make the code behave with graceful degradation if some unsupported features break. For example, UISplitPane even works (with some documented limitations) on Matlab 6, where Java GUI is not available, by using plain-ol' Matlab buttons instead of Java JSplitPane dividers. I encourage Tim and others to read the code of uisplitpane.m to understand the mechanisms I have used for graceful degradation and backward compatibility. Comments and feedbacks most welcome. Yair Altman
Scott Hirsch replied on : 3 of 5
Tim - Thanks for taking the time to share your perspectives on undocumented/unsupported functionality in MATLAB. We actually debated whether or not we should highlight Yair's submission for exactly the reasons that you mentioned - the risk to users that their code will break if they rely on unsupported functionality. Several of us are leaning towards erring on the side of providing more information, rather than less, to MATLAB users. Our thinking is that it is best to allow you to make as informed a decision as possible, trading off the risks (it will likely break, who knows when) with the reward (but it's so cool!!!!). If you are writing software in MATLAB that you expect to hang around for a while, you should be extremely careful about using unsupported functionality, but if you are just tinkering it might fit the bill perfectly. I really like that Yair consistently includes detailed warnings about his usage of unsupported functionality, so that his users can make similarly informed decisions. We are interested in doing a consistently better job of helping MATLAB users know if functionality they are using is supported or not. One of the most painful things (for me, at least) is to have your code break because of a change to an unsupported function that you didn't even know was unsupported. Tim also asked if Java-based stuff will work in the future. We are very committed to the integration of Java with MATLAB. Integration of Java in MATLAB figure windows is currently unsupported, but we are interested in providing fully documented and supported capabilities for this. When (or soon after) this happens, it is likely that code relying on the old functionality may start to break. I should be clear that this is still a very hot topic of debate at The MathWorks. I would love to hear your perspectives. - scott
wei replied on : 4 of 5
@Scott, Matlab should go further into open source for better functionality. Handle graphics was advanced and convenient a while ago. But now it starts showing its age, especially in the area of HMI. Users want and, more importantly, are used to better HMI experience. Open up to java, .net, and even flash. Make the interface open and fast. You will attract more developers. But sadly, and puzzling as well, I notice that JavaFrame is being deprecated recently. Why? What’s future for HG? Yes, there are those 'std' warnings. But what are the options? Developer has to satisfy his/her customers, in ever shorter time and with lesser cost.
Scott Hirsch replied on : 5 of 5
@Wei - Thanks for your input. We believe we can make our code much more robust if we provide fewer opportunities to sneak around through the back door as one can do with JavaFrame, which is why we are removing it. There's not much I can say about the future of HG, other than that we don't expect it to go away and we do expect it to get much better :). We are interested in providing the functionality users want directly, or at least documented ways to build the desired functionality. For instance - we are trying to learn why people use javaFrame (keep figure on top, ...) so we can evaluate adding those specific features directly into the figure window. As I mentioned above, we do want to provide supported capabilities for Java integration in MATLAB figures. We don't have any current plans to announce regarding .NET or Flash. -scott