[Top][All Lists]
[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.