Problems to compile gtk with jhbuild + imendio patchs
Hi guys, Sorry if is the wrong place to post this, but im having problems in compile Gtk with Quartz support through imendio patchs using jhbuild, All packages compiles very well, but when i try compile gtk i have this error: gcc -DHAVE_CONFIG_H -I. -I. -I../../.. -I../../../modules/other -I../../../gdk -I../../../gdk -I../../../gtk -I../../../gtk -DGTK_VERSION=\" 2.15.0\" -I/opt/gtk/include -D_REENTRANT -I/opt/gtk/include/glib-2.0-I/opt/gtk/lib/glib- 2.0/include -I/opt/gtk/include/pango-1.0 -I/opt/gtk/include/cairo -I/opt/gtk/include/libpng12 -I/opt/gtk/include/atk-1.0 -DG_ENABLE_DEBUG -DG_ERRORCHECK_MUTEXES -DG_DISABLE_DEPRECATED -O -gstabs+3 -std=gnu89 -Wall -MT libgail_la-gailwindow.lo -MD -MP -MF .deps/libgail_la-gailwindow.Tpo -c gailwindow.c -fno-common -DPIC -o .libs/libgail_la-gailwindow.o gailwindow.c: In function 'gail_window_get_name': gailwindow.c:349: warning: passing argument 1 of 'gtk_container_get_children' from incompatible pointer type gailwindow.c:1093:2: error: #error Port to this GDK backend make[5]: *** [libgail_la-gailwindow.lo] Error 1 make[4]: *** [all-recursive] Error 1 make[3]: *** [all-recursive] Error 1 make[2]: *** [all-recursive] Error 1 make[1]: *** [all-recursive] Error 1 make: *** [all] Error 2 I try find something in google but no success. If i remove the #if GDK_WINDOWING_WIN32 things, compiles but then when i try link others librarys ldconfig throws a error. Any idea whats wrong ? Cheers -- "A fé remove montanhas, mas eu prefiro a dinamite" ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: App blueprint, advice please!
Patrick wrote: > Lets say a customer had a detector and a pump to pump a sample through > it. We could write a Bash script that works something like this: > > -icon launches Bash script > -sends variable " 2" to pump command to pump 2 ml per minute > -pump command sends signal to serial port or GPIB bus, etc > -bash sends variable "230" to set the detector to wavelength 230 nm > -bash autozeros detector > -launches plot command > -after that launches data process command > -then launches database storage command > - emails whoever, turns your coffee maker on or whateveretc..etc Seems to me that the lingua franca of this kind of scientific instrument control and data collection is LabView. Most institutions already have site license for this software. LabView is ideal for several reasons: - Works with most GPIB cards, indeed most interface cards come with labview drivers - Easy graphical environment. Lets you chain things together (in a similar manner to bash, actually), but it's all within the program, rather than kludging together non-integrated programs. Plus it's all in-process. No external spawning things needed, which is expensive. - Royalty free code. You can sell you "vi" programs or give them away, or whatever. They aren't compiled, but can be obfuscated, or not. So you could sell labview code that people could modify. On the other hand, there's no reason why you couldn't use GTK and, say, Python to do similar things provided that you have drivers for the GPIB boards, and have a well-defined interface that you can use to easily build modules that you can string together. Certainly I don't believe C is the appropriate language to do any gluing. I would recommend python. Data collection modules that need to be close to the hardware can be done in C, but the rest could easily be done in python. If you defined a protocol for modules to communicate with each other, then you can very easily string modules together, hooking data out buses on one module (object) with the data in on another module. The GTK signals and slots mechanism would make this quite easy to do, all in-process. Michael > > It's a terrible over simplification but hopefully illustrates the idea. > > I only have a few hundred dollars to put towards this now but hopefully > by the later half of 2008 it will be a few thousand. Please feedback > with any thoughts you might have on this whole process. Thanks-Patrick > > > > > ___ > gtk-app-devel-list mailing list > gtk-app-devel-list@gnome.org > http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list > -- Michael Torrie Assistant CSR, System Administrator Chemistry and Biochemistry Department Brigham Young University Provo, UT 84602 +1.801.422.5771 ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Button Callbacks
Vroni wrote: > Hi guys, > > I have this really dumb problem, but I can´t get my head around it. My > program should do the following: > > - When a button is pressed, a specific playlist[m3u]-file should be > opened in the media player. > > Sure, the first part is to add a callback for the buttons, but how do I > open the file (and with it the media player. It should do the same as a > double click on the file would)? > Is it even possible to do do it this way? In a terminal, you'd do: $ xdg-open /path/to/playlist.m3u In your callback you'd probably want to use system() or g_spawn_async(), see the man pages and http://www.gtk.org/api/2.6/glib/glib-Spawning-Processes.html tom ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Multi-threaded UI Freezes on GDK Call
On Tue, 2007-12-18 at 20:37 -0500, Michael McCann wrote: > Yes, I've already tried that, to no avail. My code basically only > consists of: > > gdk_screen_get_default(): Get the default screen > gdk_screen_get_root_window(): Get the root window > gdk_pixbuf_get_from_drawable(): Get a pixbuf from the entire screen > gdk_pixbuf_save_to_bufferv(): Save the pixbuf to a buffer. taking a screenshot of the root window takes a considerable amount of time, depending on the size of the screen and the amount of windows on it. gnome-screenshot forks in the background to avoid blocking the UI; since GDK cannot be called from multiple threads, forking is the only option you have. ciao, Emmanuele. -- Emmanuele Bassi, W: http://www.emmanuelebassi.net B: http://log.emmanuelebassi.net ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Multi-threaded UI Freezes on GDK Call
On Tue, 18 Dec 2007 22:52:23 +0100 G Hasse <[EMAIL PROTECTED]> wrote: > The wrong thing is trying to do threads! > > Why Why Why are all people doing this thread programing! > I am convinced that with a propper design of your application, > maybe in several processe, you don't need threads and your > problem will go away... No, threads are not the problem. Not keeping ALL GUI-related things in ONE thread is the problem. I may have been missing the point, but it seems that this is the core of the OP's troubles. The problem with threads is that few beginners understand what they actually are. --D. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list