- new config option `singleton`.
- new plugin `converse-uniview`
- removed `converse-embedded`.
- various CSS changes, to properly render an embedded full app
- don't re-open cached and non-autojoined chats in singleton mode
The goal here is to extend the `embedded` `view_mode` so that the full app can
also be embedded, not just a single MUC or private chat.
To do this, we'll need to differentiate between multi and singleton chat apps.
* A singleton chat app contains only a single chat.
* A multi-chat app can contain zero or more chats
So we introduce a new config option, `singleton`, which when used with
`view_mode` set to `embedded` will determine whether a single chat or the full
app is embedded.
Similarly, in `overlayed`, `fullscreen` and `mobile` view modes, `singleton`
set to true will allow only one chat within the parameters of that view mode.
We're appropriating the word `singleton` and introducing the concepts of
`uniview` and `multiview` (see a785ca8) to cover what was
previously meant with `singleton`.
updates #1297
We now have uniform avatar rendering for the profile, messages and
chatboxes.
By rendering as canvas, we can avoid stretching the image.
In the process I also moved the ChatBoxViews collection into its own
plugin `converse-chatboxviews` and placed the AvatarAware views there.
fixes#1157
Include entity capabilities hash in outgoing presences
Also, started some work on using jsdoc for rendering API documentation.
Ideally that would go into a separate commit but that would take ages to
untangle.
It contained only `overrides` and some HTTP upload code was in other
modules.
Current thinking concerning overrides:
Usage of `overrides`, while useful in certain cases, should in general
be discouraged, since it's in essence "monkey patching" which makes it
more difficult to know whats executing at runtime and more difficult to
refactor.
Splitting modules up between XEPs is not always that useful. Some XEPs,
like HTTP Upload (and MAM comes to mind) have their functionality spread
out over single and group chats (and pubsub) and might for practical
purposes be considered "core" enough to not try and keep them in
separate modules (which inevitably requires overrides or a fundamentally
rethinking the architecture).
Where splitting code between modules makes a lot of sense is in keeping
Backbone Models and Views separate (so that alternative view libraries
like Vue could be used) and probably in keeping Single chats, MUC,
PubSub and MIX separate.
updates #161
Previously we kept all entities and their items (which are also
instances of _converse.DiscoEntity) in a flat array.
Instead, we should have a tree-like structure where items are stored
on the relevant entity (and recursively on other items).
- Update build scripts to use transpiled versions of newly added modules
- Stop building locales.js and remove locales stuff from build scripts
- No need for Grunt anymore since we don't need to make locales.js
- Use `enabled` method for plugins
- Rename `converse-inverse.js` to `converse-fullscreen.js` and make it a
core plugin.
- We're no longer making separate mobile and inverse builds
No longer a need to whitelist/blacklist plugins for inverse to work.
Builds are now themselves UMD modules, so they could be `require`'d like any
other AMD module or they can still be used as old ES5 modules with globals.
Additionally the build is now closured, so that the almond API doesn't pollute
the global context with `define` or `require`. This does however mean that
`require` can no longer be used outside of the build (unless requirej.s is
included directly.
Builds are now themselves UMD modules, so they could be `require`'d like any
other AMD module or they can still be used as old ES5 modules with globals.
Additionally the build is now closured, so that the almond API doesn't pollute
the global context with `define` or `require`. This does however mean that
`require` can no longer be used outside of the build (unless requirej.s is
included directly.