#36 Wysiwym

[VialeF]

Feature rather than bug.

Dear Mr.

I dislike to mix text and code, especially when I am writing scientific texts requiring attention.
Do you know wymeditor that implements a wysiwym approach.
http://www.wymeditor.org/en/

I'd like such kind of approach even so not always perfectly implemented. You could also display marks into the left margin.

Sincerely

[karlabbott]

Logged In: YES
user_id=1029645
Originator: NO

This is definitely an interesting proposition. I didn't quite get what was going on in the wymeditor. Would you please elaborate more on this concept and how it would fit into Wyneken?

Regards,
Karl

[VialeF]

Logged In: YES
user_id=1408577
Originator: YES

I am confused.
I have forgotten to write that the site has got a demo.
It is certainly better to look at the demo before further discussions.
Regards.

direct link supposed to work but depend on your browser.
http://demo.wymeditor.org/demo.html

Comment on their approach.
I do not believe that include some WYSIWYG displays are an absolute need at first (or not at all). However I'd like the fact that information about style is by side of the text. The side menu is also a good idea that avoid novice to type wrong code, or allows to bypass learning code at first.
Basic style (what is named containers) are well displayed.
Numbered list (look at the icons) is really appealing too (try to create it, switch to numbered or bullet style, or return to normal text).
What editor spells "classes" are good counterexamples because it does not always display the link between the visual transformation and the applied classed, user can be confused. In this case, you have not real advantage over pure WYSIWYG. It is exactly the point that should be work before implementing such kind of editor...

Concerning Wyneken.
One can imagine to display tags into the margin for all codes that apply to a whole paragraph.
Icons of quotes, important, code... could display additional classes.
Color variation of the background could distinguish bloc of text.

So... just prospective...
Regards,
Fabrice

[VialeF]

Logged In: YES
user_id=1408577
Originator: YES

I have looked at different software that favor structured content.
- Amaya (html editor) http://www.w3.org/Amaya/
- Serna (xlm editor) http://www.syntext.com/products/serna/index.htm
- Basket note pads (note editor) http://basket.kde.org/
- Wymeditor (Online html editor) http://www.wymeditor.org/en/

- Wymeditor display nicely the content and the information relative to the paragraph. The great advantage is to see the content easily (like a wysiwyg) while displaying info on structure (H1, H2...). The difference of display between styles must not strictly represents the style properties, but rather should help users differentiate the organization of the contents.
- Amaya and Serna display a hierarchical view of thee content that could help resolve technical problems.
- Serna graphically displays tags inside the text and that seems too obtrusive compare to simple color syntaxing and code http://www.syntext.com/products/serna/screenshots/tag_mode_l_2r.png
- Basket Note Pads is closed to the concept I promote. Each text bloc is treated into a bloc with a menu which helps selecting the corresponding style. Futhermore, blocs can contain other blocs (that could apply to character styles). It's best to try the interface with a single column page.
- Amaya display contextual side panels that facilitate the editing and fit well in widescreen monitor. E.g. One can imagine the same thing applied to the bibtext list of references.

So, in resume, the ideal goals could be :
- the user should concentrate on content while not disturbed by the form (like Wysiwym Editor).
- the structure should promote rapid reorganization or style modification (like Basket note pad).
- a side panel with tabs should display the tags, icons, style...related to the edited content.

Regards
Fabrice.

[karlabbott]

Logged In: YES
user_id=1029645
Originator: NO

So this is definitely an interesting proposition and something to consider. Looking back at what you have summarized:

So, in resume, the ideal goals could be :
- the user should concentrate on content while not disturbed by the form
(like Wysiwym Editor).

I strongly agree here. I am quite inspired by a particular text editor for OS X (I forget its name) that is just a blue screen that you can type on and then later you do your formatting. I'm also quite inspired by WordPerfect 5.1 for DOS, as honestly, that has been the best editing experience (sorry vim) that I have had to date in terms of writing content. vim is a much better programming editor though.

I have started to experiment with PyQt4 (As Qt4 is pretty cool) and am heavily working with QTextDocument, QTextEdit, QTextCursor, and trying to understand QTextBlock. My current thought is that using those widgets together could actually produce the desired result. And yes -- this means that wyneken *might* move from gtk to qt.

- the structure should promote rapid reorganization or style modification
(like Basket note pad).

I haven't done a tremendous amount here. If you look at how notebooks function in wyneken 0.5, they are actually based on how Basket manages the baskets of notes. Most notably, with wyneken 0.5:

* We no longer care about file names.
* Wyneken autosaves.
* You can easily move between note pages without having to enter a new dialog.
* You can move between notebooks without having to enter a new dialog.
* etc.

- a side panel with tabs should display the tags, icons, style...related
to the edited content.

I'm not quite sure that I agree with the side panel concept here. Perhaps this is due to the way that I think about Wyneken documents. I see something much more like "Reveal Codes" from the WP5.1 days as being a better solution. The concern I have there is just maintaining a map between the content document and the actually .wyn file that gets fed to wyn. I'm also starting to wonder if in some way, this isn't inventing/reimplementing part of xml. I don't think that it has to be that, but xml does have some nice conventions for separating the content from the form.

I definitely need to do some more thought, and put together some mockups and more sample code of what this would look like.

This concept has certainly been on my mind. As it stands right now, I see wyneken as useful, but just another editor/language to write in. I don't necessarily see a compelling reason to use Wyneken. Implementing something like this that could then allow a complete newbie (see massive help from the gui) to use Wyneken, would make it a compelling platform.

Karl