Implementation of Server Info GUI

[slotthhy]

It seems that users keeping up with the #core-dev channel are excited for this possible upcoming feature.

The API currently consists of two public methods. Dalamud handles everything else:

/// <summary>
/// Sets the given text on a text node in the Server Info in-game UI element. If a node does not
/// exist with the given ID, it will be created. If a node does exist with the given ID, its text
/// will be updated. Node IDs must be greater than 1000 in order to prevent collision with game IDs.
/// </summary>
/// <param name="nodeId">The unique node ID for this text element.</param>
/// <param name="text">The text to display.</param>
public void SetText(uint nodeId, string text)

/// <summary>
/// Removes the node with the given unique ID from the Server Info in-game UI element.
/// </summary>
/// <param name="nodeId">The unique node ID of the node to remove.</param>
public void RemoveText(uint nodeId)

When designing this, I wanted it to be as transparent as possible. Plugins should be able to add information whenever they want, and as many elements as they want. For example, a plugin like Simple Tweaks may have multiple tweaks that each add information to this location. Dalamud controls the order of the elements by calculating the size of the game's contents of the server info element, and then it begins drawing leftwards from there. The gap between elements is also configurable.

However, there is still the problem of element ordering. Currently, it is first-come-first serve. If Plugin A calls SetText before Plugin B, Plugin B will be drawn second, that is, to the left of Plugin A. This means not only is order not configurable, order is indeterminate. If a plugin is reinstalled, its position will change, provided it disposes of its text element properly (via RemoveText).

Proposed solution:

• Upon adding a new text element via SetText, Dalamud will sort the list of elements by their node ID. This will become the draw order. Lower numbers will be drawn first.
• A plugin using this feature should provide the plugin user a method of configuring the Node ID from within the plugin.
• This solves the draw order issue and prevents Dalamud from having to implement a complex ordering menu along with the associated configuration settings.

Possible issues:

• Developers are unreliable, and may forget to add a method of configuring the node ID to their plugin, or outright ignore it.
• Users may find the per-plugin "node ID" having an effect on other plugins confusing.
• Node IDs are restricted to values above 1000, to prevent collisions with in-game UI element node IDs. However, allowing users to select "any number" above 1000 is not necessarily user friendly.
• If Node IDs begin at 1000, it is possible that multiple plugin developers will choose 1000 as the starting node ID for users to configure. Since there is no further "verification" on node IDs, one plugin can change another plugin's text if IDs collided.

I am not opposed to major rewrites here. It is not a complex class. You can view the current implementation here.. Please let me know what you think.

[rlynch-ironnet]

numerical ID shouldn't matter. let dalamud just increment a number internally. throw together something simple like /xlhud that lets you order them as the user desires.

[slotthhy]

Numerical ID was just a method of keeping track of a specific element. It could be something like ImGui, where you go to add text and it's something like SetText(string id, string text). There needs to be some way for a plugin to modify the text in the element that they already put up there.

[goaaats]

I agree, this should be handled completely inside Dalamud, and maybe with some simple GUI to reorder.

[Limiana]

It would seem that "having to implement a complex ordering menu along with the associated configuration settings" is almost unavoidable if you want to provide user with a convenient interface to configure it.
Maybe it could be made somewhat less complex. For example you could just have sortable list of plugins that create the node which an user can reorder, should be simple enough. And if a plugin developer wants to use multiple slots, ordering them within their plugin is on them.
SetText(IDalamudPlugin plugin, string text, int internalOrder = 0)
Also spacing between elements should 100% be configurable, perhaps even allow for an user-defined separator?

[lokinmodar]

The idea is really neat. I think it should allow for:

• reordering
• element visibility toggling (to avoid bans if streaming and so on)
• space-between customization
• spacer customization

[slotthhy]

For these features:

• Reordering is what this main discussion is about. Hopefully I can implement something that works well.
• Element visibility will be left up to the plugins. Once you turn a feature off that uses this element, it should disappear from the UI.
• Please elaborate. It would be somewhat difficult to try to change the contents of the space between two elements. It is not a "blank element", it is actually empty space.
• Spacer customization is implemented. You can keep the space between them very small, or make it large.

[lokinmodar]

the space-between is the distance between the new elements. Spacer would be an element like | or an icon

[lokinmodar]

I think the order should be handled by Dalamud if possible. I agree with the fact that if the plugins devs hardcode their node IDs it would cause issues if more than one is uses the same id. In this case the first-come-first-serve saves the headache of having to deal with this

[philpax]

I like the idea, but I don't think it should be in Dalamud. This isn't core functionality for interfacing with the game; this is an additional layer that's been built on top, and imo Dalamud should try to avoid that as much as possible (I know that ship has already sailed, but we should close the harbour. Does that metaphor even make sense?)

Do you think it'd be possible to use a plugin + IPC for this? The main problem I see is ensuring that users have the dependency when they're using a plugin that supports it, but the failure case should be that nothing happens (plugin could opt to notify the user if they want).

By analogy to other software: Linux window managers don't build their status bar in, they use another application that can be customised and replaced as the user prefers.

Just my 2c, would be interested in hearing arguments otherwise.

[lokinmodar]

Maybe incorporate the entry points for this to GameGui and let the plugin devs use them as they see fit...