I know this idea has never been given a lot of serious thought. Tom used to say it was definitely something that could be done. Lum's said it's something he's happy to do. I have been brewing over the complications of such an idea, and have cooked up a nice little syntax for working with such an idea. Yeah, I know we don't like statpanels, but if they were more flexible, they wouldn't be so bad. One of the major issues with flexibility though, is just the fact that we're limited to one. People could actually easily design more intuitive UIs without having to cook up their own HUD-based UI solution --which is increasingly possible, but still, options are good, arbitrary limitations aren't.
Anyway, here's my mixtape:
the name of the info control to send statpanel()/stat() output to, or null/unsupplied to use the default info control.
Returns 1 if the player is looking at a panel in the supplied info element, and 0 if not. Info controls that are disabled or invisible will always return 0.
The control setting determines which info panel the verb will be displayed in.
The popup_control setting determines where verbs can be shown in a popup menu. This would allow different panels to have entirely different right click context menus depending on where the object was shown. The default of null means that this verb will appear everywhere. A single control can be specified by using the element's id: "default.map", for verbs that should only show up in the context menu on the map. Multiple controls can be supplied separated by a semicolon or an ampersand: "default.map&default.info&default.grid1"
client.statpanel should only refer to the default info panel's current statpanel.
Because of how infopanel() returns 0 or 1, the server needs to know which panels a client is focusing on a panel. the statpanels variable should be formatted in an associative list format:
"id" = "panel"
where id is the id of the info control, and "panel" is the name of the current tab that is selected in the panel.
Disabled and invisible info controls should be removed from this list as they change states.
With the above proposed changes, the default action of client.Stat() needs to call infopanel() with no argument by default to reset the currently focused infopanel to the default panel.
Info controls without tabs should be available to allow developers the ability to design their own containers for them. Such controls would internally ignore calls to statpanel(). As it contains only a single "page" of data, all output to an info control that does not show tabs would be sent to the same page. setting show-tabs to false turns an info control into one of these single-page controls.
The show-default-verbs parameter determines whether or not an info panel shows verbs with the popup_control setting as null or "". This allows an info control's popout menu for an atom to require that any verbs shown in this panel are specifically targeted at that control before they will appear.
Since grid controls are more or less intended to be the replacement for info controls (Which didn't really work), these changes would require minor changes to grid controls for them to keep parity. atoms should be able to show their suffix in grids, hence the property, and they should also inherit the show-default-verbs command that the info panel just obtained so that they can treat popout context menus in a similar fashion to grids.
Again, since we're allowing verbs more flexibility for their popout menus, they need the same property of the other two element types that permit verb popout menus.
Jun 2, 12:43 am (Edited on Jun 2, 12:49 am)