Re: "Jaguar" additions

[Alexander Malmberg]

[snip]
> > Creating a colorspace in GNUstep would be as simple as creating a
> > dictionary with the correct keys and values (I've attached an updated
> > file that has those filled in). Then pass that dictionary to
> > -GSSetFillColorspace: or -GSSetStrokeColorspace:
> 
> OK, so the backend has to keep track of existing color spaces to avoid
> creating a new one everytime a color space is set on a context. When one
> of the above methods is called the backend would have to look up if an
> existing color space with the same parameters already exists and set that
> on the context. This implementation is different than would be needed for
> the Quartz API, where the user passes a reference and the above method
> just sets that on the context.

But a Quartz interface could easily be implemented on top of this, and
it makes it easier for someone to use the interface directly. The
complexity is moved to the backend, but that's a good thing :).

> > > Me either, see above. It seems the current tendency is to implement
> > > graphics features in the gui however they should be implemented in the
> > > backend and allow backends to implement them as they see fit. This applies
> > > to at least NSAffineTransform, NSBezierPath, NSColor, NSFont,
> > > NSGraphicsState, probably more. (They could probably be moved to gsc.)

I didn't mean that I was uncertain about these. What I meant was that I
don't see anything wrong with returning opaque structures for
references, eg. to colorspaces, or images, or patterns..., nor do I see
any reason why doing things that way would me much better. However,
whenever possible, I think that the 'structures' used when the user
wants to pass data to the backend should be standard objects,
implemented in -base or -gui.

[snip]
> Backart is somewhere in between in this respect. It is mostly a gsc based
> backend in that is it uses the implementations from gsc for most things.

gsc provides basic management for states (ie. managing the stacks,
creating and destroying them), color, and paths. (And I am considering
doing path handling myself in ARTGState for speed reasons (not using
NSBezierPath), but I'm not sure if it'd be worth it.)

> But it is similar to the gslib backend in that it uses the libart
> implementations for paths (and possibly other things)

Only paths. [OT] It is a bit misleading that it's called back-art, since
libart only is a minor part of it (in fact, an average app probably
doesn't use the libart parts of back-art at all), but it seems to have
stuck. At least it seems to have good marketing properties ;).

> and freetype for
> fonts. For these it also needs to do a mapping between gsc paths and
> libart paths and NSFonts and freetype fonts.

- Alexander Malmberg