Distraction free writing mode

[Pierre Stirnweiss]

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/calligra-devel/attachments/20120907/b2dc9459/attachment.htm>