Hello,
I'm trying to dig again in NGL code and see where we stopped, who is
doing what and so on. On the contributor side, we recently had :
- Brian Hammond : MacOSX test, maintenance and dev (Carbon)
- John Batty : MSVC6 test, maintenance and dev
- Sri : planning many things on NUI, expected to concentrate on theme
support and bindings (
http://sourceforge.net/mailarchive/forum.php?thread_id=2846844&forum_id=9288
)
- Lorenzo : food for thought/fight :)
On the TODO list, a bunch of things. Let's begin with the hotest
topic, nglKernel et al. I'd like to move towards packaging soon (deb,
then RPM), and I can't just pack everything into a monolithic library,
given the different user cases and claims around. I see 3 layers :
1- the 'kludge layer' : most wanted hack, being able to use
'facility' classes like strings, files, etc with the minimum fuss.
Technically, it requires that the nglKernel class be instantiable (it
has some pure abstract methods for now). In this case, the kernel is
reduced to the minimum : it does SysInit(), holds the application log
and console instances, and that's about all. No event loop.
Let's call this 'libngl-core' (no related to current src/core). It would
include :
* ngl3DSLoader.h
* nglBitmapTools.h [image]
* nglCPUInfo.h
* nglConsole.h
* nglEndian.h
* nglError.h
* nglFile.h
* nglFontBase.h [font]
* nglFontLayout.h [font]
* nglIFile.h
* nglIMemory.h
* nglIStream.h
* nglImage.h [image]
* nglImageCodec.h [image]
* nglKernel.h
* nglKeyboard.h
* nglLog.h
* nglMath.h
* nglMatrix.h
* nglModule.h
* nglOFile.h
* nglOMemory.h
* nglOStream.h
* nglPath.h
* nglPlugin.h
* nglQuaternion.h
* nglStream.h
* nglString.h
* nglStringConv.h
* nglTime.h
* nglVector.h
We can refine this with separate parts ngl-font (FreeType dependency)
and ngl-image (PNG and JPEG dependencies). Since with apt splitting
dependencies only gives more power to user without inconvenients, I
expect packaging with the finest dependency granularity. On the Windows
side, I'm not even sure it's a good idea to split NGL at all (unless
they get winapt !).
2- the 'no-gfx layer' : as requested by Timo for a long time. It does
include a generic event loop, but nothing related to the host windowing
API. It should include network, but we don't have it yet. Let's call it
simply 'libngl'. Expected :
* nglApplication.h
* nglEvent.h
* nglInputDevice.h
* nglTimer.h
3- the 'gfx layer' : that's something like libngl-win32, libngl-x11,
libngl-carbon, etc. Contents :
* nglContext.h
* nglFont.h
* nglFontCache.h
* nglVSTPlugin.h
* nglVideoMode.h
* nglWindow.h
There's some debate about nglContext and font rendering going to no-gfx,
for offscreen renderer (like Mesa/SW). My guess is that if I want to
do (eg. server-side) offscreen rendering, I'll obviously do it on 3D
hardware anyway and thus need the windowing API.
Summary :
a) make sure we have proper ascending dependencies between layers (2
on 1, 3 on 2, and that's all), need some tweaking and a new class like a
nglApplicationBase (for layer 2, nglApplication is already fullfilling
layer 3).
b) package the thing for Unix, maybe for Windows (split library) if
maintainers feels like it (and it still only requires the dumb 'F7
press' to have it working).
--
Now for more fun stuff, any order, but mandatory I believe :
- nglConsole : define an abstsract nglConsoleBase, and provides two
console implementations (system, what we have now, and GL-based).
- nglStream : reunify input and output streams into a single
bidirectionnal nglStream class. If you consider networking, you realize
the split was finally a bad idea. Should not change the API drastically,
something like s/ngl[IO]Stream/nglStream/ should fix any NGL-based app.
We can have some transition typedefs.
- nglString : go UTF-8 and std:string based (keep 99% API
compatibility), ie. 'class nglString : public std::string'. I've done
many research and trials on the subject (a few months ago), conclusions
were :
* using literal strings for anything else than a developer audience
is insane; in other words : literals are for errors, logging and such,
they only require ASCII, everything targeted for user should go in
textual databases, gettext or XML-based, whatever (radtools can
help+force you to do this). However crude hackers can still set their
IDE to UTF-8 and output errors in traditional chinese if they feel like
it, it's even fully portable this way.
* _T() macro sucks
* double code path with HAVE_WCHAR sucks hard
* after reading a bunch of std::char_traits implementation
(including MSVC7 one), it turns out that it's worthless to try to
implement a better char-buffer holder. They already include many memory
optmization hacks (including implicit sharing for gcc's libc++) and they
are widely tested.
* we have to interface with the C++ and OS world easily. On the C++
side, either you talk std:string, either you're dead (see Boost
ostracism). On the OS side, most of them can speak UTF-8 fluently (it's
even native for BeOS and Darwin), or at least prefer the char* interface.
- nglImage : the current implementation has a kludgy codec interface,
the worst problem being the need of an offscreen buffer (which should be
bypassed as a default), and thus the lack of streaming support. I
intend to have a tight and easy interface to combine streams, images and
events to have optimal asynchronous and streaming loading (and maybe
saving). No major public API breakage in sight though.
- Font enumeration : this is the last but very important part needed
to complete the new font implementation (nglFont). Should be high
priority so NUI hackers can finally switch the font API.
--
If this can be done for the end of september that'll be great. Important
detail for the planning : I'll be on hollydays from 1st to 25th October,
so I'd better sort most important things out before that date in order
everybody can work on its part freely. You'll notice this mail does not
include anything NUI-related, another pile of work ! :)
