Re: Theme patriation
On Mon, Oct 27, 2008 at 10:46 AM, Rui Tiago Cação Matos [EMAIL PROTECTED] wrote: 2008/10/26 Thomas Thurman [EMAIL PROTECTED]: 1. The window border theme parsing and displaying code should live in a library. (It already does, but its ABI is allegedly private, though in practice Compiz binds against it anyway. For this we will need to make it public.) 2. When an app creates a GtkWindow, GTK will draw the borders as appropriate by calling this library. But why keep using metacity themes? GTK could handle the window frame like every other widget using the main GTK theme. I fail to see the usefulness of having 2 themes to style a window. If backwards compatibility is required then maybe a GTK module with access to that metacity library could be loaded into all apps. IMO decorating a window belongs in the WM, not all X applications use GTK as rendering toolkit... Rui ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list --Jacob ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Arguments in GObject-based object constructor
Lets say I've written an abstract class Foo (a class that is not
supposed to be instantiated), and a
class that inherits from Foo called Bar, which is instantiable. Foo
takes 2 constructor arguments/properties
x and y. Bar:s constructor takes the samt arguments. In order to
initialize some of Bar:s attributes,
it needs to know both x and y. In the bar_init() function I can't
get the x and y properties,
because they arent set yet, so where do I initialize the attributes?
Should I hook into the get/set property of
both x and y, and once both are set (check with some boolean
variables), I can initialize them in bar_set_property() ?
That way sounds a little too complicated so I think I'm missing something.
The GObject documentation states:
static void
maman_bar_init (GTypeInstance *instance,
gpointer g_class)
{
MamanBar *self = (MamanBar *)instance;
self-private = g_new0 (MamanBarPrivate, 1);
/* initialize all public and private members to reasonable default values. */
/* If you need specific consruction properties to complete initialization,
* delay initialization completion until the property is set.
*/
}
What does it mean by delay initialization completion until the property
is set ?
Regards Jacob Kroon
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Gtk icons caching
I've straced a few Gtk-applications, and noticed a behaviour I wanna inquery about. I am running Fedora Rawhide, which includes Gtk+ 2.6.4 as of 2005-04-06, and what is bothering me is the icon cache or whatever the thing that handles icon rendering. Using Firefox it takes about a second to open the menues the first time, and stracing seems to show that this is due to stat64():ing all of the current Gtk-themes icons. This seems to be a general behaviour for all Gtk-applications. Applications which do not render any icons never have to do the stat64()-thing it seems, and thus starts a hell of a lot faster on my system, which honestly is quite dated. So my question is, couldn't the stat64-thing be made application-independent, so that this is done only once, when the Gtk-library is first initiated by a running application, so that subsequent Gtk-applications wouldnt have to go through the same process? Now, I am not a Gtk-expert in any way, so I already now apologize for any incorrect statements in this mail, I can't even tell if this really is the bottleneck, I am just curious. Regards Jacob ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
