Re: GNUstep's release readiness

[Jonathan Gapen]

On Mon, 23 Dec 2002 discuss-gnustep-request@gnu.org wrote:
> As such we have a couple of questions which should be considered:
> 2) What major issues should be addressed before the release?

1) Application Binaries

GNUMail.app/ix86/freebsd/gnu-gnu-gnu/GNUMail:
        libPantomime.so.1 => not found (0x0)
        libgnustep-gui.so.0 => not found (0x0)
        libgnustep-base.so.1 => not found (0x0)
        libz.so.2 => /usr/lib/libz.so.2 (0x28123000)
        libxml2.so.5 => /usr/local/lib/libxml2.so.5 (0x28131000)
        libiconv.so.3 => /usr/local/lib/libiconv.so.3 (0x281f4000)
        libm.so.2 => /usr/lib/libm.so.2 (0x282cf000)
        libgmp.so.3 => /usr/lib/libgmp.so.3 (0x282ec000)
        libc_r.so.4 => /usr/lib/libc_r.so.4 (0x28302000)

     This issue with shared objects never got sorted out completely.
It's just a simple matter with the makefiles, too:  The GNUstep libraries
should be linked against the shared objects they use, and the application
binaries should be linked against the shared objects they use, and only
that set.  Back in the bad old days, when the GNUstep Makefile system
caused the application binary to pull in all the shared objects used by
the GNUstep libraries, I would have to re-build *all* of the GNUstep
programs on my system from source every time I re-configured the GNUstep
core.  The situation is better now (esp. since libxml vs. libxml2 got
sorted out), but those little links to unneeded shared objects (libiconv
and libxml2 above) will torpedo all GNUstep programs if the user installs
differently-configured GNUstep libraries, or upgrades any of those other
libraries.
     To put it another way, "RPM dependency hell" is bad enough already so
why give every GNUstep program dependencies it doesn't need?  (Of course
this problem isn't unique to RPM.)
     Actually, this raises the question of consistency in GNUstep
configurations.  IMHO, the GNUstep API should not change due to changes in
the underlying configuration.  It should support XML, all of the various
character sets, et cetera always or not at all.  The unreliability of the
API leads to both developer and user frustration.  The developer has to
provide an alternate means to support those features when the GNUstep
libraries do not, and also does not have a way to check at run-time
whether certain calls work.  The result is that the API is useless to
developers working on programs intended for end-users.  On the flip side,
it can lead to end-user frustration if a program uses those APIs, but the
installed GNUstep system doesn't support those features.
     The UTF-8 methods of NSString are my pet example.  These are
documented API methods that may or may not work depending on whether
gnustep-base was configured to use libiconv.  And they're important
methods, too, as the use of UTF-8 is growing.  If the developer of an
application did not build in alternatives, then the application may fail
in bizarre, unexpected ways for the user.  If the developer did include
alternative UTF-8 support, well, what's the point of having those methods?
(Thank you, RFM, for fixing this one!)

2) Application Robustness

     Before a major release of the current GNUstep applications, they've
got to become much more robust.  I have run into major flaws in many
applications due to the lack of sanity-checking on external information.
     Terminal.app:  Blows up if given invalid font specifications in user
defaults because it does not check that it got a valid object back from
NSFont.
     MusicBox.app:  Blows up if I press 'play' without loading a file, as
it does not check to see if any file has been loaded.
     GWorkspace.app:  Uses integers instead of booleans to store boolean
values in user defaults, explicitly checks NSGlobalDomain for some values
so I can't override them on a per-application or single-run basis, and
also blows up if presented with certain invalid user defaults values.
     GNUMail.app:  Does not handle unexpected IMAP conditions and errors
(such as a dropped connection) well.
     All such instances must be cleaned up before any release intended for
end-users and not other developers.

3) Fit and Finish
     The GNUstep system still seems rough around the edges for users.
Applications don't handle the lack of gdomap gracefully, they occasionally
put up bizarre exception alerts, and they're quite prone to dumping core
with no explaination.  Also, the menu handling is a bit wonky yet.  Some
menus appear as they should on application startup, some appear as a title
bar and add items one by one, and some (Ink.app mostly) have their menu
appear on top of the previous app's menu.
     The x11 backend, at least, doesn't handle fonts well yet.  On certain
variable-width fonts it uses the maximum advance for every glyph.  It also
does not degrade gracefully, so if the required fonts are not available,
GNUstep apps show up without any text at all.

     Those are the big ones.