gnustep-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: GNUstep ROADMAP


From: Gregory John Casamento
Subject: Re: GNUstep ROADMAP
Date: Sat, 26 Nov 2005 07:21:01 -0800 (PST)

Richard,

See below...

--- Richard Frith-Macdonald <address@hidden> wrote:

> 
> On 26 Nov 2005, at 06:05, Gregory John Casamento wrote:
> 
> > Here is the Roadmap:
> >
> > http://mediawiki.gnustep.org/index.php/Roadmap
> >
> > If you are a maintainer, please make any changes for your section  
> > that you deem
> > appropriate.
> 
> Rather than changing anything, I'd like to query some things because  
> things on that page differ from my impressions of what's been  
> discussed on the mailing list, so I guess I'm missing out on stuff.
> 
> 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.

Windows support is coming along, but I don't think it's realistic to expect 1.0
level support soon.

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

> I'm not sure what 'improve printing support' entails

Me neither, but this is something I would consider to be essential for a 1.0
release.

> The 'fix major bugs' is obviously required, but we should decide on  
> what those bugs are

Yes.

> I haven't heard anyone suggesting removal of classes before, and I  
> don't approve of the idea ... rather we should have *big* warnings  
> about works in progress so that people don't try to use them unless  
> they are also willing to work on improving them. (ie clear  
> information in the docs and warnings generated at runtime).
> 
> GNUstep  1.1
> 
> Integrate camaelon into gui ... I think this should be in 1.0 as a  
> matter of practicality ... as far as I can see, this is an easily  
> achievable target, so why not do it soon.
> 
> Integration of WildMenus ... I haven't looked at this, so i don't  
> know, but seems reasonable.
> 
> Breakup of gui and base into component libraries ... I've never heard  
> of this and haven't seen anything saying why it would be at all  
> desirable, let alone worth making into a target.
> 
> Make GNUstep more compliant with the FHS as an option ... this ought  
> to be quite easy ... so why not make it part of 1.0 if it's actually  
> a good 'selling' point?

I wanted to keep the 1.0 as simple as possible.

> Better Windows support ... yes ... but we need to get windows users  
> to define what they need improving

We've already had some comment on the theme.
 
> Nib support in gui and Gorm ... you know best on this ... very good  
> if you can do it in time for a 1.1 release

It may or may not make it for a 1.1 release.

Thanks, GJC

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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]