fix #281616 : compile x86 Windows PortableApp at release time #5508

AntonioBL · 2019-12-02T13:36:07Z

Resolves: https://musescore.org/en/node/281616
These should be the modifications needed to have a portable Windows version automatically done (and uploaded) when the "x86" option is uncommented in .appveyor.yml, e.g. for a new stable release

I signed CLA
I made sure the code in the PR follows the coding rules
I made sure the code compiles on my machine
[?] I made sure there are no unnecessary changes in the code (Actually, I am not really sure the crlf attributes for those files are exactly needed, but the target is a Windows machine)
I made sure the title of the PR reflects the core meaning of the issue you are solving
I made sure the commit message(s) contain a description and answer the question "Why do those changes fix that particular issue?" or "Why are those changes really necessary as improvements?"
I made sure the commit message title starts with "fix #424242:" if there is a related issue
I created the test (mtest, vtest, script test) to verify the changes I made (not needed)

AntonioBL · 2019-12-02T13:37:15Z

.gitattributes

+build/PortableApps/**/*.ini eol=crlf
+build/PortableApps/**/*.txt eol=crlf
+build/PortableApps/**/*.ini.in eol=crlf
+build/PortableApps/**/*.html eol=crlf


I am not really sure these are needed, but the target is a Windows machine

AntonioBL · 2019-12-02T13:39:59Z

build/appveyor/before_build.bat

+IF "%BUILD_WIN_PORTABLE%" == "ON" (
+CD C:\MuseScore
+
+IF NOT EXIST portableappslauncher.zip (START " " /wait "C:\cygwin64\bin\wget.exe" --no-check-certificate "https://docs.google.com/uc?export=download&id=1hRaZTXY0ffm-TRLzu3a0_o77r3BEQcPf" -O portableappslauncher.zip )


Here the archive should be retrieved from MuseScore server, not my Gmail account.
It is simply a zip of the installation folder of PortableApps.com Launcher.

AntonioBL · 2019-12-02T13:40:35Z

build/appveyor/before_build.bat

+CD Launcher\App
+CD C:\MuseScore
+
+IF NOT EXIST portableappsinstaller.zip (START " " /wait "C:\cygwin64\bin\wget.exe" --no-check-certificate "https://docs.google.com/uc?export=download&id=1bWHoVig0EjZXQ5jJnUdnSDoEA_HyeDzH" -O portableappsinstaller.zip )


Same as above.
It is a zip of the installation folder of PortableApps.com Installer.

.appveyor.yml

AntonioBL · 2019-12-02T13:45:15Z

I inserted PortableApps.com "development build" splash screen:
build/PortableApps/App/AppInfo/Launcher/splash.jpg
If I understood correctly, we must have the permission from the people at portableapps.com to use the PortableApps.com logo in the splash screen, after their review of the package. But I fear that the review process has stalled ( https://portableapps.com/node/60879 ).
If no news come from their side, we could maybe create a custom splash screen for the portable version (without their logo).

Jojo-Schmitz · 2019-12-03T10:45:48Z

I wonder whether this could be done for the development builds too, and either replace the nightly stuff (which is 64bit only) or sit alongside to it (as a 32bit option)? It might lower the bar for users willing to test.

AntonioBL · 2019-12-04T08:39:45Z

In principle, both a 64bit and a 32bit portable could be done for the development builds. One main difference wrt to the current dev builds is the fact that I disabled the check for updates ( https://github.com/musescore/MuseScore/pull/5508/files#diff-3056168911c88e142262cb695efd9fdaR1843 ) since I couldn't manage to have it working properly.
Another important difference is that the portable version is, in principle, completely independent from the user preferences of other installations, so if a new portable development version is installed in a different folder, it will not read the preferences and personalizations of the old, already installed, portable development version. This could mask possible regressions that would appear only in the released not-portable package.

AntonioBL · 2019-12-04T08:44:44Z

On second thought, maybe it could be useful to have debug portable development versions we could point at to possibly have more information in some cases (e.g. users experiencing bugs difficult to be reproduced). They would take a lot of disk space on the server side, though.

riaanvn · 2019-12-29T06:05:37Z

@AntonioBL

Do you consider this PR ready to be merged? If so maybe ping @anatoly_os on Telegram. If it is too late or difficult to get done fo 3.4 then maybe 3.4.1 or 3.5.

Jojo-Schmitz · 2019-12-29T10:38:11Z

It needs a rebase first though

AntonioBL · 2019-12-29T15:04:49Z

Well, the rebase was not easy, I hope I did everything correctly 😅

I still have a couple of open points I'd like to have help on them before considering this PR completely ready to be merged:

I inserted PortableApps.com "development build" splash screen: build/PortableApps/App/AppInfo/Launcher/splash.jpg should we keep it or replace with a custom MuseScore Portable splashscreen? In that case I think we should also modify the "publisher line" https://github.com/musescore/MuseScore/pull/5508/files#diff-398e13e22c8d6a0674b9d1839625b771R8 since it would not be an "official" PortableApps.com application (by the way, is the affiliation correct, or should I use "Musescore BVBA"?)
the two GDrive links should be replaced with archives on official MuseScore servers; they are simply zipped folders of PortableApps Launcher Generator and Installer Generator
I am not sure about the need for crlf ending in those Windows-only files
I didn't check if the new telemetry option leaves some files behind in user or system folders; the main guide line for PortableApps is that the application should not leave files behind except in its own folder.

CMakeLists.txt

riaanvn · 2020-02-13T21:14:27Z

@Jojo-Schmitz are you happy with the state of this PR?
@anatoly_os can this be merged?

3.x has been without a portableapp (lower-case intentional) for almost 14 months. (No pressure meant, just somewhat of a sense of urgency)

Jojo-Schmitz · 2020-02-13T22:29:16Z

I for sure am happy with it

Jojo-Schmitz · 2020-04-20T10:04:53Z

Rebase needed. And it'd be great to have this as part of 3.5, finally

anatoly-os · 2020-04-28T12:27:32Z

@AntonioBL rebase is needed

AntonioBL · 2020-04-28T12:41:11Z

I am currently working on this.
I also would like to check if telemetry is storing data in temporary folders.

What about the points I was raising in #5508 (comment) ?

anatoly-os · 2020-04-29T12:14:33Z

@AntonioBL I need time to address the questions. Will postpone merging this PR to 3.5 Beta.

AntonioBL · 2020-04-29T12:23:53Z

Ok, fine. 👍
In the meantime, I am checking that everything still works fine after rebasing (see test #6013 )

AntonioBL · 2020-04-30T16:04:45Z

Rebased and updated.
I checked the most obvious sources of leftover files (QWebEngine, workspaces, plaettes) and it seems it is not leaving any of them in the system.
So the open points are:

should we use the PortableApps.com "development build" splash screen or replace with a custom MuseScore Portable splashscreen?
should we modify the "publisher line" Publisher=Werner Schweer and Others & PortableApps.com? (by the way, is the affiliation correct, or should I use "Musescore BVBA"?)
the two GDrive links should be replaced with archives on official MuseScore servers; they are simply zipped folders of PortableApps Launcher Generator and Installer Generator.
is crlf ending needed for those Windows-only files?
I still don't know how to check for leftover for the telemetry option

Jojo-Schmitz · 2020-05-01T12:36:54Z

should we use the PortableApps.com "development build" splash screen or replace with a custom MuseScore Portable splashscreen?

Why development build?

should we modify the "publisher line" Publisher=Werner Schweer and Others & PortableApps.com? (by the way, is the affiliation correct, or should I use "Musescore BVBA"?)

Yes, IMHO better use Musescore BVBA and Others, to be in line with the "Help > About" string.
Not sure about adding & PortableApps.com though.

I still don't know how to check for leftover for the telemetry option

Would you want to have telemetry disabled for the PortableApp, or just make sure it doesn't leave traces on the system? I don't think telemetry creates any files or registry entries on the machine.

AntonioBL · 2020-05-01T15:26:22Z

Why development build?

It is not a true development build, but it is the PortableApps.com splash screen used for builds not yet officially approved by PortableApps.com (and hence hosted on their site). I understood that one has to submit a tentative build to them with that splash screen (to differentiate from an "approved" build) and wait for their approval, but my tentative MuseScore 3.2.3 portable, after some comments from Bart.S, is sitting there in their development forum since August 2019.

should we modify the "publisher line" Publisher=Werner Schweer and Others & PortableApps.com? (by the way, is the affiliation correct, or should I use "Musescore BVBA"?)
Yes, IMHO better use Musescore BVBA and Others, to be in line with the "Help > About" string.
Not sure about adding & PortableApps.com though.

It is a quick change. "& PortableApps.com" was added to MuseScore2 portable, and I think it is relevant if the portable package is delivered by their site.

Would you want to have telemetry disabled for the PortableApp, or just make sure it doesn't leave traces on the system? I don't think telemetry creates any files or registry entries on the machine.

I'd like to make sure it does not leave file or registry leftovers on the system, but I don't know how to check if it is actually working. To check leftover files/registry keys I use Regshot (portable) in a clean virtual machine.
I already disabled the check for updates/autoupdate package. I wanted to disable as little as possible with respect to the offical non-portable package.

riaanvn · 2020-05-27T15:39:53Z

@anatoly_os is this still on course for 3.5 Beta?

anatoly-os · 2020-06-20T11:45:47Z

@AntonioBL I've replied to all your points mentioned above. Is there something I need to do to make it work? ( aside from merging this PR :) )

should we use the PortableApps.com "development build" splash screen or replace with a custom MuseScore Portable splashscreen?

I would use the actual splash screen and add the portableapps.com mention there if needed. As a raw text at the bottom left corner. Btw, current splash screen is generated on fly from svgs. We can use a .png specifically for portableapps, btw to simplify the process.

should we modify the "publisher line" Publisher=Werner Schweer and Others & PortableApps.com? (by the way, is the affiliation correct, or should I use "Musescore BVBA"?)

Yes, it should be "Musescore BVBA and others". "Others" includes portableapps.com.

the two GDrive links should be replaced with archives on official MuseScore servers; they are simply zipped folders of PortableApps Launcher Generator and Installer Generator.

I've put them to our S3 storage, so that you can update the links in the PR. The new links are:

is crlf ending needed for those Windows-only files?

Don't know. How can I help with that?

I still don't know how to check for leftover for the telemetry option

There are no files or data additionally stored on user's machine. Everything is processed on fly.

AntonioBL · 2020-06-22T07:56:44Z

@anatoly-os : thank you for the feedback.
I hope I will have some time this evening (or maybe tomorrow) to deal with the remaining points.
I will change the zip links and the affiliation, use the native splash screen (I will try to add a "portable version" text somewhere; I will post here the resulting image). I think the crlf should not give problems (those are actually Windows files).
And thank you for the info about the telemetry code.

In principle it should then be ready for merging. 🤞

AntonioBL · 2020-06-22T20:16:01Z

Ok. I think it is ready.
Here is how the splash screen appears for the portable version (and also development build, in this case):

The "Portable version (portableapps.com)" text is not translatable since strings are frozen at the moment.

anatoly-os · 2020-06-22T20:46:58Z

@AntonioBL Why do you use the development build splash screen?

Jojo-Schmitz · 2020-06-22T20:59:15Z

Because that is the one that shows on a self build?

AntonioBL · 2020-06-22T21:03:15Z

Indeed, it is the one created when locally building 3.x branch.
I added the "Portable version (portableapps.com)" text to every kind of portable build (so in principle development build portable, or 64bit portable).

Jojo-Schmitz · 2020-06-23T07:55:42Z

mscore/mssplashscreen.cpp

+#if defined(WIN_PORTABLE)
+      // Additional text for Windows Portable version.
+      painter->setPen(textColor);
+      painter->drawText(_miscTextRect, Qt::AlignLeft | Qt::AlignBottom, "Portable version (portableapps.com)");


Even with translations currently frozen that text should at least be translatable, shouldn't it?
tr("Portable version (portableapps.com)")

Please, address it in a separate PR

follow up for musescore#5508

AntonioBL commented Dec 2, 2019

View reviewed changes

Jojo-Schmitz reviewed Dec 2, 2019

View reviewed changes

.appveyor.yml Show resolved Hide resolved

AntonioBL force-pushed the winportable branch from 008ebab to 787f826 Compare December 29, 2019 14:52

riaanvn reviewed Jan 27, 2020

View reviewed changes

CMakeLists.txt Outdated Show resolved Hide resolved

AntonioBL force-pushed the winportable branch from 787f826 to f59c3d7 Compare January 31, 2020 19:23

dmitrio95 requested a review from anatoly-os March 20, 2020 13:19

Jojo-Schmitz mentioned this pull request Apr 20, 2020

MuseScore 3.5 Alpha PRs to be merged #5960

Closed

AntonioBL mentioned this pull request Apr 29, 2020

[WIP] Winportabletest + collect_artifacts #6013

Closed

anatoly-os added this to the MuseScore 3.5 Beta milestone Apr 29, 2020

AntonioBL force-pushed the winportable branch from f59c3d7 to a3797d7 Compare April 30, 2020 15:55

AntonioBL force-pushed the winportable branch from a3797d7 to e7f890c Compare April 30, 2020 16:11

anatoly-os mentioned this pull request May 3, 2020

MuseScore 3.5 Beta. PRs to be merged #6027

Closed

12 tasks

AntonioBL force-pushed the winportable branch from e7f890c to e534d33 Compare May 6, 2020 19:23

AntonioBL changed the base branch from master to 3.x May 6, 2020 19:24

anatoly-os mentioned this pull request Jun 10, 2020

MuseScore 3.5 Release Candidate. PRs to be merged #6195

Closed

1 task

fix #281616 : compile for PortableApps.com

23382cc

AntonioBL force-pushed the winportable branch from e534d33 to 23382cc Compare June 22, 2020 20:06

anatoly-os modified the milestones: MuseScore 3.5 Beta, MuseScore 3.5 RC Jun 22, 2020

Jojo-Schmitz reviewed Jun 23, 2020

View reviewed changes

anatoly-os merged commit 199555f into musescore:3.x Jun 23, 2020

Jojo-Schmitz added a commit to Jojo-Schmitz/MuseScore that referenced this pull request Jun 23, 2020

add missing translatability

a2bc18f

follow up for musescore#5508

Jojo-Schmitz mentioned this pull request Jun 23, 2020

add missing translatability #6252

Merged

Jojo-Schmitz mentioned this pull request Jul 10, 2020

[MU4 Issue] PRs from 3.x to be merged into / ported to master #6079

Closed

29 tasks

igorkorsukov mentioned this pull request Oct 14, 2020

[MU4] Porting win portable build from 3x to master #6672

Merged

AntonioBL deleted the winportable branch October 26, 2020 11:06

Uh oh!

fix #281616 : compile x86 Windows PortableApp at release time #5508

fix #281616 : compile x86 Windows PortableApp at release time #5508

Uh oh!

Conversation

AntonioBL commented Dec 2, 2019

Uh oh!

AntonioBL Dec 2, 2019

Choose a reason for hiding this comment

Uh oh!

AntonioBL Dec 2, 2019

Choose a reason for hiding this comment

Uh oh!

AntonioBL Dec 2, 2019

Choose a reason for hiding this comment

Uh oh!

Uh oh!

AntonioBL commented Dec 2, 2019

Uh oh!

Jojo-Schmitz commented Dec 3, 2019

Uh oh!

AntonioBL commented Dec 4, 2019

Uh oh!

AntonioBL commented Dec 4, 2019

Uh oh!

riaanvn commented Dec 29, 2019

Uh oh!

Jojo-Schmitz commented Dec 29, 2019

Uh oh!

AntonioBL commented Dec 29, 2019

Uh oh!

Uh oh!

riaanvn commented Feb 13, 2020

Uh oh!

Jojo-Schmitz commented Feb 13, 2020

Uh oh!

Jojo-Schmitz commented Apr 20, 2020

Uh oh!

anatoly-os commented Apr 28, 2020

Uh oh!

AntonioBL commented Apr 28, 2020

Uh oh!

anatoly-os commented Apr 29, 2020

Uh oh!

AntonioBL commented Apr 29, 2020

Uh oh!

AntonioBL commented Apr 30, 2020

Uh oh!

Jojo-Schmitz commented May 1, 2020 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

AntonioBL commented May 1, 2020 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

riaanvn commented May 27, 2020

Uh oh!

anatoly-os commented Jun 20, 2020

Uh oh!

AntonioBL commented Jun 22, 2020

Uh oh!

AntonioBL commented Jun 22, 2020

Uh oh!

anatoly-os commented Jun 22, 2020 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Jojo-Schmitz commented Jun 22, 2020

Uh oh!

AntonioBL commented Jun 22, 2020 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Jojo-Schmitz Jun 23, 2020 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

anatoly-os Jun 23, 2020

Choose a reason for hiding this comment

Uh oh!

Jojo-Schmitz Jun 23, 2020

Choose a reason for hiding this comment

Uh oh!

Jojo-Schmitz commented May 1, 2020 •

edited

Loading

AntonioBL commented May 1, 2020 •

edited

Loading

anatoly-os commented Jun 22, 2020 •

edited

Loading

AntonioBL commented Jun 22, 2020 •

edited

Loading

Jojo-Schmitz Jun 23, 2020 •

edited

Loading