gnustep-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: gmodel loading appears to be broken


From: Fred Kiefer
Subject: Re: gmodel loading appears to be broken
Date: Wed, 01 Sep 2010 11:07:39 +0200
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; de; rv:1.9.1.11) Gecko/20100714 SUSE/3.0.6 Thunderbird/3.0.6

Am 31.08.2010 02:44, schrieb Gregory Casamento:
> On Mon, Aug 30, 2010 at 5:28 PM, Riccardo Mottola <address@hidden> wrote:
>> Not to sound nasty, but I proposed to deprecate gmodel files to you and Greg
>> several times.  GModel remained in place only for Cenon!
> 
> I'm all for this.  I proposed deprecating gmodel a few years prior to
> suggestions for deprecation by anyone else. :)   Cenon was just about
> to be released and, as I recall, the only reasoning for keeping gmodel
> support in GNUstep was to support Cenon only and any other apps which
> might need it.

When it comes to GModel bashing remember that I am the guy who actually
broke it.
You two may have decided to deprecate it some time ago, but I made it
unusable :-)

>> I offered the guys from Cenon
>> several times help to transition to clean GORM files and proposed the idea
>> of moving gmodel loading into an optional bundle. The guys never ever
>> replied. Now the latest version transitioned to NIB only and it looks
>> clearly inferior on GNUstep now. AS far as I know, Gregory wrote them too.
>> I found that never replying was quite rude... We should just deprecate it,
>> optionally moving the ocde in a bundle to retain the capability of Gorm
>> loading gmodels for conversions of programs we don't know of.

GModel loading is already in a separate bundle and was so for years.
Only only
tiny class is directly in gui and that was the one I broke (and fixed).

> I would be okay with this.  There are some good reasons to remove
> gmodel support at this point:
> 
> 1) The category which implements the initWithGModel and
> encodeWithGModel methods doesn't cover all of the classes which
> currently exist in GNUstep and is buggy/incomplete for many of the
> ones it does cover.
> 2) There are significant memory leaks in the GModel code.
> 3) The GModel format is no longer needed since we now have XML based
> nibs and XML based XIB files.

Yes, all these are very good reasons why we should deprecate GModel, but
it is enough to state this in the release notes of the next GNUstep gui
release. No source code changes should be done for now and in one or two
years time we can discuss moving that tiny class into the GModel bundle
and maybe putting the whole code into a separate project away from gui.
Before that we should at least rename all the panel loading methods in
GNUstep gui that have GModel in there name (_initWithoutGModel:). Even
better try to reimplement them with Gorm or NIB files.

Fred



reply via email to

[Prev in Thread] Current Thread [Next in Thread]