gnustep-dev
[Top][All Lists]
Advanced

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

Re: RFC: Removal of old (deprecated) template classes.


From: Gregory John Casamento
Subject: Re: RFC: Removal of old (deprecated) template classes.
Date: Sun, 21 Nov 2004 10:25:59 -0800 (PST)

Fred,

--- Fred Kiefer <address@hidden> wrote:

> Gregory John Casamento wrote:
> > I am going to remove the templates in GSNibCompatibility.[hm].   These
> > templates are old and some of them don't work correctly (this is why they
> were
> > deprecated in the first place).  Their functionality has been entirely
> > superceded by the new template classes in GSNibTemplates.
> > 
> > First, a small explaination of what templates do.   They allow the user to,
> in
> > Gorm, select a custom class associated with a real class (such as a window
> or a
> > table, or any other object or widget at all) and, when the .gorm is saved,
> the
> > template is saved instead of the real object (it in fact contains the real
> > object) by the NSArchiver.  This allows the template to morph the class
> into
> > the subclass which was specified by the user in Gorm when it is loaded into
> the
> > application which contains the custom class the user wanted to use.
> > 
> > The older templates need to be removed so that it will clear the way for
> the
> > MOSX templates (for compatibility with keyed MOSX nib files) some of which
> have
> > the same name as the deprecated ones in GNUstep.  Although the code there
> is
> > clearly marked as deprecated, Fred Keifer has modified the code for
> > NSWindowTemplate in the GSNibCompatibility files for this purpose.  My plan
> is
> > to remove the code which was used for loading these classes from a .gorm
> file
> > and move Fred's code to someplace else and ultimately remove the
> > GSNibCompatibility.h and .m files.
> > 
> 
> Removing the old templates is fine for me. But why remove the whole 
> file? It could just be reused to store the new templates and helper 
> classes needed for keyed decoding. That way the code I added could stay 
> where it is. :-)

I actually thought about this.  I don't see a problem with keeping the same
file.  The name sort of fits anyway.  I will send you a modified file to see
what you think.  Also, there's a cleaner way to implement what's there which
I've been meaning to discuss with you.
 
> > Under normal circumstances, I would simply remove this code, but as this
> change
> > has the potential (minimal) to impact some rather old applications that
> might
> > still use these old templates, so I thought it was important enough to
> bring up
> > here.   I, however, would like to reserve the right to make the final
> decision
> > regardless of the consensus.
> > 
> 
> This sounds a bit strange, Gregory. When there are valid objections to 
> the removal than you cannot reserve the right to do it anyway. I don't 
> think that such will show up, but if they do,we have to accept it. 
> Otherwise why start a discussion at all?

True, my apologies.  I guess I wanted to impress upon people that this needs to
happen. :)  Naturally, I will discuss any well reasoned objections.  If they
are valid, we should determine what the course of action should be then.

> > I'm not going to do anything right away.  I just want to open the
> discussion at
> > this point.
> > 
> 

Thanks, GJC

=====
Gregory John Casamento 
-- CEO/President Open Logic Corp. (A Maryland Corporation)
#### Maintainer of Gorm for GNUstep.




reply via email to

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