[Top][All Lists]

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


From: Sheldon Gill
Subject: Re: GNUstep ROADMAP
Date: Sun, 27 Nov 2005 10:51:19 +0800
User-agent: Mozilla Thunderbird 1.0.6 (Windows/20050716)

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 

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


reply via email to

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