Re: GNUstep ROADMAP

[Sheldon Gill]

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.

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

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


Regards,
Sheldon