Re: Proposal: create XML based .gorm format: .xorm

Gregory Casamento <[email protected]> Wed, 22 Jul 2026 04:51:20 -0400
Newsgroups gmane.comp.lib.gnustep.general
Message-ID <CA+BLX-zjYLUTpWkBrWd8AcFG5MzY11v9v5Ruc9-iW1PtsgaFbQ@mail.gmail.com>
--000000000000fa35b206572f3e6c
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi Richard,

My responses are below. I=E2=80=99m on my phone so I will keep it brief=E2=
=80=A6

Gregory Casamento
GNUstep Lead Developer / Black Lotus, Principal Consultant
http://www.gnustep.org - http://heronsperch.blogspot.com
https://www.openhub.net/languages/objective_c

On Wed, Jul 22, 2026 at 03:29 R Frith-Macdonald <
[email protected]> wrote:

>
> On 22/07/2026 06:35, Gregory Casamento wrote:
> > # Compositional Structure: Nested objects should reflect the actual UI
> > hierarchy (e.g., nesting an |NSView| inside an |NSWindow| tag).
> > # Human-Readable & Editable: This will allow clean version control and
> > manual merging.
> > # Project-Controlled: We dictate the schema, protecting us from externa=
l
> > breaking changes.
>
> I get where you are coming from, but suspect that maybe the only person
> with the background to happily manually edit archives would be you.


You=E2=80=99re probably right.  I ran into issues when working with Keysigh=
t where
more than one person edited a xib and it was easy to work out the conflicts
and other issues.  The xib format does lend itself to this but it=E2=80=99s=
 not for
the faint of heart.

For that reason, I'd suggest that the primary objective should be a
> format which is easily diffable: things are divided up by newlines and
> there are stable groupings of lines between different versions of an
> archive (no cases where a small change in the UI results in a huge
> number of separate changes in the archive) so that changes produced by
> diff are small/clean.


Yes.  That is a consistent problem.  I=E2=80=99ve noticed that sometimes wh=
en
making a simple change it results in massive differences.  It seems as
though interfacebuilder doesn=E2=80=99t preserve the order or ids when savi=
ng xib
files.

So yes, I agree that things need to be at least human readable enough
> that we can make some sense of diffs when we need to.
>
> I don't know if that acctually requires your 'compositional structure'
> objective:  if not, I'd say that's nice to have, but secondary.


Agreed.  I felt as though it might make it more easily understandable.  I
find nib files, while they are xml, difficult to parse (in my head).

I think your third point is an obvious given: who elses schema would we
> want to adopt anyway? I don't know of anything suitable.


Obvious to most.  The reason I made this point is that some have suggested
we use the xib format.  I feel strongly that we shouldn=E2=80=99t do this, =
so this
statement is simply meant to underscore that we should not use the xib
format.

Yours, GC

>

--000000000000fa35b206572f3e6c
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"auto">Hi Richard,<br><br>My responses are below. I=E2=80=99m on=
 my phone so I will keep it brief=E2=80=A6<br><br><div dir=3D"ltr" class=3D=
"gmail_signature" data-smartmail=3D"gmail_signature"><div dir=3D"ltr"><div =
dir=3D"ltr"><div><div dir=3D"ltr"><font face=3D"monospace" style=3D"font-fa=
mily:monospace;color:rgb(0,0,0)">Gregory Casamento<br>GNUstep Lead Develope=
r / Black Lotus, Principal Consultant<br><a href=3D"http://www.gnustep.org"=
 target=3D"_blank" style=3D"font-family:monospace">http://www.gnustep.org</=
a> - <a href=3D"http://heronsperch.blogspot.com" target=3D"_blank" style=3D=
"font-family:monospace">http://heronsperch.blogspot.com</a><br></font></div=
></div><div dir=3D"ltr"><font face=3D"monospace" style=3D"font-family:monos=
pace;color:rgb(136,136,136)"><a href=3D"https://www.openhub.net/languages/o=
bjective_c" style=3D"font-family:monospace;color:rgb(17,85,204)" target=3D"=
_blank">https://www.openhub.net/languages/objective_c</a></font></div></div=
></div></div><div><br><div class=3D"gmail_quote gmail_quote_container"><div=
 dir=3D"ltr" class=3D"gmail_attr">On Wed, Jul 22, 2026 at 03:29 R Frith-Mac=
donald &lt;<a href=3D"mailto:[email protected]">richard@frithmac=
donald.me.uk</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" styl=
e=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);paddin=
g-left:1ex"><br>
On 22/07/2026 06:35, Gregory Casamento wrote:<br>
&gt; # Compositional Structure: Nested objects should reflect the actual UI=
 <br>
&gt; hierarchy (e.g., nesting an |NSView| inside an |NSWindow| tag).<br>
&gt; # Human-Readable &amp; Editable: This will allow clean version control=
 and <br>
&gt; manual merging.<br>
&gt; # Project-Controlled: We dictate the schema, protecting us from extern=
al <br>
&gt; breaking changes.<br>
<br>
I get where you are coming from, but suspect that maybe the only person <br=
>
with the background to happily manually edit archives would be you.</blockq=
uote><div dir=3D"auto"><br></div><div dir=3D"auto">You=E2=80=99re probably =
right.=C2=A0 I ran into issues when working with Keysight where more than o=
ne person edited a xib and it was easy to work out the conflicts and other =
issues.=C2=A0 The xib format does lend itself to this but it=E2=80=99s not =
for the faint of heart. =C2=A0</div><div dir=3D"auto"><br></div><blockquote=
 class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px so=
lid rgb(204,204,204);padding-left:1ex" dir=3D"auto">For that reason, I&#39;=
d suggest that the primary objective should be a <br>
format which is easily diffable: things are divided up by newlines and <br>
there are stable groupings of lines between different versions of an <br>
archive (no cases where a small change in the UI results in a huge <br>
number of separate changes in the archive) so that changes produced by <br>
diff are small/clean.</blockquote><div dir=3D"auto"><br></div><div dir=3D"a=
uto">Yes.=C2=A0 That is a consistent problem.=C2=A0 I=E2=80=99ve noticed th=
at sometimes when making a simple change it results in massive differences.=
=C2=A0 It seems as though interfacebuilder doesn=E2=80=99t preserve the ord=
er or ids when saving xib files.=C2=A0</div><div dir=3D"auto"><br></div><bl=
ockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-lef=
t:1px solid rgb(204,204,204);padding-left:1ex" dir=3D"auto">So yes, I agree=
 that things need to be at least human readable enough <br>
that we can make some sense of diffs when we need to.<br>
<br>
I don&#39;t know if that acctually requires your &#39;compositional structu=
re&#39; <br>
objective:=C2=A0 if not, I&#39;d say that&#39;s nice to have, but secondary=
.</blockquote><div dir=3D"auto"><br></div><div dir=3D"auto">Agreed.=C2=A0 I=
 felt as though it might make it more easily understandable.=C2=A0 I find n=
ib files, while they are xml, difficult to parse (in my head).</div><div di=
r=3D"auto"><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px =
0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" dir=
=3D"auto">I think your third point is an obvious given: who elses schema wo=
uld we <br>
want to adopt anyway? I don&#39;t know of anything suitable.</blockquote><d=
iv dir=3D"auto"><br></div><div dir=3D"auto">Obvious to most.=C2=A0 The reas=
on I made this point is that some have suggested we use the xib format.=C2=
=A0 I feel strongly that we shouldn=E2=80=99t do this, so this statement is=
 simply meant to underscore that we should not use the xib format.</div><di=
v dir=3D"auto"><br></div><div dir=3D"auto">Yours, GC</div><blockquote class=
=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rg=
b(204,204,204);padding-left:1ex" dir=3D"auto"></blockquote></div></div></di=
v>

--000000000000fa35b206572f3e6c--