date:20070614

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

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

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: The new tooltips API in 5 minutes [Was: Re: Whats coming in GTK+ 2.12, continued]

2007-06-14 Thread Tshepang Lekhonkhobe

On 6/12/07, Kristian Rietveld [EMAIL PROTECTED] wrote:
 On Sun, Jun 10, 2007 at 10:38:44AM +0200, Murray Cumming wrote:
  There's also a new GtkTooltip object. Could we have some more information
  about how this should be used and if it replaces any existing API, please?

 Sure ;)  As Matthias pointed out in one of his other mails, GTK+ 2.12
 has a brand-new API for doing tooltips, replacing the aging GtkTooltips
 object.  There are several ways for showing tooltips using the new API,
 increasing in complexity as the complexity of the wished tooltip
 increases:

[blah blah]

Would be nice if this could be in some the tutorial or something.

-- 
my place on the web:
floss-and-misc.blogspot.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

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

gtk+ compile

2007-06-14 Thread Jeevan


Dear all,
Here I am trying to run a simple GUI program using Gtk+..
I am getting error as follows:  

linux:~ # gcc base.c -o base 'pkg-config --cflags --libs gtk+-2.0'
gcc: pkg-config --cflags --libs gtk+-2.0: No such file or directory
base.c:1:21: gtk/gtk.h: No such file or directory
base.c: In function `main':
base.c:6: error: `GtkWidget' undeclared (first use in this function)
base.c:6: error: (Each undeclared identifier is reported only once
base.c:6: error: for each function it appears in.)
base.c:6: error: `window' undeclared (first use in this function)
base.c:10: error: `GTK_WINDOW_TOPLEVEL' undeclared (first use in this
function)
 

Thank you very much in advance..

Regards
JivanDear all,
Here I am trying to run a simple GUI program using Gtk+..
I am getting error as follows:  

linux:~ # gcc base.c -o base 'pkg-config --cflags --libs gtk+-2.0'
gcc: pkg-config --cflags --libs gtk+-2.0: No such file or directory
base.c:1:21: gtk/gtk.h: No such file or directory
base.c: In function `main':
base.c:6: error: `GtkWidget' undeclared (first use in this function)
base.c:6: error: (Each undeclared identifier is reported only once
base.c:6: error: for each function it appears in.)
base.c:6: error: `window' undeclared (first use in this function)
base.c:10: error: `GTK_WINDOW_TOPLEVEL' undeclared (first use in this
function)
 

Thank you very much in advance..

Regards
Jivan
-- 
View this message in context: 
http://www.nabble.com/gtk%2B-compile-tf3921352.html#a8812
Sent from the Gtk+ - Dev - General mailing list archive at Nabble.com.

___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Command Buffer for Accessing Menus

2007-06-14 Thread ricardo colon

Hello GTKers.

I apologize for the cross post. I confused the people who develop with GTK
mailing list for the people that develop GTK mailing list.

I posted the following email to the Ardour(http://ardour.org) development group.
One of the replies suggested that maybe my feature request is better suited at
the GTK level.

So here I am.

Here's the email I sent to the Ardour devel mailing list.
Tell me what you think about such a feature being in GTK.

--

Many times, I feel that having to drag over a mouse to a drop down
menu and move down to the correct menu takes too much time and
distracts me. By the time I reach the menu, my mind has drifted off to
something else for a moment.

I was thinking it might be cool to have something similar to Emacs
command buffer. This buffer would be used for directly accessing
menus. But instead of using obscure keyboard shortcuts, it would use
keywords.

For example, let's say Ardour has a menu called Automation.
You would type something like Ctrl-X and then type in Automation.
The Automation menu would directly pop-up. You wouldn't have to go
through Tools - Midi - Automation or anything like that.

Automation would be the full-length keyword. To make things quicker,
you could have a full name and maybe a shorter name. So for example,
you could type Ctrl-X automation or Ctrl-X atm. and it would mean
the same thing.

Even better, you could assign common command buffer commands to a
single key. So you could bind Ctrl-X atm to Ctrl-F1 or something
similar.

Not only would you be able to access menus in the drop down list at
the top of the screen, but you could also directly access sub-menus as
well(instead of having to click through 3 or 4 menus to get
where you want).

In the beginning, you could have this work for the standard menus.
But you could also have user-defined keywords for things like plugins.
Imagine if you had a plugin called reverb. You'd highlight a portion
of the audio, hit Ctrl-X reverb and it would immediately bring up
the reverb plugin (with the selected audio as input if you want to).

Anyway, that's the gist of my idea. I think keywords would be very
intuitive for people and would work well across many platforms. You
wouldn't even have to worry about keyboard shortcuts convention across
different platforms. And I think it's much more efficient than using
the mouse in many cases.

-
This could even work for something like GIMP.

Highlight a selection, type Ctrl-x smudge and the Smudge menu might appear
with the current region already selected as input. In addition, you
might be able
to directly access script-fu plugins.

In any case, I'm not sure where such code would go, but it'd
definitely be a killer feature. I'm sure there's probably some way
to hack up something to emulate this kind of behavior. But I think
it'd be great if there was somebkind of pluggable GTK architecture
that all apps could support by providing the right hooks.

Maybe the command buffer portion doesn't need to be mandatory. It
could just be one of many different views or interfaces that could be
used. For example, you could use a Wii remote :-)

Anyway, Hope I'm not wasting anyone's time.
Thanks.
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: VFS for legacy apps (was: gvfs status report)

2007-06-14 Thread Jerome Haltom

On Thu, 2007-02-22 at 17:39 -0500, Sean Middleditch wrote:
 Just a reminder that : is the separator used in the PATH environment
 variable, and is thus a poor choice for use in directories.
 
 In all honesty, if the intended use case for reading the directory info
 is for FUSE and GVFS, I think it would be a lot cleaner to just put some
 kind of user-friendly name in ~/.mounts/, and then create a ~/.mountrc
 config file that maps the names to mount parameters which the FUSE fs
 and GVFS can use to recreate the mount points.  Basically, it'd just be
 a per-user fstab replacement.

I want to make sure this takes NFS mounted home directories into
consideration. I think perhaps ~ is a very poor choice of location for
this.

 
 Add in a few CLI utils to call mount with the right parameters for
 mounts in ~/.mountrc, and you'll have a pretty solid system for both
 modern GUI, legacy GUI, and CLI users.
 
  You're probably always going to need type, server and share though, so
  maybe you can make it a bit more readable:
  
~/.mounts/smb:$server:$share/dir/file.txt
  
  Extra options can go on the end.
  
  Also I'd probably avoid ';' just in case bash goes anywhere near it.
 
  Sure, those are requred. But say we have two optional things, like user
  and domain, as in smb:server:share:user:domain. But what do we then do
  if user is unset, but domain isn't. I guess one could do
  smb:server:share::domain. Still, it requires very specific handling of
  each type of share with a specified option order etc. A key=value
  approach is more generic.

___
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: gtk+ compile

2007-06-14 Thread Emmanuele Bassi

On Thu, 2007-06-14 at 05:04 -0700, Jeevan wrote:
 Dear all,
 Here I am trying to run a simple GUI program using Gtk+..

this list is for developing gtk+, not developing with gtk+. you want
gtk-list or gtk-app-devel-list.

 I am getting error as follows:  
 
 linux:~ # gcc base.c -o base 'pkg-config --cflags --libs gtk+-2.0'
 gcc: pkg-config --cflags --libs gtk+-2.0: No such file or directory

you have to use backticks: `

ciao,
 Emmanuele.

-- 
Emmanuele Bassi,
W: http://www.emmanuelebassi.net
B: http://log.emmanuelebassi.net

___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

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: The new tooltips API in 5 minutes [Was: Re: Whats coming in GTK+ 2.12, continued]

2007-06-14 Thread BJörn Lindqvist

On 6/12/07, Kristian Rietveld [EMAIL PROTECTED] wrote:
 On Sun, Jun 10, 2007 at 10:38:44AM +0200, Murray Cumming wrote:
  There's also a new GtkTooltip object. Could we have some more information
  about how this should be used and if it replaces any existing API, please?

 Sure ;)  As Matthias pointed out in one of his other mails, GTK+ 2.12
 has a brand-new API for doing tooltips, replacing the aging GtkTooltips
 object.  There are several ways for showing tooltips using the new API,
 increasing in complexity as the complexity of the wished tooltip
 increases:

A new API called GtkTooltip replaces an API called GtkTooltips?
Seems like that could become very confusing.. especially when using
two or more GtkTooltips. Couldn't you have came up with something a
little more imaginative? :)

-- 
mvh Björn
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Menu groups vs. use of separators

2007-06-14 Thread Alex Jones

On Thu, 2007-06-14 at 08:15 +0200, Sven Neumann wrote:
 Hi,
 
 On Thu, 2007-06-14 at 03:26 +0100, Alex Jones wrote:
 
  I've been looking at how Rhythmbox allows plugins to manipulate menus
  (via UI manager magic), and it dawned on me that there is no way to
  separate these out visually, other than to attempt to guess whether
  there should be a separator placed above and/or below what you're trying
  to insert. Of course, what I really want GTK to do is to insert
  separators *between* groups of menu items. Having this kind of ability
  would greatly simplify much goofy logic that is currently in place in a
  lot of applications to decide where separators should be placed.
 
 You can already do that using GtkUIManager. Your application should add
 placeholders for the groups that you described. Then add separators
 between the placeholders. Plug-ins can then register in the placeholder
 items. The smart separators will only be shown when needed.

OK, but I need to know how many groups are needed here in advance. I'm
not sure this solves the problem, because when I go to programatically
add another group to the end of the list I have to decide whether there
is a separator already at the end or not.
-- 
Alex Jones
http://alex.weej.com/

___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: The new tooltips API in 5 minutes [Was: Re: Whats coming in GTK+ 2.12, continued]

2007-06-14 Thread Jeff Waugh

quote who=BJörn Lindqvist

 A new API called GtkTooltip replaces an API called GtkTooltips?  Seems
 like that could become very confusing.. especially when using two or more
 GtkTooltips. Couldn't you have came up with something a little more
 imaginative? :)

Perhaps GtkTooltipEx?



























































GtkTooltippr?

Haw haw. :-)

- Jeff

-- 
Ubuntu Live 2007: Portland, OR, USA   http://www.ubuntulive.com/
 
 Laughter is a force for democracy. - John Cleese
___
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

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: Menu groups vs. use of separators

2007-06-14 Thread Matthias Clasen

On 6/14/07, Alex Jones [EMAIL PROTECTED] wrote:
 On Thu, 2007-06-14 at 08:15 +0200, Sven Neumann wrote:
  Hi,
 
  On Thu, 2007-06-14 at 03:26 +0100, Alex Jones wrote:
 
   I've been looking at how Rhythmbox allows plugins to manipulate menus
   (via UI manager magic), and it dawned on me that there is no way to
   separate these out visually, other than to attempt to guess whether
   there should be a separator placed above and/or below what you're trying
   to insert. Of course, what I really want GTK to do is to insert
   separators *between* groups of menu items. Having this kind of ability
   would greatly simplify much goofy logic that is currently in place in a
   lot of applications to decide where separators should be placed.
 
  You can already do that using GtkUIManager. Your application should add
  placeholders for the groups that you described. Then add separators
  between the placeholders. Plug-ins can then register in the placeholder
  items. The smart separators will only be shown when needed.

 OK, but I need to know how many groups are needed here in advance. I'm
 not sure this solves the problem, because when I go to programatically
 add another group to the end of the list I have to decide whether there
 is a separator already at the end or not.
 --

That is the bit that smart separators save you from. They hide when
they end up next to the edge of the menu or next to another separator.
___
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: The new tooltips API in 5 minutes [Was: Re: Whats coming in GTK+ 2.12, continued]

Kristian Rietveld wrote:
 [snip]
 In the GTK+ source code you will find a test app testing all of the
 above methods in gtk+/tests/testtooltips.c.  There are examples for
 simple tooltips on buttons (also insensitive buttons!), tooltips on
 GtkTreeView rows, tooltips on GtkTextView tags and a small example with
 tooltips on specific areas of a GtkDrawingArea.  (Yes, I know the tree
 view example is a little broken -- it will be fixed RSN).
   

Tooltips do not show at all here. Sometimes, when I put mouse
over a colored rectangle or label text, and then move mouse
away, tooltip shows up for a fraction of second. It's fresh
Gtk from today svn. And I didn't break it! Selection in the treeview
is blue, so it indeed gets focus. Tooltips are working in gtk-demo's
main application window.

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