Re: Multi-threaded UI Freezes on GDK Call

2007-12-19 Thread Dan H
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


Re: Multi-threaded UI Freezes on GDK Call

2007-12-19 Thread Emmanuele Bassi

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: Button Callbacks

2007-12-19 Thread Tomas Carnecky
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: App blueprint, advice please!

2007-12-19 Thread Michael L Torrie
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


Problems to compile gtk with jhbuild + imendio patchs

2007-12-19 Thread Arx Cruz
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