Re: RFC: Removal of Gorm's outline view class editor

[Gregory John Casamento]

--- Quentin Mathé <gnustep-quentin@club-internet.fr> wrote:

> Le 5 déc. 04, à 21:14, Gregory John Casamento a écrit :
> 
> > All,
> >
> > As just about anyone who's used Gorm knows, the outline view can be 
> > used to
> > edit classes.   This is a feature which was present in IB on OPENSTEP 
> > and
> > NeXTSTEP, so it was felt as though this would help people make the 
> > transition
> > from those systems to GNUstep.
> >
> > Gorm also has a class inspector, which is more in-line with the 
> > OPENSTEP
> > "inspector" paradigm.  It is complete and it allows you to edit any 
> > aspect of
> > the class, just as the outline view editor does.
> >
> > This has been suggested a number of times before by different people 
> > both on
> > the list and in #gnustep, but I haven't had time to take it out.   The
> > intention is to simply have a regular outline view or a browser which 
> > would
> > allow the user to look at the classes and use the class inspector to 
> > edit the
> > outlets and actions of the class.
> >
> > There are advantages to doing this:
> >
> > 1) It's more in-line with the OPENSTEP paradigm
> > 2) It simplifies the code in Gorm
> 
> For me it is ok, I never handle the outlet and actions directly with 
> the outline view. What I would like to see is the possibility to do a 
> search in the outline view content in the same way it is possible to do 
> within the class inspector.

How do you add them?  Via the class inspector?

> > Disadvantages:
> >
> > 1) People who've gotten used to the convenience of using the classes 
> > view
> > editor will have to switch to the outline view (this is the other 
> > major reason
> > why I haven't done this).
> 
> Here I don't understand what you mean because it seems to be the exact 
> opposite of what you have just explained above.

No, it's not.  Basically, the NeXTSTEP and older OPENSTEP versions of IB
allowed the user to edit the class in the outline view in the main window of
IB.  Gorm's main window was modeled after this.

> Well in fact, I think 
> you want to remove the parent class choice in the class inspector (aka 
> class view editor, right ?), hmm I think it is not really good idea 
> because it would remove the feature we have currently which permits to 
> reset the parent class of our custom class directly in Gorm unlike 
> InterfaceBuilder.

I don't agree at all with the reasoning of "it's not in IB so it shouldn't be
in Gorm."  There are some other features in Gorm which IB currently doesn't
have.   My purpose with Gorm is to give the users more features than in IB
wherever possible.   In the case of the parent class in the class inspector, a
lot of people were asking for this since it was impossible to change the class
heirarchy in Gorm once the classes were added without deleting all of the
classes and starting over.

Also, what some people would do instead is edit the data.classes file which is
a really really big NO NO and is one of the best ways to cause issues, if it's
not done right.

> Moreover what would be great is to have Gorm synchronizing not only the 
> outlets and the actions with the related class files (header and 
> implementation) but also the parent class we set (in the inspector).

Synchronizing?
 
> Thanks for the RFC,
> Quentin.
> 
> --
> Quentin Mathé
> qmathe@club-internet.fr

GJC

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