23/11/2015
Topic:
READONLY and recent updates
Glenn
|
A bunch of files... at least a dozen. I'd deleted most of the ~Update folders just following instructions before I thought to look in maybe the last one... I was surprised there was more than one marker file to indicate an Update had happened, but then I didn't pay a lot of attention, and then I deleted it. I'll see if I can recreate another and do better reporting. |
15/12/2015
Topic:
Request - search improvements / menu contents
Glenn
|
I'll guess that what deltaone meant is that he wants to see the SyMenu once, so that a command can be chosen, not known ahead of time, but that SyMenu would then exit after a single menu selection is made.
This is useful when you just want to run one thing, but you don't know ahead of time which thing. So everything is configured in the SyMenu. When you need something from that flash drive, you insert it, Click on "SyMenu Once" (a shortcut that passes a command line option, say --once) and causes SyMenu to exit after one menu item is selected.
If, when you plug in the flash drive, you know you need more than one thing, you click the regular SyMenu shortcut, and SyMenu stays around until you explicitly exit. |
15/12/2015
Topic:
The fully customizable menu: beta version
Glenn
|
I'll soon find out if it will start from an existing configuration... but it might be nice to warn people that want to try it. I know you said it is incompatible... but not how or where incompatible 
Thanks for READONLY.Mercury Good to see it coming. |
16/12/2015
Topic:
The fully customizable menu: beta version
Glenn
|
I should know better. I wrote a huge message here, with lots of feedback, and when I submitted it, it got an error, and it is all gone. I should always write more than one line of text somewhere besides in a web form... I should always write more than one line of text somewhere besides in a web form... I should always write more than one line of text somewhere besides in a web form... I should always write more than one line of text somewhere besides in a web form... I should always write more than one line of text somewhere besides in a web form... penance over, I'll try to recreate the feedback, and paste it in the web form. |
16/12/2015
Topic:
The fully customizable menu: beta version
Glenn
|
The beta version took the existing configuration fine. I just noted you spoke of a breaking change, and but didn't say how or where the break was, so it wasn't clear whether or not existing configurations would work or not.
If something is incompatible, though, you should mention what it is, so people can deal with it appropriately. If it is just the "compact menu" feature going away, it seems that you could have a "standard" configuration for each of the "regular" and "compact" menus, and maybe another for "minimum" and maybe another for "maximum" and start with corresponding configurations, based on the old choice between "compact" or not.
I was surprised not to find the new menu structure feature in the main configuration panel. And, I'm surprised that the "User items placeholder" exists... that is the antithesis of "fully configurable menu", because it artificially requires that there be no mixing of user items and built-in menu items.
What is truly the minimum menu structure required to operate SyMenu? I think it is "configuration" and "Exit". Everything else should be optional, and even those should be able to be renamed by the user, and described by the user (like all the SyItems have editable name and description fields).
So if a user-modified menu structure doesn't contain the minimum entries somewhere, either they should get an error at save time, or those minimum entries should be added to the bottom of the top-level menu structure. I prefer the former, but either would be acceptable.
Every other built-in menu item should be configurable just like other SyItems, and separators. The Item Manager menu item should either be split in 2 or 3 (Item manager, add SyItem (currently in Item Manager), add built-in item (currently in the Available elements panel). Or those could become flyout menus in Item Manager (but that would be more cumbersome to use).
"Tools" seems be just a "SyContainer" with a fancy icon. I don't mind, but maybe all you need to ship is the icon.
Would be nice to have a vertical separator also, for multi-column menus. I've mentioned before regarding large scrolling menus (folder lists, installed programs lists) that it would be nice if they were split in columns like the original Windows 95 Start menu... you'd have to figure the screen height and item height to know where to put the column separators. But for user menus, the user would specify, so you wouldn't have to know.
It would be nice if simply hovering over the Start Menu button displayed the start menu, rather than requiring a click. Maybe that should be optional.
It would be nice if, when in READONLY mode, the built-in items that cannot be performed would not be shown in the menus, even if they are configured. That would avoid confusing the users that can't use them anyway.
You mentioned in another thread about having everything in the title bar. I don't see where/how to do that, but maybe that isn't in the public Beta? From other things icons that encroached the title bar, and from your vague comment, it sounds interesting, though. Is the title bar in the "minimum set"? Maybe it shouldn't be. But maybe an icon bar could be an option, so one could have more than one of them? Title bar + icon bar might be nice, sometimes. Since I haven't seen it, and haven't figured out how to experiment with it, here are some random thoughts that may not be relevant...
It would be nice if an icon on the icon bar could be the icon for a container, and hovering would produce a flyout menu. Item icons would produce the description tool tip when hovered. Note, hovering is not something that can be done on a touch screen. Not sure what the replacement is, if any.
If one does get their useful menu structure down to only an icon bar, could it have an option to be either vertical or horizontal? Or if all items in the top level menu structure have no names, just icons and descriptions, does the width shrink enough so that it looks like a vertical icon bar?
If one does get their useful menu structure down to only an icon bar, could it substitute for the floating Start Menu button?
Is the above an adequate response to make a public Beta worthwhile? I promise I didn't install it in production! |
16/12/2015
Topic:
The fully customizable menu: beta version
Glenn
|
My next reply (pasted) also caused the error, which I didn't capture or report last time. If there is a place to report them, I've saved both the full error message, and my full text that cause this second error. The next trick will be to figure out what part of the reply caused the error. So my reply will be numerous... I will "divide and conquer" and submit parts of the reply in separate messages in hopes of determining what causes the error. First time around I lost it, and the recreated text passed the checks. |
16/12/2015
Topic:
The fully customizable menu: beta version
Glenn
|
Actually, I was using the compact menu. I noticed the Beta showed extra stuff, but with all the features to rearrange it, no big deal.
"nearly fully configurable menu". Hmm. This is the biggest item, and probably also the hardest to implement, but then eliminating that word "nearly" would be very, very nice. Let me attempt to persuade you...
"must remain separated by design because they are completely different elements". Well, _all_ the elements are completely different. A menu full of the same element would not be interesting
The differences you describe are mostly implementation sorts of differences. The user interface should drive the implementation, rather than the implementation limiting the interface, in general. Obviously that cannot always be achieved, but this sort of thing would seem to lend itself to one of two solutions I can think of, or maybe others. I'll list the ones I thought of in the next two paragraphs for inspiration, but any solution that meets the goal of a more flexible menu structure is acceptable, of course. Then I comment on the specific "reasons" you gave for them being different.
1. No doubt the built-in elements do not derive from the same "SyItem" class. So, make a super class MenuItem that is union of SyItem and BuiltIn Then they can be treated the same, for menu structure manipulation. For editing and implementation, they are treated different, but the super class tells you which subclass it is.
2. So if the differences are so extreme that you must have special handling for the items, and know exactly where they are, can you not just build a table of the active built-ins (the ones that are in the menu structure) on the side, and then have a special "SyBuiltIn" that acts like a normal user menu entry, and points to the right table entry? Your current Beta implementation must almost work that way anyway... except that you didn't call the menu structure items SyBuiltIn
"variable labels".... sure... you agreed later they could be renamed, but the initial values do come from translation tables. So that is different than SyItems, that do not have initial values for names/ descriptions. But once initialized, they both look like menu items.
"not subject to action modifiers".... sure... but that would be true whether they are at the top, bottom, or middle.
"could be filled on opening".... again, true whether they are at the top, bottom, or middle.
"contain an entire new world".... search seems to cause a flyout box to appear with a search interface. I don't see why that couldn't happen between two user items.
"They could monitor the SyMenu status".... OK, title bar can stay on top (but really, it is the pinning and moving of the menu that convinces me of this, rather than the status monitoring, per the next item)
"title is needed ... to move the menu, to pin it".... yep, so it should be on top, for those actions.
"placeholder"... well, we can probably agree that we do need user items, or SyMenu wouldn't be too useful. But I fail to see why any but title need to be separated from built-in items for positioning them anywhere on the menu.
I would like to put My Computer, with its local drive expansions, in a SyContainer called "Explore" together with SyItems that have specific directory lists from the flash drive and/or Dropbox folder, because they do similar things. I would like to put Exit in a SyContainer called "Lesser used stuff" (well, not exactly that) along with lesser used SyItems like documentation links, rather than it being so prominent... that gets used once per session, maximum, rather than the potentially many times other commands get used. |
16/12/2015
Topic:
The fully customizable menu: beta version
Glenn
|
On we go to smaller topics...
"rename and user description" So in the "unified" Menu structure, these would be the only things that could be edited in the main Configuration Panel for BuiltIn items.
Minimum entries ... "current solution"... The current solution of not being able to delete the minimum entries is fine, actually, I just didn't figure out that that solution was in place! After all, I only spent a few hours with it, whereas you have spent days/weeks creating it. Of course, I'll quibble that I can't currently move Exit into a SyContainer |
16/12/2015
Topic:
The fully customizable menu: beta version
Glenn
|
"Tools"... why is it different? Because the contents and positioning are different... if the items were unified, then Tools would just be a SyContainer... Why can there only be one Tools container? Shouldn't it be more like Separator, that putting it in the active menu still leaves it available? For that matter, why can there only be one of most of the built-ins?
"vertical separator"... I know it is in basic Windows popup menu features, but not whether it is included in whatever abstractions you are using. I find them very nice for grouping option choices.
"hovering over Start Menu", "not showing READONLY items", Nothing more to say here!
Title bar... you can put my thoughts on the shelf with the buggy feature
icon bar... never heard of RocketDock... I use something called FreeLaunchBar, which has that sort of hover on an icon, get a menu sort of feature. It is less capable than SyMenu, being all static, and tied to a particular machine, but that aspect of the interface is nice. Not sure if the title-bar bugginess extends to the icon bar idea, the icon bar aspect might have been the source of the bugginess, or might not have.
One thing I'll mention again, but really only in passing... if the menu names are blank, and all there is is an icon, and size shrank, you almost get a vertical icon bar. It is about 3 times wider than the left-aligned icon, though. Together with vertical separators, you could make a little icon grid!
Not sure if the 3 times wider part is a limitation of the Windows menus, or of your tools, or if you just have a minimum width coded. If it disappeared, it would be even more grid-like.
After taking my names away from my menu items, all of which were pointers to documentation files, I noted that the tooltip showed the path to the file, rather than the description, and rather than both path and description in two lines. Why have a description, if it doesn't show? |
16/12/2015
Topic:
The fully customizable menu: beta version
Glenn
|
OK, the bug is triggered when I used the less-than Separator greater-than (but with the symbols) name of your menu line in the text. No doubt it is the less-than and greater-than symbols that triggered the error. In fact, now that I know what it is, the error message was sort of descriptive, and included the text it didn't like, but I didn't realize that at first. Of course, I have to convert those symbols in pasting in the error message also:
A potentially dangerous Request.Form value was detected from the client (ctl00$AspNetForumContentPlaceHolder$tbMsg="...more like less-than Separator greater-than, that pu..."). |
16/12/2015
Topic:
The fully customizable menu: beta version
Glenn
|
OK, you know the code, I don't. You convince me that implementation alternative 1 is too hard to be practical.
Implementation alternative 2 is an "end run" around the super class. Instead of a super class, there is a new SyBuiltIn subclass of SyItem, and when it gets clicked, it forwards that click to the "hidden" actual builtin, which uses its current class. On the surface, this sounds easy, but I realize there may be limitations that are not obvious.
Your new beta, and even the old regular and compact modes of operation, prove that the builtins, except maybe for title, are not tied to a particular position in the menu structure, but can be configured at any point in the menu structure. So this gives me a small hope that "SyBuiltIn" might be significantly easier, implementation-wise.
Your new features will still be useful and appreciated, just not quite as useful as they potentially could be. Perhaps an implementation that wouldn't be nearly as complex as the super class, but rather somewhat practical, will come to you in a dream: now that your conscious thought has explored the idea enough to reject it, your subconscious may develop a solution Well, I can hope |
16/12/2015
Topic:
The fully customizable menu: beta version
Glenn
|
I may have seen the "information on tooltip" option at some point, but I didn't have "Description checked" That is the cure! |
16/12/2015
Topic:
The fully customizable menu: beta version
Glenn
|
Not sure your timezone, but my timeZZZZZZZZZZZZZone says I must go to bed... that's when the subconscious is most active... second most is in the shower, eh? |
18/12/2015
Topic:
The fully customizable menu: beta version
Glenn
|
I like the new hover option. |
22/12/2015
Topic:
The fully customizable menu: beta version
Glenn
|
@sl23: I think you can make your own compact menu, but I agree it would be a convenience if there were a button that created "just like old compact menu" and another "just like old complete menu", and then a "minimum" button. That was part of what I said in my post.
I like your idea of a direct menu to Configuration / Advanced / Options. Or maybe the possibility of going directly to _any_ of the sub tabs in the Options menu. People discover over time the areas of SyMenu configuration they use the most, and getting there fast would be good. That would put more entries in the what is "available", but wouldn't clutter the overall menus except when people configure their menu to include such items. |
23/12/2015
Topic:
The fully customizable menu: beta version
Glenn
|
Gianluca wrote:
For people like Glenn that manage a lot of SyMenu instances I'll implement an import and export feature which allows you to choose the options you want to export and the ones you want to import. In that way you can reproduce all or part of the settings of your master SyMenu. But I don't know when I can do that. For now you can manually operate at file level modifing the SyMenuConfig.zip file.
We should discuss this at length before you start implementing such an import/export feature. Copy and tweak gets quite far. Command line variables would get quite a bit further, enabling to pass a few parameters to internal commends. Selecting (depending on how, of course) a large subset of options to Import/export sounds like a cumbersome way to copy and tweak... probably would take lots of clicks, probably would take lots of different dialogs where different types of things could be chosen. The only thing I can't figure out how to do with "copy and tweak" and "variables", is to enable the visibility of a command. So I'll extend my notion of where variables could be useful to an option in each SyItem to specify a variable to check to decide whether it should be displayed or not Similar to not displaying Configuration menu item if SyMenu is READONLY, but more general. Well, that is the start of the discussion. It can be continued here, in a different thread, or privately, as you choose. |
23/12/2015
Topic:
The fully customizable menu: beta version
Glenn
|
Gianluca wrote:
A third beta is available.
So, in setting up some command line parameters, I noticed that in the manual section titled "Command line" that the modifier "CRTL" is mentioned. I didn't test if it worked I just spelled it "CTRL" and that worked
In the beta 3 comments at the top of this thread, it gives -cv examples:
Some examples here: -cvfoo1=text -cv%foo2%=text -cv"foo3=text" -cv"%foo foo 4%"=text -cv"%foo foo 5%=text text"
It is clear that the "" have to be around all the stuff with spaces, but don't have to include spaces. That I think I understand.
It is _not_ clear whether variables can be named with % as part of the name. I'm not sure how it could be referenced, or else I don't understand the syntax for referencing such names. I have experimentally determined that -cv"%foo%=bar" does not result in a reference to "%foo%" being expanded. So the manual needs to be more verbose to explain the usefulness of the example, or else the example may be in error?
%BIT% gets expanded in tooltips, with the "%BIT%" gets replaced with "x64-based PC". However, -cv"smhk=C+F2" gets expanded in tooltips, with the % left behind! That is "%smhk%" gets replaced with "%c+f2%". This was surprising... both the % staying around, and the value being lowercase! |
23/12/2015
Topic:
The fully customizable menu: beta version
Glenn
|
Gianluca wrote:
A third beta is available.
Maybe your examples were intended to show the use of Windows environment variable values as names for SyMenu variables? Since I started SyMenu from a batch file, that is effectively what I was getting, because Windows does interpret % syntax inside ". When I used -cv"%%foo%%=bar" then the expansion happened, without % being left behind, as they were with -cvfoo=bar.
Should I infer from this that SyMenu variables do not need enclosing % to be expanded? Is that intentional? It might raise havoc with some command lines if text on the command line happened to match a SyMenu variable name (and yes, even if command lines are not presently expanded, I hope they can be someday). |
16/01/2016
Topic:
a couple ideas for the future
Glenn
|
Pondering some updates to my SyMenu installations today, and thinking about the "fully customizable menu" limitations regarding treating all the user entries as a single block, the following ideas came to mind. They are somewhat redundant in nature, in that the overall goal is to allow shared chunks of menu structure. The first has appeal, if it can be implemented, because it might also be a way to intermix blocks of "SyMenu defined" and blocks of "user defined" menu structures, which is not presently possible.
1. It would be nice if there could be multiple blocks of "user defined" menu entries. One block would come from the current directory structure, and not be deletable. Other blocks would be defined by pointing at a separate SyMenu directory structure, and borrowing, or importing, its user defined menu structure. These imported menu structures would always be read-only to this SyMenu instance, but could be added to or deleted from the main menu list as a block. Perhaps due to the different classes, all the "user defined" blocks would have to be contiguous, but perhaps not (which would be more flexible). Perhaps the "import" entry would be new type of SyItem, instead of an additional block in the "SyMenu defined" list.
The goal here would be to have pieces of menu that could be maintained separately, but used together, preferably without adding an extra level of menu nesting, just additional entries obtained from the other SyMenu directory structure.
2. The other idea is an outgrowth of one I suggested recently, which I think is on your todo list... that entries that require Read/Write access simply vanish from the menu structure when the instance discovers it should be READONLY (either with the file flag, or the read-only file system).
This variation would be menu entries that are visible or invisible based on the existence of an environmental or SyMenu variable with a specific substring found in its value at SyMenu initialization time. The default would be for entries to be visible; but the existence of a particular substring in a specified variable would make it invisible, or the default could be for entries to be invisible, but the existence of a particular substring in a specified variable would make it visible. Either way could work. It could even be required to be a SyMenu variable with a specific name, if that simplifies the configuration or implementation.
The value of the variable then would simply be a set of delimiters and substrings, such as ~abc~def~ where the check would be for either ~abc~ or ~def~. Or it could just be a list of characters, where a single character suffices to specify the visibility of the menu entry. Short strings seems easier to keep track of, the "substring existence" check would allow users to choose either of these techniques, or possibly invent other clever schemes. One advantage of allowing the menu creator to specify both variable and substring for a command is that the variable could be something like USERNAME for commands that belong to a single user... if USERNAME is unique enough for the set of users involved.
The goal here would be to have a complete menu structure maintainable as one piece, but eliminate certain menu entries for certain users that don't need them, without having to maintain multiple, nearly-identical menu structures with just one or a few extra commands in some of them.
edited by Glenn on 16/01/2016 |
17/01/2016
Topic:
a couple ideas for the future
Glenn
|
Another use for the "vanishing" menu entries would be to deal with 32-bit/64-bit differences. I'm aware http://www.ugmfree.it/Forum/messages.aspx?TopicID=345, but it would be possible to simply define two menu entries, both with "PROCESSOR_ARCHITECTURE" as the variable, one with "x86" and one with "AMD64" as the substring, and only the appropriate one would appear. |