Re: bundlelisation of the backend

[dejaeger]

NP> Well - if the backend becomes a loadable bundle - smile - that's nice -
NP> then the library combo can be simplified, can't it ? - we remove the last
NP> part of the combo, because executables and libraries do no longer depend
NP> on it.  At run-time, the gui itself will decide (when it initializes
NP> itself in code triggered by NSApplication +sharedApplication), basing on
NP> command line arguments or user defaults or shell variables, which backend
NP> to load in.  Other gui libraries (apple one) do not need the backend part
NP> of the library combo anyway, so it becomes totally useless.  And now
NP> that's very nice.

I agree. And we don't have to choose a specific backend when we build
a binary package (see Debian). It should improve the development of the
DPS backend (more people will try it).

I see some others improvements that can be done in this way. We could
have a structure like the one in XFree86 or ghostscript : a minimal
backend only have to implement a very small set of primitives. All the
others could be implemented in gui or in a common layer of every
backend. AND, for performance reason, an optimized backend can
override (if it wishes) the default implementation of the other
primitives. For example, NSDrawButton (in xgps) doesn't depend on the
X layer but only on primitives such as DPSrectfill, DPSlineto. This
code can be in gui. Of course, xdps will overide this simple
implementation because it can draw a button more efficiently.

This should speed up the development of the win32 backend. (at least
we could have a working version with little work). (Personaly, i'm
interested in a pure opengl backend but it's another story).

>> What about static and profiled executables?

NP> Well - loading the backend as a bundle looks like meaning you can't create
NP> a totally static executable - I mean you could at most have a statically
NP> linked executable, a statically linked bundle, but still you load the
NP> bundle at runtime...

well, I will #ifdef my code in such a way that the backend could be a
bundle or not.

NP> Rather (or is it the same problem) - what about executables making X calls
NP> (for xgps) directly ? They need to be linked with X directly otherwise you
NP> get undefined symbols. <well you could put the code accessing X in a
NP> bundle, and then load the bundle after the backend bundle, but we want it
NP> to be easier than that>. <when I talk about X I just mean `the underlying
NP> graphical libraries used to implement a backend'>

NP> One idea which pops to my mind - not sure it is workable or good though -
NP> is that we could make a clear separation between executables only
NP> accessing gui stuff through the gui and special ones making occasional X
NP> calls directly.  Then, we would have two different backend bundles.  One,
NP> linked with all the X libraries.  That one is the standard one.  Standard
NP> executables only using the gui just load that backend at run-time.  They
NP> depend in no way on X.  Instead, special executables containing X calls
NP> will be linked directly with the X libraries.  To avoid conflict, these
NP> executables will then load a special version of the backend bundle, which
NP> is not linked itself with the X libraries.  The bundle can contain
NP> undefined symbols, so that doesn't look like a problem.

I don't think it is necessary to do so complicated things. As far as I
tested, there is no problem if an application is linked with X11 and
loads the xgps backend (I admit that it didn't work yet, but it is
because i didn't initialise all my pointers to backend's
functions. But the bundles loads fine and the dynamic linker does'nt
complain at all). And of course, the xgps bundle is linked with X11
too.