Enable/Disable a button and mouse clicks
I've found that if I disable a button after a click on it
(gtk_widget_set_sensitive(button, FALSE)), and then enable it back after
a timed event or something else occurs (...set_sensitive(button, TRUE)
), I'm unable to click on the button with the mouse pointer unless I
exit with the pointer from the button rectangle and enter back in it.
This is a minimal example showing this strange behaviour, I think it's a
wanted behaviour and not a bug (I found this behaviour in GTK 2.6, 2.8,
but not in GTK 2.4), but it's not what I want from my button, there is
any workaround for it?
#include gtk/gtk.h
#include stdio.h
int do_timeout(GtkWidget *w)
{
printf(Timed out, enabling button\n);
gtk_widget_set_sensitive(w, TRUE);
return 0;
}
int clicked(GtkWidget *w)
{
printf(Button clicked!\n);
gtk_widget_set_sensitive(w, FALSE);
g_timeout_add(2000, do_timeout, w);
}
int main(int argc, char *argv[])
{
gtk_init(argc, argv);
GtkWidget *w = gtk_window_new(GTK_WINDOW_TOPLEVEL);
GtkWidget *b = gtk_button_new_with_label(Test);
gtk_container_add(GTK_CONTAINER(w), b);
g_signal_connect(b, clicked, clicked, NULL);
gtk_widget_show_all(w);
gtk_main();
}
Bye,
Gabry
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
How to detect the presence of scrollbar on scrolled window.
Does anyone know how to find out whether a vertical scrollbar is present
on scolled window or not.
I need to detect its presence at runtime.
below is the code which i tried to find out.but it is not working as
expected.
line 3 is always returning false.irrespective of vscrollbar presence.
1. scrolled_window = (GtkScrolledWindow *) gtk_scrolled_window_new
(NULL, NULL);
2. gtk_scrolled_window_set_policy (scrolled_window, GTK_POLICY_NEVER,
GTK_POLICY_AUTOMATIC);
3. if (scrolled_window-vscrollbar_visible) {
4. GtkWidget *widget = gtk_scrolled_window_get_vscrollbar
(scrolled_window);
5. width = widget-requisition.width;
6. }
Thanks and Regards,
Amol.
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Enable/Disable a button and mouse clicks
Gabriele Greco wrote: I've found that if I disable a button after a click on it (gtk_widget_set_sensitive(button, FALSE)), and then enable it back after a timed event or something else occurs (...set_sensitive(button, TRUE) ), I'm unable to click on the button with the mouse pointer unless I exit with the pointer from the button rectangle and enter back in it. You've discovered bug 56070[1]. There are some workarounds at the bug, but we're fairly close to getting it fixed in GTK+. Ed 1. http://bugzilla.gnome.org/show_bug.cgi?id=56070 ___ 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 detect the presence of scrollbar on scrolled window.
amol wrote:
Does anyone know how to find out whether a vertical scrollbar is present
on scolled window or not.
I need to detect its presence at runtime.
below is the code which i tried to find out.but it is not working as
expected.
line 3 is always returning false.irrespective of vscrollbar presence.
1. scrolled_window = (GtkScrolledWindow *) gtk_scrolled_window_new
(NULL, NULL);
2. gtk_scrolled_window_set_policy (scrolled_window, GTK_POLICY_NEVER,
GTK_POLICY_AUTOMATIC);
3. if (scrolled_window-vscrollbar_visible) {
There's no such member as vscrollbar_visible in the GtkScrolledWindow
struct. Use gtk_scrolled_window_get_vscrollbar(), and possibly
GTK_WIDGET_VISIBLE.
Ed
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
GtkEntry text selection
When I bring focus to a GtkEntry, all of its text gets selected by default. How can I disable this behaviour? I want the text to remain un-selected and cursor in the end. Thanks Anurag _ Tried the new MSN Messenger? Its cool! Download now. http://messenger.msn.com/Download/Default.aspx?mkt=en-in ___ 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 capture mouse movements independend of a Window?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wed, Jan 03, 2007 at 12:18:17PM +0100, [EMAIL PROTECTED] wrote: Hello!! hello! (please, keep the list CC'ed so that others may lurk/chime-in) I'm new in this treatment, but your help is good for me. Glad it is :) I compile your code in a good way, but i want to add a cursor, just being inside the window(like the code), but with the option of deleting it,just ,leaving the window. So you just want to hide the cursor? What you do is to create an invisible pixmap. Instead of: GdkCursor *cursor = gdk_cursor_new(GDK_PIRATE); you can do (Warning: untested code): GdkCursor *cursor = gdk_cursor_new_from_pixmap(NULL, /* pixmap */ NULL, /* mask */ NULL, /* foreground */ NULL, /* background */ 0,/* xoff */ 0); /* yoff */ In your code, i can't left main window.. please, can you help me?? This is supposed to work this way. That's why I warned that this is a trap :-) For a real application, you'd have to make another event function which releases the grab. I did it for two reasons: (1) simplicity (I didn't want to complicate the sample program with irrelevant stuff) (2) to convey that pointer grabs in X are a sharp tool: use them sparingly or your users will curse at you (and for very good reasons). I seem to remember that it was late Netscape 4.x which used to half-crash, closing all the windows and keeping the grab. Boy, that was obnoxious. thanks a lot You are welcome - -- tomás -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFFm6flBcgs9XrR2kYRAvArAJ4ogflb75SFjCzuFvfJU2qdaHEt+ACfQM7p xugyedsu/UoYZ0VuC7/eZGA= =0KpM -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
How to convert GtkWidget into GdkPixbuf
I want to convert GtkWidget into GdkPixbuf. Is there any way to do that? I am trying to write an application in which i have a top-level widget which has some data (text and images) . I want to have panning and zooming support for that window. Thanks and Regards, Sanny Chawla ___ 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 capture mouse movements independend of a Window?
Yo tomas!
OK, here is a rough sketch (tested). As soon as the pointer crosses the
window boundary (inward), it is grabbed (the app changes the cursor's
appearance to show it). WARNING! IT IS A TRAP! Once your pointer is
inside, you won't be let out. See to it that you have a console around
(a virtual console wth ctrl-alt-Fn will do) to kill the app. Keep out of
reach of children ;-)
You're great. This at least solve the problem that the pointer cannot leave
the application window. One step further.
But the main problem remains: Once the pointer (Pirate!!) touch the border
or the window, the mouse coordinate don't change anymore.
Remember: I need to get the relative mouse movement independend of the
absolute cursor position.
Maybe there is a function to place the cursor in the middle of the window?
I've tested your application and rewrote it in PyGTK. (This one you can
even give to children, the pointer is released after 15 seconds ;-) )
Thank you.
Cheers, Andy
import pygtk
pygtk.require(2.0)
import gobject, gtk
def release_me():
gtk.main_quit()
return True
def on_destroy(widget):
gtk.main_quit()
def on_enter(widget, event):
if event.type == gtk.gdk.ENTER_NOTIFY:
cursor = gtk.gdk.Cursor(gtk.gdk.PIRATE) # Pirates!!
gtk.gdk.pointer_grab(widget.window, False, gtk.gdk.POINTER_MOTION_MASK,
widget.window, cursor, long(event.time))
gobject.timeout_add(15000, release_me)
else:
# leaving: won't happen
gtk.gdk.pointer_ungrab(long(event.time))
return False
def on_move(widget, event):
print move to:, event.x, event.y
def main():
w = gtk.Window()
w.set_title(Grabby)
w.connect('destroy', on_destroy)
w.connect('enter-notify-event', on_enter)
w.connect('motion-notify-event', on_move)
w.show_all()
gtk.main()
gdk.pointer_ungrab(long(event.time))
if __name__ == '__main__':
main()
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Using GLib main loop to free up temporary memory
Greetings!
When you program with GTK+ (or GLib) with C, sometimes there's a need
for temporary dynamically-allocated variables. The problem is to free
them in the right time — or worse — having to use even more auxiliary
variables, like in the example below:
gchar *func(void) {
gchar *temp = g_strdup(i am a temporary string);
return g_strdup_printf(%s - %f, temp, G_PI);
}
In this example, the temp variable will leak memory, since it was not
freed after g_strdup_printf. A way to fix this would be rewriting func
as:
gchar *func(void) {
gchar *temp = g_strdup(i am a temporary string);
gchar *temp2 = g_strdup_printf(%s - %f, temp, G_PI);
g_free(temp);
return temp2;
}
Much better: temp won't leak anymore, but we had to use another
variable. I propose a simpler solution, but it requires that your
program runs in the GLib main loop. It should be used only on callback
functions and is not threadsafe. Include these two tiny functions in
your program:
static gboolean __idle_free_do(gpointer ptr) {
g_free(ptr);
return FALSE;
}
void gpointer idle_free(gpointer ptr) {
g_idle_add(__idle_free_do, ptr);
return ptr;
}
Now we can rewrite func as:
gchar *func(void) {
gchar *temp = idle_free(g_strdup(i am a temporary variable));
return g_strdup_printf(%s - %f, temp, G_PI);
}
This way the memory will be freed as soon as GLib gains control and
the main loop is ready to process events.
Use the code as you wish.
Cheers,
--
Leandro A. F. Pereira [EMAIL PROTECTED]
Developer, Tiamat Software Wizardry.
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Saving a GdkWindow to a file
Greetings, In my application I have to save the contents of a widget to a PNG file. So far it works (using GDK Pixbuf and gdk_pixbuf_save), but garbage appears if the window is obscured by another window, or if some part of it is hidden. How can someone get a GtkWidget's GdkWindow in a way no garbage will show up if that window isn't completely visible? I know that GTK+ is double-buffered, so it must be some way. By the way, the code I am currently using is available at [1]. See tree_view_save_image(). [1] http://svn.berlios.de/wsvn/hardinfo/trunk/hardinfo2/util.c?op=filerev=0sc=0 Thanks in advance, -- Leandro A. F. Pereira [EMAIL PROTECTED] Developer, Tiamat Software Wizardry. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: [SPAM] Re: Enable/Disable a button and mouse clicks
Ed Catmur wrote: You've discovered bug 56070[1]. There are some workarounds at the bug, but we're fairly close to getting it fixed in GTK+. After a complete read of the thread I've implemented the workaround based on the window motion events capture, seems to work correctly both on linux and win32. Bye, Gabry ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Using GLib main loop to free up temporary memory
On Wed, 2007-01-03 at 13:02 -0200, Leandro A. F. Pereira wrote:
Greetings!
When you program with GTK+ (or GLib) with C, sometimes there's a need
for temporary dynamically-allocated variables. The problem is to free
them in the right time — or worse — having to use even more auxiliary
variables, like in the example below:
gchar *func(void) {
gchar *temp = g_strdup(i am a temporary string);
return g_strdup_printf(%s - %f, temp, G_PI);
}
That's - no doubt - faulty leaking code.
In this example, the temp variable will leak memory, since it was not
freed after g_strdup_printf. A way to fix this would be rewriting func
as:
gchar *func(void) {
gchar *temp = g_strdup(i am a temporary string);
gchar *temp2 = g_strdup_printf(%s - %f, temp, G_PI);
g_free(temp);
return temp2;
}
That's redundant code that tries to fix the faulty code, but it does a
poor work.
You can just do:
gchar *func(void) {
return g_strdup_printf(i am a temporary string - %f, G_PI);
}
Much better: temp won't leak anymore, but we had to use another
variable. I propose a simpler solution, but it requires that your
program runs in the GLib main loop. It should be used only on callback
functions and is not threadsafe.
AFAIK idle calls are thread safe.
Include these two tiny functions in
your program:
static gboolean __idle_free_do(gpointer ptr) {
g_free(ptr);
return FALSE;
}
void gpointer idle_free(gpointer ptr) {
g_idle_add(__idle_free_do, ptr);
return ptr;
}
If it's a void function, it may return nothing.
Try to increase the output level of your compiler if it does not warns
you about this - as example -Wall.
Now we can rewrite func as:
gchar *func(void) {
gchar *temp = idle_free(g_strdup(i am a temporary variable));
return g_strdup_printf(%s - %f, temp, G_PI);
}
This way the memory will be freed as soon as GLib gains control and
the main loop is ready to process events.
Please don't do that. The variable can be freed before the return value
is used.
Instead of all this, just free the allocated memory as soon as you use
it.
gchar *var = g_strdup_printf(i am a temporary string - %f, G_PI);
g_print(%s\n, var);
g_free (var);
Regards.
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: GtkEntry text selection
You can use the focus signal to set the cursor position using gtk_editable_set_position with a position of -1 to indicate the end of the text. - Micah Carrick http://www.micahcarrick.com | http://www.gtkforums.com Anurag Chaudhary wrote: When I bring focus to a GtkEntry, all of its text gets selected by default. How can I disable this behaviour? I want the text to remain un-selected and cursor in the end. Thanks Anurag _ Tried the new MSN Messenger? It's cool! Download now. http://messenger.msn.com/Download/Default.aspx?mkt=en-in ___ 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
Tooltip per GtkClist row
Hi, Is it possible to add tooltip to individual GtkCList rows? Regards, Preeti ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Tooltip per GtkClist row
On Thu, 2007-01-04 at 09:00 +0530, Preeti Joshi wrote: Hi, Is it possible to add tooltip to individual GtkCList rows? Um, you do realise GtkCList is deprecated? You should be using GtkTreeView with a GtkListStore. That said, the answer to your question is: Not yet. See http://bugzilla.gnome.org/show_bug.cgi?id=80980 for the gory details. Ed ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: GtkEntry text selection
The real problem is not setting the cursor position but the automatic selection of the text in the GtkEntry field. The text should remain un-selected when focussed. From: Micah Carrick [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] To: gtk-app-devel-list@gnome.org Subject: Re: GtkEntry text selection Date: Wed, 03 Jan 2007 13:06:17 -0800 You can use the focus signal to set the cursor position using gtk_editable_set_position with a position of -1 to indicate the end of the text. - Micah Carrick http://www.micahcarrick.com | http://www.gtkforums.com Anurag Chaudhary wrote: When I bring focus to a GtkEntry, all of its text gets selected by default. How can I disable this behaviour? I want the text to remain un-selected and cursor in the end. Thanks Anurag _ Tried the new MSN Messenger? It's cool! Download now. http://messenger.msn.com/Download/Default.aspx?mkt=en-in ___ 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 _ Catch all the cricketing action right here. Live score, match reports, photos et al. http://content.msn.co.in/Sports/Cricket/Default.aspx ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: GtkEntry text selection
On Thu, Jan 04, 2007 at 10:31:15AM +0530, Anurag Chaudhary wrote: The text should remain un-selected when focussed. gtk-entry-select-on-focus = 0 in gtkrc? Yeti -- http://physics.muni.cz/~yeti/pf2007.png ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: GtkEntry text selection
This will change the behaviour for all the Gtkentry widgets system wide. Can something be done for just one specific widget? Anurag From: David Neèas (Yeti) [EMAIL PROTECTED] To: gtk-app-devel-list@gnome.org Subject: Re: GtkEntry text selection Date: Thu, 4 Jan 2007 07:52:02 +0100 On Thu, Jan 04, 2007 at 10:31:15AM +0530, Anurag Chaudhary wrote: The text should remain un-selected when focussed. gtk-entry-select-on-focus = 0 in gtkrc? Yeti -- http://physics.muni.cz/~yeti/pf2007.png ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list _ Want to know what your favourite stars are up to? Catch the latest gossip in Bollywood on MSN Entertainment! http://content.msn.co.in/Entertainment/Default ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Gtk+ upstream meeting at FOSDEM
Hey All. it looks like a critical mass of (european?) Gtk+ developers can emerge at FOSDEM, the 24th and 25th February 2007 in Brussels, Belgium: http://www.fosdem.org/2007/ so it'd be really nice if a Gtk+ project meeting could be arranged there to discuss general upstream development issues, future plans/visions/nightmares/ wishlists, bug lists, etc. ;) i think such a meeting would best be held on the 23rd February 2007 to avoid collision with the official FOSDEM schedule. so everyone meaning to come to FOSDEM/Bruessels on the 23rd, 24th, 25th, or 26th February 2007 and would like to join the Gtk+ meeting, please drop me a line so i can refine the proposed date to get most people on it. --- ciaoTJ ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: bugs regarding late g_thread_init() calls
On Wed, 3 Jan 2007, Gustavo J. A. M. Carneiro wrote: On Qua, 2007-01-03 at 00:57 +0100, Tim Janik wrote: On Tue, 2 Jan 2007, Gustavo J. A. M. Carneiro wrote: On Ter, 2007-01-02 at 14:34 +0100, Tim Janik wrote: hey all. since the very early inception of the glib threading system, the docs say ( http://developer.gnome.org/doc/API/2.0/glib/glib-Threads.html ): You must call g_thread_init() before executing any other GLib functions in a threaded GLib program. In PyGObject it is virtually impossible to guarantee that g_thread_init() gets called before using some other GLib APIs. At least not without changing the API. That's because g_thread_init() is called by the python function gobject.threads_init(), but you obviously can't call gobject.threads_init() without importing gobject first, and of course import gobject already calls some GLib APIs... This is a very tricky problem :| what glib APIs are you calling there and why couldn't g_thread_init() be the first glib function to call there? For instance, g_boxed_type_register_static and g_quark_from_static_string, probably others. We need to call these on python module initialization. We don't want to call g_thread_init() unless the programmer requests to, in order to not suffer threading support performance penalty, of course.. in the single threaded case, the overhead is negligible and in the multithreaded case you need g_thread_init() anyway. so you're best off with calling g_thread_init() right before g_type_init(). -- Gustavo J. A. M. Carneiro [EMAIL PROTECTED] [EMAIL PROTECTED] The universe is always one step beyond logic. --- ciaoTJ ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: bugs regarding late g_thread_init() calls
Some comments about this discussion, in more or less random order. * In the past, we've spent quite a bit of time making things work with late calls to g_thread_init() - allowing this usage has the big advantage that an application can use a library that uses threads internally without having to know about is. And that's really where threads are most useful in many cases: as internal implementation details of a library. But the way we've done it is never equivalent to a lazy call to g_thread_init() - that would require linking all apps to gthread and -lpthread, plus adding locking overhead internal to GLib. (I actually hadn't realized that late initialization worked, and was surprised a couple of years ago when Matthias pointed it out to me in the context of a patch to fix up a place which didn't work. I checked through the code and couldn't find any places that weren't OK, though I may have missed a few or we may have regressed. But if GSlice can be fixed, I think we could easily allow late initialization.) * Behdad's worry about another thread calling g_thread_init() while Pango is in the middle of an operation isn't an issue, because everybody (I think) agrees that g_thread_init() has to be called from the *main* thread, before you start threaded operation. * It does appear that we are pulling in pthread in any case for a standard GTK+ application these days, so perhaps it would be worth at least considering whether we wanted to make that a hard dependency; considerations: - What simplifications could we achieve with such a hard dependency? - The only use for libgthread is to avoid a hard pthread dependency; if we added such a dependency, would it make sense to make libgthread an empty dummy library? (it can't be quite empty on windows, since g_thread_init() has to stay in the same DLL) - Could g_thread_init() be removed entirely, by making the different subsystems lazily initialize themselves? What's the performance impact of the necessary GOnce usage for this? - What is the performance degradation when you link to -pthread? When you initialize GLib threading? But going in those directions is a fairly major project. * I really wouldn't worry about calls to g_thread_init() with anything other than the NULL as the parameter. Though we never formally deprecated the usage, there is a fairly warning about it in the docs: You should only call g_thread_init() with a non-%NULL parameter if you really know what you are doing. If we need to remove the functionality of that parameter, we can always claim that the callers didn't know what they were doing. :-) - Owen ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: bugs regarding late g_thread_init() calls
* It does appear that we are pulling in pthread in any case for a standard GTK+ application these days, so perhaps it would be worth at least considering whether we wanted to make that a hard dependency; considerations: - What simplifications could we achieve with such a hard dependency? - The only use for libgthread is to avoid a hard pthread dependency; if we added such a dependency, would it make sense to make libgthread an empty dummy library? (it can't be quite empty on windows, since g_thread_init() has to stay in the same DLL) - Could g_thread_init() be removed entirely, by making the different subsystems lazily initialize themselves? What's the performance impact of the necessary GOnce usage for this? - What is the performance degradation when you link to -pthread? On many unix systems, linking with -lpthread will replace many libc calls (e.g. read, write, ...) by thread-safe versions, which are heavier (extra use of locks). Arno ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Adding support for OS X icons in GDK-Pixbuf
Hi Lyonel, What do I have to make GTK+ applications recognise icns files? WMF and SVG support seem to suggest developing a GDK-Pixbuf loader. I co-authored both of those loaders, so hopefully I can help you. I've tried to create a shared lib modeled after io-wmf.so (in libwmf) but without much success so far: when I run gdk-pixbuf-query-loaders I get: When you installed the loader, did you run gdk-pixbuf-queryloaders and overwrite the existing gtk-2.0/gdk-pixbuf.loaders file? Here's an example from librsvg: http://cvs.gnome.org/viewcvs/librsvg/gdk-pixbuf-loader/Makefile.am?rev=1.13view=markup Please follow-up privately off-list, as this is probably a more appropriate question for the gtk-app-devel forum. Thanks, Dom -- Counting bodies like sheep to the rhythm of the war drums. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Fosdem 2007 - Call for talks
Hi everyone, and happy new year ;) This year again we'll have a GNOME devroom at FOSDEM, and we need *you* to give a talk in that room to make it rock even more than the one we had in 2006. Devroom talks are 30/35 minute long talks presenting one aspect of the GNOME community you care about. This can be a technical talk about a library you're hacking on, but you can also give a talk about how to market GNOME at big events, or about how to get involved in the translation project, ... In short, you can talk about whatever you want as long as it's about GNOME! Like last year, you'll find all the information you want about our devroom on http://live.gnome.org/Brussels2007 , and you can add yourself to one of the slots if you are planninng to give a talk (alternatively, you can also mail me if you want to give a talk). And if you are coming, please let us now! http://live.gnome.org/Brussels2007#attendees One difference with last year is that we might have half a day of shared conferences with the KDE people about interoperability/common technology/issues between both environments. I said might because I'm not sure at all yet that we'll set that up, but I mention it so that people aren't surprised if we have to modify the schedule on the wiki because of that. And if you want to give a talk on that specific subject, don't hesitate to add yourself *now*! :) Hope to see you all in Brussels, Christophe PS: if you think I should have mailed more mailing lists, or if this mail is inappropriate on some of the lists I cc'ed, feel free to tell me :) signature.asc Description: Ceci est une partie de message numériquement signée ___ gnome-hackers mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/gnome-hackers ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
