Glenn Posts: 99 07/08/2015	Glenn Posts: 99 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.
	link
Glenn Posts: 99 07/08/2015	Glenn Posts: 99 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.
	link
Gianluca Administrator Posts: 1274 11/08/2015	Gianluca Administrator Posts: 1274 Hi Gleen. I don't like very much to have a different behavior among the right and left click mouse button. I'm trying to give the SyMenu users a complex program in the easier way as possible. So click with the right button or with the left one has the same effect on purpose. Instead I really, really, really like the idea of the customizable tooltip. To create a customizable feature we need to give some rules first. Your example where the SyMenu folder name or better the SyMenu full path is exposed is one rule but can't be the only one because it could be a very useful on but doesn't cover every needs. We should think about the reason for which you need a new feature and try to make it more general as possible. Let's try with a different idea. How about a free text to customize the tooltip? I should use it to differentiate my several SyMenu installations. For example "SanDisk Extreme installation" (it's my SyMenu on the pen drive), "Saturn installation" (it's my SyMenu on the fixed PC Saturn) and so on. Free text allows us to implement, in a future version, something like environment variables. For example I will able to set my free text with "Installed on %path%" to get the full path for the current SyMenu installation. But we should have other variables, something like %CPU%, %RAM%, %computername%... some are naturally standard environment variables, some others are SyMenu custom environment variables. Well if this feature will be implemented I surely need a list of environment variables to implement from you and the other users :-) In this way the basic user has a free text to fill to simply recognize his SyMenu installation, while the advanced user has an highest degree of customization. What do you think?
	link
Glenn Posts: 99 11/08/2015	Glenn Posts: 99 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.
	link
Gianluca Administrator Posts: 1274 12/08/2015	Gianluca Administrator Posts: 1274 You are right. I was careless to use the term environment variables. We can call them SyMenu variables. Ok the customizable tooltip is in my TODO list.
	link
Gianluca Administrator Posts: 1274 19/10/2015	Gianluca Administrator Posts: 1274 The custom tooltip feature has been implemented with the current version (4.13).
	link
Glenn Posts: 99 17/11/2015	Glenn Posts: 99 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.
	link
Glenn Posts: 99 17/11/2015	Glenn Posts: 99 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.
	link
Gianluca Administrator Posts: 1274 17/11/2015	Gianluca Administrator Posts: 1274 The SyMenu Variables can surely become the next command line customizable options. But I don't understand what is the purpose of having a new variable that SyMenu doesn't use.. The only scenario I can imagine could be affected by these unknow variables is the command line... Should I have to inject it inside every SyWinCommand execution? I not even know if it is a possible thing to do
	link
Glenn Posts: 99 17/11/2015	Glenn Posts: 99 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.
	link

---