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 <i...@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.
_______________________________________________ calligra-devel mailing list calligra-devel@kde.org https://mail.kde.org/mailman/listinfo/calligra-devel
