Re: GtkBuilder Public API - Last call
On 6/13/07, Yevgen Muntyan <[EMAIL PROTECTED]> wrote: > > > > Um, then gtk_widget_get/set_name is going to be deprecated? > > gtk_widget_set_name() sets widget->name member, and that structure > > member is used (in particular?) by themes, that's how it works. > > What does "name of GtkBuildable" mean? > > > > In any case, the question "Does GtkBuilder call > gtk_widget_set_name(widget, "name_from_xml_file")" still > stands. It can be important since it will break widgets which > set name in a constructor or before (some do, e.g. to modify > cursor color). And it can become actually important now, > since until glade-3 it was rather impossible to use fancy > non-stock widgets. Or, if other code relies on "widget > name" being name from xml, setting the name to modify > style will break that other code. > Yes, GtkBuilder calls gtk_widget_set_name. I don't see how that will break anything, though - GtkUIManager does the same, as does libglade. Widgets which set a name in a constructor are already semi-broken anyway. Widget names are supposed to be an application/user feature, not something thats used in the implementation of a widget. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
GTK+ 2.10.13 released
GTK+ 2.10.13 is now available for download at: ftp://ftp.gtk.org/pub/gtk/v2.10/ http://ftp.gnome.org/pub/GNOME/sources/gtk+/2.10/ gtk+-2.10.13.tar.bz2 md5sum: d0af87715f3b0f05bf38a3312a528012 gtk+-2.20.13.tar.gzmd5sum: 729abacb8cba288595022be1f2d1fd40 This is a bug fix release in the 2.10 series. 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.10.12 to 2.10.13 * The GtkFileChooserDialog sizing code has been refactored. * The DirectFB backend has seen various fixes. * Bugs fixed: 347883 do-overwrite-confirmation does nothing in 2.10 389603 GtkFileChooserWidget crashes when the window is too narrow 418047 GtkIconView sizing is very broken 420249 deadlock on print operation 437081 gdk_draw_pixbuf() accepts zero width or height and crashes 379213 gtkaboutdialog.h causes warnings with GCC and -Wshadow 420285 GtkFileChooserDialog resizes indefinetely in matchbox 424299 expand_folders=true shrinks dialog 424309 expand_folders=true makes dialog sticking out of screen 436721 Win32: gtk_window_resize does not redraw the child widget 437281 gtk_button_set_image destroyes the old image 437379 Please commit these patches in trunk and gtk-2-10 437879 gdk_draw_trapezoids fill wrong cairo path 438113 vertical separator requests wrong size 438261 Thai input does not work when NumLock/CapsLock is on 438750 gtk-cell-renderer-text doesn't wrap on font scale 439565 Crash in GtkIconView a11y code 440040 Reference counting in GtkPrintOperation goes awry 440511 xcursors.h: illegal initializing 440780 GtkAction set_short_label might be broken 441443 jpeg loader does not set error upon abortion 441863 Suboptimal submenu placement 444310 update_buttons_state on a bare assistant causes gtk+ to c... 445284 Custom (pixbuf etc.) cursor reverts to default cursor on ... 430746 Combobox might emit a signal during finalize 436269 GtkTreeView doesn't expand/collapse with Right/Left curso... 442326 Overview navigator traps mouse on wrong screen in dual mo... 445196 please backport cursor color patch to 2.10.x 435053 MS-Windows Theme top tabs rendered upside down for non-XP... 79585 API to change cursor color * Translation updates: Arabic (ar) Assamese (as) Brazilian Portugese (pt_BR) British English (en_GB) Bulgarian (bg) French (fr) Spanish (es) Swedish (sv) Thai (th) Welsh (cy) A list of all bugs fixed in this release can be found at: http://bugzilla.gnome.org/buglist.cgi?bug_id=430746,435053,436269,437081,437281,437879,436721,438113,438261,420285,424299,424309,437379,439565,440040,440780,440511,418047,442326,438750,347883,441863,389603,379213,444310,79585,445196,445284,420249,441443 Thanks to everybody who contributed to this release: Chris Wilson Christian Persch Yevgen Muntyan Johan Dahlin Mathias Hasselmann Kristian Rietveld Alex Graveley Tor Lillqvist Xan Lopez Chris Vine Pedro Villavicencio Carlos Garnacho Tomeu Vizoso Armin Burgmeier Loïc Minier Attilio Fiandrotti Daniel Atallah Cody Russell Dom Lachowicz Sven Neumann Jochen Baier Tommi Komulainen Michael Natterer Eddie C. Dost Behdad Esfahbod Benjamin Berg Theppitak Karoonboonyanan Matthias Clasen June 13, 2007 ___ 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
Yevgen Muntyan wrote: > Matthias Clasen wrote: > >> On 6/12/07, Yevgen Muntyan <[EMAIL PROTECTED]> wrote: >> >>> Sorry for not being clear, I meant how widget names are used in rc >>> files/strings. Gtk docs seem to imply that widget names have >>> other uses, perhaps there are some, don't know. >>> >>> and how are they related to widgets constructed by GtkBuilder? >>> It was my question actually. "#GtkWidget implements this to map >>> the buildable name to the widget name" - what does it mean? Does >>> GtkBuilder call gtk_widget_set_name(widget, "name_from_xml_file") >>> for constructed widgets? Or something else? >>> >> It means that widgets only have one name, which can be get/set by either >> the GtkWidget api or by the GtkBuildable api. >> > > Um, then gtk_widget_get/set_name is going to be deprecated? > gtk_widget_set_name() sets widget->name member, and that structure > member is used (in particular?) by themes, that's how it works. > What does "name of GtkBuildable" mean? > In any case, the question "Does GtkBuilder call gtk_widget_set_name(widget, "name_from_xml_file")" still stands. It can be important since it will break widgets which set name in a constructor or before (some do, e.g. to modify cursor color). And it can become actually important now, since until glade-3 it was rather impossible to use fancy non-stock widgets. Or, if other code relies on "widget name" being name from xml, setting the name to modify style will break that other code. Yevgen ___ 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
Hi, I found a typo. 2007/6/13, Johan Dahlin <[EMAIL PROTECTED]>: > gtkbuilder.h > > /** > * gtk_builder_add_from_file: > * @buildable: a #GtkBuilder @buildable -> @builder > * @filename: the name of the file to parse > * @error: return location for an error > * > * Parses a string containing a GtkBuilder UI > definition and > * merges it with the current contents of @builder. > * > * Returns: A positive value on success, 0 if an error occurred > * > * Since: 2.12 > **/ > guintgtk_builder_add_from_file (GtkBuilder *builder, > const gchar *filename, > GError **error); Thanks, -- kou ___ 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
Matthias Clasen wrote: > On 6/12/07, Yevgen Muntyan <[EMAIL PROTECTED]> wrote: >> >> Sorry for not being clear, I meant how widget names are used in rc >> files/strings. Gtk docs seem to imply that widget names have >> other uses, perhaps there are some, don't know. >> >> > and how are they related to widgets constructed >> > by GtkBuilder? >> >> It was my question actually. "#GtkWidget implements this to map >> the buildable name to the widget name" - what does it mean? Does >> GtkBuilder call gtk_widget_set_name(widget, "name_from_xml_file") >> for constructed widgets? Or something else? > > It means that widgets only have one name, which can be get/set by either > the GtkWidget api or by the GtkBuildable api. Um, then gtk_widget_get/set_name is going to be deprecated? gtk_widget_set_name() sets widget->name member, and that structure member is used (in particular?) by themes, that's how it works. What does "name of GtkBuildable" mean? Yevgen ___ 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 6/12/07, Yevgen Muntyan <[EMAIL PROTECTED]> wrote: > > Sorry for not being clear, I meant how widget names are used in rc > files/strings. Gtk docs seem to imply that widget names have > other uses, perhaps there are some, don't know. > > > and how are they related to widgets constructed > > by GtkBuilder? > > It was my question actually. "#GtkWidget implements this to map > the buildable name to the widget name" - what does it mean? Does > GtkBuilder call gtk_widget_set_name(widget, "name_from_xml_file") > for constructed widgets? Or something else? It means that widgets only have one name, which can be get/set by either the GtkWidget api or by the GtkBuildable api. ___ 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:
> Yevgen Muntyan wrote:
>> Johan Dahlin wrote:
>>> [snip]
>>>
>>
>>> /**
>>> * gtk_buildable_set_name:
>>> * @buildable: a #GtkBuildable
>>> * @name: name to set
>>> *
>>> * Sets the name of the buildable object, it's used to synchronize
>>> the name
>>> * if the object already has it's own concept of name.
>>> *
>>> * #GtkWidget implements this to map the buildable name to the
>>> widget name
>>> *
>>> * Since: 2.12
>>> **/
>>> void gtk_buildable_set_name (GtkBuildable
>>> *buildable,
>>> const gchar *name);
>>>
>>> /**
>>> * gtk_buildable_get_name:
>>> * @buildable: a #GtkBuildable
>>> *
>>> * Returns: the buildable name, the name which was set in
>>> * the GtkBuilder UI definition
>>> used to
>>> * construct the @buildable.
>>> *
>>> * #GtkWidget implements this to map the buildable name to the
>>> widget name
>>> *
>>> * Since: 2.12
>>> **/
>>> const gchar * gtk_buildable_get_name (GtkBuildable
>>> *buildable);
>>>
>>
>> The comments are not quite clear, it sounds like all widgets will
>> get gtk_widget_set_name(widget, "name_from_xml_file") called,
>> which would be wrong since we have themes, where widget name
>> means something special. Or what does it mean "Sets the name of
>> the buildable object, it's used to synchronize the name if the object
>> already has it's own concept of name." ("concept of name" part).
> I can't quite understand your comment, how are widget names
> special to themes,
Sorry for not being clear, I meant how widget names are used in rc
files/strings. Gtk docs seem to imply that widget names have
other uses, perhaps there are some, don't know.
> and how are they related to widgets constructed
> by GtkBuilder?
It was my question actually. "#GtkWidget implements this to map
the buildable name to the widget name" - what does it mean? Does
GtkBuilder call gtk_widget_set_name(widget, "name_from_xml_file")
for constructed widgets? Or something else?
Yevgen
___
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
Yevgen Muntyan wrote:
> Johan Dahlin wrote:
>> [snip]
>>
>
>> /**
>> * gtk_buildable_set_name:
>> * @buildable: a #GtkBuildable
>> * @name: name to set
>> *
>> * Sets the name of the buildable object, it's used to synchronize
>> the name
>> * if the object already has it's own concept of name.
>> *
>> * #GtkWidget implements this to map the buildable name to the widget
>> name
>> *
>> * Since: 2.12
>> **/
>> void gtk_buildable_set_name (GtkBuildable
>> *buildable,
>> const gchar *name);
>>
>> /**
>> * gtk_buildable_get_name:
>> * @buildable: a #GtkBuildable
>> *
>> * Returns: the buildable name, the name which was set in
>> * the GtkBuilder UI definition
>> used to
>> * construct the @buildable.
>> *
>> * #GtkWidget implements this to map the buildable name to the widget
>> name
>> *
>> * Since: 2.12
>> **/
>> const gchar * gtk_buildable_get_name (GtkBuildable
>> *buildable);
>>
>
> The comments are not quite clear, it sounds like all widgets will
> get gtk_widget_set_name(widget, "name_from_xml_file") called,
> which would be wrong since we have themes, where widget name
> means something special. Or what does it mean "Sets the name of
> the buildable object, it's used to synchronize the name if the object
> already has it's own concept of name." ("concept of name" part).
I can't quite understand your comment, how are widget names
special to themes, and how are they related to widgets constructed
by GtkBuilder?
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
On 6/12/07, Steve Frécinaux <[EMAIL PROTECTED]> wrote: > On Tue, 2007-06-12 at 19:38 -0300, Johan Dahlin wrote: > > > > So what about some "GtkBuiltDialog" object class which would do that > > > automatically, while taking care of the dialog properties, and so being > > > able to inherit from it to ease the creation of such dialogs ? > > [..] > > > Do you like the idea ? > > > > Are you suggesting that this should be included in Gtk+ on top of > > GtkBuilder? > > Yes that's the idea, if the use-case is common enough and considered as > a "good practice". > > At least doing such a thing should be easy by allowing to map an object > properties to an object in the glade file, like: > > gtk_builder_update_object_properties (widget, "widget-name"); > > then it would just be a matter of getting the first child of > "widget-name" and then updating its properties. Also, maybe an helper > function to do that would be sufficient instead of a full-blown class, > so that it can just be called in my_dialog_init to add the child widget > and update its properties according to what's specified in the glade > file. > > Sorry if I'm not clear enough. > Totally unclear to me what this update_object_properties is supposed to do. Anyway, I'd appreciate if people could try not to derail this thread into "it would be great if it also did this and this and..." The focus here should be to review the existing api proposal, not make new ones. Thanks, Matthias ___ 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
Steve Frécinaux wrote: > On Tue, 2007-06-12 at 19:38 -0300, Johan Dahlin wrote: > > >>> So what about some "GtkBuiltDialog" object class which would do that >>> automatically, while taking care of the dialog properties, and so being >>> able to inherit from it to ease the creation of such dialogs ? >>> >> [..] >> >>> Do you like the idea ? >>> >> Are you suggesting that this should be included in Gtk+ on top of GtkBuilder? >> > > Yes that's the idea, if the use-case is common enough and considered as > a "good practice". > I have such a thing too: gboolean moo_glade_xml_fill_widget (MooGladeXML*xml, GtkWidget *target, const char *buffer, int size, const char *target_name, GError**error); It does the same thing as if constructed the widget as usual, except it doesn't actually create the widget instance. It's a totally good thing. Why only dialogs though, and what's the point in having a special class (sometimes you need to inherit from something and oops, single inheritance only)? Best regards, Yevgen ___ 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:
> [snip]
>
> /**
> * gtk_buildable_set_name:
> * @buildable: a #GtkBuildable
> * @name: name to set
> *
> * Sets the name of the buildable object, it's used to synchronize the name
> * if the object already has it's own concept of name.
> *
> * #GtkWidget implements this to map the buildable name to the widget name
> *
> * Since: 2.12
> **/
> void gtk_buildable_set_name (GtkBuildable*buildable,
> const gchar *name);
>
> /**
> * gtk_buildable_get_name:
> * @buildable: a #GtkBuildable
> *
> * Returns: the buildable name, the name which was set in
> * the GtkBuilder UI definition used to
> * construct the @buildable.
> *
> * #GtkWidget implements this to map the buildable name to the widget name
> *
> * Since: 2.12
> **/
> const gchar * gtk_buildable_get_name (GtkBuildable*buildable);
>
The comments are not quite clear, it sounds like all widgets will
get gtk_widget_set_name(widget, "name_from_xml_file") called,
which would be wrong since we have themes, where widget name
means something special. Or what does it mean "Sets the name of
the buildable object, it's used to synchronize the name if the object
already has it's own concept of name." ("concept of name" part).
Best regards,
Yevgen
___
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, 2007-06-13 at 00:46 +0200, Steve Frécinaux wrote:
> Also, maybe an helper
> function to do that would be sufficient instead of a full-blown class,
> so that it can just be called in my_dialog_init to add the child widget
> and update its properties according to what's specified in the glade
> file.
Let me explain a bit more:
With such a function:
void
gtk_builder_build_object (GObject *object, const gchar *file,
const gchar *name)
{
GtkBuilder *builder;
GObject *child;
g_return_if_fail (GTK_IS_CONTAINER (object) &&
);
buider = gtk_builder_new ();
gtk_builder_add_from_file (builder, file);
child = gtk_builder_get_object (builder, );
g_return_if_fail (child != NULL);
gtk_container_add (GTK_CONTAINER (object), child);
gtk_builder_update_object_properties (builder, object, name);
}
it would probably be as simple as overwriting the constructor of the
custom container type, this way:
static void
my_dialog_constructor (GObject *object, ...)
{
G_OBJECT_CLASS (parent_class)->construct (object, ...);
gtk_builder_build_object (object, "my-dialog");
/* connect signals here */
}
the default destroy handler would take care of throwing away the built
objects.
This kind of API would look nice and simple, wouldn't it ?
___
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 Tue, 2007-06-12 at 19:38 -0300, Johan Dahlin wrote: > > So what about some "GtkBuiltDialog" object class which would do that > > automatically, while taking care of the dialog properties, and so being > > able to inherit from it to ease the creation of such dialogs ? > [..] > > Do you like the idea ? > > Are you suggesting that this should be included in Gtk+ on top of GtkBuilder? Yes that's the idea, if the use-case is common enough and considered as a "good practice". At least doing such a thing should be easy by allowing to map an object properties to an object in the glade file, like: gtk_builder_update_object_properties (widget, "widget-name"); then it would just be a matter of getting the first child of "widget-name" and then updating its properties. Also, maybe an helper function to do that would be sufficient instead of a full-blown class, so that it can just be called in my_dialog_init to add the child widget and update its properties according to what's specified in the glade file. Sorry if I'm not clear enough. -- Steve Frécinaux http://tw.apinc.org ___ 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
Steve Frécinaux wrote: > On Tue, 2007-06-12 at 18:26 -0300, Johan Dahlin wrote: >> Hi, >> >> During the Gtk+ developer meeting today it was decided that there will be a >> final GtkBuilder discussion before it gets committed to trunk. >> The current plan is that there will be a new developer release in the end of >> the week, most likely on friday and that GtkBuilder is going to be included >> in that release. > > Hello, > > We have a (I guess fairly common) use case in gedit and I'd like to know > whether it will be easier to deal with it using gtkbuilder than it was > with libglade. It will be the same, the APIs are pretty much compatible, functionality wise. > Much of our internal structure is based around composite widget, > especially when it comes to dialog windows. So what we tend to do is > creating the window in glade, and getting the widget the dialog contains > in the C file to add it manually to our dialog subclass instance. This > works ok but with some ugly code and has a few drawback because dialog > options can't be specified in the glade file. > > So what about some "GtkBuiltDialog" object class which would do that > automatically, while taking care of the dialog properties, and so being > able to inherit from it to ease the creation of such dialogs ? [..] > Do you like the idea ? Are you suggesting that this should be included in Gtk+ on top of GtkBuilder? -- 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
Philip Withnall wrote: > Warning! Spelling nazism follows... > > Is the misspelling of GTK_BUILDER_ERROR_MISSING_ATTRIBUTE in > GtkBuilderError below a transcription error? Oops did not catch that. auto-completion can be dangerous. > There're also spelling errors in the documentation for: > GtkBuilderConnectFunc: s/intented/intended/ and s/non NULL/non-%NULL/ > gtk_builder_connect_signals_full: s/interpeted/interpreted/ > gtk_buildable_set_property: s/neeeded/needed/ > gtk_buildable_construct_child: s/outsideof/outside of/ Thanks, I'll fix this. -- 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 Tue, 2007-06-12 at 18:26 -0300, Johan Dahlin wrote:
> Hi,
>
> During the Gtk+ developer meeting today it was decided that there will be a
> final GtkBuilder discussion before it gets committed to trunk.
> The current plan is that there will be a new developer release in the end of
> the week, most likely on friday and that GtkBuilder is going to be included
> in that release.
Hello,
We have a (I guess fairly common) use case in gedit and I'd like to know
whether it will be easier to deal with it using gtkbuilder than it was
with libglade.
Much of our internal structure is based around composite widget,
especially when it comes to dialog windows. So what we tend to do is
creating the window in glade, and getting the widget the dialog contains
in the C file to add it manually to our dialog subclass instance. This
works ok but with some ugly code and has a few drawback because dialog
options can't be specified in the glade file.
So what about some "GtkBuiltDialog" object class which would do that
automatically, while taking care of the dialog properties, and so being
able to inherit from it to ease the creation of such dialogs ?
What I'd like to do is something like the following (in python because
it's shorter than C, but the idea is the same). It looks cleaner to me
than what we currently have to do to have such a result.
class MyDialog(gtk.BuiltDialog):
def __init__(self):
gtk.BuiltDialog.__init__("dialogs.glade", "my-dialog")
self.connect_signals(self.__dict__)
def on_response(self, response):
do_something()
def on_reorder_button_click(self, button):
self.reorder()
...
Do you like the idea ?
--
Steve Frécinaux
http://tw.apinc.org
___
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:
>>> Is the Hello, World simplest use case as short and simple as it possibly
>>> could be? That's always a handy final litmus test for an API.
>>
>> How do you do an hello world in a ui toolkit?
>> Should it include signals? How many widgets?
>>
>
> For this purpose I think the idea is to emulate how a simple/typical app
> with no special needs would use the API.
> For the other stuff:
> - set_translation_domain - is for libraries mostly right?
>(if it's for apps it seems a gtk-wide or glib-wide way to
> do this could make sense, vs. gtkbuilder-specific)
Right, it defaults to gettext() which will probably be sufficient for
most users.
> - get_object - getting multiple objects seems like the normal case,
>so piling one object name it into the convenience function seems
>wrong
> A possible convenience API could be to have a global singleton builder
> or a hash of per-file builders and then something like:
>
> GtkWindow *window;
> GtkWindow *other_window;
>
> if (!gtk_builder_load_objects (DATADIR "/filename.glade",
> GTK_BUILDER_FLAGS_CONNECT_SIGNALS,
> "main-window", &window,
> "other-window", &other_window,
> NULL))
> g_error("My files are missing!");
>
> That could be pretty nice perhaps.
That's not so bad, I like that kind of API.
What's missing in this API is a way to telling the builder where to load
files (not part of the current API, but planned for 2.12), but that could be
solved by making the pixbuf (or other resources) path global to all
builders, which is probably what we want anyway.
--
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
Hi,
Johan Dahlin wrote:
> Havoc Pennington wrote:
>> Is the Hello, World simplest use case as short and simple as it possibly
>> could be? That's always a handy final litmus test for an API.
>
> How do you do an hello world in a ui toolkit?
> Should it include signals? How many widgets?
>
For this purpose I think the idea is to emulate how a simple/typical app
with no special needs would use the API.
> builder_new + add_from_file could be combined into one constructor,
> I've been thinking about that, which would make it easier to
> port applications using libglade which has such an api.
This makes sense to me, since pretty much every app would tend to have
the builder_new()/add_from_file() sequence, so why not save some typing
there. new_from_file() is also a common GTK convention. Adding multiple
files seems like a relatively unusual thing to do.
For the other stuff:
- set_translation_domain - is for libraries mostly right?
(if it's for apps it seems a gtk-wide or glib-wide way to
do this could make sense, vs. gtkbuilder-specific)
- connect_signals - for apps who will use this feature, they're
going to type this line every time... new_from_file_and_connect()?
kinda clunky. But it sucks to have a boilerplate line everyone
has to type.
- get_object - getting multiple objects seems like the normal case,
so piling one object name it into the convenience function seems
wrong
A possible convenience API could be to have a global singleton builder
or a hash of per-file builders and then something like:
GtkWindow *window;
GtkWindow *other_window;
if (!gtk_builder_load_objects (DATADIR "/filename.glade",
GTK_BUILDER_FLAGS_CONNECT_SIGNALS,
"main-window", &window,
"other-window", &other_window,
NULL))
g_error("My files are missing!");
That could be pretty nice perhaps.
Havoc
___
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
Warning! Spelling nazism follows...
Is the misspelling of GTK_BUILDER_ERROR_MISSING_ATTRIBUTE in
GtkBuilderError below a transcription error?
There're also spelling errors in the documentation for:
GtkBuilderConnectFunc: s/intented/intended/ and s/non NULL/non-%NULL/
gtk_builder_connect_signals_full: s/interpeted/interpreted/
gtk_buildable_set_property: s/neeeded/needed/
gtk_buildable_construct_child: s/outsideof/outside of/
I can't comment on the API though.
Philip
On Tue, 2007-06-12 at 18:26 -0300, Johan Dahlin wrote:
> Hi,
>
> During the Gtk+ developer meeting today it was decided that there will be a
> final GtkBuilder discussion before it gets committed to trunk.
> The current plan is that there will be a new developer release in the end of
> the week, most likely on friday and that GtkBuilder is going to be included
> in that release.
>
> I'd like this discussion to be focus on the Public API. I've included the
> two new public headers (gtkbuilder.h and gtkbuildable.h) with the API
> documentation embedded.
> Suggestions and questions about the documentation are also welcome, but
> remember that the documentation is still very much open for changes during
> the next couple of weeks, before the final release of 2.12.
>
> I've also attached a .glade file which demonstrates some of the new
> capabilities.
>
> gtkbuilder.h
>
>
> GtkBuilder is a replacement for the GladeXML found in the libglade library.
> It is responsible for parsing a GtkBuilder UI definition and constructing
> the object tree from that definition, usually a user interface.
>
> This is the API which applications are going to use.
>
> typedef enum
> {
> GTK_BUILDER_ERROR_INVALID_TYPE_FUNCTION,
> GTK_BUILDER_ERROR_UNHANDLED_TAG,
> GTK_BUILDER_ERROR_MISSING_ATTRIUTE,
> GTK_BUILDER_ERROR_INVALID_ATTRIBUTE,
> GTK_BUILDER_ERROR_INVALID_TAG
> } GtkBuilderError;
>
> struct _GtkBuilder
> {
> GObject parent;
>
> GtkBuilderPrivate *priv;
> };
>
> struct _GtkBuilderClass
> {
> GObjectClass parent_class;
>
> GType (* get_type_from_name) (GtkBuilder *builder,
> const char *typename);
>
> /* Padding for future expansion */
> void (*_gtk_reserved1) (void);
> void (*_gtk_reserved2) (void);
> void (*_gtk_reserved3) (void);
> void (*_gtk_reserved4) (void);
> };
>
> GTypegtk_builder_get_type(void) G_GNUC_CONST;
>
> /**
> * gtk_builder_new:
> *
> * Creates a new builder object.
> *
> * Return value: a new builder object.
> *
> * Since: 2.12
> **/
> GtkBuilder* gtk_builder_new (void);
>
> /**
> * gtk_builder_add_from_file:
> * @buildable: a #GtkBuilder
> * @filename: the name of the file to parse
> * @error: return location for an error
> *
> * Parses a string containing a GtkBuilder UI
> definition and
> * merges it with the current contents of @builder.
> *
> * Returns: A positive value on success, 0 if an error occurred
> *
> * Since: 2.12
> **/
> guintgtk_builder_add_from_file (GtkBuilder *builder,
> const gchar *filename,
> GError **error);
> /**
> * gtk_builder_add_from_string:
> * @builder: a #GtkBuilder
> * @buffer: the string to parse
> * @length: the length of @buffer (may be -1 if @buffer is nul-terminated)
> * @error: return location for an error
> *
> * Parses a file containing a GtkBuilder UI
> definition and
> * merges it with the current contents of @builder.
> *
> * Returns: A positive value on success, 0 if an error occurred
> *
> * Since: 2.12
> **/
> guintgtk_builder_add_from_string (GtkBuilder *builder,
> const gchar *buffer,
> gsize length,
> GError **error);
> /**
> * gtk_builder_get_object:
> * @builder: a #GtkBuilder
> * @name: name of object to get
> *
> * Return value: GObject or %NULL if it could not be found in the object tree.
> *
> * Since: 2.12
> **/
> GObject* gtk_builder_get_object (GtkBuilder *builder,
> const gchar *name);
> /**
> * gtk_builder_get_objects:
> * @builder: a #GtkBuilder
> *
> * Return value: a newly-allocated #GSList containing all the objects
> * constructed by GtkBuilder instance.
> *
> * Since: 2.12
> **/
> GSList* gtk_builder_get_objects (GtkBuilder *builder);
>
> /**
> * gtk_builder_set_translation_domain:
> * @builder: a #GtkBuilder
> * @domain: the translation domain or %NULL
> *
> * Sets the translation domain and uses dgettext() for translating the
> * property values marked as translatable from an interface description.
> * You can also pass in %NULL to this method to use gettext() instead of
> * dgettext().
> *
Re: GtkBuilder Public API - Last call
On 6/12/07, Johan Dahlin <[EMAIL PROTECTED]> wrote: > Not so nice, really. > And still missing connect_signals() and (maybe) set_translation_domain. > Yeah, so it would probably have to be GObject * gtk_builder_load_object_from_file (const gchar *filename, const gchar *name, const gchar *domain); > Do we really want this? No, I don't think so. ___ 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
Matthias Clasen wrote: > On 6/12/07, Johan Dahlin <[EMAIL PROTECTED]> wrote: >> Havoc Pennington wrote: >> > Is the Hello, World simplest use case as short and simple as it >> possibly >> > could be? That's always a handy final litmus test for an API. >> >> How do you do an hello world in a ui toolkit? >> Should it include signals? How many widgets? >> >> > From the header it looks like the simplest hello, world would have to >> > builder_new, add_from_file, connect_signals, get_object at minimum? >> > Maybe there's a convenience function or two that makes sense? >> >> builder_new + add_from_file could be combined into one constructor, >> I've been thinking about that, which would make it easier to >> port applications using libglade which has such an api. > > You could combine it with get_object too, to arrive at > > GObject * > gtk_builder_load_object_from_file (const gchar *filename, >const gchar *name); Not so nice, really. And still missing connect_signals() and (maybe) set_translation_domain. Do we really want this? -- 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 6/12/07, Johan Dahlin <[EMAIL PROTECTED]> wrote: > Havoc Pennington wrote: > > Is the Hello, World simplest use case as short and simple as it possibly > > could be? That's always a handy final litmus test for an API. > > How do you do an hello world in a ui toolkit? > Should it include signals? How many widgets? > > > From the header it looks like the simplest hello, world would have to > > builder_new, add_from_file, connect_signals, get_object at minimum? > > Maybe there's a convenience function or two that makes sense? > > builder_new + add_from_file could be combined into one constructor, > I've been thinking about that, which would make it easier to > port applications using libglade which has such an api. You could combine it with get_object too, to arrive at GObject * gtk_builder_load_object_from_file (const gchar *filename, const gchar *name); ___ 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 6/12/07, Johan Dahlin <[EMAIL PROTECTED]> wrote: > Havoc Pennington wrote: > > Is the Hello, World simplest use case as short and simple as it possibly > > could be? That's always a handy final litmus test for an API. > > How do you do an hello world in a ui toolkit? > Should it include signals? How many widgets? > examples/helloworld/helloworld.c Does't put the bar very high, though. ___ 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: > Is the Hello, World simplest use case as short and simple as it possibly > could be? That's always a handy final litmus test for an API. How do you do an hello world in a ui toolkit? Should it include signals? How many widgets? > From the header it looks like the simplest hello, world would have to > builder_new, add_from_file, connect_signals, get_object at minimum? > Maybe there's a convenience function or two that makes sense? builder_new + add_from_file could be combined into one constructor, I've been thinking about that, which would make it easier to port applications using libglade which has such an api. -- 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
Is the Hello, World simplest use case as short and simple as it possibly could be? That's always a handy final litmus test for an API. From the header it looks like the simplest hello, world would have to builder_new, add_from_file, connect_signals, get_object at minimum? Maybe there's a convenience function or two that makes sense? Havoc ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
GtkBuilder Public API - Last call
Hi,
During the Gtk+ developer meeting today it was decided that there will be a
final GtkBuilder discussion before it gets committed to trunk.
The current plan is that there will be a new developer release in the end of
the week, most likely on friday and that GtkBuilder is going to be included
in that release.
I'd like this discussion to be focus on the Public API. I've included the
two new public headers (gtkbuilder.h and gtkbuildable.h) with the API
documentation embedded.
Suggestions and questions about the documentation are also welcome, but
remember that the documentation is still very much open for changes during
the next couple of weeks, before the final release of 2.12.
I've also attached a .glade file which demonstrates some of the new
capabilities.
gtkbuilder.h
GtkBuilder is a replacement for the GladeXML found in the libglade library.
It is responsible for parsing a GtkBuilder UI definition and constructing
the object tree from that definition, usually a user interface.
This is the API which applications are going to use.
typedef enum
{
GTK_BUILDER_ERROR_INVALID_TYPE_FUNCTION,
GTK_BUILDER_ERROR_UNHANDLED_TAG,
GTK_BUILDER_ERROR_MISSING_ATTRIUTE,
GTK_BUILDER_ERROR_INVALID_ATTRIBUTE,
GTK_BUILDER_ERROR_INVALID_TAG
} GtkBuilderError;
struct _GtkBuilder
{
GObject parent;
GtkBuilderPrivate *priv;
};
struct _GtkBuilderClass
{
GObjectClass parent_class;
GType (* get_type_from_name) (GtkBuilder *builder,
const char *typename);
/* Padding for future expansion */
void (*_gtk_reserved1) (void);
void (*_gtk_reserved2) (void);
void (*_gtk_reserved3) (void);
void (*_gtk_reserved4) (void);
};
GTypegtk_builder_get_type(void) G_GNUC_CONST;
/**
* gtk_builder_new:
*
* Creates a new builder object.
*
* Return value: a new builder object.
*
* Since: 2.12
**/
GtkBuilder* gtk_builder_new (void);
/**
* gtk_builder_add_from_file:
* @buildable: a #GtkBuilder
* @filename: the name of the file to parse
* @error: return location for an error
*
* Parses a string containing a GtkBuilder UI
definition and
* merges it with the current contents of @builder.
*
* Returns: A positive value on success, 0 if an error occurred
*
* Since: 2.12
**/
guintgtk_builder_add_from_file (GtkBuilder *builder,
const gchar *filename,
GError **error);
/**
* gtk_builder_add_from_string:
* @builder: a #GtkBuilder
* @buffer: the string to parse
* @length: the length of @buffer (may be -1 if @buffer is nul-terminated)
* @error: return location for an error
*
* Parses a file containing a GtkBuilder UI
definition and
* merges it with the current contents of @builder.
*
* Returns: A positive value on success, 0 if an error occurred
*
* Since: 2.12
**/
guintgtk_builder_add_from_string (GtkBuilder *builder,
const gchar *buffer,
gsize length,
GError **error);
/**
* gtk_builder_get_object:
* @builder: a #GtkBuilder
* @name: name of object to get
*
* Return value: GObject or %NULL if it could not be found in the object tree.
*
* Since: 2.12
**/
GObject* gtk_builder_get_object (GtkBuilder *builder,
const gchar *name);
/**
* gtk_builder_get_objects:
* @builder: a #GtkBuilder
*
* Return value: a newly-allocated #GSList containing all the objects
* constructed by GtkBuilder instance.
*
* Since: 2.12
**/
GSList* gtk_builder_get_objects (GtkBuilder *builder);
/**
* gtk_builder_set_translation_domain:
* @builder: a #GtkBuilder
* @domain: the translation domain or %NULL
*
* Sets the translation domain and uses dgettext() for translating the
* property values marked as translatable from an interface description.
* You can also pass in %NULL to this method to use gettext() instead of
* dgettext().
*
* Since: 2.12
**/
void gtk_builder_set_translation_domain (GtkBuilder *builder,
const gchar *domain);
/**
* gtk_builder_get_translation_domain:
* @builder: a #GtkBuilder
*
* Return value : the translation domain. This string is owned
* by the builder object and must not be modified or freed.
*
* Since: 2.12
**/
const gchar* gtk_builder_get_translation_domain (GtkBuilder *builder);
/**
* GtkBuilderConnectFunc:
* @builder: a #GtkBuilder
* @object: a GObject subclass to connect a signal to
* @handler: name of the handler
* @object: GObject, if non NULL, use g_signal_connect_object.
* @after: if %TRUE use with g_signal_connect_after.
* @data: user data
*
* This is the signature of a function used to connect signals
Re: Editable GtkCellRendererText and focus
On Tue, Jun 12, 2007 at 09:34:50AM +1000, Daniel Kasak wrote: > Also related: > > http://bugzilla.gnome.org/show_bug.cgi?id=317387 > > ... affects cells with a CellRendererCombo as well. I think this is related in a different way, since you currently do not get a signal when the value in the combo box changes, only when you popdown the combo box. This is something we want to fix by adding a "changed" signal to GtkCellRendererCombo (the patch is there, will work on getting it in 2.12). Apart from that, the combo renderer currently fails to stop editing when the tree view loses focus, another thing which will be fixed soon. regards, -kris. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Editable GtkCellRendererText and focus
On 6/12/07, Kristian Rietveld <[EMAIL PROTECTED]> wrote: > On Mon, Jun 11, 2007 at 05:27:05PM +1200, Tim Evans wrote: > > I've attached a small PyGTK script that illustrates the problem. Our > > users are presented with a GtkTreeView containing a list of strings to > > edit. Having changed the values to their satisfaction, they click "OK". > > The problem is that the last change they make is not applied: no > > 'edited' signal is emitted on the GtkCellRendererText, so my code does > > not modify the underlying model. > > This is not a really easy problem :) I think we have to take two things > into account when contemplating about this: > > 1. What to do when the tree view loses focus? Do we leave the cell in > editing mode, or do we stop editing. > > Years ago, I think in 2.2 already, we have made changes to stop > editing as soon as focus was lost. I think this has been working > well over the last few years. > > 2. When we stop editing, do we confirm or cancel the changes? > > It feels like this decision can depend on what kind of data we are > editing, etc. > > > I actually tend to agree with Tim here that we should probably commit > the values when we lose focus. This is more or less equivalent with > what spreadsheets do -- I am only thinking about what users might compare > this editing functionality with here, GtkTreeView is not and will not > become a table/sheet widget ;) > > If applications really need confirmation via enter or something else, > I'd say they can hook into the entry and maintain a flag whether entry > was pressed yes or no and use that information in the "edited" callback > to decide whether to change the model or not. > > Personally, I've been disliking the cell editable API, because of its > short-comings, it's high on my list for redesigning. > > > So, if there are no objections, maybe we should revert. > > Opinions? Looking at the bugs that have been filed over the years, it seems clear that there is no universal solution. We can cop out and add a GtkCellRenderer:commit-on-focus-out property... ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Editable GtkCellRendererText and focus
On Mon, Jun 11, 2007 at 12:50:48AM -0500, Yevgen Muntyan wrote: > What's wrong with the filechooser, by the way? File > managers seem to work that way: you say "Create > Folder" and it creates folder. If you're unhappy, you > delete it. If you changed your mind while editing > name, hit Escape which means "Cancel", i.e. "No don't > create it". How is *switching focus* an indicator of > whether you want or do not want a folder on disk > to be created? In the original bug report it was argued that the file chooser should not create the folder until enter has been pressed, and the opinions really differ on this one. This falls nicely under point 2 in my other mail -- it depends on what kind of data we are editing whether we should confirm or cancel when the editing stops. Once we revert it will be well possible to make the file chooser only create the folder after explicit confirmation (maybe it works around this already, I am not sure), but I will leave that decision to somebody else ;) -kris. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Editable GtkCellRendererText and focus
On Mon, Jun 11, 2007 at 05:27:05PM +1200, Tim Evans wrote: > I've attached a small PyGTK script that illustrates the problem. Our > users are presented with a GtkTreeView containing a list of strings to > edit. Having changed the values to their satisfaction, they click "OK". > The problem is that the last change they make is not applied: no > 'edited' signal is emitted on the GtkCellRendererText, so my code does > not modify the underlying model. This is not a really easy problem :) I think we have to take two things into account when contemplating about this: 1. What to do when the tree view loses focus? Do we leave the cell in editing mode, or do we stop editing. Years ago, I think in 2.2 already, we have made changes to stop editing as soon as focus was lost. I think this has been working well over the last few years. 2. When we stop editing, do we confirm or cancel the changes? It feels like this decision can depend on what kind of data we are editing, etc. I actually tend to agree with Tim here that we should probably commit the values when we lose focus. This is more or less equivalent with what spreadsheets do -- I am only thinking about what users might compare this editing functionality with here, GtkTreeView is not and will not become a table/sheet widget ;) If applications really need confirmation via enter or something else, I'd say they can hook into the entry and maintain a flag whether entry was pressed yes or no and use that information in the "edited" callback to decide whether to change the model or not. Personally, I've been disliking the cell editable API, because of its short-comings, it's high on my list for redesigning. So, if there are no objections, maybe we should revert. Opinions? regards, -kris. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Question about new functions in GDK 2.11
On Thu, 2007-06-07 at 00:42 +0200, Tomasz Jankowski wrote: > Hi! > > My question isn't really important, I'm only curious ;P > > Why did you add functions below to GDK? > > gdk_threads_add_idle > gdk_threads_add_idle_full > gdk_threads_add_timeout > gdk_threads_add_timeout_full > If we write multi thread aplication in GTK+ we surround gtk_main () > function with gdk_threads_enter () and gdk_threads_leave (), so any > call of g_idle_add... or g_timeout... functions will be automatically > thread safe, am I right? > > Can someone explain it for me? No, that is not true. All Gtk+ callbacks and signals will have the gdk lock taken, but idles and timeouts need to call gdk_threads_enter() manually. Plus there is the race matthias explained. ___ 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: > 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. So could we deprecate GtkTooltips with #ifdefs and gtk-doc comments? Thanks for the great overview. > There are several ways for showing tooltips using the new API, > increasing in complexity as the complexity of the wished tooltip > increases: > > 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. > > 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. > > - Connect to the "query-tooltip" signal on GtkWidget. This signal > will be emitted when a tooltip will have to be shown. The > signature is: > > gboolean (* query_tooltip) (GtkWidget *widget, >gintx, >ginty, >gbooleankeyboard_tooltip, >GtkTooltip *tooltip); > > The arguments are pretty much straightforward, and here we see > where the new GtkTooltip object comes to play. The GtkTooltip > is the object that we are about to display as a tooltip, and can > be manipulated in your query-tooltip callback using functions > like: > >void gtk_tooltip_set_icon (GtkTooltip *tooltip, > GdkPixbuf *pixbuf); > > there are likewise functions for setting the tooltip's markup, > setting an image from a stock icon or even for putting in a > custom widget. > > Important is the return value of query-tooltip: when you return > TRUE the GtkTooltip will be shown, when you return FALSE it will > not be shown. > > 3. In the, probably, rare case where you want to have even more control > over the tooltip that is about to be shown, you can set your own > GtkWindow which will be used as tooltip window. This works as > follows: > > - Set has-tooltip and connect to query-tooltip as under 2). > > - Use gtk_widget_set_tooltip_window() to set a GtkWindow created > by you as tooltip window. > > - In the query-tooltip callback you can access your GtkWindow > using gtk_widget_get_tooltip_window() and manipulate as you > wish. The semantics of the return value of query-tooltip are > exactly the same as with 2): TRUE will show the tooltip > window, FALSE will not show it. > > > In the GTK+ source code you will find a test app testing all of the > above methods in gtk+/tests/testtooltips.c. There are examples for > simple tooltips on buttons (also insensitive buttons!), tooltips on > GtkTreeView rows, tooltips on GtkTextView tags and a small example with > tooltips on specific areas of a GtkDrawingArea. (Yes, I know the tree > view example is a little broken -- it will be fixed RSN). > > Some small details are still left to be worked out; think of improving > tooltips positioning, probably popup-tooltip-directly-on-demand and at > some later stage greater flexibility and customizability. Watch > gtk-devel-list for the latest news ;) > > > I hope this gives you enough information to get started! > > > regards, > > -kris. > ___ > gtk-devel-list mailing list > gtk-devel-list@gnome.org > http://mail.gnome.org/mailman/listinfo/gtk-devel-list -- Murray Cumming [EMAIL PROTECTED] www.murrayc.com www.openismus.com ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
The new tooltips API in 5 minutes [Was: Re: Whats coming in GTK+ 2.12, continued]
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: 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. 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. - Connect to the "query-tooltip" signal on GtkWidget. This signal will be emitted when a tooltip will have to be shown. The signature is: gboolean (* query_tooltip) (GtkWidget *widget, gintx, ginty, gbooleankeyboard_tooltip, GtkTooltip *tooltip); The arguments are pretty much straightforward, and here we see where the new GtkTooltip object comes to play. The GtkTooltip is the object that we are about to display as a tooltip, and can be manipulated in your query-tooltip callback using functions like: void gtk_tooltip_set_icon (GtkTooltip *tooltip, GdkPixbuf *pixbuf); there are likewise functions for setting the tooltip's markup, setting an image from a stock icon or even for putting in a custom widget. Important is the return value of query-tooltip: when you return TRUE the GtkTooltip will be shown, when you return FALSE it will not be shown. 3. In the, probably, rare case where you want to have even more control over the tooltip that is about to be shown, you can set your own GtkWindow which will be used as tooltip window. This works as follows: - Set has-tooltip and connect to query-tooltip as under 2). - Use gtk_widget_set_tooltip_window() to set a GtkWindow created by you as tooltip window. - In the query-tooltip callback you can access your GtkWindow using gtk_widget_get_tooltip_window() and manipulate as you wish. The semantics of the return value of query-tooltip are exactly the same as with 2): TRUE will show the tooltip window, FALSE will not show it. In the GTK+ source code you will find a test app testing all of the above methods in gtk+/tests/testtooltips.c. There are examples for simple tooltips on buttons (also insensitive buttons!), tooltips on GtkTreeView rows, tooltips on GtkTextView tags and a small example with tooltips on specific areas of a GtkDrawingArea. (Yes, I know the tree view example is a little broken -- it will be fixed RSN). Some small details are still left to be worked out; think of improving tooltips positioning, probably popup-tooltip-directly-on-demand and at some later stage greater flexibility and customizability. Watch gtk-devel-list for the latest news ;) I hope this gives you enough information to get started! regards, -kris. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
[REMINDER] GTK+ Team Meeting Tonight
hi everyone; tonight there will be a gtk+ team IRC meeting: #gtk-devel on irc.gimp.org, at 20:00 UTC[1] the discussion points for the meeting are: * status of GtkBuilder; * small API additions still pending; * removal of the remaining linux-fb bits; as usual, everyone can attend. ciao, Emmanuele. +++ [1] http://www.timeanddate.com/worldclock/fixedtime.html?month=6&day=12&year=2007&hour=20&min=0&sec=0&p1=0 -- Emmanuele Bassi, E: [EMAIL PROTECTED] W: http://www.emmanuelebassi.net B: http://log.emmanuelebassi.net ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
