adonthell-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Adonthell-devel] libfreetype2, callback and namespace


From: Alexandre Courbot
Subject: Re: [Adonthell-devel] libfreetype2, callback and namespace
Date: 20 Feb 2002 14:00:48 +0100

> First subject: libfreetype2
>   I'm ready to use libfreetype2 for adonthell GUI,
> i'll write some stuff to manipulate freetype mopre
> easily.
> So if you're not agree tell me, otherwise i use it

That's fine. We already agreed on this I think, and anyway freetype 2 is
widely used, so depending on it isn't really a problem. By the way,
you'll probably be interested in SDL_ttf which is a true type fonts
manipulation lib for SDL.

> Second subject:
> Currently we use callback<> and makefunctor. So i
> decide to create a class to manipulate severals
> callback with one variable:

Fine, but make sure we can still use callbacks the old way. Ah also, I'd
like to use for the input code a callback that takes one argument and
returns something. How can I do that with the current system?

> So it can be usefull and more cleanner, so i'm ready
> to use it for new GUI, tell me your suggestion

Looks fine. But the GUI signals will be identified by strings then,
right?

> Subject number three:
>   THere are lots of work on adonthell projet, lots of
> class and other .... 
> I think we must organize adonthell in several parts.
> So several choice is possible:
>     rename classes, by example all class like
> drawing_area, surface, image in adk_drawing_area,
> adk_surface. Adk is adonthell drawing kit .
> It can be a solution, or we add namespace, in this
> case
> namespace adk
> {
>  class image;
>  class surface;
> ....
> }

I came to the same reflexion this morning. Actually the best thing to do
would be to use namespaces, just the way you suggested. One namespace
for drawing stuff, one for input, one for the window system, etc... We
could even put all the stuff that goes into the same namespace into the
same subdirectory. But the problem is that SWIG doesn't like namespaces
at all. When it sees the "namespace" token, it raises a syntax error.
This should be corrected in the next future, but right now it's
unusuable. Unless we isolate the namespace declarations with #ifndef
SWIG so swig doesn't parse them, but in this case there would be
namespaces in C++ while everything would be directly accessible from
Python. Another solution would be to cut our subsystems into different
modules. But I haven't found a way yet to do it without making the image
class usuable anywhere else than in the gfx module (when you need to
pass an image as an argument in another module for example). But well,
there is certainly a way to do it. I'm subscribing to the SWIG list, if
we decide to aim this way, I'll ask the question there.

What do you others think about the reorganisation? We all agree it's
necessary, but how to do it? Namespaces & subdirectories seems quite
sensible in that respect. I think many others projects use this scheme,
including ClanLib (which is my new reference when talking about code
design ;)) If we can solve the Python/SWIG problems, it would be
absolutely fine. Shall I ask the SWIG guys?

Alex.
-- 
http://www.gnurou.org





reply via email to

[Prev in Thread] Current Thread [Next in Thread]