I can't understand the difference output of only a line differ
Hi,
I tried gdk_draw_image with a small program, but the behavior is very
confusing, please help me find out whats happening.
With the sleep(1) the program shows nothing, but without it the window
will show, why?
Thanks.
Bin
#include gtk/gtk.h
main(int argc, char **argv)
{
int ret;
gtk_init(argc, argv);
GtkWidget *win;
GtkWidget *drawing;
GdkImage *img;
GdkGC *gc;
win = gtk_window_new(GTK_WINDOW_TOPLEVEL);
drawing = gtk_drawing_area_new();
gtk_widget_set_size_request(drawing, 200, 200);
gtk_container_add(GTK_CONTAINER(win), drawing);
img = gdk_image_new(GDK_IMAGE_FASTEST, gdk_visual_get_system(),
200, 200);
memset(img-mem, 1, 200 * 200 * 2);
gtk_widget_show_all(win);
gc = gdk_gc_new(drawing-window);
while (1) {
sleep(1);
gdk_draw_image(drawing-window, gc, img, 0, 0, 0, 0, 200, 200);
}
gtk_main();
}
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Can gdk image attach to a window?
Hi, I am writing a video player using a commercial codec library. The library will callback my function when one frame of video has been decoded. The decoded frame is placed in a memory which is set by me. And the callback is started in another thead different from main thread. I know xlib has big problem when using in multi threaded environment. So I can't update a widget that is created in main thread. The problem comes, if I create all the widget in main thread, then I can't manipulate the widget in the callback. So GdkImage helps me, because I can tell the library to put the decoded bitmap in GdkImage-mem. But how can GdkImage draw to screen automatically? I only know I can use gdk_draw_image to draw a GdkImage to a drawing area, this means I need to call this function in main thread to display the GdkImage, damn!! Is there any better way? I think if I can attach a GdkImage to a widget then the problem resolved. Thanks. Bin ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: I can't understand the difference output of only a line differ
On Thu, 2007-12-06 at 17:40 +0800, Binary Chen wrote:
while (1) {
sleep(1);
gdk_draw_image(drawing-window, gc, img, 0, 0, 0, 0, 200, 200);
}
you are blocking with your own loop before entering inside the gtk+ main
loop with the following call:
gtk_main();
if you want to wait one second before drawing onto the window, use
g_timeout_add() and call gdk_draw_image() inside the callback passed to
that function.
please, read the documentation about the GLib main loop at:
http://library.gnome.org/devel/glib/stable/glib-The-Main-Event-Loop.html
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: I can't understand the difference output of only a line differ
On Thu, 2007-12-06 at 10:41 +, Emmanuele Bassi wrote:
On Thu, 2007-12-06 at 17:40 +0800, Binary Chen wrote:
while (1) {
sleep(1);
gdk_draw_image(drawing-window, gc, img, 0, 0, 0, 0, 200, 200);
}
you are blocking with your own loop before entering inside the gtk+ main
loop with the following call:
gtk_main();
But without the sleep() I will also not reach gtk_main(), but the window
shows, why? What I am asking is this.
Thanks.
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: I can't understand the difference output of only a line differ
On Thu, 2007-12-06 at 18:54 +0800, Binary Chen wrote: But without the sleep() I will also not reach gtk_main(), but the window shows, why? What I am asking is this. I'm guessing that it fills the drawing buffer and forces a flush. That is, with the sleep, given enough time, you will see the same result. You just need to be patient. Thanks. -- behdad http://behdad.org/ ...very few phenomena can pull someone out of Deep Hack Mode, with two noted exceptions: being struck by lightning, or worse, your *computer* being struck by lightning. -- Matt Welsh ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: I can't understand the difference output of only a line differ
On Thu, 2007-12-06 at 06:01 -0500, Behdad Esfahbod wrote: On Thu, 2007-12-06 at 18:54 +0800, Binary Chen wrote: But without the sleep() I will also not reach gtk_main(), but the window shows, why? What I am asking is this. I'm guessing that it fills the drawing buffer and forces a flush. That is, with the sleep, given enough time, you will see the same result. You just need to be patient. How long? Are you sure? Thanks. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: I can't understand the difference output of only a line differ
there's no need to reply to me: I'm subscribe to the list, so reply
there.
On Thu, 2007-12-06 at 18:54 +0800, Binary Chen wrote:
On Thu, 2007-12-06 at 10:41 +, Emmanuele Bassi wrote:
On Thu, 2007-12-06 at 17:40 +0800, Binary Chen wrote:
while (1) {
sleep(1);
gdk_draw_image(drawing-window, gc, img, 0, 0, 0, 0, 200, 200);
}
you are blocking with your own loop before entering inside the gtk+ main
loop with the following call:
gtk_main();
But without the sleep() I will also not reach gtk_main(), but the window
shows, why? What I am asking is this.
gdk_draw_image() forces a flush. but that is not the problem: you should
never use a while() loop inside a GTK+ application, because you are
effectively blocking the real main loop from spinning. remember: GTK+ is
not threaded.
use a timeout or an idle source to repaint your window with the
GdkImage.
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: I can't understand the difference output of only a line differ
On Thu, 2007-12-06 at 19:08 +0800, Binary Chen wrote: On Thu, 2007-12-06 at 06:01 -0500, Behdad Esfahbod wrote: On Thu, 2007-12-06 at 18:54 +0800, Binary Chen wrote: But without the sleep() I will also not reach gtk_main(), but the window shows, why? What I am asking is this. I'm guessing that it fills the drawing buffer and forces a flush. That is, with the sleep, given enough time, you will see the same result. You just need to be patient. How long? Enough time. Are you sure? I'm guessing. Thanks. -- behdad http://behdad.org/ ...very few phenomena can pull someone out of Deep Hack Mode, with two noted exceptions: being struck by lightning, or worse, your *computer* being struck by lightning. -- Matt Welsh ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: I can't understand the difference output of only a line differ
On Thu, 2007-12-06 at 11:33 +, Emmanuele Bassi wrote:
there's no need to reply to me: I'm subscribe to the list, so reply
there.
On Thu, 2007-12-06 at 18:54 +0800, Binary Chen wrote:
On Thu, 2007-12-06 at 10:41 +, Emmanuele Bassi wrote:
On Thu, 2007-12-06 at 17:40 +0800, Binary Chen wrote:
while (1) {
sleep(1);
gdk_draw_image(drawing-window, gc, img, 0, 0, 0, 0,
200, 200);
}
you are blocking with your own loop before entering inside the gtk+ main
loop with the following call:
gtk_main();
But without the sleep() I will also not reach gtk_main(), but the window
shows, why? What I am asking is this.
gdk_draw_image() forces a flush. but that is not the problem: you should
never use a while() loop inside a GTK+ application, because you are
effectively blocking the real main loop from spinning. remember: GTK+ is
not threaded.
Yes, I know GTK+ is not threaded, there is only one thread running, so
this make things more complecated, whats loop am I prohibit running?
Again I'd like to say in both testing the gtk_main() is not running at
all, so whats the difference? Can you point out the exact source of such
headache problem?
use a timeout or an idle source to repaint your window with the
GdkImage.
This is just a testing program, not production code, I just want to find
out whats happening.
Thanks.
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
how to destroy window if ptr to mainWindow not known
Hi all, the problem is when loading windows from the xml file: glade_xml = glade_xml_new(ami.glade,NULL,NULL); I need to know the reference to main window (GtkWindow) to be able to destroy it, yes? I can get it like this: window = glade_xml_get_widget(glade_xml,window1); and destroy: gtk_widget_destroy(window); But what if there is no window1 in the glade file? Let's say updated xml changed the name to mainWindow? Window exists on the screen, but how to delete it? regards, LUK ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: I can't understand the difference output of only a line differ
On Thu, 2007-12-06 at 19:40 +0800, Binary Chen wrote: gdk_draw_image() forces a flush. but that is not the problem: you should never use a while() loop inside a GTK+ application, because you are effectively blocking the real main loop from spinning. remember: GTK+ is not threaded. Yes, I know GTK+ is not threaded, there is only one thread running, so this make things more complecated, whats loop am I prohibit running? the main loop that processes and delivers the events and handles the redraws, and that is invoked by gtk_main(). you should read the GTK+ documentation, at this point. Again I'd like to say in both testing the gtk_main() is not running at all, so whats the difference? Can you point out the exact source of such headache problem? the exact source is, in this case, a PEBKAC; the documentation available on how GTK+ works (at this level, at least) is quite abundant; the GTK+ tutorial should shed some more light. use a timeout or an idle source to repaint your window with the GdkImage. This is just a testing program, not production code, I just want to find out whats happening. what's happening is that you are blocking the main loop from ever running, so any result you see is an undefined behaviour. for the third time: use a timeout/idle source instead of the while() loop to hook into the GTK+ main loop. 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: I can't understand the difference output of only a line differ
On Thu, 2007-12-06 at 06:40 -0500, Behdad Esfahbod wrote: On Thu, 2007-12-06 at 19:08 +0800, Binary Chen wrote: On Thu, 2007-12-06 at 06:01 -0500, Behdad Esfahbod wrote: On Thu, 2007-12-06 at 18:54 +0800, Binary Chen wrote: But without the sleep() I will also not reach gtk_main(), but the window shows, why? What I am asking is this. I'm guessing that it fills the drawing buffer and forces a flush. That is, with the sleep, given enough time, you will see the same result. You just need to be patient. How long? Enough time. Are you sure? I'm guessing. Thanks. To be more helpful, and hopefully you understand it, in the case without the sleep, your loop is running over and over, very first. So, what may seem to you like immediate rendering of the window may actually not happen before (for example) the 1000th iteration of the loop. Now if you wait for the 1000th iteration of your loop with the sleep, you should get the same result. 1000 being just a guess. -- behdad http://behdad.org/ ...very few phenomena can pull someone out of Deep Hack Mode, with two noted exceptions: being struck by lightning, or worse, your *computer* being struck by lightning. -- Matt Welsh ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: I can't understand the difference output of only a line differ
On Thu, 2007-12-06 at 11:53 +, Emmanuele Bassi wrote: On Thu, 2007-12-06 at 19:40 +0800, Binary Chen wrote: gdk_draw_image() forces a flush. but that is not the problem: you should never use a while() loop inside a GTK+ application, because you are effectively blocking the real main loop from spinning. remember: GTK+ is not threaded. Yes, I know GTK+ is not threaded, there is only one thread running, so this make things more complecated, whats loop am I prohibit running? the main loop that processes and delivers the events and handles the redraws, and that is invoked by gtk_main(). you should read the GTK+ documentation, at this point. Again I'd like to say in both testing the gtk_main() is not running at all, so whats the difference? Can you point out the exact source of such headache problem? the exact source is, in this case, a PEBKAC; the documentation available on how GTK+ works (at this level, at least) is quite abundant; the GTK+ tutorial should shed some more light. use a timeout or an idle source to repaint your window with the GdkImage. This is just a testing program, not production code, I just want to find out whats happening. what's happening is that you are blocking the main loop from ever running, so any result you see is an undefined behaviour. for the third time: use a timeout/idle source instead of the while() loop to hook into the GTK+ main loop. You don't know my situation. I am writing a media player which need to copy the decoded bitmap into screen. I am using gdk_draw_image to draw a GdkImage to the drawing area. g_timeout_add is too slow because it need to update the screen 20 times/sec. So I need to use a FAST blit to screen, which is only possible using busy while... but only if the delay is very small using usleep(1), the result is - no things on screen. Image a situation that a thread is doing decoding and put the result in somewhere memory, another thread drawing to GTK+ widget. Bin ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: I can't understand the difference output of only a line differ
Binary Chen wrote: You don't know my situation. I am writing a media player which need to copy the decoded bitmap into screen. I am using gdk_draw_image to draw a GdkImage to the drawing area. g_timeout_add is too slow because it need to update the screen 20 times/sec. So I need to use a FAST blit to screen, which is only possible using busy while... but only if the delay is very small using usleep(1), the result is - no things on screen. Image a situation that a thread is doing decoding and put the result in somewhere memory, another thread drawing to GTK+ widget. You don't seem to understand: You can not use a while loop. At all. Ever! It simply won't work! Use something else, but _not_ the while loop! tom ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: I can't understand the difference output of only a line differ
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Binary Chen wrote: On Thu, 2007-12-06 at 11:53 +, Emmanuele Bassi wrote: On Thu, 2007-12-06 at 19:40 +0800, Binary Chen wrote: gdk_draw_image() forces a flush. but that is not the problem: you should never use a while() loop inside a GTK+ application, because you are effectively blocking the real main loop from spinning. remember: GTK+ is not threaded. Yes, I know GTK+ is not threaded, there is only one thread running, so this make things more complecated, whats loop am I prohibit running? the main loop that processes and delivers the events and handles the redraws, and that is invoked by gtk_main(). you should read the GTK+ documentation, at this point. Again I'd like to say in both testing the gtk_main() is not running at all, so whats the difference? Can you point out the exact source of such headache problem? the exact source is, in this case, a PEBKAC; the documentation available on how GTK+ works (at this level, at least) is quite abundant; the GTK+ tutorial should shed some more light. use a timeout or an idle source to repaint your window with the GdkImage. This is just a testing program, not production code, I just want to find out whats happening. what's happening is that you are blocking the main loop from ever running, so any result you see is an undefined behaviour. for the third time: use a timeout/idle source instead of the while() loop to hook into the GTK+ main loop. You don't know my situation. I am writing a media player which need to copy the decoded bitmap into screen. I am using gdk_draw_image to draw a GdkImage to the drawing area. g_timeout_add is too slow because it need to update the screen 20 times/sec. So I need to use a FAST blit to screen, which is only possible using busy while... but only if the delay is very small using usleep(1), the result is - no things on screen. Image a situation that a thread is doing decoding and put the result in somewhere memory, another thread drawing to GTK+ widget. A couple of notes: 1) with a threaded application, you must make sure that *ALL* gtk calls are done *ONLY* from one thread. Any multi-thread calls into gtk will lead to unexplained behaviour, possibly including unexplained crashes. 2) When you write a busy loop, as you have, you are *not* giving the gtk library any chance AT all to update the screen. Updating teh screen essentially happens in the gtk_mail loop (or the idle loop), which gets called when you return from your callback. While you have not given us all your code, between what you have given us, and the above, it sounds like when your thread sleeps()'s, it is giving the gtk_main a chance to run. 3) one ugly hack (and it is just that, an ugly hack), would be do to the following in your while loop: while( gtk_events_pending()) gtk_main_iteration(); This will drain the queued up gtk events (including the display events), and you'll be happy. 4) Having said that, the fact that you have a forever loop and need to do this highly suggests that you have a design error. You REALLY should have a callback that is processing all the queued up images, and then returns. Perhaps this should even be a g_idle_add() callback if there is no convenient way to invoke it via some other callback method. - -G Bin ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list - -- +-+ Please also check the log file at /dev/null for additional information. (from /var/log/Xorg.setup.log) | Greg Hosler [EMAIL PROTECTED]| +-+ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFHV/67404fl/0CV/QRAjZmAJ9iYJVSU+xDjPLiW/0qGLpZOlceEwCgmoS5 +JNnCApXBOSEd0H6LoSinMc= =K9nu -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
Re: I can't understand the difference output of only a line differ
again: no need to reply to me directly. On Thu, 2007-12-06 at 20:29 +0800, Binary Chen wrote: what's happening is that you are blocking the main loop from ever running, so any result you see is an undefined behaviour. for the third time: use a timeout/idle source instead of the while() loop to hook into the GTK+ main loop. You don't know my situation. I read your other emails in this thread and I can say I understood fairly well your situation; and yet, you don't seem to understand what I'm saying to you: what are you doing leads to undefined behaviours, so *don't do it*. I am using gdk_draw_image to draw a GdkImage to the drawing area. why are you using a GdkImage in the first place? can't you just use a client-side pixbuf and then blit it to the target widget using gdk_draw_pixbuf() instead? anyway: g_timeout_add is too slow because it need to update the screen 20 times/sec. 20 times per sec is 50 msecs, which is fairly doable for a timeout source; you might want to disable the double buffering and set the widget you're drawing on as paintable, to squeeze it every millisecond. in any case, instead of using a timeout you can use an idle source with g_idle_add_full(), and setting a fairly high priority (but probably lower than GDK_PRIORITY_REDRAW to avoid useless tearing). So I need to use a FAST blit to screen, which is only possible using busy while... there already is a busy loop: it's the GTK+ main loop. you can hook into it, but you cannot avoid calling it because (and this is the central bit) it leads to undefined behaviours like you witnessed. aside from this, I cannot stress enough that it seems to me you don't know GTK+ (let alone GDK) well enough. so my recommendation is for you to spend some time learning and getting acquainted with how GTK+ works first. 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: how to destroy window if ptr to mainWindow not known
On Dec 6, 2007 4:46 AM, Lukasz Gromotowicz [EMAIL PROTECTED] wrote: Hi all, the problem is when loading windows from the xml file: glade_xml = glade_xml_new(ami.glade,NULL,NULL); I need to know the reference to main window (GtkWindow) to be able to destroy it, yes? I can get it like this: window = glade_xml_get_widget(glade_xml,window1); and destroy: gtk_widget_destroy(window); But what if there is no window1 in the glade file? Let's say updated xml changed the name to mainWindow? Window exists on the screen, but how to delete it? I don't think the glade file should be edited while the program is running... or is that what you are doing? ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: how to destroy window if ptr to mainWindow not known
- Original Message From: Jim George [EMAIL PROTECTED] To: Lukasz Gromotowicz [EMAIL PROTECTED] Cc: gtk-app-devel-list@gnome.org Sent: Thursday, December 6, 2007 8:45:24 AM Subject: Re: how to destroy window if ptr to mainWindow not known On Dec 6, 2007 4:46 AM, Lukasz Gromotowicz [EMAIL PROTECTED] wrote: Hi all, the problem is when loading windows from the xml file: glade_xml = glade_xml_new(ami.glade,NULL,NULL); I need to know the reference to main window (GtkWindow) to be able to destroy it, yes? I can get it like this: window = glade_xml_get_widget(glade_xml,window1); and destroy: gtk_widget_destroy(window); But what if there is no window1 in the glade file? Let's say updated xml changed the name to mainWindow? Window exists on the screen, but how to delete it? I don't think the glade file should be edited while the program is running... or is that what you are doing? --- As far as I'm concerned, you should look at the glade file as one of the source files. If it is changed, other things may need to be changed to reflect it. It isn't an unrelated file, as config files can be. Looking for last minute shopping deals? Find them fast with Yahoo! Search. http://tools.search.yahoo.com/newsearch/category.php?category=shopping ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: how to destroy window if ptr to mainWindow not known
Maybe you are right. The problem appeared when I have updated the software and .glade but forgot to copy .glade to the destination machine. I could not see any messages, program just did not start. It took me some time to find the problem. It looks like I have to live with it ;0 regards, LUK 2007/12/6, Lance Dillon [EMAIL PROTECTED]: - Original Message From: Jim George [EMAIL PROTECTED] To: Lukasz Gromotowicz [EMAIL PROTECTED] Cc: gtk-app-devel-list@gnome.org Sent: Thursday, December 6, 2007 8:45:24 AM Subject: Re: how to destroy window if ptr to mainWindow not known On Dec 6, 2007 4:46 AM, Lukasz Gromotowicz [EMAIL PROTECTED] wrote: Hi all, the problem is when loading windows from the xml file: glade_xml = glade_xml_new(ami.glade,NULL,NULL); I need to know the reference to main window (GtkWindow) to be able to destroy it, yes? I can get it like this: window = glade_xml_get_widget(glade_xml,window1); and destroy: gtk_widget_destroy(window); But what if there is no window1 in the glade file? Let's say updated xml changed the name to mainWindow? Window exists on the screen, but how to delete it? I don't think the glade file should be edited while the program is running... or is that what you are doing? --- As far as I'm concerned, you should look at the glade file as one of the source files. If it is changed, other things may need to be changed to reflect it. It isn't an unrelated file, as config files can be. Looking for last minute shopping deals? Find them fast with Yahoo! Search. http://tools.search.yahoo.com/newsearch/category.php?category=shopping ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: I can't understand the difference output of only a line differ
Binary Chen wrote: Hi, I tried gdk_draw_image with a small program, but the behavior is very confusing, please help me find out whats happening. [...] I've read through the thread detailing your GTK troubles. I also know you are trying to write a custom GTK player for a particular multimedia format. I just wanted to throw out the possibility of asking your client whether they have any interest in open sourcing the video codec itself? Take this step and there is a community of fanatical open source multimedia enthusiasts (myself included) who would try to incorporate the codec into FFmpeg (ffmpeg.org), at which point it would be accessible to a huge number of existing media players. Think about it... -- -Mike Melanson ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: how to destroy window if ptr to mainWindow not known
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Lukasz Gromotowicz schrieb: Hi all, the problem is when loading windows from the xml file: glade_xml = glade_xml_new(ami.glade,NULL,NULL); I need to know the reference to main window (GtkWindow) to be able to destroy it, yes? I can get it like this: window = glade_xml_get_widget(glade_xml,window1); and destroy: gtk_widget_destroy(window); glade_xml_get_widget() returns NULL if the widget does not exists you can check if window is not NULL and after that you can call gtk_main or exit the app But what if there is no window1 in the glade file? Let's say updated xml changed the name to mainWindow? Window exists on the screen, but how to delete it? I believe that in a old version of libglade, glade shows all toplevel widgets even if gtk_widget_show_all was not called. With a current version I never saw this again. - -- Jens Sauer [EMAIL PROTECTED] OpenPGP key D3CA3DAF - - to verify attachments use 'gpg --verify FILENAME.sig FILENAME' -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHWDjnS6CQotPKPa8RAmPnAJ4i3RDmBG08WvNDVQHd6q82yg3G8QCfVfhD F8A0Ci7njApZUj1bbpfAtd4= =yk9l -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
Re: how to destroy window if ptr to mainWindow not known
I do check glade_xml_new() and all glade_xml_get_widget() for NULL return. Problem is that the gtk_main() is already running as I create new windows in events / callbacks from the existing window. All I would like to do is not to create and not to show the new window if there are any problems. regards, LUK 2007/12/6, Jens Sauer [EMAIL PROTECTED]: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Lukasz Gromotowicz schrieb: Hi all, the problem is when loading windows from the xml file: glade_xml = glade_xml_new(ami.glade,NULL,NULL); I need to know the reference to main window (GtkWindow) to be able to destroy it, yes? I can get it like this: window = glade_xml_get_widget(glade_xml,window1); and destroy: gtk_widget_destroy(window); glade_xml_get_widget() returns NULL if the widget does not exists you can check if window is not NULL and after that you can call gtk_main or exit the app But what if there is no window1 in the glade file? Let's say updated xml changed the name to mainWindow? Window exists on the screen, but how to delete it? I believe that in a old version of libglade, glade shows all toplevel widgets even if gtk_widget_show_all was not called. With a current version I never saw this again. - -- Jens Sauer [EMAIL PROTECTED] OpenPGP key D3CA3DAF - - to verify attachments use 'gpg --verify FILENAME.sig FILENAME' -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHWDjnS6CQotPKPa8RAmPnAJ4i3RDmBG08WvNDVQHd6q82yg3G8QCfVfhD F8A0Ci7njApZUj1bbpfAtd4= =yk9l -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 ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Scrolling in ComboBox popup
Is there a way to control scrolling in the popup for a ComboBox? I have a ComboBox with only 10 items. The ComboBox pops up a window with the active item positioned near the top. If the active item is not one of the first two items, then scrollbars appear and there is a vast empty space below the last item. I can scroll to the top, at which point the scrollbars disappear and the items neatly fill the space that was originally available. I don't understand why the ComboBox is resorting to scrollbars when the popup has enough room for all items. Is there a way to tell the ComboBox not to use scrollbars? Can I force the first item to appear so that the scrollbars disappear? -- Jeffrey Barish ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
ComboBox and set_cell_data_func
I am using set_cell_data_func with a ComboBox. I noticed that when I call the append method of the TreeStore, set_cell_data_func is called twice. The first time, the row has not yet been written into the TreeStore, so the set_cell_data_func can't perform its function. Is there a reason that GTK calls set_cell_data_func twice? -- Jeffrey Barish ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: I can't understand the difference output of only a line differ
On Thu, 2007-12-06 at 13:59 +, Emmanuele Bassi wrote: again: no need to reply to me directly. On Thu, 2007-12-06 at 20:29 +0800, Binary Chen wrote: what's happening is that you are blocking the main loop from ever running, so any result you see is an undefined behaviour. for the third time: use a timeout/idle source instead of the while() loop to hook into the GTK+ main loop. You don't know my situation. I read your other emails in this thread and I can say I understood fairly well your situation; and yet, you don't seem to understand what I'm saying to you: what are you doing leads to undefined behaviours, so *don't do it*. I am using gdk_draw_image to draw a GdkImage to the drawing area. why are you using a GdkImage in the first place? can't you just use a client-side pixbuf and then blit it to the target widget using gdk_draw_pixbuf() instead? anyway: g_timeout_add is too slow because it need to update the screen 20 times/sec. 20 times per sec is 50 msecs, which is fairly doable for a timeout source; you might want to disable the double buffering and set the widget you're drawing on as paintable, to squeeze it every millisecond. in any case, instead of using a timeout you can use an idle source with g_idle_add_full(), and setting a fairly high priority (but probably lower than GDK_PRIORITY_REDRAW to avoid useless tearing). So I need to use a FAST blit to screen, which is only possible using busy while... there already is a busy loop: it's the GTK+ main loop. you can hook into it, but you cannot avoid calling it because (and this is the central bit) it leads to undefined behaviours like you witnessed. aside from this, I cannot stress enough that it seems to me you don't know GTK+ (let alone GDK) well enough. so my recommendation is for you to spend some time learning and getting acquainted with how GTK+ works first. Thanks !! I solved this by using g_timeout_add, sorry for my misunderstanding becoz I vaguely remember g_timeout_add take the parameter in second precision, wrong. And another problem is after I set the priority to -90, the window's close button seems not very responsive, I think the GTK+ is busying doing the timeout function, so what priority you suggest to use in this application? Thanks! Bin ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: I can't understand the difference output of only a line differ
On Thu, 2007-12-06 at 09:40 -0800, Mike Melanson wrote: I just wanted to throw out the possibility of asking your client whether they have any interest in open sourcing the video codec itself? Now would be a good time, if the codec might be useable on the Web -- see for example http://www.webvideosummit.com/ -- especially if it not encumbered by software patents that you [Binary Chen's client] don't control... Liam -- Liam Quin - XML Activity Lead, W3C, http://www.w3.org/People/Quin/ Pictures from old books: http://fromoldbooks.org/ Ankh: irc.sorcery.net irc.gnome.org www.advogato.org ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Linear Scaling of fonts with FreeType on Cairo
I'm trying to find a way to scale fonts linearly. As far as I can tell, the way to do it is to use a freetype font and turn hinting off. Using the API, I tried to pull some code together that would try to do that, but unfortunately, the font is still scaling non-linearly. cairo_font_options_t *options; PangoFontMap*fm; PangoContext*context; fm = pango_cairo_font_map_new_for_font_type (CAIRO_FONT_TYPE_FT); pango_cairo_font_map_set_resolution (PANGO_CAIRO_FONT_MAP(fm), 96); context = pango_cairo_font_map_create_context (PANGO_CAIRO_FONT_MAP(fm)); options = cairo_font_options_create (); cairo_font_options_set_hint_style (options, CAIRO_HINT_STYLE_NONE); pango_cairo_context_set_font_options (context, options); . During runtime I receive the following error: Pango-CRITICAL **: pango_cairo_font_map_create_context: assertion `PANGO_IS_CAIRO_FONT_MAP (fontmap)' failed Specifically, how can I use a PangoCairoFontMap in such a scenario? The documentation states that I should be getting such a structure upon calling pango_cairo_font_map_new_for_font_type. However, all I get is a PangoFontMap. I'm not sure what the difference is between these two structures and/or if one can be type cast onto another. More generally, how can I scale fonts linearly using the Pango, Cairo API? Tutorials, guides would be very helpful. Thanks, Karl ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
GtkComboBox - how to clear and repopulate in one step?
I am using gtk_combo_box_new_text() to setup a combo box to display a list of strings. However, the documentation states that in this case you can only use the following set of related (convenience) functions to manipulate the ComboBox: gtk_combo_box_append_text() gtk_combo_box_insert_text() gtk_combo_box_prepend_text() gtk_combo_box_remove_text() which then makes it a bit tedious to clear out (i.e. delete all entries) the ComboBox because you then have to call gtk_combo_box_remove_text() specifying the index of the entries one by one. Is there any other way to conveniently or simply remove all entries (strings in my case) from the ComboBox preferably in one function call? Is there another way I should be using the GtkComboBox? I have two comboboxes in my application: the selection in the first combo affects what data (strings) gets populated in the second combo. Hence the reason why I need to be able to clear and (re)populate the combo box very quickly and preferably in one call. I am using GTK+ 2.10.4 on CentOS 5. Thanks! Salman Ahmed Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now. http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Linear Scaling of fonts with FreeType on Cairo
On Thu, 2007-12-06 at 19:01 -0800, Karl Reis wrote: I'm trying to find a way to scale fonts linearly. As far as I can tell, the way to do it is to use a freetype font and turn hinting off. Using the API, I tried to pull some code together that would try to do that, but unfortunately, the font is still scaling non-linearly. You're on the right track. All font backends are supposed to support that but I'm not sure how non-freetype ones handle it right now. cairo_font_options_t *options; PangoFontMap*fm; PangoContext*context; fm = pango_cairo_font_map_new_for_font_type (CAIRO_FONT_TYPE_FT); pango_cairo_font_map_set_resolution (PANGO_CAIRO_FONT_MAP(fm), 96); context = pango_cairo_font_map_create_context (PANGO_CAIRO_FONT_MAP(fm)); options = cairo_font_options_create (); cairo_font_options_set_hint_style (options, CAIRO_HINT_STYLE_NONE); pango_cairo_context_set_font_options (context, options); During runtime I receive the following error: Pango-CRITICAL **: pango_cairo_font_map_create_context: assertion `PANGO_IS_CAIRO_FONT_MAP (fontmap)' failed What's your platform? This pretty much means that pango_cairo_font_map_new_for_font_type() returned NULL, which according to the docs, means that pango detected at compile time that your cairo isn't compiled with the freetype font backend enabled. Most of the time you just need pango_cairo_font_map_get_default(). Specifically, how can I use a PangoCairoFontMap in such a scenario? The documentation states that I should be getting such a structure upon calling pango_cairo_font_map_new_for_font_type. However, all I get is a PangoFontMap. I'm not sure what the difference is between these two structures and/or if one can be type cast onto another. PangoCairoFontMap is a PangoFontMap. Think object-oriented programming. More generally, how can I scale fonts linearly using the Pango, Cairo API? You are setting hint_style. That affects rendering of the glyphs but not their extents. You should turn metrics hinting off for that. cairo_font_options_set_hint_metrics(). Tutorials, guides would be very helpful. A tutorial is in the works right now, but far from complete: http://bugzilla.gnome.org/show_bug.cgi?id=50 Thanks, Karl Have fun with pangocairo! -- behdad http://behdad.org/ ...very few phenomena can pull someone out of Deep Hack Mode, with two noted exceptions: being struck by lightning, or worse, your *computer* being struck by lightning. -- Matt Welsh ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
RE: Linear Scaling of fonts with FreeType on Cairo
Thank you for your excellent reply! I modified the code per your suggestions and it worked perfectly. Here is the full snippet of code for anyone else who might find this useful: cairo_font_options_t*options; cairo_t *cr; PangoFontMap*fm; PangoContext*context; PangoLayout *layout; PangoFontDescription*pfd; cr = gdk_cairo_create (pixmap); fm = pango_cairo_font_map_get_default (); pango_cairo_font_map_set_resolution (PANGO_CAIRO_FONT_MAP(fm), 96); context = pango_cairo_font_map_create_context (PANGO_CAIRO_FONT_MAP(fm)); options = cairo_font_options_create (); cairo_font_options_set_hint_style (options, CAIRO_HINT_STYLE_NONE); cairo_font_options_set_hint_metrics (options, CAIRO_HINT_METRICS_OFF); pango_cairo_context_set_font_options (context, options); layout = pango_layout_new (context); pango_layout_set_text (layout,text_string,-1); pfd = pango_font_description_new (); pango_font_description_set_size (pfd,12*PANGO_SCALE*scale_factor); pango_layout_set_font_description (layout,pfd); cairo_move_to (cr, x, y); pango_cairo_show_layout (cr,layout); So, I guess I ended up using some default font which I presume is not a freetype font. But, it worked. To answer your question below, I did check for NULL and indeed the font map created was NULL which means as you indicate that the cairo I have is not compiled with the freetype backend enabled. For what it's worth, I also tried it with the TOY font and I got the same error. I am running on mingw windows with the binaries derived straight from Tor's page. Thanks again for your help, Karl -Original Message- From: Behdad Esfahbod [mailto:[EMAIL PROTECTED] On Behalf Of Behdad Esfahbod Sent: Thursday, December 06, 2007 2127 PM To: Karl Reis Cc: gtk-app-devel-list@gnome.org Subject: Re: Linear Scaling of fonts with FreeType on Cairo On Thu, 2007-12-06 at 19:01 -0800, Karl Reis wrote: I'm trying to find a way to scale fonts linearly. As far as I can tell, the way to do it is to use a freetype font and turn hinting off. Using the API, I tried to pull some code together that would try to do that, but unfortunately, the font is still scaling non-linearly. You're on the right track. All font backends are supposed to support that but I'm not sure how non-freetype ones handle it right now. cairo_font_options_t *options; PangoFontMap*fm; PangoContext*context; fm = pango_cairo_font_map_new_for_font_type (CAIRO_FONT_TYPE_FT); pango_cairo_font_map_set_resolution (PANGO_CAIRO_FONT_MAP(fm), 96); context = pango_cairo_font_map_create_context (PANGO_CAIRO_FONT_MAP(fm)); options = cairo_font_options_create (); cairo_font_options_set_hint_style (options, CAIRO_HINT_STYLE_NONE); pango_cairo_context_set_font_options (context, options); During runtime I receive the following error: Pango-CRITICAL **: pango_cairo_font_map_create_context: assertion `PANGO_IS_CAIRO_FONT_MAP (fontmap)' failed What's your platform? This pretty much means that pango_cairo_font_map_new_for_font_type() returned NULL, which according to the docs, means that pango detected at compile time that your cairo isn't compiled with the freetype font backend enabled. Most of the time you just need pango_cairo_font_map_get_default(). Specifically, how can I use a PangoCairoFontMap in such a scenario? The documentation states that I should be getting such a structure upon calling pango_cairo_font_map_new_for_font_type. However, all I get is a PangoFontMap. I'm not sure what the difference is between these two structures and/or if one can be type cast onto another. PangoCairoFontMap is a PangoFontMap. Think object-oriented programming. More generally, how can I scale fonts linearly using the Pango, Cairo API? You are setting hint_style. That affects rendering of the glyphs but not their extents. You should turn metrics hinting off for that. cairo_font_options_set_hint_metrics(). Tutorials, guides would be very helpful. A tutorial is in the works right now, but far from complete: http://bugzilla.gnome.org/show_bug.cgi?id=50 Thanks, Karl Have fun with pangocairo! -- behdad http://behdad.org/ ...very few phenomena can pull someone out of Deep Hack Mode, with two noted exceptions: being struck by lightning, or worse, your *computer* being struck by lightning. -- Matt Welsh ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
RE: Linear Scaling of fonts with FreeType on Cairo
Great! On Thu, 2007-12-06 at 22:38 -0800, Karl Reis wrote: I also tried it with the TOY font and I got the same error. The toy font backend is not a real backend. Pango doesn't recognize it and can't use it. The available ones are FreeType, win32, and ATSUI. You are using win32 obviously. -- behdad http://behdad.org/ ...very few phenomena can pull someone out of Deep Hack Mode, with two noted exceptions: being struck by lightning, or worse, your *computer* being struck by lightning. -- Matt Welsh ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
RE: Linear Scaling of fonts with FreeType on Cairo
I see. Yes, that's right as the error went away when I explicitly specified the win32 font. -Original Message- From: Behdad Esfahbod [mailto:[EMAIL PROTECTED] On Behalf Of Behdad Esfahbod Sent: Thursday, December 06, 2007 2302 PM To: Karl Reis Cc: gtk-app-devel-list@gnome.org Subject: RE: Linear Scaling of fonts with FreeType on Cairo Great! On Thu, 2007-12-06 at 22:38 -0800, Karl Reis wrote: I also tried it with the TOY font and I got the same error. The toy font backend is not a real backend. Pango doesn't recognize it and can't use it. The available ones are FreeType, win32, and ATSUI. You are using win32 obviously. -- behdad http://behdad.org/ ...very few phenomena can pull someone out of Deep Hack Mode, with two noted exceptions: being struck by lightning, or worse, your *computer* being struck by lightning. -- Matt Welsh ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: GtkComboBox - how to clear and repopulate in one step?
You may create the combo box using gtk_combo_box_new_with_model. You insert all the items that may appear in the second combo box in a GtkListStore. Along with the text, you create a column that contains the index of the items in the first combo box that they belong to. Use a GtkTreeModelFilter over the GtkListStore and define a visibility function that returns true for the rows whose index column value is equal with the selected index of the first combo box. Now, every time when the index in the first combo box changes, you just have to call gtk_tree_model_filter_refilter. Other solution is to use gtk_combo_box_new_with_model using a GtkListStore. When the selection in the first combo box changes, you call gtk_list_store_clear. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Get rid of deprecated widgets
On Wed, 2007-12-05 at 20:26 +0100, Soeren Sandmann wrote: Alexander Larsson [EMAIL PROTECTED] writes: A possibly interesting approach would be to put all the deprecated code in another ELF section and place that section at the end. This will mean that the deprecated stuff will be in one continous place and might make paging in non-deprecated code slightly more efficient and less seeky. I'm not sure you would be able to measure the difference this would make though... That particular optimization may not be very measurable, but having the ability to move arbitrary functions around would make it possible to put the most used functions together at the front of the library, based on a desktop-wide profile. This would very likely be measurable. Someone could try using -freorder-functions which does this, based on a profile. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: gio on win32 (was Re: Announce: gio merged)
On Wed, 2007-12-05 at 22:13 +0100, Hans Breuer wrote: On 05.12.2007 12:19, Alexander Larsson wrote: On Tue, 2007-12-04 at 00:15 +0100, Hans Breuer wrote: On 03.12.2007 10:07, Alexander Larsson wrote: Thats a way it can be made to work with the current use in libgio, but it makes the API sort of weird for win32. How exactly is the dynamic path calculated? Maybe its possible to make the API work in some relative way? That way some other library on could also use g_io_modules_ensure_loaded() to load its modules relative to its dll. The thing needed than would be the DLL name or the HANDLE of the DLL to resolve the relative path against. I'm not sure though how the responsibilities need to be split for loading some gio-modules. Is an application supposed to deliver it's own extension modules for gio? I changed this so that _g_io_modules_ensure_loaded is a private function that only glib uses for its libs. It takes no arguments and could use whatever magic require on win32 to find the module directory. Instead I exported g_io_modules_load_all_in_directory, which is used in the implementation of _g_io_modules_ensure_loaded. It can be used in other libraries (such as in gvfs) to implement a similar thing. Is this ok for you? Looks good. So I guess someone needs to write the first gio-module working on windoze - maybe around FindFirstChangeNotification() ;) I don't think that needs to be a module actually. I've made the fam file monitor a module, so that gio doesn't link to libfam. However, the inotify monitor is built in, as that has no extra dependencies. (Loading modules is not free, as it causes an extra private dirty page.) ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: [directfb-dev] GDK-DirectFB Patches
Hi Sven, I backed out the two hacks. Still if rgb16_default.patch is there, apps like swplay is getting some black screen while playing flash. gtk-demo is having problem in dropdown icon in the icon-view object in left hand side If this patch is not present, then flash is playing fine and gtk-demo doesnot have the above mentioned issue. Can some one tell why to use use RGB16 format by default. Thanks Regards Reny On Dec 6, 2007 1:20 PM, Sven Neumann [EMAIL PROTECTED] wrote: Hi, On Thu, 2007-12-06 at 13:15 +0530, RENY PAUL wrote: Thanks for the patch. I have applied all the patches including the hacks. Could you please back out the hacks again? Denis asked you explicitely not to apply them and if the hacks are causing problems in gtk-demo, as you said, then they should definitely not go in. Sven ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: SoupInputStream / trying out gio
On Dec 5, 2007 3:47 PM, Morten Welinder [EMAIL PROTECTED] wrote: Perhaps beside the point, but one wouldn't introduce this problem had one written #define stat(path, buf) stat64(path, buf) Not in the case of stat, certainly. struct stat needs to work. Oh, my. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: [directfb-dev] GDK-DirectFB Patches
Yesterday i noticed the very same issue Reny spotted (even without the HACK files). So my idea is committing the single gdkevens patch now and wait some more before applying the last set of patches proposed by dok, os that those issues can be adressed properly. Attilio RENY PAUL wrote: Hi Sven, I backed out the two hacks. Still if rgb16_default.patch is there, apps like swplay is getting some black screen while playing flash. gtk-demo is having problem in dropdown icon in the icon-view object in left hand side If this patch is not present, then flash is playing fine and gtk-demo doesnot have the above mentioned issue. Can some one tell why to use use RGB16 format by default. Thanks Regards Reny On Dec 6, 2007 1:20 PM, Sven Neumann [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Hi, On Thu, 2007-12-06 at 13:15 +0530, RENY PAUL wrote: Thanks for the patch. I have applied all the patches including the hacks. Could you please back out the hacks again? Denis asked you explicitely not to apply them and if the hacks are causing problems in gtk-demo, as you said, then they should definitely not go in. Sven ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: [directfb-dev] [directfb-users] Problems in GdkWindow Events with Gtk - DirectFb backend
Christopher Johnson wrote: Unless I am grossly mistaken, any other behavior will create a serious incompatibility between GTK+ backends. I am currently struggling with code that isn't getting events it expects (DirectFB 1.0.0 and GTK+ 2.10.13). Sounds like maybe Mike's explanation might cover my problems and incompatibilities with GTK/X. If you're not interested in raw X11 events, but only GdkEvents, your code should work with GDKDirectFB, otherwise it's a bug and needs to be fixed. -- Best regards, Denis Oliver Kropp .--. | DirectFB - Hardware accelerated graphics | | http://www.directfb.org/ | -- ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GDK-DirectFB Patches
Carl Worth wrote:
On Wed, 5 Dec 2007 12:15:38 -0800, Mike Emmel wrote:
I've not come up with a general
way to interleave a Cairo context
with directfb calls. So depending on how you do things you can get
unexpected results.
Above we were talking about performance, right? And here you are
talking about incorrect results, right? What's the cause of this? Is
it that cairo-directfb is just broken?
For interleaving cairo and non-cairo rendering, cairo provides the
cairo_surface_flush and cairo_surface_mark_dirty APIs. Does
cairo-directfb implement those and does your application use them.
Thanks for the pointer. The cairo-directfb backend seems to do nothing
in these functions. I'm not sure what it's supposed to do. Should the
first accumulate a region to flip and the second actually flips?
static cairo_status_t
_cairo_directfb_surface_mark_dirty_rectangle (void *abstract_surface,
int x,
int y,
int width,
int height)
{
#if 0
cairo_directfb_surface_t *surface = abstract_surface;
D_DEBUG_AT (Cairo_DirectFB,
%s( surface=%p, x=%d, y=%d, width=%d, height=%d ).\n,
__FUNCTION__, surface, x, y, width, height);
if( !surface-dirty_region )
surface-dirty_region = malloc(sizeof(DFBRegion));
if (!dirty_region)
return CAIRO_STATUS_NO_MEMORY;
#endif
return CAIRO_STATUS_SUCCESS;
}
static cairo_status_t
_cairo_directfb_surface_flush (void *abstract_surface)
{
#if 0
cairo_directfb_surface_t *surface = abstract_surface;
D_DEBUG_AT (Cairo_DirectFB,
%s( surface=%p ).\n, __FUNCTION__, surface);
if (surface-surface != surface-buffer) {
surface-surface-SetClip (surface-surface, NULL);
surface-surface-SetBlittingFlags (surface-surface, DSBLIT_NOFX);
surface-surface-Blit (surface-surface, surface-buffer, NULL, 0, 0);
}
#endif
return CAIRO_STATUS_SUCCESS;
}
No more -surface and -buffer exist, just -dfbsurface.
typedef struct _cairo_directfb_surface {
cairo_surface_t base;
cairo_format_t format;
IDirectFB *dfb;
int owner;
IDirectFBSurface*dfbsurface;
/* color buffer */
cairo_surface_t *color;
DFBRegion *clips;
int n_clips;
DFBRegion *dirty_region;
int width;
int height;
} cairo_directfb_surface_t;
BTW, with the recent state/clipping fixes to GDK-DirectFB, the rectangle
filling in cairo-directfb could be fixed, I did not check the BTS entries
to verify what was the problem with it.
--
Best regards,
Denis Oliver Kropp
.--.
| DirectFB - Hardware accelerated graphics |
| http://www.directfb.org/ |
--
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GDK-DirectFB Patches
Mike Emmel wrote: On Dec 5, 2007 10:40 AM, Carl Worth [EMAIL PROTECTED] wrote: On Wed, 5 Dec 2007 10:22:08 -0800, Mike Emmel wrote: And next we need to make sure that we are not breaking gdk. One approach may mean to pass in a features arg when initializing Cairo. It could be a simple bool accel or no acceleration. I'm not interested in anything like that at all. If it's not correct, then it's not acceleration---it's just broken. Well not quite. One of the problems is that DirectFB directly supports a lot of surface formats not supported by Cairo but it does not have the complex drawing api. When you dealing with incompatible surface formats and software fallbacks it tends to be better to just use the fallbacks instead of trying to interleave accelerated direct calls and redirected software fallbacks. I've not come up with a general way to interleave a Cairo context with directfb calls. So depending on how you do things you can get unexpected results. I'm seeing _cairo_directfb_surface_acquire_dest_image() and _cairo_directfb_surface_release_dest_image() which probably get called before and after cairo's software fallbacks. These call Lock() and Unlock() so DirectFB has a chance to synchronize with the accelerator. I don't see a problem with interleaved cairo/directfb drawing, but maybe you're talking about something different. -- Best regards, Denis Oliver Kropp .--. | DirectFB - Hardware accelerated graphics | | http://www.directfb.org/ | -- ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GDK-DirectFB Patches
RENY PAUL wrote: Hi, This patch sove the bug 476823( http://bugzilla.gnome.org/show_bug.cgi?id=476823) Interesting, the patch causes DirectFB to be used instead of Cairo even if DirectFB can't accelerate the font rendering. Are you sure it's just this single change that fixes the bug? -#if DFB_SHOW_GLYPHS +#if DFB_SHOW_GLYPHS 0 if (!(dsc.acceleration_mask DFXL_BLIT)|| !(dsc.blitting_flags DSBLIT_COLORIZE) || !(dsc.blitting_flags DSBLIT_BLEND_ALPHACHANNEL)) -- Best regards, Denis Oliver Kropp .--. | DirectFB - Hardware accelerated graphics | | http://www.directfb.org/ | -- ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GDK-DirectFB Patches
Carl Worth wrote: On Wed, 05 Dec 2007 11:09:33 +0100, Denis Oliver Kropp wrote: CAIRO-DIRECTFB: Use DirectFB for show_glyphs() even if it is unaccelerated. The software fallback in DirectFB is well optimized. Hi Denis, I'm inclined to let anyone who wants to maintain cairo-directfb-surface.c do whatever they feel is best to it. But could you please send proposed patches to the cairo mailing list? There are probably cairo-directfb maintainers there that will want to review this. -#if DFB_SHOW_GLYPHS +#if DFB_SHOW_GLYPHS 0 if (!(dsc.acceleration_mask DFXL_BLIT)|| !(dsc.blitting_flags DSBLIT_COLORIZE) || !(dsc.blitting_flags DSBLIT_BLEND_ALPHACHANNEL)) Why leave this code around? If it's truly not wanted, it would be cleaner to remove it. Yes, usually I'm against commented out or disabled code being checked in, except for active construction sites. Feel free to remove it :) -- Best regards, Denis Oliver Kropp .--. | DirectFB - Hardware accelerated graphics | | http://www.directfb.org/ | -- ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: [directfb-dev] GDK-DirectFB Patches
RENY PAUL wrote: Hi Sven, I backed out the two hacks. Still if rgb16_default.patch is there, apps like swplay is getting some black screen while playing flash. gtk-demo is having problem in dropdown icon in the icon-view object in left hand side If this patch is not present, then flash is playing fine and gtk-demo doesnot have the above mentioned issue. Can some one tell why to use use RGB16 format by default. I've been optimizing GDK-DirectFB on an RGB16 display and found that some surfaces were still created as ARGB while they could have been RGB16. Moving RGB16 to the top of supported formats solved the issue without impact. I did not investigate further what it could mean for ARGB displays, probably should have marked that patch as a hack, too. Can someone explain the visual selection or why at all it makes a difference what is at the top? Does it just pick the first, assuming the first is the ultimatively compatible one? -- Best regards, Denis Oliver Kropp .--. | DirectFB - Hardware accelerated graphics | | http://www.directfb.org/ | -- ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: [directfb-dev] linux-fusion lock problem
Victor Liu wrote:
Hi,
while I am using DirectFB with fusion, some time the application was locked.
we debugged into, find lock is in fusion. I looked the code, found a place
seems missed unlock (see red line or comment). if any one knows linux-fusion,
please make sure. both 3.x or 7.x have same code.
Thanks,
Victor Liu
int
fusion_skirmish_prevail (FusionDev *dev, int id, int fusion_id)
{
int ret;
FusionSkirmish *skirmish;
#ifdef FUSION_DEBUG_SKIRMISH_DEADLOCK
FusionSkirmish *s;
int i;
bool outer = true;
#endif
dev-stat.skirmish_prevail_swoop++;
ret = fusion_skirmish_lock( dev-skirmish, id, true, skirmish );
if (ret)
return ret;
..
up( dev-skirmish.lock );
while (skirmish-lock_pid) {
ret = fusion_skirmish_wait( skirmish, NULL );
if (ret)
{
fusion_skirmish_unlock( skirmish ); // original code does not have
this line
IIRC, a non-zero return value (error) means the lock is not reacquired.
Only if the call was successful, the code needs to unlock it.
But I'm checking the code now (fusion_entry_wait).
--
Best regards,
Denis Oliver Kropp
.--.
| DirectFB - Hardware accelerated graphics |
| http://www.directfb.org/ |
--
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Static compose table in gtkimcontextsimple.c
On Thu, 2007-12-06 at 12:28 +, Paul LeoNerd Evans wrote: On Tue, 04 Dec 2007 05:38:56 + Simos Xenitellis [EMAIL PROTECTED] wrote: If you would like to help with bug 321896 it would be great. The current state is on how to make the table much smaller, even with the addition of more keysyms. There is a script that converts en_US.UTF-8/Compose into a series of arrays that should be easy for GTK+ to work on. OK, I've had a good read through that bug, and now I'm confused again. Can someone explain why GTK has to have this large table compiled into it..? I thought X itself provided ways to perform input composition into Unicode strings. Otherwise, why do I have a file /usr/share/X11/locale/en_US.UTF-8/Compose Can we just use that? There are issues on GTK+ running on other platforms that require to have a separate copy. Having the file contents in the library as static data is good for performance and memory use. I just compiled Tor's working patch which actually eliminates most of the compose sequences and it is amazing in the way it simplifies the work. I think it is the way to go once the small issues are resolved. Simos ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Static compose table in gtkimcontextsimple.c
On Dec 6, 2007 8:22 AM, Simos Xenitellis [EMAIL PROTECTED] wrote: I just compiled Tor's working patch which actually eliminates most of the compose sequences and it is amazing in the way it simplifies the work. I think it is the way to go once the small issues are resolved. Thanks for staying on this issue for so long, SImos. It will be good to have this finally resolved. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Static compose table in gtkimcontextsimple.c
On Tue, 4 Dec 2007 08:31:30 +0200 Tor Lillqvist [EMAIL PROTECTED] wrote: The sequences you list are exactly of the straightforward kind that in my opinion can and should be handled algorithmically. I.e. a dead accent followed by a letter can be mapped to the corresponding precomposed character without an explicit table. Really..? Last time I checked, the precomposed letters weren't in any particularly easy-to-find locations; I looked them up by typing them in xterm and seeing what unicode sequences were generated. I have a patch in bug #321896 that implements such an algorithm (and which would handle your cases, too.) Basically it's waiting for a second opinion from the GTK+ maintainers. Perhaps we could subtly poke them here then to remind them? :) -- Paul LeoNerd Evans [EMAIL PROTECTED] ICQ# 4135350 | Registered Linux# 179460 http://www.leonerd.org.uk/ signature.asc Description: PGP signature ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Static compose table in gtkimcontextsimple.c
On Tue, 04 Dec 2007 05:38:56 + Simos Xenitellis [EMAIL PROTECTED] wrote: If you would like to help with bug 321896 it would be great. The current state is on how to make the table much smaller, even with the addition of more keysyms. There is a script that converts en_US.UTF-8/Compose into a series of arrays that should be easy for GTK+ to work on. OK, I've had a good read through that bug, and now I'm confused again. Can someone explain why GTK has to have this large table compiled into it..? I thought X itself provided ways to perform input composition into Unicode strings. Otherwise, why do I have a file /usr/share/X11/locale/en_US.UTF-8/Compose Can we just use that? -- Paul LeoNerd Evans [EMAIL PROTECTED] ICQ# 4135350 | Registered Linux# 179460 http://www.leonerd.org.uk/ signature.asc Description: PGP signature ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: [directfb-dev] GDK-DirectFB Patches
Attilio Fiandrotti wrote: Yesterday i noticed the very same issue Reny spotted (even without the HACK files). So my idea is committing the single gdkevens patch now and wait some more before applying the last set of patches proposed by dok, os that those issues can be adressed properly. Do problems exist if you leave out the hacks and the rgb16 patch? -- Best regards, Denis Oliver Kropp .--. | DirectFB - Hardware accelerated graphics | | http://www.directfb.org/ | -- ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
OSX Target (was: GDK-DirectFB Patches)
Sven Neumann wrote: Hi, On Thu, 2007-12-06 at 13:15 +0530, RENY PAUL wrote: Thanks for the patch. I have applied all the patches including the hacks. Could you please back out the hacks again? Denis asked you explicitely not to apply them and if the hacks are causing problems in gtk-demo, as you said, then they should definitely not go in. Is the gtk-demo working on OSX? While optimizing/fixing the backend I came across the OSX backend code and saw that it doesn't do all those things that I wouldn't like to do as well. It does not seem to clip out children when filling rectangles or drawing. It does not recurse during invalidation. As DirectFB is much more like OSX than X11 I was wondering if the OSX backend would be working in that lightweight fashion. The overhead in the DirectFB backend could be further reduced if we follow the OSX backend, unless it's not working or the intensive tasks are just done elsewhere. In that backend the ...clear_area(_e) calls are unimplemented, for example. -- Best regards, Denis Oliver Kropp .--. | DirectFB - Hardware accelerated graphics | | http://www.directfb.org/ | -- ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GDK-DirectFB Patches
Mike Emmel wrote: On Dec 5, 2007 1:17 PM, Carl Worth [EMAIL PROTECTED] wrote: On Wed, 5 Dec 2007 12:15:38 -0800, Mike Emmel wrote: Well not quite. One of the problems is that DirectFB directly supports a lot of surface formats not supported by Cairo but it does not have the complex drawing api. So that sounds like justification for adding more surface formats to cairo. Do you have a short list of interesting formats? DirectFB has a lng list of supported formats :) Probably some of the YUV are the most interesting ones in this context. I'd rather not see Cairo polluted with a zillion formats just we might want to handle format mismatches better. I actually like the idea of Cairo working with a small number of formats and the conversion issue solved elsewhere. RGB16'd be enough, according to me. -- Regards, Claudio Ciccani [EMAIL PROTECTED] http://directfb.org http://sf.net/projects/php-directfb ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
File plugin with c++
Hi! Is it possible to write a file plugin like gdk-pixbuf/io-jpeg.c in c++? The problem is openexr expects a char* for it's constructor and gdk works with FILE. Thanks, g ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: File plugin with c++
Hi, Is it possible to write a file plugin like gdk-pixbuf/io-jpeg.c in c++? Yes. The problem is openexr expects a char* for it's constructor and gdk works with FILE. That doesn't have anything to do with C++ AFAICT. The GdkPixbufLoader also has a push API, where a stream of bytes is sent to the loader. The SVG loader uses this API instead of the file-based one. Eg. http://svn.gnome.org/viewvc/librsvg/trunk/gdk-pixbuf-loader/io-svg.c?revision=1136view=markup If openexr doesn't have a way to load an image from a stream of bytes, you could always serialize the bytes to a temporary file and then load that. Dom ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Get rid of deprecated widgets
Hi, Xavier Bestel schrieb: On mer, 2007-12-05 at 14:09 +0100, Alexander Larsson wrote: The only way to make this backwards compatible is to make libgtk-2.0.so.0 have the deprecated symbols and link to libgtk-no-compat-2.0.so.0 which doesn't. Then normal apps will keep working, and apps that don't need compat widgets will need to link with -lgtk-no-compat-2.0. Each new releases may deprecate some symbols. So what's needed is a symbolic library name per release, and say when you release gtk+2.14, make libgtk-2.0.so ... libgtk-2.12.so all point to the same thing (with all deprecated symbols) which then links to libgtk-2.14.so with only supported symbols. Removing the deprecated stuff is in most cases not an option. But lowering the impact is. WHat kind of impact have they? 1) longer symbol resolving on startup 2) memory usage 3) locatisation 4) ??? 2) can be addressed like i described in http://bugzilla.gnome.org/show_bug.cgi?id=471123 Now it would be great if we could also tell the linker to resolve deprecated entries lazily. That would help with 1). For 3) one could maybe redef _(). Needs to be tried. Stefan ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Static compose table in gtkimcontextsimple.c
On Thu, 2007-12-06 at 12:28 +, Paul LeoNerd Evans wrote: On Tue, 04 Dec 2007 05:38:56 + Simos Xenitellis [EMAIL PROTECTED] wrote: If you would like to help with bug 321896 it would be great. The current state is on how to make the table much smaller, even with the addition of more keysyms. There is a script that converts en_US.UTF-8/Compose into a series of arrays that should be easy for GTK+ to work on. OK, I've had a good read through that bug, and now I'm confused again. Can someone explain why GTK has to have this large table compiled into it..? I thought X itself provided ways to perform input composition into Unicode strings. Otherwise, why do I have a file /usr/share/X11/locale/en_US.UTF-8/Compose Can we just use that? Note also that loading /usr/share/X11/locale/en_US.UTF-8/Compose causes a large amount of per-process memory to be allocated, and quite a bit of time spent parsing it. While the GTK+ table is large, it is mapped read-only so shared between all GTK+ applications. (*) (**) I don't have any exact or recent numbers here; the Compose table was a significant fraction of the per-process overhead when I measured it before writing gtkimcontextsimple.c, and current UTF-8 table is much bigger than anything I measured. On the other hand, it's possible that optimization has been done within Xlib in the subsequent 5-6 years. The original motivations in order of priority: 1. Reliable compose sequences in non-UTF-8 locales 2. Efficiency 3. Cross-platform portability 1. is luckily no longer an issue, but the two still apply. - Owen (*) The Xlib problem could obviously be fixed by precompiling and mem-mapping the Compose tables, as we do for similiar things (**) The one thing to be careful about when modifying gtkimcontextsimple.c is not to save size by introducing relocations. Arrays that include pointers to other arrays cannot be mapped read-only. Other than that, go for it! signature.asc Description: This is a digitally signed message part ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Static compose table in gtkimcontextsimple.c
On Thu, 06 Dec 2007 12:12:39 -0500 Owen Taylor [EMAIL PROTECTED] wrote: Note also that loading /usr/share/X11/locale/en_US.UTF-8/Compose That's not quite what I meant. What I meant was, I thought that the X11 server did some of this work for us? So can we not ask it to do that? Or have I misunderstood how it works, and that this is really a clientside thing done by Xlib? -- Paul LeoNerd Evans [EMAIL PROTECTED] ICQ# 4135350 | Registered Linux# 179460 http://www.leonerd.org.uk/ signature.asc Description: PGP signature ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Static compose table in gtkimcontextsimple.c
On Thu, 2007-12-06 at 17:30 +, Paul LeoNerd Evans wrote: On Thu, 06 Dec 2007 12:12:39 -0500 Owen Taylor [EMAIL PROTECTED] wrote: Note also that loading /usr/share/X11/locale/en_US.UTF-8/Compose That's not quite what I meant. What I meant was, I thought that the X11 server did some of this work for us? So can we not ask it to do that? Or have I misunderstood how it works, and that this is really a clientside thing done by Xlib? The latter. - Owen signature.asc Description: This is a digitally signed message part ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GDK-DirectFB Patches
On Thu, 06 Dec 2007 09:44:55 +0100, Denis Oliver Kropp wrote: Carl Worth wrote: For interleaving cairo and non-cairo rendering, cairo provides the cairo_surface_flush and cairo_surface_mark_dirty APIs. Does cairo-directfb implement those and does your application use them. Thanks for the pointer. The cairo-directfb backend seems to do nothing in these functions. I'm not sure what it's supposed to do. Should the first accumulate a region to flip and the second actually flips? I don't know how cairo-directfb surface is implemented exactly. So I'll describe the general concepts and then illustrate them by way of a fictitious shadow backend that is implemented with a cairo-image-surface internally and can copy back and forth between that and some underlying system object. When an application wants to switch from cairo- to non-cairo-based drawing it should call cairo_surface_flush. In this case, our shadow backend would copy its state from the image surface to the underlying system. (Ideally it would copy a minimal region based on the extents of cairo drawing operations that have occurred, but cairo's current backend interfaces don't make it easy to know this. But there would be no API impact from improving that.) Then, when an application wants to switch back from non-cairo- to cairo-based drawing it should call cairo_surface_mark_dirty_rectangle one or more times. Our shadow backend would accumulate a region from these rectangles and before the next cairo drawing operation would copy that region from the system to the image surface. Does that make sense? -Carl pgpEcrygSGOra.pgp Description: PGP signature ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: [directfb-dev] GDK-DirectFB Patches
Denis Oliver Kropp wrote: Attilio Fiandrotti wrote: Yesterday i noticed the very same issue Reny spotted (even without the HACK files). So my idea is committing the single gdkevens patch now and wait some more before applying the last set of patches proposed by dok, os that those issues can be adressed properly. Do problems exist if you leave out the hacks and the rgb16 patch? If i leave out the rgb16 patch, the problem disappears and everything works fine as before. I just committed your previous patch for gdk events in trunk and gtk-2-10, only to discover it causes a crash on toplevel window closing (META + C), i'll try to fix it. Attilio ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: [directfb-dev] GDK-DirectFB Patches
Attilio Fiandrotti wrote: Denis Oliver Kropp wrote: Attilio Fiandrotti wrote: Yesterday i noticed the very same issue Reny spotted (even without the HACK files). So my idea is committing the single gdkevens patch now and wait some more before applying the last set of patches proposed by dok, os that those issues can be adressed properly. Do problems exist if you leave out the hacks and the rgb16 patch? If i leave out the rgb16 patch, the problem disappears and everything works fine as before. I just committed your previous patch for gdk events in trunk and gtk-2-10, only to discover it causes a crash on toplevel window closing (META + C), i'll try to fix it. I just verified that the GdkDirectFB patch alone doesn't cause the bug, so its recent commit was ok. The bug i ran into (try closing the icon view basic window in gtk-demo, trace attached) was istead caused by window_flip_group.patch and is triggered only when NO_EXPERIMENTS is *not* defined, otherwise the patch is ok. I'll do more testing tomorrows. Attilio Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0xb75b76b0 (LWP 29606)] 0xb7f57dfd in IA__gdk_window_get_toplevel (window=0x837c0e0) at gdkwindow.c:617 617 while (GDK_WINDOW_TYPE (obj) == GDK_WINDOW_CHILD) (gdb) bt #0 0xb7f57dfd in IA__gdk_window_get_toplevel (window=0x837c0e0) at gdkwindow.c:617 #1 0xb7f6f41c in gdk_window_directfb_process_all_updates () at gdkwindow-directfb.c:105 #2 0xb7f6f4d7 in gdk_window_update_idle (data=0x0) at gdkwindow-directfb.c:134 #3 0xb7f39b4f in gdk_threads_dispatch (data=0x838e760) at gdk.c:470 #4 0xb78d7661 in ?? () from /usr/lib/libglib-2.0.so.0 ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Static compose table in gtkimcontextsimple.c
I wrote: a dead accent followed by a letter can be mapped to the corresponding precomposed character without an explicit table. On 06/12/2007, Paul LeoNerd Evans [EMAIL PROTECTED] wrote: Really..? Last time I checked, the precomposed letters weren't in any particularly easy-to-find locations; Well, obviously there has to be some tables somewhere (in GLib's case I guess it's in the generated header files like gunicomp.h), but I meant, the information shouldn't have to be effectively duplicated in gtk. --tml ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Get rid of deprecated widgets
On Wed, 2007-05-12 at 12:17 +0100, Mikael Hermansson wrote: Hello! Some thoughts For years now there has been widgets that is deprecated in Gtk+ GtkList GtkCList GtkFileSel GtkCTree GtkItemFactory Pidgin still uses GtkItemFactory. Gabriel ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GDK-DirectFB Patches
Carl Worth wrote: On Thu, 06 Dec 2007 09:44:55 +0100, Denis Oliver Kropp wrote: Carl Worth wrote: For interleaving cairo and non-cairo rendering, cairo provides the cairo_surface_flush and cairo_surface_mark_dirty APIs. Does cairo-directfb implement those and does your application use them. Thanks for the pointer. The cairo-directfb backend seems to do nothing in these functions. I'm not sure what it's supposed to do. Should the first accumulate a region to flip and the second actually flips? I don't know how cairo-directfb surface is implemented exactly. So I'll describe the general concepts and then illustrate them by way of a fictitious shadow backend that is implemented with a cairo-image-surface internally and can copy back and forth between that and some underlying system object. When an application wants to switch from cairo- to non-cairo-based drawing it should call cairo_surface_flush. In this case, our shadow backend would copy its state from the image surface to the underlying system. (Ideally it would copy a minimal region based on the extents of cairo drawing operations that have occurred, but cairo's current backend interfaces don't make it easy to know this. But there would be no API impact from improving that.) Then, when an application wants to switch back from non-cairo- to cairo-based drawing it should call cairo_surface_mark_dirty_rectangle one or more times. Our shadow backend would accumulate a region from these rectangles and before the next cairo drawing operation would copy that region from the system to the image surface. Does that make sense? Yes. Thanks for your explanation. The cairo-directfb surface uses the system object directly, which is an IDirectFBSurface. For each source/dest acquire it does a Lock() to get the surface data pointer and pitch and calls cairo_image_surface_create_for_data() which is not too heavy for every acquire I hope. So flushing and marking is not required. -- Best regards, Denis Oliver Kropp .--. | DirectFB - Hardware accelerated graphics | | http://www.directfb.org/ | -- ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GDK-DirectFB Patches
Denis Oliver Kropp wrote: Carl Worth wrote: On Thu, 06 Dec 2007 09:44:55 +0100, Denis Oliver Kropp wrote: Carl Worth wrote: For interleaving cairo and non-cairo rendering, cairo provides the cairo_surface_flush and cairo_surface_mark_dirty APIs. Does cairo-directfb implement those and does your application use them. Thanks for the pointer. The cairo-directfb backend seems to do nothing in these functions. I'm not sure what it's supposed to do. Should the first accumulate a region to flip and the second actually flips? I don't know how cairo-directfb surface is implemented exactly. So I'll describe the general concepts and then illustrate them by way of a fictitious shadow backend that is implemented with a cairo-image-surface internally and can copy back and forth between that and some underlying system object. When an application wants to switch from cairo- to non-cairo-based drawing it should call cairo_surface_flush. In this case, our shadow backend would copy its state from the image surface to the underlying system. (Ideally it would copy a minimal region based on the extents of cairo drawing operations that have occurred, but cairo's current backend interfaces don't make it easy to know this. But there would be no API impact from improving that.) Then, when an application wants to switch back from non-cairo- to cairo-based drawing it should call cairo_surface_mark_dirty_rectangle one or more times. Our shadow backend would accumulate a region from these rectangles and before the next cairo drawing operation would copy that region from the system to the image surface. Does that make sense? Yes. Thanks for your explanation. The cairo-directfb surface uses the system object directly, which is an IDirectFBSurface. For each source/dest acquire it does a Lock() to get the surface data pointer and pitch and calls cairo_image_surface_create_for_data() which is not too heavy for every acquire I hope. So flushing and marking is not required. I'd also like to see that revived: * @CAIRO_FORMAT_RGB16_565: This format value is deprecated. It has * never been properly implemented in cairo and should not be used * by applications. (since 1.2) Embedded devices running at 16bit should be able to use Cairo without converting back and forth. -- Best regards, Denis Oliver Kropp .--. | DirectFB - Hardware accelerated graphics | | http://www.directfb.org/ | -- ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Get rid of deprecated widgets
On Dec 6, 2007 3:04 PM, Stefan Kost [EMAIL PROTECTED] wrote: Hi, Xavier Bestel schrieb: On mer, 2007-12-05 at 14:09 +0100, Alexander Larsson wrote: The only way to make this backwards compatible is to make libgtk-2.0.so.0 have the deprecated symbols and link to libgtk-no-compat-2.0.so.0 which doesn't. Then normal apps will keep working, and apps that don't need compat widgets will need to link with -lgtk-no-compat-2.0. Each new releases may deprecate some symbols. So what's needed is a symbolic library name per release, and say when you release gtk+2.14, make libgtk-2.0.so ... libgtk-2.12.so all point to the same thing (with all deprecated symbols) which then links to libgtk-2.14.so with only supported symbols. Removing the deprecated stuff is in most cases not an option. But lowering the impact is. WHat kind of impact have they? I've been watching this topic for a while, and it comes back up every so often, I would actually say something quite to the contrary: Lowering the impact of deprecated widgets and code paths is probably not ever worth the effort (I dont believe the impact is that great, especially if you are not pulling in libgnomeui and friends). OTOH the (quite valid) option of breaking the api could be alot more useful, who cares about the short term gains - a thorough code cleanup and refactoring of gtk+ cannot be done without breaking the api, how can we work on new features/functionality and even code optimization before breaking the api and refactoring ? Cheers, -Tristan ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GDK-DirectFB Patches
On Thu, 06 Dec 2007 21:52:08 +0100, Denis Oliver Kropp wrote: I'd also like to see that revived: * @CAIRO_FORMAT_RGB16_565: This format value is deprecated. It has * never been properly implemented in cairo and should not be used * by applications. (since 1.2) Embedded devices running at 16bit should be able to use Cairo without converting back and forth. This is on the todo list for the current cairo development working toward a 1.6 release. Any help would definitely be appreciated. -Carl pgpcX8QHWamDV.pgp Description: PGP signature ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GDK-DirectFB Patches
On Dec 6, 2007 9:56 AM, Carl Worth [EMAIL PROTECTED] wrote: On Thu, 06 Dec 2007 09:44:55 +0100, Denis Oliver Kropp wrote: Carl Worth wrote: For interleaving cairo and non-cairo rendering, cairo provides the cairo_surface_flush and cairo_surface_mark_dirty APIs. Does cairo-directfb implement those and does your application use them. Thanks for the pointer. The cairo-directfb backend seems to do nothing in these functions. I'm not sure what it's supposed to do. Should the first accumulate a region to flip and the second actually flips? I don't know how cairo-directfb surface is implemented exactly. So I'll describe the general concepts and then illustrate them by way of a fictitious shadow backend that is implemented with a cairo-image-surface internally and can copy back and forth between that and some underlying system object. When an application wants to switch from cairo- to non-cairo-based drawing it should call cairo_surface_flush. In this case, our shadow backend would copy its state from the image surface to the underlying system. (Ideally it would copy a minimal region based on the extents of cairo drawing operations that have occurred, but cairo's current backend interfaces don't make it easy to know this. But there would be no API impact from improving that.) Then, when an application wants to switch back from non-cairo- to cairo-based drawing it should call cairo_surface_mark_dirty_rectangle one or more times. Our shadow backend would accumulate a region from these rectangles and before the next cairo drawing operation would copy that region from the system to the image surface. Does that make sense? -Carl Yes Carl this support was added after I stopped actively working on the Cairo DFB backend. When we have a format mismatch then a shadow may be the right answer. Note for directfb you can ask for a different buffer format i.e ARGB for a window. But we probably still want to use dirty regions for flipping. I don't think your getting all of the emails on the topic but it finally looks like a lot of people are looking at the problem. So for now lets see how this resolves. I know I pulled my hair out on it for a while :) ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: [directfb-dev] [directfb-users] Problems in GdkWindow Events with Gtk - DirectFb backend
On Dec 6, 2007 12:19 PM, Christopher Johnson [EMAIL PROTECTED] wrote: Mike, even your flames are welcome. I know Mike personally and have worked with him in the past, and have nothing but the highest respect. So here's my semi-flame in return. I've been working with GTK+ and DirectFB for only a few months now, and I only have the limited and poorly maintained information on the web from which to draw my conclusions. I ask you to interpret this statement from the Wiki: This wiki page is an howto about building GTK+ http://www.gtk.org (/http://www.gtk.org/) libraries with DirectFrameBuffer backend enabled, which permits running a generic GTK+ application directly on top of DFB instead of X11. The DFB backend is meant for embedded use so hasn't all the features the X11 backend has but it's complete and stable enough to run even complex applications like the GIMP. I don't see anything here at all like your statement (although I believe your statements). In fact, just the opposite. I'm led to believe that programs, even complicated ones like gimp, can be moved from GTK/X to GTK/DFB. Of course, it all depends on the meaning of generic and permits. Even though I'm porting some VERY complicated GTK/X programs to dfb, many of the most generic examples are not permitted to run (and actually work). I'm not talking so much about moving programs over. It more akin to the java world problem of MIDP vs J2SE. In the embedded world you need a very modular system. This includes the toolkit and the applications. Large toolkits with rich api's and large apps end written on them end up tightly intertwined. A more realistic example would be to bring some of the rich editing capability in gimp to a embedded device that has a camera. Open source does not help in this situation a whole lot. Its a design failure. Also on the side of the gimp developers why should they refactor their cool app so bits and pieces can be reused ? For the entire development community a SDK that works from the embedded devices up would be useful. But opensource by itself cannot get this sort of initiative to work. This holds for pretty much any large complex code base. In my opinion its why COM/CORBA/XPCOM etc are failures. Without modular code component frameworks fail since component frameworks fail no one writes modular code. Certainly we have exceptions the Linux kernel is a example of a code base thats moved to be fairly nicely modularized over time. But its a exception not the rule. GCC is trundling slowly down this path also. What is there out there to warn me that this windowing system doesn't fit the assumptions made by gdk? Thus far, I've seen none, other than your response. Worst of all is when management-types see the misinformation out there and come up with project schedules allowing for a few days to migrate a GTK program to DirectFB... Its more of a internal issue. I had to do some horrid hacks to get everything to work. Gdk closely replicates the X11 api and for X11 at least its a fairly thin wrapper around xlib. To write applications you don't need this rich api. My current work has a gdk like layer that replaces X11,glib,gdk,pango etc and it runs about 200k and is capable of running WebKit and supporting a rootless X11 server. I'm not saying its in anyway equal to the rich frameworks but I am saying that a basic framework to run apps is certianly less than 1 meg. We don't have this sort of simple base to build on. Everything on top of this could be a module. With all due respect, Mike - I think virtually all of the first-time gtk/x to gtk/dfb porters out there are going to think the same thing I did. Perhaps your comment should be added at the front of the wiki in flaming orange. I don't know about that :) I guess I just got fed up with the way things work. And just to explain a bit I worked for SavaJE and ported Swing to run on a mobile phone. That experience helped me realize that the way we build a lot of our software now has caused us to get stuck in a rut of ever bloating frameworks and apps. GTK offered nothing new nor does QT etc etc. I just reached the point that I was done with this style of programming its endless cycle and leads nowhere. Most of our apps today are not much better than the ones from the 1980's. Sure they are prettier and hardware improvements have allowed expansion but we are not really going anywhere with human computer interaction its the same model that Xerox used. We have failed to get intrinsically better. I'm not saying I have the answer but I do feel that until we move to modular software we don't have a chance to get better. The answer is in my opinion requires the ability to really be able to synthesis software from modular components. Declarative programming is also part of the solution. The key is that a programmers intent needs to be preserved in the software. Maybe you could call it Desire programming which is a step above Declarative. We
Re: Get rid of deprecated widgets
On Thu, 2007-12-06 at 19:04 +0200, Stefan Kost wrote: Hi, Xavier Bestel schrieb: On mer, 2007-12-05 at 14:09 +0100, Alexander Larsson wrote: The only way to make this backwards compatible is to make libgtk-2.0.so.0 have the deprecated symbols and link to libgtk-no-compat-2.0.so.0 which doesn't. Then normal apps will keep working, and apps that don't need compat widgets will need to link with -lgtk-no-compat-2.0. Each new releases may deprecate some symbols. So what's needed is a symbolic library name per release, and say when you release gtk+2.14, make libgtk-2.0.so ... libgtk-2.12.so all point to the same thing (with all deprecated symbols) which then links to libgtk-2.14.so with only supported symbols. Removing the deprecated stuff is in most cases not an option. But lowering the impact is. WHat kind of impact have they? 1) longer symbol resolving on startup This is unlikely to be affected. There is one hash lookup per shared object in the global namespace on each symbol resolve. The number of symbols in a shared object should not affect things much, as the hash table is just made larger. 2) memory usage If its not used, should be little. It does affect paging behaviour of the other code though, so some code/data rearrangement would probably help a bit. 3) locatisation All of this stuff is old, doesn't change and is already translated, so I don't think its a huge problem. 2) can be addressed like i described in http://bugzilla.gnome.org/show_bug.cgi?id=471123 I added a comment to this, because I don't think the method described will work as well as it can. Now it would be great if we could also tell the linker to resolve deprecated entries lazily. That would help with 1). ELF symbols are always lazily resolved. Unless LD_BIND_NOW is defined (on linux/gnu). One can further reduce the costs of symbol lookups with prelink. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
