From asadujjaman at gmail.com Mon Oct 1 15:27:08 2007 From: asadujjaman at gmail.com (asm asadujjaman) Date: Tue, 2 Oct 2007 01:27:08 +0600 Subject: [Glade-devel] Glade 3.2.2 Compilation failed on MinGW (MSYS) .... please help Message-ID: I am trying to compile Glade 3.2.2 on MinGW (MSYS). But being ended up getting a peculiar error message. $ ./configure checking build system type... i686-pc-mingw32 checking host system type... i686-pc-mingw32 checking target system type... i686-pc-mingw32 checking for a BSD-compatible install... /bin/install -c checking whether build environment is sane... yes checking for gawk... gawk checking whether make sets $(MAKE)... yes checking whether to enable maintainer-specific portions of Makefiles... no checking for intltool >= 0.35.0... 0.35.0 found checking for perl... /c/Perl/bin/perl checking for XML::Parser... ok checking for iconv... /c/GTK/bin/iconv checking for msgfmt... /c/GTK/bin/msgfmt checking for msgmerge... /c/GTK/bin/msgmerge checking for xgettext... /c/GTK/bin/xgettext checking for glib-genmarshal... /c/GTK/bin/glib-genmarshal checking for dlltool... /mingw/bin/dlltool checking for style of include used by make... GNU checking for gcc... gcc checking for C compiler default output file name... a.exe checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... .exe checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ISO C89... none needed checking dependency style of gcc... gcc3 checking for library containing strerror... none required checking for gcc... (cached) gcc checking whether we are using the GNU C compiler... (cached) yes checking whether gcc accepts -g... (cached) yes checking for gcc option to accept ISO C89... (cached) none needed checking dependency style of gcc... (cached) gcc3 checking for a BSD-compatible install... /bin/install -c checking whether make sets $(MAKE)... (cached) yes checking for a sed that does not truncate output... /bin/sed checking for grep that handles long lines and -e... /bin/grep checking for egrep... /bin/grep -E checking for ld used by gcc... c:/MinGW/mingw32/bin/ld.exe checking if the linker (c:/MinGW/mingw32/bin/ld.exe) is GNU ld... yes checking for c:/MinGW/mingw32/bin/ld.exe option to reload object files... -r checking for BSD-compatible nm... /mingw/bin/nm checking whether ln -s works... no, using cp -p checking how to recognise dependent libraries... file_magic file format pei*-i386(.*architecture: i386)? checking for dlltool... /mingw/bin/dlltool checking for as... as checking for objdump... objdump checking how to run the C preprocessor... gcc -E checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... yes checking for unistd.h... yes checking dlfcn.h usability... no checking dlfcn.h presence... no checking for dlfcn.h... no checking for g++... g++ checking whether we are using the GNU C++ compiler... yes checking whether g++ accepts -g... yes checking dependency style of g++... gcc3 checking how to run the C++ preprocessor... g++ -E checking for g77... no checking for f77... no checking for xlf... no checking for frt... no checking for pgf77... no checking for cf77... no checking for fort77... no checking for fl32... no checking for af77... no checking for f90... no checking for xlf90... no checking for pgf90... no checking for pghpf... no checking for epcf90... no checking for gfortran... no checking for g95... no checking for f95... no checking for fort... no checking for xlf95... no checking for ifort... no checking for ifc... no checking for efc... no checking for pgf95... no checking for lf95... no checking for ftn... no checking whether we are using the GNU Fortran 77 compiler... no checking whether accepts -g... no checking the maximum length of command line arguments... 8192 checking command to parse /mingw/bin/nm output from gcc object... ok checking for objdir... .libs checking for ar... ar checking for ranlib... ranlib checking for strip... strip checking if gcc supports -fno-rtti -fno-exceptions... no checking for gcc option to produce PIC... -DDLL_EXPORT checking if gcc PIC flag -DDLL_EXPORT works... yes checking if gcc static flag -static works... yes checking if gcc supports -c -o file.o... yes checking whether the gcc linker (c:/MinGW/mingw32/bin/ld.exe) supports shared libraries... yes checking whether -lc should be explicitly linked in... yes checking dynamic linker characteristics... Win32 ld.exe checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... yes checking if libtool supports shared libraries... yes checking whether to build shared libraries... yes checking whether to build static libraries... no configure: creating libtool appending configuration tag "CXX" to libtool checking for ld used by g++... c:/MinGW/mingw32/bin/ld.exe checking if the linker (c:/MinGW/mingw32/bin/ld.exe) is GNU ld... yes checking whether the g++ linker (c:/MinGW/mingw32/bin/ld.exe) supports shared libraries... yes checking for g++ option to produce PIC... -DDLL_EXPORT checking if g++ PIC flag -DDLL_EXPORT works... yes checking if g++ static flag -static works... yes checking if g++ supports -c -o file.o... yes checking whether the g++ linker (c:/MinGW/mingw32/bin/ld.exe) supports shared libraries... yes checking dynamic linker characteristics... Win32 ld.exe checking how to hardcode library paths into programs... immediate appending configuration tag "F77" to libtool checking locale.h usability... yes checking locale.h presence... yes checking for locale.h... yes checking for LC_MESSAGES... no checking libintl.h usability... no checking libintl.h presence... no checking for libintl.h... no checking how to copy va_list... va_copy checking for pkg-config... /c/GTK/bin/pkg-config checking pkg-config is at least version 0.9.0... yes checking for GTK... yes checking for GNOME... checking whether Python support is requested... autodetect checking for a Python interpreter with version >= 2.3... none configure: creating ./config.status config.status: creating Makefile config.status: creating data/gladeui-1.0.pc config.status: creating data/glade-3.desktop.in config.status: creating data/Makefile config.status: creating data/icons/Makefile config.status: creating data/icons/hicolor/Makefile config.status: creating data/icons/hicolor/16x16/Makefile config.status: creating data/icons/hicolor/16x16/apps/Makefile config.status: creating data/icons/hicolor/22x22/Makefile config.status: creating data/icons/hicolor/22x22/apps/Makefile config.status: creating data/icons/hicolor/24x24/Makefile config.status: creating data/icons/hicolor/24x24/apps/Makefile config.status: creating data/icons/hicolor/32x32/Makefile config.status: creating data/icons/hicolor/32x32/apps/Makefile config.status: creating data/icons/hicolor/48x48/Makefile config.status: creating data/icons/hicolor/48x48/apps/Makefile config.status: creating data/icons/hicolor/scalable/Makefile config.status: creating data/icons/hicolor/scalable/apps/Makefile config.status: creating gladeui/Makefile config.status: creating src/Makefile config.status: creating plugins/Makefile config.status: creating plugins/gtk+/Makefile config.status: creating plugins/gtk+/icons/Makefile config.status: creating plugins/gtk+/icons/16x16/Makefile config.status: creating plugins/gtk+/icons/22x22/Makefile config.status: creating plugins/gnome/Makefile config.status: creating plugins/gnome/icons/Makefile config.status: creating plugins/gnome/icons/16x16/Makefile config.status: creating plugins/gnome/icons/22x22/Makefile config.status: creating bindings/Makefile config.status: creating bindings/python/Makefile config.status: creating po/Makefile.in config.status: creating doc/Makefile config.status: creating doc/version.xml config.status: creating help/Makefile config.status: creating config.h config.status: executing intltool commands config.status: executing depfiles commands config.status: executing default-1 commands config.status: executing po/stamp-it commands Configuration: Source code location: . Compiler: gcc GnomeUI Catalog: no Python Binding: no Glade User Manual: no $ mingw32-make c:/MinGW/bin/mingw32-make all-recursive mingw32-make[1]: Entering directory `C:/msys/1.0/home/Rana/glade3-3.2.2' Making all in po mingw32-make[2]: Entering directory `C:/msys/1.0/home/Rana/glade3-3.2.2/po' file=`echo az | sed 's,.*/,,'`.gmo \ && rm -f $file && -o $file az.po mingw32-make[2]: Leaving directory `C:/msys/1.0/home/Rana/glade3-3.2.2/po' mingw32-make[1]: Leaving directory `C:/msys/1.0/home/Rana/glade3-3.2.2' What can I do now? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.ximian.com/pipermail/glade-devel/attachments/20071002/a29d7445/attachment-0001.html From keya.nema at gmail.com Wed Oct 3 05:27:39 2007 From: keya.nema at gmail.com (Keya Nema) Date: Wed, 3 Oct 2007 14:57:39 +0530 Subject: [Glade-devel] Extending Glade Palette Message-ID: Hi, -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.ximian.com/pipermail/glade-devel/attachments/20071003/f607b988/attachment.html From keya.nema at gmail.com Wed Oct 3 05:32:57 2007 From: keya.nema at gmail.com (Keya Nema) Date: Wed, 3 Oct 2007 15:02:57 +0530 Subject: [Glade-devel] Extending Glade Palette In-Reply-To: References: Message-ID: Hi, I am trying to extend the Glade Palette adding my Custom Widget. I can add the widget to the catalog file and it is visible on the Palette also. My problem is that, while creating the Custom Widget [ my_custom_widget_new () ] I need to pass few arguments which are required to create the widget. I need to know how I can specify the arguments with default values in the catalog file. Thanks, Keya -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.ximian.com/pipermail/glade-devel/attachments/20071003/0db3b3af/attachment.html From tvb at gnome.org Thu Oct 4 01:25:52 2007 From: tvb at gnome.org (Tristan Van Berkom) Date: Thu, 04 Oct 2007 01:25:52 -0400 Subject: [Glade-devel] Extending Glade Palette In-Reply-To: References: Message-ID: <1191475552.6381.4.camel@scrabble-desktop> On Wed, 2007-10-03 at 15:02 +0530, Keya Nema wrote: > Hi, > > I am trying to extend the Glade Palette adding my Custom Widget. I > can add the widget to the catalog file and it is visible on the > Palette also. > > My problem is that, while creating the Custom Widget > [ my_custom_widget_new () ] I need to pass few arguments which are > required to create the widget. I need to know how I can specify the > arguments with default values in the catalog file. The best is if you are using construct-only proper gobject properties, then in the catalog you can simply specify a default in xml: Cheers, -Tristan From arthurmaciel at gmail.com Fri Oct 5 23:22:19 2007 From: arthurmaciel at gmail.com (Arthur Maciel) Date: Sat, 6 Oct 2007 00:22:19 -0300 Subject: [Glade-devel] Future of Custom Widget Message-ID: Hi there. I?m new to the list and would like to know two things: 1) Do you intend to let 'Custom' widget to be in the future Glade releases? I?ve seen that in Glade 3 it is placed as GTK+ Obsolete, but this widget is really what I need for some 'hacks' for my Gtkmm program and I?ve based some part of my program on it. I have to be sincere that I don?t feel able at the moment to create my own widget to be loaded by Glade. Maybe in the future. 2) Can I sell my Gtkmm program (with closed source) considering that it loads .glade files and process it and that Glade is released under GPL? The team I work for want this to happen. Really thanks. Arthur From tvb at gnome.org Sat Oct 6 10:00:22 2007 From: tvb at gnome.org (Tristan Van Berkom) Date: Sat, 06 Oct 2007 10:00:22 -0400 Subject: [Glade-devel] Future of Custom Widget In-Reply-To: References: Message-ID: <1191679222.5485.10.camel@scrabble-desktop> On Sat, 2007-10-06 at 00:22 -0300, Arthur Maciel wrote: > Hi there. > > I?m new to the list and would like to know two things: > > 1) Do you intend to let 'Custom' widget to be in the future Glade > releases? I?ve seen that in Glade 3 it is placed as GTK+ Obsolete, but > this widget is really what I need for some 'hacks' for my Gtkmm > program and I?ve based some part of my program on it. I have to be > sincere that I don?t feel able at the moment to create my own widget > to be loaded by Glade. Maybe in the future. First, I wonder if you read my blog post[1] that describes how loading your custom type can now be "faked" in the glade runtime, this makes integrating custom widget types easier, and from the libglade point of view, loading a custom type is really only a matter of calling glade_register_widget() before calling glade_xml_new() (then again, maybe this is a little more difficult when using gtkmm for some reason ?) That being said, we put the old hacked out "custom" widget support in the "obsolete" group because we believe better alternatives exist now, I'm not really planning on removing that support for old glade files though - maybe in some distant future. > 2) Can I sell my Gtkmm program (with closed source) considering that > it loads .glade files and process it and that Glade is released under > GPL? The team I work for want this to happen. Yes you can, the codebase is protected by GPL not the xml file :) (note ofcourse libglade is distributed under LGPL) Cheers, -Tristan [1] http://blogs.gnome.org/tvb/2007/07/25/some-popular-features/ From asadujjaman at gmail.com Sun Oct 7 00:23:39 2007 From: asadujjaman at gmail.com (asm asadujjaman) Date: Sun, 7 Oct 2007 10:23:39 +0600 Subject: [Glade-devel] Glib: Such a nasty bug? I wish I Am I just having a mistake? Message-ID: I am trying to actually compile glade3-3.4 so I need to compile loads of other things including glib and gtk+. I have compiled and installed glib-2.14.0 and then trying to configure gtk+. But it says- [CODE] checking pkg-config is at least version 0.7... yes checking for GLIB - version >= 2.13.5... *** 'pkg-config --modversion glib-2.0' returned 2.14.0, but GLIB (2.12.11) *** was found! If pkg-config was correct, then it is best *** to remove the old version of GLib. You may also be able to fix the error *** by modifying your LD_LIBRARY_PATH enviroment variable, or by editing *** /etc/ld.so.conf. Make sure you have run ldconfig if that is *** required on your system. *** If pkg-config was wrong, set the environment variable PKG_CONFIG_PATH *** to point to the correct configuration files no configure: error: *** GLIB 2.13.5 or better is required. The latest version of [/CODE] Then I tried to check it by hand- [CODE] [root at localhost src]# cat glib-version.c #include #include int main () { printf ("%d %d %d\n",glib_major_version,glib_minor_version,glib_micro_version); return 0; } [root at localhost src]# FLAGS=`pkg-config glib-2.0 --cflags --libs` [root at localhost src]# echo $FLAGS -I/gtkmm/include/glib-2.0 -I/gtkmm/lib/glib-2.0/include -L/gtkmm/lib -lglib-2.0 [root at localhost src]# cc -o glib-version glib-version.c $FLAGS [root at localhost src]# ./glib-version 2 12 11 [root at localhost src]# [/CODE] I have also had a try with glib-2.14.1 but no gain. Seems those sources are actually 2.12.11 or my wrong! Can any one help? I am feeling desperate.. From tvb at gnome.org Wed Oct 10 10:28:48 2007 From: tvb at gnome.org (Tristan Van Berkom) Date: Wed, 10 Oct 2007 10:28:48 -0400 Subject: [Glade-devel] [Glade-users] Autoglade In-Reply-To: <470C9ADE.4090500@codtech.com> References: <470C9ADE.4090500@codtech.com> Message-ID: <1192026528.5632.28.camel@scrabble-desktop> On Wed, 2007-10-10 at 11:26 +0200, Diego Torres Milano wrote: > I've been working on a tool named autoglade that could be of help to > simplify application development using glade as the interface designer. > You can download autoglade from http://sourceforge.net/projects/autoglade. > A basic tutorial can be found in the wiki: > http://autoglade.wiki.sourceforge.net/autoglade+tutorial+-+first+steps > More to come. This sounds really cool I think :) I didn't take the time to go through the whole tutorial but I think I get the idea, one little problem I see is that you are using the widget's name property, I think with a little collaboration we can setup the widget's name, auto, init and optional parameters separately from the widget name. Another thing, have you considered writing this code somehow as a plugin to glade ? or maybe a plugin to anjuta that can interface with the glade core ? Excuse me here I'm going to run off on a tangent but you might want to indulge with me ;-) ... I wonder if this task could be done simply by defining objects that control what to do with entries and inputs, this way the objects could be added to the xml output of glade, the resulting program would remain language independent and you'd just need to have your library of "input controlling objects" installed on the target system for it to run (those object's parameters would replace the auto/init/extra params you outlined and would contain the needed code to do the appropriate things in the resulting runtime). A simple similar idea thats been floating around that would be useful and might also integrate well with your work is a state machine plugin, basically you would have your GObject based "state" objects with callbacks for state initializers, cleanups and transitions and predefined links from one state to another or from state back to superstate, or to substate (all of these links interestingly could be setup using a GUI that could be part of the state machine plugin and work seemlessly with glade as if the state objects were actually widgets) ofcourse, state transitions could also be triggered by widget events or GtkAction activations, a simple state_machine_run_action() could be setup as a callback for any GtkAction, the GtkAction itself could have an attribute telling the state machine in which state it should transition to. Anyway, these are just a couple ideas that I think could go a long way, I'm glad to see that people are doing work towards really automating the application writing procedure :) Cheers, -Tristan From diego at codtech.com Wed Oct 10 16:14:34 2007 From: diego at codtech.com (Diego Torres Milano) Date: Wed, 10 Oct 2007 22:14:34 +0200 Subject: [Glade-devel] [Glade-users] Autoglade In-Reply-To: <1192026528.5632.28.camel@scrabble-desktop> References: <470C9ADE.4090500@codtech.com> <1192026528.5632.28.camel@scrabble-desktop> Message-ID: <470D32AA.5070601@codtech.com> Tristan Van Berkom wrote: > This sounds really cool I think :) > Thanks for your comments. > I didn't take the time to go through the whole tutorial but > I think I get the idea, one little problem I see is that you > are using the widget's name property, I think with a little > collaboration we can setup the widget's name, auto, init and > optional parameters separately from the widget name. > Widget name is used because the file continues to be a valid glade file and can be edited through glade. It would be nice to have somewhere to enter arbitrary properties and values. Then it would be added as myval in the glade XML file. > Another thing, have you considered writing this code somehow > as a plugin to glade ? or maybe a plugin to anjuta that can > interface with the glade core ? > Yes, this is an alternative. But don't forget that autoglade "is" the application (or the module imported in some cases), not to be run as part of the designer. i.e: $ autoglade myapp.glade Am I missing something ? > Excuse me here I'm going to run off on a tangent but you > might want to indulge with me ;-) ... > > I wonder if this task could be done simply by defining objects > that control what to do with entries and inputs, this way > the objects could be added to the xml output of glade, the > resulting program would remain language independent and > you'd just need to have your library of "input controlling > objects" installed on the target system for it to run > (those object's parameters would replace the auto/init/extra > params you outlined and would contain the needed code > to do the appropriate things in the resulting runtime). > Yep, would be nice, but much harder to implement I think. Currently, autoglade can invoke any method almost with any arbitrary list of parameters (widget:auto:method:params). > A simple similar idea thats been floating around that would be > useful and might also integrate well with your work is a > state machine plugin, basically you would have your GObject > based "state" objects with callbacks for state initializers, > cleanups and transitions and predefined links from one state > to another or from state back to superstate, or to substate > (all of these links interestingly could be setup using a GUI > that could be part of the state machine plugin and work seemlessly > with glade as if the state objects were actually widgets) > > ofcourse, state transitions could also be triggered by widget > events or GtkAction activations, a simple state_machine_run_action() > could be setup as a callback for any GtkAction, the GtkAction > itself could have an attribute telling the state machine in which > state it should transition to. > Very interesting idea indeed. > Anyway, these are just a couple ideas that I think could > go a long way, I'm glad to see that people are doing work > towards really automating the application writing procedure :) > autoglade target, at this stage, is to simplify (or to eliminate in some cases) the development of simple applications, mainly to give a command line tool a GUI. One of the most representative examples is described in the tutorial (rdc, a GUI for rdesktop). In about 100 lines of bash scripting, plus the glade definition plus autoglade you have a "real" application comparable in functionality with Microsoft's client or tsclient (~ 5K lines of C code). Any ideas are welcome. Again, thanks for your comments. > Cheers, > -Tristan > > > From ntd at users.sourceforge.net Wed Oct 10 18:44:00 2007 From: ntd at users.sourceforge.net (Nicola Fontana) Date: Thu, 11 Oct 2007 00:44:00 +0200 Subject: [Glade-devel] [Glade-users] Autoglade In-Reply-To: <470D32AA.5070601@codtech.com> References: <470C9ADE.4090500@codtech.com> <1192026528.5632.28.camel@scrabble-desktop> <470D32AA.5070601@codtech.com> Message-ID: <20071011004400.6ecb7e0c@amd64.entidi.local> On Wed, 10 Oct 2007 22:14:34 +0200 Diego Torres Milano wrote: > Tristan Van Berkom wrote: > > I didn't take the time to go through the whole tutorial but > > I think I get the idea, one little problem I see is that you > > are using the widget's name property, I think with a little > > collaboration we can setup the widget's name, auto, init and > > optional parameters separately from the widget name. > > > Widget name is used because the file continues to be a valid glade file > and can be edited through glade. > It would be nice to have somewhere to enter arbitrary properties and > values. Then it would be added as > myval > in the glade XML file. Properties cannot be used because they are defined in the class initialization. Anyway, as Diego, me also will be more than happy to have a chance to bind arbitrary key-value to an object. I think implementing it using g_object_{set,get}_data() should be possible, using the g_strduped text as the value and adding myval to the XML definitions. Checked GtkBuilder but found nothing on this matter. Ciao, -- Nicola