On 20.05.2012 00:49, Riccardo Mottola wrote:
Hi All,
On 05/14/12 15:47, Riccardo Mottola wrote:
Hi,
I need to save a gworkspace gorm file (DesktopPrefs) with a version
previous to current. Gorm gives the opportunity to select 0.10.3 (what
version does this refer to? Should we add a newer one?)
I can save it and reopen it. However if I reopen it with "really" a
previous release (in this case our last release, base 1.24 and gui
0.22) it won't open, vingi an int vs. unsigned int exception
I think our we have a compatibility problem with the encoded archive.
Can that be fixed? Thank you.
can we work on this? It is not only a nasty bug (we should for
convenience always be able to save a correct version, else the version
feature in Gorm is useless and deceiving) but it is also blocking a good
and long needed release of gworkspace.
Gregory says it is not a Gorm problem but a gui/base compatibility
archiving problem.
How can I help identifying what got incompatible so it can be fixed?
Hi Riccardo,
I looked into your problem more deeply and there were two issues
blocking you. One was the change Richard made in the way we store the
item count of an array in archives. Richard improved on that an now
archives store this count in a forward compatible way in most cases,
this means old code will be able to read arrays in archives written by
newer code.
The other issues hasn't been resolved and is unlikely to get resolved.
In the last release we changed the way some classes get archived. This
has happened for almost all gui releases over the last years and there
isn't much we can do about it. We try to implement the new archiving
code in a way that allows us to read old archives, but there is no way
to allow old code to read newer archives, when the format changes.
Now the simplest solution for you would be to switch over to keyed
archives, in this case from Gorm to NIB files. This format is backward
and forward compatible most of the time and for this reason should be
preferred over non-keyed archives.
If this isn't an option for you, your could try to build a hybrid
version of archiving for the classes that are needed for you specific
Gorm files. That is, you move the -encodeWithCoder: back to the last
version and keep the -initWithCoder: method on the new state. This
requires that you find all the classes where this is needed and is is
also a bit dangerous, as you will write out the objects with the wrong
version number if you don't change that number as well.
If you are very sure that your only problem are the unsigned/signed
changes that Sebastian made a while ago, then there is another option,
you could remove the sign check from the base code, or rather make it a
warning. (This is in NSUnarchiver.m in the function typeCheck) This may
even be a change we could keep. But don't expect this to resolve all
your issues with forward compatibility. For example NSTableColumn and
NSTextView were also changed in a incompatible way. If I remember
correctly, this was to fix bugs that you reported.
Fred
_______________________________________________
Gnustep-dev mailing list
[email protected]
https://lists.gnu.org/mailman/listinfo/gnustep-dev
