On 11/12/2012 05:10 PM, Inge Wallin wrote:
On Monday, November 12, 2012 16:01:20 Friedrich W. H. Kossebau wrote:
Am Montag, 12. November 2012, 15:19:01 schrieb Inge Wallin:
On Monday, November 12, 2012 01:34:03 Friedrich W. H. Kossebau wrote:
Hi,
I would propose to remove the option "Uncompressed XML Files" for non-
developer buils, or positively said, only enable it for developer
builds. Reasoning:
* only confuses the user ("what is the difference to compressed?")
* cannot be opened in other ODF programs
* results in data without a mimetype, so badly shown in
filemanagers/-dialogs * no/wrong thumbnails (for content.xml or
directory)
Anyone objecting to this? If not, I will finish/prepare a patch and
upload for review which adds support for uncompressed/directory store
formats only in developer-like builds. Such a build I assume if NDEBUG
is _not_ set. Or any better idea what the condition should be?
I am against it for Calligra Author. The reason being that it's a good
format if you want to collaborate on a document and want to be able to
follow the changes in a version control system.
The documentation team decided to use this format for the Author / Words
documentation.
Then I urge you to reconsider your decision:
Together with Jos description of fodt, I can actually consider to reconsider.
:)
* "Uncompressed XML Files" is not defined by any OpenDocument spec, so
calling it a "OpenDocument" format is wrong (and if I was in OASIS I would
even think about pointing to my lawyer stick ;) ). Worse, it is slightly
damaging the OpenDocument movement as this is an unofficial variant which
is not defined anywhere (besides in code) and only supported by one
implementation. Which is what we want to get free from, no?
This is true.
* There is zero support for filesystem-directory-based documents: Documents
saved that way have no mimetype (sadly, I whished directories could have),
thus are not assigned to default handlers or can be shown with a proper
icon. Also thumbnailing is not there. Do you really want to tell you users
they have to deal with that non-comfort?
Not sure what you mean by "zero support" here though. I can de facto both save
and load documents just fine. If you mean "in the OS" then I can agree.
The argument with the VCS I see, but that is more theory at least ATM, no?
No, not at all. However it seems that the same issue can be solved by using
fodt as Jos described even though the lack of RDF can become a problem in the
future. I'd really like to see a solution to that.
Have you ever looked at a diff between a roundtrip? Currently e.g. all xml
ids are regenerated on saving, spoiling a nice diff.
And the real issue here is that VCSs still seem to be only for
textline-based sourcecode files, unable/willing to smartly deal with
file-archives and tree- based structures like XML/JSON.
The xml id regeneration does spoil the diffs. But I think that Calligra
formats the XML nicely enough that a line based VCS is still usable. And I
also don't think that it will make the diffs unreadable and hide the real
content changes.
Better find a VCS which does not do dump diffs on "binary" files but
instead does deep-package diffs where possible.
Now, *this* is really more theory than practice. Suppose I found such a VCS,
would you lobby that KDE changes to it? ;)
But all this said, I don't think we'll use uncompressed odf. It seems the
drawbacks of fodt are not as large as I thought.
Would you go for disable saving and still allow loading? That way you won't
destroy for those few that actually have uncompressed odf files out there.
One could use git hooks that normalize the fodt before committing and
check on the server side that all fodt that is being committed conforms
to the normalization. That is some work initially but would make quite
some people happy.
However, i think xml:id would fall outside of the normalization and in
fact an ODF editor should not change the xml:id unless the element on
which it occurs is copied or split at which point it is not clear
anymore which of the two new elements should receive the xml:id.
Cheers,
Jos
_______________________________________________
calligra-devel mailing list
calligra-devel@kde.org
https://mail.kde.org/mailman/listinfo/calligra-devel
