Currently there is significant feature gap for tab elements pertaining to customizable chat menus.
Among these:
1) flash is not implemented for tabs to indicate when a new message has been received in a new chat tab. Please implement flash for tabs.
2) Closable tabs are needed for customizable chat menus. Please give us the ability to indicate that a tab can be closed. This could pull from the linked pane's can-close option to indicate the tab can be closed.
3) Right click context menus for tabs need to be implemented. These could pull from the linked window's menu setting for the right click context menus.
4) Reorderable tabs by dragging. This should be a new option for tab elements.
The purpose for these three requests is simply to allow the creation of standard video game chat panels, where the user can right click on a tab and customize which channels feed out to each tab, create new tabs by clicking on a "+" tab (this can already be done), and to close old tabs by clicking on an "x" button.
All of these features are currently implemented in Dream Maker's tabset for the content panel. Please consider finally completing the feature set that has been missing these completely necessary things since 2005.
ID:2049960
 Mar 9 2016, 8:18 am
|
|||||||
| |||||||
|
Mar 9 2016, 8:21 am
|
|
Lummox JR
   |
For #2, there's a slight problem I foresee. Namely, I think a lot of games may have can-close on their panes already and this could potentially break a few interfaces that didn't expect to close tabs.
|
Also, I should mention that there are a series of feature gaps on this subject with the alternatives as well.
1) Using Browser elements: The inability to deny keyboard input/focus to a browser element makes using one as a standard part of the interface less than feasible. Further, lack of background transparency in DS makes this problematic for over-map tabs. 2) Using screen objects: The inability to detect the width/height of maptext makes it incredibly difficult to build dynamic tabsets using maptext. 3) Inability to specify per-object right-click context menu refusal at the appearance level makes any game that relies on verbs unable to specify any kind of a custom context menu. Basically, a combination of feature gaps in other, better ways of doing this one extremely common thing that almost every other online game does by necessity of design borderline impossible to do in a sensible manner. | |
For #2, there's a slight problem I foresee. Namely, I think a lot of games may have can-close on their panes already and this could potentially break a few interfaces that didn't expect to close tabs. To me, that's indicative of lack of forward thinking during the design of v3.5 and beyond. There is no purpose to having can-close marked true for a pane window. Perhaps a quick fix would be to make any game that was compiled with a version less than the one where this makes it in sets the can-close value of any panes to false on initialization. | |
Yeah, I think you're right. A version check would make good sense.
| |
Man, all of these features would have made NChat (AKA: "Lets see what 4.0 can do!") so much less hacky when it came to detecting new messages.
| |
+1!
| |
Definitely +1.
Especially, 1) Using Browser elements: The inability to deny keyboard input/focus to a browser element makes using one as a standard part of the interface less than feasible. Further, lack of background transparency in DS makes this problematic for over-map tabs. | |
Still waiting on flash for tabs! That's sorely needed.
| |