Re: [n00b] what's a smooth_draw_box?
Daniel Fetchinson wrote: Hi list, I've just started with GTK and been going through the tutorial and examples. My first small application is working all right but the following (I guess) warning keeps being written to the console: CRITICAL **: smooth_draw_box: assertion `width = -1' and strangely enough Google doesn't return any pages for the queries http://www.google.com/search?q=smooth_draw_box+site%3Agtk.org http://www.google.com/search?q=smooth_draw_box+site%3Alibrary.gnome.org Try dropping the 'site:gtk.org' part, you'll get lots of hits. tom ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
posting rules regarding text format
I have not been able to post a message today. I tried three times. The message concerned a website. The email was sent as text but contained a hyperlink I guess that's not good. I also tried after removing the _W_W_W but my message did not post. I visited the gtk site to review the rules but did not see something applicable Could someone tell me some other reasons why I would be blocked. Thanks in advance-patrick ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Multi-threaded UI Freezes on GDK Call
I've got a multithreaded GTK application. One thread runs gtk_main(): gtk_threads_enter(); gtk_main(); gtk_threads_leave(); The other thread is an infinite loop that sleeps for one second on each loop. Every x seconds, the infinite loop calls a function, which makes some GDK calls. At the beginning of this function, gdk_threads_enter() is called; at the end, gdk_flush() and gdk_threads_leave() is called. Whenever this function is called, the UI freezes and CPU usage jumps to 100% for about one second (no other applications freeze, of course). I've tried calling gdk_threads_leave()/enter() before and after each GDK call to no avail. I run g_thread_init() and gdk_threads_init() at the beginning of my program. In the function, gdk_screen_get_default(), gdk_screen_get_root_window(), gdk_pixbuf_get_from_drawable(), and gdk_pixbuf_save_to_bufferv() are called. I'm using NetBSD on a P4 1.2GHz. What am I doing wrong? I've asked this question on IRC (irc.gnome.org, #gtk+) but noone seems to know the problem. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Multi-threaded UI Freezes on GDK Call
On Tue, Dec 18, 2007 at 04:45:50PM -0500, Michael McCann wrote: I've got a multithreaded GTK application. One thread runs gtk_main(): gtk_threads_enter(); gtk_main(); gtk_threads_leave(); The other thread is an infinite loop that sleeps for one second on each loop. Every x seconds, the infinite loop calls a function, which makes some GDK calls. At the beginning of this function, gdk_threads_enter() is called; at the end, gdk_flush() and gdk_threads_leave() is called. Whenever this function is called, the UI freezes and CPU usage jumps to 100% for about one second (no other applications freeze, of course). I've tried calling gdk_threads_leave()/enter() before and after each GDK call to no avail. I run g_thread_init() and gdk_threads_init() at the beginning of my program. In the function, gdk_screen_get_default(), gdk_screen_get_root_window(), gdk_pixbuf_get_from_drawable(), and gdk_pixbuf_save_to_bufferv() are called. I'm using NetBSD on a P4 1.2GHz. What am I doing wrong? I've asked this question on IRC (irc.gnome.org, #gtk+) but noone seems to know the problem. The wrong thing is trying to do threads! Why Why Why are all people doing this thread programing! I am convinced that with a propper design of your application, maybe in several processe, you don't need threads and your problem will go away... ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list -- Göran Hasse Göran Hasseemail: [EMAIL PROTECTED] Tel: 08-6949270 Raditex AB http://www.raditex.se Planiavägen 15, 1tr Mob: 070-5530148 131 34 NACKA, SWEDEN OrgNr: 556240-0589 VAT: SE556240058901 -- ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Multi-threaded UI Freezes on GDK Call
On Tue, 2007-12-18 at 16:45 -0500, Michael McCann wrote: I've got a multithreaded GTK application. One thread runs gtk_main(): gtk_threads_enter(); gtk_main(); gtk_threads_leave(); I assume you meant g_threads_init(); gdk_threads_init(); gtk_init(); gdk_threads_enter(); gtk_main(); gdk_threads_leave(); right? The other thread is an infinite loop that sleeps for one second on each loop. Every x seconds, the infinite loop calls a function, which makes some GDK calls. At the beginning of this function, gdk_threads_enter() is called; at the end, gdk_flush() and gdk_threads_leave() is called. Whenever this function is called, the UI freezes and CPU usage jumps to 100% for about one second (no other applications freeze, of course). I've tried calling gdk_threads_leave()/enter() before and after each GDK call to no avail. I run g_thread_init() and gdk_threads_init() at the beginning of my program. In the function, gdk_screen_get_default(), gdk_screen_get_root_window(), gdk_pixbuf_get_from_drawable(), and gdk_pixbuf_save_to_bufferv() are called. I'm using NetBSD on a P4 1.2GHz. What am I doing wrong? I've asked this question on IRC (irc.gnome.org, #gtk+) but noone seems to know the problem. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list -- Michael R. Head [EMAIL PROTECTED] http://www.suppressingfire.org/~burner/ http://suppressingfire.livejournal.com ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: make a window without the title bar
On Fri, 2007-12-14 at 20:52 +0800, Binary Chen wrote: I know it is a feature of window manager, but is there any portable way in GTK+ to do this? In C... gtk_window_set_decorated(GTK_WINDOW(window), FALSE); or Python... window.set_decorated(False); or Java... window.setDecorated(false); etc :) As you noted in your question, this is a *request*. The window manager may choose to ignore you. AfC Sydney ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Multi-threaded UI Freezes on GDK Call
On Tue, 2007-12-18 at 17:14 -0500, Michael R. Head wrote:
On Tue, 2007-12-18 at 16:45 -0500, Michael McCann wrote:
I've got a multithreaded GTK application. One thread runs gtk_main():
gtk_threads_enter();
gtk_main();
gtk_threads_leave();
I assume you meant
g_threads_init();
gdk_threads_init();
gtk_init();
gdk_threads_enter();
gtk_main();
gdk_threads_leave();
right?
The other thread is an infinite loop that sleeps for one second on each
loop. Every x seconds, the infinite loop calls a function, which makes
some GDK calls. At the beginning of this function, gdk_threads_enter()
is called; at the end, gdk_flush() and gdk_threads_leave() is called.
Whenever this function is called, the UI freezes and CPU usage jumps to
100% for about one second (no other applications freeze, of course).
I've tried calling gdk_threads_leave()/enter() before and after each GDK
call to no avail. I run g_thread_init() and gdk_threads_init() at the
beginning of my program.
Does your special function take time to do its job? If so, then that
would be why. For example:
...
while(1) {
gdk_threads_enter();
sleep(1)
gdk_threads_leave();
sleep(10)
};
...
you'd freeze your app for a second every 10 seconds.
In the function, gdk_screen_get_default(), gdk_screen_get_root_window(),
gdk_pixbuf_get_from_drawable(), and gdk_pixbuf_save_to_bufferv() are
called.
I'm using NetBSD on a P4 1.2GHz. What am I doing wrong? I've asked this
question on IRC (irc.gnome.org, #gtk+) but noone seems to know the problem.
___
--
Michael R. Head [EMAIL PROTECTED]
http://www.suppressingfire.org/~burner/
http://suppressingfire.livejournal.com
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
App blueprint, advice please!
Thanks yet again to all for your help with this thread! and special thanks to John, Nicola, Dan, Gian, Lance and Reed for yesterdays posts. This is awesome! I was inspired by Göran's advice to promote selling code not software. I had an idea for the project name yesterday so I registered a couple of domain names. code-read-dot-org (code-red, as in I read the code, get it??) In the next 4-6 weeks I hope to upload diagrams of the proposed infrastructure and I would like to create a login page were I can post information to those who are interested in this project. Information such as competitors screenshots. I thought the login might be wise as I am not sure of the legality of openly posting this material. I will layout the technical challenges to this project, source code I have already collected and a proposal for a business outline. Thanks so much, this project has taken a quantum leap forward in a few days-Patrick ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Multi-threaded UI Freezes on GDK Call
Michael R. Head wrote:
On Tue, 2007-12-18 at 17:14 -0500, Michael R. Head wrote:
I assume you meant
g_threads_init();
gdk_threads_init();
gtk_init();
gdk_threads_enter();
gtk_main();
gdk_threads_leave();
right?
Yes, that is correct. :)
Does your special function take time to do its job? If so, then that
would be why. For example:
...
while(1) {
gdk_threads_enter();
sleep(1)
gdk_threads_leave();
sleep(10)
};
...
you'd freeze your app for a second every 10 seconds.
Ahh, ok. How else can I accomplish my goal, then? I need to give GTK the
lock, as I'm calling GDK from another function not in the main GTK loop.
I tried leaving out gdk_threads_enter()/leave() in the CPU-intensive
function, but X gives me errors.
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Multi-threaded UI Freezes on GDK Call
Michael McCann wrote:
Michael R. Head wrote:
On Tue, 2007-12-18 at 17:14 -0500, Michael R. Head wrote:
I assume you meant
g_threads_init();
gdk_threads_init();
gtk_init();
gdk_threads_enter();
gtk_main();
gdk_threads_leave();
right?
Yes, that is correct. :)
Does your special function take time to do its job? If so, then that
would be why. For example:
...
while(1) {
gdk_threads_enter();
sleep(1)
gdk_threads_leave();
sleep(10)
};
...
you'd freeze your app for a second every 10 seconds.
Ahh, ok. How else can I accomplish my goal, then? I need to give GTK the
Which goal? Describe what your app is supposed to do.
lock, as I'm calling GDK from another function not in the main GTK loop.
I tried leaving out gdk_threads_enter()/leave() in the CPU-intensive
function, but X gives me errors.
tom
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Multi-threaded UI Freezes on GDK Call
Tomas Carnecky wrote:
Michael McCann wrote:
Michael R. Head wrote:
On Tue, 2007-12-18 at 17:14 -0500, Michael R. Head wrote:
I assume you meant
g_threads_init();
gdk_threads_init();
gtk_init();
gdk_threads_enter();
gtk_main();
gdk_threads_leave();
right?
Yes, that is correct. :)
Does your special function take time to do its job? If so, then that
would be why. For example:
...
while(1) {
gdk_threads_enter();
sleep(1)
gdk_threads_leave();
sleep(10)
};
...
you'd freeze your app for a second every 10 seconds.
Ahh, ok. How else can I accomplish my goal, then? I need to give GTK the
Which goal? Describe what your app is supposed to do.
tom
I want to fix the issue of the UI freezing when the CPU-intensive
function, which is on a separate thread and calls GDK, is executed.
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Multi-threaded UI Freezes on GDK Call
On Tue, 2007-12-18 at 18:46 -0500, Michael McCann wrote:
Ahh, ok. How else can I accomplish my goal, then? I need to give GTK the
lock, as I'm calling GDK from another function not in the main GTK loop.
I tried leaving out gdk_threads_enter()/leave() in the CPU-intensive
function, but X gives me errors.
Well, I guess what you need to do is to separate out the CPU intensive
bits of the function from the widget manipulation bits...
my_function() {
compute_real_hard();
gdk_threads_enter();
update_ui();
gdk_threads_leave();
}
Or something like that.
mike
--
Michael R. Head [EMAIL PROTECTED]
suppressingfire.org
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Multi-threaded UI Freezes on GDK Call
I'll break protocol and reply to my own message _again_...
On Tue, 2007-12-18 at 19:05 -0500, Michael R. Head wrote:
On Tue, 2007-12-18 at 18:46 -0500, Michael McCann wrote:
Ahh, ok. How else can I accomplish my goal, then? I need to give GTK the
lock, as I'm calling GDK from another function not in the main GTK loop.
I tried leaving out gdk_threads_enter()/leave() in the CPU-intensive
function, but X gives me errors.
Well, I guess what you need to do is to separate out the CPU intensive
bits of the function from the widget manipulation bits...
my_function() {
compute_real_hard();
gdk_threads_enter();
update_ui();
gdk_threads_leave();
}
Or something like that.
Also, you can skip using gdk_threads_enter() and gdk_threads_leave() if
you instead use g_idle_add(update_ui) and make update_ui a suitable
callback:
http://library.gnome.org/devel/glib/stable/glib-The-Main-Event-Loop.html#g-idle-add
mike
mike
--
Michael R. Head [EMAIL PROTECTED]
suppressingfire.org
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Multi-threaded UI Freezes on GDK Call
Michael McCann wrote:
Michael R. Head wrote:
Does your special function take time to do its job? If so, then that
would be why. For example:
...
while(1) {
gdk_threads_enter();
sleep(1)
gdk_threads_leave();
sleep(10)
};
...
you'd freeze your app for a second every 10 seconds.
Ahh, ok. How else can I accomplish my goal, then? I need to give GTK the
lock, as I'm calling GDK from another function not in the main GTK loop.
I tried leaving out gdk_threads_enter()/leave() in the CPU-intensive
function, but X gives me errors.
Don't use gdk in the CPU-intensive function:
while(1) {
sleep(1);
do_time_consuming_task();
gdk_threads_enter();
update_ui();
gdk_threads_leave();
}
You may need to factor out some code, but this is the right (read: only)
way to do it if you don't want to block the UI.
-brian
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Multi-threaded UI Freezes on GDK Call
On Tue, Dec 18, 2007 at 07:05:18PM -0500, Michael McCann wrote:
Tomas Carnecky wrote:
Michael McCann wrote:
Michael R. Head wrote:
On Tue, 2007-12-18 at 17:14 -0500, Michael R. Head wrote:
I assume you meant
g_threads_init();
gdk_threads_init();
gtk_init();
gdk_threads_enter();
gtk_main();
gdk_threads_leave();
right?
Yes, that is correct. :)
Does your special function take time to do its job? If so, then that
would be why. For example:
...
while(1) {
gdk_threads_enter();
sleep(1)
gdk_threads_leave();
sleep(10)
};
...
you'd freeze your app for a second every 10 seconds.
Ahh, ok. How else can I accomplish my goal, then? I need to give GTK the
Which goal? Describe what your app is supposed to do.
tom
I want to fix the issue of the UI freezing when the CPU-intensive
function, which is on a separate thread and calls GDK, is executed.
Then put your CPU-intensive code on another proces an give data
back on a file descriptor when you are redy. This is the common
way to do it!
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
--
Göran Hasse
Göran Hasseemail: [EMAIL PROTECTED] Tel: 08-6949270
Raditex AB http://www.raditex.se
Planiavägen 15, 1tr Mob: 070-5530148
131 34 NACKA, SWEDEN OrgNr: 556240-0589
VAT: SE556240058901
--
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Multi-threaded UI Freezes on GDK Call
Brian J. Tarricone wrote:
Michael McCann wrote:
Michael R. Head wrote:
Does your special function take time to do its job? If so, then that
would be why. For example:
...
while(1) {
gdk_threads_enter();
sleep(1)
gdk_threads_leave();
sleep(10)
};
...
you'd freeze your app for a second every 10 seconds.
Ahh, ok. How else can I accomplish my goal, then? I need to give GTK the
lock, as I'm calling GDK from another function not in the main GTK loop.
I tried leaving out gdk_threads_enter()/leave() in the CPU-intensive
function, but X gives me errors.
Don't use gdk in the CPU-intensive function:
Unfortunately, the GDK calls _are_ what is CPU-intensive. I believe the
gdk_pixbuf_get_from_drawable() call is the most intensive. None of my regular
code is CPU-intensive.
Of course, if I clocked my CPU back up to 3.2GHz, this wouldn't be a problem.
;D However, I can't count on my users having a fast CPU.
I'll try out that g_idle_add() method tomorrow...
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Multi-threaded UI Freezes on GDK Call
Michael R. Head wrote:
I'll break protocol and reply to my own message _again_...
On Tue, 2007-12-18 at 19:05 -0500, Michael R. Head wrote:
On Tue, 2007-12-18 at 18:46 -0500, Michael McCann wrote:
Ahh, ok. How else can I accomplish my goal, then? I need to give GTK the
lock, as I'm calling GDK from another function not in the main GTK loop.
I tried leaving out gdk_threads_enter()/leave() in the CPU-intensive
function, but X gives me errors.
Well, I guess what you need to do is to separate out the CPU intensive
bits of the function from the widget manipulation bits...
my_function() {
compute_real_hard();
gdk_threads_enter();
update_ui();
gdk_threads_leave();
}
Or something like that.
Also, you can skip using gdk_threads_enter() and gdk_threads_leave() if
you instead use g_idle_add(update_ui) and make update_ui a suitable
callback:
http://library.gnome.org/devel/glib/stable/glib-The-Main-Event-Loop.html#g-idle-add
mike
Ok, I tried the g_idle_add() idea out:
NonUIThread Calls foo() -
foo() calls g_idle_add(), which is passed a GSourceFunc, bar(),
along with some data it needs -
bar() runs a bunch of GDK calls (gdk_threads_enter()/leave() is
_not_ called, neither in foo() nor bar())
foo(), after calling g_idle_add(), immediately begins executing
statements after the g_idle_add() call. However, bar() still holds up
the UI...
Ack!
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Multi-threaded UI Freezes on GDK Call
Michael McCann wrote: Brian J. Tarricone wrote: Don't use gdk in the CPU-intensive function: Unfortunately, the GDK calls _are_ what is CPU-intensive. I believe the gdk_pixbuf_get_from_drawable() call is the most intensive. None of my regular code is CPU-intensive. How large is the GdkDrawable? I wouldn't imagine that to eat too much CPU. You can try only acquiring the gdk lock in your thread when absolutely necessary to see if that helps, like this: do_something_without_gdk(); gdk_threads_enter(); gdk_pixbuf_get_from_drawable(); gdk_threads_leave(); do_other_stuff_without_gdk(); gdk_threads_enter(); do_some_stuff_with_the_gdk_drawable(); gdk_threads_leave(); ... Obviously you don't want to go nuts taking and dropping the lock over and over, but this might help track down (or even eliminate) what part of your code is blocking and causing the UI to freeze (add some printf()s in there too, I guess). -brian ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Multi-threaded UI Freezes on GDK Call
Brian J. Tarricone wrote: Michael McCann wrote: Brian J. Tarricone wrote: Don't use gdk in the CPU-intensive function: Unfortunately, the GDK calls _are_ what is CPU-intensive. I believe the gdk_pixbuf_get_from_drawable() call is the most intensive. None of my regular code is CPU-intensive. How large is the GdkDrawable? It's the size of the entire screen: 1024x768 I wouldn't imagine that to eat too much CPU. You can try only acquiring the gdk lock in your thread when absolutely necessary to see if that helps, like this: do_something_without_gdk(); gdk_threads_enter(); gdk_pixbuf_get_from_drawable(); gdk_threads_leave(); do_other_stuff_without_gdk(); gdk_threads_enter(); do_some_stuff_with_the_gdk_drawable(); gdk_threads_leave(); ... Yes, I've already tried that, to no avail. My code basically only consists of: gdk_screen_get_default(): Get the default screen gdk_screen_get_root_window(): Get the root window gdk_pixbuf_get_from_drawable(): Get a pixbuf from the entire screen gdk_pixbuf_save_to_bufferv(): Save the pixbuf to a buffer. Remove all of the GDK calls, and there is no UI freeze. I can even throw in an infinite loop to any function in the non-UI thread, and the UI does not freeze, which is to be expected. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: C vs C++ for GTK
On Thursday 13 December 2007 08:28, Dan H wrote: On Wed, 12 Dec 2007 09:26:25 -0700 Michael L Torrie [EMAIL PROTECTED] wrote: GTKmm is based on some very nice C++ abstractions around pointers, providing many of the same benefits as any managed language with pure C++. They are called smart pointers and for GUI development, they work very very well. Isn't smart pointers just a reference counting scheme? Exactly, yes. It is no substitute for accurate GC, of course. -- Dr Jon D Harrop, Flying Frog Consultancy Ltd. http://www.ffconsultancy.com/products/?e ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Button Callbacks
Hi guys, I have this really dumb problem, but I can´t get my head around it. My program should do the following: - When a button is pressed, a specific playlist[m3u]-file should be opened in the media player. Sure, the first part is to add a callback for the buttons, but how do I open the file (and with it the media player. It should do the same as a double click on the file would)? Is it even possible to do do it this way? I would be unbelievable grateful for ideas, tips or hints. I´m kinda at my wits end. So long, V -- View this message in context: http://www.nabble.com/Button-Callbacks-tp14350641p14350641.html Sent from the Gtk+ - Apps Dev mailing list archive at Nabble.com. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Custom container widget - childs drawn in top-left corner of window
On Dec 15, 2007 8:46 AM, Stephan Arts [EMAIL PROTECTED] wrote:
Hi,
I am having an issue with a new container widget I am writing. I have
overridden the size_request and size_allocate methods.[0]
For some reason, the children are all rendered in the top-left corner
of the main window. Not even near the container.
[...]
child_allocation.x = allocation-x + border_width;
child_allocation.y = allocation-y + border_width;
child_allocation.width = 70 - border_width;
child_allocation.height = 70 - border_width;
Looks like you ignored the allocation here and just assigned 70...
/*
if (GTK_WIDGET_REALIZED (widget))
{
gdk_window_move_resize (widget-window,
allocation-x + border_width,
allocation-y + border_width,
allocation-width - border_width * 2,
allocation-height - border_width * 2);
}
*/
And your problem is here, since you never moved your GdkWindow to
where it is supposed to be, it is infact still at its default location at
the
top-left corner of its parent window.
Cheers,
-Tristan
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Reparsing with GtkBuilder
amol wrote: Hi If i used gtk_builder_add_from_string to parse some string for builder which already has some content then application terminates with following message Gtk-ERROR **: file gtkbuilder.c: line 567 (apply_delayed_properties): assertion failed: (object != NULL) if builder had already set some delayed property. If builder had not set any delayed property previously then it does not crashes while reparsing with add_string. Is this bug in Gtk+? Likely! Multiple calls to add_from_string/add_from_file has not yet been thoroughly tested. Delayed properties are applied in parser finished. If we parse any buffer again with same builder then it tries to set the delayed properties again which are irrelevant. setting builder-delayed_properties to NULL in parser_finished solves above problem but is this a right solution or it has any other side effects? If new buffer has any delayed properties associated with objects then builder-delayed_properties will set again and that properties will be applied in parser_finished. This makes sense, we had a similar bug related to signal connection and the solution is the same as you proposed. Could you please file a bug and let the discussion continue there? Johan ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Multi-threaded UI Freezes on GDK Call
I've got a multithreaded GTK application. One thread runs gtk_main(): gtk_threads_enter(); gtk_main(); gtk_threads_leave(); The other thread is an infinite loop that sleeps for one second on each loop. Every x seconds, the infinite loop calls a function, which makes some GDK calls. At the beginning of this function, gdk_threads_enter() is called; at the end, gdk_flush() and gdk_threads_leave() is called. Whenever this function is called, the UI freezes and CPU usage jumps to 100% for about one second (no other applications freeze, of course). I've tried calling gdk_threads_leave()/enter() before and after each GDK call to no avail. I run g_thread_init() and gdk_threads_init() at the beginning of my program. In the function, gdk_screen_get_default(), gdk_screen_get_root_window(), gdk_pixbuf_get_from_drawable(), and gdk_pixbuf_save_to_bufferv() are called. I'm using NetBSD on a P4 1.2GHz. What am I doing wrong? I've asked this question on IRC (irc.gnome.org, #gtk+) but noone seems to know the problem. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Multi-threaded UI Freezes on GDK Call
On Tue, 2007-12-18 at 20:37 -0500, Michael McCann wrote: Brian J. Tarricone wrote: Yes, I've already tried that, to no avail. My code basically only consists of: gdk_screen_get_default(): Get the default screen gdk_screen_get_root_window(): Get the root window gdk_pixbuf_get_from_drawable(): Get a pixbuf from the entire screen OK, yeah, this operation will probably be slow! Taking a screenshot is a time consuming op. I don't think there's much to do about that. I mean, just run the Applications/Accessories/Take Screenshot app to see how long it takes. There is probably a better way to implement your app. What exactly do you want to do? gdk_pixbuf_save_to_bufferv(): Save the pixbuf to a buffer. Remove all of the GDK calls, and there is no UI freeze. I can even throw in an infinite loop to any function in the non-UI thread, and the UI does not freeze, which is to be expected. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list -- Michael R. Head [EMAIL PROTECTED] http://picasaweb.google.com/demiri.head.wedding ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Force redrawing of a window
Am Dienstag, den 18.12.2007, 00:33 + schrieb Xaero: Hi, I added an rgba colormap to a screen (using gdk_screen_get_rgba_colormap and gtk_widget_set_default_colormap); The result is that the change affects only new created windows, while those which already exist remain the same. Is there a solution? I have not worked with RGBA visuals yet, but from my theoretical understanding you cannot chance the visual of existing __X11__ windows. Therefore I'd try to call gtk_widget_unrealize(), followed by gtk_widget_realize() on your window. I hope this information helps. This list has the purpose of coordinating development of the library itself, btw. For questions regarding use of GTK+ there are the gtk-list and the gtk-app-devel-list mailing lists. Ciao, Mathias -- Mathias Hasselmann [EMAIL PROTECTED] http://taschenorakel.de/ signature.asc Description: Dies ist ein digital signierter Nachrichtenteil ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
GLib Testframework API
Sorry for being late in the game for comments, but here we go. In general this api differs slightly from JUnit/python, which has the following (main) methods: assertEqual assertNotEqual assertTrue assertFalse assertRaises Perhaps the term equals could be used instead of cmp. assertTrue is g_assert, but assertFalse is missing. I know it is easy to just put an ! in the beginning of the expression, but it is easier to read if it is explicitly visible in the function/macro name. I haven't looked in detail at the trap api, but having something similar to assertRaises for g_error friends would be a good thing. g_assert_cmpstr, accepts a comparison operator, while this makes sense for comparing floats and integers I don't think it should be included in the api for strings. Basically, the only thing you want to check if is a string is equal to another or not, so perhaps it could be replaced with: g_assert_equals_str g_assert_not_equals_str Or do you see a use case for using other operators besides == and != ? Johan ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Expose event for DirectFb
Hi all, Is there any DirectFb events equivalent to x11 expose-event. I am currently porting Firefox X11 events related code to DirectFb. I built gtk+-2.10.14 with DirectFb. Thanks in Advance, Logan ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
g_format_file_size_for_display()
Should this be called generically g_format_size_for_display()? You could use it for more than file sizes (free RAM in gnome-system-monitor, etc.). Federico ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: g_format_file_size_for_display()
On Tue, 2007-12-18 at 14:50 -0600, Federico Mena Quintero wrote: Should this be called generically g_format_size_for_display()? You could use it for more than file sizes (free RAM in gnome-system-monitor, etc.). It's here btw http://svn.gnome.org/viewvc/glib/trunk/glib/gfileutils.c?revision=6076view=markup char *g_format_file_size_for_display (goffset size); Ideally this one needs to take another parameter indicating whether you want 1kb = 1000 bytes or 1kb = 1024 bytes. The reason is that we want to generate nice display names in the volume monitor; for ordinary media you want 1000 (to match the label on the media); for optical discs you normally want 1024. gnome-vfs has this terrible bug where it uses 1024 so you get the label 61.2 MB media even when the media itself says 64MB. This is kinda like punching the user right in the face. It's not a mistake we should make for the new shiny gvfs stuff. David ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: g_format_file_size_for_display()
Computer Makers Sued Over Hard Drive Size http://yro.slashdot.org/article.pl?sid=03/09/18/2245200 ;) On Tue, 2007-12-18 at 16:45 -0500, David Zeuthen wrote: On Tue, 2007-12-18 at 14:50 -0600, Federico Mena Quintero wrote: Should this be called generically g_format_size_for_display()? You could use it for more than file sizes (free RAM in gnome-system-monitor, etc.). It's here btw http://svn.gnome.org/viewvc/glib/trunk/glib/gfileutils.c?revision=6076view=markup char *g_format_file_size_for_display (goffset size); Ideally this one needs to take another parameter indicating whether you want 1kb = 1000 bytes or 1kb = 1024 bytes. The reason is that we want to generate nice display names in the volume monitor; for ordinary media you want 1000 (to match the label on the media); for optical discs you normally want 1024. gnome-vfs has this terrible bug where it uses 1024 so you get the label 61.2 MB media even when the media itself says 64MB. This is kinda like punching the user right in the face. It's not a mistake we should make for the new shiny gvfs stuff. David ___ 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: g_format_file_size_for_display()
Hi, On Tue, 2007-12-18 at 16:45 -0500, David Zeuthen wrote: On Tue, 2007-12-18 at 14:50 -0600, Federico Mena Quintero wrote: Should this be called generically g_format_size_for_display()? You could use it for more than file sizes (free RAM in gnome-system-monitor, etc.). It's here btw http://svn.gnome.org/viewvc/glib/trunk/glib/gfileutils.c?revision=6076view=markup char *g_format_file_size_for_display (goffset size); Ideally this one needs to take another parameter indicating whether you want 1kb = 1000 bytes or 1kb = 1024 bytes. We should also decide then whether the displayed size should use MB or MiB, see http://en.wikipedia.org/wiki/Mebibyte and http://www.iec.ch/zone/si/si_bytes.htm Sven ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: g_format_file_size_for_display()
On Tue, 2007-12-18 at 23:01 +0100, Sven Neumann wrote: We should also decide then whether the displayed size should use MB or MiB, see http://en.wikipedia.org/wiki/Mebibyte and http://www.iec.ch/zone/si/si_bytes.htm I think MiB would just go into the geekspeak_US translations, no? :-) David ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: g_format_file_size_for_display()
On Tue, 18 Dec 2007 23:01:22 +0100 Sven Neumann [EMAIL PROTECTED] wrote: We should also decide then whether the displayed size should use MB or MiB, see http://en.wikipedia.org/wiki/Mebibyte and http://www.iec.ch/zone/si/si_bytes.htm I for one would like to vote in favour of the kiB/MiB/etc.. scheme for powers-of-2, reserving kB/MB/etc.. strictly for powers-of-10. Trying to cuddle users by protecting them from the confusing MiB unit will only lead to even more confusion about 1000 vs 1024. Better to be consistent eveywhere, even if it means sometimes people have to learn what ki means. -- 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: GLib Testframework API
On Tue, 2007-12-18 at 06:20 -0500, Johan Dahlin wrote: assertTrue is g_assert, but assertFalse is missing. Call it g_assert_fail()... -- 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-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: g_format_file_size_for_display()
On Tue, 18 Dec 2007 22:13:56 + Paul LeoNerd Evans [EMAIL PROTECTED] wrote: I for one would like to vote in favour of the kiB/MiB/etc.. scheme for Oops. Apparently it's KiB (capital 'K') to mean 2^10. How's that for consistency? :) -- 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: g_format_file_size_for_display()
Am Dienstag, den 18.12.2007, 23:01 +0100 schrieb Sven Neumann: Hi, On Tue, 2007-12-18 at 16:45 -0500, David Zeuthen wrote: On Tue, 2007-12-18 at 14:50 -0600, Federico Mena Quintero wrote: Should this be called generically g_format_size_for_display()? You could use it for more than file sizes (free RAM in gnome-system-monitor, etc.). It's here btw http://svn.gnome.org/viewvc/glib/trunk/glib/gfileutils.c?revision=6076view=markup char *g_format_file_size_for_display (goffset size); Ideally this one needs to take another parameter indicating whether you want 1kb = 1000 bytes or 1kb = 1024 bytes. We should also decide then whether the displayed size should use MB or MiB, see http://en.wikipedia.org/wiki/Mebibyte and http://www.iec.ch/zone/si/si_bytes.htm I am all for SI units, even it writing MiB could cause some users to believe, we are too stupid to spell. Seemingly random switching between 1000 and 1024 whouldn't really help - I guess: Imagine some user wants to copy a 64 MiB file from some 1024 to some 1000 scale media: WTF doesn't this 64 MB file (64 * 2^10 bytes) fit on this 64 MB stick (64 * 10^6 bytes)? Ciao, Mathias -- Mathias Hasselmann [EMAIL PROTECTED] Openismus GmbH: http://www.openismus.com/ Personal Site: http://taschenorakel.de/ signature.asc Description: Dies ist ein digital signierter Nachrichtenteil ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: g_format_file_size_for_display()
On Tue, Dec 18, 2007 at 05:14:31PM -0600, Federico Mena Quintero wrote: Big deal :) When you see 61.2 MB you think, oh, file system overhead! ripples in the time-space continuum. Nobody cares about that. Back to my original question: should this function be called g_format_size_for_display()? It's not for files only. I have no idea whether to use SI or computer units, but the fact that there's debate suggests holding off til there's more experience. Once a few cut-n-pasted versions exist, then you can decide if they are all the same... - dave ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: g_format_file_size_for_display()
On Tue, 2007-12-18 at 16:45 -0500, David Zeuthen wrote: char *g_format_file_size_for_display (goffset size); Ideally this one needs to take another parameter indicating whether you want 1kb = 1000 bytes or 1kb = 1024 bytes. No, because then you'll have applications using either, and then someone will want to make them consistent and we'll get an option in the control center an an XSETTING, which is yet another thing we'll have to port over when moving from GConf to DConf, and it's just a big fat mess. The reason is that we want to generate nice display names in the volume monitor; for ordinary media you want 1000 (to match the label on the media); for optical discs you normally want 1024. gnome-vfs has this terrible bug where it uses 1024 so you get the label 61.2 MB media even when the media itself says 64MB. This is kinda like punching the user right in the face. It's not a mistake we should make for the new shiny gvfs stuff. Big deal :) When you see 61.2 MB you think, oh, file system overhead! ripples in the time-space continuum. Nobody cares about that. Back to my original question: should this function be called g_format_size_for_display()? It's not for files only. [Who's the nitpicker: the one who asks for file sizes versus general sizes or the one who asks about SI units vs. computer units...] Federico ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: g_format_file_size_for_display()
On Tue, 2007-12-18 at 15:31 -0800, Dave Benson wrote: On Tue, Dec 18, 2007 at 05:14:31PM -0600, Federico Mena Quintero wrote: Big deal :) When you see 61.2 MB you think, oh, file system overhead! ripples in the time-space continuum. Nobody cares about that. Back to my original question: should this function be called g_format_size_for_display()? It's not for files only. I have no idea whether to use SI or computer units, but the fact that there's debate suggests holding off til there's more experience. Actually, I see it as an argument for centralizing the call and abstracting the decision away from apps. Then whenever its tweaked you fix it in one spot and it instantly propagates everywhere. Once a few cut-n-pasted versions exist, then you can decide if they are all the same... They are already a few like gnome-system-monitor, gnome-main-menu, presumably nautilus. -JP -- JP Rosevear [EMAIL PROTECTED] Novell, Inc. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: g_format_file_size_for_display()
David Zeuthen wrote: Ideally this one needs to take another parameter indicating whether you want 1kb = 1000 bytes or 1kb = 1024 bytes. The reason is that we want to generate nice display names in the volume monitor; for ordinary media you want 1000 (to match the label on the media); for optical discs you normally want 1024. gnome-vfs has this terrible bug where it uses 1024 so you get the label 61.2 MB media even when the media itself says 64MB. This is kinda like punching the user right in the face. It's not a mistake we should make for the new shiny gvfs stuff. Mistake? That's correct behavior. It's not our fault the storage companies lie and use base-10 kB/MB/GB when everyone else uses base-2, and in fact they've been successfully sued in the US for doing this. Reporting the *actual* size of the media in base-2 units is the right way to go everywhere. Whether to use traditional kB/MB/GB or the (IMO somewhat ridiculous) SI KiB(which breaks the normal lowercase k = kilo convention for no reason)/MiB/GiB is another discussion. (I'd vote no in that discussion, at any rate.) -brian ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: g_format_file_size_for_display()
We can make it _(kB), and then people can use LANG=en_US.crazy-si-units if they really want that. Sounds like a case for LC_MEASUREMENT, acutally. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: g_format_file_size_for_display()
Hi, On Tue, 2007-12-18 at 17:14 -0600, Federico Mena Quintero wrote: char *g_format_file_size_for_display (goffset size); Ideally this one needs to take another parameter indicating whether you want 1kb = 1000 bytes or 1kb = 1024 bytes. No, because then you'll have applications using either, and then someone will want to make them consistent and we'll get an option in the control center an an XSETTING, which is yet another thing we'll have to port over when moving from GConf to DConf, and it's just a big fat mess. Yes, because this is a choice that the application developer needs to make, not the user. So this is never going to become am option in the control center or an XSETTING. We just need to make sure that the API docs give the application developer the information they need to make the right choice. Back to my original question: should this function be called g_format_size_for_display()? It's not for files only. Yes, we all seem to agree that this function is useful for other things than file sizes. But we should try to get it right. Otherwise it is simply not going to be used and we force application developers to invent their own function. Sven ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
