2010/4/6 Jon Cruz <jon@...18...>:
That is, we need to make it easy to work with multiple views ("desktops") on a single document with everything consistent. Allowing for rotation is a view-specific twist that I think can help with considering where and how to separate coords.
I think being able to create multiple desktops for the same document is a huge misfeature. It introduces considerable additional complexity for little benefit. All applications I have ever used work like this: 1. You open a document. 2. The document stays in memory until you save and / or close it. 3. If you open the same document in a different window, those two copies are not connected in any way. 4. If you save one of them, the second window can complain that the file was modified, and offer to reload in such case (if the app is smart enough). If you don't reload, the document should be considered unsaved, e.g. the Save toolbar item should bring up the Save As dialog.
W dniu 6 kwietnia 2010 03:21 użytkownik ~suv <suv-sf@...58...> napisał:
Inkscape 0.47+devel r9295:
Newly created horizontal guides don't stay where they are dropped but immediately move to the mirrored location. Origins of vertical guides move to the mirrored position. Diagonal guides can't be positioned as intended either, guides converted from objects don't align with the objects.
It's because the "namedview" element is stored without conversion to SVG coordinates.
Here's how I would like to fix this and the 3D Box problem. 1. Introduce a file called document-compatibility.cpp. 2. Introduce versioning of documents' editing information. The editing info version will not be tied to the Inkscape version - it will be just a number. We start at editing info version 0, which is defined as what Inkscape 0.47 uses. Every subsequent version is defined as a series of transformations from version 0. 3. document-compatibility.cpp contains a function called upgrade_document(), or something like this. It takes an Inkscape::XML::Node to the root of the SVG and upgrades the document to the latest editing info version. 4. upgrade_document() reads the editing info version from an extra attribute in the SVG root (it can be called inkscape:document-version). It executes a series of transformations on the XML document to bring it in line with what the current SP tree expects. 5. When you want to make a change in the XML, you bump the current version by one, add the necessary XML transformations and update all relevant SP tree code to only recognize the new XML. If you did everything correct, the SP tree code doesn't need to know about any document format other than the latest one.
Why this is good: 1. Upgrade is performed before the SP tree is constructed. This means the SP tree doesn't have to retain backwards compatibility junk indefinitely. 2. We have a well defined backwards compatibility mechanism, rather than a collection of hacks. 3. We have a clear way forward to fix long time blunders like flowtext.
Why this could be bad: 1. No semantic help from the SP tree. 2. ???
Regards, Krzysztof