- actionManager is used by default (no callback provided)
- in XMLUI, the dialog is closed before calling actionManager
- if keys are not managed in resuling data, an exceptions is raised
- adaptation to backend modifications
- moved common blogging parts from Libervia to quick frontend
- QuickApp use a MB_HANDLE class variable to indicated if blogging is managed by the frontend (and avoid waste of resources if not)
- comments are now managed inside parent entry, as a result a tree of comments is now possible
- Entry.level indicate where in the tree we are (-1 mean parent QuickBlog, 0 mean main item, more means comment)
- items + comments are requested in 1 shot, and RTDeferred are used to avoid blocking while waiting for them
- in QuickBlog, id2entries allow to get Entry from it's item id, and node2entries allow to get Entry(ies) hosting a comments node
- QuickBlog.new_message_target tell where a new message will be sent by default
- remove parameter "online" (can be guess from "presence" value)
- process "statuses" dict in quick_frontend, so this method can get a simple unicode "status"
- add C.PRESENCE_STATUSES_DEFAULT to define the key to use for fallback status
- chat: notification was raising an error when you just entered the room and self.nick is None
- quick_widget: deleting a widget was modifying a dict while looping on it + unselect widget when it's being deleted
- actually call the cached signals, everything was there but the call was not done
- display '[]' instead of '[None]' when group message coming from the room (no resource)
- catch the exception when trying to delete an occupant who's not in the room
- do not cache a "main resource" for MUC entities
- there are 2 mains types of menu: MenuItem which can be launched, and MenuCategory which contains other menus
- local menus (from frontend only) and distant menus (from backend and its plugins) are managed
- there is a menu manager which, in a similar ways as for widgets, manages the menus logic and should be instantiated by host
- when a context is necessary (this is the case for most of menus), a data collector is used: it collects data from the caller (the instance linked to the menu) and construct data which is then sent throught bridge
- to have implementation specific to a frontend which override the backend one, there is a MenuHook class
- it is possible to place an expected menu in the desired position with MenuPlaceHolder class
- add quick_frontend.quick_games for registering the signals and registering the UI classes
- rename the signals handlers to fit the convention (e.g.: tarotGameScoreHandler)
- rename card_game to game_tarot, quick_card_game to quick_game_tarot, CardGame to TarotGame
