On Mon, Jun 07, 2004 at 01:50:10PM -0400, [EMAIL PROTECTED] wrote:
> On Sat, 05 Jun 2004 23:24:19 CDT, David <[EMAIL PROTECTED]> said:
> > I don't know how to do it on a Windows system, but I was able to get
> > to the gimp/win32 site by adding the entry
> > 128.32.112.248 www.gimp.org
> > t
Dear GTK gurus,
I ran into a problem when trying to compile GTK+2.4.2 on MacOSX 10.2.8.
The root cause is that getc_unlocked() is not available on my system,
and this is not correctly handled in xdgmimemagic.c.
As a temporary solution, I have added the following to
gtk/xdgmime/xdgmimemagic.c:
#
There is a function in glib called g_idle_add which makes it so the
function will be called in the main loop, avoiding locking problems.
What I typically do is wrap functions like I've shown below so you
basically call thread_button_set_label instead of gtk_button_set_label
and everything works out
On Sat, 05 Jun 2004 23:24:19 CDT, David <[EMAIL PROTECTED]> said:
> I don't know how to do it on a Windows system, but I was able to get to
> the gimp/win32 site by adding the entry
>
> 128.32.112.248 www.gimp.org
>
> to my /etc/hosts file on my Linux system. This allows my system to
> resolve
Hi
I am writing a GTK+-2.0 code that is supposed to change the label of a GtkButton
constantly in a thread diferent than the main, while the button is usefull.
The next is the code i have until now:
-- code --
#include
#include
#include
#include "gthread.h"
static void
print_something (GtkW
>Maybe this wouldn't work for you, but I get around this problem by having a separate
>style for each state and flipping widgets between them with
>a gtk_widget_set_name(). For example:
Thanks for the idea. Its a good one. I don't like the resource
consumption (we have 400 widget "names" in Ardo
I have a GTK app that places a bunch of Canvas Items on to a Gnome
Canvas. The user can then click on the Items and move them around.
When the Item is clicked on it also raises to the top.
My problem arises when saving the results of the clickage. I can
get the X and Y of the Items, but I ca
Paul Davis wrote:
Are there are any plans to allow disabling of prelight, globally, in
any future version of GTK?
Prelighting conflicts absolutely with the use of color to distinguish
widget state. For a simple demonstration, consider this style:
style "foo" {
fg[NORMAL]
Are there are any plans to allow disabling of prelight, globally, in
any future version of GTK?
Prelighting conflicts absolutely with the use of color to distinguish
widget state. For a simple demonstration, consider this style:
style "foo" {
fg[NORMAL] = { 1.0, 0.0, 0.0
