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

[joel vennin]

 --- Alexandre Courbot
<address@hidden> a écrit : > 
> > 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.
Yes but i prefer to create own ttf class.

 
> > 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.
Yeah, sure, we can still use old callback.
 >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?
Is not current implemented but if you want tomorrow i
update callback.h or feel free to implement it

> 
> > 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?
Yep, but i think lot of GUI bind their callback, just
see QT, gtk or other...

Maybe for input system, when an event arrive you can
bind the event:


class input_manager
{
   vector<listener> l;
....

   void update()
   {
      if (SDL_event is mouse)
         iterate vector with by exemple
"mouse_pressed"
else if  (SDL_event is keyboard
         iterate vector with by exemple
"keyboard_pressed"
....
   }
};  

in the listener

class listener
{
   callbackslot<..> call;
 ...

 public:
   //redefine operator () to access callback
   // user can
listener().connect("on_mouse_click",method)
   callbackslot<..> & operator(){return call;}

   void update (const std::string & name_event)
  {
   call.update(name_event);
  }
 ...
};

I know string is not a powerfull method, maybe you
want to replace string by int. Yep but to understand
the code, i think it will be more difficult.


> > 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?
>
 Yes i think.

> Alex.
Jol

> -- 
++, C++ not C-- ;=)

> http://www.gnurou.org
> 
> 
> 
> _______________________________________________
> Adonthell-devel mailing list
> address@hidden
>
http://mail.freesoftware.fsf.org/mailman/listinfo/adonthell-devel 

___________________________________________________________
Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français !
Yahoo! Mail : http://fr.mail.yahoo.com