Interesting, but all of your examples (here and on your sourceforge site) seem to emphasize the extraneous plot elements more than the data itself. The lines are thick, the grids and axes visually compete with the data being displayed. There is no subtlety and I while neat I can’t say that I found a single one of your examples beautiful. This is one of the things I dislike about Matlab as well, where it requires an enormous amount of work to create the simplest attractive (and effective) plot. The fact that defaults are so poorly chosen does not help. More fiddly options is not always the answer, however – the key is a designing in good defaults (and even removing some options) from the outset. It looks like you have some good engineering under the hood (love the SVG and processing.js capabilities), but what I’d really like to see is some work on the graphic design and visual display of information end of things. Cheers.

@Andrew – I think it would be constructive if you could let Malcolm know which defaults you think should be modified and how. Same with MathWork’s new HG2 (which has lots of new defaults).

When reflecting on Malcolm’s work, please remember that this entire set of library (a huge development effort) was created by a single individual, and posted as Open Source for the benefit of the community with nothing but good intentions at heart. So if you think that something should be changed, do chip in and help in a constructive manner. I suggest that you take this discussion offline directly with Malcolm (and for HG2 you can comment on the ^[20]).

@Andrew

The defaults are user-settable using the preferences dialog above for plots and axes. Colors, line thicknesses etc can all be set and saved for use across MATLAB sessions. All the setLeftAxisPainted(false) etc calls above could have been avoided if this were the defualt setting.

The settings are saved to XML in the $(java.home)/waterlooSettings folder and so kept across Waterloo updates too. That XML file can of course be shared across a team – so imposing a “corporate” theme. I would be happy to include a “theme” selector if users wanted to contribute their settings to the project.

One note of caution – the defaults table is referenced in the constructors and is a singleton instance. It is swapped during serialisation/deserialization of Waterloo files to allow the standard bean XML coder/decoder to be used. This results in graphs always using the defaults chosen by the user who created the file rather than the user opening it – The values can be edited – but the keys should not be, to ensure portability.

Eventually this may all be styled via CSS, but that is some way off.

You point is well taken and the beta version includes some preliminary work on colour schemes in the Colors class included in the kcl.waterloo.defaults package. There is a substantial literature on these issues notably in designing aircraft control GUIs (where the emphasis is on guiding the eye away from extraneous elements) and mapping (where the emphasis is on avoiding false impressions because of poorly chosen colours). Add to that the requirement to address the needs of those with colour-vision impairments and produce good output for both print and web media and you see that it is not a simple issue.

It occurs to me that some of ^[21]illustrations are useful here. The Lincoln Penny contours created a set of colors from the Colors class. These used the ^[22]color scheme. The color contrasts in the figures will be visible to those with all 3 common forms of colour-blindness. For those with full colour vision, you can check it out using the app from ^[23].

As per Yair’s comment above: general comments/suggestions about Waterloo are always welcome at
^[24]

Malcolm,
Congratulations for this very impressive library which looks very attractive…
Because you seem to be an EDT expert, I was wondering if you knew a way to synchronize graphics update of java components (integrated with javacomponent function) with drawnow mechanism ?
Because I am not sure to be clear, here is an example :

jLab = javaObjectEDT('javax.swing.JLabel');
for i=1:1000
    jLab.setText(num2str(i));
end

When we run this code, JLabel’s string is updated at each iteration. To have a similar behavior with uicontrol’s implementation, a drawnow has to be added in the loop.
So, do you know how, in the example above, we can prevent java component’s graphics from being updated at each iteration ?

@Julien – the easiest (and unsafe!) way is simply NOT to create the JLabel on the EDT in the first place, and only issue a drawnow and/or jLab.repaint when you really want to update the GUI:

jLab = javax.swing.JLabel;   % runs directly on MT, not EDT - careful!
for i=1:1000
    jLab.setText(num2str(i));
end
drawnow; pause(0.01); jLab.repaint;   % refresh the GUI

See ^[25] for more details on using Matlab with EDT

Thanks for your fast answer. I really carefully read all of your posts, especially those related to the integration of java components inside matlab figures. In particular, the EDT’s one is extremely usefull and interesting, but some points are still unclear to me.
In the code snippet above, I forgot one line which corresponds to the rendering of the component with javacomponent.

jLab   = javax.swing.JLabel;
[HJ,M] = javacomponent(jLab,[10 10 100 30],figure); % This puts JLabel on EDT
for i=1:20000
    jLab.setText(num2str(i));
end

Actually, as you mention in your post, javacomponent’s function puts component on the EDT, even if it was initially created on MT. That’s why with your example, unfortunately, it does not work better…

@Julien

There are two problems:

1. Updating the text property has to be done on the EDT to ensure that calls to getText on the EDT will see the changes. That is the point of a single-threaded model for AWT/Swing. For JLabel, this is not thread-safe (it is for Swing text components like JTextField).
The simplest way to avoid updating the text property 2000 times is not to write code that does that!
However, the overhead is simply setting the property is not enormous. The problem is that for a JLabel, the setText method calls repaint().
Here’s the code, which I have edited for clarity. Note that there is no check that we are on the EDT and no code to repost to the EDT (JLabel’s setText is not thread-safe). As you point out, MATLAB will ensure the code is called on the EDT when javacomponent has been used. Note that text is a bound property – if the property change listeners call repaint, mutiple repaint calls will be issued for each call to setText.

    public void setText(String text) {
        ......
        String oldValue = this.text;
        this.text = text;
        firePropertyChange("text", oldValue, text);
        ......
        if (text == null || oldValue == null || !text.equals(oldValue)) {
            revalidate();
            repaint();
        }
    }

2. The repaint will run on the EDT – whether or not javacomponent has been used – as repaint is a thread-safe method (N.B. for standard Swing components – always check when using custom subclasses).
Rendering the JLabel to screen is managed by the Swing repaint manager. That does not run on the EDT but analyses the repaint queue and collapses multiple calls to repaint the same screen area into a single call. When it is done, it calls the relevant Swing repaint methods which refresh the screen (on the EDT with the collapsed data). So despite the multiple calls to repaint, the repaint manager should reduce the work needed.

Flushing the event queue with pause or drawnow will disrupt that, forcing more repaints than needed – which I assume is why Yair put those outside the loop in the code above.

How you solve the problem depends on the use-case but a JLabel, or any other Swing component, will not always be the right tool for the job.

Thanks Malcolm for all these explanations which are very useful.
I chose this very simple example because I thought it reflected well my problem, which is actually different. A JLabel appears to be a bad candidate, your explanations are very clear on this. However, if I replace the JLabel by a JTextField or a JEditorPane for example, the behavior is unfortunately the same.

The problem which inspired my initial comment is actually le following :
I have a JTabbedPane with potentially more than 10 tabs, which can be added/removed interactively according to user’s needs. When I want to close several tabs at a time, I loop on tab indexes and invoke jTabbedPane.remove(tabIndex). However, with this MATLAB-side approach, I see the tabs which disappear one by one onscreen, and I want to avoid this. I would prefer to see all the tabs that disapper or appear at a time.

A solution could be to write a java util class with static methos that would be responsible for adding or removing several tabs (a simple loop). These methods would be invoked from MATLAB and executed on the EDT (using javaMethodEDT), in order to ensure that synchronous repaints will be done only after the method’s execution is completed (which is not the case when you do the equivalent loop MATLAB-side). I already tried this with JTable selections updates and it works well. However, in this specific case, I would like to avoid this (if you are interested, I could tell you more offline about this).

@Julien
Understood. jTabbedPane.remove(tabIndex) calls removeTabAt(tabIndex) and that calls repaint() which I suspect explains what you see. [JTable is rather different: probably the most complex of all swing components, and mixes data and visual elements in way that makes to impossible to comment on what you see without details.]

Google “grep JTabbedPane remove” to see the Java source code – Java is all open source.

A solution might be to subclass JTabbedPane and provide an additional method that allows removal of multiple tabs then calls repaint() only once. I do not see a way to do that MATLAB-side – neither could you rely simply on calling the JTabbedPane super class removeTab method in Java as that would still call repaint each time. It is not a huge task as the Oracle/Sun code shows most of what is needed to make it a Java subclass robust – so I suspect a professional programmer/consultant would quote a reasonable price if you are not happy doing it yourself (a man called Yair springs immediately to mind).

Thanks again Malcolm…
Actually, even if I am not a Java expert, I do not need help to subclass a swing component and override one method. I do not have much funds to this kind of consulting work, so I prefer to reserve Yair more tricky and exciting tasks!
To test your approach, I simply wanted to create a custom myJLabel class, which extends JLabel and overrides setText() method. In this method, I copied the setText() code from your link (thanks for the tip) and simply commented the repaint() line. However, because text property is private, I cannot modify it from the subclass without calling super.setText(), which calls repaint…
On the other hand, I have not tried yet, but it should work for JTabbedPane.removeTabAt(int) because no private properties are modified.

@Julien
One way for JLabel might be to create a myText property in your subclass. Compare the contents of that with the result returned by getText and override other methods (e.g. revalidate and paint) to call super.setText() as appropriate. Note though, there might be issues if the L&F UI delegate calls into superclass methods during construction (usually an issue with Synth-based L&Fs like Nimbus) and there could be synchronization issues. That may be why text is private to begin with.
Alternatively, copy the whole of JLabel. The GJGraph in Waterloo began as the JXGraph from the SwingX project (see the 1st blog about it). Rather than try overriding single methods I copied the whole class (it’s LPGL) and started from there, in part because I kept hitting issues with private fields.