Re: GNUstep ROADMAP

[Gregory John Casamento]

Fred,

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

> Hi Gregory,
> 
> 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?

> 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?

> >>
> >> GNUstep 1.0
> >>
> >> 1. it says current base/make/back ... but what about ms-windows  
> >> support ... I'm guessing we want base/make/back fixes/improvements  
> >> for windows as it's not nearly such a good state as unix-style  
> >> systems.  I'm not sure this is a 1.1 issue rather than 1.0
> >> This also ignores the fact that window manager interaction (focus in  
> >> particular) is undoubtedly the biggest problem with current apps, and  
> >> is a backend issue at least as much as a gui issue.
> 
> Here I agree with Richard, we need to solve the focus problem, even if
> it may require big changes in back. We should not freeze back for the
> 1.0 release, rather have all interfaces between gui and back investigate
> if these are suited for what we may need later on.

I agree with this.

> > 
> >> 2. gui seems wildly ambitious (complete coding on all existing  
> >> classes) .
> > 
> > By this I simply mean that we should try to bring all of the classes
> currently
> > in GNUstep GUI up to spec.   Many of them are already there.   I am *not*
> > saying that we should implement all of the Cocoa classes, but only that we
> > should finish the classes which have already been started in the
> repository.
> > 
> > You may also notice that I say that we should remove those classes which
> will
> > likely never get finished or will not be finished for the 1.0.
> > 
> > Is this still too ambitious??
> 
> 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.

> 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.

> You surely remember that missing
> this class was one of the points that made the porting of Book
> impossible about one and a half year ago. For this application even a
> very simple implementation would have been sufficent.
> Taking your words litarally we would need to decide to remove NSCell, as
> I don't see anybody implementing the setEntryType: method for the 1.0
> release.

I'm sure that you know I don't mean that. :)  I'll clarify the Roadmap to
indicate "shell" classes with no implementation at all.   My fault for not
being clear enough.

> Having a roadmap again is great, but the current state of it does not
> help much. To end a bit more constructive let me list the bug numbers of
> bugs that I think should be resolved for 1.0:
> 
> #5871 (Will require a complete redesign of cursor rect handling)
> #6152 (Focus problem)
> #10825 (I have a patch for this, but need to test with all different
> backends)
> #10856 (With this bug I have a very bad feeling, it may be a lot worse
> than it looks like)
> 
> 
> There are of course a lot of other important bug reports, but these I
> would call severe.
> 
> Cheers
> Fred
> 

Later, GJC

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