|
jimlad68 Posts: 13
30/12/2018
|
I have noticed this with more than one Symenu program. This example is for HandBrake (Q-Dir is also a problem).
If I PIN it to the Windows Taskbar OR create a shortcut, the settings end up being saved at:
C:\Users\jim\AppData\Roaming\HandBrake\settings.json
If I call the program from SyMenu it saves the settings at:
E:\.....\SyMenu\ProgramFiles\SPSSuite\SyMenuSuite\HandBrake_(x64)_sps\User\AppData\Roaming\HandBrake\settings.json
Is there a way to always save the settings in the same place, ideally within the SyMenuSuite.
edited by jimlad68 on 30/12/2018
|
|
|
link
|
|
Gianluca Administrator Posts: 1274
30/12/2018
|
Absolutely not.
HandBrake is a program that works in the right way (right way from a Windows point of view) because it asks the system where the Roaming folder is through the right environment variable query.
When a program is so good, we can use the SyMenu power to rewrite those environment variable just before the program execution. In this way the program thinks that the Roaming folder is placed elsewhere and writes its setting there.
The trick is feasible with almost all the system environment variables.
HandBrake wants to write in the Roaming folder but other programs could write in the Temp folder or Local folder or ProgramData folder... The variability is extraordinary you can not even image that.
But, a lot of programs act in the wrong way, and find their data folders in other ways so the environment variable rewrite become useless.
If you want you can experience by yourself the effects of the environment variable rewrite. Start with HandBrake (go to the configuration form, select HandBrake, select advanced tab) to understand how SyMenu redefines the Environment variables. Then if you find some other rewrite trick for some other program, please let's us know! ;-)
|
|
|
link
|
|
jimlad68 Posts: 13
30/12/2018
|
Many thanks for that explanation.
In this case, the only variable that seams to be written to the Windows drive is
C:\Users\jim\AppData\Roaming\HandBrake.
However:
I put this in a batch file:
E:\zPortAps\SyMenu\SyMenu.exe -runb7fc73be-f485-4505-807e-914c3102d731
(having eventually found the GUID from E:\zPortAps\SyMenu\Config\SyMenuItem.zip\)
Which ran OK, but the settings and presets still ended up on C:\Users\jim\AppData\Roaming\HandBrake\
I suppose the simple answer is to always use one or the other. But that partially defeats the purpose of portability! (I also use portable programs to have a smaller OS drive image)
The other advantage of calling from outside of SyMenu is the option to use the "SendTo" in File Explorer.
For the future:
1. Would it be possible to create shortcuts to SyMenu items that go "via" SyMenu, hence picking up the environment variables changed by SyMenu?
2. I use taskbar shortcuts (or PINs) for regular programs because, as wonderful as SyMenu is, I find the program selection via SyMenu panels a bit clunky (especially the bit where if your cursor moves from the panel the search menu is gone!). Also when trying to run "minimally" there is no need to have SyMenu running all the time. It would be nice to have a "search items" more like liberkey where the "search items" does not disappear and search results stay for later selection.
Thanks again
|
|
|
link
|
|
Gianluca Administrator Posts: 1274
31/12/2018
|
1) Yes sure, they already exists and you don't need to create a batch file for this purpose.
SyMenu is able to create a so called Desktop shortcut for every configured item (see https://www.ugmfree.it/SyMenuManual.aspx#DesktopShortcut).
It's true, this kind of shortcuts are temporary by design but you can force them to become permanent with an easy workaround. SyMenu recognize its own temporary shortcuts because all of them have a comment equal to the SyMenu GUID. In this way you can have more than one SyMenu version running at the same time and every version is able to recognize its own shortcuts. If you want to convert a temporary shortcut in a permanent one, please remove that value from the comment. To access the comment ask for the shortcut properties - shortcut tab.
2) A stable search items is quite impossible to get for SyMenu because of its design. The only stable window in SyMenu is the Separate launcher (not search then). You can find info about it here: https://www.ugmfree.it/SyMenuManual.aspx#SyContainerSeparateLauncher
But you can test one alternative way of working.
Why don't you use the search shortcut? Since the search is effective only if you type on the keyboard, prepending a customizable shortcut to make the search directly appear won't be too annoying.
|
|
|
link
|
|
jimlad68 Posts: 13
31/12/2018
|
As expected; I did notice that if Handbrake advanced parameters was unticked it saved to the Windows C: drive.
I am not sure if there would be any other downsides to leaving it unticked??;
otherwise this would allow continuity between the SyMenu call and a shortcut or explorer Send To
I created a shortcut link for Handbrake which worked nicely, but I could not find the "temporary desktop shortcut" (I looked for *.lnk on C: drive + SyMenu drive)
I did notice this file: ….\SyMenu\ProgramFiles\SPSSuite\SyMenuSuite\HandBrake_(x64)_sps\portable.ini.template
Containing:
#################################
# HandBrake Portable
#################################
# Notes:
# - Rename this file to portable.ini to activate feature.
# - storage.dir => Stores Presets, Settings and Log Files.
# - tmp.dir => temporary files only. (i.e Preview images)
# - update.check => true | false (enabled / disabled, default disabled for portable)
#
# Set to 'cwd' to use the current applications directory. It will automatically create "storage" and "tmp" folders in this instance.
# Leave blank to use the system "TMP" directory and the "AppData" user profile folder.
#################################
storage.dir = cwd
tmp.dir = cwd
update.check = false
Would that make it easier to be portable?
Anyway, thanks again, I am now reaching the end of my "geriatric" investigative powers and have a "reliable" working solution.
|
|
|
link
|
|
Gianluca Administrator Posts: 1274
31/12/2018
|
jimlad68 wrote:
I am not sure if there would be any other downsides to leaving it unticked??
Who knows...? It depends on how HandBrake works
jimlad68 wrote:
[...]I could not find the "temporary desktop shortcut" (I looked for *.lnk on C: drive + SyMenu drive)
That's probably because when you activate the checkbox for "Desktop Shortcut" you haven't restarted SyMenu.
SyMenu creates all the Desktop shortcut at start time, and removes them at quit time.
So tick the checkbox for HB, save the configuration, quit SyMenu, start SyMenu. Your new shortcut will appear in your desktop and it'll be called "HandBrake (x64) (Sy).lnk".
jimlad68 wrote:
I did notice this file: ….\SyMenu\ProgramFiles\SPSSuite\SyMenuSuite\HandBrake_(x64)_sps\portable.ini.template
You did it!!! This file didn't exist when I first studied HB. It's probably a recent addition from the author. Now the HB portability becomes easier and doesn't need the Environment Variable rewrite.
I've just changed the definition so if you want to check it, remove HB, download again the program definitions from within SyMenu, install HD again. No more Advanced parameters but the program is portable the same thanks to the ini file (the file renaming is made by SyMenu itself during installation).
Thanks for the tip!!!
|
|
|
link
|
|
jimlad68 Posts: 13
31/12/2018
|
Firstly, I worked out the shortcut problem, I had created shortcut keys from Programs Shortcut, instead of Desktop shortcut!!! That now works a treat.
Reinstalled HandBrake as you suggested, copied/overwrote my saved presets.json and settings.json to the SyMenu folder:
And all is well with the world at the end of 2018 (if only).
However, for the file explorer "send to" to pickup the selected file in explorer, I had to use a standard shortcut e.g. :
Target "E:\zPortAps\SyMenu\ProgramFiles\SPSSuite\SyMenuSuite\HandBrake_(x64)_sps\HandBrake.exe
But it did use the same presets and settings, so not a problem.
Is there a way to pass the explorer selected file name as input to the "send to" SyMenu shortcut? Perhaps it would not have made any difference which shortcut was used without the new "portable" option.
Thanks, yet again.
|
|
|
link
|
|
Gianluca Administrator Posts: 1274
02/01/2019
|
IMHO the "Send to" feature is, by its nature, opposed to the portability concept.
Your case is a bit extreme in the same way. If you want HB to be fully portable, why do you need it in the send to menu? I understand the need for a clean PC but a clean PC must be clean even in the send to menu 
Anyway the Windows send to feature is nothing else than a folder with some shortcuts in it. In my PC I can find it in:
C:\Users[user]\AppData\Roaming\Microsoft\Windows\SendTo
If you want a SyMenu Desktop shortcut appears in the send to menu, simply copy it inside the special folder. The Windows send to menu will gain a new item where the executable called will be SyMenu that consequentially will call your program.
|
|
|
link
|
|
jimlad68 Posts: 13
02/01/2019
|
I understand your ideology regarding portability, and to me every program should be built to be portable, unfortunately they are not. But I do appreciate that some programs need to interact with the "system" and other programs.
That said, as mentioned before, I like portable programs because they do no clutter up my OS disk and make image backups much smaller, and do not add unnecessary items to the already massive registry. Hence my reason to use a portable version of HB, and many other programs, but as you intimate, a portable version may not be the best option for regular use and integration. (In those instances I may have both portable and non-portable versions).
So, especially if one uses mostly 1 PC, features like the Explorer "Send To", shortcuts/Pins on the taskbar are very useful and time saving. So why not take advantage of them.
I use the explorer "send to" feature rather than adding to the explorer R click as it is less cluttered for the R click, and as you show, very easy to add to the "send to" folder. I have a shortcut to the "send to" folder in the "send to" folder!
Throughout my IT career (mostly operations and system testing), and not being a programer (a limited bodging scripter at best) I have often resorted to use products/features made for one function in another domain, far from ideal, but often solves a problem. So I am very appreciative of the "collection" features of SyMenu.
Hope that helps.
|
|
|
link
|