|
Glenn Posts: 99
05/08/2015
|
It took me a couple hours to figure out how to really configure a program to run using SyMenu. Once I figured it out, I realized that the reason was because SyMenu was designed based on some assumptions from portable program design, which are neither stated nor explained in the manual. It has been a while since I looked at portable programs, and I have probably never created one to any portable program standard or specification, but I have made a fair number of programs that are portable because they are single-file executables... the simplest packaging case.
My first astonishment was that SyMenu.exe was _inside_ of the SyMenu folder instead of beside it. Once I started thinking about what I'd read about portable programs, I realized that this is the way portable programs are supposed to be constructed... the highest level folder is the container for everything, including the program and any files or folders it uses during startup or operation.
In fact, this is an assumption that is not stated in the SyMenu manual... SyMenu is a portable program, so "of course" it obeys that rule. But that rule is very unnatural to someone that isn't regularly using or creating portable programs.
My second astonishment was that when I had path problems, I fiddled around and realized that somehow the "relative" parameter I had passed to a SyProgram was relative to the program file rather than the CWD, and so I tweaked it to work, but then the program was getting the wrong CWD, and I looked to see what the "Start In:" value was set to, was that there was no "Start In:" value!
In fact, this is an assumption that is unstated in the SyMenu manual... regarding the "current working directory" or CWD (in Unix/C terms) or "Start in:" (Windows shortcut term) or %CD% (Windows CMD with command extensions enabled terms) or %WORKING DIRECTORY% in SyMenu terms. SyMenu being intended for use with portable programs, and understanding how portable programs work, therefore by design sets the CWD for a program to launch to be the inside of the highest level folder for the program. This fits perfectly with the expectations of portable programs, but is very unnatural to someone that is accustomed to setting up Windows Shortcuts. The SyMenu manual's description of setting up a SyProgram sounds very much like setting up a Windows shortcut, and Windows shortcuts can be dragged to SyMenu for use, but not everything is preserved, particularly, the "Start In:" value.
This thread: http://www.ugmfree.it/forum/messages.aspx?TopicID=24 was one that I found when searching for "Start In", and the explanation there
This problem is due to a not perfect portability of these programs: they trust in the existence of a parameter that is not strictly pertinent with portable programs. The parameters is 'Working Directory'.
You can see this attribute in quite any Windows link (it's usually called 'Start in').
sounds very backwards to me, but it gave me the clue that I needed to set the "advanced" working directory parameter to "%WORKING DIRECTORY%", and then my tweaked relative path failed again, and I had to untweak it, and then I realized the difference in the basic assumptions that I was making versus those assumed by the SyMenu manual: the exact set of specifications that defined to allow programs to be portable.
I'm not sure if there are other assumptions that should be stated. Certainly there should be a section in the manual that mentions that SyMenu is a portable program, and its primary use is to work with portable programs, and that means that the following list of items are different than users of typical installed Windows programs would expect:
1) SyMenu lives within its container directory.
2) SyMenu, by default, launches programs with the CWD set to the program's container directory.
3) relative parameters passed to the program must be relative to the CWD used to launch the program.
4) SyMenu, when importing a Windows shortcut, ignores the Start In setting in favor of the container directory.
One might also include a crib sheet of how to configure SyMenu to launch installed programs. List corresponds to the above.
1) To enable easy launching of SyMenu from local or portable or network directories, simply make a batch file wherever desired, and code a line
START "SyMenu" "path\to\SyMenu\SyMenu.exe"
2) Turn on the Advanced Settings and set working directory to "%WORKING DIRECTORY%" (too bad you didn't use %CD%)
3) no special action required, if #2 is done
4) Manually configure working directory to reflect the Start In setting (or some other value better suited to the environment of interest, if that is desired, but do not assume it will be inherited from the imported shortcut.
My lists may not be complete, because I haven't yet tapped the whole power of SyMenu. Now that I've figured out the above, though, I'm liking the looks of the resulting menus.
edited by Glenn on 05/08/2015
|
|
|
link
|
|
Gianluca Administrator Posts: 1274
05/08/2015
|
Hi Glenn.
Let me tell you that your contribution to the project in these few days has been huge!
I think that you are the first user to go so deep in all the SyMenu features.
Thanks!
Your post touches a lot of topics and it is a bit difficult for me to reply in a schematic way but I try the same (schematic posts are more useful for readers than conversational ones).
Default portable program structure
There is no standard in the file and folder structure for portable programs neither for the file and folder structure of installed programs indeed.
The manual explains how to download, unzip, and execute SyMenu here http://localhost/UGMFree/SyMenuManual.4.12.aspx#Installation so implicitly it explains how the SyMenu file and folder structure is.
Portable program nature
A portable program is not a different kind of animal from a not portable program. It is only a more respectful and educated one.
The only real difference is that some portable programs need highest privileges to execute but it is true for the not portable programs too.
Working directory
The working directory (or "Start in") is a particular attribute for Windows shortcuts. When you create a Windows shortcut the assumption is that the WD is the same as the executable directory. In this case it is useless. The attribute utility instead raises when you need to change the current working directory. I post some example for Jar programs where the executable file is java.exe but the working directory is the jar root folder. Another scenario where the WD is useful could be in command items.
In all the other cases WD is useless and it is not necessary to specify "%WORKING DIRECTORY%" for every local program.
Maybe your experience is different and doesn't fall in the category I mentioned. So please do some examples.
Shortcut import
When you import a Windows shortcut, it is unwrapped to allow SyMenu to create an item that points to the real program and not to the shortcut.
You are right, the unwrapping method loses the original WD. I can add this feature.
Manual lacking
I will include your four sentences in the manual.
You are right, there are a lot of assumptions inside the manual, but I think it is quite normal that a user finds lacking in a manual according with his experience, knowledge, skills...
|
|
|
link
|
|
Glenn Posts: 99
07/08/2015
|
Gianluca wrote:
Hi Glenn.
Let me tell you that your contribution to the project in these few days has been huge!
I think that you are the first user to go so deep in all the SyMenu features.
Thanks!
You are welcome. It makes me feel better — I was quite concerned that I might be overloading you with unwanted complaints. But I'm finding SyMenu to be quite useful, and I have set up a system for one of my shared projects, and I'm looking forward to the next release with the readonly flag to be able to deploy it more broadly and safely. It is going to be slick. And just today I found another little tweak that could help, but that will be a different post.
Gianluca wrote:
Your post touches a lot of topics and it is a bit difficult for me to reply in a schematic way but I try the same (schematic posts are more useful for readers than conversational ones).
Default portable program structure
There is no standard in the file and folder structure for portable programs neither for the file and folder structure of installed programs indeed.
The manual explains how to download, unzip, and execute SyMenu here http://localhost/UGMFree/SyMenuManual.4.12.aspx#Installation so implicitly it explains how the SyMenu file and folder structure is.
You are probably right here... last I had researched portable programs, it was certainly before there were any standards, and it was quite some years ago, when the term was barely coined... I assumed there must be standards by now... Maybe what I am remembering and thinking would be standardized by now was more just a consensus statement of some proponents of how a portable could or should be written rather than any sort of official standard. Your manual is not the only place to find unstated assumptions 
Gianluca wrote:
Portable program nature
A portable program is not a different kind of animal from a not portable program. It is only a more respectful and educated one.
The only real difference is that some portable programs need highest privileges to execute but it is true for the not portable programs too.
Working directory
The working directory (or "Start in") is a particular attribute for Windows shortcuts. When you create a Windows shortcut the assumption is that the WD is the same as the executable directory. In this case it is useless. The attribute utility instead raises when you need to change the current working directory. I post some example for Jar programs where the executable file is java.exe but the working directory is the jar root folder. Another scenario where the WD is useful could be in command items.
In all the other cases WD is useless and it is not necessary to specify "%WORKING DIRECTORY%" for every local program.
Maybe your experience is different and doesn't fall in the category I mentioned. So please do some examples.
Here I am probably biased by my experience with particular, heavily used applications, rather than what the Windows shortcut defaults are. You are correct that when creating a shortcut using Windows Right-click / New / Shortcut or right-click-n-drag / drop / Create Shortcut Here, that the Start In is often explicitly set to the Program Folder. Creating a shortcut that points at %windir%\system32\cmd.exe, though, used Start In: %windir%
On the other hand, a fair number of programs create shortcuts with no entry in "Start In", and it appears that no entry in "Start In" produces a shortcut whose default working directory is the directory in which the shortcut is stored, rather than the directory in which the program is stored.
Another situation arises for command line programs. They are invoked with an explicit path, but the working directory is left at the CWD of the command line program that launches it... similar to blank Start In:.
So with the Working directory entry in SyMenu blank, it was surprising to me. If it had been filled in, like Windows does with Start In:, it would have been less surprising. But that is me. And stating the assumptions explicitly in the manual certainly won't hurt.
Gianluca wrote:
Shortcut import
When you import a Windows shortcut, it is unwrapped to allow SyMenu to create an item that points to the real program and not to the shortcut.
You are right, the unwrapping method loses the original WD. I can add this feature.
That would be useful... but I'm not sure what you would do when importing a blank Start In: ... leaving working directory blank has different semantics. Setting it to the directory in which the shortcut was located would at least be explicit and cause the SyProgram item to behave in the same manner as the imported shortcut... and be visible when looking at settings to discover the discrepancy.
Likewise, if SyMenu assumes, on a created-from-scratch SyProgram, that the blank working directory means the same as the program directory, being explicit there by filling it in would also be a useful enhancement.
The minimum, of course, is to document it in the manual, which you agreed to do below.
Gianluca wrote:
Manual lacking
I will include your four sentences in the manual.
You are right, there are a lot of assumptions inside the manual, but I think it is quite normal that a user finds lacking in a manual according with his experience, knowledge, skills...
Thanks. Yes, it is especially hard to document all the assumptions made by a program you also wrote. One of the things that impressed me with SyMenu was the apparent completeness of its manual, although by poking at the program a bit, I have managed to find a few omissions It's not my goal, I'm just wanting to use SyMenu for some projects, but being a new user with different background than yours, we have different assumptions in our heads Thanks for being willing to make improvements.
|
|
|
link
|