On Friday, September 07, 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.
Well, not so much discussion as I asking and you replying. :) But yes, it's time to make it into a discussion. > 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
