reparent issues
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi All, I have some code that does this where windowid is an X window id. And window is a gtk_window_new(GTK_WINDOW_TOPLEVEL). window_container = gdk_window_foreign_new(windowid); gdk_window_reparent(window-window,window_container,0,0); gtk_widget_map(window); When I use beryl, this works perfectly, but when I use metacity as my window manager, the window won't embed... Am I doing this wrong or should I look someplace else. Thanks, Kevin - -- Get my public GnuPG key from http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0x7D0BD5D1 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFF2jOW6w2kMH0L1dERAj3AAJ4j+vH+xs3KMi36be/0YLkRYf8KiQCfcQs4 MPlFBKu2GblMeqqCLDimy+M= =/dZ2 -END PGP SIGNATURE- ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
gdk_window_at_pointer and foreign windows
Hi, I'm pretty new to the whole GDK programming area. I have a question on managing foreign windows using GDK. I have a foreign window which I've registered with GDK using gdk_window_foreign_new. However, calling gdk_window_at_pointer when the mouse pointer is over the window returns me null. My theory for this is that child windows of the registered window might be blocking GDK from seeing the window that it has registered. I've no idea if this is actually the case or not though. If you call this method and the window directly under the pointer is a non-GDK window, will GDK go back up the X windows tree until it finds a GDK window? Thanks in advance for any help. Kevin. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Cairo in tooltips
Hello, Since the new tooltips API allows us to put custom widgets in a tooltip, I thought it would be nice to make that widget be a drawing area showing an alpha transparent Cairo drawing. So I wrote testcairotooltips.c for fun. You can see how it looks like [1] or even download it [2]. (I built it in gtk+/tests so the archive also contains a small patch for Makefile.am.) The rectangle drawing code is from cairo snippets. My first idea was to put a balloon, but I don't know how to draw it quickly yet since I've just started learning Cairo for real. But perhaps the container drawing doesn't have to be drawn in code at all; instead it could be loaded from a .svg with librsvg and cached at program startup or idle time. Then some text could be rendered over that context with Pango. While this approach could be taken instead of the usual (mostly) boring tooltips, a program could have something like a help mode which would turn on extended tooltips showing more text and some small images to help the user. This is just an idea of course. I think that this is useful and gives more pleasant experience to the user, thus not just useless eye candy. If you think that it is a good idea to suggest the developers to consider making such tooltips then perhaps it would be good to make it even easier in the API. For instance, calling: gtk_widget_create_tooltip_cairo_context (GtkWidget *widget, cairo_t *cr) and a query-tooltip-draw signal (instead of query-tooltip for this purpose) would be enough, while internally a window with the alpha colormap would be set with drawing area for which this Cairo context is created. (I'm CC-ing gtk-app-devel-list since I guess there might be people interested to hear this.) Marko [1] http://marko.anastasov.name/cairotooltip.png [2] http://marko.anastasov.name/testcairotooltips.tar.gz ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Problems with Threading Concept
On Mon, 2007-02-19 at 12:42 +0530, naveen wrote:
#include gtk/gtk.h
#include stdio.h
#include pthread.h
int flag=1,toggle=0;
int i=0;
pthread_t yes_tid;
void hello()
{
while (flag)
{
gdk_threads_enter ();
printf (%d %d\n,i++,flag);
if (gtk_events_pending())
gtk_main_iteration(); // Handle unprocessed GTK events
gdk_threads_leave ();
}
}
void hello_print( GtkWidget *widget,
gpointer data )
{
if(toggle==0)
{
toggle=1;
flag=1;
pthread_create (yes_tid, NULL,(void *)hello, NULL);
}
else
{
flag=0;
toggle=0;
}
}
int main(int argc,
char *argv[] )
{
GtkWidget *window;
GtkWidget *button;
g_thread_init (NULL);
gdk_threads_init ();
gdk_threads_enter ();
gtk_init (argc, argv);
/* create a new window */
window = gtk_window_new (GTK_WINDOW_TOPLEVEL);
g_signal_connect (G_OBJECT (window), destroy,
G_CALLBACK (gtk_main_quit), NULL);
gtk_container_set_border_width (GTK_CONTAINER (window), 100);
button = gtk_button_new_with_label(click it);
g_signal_connect (G_OBJECT (button), clicked,
G_CALLBACK (hello_print), NULL);
gtk_container_add (GTK_CONTAINER (window), button);
gtk_widget_show (button);
gtk_widget_show (window);
gtk_main ();
gdk_threads_leave ();
return 0;
}
Naveen,
Look at these changes. A B C
A. gdk_thread_enter/leave() is used to surround the gtk_main loop and
any gtk_* functions called from another thread. In A you are not
calling and gtk_ functions. I see that you plan too though, when you do
surrond just the group of calls with the gdk_thread... statements.
Also, you should strong consider using g_thread_create() and the glib
set of functions for multithreaded gtk applications. see devHelp, a
locally installed api documentation tool, for how-to usage of the glib
functions
B. You have re-implemented the gtk_main() loop here; which is a vaild
construct -just not needed at this level programing. The gtk_main loop
in the first (main) thread is active and running, trying to handle ALL
gtk commands, this is simply a duplication that adds nothing.
C. In the correct place, immediately before and after, the gtk_main()
these calls serve a vaild function to serialize access to gdk/gtk global
variables. Managing the resource action will become more difficult when
you start adding more threads or gdk/gtk functions in other threads.
Focus on starting out right and following this before/after guideline
got gtk_main.
General Comment:
The design of a multi-threaded GTK application deserves some time
investment and design consideration. Read this tutorial link:
http://www.gtk.org/faq/#AEN482;.Also, read this for GLIB thread
functions, the preferred choice for GTK multi-threaded programming:
http://developer.gnome.org/doc/API/2.0/glib/glib-Threads.html;.
You are going to find very quickly that using gdk/gtk functions in
anything except the main thread is a real pain to control and manage;
BUT it can and has been done by many. As a design point you should
minimize the need to do so. Given that: consider this for IO related
thread-like work, GLIB provide the g_io_add_watch()/g_io_channel... set
of functions that are pre-integrated into GTK/GDK cleanly. For other
programming actions GDK/GTK/GLIB provides a collection of thread-like
constructs to run functions via timers and idles -
g_timeout_add()/g_idle_add(). Most of what I have mentioned thus far
does not require the use of gdk_thread_enter/leave(), and are considered
multi-threaded in behaviour.
Lastly, g_thread_create() and the whole GLIB collection of thread
support routines are available. As are a collection of inter-thread
communication methods like GASyncQueue(), mutex's, semaphores, and
conditions. Combined these standard tools and functions will allow you
to create high performance applications that use GDK/GTK graphics
capabilities without hindrance. Just do a little design work first, and
keep asking questions and looking at existing code that uses these
api's.
James,
#include gtk/gtk.h
#include stdio.h
#include pthread.h
int flag=1,toggle=0;
int i=0;
pthread_t yes_tid;
void hello()
{
while (flag)
{
/*-A gdk_threads_enter (); -- your not going gtk thing here so you
don't need this !! */
printf (%d %d\n,i++,flag);
/*-B if (gtk_events_pending()) -- never do this unless your
certain what your doing */
/* gtk_main_iteration(); */
/*-A gdk_threads_leave ();--- again not needed */
}
}
void hello_print( GtkWidget *widget,
gpointer data )
{
if(toggle==0)
{
toggle=1;
flag=1;
pthread_create (yes_tid, NULL,(void *)hello, NULL);
}
else
{
flag=0;
toggle=0;
}
}
Re: gdk_window_at_pointer and foreign windows
On Mon, 2007-02-19 at 23:55 +, Kevin O'Riordan wrote: I'm pretty new to the whole GDK programming area. I have a question on managing foreign windows using GDK. I have a foreign window which I've registered with GDK using gdk_window_foreign_new. However, calling gdk_window_at_pointer when the mouse pointer is over the window returns me null. My theory for this is that child windows of the registered window might be blocking GDK from seeing the window that it has registered. Yes. I've no idea if this is actually the case or not though. Have you tried reading the source? Look in gdk/x11/gdkwindow-x11.c. If you call this method and the window directly under the pointer is a non-GDK window, will GDK go back up the X windows tree until it finds a GDK window? No. How big a problem is this? What are you actually trying to do here? Ed ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
