|
VVV_Easy_Symenu Posts: 159
06/04/2018
|
Hello,
the SyMenu family is getting bigger, however I believe that people are still afraid to become the SPS Publisher App.
My experience is that with SyMenu the vast majority of free applications are easily portable but the first time that you program SPS Builder is a little bit hard (even with the great help of Gian)
So I would like to make available to everyone what I am learning and, perhaps, some code snippets may be useful for someone.
I choose the principal SPS App lesson but I don’t include the code because is easily accessible with the SPS Publised Track App of SyMenu suite (ReBuild with empty publisher and right click for open it with SPSBuilder) and always in the last functional version.
Do not hesitate to ask about any questions or add your own improvements or snippets.
(PS for Gian: Perhaps could be useful Pin Up this Topic in the forum to make it easy to find. ¿May be better under "Technical discussion"?)
Avidemux (x64):
Scrip After Install = Clean installation files like $PLUGINSDIR folder, uninstall.exe.
ImgBurn:
In this case, with the code snippet comes a good habit: Before creating the SPS App consult its portability in "The Portable Freeware Collection". And also another advice, if there are doubts about which application to use search in "AlternativeTo" in order to check if there are other FOSS (Free and Open Source Software) options.
Scrip After Install = Creation of ini text file for make the app portable (see SPS Builder and "ImageBurn in PortableFreeware")
MiniTool Partition Wizard Free >>> Discontinued and discouraged: difficult to maintain the division of versions
Scrip After Install = From a InnoSetup installation package with double versions (x86 and x64) create double SPS App versions creating the folder tree and renaming de *1, *,2 files.
ExifToolGUI:
Scrip After Install = This is a SPS App “ExifTool” dependent (at least when runs the first time) so it make a launcher batch for:
1) copy the needed files from the parent SPS App.
2) verify if the parent app has been updated (then update the needed files) but always runs the app.
SciTE4AutoHotkey:
Scrip After Install = This is a SPS App “AutoHotkey Compiler” dependent (at least when runs the first time) so it make a launcher batch for:
1) copy the needed files from the parent SPS App.
2) verify if the parent app has been updated (then update the needed files) but always runs the app.
DSynchronize:
Scrip After Install = Make a launcher batch for:
1) If the language is not set and internet is enable, ask for the user language and download the language pack. Always runs the app.
TCX Converter:
Scrip Before Install = Process (unzip) a downloaded package before passing it to the InnoSetup unpacker.
Scrip After Install = Make a launcher batch for:
1) Create the folder “%APPDATA%\TCXConverter” with the default database settings (it must unzip the file)
2) If internet is enable, download the language pack update but always runs the app.
TrIDNet:
In addition to the snippet, this entry is interesting for the SPS Builder approach. TrDNet is designed to identify file types from their binary signatures. The app is very stable (last update in 2016) but the file definitions is frequently updated. In addition, the download file of the app is zip and the definition file are 7z (no PowerShell command for 7z files although SyMenu has 7z.exe). Finally, the program doesn’t have built system for download (neither update) the definition file, this must be done manually by the user.
In this case, SPS Builder download and install the definition file (in this manner the publisher can use the SyMenu update tracing alert both for the definition file and for the app) and in the first time (the app doesn’t exist), the launcher downloads and decompress the app.
Scrip After Install = Make a launcher batch for:
1) If the executable file of the app doesn’t exist and internet is enable, it downloads and decompresses the app. If no executable and no internet it alerts to the user “Internet needed in the first run for complete the app” and exits. If the executable file exists (downloaded in this time or before) it runs the app.
Attribute changer X64:
Attribute Changer is implemented as a shell extension: You need to right-click on files, folders or drives and choose the “Change attributes…” explorer context menu item.
To make it portable you need register the program as COM In-Process for use it.
Scrip After Install = Sort the different files. Make two batch for:
· Activate_Attribute_Changer_x64.bat:
1. If the language is not set, ask for the user language and set it.
2. If not running in elevate mode, prompt for running administrator privileges.
3. In Elevate mode, Register the program dll as COM In-Process for use it in the explorer context menu.
· Disable_Attribute_Changer_x64.bat
1. Delete the software registry key (for edit the right user HKCU registry key you must be in the session of the normal Attribute Changer user, elevate is NOT needed)
2. If not running in elevate mode, prompt for running administrator privileges.
3. In Elevate mode, UnRegister the COM In-Process server.
MuseScore X64:
MuseScore is the typical FOSS application developed with QT5 that it is practically portable itself but not stealth by the folders it uses to save the configurations:
%APPDATA%\MuseScore, %LOCALAPPDATA%\MuseScore,
%USERPROFILE%\Documents\MuseScore and %USERPROFILE%\Desktop (is used as default in Open Folder Dialog)
The solution is to use the change of system variables that SyMenu has, reconfiguring USERPROFILE operating system variable. This is this is done in the section Scrip After Install:
MakeDir ".\USERPROFILE_PORTABLE"
MakeDir ".\USERPROFILE_PORTABLE\AppData"
MakeDir ".\USERPROFILE_PORTABLE\AppData\Local"
MakeDir ".\USERPROFILE_PORTABLE\AppData\Roaming"
MakeDir ".\USERPROFILE_PORTABLE\Documents"
MakeDir ".\USERPROFILE_PORTABLE\Desktop"
AddVar USERPROFILE=..\..\USERPROFILE_PORTABLE
DelFile *.msi
Some remarks:
1. In the 'MakeDir' stataments we use ".\USERPROFILE_PORTABLE" because the statement is going to be executed by installer and the reference is the install folder, MuseScore_ (x64) _sps\.
2. In the 'AddVar' stataments we use "..\..\USERPROFILE_PORTABLE" because the statement is going to be executed in every each application launch so the the reference is the folder of the Main Exe File, in this case MuseScore_ (x64) _sps\MuseScore 3\bin\ MuseScore3.exe
3. Normally it's not necessary to create all the folders because the program does it by itself but it helps to understand the user the clarification of the following point.
4. In the Not Sealth section is included one useful information for the user:
"You can move an installed configuration from %APPDATA%\MuseScore, %LOCALAPPDATA%\MuseScore and %USERPROFILE%\Documents\MuseScore to the equivalent in the SPS App MuseScore folder "USERPROFILE_PORTABLE"
KeyCastOW:
Now the build is dowloaded from well know Chocolatey.org.
"Chocolatey is a software management solution unlike anything else you've ever experienced on Windows. Chocolatey brings the concepts of true package management to allow you to version things, manage dependencies and installation order, better inventory management, and other features."
The "nupkg" package is a zip archive and, in this case, you can get easily the original program.
.
edited by VVV_Easy_Symenu on 31/05/2020
|
|
|
+1
link
|
|
Gianluca Administrator Posts: 1274
09/04/2018
|
Thank you very much for your effort to document the best techniques you implemented in the SPS.
I would like to implement a wiki for this, also because all the SPS topic, lacks a real guide, but, at the moment, it's a too time-consuming task for me.
Anyway I agree with your idea to pin this thread and I hope other editors could publish some other trick here.
Thank you again for you devotion to this project!!!
|
|
|
link
|
|
VVV_Easy_Symenu Posts: 159
22/04/2018
|
Update with
ImgBurn:
In this case, with the code snippet comes a good habit: Before creating the SPS App consult its portability in "The Portable Freeware Collection". And also another advice, if there are doubts about which application to use search in "AlternativeTo" in order to check if there are other FOSS (Free and Open Source Software) options.
Scrip After Install = Creation of ini text file for make the app portable (see SPS Builder and "ImageBurn in PortableFreeware")
|
|
|
link
|
|
VVV_Easy_Symenu Posts: 159
03/08/2018
|
Updated with
TrIDNet:
In addition to the snippet, this entry is interesting for the SPS Builder approach. TrDNet is designed to identify file types from their binary signatures. The app is very stable (last update in 2016) but the file definitions is frequently updated. In addition, the download file of the app is zip and the definition file are 7z (no PowerShell command for 7z files although SyMenu has 7z.exe). Finally, the program doesn’t have built system for download (neither update) the definition file, this must be done manually by the user.
In this case, SPS Builder download and install the definition file (in this manner the publisher can use the SyMenu update tracing alert both for the definition file and for the app) and in the first time (the app doesn’t exist), the launcher downloads and decompress the app.
Scrip After Install = Make a launcher batch for:
1) If the executable file of the app doesn’t exist and internet is enable, it downloads and decompresses the app. If no executable and no internet it alerts to the user “Internet needed in the first run for complete the app” and exits. If the executable file exists (downloaded in this time or before) it runs the app.
|
|
|
link
|
|
VVV_Easy_Symenu Posts: 159
10/05/2020
|
Updated with
MuseScore X64:
MuseScore is the typical FOSS application developed with QT5 that it is practically portable in itself but not stealth by the folders it uses to save the configurations:
%APPDATA%\MuseScore, %LOCALAPPDATA%\MuseScore,
%USERPROFILE%\Documents\MuseScore and %USERPROFILE%\Desktop (is used as default in Open Foldeer Dialog)
the solution is to use the change of system variables that SyMenu has, reconfiguring USERPROFILE operating system variable. This is this is done in the section Scrip After Install:
MakeDir ".\USERPROFILE_PORTABLE"
MakeDir ".\USERPROFILE_PORTABLE\AppData"
MakeDir ".\USERPROFILE_PORTABLE\AppData\Local"
MakeDir ".\USERPROFILE_PORTABLE\AppData\Roaming"
MakeDir ".\USERPROFILE_PORTABLE\Documents"
MakeDir ".\USERPROFILE_PORTABLE\Desktop"
AddVar USERPROFILE=..\..\USERPROFILE_PORTABLE
DelFile *.msi
Some remarks:
1. In the 'MakeDir' stataments we use ".\USERPROFILE_PORTABLE" because the statement is going to be executed by installer and the reference is the install folder, MuseScore_ (x64) _sps\.
2. In the 'AddVar' stataments we use "..\..\USERPROFILE_PORTABLE" because the statement is going to be executed in every each application launch so the the reference is the folder of the Main Exe File, in this case MuseScore_ (x64) _sps\MuseScore 3\bin\ MuseScore3.exe
3. Normally it's not necessary to create all the folders because the program does it by itself but it helps to understand the user the clarification of the following point.
4. In the Not Sealth section is included one useful information for the user:
"You can move an installed configuration from %APPDATA%\MuseScore, %LOCALAPPDATA%\MuseScore and %USERPROFILE%\Documents\MuseScore to the equivalent in the SPS App MuseScore folder "USERPROFILE_PORTABLE"
|
|
|
link
|
|
VVV_Easy_Symenu Posts: 159
31/05/2020
|
Updated with
KeyCastOW:
Now the build is dowloaded from well know Chocolatey.org.
"Chocolatey is a software management solution unlike anything else you've ever experienced on Windows. Chocolatey brings the concepts of true package management to allow you to version things, manage dependencies and installation order, better inventory management, and other features."
The "nupkg" package is a zip archive and, in this case, you can get easily the original program.
|
|
|
link
|
|
Gianluca Administrator Posts: 1274
05/01/2021
|
Electron apps
Electron is a framework that allows the creation of applications, Windows desktop ones but not only, with web technologies such as JavaScript, HTML, and CSS.
Every Electron app packed to be a Windows desktop application, uses the AppData\Roaming folder to store the user customization and files. We don't like this behavior very much because this way the application settings become not portable.
The solution is pretty easy.
With the SPS script after install you can instruct SyMenu to build a proper folder inside the application root and to force the Electron app to use that folder as a replacement of AppData\Roaming.
Example:
MakeDir .\USERPROFILE\AppData\Roaming
AddVar USERPROFILE=.\USERPROFILE
Certain Electron apps are less greedy and only need to know where AppData folder is. If the others folders lack, they'll be created on the fly.
For example Visual Studio Code only needs this script after install:
AddVar APPDATA=.\
With this instruction only VS Code is able to create the needed folder (namely Code) into the root. Inside the Code folder it stores all its user files.
In general the Electron apps outputs are really easy to redirect.
|
|
|
link
|