SyMenu Forum

Glenn

all messages by user

08/08/2015 Topic: Download page could mention Windows 10 Glenn	All my testing with SyMenu has been on Windows 10. While I likely haven't exercised every feature as yet, enough of it is working to claim that it runs on Windows 10.
11/08/2015 Topic: tooltip for SyMenu system tray icon Glenn	I'll split menu ideas to a different topic it should have been, but it just hit me while writing this one, regarding the tooltip. For the tooltip, my first idea was just to allow plain text from an edit field, allowing any sort of fixed customization, followed by - SyMenu. Then it occurred to me that a default semi-custom value of the "leaf" directory name (the one just higher than SyMenu itself) would go a long way toward discriminating between various menus if the user didn't customize anything. So I'm suggesting that or something similar as a new default value for for the tooltip, if the new configuration feature is left uncustomized. Regarding the new configuration value itself, your idea of having a variable substitution mechanism is great (if you call them environment variables, there is a strong connotation that they would be Windows environment variables, I'm not sure if that is desirable)... it all depends on how much work you want to do. For my purposes, a simple text string would suffice. However, I can see that the use of variables, and perhaps some technique for indicating a newline, could be useful. One that sounds appealing would be the Windows "bitness" (16 (if you support that) or 32 or 64 or maybe even 128 someday). There are many others. Using the CMD environment variable expansion syntax %varname% is appealing for its familiarity, but again, it alludes to supporting Windows environment variables. To support Windows environment variables and also SyMenu custom variables there could be a conflict in the name space between a particular users' collection of Windows environment variables and any defined SyMenu custom variables. While for any version of SyMenu, the list of custom names might be knowable, and might be avoidable, if additional variables are added by Windows, by SyMenu, or by a users' additions to the Windows environment variables, names could conflict. My understanding is that the only character that cannot be used in a Windows environment variable name is the equal sign. Perhaps %varname% would refer to Windows environment variables, and %=varname% would refer to SyMenu custom environment variables? Other syntaxes or delimiters, or namespace indications could be used. By having separate name spaces, additional SyMenu custom variables could be added at any time, without being concerned about conflict with Windows and user environment variables. Regarding a list of SyMenu custom variables, bitness (mentioned above), parent-of-SyMenu directory, and available RAM sound most useful to me. Once the capability is in place, other variables may be suggested over time, with the implementation straightforward, except for any difficulty in determining the value of the suggested variable.
11/08/2015 Topic: Menu customization Glenn	I suggested in another thread the idea of having a different result for right and left click actions, and the feedback was that this adds complexity. While it does, indeed, add complexity, such complexity is found in nearly every existing Windows program, so that particular complexity is somewhat commonplace, and knowledge of it fairly widespread. It is certainly true that any feature added to a program adds complexity. Complexity adds power to a program, but concurrently makes the full set of program capabilities larger and thus harder to master in full. Users tend to learn only what they need to learn to get their activities done... in fact, many users limit their effectiveness in using programs because of their unwillingness to learn more features, even features that would assist them in their activities. Most programs that I have used that have different results for left and right click typically put "easy" or "commonly used" functions on the left-click menu, and more complex or less commonly used functions on the right click menu. Windows Explorer even goes as far as to have yet more entries show up on the right click menu only if the user also presses a shiftt key. Personally, I find "copy as path" and "start CMD prompt here" to be more frequently used in my right click emnu from Windows Explorer than many of the other entries in that menu.. but i have to remember to hold Shift to get them to show up. Back to my original suggestion for splitting the SyMenu menu into separate left and right click menus. I would perceive three kinds of users for SyMenu. 1. Those that make menus for their own use. 2. Those that make menus for use by others. 3. Those that use menus made by others. The first group is likely to regularly edit their menus, although I suspect that they use the entries more often than they edit them. The second group is probably the smallest group, and they may well tweak menus as much or more than they use them. The third group wouldn't edit the menus at all. You have already recognized, in having both the full menu and compact menu available, that the SyMenu-defined items are "in the way" of efficient use of the user-defined menu entries, once the menu creation process is complete. Putting the SyMenu-defined items in a submenu gets them "out of the way" of efficient use of the user-definned menu. However, it also make use of the SyMenu-defined items less efficient when editing a menu. One can switch the configuration back and forth between Compact and Full menu mode but doing that repeatedly is not particularly efficient either. My suggestion goes just one step further. A willingness by a user to deal with the complexity of having different menus on left and right buttons, which is an extremely common form of complexity among Windows programs, can restore the efficiency of using the SyMenu-defined items for menu editing while not reducing the efficiency of using/testing the user-defined menu. But after thinking through all of the above, it occurred to me that for most menu editing operations, the function really used most is Tools / Configuration, and a hot-key directly to that screen would _add_ efficiency to the editing process, without splitting the menus or switch back and forth between Normal and Compact view.
21/08/2015 Topic: New SyMenu version 4.12 Glenn	Gianluca wrote: The last news regards the availability of the first file flag. The READONLY file. If you create this kind of empty file on the root of SyMenu folder, SyMenu will run in read only mode. Very timely for my needs. I just checked today to see if there was a new version with READONLY, as tomorrow, I'll have 4 people working in the same Dropbox folder... now with the READONLY feature. The alternative was going to be to clone 4 copies of SyMenu in the Dropbox folder, one for each user... This is much better! Thanks!
09/09/2015 Topic: New SyMenu version 4.12 Glenn	Gianluca wrote: The last news regards the availability of the first file flag. The READONLY file. If you create this kind of empty file on the root of SyMenu folder, SyMenu will run in read only mode. And I've been sharing the use of a READONLY menu among 3-4 simultaneous computers for 17 days now, and it has been working great, with no conflict or corruption that I have been able to determine. This has been a great enhancement to the shared Dropbox folder collaboration that I have been experimenting with... just what I needed to make it much easier for the less computer-literate users. Thanks for sneaking that in to this release and this timeframe.
06/10/2015 Topic: AppData Glenn	Regarding environment variables, is there a way that one can set an environment variable to the same value as %WORKING DIRECTORY% which does not actually appear in the environment of launched programs? It seems that setting APPDATA to %WORKING DIRECTORY% produces an error -- I suppose that those 4 boxes are expecting actual path names, rather than environment variables that (could) expand to path names? Is there some way to specify that APPDATA gets set to the equivalent path? It would be nice to have the ability to set _any_ environment variable to _any_ value... either a path with Universal Unit Identifier expansion or expansion of other environment variables, or SyMenu variables, or both (as long as there is a syntax that allows escaping the expansions so they don't happen, in case the reference matches as desired value). edited by Glenn on 06/10/2015
06/10/2015 Topic: WinCommand issues Glenn	Seems that the "start" command is supported, but doesn't get the asynhcronous behaviour of the "start" command in CMD.exe. Generally, the purpose of "start" is to launch a program and _not_ wait for it to complete, but continue with the next operation.... unless the /WAIT option is given. Along with that, the nice "CMD-like" window that displays while the WinCommand is running is great for debugging, but it would be nice to have a checkbox to make it auto-close when complete. Or just to make it always auto-close when complete, but the user can add a pause command if they want it to stay around for debugging.
06/10/2015 Topic: Inconsistent current directory Glenn	In a Windows command, it seems that references to relative paths start at the directory containing SyMenu, where as in a Program, references ot relative paths start inside the SyMenu directory. So a Program that might reference ..\..\spw\program.exe doesn't get found when the relative path is copied to a Windows Command, there it has to be ..\spw\program.exe This is a bit confusing. I think the Windows Command uses a more natural expectation of where the relative paths should start from, but I doubt that backwards compatibility would allow either to be changed. Perhaps the manual could better explain the expected starting point for relative paths in each case (and there might be more than these two cases, I've not explored every feature of SyMenu as yet).
13/10/2015 Topic: Command line option for hot-key Glenn	After having created a number of SyMenu configurations on different dropbox folders, and realizing the need to distinguish among them via configurable tool-tip text and icons, comes the realization that it would be good to have the Control-F1 hotkey also configurable... but from the command line, so that different people that use different combinations of the SyMenu configurations could assign the hotkeys they want that don't interfere with other hotkeys they use. So it would be nice to be able to say, for example, in a batch file: %dropbox-path%\project-one-folder\SyMenu\SyMenu.exe /Hotkey="CTRL F1" %dropbox-path%\project-two-folder\SyMenu\SyMenu.exe /Hotkey="CTRL F2" %dropbox-path%\project-three-folder\SyMenu\SyMenu.exe /Hotkey="CTRL F3" I suppose some might also like an option to set the search hotkey as well.
17/11/2015 Topic: WinCommand issues Glenn	The use of the system CMD window may indeed resolve such problems. IIRC, I resolved my issue by writing a little AutoHotKey script to do the asynchronous part. AutoHotKey fits well with SyMenu: although its syntax is atrocious, it is small, portable, and quite capable.
17/11/2015 Topic: Inconsistent current directory Glenn	I'm sure you can better describe the fact that there are two different root paths, and what they are. If there were only one, it would be even easier to comprehend as well as to explain. It is true that "." as a path name has different meanings depending on the current directory at the time it is referenced. This is something that people have to deal with all the time. It just seems to me to be a shame that within a single program, SyMenu, the concept of "." has different meanings in different contexts within the program. Surely I agree that C:\Windows\system32 is a pretty useless definition of ".", but in looking for an alternative, consistency with SyProgram would seem quite natural to me. Both SyProgram and Windows Command execute commands. Why should they have different definitions of "."? Is there any benefit to the user? What is that benefit? Having a single definition of "." throughout a particular SyMenu invocation (that of the current directory inherited by SyMenu when it is started) would be very natural to me. But, that would be an incompatible change, at this point. So better documentation would help. Maybe you've updated it already. I was too busy the last 6 weeks to read anything here, but just getting back, and updating my SyMenu installations to the latest versions...
17/11/2015 Topic: Request - Read only mode change Glenn	The READONLY.machine idea could work, but you would have to search for a pattern of file names. Another alternative would be to place a single line in the file containing the non-READONLY machine COMPUTERNAME. Someone with write access to the directory could clearly override it, but that solves the "problem" of misspelled COMPUTERNAME values, while still providing a reasonable assurance in a known environment that only one machine can update. [obviously, computer names can be changed, but that is lots harder than editing the content of the READONLY file: we are not talking about security from hacking here, just protection from accidental changes.]
17/11/2015 Topic: tooltip for SyMenu system tray icon Glenn	YAY! I was a little disappointed that there was no SyMenu variable defined for the directory name just above SyMenu itself, since that would differentiate the various directories on Dropbox where I am using SyMenu, and was the example in my initial discussion of the feature. But then, thinking about the Command line Hotkey (that is going to be _really_ helpful, thanks), I wondered if maybe there should be a technique for defining new SyMenu variables on the command line: -sv"VARNAME=VALUE" (-sv for SyMenu Variable). This might be useful in contexts other than the tooltip as well, so allowing multiple instances of the option on the command line might be good.
17/11/2015 Topic: tooltip for SyMenu system tray icon Glenn	When I mention "defining new SyMenu variables", I really mean new ones... ones that SyMenu doesn't define for itself. Whether allowing override values for existing SyMenu variables is a good idea or not, I couldn't say, but if it is, it should have a different syntax. That way, an attempt to define an existing SyMenu variable could produce an error MessageBox at startup time.
17/11/2015 Topic: AppData Glenn	I never thought to put a "." in APPDATA! Sure it works. But it would be nice to be able to set any environment variable to any value, including references to other environment variables and potentially to SyMenu variables as well. Some programs define particular environment variables that they respond to, and it may be useful to be able to set them differently for different invocations of those programs from a single SyMenu instance.
17/11/2015 Topic: tooltip for SyMenu system tray icon Glenn	SyMenu variables that are not defined or used by SyMenu itself, could be referenced inside of places that allow substitution of SyMenu variables, such as the Tooltip text (which is the topic of this discussion), or SyProgram Advanced settings (like %WORKING DIRECTORY% can be used there), or maybe even SyProgram command lines? As parameters to programs? You would know better than I where they can be used at present, and the complete list of them. The only problem I see is that you are using the exact same expansion syntax as is generally used for environment variables, and it would be hard to differentiate when to expand a SyMenu variable and when to leave the syntax alone for later expansion by something else. That could be left to the user, though, to keep their names separate.
17/11/2015 Topic: AppData Glenn	Well, I think Albert E. and quite a few others are ahead of me in the genius category! Yes, the 4 you have presently may be useful in some circumstances, but it seems rare. APPDATA I needed once, and worked around it when I couldn't figure out how to put %WORKING DIRECTORY% in it, and didn't think of ".". I can think of programs (not necessarily portable ones) that use each of APPDATA, HOMEPATH, and USERPROFILE. But I have never come across a program that actually looks in PROGRAMFILES for anything... and these days, with 64/32 and "Program Files (x86)", such programs would probably be broken anyway. You have a nice "browse" button next to each of those... but it seems to select fully qualified paths, which would then need to be front-truncated and edited to make the path portable, if #: can even be used in them... a user can get the fully qualified paths from other sources, such as Windows Explorer, copy as path feature, if they are needed. A multiline textbox sounds good to me... I'm envisioning that each line could be an environment variable definition, and that expansion of %var% would happen (both environment and SyMenu, making SyMenu variables from the command line have another use?), as in: APPDATA=. MyPath=#:\over\here MyFile=.\over\%there% fonts=%windir%\fonts VERBOSE=3 SyMenu.exe -sv"there=the\hill"
23/11/2015 Topic: READONLY and recent updates Glenn	Is the notification that SyMenu has recently been updated, and the offer to launch the browser showing the new features itself a new feature? It seems that if one does the following sequence (and maybe other variations), that the offer gets repeated at each launch of SyMenu. 1) remove READONLY marker 2) start SyMenu 3) recreate READONLY marker 4) update SyMenu One could make a case that this is an inappropriate sequence, but steps 1-3 are a fast way to get a non-READONLY instance on a machine, leaving it READONLY for others as much as possible.
23/11/2015 Topic: READONLY and recent updates Glenn	Thanks for the workaround, and the forthcoming version.
23/11/2015 Topic: READONLY and recent updates Glenn	I'm surprised how much stuff is in the ~Update folder. Does it normally stick around or go away? Space could be an issue in some environments. Since you suggest deleting it for this workaround, can it generally be deleted? What is the benefit of keeping it, if any?