|
Gianluca Administrator Posts: 1274
12/12/2015
|
Hi.
I'm working on a new version to implement a great feature: the completely customizable menu.
When this version is released you'll be able to decide which elements to include in your menu and in which position. Naturally the current normal and compact menu will disappear because they are only two of the multiple configuration. I think this is the first breaking changes in all the SyMenu history.
Since this implementation is really complex I decided to release a public beta if someone wants to test it.
I'm not for the public beta versions, I think they are useless because people download them to use them and not to test them, but I could make a mistake so I'm ready to be disproved.
Don't use this version as your main one because it is really buggy and you can easily lose your configuration.
If you mess your menu and SyMenu doesn't load anymore or has some problems, you can reload the program with a particular command line argument (-msnormal) that reset your menu to the base one.
There are other main new features:
- The file flag READONLY can be ineffective for a certain PC if the file name is followed by a dot and the machine name. For example READONLY.Mercury file makes SyMenu runs in readonly mode for every machine except for the PC called Mercury;
- The contextual menus scrollable buttons are now bigger to simplify the use on touch screen devices.
Here is the download link. Let me know.
[updated]
2015.12.17 Second beta version
With this second version I solved various bugs besides implementing some minor features:
- There is a new option to show the contextual menu on start button mouse hover
- I fix a memory leak when thousands of elements are added
- The shortcuts to make the search bar appear and to change the current action modifier work only if the menu structure includes the corresponding element
[updated]
2015.12.23 Third beta version
Other bugs solved and some new features:
- The title element in the contextual menu can contain child elements, it's more similar to the old compact menu (R.I.P.)
- There is a new command line for user custom variables. The new flag is -cv (custom variable) followed from a key=value structure. The -cv flag could recur multiple times. Some examples here: -cvfoo1=text -cv%foo2%=text -cv"foo3=text" -cv"%foo foo 4%"=text -cv"%foo foo 5%=text text"
- I introduced a new element in contextual menu to directly go to SyMenu options
http://www.ugmfree.it/public/SyMenuBeta/SyMenu.4.14.5835.beta.zip
edited by Gianluca on 23/12/2015
|
|
|
link
|
|
Drakkn Posts: 22
13/12/2015
|
I can't download it from the link. It says the file is not found.
|
|
|
link
|
|
Drakkn Posts: 22
13/12/2015
|
Drakkn wrote:
I can't download it from the link. It says the file is not found.
Edit:
I see what happened. The link tries to be "http://www.ugmfree.it/Forum/www.ugmfree.it/public/SyMenuBeta/SyMenu.4.14.5824.beta.zip"
The link needs to be http://www.ugmfree.it/public/SyMenuBeta/SyMenu.4.14.5824.beta.zip
I grabbed it and will sure test it out!
|
|
|
link
|
|
Gianluca Administrator Posts: 1274
13/12/2015
|
Ok url fixed.
It's an interesting bug of the link function for this forum editor. If you use the hyperlink button instead of publish the link directly it convert your absolute url in a relative one to the root of the forum.
I have to report the bug to the jitbit guys 
|
|
|
link
|
|
VVV_Easy_Symenu Posts: 159
13/12/2015
|
The "Empty Trash" feature works in Spanish Traslation 
.
edited by VVV_Easy_Symenu on 13/12/2015
|
|
|
link
|
|
Ilias Posts: 6
13/12/2015
|
I really like the ability to change the menu structure.
I have i preexisted problem, sometime the sentence is so big that is being cut by the frame.
|
|
|
link
|
|
Gianluca Administrator Posts: 1274
14/12/2015
|
@VVV_Easy_Symenu
Great! I fixed the bug blindly because I've never been able to reproduce it.
@Ilias
I know, it's a problem for several languages but there is no solution (we are not in a web context where the text can flow). You should change the cutted sentences or use abbreviations
|
|
|
link
|
|
Glenn Posts: 99
15/12/2015
|
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.
|
|
|
link
|
|
Gianluca Administrator Posts: 1274
15/12/2015
|
Hi Glenn.
Which kind of incompatibility you've found starting from your existing configuration? Can you detail that more? It could be useful.
|
|
|
link
|
|
sl23 Posts: 285
15/12/2015
|
That problem with sentence cutoff also happens in the error message windows in sps builder.
|
|
|
link
|
|
Glenn Posts: 99
16/12/2015
|
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.
|
|
|
link
|
|
Glenn Posts: 99
16/12/2015
|
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!
|
|
|
link
|
|
Gianluca Administrator Posts: 1274
16/12/2015
|
Ok Gleen. It is enough to change my mind about the beta value.
Glenn wrote:
I just noted you spoke of a breaking change, and but didn't say how or where the break was [...]
If something is incompatible, though, you should mention what it is[...]
If it is just the "compact menu" feature going away[...]
The breaking change regards the menu structure and precisely the compact menu only. If you've already have a valid configuration, it'll be preserved entirely but if you chose a compact menu, it'll be replaced by the advanced one. This is the only breaking change but since you are using the advance menu, it doesn't affect you.
You are right I should be more accurate to describe it. Sorry it was my first time with a public beta
Glenn wrote:
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.
Ok we can change the feature name in "nearly fully configurable menu" if you prefer.
The menu structure concern the built-in elements so its correct place is inside the Options form.
The built-in elements and the user custom elements must remain separated by design because they are completely different elements. Think that the built-in elements have variable labels according with your current language, they are not subjected to the action modifiers, they could be filled on opening (think about the drive units in My Computer or the My Computer itself that changes the drive units according with the removable drives available at opening), they could contain an entire new world also (think about the search item and how it works), they could monitor the SyMenu status (think about the title bar with the feedback icons for the pinned, the readonly, and the moving status).
Glenn wrote:
What is truly the minimum menu structure required to operate SyMenu? I think it is "configuration" and "Exit".
According to my analysis the title is needed too, because it allows to move the menu, to pin it, and to monitor the read only status.
The second required element is the placeholder for user custom items.
So my vote goes to: title, configuration, user item placeholder, exit. Anyway the poll is open!
Glenn wrote:
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).
Well Glenn I've just created this new feature and it was a huge effort... we have time to improve it
Anyway I like the idea to rename the built-in element too and to supply a user description. It's in my TODO list now.
Glenn wrote:
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.
I think I will leave the current solution. Why don't you mention it? You can't drag away a mandatory build-in element but you can move it wherever you want. In my opinion it works properly and better than throwing an error during the saving.
Glenn wrote:
"Tools" seems be just a "SyContainer" with a fancy icon.
Yep. But since it is a different kind of animal than a SyContainer, I have to create it in a different mode and can't be mixed with user items.
Glenn wrote:
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...
Nice. I'll investigate for that. I not even know if it is possible with the components I'm using for SyMenu...
Glenn wrote:
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.
Consider it done!
Glenn wrote:
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.
Right! It's in the TODO list.
Glenn wrote:
You mentioned in another thread about having everything in the title bar.
It's gone now. The title bar, similarly to the Tools and My Computer items, could contain elements, but I preferred to avoid a title bar with this ability because it was really buggy. Maybe it will come back in future.
Glenn wrote:
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.[...]
Are you describing something else than SyMenu? Like RocketDock?
Well this would be a completely new direction to explore. For now I'll leave it.
Well don't trust too much this forum editor... sometimes it loses the messages while you are writing it. I hope the jitbit guys will improve it.
|
|
|
link
|
|
Glenn Posts: 99
16/12/2015
|
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.
|
|
|
link
|
|
Glenn Posts: 99
16/12/2015
|
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.
|
|
|
link
|
|
Glenn Posts: 99
16/12/2015
|
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
|
|
|
link
|
|
Glenn Posts: 99
16/12/2015
|
"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?
|
|
|
link
|
|
Glenn Posts: 99
16/12/2015
|
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...").
|
|
|
link
|
|
Gianluca Administrator Posts: 1274
16/12/2015
|
I fully understand your point of view but changing a program so vast like SyMenu at its roots means rewrite almost entirely the code base.
Creating a new super class and inheriting the built-in items and the user items from it is not like creating a new child class. It means that every element, graphical and not, must be rewritten to deal with the super class and not with two different classes.
I can evaluate this change in at least 40 man-days work and for this reason it's outside my possibilities.
|
|
|
link
|
|
Gianluca Administrator Posts: 1274
16/12/2015
|
Glenn wrote:
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?
Yes sure, in future we can have more than one element for passive items. Tools is one of them. For now you have one only because its name is not customizable. The not passive elements will be available in one copy only.
Glenn wrote:
Not sure if the title-bar bugginess extends to the icon bar idea
Me neither. We'll see.
Glenn wrote:
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!
Well the problem is not in showing the icons only, it is in the vertical separator. I'll study that.
Glenn wrote:
Not sure [...] if you just have a minimum width coded. If it disappeared, it would be even more grid-like.
It's coded but honestly I don't remember why I'll do some experiment about.
Glenn wrote:
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?
Maybe it is a bug. An item without a name shows a full tooltip. The source for tooltip is decided by you in the general options form.
|
|
|
link
|