libglade's _new() function has a root parameter:
http://developer.gnome.org/doc/API/libglade/gladexml.html#GLADE-XML-NEW
This is necessary because libglade otherwise instantiates all the items
in the file. Does GtkBuilder instead only instantiate the objects when
you actually use
2007/6/26, Murray Cumming [EMAIL PROTECTED]:
libglade's _new() function has a root parameter:
http://developer.gnome.org/doc/API/libglade/gladexml.html#GLADE-XML-NEW
This is necessary because libglade otherwise instantiates all the items
in the file. Does GtkBuilder instead only instantiate
On Tue, 2007-06-26 at 14:19 +0300, Kalle Vahlman wrote:
2007/6/26, Murray Cumming [EMAIL PROTECTED]:
libglade's _new() function has a root parameter:
http://developer.gnome.org/doc/API/libglade/gladexml.html#GLADE-XML-NEW
This is necessary because libglade otherwise instantiates all the
On Tue, 2007-06-26 at 13:50 +0200, Murray Cumming wrote:
On Tue, 2007-06-26 at 14:19 +0300, Kalle Vahlman wrote:
2007/6/26, Murray Cumming [EMAIL PROTECTED]:
libglade's _new() function has a root parameter:
http://developer.gnome.org/doc/API/libglade/gladexml.html#GLADE-XML-NEW
This
Tristan Van Berkom wrote:
On Tue, 2007-06-26 at 13:50 +0200, Murray Cumming wrote:
On Tue, 2007-06-26 at 14:19 +0300, Kalle Vahlman wrote:
2007/6/26, Murray Cumming [EMAIL PROTECTED]:
libglade's _new() function has a root parameter:
Torsten Schoenfeld wrote:
On Mon, 2007-06-18 at 09:55 -0300, Johan Dahlin wrote:
void (* set_property)(GtkBuildable *buildable,
GtkBuilder*builder,
const gchar *name,
Torsten Schoenfeld wrote:
On Tue, 2007-06-12 at 18:26 -0300, Johan Dahlin wrote:
gtkbuildable.h
==
GtkBuildable is an interface which is implementable to allow a GObject
subclass to customize the behavior of how it is going to be built.
Some of the GtkBuildable methods have
2007/6/18, Johan Dahlin [EMAIL PROTECTED]:
Torsten Schoenfeld wrote:
On Tue, 2007-06-12 at 18:26 -0300, Johan Dahlin wrote:
gtkbuildable.h
==
GtkBuildable is an interface which is implementable to allow a GObject
subclass to customize the behavior of how it is going to be
On Mon, 2007-06-18 at 09:55 -0300, Johan Dahlin wrote:
void (* set_property)(GtkBuildable *buildable,
GtkBuilder*builder,
const gchar *name,
On Tue, 2007-06-12 at 18:26 -0300, Johan Dahlin wrote:
gtkbuildable.h
==
GtkBuildable is an interface which is implementable to allow a GObject
subclass to customize the behavior of how it is going to be built.
Some of the GtkBuildable methods have very generic names which can
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
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
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
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
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
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
*
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
2007/6/13, Yevgen Muntyan [EMAIL PROTECTED]:
Kalle Vahlman wrote:
2007/6/13, Matthias Clasen [EMAIL PROTECTED]:
GtkBuilder is just setting the name that was specified in the xml, so
it is not violating the principle that the widget name belongs to the
app/user, since
the xml is part of
Kalle Vahlman wrote:
2007/6/13, Yevgen Muntyan [EMAIL PROTECTED]:
Kalle Vahlman wrote:
2007/6/13, Matthias Clasen [EMAIL PROTECTED]:
GtkBuilder is just setting the name that was specified in the xml, so
it is not violating the principle that the widget name belongs to the
app/user, since
2007/6/14, Yevgen Muntyan [EMAIL PROTECTED]:
Kalle Vahlman wrote:
2007/6/13, Yevgen Muntyan [EMAIL PROTECTED]:
Kalle Vahlman wrote:
2007/6/13, Matthias Clasen [EMAIL PROTECTED]:
GtkBuilder is just setting the name that was specified in the xml, so
it is not violating the principle
Kalle Vahlman wrote:
2007/6/14, Yevgen Muntyan [EMAIL PROTECTED]:
Kalle Vahlman wrote:
2007/6/13, Yevgen Muntyan [EMAIL PROTECTED]:
Kalle Vahlman wrote:
2007/6/13, Matthias Clasen [EMAIL PROTECTED]:
GtkBuilder is just setting the name that was specified in the
xml, so
it is not
Hi,
Lainaus Yevgen Muntyan [EMAIL PROTECTED]:
[clip]
Yes you can set the name after construction.
gtk_builder_build_stuff();
widget1 = gtk_builder_lookup (foo);
gtk_widget_set_name (widget1, gtk-tooltips);
/* oops, forgot to set up widget2 after adding it in glade,
since we set all
Tim Janik wrote:
On Wed, 13 Jun 2007, Johan Dahlin wrote:
Johan Dahlin wrote:
Christian Persch wrote:
Hi;
typedef void (*GtkBuilderConnectFunc) (GtkBuilder *builder,
const gchar *handler_name,
GObject
On Thu, 2007-06-14 at 10:41 -0300, Johan Dahlin wrote:
Let's use this xml attributes for the signal tag;
name: signal name
handler: handler to connect the signal to
after: optional, boolean if True, set flags to G_CONNECT_AFTER
swapped: optional, boolean if True, set flags to
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:
On Thu, 14 Jun 2007, Johan Dahlin wrote:
Tim Janik wrote:
there could conceivably be new flags in the future. also,
object is different from swapped. the former should use
g_signal_connect_object which needs a GObject argument and
auto-disconnects the signal handler if the object argument
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:
Steve Frécinaux wrote:
On Thu, 2007-06-14 at 10:41 -0300, Johan Dahlin wrote:
Let's use this xml attributes for the signal tag;
name: signal name
handler: handler to connect the signal to
after: optional, boolean if True, set flags to G_CONNECT_AFTER
swapped: optional, boolean if
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
On Thu, 2007-06-14 at 12:42 +0300, [EMAIL PROTECTED] wrote:
So, I'm asking: Why not include something like set widget name option
into glade and xml-file, or separate property for the name to be set??
Those widgets that have this flag set will have gtk_widget_set_name called,
other do not
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
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
2007/6/14, Yevgen Muntyan [EMAIL PROTECTED]:
Kalle Vahlman wrote:
Is there a particular reason to set the name in _init() rather than in
_set_cursor_colors()? It would avoid setting it completely if using
Gtk+ =2.11.3
Code was written before Gtk+ = 2.11.3.
...with a chisel to a stone I
Kalle Vahlman wrote:
[snip philosophy]
[1] though I don't really agree on widgets setting colors at all,
regardless the fact that it then possibly won't look good with older
themes (depending on what colors you can use).
If you are really interested, get a fresh tarball of gtksourceview
and
2007/6/14, Yevgen Muntyan [EMAIL PROTECTED]:
Kalle Vahlman wrote:
[snip philosophy]
[1] though I don't really agree on widgets setting colors at all,
regardless the fact that it then possibly won't look good with older
themes (depending on what colors you can use).
If you are really
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
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
2007/6/13, Havoc Pennington [EMAIL PROTECTED]:
- 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.
There was discussion of
Matthias Clasen wrote:
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
2007/6/13, Yevgen Muntyan [EMAIL PROTECTED]:
Right, GtkUIManager as well as libglade hardly use non-stock
widgets now (see above). How many glade files use GtkSourceView
for instance? (or GtkUIManager xml description, for that matter)
I would assume 0 for UIManager descriptions, since it's not
Hi,
why do gtk_builder_add_from_file and gtk_builder_add_from_string return
a guint instead of a gboolean?
If the positive number returned on success has a special meaning it
should be documented, otherwise I think it is better to use a gboolean
like you do in gtk_builder_value_from_string and
2007/6/13, Paolo Maggi [EMAIL PROTECTED]:
Hi,
why do gtk_builder_add_from_file and gtk_builder_add_from_string return
a guint instead of a gboolean?
If the positive number returned on success has a special meaning it
should be documented, otherwise I think it is better to use a gboolean
Paolo Maggi wrote:
Hi,
why do gtk_builder_add_from_file and gtk_builder_add_from_string return
a guint instead of a gboolean?
If the positive number returned on success has a special meaning it
should be documented, otherwise I think it is better to use a gboolean
like you do in
On Wed, 2007-06-13 at 03:40 -0500, Yevgen Muntyan wrote:
[snip]
Right, GtkUIManager as well as libglade hardly use non-stock
widgets now (see above). How many glade files use GtkSourceView
for instance? (or GtkUIManager xml description, for that matter)
[snip]
I do that for Glom's .glade file.
Hi;
typedef void (*GtkBuilderConnectFunc) (GtkBuilder *builder,
const gchar *handler_name,
GObject *object,
const gchar *signal_name,
On Tue, 12 Jun 2007, 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?
this page shows the very first hello-world
Tim Janik wrote:
On Tue, 12 Jun 2007, 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
Johan Dahlin wrote:
Christian Persch wrote:
Hi;
typedef void (*GtkBuilderConnectFunc) (GtkBuilder *builder,
const gchar *handler_name,
GObject *object,
const gchar
Hi;
Le mercredi 13 juin 2007 à 10:01 -0300, Johan Dahlin a écrit :
Johan Dahlin wrote:
Christian Persch wrote:
Hi;
typedef void (*GtkBuilderConnectFunc) (GtkBuilder *builder,
const gchar *handler_name,
Hi,
Perhaps gtk_builder_connect_signals_with_data (or something like that)
is the way to go. At least in a case we plan to include the DestroyNotify.
Otherwise we could tolerate one extra parameter into connect_signals, right?
Putting a DestroyNotify there will create the following (easy) bug
On 6/13/07, Yevgen Muntyan [EMAIL PROTECTED] wrote:
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.
Programmers are also not supposed to set
[EMAIL PROTECTED] wrote:
Hi,
Perhaps gtk_builder_connect_signals_with_data (or something like that)
is the way to go. At least in a case we plan to include the DestroyNotify.
Otherwise we could tolerate one extra parameter into connect_signals, right?
I think so, one extra parameter is not
Christian Persch wrote:
Hi;
Le mercredi 13 juin 2007 à 10:01 -0300, Johan Dahlin a écrit :
Johan Dahlin wrote:
Christian Persch wrote:
Hi;
typedef void (*GtkBuilderConnectFunc) (GtkBuilder *builder,
const gchar *handler_name,
Hi;
Le mercredi 13 juin 2007 à 11:07 -0300, Johan Dahlin a écrit :
Is there are reason to prefer glade_xml_signal_connect[data] to the
connect_signals() api? Assuming we add a user data argument to
connect_signals, see separate discussion.
I don't think we need a separate connect_data if we
Christian Persch wrote:
Hi;
Le mercredi 13 juin 2007 à 11:07 -0300, Johan Dahlin a écrit :
Is there are reason to prefer glade_xml_signal_connect[data] to the
connect_signals() api? Assuming we add a user data argument to
connect_signals, see separate discussion.
I don't think we need a
Good morning folks,
What I really want to discuss in this thread is properties, packing
properties and also more specifically, packing properties on
non-GtkContainer GObjects - I use a custom gtk+ based toolkit that
makes heavy use of delagate GObjects in the widget hierarchy
(objects that define
On Wed, 2007-06-13 at 10:44 -0400, Tristan Van Berkom wrote:
Good morning folks,
[...]
Can we please not swap signal handlers unless they are
explicitly specified ?
object class=GtkEntry id=entry
signal name=activate handler=button_clicked object=button/
/object
Oops, have to
Tristan Van Berkom wrote:
Good morning folks,
Thanks for the comments!
What I really want to discuss in this thread is properties, packing
properties and also more specifically, packing properties on
non-GtkContainer GObjects - I use a custom gtk+ based toolkit that
makes heavy use of
On Wed, 2007-06-13 at 10:48 -0400, Tristan Van Berkom wrote:
object class=GtkEntry id=entry
signal name=activate handler=button_clicked swapped=True/
/object
Why should swapped be a property of the xml ? it looks closely tied to
the code, to me, and should not be specified in the XML
2007/6/13, Matthias Clasen [EMAIL PROTECTED]:
On 6/13/07, Yevgen Muntyan [EMAIL PROTECTED] wrote:
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
On Wed, 2007-06-13 at 12:13 -0300, Johan Dahlin wrote:
[...]
Ideally not.
It seems to me that most of the virtual properties were hacks.
Preferably the widgets should be fixed upstream instead.
Yes, there are also special cases such as visibility of windows and
focus/default. I think they
Kalle Vahlman wrote:
2007/6/13, Matthias Clasen [EMAIL PROTECTED]:
On 6/13/07, Yevgen Muntyan [EMAIL PROTECTED] wrote:
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
On Wed, 2007-06-13 at 10:57 -0500, Yevgen Muntyan wrote:
Kalle Vahlman wrote:
2007/6/13, Matthias Clasen [EMAIL PROTECTED]:
On 6/13/07, Yevgen Muntyan [EMAIL PROTECTED] wrote:
Widgets which set a name in a constructor are already semi-broken
anyway. Widget names are supposed
Tristan Van Berkom wrote:
On Wed, 2007-06-13 at 10:57 -0500, Yevgen Muntyan wrote:
Kalle Vahlman wrote:
2007/6/13, Matthias Clasen [EMAIL PROTECTED]:
On 6/13/07, Yevgen Muntyan [EMAIL PROTECTED] wrote:
Widgets which set a name in a constructor are already
/**
* gtk_builder_enum_from_string:
* @type: a #GType
* @string: string containing an enum
*
* This function is used to convert a string to a enum value. You can use
the
* enums nick or blurb representations to convert from.
*
* Return value: converted enum value
*
* Since: 2.12
*/
gint
Samuel Cormier-Iijima wrote:
/**
* gtk_builder_enum_from_string:
* @type: a #GType
* @string: string containing an enum
*
* This function is used to convert a string to a enum value. You can
use the
* enums nick or blurb representations to convert
Since it accepts a nick, name or number, it's using
g_enum_get_value_by_nick/name internally.
...in which case it belongs in glib.
Morten
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Morten Welinder wrote:
Since it accepts a nick, name or number, it's using
g_enum_get_value_by_nick/name internally.
...in which case it belongs in glib.
Large parts of GtkBuilder belongs to glib, (de)serialization of objects is
not tied to a graphical toolkit. It's difficult as it is to get
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
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
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
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
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
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,
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/
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
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
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:
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 ?
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
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 ?
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.
*
*
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
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
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
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
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.
87 matches
Mail list logo
