It appears that each project has one and only one menu structure.
Is there a way to alter that menu structure depending on some parameter (i.e. which window is active, which user is active, etc.)?
Also, related but separate, is there any security that can be attached to menu items?
Thanks.
Security can easily be added to menu items with Jython.
The menu structure is static by design (but probably not for good reason). A more dynamic menu is a good feature request. Unfortunately, from what I’ve seen, very few users actually use the menu.
Perhaps if they were more useful…
Your experience describes my use - I’ve never used the menus, and I won’t for this project, but not because I don’t want to, simply because they aren’t very powerful.
I imagine that if the menu could be configured per screen, and if menu items could be enabled/disabled using standard security methods, folks would use them.
I also question the somewhat circular implication that a weak feature is not worth improving, since people don’t use it (because it is so weak).
Whoa whoa whoa. First of all, I see lots of users using the menu.
Second, the menu feature is powerful, useful, and certainly not ‘weak’. I think your complaint is that they aren’t very user-friendly (you have to write scripts to handle each menu item). A static menu is quite useful for the majority of the implementations that we see.
I do agree that a dynamic menuing system would be neat, but thats going to make them even more complex. Your suggestion of defining a menu ‘per window’ isn’t very realistic - you can have (and typically do) multiple windows open at a time - which menu is displayed? Furthermore, for the vast majority of apps that do want a static menu (for navigation), defining a menu per window would be a royal pain.
So, that said, we are open to suggestions about the menuing system. Certainly some built-in security and Jython script builds (ala the event configuration) would be nice.
Can you think of a user-friendly way to make them dynamic? Maybe each menu item could have a “Only display/enable if [these roles are present] / [these windows are open] / [a client tag has this value]” option…
What if each window had the possibility of defining menus, and then those were simply integrated in to the menu bar and removed from it based on whether or not the window had focus?
I think I was getting specific and painting a narrow picture. I should have said really use instead of actually use, the menu to its existing capability - meaning script with libraries, etc. You can get a pretty good range of flexibility there. And BTW they are powerful - you can do pretty much anything with Jython script.
Doing it in code like a generated right menu tree would be powerful, but probably of limited use to most users.
Carl - I think your suggestion would do it. As long as we’re on the topic, I think it’s a possible feature set to open up more options (like a browser with shortcut bars or “start” style menu or whatever)
IMO a dynamic menu structure applied on a per window basis would be pretty knarly for the user to follow with navigation (plus I’d anticipate a lot of projects to use a “frame” style navigation with popups).
On the second thought, what about making the menu a special form of client SQLTags? It’d have properties that we described: script, display name, security, enabled, etc that could be static or bound. It’d probably need a custom editor.
I like colby’s idea about letting windows define their own windows that would get put between the ‘global’ top-level menu items and the Windows / Help menus. The only problem I see is that it doesn’t include hiding/disabling based on permissions, and what if a large set of windows needed the same menus, there would be a lot of duplication…
That idea sounds workable to me. However, I would expect that only 1 menu item change based on the selected window instead of adding an item for each open window.
Good thoughts. BTW, I didn’t mean to raise such a ruckus, but I guess a good ruckus is ok now and again.
I am indeed looking from my very limited perspective. We envision that our projects will be similar to the dairy demo, in that there will will be multiple screens open, but one will be what I consider the “main” screen. For instance, there will be a header, maybe a separate navigation screen, maybe popup screens, but most of the real estate will be occupied by this “main” window, showing the principal data and graphics on the current topic. That window would always be swapped with another, so there is only one “main” window open at a time. That would be the screen that I’d tie my menu to, if I could.
This vision takes care of the problem where several windows add duplicate menu items.
Again, I recognize that this comes from a limited perspective and need, so of course you guys need to decide what make sense for you to do.
For now, we’ll probably do something like Nathan’s post re “frame” style navigation but will be interested to see where this all goes in future releases.