Hi,
On Thu, 2007-06-14 at 03:26 +0100, Alex Jones wrote:
> I've been looking at how Rhythmbox allows plugins to manipulate menus
> (via UI manager magic), and it dawned on me that there is no way to
> separate these out visually, other than to attempt to guess whether
> there should be a separato
Hi list
I've been looking at how Rhythmbox allows plugins to manipulate menus
(via UI manager magic), and it dawned on me that there is no way to
separate these out visually, other than to attempt to guess whether
there should be a separator placed above and/or below what you're trying
to insert.
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 t
> 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
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 c
On Wed, 2007-06-13 at 13:25 -0300, Johan Dahlin wrote:
[...]
> Let's do something a little cleaner and more flexible;
>
> typedef void (*GtkBuilderConnectFunc) (GtkBuilder *builder,
> const gchar *handler_name,
> GObject
/**
* 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 g
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
Tristan Van Berkom wrote:
[..]
>>> Another important point that was raised:
>>>
>>> On Wed, 2007-06-13 at 10:01 -0300, Johan Dahlin wrote:
>>> [...]
Well, actually swapped handlers are supported, using the object attribute,
eg:
>>> I think its quite
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. Wid
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 some
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 t
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 implem
On Wed, 2007-06-13 at 10:48 -0400, Tristan Van Berkom wrote:
>
>
>
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 file, but set
while actually connecting the widget.
A (bad, but demonstrative enough) ex
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 d
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 ?
>
>
>
>
Oops, have to ammend my mistype here, I meant to say:
-Tristan
__
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
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
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 à 10:01 -0300, Johan Dahlin a écrit :
>> Johan Dahlin wrote:
>>> Christian Persch wrote:
Hi;
> typedef void (*GtkBuilderConnectFunc) (GtkBuilder *builder,
>const gchar *handler_nam
[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
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 suppose
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 sc
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,
> >>>
[EMAIL PROTECTED] wrote:
> Hi,
>
> I'm wondering if there is a reason why one cannot provide user_data
> for gtk_builder_connect_signals? This data would be used as user_data
> for each signal connected, except for those where a specific data widget
> is defined in the glade-file. Currently the da
Hi,
I'm wondering if there is a reason why one cannot provide user_data
for gtk_builder_connect_signals? This data would be used as user_data
for each signal connected, except for those where a specific data widget
is defined in the glade-file. Currently the data used in signal connection
is eith
Johan Dahlin wrote:
> Christian Persch wrote:
>> Hi;
>>
>>> typedef void (*GtkBuilderConnectFunc) (GtkBuilder *builder,
>>>const gchar *handler_name,
>>>GObject *object,
>>>c
Christian Persch wrote:
> Hi;
>
>> typedef void (*GtkBuilderConnectFunc) (GtkBuilder *builder,
>>const gchar *handler_name,
>>GObject *object,
>>const gchar *signal_name,
>>
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
>> e
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-wo
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 week, most likely on
Kalle Vahlman wrote:
> 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 assum
Hi;
> typedef void (*GtkBuilderConnectFunc) (GtkBuilder *builder,
>const gchar *handler_name,
>GObject *object,
>const gchar *signal_name,
>
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 fil
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 gtk
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 gboo
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 ot
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
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.
>> > Wh
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
40 matches
Mail list logo
