Re: GTK+ Windows dependancies
I would recommend *not* installing packages from other sources in your MinGW folder. I did not know. It is better to install them in the directory of Code:Blocks (my IDE)? No, that would also be mixing stuff from separate sources. I would install them in a totally separate folder. --tml ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: buildable_set_name
amol wrote: Hi, When we do gtk_buildable_set/get_name for any object created through GtkBuilder, GtkBuildable does g_object_set/get_data to return the corresponding name of object if its set/get_name are not overridden. But GtkWidget overrides set/get_name of buildable interface and does gtk_widget_set/get_name. I may create GtkWidget through GtkBuilder and after that i may set widget name accordingly (to use different styles in different cases). But when i do gtk_buildable_get_name it returns me new name which was set through widget_set_name and not through buildable_set_name. That is correct. There's only one name for the object, it can be set and accessed either by using the widget or the buildable accessors. No one except GtkAction and GtkActionGroup seems to be using buildable set/get_name. My doubt is - What is the intention for GtkWidget to override set/get functions of GtkBuildable interface. The intention of introduction the set/get_name is to be able to name the widget so you can access the ids used in the ui designer in runtime. I've used the names myself for ui testing frameworks (based upon gazpacho and libglade though), and I am sure there are other uses for them. Can we get rid of it w/o affecting any Gtk applications. It's a nice feature which are useful in some circumstances. I'd really like to keep it. Gtk+ don't have any idea about the custom Id's specified in ui file while object creation. What is achieved doing by gtk_widget_set_name with Id specified in ui file.(gtkrc and ui Creator must be always in sync for themes to be work correctly ) I am planning to get rid of overriding set/get_name of buildable in GtkWidget. Does it will have any adverse effect? I don't quite understand how this is an issue. Yes, objects created by a UI designer will be named. Yes, you will have to keep your gtkrc files in sync with these names. The problem you are having is that you have a theme depending on the name property of a widget when it shouldn't. Use the class name instead, why is that not sufficient? Johan ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Does libX11 use shared memory between several clients?
On Jan 29, 2008 5:35 AM, Bin Chen [EMAIL PROTECTED] wrote: [...] I can't see any code to transfer modified display structure to the server, this API is invoked by a XIM server so obviously the register stuff need to be accessed by other process, is there any shared memory trick in libX11? Yes, but this is not one of those tricks I would think. When connecting to the X server, XOpenDisplay establishes a connection and returns a locally allocated Display structure to be used for all your api calls. All commands to the X server are sent and queued so to speak on the display. I dont know much about the guts of XIM but it looks like _XRegisterFilterByType doesnt need to tell the server anything... only needs to tell Xlib locally how to handle input when it comes from the X server. 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: GTK+ Windows dependancies
I looked the gimp install directory and I found this files : - bin/*.dll - etc/gtk-2.0/gdk-pixbuf.loaders - etc/gtk-2.0/gtk.immodules - etc/gtk-2.0/gtkrc - etc/pango/pango.aliases - etc/pango/pango.modules - lib/gtk-2.0/2.10.0/engines/* - lib/gtk-2.0/2.10.0/immodules/* - lib/gtk-2.0/2.10.0/loaders/* - lib/locale/* - share/themes/* The files are missing from the GTK+-2.12.6 binaries archive : - etc/gtk-2.0/gtkrc (optionnal) - lib/gtk-2.0/2.10.0/loaders/* (now - for the moment ? - include in dll) - lib/locale/* (move in share/) It's better ? -- Nicolas Joseph Responsable de la rubrique GTK+ de developpez.com http://nicolasj.developpez.com ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: What's wrong with the docs?
I feel the same way. I can't think of an example off of the top of my head, but I swear there have been things that the only way I figured them out was by reading the python documentation and sort of guessing at the C API. Yes I look at the reference docs on gtk.org and gnome.org. Date: Wed, 30 Jan 2008 17:27:33 -0200 From: John Coppens [EMAIL PROTECTED] Subject: What's wrong with the docs? To: gtk-app-devel-list@gnome.org Message-ID: [EMAIL PROTECTED] Content-Type: text/plain; charset=US-ASCII Hello all... There must be something terribly wrong somewhere, when I try to find documentation on operation with GTK+ or GDK elements, I always seem to get _much_ more documentation from the Python/Perl libraries than from the actual C interface. I'm sure others noticed the same trend. So, why is this? - Are the original (C/C++) docs really so scarse they don't appear at the top of of the list? or... - Is something in the google algorithms preferencial to anything but C? - Are those docs maybe declared unaccessible by the spider engines? (by robots.txt or so) - Or are those alternative languages just much more popular than C? Which makes this question pop up: Wouldn't it be interesting/practical to have _common_ documentation. Say, GtkWidget is used in Python like this, in C like this, etc.? I could even serve as an educational tool to compare languages. Just idle thoughts... John ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: GTK+ Windows dependancies
On Thu, 31 Jan 2008, Tor Lillqvist wrote: In particular, the loaders directory is now gone due to Tor's decision to build a monolithic gdkpixbuf library for GTK on Windows, with all the loaders pre-embedded. Personally, I wish he'd reconsider that. OK, you are the second person to oppose this change (if I recall correctly), so from the next build I will return to not including the loaders in the gdk-pixbuf DLL. Thank you. It's not a big deal, but I'm a thrifty Scot, and it pains me to think of people having to install jpeg and tiff libraries that'll just take up disk space and never get used. (Although that's small beer compared to be volume of useless cr*p installed on most Windows machines.) Allin Cottrell ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
