gtkwrapper-general — general discuss of gtw

[gtkwrapper-general] Gtk - Window XP - can't include Gtk library

[Pascal <pas...@ho...>]

Hello everyone,

I've installed Gnat Gps and Gtk, and I did some testing but I'm still unable
to compile properly one of the example provided along with Gtk;
"..\Gtk\share\examples\gtkada\base_widget"

I've tried all three different sugested ways without success; please see
bellow:
- including -I switch in Project setup
- use project template provided with Gtk
- use Environement variable to point at a library list

So sorry for this stupid question and thnaks in advance to whom might help
me.

Cheers

Pascal

Detail of message I got.

gnatmake -Pc:\gnat\gpl_2006\my_projects\base_widget\basic_widget.gpr
main.adb -d 
gcc -c -I- -gnatA c:\gnat\gpl_2006\my_projects\base_widget\main.adb
main.adb:1:06: file "gtk.ads" not found
main.adb:2:06: file "gtk.ads" not found
main.adb:3:06: file "gtk.ads" not found
main.adb:4:06: file "gtk.ads" not found
main.adb:5:06: file "gtk.ads" not found
main.adb:6:06: file "gtk.ads" not found
main.adb:8:06: file "glib.ads" not found
main.adb:8:06: "My_Widget (spec)" depends on "Glib (spec)"
main.adb:8:06: "My_Widget (spec)" depends on "Gdk (spec)"
main.adb:8:06: "Main (body)" depends on "My_Widget (spec)"
main.adb:8:06: "My_Widget (spec)" depends on "Gtk (spec)"
gnatmake: "c:\gnat\gpl_2006\my_projects\base_widget\main.adb" compilation
error
process exited with status 4


-- 
View this message in context: http://www.nabble.com/Gtk---Window-XP---can%27t-include-Gtk-library-tf3058389.html#a8503547
Sent from the Gtk+ - Gtw - General mailing list archive at Nabble.com.

[gtkwrapper-general] FASD project: Online survey launched

[<ben...@id...>]

Dear Open Source developer

I am doing a research project on "Fun and Software Development" in which I kindly invite you to participate.
You will find the online survey under http://fasd.ethz.ch/qsf/. The questionnaire consists of 53 questions and you will need about 15 minutes to complete it.

With the FASD project (Fun and Software Development) we want to define the motivational significance of fun when software developers decide to engage in Open Source projects. What is special about our research project is that a similar survey is planned with software developers in commercial firms. This procedure allows the immediate comparison between the involved individuals and the conditions of production of these two development models. Thus we hope to obtain substantial new insights to the phenomenon of Open Source Development.


With many thanks for your participation,
Benno Luthiger


PS:
The results of the survey will be published under http://www.isu.unizh.ch/fuehrung/blprojects/FASD/.
We have set up the mailing list fa...@we... for this study. Please see http://fasd.ethz.ch/qsf/mailinglist_en.html for registration to this mailing list.

_______________________________________________________________________

Benno Luthiger
Swiss Federal Institute of Technology Zurich
8092 Zurich

Mail: benno.luthiger(at)id.ethz.ch
_______________________________________________________________________

[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

Re: [gtkwrapper-general] gtkwrapper LGPL issue

[Li L. <li...@ho...>]

Alex Shaduri wrote:

>Hi
>
>I saw your announcement of gtkwrapper library in the gtk mailing lists.
>I think this is a very good library, because you can add it to existing
>projects without rewriting them (porting to gtkmm or inti would require
>that) and you don't need any additional runtime linking. The API seems
>very good too.
>
Thank you very much for the nice word.  The gtkwrapper project is still 
in its infant state.  I will keep on improving it.

>...
>I suggest you look into the matter of licensing, as LGPL for a linkable library
>is not the same as LGPL for header-only library.
>  
>
I actually do not really understand what LGPL means.  I will follow your 
suggestion to change the license text so that every one can use it.

>Oh, and your .tar.bz2 contains win32 newlines (It's common that the zip file
>should contain win32 newlines and the tar.gz and tar.bz2 files should
>contain Unix newlines). You could use dos2unix program to convert them.
>And the files in tar archives should be chmod 644-ed (you have the
>executable permissions in your archives).
>  
>
Will fix this.  Thank you again...

>And another thing... Your headers are named like CanvasLine.h. This is a
>bit annoyance on Unix systems where filesystem is case-sensitive.
>It's a good practice to name the files lowercase, like canvasline.h or
>canvas_line.h.
>  
>
I am making a convention here: the file name is the same as the class 
name.  Is this acceptable?

I am actually quite new to the gtk/linux world.  Your encouragement and 
comments are very valuable for me.
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.

Regards,
Lirong

[gtkwrapper-general] gtkwrapper LGPL issue

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

Hi

I saw your announcement of gtkwrapper library in the gtk mailing lists.
I think this is a very good library, because you can add it to existing
projects without rewriting them (porting to gtkmm or inti would require
that) and you don't need any additional runtime linking. The API seems
very good too. But the only thing that dislike is it's LGPL license. Don't
get me wrong, I love that license, but not for header-only library. The
thing is, if the library is not dinamically linkable, it can't be linked with
non-GPL/LGPL software, even if the software is LGPL-compatible.
The solution is to use the libstdc++-like license (look for headers of files
in /usr/include/c++/<gcc_ver>/<any_cpp_include>). The libstdc++
headers are LGPL, but they contain templates and macros that will
not be dinamically linkable, so they came up with a solution. As an
exception, they allow any kind of linking. These headers contain:

// As a special exception, you may use this file as part of a free software
// library without restriction.  Specifically, if other files instantiate
// templates or use macros or inline functions from this file, or you compile
// this file and link it with other files to produce an executable, this
// file does not by itself cause the resulting executable to be covered by
// the GNU General Public License.  This exception does not however
// invalidate any other reasons why the executable file might be covered by
// the GNU General Public License.

Note that the headers are still covered LGPL, they just loosened the license
a bit.

I suggest you look into the matter of licensing, as LGPL for a linkable library
is not the same as LGPL for header-only library.

Oh, and your .tar.bz2 contains win32 newlines (It's common that the zip file
should contain win32 newlines and the tar.gz and tar.bz2 files should
contain Unix newlines). You could use dos2unix program to convert them.
And the files in tar archives should be chmod 644-ed (you have the
executable permissions in your archives).

And another thing... Your headers are named like CanvasLine.h. This is a
bit annoyance on Unix systems where filesystem is case-sensitive.
It's a good practice to name the files lowercase, like canvasline.h or
canvas_line.h.


Thanks,
Alex Shaduri

[gtkwrapper-general] test

[Li L. <li...@ho...>]