Style menu: remember last selected dialog?

I agree, although to me this was more of an issue in 2.x when the dialog was not "live". Now that you can see the effects of changes in real time, it's much less often I tend to go back to the same setting.

This would make it easier to access frequently used dialogs! but If ths was implemnted, then there are a lot simliar dialog windows, would they all be programmed to remember last status?

Which other dialogs also have multiple pages like Format / Style? I think that may actually be the only one.

Master Palette for example? and of its sub, the "Symbols"? and of its sub, the "Font"? and if "Style" and all dialog windows remember the last selection, then they are keeping consistency and good.

Other two settings of 3.0.5.5992 couldn't remember user selections are (I was thinking to file in separate reports):
The New "Pay Panel" docking/undocking status and "Mark Irregular Bars" ticking/unticking.

Oh, sure, there are lots of settings and feel free to file separate issues about those (search first to be sure there aren't any already), but this issue is about the specific issue of multipage dialogs remembering the last used page. And I do think this is literally the only one.

The View > Preferences dialog has multiple tabs, and Help > Resoure manager. Not pages , but tabs.

Some lose their status upon reopening ("Style" for example), some lose their status upon restart the app and opening ("Master Palettes" for ex), some do not lose even after restart app ("Synthesiser" for ex), confusing and hard to clear them out. It's good practise to keep them all in consistency.

For Edit / Preference,s it seems we do remember the current tab for the duration of the session, which is good. Not so for resource manage,r but probably less critical there.

I have a working fix for the style dialog, but I think it could be bettered. Currently, we create a new object each time we show the dialog. I added a static member to the class to cache the index of pageList before a hide event and then select the cached item from pageList on a show event. I would think it would be better to just hide, not destroy, the dialog on hide. Will try to get it to work.

I have a fix without creating a new object each time. Should I make a PR or should I see if the same method could work for other similar cases and make it all one PR?

See https://github.com/musescore/MuseScore/pull/5057

About the other dialogs: I propose to let all dialogs with tabs/pages just remember their state for a session. That makes most sense to me. What do you think?

I think windows should remember their state for the session.

@mike320 so you agree with me that the synthesizer shouldn't remember its state across sessions?

The synthesizer is unique in that the user expects it to always load the default soundfonts. There are even special buttons in it to tell it what you want it to load. I think it needs to be left alone.

Earlier today I was using the arrow buttons to rearrange my soundfonts. This is such a slow process, I closed and reopened MuseScore to reset the order to my normal list.

We should clarify what we mean by "state" here. The issue as stated has nothing to do with the content of the dialog - nothing to do with the settings you make within the dialog. The issue only has to do with it's appearance - which tab or page is active when you open the dialog. So for synth, that means, would it remember you last used the Zerberus tab, or effects, or would it always open on the Fluid tab. It has nothing to do with which soundfonts are loaded.

Both the mixer and synthesizer seem to remember their state the last time they were opened, so I don't think these are included.

The mixer even remembers its state when you switch scores, which is a bit odd. If you have several scores open some with lots of instruments, some with few you get some strange "memories" as you open adjust and close the mixer in various scores.

Two soundfonts dialogs lose their dimension/last selection, every time i have to drag it bigger and looking for the last one selected in the same session:

Mixer -> Patch remembers last instrument selection, this memory ONLY can be spelt out if it's tapped VERY QUICKLY, timing needs adj.

I almost need a brown paper bag: only the fact that @Anatoly-os didn't merge the PR yet saves me. I thought about this in way too simple terms. I completely forgot to think about what should happen when you switch scores. So now I am wondering: what should only be remembered if the score remains the same between two opens of the widget and what should remain the same regardless of whether it is the same score or not on which the dialog is invoked.

Fixed in branch master, commit b1e4a71a64

fix #283240 Let Style dlg state persist through open/close

Automatically closed -- issue fixed for 2 weeks with no activity.