From souliane at mailoo.org Fri Sep 6 17:12:55 2013 From: souliane at mailoo.org (Adrien) Date: Fri, 06 Sep 2013 17:12:55 +0200 Subject: [dev] XEP-0085 implementation In-Reply-To: <62470828.IofdQ7RDuL@goffissimo> References: <62470828.IofdQ7RDuL@goffissimo> Message-ID: <5229F0F7.4080806@mailoo.org> Hi everybody! A short introduction first: I'm a friend of Goffi living in Vienna, Austria, and I'm joining him on the SàT project (development, updating documentation on the wiki...). Please find attached an archive with some patches for sat and libervia. It is adding a plugin for the XEP-0085 (chat state notification) and modifies a few other thinks (smalls bug fixes or improvements, PEP 8). Best regards, Adrien -------------- section suivante -------------- Une pièce jointe autre que texte a été nettoyée... Nom: patches_20130906.zip Type: application/zip Taille: 21683 octets Desc: non disponible URL: From goffi at goffi.org Fri Sep 6 18:02:34 2013 From: goffi at goffi.org (Goffi) Date: Fri, 06 Sep 2013 18:02:34 +0200 Subject: [dev] [en] XEP-0085 implementation (chat state) In-Reply-To: <5229F0F7.4080806@mailoo.org> References: <62470828.IofdQ7RDuL@goffissimo> <5229F0F7.4080806@mailoo.org> Message-ID: <5229FC9A.6070605@goffi.org> Great, thanks :). Just a few remarks: - please create a new message when writing on the list, don't use the "reply" button for a new thread, else it mess up threads - this list is bilingual, so we try to put [en] or [fr] in the subject if the message is just in one language. - the archive is misnamed (zip extension instead of tar.bz2) - it's better to use a root dir when doing an archive (e.g.: patches/ with all the patches inside) Thanks for your work :) Goffi On 06/09/2013 17:12, Adrien wrote: > Hi everybody! > > A short introduction first: I'm a friend of Goffi living in Vienna, > Austria, and I'm joining him on the SàT project (development, updating > documentation on the wiki...). > > Please find attached an archive with some patches for sat and libervia. > It is adding a plugin for the XEP-0085 (chat state notification) and > modifies a few other thinks (smalls bug fixes or improvements, PEP 8). > > > Best regards, > Adrien > > > _______________________________________________ > dev mailing list > dev at goffi.org > http://lists.goffi.org/listinfo/dev > From souliane at mailoo.org Sat Sep 7 02:24:34 2013 From: souliane at mailoo.org (Adrien) Date: Sat, 07 Sep 2013 02:24:34 +0200 Subject: [dev] [en] security check before modifying a param Message-ID: <522A7242.3030107@mailoo.org> Hi, here 2 other patches for sat and libervia. The parameter "security_limit" that has been previously added to the getParams methods is now also in setParam. One check is done by Libervia (only parameters that are displayed in the dialog can be modified) and the core setParam method also do the general check (security_limit must be >= security of the param node). Best regards, Adrien -------------- section suivante -------------- Une pièce jointe autre que texte a été nettoyée... Nom: libervia_215.patch Type: text/x-diff Taille: 5644 octets Desc: non disponible URL: -------------- section suivante -------------- Une pièce jointe autre que texte a été nettoyée... Nom: sat_633.patch Type: text/x-diff Taille: 14242 octets Desc: non disponible URL: From souliane at mailoo.org Sun Sep 8 15:20:28 2013 From: souliane at mailoo.org (Adrien) Date: Sun, 08 Sep 2013 15:20:28 +0200 Subject: [dev] [en] patches for SaT and Libervia Message-ID: <522C799C.6080409@mailoo.org> Hi, here some new patches for SàT: - plugin XEP-0085: renamed category and parameter - plugin misc_account: fix for sending a failure message - core: fix for methods signature (getParams...) and for Libervia: - browser_side: small improvements for parameters panel - auto-select the first tab - remove the parameters item if there's nothing to display - browser_side: display clickable URLs in chat text - browser_side: added key listener to login and register panels - pressing enter set the focus to the next field or validate the form (fix bug 29) Best regards, Adrien -------------- section suivante -------------- Une pièce jointe autre que texte a été nettoyée... Nom: libervia_216-218.patch Type: text/x-diff Taille: 15975 octets Desc: non disponible URL: -------------- section suivante -------------- Une pièce jointe autre que texte a été nettoyée... Nom: sat_634-636.patch Type: text/x-diff Taille: 6131 octets Desc: non disponible URL: From goffi at goffi.org Sat Sep 21 15:56:32 2013 From: goffi at goffi.org (Goffi) Date: Sat, 21 Sep 2013 15:56:32 +0200 Subject: [dev] [en] patches for SaT and Libervia In-Reply-To: <522C799C.6080409@mailoo.org> References: <522C799C.6080409@mailoo.org> Message-ID: <523DA590.6040109@goffi.org> Everything is pushed, thanks :). I have updated the Libervia demo so you can try there. As attachment, I put the missing patches that you sent me in private emails, so we can keep them in the mailing list archive. Thank again for your good work. Cheers Goffi On 08/09/2013 15:20, Adrien wrote: > Hi, > > here some new patches for SàT: > > - plugin XEP-0085: renamed category and parameter > - plugin misc_account: fix for sending a failure message > - core: fix for methods signature (getParams...) > > and for Libervia: > > - browser_side: small improvements for parameters panel > - auto-select the first tab > - remove the parameters item if there's nothing to display > - browser_side: display clickable URLs in chat text > - browser_side: added key listener to login and register panels > - pressing enter set the focus to the next field or validate the > form (fix bug 29) > > Best regards, > Adrien > > > _______________________________________________ > dev mailing list > dev at goffi.org > http://lists.goffi.org/listinfo/dev > -------------- section suivante -------------- Une pièce jointe autre que texte a été nettoyée... Nom: libervia_217.patch Type: text/x-diff Taille: 3095 octets Desc: non disponible URL: -------------- section suivante -------------- Une pièce jointe autre que texte a été nettoyée... Nom: sat_635.patch Type: text/x-diff Taille: 1377 octets Desc: non disponible URL: From souliane at mailoo.org Thu Sep 26 15:26:05 2013 From: souliane at mailoo.org (Adrien) Date: Thu, 26 Sep 2013 15:26:05 +0200 Subject: [dev] [en] Bug fix for wix and couple of improvements Message-ID: <524435ED.1090601@mailoo.org> Hi to you! Here a few patches for sat and libervia again. Goffi> could you please check them in - after checking :-) There are some modifications for PEP8 compliances which make it difficult to read... I hope it's still OK... let me know if something is wrong with that. Below a copy of the commit messages for sat: plugin XEP-0085: improvement for sendind "composing" state ************** wix, plugin XEP-0085: bug fix at startup when the method chatStateReceived doesn't exist TODO: implementation for displaying the states on the chat window and sending "composing" states ************** For libervia: browser_side: check for duplicate name before adding a new contact group ************** browser_side: set the focus to the first field when a tab is selected from the register panel ************** browser_side, plugin XEP-0085: limit the number of bridge methods calls for "chatStateComposing". ************** browser_side: center the buttons of GenericConfirmDialog ************** browser_side: display widget title in the debug info (LiberviaWidget method "getDebugName") - better PEP8 compliance ************** browser_side, misc: better PEP8 compliance ************** browser_side: added the flag REUSE_EXISTING_LIBERVIA_WIDGETS - do not create a new chat panel for contacts/groups if a similar one is found - this goes with a modification of the class methods to create new panels (for genericity) - improvement of the accepted groups list for MicroblogPanel (remove duplicates and keep sorted) Details for the new flag: # Set to true to not create a new LiberviaWidget when a similar one # already exist (i.e. a chat panel with the same target). Instead # the existing widget will be eventually removed from its parent # and added to new WidgetsPanel, or replaced to the expected # position if the previous and the new parent are the same. I will hopfully finish this week a prototype for a rich text editor. Not wysiwyg but for with some buttons to help the users decorating is text with some tags, also something to send messages to several contacts/groups (sending them in a batch first, then we will need to implement XEP-0033[1]). [1] http://xmpp.org/extensions/xep-0033.html Best regards, Adrien -------------- section suivante -------------- Une pièce jointe autre que texte a été nettoyée... Nom: libervia_221-227.patch Type: text/x-diff Taille: 70991 octets Desc: non disponible URL: -------------- section suivante -------------- Une pièce jointe autre que texte a été nettoyée... Nom: sat_647_648.patch Type: text/x-diff Taille: 3832 octets Desc: non disponible URL: From souliane at mailoo.org Sat Sep 28 15:31:16 2013 From: souliane at mailoo.org (Adrien) Date: Sat, 28 Sep 2013 15:31:16 +0200 Subject: [dev] [en] ideas for the rich text editor? Message-ID: <5246DA24.80202@mailoo.org> Hi, This message is a bit long because I would like to discuss about a rich text dialog feature, and how the regexp processing could work. I send you some screenshots from the current status of the editor for libervia. Feel free to share any comment or suggestion! Screenshot-1: the input is retrieved from the unibox when you press that icon on its left (or double click the unibox). Target hooks are eventually parsed, otherwise the selected chat/microblog dialogs is taken as the target (if any). This was already implemented for sending messages. So these information are copied to the editor. By default you only see the recipient type "Too" and there's an AutoCompleteTextBox to help you (with values from groups - with prefix @ - and contacts). Screenshot-2: user pressed the "Too" button, which displays a new dialog where you can select none (first value = ""), one or more recipients for "Too", "Cc" and "Bcc". The reset button restores the values as they where when the dialog has beem showed. Later we can think of using drag and drop to make it easier and move from one recipient type to the other [1]. Screenshot-3: "Too" recipient type is always displayed anyway, but "Cc" and "Bcc" are displayed only if not empty. Recipients are added regarding what was selected in the previous dialog. There's a selector to change the format from markdown, bbcode, dokuwiki, html... this is not well defined yet but we want to show buttons for a restricted subset of these formats, to not overload the GUI. I don't plan any wysiwyg stuff, but for later a previous panel would be needed. Screenshot-4: message can be send back to the unibox or sent only if there's a maximum of 1 Too recipient, and no Cc nor Bcc. So finally the user removed here some recipients and clicked "Back to quick box" or "Send message" : in any case, the associated chat/microblog dialog is selected/opened, and the message body copied to the unibox. If he clicked "Send message", what we expect is done... So it's possible to go from unibox to that text editor and vice versa. Questions: - we need another colour for the toolbox icon when the mouse pass over it - see screenshot-3, it's not so nice like that... any other ideas regarding the UI/colour/behavior whatever are more then welcome. - we need to store the format of the message to know how to display it. You know about a XEP to attach such information (and not to convert the message to HTML, we want to keep it stored as the selected format to allow further edition of the message)? - We obviously won't display HTML in primitivus... I was thinking that each frontend would have it's associated format and that the text would be converted dynamically from the backend... I think we can do that by defining a set a regexp for each format, and this would be used for everything: markdown: {"italic": "(?P*)(?P*), ... } html: {"italic": "(?P)(?P), ... } bbcode: {"italic": "(?P[i])(?P[/i]), ... } From that it should be possible to know that: - when you click the italic button, the text will be surrended by * * or
    • . - a message written in markdown to be displayed in html should be processed to replace * * with . If we are using primitivus which is set for bbcode, it will be replaced with [i] [/i] It should be a bit more complicated to also handle special formatters like "heading" or "list" which need to more the selected text to a new line. If no text is selected we may want some information to be written in between the markers, like for the URL formatter in markdown: [desc](link), where if some text was selected it would be [desc](). That's the idea. But I'm not so familiar with regexp. Do you think that's a good solution? Later we may have to do a lot of regexp processing and it's better to start with a well-defined system :) [1] About drag and drop for selecting the recipients: as a popup dialog, the window here doesn't allow to use the Contacts panel in the background. This editor dialog actually has a parameter "syncWithUnibox" which is set to True when it's opened from the unibox, but later we would like to be able to edit several messages at the same time (this means pause/resume the composition). For that usecase it's not possible to keep the editor in relation with the unibox. Maybe we can have a menu item to open that editor, not in a popup but as a standard Libervia widget (a panel in a new tab, just like the web browser panel, and without the "back to quick box" button) and then we can drag and drop... Thanks for your attention and cheers! Adrien -------------- section suivante -------------- Une pièce jointe autre que texte a été nettoyée... Nom: Screenshot-1.png Type: image/png Taille: 122903 octets Desc: non disponible URL: -------------- section suivante -------------- Une pièce jointe autre que texte a été nettoyée... Nom: Screenshot-2.png Type: image/png Taille: 133789 octets Desc: non disponible URL: -------------- section suivante -------------- Une pièce jointe autre que texte a été nettoyée... Nom: Screenshot-3.png Type: image/png Taille: 128627 octets Desc: non disponible URL: -------------- section suivante -------------- Une pièce jointe autre que texte a été nettoyée... Nom: Screenshot-4.png Type: image/png Taille: 142758 octets Desc: non disponible URL: From souliane at mailoo.org Sat Sep 28 16:02:53 2013 From: souliane at mailoo.org (Adrien) Date: Sat, 28 Sep 2013 16:02:53 +0200 Subject: [dev] [en] ideas for the rich text editor? In-Reply-To: <5246DA24.80202@mailoo.org> References: <5246DA24.80202@mailoo.org> Message-ID: <5246E18D.1070808@mailoo.org> > markdown: {"italic": "(?P*)(?P*), ... > } > html: {"italic": "(?P)(?P), > ... } > bbcode: {"italic": "(?P[i])(?P[/i]), > ... } I forgot here someting like .* the middle of the groups. Anyway these initial patterns, which are defined for recognition, need to be reused somehow: - to isolate the markers to be added in the composition text area ; - to define the regexp that will be used for text replacement. I hope it's more clear now :) Adrien From mcy at lm7.fr Sun Sep 29 04:14:27 2013 From: mcy at lm7.fr (Matteo Cypriani) Date: Sat, 28 Sep 2013 22:14:27 -0400 Subject: [dev] [en] ideas for the rich text editor? In-Reply-To: <5246DA24.80202@mailoo.org> References: <5246DA24.80202@mailoo.org> Message-ID: <3657127.IFK6uGnIKV@silence> Hi there, Le samedi 28 septembre 2013 15:31:16 Adrien a écrit : > - we need another colour for the toolbox icon when the mouse pass over > it - see screenshot-3, it's not so nice like that... any other ideas > regarding the UI/colour/behavior whatever are more then welcome. Just answering that for now ? I think a darker grey instead of the red would be simple and clean. No need for a fancy colour. Two questions/suggestions I had when looking at your screenshots: 1. I'm wondering what is the behaviour of the lines ?To? and friends when they contain a lot of recipients. I think maybe it would be better to avoid fixed- length fields and instead print the addresses as text all together. Also, the little cross to delete a given address could be hidden by default, unless the mouse is over the address. That's just suggestions, not top-priority of course. 2. What will happen when the user starts typing a message in a given format (say markdown) and then selects another format (say bbcode). Will the text typed be converted from markdown to bbcode? Wouldn't it be simpler to ask the user for a format in the beginning and not allow it to be changed after that? Cheers, Matteo -------------- section suivante -------------- Une pièce jointe autre que texte a été nettoyée... Nom: signature.asc Type: application/pgp-signature Taille: 836 octets Desc: This is a digitally signed message part. URL: From goffi at goffi.org Sun Sep 29 13:23:22 2013 From: goffi at goffi.org (Goffi) Date: Sun, 29 Sep 2013 13:23:22 +0200 Subject: [dev] [en] ideas for the rich text editor? In-Reply-To: <5246DA24.80202@mailoo.org> References: <5246DA24.80202@mailoo.org> Message-ID: <52480DAA.30904@goffi.org> G'day, very exciting screenshots, here are some suggestions: - in my opinion, the rich text panel should not be in a popup, but replace the UniBox. This way there should not be confusion, and you can use Drag'n'Drop more easily. I really like the Rich Text button on the left of the unibox. - I thing the To/CC/BCC panel in screenshot 2 is complex and confusing. I really like the way thunderbird do for the same purpose: you have a "To" field by default, and you click on it to change it with a drop-down list for a "Cc" or "Bcc". - Yes a new color can be useful, maybe a brighter red, or a light grey as already suggested.Anyway it's just a matter of CSS, very easy to do/test. - for the rich text syntax, I think we should change the syntax in the global preferences, and not directly in the rich text window: we usualy use the same syntax all the time, it's just a matter of taste, and once setted, no need to change it each time. In addition, it avoid the question pointed by Mattéo of converting the syntax if you change it. - I think we should not use regex, but the many already available libraries for each syntax, no need to reinvent the wheel. For example, there is a markdown python library which can be used. HTML should be used as a common intermediate syntax: for example if we get a bbcode text and the user prefer markdown, we can convert BBcode to HTML, then HTML to markdown. Of course we need to do some tests to see if the result is not too bad. - we should always send a plain (without any rich text data) version of the text for frontends like primitivus. Anyway, it's the way it's done in XEPs like XEP-0071 I can manage the XEP-0071 and the syntaxes converter, so you can concentrate on the UI part. Thats pretty exciting, we are getting closer to a nice blogging tool :) Cheers Goffi On 28/09/2013 15:31, Adrien wrote: > Hi, > > This message is a bit long because I would like to discuss about a rich > text dialog feature, and how the regexp processing could work. > > I send you some screenshots from the current status of the editor for > libervia. Feel free to share any comment or suggestion! > > Screenshot-1: the input is retrieved from the unibox when you press that > icon on its left (or double click the unibox). Target hooks are > eventually parsed, otherwise the selected chat/microblog dialogs is > taken as the target (if any). This was already implemented for sending > messages. So these information are copied to the editor. By default you > only see the recipient type "Too" and there's an AutoCompleteTextBox to > help you (with values from groups - with prefix @ - and contacts). > > Screenshot-2: user pressed the "Too" button, which displays a new dialog > where you can select none (first value = ""), one or more recipients for > "Too", "Cc" and "Bcc". The reset button restores the values as they > where when the dialog has beem showed. Later we can think of using drag > and drop to make it easier and move from one recipient type to the other > [1]. > > Screenshot-3: "Too" recipient type is always displayed anyway, but "Cc" > and "Bcc" are displayed only if not empty. Recipients are added > regarding what was selected in the previous dialog. There's a selector > to change the format from markdown, bbcode, dokuwiki, html... this is > not well defined yet but we want to show buttons for a restricted subset > of these formats, to not overload the GUI. I don't plan any wysiwyg > stuff, but for later a previous panel would be needed. > > Screenshot-4: message can be send back to the unibox or sent only if > there's a maximum of 1 Too recipient, and no Cc nor Bcc. So finally the > user removed here some recipients and clicked "Back to quick box" or > "Send message" : in any case, the associated chat/microblog dialog is > selected/opened, and the message body copied to the unibox. If he > clicked "Send message", what we expect is done... > > So it's possible to go from unibox to that text editor and vice versa. > > Questions: > > - we need another colour for the toolbox icon when the mouse pass over > it - see screenshot-3, it's not so nice like that... any other ideas > regarding the UI/colour/behavior whatever are more then welcome. > > - we need to store the format of the message to know how to display it. > You know about a XEP to attach such information (and not to convert the > message to HTML, we want to keep it stored as the selected format to > allow further edition of the message)? > > - We obviously won't display HTML in primitivus... I was thinking that > each frontend would have it's associated format and that the text would > be converted dynamically from the backend... I think we can do that by > defining a set a regexp for each format, and this would be used for > everything: > > markdown: {"italic": "(?P*)(?P*), ... > } > html: {"italic": "(?P)(?P), > ... } > bbcode: {"italic": "(?P[i])(?P[/i]), > ... } > > From that it should be possible to know that: > > - when you click the italic button, the text will be surrended by * * or >
    • . > - a message written in markdown to be displayed in html should be > processed to replace * * with . If we are using primitivus which > is set for bbcode, it will be replaced with [i] [/i] > > It should be a bit more complicated to also handle special formatters > like "heading" or "list" which need to more the selected text to a new > line. If no text is selected we may want some information to be written > in between the markers, like for the URL formatter in markdown: > [desc](link), where if some text was selected it would be > [desc](). > > That's the idea. But I'm not so familiar with regexp. Do you think > that's a good solution? Later we may have to do a lot of regexp > processing and it's better to start with a well-defined system :) > > > [1] About drag and drop for selecting the recipients: as a popup dialog, > the window here doesn't allow to use the Contacts panel in the > background. This editor dialog actually has a parameter "syncWithUnibox" > which is set to True when it's opened from the unibox, but later we > would like to be able to edit several messages at the same time (this > means pause/resume the composition). For that usecase it's not possible > to keep the editor in relation with the unibox. Maybe we can have a menu > item to open that editor, not in a popup but as a standard Libervia > widget (a panel in a new tab, just like the web browser panel, and > without the "back to quick box" button) and then we can drag and drop... > > Thanks for your attention and cheers! > > Adrien > > > _______________________________________________ > dev mailing list > dev at goffi.org > http://lists.goffi.org/listinfo/dev > From souliane at mailoo.org Sun Sep 29 16:53:36 2013 From: souliane at mailoo.org (Adrien) Date: Sun, 29 Sep 2013 16:53:36 +0200 Subject: [dev] [en] ideas for the rich text editor? In-Reply-To: <3657127.IFK6uGnIKV@silence> References: <5246DA24.80202@mailoo.org> <3657127.IFK6uGnIKV@silence> Message-ID: <52483EF0.3080105@mailoo.org> Hi, On 09/29/2013 04:14 AM, Matteo Cypriani wrote: > 1. I'm wondering what is the behaviour of the lines ?To? and friends when they > contain a lot of recipients. I think maybe it would be better to avoid fixed- > length fields and instead print the addresses as text all together. Hi, yes that sounds better. First I wanted to keep the ListBox for the user to eventually modify it later (and didn't manage to make the size fit the selected value!), but in the end I set it inactive; in that case there's no more reason to keep the ListBox. > 2. What will happen when the user starts typing a message in a given format > (say markdown) and then selects another format (say bbcode). Will the text > typed be converted from markdown to bbcode? Wouldn't it be simpler to ask the > user for a format in the beginning and not allow it to be changed after that? My plan was to convert it when another format is set, but as you and Goffi suggested, we can fix it using a standard parameter. On 09/29/2013 01:23 PM, Goffi wrote:> G'day, > - in my opinion, the rich text panel should not be in a popup, but > replace the UniBox. This way there should not be confusion, and you > can use Drag'n'Drop more easily. In that case shouldn't we reorganize the components? ___menubar_____________________________ Contacts|_________unibox_______________ |_________status_______________ | | | | dialogs | Otherwise you would hide the contacts when the rich text panel is displayed. If we do like that, we just need to replace one widget by another, also remove the button "back to the quick box" but keep the icon to switch back. > - I think we should not use regex, but the many already available > libraries for each syntax, no need to reinvent the wheel. Sure! I didn't search for these libraries :p But if it doesn't exist I need to do it at least for DokuWiki in order to import my current blog to SàT :) > I can manage the XEP-0071 and the syntaxes converter, so you can > concentrate on the UI part. Ok :) Regards, Adrien From goffi at goffi.org Sun Sep 29 18:54:24 2013 From: goffi at goffi.org (Goffi) Date: Sun, 29 Sep 2013 18:54:24 +0200 Subject: [dev] [en] ideas for the rich text editor? In-Reply-To: <52483EF0.3080105@mailoo.org> References: <5246DA24.80202@mailoo.org> <3657127.IFK6uGnIKV@silence> <52483EF0.3080105@mailoo.org> Message-ID: <52485B40.1050008@goffi.org> On 29/09/2013 16:53, Adrien wrote: > In that case shouldn't we reorganize the components? > > ___menubar_____________________________ > Contacts|_________unibox_______________ > |_________status_______________ > | > | > | > | dialogs > | Hum you're right about the hidden contacts, but I'm not sure how nice it would be with the contact on all the left side like this. I'm affraid that the result would not be that nice, maybe we should give it a try to be sure. An other option is, as you suggested, to put the rich text dialog in the dialogs part, but once again, I'm not sure of the result. An other suggestion, anyone ? > Sure! I didn't search for these libraries :p But if it doesn't exist I > need to do it at least for DokuWiki in order to import my current blog > to SàT :) No worries, we can do import tools easily :) From goffi at goffi.org Sun Sep 29 19:16:47 2013 From: goffi at goffi.org (Goffi) Date: Sun, 29 Sep 2013 19:16:47 +0200 Subject: [dev] [en] ideas for the rich text editor? In-Reply-To: <52485B40.1050008@goffi.org> References: <5246DA24.80202@mailoo.org> <3657127.IFK6uGnIKV@silence> <52483EF0.3080105@mailoo.org> <52485B40.1050008@goffi.org> Message-ID: <5248607F.7010002@goffi.org> An other option would be to move the contacts panel on the left to the rich text dialog when we are in rich editing mode. It's quite easy to do, and would not break the current disposition which I kind of like. On 29/09/2013 18:54, Goffi wrote: > On 29/09/2013 16:53, Adrien wrote: >> In that case shouldn't we reorganize the components? >> >> ___menubar_____________________________ >> Contacts|_________unibox_______________ >> |_________status_______________ >> | >> | >> | >> | dialogs >> | > > > Hum you're right about the hidden contacts, but I'm not sure how nice it > would be with the contact on all the left side like this. I'm affraid > that the result would not be that nice, maybe we should give it a try to > be sure. > An other option is, as you suggested, to put the rich text dialog in the > dialogs part, but once again, I'm not sure of the result. > An other suggestion, anyone ? > >> Sure! I didn't search for these libraries :p But if it doesn't exist I >> need to do it at least for DokuWiki in order to import my current blog >> to SàT :) > > No worries, we can do import tools easily :) > > > > _______________________________________________ > dev mailing list > dev at goffi.org > http://lists.goffi.org/listinfo/dev