These are my ideas for the functionality of Evennia's webclient in the (possibly distant) future. It assumes the webclient options have been implemented as per [#1172](https://github.com/evennia/evennia/pull/1172).
![Mockup 1][webclient_mockup_1]
The idea of the GUI is based around *panes* (a "window" feels like something that pops open). These are areas of the window of the type you would see from a javascript library like [Split.js](https://nathancahill.github.io/Split.js/). Each pane has a separator with a handle for resizing it.
Each pane has an icon for opening a dropdown menu (see next mockup image).
Above image could show the default setup; mimicking the traditional telnet mud client setup. There should be at least one input pane (but you could add multiple). The Input pane has the icon for launching the main webclient options window. *Alternatively the options icon could hover transparently in the upper left, "above" all panes*.
The main webclient options window should have an option for hiding all GUI customization icons (the draggable handles of panes and the dropdown menu) for users who does not want to have to worry about changing things accidentally. Devs not wanting to offer players the ability to customize their client GUIs could maybe just set it up the way they want and then turn the gui controls off on the javascript level.
![Mockup 2][webclient_mockup_2]
The dropdown menu allows for splitting each pane horizontally and vertically.
![Mockup 3][webclient_mockup_3]
Each pane is "tagged" with what data will be sent to it. It could accept more than one type of tagged data. Just which tags are available is different for each game (and should be reported by the server).
For example, the server could send the return of the "look" command as
```python
msg("you see ...", {"pane": "look"})
```
If one (or more) of the panes is set to receive "look" data, all such will go there. If *no* pane is assigned to "look", this text will end up in the pane(s) with the "Unassigned" designation. It might be necessary to enforce that at least one window has the "unassigned" designation in order to not lose output without a clear pane target. By contrast the pane tagged with "All" receives all output regardless of if it is also being sent to other panes.
Another thing that came to mind is logging. It might be an idea to tie a given log file to a specific pane (panes?) to limit spam in the log (it might be one reason for having a pane with the "All" tag, for those wanting to log *everything*). This could also be set in the dropdown menu or in the webclient options window, maybe.
Comments?
## titeuf87 Jan 23, 2017
That way of splitting panes seems easy to manage while still being powerful at the same time.
It's certainly a lot more flexible than what I had in mind.
This is a quick sketch of what I was thinking about:
```
=====================
Options [x]
=====================
help: [popup]
map: [top left]
channels: [top right]
look: [main output]
```
But that's not as good as Griatch's proposal.
The panes themselves can work differently depending on the content though:
* channel messages: when someone talks on a channel, the output text needs to be appended to the text already shown.
* inventory: this pane should clear its output every time the inventory is displayed, so old inventory is not displayed. Also what about dropping items? As long as the player doesn't check its inventory then that pane won't be updated, unless more OOB data is added to track the inventory.
* help/look: those pane should probably also clear their content before displaying new content.
logging: do you mean have a "save to log" item in the pane menu?
It makes sense that different types of panes would have different functionality. I was thinking that something like `inventory` would be very specific to a given game. But titeuf87 has a point - maybe you can get a rather generalized behavior just by defining if a pane should replace or append to the existing data.
As for the updating of inventory when dropping items, not sure if that can be generalized, but I guess drop/get commands could be wired to do that.
As for logging - yes I picture a "save to log" thing in the menu. The problem is just where to save the log. I think at least for an initial setup, one could maybe set the logging file path in the webclient options and just append logs from all the panes marked for logging to that same file.
I've been messing a little bit with split.js - I've managed to split a split dynamically with a data attribute on a button and jQuery. My current thinking on this issue is to use [jQuery Templates](http://codepb.github.io/jquery-template/) to write the template for horizontal and vertical splits, then using jQuery to set up the initial split layout by inserting those templates as appropriate for user settings.
We would have a dropdown per split that decides what tag it's meant to handle - perhaps a data attribute that we change in the template for easy selection through jQuery - and then send tags for messages to the webclient. This dropdown would also have a setting per split to either append new content or replace content - again, perhaps a data attribute.
We might also want to store "mobile" and "desktop" layouts separately - or just default to a mobile-friendly layout at a certain screen size, and turn off the splits.
Oh, and embedding Bootstrap containers in splits works perfectly - that could help us too.
## chainsol 9th of October, 2017
I've got a demo of this working at [my development box](https://dev.perfectdisorder.net/webclient), if anyone wants to take a look. So far, I've got tag handling, dynamic splits, and the ability to swap splits' contents. Since this doesn't have a fancy interface yet, if you want to see a dynamic split, open your browser's console and try these commands:
`SplitHandler.split("#main", "horizontal")` will split the top-half into two 50-50 splits, both receiving content that's not tagged or is tagged "all" from the server.
`SplitHandler.swapContent("#input", "#split_2")` after doing so will swap the input into the top-left split.
I'm trying to figure out where to put each split's configuration - maybe a dropdown button that's semi-transparent until you hover over it? So far, if you edited the data attributes, you could change each split to receive only tagged messages ( data-tag="all" ), and you could change them to overwrite instead of append data ( data-update-append or data-update-overwrite )
## Griatch Oct 13, 2017
I would suggest that, assuming the game dev allows the user to modify their GUI in the first place, that modification is a "mode". I picture that 99% of the time a user doesn't need to modify their interface. They only want to click whatever game-related buttons etc are present in the pane without risk of resizing things accidentally.
So I'd say that normally the panes are all fixed, with minimal spacing between them, no handles etc. But you can enter the client settings window and choose *Customize GUI mode* (or something like that). When you do, then separators get handles and the dropdown menu markers appear (permanently) in the corner of each pane. This means that if a user *wants* to easily tweak their window they could stay in this mode, but they could also "lock" the gui layout at any time.
