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
_______________________________________________
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev