[dev] [en] ideas for the rich text editor?

[Goffi]

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<before_selection>*)(?P<after_selection>*), ...
> <other formatters> }
> html: {"italic": "(?P<before_selection><i>)(?P<after_selection></i>),
> ... <other formatters> }
> bbcode: {"italic": "(?P<before_selection>[i])(?P<after_selection>[/i]),
> ... <other formatters> }
>
>  From that it should be possible to know that:
>
> - when you click the italic button, the text will be surrended by * * or
> <li> </li>.
> - a message written in markdown to be displayed in html should be
> processed to replace * * with <i> </i>. 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](<selected_text>).
>
> 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
>