GTK+ 2.11.3 released
GTK+ 2.11.3 is now available for download at: ftp://ftp.gtk.org/pub/gtk/2.11/ http://ftp.gnome.org/pub/GNOME/sources/gtk+/2.11/ gtk+-2.11.3.tar.bz2 md5sum: 49c53959df501a48c2cba834d1993508 gtk+-2.11.3.tar.gzmd5sum: 84b6c30467cc089ef1dcffe1d1f51906 This is the fourth development release leading up to GTK+ 2.12. Notes: * This is unstable development release. While it has had a bit of testing, there are certainly plenty of bugs remaining to be found. This release should not be used in production. * Installing this version will overwrite your existing copy of GTK+ 2.10. If you have problems, you'll need to reinstall GTK+ 2.10. * GTK+ 2.12 will be source and binary compatible with the GTK+ 2.10 series; however, the new API additions are not yet finalized, so there may be incompatibilities between this release and the final 2.12 release. In particular, the following API additions are still being considered for inclusion: 166995 Need gtk_radio_button_get_group_active_index() 318807 Offscreen windows and window redirection * Bugs should be reported to http://bugzilla.gnome.org. What is GTK+ GTK+ is a multi-platform toolkit for creating graphical user interfaces. Offering a complete set of widgets, GTK+ is suitable for projects ranging from small one-off tools to complete application suites. GTK+ has been designed from the ground up to support a range of languages, not only C/C++. Using GTK+ from languages such as Perl and Python (especially in combination with the Glade GUI builder) provides an effective method of rapid application development. GTK+ is free software and part of the GNU Project. However, the licensing terms for GTK+, the GNU LGPL, allow it to be used by all developers, including those developing proprietary software, without any license fees or royalties. Where to get more information about GTK+ Information about GTK+ including links to documentation can be found at: http://www.gtk.org/ An installation guide for GTK+ is found at: http://developer.gnome.org/doc/API/2.0/gtk/gtk-building.html Common questions: http://developer.gnome.org/doc/API/2.0/gtk/gtk-question-index.html http://www.gtk.org/faq/ Contributing GTK+ is a large project and relies on voluntary contributions. We are actively searching for new contributors in various areas and invite everyone to help project development. If you are willing to participate, please subscribe to the project mailing lists to offer your help and read over our list of vacant project tasks: http://live.gnome.org/GtkTasks Overview of Changes from GTK+ 2.11.2 to 2.11.3 == * GtkBuilder: GTK+ supports constructing user interfaces from XML descriptions now, similar to libglade. * The new tooltip code now has convenience api to set text tooltips: gtk_widget_set_tooltip_text(), gtk_widget_set_tooltip_markup() * GtkTextView, GtkEntry: - gtk_widget_modify_cursor() is a new function in the gtk_widget_modify family to override the style-provided cursor colors - Use a block cursor in overwrite mode * GtkFileChooser: - Use xdg-user-dirs to find the Desktop directory - gtk_file_system_create() is now public API * GtkMenu: - GtkMenuItem gained a submenu property - GtkMenuShell obtained a move-selected signal * OS X port: - Many improvements * Bugs fixed: 445691 Crash when spawning a new process 447163 Implicit pointer conversion gdk_font_ref() 420249 deadlock on print operation 440918 out-of-bound access on loading pnm 142494 treeview coordinate systems need documentation/auditing 343012 RC parser rejects lower-case identifiers. 350460 Popup windows (esp. menus) misbehave wrt focus 410815 Icon view gets confused when scaling down the pixbuf column 435471 small GtkComboBox cleanup 435840 GTK_WIDGET_SAVED_STATE inconsistency 442617 gdk_spawn overrides envp, breaking child setup funcs whic... 443913 When .recently-used.xbel is empty, recently-used uses %10... 444097 Cannot compile gtksearchenginesimple.c 444310 update_buttons_state on a bare assistant causes gtk+ to c... 444734 Compact file-chooser folder selection not working with gt... 444786 Error loading 'gtk-select-color' in Stock icons and Items 445054 GtkScrolledWindow::scrollbars-within-bevel is drawing wrong 445284 Custom (pixbuf etc.) cursor reverts to default cursor on ... 445539 Unititialized var in gtkrc.c trunk 445855 gtk_scale_button_new() uses private API. 446138 Tiny doc update for gdk_window_get_pointer() 446513 gtknotebook.h: create_window is wrong declaration 446616 glib requirement insufficient 447065 GtkMenuItem: add "submenu" property and some cleanup 426192 Symbolic colors are not working under "engine" sections o... 446107 tiff load dialogue has unreadable text 447396 Typo in documentation of gtk_widget_modify_cursor 79585 API to change cursor color 80
Re: The new tooltips API in 5 minutes [Was: Re: Whats coming in GTK+ 2.12, continued]
On Sat, 16 Jun 2007, Damon Chaplin wrote: > On Fri, 2007-06-15 at 11:25 +0200, Tim Janik wrote: >> please read Kris' description again. >> if you set ::tooltip-markup, ::has-tooltip is set automatically, and >> you don't need to worry about it. this is *not* the case if you connect to >> ::query-tooltip and possibly return TRUE. there is no way for gtk to tell >> this kind of setup and querying every widget would be excessively >> expensive, so we need the user to set ::has-tooltip here. > > We discussed it before. I said that query-tooltip should really only be > emitted just before a tooltip is shown, and you agreed. If that is done > the efficiency problem disappears, doesn't it? i'm not sure it does (on every machine). worst case, there would be widget_tree_height signal emissions for each pixel the mouse pointer moves or at least 20 times a second if we reduce querying to 50ms intervalls. > Damon --- ciaoTJ ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GtkBuilder Public API - Last call
On Thu, 2007-06-14 at 11:55 -0300, Johan Dahlin wrote: > Damon Chaplin wrote: > > On Wed, 2007-06-13 at 11:49 -0400, Tristan Van Berkom wrote: > > > >> Anyway, my point here is not wrt code that exists already in Gtk+, > >> I am of the opinion that GContainer iface is "missing", and that > >> objects in general use other objects in general, and in that process > >> of ownership, packing properties are an essential thing. > > > > Yes, generic support for packing properties will be needed for any > > future GtkCanvas widget as well (for packing items inside each other). > > Not really, GtkCanvas can just define it's own custom tags where it controls > the relation between the canvas and its items. Though if we added a generic GContainer interface, we wouldn't need to mess around with custom tags. For GooCanvas I've already had to cut & paste a bunch of GtkContainer code to get packing properties working for canvas items. I've also had to add a hack to gtk-doc to document the packing properties. With a GContainer interface things would be a lot simpler. Damon ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: The new tooltips API in 5 minutes [Was: Re: Whats coming in GTK+ 2.12, continued]
On Fri, 2007-06-15 at 11:25 +0200, Tim Janik wrote: > On Thu, 14 Jun 2007, Damon Chaplin wrote: > > > On Tue, 2007-06-12 at 13:59 +0200, Kristian Rietveld wrote: > > > >> 2. When you need a tooltip with a little more fancy contents, like > >> adding an image, or you want the tooltip to have different contents > >> per GtkTreeView row or cell, you will have to do a little more work: > >> > >> - Set the has-tooltip property on GtkWidget to TRUE, this will > >>make GTK+ monitor the widget for motion and related events > >>which are needed to determine when and where to show a tooltip. > > > > I still think this is unnecessary and clutters the API - it can be > > determined automatically from the other settings. Can't we get rid of > > it? > > please read Kris' description again. > if you set ::tooltip-markup, ::has-tooltip is set automatically, and > you don't need to worry about it. this is *not* the case if you connect to > ::query-tooltip and possibly return TRUE. there is no way for gtk to tell > this kind of setup and querying every widget would be excessively > expensive, so we need the user to set ::has-tooltip here. We discussed it before. I said that query-tooltip should really only be emitted just before a tooltip is shown, and you agreed. If that is done the efficiency problem disappears, doesn't it? Is "has-tooltip" needed for anything besides the efficiency issue? (e.g. a11y or something?) Damon ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: The new tooltips API in 5 minutes [Was: Re: Whats coming in GTK+ 2.12, continued]
On Tue, 2007-06-12 at 13:59 +0200, Kristian Rietveld wrote: > 1. If everything you need is a tooltip displaying a simple text string, > with or without Pango markup, the only thing you have to do is > just setting the "tooltip-markup" property. just a small add-on, fresh from the commit factory: the tooltip-markup property now has a sister called tooltip-text, which will set the tooltip as plain text, escaping the eventual markup entities; if you're setting tooltips on widgets from external data sources (file names, desktop entries, whatever) you won't have to pass through g_markup_escape_text() first. both the tooltip-markup and the tooltip-text properties also have accessors. finally, along with gtk_tooltip_set_markup() mentioned below, now there's a gtk_tooltip_set_text() as well. kudos to kris for implementing this rocking API for tooltips: it was sorely needed and he did a wonderful job. if you're coming to GUADEC this year, be sure to buy kris a pint! ciao, Emmanuele. -- Emmanuele Bassi, http://www.gnome.org/~ebassi ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GtkBuilder Public API - Last call
Johan Dahlin wrote:
> Morten Welinder wrote:
>>> user_type and user_data which I proposed doesn't make too much sense,
>>> it's
>>> also difficult to support since you can't (AFAICT) use a GValue as
>>> user data.
>> It would be marginally useful for providing constant user data like...
>>
>> * Strings: "oink"
>> * Translated strings: _("Moo!")
>> * Integers: GINT_TO_POINTER(12)
>>
>> Having integer arguments saves you a function if you have, for example,
>> "Up"
>> and "Down" buttons that are handled almost identically.
>
> Right, useful but not a blocker IMO.
>
> I'll open a bug to add support for this after landing the initial version of
> GtkBuilder.
Filed as;
http://bugzilla.gnome.org/show_bug.cgi?id=447972
Johan
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GtkBuilder Public API - Last call
Havoc Pennington wrote: > Hi, > > Johan Dahlin wrote: >> Havoc Pennington wrote: [...] > A possible convenience API could be to have a global singleton builder > or a hash of per-file builders and then something like: I reported this as; http://bugzilla.gnome.org/show_bug.cgi?id=447969 -- Johan Dahlin <[EMAIL PROTECTED]> Async Open Source ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GtkBuilder Public API - Last call
On Thu, 2007-06-14 at 11:55 -0300, Johan Dahlin wrote: > Damon Chaplin wrote: > > On Wed, 2007-06-13 at 11:49 -0400, Tristan Van Berkom wrote: > > > >> Anyway, my point here is not wrt code that exists already in Gtk+, > >> I am of the opinion that GContainer iface is "missing", and that > >> objects in general use other objects in general, and in that process > >> of ownership, packing properties are an essential thing. > > > > Yes, generic support for packing properties will be needed for any > > future GtkCanvas widget as well (for packing items inside each other). > > Not really, GtkCanvas can just define it's own custom tags where it controls > the relation between the canvas and its items. > > What Tristan wants is a way to override and introspect these properties. True, but given that argument you could also say the same for GObject properties, GObject could just as well define a custom parser for the "property" attribute. But - if GObjects handled properties in their own custom parser and a derived object wanted to execute custom code for a given property at load/"build" time - overriding the custom_start/end and code sharing with a parent object is next to impossible. Anyway, I think the important part is to recognize that we can easily add a child_set_property() vfunc to the buildable, deliver packing properties in convenient GValues to container objects and all that in the near future without api breakage. its alot more scary to think that GtkBuilder will be pushed back another release cycle just for its few imperfections. Cheers, -Tristan ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GtkBuilder Public API - Last call
On Thu, 2007-06-14 at 15:32 +0100, Damon Chaplin wrote: > > I think its quite important here to not repeat one of the > > the most obvious mistakes of glade/libglade, swapping the > > signal based on the fact that an "object" was specified > > is confusing - it also rules out the use case of specifying > > a signal that is not swapped & has an object user_data. > > Back in the GTK+ 1.x days I think gtk_signal_connect_object() used to > automatically swap the callback arguments. There wasn't any "swap" > option. > > So calling it "one of the most obvious mistakes" is a bit harsh! > I'm sorry Damon I wasn't aware of that history, I just remembered you being annoyed about this glitch on the ML one day so I assume we can agree that its confusing functionality, dont know why I assumed it was a mistake. Cheers, -Tristan ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GtkBuilder Public API - Last call
Tim Janik wrote: > On Wed, 13 Jun 2007, Johan Dahlin wrote: > >> Samuel Cormier-Iijima wrote: > >>> gint gtk_builder_enum_from_string(GType >>> type, >>> const char >>> *string); >>> >>> >>> Just curious, but why do you have gtk_builder_enum_from_string when >>> something >>> similar already exists in GObject as g_enum_get_value_by_nick/name? >> >> Since it accepts a nick, name or number, it's using >> g_enum_get_value_by_nick/name internally. > > sounds like a good candidate for a convenience function to be moved > down to libgobject. Filed as http://bugzilla.gnome.org/show_bug.cgi?id=447907 It'll probably makes sense to add a similar function for flags. -- Johan Dahlin <[EMAIL PROTECTED]> Async Open Source ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GtkBuilderConnectFunc and tag
Tim Janik wrote: [..] >> Would that be enough? > > why? what is the type specification good for if it's not an object? > and, didn't an earlier variant of your code match object="button" > to some "button" object from the builder file? so then, the straight > forward mapping of the GSignal API would be: > after="bool"// optional >swapped="bool"// optional >user_data="0x42" object="objectname" // optionally have either of > these but not both > /> > > i'd say anything other than > "after" indicating G_CONNECT_AFTER, > "swapped" indicating G_CONNECT_SWAPPED, > "object" indicating g_signal_connect_object, > would be misleading and likely confuse people > who also know the C API. > especially so, since g_object_connect() already establishes > a mapping between strings and AFTER/SWAPPED/connect_object, > which is exactly the one i listed above. I also realized that after trying to implement user_type/user_data and I agree that haveing after, swapped and object tags is a much better mapping to what you can do using signal connection mechanism. The only use case it doesn't cover is a way to send in a string or an integer (with GPOINTER_TO_INT), as Morten mentioned in this thread. Johan ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GtkBuilderConnectFunc and tag
On Fri, 15 Jun 2007, Johan Dahlin wrote: > Tim Janik wrote: > [..] >>> Would that be enough? >> >> why? what is the type specification good for if it's not an object? >> and, didn't an earlier variant of your code match object="button" >> to some "button" object from the builder file? so then, the straight >> forward mapping of the GSignal API would be: >> >after="bool"// optional >>swapped="bool"// optional >>user_data="0x42" object="objectname" // optionally have either of >> these but not both >> /> >> >> i'd say anything other than >> "after" indicating G_CONNECT_AFTER, >> "swapped" indicating G_CONNECT_SWAPPED, >> "object" indicating g_signal_connect_object, >> would be misleading and likely confuse people >> who also know the C API. >> especially so, since g_object_connect() already establishes >> a mapping between strings and AFTER/SWAPPED/connect_object, >> which is exactly the one i listed above. > > I also realized that after trying to implement user_type/user_data and I > agree that haveing after, swapped and object tags is a much better mapping > to what you can do using signal connection mechanism. > > The only use case it doesn't cover is a way to send in a string or an > integer (with GPOINTER_TO_INT), as Morten mentioned in this thread. yeah, you said you'd put this as a future bug though, so we can still make up our mind on that later. on a related note, we might want to have similar conveniences in the C API, e.g.: voidg_object_set_qdata_int(GObject*object, GQuark quark, gssize int_data); in your case, that'd map to "user_data_int". or alternatively: voidg_object_set_float_qdata (GObject*object, GQuark quark, float float_data); in your case, that'd map to "user_float_data". however, that can be a seperate enhancement bug and doesn't need to hold off builder inclusion right now. (for anyone who wants to discuss this, please *first* open a bug report and start a seperate email thread) > Johan --- ciaoTJ ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GtkBuilderConnectFunc and tag
On Wed, 13 Jun 2007, Johan Dahlin wrote: > Tristan Van Berkom wrote: > Let's do something a little cleaner and more flexible; > > typedef void (*GtkBuilderConnectFunc) (GtkBuilder *builder, > const gchar *handler_name, > GObject *object, > const gchar *signal_name, > const GValue *signal_user_data, > GConnectFlags flags, > gpointer user_data); > > and; > > user_type="type" user_data=""/> > > user_type would take a GType name, if it's derived from G_TYPE_OBJECT > user_data will be treated an object reference, similar to other > object properties. > > Would that be enough? why? what is the type specification good for if it's not an object? and, didn't an earlier variant of your code match object="button" to some "button" object from the builder file? so then, the straight forward mapping of the GSignal API would be: i'd say anything other than "after" indicating G_CONNECT_AFTER, "swapped" indicating G_CONNECT_SWAPPED, "object" indicating g_signal_connect_object, would be misleading and likely confuse people who also know the C API. especially so, since g_object_connect() already establishes a mapping between strings and AFTER/SWAPPED/connect_object, which is exactly the one i listed above. > Johan --- ciaoTJ ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Pango-warning
Am Donnerstag, den 14.06.2007, 22:22 -0700 schrieb Jeevan: > Hi, > Here I am trying to run a simple Gtk+ program, I am getting error as > follows: > Can you plz give me suggestion.. This list is for development of Gtk+ itself, the list for developments using Gtk+ is [EMAIL PROTECTED] > *8 > linux:~ # gcc base.c -o base `pkg-config --cflags --libs gtk+-2.0` > linux:~ # ./base > > (base:4262): Pango-WARNING **: No builtin or dynamically > loaded modules were found. Pango will not work correctly. > This probably means there was an error in the creation of: > '/usr/local/etc/pango/pango.modules' > You should create this file by running pango-querymodules. Doing what the message suggests and running pango-querymodules > /usr/local/etc/pango/pango.modules as described in the very fine manual of that program should help. 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
Re: Pango-warning
2007/6/15, Jeevan <[EMAIL PROTECTED]>: Hi, Here I am trying to run a simple Gtk+ program, I am getting error as follows: Can you plz give me suggestion.. This list its mean to be used by the Gtk+ development, and not for app development. The gtk general discussion list mihgt me more appropiate: http://mail.gnome.org/mailman/listinfo/gtk-list *8 linux:~ # gcc base.c -o base `pkg-config --cflags --libs gtk+-2.0` linux:~ # ./base (base:4262): Pango-WARNING **: No builtin or dynamically loaded modules were found. Pango will not work correctly. This probably means there was an error in the creation of: '/usr/local/etc/pango/pango.modules' You should create this file by running pango-querymodules. Maybe... you should create this file... perhaps running pango-querymodules? Don't you think? :) (base:4262): Pango-WARNING **: pango_shape called with bad font, expect ugly output Hello World ** Thank you very much., Thanks & Regards Jivan -- Un saludo, Alberto Ruiz ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Pango-warning
On Fri, 2007-06-15 at 01:22 -0400, Jeevan wrote: > Hi, > Here I am trying to run a simple Gtk+ program, I am getting error as > follows: > Can you plz give me suggestion.. First, helps if you attach the test program when you are asking for help. Next, gtk-devel-list is not the right list for such question. gtk-list and/or gtk-app-devel-list is. Last, the first warning is already telling you what your problem is. Read it. behdad > *8 > linux:~ # gcc base.c -o base `pkg-config --cflags --libs gtk+-2.0` > linux:~ # ./base > > (base:4262): Pango-WARNING **: No builtin or dynamically > loaded modules were found. Pango will not work correctly. > This probably means there was an error in the creation of: > '/usr/local/etc/pango/pango.modules' > You should create this file by running pango-querymodules. > > (base:4262): Pango-WARNING **: pango_shape called with bad font, expect ugly > output > > (base:4262): Pango-WARNING **: pango_font_get_glyph_extents called with null > font argument, expect ugly output > > (base:4262): Pango-CRITICAL **: pango_cairo_show_glyph_string: assertion > `PANGO_IS_CAIRO_FONT (font)' failed > > (base:4262): Pango-CRITICAL **: pango_cairo_show_glyph_string: assertion > `PANGO_IS_CAIRO_FONT (font)' failed > > (base:4262): Pango-CRITICAL **: pango_cairo_show_glyph_string: assertion > `PANGO_IS_CAIRO_FONT (font)' failed > > (base:4262): Pango-CRITICAL **: pango_cairo_show_glyph_string: assertion > `PANGO_IS_CAIRO_FONT (font)' failed > > (base:4262): Pango-CRITICAL **: pango_cairo_show_glyph_string: assertion > `PANGO_IS_CAIRO_FONT (font)' failed > > (base:4262): Pango-CRITICAL **: pango_cairo_show_glyph_string: assertion > `PANGO_IS_CAIRO_FONT (font)' failed > > (base:4262): Pango-CRITICAL **: pango_cairo_show_glyph_string: assertion > `PANGO_IS_CAIRO_FONT (font)' failed > > (base:4262): Pango-CRITICAL **: pango_cairo_show_glyph_string: assertion > `PANGO_IS_CAIRO_FONT (font)' failed > > (base:4262): Pango-CRITICAL **: pango_cairo_show_glyph_string: assertion > `PANGO_IS_CAIRO_FONT (font)' failed > Hello World > ** > > > Thank you very much., > > > Thanks & Regards > Jivan -- behdad http://behdad.org/ "Those who would give up Essential Liberty to purchase a little Temporary Safety, deserve neither Liberty nor Safety." -- Benjamin Franklin, 1759 ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Pango-warning
Hi, Here I am trying to run a simple Gtk+ program, I am getting error as follows: Can you plz give me suggestion.. *8 linux:~ # gcc base.c -o base `pkg-config --cflags --libs gtk+-2.0` linux:~ # ./base (base:4262): Pango-WARNING **: No builtin or dynamically loaded modules were found. Pango will not work correctly. This probably means there was an error in the creation of: '/usr/local/etc/pango/pango.modules' You should create this file by running pango-querymodules. (base:4262): Pango-WARNING **: pango_shape called with bad font, expect ugly output (base:4262): Pango-WARNING **: pango_font_get_glyph_extents called with null font argument, expect ugly output (base:4262): Pango-CRITICAL **: pango_cairo_show_glyph_string: assertion `PANGO_IS_CAIRO_FONT (font)' failed (base:4262): Pango-CRITICAL **: pango_cairo_show_glyph_string: assertion `PANGO_IS_CAIRO_FONT (font)' failed (base:4262): Pango-CRITICAL **: pango_cairo_show_glyph_string: assertion `PANGO_IS_CAIRO_FONT (font)' failed (base:4262): Pango-CRITICAL **: pango_cairo_show_glyph_string: assertion `PANGO_IS_CAIRO_FONT (font)' failed (base:4262): Pango-CRITICAL **: pango_cairo_show_glyph_string: assertion `PANGO_IS_CAIRO_FONT (font)' failed (base:4262): Pango-CRITICAL **: pango_cairo_show_glyph_string: assertion `PANGO_IS_CAIRO_FONT (font)' failed (base:4262): Pango-CRITICAL **: pango_cairo_show_glyph_string: assertion `PANGO_IS_CAIRO_FONT (font)' failed (base:4262): Pango-CRITICAL **: pango_cairo_show_glyph_string: assertion `PANGO_IS_CAIRO_FONT (font)' failed (base:4262): Pango-CRITICAL **: pango_cairo_show_glyph_string: assertion `PANGO_IS_CAIRO_FONT (font)' failed Hello World ** Thank you very much., Thanks & Regards Jivan -- View this message in context: http://www.nabble.com/Pango-warning-tf3925845.html#a11133383 Sent from the Gtk+ - Dev - General mailing list archive at Nabble.com. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GtkBuilder Public API - Last call
On Wed, 13 Jun 2007, Johan Dahlin wrote: > Samuel Cormier-Iijima wrote: >> gint gtk_builder_enum_from_string(GType type, >> const char *string); >> >> >> Just curious, but why do you have gtk_builder_enum_from_string when >> something >> similar already exists in GObject as g_enum_get_value_by_nick/name? > > Since it accepts a nick, name or number, it's using > g_enum_get_value_by_nick/name internally. sounds like a good candidate for a convenience function to be moved down to libgobject. > Johan Dahlin <[EMAIL PROTECTED]> > --- ciaoTJ ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: The new tooltips API in 5 minutes [Was: Re: Whats coming in GTK+ 2.12, continued]
On Thu, 14 Jun 2007, BJörn Lindqvist wrote: On 6/12/07, Kristian Rietveld <[EMAIL PROTECTED]> wrote: On Sun, Jun 10, 2007 at 10:38:44AM +0200, Murray Cumming wrote: There's also a new GtkTooltip object. Could we have some more information about how this should be used and if it replaces any existing API, please? Sure ;) As Matthias pointed out in one of his other mails, GTK+ 2.12 has a brand-new API for doing tooltips, replacing the aging GtkTooltips object. There are several ways for showing tooltips using the new API, increasing in complexity as the complexity of the wished tooltip increases: A new API called "GtkTooltip" replaces an API called "GtkTooltips"? Seems like that could become very confusing.. especially when using two or more GtkTooltips. Couldn't you have came up with something a little more imaginative? :) no. widget names are not optimized to be imanginative, they are optimized to be descriptive. so users can build up a good understanding of gtk instead of a fancy useless picture of it. since these names are about one component replacing the other, you ideally only use GtkTooltips or GtkTooltip exclusively at any point in time in your code, so there is no long-term clash or confusion. if not, upgrade your code to GtkTooltip *now* ;) -- mvh Björn --- ciaoTJ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: The new tooltips API in 5 minutes [Was: Re: Whats coming in GTK+ 2.12, continued]
On Thu, 14 Jun 2007, Damon Chaplin wrote: > On Tue, 2007-06-12 at 13:59 +0200, Kristian Rietveld wrote: > >> 2. When you need a tooltip with a little more fancy contents, like >> adding an image, or you want the tooltip to have different contents >> per GtkTreeView row or cell, you will have to do a little more work: >> >> - Set the has-tooltip property on GtkWidget to TRUE, this will >> make GTK+ monitor the widget for motion and related events >> which are needed to determine when and where to show a tooltip. > > I still think this is unnecessary and clutters the API - it can be > determined automatically from the other settings. Can't we get rid of > it? please read Kris' description again. if you set ::tooltip-markup, ::has-tooltip is set automatically, and you don't need to worry about it. this is *not* the case if you connect to ::query-tooltip and possibly return TRUE. there is no way for gtk to tell this kind of setup and querying every widget would be excessively expensive, so we need the user to set ::has-tooltip here. > Damon --- ciaoTJ ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
