Distraction free writing mode

[C. Boemann]

On Friday 07 September 2012 11:42:28 Pierre Stirnweiss wrote:
> Time to involve the whole devel list I think:
> 
> Here is roughly where we stand in a discussion (between Inge and me, with
> some public) about distraction free mode.
> I think it is becoming concrete enough and will be of interest for others
> in the ML.
> 
> Pierre
> 
> On Fri, Sep 7, 2012 at 10:16 AM, Inge Wallin <inge at lysator.liu.se> wrote:
> >  So, after the semi-long subthread understanding why my idea wasn't so
> > 
> > good...
> > 
> > >Ok, i will throw here what i am thinking about so it can start a
> > 
> > discussion and perhaps mature into something:
> > >since it is clear that handling this in QTextDocument itself would be
> > 
> > quite a nightmare, my line of thinking is that we shouldn't.
> > 
> > >So:
> > >
> > >- 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.
> > 
> > >- for inline objects, i think this can be handled directly in the
> > 
> > paint/layout process (Camilla?)
> > 
> > > Doing this allows us to use always the same QTextDocumet, also we 
would
> > 
> > not
> > 
> > > need to care about the QTextCursors. There is a bit of a caveat with
> > > the undo stack: it would create undo/redo actions. However, I think we
> > > could actually empty the stack after switching mode and start with a
> > > fresh
> > 
> > stack.
> > 
> > > Also, if we give the user several "styles" shortcut, the user could
> > > still define a default format of these for the DFM mode so he would
> > > still get some visual feedback that the style is properly applied.
> > 
> > Empty the undo stack when switching mode is possible but sounds like a
> > rather
> > severe workaround.
> 
> 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.
> 
> If you do not empty the undo stack, you will get an undo/redo action for
> changing the style profile to DFM mode style.
> 
> On the other hand it might not look completely bogus depending on how this
> switching of mode is presented.
> 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.
> 
> > > The added bonus of the style manager solution is that we could push it
> > > a bit further and define further versions of each style. This would
> > > handle the use case of several editors having different requirements
> > > in terms of styling. For saving, we might be able to do something with
> > > the RDF stuff
> > 
> > in
> > 
> > > the odt.
> > 
> > Yes, this is the feature that I originally wanted to add for the first
> > version
> > of Author but which I scrapped for the same reason that now makes DFM
> > difficult. We called that Document Profiles and it looks like if we can
> > make
> > DFM work then we have almost also implemented document profiles.
> > 
> > > This is obviously very rough thoughts and i probably have not thought
> > > of several problems with it. But as far as I can see it should work.
> > > And
> > 
> > since
> > 
> > > the re-application of styles would only be done at mode change, i don't
> > > think the speed of it (for very large documents) would be much of an
> > 
> > issue.
> > 
> > As always the devil is in the details. So far I have managed to come up
> > with a
> > number of ideas only to have them shot down by the harsh reality. :)  You
> > have
> > much more experience with these things and may be able to come up with
> > something that works.
> 
> 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.
Unfortunately it's very limited and doesn't begin to cover what we will need 
from it.