subject:"Re\: GtkBuilder Public API \- Last call"

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 the app.
 

 And widget isn't part of the app? Such separation is meaningless for
 purpose of answering the question should we change code of given
 widget if we want the widget to be usable with GtkBuider?

 So, if a widget sets its name to modify its style, then
 it's broken? Even if the style is essential part of its functionality?
 E.g. text cursor color is not something fancy, it's an essential part
 of text widget and it rather sucks if cursor is invisible because of
 wrong styles. Saying it's broken because it is somehow
 not a part of application just doesn't make sense.

So let's see, the things that make up a style in gtkrc are colors
and style properties. Any special-casing above (or rather below) that
is up to the theme engine and thus can't really be trusted. Colors are
grouped by functionality into fg, bg, base and text (as well as the
various computed colors from those). Those have clear meanings, and
should provide enough distinct colors for most widgets. If not, you
must rely on custom style properties and accept that it might not
match the theme. There is no way around this (other than calculating
the color, but that might be less than pleasing visually).

If a widget goes bonkers because a style property had the default
value, maybe the default value should be made more sensible?

  Furthermore, if my (admittedly quick) glance over how the object names
  are handled is not misguided, GtkBuilder sets the name once and never
  checks it again. It has an internal hash table in which it stores the
  id in the xml and all lookups use that instead of referring to the
  actual name.
 
  So even if GtkBuilder sets the initial name to what is in the xml, you
  should be able to change it afterwards to whatever you like without
  everything going bork bork.
 

 I said already what could be a problem. get_widget_by_name()
 is irrelevant.

You said that matching the widgets in gtkrc would be a problem and in
the part that you didn't include here I told you it's not:

A quick test shows that I can indeed match my widget by the fancy name
I gave it in the code in a gtkrc, while the lookup returns the correct
object with the xml id.

Did I miss something obvious here? Or did you?

-- 
Kalle Vahlman, [EMAIL PROTECTED]
Powered by http://movial.fi
Interesting stuff at http://syslog.movial.fi
___
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

2007-06-14 Thread Yevgen Muntyan

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
  the xml is part of the app.
 

 And widget isn't part of the app? Such separation is meaningless for
 purpose of answering the question should we change code of given
 widget if we want the widget to be usable with GtkBuider?

 So, if a widget sets its name to modify its style, then
 it's broken? Even if the style is essential part of its functionality?
 E.g. text cursor color is not something fancy, it's an essential part
 of text widget and it rather sucks if cursor is invisible because of
 wrong styles. Saying it's broken because it is somehow
 not a part of application just doesn't make sense.

 So let's see, the things that make up a style in gtkrc are colors
 and style properties. Any special-casing above (or rather below) that
 is up to the theme engine and thus can't really be trusted. Colors are
 grouped by functionality into fg, bg, base and text (as well as the
 various computed colors from those). Those have clear meanings, and
 should provide enough distinct colors for most widgets. If not, you
 must rely on custom style properties and accept that it might not
 match the theme. There is no way around this (other than calculating
 the color, but that might be less than pleasing visually).

 If a widget goes bonkers because a style property had the default
 value, maybe the default value should be made more sensible?

Until gtk-2.12 there was no API to set cursor color. Try a textview
with black background and black cursor and you'll see what I'm
talking about ;)
Try to get tooltips yellow color from a theme, without using
gtk-tooltips name.
And of course those custom style properties won't match theme,
why would one change them otherwise? Thing is, sometimes you
do need to change those style properties, and it is *not* something
wrong or evil.


  Furthermore, if my (admittedly quick) glance over how the object names
  are handled is not misguided, GtkBuilder sets the name once and never
  checks it again. It has an internal hash table in which it stores the
  id in the xml and all lookups use that instead of referring to the
  actual name.
 
  So even if GtkBuilder sets the initial name to what is in the xml, you
  should be able to change it afterwards to whatever you like without
  everything going bork bork.
 

 I said already what could be a problem. get_widget_by_name()
 is irrelevant.

 You said that matching the widgets in gtkrc would be a problem and in
 the part that you didn't include here I told you it's not:

 A quick test shows that I can indeed match my widget by the fancy name
 I gave it in the code in a gtkrc, while the lookup returns the correct
 object with the xml id.

 Did I miss something obvious here? Or did you?


Set widget name in constructor or init(), then create this widget with 
GtkBuilder.
Yeah, semi-broken.

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

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 that the widget name belongs to the
   app/user, since
   the xml is part of the app.
  
 
  And widget isn't part of the app? Such separation is meaningless for
  purpose of answering the question should we change code of given
  widget if we want the widget to be usable with GtkBuider?
 
  So, if a widget sets its name to modify its style, then
  it's broken? Even if the style is essential part of its functionality?
  E.g. text cursor color is not something fancy, it's an essential part
  of text widget and it rather sucks if cursor is invisible because of
  wrong styles. Saying it's broken because it is somehow
  not a part of application just doesn't make sense.
 
  So let's see, the things that make up a style in gtkrc are colors
  and style properties. Any special-casing above (or rather below) that
  is up to the theme engine and thus can't really be trusted. Colors are
  grouped by functionality into fg, bg, base and text (as well as the
  various computed colors from those). Those have clear meanings, and
  should provide enough distinct colors for most widgets. If not, you
  must rely on custom style properties and accept that it might not
  match the theme. There is no way around this (other than calculating
  the color, but that might be less than pleasing visually).
 
  If a widget goes bonkers because a style property had the default
  value, maybe the default value should be made more sensible?

 Until gtk-2.12 there was no API to set cursor color. Try a textview
 with black background and black cursor and you'll see what I'm
 talking about ;)

But I don't understand why this has anything to do with widget names?
If you set black on black, it'll be black on black even if you widget
is named GreyOnWhite.

 Try to get tooltips yellow color from a theme, without using
 gtk-tooltips name.

But GtkBuilder doesn't touch that name? So why would it break?

 And of course those custom style properties won't match theme,
 why would one change them otherwise? Thing is, sometimes you
 do need to change those style properties, and it is *not* something
 wrong or evil.

Let me see if I can list the cases where this is neccessary:
 - You implemented your custom widget and it needs style
- match by *.class
 - You implemented a custom container and wish to give style to the children
- match by *.class.child_class
 - You implemented a custom widget with internal children and they need style
- name the internal child whatever and match by name
 - You need to set style to it here but not there
- name the widget you get from GtkBuilder and match by name

Is there other cases, and why do they break down if GtkBuilder sets the name?

  You said that matching the widgets in gtkrc would be a problem and in
  the part that you didn't include here I told you it's not:
 
  A quick test shows that I can indeed match my widget by the fancy name
  I gave it in the code in a gtkrc, while the lookup returns the correct
  object with the xml id.
 
  Did I miss something obvious here? Or did you?
 

 Set widget name in constructor or init(), then create this widget with
 GtkBuilder.
 Yeah, semi-broken.

Why is that preferrable over matching by the widget class name?

-- 
Kalle Vahlman, [EMAIL PROTECTED]
Powered by http://movial.fi
Interesting stuff at http://syslog.movial.fi
___
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

2007-06-14 Thread Yevgen Muntyan

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 violating the principle that the widget name belongs
to the
app/user, since
the xml is part of the app.

And widget isn't part of the app? Such separation is meaningless for
purpose of answering the question should we change code of given
widget if we want the widget to be usable with GtkBuider?

So, if a widget sets its name to modify its style, then
it's broken? Even if the style is essential part of its
functionality?
E.g. text cursor color is not something fancy, it's an essential part
of text widget and it rather sucks if cursor is invisible because of
wrong styles. Saying it's broken because it is somehow
not a part of application just doesn't make sense.

So let's see, the things that make up a style in gtkrc are colors
and style properties. Any special-casing above (or rather below) that
is up to the theme engine and thus can't really be trusted. Colors are
grouped by functionality into fg, bg, base and text (as well as the
various computed colors from those). Those have clear meanings, and
should provide enough distinct colors for most widgets. If not, you
must rely on custom style properties and accept that it might not
match the theme. There is no way around this (other than calculating
the color, but that might be less than pleasing visually).

If a widget goes bonkers because a style property had the default
value, maybe the default value should be made more sensible?

Until gtk-2.12 there was no API to set cursor color. Try a textview
with black background and black cursor and you'll see what I'm
talking about ;)

But I don't understand why this has anything to do with widget names?
If you set black on black, it'll be black on black even if you widget
is named GreyOnWhite.

Try to get tooltips yellow color from a theme, without using
gtk-tooltips name.

But GtkBuilder doesn't touch that name? So why would it break?

And of course those custom style properties won't match theme,
why would one change them otherwise? Thing is, sometimes you
do need to change those style properties, and it is *not* something
wrong or evil.

Let me see if I can list the cases where this is neccessary:
- You implemented your custom widget and it needs style
- match by *.class
- You implemented a custom container and wish to give style to the
children
- match by *.class.child_class
- You implemented a custom widget with internal children and they need
style
- name the internal child whatever and match by name
- You need to set style to it here but not there
- name the widget you get from GtkBuilder and match by name

Is there other cases, and why do they break down if GtkBuilder sets
the name?

You said that matching the widgets in gtkrc would be a problem and in
the part that you didn't include here I told you it's not:

A quick test shows that I can indeed match my widget by the fancy
name
I gave it in the code in a gtkrc, while the lookup returns the correct
object with the xml id.

Did I miss something obvious here? Or did you?

Set widget name in constructor or init(), then create this widget with
GtkBuilder.
Yeah, semi-broken.

Why is that preferrable over matching by the widget class name?

See
http://svn.gnome.org/viewcvs/gtksourceview/trunk/gtksourceview/gtksourcestylescheme.c?view=markup
for cursor color thing, set_cursor_colors() function. For non-unique
name, try
to get tooltips color on your widget without gtk-tooltips 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

2007-06-14 Thread markku . vire


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 the properties in glade, don't we? */
 
 IMHO, it's silly.
 
 I don't think it's a big deal because we won't get to the level
 of doing everything in glade anyway. Still, it's a weird thing.
 Anyway, let us stop. People are fine with this, good.
 No need to tell how to work it around, it's clear how to
 work it around; and no need to explain how it's wrong to
 do these nasty things with styles, because it's *not* wrong
 (it sucks one has to do things like that, indeed).

What about the opposite scenario: Application developer wants that
some widgets designed by glade need to have their names set, in order
to be themed in a special way. If the builder won't set the names,
then developer ends up fetching the pointers and set the names by hand...
just like in your example.

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 (name is just a internal reference, like a variable name in C). 
By default this would be off (since most widgets are certainly not special 
ones, you are not calling gtk_widget_set_name for each widget if you write 
the UI by hand, do you...)

-Markku-
___
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:
 
 Johan Dahlin wrote:
 Christian Persch wrote:
 Hi;

 typedef void (*GtkBuilderConnectFunc) (GtkBuilder  *builder,
const gchar *handler_name,
GObject *object,
const gchar *signal_name,
GObject *connect_object,
gboolean after,
gpointer user_data);
 Could we have GConnectFlags flags instead of gboolean after
 here, so
 this could also support swapped handlers in future?

 This was copied more or less directly from libglade, there's a certain
 advantage of making this compatible with the existing code.


 Well, actually swapped handlers are supported, using the object
 attribute, eg:

  object class=GtkButton id=button/
  object class=GtkEntry id=entry
signal name=activate handler=button_clicked object=button/
  /object

 It definitely makes sense to support GConnectFlags though.

 I thought there were other flags apart from after and swapped, so this is
 not true, right?
 
 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
 is disposed. the later also works for void* pointers.

Oh, I knew I missed something.

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 G_CONNECT_SWAPPED
  object: optional, if set use g_signal_connect_object

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.

g_signal_connect_object does not provide a way to send in user data so it
conflicts with the user data which may be passed in to
gtk_builder_connect_signals. Not a too big deal I guess, it just needs to be
documented.

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

2007-06-14 Thread Steve Frécinaux

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 G_CONNECT_SWAPPED
   object: optional, if set use g_signal_connect_object

I still don't understand how swapped is relevant in the XML context
instead of in the C code actually connecting the handler. It looks like
implementation detail to me, that should not be enforced by the XML
file... The same applies for after and object.

Do someone has a real-life example for when it is useful ?


___
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

2007-06-14 Thread Morten Welinder

 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.

M.
___
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

2007-06-14 Thread Tim Janik

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
 is disposed. the later also works for void* pointers.

 Oh, I knew I missed something.

 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 G_CONNECT_SWAPPED
  object: optional, if set use g_signal_connect_object

 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.

 g_signal_connect_object does not provide a way to send in user data so it
 conflicts with the user data which may be passed in to
 gtk_builder_connect_signals.

well, to be more precise, g_signal_connect_object hardcodes the assumption
that user_data is_a GObject*.

 Not a too big deal I guess, it just needs to be
 documented.

 Johan


---
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

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.

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

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 True, set flags to G_CONNECT_SWAPPED
   object: optional, if set use g_signal_connect_object
 
 I still don't understand how swapped is relevant in the XML context
 instead of in the C code actually connecting the handler. It looks like
 implementation detail to me, that should not be enforced by the XML
 file... The same applies for after and object.
 
 Do someone has a real-life example for when it is useful ?

It's the same use case as g_signal_connect_after, it's occasionally useful
to make sure that a handler is executed after all other handlers.

For instance you might want to play a movie which is draw on a drawing area,
but only start the playback after it's realized.

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

2007-06-14 Thread Damon Chaplin


 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!

Damon


___
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

2007-06-14 Thread Damon Chaplin

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 (name is just a internal reference, like a variable name in C). 
 By default this would be off (since most widgets are certainly not special 
 ones, you are not calling gtk_widget_set_name for each widget if you write 
 the UI by hand, do you...)

In Glade-2 for code generation it was a project-wide option, Set Widget
Names, and the default was FALSE (since few people use them).

If it was up to me I'd probably make it an optional GtkBuilder setting,
and default to FALSE again. Though it's not a big deal.

Damon


___
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

2007-06-14 Thread Damon Chaplin

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).

Damon


___
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

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.

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

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 gather ;)

  and since it does nothing(?) if the custom colors are
  not set...
 
  Also, why is it neccessary when the colors are not set explicitly?
  Isn't the class name as good as any for setting default values in
  themes?

 What's necessary? Let's not consider funny cases when nothing changed,
 think white cursor and white text color and black background in a usual
 black-on-white gtk theme (people actually do use dark themes, it's not
 some academic exercise about how to override theme colors).

I meant, why does the widget need to have the unique name even if the
cursor colors are not set? Maybe I missed that but I didn't see it set
anywhere in the initialization code so the unique name matches to
exactly nothing until someone sets it.

  The GtkSourceView code (and code above) was an example
  of code which uses unique widget name to modify style property,
  since you didn't seem to believe it is possible and may be
  needed.
 
  I never said it wouldn't be needed. I'm just saying that there is no
  reason to do it in construction stage,

 You were talking about class matching and whatnot, so I got
 that impression. Anyway, one possible reason is that constructor
 and init() are natural places for things which are done once for
 whole life of the widget. Another reason is that one may still
 change the name if he knows what he's doing (GtkBuilder doesn't
 and it's what sucks). Dunno, it just happened so. Now, If you want
 the widget to be used with GtkBuilder you must not set widget
 name until after construction. Why? No reason really, just because.
 It's silly.

Because the user gave it a name in the xml and would possibly like
that to be matchable from a gtkrc? If the application explicitly sets
the cursor color, well, then it's bye-bye for the end-user theme I
guess...

  since it will not give you
  anything over matching by class.

 That setting is *per-widget*, not per-class.

Unless it's not set, which means either the default value or the value
from any parsed gtkrc. Which was my point.

  If you need to hack styles in later,
  you can set the name then and hope the user doesn't go and change it
  afterwards. Also you can hope that the user didn't want to customize
  the theming of that widget by his own account and get angry at you
  since the widget changes it's name making it impossible...

 So there are possible problems (of course), so I shouldn't mind
 one more possible complication? Note that this latter complication
 is not related to theme business (as opposed to user changing styles
 manually and breaking things), it's just some strange function
 call in a place seemingly unrelated to the theme business.

manually as in gtkrc? I consider that the authority when it comes to
what style settings should be obeyed, if the application overrides
that... well. I guess it's your application.

For the record, I do understand[1] why the unique names and styles are
used. But since it is very error prone and unfriendly to themes when
done *inside* widgets (or even applications), I don't think it's worth
blocking a natural expectation of the user of GUI editors; that the
Name field in the editor will really be the name of the widget which
you can use in gtkrc:s for your own theming options.

If you now understand my POV (that's all I'm after), we could just
stop here (it's not like this is really constructive anymore ;)

[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).

-- 
Kalle Vahlman, [EMAIL PROTECTED]
Powered by http://movial.fi
Interesting stuff at http://syslog.movial.fi
___
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

2007-06-14 Thread Yevgen Muntyan

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 see what a style scheme is. Perhaps then you'll stop convicting
me of breaking user themes, expectations, and whatnot. These
talks about how things should be in general are nice but are not
to the point.
Could not resist, sorry.

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

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 interested, get a fresh tarball of gtksourceview
 and see what a style scheme is. Perhaps then you'll stop convicting
 me of breaking user themes, expectations, and whatnot. These
 talks about how things should be in general are nice but are not
 to the point.

Sure, but the basic issue was should widgets set their name in the
constructor[1]
Let's brew it down like this:

Me: njet.
You: da.

I think we are done here :)

[1] Regardless of what it is used for, I don't see style schemes
requiring that. In fact, I see benefit in making the style scheme be
the identifying one (not the widget) so it could be trivially
applyable to multiple widgets... But whatever.

-- 
Kalle Vahlman, [EMAIL PROTECTED]
Powered by http://movial.fi
Interesting stuff at http://syslog.movial.fi
___
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

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!

It might make sense to do the same for gtkbuilder, since libglade does the
same when you set the object attribute, that'd make it easier to migrate
from the older formats. Or just make the conversion scripts insert
swapped=yes when converting an old libglade file.

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

2007-06-13 Thread Matthias Clasen

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

Re: GtkBuilder Public API - Last call

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 having it done automatically by the build
functions[1], but the issue there was fixed by making the
autoconnection work properly when called multiple times.

Is there cases where autoconnecting on building would result in
premature calls to handlers? I'm thinking of some status-and-control
UI that needs to be synced on startup but for which re-setting the
same status is not a no-op... But I guess you could just block the
handlers in those cases.

[1] http://bugzilla.gnome.org/show_bug.cgi?id=172535#c100

-- 
Kalle Vahlman, [EMAIL PROTECTED]
Powered by http://movial.fi
Interesting stuff at http://syslog.movial.fi
___
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

2007-06-13 Thread Yevgen Muntyan

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 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.

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)

 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 style properties. Nevertheless
it happens, and widget name is one of tools for that. It is a documented
use which shouldn't break, isn't it?
How do you draw the line between implementation of a widget and
an application part exactly? Note that what you said makes it look
like calling gtk_widget_set_name() by a widget implementation is
not supposed to happen; while doing it by GtkBuilder is indeed right
and good; is it quite logical? GtkBuilder is more a user than the widget?

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

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 possible
to make it do anything sensible. Libglade doesn't support it in any
shape or form AFAIK (as it doesn't do objects).

 Programmers are also not supposed to set style properties. Nevertheless
 it happens, and widget name is one of tools for that. It is a documented
 use which shouldn't break, isn't it?
 How do you draw the line between implementation of a widget and
 an application part exactly? Note that what you said makes it look
 like calling gtk_widget_set_name() by a widget implementation is
 not supposed to happen; while doing it by GtkBuilder is indeed right
 and good; is it quite logical? GtkBuilder is more a user than the widget?

Yes, since GtkBuilder doesn't decide the name, the user does. Widgets
that rely on their name will break upon setting the name whether it is
the user with set_name() or the builder setting it, so there is no
reason to avoid this in GtkBuilder.

If a widget breaks down when you change the name, it's a bug in the
widget right?

By grepping the source for gtk_widget_set_name(), the references I see
there are for combobox popup window, toolbar arrow and tooltip window,
all of which are internal children and AFAIK shouldn't be referenced
in the UI descriptions anyway.

So I don't see what will break due to GtkBuilder setting the name
according to the users wishes. Do you have an example where this would
happen?

-- 
Kalle Vahlman, [EMAIL PROTECTED]
Powered by http://movial.fi
Interesting stuff at http://syslog.movial.fi
___
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

2007-06-13 Thread Paolo Maggi

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 other functions.

Ciao,
Paolo


___
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

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
 like you do in gtk_builder_value_from_string and other functions.

It is intended to allow UIManager-style merging and unmerging of UI
descriptions (in the future).

-- 
Kalle Vahlman, [EMAIL PROTECTED]
Powered by http://movial.fi
Interesting stuff at http://syslog.movial.fi
___
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

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_builder_value_from_string and other functions.
   
GtkBuilder is currently not supporting unmerging/merging of interfaces,
but it might do in the future. I changed the api to return an integer
instead of a boolean to be able to support that feature without
adding a new API.

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

2007-06-13 Thread Murray Cumming

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. It works well, and I don't know how
else I should do it.

-- 
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

Re: GtkBuilder Public API - Last call

2007-06-13 Thread Christian Persch

Hi;

 typedef void (*GtkBuilderConnectFunc) (GtkBuilder  *builder,
const gchar *handler_name,
GObject *object,
const gchar *signal_name,
GObject *connect_object,
gboolean after,
gpointer user_data);

Could we have GConnectFlags flags instead of gboolean after here, so
this could also support swapped handlers in future?

 void gtk_builder_connect_signals_full(GtkBuilder   *builder,
   GtkBuilderConnectFunc func,
   gpointer  user_data);

Why does this have no GDestroyNotify parameter for the user_data ?

Regards,
Christian



___
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

2007-06-13 Thread Tim Janik

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 program for the first gtk
toolkit builder ever ;)
   http://www.gtk.org/~timj/gubi/index.htm

 Should it include signals? How many widgets?

signals would be nice, e.g. to handle Close and delete-event, every GUI
app has/needs that anyway.

 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: GtkBuilder types (Re: GtkBuilder Public API - Last call)

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 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;

 parent is a bad name for a nested instance structure, 
 GtkWidget-parent is
 the best example for this. better use something like parent_instance 
 here,
 people are never supposed to access this member directly anyway (we 
 have our
 casting macros for getting at the parent types).


  GtkBuilderPrivate *priv;
 };


 /**
 * gtk_builder_get_type_from_name:
 * @builder: a #GtkBuilder
 * @typename: Type name to lookup.
 *
 * This method is used to lookup a type. It can be implemented in a 
 subclass to
 * override the #GType of an object created by the builder.
 *
 * Since 2.12
 */
 GTypegtk_builder_get_type_from_name  (GtkBuilder   *builder,
  const char   
 *typename);

 how is this different from g_type_from_name() ?
It is overridable by a GtkBuilder class,  it's needed by the c++ 
bindings which has
another GType for the wrappers.
Also, the default implementation tries to guess the name of the 
_get_type() function for
a type name if the type isn't registered yet, but that's an 
implementation detail.

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

Johan Dahlin wrote:
 Christian Persch wrote:
 Hi;

 typedef void (*GtkBuilderConnectFunc) (GtkBuilder  *builder,
const gchar *handler_name,
GObject *object,
const gchar *signal_name,
GObject *connect_object,
gboolean after,
gpointer user_data);
 Could we have GConnectFlags flags instead of gboolean after here, so
 this could also support swapped handlers in future?
 
 This was copied more or less directly from libglade, there's a certain
 advantage of making this compatible with the existing code.
 

Well, actually swapped handlers are supported, using the object attribute, eg:

  object class=GtkButton id=button/
  object class=GtkEntry id=entry
signal name=activate handler=button_clicked object=button/
  /object

 It definitely makes sense to support GConnectFlags though.

I thought there were other flags apart from after and swapped, so this is
not true, right?

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

2007-06-13 Thread Christian Persch

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,
 GObject *object,
 const gchar *signal_name,
 GObject *connect_object,
 gboolean after,
 gpointer user_data);
  Could we have GConnectFlags flags instead of gboolean after here, so
  this could also support swapped handlers in future?
  
  This was copied more or less directly from libglade, there's a certain
  advantage of making this compatible with the existing code.
  

I think I misunderstood the API. I thought |user_data| in
gtk_builder_connect_signals_full was the data that the signal handlers
get connected to, but it actually is the data that's passed to the
GtkBuilderConnectFunc function (and the signal handler data is always
NULL with the default builder func, unless it's a connect_object). That
probably makes a destroy notify unnecessary.

The API has no equivalent to glade_xml_signal_connect_data, so one needs
to implement that oneself with a custom connect function?

 Well, actually swapped handlers are supported, using the object attribute, eg:
 
   object class=GtkButton id=button/
   object class=GtkEntry id=entry
 signal name=activate handler=button_clicked object=button/
   /object

The default builder func uses SWAPPED for this case, yes (why?). I don't
see why every builder func would do the same though, so a way to hint
that from the XML would needed.

  It definitely makes sense to support GConnectFlags though.
 
 I thought there were other flags apart from after and swapped, so this is
 not true, right?

The only flags that exist now are G_CONNECT_AFTER and G_CONNECT_SWAPPED.

Regards,
Christian

___
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

2007-06-13 Thread markku . vire


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 scenario:

  data = g_new(...);
  ...
  gtk_builder_connect_signals_with_data(builder, data, g_free);

and now the memory is freed once per signal connected... Of course this is a 
programmers mistake (no proper refcounting), but I think it would 
be good to place a warning into the documentation? 

-Markku-

Lainaus Johan Dahlin [EMAIL PROTECTED]:

  Of course one can use connect_full variant to achieve this, but that
  also means that GModule-related code needs to be written into app.
 
 Exactly, I think this use case is valid to avoid duplicating that code.
 
 I see two possible solutions;
 
 1) Change gtk_builder_connect_signals () to accept a gpointer to the
user data
 2) Add a new method  which is similar to gtk_builder_connect_signals but
accepts user_data and perhaps a GDestroyNotify.
 
 Any preference? I'm leaning towards the latter.
 
 -- 
 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

2007-06-13 Thread Matthias Clasen

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 style properties. Nevertheless
 it happens, and widget name is one of tools for that. It is a documented
 use which shouldn't break, isn't it?
 How do you draw the line between implementation of a widget and
 an application part exactly? Note that what you said makes it look
 like calling gtk_widget_set_name() by a widget implementation is
 not supposed to happen; while doing it by GtkBuilder is indeed right
 and good; is it quite logical? GtkBuilder is more a user than the widget?

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 the app.
___
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

[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 a big deal.

 Putting a DestroyNotify there will create the following (easy) bug scenario:

Actually a GDestroyNotify is probably not a very good idea since the life
cycle of the data structure is normally not tied to the process of
connecting the signals.

-- 
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

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,
GObject *object,
const gchar *signal_name,
GObject *connect_object,
gboolean after,
gpointer user_data);
 Could we have GConnectFlags flags instead of gboolean after here, so
 this could also support swapped handlers in future?
 This was copied more or less directly from libglade, there's a certain
 advantage of making this compatible with the existing code.

 
 I think I misunderstood the API. I thought |user_data| in
 gtk_builder_connect_signals_full was the data that the signal handlers
 get connected to, but it actually is the data that's passed to the
 GtkBuilderConnectFunc function (and the signal handler data is always
 NULL with the default builder func, unless it's a connect_object). That
 probably makes a destroy notify unnecessary.
 
 The API has no equivalent to glade_xml_signal_connect_data, so one needs
 to implement that oneself with a custom connect function?

Right, I didn't add these.
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.

 Well, actually swapped handlers are supported, using the object attribute, 
 eg:

   object class=GtkButton id=button/
   object class=GtkEntry id=entry
 signal name=activate handler=button_clicked object=button/
   /object
 
 The default builder func uses SWAPPED for this case, yes (why?). I don't
 see why every builder func would do the same though, so a way to hint
 that from the XML would needed.

It uses swapped because you specified an object you want to connect the
signal to, if you remove the object it'll connect without using swapped.

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

2007-06-13 Thread Christian Persch

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 add that user_data
argument. CONNECT_SWAPPED still needs to be handled in this case,
however.

Regards,
Christian

___
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

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 separate connect_data if we add that user_data
 argument. CONNECT_SWAPPED still needs to be handled in this case,
 however.

I can't see a use case where sending in a user_data and CONNECT_SWAPPED at
the same time makes sense. Do you know of one?

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

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 how a widget behaves when in a certain state,
objects that animate widget-window etc etc), I've found that in
an object heirarchy, as soon as one object owns one or more
other objects; packing properties are an essential thing.

So these are the points I want to raise specifically:
   - Do we want support for virtual properties ?
 (properties handled by the GtkBuildable instance but are
 not handled on the object and have no GParamSpec), examples
 of use cases are the exceptions coded into libglade's glade-gtk.c

 Ideally I think we dont need to support them, but they could
 turn out handy so I'm just pointing it out. (note that I
 implemented this as creating them by GParamSpecString properties
 in my patch suite[1], so it doesnt represent alot of work)

   - GtkBuilder still doesnt handle packing properties, GtkContainer
 treats them like a special case, making it difficult for child
 gtkcontainers to do anything for buildable-child_set_property()
 and chain up to its parent implementation (i.e. lots of voodoo
 has to be done to parse them manually using the custom_start/end
 stuff, also leaving it unclear if chaining up is even possible
 here).

 Again, I already did this work in my patch suite so it doesnt
 represent alot of work (I can refit individual patches against
 Johans work for this if so desired)

 I really consider packing properties essential and I really hope
 that the builder will recognize them as something more than just 
 an anomaly of GtkContainerClass.

   - One step further - For the time being we dont have a GContainer
 iface, so packing properties on non-GtkContainer objects cannot
 be introspected, for this I request that packing properties be
 passed along as GParamSpecString properties (like I did with
 virtual properties), so that non-GtkContainer GObjects dont have
 to write custom parser voodoo just to support packing properties.
 (This ofcourse is redundantly also available in the work I did
 for GtkBuilder, and ofcourse I can port it in...)


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:
 
   object class=GtkButton id=button/
   object class=GtkEntry id=entry
 signal name=activate handler=button_clicked object=button/
   /object

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.

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

On Wed, 2007-06-13 at 10:01 -0300, Johan Dahlin wrote:
 GtkBuilder is currently not supporting unmerging/merging of
 interfaces,
 but it might do in the future. I changed the api to return an integer
 instead of a boolean to be able to support that feature without
 adding a new API.

I think this is a little offtopic but since it was raised here's
my opinion; I think that merging/unmerging shouldnt be tied into
the builder, some containers could implement GtkMergable, even
GtkContainer could provide a default implementation (menus might
get treated differently etc).


Cheers,
  -Tristan


[1]http://bugzilla.gnome.org/show_bug.cgi?id=383035


___
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 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 ammend my mistype here, I meant to say:

  object class=GtkEntry id=entry
signal name=activate handler=button_clicked swapped=True/  
 /object

-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

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 delagate GObjects in the widget hierarchy
 (objects that define how a widget behaves when in a certain state,
 objects that animate widget-window etc etc), I've found that in
 an object heirarchy, as soon as one object owns one or more
 other objects; packing properties are an essential thing.

To me this is outside of the scope of the current builder, but not
impossible to support in the future.

I'd like GtkBuilder primarily support what libglade does but also support
newer features such as treeview, ui mananger and non-widget properties
in general.

 So these are the points I want to raise specifically:
- Do we want support for virtual properties ?
  (properties handled by the GtkBuildable instance but are
  not handled on the object and have no GParamSpec), examples
  of use cases are the exceptions coded into libglade's glade-gtk.c

  Ideally I think we dont need to support them, but they could
  turn out handy so I'm just pointing it out. (note that I
  implemented this as creating them by GParamSpecString properties
  in my patch suite[1], so it doesnt represent alot of work)

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 are a different use case from virtual properties
since they are real, it's just that their behavior changes a little,
setting these properties are just delayed until the parsing is finished.

- GtkBuilder still doesnt handle packing properties, GtkContainer
  treats them like a special case, making it difficult for child
  gtkcontainers to do anything for buildable-child_set_property()
  and chain up to its parent implementation (i.e. lots of voodoo
  has to be done to parse them manually using the custom_start/end
  stuff, also leaving it unclear if chaining up is even possible
  here).
 
  Again, I already did this work in my patch suite so it doesnt
  represent alot of work (I can refit individual patches against
  Johans work for this if so desired)
 
  I really consider packing properties essential and I really hope
  that the builder will recognize them as something more than just 
  an anomaly of GtkContainerClass.

I still have the opinion that the builder shouldn't need to know about
packing properties, since it's something which is specific to the relation
of GtkContainer and their children.
In the same way as attributes are specific to anything implementing cell
layout and cell renderers.

Which are the custom packing properties you want to support anyway?
Seems like me that some of them are handled (expander,frame,notebook),
some of them not needed (menus, toolbar, layout) and the rest on deprecated
widgets (clist).

- One step further - For the time being we dont have a GContainer
  iface, so packing properties on non-GtkContainer objects cannot
  be introspected, for this I request that packing properties be
  passed along as GParamSpecString properties (like I did with
  virtual properties), so that non-GtkContainer GObjects dont have
  to write custom parser voodoo just to support packing properties.
  (This ofcourse is redundantly also available in the work I did
  for GtkBuilder, and ofcourse I can port it in...)

Something like this would be better, to have an api which would
define a relation between an object and a children.
I don't know how this should be done right now, but it could easily be
supported in the future without breaking the API, such as adding
a couple of new vfuncs to the GtkBuildable class.

 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:

   object class=GtkButton id=button/
   object class=GtkEntry id=entry
 signal name=activate handler=button_clicked object=button/
   /object
 
 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.
 
 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

I mainly kept this for Glade compatibility, I'd be happy to remove the
object attribute if it's not something you're keen to support.

 On Wed, 2007-06-13 at 10:01

Re: GtkBuilder Public API - Last call

2007-06-13 Thread Steve Frécinaux

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 file, but set
while actually connecting the widget.

A (bad, but demonstrative enough) example:

  g_signal_connect_swapped (window-close_button, clicked,
G_CALLBACK (gtk_widget_destroy), window);

vs

  void close_button_clicked (GtkButton *button, GtkWidget *window)
  {
g_print (close button clicked !\n);
gtk_widget_destroy (window);
  }

  g_signal_connect (window-close_button, clicked,
G_CALLBACK (close_button_clicked), window);

This shows that it's really an implementation detail that shouldn't
appear in the XML. It would be error prone and would require to edit
the interface when the implementation change (thus breaking the VC
separation, and, more importantly, would be unhandy).

So I second Christian Persch's suggestion of using CONNECT_SWAPPED and
Tristan's one of dropping the connect_object convention as well.

___
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

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 widget.
 
  Programmers are also not supposed to set style properties. Nevertheless
  it happens, and widget name is one of tools for that. It is a documented
  use which shouldn't break, isn't it?
  How do you draw the line between implementation of a widget and
  an application part exactly? Note that what you said makes it look
  like calling gtk_widget_set_name() by a widget implementation is
  not supposed to happen; while doing it by GtkBuilder is indeed right
  and good; is it quite logical? GtkBuilder is more a user than the widget?

 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 the app.

Furthermore, if my (admittedly quick) glance over how the object names
are handled is not misguided, GtkBuilder sets the name once and never
checks it again. It has an internal hash table in which it stores the
id in the xml and all lookups use that instead of referring to the
actual name.

So even if GtkBuilder sets the initial name to what is in the xml, you
should be able to change it afterwards to whatever you like without
everything going bork bork.

A quick test shows that I can indeed match my widget by the fancy name
I gave it in the code in a gtkrc, while the lookup returns the correct
object with the xml id.

So this shouldn't be a problem...

-- 
Kalle Vahlman, [EMAIL PROTECTED]
Powered by http://movial.fi
Interesting stuff at http://syslog.movial.fi
___
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 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 are a different use case from virtual properties
 since they are real, it's just that their behavior changes a little,
 setting these properties are just delayed until the parsing is finished.

Definitly agreed here.

 
 - GtkBuilder still doesnt handle packing properties, GtkContainer
   treats them like a special case, making it difficult for child
   gtkcontainers to do anything for buildable-child_set_property()
   and chain up to its parent implementation (i.e. lots of voodoo
   has to be done to parse them manually using the custom_start/end
   stuff, also leaving it unclear if chaining up is even possible
   here).
  
   Again, I already did this work in my patch suite so it doesnt
   represent alot of work (I can refit individual patches against
   Johans work for this if so desired)
  
   I really consider packing properties essential and I really hope
   that the builder will recognize them as something more than just 
   an anomaly of GtkContainerClass.
 
 I still have the opinion that the builder shouldn't need to know about
 packing properties, since it's something which is specific to the relation
 of GtkContainer and their children.
 In the same way as attributes are specific to anything implementing cell
 layout and cell renderers.
 
 Which are the custom packing properties you want to support anyway?
 Seems like me that some of them are handled (expander,frame,notebook),
 some of them not needed (menus, toolbar, layout) and the rest on deprecated
 widgets (clist).

Here's an example, lets say I have an animated widget, the widget
has a State object for every state 
(up/down/insensitive/insert your flavour here), every State can
have a number of Animations, there can be an Animation object that
defines the visual aspect of the current state, other Animations
can be added as intro's for when performing transitions from other
animated states (like when your icon goes from running to doing
cartwheels, you need to add the correct transition animation).

I use packing properties to tell State down that its Animation 
child is in fact the intro for passing from State up (and possibly
another as an intro from State disabled).

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.

 
 - One step further - For the time being we dont have a GContainer
   iface, so packing properties on non-GtkContainer objects cannot
   be introspected, for this I request that packing properties be
   passed along as GParamSpecString properties (like I did with
   virtual properties), so that non-GtkContainer GObjects dont have
   to write custom parser voodoo just to support packing properties.
   (This ofcourse is redundantly also available in the work I did
   for GtkBuilder, and ofcourse I can port it in...)
 
 Something like this would be better, to have an api which would
 define a relation between an object and a children.
 I don't know how this should be done right now, but it could easily be
 supported in the future without breaking the API, such as adding
 a couple of new vfuncs to the GtkBuildable class.

Ok point taken, the builder is a vast feature with many possibilities,
it would be next to impossible to satisfy everyones demands at once so
the main concern here is compatability and room for improvement.

We can add GContainer iface for introspection of packing properties on
non-GtkContainer objects in the future, and add child_set_property()
vfunc to the buildable as its counterpart - I would really like to
get this aspect in sooner than later (and hopefully not forgotton)
but what matters now is to land the friggn builder so we can start
working on it :)

  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:
 
object class=GtkButton id=button/
object class=GtkEntry id=entry
  signal name=activate handler=button_clicked object=button/
/object
  
  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.
  
  Can we please not swap signal handlers unless they are
  explicitly specified ?
  
object class=GtkEntry id=entry
  signal

Re: GtkBuilder Public API - Last call

2007-06-13 Thread Yevgen Muntyan

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 the implementation of a widget.
 
 Programmers are also not supposed to set style properties. Nevertheless
 it happens, and widget name is one of tools for that. It is a documented
 use which shouldn't break, isn't it?
 How do you draw the line between implementation of a widget and
 an application part exactly? Note that what you said makes it look
 like calling gtk_widget_set_name() by a widget implementation is
 not supposed to happen; while doing it by GtkBuilder is indeed right
 and good; is it quite logical? GtkBuilder is more a user than the widget?
   
 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 the app.
 

And widget isn't part of the app? Such separation is meaningless for
purpose of answering the question should we change code of given
widget if we want the widget to be usable with GtkBuider?

So, if a widget sets its name to modify its style, then
it's broken? Even if the style is essential part of its functionality?
E.g. text cursor color is not something fancy, it's an essential part
of text widget and it rather sucks if cursor is invisible because of
wrong styles. Saying it's broken because it is somehow
not a part of application just doesn't make sense.

 Furthermore, if my (admittedly quick) glance over how the object names
 are handled is not misguided, GtkBuilder sets the name once and never
 checks it again. It has an internal hash table in which it stores the
 id in the xml and all lookups use that instead of referring to the
 actual name.

 So even if GtkBuilder sets the initial name to what is in the xml, you
 should be able to change it afterwards to whatever you like without
 everything going bork bork.
   

I said already what could be a problem. get_widget_by_name()
is irrelevant.

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 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 to be an application/user feature,
  not something thats used in the implementation of a widget.
  
  Programmers are also not supposed to set style properties. Nevertheless
  it happens, and widget name is one of tools for that. It is a documented
  use which shouldn't break, isn't it?

Sure programmers are supposed to set style properties, in thier custom
gtkrc that they distribute with thier app in thier custom environment.
its just not something people generally do in the desktop world, which
is just one popular use case of gtk+, but gtk+ is not the desktop, and
skinning your widgets by name is an important feature of gtk+.

  How do you draw the line between implementation of a widget and
  an application part exactly? Note that what you said makes it look
  like calling gtk_widget_set_name() by a widget implementation is
  not supposed to happen; while doing it by GtkBuilder is indeed right
  and good; is it quite logical? GtkBuilder is more a user than the widget?

  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 the app.
  
 
 And widget isn't part of the app? Such separation is meaningless for
 purpose of answering the question should we change code of given
 widget if we want the widget to be usable with GtkBuider?

libglade set the widget name according to the name specified in the xml,
afaics so does the builder right ? so how does the bulder differ from
how libglade did it and where is the breakage ?

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

2007-06-13 Thread Yevgen Muntyan

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 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 style properties. Nevertheless
 it happens, and widget name is one of tools for that. It is a documented
 use which shouldn't break, isn't it?
   

 Sure programmers are supposed to set style properties, in thier custom
 gtkrc that they distribute with thier app in thier custom environment.
 its just not something people generally do in the desktop world, which
 is just one popular use case of gtk+, but gtk+ is not the desktop, and
 skinning your widgets by name is an important feature of gtk+.
   

Custom gtkrc distributed with application is only one such use.
Does gedit count as a desktop application? It uses this thing, and
it uses it not for skins-like stuff.
As to skins-like stuff, it's also an interesting part. Shouldn't it be
supported directly in glade/builder, so that you could set widget
name to my-fancy-button for all five fancy buttons in your
player UI (perhaps it doesn't make sense, I've never done stuff
like xmms)?

   
 How do you draw the line between implementation of a widget and
 an application part exactly? Note that what you said makes it look
 like calling gtk_widget_set_name() by a widget implementation is
 not supposed to happen; while doing it by GtkBuilder is indeed right
 and good; is it quite logical? GtkBuilder is more a user than the widget?
   
   
 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 the app.
 
 
 And widget isn't part of the app? Such separation is meaningless for
 purpose of answering the question should we change code of given
 widget if we want the widget to be usable with GtkBuider?
 

 libglade set the widget name according to the name specified in the xml,
 afaics so does the builder right ? so how does the bulder differ from
 how libglade did it and where is the breakage ?
   

There is no formal breakage. It's just that some widgets need to
be made GtkBuilder-ready if one wants to use them with GtkBuilder,
and there possible some funny bugs caused by GtkBuilder doing
wrong thing (if some code will assume that widget has name
set from xml, and so on). As I said, libglade example is not good simply
because until recently (before glade-3 that is) people simply didn't use
custom widgets much with glade, something that hopefully will change
(and *then* people are more likely to use xml for fancy things since
it won't require an additional library).
Um, if it's not clear, what libglade does is wrong, but it has not much
choice - abusing gtk_widget_set_name() is tiny comparing to making people
happy that get_name() returns name from xml. Gtk now gets
gtk_buildable_set/get_name which could do the right thing, without mixing
glade xml and styles.

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

2007-06-13 Thread Samuel Cormier-Iijima


/**

* 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 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?

--

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



___
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

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 from.
 *
 * Return value: converted enum value
 *
 * Since: 2.12
 */
 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.

-- 
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

2007-06-13 Thread Morten Welinder

 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

Re: GtkBuilder Public API - Last call

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 everyone 
to agree
on API:s in gtk, let alone glib.

The consent so far has been to include GtkBuilder more or less how it
is right how and eventually deprecate parts of the API if replacements
are introduced in glib.

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

2007-06-12 Thread Havoc Pennington

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

Re: GtkBuilder Public API - Last call

2007-06-12 Thread Johan Dahlin

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

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

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:

 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

2007-06-12 Thread Philip Withnall

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 link linkend=BUILDER-UIGtkBuilder UI
 definition/link 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 link linkend=BUILDER-UIGtkBuilder UI
 definition/link 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

Re: GtkBuilder Public API - Last call

2007-06-12 Thread Havoc Pennington

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

2007-06-12 Thread Steve Frécinaux

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

2007-06-12 Thread Johan Dahlin

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

2007-06-12 Thread Steve Frécinaux

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

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 link linkend=BUILDER-UIGtkBuilder UI definition/link 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

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

2007-06-12 Thread Johan Dahlin

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 link linkend=BUILDER-UIGtkBuilder UI definition/link 
 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

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 link linkend=BUILDER-UIGtkBuilder UI definition/link 
 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

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

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

2007-06-12 Thread Kouhei Sutou

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 link linkend=BUILDER-UIGtkBuilder UI
 definition/link 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