Re : Confused about GDKPixBuf/Cairo interaction
--- En date de : Lun 18.2.13, Rena hyperhac...@gmail.com a écrit : Recently I've been developing a Game Boy emulator that uses GtkDrawingArea and GdkPixbuf to display the game screen. In addition to the game output I want to also be able to draw text and shapes on the display window, and Cairo seems to be the ideal way to draw shapes. I'm already using Cairo to copy the Pixbuf to the GtkDrawingArea, so that seems like a good sign that Cairo and GdkPixbuf should interact nicely. Hi, Not sure if this can help, but here's what I do. It uses GdkPixmap. double new_x,new_y; new_x=d_area-allocation.width; new_y=d_area-allocation.height; copy_gc=d_area-style-fg_gc[GTK_WIDGET_STATE (d_area)]; pixmap=gdk_pixmap_new(d_area-window,new_x,new_y,-1); cairo=gdk_cairo_create(pixmap); and then, on expose events: gdk_draw_drawable(d_area-window, copy_gc, pixmap, event-area.x, event-area.y, event-area.x, event-area.y, event-area.width, event-area.height); I also have to handle configure events (where the drawing area changes size). -- LL ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Help Broadway Backend
I tried this but I can not install this requirement: configure: error: Package requirements (glib-2.0 = 2.35.3atk = 2.7.5 pango = 1.32.4cairo = 1.10.0cairo-gobject = 1.10.0 gdk-pixbuf-2.0 = 2.27.1) were not met: No package 'pango' found When I run configure: bill@bill-laptop:~/Downloads/pango-1.32.6$ ./configure checking for a BSD-compatible install... /usr/bin/install -c checking whether build environment is sane... yes checking for a thread-safe mkdir -p... /bin/mkdir -p checking for gawk... gawk checking whether make sets $(MAKE)... yes checking whether make supports nested variables... yes checking build system type... i686-pc-linux-gnu checking host system type... i686-pc-linux-gnu checking for native Win32... no checking for gcc... gcc checking whether the C compiler works... yes checking for C compiler default output file name... a.out checking for suffix of executables... checking whether we are cross compiling... no 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 for style of include used by make... GNU checking dependency style of gcc... gcc3 checking for c++... c++ checking whether we are using the GNU C++ compiler... yes checking whether c++ accepts -g... yes checking dependency style of c++... gcc3 checking for sysconf... yes checking for getpagesize... yes checking how to run the C preprocessor... gcc -E checking for grep that handles long lines and -e... /bin/grep checking for egrep... /bin/grep -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 for unistd.h... (cached) yes checking sys/mman.h usability... yes checking sys/mman.h presence... yes checking for sys/mman.h... yes checking how to print strings... printf checking for a sed that does not truncate output... /bin/sed checking for fgrep... /bin/grep -F checking for ld used by gcc... /usr/bin/ld checking if the linker (/usr/bin/ld) is GNU ld... yes checking for BSD- or MS-compatible name lister (nm)... /usr/bin/nm -B checking the name lister (/usr/bin/nm -B) interface... BSD nm checking whether ln -s works... yes checking the maximum length of command line arguments... 1572864 checking whether the shell understands some XSI constructs... yes checking whether the shell understands +=... yes checking how to convert i686-pc-linux-gnu file names to i686-pc-linux-gnu format... func_convert_file_noop checking how to convert i686-pc-linux-gnu file names to toolchain format... func_convert_file_noop checking for /usr/bin/ld option to reload object files... -r checking for objdump... objdump checking how to recognize dependent libraries... pass_all checking for dlltool... dlltool checking how to associate runtime and link libraries... printf %s\n checking for ar... ar checking for archiver @FILE support... @ checking for strip... strip checking for ranlib... ranlib checking command to parse /usr/bin/nm -B output from gcc object... ok checking for sysroot... no checking for mt... mt checking if mt is a manifest tool... no checking for dlfcn.h... yes checking for objdir... .libs checking if gcc supports -fno-rtti -fno-exceptions... no checking for gcc option to produce PIC... -fPIC -DPIC checking if gcc PIC flag -fPIC -DPIC works... yes checking if gcc static flag -static works... yes checking if gcc supports -c -o file.o... yes checking if gcc supports -c -o file.o... (cached) yes checking whether the gcc linker (/usr/bin/ld) supports shared libraries... yes checking whether -lc should be explicitly linked in... no checking dynamic linker characteristics... GNU/Linux ld.so 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 checking how to run the C++ preprocessor... c++ -E checking for ld used by c++... /usr/bin/ld checking if the linker (/usr/bin/ld) is GNU ld... yes checking whether the c++ linker (/usr/bin/ld) supports shared libraries... yes checking for c++ option to produce PIC... -fPIC -DPIC checking if c++ PIC flag -fPIC -DPIC works... yes checking if c++ static flag -static works... yes checking if c++ supports -c -o file.o... yes checking if c++ supports -c -o file.o... (cached) yes checking whether the c++ linker (/usr/bin/ld) supports shared libraries... yes checking dynamic linker characteristics... (cached) GNU/Linux ld.so checking how to hardcode library paths into
Re: Help Broadway Backend
When I try to compile a older version of gtk+-3 (3.4.4), I have the same error: When I configure: bill@bill-laptop:~/Downloads/gtk+-3.4.4$ ./configure --prefix=/opt/gtk --enable-x11-backend --enable-broadway-backend checking for a BSD-compatible install... /usr/bin/install -c checking whether build environment is sane... yes checking for a thread-safe mkdir -p... /bin/mkdir -p checking for gawk... gawk checking whether make sets $(MAKE)... yes checking how to create a ustar tar archive... gnutar checking whether to enable maintainer-specific portions of Makefiles... yes checking whether make supports nested variables... yes checking for gcc... gcc checking whether the C compiler works... yes checking for C compiler default output file name... a.out checking for suffix of executables... checking whether we are cross compiling... no 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 for style of include used by make... GNU checking dependency style of gcc... gcc3 checking whether gcc and cc understand -c and -o together... yes checking for gcc option to accept ISO C99... -std=gnu99 checking for gcc -std=gnu99 option to accept ISO Standard C... (cached) -std=gnu99 checking whether make sets $(MAKE)... (cached) yes checking build system type... i686-pc-linux-gnu checking host system type... i686-pc-linux-gnu checking for native Win32... no checking for c++... c++ checking whether we are using the GNU C++ compiler... yes checking whether c++ accepts -g... yes checking dependency style of c++... gcc3 checking how to print strings... printf 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 fgrep... /bin/grep -F checking for ld used by gcc -std=gnu99... /usr/bin/ld checking if the linker (/usr/bin/ld) is GNU ld... yes checking for BSD- or MS-compatible name lister (nm)... /usr/bin/nm -B checking the name lister (/usr/bin/nm -B) interface... BSD nm checking whether ln -s works... yes checking the maximum length of command line arguments... 1572864 checking whether the shell understands some XSI constructs... yes checking whether the shell understands +=... yes checking how to convert i686-pc-linux-gnu file names to i686-pc-linux-gnu format... func_convert_file_noop checking how to convert i686-pc-linux-gnu file names to toolchain format... func_convert_file_noop checking for /usr/bin/ld option to reload object files... -r checking for objdump... objdump checking how to recognize dependent libraries... pass_all checking for dlltool... no checking how to associate runtime and link libraries... printf %s\n checking for ar... ar checking for archiver @FILE support... @ checking for strip... strip checking for ranlib... ranlib checking command to parse /usr/bin/nm -B output from gcc -std=gnu99 object... ok checking for sysroot... no checking for mt... mt checking if mt is a manifest tool... no checking how to run the C preprocessor... gcc -std=gnu99 -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 for dlfcn.h... yes checking for objdir... .libs checking if gcc -std=gnu99 supports -fno-rtti -fno-exceptions... no checking for gcc -std=gnu99 option to produce PIC... -fPIC -DPIC checking if gcc -std=gnu99 PIC flag -fPIC -DPIC works... yes checking if gcc -std=gnu99 static flag -static works... yes checking if gcc -std=gnu99 supports -c -o file.o... yes checking if gcc -std=gnu99 supports -c -o file.o... (cached) yes checking whether the gcc -std=gnu99 linker (/usr/bin/ld) supports shared libraries... yes checking whether -lc should be explicitly linked in... no checking dynamic linker characteristics... GNU/Linux ld.so 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 checking how to run the C++ preprocessor... c++ -E checking for ld used by c++... /usr/bin/ld checking if the linker (/usr/bin/ld) is GNU ld... yes checking whether the c++ linker (/usr/bin/ld) supports shared libraries... yes checking for c++ option to produce PIC... -fPIC -DPIC checking if c++ PIC flag -fPIC -DPIC works... yes checking if c++ static flag -static works... yes checking if c++ supports -c -o file.o... yes checking if c++ supports -c -o file.o... (cached) yes checking whether the c++
Re: Help Broadway Backend
You need to update your version of glib. On Sun, Feb 17, 2013 at 9:00 PM, Diego Felix (Bill) diegob...@gmail.comwrote: When I try to compile a older version of gtk+-3 (3.4.4), I have the same error: When I configure: bill@bill-laptop:~/Downloads/gtk+-3.4.4$ ./configure --prefix=/opt/gtk --enable-x11-backend --enable-broadway-backend checking for a BSD-compatible install... /usr/bin/install -c checking whether build environment is sane... yes checking for a thread-safe mkdir -p... /bin/mkdir -p checking for gawk... gawk checking whether make sets $(MAKE)... yes checking how to create a ustar tar archive... gnutar checking whether to enable maintainer-specific portions of Makefiles... yes checking whether make supports nested variables... yes checking for gcc... gcc checking whether the C compiler works... yes checking for C compiler default output file name... a.out checking for suffix of executables... checking whether we are cross compiling... no 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 for style of include used by make... GNU checking dependency style of gcc... gcc3 checking whether gcc and cc understand -c and -o together... yes checking for gcc option to accept ISO C99... -std=gnu99 checking for gcc -std=gnu99 option to accept ISO Standard C... (cached) -std=gnu99 checking whether make sets $(MAKE)... (cached) yes checking build system type... i686-pc-linux-gnu checking host system type... i686-pc-linux-gnu checking for native Win32... no checking for c++... c++ checking whether we are using the GNU C++ compiler... yes checking whether c++ accepts -g... yes checking dependency style of c++... gcc3 checking how to print strings... printf 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 fgrep... /bin/grep -F checking for ld used by gcc -std=gnu99... /usr/bin/ld checking if the linker (/usr/bin/ld) is GNU ld... yes checking for BSD- or MS-compatible name lister (nm)... /usr/bin/nm -B checking the name lister (/usr/bin/nm -B) interface... BSD nm checking whether ln -s works... yes checking the maximum length of command line arguments... 1572864 checking whether the shell understands some XSI constructs... yes checking whether the shell understands +=... yes checking how to convert i686-pc-linux-gnu file names to i686-pc-linux-gnu format... func_convert_file_noop checking how to convert i686-pc-linux-gnu file names to toolchain format... func_convert_file_noop checking for /usr/bin/ld option to reload object files... -r checking for objdump... objdump checking how to recognize dependent libraries... pass_all checking for dlltool... no checking how to associate runtime and link libraries... printf %s\n checking for ar... ar checking for archiver @FILE support... @ checking for strip... strip checking for ranlib... ranlib checking command to parse /usr/bin/nm -B output from gcc -std=gnu99 object... ok checking for sysroot... no checking for mt... mt checking if mt is a manifest tool... no checking how to run the C preprocessor... gcc -std=gnu99 -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 for dlfcn.h... yes checking for objdir... .libs checking if gcc -std=gnu99 supports -fno-rtti -fno-exceptions... no checking for gcc -std=gnu99 option to produce PIC... -fPIC -DPIC checking if gcc -std=gnu99 PIC flag -fPIC -DPIC works... yes checking if gcc -std=gnu99 static flag -static works... yes checking if gcc -std=gnu99 supports -c -o file.o... yes checking if gcc -std=gnu99 supports -c -o file.o... (cached) yes checking whether the gcc -std=gnu99 linker (/usr/bin/ld) supports shared libraries... yes checking whether -lc should be explicitly linked in... no checking dynamic linker characteristics... GNU/Linux ld.so 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 checking how to run the C++ preprocessor... c++ -E checking for ld used by c++... /usr/bin/ld checking if the linker (/usr/bin/ld) is GNU ld... yes checking whether the c++ linker (/usr/bin/ld) supports shared libraries... yes checking for c++ option to produce PIC... -fPIC -DPIC checking if c++ PIC flag -fPIC -DPIC works... yes checking if c++ static flag -static works...
Re: Help Broadway Backend
I installed a new version (2.35.7): bill@bill-laptop: pkg-config --modversion glib-2.0 2.35.7 But I can not remove old version 2.32.3, because of packages dependecies, like: ubuntu-desktop, ... How to update old version (2.32.3)? Em 18/02/2013 01:10, Jasper St. Pierre jstpie...@mecheye.net escreveu: You need to update your version of glib. On Sun, Feb 17, 2013 at 9:00 PM, Diego Felix (Bill) diegob...@gmail.comwrote: When I try to compile a older version of gtk+-3 (3.4.4), I have the same error: When I configure: bill@bill-laptop:~/Downloads/gtk+-3.4.4$ ./configure --prefix=/opt/gtk --enable-x11-backend --enable-broadway-backend checking for a BSD-compatible install... /usr/bin/install -c checking whether build environment is sane... yes checking for a thread-safe mkdir -p... /bin/mkdir -p checking for gawk... gawk checking whether make sets $(MAKE)... yes checking how to create a ustar tar archive... gnutar checking whether to enable maintainer-specific portions of Makefiles... yes checking whether make supports nested variables... yes checking for gcc... gcc checking whether the C compiler works... yes checking for C compiler default output file name... a.out checking for suffix of executables... checking whether we are cross compiling... no 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 for style of include used by make... GNU checking dependency style of gcc... gcc3 checking whether gcc and cc understand -c and -o together... yes checking for gcc option to accept ISO C99... -std=gnu99 checking for gcc -std=gnu99 option to accept ISO Standard C... (cached) -std=gnu99 checking whether make sets $(MAKE)... (cached) yes checking build system type... i686-pc-linux-gnu checking host system type... i686-pc-linux-gnu checking for native Win32... no checking for c++... c++ checking whether we are using the GNU C++ compiler... yes checking whether c++ accepts -g... yes checking dependency style of c++... gcc3 checking how to print strings... printf 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 fgrep... /bin/grep -F checking for ld used by gcc -std=gnu99... /usr/bin/ld checking if the linker (/usr/bin/ld) is GNU ld... yes checking for BSD- or MS-compatible name lister (nm)... /usr/bin/nm -B checking the name lister (/usr/bin/nm -B) interface... BSD nm checking whether ln -s works... yes checking the maximum length of command line arguments... 1572864 checking whether the shell understands some XSI constructs... yes checking whether the shell understands +=... yes checking how to convert i686-pc-linux-gnu file names to i686-pc-linux-gnu format... func_convert_file_noop checking how to convert i686-pc-linux-gnu file names to toolchain format... func_convert_file_noop checking for /usr/bin/ld option to reload object files... -r checking for objdump... objdump checking how to recognize dependent libraries... pass_all checking for dlltool... no checking how to associate runtime and link libraries... printf %s\n checking for ar... ar checking for archiver @FILE support... @ checking for strip... strip checking for ranlib... ranlib checking command to parse /usr/bin/nm -B output from gcc -std=gnu99 object... ok checking for sysroot... no checking for mt... mt checking if mt is a manifest tool... no checking how to run the C preprocessor... gcc -std=gnu99 -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 for dlfcn.h... yes checking for objdir... .libs checking if gcc -std=gnu99 supports -fno-rtti -fno-exceptions... no checking for gcc -std=gnu99 option to produce PIC... -fPIC -DPIC checking if gcc -std=gnu99 PIC flag -fPIC -DPIC works... yes checking if gcc -std=gnu99 static flag -static works... yes checking if gcc -std=gnu99 supports -c -o file.o... yes checking if gcc -std=gnu99 supports -c -o file.o... (cached) yes checking whether the gcc -std=gnu99 linker (/usr/bin/ld) supports shared libraries... yes checking whether -lc should be explicitly linked in... no checking dynamic linker characteristics... GNU/Linux ld.so 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 checking how to run the C++ preprocessor... c++ -E checking for ld used
Re: Confused about GDKPixBuf/Cairo interaction
2013/2/18 Colomban Wendling lists@herbesfolles.org Or maybe I got you wrong and you'd like to *draw* on your GdkPixbuf? I'm afraid this just isn't possible directly. If you really want to do that, you'll probably have to manually do some pixel conversion. You can create a Cairo surface of the pixbuf's size, draw on that, and then get the surface's pixels which you'd convert manually to the pixbuf format, and push those pixels to the pixbuf. But again, why would you need to draw specifically on a GdkPixbuf? Or you could just use Tadej Borovsak's code: http://www.gtkforums.com/viewtopic.php?t=5204 regards! ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Confused about GDKPixBuf/Cairo interaction
Le 19/02/2013 01:45, Rena a écrit : On Mon, Feb 18, 2013 at 9:24 AM, Colomban Wendling [...] Well, my emulator gets the pixel data from gdk_pixbuf_get_pixels() and writes into that buffer directly; that way it doesn't have to know anything about GDK and can draw pixels by just writing directly into memory, which saves a lot of overhead when it's rendering roughly 1.5 million pixels per second. The emulator also supports Lua extensions which give scripts an object wrapping the pixbuf and lets them draw on it. OK I see. If I use Cairo to draw shapes in the ::draw handler, that means I'd be painting the pixbuf to the GtkDrawingArea's surface, then drawing those shapes onto it? So the actual pixbuf contents wouldn't be modified. Yes. That could lead to complications if a script wants to e.g. produce a screenshot or read pixels back from the pixbuf, as it wouldn't see anything it had drawn itself. Indeed, nothing would be on the pixbuf but the original image. I guess at best I'd need to keep a separate surface around for scripts to draw on, and paint both of those onto the GtkDrawingArea. I guess that's 1 of 4 possibilities: *) use Cairo directly, e.g. instead of creating a buffer compatible with GdkPicbuf (or actually the GdkPixbuf buffer), create your own buffer that uses a Cairo-compatible format and just write to that. Then, you'd just have to create a CairoImageSurface for that buffer and could happily write to your buffer with Cairo. That's probably the faster solution. Note that apparently Cairo don't have any 3-bytes format, even RGB24 has a 4th unused byte. *) convert (manually) data back and forth to and from Cairo (Edscott Wilson pointed you a code doing this). This has the overhead of 2 conversions each time you want to draw on the pixbuf (not counting the conversion performed by GDK in the ::draw handler). *) implement a Cairo surface that can draw directly to the pixbuf (e.g. that does whatever conversion when performing drawings). I don't know how to do that but I guess it's feasible since Cairo already provides various kinds of surfaces (and have a GObject layer). *) handle 2 layers, the pixbuf and what's drawn on. It may show som use case (e.g. one could take a shot with or without additions) but probably only makes things more complex. Mainly I'm just confused at how GDK is using Cairo to do its painting, but they use two different pixel formats. I'm not 100% sure, but I guess they use the specific Cairo surfaces for their targets (e.g. XLib surfaces on X11, Win32 surfaces on Win32 and Quartz surfaces on OSX). And when drawing pixbuf, they convert it (using gdk_cairo_set_source_pixbuf()). ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Function completion for GVariant maybe types?
- if the maybe contains a value, return the NULL of the same type Do any software developers dare to think about extensions around the function g_variant_new_maybe once more? http://developer.gnome.org/glib/2.35/glib-GVariant.html#glib-GVariant.description Regards, Markus ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Function completion for GVariant maybe types?
On 20/02/13 09:45, Markus Elfring wrote: Do any software developers dare to think about extensions around the function g_variant_new_maybe once more? Ryan and I have explained several times why we don't think the semantics you requested are useful to have in GLib. Repeatedly asking for the same functions, without providing any more information, is not going to get these functions added. Repeating Ryan's question from before: Can you please explain, at a higher level, what you are trying to accomplish? I want to reset a variant variable is not the explanation he asked for. The explanation we want might look more like I want to use variants as values in a database, where 'maybe x' is a possible column type. Please explain. When you do, we will hopefully be able to either see why the functions and semantics you suggested are useful, or suggest a way you can achieve your high-level goal without them. If you want to use these functions in a particular module but you are not willing to explain why you need them, then they are not going to be added to GLib. Add them to that other module instead, or reconsider its design so you don't need them. - Returning to your original mail and making one last attempt to guess what it is that you want: It is important to distinguish between a variable that can point to a variant object (a variable of type GVariant *), and the variant object that it can point to. Variables of type GVariant * are mutable (can be set to point to a GVariant) and nullable (can be set to NULL). If what you want is a variable that contains maybe x, the simplest way is to have a GVariant * variable whose value is either a variant object of type x, or NULL. Variant objects are immutable, and have a particular type and value. You cannot change the type or value of a variant object, at all. What you *can* do is to change the value of a GVariant * variable, so it points to a *different* variant object. You only need to get into 'maybe' types if you have a container (e.g. serialized structure or D-Bus message) containing 'maybe x', in which case the immutability of variant objects makes your proposed semantics not very useful. g_variant_is_maybe I don't think this is worthwhile. If g_variant_is_maybe (GVariant *v) existed, it'd be exactly equivalent to: g_variant_is_of_type (v, G_VARIANT_TYPE_MAYBE) which is just as easy to write. g_variant_can_be_nothing/undefined/optional/maybe This is not meaningful. A GVariant object (the thing pointed to by a GVariant *) has a definite, immutable value: either it is Nothing, or Just x (for some x). GVariant objects are value-objects, not slots for value objects. A variant v is a maybe containing Nothing if and only if this expression is true: (g_variant_is_of_type (v, G_VARIANT_TYPE_MAYBE) g_variant_get_maybe (v) == NULL) If you are talking about a GVariant * variable (pointer to variant object) and you want a signature more like g_variant_location_can_be_null (GVariant **variable) then, no, that's impossible. GLib can't know what the semantics of your variable are: only you (and your code's documentation) can know that. Or, if you want the function's parameter to be a GVariantType rather than a GVariant, then this is just g_variant_type_is_maybe (type). g_variant_convert_to_maybe I see a need for a alternative to the interface g_variant_new_maybe. I would like to replace a maybe instance directly instead of allocating a new one. You can't replace a maybe instance. Variant objects are immutable: creating a new variant object with a different value is always a new allocation. It is possible to reassign a GVariant * variable to point to a different variant object, but that doesn't need a special function: just write the code. 4. g_variant_set_to_nothing/none How should a GVariant variable be reset to the special marker nothing after it was used with other concrete values for a while? Rather than messing about with maybe x types, I think you would find it much easier to have this structure: /* Contains a variant of type x, or NULL. * (transfer full) */ GVariant *my_variant = NULL; ... /* set the variable to a non-NULL value */ if (my_variant != NULL) g_variant_unref (my_variant); my_variant = g_variant_ref_sink (g_variant_new_int64 (y)); ... /* set the variable to a NULL value */ if (my_variant != NULL) g_variant_unref (my_variant); my_variant = NULL; and if you need to serialize it somewhere, *then and only then* wrap its current value in an immutable maybe x variant object: g_dbus_message_set_body (message, ..., g_variant_new_maybe (G_VARIANT_TYPE_INT64, my_variant), ...); (For x and int64 substitute whatever type the thing has, which you should know already - either hard-coded, or by reading a GVariantType * variable from your database schema or whatever - because you can't do anything useful with data of an unknown
can gir files be installed in another directory
Hello, I trying to port Cinnamon to Crux linux. But I see that Gobject-introspection places the gir files in /usr/local/gir-1.0 But in Crux it is forbidden to place files in /usr/local/ So is it possible to tell gobject-introspection to place the gir files in another directory. Regards, Roelof Wobben ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
G_DEBUG_LOCKS - use G_(UN)LOCK macros internally
Hi,
does this patch makes any sense?
diff --git a/glib/gthread.c b/glib/gthread.c
index ee87574..60cff76 100644
--- a/glib/gthread.c
+++ b/glib/gthread.c
@@ -522,7 +522,7 @@ G_DEFINE_QUARK (g_thread_error, g_thread_error)
/* Local Data {{{1 */
-static GMutexg_once_mutex;
+static G_LOCK_DEFINE(once_mutex);
static GCond g_once_cond;
static GSList *g_once_init_list = NULL;
@@ -610,24 +610,24 @@ g_once_impl (GOnce *once,
GThreadFunc func,
gpointer arg)
{
- g_mutex_lock (g_once_mutex);
+ G_LOCK(once_mutex);
while (once-status == G_ONCE_STATUS_PROGRESS)
-g_cond_wait (g_once_cond, g_once_mutex);
+g_cond_wait (g_once_cond, G_LOCK_NAME(once_mutex));
if (once-status != G_ONCE_STATUS_READY)
{
once-status = G_ONCE_STATUS_PROGRESS;
- g_mutex_unlock (g_once_mutex);
+ G_UNLOCK (once_mutex);
once-retval = func (arg);
- g_mutex_lock (g_once_mutex);
+ G_LOCK(once_mutex);
once-status = G_ONCE_STATUS_READY;
g_cond_broadcast (g_once_cond);
}
- g_mutex_unlock (g_once_mutex);
+ G_UNLOCK (once_mutex);
return once-retval;
}
@@ -669,7 +669,7 @@ gboolean
{
volatile gsize *value_location = location;
gboolean need_init = FALSE;
- g_mutex_lock (g_once_mutex);
+ G_LOCK(once_mutex);
if (g_atomic_pointer_get (value_location) == NULL)
{
if (!g_slist_find (g_once_init_list, (void*) value_location))
@@ -679,10 +679,10 @@ gboolean
}
else
do
- g_cond_wait (g_once_cond, g_once_mutex);
+ g_cond_wait (g_once_cond, G_LOCK_NAME(once_mutex));
while (g_slist_find (g_once_init_list, (void*) value_location));
}
- g_mutex_unlock (g_once_mutex);
+ G_UNLOCK (once_mutex);
return need_init;
}
@@ -710,10 +710,10 @@ void
g_return_if_fail (g_once_init_list != NULL);
g_atomic_pointer_set (value_location, result);
- g_mutex_lock (g_once_mutex);
+ G_LOCK(once_mutex);
g_once_init_list = g_slist_remove (g_once_init_list, (void*) value_location);
g_cond_broadcast (g_once_cond);
- g_mutex_unlock (g_once_mutex);
+ G_UNLOCK (once_mutex);
}
/* GThread {{{1 */
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: glib-mkenums in glib 2
I would like to see that information - even if I have no instant use for it - but I am pretty sure it will help a lot of people digging for information. Best Bernhard 2013/2/19 John Emmas john...@tiscali.co.uk: On 4 Jan 2013, at 10:49, Matthew Brush wrote: From the last few messages on this thread, it kind of sounds like your module search path is not set up correctly, that is, Python doesn't know where to look to import your modules/packages (try print(sys.path) to see which paths I mean). There's good docs about this on python.org (as well as all kinds of other excellent docs/tuts). Hi guys, I suppose everyone's probably forgotten all about this by now - so to recap... I was trying to use Visual Studio to do a complete build of libglib, including the various perl and python scripts such as 'glib-mkenums' and 'gdbus-codegen'. glib-mkenums eventually got solved but I couldn't build gdbus-codegen (which needs Python). My builds were consistently failing at lines which looked like this:- from . import something A few people suggested changing those lines to a simplified version:- import something but initial tests didn't look good, so I gave up. But yesterday I came across this thread at StackOverflow which gave me some further information to consider:- http://stackoverflow.com/questions/72852/how-to-do-relative-imports-in-python and finally, after a lot of patience I've just managed to make the build work! It does seem to be a problem with paths and I'm not yet sure what the minimum changes are. However, if anyone's still interested, I'll simplify it as much as I can and post the solution here sometime. John ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Notebook tab not correctly drawn if tab pos = BOTTOM (gtk 3.5.4, win32)
Hello, I was putting a GtkNotebook on a main window widget (using glade) and set the tab position to BOTTOM. This looks alright in glade. However, running the application itself one sees that the tabs are not drawn correctly (they retain round corners and the highlighting orange at the _top_ edge of the tab, while it should be at the bottom). see attach link. Looking through the code (git master gtknotebook.c) I can only guess where the respective drawing action might occur, and I can't see anything which might cause this behavior (specifically on windows). I was hesitating to file a bug report for this. Thomas NB: Alongside, I was curious whether the windows code is actually a separate code, a slight adaption of the trunk or completely the same (with switching #defines). http://www.imagetoo.com/images/gtk354win3.png + DAS BEDINGUNGSLOSE GRUNDEINKOMMEN [1]: Machen uns die Schweizer jetzt vor, wie es geht? JETZT IM UNI.DE MAGAZIN. Links: -- [1] http://uni.de/redaktion/bge-das-bedingungslose-grundeinkommen ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: can gir files be installed in another directory
On Fri, 2013-02-15 at 14:14 +0100, Chantal Wobben wrote:
Hello,
I trying to port Cinnamon to Crux linux.
But I see that Gobject-introspection places the gir files in
/usr/local/gir-1.0
No; like every other Autotools using component, it places them in
whatever you specify as --datadir.
And if what you're actually asking for is for it to use something
other than ${prefix}/share/gir-1.0 because you have some moral
objection to directories there - well, good luck patching the world,
because *tons* of things in the GNOME stack do that.
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Function completion for GVariant maybe types?
Ryan and I have explained several times why we don't think the semantics you requested are useful to have in GLib. I replied to your concerns. I was missing a bit more feedback in the meantime. Now I hope that our small discussion can be continued in constructive ways. I want to reset a variant variable is not the explanation he asked for. The explanation we want might look more like I want to use variants as values in a database, where 'maybe x' is a possible column type. I would appreciate the requested functionality also for such an use case. I need it for concrete adjustments in applications like a partition manager. Do you see the applicability by an open issue like Improvements for partition in-use indication? https://bugzilla.gnome.org/review?bug=621677attachment=205643 ... - because you can't do anything useful with data of an unknown type.) Thanks for your detailed response. How would you like to achieve the feature to set a nullable object to the special marker nothing while keeping the previous data type information? Regards, Markus ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Function completion for GVariant maybe types?
On 20/02/13 16:37, Markus Elfring wrote: I need it for concrete adjustments in applications like a partition manager. I don't see how this is relevant to GVariant. How are you using variants? What does the variant represent? What type is it? What data structure are they stored in? Why are you using a 'maybe' type, as opposed to a GVariant * that may be NULL? Do you see the applicability by an open issue like Improvements for partition in-use indication? https://bugzilla.gnome.org/review?bug=621677attachment=205643 I don't see anything in that patch that has anything to do with variants. How would you like to achieve the feature to set a nullable object to the special marker nothing while keeping the previous data type information? As far as I can see, not having this function in GLib doesn't prevent you from doing anything, because it's implementable in terms of GLib functions. That means this function should only exist in GLib if it is useful to other developers/other projects, and has an appropriate data model to be useful. Now, I don't think this *is* an appropriate data model in many (any?) situations: if you have a GVariant but you don't know what type it's meant to be, that probably means something has gone horribly wrong. If you're dealing with GVariants that mean something to your code, then your code should already know the right type. S ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Function completion for GVariant maybe types?
How are you using variants? I would like to achieve a mapping of nullable objects to indeterminate checkboxes for example. What data structure are they stored in? Candidate: template class Gtk::TreeModelColumn Why are you using a 'maybe' type, as opposed to a GVariant * that may be NULL? I would like to point out that a null pointer has got a different meaning in comparison to a specific object which was marked to contain nothing (representation for an unknown value). Such a nullable object can store valuable data type information, can't it? https://bugzilla.gnome.org/review?bug=621677attachment=205643 I don't see anything in that patch that has anything to do with variants. You are right. - I could not introduce the affected feature so far because the class library gtkmm does not support nullable containers yet, does it? http://developer.gnome.org/glibmm/2.34/classGlib_1_1VariantBase.html See also discussion on a topic like Clarification for the application of GVariant/Glib::Variant maybe types: https://mail.gnome.org/archives/gtkmm-list/2011-October/msg00051.html http://article.gmane.org/gmane.comp.gnome.gtkmm/25571 If you're dealing with GVariants that mean something to your code, then your code should already know the right type. I have got a different opinion for this design detail. I am also interested in generic programming for the design pattern Model-View-Controller. http://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller Regards, Markus ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Function completion for GVariant maybe types?
I would like to achieve a mapping of nullable objects to indeterminate
checkboxes for example.
A GVariant with 'maybe' type seems far too complicated for this.
Why?
I find that GVariant provides a general interface for the handling of nullable
data types.
I'd use an integer holding a tristate enum, { NO, INDETERMINATE, YES } (or
possibly a pair of booleans, to match how GtkCheckButton works).
Why do you prefer to use an enumeration instead of the other general application
programming interface?
If you need variants for some reason, { GVariant of type 'b' with value
FALSE, NULL, GVariant of type 'b' with value TRUE } is also a perfectly
good tristate.
I agree in principle. Now you try to reduce my request to a special case while I
am still looking for a more general solution.
If, for some reason, you absolutely need non-NULL variants with type
'mb' (maybe boolean), then you already know that your data model is
that you have variants of that type; so you can just make one of these
objects whenever you need a new variant, and you're done:
I do not think that I can refer to such preallocated objects if I would like to
reuse a template class like Gtk::TreeModelColumn.
There's no need to add functions to GLib for this; and in the time
you've spent arguing about it, you could have implemented all three of
those possibilities and possibly more, chosen the one you liked best,
and got on with whatever high-level problem you were solving.
I have got still a different opinion here which I tried to demonstrate in a
draft for the function g_variant_new_nothing_from_type.
https://mail.gnome.org/archives/gtk-devel-list/2011-December/msg00018.html
http://article.gmane.org/gmane.comp.gnome.gtk+.devel.general/21768/
If your data model is I have a variant, and I don't really know what it
means then... you don't really know what it means, and you can't do
anything particularly useful with it until you find out.
I disagree to your conclusion here. - I would like to copy the data type
information from the contained value into a new Nothing GVariant in an
efficient way. I do not really want to know the concrete copied data type if I
would like that this operation will be supported in a generic way so that it can
be reused by other class libraries like glibmm.
Model-view-controller programming shouldn't be an excuse for speculative
generalization. Don't make things more complicated than they need to be;
software is usually quite complicated enough already.
I see opportunities for further fine-tuning and improvement of the involved
APIs.
Regards,
Markus
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Function completion for GVariant maybe types?
On Wed, Feb 20, 2013 at 1:44 PM, Markus Elfring markus.elfr...@web.dewrote: I do not think that I can refer to such preallocated objects if I would like to reuse a template class like Gtk::TreeModelColumn. I disagree to your conclusion here. - I would like to copy the data type information from the contained value into a new Nothing GVariant in an efficient way. I do not really want to know the concrete copied data type if I would like that this operation will be supported in a generic way so that it can be reused by other class libraries like glibmm. I can't say I really understand what you want, but in glibmm you can: Glib::VariantBase v = Glib::VariantBase(); Which will create C++ VariantBase object that does not actually have an allocated GVariant backing it, e.g. v.gobj() == NULL In glibmm 2.36 it will be possible to test whether the GVariant is null or not by just doing if (v), see bug 690121. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Some shortcomings in gtestutils
Hi, everyone, I've been writing some tests for GtkFileChooserButton and putting them in gtk+/gtk/tests/filechooser.c - this is the old test suite, resurrected and alive. So, I've been learning what gtestutils provides. It is not bad, but it seems pretty pedestrian on some counts. These are some things I'd like to change, or at least for someone to point me in the right way of doing them: * Tests abort as soon as a test fails, since tests ultimately depend on variations of g_assert(). This is fine in that it makes the ensure things are okay code look the same as generic sanity check code. However, it also means that a test suite aborts as soon as it encounters the first test that doesn't pass. There is g_test_fail(), but the documentation pretty much only says, You can use this function if your test failed in a recoverable way. I don't know if that means that the test couldn't find a data file (but can continue anyway), or if it means call this if you want the test to fail but want the test suite to continue running. * It's hard to get a debugger up in the middle of make check. I can't think of a way to do it other than manually inserting code to sleep in the middle of the faulty test, and then attaching with a debugger manually. Maybe having an environment variable or something, so that I could run $ G_PAUSE_ON_FAILED_TESTS=1 make check when a test fails, I would get told, attach to $pid now or somthing. Maybe even have a G_NAME_OF_TEST_TO_PAUSE_IN variable to pause for a specific test, not any one that fails. * The documentation on gtestutils is far from stellar :) * Now that the a11y infrastructure is included in-the-box with GTK+, it sounds like a good idea to start putting an a11y-based testing infrastructure in GTK+ itself. For the file chooser's tests, I had to do some manual hacks to simulate, click this button, find the dialog, click the dialog's button... this is tricky C code that assumes too much knowledge of the internals of the toolkit, and I'd love to write some higher-level stuff instead for such tests. (Feel free to reply about this in a different thread - this could derail *this* thread pretty fast) :) Thoughts? We have a useful battery of tests now, and it only seems that improving the testing infrastructure could lead to people actually wanting to write more test code. Federico ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Notebook tab not correctly drawn if tab pos = BOTTOM (gtk 3.5.4, win32)
On Tue, 2013-02-19 at 18:39 +0100, th-pitsc...@uni.de wrote: I was putting a GtkNotebook on a main window widget (using glade) and set the tab position to BOTTOM. This looks alright in glade. However, running the application itself one sees that the tabs are not drawn correctly (they retain round corners and the highlighting orange at the _top_ edge of the tab, while it should be at the bottom). see attach link. Please file a bug about this. If you have time, file it with a minimal test case - a little program and the corresponding .ui file, or a little program with the Glade stuff embedded and using gtk_builder_add_from_string(). Federco ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Some shortcomings in gtestutils
On Thu, Feb 21, 2013 at 10:46 AM, Federico Mena Quintero feder...@gnome.org wrote: Hi, everyone, I've been writing some tests for GtkFileChooserButton and putting them in gtk+/gtk/tests/filechooser.c - this is the old test suite, resurrected and alive. So, I've been learning what gtestutils provides. It is not bad, but it seems pretty pedestrian on some counts. These are some things I'd like to change, or at least for someone to point me in the right way of doing them: Warning, controversial mail ahead. I've noticed that gtester and gtestutils is a little lackluster. I wanted to see what the GNOME community's thoughts on using an established xUnit framework like Google Test, CPPUnit or boost::test would be. I know, its C++. I get that's not appreciated around here. The only reason why I suggest considering frameworks like these is that they're incredibly powerful, easy to use and I've found that they can be applied to almost any situation, C or C++. Google Test addresses some of the concerns listed below, and does a lot more, like custom test environments, SetUp/TearDown fixtures, matchers (which allow you to do something like EXPECT_THAT (value, MatchesSomething ()), where that would be looking inside lists, variants, whatever). It also ties in really nicely with Google Mock, which allows you to define mock implementations of classes and control on a very fine level how those mock classes behave on a per-test basis. I've used Google Mock alongside in my own GObject projects to great effect[1], and I've been playing around with the idea to use GObject-Introspection to automatically generate them from GInterfaces. (Marketspeak: Google Test has some really strong credentials in this area. It is the test framework of choice for projects like Chromium, XBMC, Xorg and projects at Canonical, such as Unity, Nux and Compiz. Chromium in particular has tens of thousands of unit, integration, system and acceptance tests, mostly all written using Google Test. Self-promotion: Compiz has over 1350 Unit, Integration and Acceptance tests, and works very well with Google Test). Its just some food for thought - I agree with Federico that having a flexible, powerful and easy to use test framework certainly lowers a substantial barrier to entry . *snip* I think that some of the ideas you've raised here are excellent. To address some of your concerns: 1. Most xUnit frameworks I know of have something like ASSERT_* and EXPECT_*. The former will set the test to failed and return directly. The latter will just set the test to failed and continue. Generally speaking, it is acceptable to have multiple ASSERT_ statements because they usually belong in SetUp/TearDown logic. ASSERT_ usually means this test failed because it could not be run due to a failed precondition in SetUp. Ideally, every test should have only one EXPECT_* statement. The EXPECT_* statement is the essence of the test, and tests should test one thing so that you have pinpoint resolution as to which part of the unit failed. 2. The best way to handle this case is to expose the test binary in the build-directory so that users can run it directly. Sometimes you might have multiple test binaries, but that is fine. Ideally no test should have any dependency on the previous test finishing. If that happens, then you've got a serious problem with your code. 3. This is a good point 4. This is an excellent idea for bootstrapping an acceptance testing framework. Care should always be taken when writing acceptance tests though, in particular: a. They aren't a replacement for unit or integration tests. They run particularly slowly, and are usually more failure prone because they can be impacted by external factors that you might not expect. The best kind of code coverage is code covered at a unit, integration and acceptance level. b. Acceptance testing can also be tricky because they often rely on introspection through, eg, the a11y interface. That can create unwanted coupling between the internals of your system and the test, which means that you'll be constantly adjusting the tests as the code is adjusted. Determine what kind of interface you want to expose for test verification and make the tests rely on that. c. Running on some kind of dummy display server (eg, wayland, xorg with the dummy video driver[2]) is always a good idea because it means that you don't have awkward situations where you can't get tests running in continuous integration servers. Tests that aren't run are broken tests. d. Never ever ever ever ever ever ever ever ever rely on sleep()s, timing, or whatever in the tests when verifying conditions. Autopilot in Unity does this and it is a giant fail. Otherwise, great to see these topics are being talked about. [1] http://bazaar.launchpad.net/~compiz-team/compiz/0.9.9/files/head:/gtk/window-decorator/tests/ [2] Xorg-GTest is good for this. Federico ___ gtk-devel-list
Re: GUI Testing (was: Some shortcomings in gtestutils)
On Feb 20, 2013, at 6:46 PM, Federico Mena Quintero feder...@gnome.org wrote: * Now that the a11y infrastructure is included in-the-box with GTK+, it sounds like a good idea to start putting an a11y-based testing infrastructure in GTK+ itself. For the file chooser's tests, I had to do some manual hacks to simulate, click this button, find the dialog, click the dialog's button... this is tricky C code that assumes too much knowledge of the internals of the toolkit, and I'd love to write some higher-level stuff instead for such tests. (Feel free to reply about this in a different thread - this could derail *this* thread pretty fast) :) There are two ways to go about GUI testing. One is to retrieve the coordinates of a control and inject a mouse or keyboard event at those coordinates, the other is to give every control an id that can be used to send events to. The first is incredibly brittle and the second is AFAIK supported only by wxWidgets. [1] ISTR that there was an implementation of the coordinate-tracking sort for Gtk1, but I've lost track of it. It would be a pretty big change to Gtk to introduce control ids and event injectability. Regards, John Ralls [1] http://wxguitest.sourceforge.net/ ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Function completion for GVariant maybe types?
On 20 Feb 2013, at 21:44, Markus Elfring wrote: Why do you prefer to use an enumeration instead of the other general application programming interface? Hi Markus. Until a couple of days ago I'd never even encountered GVariant so forgive me if I've misunderstood the concept - but from what you've written, it seems like you want to be able to map a nullable object to the state of a checkbox for some reason. However, according to the description for GVariant:- GVariant instances always have a type and a value (which are given at construction time). The type and value of a GVariant instance can never change other than by the GVariant itself being destroyed. So GVariant doesn't seem to be a suitable type for mapping the state of something whose state can change. Could that be why there's so much reluctance to implement what you want? As I said, forgive me if I've misunderstood the concept. Just making an observation. John___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Some shortcomings in gtestutils
On Thu, Feb 21, 2013 at 1:17 PM, Peter Hutterer peter.hutte...@who-t.net wrote: Having worked with googletest and xorg-gtest [1] for X integration testing, I can say the most annoying bit is to get the whole thing to compile. The C++ ODR prevents us from building gtest and xorg-gtest as library and then compiling against that. and autotools is not happy with having external source files. if you're planning to share a test framework across multiple source repositories, that can be a major pain. [1] http://cgit.freedesktop.org/~whot/xorg-integration-tests/ I agree, this is the one drawback of google-test. *snip* fwiw, one of the drawbacks I found with the multiple binary case is that it reduces the chance of running all tests every time. there's a sweet spot somewhere between too many and too few binaries and I suspect it differs for each project. A good way to handle that is to have a separate test-runner that runs the make check/test target. That can usually just be a makefile rule or something else (in compiz we use ctest) for the googletest case for example separate binaries will give you a separate junit xml output, which make some regression comparisons harder. We ran into this problem as well. I think the solution was two fold: 1. First of all, we wanted to be able to introspect test binaries so that the test runner would be able to show each individual one. [1] is a massive hack, but it works. 2. Second of all, we had to patch google-test to shut up about skipped tests in the junit.xml so that Jenkins didn't think you had like 600,000 tests or something. I can provide this patch upon request, its just somewhere in the midsts of the Canonical Jenkins deployment. [1] http://bazaar.launchpad.net/~compiz-team/compiz/0.9.9/view/head:/cmake/src/compiz/compiz_discover_gtest_tests.cpp -- Sam Spilsbury ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Some shortcomings in gtestutils
On Thu, Feb 21, 2013 at 02:39:21PM +0800, Sam Spilsbury wrote: On Thu, Feb 21, 2013 at 1:17 PM, Peter Hutterer peter.hutte...@who-t.net wrote: Having worked with googletest and xorg-gtest [1] for X integration testing, I can say the most annoying bit is to get the whole thing to compile. The C++ ODR prevents us from building gtest and xorg-gtest as library and then compiling against that. and autotools is not happy with having external source files. if you're planning to share a test framework across multiple source repositories, that can be a major pain. [1] http://cgit.freedesktop.org/~whot/xorg-integration-tests/ I agree, this is the one drawback of google-test. *snip* fwiw, one of the drawbacks I found with the multiple binary case is that it reduces the chance of running all tests every time. there's a sweet spot somewhere between too many and too few binaries and I suspect it differs for each project. A good way to handle that is to have a separate test-runner that runs the make check/test target. That can usually just be a makefile rule or something else (in compiz we use ctest) yeah, I've hooked it up to make check, but that has other issues too. I should really write a script for that. fwiw, we still have multiple binaries (evdev, synaptics, server, libXi, etc.) But initially I had multiple binaries for the server to test various server features (grab, multihead, touch, etc.). Since the features aren't clear-cut though (where do you put touch grab tests?) I found having a single server binary was better. This is what I meant with there being a sweet spot for each project that needs to be found. for the googletest case for example separate binaries will give you a separate junit xml output, which make some regression comparisons harder. We ran into this problem as well. I think the solution was two fold: 1. First of all, we wanted to be able to introspect test binaries so that the test runner would be able to show each individual one. [1] is a massive hack, but it works. 2. Second of all, we had to patch google-test to shut up about skipped tests in the junit.xml so that Jenkins didn't think you had like 600,000 tests or something. I can provide this patch upon request, its just somewhere in the midsts of the Canonical Jenkins deployment. oh, right. that hasn't been a problem for me so far, the jenkins install always runs all tests. the tricky bit for me was tracking which tests are supposed to fail (e.g. on RHEL6 tests for newer features are known-to-fail). so far I'm tracking this largely manually, but the known-to-fail case shouldn't be much of an use-case for an upstream project. Cheers, Peter [1] http://bazaar.launchpad.net/~compiz-team/compiz/0.9.9/view/head:/cmake/src/compiz/compiz_discover_gtest_tests.cpp -- Sam Spilsbury ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
