|
|
Capture d’écran (201).png (159,484 bytes) |
|
|
please, if you make changes to the way item IDs work, make them not editable! the label a user can attach to an item should be just that, a label, not the id used by scribus internally. this is also valid for all resources like colors and styles! (that is: never use user input for internally referencing resources... not translate the references). |
|
|
Yes, I agree with you :) I know they're internally used and shouldn't be changed by user, but it's really annoying Scribus decides to change them all after every save :( If nobody can have a look to this "issue", I could eventually fix it myself (and propose a patch), but since I never modified Scribus code, I prefer to let experts do that :) About your comment "this is also valid for all resources like colors and styles", there are also problems with styles and colors that are internally referenced in SLA file using user input, which is I think a bad idea :s |
|
|
+1 I keep Scribus documents under version control (using Git). Version control becomes much more useful when files are diffable and mergeable. Thanks to the human-readable XML format, Scribus documents would be very easy to diff and merge, if it weren’t for these changing ItemIDs. |
|
|
Indeed :) I really don't understand why ItemIDs are not kept :( |
|
|
I looked into this and the problem is, that the ItemID is not some value stored alongside other values inside the class, but it's rather derived from the qHash of the pointer to the instance. This way, the ItemID will change, when the location in memory changes - which is obviously the case when loading an old .sla file. IMO, the ItemID should really be a value stored inside each instance which gets randomly initialized on creation. |
|
|
If that is so, then why does the ItemID need to be written to the XML file at all? (I haven’t looked at the code.) |
|
|
I think some other tags/options could be referencing them by ItemID but I'm not sure :( |
|
|
Yes, there are definitely references to ItemIDs in the sla. However, I did not see a relevant reading from the sla of those on first glance - but I need to check more thoroughly again. |
|
|
Changing ids every time document is Saved prevents any usefull diff or version control. Keeping them would enable that. |
|
|
+1 for that topic :-). As a work around, I wrote a perl script that temporary sets all ItemID = "0" before I commit my changes. |
|
|
Setting all ItemID to 0 prevents reopening the saved files @emmkei isnt ? how do you envision the use of such id-stripped files ? |
|
|
@JLuc: From my experience, Scibus is opening these files as well as with changing the IDs to any other value (I hope I did not miss anything...). Therefore I would also raise the question from cwalther: Why do we need these values in the sla-file? |
|
|
I really thought ItemID were referenced by other items, but in my own SLA files, it's not the case, each ItemID is used only once ;p |
|
|
I also don't see any refs |
- Anonymous
