Gtk2 1.152 (unstable) available

classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

Gtk2 1.152 (unstable) available

Torsten Schoenfeld
Overview of changes in Gtk2 1.152
=================================

* Make Gtk2::TreeModelSort::convert_child_iter_to_iter usable.  [Adrian
  Priscak, muppet]
* Make sure calling get() on a Gtk2::TreeModelSort resolves to
  Gtk2::TreeModel::get if appropriate.  [Torsten]
* Fix string encoding problems in Gtk2::Editable's insert-text signal
  marshaller.  [Roderich Schupp]
* Handle the recent deprecation of gtk_about_dialog_[sg]et_name and the removal
  of the "name" property.  [Torsten, muppet]
* Add support for GtkTooltip.  [Torsten]
* Add support for the pango gravity stuff.  [Torsten]
* Add support for GtkRecentAction.  [Torsten]
* Add support for GtkScaleButton and GtkVolumeButton.  [Torsten]
* Add support for GtkBuilder.  [Torsten]
* New API:  [Torsten]
  - gdk_event_request_motions
  - gtk_action_create_menu
  - gtk_entry_completion_set_inline_selection,
    gtk_entry_completion_get_inline_selection,
    gtk_entry_completion_get_completion_prefix,
    gtk_entry_set_cursor_hadjustment and gtk_entry_get_cursor_hadjustment
  - gtk_icon_theme_list_contexts and gtk_icon_theme_choose_icon
  - gtk_page_setup_new_from_file, gtk_page_setup_to_file,
    gtk_page_setup_new_from_key_file, and gtk_page_setup_to_key_file
  - gtk_paper_size_new_from_key_file, gtk_paper_size_to_key_file, and
    gtk_paper_size_get_paper_sizes
  - gtk_print_settings_new_from_file, gtk_print_settings_to_file,
    gtk_print_settings_new_from_key_file, and gtk_print_settings_to_key_file
  - gtk_text_mark_new
  - gtk_text_buffer_add_mark
  - gtk_tree_view_column_get_tree_view,
    gtk_tree_view_convert_widget_to_tree_coords,
    gtk_tree_view_convert_tree_to_widget_coords,
    gtk_tree_view_convert_widget_to_bin_window_coords,
    gtk_tree_view_convert_bin_window_to_widget_coords,
    gtk_tree_view_convert_tree_to_bin_window_coords, and
    gtk_tree_view_convert_bin_window_to_tree_coords
  - gtk_widget_set_tooltip_window, gtk_widget_get_tooltip_window,
    gtk_widget_trigger_tooltip_query, gtk_widget_set_tooltip_text,
    gtk_widget_get_tooltip_text, gtk_widget_set_tooltip_markup,
    gtk_widget_get_tooltip_markup, and gtk_widget_modify_cursor
  - gtk_window_set_startup_id, gtk_window_set_opacity, and
    gtk_window_get_opacity
  - PangoLogAttr property is_expandable_space
  - pango_cairo_context_set_shape_renderer
  - pango_color_to_string

This is an unstable development release of Gtk2, containing new
features and other cool stuff that have been added since the 1.14x
stable series.  Report any bugs to gtk-perl-list AT gnome DOT org as
soon as possible.  Please use the stable 1.14x series for important
work.

The source code is available from the gtk2-perl project page on  
sourceforge:

http://sourceforge.net/project/showfiles.php?group_id=64773&package_id=91218&release_id=518321

...and from anonymous cvs, tagged "rel-1-15-2" in the directory  
/gtk2-perl-xs/Gtk2.

This module requires these other modules and libraries:

   perl >= 5.8.0
   Glib >= 1.151 (perl module)
   GTK+ > 2.x (C library and prerequisites)

If GTK+ is as new or newer as 2.8, the Cairo module is also required:

  Cairo >= 1.00 (Perl module)

In order to build it from source, you'll also need

   ExtUtils::Depends >= 0.2
   ExtUtils::PkgConfig >= 1.03
   development headers for gtk+ and friends

Gtk2 is a Perl extension providing Perl bindings to the 2.x series of  
the Gtk+ graphical user interface library.  This module allows you to  
write graphical user interfaces in a perlish and object-oriented way,  
freeing you from the casting and memory management in C, yet remaining
very close in spirit to original API.  Find out more about Gtk+ at
<http://www.gtk.org>, and about Gtk2-Perl at
<http://gtk2-perl.sourceforge.net/>.

_______________________________________________
gtk-perl-list mailing list
[hidden email]
http://mail.gnome.org/mailman/listinfo/gtk-perl-list
Reply | Threaded
Open this post in threaded view
|

Re: Gtk2 1.152 (unstable) available

Torsten Schoenfeld
On Sun, 2007-06-24 at 14:26 +0200, Torsten Schoenfeld wrote:

> * Add support for GtkBuilder.  [Torsten]

I'd like to hear some feedback on Gtk2::Builder from people who use
Gtk2::GladeXML.  The new API is roughly:

  $builder = Gtk2::Builder->new

followed by either

  $builder->add_from_file ($file)

or

  $builder->add_from_string ($buffer).

As for connecting signals, just as in Gtk2::GladeXML, you have three
options:

  $builder->connect_signals ($user_data)
   When invoked like this, Gtk2::Builder will connect signals to
   functions in the main package whose names are specified in the
   UI description.

 $builder->connect_signals ($user_data, $package)
   When invoked like this, Gtk2::Builder will connect signals to
   functions in the package $package.

 $builder->connect_signals ($user_data, %handlers)
   When invoked like this, %handlers is used as a mapping from
   handler names to code references.

Does this make sense?  Is this how you'd expect the API to work?  Is the
heavy overloading of connect_signals() too confusing?  Do you have any
other suggestions?

--
Bye,
-Torsten

_______________________________________________
gtk-perl-list mailing list
[hidden email]
http://mail.gnome.org/mailman/listinfo/gtk-perl-list
Reply | Threaded
Open this post in threaded view
|

Re: Gtk2 1.152 (unstable) available

muppet-6

On Jun 25, 2007, at 4:19 PM, Torsten Schoenfeld wrote:

> On Sun, 2007-06-24 at 14:26 +0200, Torsten Schoenfeld wrote:
>
>> * Add support for GtkBuilder.  [Torsten]
>
> I'd like to hear some feedback on Gtk2::Builder from people who use
> Gtk2::GladeXML.  The new API is roughly:
>
>   $builder = Gtk2::Builder->new
>
> followed by either
>
>   $builder->add_from_file ($file)
>
> or
>
>   $builder->add_from_string ($buffer).

So, two boilerplate lines in all cases?

How about

     $builder = Gtk2::Builder->new_from_file ($filename);

?

Or possibly:

     $builder = Gtk2::Builder->new (
                 filename => $filename,
                 package => $package,
                 userdata => $userdata,
     );



> As for connecting signals, just as in Gtk2::GladeXML, you have three
> options:
>
>   $builder->connect_signals ($user_data)
>    When invoked like this, Gtk2::Builder will connect signals to
>    functions in the main package whose names are specified in the
>    UI description.

In Gtk2::GladeXML, if you didn't supply a package to  
signal_autoconnect_from_package(), it default to the *calling*  
package, not to main.

     sub signal_autoconnect_from_package
     {
         my $self = shift;
         my $package = shift;

         ($package, undef, undef) = caller() unless $package;
         $self->signal_autoconnect(\&_autoconnect_helper, $package);
     }



--
It's all very complicated and would take a scientist to explain it.
   -- MST3K


_______________________________________________
gtk-perl-list mailing list
[hidden email]
http://mail.gnome.org/mailman/listinfo/gtk-perl-list
Reply | Threaded
Open this post in threaded view
|

Re: Gtk2 1.152 (unstable) available

Torsten Schoenfeld
On Mon, 2007-06-25 at 20:30 -0400, muppet wrote:

> So, two boilerplate lines in all cases?

Yeah.  Your suggestions look good, but I think I'll wait with
implementing them until #447969 is resolved.  They discuss additional
convenience API in that bug.

<http://bugzilla.gnome.org/show_bug.cgi?id=447969>

> In Gtk2::GladeXML, if you didn't supply a package to  
> signal_autoconnect_from_package(), it default to the *calling*  
> package, not to main.

Oh, yeah.  Fixed.

--
Thanks,
-Torsten

_______________________________________________
gtk-perl-list mailing list
[hidden email]
http://mail.gnome.org/mailman/listinfo/gtk-perl-list
Reply | Threaded
Open this post in threaded view
|

Re: Gtk2 1.152 (unstable) available

Grant McLean
In reply to this post by muppet-6
On Jun 25, 2007, at 4:19 PM, Torsten Schoenfeld wrote:
> I'd like to hear some feedback on Gtk2::Builder from people who use
> Gtk2::GladeXML.

I'm an infrequent user of GladeXML so I guess that means me :-)

> As for connecting signals, just as in Gtk2::GladeXML, you have three
> options:
>
>   $builder->connect_signals ($user_data)
>    When invoked like this, Gtk2::Builder will connect signals to
>    functions in the main package whose names are specified in the
>    UI description.
>
>  $builder->connect_signals ($user_data, $package)
>    When invoked like this, Gtk2::Builder will connect signals to
>    functions in the package $package.
>
>  $builder->connect_signals ($user_data, %handlers)
>    When invoked like this, %handlers is used as a mapping from
>    handler names to code references.

One piece of functionality from GladeXML that isn't explicitly mentioned
in your description is:

  $builder->connect_signals ($user_data, $object)
    When invoked like this, Gtk2::Builder will connect signals to
    method calls against the object $object.

Also I looked briefly at the C API docs for GtkBuilder and it says:

  GtkBuilder also provides an interface by which it can look up the
  signal handler names in the program's symbol table and automatically
  connect as many handlers up as it can that way.

Is that type of functionality supported by the Perl bindings?  What I'm
envisaging is defining a UI in Glade but not specifying any signal
handler details.  Then having some auto connect method in the builder
package scan the object for methods matching a certain naming convention
and then hooking up the appropriate signals.  So handling an additional
signal would simply require the developer to add another method to the
object class.

The autoconnect code would probably be too expensive to be the default
behaviour.

Here's a link to my last burblings on this topic:

http://mail.gnome.org/archives/gtk-perl-list/2006-July/msg00059.html

Cheers
Grant



_______________________________________________
gtk-perl-list mailing list
[hidden email]
http://mail.gnome.org/mailman/listinfo/gtk-perl-list
Reply | Threaded
Open this post in threaded view
|

Re: Gtk2 1.152 (unstable) available

Daniel Kasak
In reply to this post by Torsten Schoenfeld
On Mon, 2007-06-25 at 22:19 +0200, Torsten Schoenfeld wrote:

> On Sun, 2007-06-24 at 14:26 +0200, Torsten Schoenfeld wrote:
>
> > * Add support for GtkBuilder.  [Torsten]
>
> I'd like to hear some feedback on Gtk2::Builder from people who use
> Gtk2::GladeXML.

I've heard some talk of the gtk builder stuff, but I'm not clear on
where it fits in. Is the intention to replace glade?

I will do an upgrade and try out Gtk2::Builder when I get a chance
( which may be a while ... but it's on my list ).

--
Daniel Kasak
IT Developer
NUS Consulting Group
Level 5, 77 Pacific Highway
North Sydney, NSW, Australia 2060
T: (+61) 2 9922-7676 / F: (+61) 2 9922 7989
email: [hidden email]
website: http://www.nusconsulting.com.au

_______________________________________________
gtk-perl-list mailing list
[hidden email]
http://mail.gnome.org/mailman/listinfo/gtk-perl-list
Reply | Threaded
Open this post in threaded view
|

Re: Gtk2 1.152 (unstable) available

muppet-6

On Jul 2, 2007, at 7:46 PM, Daniel Kasak wrote:

> I've heard some talk of the gtk builder stuff, but I'm not clear on
> where it fits in. Is the intention to replace glade?

Exactly that, as i understand it.


--
I hate to break it to you, but magic data pixies don't exist.
   -- Simon Cozens


_______________________________________________
gtk-perl-list mailing list
[hidden email]
http://mail.gnome.org/mailman/listinfo/gtk-perl-list
Reply | Threaded
Open this post in threaded view
|

Re: Gtk2 1.152 (unstable) available

Emmanuele Bassi
In reply to this post by Daniel Kasak
On Tue, 2007-07-03 at 09:46 +1000, Daniel Kasak wrote:

> > > * Add support for GtkBuilder.  [Torsten]
> >
> > I'd like to hear some feedback on Gtk2::Builder from people who use
> > Gtk2::GladeXML.
>
> I've heard some talk of the gtk builder stuff, but I'm not clear on
> where it fits in. Is the intention to replace glade?

yes, GtkBuilder is the libglade-in-gtk replacement for libglade.

ciao,
 Emmanuele.

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

_______________________________________________
gtk-perl-list mailing list
[hidden email]
http://mail.gnome.org/mailman/listinfo/gtk-perl-list
Reply | Threaded
Open this post in threaded view
|

Re: Gtk2 1.152 (unstable) available

Torsten Schoenfeld
In reply to this post by Grant McLean
On Tue, 2007-07-03 at 09:17 +1200, Grant McLean wrote:

> One piece of functionality from GladeXML that isn't explicitly mentioned
> in your description is:
>
>   $builder->connect_signals ($user_data, $object)
>     When invoked like this, Gtk2::Builder will connect signals to
>     method calls against the object $object.

Oops.  The functionality is already there (and is exercised in the
tests), but I forgot to mention it in the docs.  Fixed in CVS.  Thanks.

> Also I looked briefly at the C API docs for GtkBuilder and it says:
>
>   GtkBuilder also provides an interface by which it can look up the
>   signal handler names in the program's symbol table and automatically
>   connect as many handlers up as it can that way.

This seems to refer to gtk_builder_connect_signals.  It doesn't really
do what you mean, I think.  It merely iterates over the handler names
specified in the UI description and tries to find that handler in the
application's symbol table.  So it's basically the same as
$builder->connect_signals ($data) in Perl.

> Is that type of functionality supported by the Perl bindings?  What I'm
> envisaging is defining a UI in Glade but not specifying any signal
> handler details.  Then having some auto connect method in the builder
> package scan the object for methods matching a certain naming convention
> and then hooking up the appropriate signals.  So handling an additional
> signal would simply require the developer to add another method to the
> object class.

This does sound interesting.  Is their enough interest to justify
putting this directly into Gtk2?

--
Bye,
-Torsten

_______________________________________________
gtk-perl-list mailing list
[hidden email]
http://mail.gnome.org/mailman/listinfo/gtk-perl-list