Details pane missing in 2025a

I have just installed 2025a and the details pane in the main command window is missing. I can't find the setting to restore it. It's reall y useful to load single variables from mat files and add other variables so I really miss it! Attached image shows it in 2024b

Answer 1

[Matt J]

Yes, it's been removed. You can still preview the file by right-clicking on it and selecting Preview. I would be interested to know what happens for you when you try to drag a variable from there into the Command Window. For me, the Command Window freezes up entirely.

[Philip Masding]

HI Matt, thank you for your answer. I can successfully drag variables from the preview to the command window. I tried several different .mat files and there were no problems. I can also drag a variable from the workspace pane to a file in the files pane. So I have all the functionality as in earlier versions

[Matt J]

If so, I guess your issue is resolved, right? If that's the case, please Accept-click the answer.

[Philip Masding]

Details pane was much better then the preview method.

[dpb]

In what way(s)?

[Matt J]

In what way(s)?

For one thing, it took fewer mouse clicks to get to the information. For another, the previewer takes several seconds to load (or so I find), even on small .mat files containing only a few scalar variables.

[Philip Masding]

I am saying the old method (details pane) is better than the previewer. Your comment seems to agree with that so I think we are in agreement?

[Matt J]

@Philip Masding Whose comment are you referring to, mine or @dpb's? Yes, I agree the details pane was better.

[dpb]

As I've commented before, "new and improved" isn't always better, sometimes just different or even not as good as the former. It appears Mathworks has fallen into trying to reinvent the wheel on the UI. I've never found any real use for any almost of the stuff that has been added since R7; other than the command window, history and editor, don't much see the need to clutter things up and add the bloat.

But, to each his own; although one wonders why review teams don't bring up these issues before things are revised/removed, though. I would raise the issue of missing features that did find useful as quality of implementation bugs although it's not likely to change corporate direction which, I think, is getting off track.

My comment was intended to focus on specifics missing in order to support the reasons for restoring prior functionality.

[Steven Lord]

It appears Mathworks has fallen into trying to reinvent the wheel on the UI. I've never found any real use for any almost of the stuff that has been added since R7

I've highlighted a key word in your comment. Not every feature needs to be useful for every user in order for MathWorks to implement it; indeed, I'm pretty sure that would be an impossible requirement! [Even performance improvements, which you think might please everyone, can annoy users if they change the answers slightly causing "ripple effects" in code that uses it.

And no, this is not a hypothetical concern. I've seen technical support cases where users complained about a bug changing the answers of their code when a new release comes out, and the root cause being a change to make a function faster causing a unit-in-the-last-place change in the answer returned by that function. The answer was still correct (indeed, it could be considered more accurate than the previous answer in some cases) but because it was different that user had to contact Support.]

But, to each his own; although one wonders why review teams don't bring up these issues before things are revised/removed, though. I would raise the issue of missing features that did find useful as quality of implementation bugs although it's not likely to change corporate direction which, I think, is getting off track.

What makes you think review teams don't bring up these issues? As someone who is on a design review team (though not one of the ones that reviewed this particular change) we do think a LOT about compatibility and workflows when reviewing proposals for new features in MATLAB. But compatibility is just one aspect of the design that we need to consider.

It's a trade-off -- suppose as a hypothetical example that in order to keep the details pane around, we would have had to delay dark mode (a feature that a ton of users have been clamoring for, in some cases for years) by six months to make the code changes needed to make the details pane compatible with dark mode. Would that have been preferable?

One thing I would suggest is that you try out the Prerelease that we offer before the general release ships to users. If you see something that's a show-stopper for your workflow, if you share that feedback on the Prerelease there's time (not much of it, but a little) for us to action it. Again, I'm not guaranteeing that if you had written in saying "Why the bleep did you remove the details pane? Bring it back!" we would have actioned that feedback. But we might have.

[dpb]

I understand there are trade-offs; from my viewpoint it seems the rush to release two updates a year has taken precedence over when new features are really ready to be released to the production code base.

Personally, I'd prefer later release of the feature with enough time with the prerelease for there to actually be a meaningful time frame available for user testing and feedback that TMW could realistically make such changes. The competitive environment with the plethora of alternatives currently available may not be amenable to such a cycle, however.

I grok the perfomrance example; that's why in my former life with a commercial reactor vendor MATLAB was never an allowable toolset; the reverification exercise that would be required to continue to with supported versions would have been far more effort than the benefits of having the development platform instead of the traditional compile/link/submit step of compiler toolsets with official Standard conformance. The pace of improvements was a snail or nonexistent but the NRC compliance and licensing comparisons to allow a change in toolsets was a many months/years effort (although we at least had sufficient "smarts" built into the comparisons to define a meaningfully different result magnitude, not strict equality to the last decimal digit). The move of production code from one vendor/compiler toolset to another took roughly two years prior preparation in recoding and conversion and then about another eighteen months verfication after the new platform was onsite before were able to actually "pull the plug" on the former platform and use only the new one with NRC concurrence.

It also is probably not practical to release performance improvements without all the graphical/UI stuff, too, although that would be the overall direction that would fit my working style most appropriately, not really giving a hoot about the fancy UI stuff.