[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Nuke libgmodel?
From: |
Jonathan Gapen |
Subject: |
Re: Nuke libgmodel? |
Date: |
Mon, 05 Feb 2001 14:11:23 -0600 |
Gregory Casamento wrote:
> Actually, loginpanel does use gmodels. Something has changed recently and
> gmodels are now broken. I was tempted to find the problem, but I believe
> that
> our time is better spent trying to get GORM.app working and .gorm files read
> correctly.
That's my inclination, as well.
> Perhaps we should consider a nib2gorm program.
That's, well, an interesting proposition. A NIB is an archive of an
object tree, where each object archives its internal state. So is a
.gorm file. To have one program to convert between the two, you'd need
to compile gnustep-base and gnustep-gui on OPENSTEP/MacOS X. This would
include code which would load up the NIB, and then describe the object
tree by getting objects' attributes through their method interfaces.
Then, it could use this description of the object tree to construct an
analogous object tree using GNUstep objects, and then archive that tree
into a .gorm.
The intermediate format described above is actually available, it's
called a gmodel! So, you could do a nib2gorm program, if you wanted to
compile the GNUstep libraries on OPENSTEP/MacOS X. I think it's easier
just to write a gmodel2gorm on the GNUstep side, with a gmodel as the
OPENSTEP -> GNUstep intermediate, as I suggested.
--
All persons, living or dead, are purely coincedental.
Re: Nuke libgmodel?, Gregory Casamento, 2001/02/05
- Re: Nuke libgmodel?,
Jonathan Gapen <=