The current LibGGI X target depends on LibGII, which is A) broken by design (shouldn't be required to use eventing in a graphics library), and B) results in a problem where the LibGGI config (which doesn't look for LibGII) succeeds and the build itself fails. I guess that there is no way to share access to an underlying target instance/lock between GGI and GII - that is the only reason I can see for why Brian used events management in a LibGGI target.
A core rewrite is apparently needed, and it will be somewhat heavyweight, but unfortunately the current system is broken and I don't know how it could be fixed unless a common target pool which can be cleanly extended on a extension by extension basis is made. Basic access mux/lock stuff at least for most targets needs to be broken out into a separate sublib management unit, probably with a whole-comprehensive API and resource conversion exposure - the core target lib and helperlib set will need to be able to handle basically every abstraction the target can throw, not just events or drawing commands in the cases of LibGII and LibGGI (which in turn will have to throw a sub-comprehensive core to their extensions).
My first inclination would be to abstract away all the console-type functions into a LibConsole which would be able to "handle" both LibGGI and LibGII as extensions (another one which springs to mind is the original LibGWT design, which wrapped together LibGGI visuals and LibGGI events and thus was "off to the side" of both of them). LibConsole would probably take both "raw" eventing (pure uncooked events, probably a simple bytestream) and "raw" graphics (directbuffer-type mmap()ed framebuffers) in as abstractions, allowing LibGII (cooked and routed eventing) and LibGGI (async graphics buffering and accelerated out-of-band drawing commands) to cleanly extend a much more abstract basis.
Log in to post a comment.