New release talk

[spamatica]

I saw you asked about our status Tim.

Well... erratic at best ;)
I got lots of things I want to work on but nothing I can recall that holds up a release. Besides waiting for me is a fools game ;)

I'm all FOR making a release.
Can we do the necessary changes to make the Dark Flat theme the default in that case? I think that would be cool, unless you think it's too early for that?

[kybos]

I would suggest getting out a small maintenance release (3.1.1), as the Arch guy in the ticket suggested. And leaving the switch to the new theme for 3.2 (if you both agree with this switch). There are still some areas I wanted to improve/extend in the new theme, and we still have to clarify the Qt style issues (I would like to avoid seeing my theme broken by incompatible Qt styles ;-) ).
And I will be on vacation the following 2 weeks, so I will have "restricted availability" ;-).

[kybos]

BTW: Even if we set the new theme as the default for some future release, existing users won't notice - I guess we are not going to overwrite their settings (where their current theme is stored), are we?

[spamatica]

We will just do a maintenance release and push for all minor fixes then.

No we shouldn't force the theme. If people actually care about themes and colors, they will just be annoyed if their settings are overwritten.
We can of course push that this is the main look that will be best maintained and recommend that people move to it. We could make a pop up dialog the first time MusE is started after upgrading.

What about forceing the qt style? Should we remove or make it harder to change qt-style?

[kybos]

Agreed.

What about forcing the qt style? Should we remove or make it harder to change qt-style?

I would definitely force the Fusion style for the new theme to avoid unnecessary issues, like Breeze/Oxygen ignoring some stylesheet directives and causing misalignments.

I see 2 options:

1. Remove the Qt style selection completely and stick to Fusion (I would prefer this, for the sake of simplification and consistency/predictability).
2. Keep the Qt style selection, but switch to Fusion automatically when the new theme is switched to (but let the user change the Qt style explicitly afterwards if he really wants to...).

I remember you mentioned another option, also removing the Qt-styles from the UI but keep them in the config file and let the user edit it there if he is really adamant about it. Would be OK with me, but let the user edit the xml config file could be a little dangerous, easy to break, causing more issues...

[terminator356]

Remember, the mechanism to force existing settings to change
is always available. A bump-up of the song file version and comparison
of the user's version can do it. We routinely do it, because we must, when for example
toolbar Qt Settings change.

[kybos]

@spamatica
Maybe you could add updating the MusE wikipedia page to your release checklist ;-).
I updated it after the 3.1 release, the release and also the MusE web address were obsolete.

[spamatica]

Indeed, seems like a good idea :D In totally unrelated news (not news). Nobody noticed that lately we seem to have added ten year old fixes? That is, if you go by the changelog ;) Den tors 25 juni 2020 kl 19:56 skrev kybos <[email protected]>:

…

@spamatica <https://github.com/spamatica> Maybe you could add updating the MusE wikipedia page to your release checklist ;-). I updated it after the 3.1 release, the release and also the MusE web address were obsolete. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <https://github.com/orgs/muse-sequencer/teams/musedevteam/discussions/49/comments/6>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABCFANYMIMQX3HRA6Y7CVIDRYOFVXANCNFSM4OGAVF3Q> .

[kybos]

Right, and it seems to be me who started it.
Living in the past ;-) (Jethro Tull, wasn't it?).
I will correct it.

[terminator356]

Ha! I already fixed some before, now more? Tsk tsk ;-)

Finishing up my controller graph fixes... Hopefully this works, took a while...

[terminator356]

- Midi controller graphs: Fixed bug left over from 21.01.2019: Drag n drop broken.
  Items were wrongly being erased after dropping.

OK That was what I wanted to get in there.
Hopefully that will take care of it. Was tricky.

I'll take a peek at the compressed file problem and the wave editing problem.
I've known for a while there were some new issues editing the waves.

[terminator356]

- Compressed song files (.gz,.bz2): Fixed issue 831: Blank song on load. Error from 01.01.

My fault. Tests OK now, loading and saving.

[terminator356]

- Fixed issue 830: Wave Editor: Copy-on-write always triggered. Error from 01.01.2020

My fault again. Tests OK using the editor functions on writeable and non-writeable (C.O.W.) files.
Looking to be a good maintenance release. I botched a few things, eh?

Two more things:

1. When a live re-sampler or time-stretch is used on a wave,
   editing it causes the wrong section to change, ie. if project is at 44100 and wave is 22050,
   edited section will be twice as long and displaced at twice the position, of the actual selected
   visual portion. My fault again, could swear that worked ;-(

2. Using the 'functions' menu does nothing on compressed files like ogg.
   Not sure if this is possible, needs some checking (flac too?).
   But a warning should at least inform the user that some file cannot be edited, to avoid confusion.

Issues filed.