Re: GNUstep ROADMAP

[Gregory John Casamento]

Sheldon,

--- Sheldon Gill <address@hidden> wrote:

> Richard Frith-Macdonald wrote:
> > 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
> 
> In my opinion it's definitely a 1.0 issue. A short explanation why:
> 
> * it's high-lighting assumptions and specifications made in the codebase for 
> unix generally and window maker specifically.
> 
> * focus issues are, to varying degrees, problems on KDE, GNOME etc as well
> 
> * add to that window manager interaction. We're not doing well with other 
> window managers.
> 
> I'd but back with gui because the two really do go together. We should
> consider 
> base, make and GUI as three separate categories and focus on what needs to be
> 
> done on each.

Agreed.

> > 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.
> 
> Hear, hear!
> 
> > 2. gui seems wildly ambitious (complete coding on all existing  classes) .
> > I'm not sure what 'improve printing support' entails
> > The 'fix major bugs' is obviously required, but we should decide on  
> > what those bugs are
> > 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).
> 
> "Complete coding on all existing classes."
> "Remove any classes which are not going to be finished for or included in the
> 
> 1.0 release."
> 
> These two seem to be contradictory: we'll complete everything except those we
> don't be completing which we'll remove instead so we can say its all
> complete.

Hehe. :)  This is my fault for not being clear.   

In GNUstep there are some class files which are just placeholders, such as
NSMovie and NSMovieView, which have no implementation.  We need to decide which
of these placeholder classes will get implementations and which ones will be
pushed off into the next release.   Those that will be pushed off to the next
release will be removed from the repository.

I just think that it's wrong to call something 1.0 and deliver classes which
are entirely empty.
 
> I think the map should really be *much* more specific about what needs to be
> done:
> 
> - Documentation
> - alpha/compositing support
> - themes
> - panel auto-sizing and layout
> - architectural changes to improve platform/desktop support work
> 
> > 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.
> 
> Well I can see why some things may be worth separating out. For example, 
> Openstep actually had a separate pdo library. Headers in Foundation, linking 
> and using not a problem. It could help contain areas of functionality. This
> may 
> help in a few ways technically, but also might make maintenance easier in
> that 
> we could allocate a maintainer to a smaller code-base. It may also encourage 
> competing implementations or people assisting in the more specific arenas of 
> interest to them. Right now trying to get involved is somewhat daunting
> because 
> of the size and complexity of the libraries.
> 
> I definitely think that the IconApp (aka 'fiend') code should be entirely 
> separated out and become a loadable-bundle/whatever. It is NeXT desktop 
> specific and should be packaged accordingly. Just as other "features" may be 
> specific to other desktop environments.
> 
> I can see some cause for separating parts of image support so that the
> imaging 
> can rely on different libraries. More front-end/back-end stuff.
> 
> Some are interested in, for example, NSNetService and friends. We should be 
> able to add those in as base extensions.
> 
> Anyway, I don't remember any proposals being put forward and this is
> definitely 
> a dicussion for a different thread.
> 
> > 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've done much on this. Some parts are easier but we can get a whole lot more
> 
> compliant without breakage or significant inconvenience. The level of 
> compliance we can achieve is pretty close to Debian.
> {If we can make it there we can make it anywhere...}
> 
> The only problem in doing this is the amount of configuration involved to 
> tailor the installation. My idea was always for this to be for package 
> maintainers ony.
> 
> Again, specifics should be a different thread.
> 
> > Better Windows support ... yes ... but we need to get windows users  to 
> > define what they need improving
> 
> I have a long list (of not just my own items) so I guess I should put
> together 
> the "Road to Windows"?

Please do, that would be great!

> 
> Regards,
> Sheldon

Later, GJC

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