SyMenu Forum

Glenn

all messages by user

17/01/2016 Topic: a couple ideas for the future Glenn	Here's another idea, different than the above: In the Item Manager, it would be nice to have a "make copy" operation when an item is selected. It would make an exact copy of an item, but give it a different name (by adding "Copy of " to the front, or something along that line). Then similar commands could be created more efficiently.
18/01/2016 Topic: "." in a command parameter gets expanded Glenn	The attached shows an "echo ." command setup. Sadly, what gets echoed is the path to the current directory. I got excited when I discovered that "echo ^." didn't have that problem, but in non-CMD.exe programs, ^ just gets passed through. So the question is, is there a SyMenu way to escape a "." so that it can get passed through to a program, instead of being modified from "." to the current directory path on the way? In other words, not all "." are paths, or path prefixes. Sometimes, they are just a parameter to a command. edited by Glenn on 18/01/2016
18/01/2016 Topic: & sometimes appears in menu text Glenn	I stuck a bunch of & in one SyMenu to do accelerator keys. They sort of work. One command, though, made the & visible. It was in front of the word Analyze (and more) in a menu entry. A bunch of other & at the front didn't have that happen. Not sure what info you need to try to reproduce that. Windows switched the default from displaying accelerator keystrokes with _ all the time to only doing it when the menu was invoked by a keystroke. Not sure of the internal mechanism. However, SyMenu doesn't _ the keystrokes whether invoked with a click or the hotkey. Would be nice if it underlined them when invoked by the hotkey. Would be nice to have an option to turn on the underlines all the time.
19/01/2016 Topic: Multi-execution Glenn	OK, the manual has a section on Multi-execution: Multi Execution SyMenu allows more than one running instance from different execution paths. In that way you can use SyMenu from different portable drives at the same time. Overlay unit letter on task icon (see Advanced menu - Options - Startup tab), different fixed colors and different hot keys show up so SyMenu can help you manage a multi session SyMenu system. When SyMenu is executed from the same path of an already running instances, it doesn't execute but it makes that previous instance popup its menu. Is/could there be a way to allow multi-execution from the same path, getting multiple independent instances? No need for the "previous instance popup its menu" feature in that case. Why? Using environment variables, I've been able to customize one SyMenu installation on a read-only, shared, "program" Dropbox folder to work for different projects, with different data in different project-specific Dropbox folders, but the same menu/program needs. And my users will have no problem... they work on one project at a time. So I'm the only one with the problem: I can't keep multiple instances loaded to be quickly responsive to requests for help from different projects. I'm hoping that all the configuration boxes that supply names to the menu entries will be customizable via environment variable or SyMenu variables in some future release, as well as the "Tooltip text on taskbar icon", to go along with the other customizations I could do via environment variables. edited by Glenn on 19/01/2016 edited by Glenn on 19/01/2016
22/01/2016 Topic: Multi-execution Glenn	Yes, that would be a fine technique for my particular use case. -mi shouldn't directly affect the READONLY-ness, but would only be useful in the situation where all but at most one instance is READONLY.
22/01/2016 Topic: "." in a command parameter gets expanded Glenn	It occurred to me just a few moments ago, that this same technique might be appropriate to apply to #:\ ??? ^#:\ would have ^ removed, but be passed without expanding to the portable drive letter. I haven't played much with #:\ and do not know if replacement happens only with the 3-letter sequence, which is much more unlikely to occur than a single ".", and I don't know of any programs that take "#:\" as a command line parameter, so this one is likely less important. But if the replacement only depends on the #, then it could be critical to some applications.
22/01/2016 Topic: & sometimes appears in menu text Glenn	While I would like to be able to see the accelerator characters underlined, this report was mentioning that only in passing. What seemed to be a _bug_ rather than a missing feature, is the visibility of the & character itself in one entry I created. Your response seemed to focus on the underlining; I think the underlining can be controlled by a bit in the menu creation API somewhere, as once upon a time I created a program (now invoked by SyMenu) that always underlines its accelerator keys, but it is a long time since I've looked at the code that caused that to happen. I reply just to make sure you don't miss the issue of the & being visible.
22/01/2016 Topic: a couple ideas for the future Glenn	@sl23: as I outlined the idea, the "PROCESSOR_ARCHITECTURE" would be a configurable technique to turn on or off particular items. If your version of Windows includes WOW6432 (or whatever it is called), then programs of the opposite bitness could still be invoked, but when programs have both 32 and 64 bit versions, the idea, if implemented, could be configured to hide the one that doesn't match the native architecture, presumably the one that matches would be preferred. @Gianluca: I suspected that would be your reaction to the "multiple blocks of user entries" idea, but it was just enough different than full integration that I thought there might be a small possibility it might be more practical, and thus worth mentioning. So we will not discuss that further. The hide/show idea: Agreed that most users, and most SyItem menu entries would not need the options. And I'm not averse to command line options in general. However, most usages of the option would be tightly coupled to the SyItem, and needing to also change the command line options on a command by command basis would be awkward. Naming the commands in a way to minimize the number of command line options required to turn them on or off would also be awkward, or make the command line long. I see 2-3 "global values" being set, but a dozen or more SyItems wanting to be tweaked based on those global values... the same value turning some SyItems on, and others off. I note that you have, under Advanced options (for SyProgram only) the 4 boxes for particular environment variables. We had discussed the possibility of changing that to not be specific to those 4 variables, but to allow for a list of (name, value) pairs, allowing a user-specified variable to be set to a user-specified value to be passed to this particular program. We hadn't discussed how many, but some programs would benefit from 5-6 such variables. Often they can be set globally and other programs will ignore them. Mostly it would be when using the same program in multiple ways, that specific settings for particular variables would want to differ. We didn't discuss the UI for that... there isn't a lot of space right there, but maybe a multiple selection list box with a few items showing, scrollable, a button to delete the selected items, and a button to pop up a dialog box where a new name, value pair could be entered and added to the list. If the above happens, then maybe instead of just (name, value) it could be extended to (usage, name, value) where usage would be one of: →Set this variable to this value for this run of this program →Check this variable for this substring to determine the visibility of this command in the menu One could gain a bit of space, by combining the working directory into the list: →Use this value for the working directory [which would empty and disable the name box] →Use this value for the Home drive for folder [I really haven't figured out what this does, or why it is useful, but I'll trust that it is: I looked in the manual and found the section named "SyProgram - Advanced" and didn't find anything about "Home drive for folder", but somehow I missed how to copy items, which is embarrassing.] The Default values button could be moved up by "Enable Advanced params" checkbox (actually, is there any reason to have the "Enable advanced params" as a checkbox? if everything is blank, what gets enabled?), and would cause the default values to be explicitly filled in, or the overridden values to be removed? And actually, I'm not sure the Default values generated are particularly useful, either. Maybe they are, but they seem specific to the "current managed 4 variables" so without those, maybe this button could go away too. So Advanced could wind up as just add/delete buttons, and a list of name value pairs. The usages could be specified by special names, following by → whereas environment variable settings would be the environment variable name following by =, and hide/show by name ?, and then the value. For example: Working Directory → %WORKING DIRECTORY% Home Drive for folder → G: APPDATA=.\APPDATA PROCESSOR_ARCHITECTURE ? x86 SPECIAL-FOR-THIS-PROGRAM=#:\progconfig For more discrimination between types of values in the list, each type could be displayed in a different color to benefit non-color-blind people, but the plain text with special names and symbols would suffice for everyone. Well, maybe the above would work for SyProgram... do other SyItems need to be turn on/off? Well, all the others would have room for the options in their UI. SyProgram is the most crowded. The only "usage" that would be relevant to the others would be the hide/show. The only other ones I could imagine wanting to hide/show would be separator and container, but maybe my imagination is limited in this regard. So those two, or all the other items could grow the "Advanced" tab, with the same interface, although most of the options would be irrelevant, and maybe only the one usage type even enabled.
22/01/2016 Topic: a couple ideas for the future Glenn	Of course, the problem with UI design, is there are so many ways to do it. As soon as I sent the previous comment, I thought of a completely different alternative, not tied to restructuring the SyProgram Advanced options box (although those restructurings have merit on their own, perhaps). A SyProgram could have a 4th button in the row "Additional Params" "Gesture" "Advanced" called "Visibility". A name and substring could be entered in boxes there, and maybe even a "not" checkbox, to invert the sense of the match. If the variable called name has substring in its value, the item would be visible. If "not" is checked, it would be invisible. Not finding the substring would produce the opposite result. Then, the other items could all have the same "Visibility" options. The problem I see with basing the choice on the name, is that the name of a program is not very indicative of whether it has both 16 and 32 bit versions, or whether or not it is an advanced program only appropriate for some users, or whether it is a program that only works in some environments. (these are the three concepts that I see for which this hide/show feature would be useful).
22/01/2016 Topic: Multi-execution Glenn	In fact, if you wanted to restrict -mi to working only in the case where the directory can be detected as readonly, plus the case where READONLY exists, plus the case where READONLY.computername exists and the computer passing the -mi option matches READONLY.computername, all those restrictions would be fine by me, and would give assurance that the SyMenu data structures would not get messed up because of the -mi switch being present. Well, actually it wouldn't... because the 10 copies on _computername_ would all be non-readonly in the last case. Maybe -mi should imply READONLY, in spite of a matching READONLY.computername... that way, only one instance on the machine (the first started, without -mi) would be able to make edits. Those edits, of course, would not be seen by the other instances until they were restarted. Yes, this sounds simpler to implement, and has better guarantees than my first paragraph of a few moments ago. edited by Glenn on 22/01/2016
24/01/2016 Topic: & sometimes appears in menu text Glenn	The text below is pasted from the entry; the entry appears just like the pasted text, with the & visible. I've also noticed this entry scrolls when I hover over it with the mouse, which surprised me. Only one other entry does likewise, and it is equal in length (but without a &), and the two are the longest entries I have. Yet there is blank space to the right of the entry, and the whole entry is visible without scrolling. &Analyze .song, generate print.tsv
24/01/2016 Topic: Multi-execution Glenn	I can work with -mi whether or not it implies READONLY status.
24/01/2016 Topic: First user SyMenu 5.00.5866 Glenn	Thanks, indeed! Maybe I'm not first, or not even second (except to reply here). I am _extremely_ delighted to have -mi, and the new (almost) fully configurable menu structure!
24/01/2016 Topic: New version bug or bugs or misunderstandings Glenn	I've been playing with the new version for a bit since discovering it today, trying to use some of the features you added especially for me, but I'm having some very minor issues with a couple of them. -sm"CTRL+F2" doesn't work. But it does work without the quotation marks. Manual seems to indicate quotation marks are optional, but... better not use them at all! -cv"smproj=Text" shows up in a tooltip configured with %smproj%, but all in lower case. No capital T. (I actually have a different Text.) This is far more usable than a tooltip that says %smproj% But not exactly what I'd expected. I was surprised to still find "Configuration" and "Options" showing in a READONLY instance of SyMenu.
24/01/2016 Topic: a couple ideas for the future Glenn	Gianluca wrote: I'm trying to reply to your proposals even if they are not so clear for me (maybe it is a language misunderstanding in this case). Sure. We'll keep talking until we understand each other. Glenn wrote: the idea could be configured to hide the one that doesn't match the native architecture, presumably the one that matches would be preferred. Gianluca wrote: The only real utility of this feature is when you hide a x64 program in a x32 platform. In some cases it is necessary to execute x32 programs in the x64 platform. An example: I user my preferred image viewer, Irfanview, to scan images from my printer. My printer driver is compatible with x32 architecture, so if I want to scan something I have to execute Irfanview x32 even if my system is x64. Honestly I think that the usefulness of an implementation that hides or preferably offers certain programs according to the OS architecture is very low. In the cases that it is necessary to execute x32 on x64, one wouldn't hide it. In the cases that it is not necessary to execute x32 on x64, one could hide it. http://www.ugmfree.it/Forum/messages.aspx?TopicID=345 is not from me, but demonstrates a different technique for choosing a program based on architecture. That technique doesn't allow for choosing x32 on x64, and indicates I am not alone in thinking there is merit to the idea. Although I'm suggesting a much more general technique, that could easily be used to implement any combination of visibility for x32 or x64 programs on x32 or x64 architectures, whichever combinations want to be displayed (probably only a proper or improper subset of the ones that work, but particularly, avoiding ones that don't work, or aren't necessary for the project.) Gianluca wrote: Hide/show trough command line. You are right. A too long and complex command line is not viable, above all the items to switch on/off are many. Advanced parameter. Well your idea is great and really useful at a UI level too. I can create the dropdown with the most common environment variable, program variables and some special variables. The dropdown will help you to fill a multiline textbox where you can set and edit your variables by hand too. I wouldn't push the system to create a specific operator syntax for activate/deactivate the features, but every feature could be represented by a different variable followed by the value. It's a more generic and expandable method. For example if you want to hide an item you will have the variable SYMENU_SHOW SYMENU_SHOW=false In case you want to show or hide an element based on a condition you can use SYMENU_SHOW=%BIT%==x64 Using the %BIT% variable instead the PROCESSOR_ARCHITECTURE we remain consistent with the variables define for the tooltip and we can use the variable value in the right hand side of our equation. Naturally all the not SYMENU_ variables will be considered system variables or item variables. When you want to define the Working directory for example you can create it dynamically with the universal unit identifier (#:\) as you do today Working directory=#:\SyMenu\ProgramFiles or dynamically with a custom variable passed from the command line Working directory=%customPathFromCommandLine%ProgramFiles All this architecture represents a simple idea started from your thoughts but I'm not so sure to implement it because: 1) I'm not so sure that this viable, consistent and understandable 2) I'm not so sure it is really useful for a lot of users. Your scenario and the implementation you are requesting are very special. I want to use my time to meet the requirements of a many users. So we can continue to speak about this topic but I would like to see a lot of interested about it too otherwise our speculation will remain so. --- general response I hear you on spending time to meet requirements of many users. I do appreciate the "specials" that you've done for me, already. It seemed like a simple idea, similar to turning off the "Configuration" menu entry for READONLY users. But implementation ideas are more complex, so far. My first idea, reworking Advanced settings in SyProgram items, is a significant rework, but provides other benefits than visibility.... if they are deemed beneficial. One of the reasons I poked at the Advanced settings in SyProgram items, and the 4 environment variables there, was that those particular 4 don't seem all that useful to set, and others would be; and your manual even admits those 4 aren't even paid attention to by many programs that simply read the registry to get the "real" values, or use various Win32 APIs that read the registry on their behalf to get the "real" values. But there are a fair number of tools (especially programming tools, and especially ports of Unix/Linux programs) that do respond to particular environment variables of their own creation, so changing/expanding that feature seems of quite general utility to me. The other implementation idea, a new box beside the Advanced box, would be more easily applicable to other SyItem types, and is independent of enhancements to things in the Advanced box, but is also a fair bit of code to implement a small. Anything with a user interface takes a fair bit of code, unfortunately. Your idea of command line gets unwieldy, at least in the way you proposed it, by matching menu entry text (if I understood it correctly), because groups of things to enable/disable don't necessarily have common text... and in the case of architecture visibility...the 32-bit and 64-bit program menu entries, being mutually exclusive in visibility (for some scenarios) might want to have exactly the same menu text! It is much easier to find problems with implementation ideas, than to think them up!! But I'll do some more thinking, and maybe something with a much smaller implementation will occur to me. ---- specific responses I'd agree, I don't think you understand all the ideas I tried to describe, and I don't think I understand all of yours.... that certainly raises the question of "viable, consistent, and understandable" ! In your examples you show an expression syntax. I was attempting to avoid expression evaluation, and just use substring searching with success or failure of the search determining the visibility. So I think I'd simplify your 2nd example to: BIT ? x64 With the ? marking that as a "visibility" option, instead of = meaning a variable to set... examining the BIT variable and seeing if it contains x64 or not. So far in my use of SyMenu, I've only found reason to use one value for "Working directory": %WORKING DIRECTORY%. Anything where programs are stored is completely inappropriate for use as a "Working directory", which is where data files should be. Windows gets that backwards. I start SyMenu giving it a "working directory" of the directory where the data is.... and want to pass that to all the programs it starts, as well. Glenn wrote: actually, is there any reason to have the "Enable advanced params" as a checkbox? if everything is blank, what gets enabled? Gianluca wrote: Simply you can disable the advanced params without any need to empty all the fields and the system preserves your values for a future use. OK. I guess I couldn't see any value in filling all the fields, and then not using them But maybe for debugging or something, turning them off without losing them would be useful... Once could make a copy of the SyItem, and empty them out there, for debugging.... So I'm missing the use case for the disable button, but my only reason for questioning it was to save space in rearranging things, to be able to show more environment variable settings.
24/01/2016 Topic: weird positioning leads to usability issue Glenn	So my SyMenu appears in the lower right corner of the screen. Then a flyout (to the left) from a near-bottom entry in the menu does, it fact, reach the bottom of the screen. When I hover over the last entry, the tooltip for that item appears, also at the very bottom of the screen. That entry has a particularly long tooltip, and it gets positioned so that it ends at the right edge of the screen, and then extends across the main SyMenu menu, and across the flyout, and further to the left, even. So then it blinks on and off, because my cursor is sitting there hovering. If I click, I seem to mostly click on the tooltip, and the command doesn't execute. The tooltip uses a slightly smaller font, and there is a small slice of the flyout menu entry that doesn't get covered by the tooltip, and if I carefully click there, it works. I don't know whether there is a solution to this issue or not, or whether it is just the way Windows works. If, however, you are positioning things rather than Windows, then maybe there is a solution... never position a menu at the extreme bottom of the screen.
25/01/2016 Topic: a couple ideas for the future Glenn	This discussion, whether there are any changes to SyMenu that result or not, has been very profitable to me in understanding the disconnect there is between efficiency and Windows. While not really on-topic for discussion here, I wrote a diatribe about it at http://slashdot.org/firehose.pl?op=view&id=80569101. Some people may have simple projects and use only one file and one program at a time. When it gets more complex than that, Windows gets seriously in the way, and one of your comments (paraphrased) "but that is the Windows default for Start In" and one of mine "So far in my use of SyMenu, I've only found reason to use one value for "Working directory": %WORKING DIRECTORY%." finally made it click for me why Windows is so inefficient to use, which is the topic of the diatribe. And in my search for efficiency, and for a portable menu structure to help with using Dropbox and portable programs effectively, one of the things I found was SyMenu... and yet there are some thing about SyMenu, duly borrowed from "the Windows way of doing things", that I have to consistently work around. But now that I've found "Control" to copy SyItems, that is easier to work around, even if the defaults are too much like "the Windows way of doing things" Sadly, "the Windows way of doing things" has been ingrained into so many programs, that I doubt they will ever be cured. Yet, it would only take a few tweaks to most program to allow an efficient way of doing things to live side by side with "the Windows way". 1. Launching programs and shortcuts should respect the concept of a "current working directory" as more important than a "Start In" directory. But the way the presently get started by Windows, they only get a hint of "current working directory" if they are launched by clicking on an associated file: the path to that file is the "current working directory". If they get launched from Start menu or desktop shortcuts, they have no clue, and are given a "generic" Environment block and "global" access to the registry, neither of which informs them of the user context. 2. Multiple instances of programs should be common: one for each "current working directory", rather than one per user. 3. When using multiple desktops, the "current working directory" should be tightly bound to it, and passed along to programs, as part of the "current desktop environment", so that there can be one project per desktop. The key thing is in understanding that "projects" are the efficient form of organization, not "programs". No one ever created their paper filing system for their business by putting all their receipts from Home Depot in one place, and all their receipts from Lowe's in another: instead, the receipts were filed by "project" or "customer" for later reimbursement.
26/01/2016 Topic: & sometimes appears in menu text Glenn	Regarding the underlining of accelerator keys: There is a control panel item for this: Control Panel\All Control Panel Items\Ease of Access Center\Make the keyboard easier to use Make it easier to use keyboard shortcuts [X] Underline keyboard shortcuts and access keys While I had set that in my old computer, I hadn't got around to setting it in my newest one with Win10. When I set it, then SyMenu shows the underlines, so it is, apparently following the default Windows setting for that. However, even before I set it, one of my programs was showing the underlines, so I had apparently overridden the setting. Apparently that is done by making sure that ODS_NOACCEL is not set in the menu entries... somehow... I didn't quickly find it in my code.
29/01/2016 Topic: & sometimes appears in menu text Glenn	Glad you've homed in on the bug. I actually looked briefly for a way to turn off the scrolling, but didn't find one. Maybe that is not an exposed setting? Maybe my entry was right on the boundary of "long enough to need to scroll" although it was fully visible before the scrolling started... that boundary may be another bug.
29/01/2016 Topic: weird positioning leads to usability issue Glenn	Hmm. Now you've got me curious what happens when tooltips are as wide as the entire screen!