[NGL-devel] NGL status and previsions

[Vincent C. <v....@ze...>]

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 ! :)