What happened to the figure toolbar? Why is it an axes toolbar? How can I put the buttons back?

From R2018b onwards, tools such as the zoom, pan, datatip, etc are no longer at the toolbar at the top of the figure window. These buttons are now in an "axes" toolbar and only appear when you hover your mouse over the plot. How do I put the buttons back at the top of the figure window?

Answer 1

[MathWorks Support Team]

From the R2018b release onwards, you can drag-to-pan and scroll-to-zoom in an axes without having to call any MATLAB functions or select any toolbar buttons. Most types of axes include a default set of built-in interactions, but you can customize them by setting the Interactions property of the axes.  For more information about controlling chart interactivity, see the following link:

https://www.mathworks.com/help/matlab/creating_plots/control-axes-interactions.html

You can also return the tools to the figure toolbar using the "addToolbarExplorationButtons" function. Please refer to the following code for an example:

surf(peaks)\naddToolbarExplorationButtons(gcf) % Adds buttons to figure toolbar

You can also hide or remove the axes toolbar with the code below:

ax = gca;\n\nax.Toolbar.Visible = 'off'; % Turns off the axes toolbar\n%or\nax.Toolbar = []; % Removes axes toolbar data

If you would like to ensure that figures always open with the tools in the toolbar and that axes never contain a toolbar, execute the following code:

>>set(groot,'defaultFigureCreateFcn',@(fig,~)addToolbarExplorationButtons(fig))

Execute the below code if you are using R2018b or R2019a release:

>>set(groot,'defaultAxesCreateFcn',@(ax,~)set(ax.Toolbar,'Visible','off'))

Execute the below code if you are using R2019b and onwards release:

>>set(groot,'defaultAxesToolbarVisible','off')

The above settings will be reset when MATLAB re-starts.  To ensure that these settings are used even after MATLAB re-starts, place the above "set" commands in a 'startup.m' file. The 'startup.m' file, when placed on the MATLAB Path, is run during the program start-up process.  For more information about 'startup.m' files, see the following link:

https://www.mathworks.com/help/matlab/ref/startup.html

UPDATE (8/15/19):

Thank you for all of your comments and proposals about the axes toolbar.

We have heard your feedback and worked with members of the community on ways to improve the axes toolbar experience.  With R2019a we released several enhancements to the axes toolbar, including faster startup time, ability to hover directly over the toolbar to make it visible, and improved performance with dense surface data.  Additionally, with R2018b Update 5 we have made performance improvements to the axes toolbar startup time.  We will continue to develop enhancements to the axes toolbar experience, and would like to thank you again for your feedback to help us improve our products.

 

You can download the latest updates using the following link:https://www.mathworks.com/downloads/web_downloads/

 

[Amir Moghadam]

It is funny that the number of votes that the complaint answers have is much higher than the votes your answer has.

Hopefully that tells the design team something.

[Bruno Luong]

Strictly speaking, no. The property defaultFigureCreateFcns must contain zero/one callback function as with the case with all callbacks.

But you can put many commands in one function, depending on the commands you can do something like this for anonymous function (each command return one output)

set(groot,'defaultAxesCreateFcn',...
    @(ax,~) {set(ax.Toolbar,'Visible','off'), ...
             fprintf('annoying floating toolbar turn off\n')})

[Yair Altman]

Readers should note that the anonymous-function syntax

@(h,e) {command1, comand2, ...}

in its use for callback functions is undocumented (reference), although one could say that it's a logical extension of the ability to specify an anonymous function that returns a cell-array. It's an interesting use-case with multiple programmatic applications, so I think I'll blog about it. Thanks for the idea Bruno :-)

Caveat: this trick only works with commands that return an output value. The anonymous function tries to evaluate a cell array of values provided by the constituent commands, so if any command does not return a value the corresponding cell cannot be evaluated.

For example, the command disp('123') will cause a run-time error ("Too many output arguments") because it does not return an output value.

On the other hand, the command set(ax.Toolbar,'Visible','off') does work, because it returns an output value of [] (this is yet another undocumented feature - the 3-input set command is not documented to return anything). Similarly, fprintf(...) works because it returns a value (the number of characters that it outputted).

[Rik]

I though you were making a typo when you said it would return the error too many output arguments, so I made this MWE.

figure(1),clf(1)
CallbackFcn=@(h,e) {set(gcbo,'String',datestr(now)),disp('a')};
uicontrol(...
    'Units','Normalized',...
    'Position',[.1 .1 .8 .8],...
        'Callback',CallbackFcn)

And it actually does return the too many output arguments error. It does succesfully execute the first command of course. Also, this behaviour is not limited to callbacks, as running CallbackFcn() returns the same error.

Matlab can be weird sometimes...

[Bruno Luong]

Matlab can be weird sometimes...

Nothing is weird. The trick is tell MATLAB to regroup the outputs of commands in the cell so that MATLAB just executes them sequenctially. DISP does not return any output so it throw the error message "too many output arguments".

[Rik]

Now I get it, I was looking at it from the wrong way.

For people who made the same mistake: the error occurs because the syntax is essentially requesting a single output (even if it is only an empty []), so it is equivalent to this

arg_out=someFunction;
function someFunction
end

So the error occurs because too many outputs are requested, not because there are too many returned. (Now I come to think about it, that is not how Matlab works in the first place, so that wouldn't even have made sense.)

[Adam]

I've had

set(groot,'defaultFigureCreateFcn',@(fig,~)addToolbarExplorationButtons(fig))

in my startup file for many years, with no problems, but I recently upgraded to R2024a and now I get an error every time I start a uifigure (rather than a standard figure):

Error using matlab.ui.Figure/set
Functionality not supported with figures created with the uifigure function.

Error in addToolbarExplorationButtons

Error in normalized_mutual_information>@(fig,~)addToolbarExplorationButtons(fig)

Error using matlab.ui.internal.uifigureImpl (line 83)
Error while evaluating Figure CreateFcn.

Obviously I realise the toolbars are different for uifigures, but this code didn't used to complain when opening a uifigure, in previous versions. Is there any way I can set this for only regular figures so it doesn't keep erroring on uifigures?

[Adam]

For anyone else wondering this, I found a question on exactly this with an answer that works:

https://uk.mathworks.com/matlabcentral/answers/2075356-how-to-detect-whether-a-figure-is-created-by-uifigure#answer_1452421

Answer 2

[Yair Altman]

For the benefit of readers who don't follow my blog, Michelle Hirsch posted the following comment yesterday, which sheds some light on the subject:

Rest assured the team is digging in to the feedback to figure out the best approach to addressing concerns.

One thing puzzles me about the whole conversation (esp. on MTLAB Answers). Nobody is mentioning the default axes interactions, which we introduced along with the axes toolbar. We actually felt this was the biggest breakthrough, because you don’t need to interact with the toolbar at all in order to zoom, pan, rotate, or add datatips to a chart. Any thoughts on this? There’s a huge banner on the figure in 18b that introduces these new gestures so we thought people would find them.

I also can clarify a couple of things from your post:

* The Toolstrip was not driven by the marketing guys (and gals!). It was very much driven by our interest in improving discoverability of key capabilities which were too buried in menus and toolbars.

* The axes toolbar was not created primarily to support the move to web graphics. We intended it to be a solution to multiple problems:

** The toolbar for a figure docked in the desktop can be very far from the figure itself.

** We’d like to move towards being able to define interactions at the axes level, instead of the figure level, since interactions are axes specific. The axes toolbar is one step in that direction

[Thomas Hoffend]

It sounds like Mathworks is having a difficult time reaching and understanding its core, long-term customers. "Improving discoverability" says quite a bit. Features intended to enhance discoverability belong in well-written and cross-referenced help files, documentation, and learning materials and not in the API. I am all for additions and new features provided they enhance productivity and workflow. Anything that upsets workflow is a roadblock. Anything that has to be undone by adding lines of code to startup files, increases mouse clicks, requires looking for a feature that has moved, shifts icons, modifies the API in any significant way that can't be customized in or out, or adds to the time delay launching figures is a roadblock.

[Thomas Hoffend]

I think the cryptic reference suggests the release notes web page for Matlab 2018b, but I am not sure. Axis interactions are listed under the Graphics section:

https://www.mathworks.com/help/matlab/release-notes.html

[David Goodmanson]

Hello Yair,

Could you explain where the "huge banner on the figure in 18b is?" Is the banner perhaps something that appears the first time that Matlab is invoked after download, and then not again? Maybe no one is talking about the new features because they are effectively hidden.

At any rate, documentation by banner is not what most people would call good software practice.

And in this case the regular documentation of the phantom toolbar does not work either, for a different reason: it's inaccurate. If you go to "Interactively Explore Plotted Data" it says: "Some types of interactions are enabled by default, while other types of interactions are only available through the axes toolbar. The toolbar appears at the top-right corner of the axes when you hover over it."

This is not true. It only appears when you hover the cursor over the actual plot. Then, as i mentioned in a separate comment, if you take the cursor off the plot (still in the figure window but not on the toolbar) the toolbar disappears again, intentionally taking away any visual knowledge of whether any of the toolbar zoom states are active or not. That's poor.

[DGM]

The dynamic visibility (fading effect) isn't just annoying. I will always argue that invisible elements are fundamentally the most anti-intuitive thing you could possibly incorporate into a UI. Besides that, I find that it's occasionally extremely laggy or broken. I can't count the number of times I've tried to get the axes toolbar to pop up and gotten nothing but a massive spike in CPU usage for about 10s as nothing useful happens. I end up having to click on the unresponsive axes, inadvertently adding a datatip or creating an interminable zoom box that will permanently follow the cursor until I close the figure.

Then again, prior to these changes, view controls were cumbersome to the point of ridiculousness. At least in 2D, FEX akzoom() had that solved. Now it's a weird mess of implicit and explicit controls, invisible UI elements and lag.

Answer 3

[Bruno Luong]

Duplicate my poste here

For R2019b all the tricks found previously no longer work.

I found this one does the trick

set(groot,'defaultAxesCreateFcn', ...
@(ax,varargin) start(timer('StartDelay',1,'ExecutionMode','singleShot','TimerFcn',@(varargin) axtoolbar(ax,{}))));

You might put it in startup.m file

if ~verLessThan('MATLAB','9.7')
    set(groot,'defaultAxesCreateFcn', ...
        @(ax,varargin) start(timer('StartDelay',1,'ExecutionMode','singleShot','TimerFcn',@(varargin) axtoolbar(ax,{}))));
end