Not sure about the Django login session as a baseline thing. Auto-login based on a given criterion sounds more like an alternate login system suitable for a contrib.

Sound as a baseline thing sounds superfluous to me but I can see the argument.

The GUI configuration should ideally be freeform, with the ability to split the display horisontally/vertically into as many panes as required, and then using some sort of menu in each pane to assign it a role (input: single/multiline and output with an OOB tag for knowing to redirect server data to that particular window.

Probably we should be talking about two levels of preferences here - game designer level configurabilty and user-level configurability. Whereas it sounds nice to have user preferences, I think it would make sense to also let game creators "lock" parts of the client configuration so as to offer some sort of minimum common ground for their particular game.

@Griatch I think the Django logins should be a baseline thing, but they should be overwritable. Django supports pluggable authentication, so if someone intends to do something really fancy with their game login handling, they can, and even have it integrate with the game.

But mostly I want this because not having it violates expectations. I just logged into the website. Why do I have to type 'connect username password' on the webclient? I think the majority of cases would want this, but like anything in Evennia, I'm cool with it being overridable.

I think these are good ideas. I modified codes in contrib/menu_login.py, so users do not need to input 'connect username password' any more. They can use menu to login and new uses can login right after creation. It must be more convenient if the website can share login info with webclient.

I think we can make the webclient more beautiful with OOB, such as divide the window into several sections displaying different kinds of informations.

There is some work done (not yet online) on a new webclient. This one is based on a javascript component (evennia.js) that relays incoming text data to a javascript function. These functions can be simply added to (modularity) but just importing one's own javascript module and append one's function to the relevant object dictionary mapping from evennia.js.

While not ready for prime time yet, the webclient component I'm toying with currently gives the dev the ability to use any js gui toolkit (I use Foundation for now) and just mark up their containers with class= markers that evennia.js recognizes. The component comes with a few convenience functions so far, like a function to relay data to a specified class (accessed with something like msg("Text", ooc=("divclass", "textarea") as well as single- and multiple-line input fields with mud-like history handling.
.
Griatch

I am completely new to Evennia and I have a lot of reading to do before I can confidently give precise feedback. However, if I understand Griatch right, I think he is taking this in the right direction. What you ought to do is equip web developers with something that allows them to completely paint their own experience using whatever client-side methods that they wish. The language of the web is Javascript and Javascript uses JSON for all things communication. Give us the flexibility to see just JSON and we will build you elaborate engines that let you play whatever kinds of sounds you wish. On any platform. :)

Hey there, I had a brief discussion with @Griatch about the form of the web component and he asked me to contribute my thoughts to this issue.

I'm actually looking for something a lot more light-weight from the Evennia team as far as the interface goes. Here are the things I'd request of the interface:

• An emitter that sends commands to the backend and calls a passed callback.

  Evennia.emit('event:name', params, [callback]);

• A configuration setting for the evennia interface that allows me to pass it a custom emitter for it to call emit upon.

  // perhaps default to jQuery emitter? Or custom emitter
  // provided by Evennia?
  Evennia.set({ emitter: MyCustomEmitter });

MyCustomEmitter would be my own implementation of an event aggregator that handles event listeners and passing params to them. I briefly see the emitter having an emit function callable by backend based events. This is to give control to the front-end developer, allowing them to integrate an event aggregator into a framework of their choice (angular/react/marionette/etc).

An emit message might look something like:

var msg = {
  source: 'roller',
  command: 'roll',
  params: //arbitrary, could be list, string, int, object,
  ... // <other tags or key/value pairs that might be necessary
}

I don't think it is a bad idea to build out what you're suggesting here, a modular interface for point-and-click construction, but I think what I suggest offers an easier first step and more flexibility. I know I could look at the current websocket evennia.js code and build what I'm suggesting, but I'm not as familiar with your code and I wouldn't have to be, I would just know what format I need to put things in to get things out.

I edited the evennia_websocket_webclient.js file to reflect the sort of thing I was talking about. It's just thrown together, so I can't guarantee it all works, but it should give a basic idea of where I was going with a more narrow scope for the evennia websocket wrapper.

I made a gist of it here.

Thanks for the gist; it looks useful and most illustrative. I won't be able to do more with this until after the holidays though, just so you know. :)

The wclient development branch is now online and open for input as per #924. The JS part implements a handler directly influenced by @hakupaku's gist above (plus making changes to fit the new data flow on the backend also introduced with this branch. See here for a detailed overview.

On this issue (#613):

The wclient branch means modularity from this issue is going to be handled pretty nicely I think. The addition of particular modules (including the notification) is probably best deferred to #614. The sharing of the Django session is not setup or considered, not sure the wclient branch will deal with that at all (there's still a lot of stuff to add to the branch as it is.

Hey there! I don't mean to nag, but I haven't seen this listed anywhere as a priority - will the new web client support Xterm256? I've been having a wonderful time with the greater spectrum of colors on offer when working on my own projects, and I found it kind of baffling that the webclient that comes with Evennia doesn't support it, even though it's built into Evennia itself by default...

@BattleJenkins

Added xterm256 color support to wclient-branch webclient.

The modularity and overall webclient improvements have now merged into master. Not all aspects of this issue has been addressed though, so leaving this open along with #614.

@Kelketek

Any ideas how one would practically tie the Django login to the webclient login? For it to be useful I figure one would need to handle these cases:

1. Player has authenticated to the website (or admin interface if they have the django staff bit) - they can then open the webclient and directly connect to their player. This suggests some sort of browser-based session being stored.
2. The player has logged into the webclient, then opens the website in another tab(?) - they should then be able to use the website without logging in.
3. Should logging out of the website/webclient also log you out of the other site? I'm thinking not.

Logging into the website is not hard, I'm not sure how to handle the whole session aspect of it though, and where to store it to make it available to either system.

@Griatch Have the webclient view in Django insert a one-time token which can be sent by the webclient to validate the user.

Also, you may want to look up https://docs.djangoproject.com/en/1.9/topics/http/sessions/

@Kelketek

That actually looks a lot easier than I thought it would be. I just need to figure out how to tie the Evennia Session to the Django-Session though; Since one is assigned at the websocket connection and the other when entering the webpage in the Django view.

I have a working shared login running on my local machine. For now I'm telling the web client the browser hash via the django template context var csession = {{ browser_sessid }}; and then I send that as an OOC command to the evennia side. I suppose this is not more of a security problem than using a cookie-based login state in the first place.

Bit of necro, I agree with point 2, having the tab flash or a toast popup when stuff happens will definitely make it so people don't want to go back to using telnet clients. I'll mock something up in a branch and see how it goes.

I'm closing this issue, instead solely deferring to #614 for future work.