Re: GNUstep ROADMAP

[Gregory John Casamento]

Fred,

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

> Hi Gregory,
> 
> Gregory John Casamento wrote:
> > --- Fred Kiefer <address@hidden> wrote:
> >> Gregory John Casamento wrote:
> >>>>> If you are a maintainer, please make any changes for your section
> >>>>> that you deem appropriate.
> >> as far as I know we currently don't have a maintainer for GUI, so we all
> >> should comment on that part. And some of us already did in previous mail
> >> exchanges. I remember two points from my mail (yes one tends to remember
> >> ones own entries best) which are not addressed by your list. One being
> >> the stable memory layout of the GUI classes. Why would we call a release
> >> 1.0 if it does not garranty some sort of stable interface? 
> > 
> > Could you elaborate on this point?
> > 
> 
> Sorry, I should have been more explicit. I was refering to missing or
> obsolete ivars for the GUI classes. Have a look at NSResponder, here you
> find a bunch of boolean variables, most of them only used in the NSView
> subclasses. We could decide now to move these ivars to NSView, but we
> should not do so after release 1.0. On the other hand are we missing
> quite some ivars for NSCell, if we want to get fully compatible with
> Cocoa. Richard posted some ideas on how we could still extend classes
> after the 1.0 relase, but we need to prepare them now.

I see what you mean.  Our ivar layout should be stable before we release a 1.0,
I agree.

> >> The other
> >> being the problems with the matrix classes. If we want a "complete
> >> coding" here, we will probably have to wait for GNUstep GUI 1.0 for
> >> another year, or even more. Is this what you want? 
> > 
> > No.  I would rather have a 1.0 release sooner rather than later.  
> > 
> >> All multiple cell
> >> classes are only partial usable, they work for simple exmaples, but when
> >> put in general use they seem to fail.
> > 
> > Could you  go ahead and add details of what needs to be done to the cell
> > classes to the Roadmap where you think it needs to be?
> > 
> 
> I don't have Wiki write access, yes, I should just register.
> The problem itself is obvious, just by looking into the bug database, or
> following the mailing list. The classes NSMatrix, NSBrowser, NSTableView
> and NSOutlineView are usable, but not much more. We may be able to
> improve them, but I don't see a complete implementation for the 1.0 
> release.

Okay.

> >> Removing classes? Which classes are you talking about. At least after
> >> Richards question you should have given an example. There are classes in
> >> GUI that have currently no actual benefit, like NSMovie, but we will
> >> surely implement them later on. Do you want to remove these classes? 
> > 
> > I'm only advocating removal of "shell" classes which currently exist as
> > placeholders for things that are entirely unimplemented.  I'm not saying
> that
> > we should remove a class that has an "incomplete" implementation.
> > 
> > In my view, if we're not going to make a class somewhat usable (i.e. even a
> > skeletal/simply implementation), then we should remove it until the next
> > release.  This is because it's confusing to the developer who ports an app.
>  
> > If the header is there, I'll naturally assume that the class is available. 
> If
> > it's not, then I know it's yet to be implemented.  
> > 
> > NSMovieView and NSMovie, as you pointed out, are excellent examples of
> this. 
> > I'm not sure if anyone is going to have the time to do it before we want to
> > make a 1.0 release.
> > 
> 
> I had a similar discussion with Nicola almost five years ago. At that
> time it was about what unimplemened methods should do, raise a
> condiontion or silently ignore the fact that there is no code. We came
> to the conclusion that outputting a warning would be best.
> When we remove these classes any application that refers to object of
> these classes, even if they are not critical to the overall behaviour of
> the application, wont compile with GNUstep. If we leave the classes in,
> but put warning messages (printed only once) into the empty methods,
> these application work, with minimal functionality missing.
> 
> That's why I used NSMovie as an example. You surely wont be able to
> implement a movie player with GNUstep at the time being, but if your
> application sport only a gimmick movie in the about box, it should still
> work with GNUstep, without displaying the movie of course.

But we're being inconsistent.   What if my application uses NSInputStream,
which currently is not implemented in GNUstep?   Should it not work by the same
token as above?

> >> Or  what if I wanted to contribute a simple minded implementation of
> >> NSearchField in the next weeks? Would we drop that class again, as the
> >> implementation would not be complete? 
> > 
> > So long as the class works on some level, it's okay to leave it in.  I'm
> > referring mainly to those classes which are in GNUstep which are simply
> shells
> > awaiting some kind of implementation and do not work at all.
> > 
> 
> "works on some level", what if I think that not raising an exception is
> already some sort of working? 

I believe you know what I mean.  "Working" means that it should do something
close to what is intended.  

> When I started with GNUstep, most of the
> GUI classes where empty declarations, which needed filling out and that
> was what I did. 

Having empty declarations is okay for something that's in beta, however, for a
1.0, I'm not sure that we should include those classes which are simply empty
declarations.

> If we would have removed all classes without
> implementation at that time, GNUstep would still be rather empty.
> I really would prefer warning messages at runtime from removing classes
> as a whole. Will it be a problem that some applications will compile,
> but later fail to run correctly? I don't think so, as long as we output
> honest warnings about missing code. 
>
> Having a method not implemented
> macro in some GNUstep header file could help here. (What about using
> GSOnceMLog for that?)

I really would rather save the developer time and expense of porting an
application only to have it say "NSException: This functionality is not
currently implemented" at runtime.  If it were me, I would be supremely
frustrated that I spent hours porting something only for it to fail at runtime.

As stated earlier: what about all of those classes in Cocoa that don't
currently have anything in GNUstep?  A good example of these are classes like
NSInputStream, NSOutputStream and all of the Applescript related classes. 
Rhetorical question: Should we add all of these to be complete so that the
developers compilation won't fail?  I, personally, don't think that we should.

> 
> Cheers
> Fred
> 

Later, GJC

Gregory John Casamento 
-- Principal Consultant, Open Logic Corp. (A MD Corp.)
## Maintainer of Gorm (IB Equiv.) for GNUstep.