[gtkwrapper-general] Re: gtkwrapper LGPL issue

[Alex S. <ash...@ya...>]

> I actually do not really understand what LGPL means.

I did some googling and found this: http://teem.sourceforge.net/lgpl.html
This link may interest you as it explains a bit of LGPL in a natural language.
Note that LGPL generally applies to linkable libraries, so header-only
libraries should use a modified LGPL, like I told you before.

> I am making a convention here: the file name is the same as the class 
> name.  Is this acceptable?

I understand your point, but it's a good practice to name all the include
files lowercase, to avoid some problems. One of the problems is copying
these files to the filesystem that doesn't preserve cases, and then copying
them back. This way, the files will become lowercase, or even worse -
the files will have the first letter uppercase and all the others lowercase
(like ButtonBox.h -> Buttonbox.h). This happens sometimes with win32
filesystems. Another problem is that one win32 programmer will use
ButtonBox.h and another will use buttonbox.h (I've even seen some
people use strange conventions like StdIO.H in their code). Because
both examples will compile, the programmers will not be carefull about
the case of the names, thus making their code non-portable. Making
all include files lowercase will lower the chance of misusing the case
(was it HScrollbar.h or HScrollBar.h? and so on...). This practice has
been adopted by almost all Unix libraries, like QT (e.g. class QCanvas is
in qcanvas.h), GTK+, etc...


> I am actually quite new to the gtk/linux world.  Your encouragement and 
> comments are very valuable for me.

Let me know if you need some advice on linux. I'll be very glad to help.


> There are actually still quite a lot can be done for the wrapper
> library.  I am currently looking at the possibility of generating
> gtw-based code from glabe files.  Any suggestions about this?  Another
> thing to be done is to wrap the properties with get/set functions.

I'm not sure about glade... Current glade-2 development has been halted
and all efforts are focused on a total rewrite (glade-3). I don't know their
current status, but they had some ideas about implementing plugin-based
language/toolkit components, so that you can write your own component.
But the current cvs doesn't even compile, so I can't confirm this.
As for other ways of generating code - maybe libglade could help...
I'm not familiar with it, but I heared it is used for parsing glade's xml
files and making the interfaces in runtime. That's all I know about it.
Unfortunately, I didn't have much time to look into your library, so I
cannot make any useful comments about it, but a quick look made me
think: Why not make some of the functions STL-aware? I mean,
e.g. Label's
void set_text(const char * str);
could be
void set_text(const std::string& str);

This would be really useful as a user wouldn't have to write .c_str()
every time. The same thing could be done for GList vs. std::vector,
though it would be much harder to implement.

Of course, these are only ideas and may be impractical to implement...


Thanks,
Alex Shaduri