If and when you want to write a new persistence layer of the framework is of course up to you. If you want to seriously work on this let me know, I’m certain your are going to miss some methods you need to access the layout data… 
We may even talk about you having write access to the repository.
I don’t believe, that making things right means compatibility must be broken. But ok - I don’t know enuf to know it right.
Well, maybe it could be solved by duplicating some interfaces (don’t like that idea)… but it would be a long term project, slowly migrating from one system to the other giving everyone enough time to react and rewrite their parts.
I very hope, the different formats will only be on disk and not in your framework code.
Let me answer this with an image:
All of the formats have different roles, in which they are especially efficient:
[ul]
[li] Actual layout: well, there is no way around that one 
[/li][li] Perspective: a very simplified version of the actual layout, without the gigantic overhead of Components, code that paints stuff, etc… a client can create a few million perspective elements, you better don’t try that with the actual layout.
[/li][li] Intermediate: If some property is in the intermediate format, then it is important. Anything not in the intermediate format is not important. It is designed to be easily written into a file, but modifying the layout when it is in this format is really hard.
[/li][li]Xml / bytes: self explanatory I hope
[/li][/ul]
Here you definitely took me wrong. I did not talk about ObjectOutputStream or DataOutputStream - I really want to handle the Complexity in the ObjectWriter. So you use i.e. ObjectWriter.write(„path of property“, DockableProperty) or the like. If it is not appropriate for your code, you might consider split your classes into compound classes, where one class is the saveable and the surrounding class is the functionality. That way you simply put the saveable in the write-call.
Yes, I misunderstood you.
It seems you put a lot of work in your persistence layer What I call the „intermediate format“, is close to your ObjectWriter. The intermediate format is „the saveable part“ and nothing else. In order to get from actual layout to a file on the disk, I need 2 steps. The ObjectWriter would need only 1 step.
But because the framework needs to perform some operations on stored layouts (guessing the type and location of Dockables whose factory is added after the layout was loaded; removing obsolete placeholders), I need to store and access the layout in memory anyways. Looking at the image of formats, using your ObjectWriter would result in different arrows, but the same amount of boxes at the same places.
My current app using docking frames is very small - only 4 dockables in one frame.
I’m very astonished, that the stored layout uses 4k diskspace in binary format. Looks quite a lot to me.
Nice app. Und wie ich sehe, hätten wir uns auch auf Deutsch unterhalten können. I can easily explain how 4k data is gathered: Let’s assume the usual identifier for a factory, a CStation or a CDockable consists of about 20 characters. So each stored identifier is going to need about 40 bytes.
→ 4 Dockables, 6 Stations: 400 bytes alone to assign factories to these elements.
→ Another 10*40=400 bytes alone to store the identifiers of these elements.
Each station has a layout, and the layout contains „placeholders“ - identifiers to elements that were moved around.
→ Assuming you clicked around a bit: 3 placeholders per dockable, another 12*40=480 bytes.
→ The layouts themselves usually are serialized maps, maybe another 200 bytes / station: 1200 bytes (that was guessed)
Each Dockable stores one location per extended-mode („minimized“, etc). Each location contains a placeholder.
→ 4 * 4 * 40 = 640 bytes
By now we are at 3120 bytes, and I did not even start of speaking about delegate factories, automatically created nested DockStations, PlaceholderMaps for removed nested DockStations…
I suggest you store the layout as xml file and have a look at it, I always think it gives a good impression on what is going on inside the framework.
You are arguing on a technical level, and most of the things you say I agree with. But for me it looks like you are ignoring one important non-technical factor: human resources.