Re: NSBrowser cleanup

[Serg Stoyan]

Hello Alexander,

> Serg Stoyan wrote:
> > Hi everybody,
> > 
> > Doing some fixes in NSBrowser I come up to idea that NSBrowser needs
> > some reorganization. Let me explain what I mean.
> > 
> > NSBrowser.m has 3 classes NSBrowserColumn,  GSBrowserTitleCell and
> > NSBrowser itself. The idea is to sepearate classes location:
> > - NSBrowser stays in NSBroser.m
> > - NSBrowserColumn goes into AppKit/NSBrowserColumn.h  and
> > Sources/NSBrowserColumn.m- change GSBrowserTitleCell name to
> > NSBrowserTitleCell and put into
> >   AppKit/NSBrowserTitleCell.h and Sources/NSBrowserTitleCell.m
> 
> As Gregory pointed out, that should be GSBrowserTitleCell and
> GSBrowserColumn, and since they're GNUstep classes, the headers should
> go in GNUstepGUI/, not AppKit/.

You and Gregory are right.

> > Notice that NSBrowserTitleCell.h and NSBrowserColumn.h can be
> > installable or not.
> 
> If you know that they aren't going to be installed, they should be
> placed in Source/. If you're unsure, I guess GNUstepGUI/ makes sense,
> but it'd be better to get it right the first time; cvs isn't happy about
> moving files around.

GSBrowserTitleCell and GSBrowserColumn can be a general use classes and go
to GNUstepGUI/. NSFontPanel already use GSBrowserTitleCell.

> > I've done some formatting inside NSBrowser.m also. The basic principles
> > of this formatting are:
> [snip principles]
> > Moreover, when documentation generated, we'll see GNUstep and Cocoa
> > specific methods (if any) separated from OpenStep standard's methods.
> 
> It seems to me that this should be handled by markers in the
> documentation comments (in fact, I thought we already had something like
> that), and the separation should be optional when the documentation is
> generated. (I don't think GNUstep users have any interest in the
> separation; I know I don't.)

That's not problem. I try to make sources more logically organized. If
you don't care about that logic, you see no difference before and after my
changes.

> [snip]
> > What do everybody think about adding such formatting rules info "Coding
> > Style" section of"Coding Standarts" document?
> 
> No. I can't see anything good coming out of trying to be rigid about
> this, and if we're going to do it, I disagree with your principles (and
> Richard's, fwiw :).
> 
> I'd also be very wary of reorganizing existing code, but if you're going
> to do _extensive_ work on NSBrowser, I guess I don't mind if you
> reorganize it the way you like it at the same time.

Is GNUstep is fully OpenStep complaint? If not, why so? What methods in
what classes are unfinished? And so on... To answer these and a lot of
other questions that appear from time to time, I want to structurize
gnustep-gui source code. What makes you so uncomfortable with this?

-- 
Serg Stoyan