Time to involve the whole devel list I think:<br><br>Here is roughly where we stand in a discussion (between Inge and me, with some public) about distraction free mode.<br>I think it is becoming concrete enough and will be of interest for others in the ML.<br>

<br>Pierre<br><br><br><div class="im">On Fri, Sep 7, 2012 at 10:16 AM, Inge Wallin <span dir="ltr"><<a href="mailto:inge@lysator.liu.se" target="_blank">inge@lysator.liu.se</a>></span> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div class="im">
So, after the semi-long subthread understanding why my idea wasn't so good...<br></div><div>
><div>>Ok, i will throw here what i am thinking about so it can start a discussion and perhaps mature into something:<br><br>>since
 it is clear that handling this in QTextDocument itself would be quite a
 nightmare, my line of thinking is that we shouldn't.<br>
><br>>So:<br>><br>>- for text styling, I think the best place to handle this
 is in the (kotext) style manager. it could function like this: each 
style in the style manager (including the default style) would have 
several versions. one of these would be >the DFM style. When entering DFM
 mode, we would re-apply the styling on the entire document with the DFM
 properties, when we exit DFM mode we would then re-apply the "normal" 
version of the styles.<br>
><br>>- for inline objects, i think this can be handled directly in the paint/layout process (Camilla?) <br></div></div></blockquote><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">

<div><div class="im">
><br>
> Doing this allows us to use always the same QTextDocumet, also we would not<br>
> need to care about the QTextCursors. There is a bit of a caveat with the<br>
> undo stack: it would create undo/redo actions. However, I think we could<br>
> actually empty the stack after switching mode and start with a fresh stack.<br>
> Also, if we give the user several "styles" shortcut, the user could still<br>
> define a default format of these for the DFM mode so he would still get<br>
> some visual feedback that the style is properly applied.<br>
<br>
</div></div><div class="im">Empty the undo stack when switching mode is possible but sounds like a rather<br>
severe workaround.<br></div></blockquote><div><br>Well the problem is 
that the solution i propose isn't ideal either. It also modifies the 
"content" which it shouldn't for switching visualisation mode IMHO. 
Applying different "style profile" to the document is a different story.<br>
<br>If you do not empty the undo stack, you will get an undo/redo action for changing the style profile to DFM mode style. <br><br>On the other hand it might not look completely bogus depending on how this switching of mode is presented.<br>


If the switching of mode is integrated in the UI as one of the different
 style profiles (ie: original, DFM, editor1, monochrome, colourful, 10' 
screen, ...), switching the style profile can be regarded as a 
modification to the document by the user and so justify an undo/redo 
action.<br>
<br><br></div><div class="im"><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div><br>
> The added bonus of the style manager solution is that we could push it a<br>
> bit further and define further versions of each style. This would handle<br>
> the use case of several editors having different requirements in terms of<br>
> styling. For saving, we might be able to do something with the RDF stuff in<br>
> the odt.<br>
<br>
</div>Yes, this is the feature that I originally wanted to add for the first version<br>
of Author but which I scrapped for the same reason that now makes DFM<br>
difficult. We called that Document Profiles and it looks like if we can make<br>
DFM work then we have almost also implemented document profiles.<br>
<div><br>
> This is obviously very rough thoughts and i probably have not thought of<br>
> several problems with it. But as far as I can see it should work. And since<br>
> the re-application of styles would only be done at mode change, i don't<br>
> think the speed of it (for very large documents) would be much of an issue.<br>
<br>
</div>As always the devil is in the details. So far I have managed to come up with a<br>
number of ideas only to have them shot down by the harsh reality. :)  You have<br>
much more experience with these things and may be able to come up with<br>
something that works.<br>
<span><font color="#888888"><br></font></span></blockquote></div><br>There
 is perhaps a way, that i started to explore for change tracking without
 much success (but i didn't pursue this very long). It seems possible to
 specify additional formatting at layout stage (QTextLayout class I 
think). I don't know how usable this is. Camilla should know much more 
than me about this one.<br>