SyMenu Forum

Glenn

all messages by user

02/08/2015 Topic: read-only media Glenn	Is it possible to put a version of SyMenu, preconfigured for use with read-only media, and install it on that read-only media, and be able to obtain a functional menu system for accessing things on that media? (CD-R, DVD-R, etc.) Or are there too many places where SyMenu assumes the ability to write to certain parts of its filesystem. I realize this would be a restriction on the types of programs and purposes for the rest of the content on the media as well.
03/08/2015 Topic: multi-column menus? Glenn	When I expand My Computer / Host programs I get a menu listing that is extremely long, because I have a lot of software packages installed. Back in XP days, long menus in the Start Menu would appear in multiple columns, so you could see all the packages at once without scrolling. This is helpful when you know something is installed, but sort of forget the name of it... Like do you look under WordPerfect or Corel, etc. Of course, they ruined the Start Menu starting in Vista. I'm just starting to play with SyMenu, not particularly for the portable software for which it was designed, but rather as a way of using it as a replacement for the dysfunctional Start Menus on Vista, Win8, and Win10. And it seems likely that I'll be able to create functionally organized submenus for programs that are used together for different types of tasks... and with the "auto execute" feature, and several configurations of SyMenu, launching a set of programs used together becomes possible also. Still, there will be times when the whole list of Host programs would be good to see... and multiple columns presents a better interface than scrolling.
03/08/2015 Topic: multi-user SyMenu? Glenn	I just had another inspiration for a use of SyMenu, while writing my previous question... I have one project that I share on dropbox... one dropbox folder has a number of programs installed, and for each of several instances of the project there is a data folder. If this project grows big enough that I use more space than in available on free dropbox (and it is heading that way), I'll make the project programs folder read-only to others. Right now, others are just "cooperating" to make it read-only. So if I install SyMenu for this project, that would allow all the users to benefit... but if I put it in the programs folder, it might become read-only, like the CD/DVD question I posed yesterday. On the other hand, if it is customized for a particular instance of the project, and placed in the data folder, there is still the possibility of multiple people working on that instance wanting to use SyMenu concurrently. I realize that this isn't the "design goal" for SyMenu, but am wondering if it might work in such a scenario?
03/08/2015 Topic: read-only media Glenn	I see in the release notes on the download page for 3.04 that "SyMenu recognizes if it is executing from a read only device". But I'm not sure what that means, or where to find more information about it... the phrase "read only" is not in the manual.
03/08/2015 Topic: multi-user SyMenu? Glenn	Having just commented in my read only media thread, after having found a reference from version 3.04 release notes, I wonder if "multi user mode" might be possible by "simply" configuring SyMenu to _think_ it was running on read-only media, even if it is a read-write dropbox folder. And, as a corollary, I wonder if SyMenu detects "read only dropbox folders" (but I don't have any to test with, and I'm not sure how I'd know if it detected it, if I had one!)
03/08/2015 Topic: multi-column menus? Glenn	From https://msdn.microsoft.com/en-us/library/windows/desktop/ms647578%28v=vs.85%29.aspx this seems relevant, if you populate the menus yourself. MFT_MENUBARBREAK0x00000020L Places the menu item on a new line (for a menu bar) or in a new column (for a drop-down menu, submenu, or shortcut menu). For a drop-down menu, submenu, or shortcut menu, a vertical line separates the new column from the old.
03/08/2015 Topic: multi-user SyMenu? Glenn	There are 3 kinds of Dropbox sharing that I am aware of, but have only experienced #1 and #3 below so far. 1) Read-write sharing among a group of cooperating users, all synchronizing in read-write modes, but there is a delay from a file getting updated by user A and seen by user B (and C, etc). And Dropbox maintains old revisions for 30 days, so if there was a conflict, and it is noticed soon enough, manual resolution can be done. 2) Read-only sharing among a group of cooperating users, a paid feature, which I haven't experienced. I would assume one writer and many readers, in which case the readers see read-only. If it is possible to have multiple writers in this mode, I would assume they would synchronize as above. 3) Public URL. No automatic synchronization is done. Users with the link can download, and can share the link further. Downloading makes their own copy read-only or read-write, but it is their copy or fork and does not affect the data at the link.
03/08/2015 Topic: multi-user SyMenu? Glenn	So it sounds like sharing mode 2 will work great with the improved read-only detection. Sharing mode 3 works today, because it is a private copy. Sharing mode 1 is the remaining question here, I think. Where each person has a read-write copy, but may be using SyMenu concurrently, even if carefully updating different files in a cooperative manner with other users. Here is where a configuration setting that says "pretend to be read-only" would be useful, or else very careful updating in SyMenu to deal with concurrent access/update to the SyMenu working data.
04/08/2015 Topic: multi-user SyMenu? Glenn	I'm not surprised that SyMenu keeps data in memory for better performance while operating, thus making Sharing mode 1 problematical. But one way to support sharing mode 1 would be to have a configuration item that causes SyMenu to pretend it is in a read-only environment.... except for one computer that is allowed to read-write. The name of the computer would generally suffice, as we are talking cooperative users here, if they are allowed read-write access to the dropbox folder, and it is unlikely that two users would have the same computer name. But for extra protection, it could be computer name and user name combined, which would more rarely coincide. The computer name (and user name) could be automatically determined when that user sets the read-only mode for others.
04/08/2015 Topic: multi-user SyMenu? Glenn	Oh, no, not at all. I'm not at all suggesting that SyMenu would manage the permissions of the Windows file system. I'm only suggesting that SyMenu have a configuration method to enable a mode that is already necessary for the support of read-only media, wherein SyMenu disables its own features that would require writing to the files that it manages for its own use. The result of enabling that mode for SyMenu on shared read-write media is that one person would be able to configure SyMenu for a particular purpose or usage for the environment that is shared in the read-write media, and that others could use the pre-configured SyMenu in that environment without having SyMenu garble its configuration file by having multiple instances of it writing back files to the shared media. Your suggestion of sharing a copy of a particular preconfigured SyMenu environment on read-only media assumes that it is possible to share read-only media together with read-write media. With Dropbox, creating read-only media costs $100/year, not an onerous amount, perhaps, in a commercial environment, but I am not in a commercial environment. I suppose there are two different implementation techniques that could be used to implement support for SyMenu on read-only media: The first would "detect" (somehow, not exactly sure your what techniques are being used or how, from 3.04 onward) and set a global mode that prevents operations that would eventually cause SyMenu to wish to write data to the disk. From your description of putting padlocks on certain operations, it would seem that this is the technique that you chose. I'm only suggesting that an additional mechanism be added to the detection, to set that global mode based on a configuration setting. The second technique would simply ignore the errors that occur when writing to media, but that would potentially ignore errors caused by other reasons than read-only media. It would also result in users being able to think they have performed certain operations, but that the effect of those operations would be transient, and vanish when SyMenu exits. Depending on whether any operations of SyMenu involve writing to the disk prior to exiting, the effects could be perceived sooner than at exit time, and be confusing. I doubt you have chosen this technique.
04/08/2015 Topic: multi-user SyMenu? Glenn	Thanks for your continued attention to my suggestion. The existence of a file such as READONLY to trigger ROM would be sufficient. While any user actually on read-write media could remove that file, _any_ solution that depends on _any_ configuration setting to trigger ROM on read-write media would be subject to replacement of the file containing the configuration. There can be no prevention of an "attack". But this, or any configuration scheme, would avoid the situation where users accidentally modify a shared configuration of SyMenu that other users are depending on having in a stable state, and this would avoid surprises for the other users. Regarding a configuration item, I note that you have "auto execute" items that only run on certain computers. A readonly configuration setting that retained the computer name (and maybe user name), of the person that set the option, and only entered ROM for other users, would allow that one user to conveniently edit the SyMenu configuration for the other users. Of course, that one user could have a second SyMenu configuration stored elsewhere that could be edited, as you pointed out, and being on read-write media in actual fact, the shared configuration could then be replaced by updated one. This would be more cumbersome, but would also ensure that the one user also doesn't accidentally make changes that affect others.
04/08/2015 Topic: multi-user SyMenu? Glenn	"... you'll have it for the 4.12."
05/08/2015 Topic: compact and pinned? Alas! Glenn	Experimenting, I turned on compact contextual menu. This seems appropriate for use when setting up a menu system to be used by others, for a specific application. However, I was surprised that there is no pin in the compact menu. Pondering, I realize that the top entry in the compact menu has a fly-out menu which might conflict somewhat with the 4-headed arrow icon for moving the non-compact menu. But couldn't click-n-drag on the top entry cause motion of the menu anyway, without the 4-headed arrow icon being needed? Or at least click-n-drag on the pin? (if click-n-drag on a menu entry has some other meaning I haven't discovered yet)
05/08/2015 Topic: manual is deficient in describing relative paths Glenn	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
05/08/2015 Topic: compact and pinned? Alas! Glenn	Basic and expert sounds interesting, I suppose, although the completely customizable one sounds more interesting. Once that is achieved, I suppose Basic, expert, full, and compact could all just be predefined customizations. To go with this, another option that would be convenient, in my opinion, would be to have the (compact or non-compact) pinned menu replace show up when at appropriately configured SyMenu first starts. The floating icon can already be disabled. It should be pinned to the configured location, unless that is off-screen, in which case it should be centered or top left, or some such place.
05/08/2015 Topic: copy SyContainers Glenn	If there is a way to make a duplicate of a SyContainer, I haven't found it yet, but that would sure be handy, as many programs are similar to others, and frequently 2-3 variations of a single program are of interest to have separate shortcuts.
07/08/2015 Topic: copy SyContainers Glenn	I missed the Control Drag & Drop, or at least its significance. I actually was looking for a way to copy a single item, and incorrectly used SyContainer as an "object superclass" of all the other individual items, sorry. Thanks for pointing out the clone feature, it is exactly what I was looking for, but I was looking for it by searching for copy, which doesn't appear in the title or description because you used the word clone. Maybe that is a manual suggestion... Windows Explorer calls the operation "copy", when copying items around in its Start Menu... right-click-n-drag, and when dropping, you get a popup for copy or move.
07/08/2015 Topic: manual is deficient in describing relative paths Glenn	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.
07/08/2015 Topic: tooltip for SyMenu system tray icon Glenn	The Notification area icons (usually called the system tray icons) often have 4 available behaviors... hovering usually pops up a tooltip telling what the system tray icon is and/or a brief status, the icon itself may change to reflect status changes, left clicking often launches a user interface window or menu, and right clicking usually gives a menu, sometimes the same, sometimes different than the left click when it produces a menu. For SyMenu, left and right click seem to do the same thing by default, not sure if that is changeable. I could imagine a menu mode where left click produces the compact menu, and right click produces the SyMenu built-in menus. But the real purpose of this note is to suggest that the tooltip for the icon, and the icon itself, be configurable. Right now, as far as I can tell, the icon is fixed, and the tooltip is "SyMenu" also. Realizing that a little acknowledgement for SyMenu is appropriate, I suggest that the tooltip be configurable, and if blank "SyMenu" is used, and if non-blank " - SyMenu" is appended. This suggestion came to me immediately when I loaded by second concurrent copy of SyMenu, and realized I couldn't tell which was which.
07/08/2015 Topic: tooltip for SyMenu system tray icon Glenn	I note that it is probably unusual to have more than one portable media installed on a computer in the "computing on a thumb drive" model, but it is certainly not unusual to have more than one dropbox folder in use concurrently. The drive letter overlay is handy when the portable media is assigned a drive letter... but when SyMenu is not at \SyMenu on that drive letter, maybe a default tooltip value that is the same as the name of the folder one level above SyMenu would be a useful default, if not configured.