From souliane at mailoo.org Wed Dec 4 17:17:19 2013 From: souliane at mailoo.org (Adrien) Date: Wed, 04 Dec 2013 17:17:19 +0100 Subject: [dev] [FR] Votre avis sur la disposition unibox / mode riche Message-ID: <529F558F.2020403@mailoo.org> Salut, J'aimerais avoir votre avis sur la manière dont sont/devraient être affichés le sélecteur de destinataires et l'éditeur de texte riche + la barre de statut. Voir screenshot pour l'état actuel. Ca fait un peu moche... La question que je me pose principalement, c'est : on devrait pas plutot affiché ce dialogue comme un LiberviaWidget (c'est à dire comme un dialogue de chat) ? Les choses à prendre en compte sont : - le panneau de contacts qui est actuellement déplacé - le fait qu'on n'est pas besoin d'autant de largeur pour l'éditeur (plus tard il y aura une prévisualisation mais bon...), du coup pourquoi ne pas permettre de l'afficher à côté d'une conversation ? - le fait qu'un message envoyé à plusieurs personnes et/ou avec du texte riche a des chances d'être un peu plus long qu'une ou deux lignes, du coup ce serait bien que l'on puisse continuer à chatter pendant sa rédaction (possible seulement si l'unibox est encore affichée) - de même, pourquoi ne pourrait on pas rédiger deux messages en parallèle ? - le bouton "Back to quick box" est quand même perturbant... - que faire avec la barre de statut là ? Bref, vos avis sont les bienvenus, pour dire si vous voyez ca plutôt la ou c'est mais avec des modifications, ou bien ailleurs (en tant que LiberviaWidget, dans l'onglet courant et dans un nouveau ?) Merci :) -------------- section suivante -------------- Une pièce jointe autre que texte a été nettoyée... Nom: Screenshot.png Type: image/png Taille: 113369 octets Desc: non disponible URL: From goffi at goffi.org Thu Dec 5 00:16:47 2013 From: goffi at goffi.org (Goffi) Date: Thu, 05 Dec 2013 00:16:47 +0100 Subject: [dev] [FR] Votre avis sur la disposition unibox / mode riche In-Reply-To: <529F558F.2020403@mailoo.org> References: <529F558F.2020403@mailoo.org> Message-ID: <529FB7DF.5080305@goffi.org> On 04/12/2013 17:17, Adrien wrote: > Salut, Salut > - le panneau de contacts qui est actuellement déplacé Ça ça n'est pas un problème à mon avis > - le fait qu'on n'est pas besoin d'autant de largeur pour l'éditeur > (plus tard il y aura une prévisualisation mais bon...), du coup pourquoi > ne pas permettre de l'afficher à côté d'une conversation ? effectivement il y a la pré-visualisation, la largeur ne me gêne pas (je rédige actuellement ce courriel sur toute la largeur de mon écran). Je trouve même désagréable d'avoir des saisies trop petites comme c'est souvent le cas > - le fait qu'un message envoyé à plusieurs personnes et/ou avec du texte > riche a des chances d'être un peu plus long qu'une ou deux lignes, du > coup ce serait bien que l'on puisse continuer à chatter pendant sa > rédaction (possible seulement si l'unibox est encore affichée) ça c'est un très bon argument, et effectivement il me semble tout à fait logique > - de même, pourquoi ne pourrait on pas rédiger deux messages en parallèle ? > - le bouton "Back to quick box" est quand même perturbant... tout à fait d'accord > - que faire avec la barre de statut là ? Y'a pas mal de choses qui vont s'ajouter dans la barre de statut (humeur, musique en cours d'écoute, etc). elle a son utilité > Bref, vos avis sont les bienvenus, pour dire si vous voyez ca plutôt la > ou c'est mais avec des modifications, ou bien ailleurs (en tant que > LiberviaWidget, dans l'onglet courant et dans un nouveau ?) Le seul truc qui me gêne c'est que je n'associe pas dans ma tête des widgets à de la saisie, pour moi la zone de saisie est au dessus, et en plus j'ai peur que ça fasse pas très joli dans un LiberviaWidget. Enfin c'est pas forcément très grave, disons qu'une capture pour voir ce que ça donne serait sûrement pas mal. À la base j'avais fait l'unibox pour gagner de la place, et voir ce que ça ferait d'avoir une barre pour tout gérer au dessus de tout, mais ce n'est peut-être pas si terrible (beaucoup de monde est perdu, ça change des habitudes, et l'apport n'est peut-être pas si évident). Bref, il y a aussi la possibilité d'afficher la barre de saisie sous le widget en cours d'édition (ou dans une partie définie: pour un commentaire ce serait sous le commentaire). Mais la barre d'édition riche risque de prendre trop de place dans ce cas... Et si le widget n'est que sur une largeur faible, ça va être génant aussi... A priori je pense que ça ne serait pas long de faire des essais en plaçant l'édition riche dans un LiberviaWidget et de le mettre à différents endroit (dans un widget tout en haut, dans un widget en bas, à l'interieur d'un autre widget - dans ce cas ça ne serait plus un libervia widget mais un widget Pyjamas classique -). Le principe de l'Unibox a déjà était mis à mal avec l'édition riche, et à bien y réfléchir c'était peut-être une erreur. Je suis prêt à l'abandonner si vous me confirmez que vous n'aimez pas (après il y a toujours la possibilité de le rendre optionnel). En bonus, placer la saisie dans le LiberviaWidget pourrait simplifier la modification d'un billet existant. ++ Goffi From souliane at mailoo.org Mon Dec 9 17:24:36 2013 From: souliane at mailoo.org (Adrien) Date: Mon, 09 Dec 2013 17:24:36 +0100 Subject: [dev] [EN][PATCH] XEP-0033, presence, blogs, radiocol... Message-ID: <52A5EEC4.70803@mailoo.org> Hi, here are some patches for sat/libervia and one for sat_pubsub: * plugin XEP-0033: implementation of the addressing feature: - frontends pass the recipients in the extra parameter of sendMessage - backend checks if the target server supports the feature (this is not done yet by prosody plugin) - features and identities are cached pro profile and server - messages are duplicated in history for now and echo signals are also send many times to the sender (once per recipient): this has to be fixed later --> IMPORTANT: the following plugin need to be added to your prosody installation: https://code.google.com/p/prosody-modules/source/browse/mod_addressing/mod_addressing.lua 1. copy it to the plugins directory 2. add in the section "modules_enabled" of prosody.cfg.lua the following: "addressing"; * pubsub : I experienced a strange issue with the auto-create feature (PostGreSQL 9.1.10), this occurs when a user posts his first blog message and I found no other solution then applying this solution: http://cssmay.com/question/tag/tag-psycopg2 * you can update/delete your posts in libervia. Update does not make use of the rich text dialog for now. Also we need to save in the pubsub database not only the raw text and xhtml, but also the user defined format and the corresponding text. Behavior is for now a bit disturbing, you can actually mix xhtml (which will be cleaned) and the user defined format (which will be processed). I think we need to save in the pubsub database some extra information like the user defined format at the time of the message creation, also the text has it has been entered by the user - to keep xhtml only is not funny for the poor guy who will want to edit a looong blog post :) * a small change has been made in xep-0060 regarding the blog post deletion, this should be sent the the wokkel project to fix upstream. But the event notifications after a node/item deletion (as described in the spec) are not OK yet, maybe it's better to fix this before. I have to look at it more but for now I didn't manage to make it work. * frontends (other then libervia): replaced the use of __builtin__ to define constants with the use of classes * completed in libervia/primitivus the UI to set your presence and status. This is a first try and we will probably need to change the UI integration. For primitivus I added a bar with clickable items on the bottom of the contact list, you can also use the following commands: - ":presence" to open the presence dialog - ":presence ?" where ? is in ('', 'chat', 'away', 'dnd', 'xa') to set ? as the new presence - ":status" to open the status dialog - ":status ?" to set ? as the new status Note that ":presence " and ":status " are not the same as ":presence" and ":status", they will reset to default/empty value. * Radiocol: - check for the file size and type before sending - handle some error responses - GUI changes and more detailed "status message" (let me know how you would improve it...) - send the queue to new players who just joined (but the music file may have been removed from the server already... to be fixed). * libervia: fixed the waiting problem at account creation... at least it looks fixed, this must be tested more Please have a look and let me know if something need to be changed before we release the 0.4. Then I will add some tests for all that before I break everything :) Best regards, Adrien -------------- section suivante -------------- Une pièce jointe autre que texte a été nettoyée... Nom: lib_presence_addressing_radiocol.diff Type: text/x-diff Taille: 69229 octets Desc: non disponible URL: -------------- section suivante -------------- Une pièce jointe autre que texte a été nettoyée... Nom: pubsub_autocreate.diff Type: text/x-diff Taille: 1796 octets Desc: non disponible URL: -------------- section suivante -------------- Une pièce jointe autre que texte a été nettoyée... Nom: sat_presence_addressing.diff Type: text/x-diff Taille: 103226 octets Desc: non disponible URL: From souliane at mailoo.org Mon Dec 9 20:45:26 2013 From: souliane at mailoo.org (Adrien) Date: Mon, 09 Dec 2013 20:45:26 +0100 Subject: [dev] [EN][PATCH] XEP-0033, presence, blogs, radiocol... In-Reply-To: <52A5EEC4.70803@mailoo.org> References: <52A5EEC4.70803@mailoo.org> Message-ID: <52A61DD6.5030603@mailoo.org> Hi, I answer to myself :) In my previous message, forget the microblogging part for now! I didn't use the good words and explained both what I changed and what I think we should do next. So we discussed about it with Goffi and there's a better solution then saving extra data to the pubsub database (this is what I wanted to do): we can convert the xhtml to the currently selected format, that's more flexible. I send you back the diff without the microblogging changes and divided in pieces to ease the review/integration. Files which start with the same prefix should be pushed together, one for sat and one for libervia, that's it. Cheers, Adrien On 12/09/2013 05:24 PM, Adrien wrote: > Hi, > > here are some patches for sat/libervia and one for sat_pubsub: > > * plugin XEP-0033: implementation of the addressing feature: > - frontends pass the recipients in the extra parameter of sendMessage > - backend checks if the target server supports the feature (this is > not done yet by prosody plugin) > - features and identities are cached pro profile and server > - messages are duplicated in history for now and echo signals are also > send many times to the sender (once per recipient): this has to be fixed > later > > --> IMPORTANT: the following plugin need to be added to your prosody > installation: > > https://code.google.com/p/prosody-modules/source/browse/mod_addressing/mod_addressing.lua > > > 1. copy it to the plugins directory > 2. add in the section "modules_enabled" of prosody.cfg.lua the following: > "addressing"; > > > * pubsub : I experienced a strange issue with the auto-create feature > (PostGreSQL 9.1.10), this occurs when a user posts his first blog > message and I found no other solution then applying this solution: > http://cssmay.com/question/tag/tag-psycopg2 > > * you can update/delete your posts in libervia. Update does not make use > of the rich text dialog for now. Also we need to save in the pubsub > database not only the raw text and xhtml, but also the user defined > format and the corresponding text. Behavior is for now a bit disturbing, > you can actually mix xhtml (which will be cleaned) and the user defined > format (which will be processed). I think we need to save in the pubsub > database some extra information like the user defined format at the time > of the message creation, also the text has it has been entered by the > user - to keep xhtml only is not funny for the poor guy who will want to > edit a looong blog post :) > > * a small change has been made in xep-0060 regarding the blog post > deletion, this should be sent the the wokkel project to fix upstream. > But the event notifications after a node/item deletion (as described in > the spec) are not OK yet, maybe it's better to fix this before. I have > to look at it more but for now I didn't manage to make it work. > > * frontends (other then libervia): replaced the use of __builtin__ to > define constants with the use of classes > > * completed in libervia/primitivus the UI to set your presence and > status. This is a first try and we will probably need to change the UI > integration. For primitivus I added a bar with clickable items on the > bottom of the contact list, you can also use the following commands: > - ":presence" to open the presence dialog > - ":presence ?" where ? is in ('', 'chat', 'away', 'dnd', 'xa') to set > ? as the new presence > - ":status" to open the status dialog > - ":status ?" to set ? as the new status > Note that ":presence " and ":status " are not the same as ":presence" > and ":status", they will reset to default/empty value. > > * Radiocol: > - check for the file size and type before sending > - handle some error responses > - GUI changes and more detailed "status message" (let me know how you > would improve it...) > - send the queue to new players who just joined (but the music file > may have been removed from the server already... to be fixed). > > * libervia: fixed the waiting problem at account creation... at least it > looks fixed, this must be tested more > > > Please have a look and let me know if something need to be changed > before we release the 0.4. Then I will add some tests for all that > before I break everything :) > -------------- section suivante -------------- Une pièce jointe autre que texte a été nettoyée... Nom: 1_lib_presence.diff Type: text/x-diff Taille: 15114 octets Desc: non disponible URL: -------------- section suivante -------------- Une pièce jointe autre que texte a été nettoyée... Nom: 1_sat_presence.diff Type: text/x-diff Taille: 37260 octets Desc: non disponible URL: -------------- section suivante -------------- Une pièce jointe autre que texte a été nettoyée... Nom: 2_lib_radiocol.diff Type: text/x-diff Taille: 29913 octets Desc: non disponible URL: -------------- section suivante -------------- Une pièce jointe autre que texte a été nettoyée... Nom: 2_sat_radiocol.diff Type: text/x-diff Taille: 26707 octets Desc: non disponible URL: -------------- section suivante -------------- Une pièce jointe autre que texte a été nettoyée... Nom: 3_lib_addressing.diff Type: text/x-diff Taille: 5282 octets Desc: non disponible URL: -------------- section suivante -------------- Une pièce jointe autre que texte a été nettoyée... Nom: 3_sat_addressing.diff Type: text/x-diff Taille: 26946 octets Desc: non disponible URL: -------------- section suivante -------------- Une pièce jointe autre que texte a été nettoyée... Nom: 4_lib_account.diff Type: text/x-diff Taille: 3634 octets Desc: non disponible URL: -------------- section suivante -------------- Une pièce jointe autre que texte a été nettoyée... Nom: 4_sat_account.diff Type: text/x-diff Taille: 2744 octets Desc: non disponible URL: From souliane at mailoo.org Tue Dec 10 14:18:49 2013 From: souliane at mailoo.org (Adrien) Date: Tue, 10 Dec 2013 14:18:49 +0100 Subject: [dev] [EN][PATCH] microblog delete/update In-Reply-To: <52A61DD6.5030603@mailoo.org> References: <52A5EEC4.70803@mailoo.org> <52A61DD6.5030603@mailoo.org> Message-ID: <52A714B9.9090409@mailoo.org> Hi again, so here are the patches for the microblog feature. It will now call the syntaxConvert method live to display the editable text in the user selected format. Concerning sat_pubsub, please re-use the one that I sent yesterday (file pubsub_autocreate.diff). I fixed at the same time the display issue with the contact bar (it was not resized when in rich text mode). Also both rich text dialog and blog update dialog use the full available space. A+ Adrien On 12/09/2013 08:45 PM, Adrien wrote: > Hi, > > I answer to myself :) > > In my previous message, forget the microblogging part for now! I didn't > use the good words and explained both what I changed and what I think we > should do next. So we discussed about it with Goffi and there's a better > solution then saving extra data to the pubsub database (this is what I > wanted to do): we can convert the xhtml to the currently selected > format, that's more flexible. > > I send you back the diff without the microblogging changes and divided > in pieces to ease the review/integration. Files which start with the > same prefix should be pushed together, one for sat and one for libervia, > that's it. > > Cheers, > Adrien -------------- section suivante -------------- Une pièce jointe autre que texte a été nettoyée... Nom: 5_lib_microblog.diff Type: text/x-diff Taille: 37732 octets Desc: non disponible URL: -------------- section suivante -------------- Une pièce jointe autre que texte a été nettoyée... Nom: 5_sat_microblog.diff Type: text/x-diff Taille: 12958 octets Desc: non disponible URL: From goffi at goffi.org Fri Dec 13 17:23:59 2013 From: goffi at goffi.org (Goffi) Date: Fri, 13 Dec 2013 17:23:59 +0100 Subject: [dev] [en] plugin account now use sat.conf Message-ID: <52AB349F.3000309@goffi.org> G'day, just for the record, I have modified the plugin account used to automatically create new accounts with libervia, so you can put the server dependants data in sat.conf, instead of modifying the plugin itself like before. The names to use are explained at the beginning of the plugin (src/plugins/plugin_misc_account.py). Cheers Goffi From mcy at lm7.fr Fri Dec 13 19:19:42 2013 From: mcy at lm7.fr (Matteo Cypriani) Date: Fri, 13 Dec 2013 13:19:42 -0500 Subject: [dev] [FR] Votre avis sur la disposition unibox / mode riche In-Reply-To: <529FB7DF.5080305@goffi.org> References: <529F558F.2020403@mailoo.org> <529FB7DF.5080305@goffi.org> Message-ID: <20131213131942.fcaffd876d1c2fc288c13a4f@lm7.fr> On Thu, 05 Dec 2013 00:16:47 +0100, Goffi wrote: > [?] > > Le principe de l'Unibox a déjà était mis à mal avec l'édition riche, et > à bien y réfléchir c'était peut-être une erreur. Je suis prêt à > l'abandonner si vous me confirmez que vous n'aimez pas (après il y a > toujours la possibilité de le rendre optionnel). En bonus, placer la > saisie dans le LiberviaWidget pourrait simplifier la modification d'un > billet existant. Je ne suis pas sûr d'avoir tout bien suivi, mais selon moi le point essentiel qu'Adrien a soulevé, c'est qu'il est important de pouvoir taper plusieurs messages simultanément et de pouvoir continuer les discussions instantanées en parallèle. Je pense que le plus naturel serait dans un widget comme les discussions et le reste, mais ça pourrait aussi être dans des onglets séparés. Mes deux sous qui valent ce qu'ils valent, Matteo -------------- section suivante -------------- Une pièce jointe autre que texte a été nettoyée... Nom: non disponible Type: application/pgp-signature Taille: 836 octets Desc: non disponible URL: From goffi at goffi.org Sat Dec 14 15:50:55 2013 From: goffi at goffi.org (Goffi) Date: Sat, 14 Dec 2013 15:50:55 +0100 Subject: [dev] [FR] Votre avis sur la disposition unibox / mode riche In-Reply-To: <20131213131942.fcaffd876d1c2fc288c13a4f@lm7.fr> References: <529F558F.2020403@mailoo.org> <529FB7DF.5080305@goffi.org> <20131213131942.fcaffd876d1c2fc288c13a4f@lm7.fr> Message-ID: <52AC704F.1010903@goffi.org> On va probablement intégrer la saisie dans les widgets de manières plus classique, mais on verra ça pour la 0.5... On 13/12/2013 19:19, Matteo Cypriani wrote: > On Thu, 05 Dec 2013 00:16:47 +0100, Goffi wrote: >> [?] >> >> Le principe de l'Unibox a déjà était mis à mal avec l'édition riche, et >> à bien y réfléchir c'était peut-être une erreur. Je suis prêt à >> l'abandonner si vous me confirmez que vous n'aimez pas (après il y a >> toujours la possibilité de le rendre optionnel). En bonus, placer la >> saisie dans le LiberviaWidget pourrait simplifier la modification d'un >> billet existant. > > Je ne suis pas sûr d'avoir tout bien suivi, mais selon moi le point essentiel > qu'Adrien a soulevé, c'est qu'il est important de pouvoir taper plusieurs > messages simultanément et de pouvoir continuer les discussions instantanées > en parallèle. Je pense que le plus naturel serait dans un widget comme les > discussions et le reste, mais ça pourrait aussi être dans des onglets séparés. > > Mes deux sous qui valent ce qu'ils valent, > Matteo > > > > _______________________________________________ > dev mailing list > dev at goffi.org > http://lists.goffi.org/listinfo/dev > From souliane at mailoo.org Thu Dec 19 14:28:58 2013 From: souliane at mailoo.org (Adrien) Date: Thu, 19 Dec 2013 14:28:58 +0100 Subject: [dev] [EN][PATCH] file upload, presence, blogs Message-ID: <52B2F49A.4060409@mailoo.org> Hi, here are some new patches, nothing really new but small improvements. The main topics are file uploads, presence update and blogs. File upload: radiocolSongAdded is now asynchronous and bridge methods that are called after a file upload return a Failure when necessary. In libervia.tac, UploadManager instanciate a JSONRPCMethodManager to call the asynchronous method, returns server.NOT_DONE_YET and finish the request later when the answer arrives from the backend. This is basically what is done already during account registration. Presence and status were shared between all resources of the same user, this has been fixed. Rich text is also displayed in the external blogs accessible from /blog/ + CSS modification to display the sections and lists properly (tags h1, h2... ul ol li) within the MicroblogPanel. Note that the tags/style filtering is unchanged: ChatPanel still doesn't display everything as "expected", because XHTML-IM is not supposed to be used for writing an article. MicroblogEntry is now based on FlexTable instead of FlowPanel/HTMLPanel, so we can have a better control of the different element positioning, and we can force large images to fit the available space. Finally the blog items are now making the difference between "published" and "updated". They are ordered according to the date of publication. Best regards, Adrien -------------- section suivante -------------- Une pièce jointe autre que texte a été nettoyée... Nom: lib_radiocol_blog.diff Type: text/x-diff Taille: 30565 octets Desc: non disponible URL: -------------- section suivante -------------- Une pièce jointe autre que texte a été nettoyée... Nom: sat_radiocol_blog.diff Type: text/x-diff Taille: 13126 octets Desc: non disponible URL: From goffi at goffi.org Tue Dec 24 15:55:28 2013 From: goffi at goffi.org (Goffi) Date: Tue, 24 Dec 2013 15:55:28 +0100 Subject: [dev] [en] important core changes Message-ID: <52B9A060.3010801@goffi.org> G'day all, I have made several important changes in core that I need to explain (N.B.: urwid_satext need to be updated too): - a new Sessions class in memory.memory is used to managed time limited session. It act like a dict, and is automatically purge after a given timeout (default 10 min): * You first need to create the session with sessions = Sessions() (and optionaly the timeout or the profile, see below). * To create a session, just do session=newSession(). this return a session_id (a string) and a session_data object (an empty dict) * if session is accessed, the timeout is reset * if you have finished with the session, you can delete it with "del sessions[session_id]" * if your sessions need to be protected from other profiles access (needed for sensitive data, to avoid session_id guessing with multi-users frontends like Libervia), you can give a profile argument when creating the instance; in this case you have to use profileGet instead of the __getitem__ access. - I have started a refactoring for importMenu and callbacks. The goal is to use a unique and easy callback system. The actionResult* methods are deprecated, and LaunchAction is now asynchronous. Callbacks can be used for many things: plugin menus, XMLUI buttons, form submitting, or anything than is launched by a frontend. Here's how they work: * You register a callback with core.sat_main.registerCallback. The first argument is the callback itself, then are arguments which will be sent back to the callback. * when registering a callback, you can use the following keyword arguments: "with_data" indicate that the callback need a dictionary data (e.g.: necessary for XMLUI form submitting). "force_id" indicate that you want to use you own id instead of the autogenerated one; this is generally a bad idea as this can lead to name conflicts. * registerCallback return you the callback id which be used in XMLUI or anywhere to reference the callback - Import menu: don't use action id anymore and become asynchronous too. The refactoring is not finished yet, it will use callback system soon. - Gateways plugin (XEP-0100) should be broken, I'll fix it soon. - XMLUI now use submit_id which use the callback system (submit_id is a callback id). submit_id is mandatory if you create a form XMLUI (but if you know what you are doing, you can use empty string instead of None to bypass the restriction). - XMLUI now manages session_id: if a session_id is specified, it means that a complex multi-panel UI is running, the frontends MUST return this id. - in xml_tools: dataForm*2XML has been renamed to dataForm*2XMLUI because they now return a XMLUI instead of raw XML, so they can still be modified before sending. - Urwid SàText now use a ListOption for GenericList and descendants: this is actually like a unicode (so it preserve compatibility), but it make the difference between "value" and "label": comparaisons are made against value, and values are returned in XMLUI results, but it's the label which is displayed. Again, it's necessary to update Urwit SàText to last dev version to use last dev version of SàT - XMLUI refactoring is not finished: mainly frontends code still need to be factorised and cleaned - Add-Hoc Commands are available. It's not fully finished, but it's working. You can add a command to answer with XEP_0050.addAdHocCommand. There are plenty of options but most of them are optional and everything is explained in docstring. I have added a command to change status as an example, this command is restricted to the same bare jid (tested with Gajim and Psi). ++ Goffi From goffi at goffi.org Sun Dec 29 21:00:27 2013 From: goffi at goffi.org (Goffi) Date: Sun, 29 Dec 2013 21:00:27 +0100 Subject: [dev] [en] i18n and dynamic menu changes Message-ID: <52C07F5B.3010500@goffi.org> G'day, there are again some important changes in core, concerning internationalisation (i18n) and dynamic menus: *** i18n *** - _() method is not imported anymore in __builtins__ but has to be explicitly imported from sat.core.i18n. I think it's more clean, and it avoid errors with tools like pyflakes. - core.i18n module manage gettext importError, thus is can be used in Libervia directly - there id a D_() method for deferred translation. This need some explanations: xgettext read python sources to find _() method to get sentences to translate. But xgettext only get python strings. In addition the _() method return the translated string immediately, this is not always what we want. D_() allow to say "I want to translate this sentence, but I'll do it later, so keep the sentence untranslated for now". Two usecases to be more clear: * if you have a constants that has to be used for a parameter category, you want to keep the sentence untranslated, until you actually display it. This is what is used in plugins/plugin_misc_text_syntaxes.py: the CATEGORY constant is a deferred translation like this: CATEGORY = D_("Composition") . After, the untranslated version is used in TextSyntaxes.params for category_name (CATEGORY), and the translated one is used for category_label (_(CATEGORY)) * if you want to dynamically translate a sentence in a other language. This is the case for menus: Libervia can be used by people speaking different languages at the same time, so menus need to be translated on the fly. the getMenus bridge method take a language argument to select the language. When using importMenu, you need to give deferred translation for that (e.g.: (D_('Open'), D_('File')). The untranslated version is used to check conflicts, while the translated version is returned to the frontend with menu_path_i18n. - to do dynamic translations, you can change the translation language with core.i18n.languageSwitch (dont forget to change back to default after ! Just use languageSwitch() with no argument) ** menus ** - menus now use generic callback system. When using importMenu, you can give an actual callback, or the id of an already registered callback (in this case, you can use additionnal *args and **kwargs as allowed by registerCallback). - the extra data parameter is used by menu. e.g. the selected jid for ITEM_CONTEXT is returned throught these data, with the "jid" key. - menus are now identified with menu_id (same as callback_id) instead of (type, category, name) tuples - paths (array of strings) are used instead of category/name. e.g. instead of the category "File" and the name "Open", we use the path ("File", "Open"). This allow to easily create submenus. - menus are internationalised (see above) - security_limit is used in the same ways as for parameters. Next week I will not be available a lot, so the 0.4 is postponed to begin of january. I still need to refactor XMLUI and fix gateways (XEP-0100). Cheer Goffi