Menu
▾
▴
ngl-devel — NGL developers discussion list
You can subscribe to this list here.
| 2002 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(1) |
Jun
(9) |
Jul
(35) |
Aug
(16) |
Sep
(13) |
Oct
(16) |
Nov
(11) |
Dec
(12) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2003 |
Jan
(2) |
Feb
(5) |
Mar
(2) |
Apr
(18) |
May
(88) |
Jun
(68) |
Jul
(3) |
Aug
(1) |
Sep
(1) |
Oct
(2) |
Nov
|
Dec
|
| 2004 |
Jan
(1) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Sage S. <ma...@ms...> - 2004-01-07 13:03:51
|
Dear All, I will be implementing a scriptable themeing and layout system into NUI. = The themes are could be written planned to be composed of Lua5 scripts = with support for whatever pixmap/vector types that are supported by = NGL/NUI. Support for GLSL for themes is under consideration. AFAIK NGL does not = yet support GLSL. (More info on GLSL: = http://www.opengl.org/documentation/oglsl.html) For the initial phase, the following is planned: - Themeing and Widget classes/interfaces - Lua5 bindings for NGL and NUI - Incorporation of scripting support into XML UI descriptions What the above means is that NGL and NUI API will be made available via = Lua. Thus you will be able to code your application and design your UI = via Lua. Support for themes via Lua scripts would be added to the = themeing classes. E.g: You could write widget behaviour and appearance = code in Lua and load it via the themeing classes. The actual specifications and methods as to how to it will be implemeted = will be posted to this mailing list. So keep your eyes open! The reason behind using Lua5 as the defacto scripting system is because = of implementation simplicity and standardizing on one language. Python = was suggested but due to certain thread locking issues, we had to = consider = alternatives.(http://www.python.org/doc/faq/library.html#can-t-we-get-rid= -of-the-global-interpreter-lock) Also Lua5 is faster than before! Check out the average scores: = http://dada.perl.it/shootout/craps.html Any feedback you may have please post to this list. No personal insults = please! -SageX |
|
From: Vincent C. <v....@ze...> - 2003-10-28 01:06:27
|
Chetan Dandekar wrote: > > When I run bootstrap, I get this: > ---------------------- > I am going to run ./configure with no arguments - if you wish > to pass any to it, please specify them on the ./bootstrap command line. > > You should update your `aclocal.m4' by running aclocal. > src/Makefile.am:178: Libtool library used but `LIBTOOL' is undefined. > src/Makefile.am:178: The usual way to define `LIBTOOL' is to add > `AC_PROG_LIBTOOL' > src/Makefile.am:178: to `configure.in' and run `aclocal' and `autoconf' > again. > ./bootstrap: line 113: ./configure: No such file or directory > ----------------------- > > I have libtool installed and LIBTOOL defined as /usr/share/libtool Hello, sorry for the insane delay, I'm back from holidays. Can you provide versions of your GNU/Linux distro, autoconf (autoconf --version), automake (automake --version) and libtool (libtoolize --version) ? |
|
From: Chetan D. <che...@as...> - 2003-10-08 18:43:32
|
Dear All, I am trying to compile ngl that I got from the CVS. The steps I need to follow are: ./bootstrap ./configure make make install When I run bootstrap, I get this: ---------------------- I am going to run ./configure with no arguments - if you wish to pass any to it, please specify them on the ./bootstrap command line. You should update your `aclocal.m4' by running aclocal. src/Makefile.am:178: Libtool library used but `LIBTOOL' is undefined. src/Makefile.am:178: The usual way to define `LIBTOOL' is to add `AC_PROG_LIBTOOL' src/Makefile.am:178: to `configure.in' and run `aclocal' and `autoconf' again. ./bootstrap: line 113: ./configure: No such file or directory ----------------------- I have libtool installed and LIBTOOL defined as /usr/share/libtool Thanks, - Chetan |
|
From: Lorenzo P. <pas...@ul...> - 2003-09-18 23:47:03
|
There was a discussion about generating wrappers for Opengl extensions, I found an interesting initiative, I didn't checked very extensively the coverage but I think this could be a good starting point for a better (dynamic) support of extensions until the comming of opengl2 http://www.delphi3d.net/download/metaglext.xml Lo. |
|
From: Vincent C. <v....@ze...> - 2003-08-18 17:05:27
|
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 ! :) |
|
From: Sebastien M. <me...@me...> - 2003-07-28 14:37:14
|
Vincent Caron wrote: >Sritharan said: > > >>Dear Guys, >> >>I am developing a multiplayer client using NUI under windows. I would like to know if >>you guys have any roadmap in store for NGL/NUI. I would like to contribute to NUI/NGL >>development as well. >> >> Very cool news :). As Vincent allready said this is the summer holydays also for NGL and NUI :). I have some big changes for NUI in the pipe (some of them have been around for 3 month but I never found the time to finish them). The bigest change is the addition of a higher level window manager abstraction over nuiWidget/nuiContainer. Most existing programs will not be affected by this change (well nothing than a well placed search and replace will not fix :) ). The next thing I want to add in NUI is support for minimal redrawing of the UI. I have a working prototype of this but I have to finish the Window Manager stuff to get it working right. I also have a good bunch of bug fixes for the Mac version of NGL and NUI. There is a lot to invent/test with NUI and one thing that is still missing is animation support in the UI. We started thinking about this with Vincent some time ago but if anybody wants to take care of it and present a bunch of ideas/code I'd be very happy. Here is a small list of cool things to do with NUI: - add complex clipping from a nuiShape (using the stencil buffer). - add animation support. - simplify the event system (ideas?). - think about scripting support (need to simplify the API?). - add new effects (bump mapping? better blurring?). - add a lot of widgets!!! - reimplement text support with the new nglFont class. - ... :). Sebastien |
|
From: Vincent C. <v....@ze...> - 2003-07-28 13:22:56
|
Sritharan said: > Dear Guys, > > I am developing a multiplayer client using NUI under windows. I would like to know if > you guys have any roadmap in store for NGL/NUI. I would like to contribute to NUI/NGL > development as well. Some help is certainly welcome. Since you're running Windows, some testing and maintenance on the MSVC project files (especially the VC6 ones) is one of the thing we seek. NGL development is quite stalled this summer, for various reasons, but we're still available for comments. There's a kind of mini-roadmap in the TODO file. I think the only item that does not require intimate knowledge of NGL is the rewrite of nglString on UTF-8 grounds. You might also be interested in networking support, but you'll notice that this item as been moved to mid-term because 1) it depends on the I/O streams reunification, 2) we felt we had some rough corners to fix first. We also obviously need bugfixes (doc and code), etc, you name it :). Just find an itch to scratch, ask your questions, submit your code, and so on. > I understand that your license for NUI and NGL is LGPL. Does that mean that I could > use it for developing commercial apps? As long as I link my applications to NGL > dynamically I do not have to expose my client source code? That is right, only modifications of the libraries themselves must be redistributed under LGPL-compatible terms, this does not affect the licensing of your program. |
|
From: Sritharan <sr...@de...> - 2003-07-28 08:16:50
|
Dear Guys, I am developing a multiplayer client using NUI under windows. I would = like to know if you guys have any roadmap in store for NGL/NUI. I would = like to contribute to NUI/NGL development as well. I understand that your license for NUI and NGL is LGPL. Does that mean = that I could use it for developing commercial apps? As long as I link my = applications to NGL dynamically I do not have to expose my client source = code? My sourceforge handle is SageX. I would like to join your project but I = need to know where you guys are heading with NGL/NUI. Mucho gracias, -Sri |
|
From: Vincent C. <v....@ze...> - 2003-06-24 23:49:09
|
>> - explicitely link against the .lib files in the libngl{_static}.dsp
>> project settings, then we only need this single project in
>> libngl{_static}.dsw. And a NGL based can drag the libgnl project into
>> its workspace and see it linking automagically against the 3rd party
>> libraries.
>
> I much prefer the option (2).
So does Meeloo after I consulted him (10 ten days ago, I confess :)). We should make
that the default policy of VC6 project files in NGL. For now we're statically linking
those 3rd party libs so it's easy, all a NGL-based project has to do will properly
setup its include and lib path to have NGL at reach. We'll see for fully modularized
DLL support later ...
BTW, I might have broken the Windows build, I'm not always confident about the
namespace issues when you have a class defined in a class scope, eg. :
class nglFontBase {
class GlyphBitmap { ....};
bool GetBitmap (GlyphBitmap& rBmp);
};
bool nglFontBase::GetBitmap (GlyphBitmap& rBmp, uint Index)
{ }
As far as I can tell, this is standard compliant code, but I'm not sure VC6 gets the
'GlyhBitmap' parameter scope right in the latter (implementation) declaration. However
this is mandatory for any compiler (and I think I stick to it) :
nglFontBase::GlyphBitmap nglFontBase::GetBitmap(uint Index)
{ }
--
sig(h)
|
|
From: Vincent C. <v....@ze...> - 2003-06-24 23:38:41
|
Vincent Caron said: > > - nglStringConv.h : went nicely > - nglVideoMode.h : looks a bit more ugly, but still acceptable > - nglFont1.h : I went for the fastest and often ugliest solutions, this class is not > here to stay anyway > - nglFont/Base/Cache : TODO. Well, finally done. Looks like I didn't break anything, the examples still run out of the box. Some parts of the protected API have changed, but they are only used by the current renderer and cache implementations. It means that we at last don't have any dependency on 3rd party headers in NGL. Now I need to clean up the ngl.h and ngl_config.h which does not make sense, and actually connect it to autoconf (we'll have a hardcoded profile for non-autoconf'ed builds). |
|
From: Vincent C. <v....@ze...> - 2003-06-13 01:26:06
|
> This work will have to be done in : > > - nglFont/nglFontBase (USE_FREETYPE) : okay, text editing skills > - nglStringConv (USE_ICONV, USE_MLANG) : maybe I can cope with some simple opaque > types > - nglVideoMode (USE_XF86VIDMODE) : same trick as nglFont > - nglMath (USE_FAST_FLOAT_CONVERSION) : actually only affects header inline code, so > is okay here Removed dependencies with 3rd parties from these headers (in CVS) : - nglStringConv.h : went nicely - nglVideoMode.h : looks a bit more ugly, but still acceptable - nglFont1.h : I went for the fastest and often ugliest solutions, this class is not here to stay anyway - nglFont/Base/Cache : TODO. This part is much more tricky because these class have shared interfaces using FreeType structures. I'll take more time to do it properly, this class _is_ here to stay :) |
|
From: Vincent C. <v....@ze...> - 2003-06-12 15:46:27
|
>> For the dependencies on other libs dependencies, it will require some >> work, mainly on FreeType (the image codecs have a well separated >> internal interface). C++ can quickly become ugly when we have to use >> tricks to hide internal things, and I only stuffed this info in >> 'private:' for now. If you have any suggestion to make this move not >> too painful, I'm interested. > > The "pimpl" C++ idiom seems apropos. > http://www.gotw.ca/gotw/024.htm OK, this is the only thing that came to my mind, seems it's a fair solution. This work will have to be done in : - nglFont/nglFontBase (USE_FREETYPE) : okay, text editing skills - nglStringConv (USE_ICONV, USE_MLANG) : maybe I can cope with some simple opaque types - nglVideoMode (USE_XF86VIDMODE) : same trick as nglFont - nglMath (USE_FAST_FLOAT_CONVERSION) : actually only affects header inline code, so is okay here |
|
From: Vincent C. <v....@ze...> - 2003-06-12 15:21:14
|
Hello, I wrote a Perl script to help with some maintenance issues on MSVC project files, and mainly the problem of synchronisation (between VC6/VC7 and other builds). I needed it for another project, but it turns out that it will mostly useful for NGL in my case. Some people had a sneak peek two weeks ago, I fixed a few things and made it 'official'. http://zerodeux.net/projects/vctool/ ChangeLog from previous version : 0.1.1 * added output alpha-sorting * added support from vcproj's ExcludedFromBuild property * 'In ... not in ...' -> 'Built in ... not in ...' NB: looks like I should add Apple PB support now :) |
|
From: Brian H. <br...@ab...> - 2003-06-12 14:48:15
|
> > - Using UNIX versions for Carbon implementations of a few NGL > > interfaces (nglFile, etc)... for now. > > OK, I guess it means file paths can't use Mac style 'volume:' and we > can't read ressource forks, something like that ? Yes, that's right. Paths are UNIX style. I can update this if it's needed. It's pretty low on the priority list for now. > Would it be far fetched to find or provide these 3rd party libraries as frameworks too > ? Just a suggestion though ... I would rather not do that. That'd be quite a lot more work to maintain, and I am pretty sure it's not really required. The end-users of NGL (other developers, not end-users of NGL applications) should need only NGL.framework and the PB template to create NGL applications. That's my goal. > > This is doable as long as the NGL headers do not reference > > implementation details. I was kind of surprised that the > > nglFontBase.h includes FreeType headers (USE_FREETYPE). I would > > think that for a public interface, it should be free of any impl > > details... IMHO that's much cleaner and also allows the OS X NGL > > developers to not have to install _any_ external libs (and their > > headers) to build NGL apps. I have a lot of notes on this if anyone > > is interested. > > Yes, this is ugly, we actually delayed the configuration part for a > long time. It once had a better support (18 months ago ?). > > For the USE_ macros, they will all definitively move in a private and > non-distributed header, and since you need it now we'll try to do this > quickly. Ah, great! > For the dependencies on other libs dependencies, it will require some > work, mainly on FreeType (the image codecs have a well separated > internal interface). C++ can quickly become ugly when we have to use > tricks to hide internal things, and I only stuffed this info in > 'private:' for now. If you have any suggestion to make this move not > too painful, I'm interested. The "pimpl" C++ idiom seems apropos. http://www.gotw.ca/gotw/024.htm Thanks, Brian Hammond [http://threeminutehero.com] |
|
From: Timothee B. <tt...@id...> - 2003-06-12 12:42:51
|
Yes. I already use a metadata description for doom. Only for the regular GL API though (I generate bindings on the fly with that, allowing implicit dependency / explicit dlopen or function overrides for logging). Putting the extension APIs in a metadata format is the way to go I think (XML sounds sane). Does this get us rid of License issues? Do we generate glext.h on-demand from there? TTimo On Thu, 12 Jun 2003 14:33:11 +0200 (CEST) "Vincent Caron" <v....@ze...> wrote: > Timothee Besset said: > > Sadly, with the 'extraction' method you need a glext.h that would have all > > the extensions (I have one, but it's Licensed and I can't give it away). > > Yes, and this is desesperatly needed. SGI's glext.h (which is in Mesa) has this stupid > GLX license which is way to prohibitive to distribute modifications, I've encountered > the same problems with ATI and NVIDIA's licences on those include files. This is also > why I can't distribute a glext.h with NGL and we have this #warning in ngl.h. I > consulted a GNU licence guru : "this is a sad mess" and Brian Paul "please don't drag > me into that licence business". I also comited the typo bug (in the vertex program > ext) to SGI's bugzilla and alerted Leech 8 months ago, the bug is still in the > official glext.h. Sigh. > > Conclusion : someone _has_ to write an alternative glext.h with 1) up-to-date infos, > 2) and under all liberal license like BSD. The problem is that the file structure is > so trivial that rewriting it and copying it is almost the same. I think the idea is to > write the registry with our own description language and generates the file from it > (just like SGI actually do, except nobody understands - and use - their registry > maintenance scripts). > > > > ------------------------------------------------------- > This SF.NET email is sponsored by: eBay > Great deals on office technology -- on eBay now! Click here: > http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5 > _______________________________________________ > NGL-devel mailing list > NGL...@li... > https://lists.sourceforge.net/lists/listinfo/ngl-devel > -- |
|
From: Vincent C. <v....@ze...> - 2003-06-12 12:33:17
|
Timothee Besset said: > Sadly, with the 'extraction' method you need a glext.h that would have all > the extensions (I have one, but it's Licensed and I can't give it away). Yes, and this is desesperatly needed. SGI's glext.h (which is in Mesa) has this stupid GLX license which is way to prohibitive to distribute modifications, I've encountered the same problems with ATI and NVIDIA's licences on those include files. This is also why I can't distribute a glext.h with NGL and we have this #warning in ngl.h. I consulted a GNU licence guru : "this is a sad mess" and Brian Paul "please don't drag me into that licence business". I also comited the typo bug (in the vertex program ext) to SGI's bugzilla and alerted Leech 8 months ago, the bug is still in the official glext.h. Sigh. Conclusion : someone _has_ to write an alternative glext.h with 1) up-to-date infos, 2) and under all liberal license like BSD. The problem is that the file structure is so trivial that rewriting it and copying it is almost the same. I think the idea is to write the registry with our own description language and generates the file from it (just like SGI actually do, except nobody understands - and use - their registry maintenance scripts). |
|
From: Timothee B. <tt...@id...> - 2003-06-12 12:14:38
|
Sadly, with the 'extraction' method you need a glext.h that would have all the extensions (I have one, but it's Licensed and I can't give it away). The glext.h you can find in driver packages / mesa-glx-dev etc. either contain the NVidia extensions only, or the ATI extensions only, etc. And it's not possible to do something like: #include "nv-glext/glext.h" #include "ati-glext/glext.h" TTimo On Thu, 12 Jun 2003 14:08:24 +0200 (CEST) "Vincent Caron" <v....@ze...> wrote: > Hello, > > Some links to complete your section "Is there another libs that can be used to load > OpenGL extensions ?" : > > * The OpenGL Extension Wrangler Library > http://glew.sourceforge.net/ > Tediously updated by hand > > * NGL C++ OpenGL framework > http://ngl.sourceforge.net/doc/ngl/classngl_context.html > http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/ngl/ngl/src/core/glext/ > Extraction from glext.h with a Perl script, Doxygen doc tag generation and > cross-linking to ARB docs. > > > > ------------------------------------------------------- > This SF.NET email is sponsored by: eBay > Great deals on office technology -- on eBay now! Click here: > http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5 > _______________________________________________ > NGL-devel mailing list > NGL...@li... > https://lists.sourceforge.net/lists/listinfo/ngl-devel > -- |
|
From: Vincent C. <v....@ze...> - 2003-06-12 12:08:34
|
Hello, Some links to complete your section "Is there another libs that can be used to load OpenGL extensions ?" : * The OpenGL Extension Wrangler Library http://glew.sourceforge.net/ Tediously updated by hand * NGL C++ OpenGL framework http://ngl.sourceforge.net/doc/ngl/classngl_context.html http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/ngl/ngl/src/core/glext/ Extraction from glext.h with a Perl script, Doxygen doc tag generation and cross-linking to ARB docs. |
|
From: Lorenzo P. <pas...@ul...> - 2003-06-12 08:56:55
|
I guess the main disadvantage of #1 is that dependencies infos becomes
a 'workspace' data so when you include one of those dsp in an other
dsw (ie: your first ngl application workspace) you loose the
dependency infos.. I've personnally concluded that explicit relative
path in dsp's (../include and ../lib) are a must, and the only way to
keep projects consistently up and building upon any situation...
Lo.
----- Original Message -----
From: "John Batty" <JP...@da...>
To: <ngl...@li...>
Sent: Thursday, June 12, 2003 9:29 AM
Subject: RE: [NGL-devel] Re: MSVC6 build fixes
> Vincent said:
> > On ngl/libngl{_static}.dsp/dsw, correct me if I'm wrong but do we
have the
> choice
> > between these two solutions :
> >
> > - drag 3rd party libs (png, jpeg, zlib, freetype) .dsp into
> libngl{_static}.dsw as
> > dependencies. Then we don't have to set explicitly the 'additional
> libraries' list
> > (libpng.lib libjpeg.lib ...) in libngl{_static}.dsp, MSVC will do
the
> linking for us.
> > The major inconvenient being that then for every application
using NGL,
> we must drag
> > libngl{_static}.dsp AND the 3rd part libraries projects into its
> workspace.
> >
> > - explicitely link against the .lib files in the
libngl{_static}.dsp
> project settings,
> > then we only need this single project in libngl{_static}.dsw. And
a NGL
> based can drag
> > the libgnl project into its workspace and see it linking
automagically
> against the 3rd
> > party libraries.
> >
> > If I'm right, then your patch brings up a mix of the two
situations. I
> remember we
> > already went on these questions a looong time ago...
>
> I was a bit confused by the project dependencies (I haven't used
workspaces
> with
> multiple projects before!). Thanks for the clarifying thoughts...
>
> I much prefer the option (2). It gives rather better encapsulation
of the
> ngl build,
> and if you ever add more libraries into ngl we only have to update
the ngl
> project.
> Can you remember what you concluded last time you discussed...?! I
seem to
> remember
> most examples using option (1) - which implies that you went in that
> direction.
>
> If we can agree on the preferred method, I can go through and make
all the
> examples
> consistent.
>
> Cheers,
>
> John
>
> -----Original Message-----
> From: Vincent Caron [mailto:v....@ze...]
> Sent: 11 June 2003 23:47
> To: ngl...@li...
> Subject: [NGL-devel] Re: MSVC6 build fixes
>
>
> Hello John,
>
> I finally take the time to go through your patch !
>
>
> > Most changes are workspace/project file tweaks (.dsw/.dsp).
>
> On ngl/libngl{_static}.dsp/dsw, correct me if I'm wrong but do we
have the
> choice
> between these two solutions :
>
> - drag 3rd party libs (png, jpeg, zlib, freetype) .dsp into
> libngl{_static}.dsw as
> dependencies. Then we don't have to set explicitly the 'additional
> libraries' list
> (libpng.lib libjpeg.lib ...) in libngl{_static}.dsp, MSVC will do
the
> linking for us.
> The major inconvenient being that then for every application using
NGL, we
> must drag
> libngl{_static}.dsp AND the 3rd part libraries projects into its
workspace.
>
> - explicitely link against the .lib files in the libngl{_static}.dsp
project
> settings,
> then we only need this single project in libngl{_static}.dsw. And a
NGL
> based can drag
> the libgnl project into its workspace and see it linking
automagically
> against the 3rd
> party libraries.
>
> If I'm right, then your patch brings up a mix of the two situations.
I
> remember we
> already went on these questions a looong time ago...
>
>
> > - benchapp.cpp: Removed mpFont references from destructor.
mpFont is not
> > initialized or used anywhere else.
> > - benchapp.h: Removed declaration of mpFont member variable.
>
> Indeed, applied.
>
>
> > - ngl_all.h: Removed #include "nglFont2.h" and #include
"nglInput.h"
> (these
> > files don't seem to exist). Your call on what to do with this
(are these
> > old files?).
>
> This has already been updated in CVS two weeks ago, but your patch
is right
> (we also
> added nglFont1.h and nglInputDevice.h since then).
>
>
> > I have also created new .dsw/.dsp files for the nui examples.
> > I have tested all of them except the OggVorbis and vstplugin
examples,
> which
> > I could not do as I don't have all the required files to build
them.
>
> Applied. Note : I can see strange strings like '' and '' in
libnui.dsp,
> looks like old
> Meeloo experiments that slipped in.
>
>
> > - nuimemorydrawcontext.cpp: Changed BITMAPV5HEADER to
BITMAPV4HEADER.
> > BITMAPV5HEADER is not declared in my headers - must have been
added in the
> > newer MSVC headers. Seems to work fine with BITMAPV4HEADER (you
don't use
> > any of the new fields).
>
> Let's report this one to Meeloo, this is his code (patch attached).
>
>
> > Previously reported fixes:
> > - nuicontainer.h: Added nuiContainer:: qualifier inside Iterator
class
> > declaration.
>
> This looks weird, we have such nested classes in NGL and MSVC6 seems
to
> compile them
> without this explicit prefix. Meeloo, could you have a look at the
attached
> patch ?
>
>
> > - nuiedittext.cpp: Removed return statement from
> > nuEditText::Invalidate(..).
>
> This was already in CVS.
>
>
> -------------------------------------------------------
> This SF.NET email is sponsored by: eBay
> Great deals on office technology -- on eBay now! Click here:
> http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5
> _______________________________________________
> NGL-devel mailing list
> NGL...@li...
> https://lists.sourceforge.net/lists/listinfo/ngl-devel
>
|
|
From: John B. <JP...@da...> - 2003-06-12 07:29:53
|
Vincent said:
> On ngl/libngl{_static}.dsp/dsw, correct me if I'm wrong but do we have the
choice
> between these two solutions :
>
> - drag 3rd party libs (png, jpeg, zlib, freetype) .dsp into
libngl{_static}.dsw as
> dependencies. Then we don't have to set explicitly the 'additional
libraries' list
> (libpng.lib libjpeg.lib ...) in libngl{_static}.dsp, MSVC will do the
linking for us.
> The major inconvenient being that then for every application using NGL,
we must drag
> libngl{_static}.dsp AND the 3rd part libraries projects into its
workspace.
>
> - explicitely link against the .lib files in the libngl{_static}.dsp
project settings,
> then we only need this single project in libngl{_static}.dsw. And a NGL
based can drag
> the libgnl project into its workspace and see it linking automagically
against the 3rd
> party libraries.
>
> If I'm right, then your patch brings up a mix of the two situations. I
remember we
> already went on these questions a looong time ago...
I was a bit confused by the project dependencies (I haven't used workspaces
with
multiple projects before!). Thanks for the clarifying thoughts...
I much prefer the option (2). It gives rather better encapsulation of the
ngl build,
and if you ever add more libraries into ngl we only have to update the ngl
project.
Can you remember what you concluded last time you discussed...?! I seem to
remember
most examples using option (1) - which implies that you went in that
direction.
If we can agree on the preferred method, I can go through and make all the
examples
consistent.
Cheers,
John
-----Original Message-----
From: Vincent Caron [mailto:v....@ze...]
Sent: 11 June 2003 23:47
To: ngl...@li...
Subject: [NGL-devel] Re: MSVC6 build fixes
Hello John,
I finally take the time to go through your patch !
> Most changes are workspace/project file tweaks (.dsw/.dsp).
On ngl/libngl{_static}.dsp/dsw, correct me if I'm wrong but do we have the
choice
between these two solutions :
- drag 3rd party libs (png, jpeg, zlib, freetype) .dsp into
libngl{_static}.dsw as
dependencies. Then we don't have to set explicitly the 'additional
libraries' list
(libpng.lib libjpeg.lib ...) in libngl{_static}.dsp, MSVC will do the
linking for us.
The major inconvenient being that then for every application using NGL, we
must drag
libngl{_static}.dsp AND the 3rd part libraries projects into its workspace.
- explicitely link against the .lib files in the libngl{_static}.dsp project
settings,
then we only need this single project in libngl{_static}.dsw. And a NGL
based can drag
the libgnl project into its workspace and see it linking automagically
against the 3rd
party libraries.
If I'm right, then your patch brings up a mix of the two situations. I
remember we
already went on these questions a looong time ago...
> - benchapp.cpp: Removed mpFont references from destructor. mpFont is not
> initialized or used anywhere else.
> - benchapp.h: Removed declaration of mpFont member variable.
Indeed, applied.
> - ngl_all.h: Removed #include "nglFont2.h" and #include "nglInput.h"
(these
> files don't seem to exist). Your call on what to do with this (are these
> old files?).
This has already been updated in CVS two weeks ago, but your patch is right
(we also
added nglFont1.h and nglInputDevice.h since then).
> I have also created new .dsw/.dsp files for the nui examples.
> I have tested all of them except the OggVorbis and vstplugin examples,
which
> I could not do as I don't have all the required files to build them.
Applied. Note : I can see strange strings like '' and '' in libnui.dsp,
looks like old
Meeloo experiments that slipped in.
> - nuimemorydrawcontext.cpp: Changed BITMAPV5HEADER to BITMAPV4HEADER.
> BITMAPV5HEADER is not declared in my headers - must have been added in the
> newer MSVC headers. Seems to work fine with BITMAPV4HEADER (you don't use
> any of the new fields).
Let's report this one to Meeloo, this is his code (patch attached).
> Previously reported fixes:
> - nuicontainer.h: Added nuiContainer:: qualifier inside Iterator class
> declaration.
This looks weird, we have such nested classes in NGL and MSVC6 seems to
compile them
without this explicit prefix. Meeloo, could you have a look at the attached
patch ?
> - nuiedittext.cpp: Removed return statement from
> nuEditText::Invalidate(..).
This was already in CVS.
|
|
From: Vincent C. <v....@ze...> - 2003-06-11 23:26:53
|
Brian Hammond said: > > - PB project for creating an OS X framework based on Carbon is done > > - Using UNIX versions for Carbon implementations of a few NGL > interfaces (nglFile, etc)... for now. OK, I guess it means file paths can't use Mac style 'volume:' and we can't read ressource forks, something like that ? > - PB project template for creating "NGL Application"s is done; this > embeds the framework and links application code to NGL framework code. Very cool, we never managed to get this done for MSVC or Unix. > - Shell scripts to install the external libs required for building the > NGL.framework are done (FreeType 2.1.4, libjpeg 6b, libpng 1.2.5, and > zlib 1.1.4). Would it be far fetched to find or provide these 3rd party libraries as frameworks too ? Just a suggestion though ... > The idea of the NGL.framework would be to give end-users of NGL a PKG > that they can double click to install a developer version of the > NGL.framework and the PB NGL Application template. I don't want them to > have to deal with installing the external libs (FreeType, etc), > including the search paths in every project, etc. Obviously a great idea, but then I stick to my previous question, would it be still easy to use if these 3rd party libraries were distributed as frameworks ? This could be a long term idea, as I guess becoming the Mac maintainer for a bunch of other libs is not your top priority :) > This is doable as long as the NGL headers do not reference > implementation details. I was kind of surprised that the nglFontBase.h > includes FreeType headers (USE_FREETYPE). I would think that for a > public interface, it should be free of any impl details... IMHO that's > much cleaner and also allows the OS X NGL developers to not have to > install _any_ external libs (and their headers) to build NGL apps. I > have a lot of notes on this if anyone is interested. Yes, this is ugly, we actually delayed the configuration part for a long time. It once had a better support (18 months ago ?). For the USE_ macros, they will all definitively move in a private and non-distributed header, and since you need it now we'll try to do this quickly. For the dependencies on other libs dependencies, it will require some work, mainly on FreeType (the image codecs have a well separated internal interface). C++ can quickly become ugly when we have to use tricks to hide internal things, and I only stuffed this info in 'private:' for now. If you have any suggestion to make this move not too painful, I'm interested. I know we could go the COM way, but : we keep it simple and stupid, and we never asked the user to do things like nglFont::Build() and nglFont::Release(). I'd really prefer not going that way. > - Documentation for the NGL.framework maintainer (me) with all the funky > steps (-seg1addr, @executable_path/../Frameworks, etc). Rare maintainer quality, documentation ! Way to go |
|
From: Vincent C. <v....@ze...> - 2003-06-11 22:47:07
|
Hello John,
I finally take the time to go through your patch !
> Most changes are workspace/project file tweaks (.dsw/.dsp).
On ngl/libngl{_static}.dsp/dsw, correct me if I'm wrong but do we have the choice
between these two solutions :
- drag 3rd party libs (png, jpeg, zlib, freetype) .dsp into libngl{_static}.dsw as
dependencies. Then we don't have to set explicitly the 'additional libraries' list
(libpng.lib libjpeg.lib ...) in libngl{_static}.dsp, MSVC will do the linking for us.
The major inconvenient being that then for every application using NGL, we must drag
libngl{_static}.dsp AND the 3rd part libraries projects into its workspace.
- explicitely link against the .lib files in the libngl{_static}.dsp project settings,
then we only need this single project in libngl{_static}.dsw. And a NGL based can drag
the libgnl project into its workspace and see it linking automagically against the 3rd
party libraries.
If I'm right, then your patch brings up a mix of the two situations. I remember we
already went on these questions a looong time ago...
> - benchapp.cpp: Removed mpFont references from destructor. mpFont is not
> initialized or used anywhere else.
> - benchapp.h: Removed declaration of mpFont member variable.
Indeed, applied.
> - ngl_all.h: Removed #include "nglFont2.h" and #include "nglInput.h" (these
> files don't seem to exist). Your call on what to do with this (are these
> old files?).
This has already been updated in CVS two weeks ago, but your patch is right (we also
added nglFont1.h and nglInputDevice.h since then).
> I have also created new .dsw/.dsp files for the nui examples.
> I have tested all of them except the OggVorbis and vstplugin examples, which
> I could not do as I don't have all the required files to build them.
Applied. Note : I can see strange strings like '' and '' in libnui.dsp, looks like old
Meeloo experiments that slipped in.
> - nuimemorydrawcontext.cpp: Changed BITMAPV5HEADER to BITMAPV4HEADER.
> BITMAPV5HEADER is not declared in my headers - must have been added in the
> newer MSVC headers. Seems to work fine with BITMAPV4HEADER (you don't use
> any of the new fields).
Let's report this one to Meeloo, this is his code (patch attached).
> Previously reported fixes:
> - nuicontainer.h: Added nuiContainer:: qualifier inside Iterator class
> declaration.
This looks weird, we have such nested classes in NGL and MSVC6 seems to compile them
without this explicit prefix. Meeloo, could you have a look at the attached patch ?
> - nuiedittext.cpp: Removed return statement from
> nuEditText::Invalidate(..).
This was already in CVS.
|
|
From: Lorenzo P. <pas...@ul...> - 2003-06-10 15:06:11
|
Yep, Thanks for the note.. I'll be watchin' for your next posts, and try to be as responsive as I can.. Lo. ----- Original Message ----- From: "Vincent Caron" <v....@ze...> To: <ngl...@li...> Sent: Tuesday, June 10, 2003 1:58 PM Subject: [NGL-devel] Note to maintainers > Hello, > > This information mainly for John and Brian. I will try to integrate your patches and > answer your questions the sooner I can (tonight I hope). Meanwhile, I suggest you > subscribe to the ngl-cvs mailing-list to see how the patches get in, and how it gets > splitted up and documented. Since you look like our next platform maintainers, > you'll have a better insight about how the code gets comitted, our various habits > and 'cleanliness definitions', etc. This is also an important feedback for you, > which is actually not duplicated on ngl-devel. Thanks for your time and dedication ! > > Subscription: http://lists.sourceforge.net/lists/listinfo/ngl-cvs > > Also for Lorenzo : our 'bigger' questions get delayed by some grunt maintainer work, > but the kernel and console things are still top on my todo-list. > > > > > ------------------------------------------------------- > This SF.net email is sponsored by: Etnus, makers of TotalView, The best > thread debugger on the planet. Designed with thread debugging features > you've never dreamed of, try TotalView 6 free at www.etnus.com. > _______________________________________________ > NGL-devel mailing list > NGL...@li... > https://lists.sourceforge.net/lists/listinfo/ngl-devel > |
|
From: Vincent C. <v....@ze...> - 2003-06-10 12:26:04
|
Hello, This information mainly for John and Brian. I will try to integrate your patches and answer your questions the sooner I can (tonight I hope). Meanwhile, I suggest you subscribe to the ngl-cvs mailing-list to see how the patches get in, and how it gets splitted up and documented. Since you look like our next platform maintainers, you'll have a better insight about how the code gets comitted, our various habits and 'cleanliness definitions', etc. This is also an important feedback for you, which is actually not duplicated on ngl-devel. Thanks for your time and dedication ! Subscription: http://lists.sourceforge.net/lists/listinfo/ngl-cvs Also for Lorenzo : our 'bigger' questions get delayed by some grunt maintainer work, but the kernel and console things are still top on my todo-list. |
|
From: Brian H. <br...@ab...> - 2003-06-10 06:09:12
|
* Sebastien Metrot <me...@me...> [2003-06-09 19:43]:
> I think everybody is happy to count you in. As for the direct CVS access
> we preffer generally to delay things a bit, just the time for everyone
> to know each other and for you to get a more complete understanding of
> the project. Don't see this as a rebutal at all but more like the normal
> path of admition :).
Ah, thanks. Ok, some updates on progress...
- PB project for creating an OS X framework based on Carbon is done
- Using UNIX versions for Carbon implementations of a few NGL
interfaces (nglFile, etc)... for now.
- Public headers vs private, etc.
- Apple recommends that frameworks be setup to be embedded in host
apps. This is what NGL.framework is setup to do.
- PB project template for creating "NGL Application"s is done; this
embeds the framework and links application code to NGL framework code.
- Shell scripts to install the external libs required for building the
NGL.framework are done (FreeType 2.1.4, libjpeg 6b, libpng 1.2.5, and
zlib 1.1.4).
The idea of the NGL.framework would be to give end-users of NGL a PKG
that they can double click to install a developer version of the
NGL.framework and the PB NGL Application template. I don't want them to
have to deal with installing the external libs (FreeType, etc),
including the search paths in every project, etc.
This is doable as long as the NGL headers do not reference
implementation details. I was kind of surprised that the nglFontBase.h
includes FreeType headers (USE_FREETYPE). I would think that for a
public interface, it should be free of any impl details... IMHO that's
much cleaner and also allows the OS X NGL developers to not have to
install _any_ external libs (and their headers) to build NGL apps. I
have a lot of notes on this if anyone is interested.
- Working on getting samples to build using the PB template.
- helloworld works no problem
- Just tried the Gears sample. It fails because it includes the
NGL.framework (of course) whose headers reference the FreeType
headers, but those are NOT to be required by end-users of
NGL.framework (at least, if I get my way). See above.
- Documentation for the NGL.framework maintainer (me) with all the funky
steps (-seg1addr, @executable_path/../Frameworks, etc).
- Haven't started to create a dummy makefile that delegates to pbxbuild
to build the framework. This would allow a autotools based
installation.
- Haven't started on input device code nor a nice console.
Brian -+- http://brianhammond.com
|
