libraries

[Christopher Browne]

On Sat, 23 Sep 2000 15:39:44 EDT, the world broke into rejoicing as
Terry <tboldt@attglobal.net>  said:
> On Wed, 20 Sep 2000, you wrote:
> > Downloaded 1.5.1 and tries to install - unsatisfied dependencies:
> > 
> > libaspell
> > libpspell
> > libgtkhtml
> > 
> > Looked on the HelixCode site - couldn't find anything similar listed.
> > 
> > Where do I find the above libraries??
> > 
> > Terry
> Let me try again - I don't want all of GNOME - I don't really run GNOME - rig
ht
> now I prefer KDE - GNOME runs like molasses on my h/w. I just want the above
> libraries - updating all of GNOME would take more bandwidth than I have and
> probably more HD than I have available. If updating all of GNOME is the only
> option, then I will have to freeze gnucash at 1.5.0. I know that gnucash was
> designed to run under GNOME, but GNOME isn't the only desktop running under
> Linux, right now GNOME and KDE apps mostly run on either desktop. If they
> diverge then everybody picks their own favorite and we have the GNOME camp an
d
> the KDE camp for the apps - doesn't really sound very reasonable. I know that
> the gnucash devel. list is probably not the best place to vent on this issue,
> but the apps are really the only ones that can convince the two to
> confirm/conform to a single API.

There are several problems with trying to do what you suggest.

a) As you probably know, applications do not "run on the desktop" for
   either Gnome or KDE; applications _use libraries_ from the respective
   system.

   Gnome and KDE applications generally run atop X, and that seems to
   work quite well.

b) There is a crucial dichotomy between Gnome and KDE in that Gnome
   explicitly intends language independence, and has libraries that
   use C conventions so that they may be accessible by all sorts of
   languages, whilst KDE is essentially C++-based.

   GnuCash is largely written in C, which is largely not compatible
   with C++ library conventions.

   Throw in for fun the fact that there is not yet any binary
   compatibility standard for C++; it is not reasonable to expect
   applications to work with libraries that were not all compiled
   by exactly the same compiler.  (GCC 3.0 plans to improve the
   situation, but it isn't out yet, which means that the lack
   of interoperability will persist for a while.)

c) There _is_ no "single API."

   Both KDE and Gnome represent sets of libraries, and thus represent
   a whole _host_ of APIs.

   The "Holy Grail" of Somehow Magically Integrating Them so that
   applications simultaneously are "native" with both seems just
   SILLY.  

   To name just one part, the GUI libraries, GTK and Qt, have fairly
   different sets of abstractions, and it seems more likely that what
   you'd get by trying to "unify" them is not really a unification,
   but rather Still Another API that is neither GTK nor Qt, which
   would probably be inferior to either as it would need to provide
   a "lowest common denominator."

It seems to be _vastly_ more sensible to pick one or the other to
provide the set of services desired for GnuCash.  

If that forces people to keep Gnome components up-to-date in order to
compile bleeding edge versions of GnuCash, that is certainly somewhat
unfortunate; the problem with that is a function of the fact that GnuCash
is making use of Gnome services that are not yet completely mature.

That points out a dilemma that is independent of any of the other things
mentioned thus far; there are two choices:
  a) Use late-breaking (and possibly "periodically broken") Gnome
     services that means that people have to regularly update the "other
     Gnome libs," or
  b) Don't use Gnome services; instead create equivalents thereof 
     that are solely used for GnuCash, which bloats GnuCash, and
     wastes efforts going into Gnome services.

We could do s/Gnome/KDE/g, and get the exact same set of dilemmas.
And the problem that you're hitting is due to GnuCash using the 
"a)" strategy.

Deciding to favor KDE wouldn't resolve the problem; it would merely
mean that rather than worrying about somewhat-experimental Gnome
services where new libs need to get installed regularly, we'd
be worried about experimental KDE services where people would need
to install and compile new libs on a regular basis, which is, in
effect, no change at all.
--
aa454@freenet.carleton.ca - <http://www.hex.net/~cbbrowne/lsf.html>
Rules of the Evil Overlord #25. "No matter how well it would perform,
I will never construct any sort of machinery which is completely
indestructible except for one small and virtually inaccessible
vulnerable spot." <http://www.eviloverlord.com/>