Re: GtkImageView and gtk+-3

[Jeff]

On 04/01/18 19:04, Jeff wrote:
> Some ten years ago various people on this list helped me write Perl
> bindings for GtkImageView.

[...]

> Now I am trying to decide how to create the functionality of the widget
> in gtk+-3. I see a couple of options:

[...]

> 3. Do something basic in Perl. Is region selection even possible in pure
> Perl?

I've made some progress. Attached are a couple of small examples
(drawingarea_pan.pl and drawingarea_rubberband.pl) for selecting a
region of an image, and also panning and zooming an image.

Probably thanks to Cairo, they are almost certainly quick enough for
what I want, even though they are pure Perl.

However, I don't understand why although panning and zooming works, the
Cairo context never seems to reflect this in $context->user_to_device()

If you run drawingarea_pan.pl, and try panning at various zoom levels in
the top left hand corner (to keep the numbers small and simple), the
coordinates are not affected by the zoom level or the amount of pan.

What is going on? Why isn't user_to_device() working as I expect?

Regards

Jeff


drawingarea_rubberband.pl
Description: Perl program


drawingarea_pan.pl
Description: Perl program


signature.asc
Description: OpenPGP digital signature
___
gtk-perl-list mailing list
gtk-perl-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-perl-list

GtkImageView and gtk+-3

[Jeff]

Hi all,

Some ten years ago various people on this list helped me write Perl
bindings for GtkImageView.

https://github.com/GNOME/gtkimageview

https://metacpan.org/pod/Gtk2::ImageView

Now I am trying to migrate gscan2pdf to gtk+-3.0. Having enjoyed the
widget for the last ten years, I would like to continue to use it.
Unfortunately, there is no gtk3+-3 version and upstream is dead.

I attempted to compile GtkImageView against gtk+-3.0. This failed,
mostly due to types like GtkDrawable and GtkGC not being in gtk+-3,
which seems to have replaced such things with Cairo.

I see that the GTK people have their own version of GtkImageView in
gtk+-4.0:

https://git.gnome.org/browse/gtk+/commit/?h=wip/baedert/gtkimageview=545f4186042f03026410e174f9940696af76fccb

The code looks completely different to the gtk+-2 code. I haven't tested
it, but it doesn't seem to offer the ability to select regions of the
image, either.

Now I am trying to decide how to create the functionality of the widget
in gtk+-3. I see a couple of options:

1. Start with the gtk+-2 code and replace the deprecated types.

I'm no expert with Cairo, and I don't know whether that allows me to
throw away all the caching code that makes GtkImageView efficient.

2. Start with the gtk+-4.0 code and try to backport it to gtk+-3.0

I don't know how hard this is, and how difficult it is then to implement
stuff like region selection on top

3. Do something basic in Perl. Is region selection even possible in pure
Perl?

I know enough C to write Perl bindings and be generally dangerous, but I
am no expert, so I have started with #3, but I have no idea how to
implement the region selection functionality.

Any insights would be most welcome.

Regards

Jeff Ratcliffe



signature.asc
Description: OpenPGP digital signature
___
gtk-perl-list mailing list
gtk-perl-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-perl-list

Re: GtkImageView

[muppet]

On Feb 18, 2008, at 4:10 AM, Jeffrey Ratcliffe wrote:

 On 17/02/2008, muppet [EMAIL PROTECTED] wrote:
 Now that you have a GBoxed GType for the struct (that can go upstream
 just like the GEnum GTypes), you can also register the functions to
 marshal the value to and from perl.  See gperl_register_boxed() in
 Glib::xsapi.

 As I have added the GBoxed entries to maps, Glib::CodeGen is creating
 gperl_register_boxed() entries in register.xsh, but with NULL for the
 wrapper class. If I understand the Glib::xsapi correctly, this means
 the GBoxed gets a standard wrapper - which is what? Do I need to
 change this? If so, how?

Add your own call to gperl_register_boxed() in a BOOT: section, and  
pass the wrapper class there.  See files like Gtk2/xs/ 
PangoAttributes.xs and Gtk2/xs/GtkEntry for examples.

(or others, with grep gperl_register_boxed Gtk2/xs/*.xs)



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


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

Re: GtkImageView

[Jeffrey Ratcliffe]

I held off releasing the Perl bindings for gtkimageview 1.5.0 because
the author wanted to add the GTypes and a couple of other things. This
he has done, and I have updated the bindings to match
(http://trac.bjourne.webfactional.com/). There are, however, a couple
of things that I don't understand:

a. there is an enum (not a gobject), GdkPixbufDrawOpts, which is used
in both gtkiimagetool.h and gdkpixbufdrawcache.h. I find I have to
include the newSVGdkPixbufDrawOpts and SvGdkPixbufDrawOpts definitions
in the bindings twice, once for each header file, to avoid errors
missing the SvGdkPixbufDrawOpts symbol. What am I doing wrong?

b. compiling gives me the message:
GdkPixbufDrawOpts is not registered with the GLib type system.

c. Gtk2::Gdk::Pixbuf::Draw::Cache::get_method segfaults at the moment
if it not fed with the requisite two GdkPixbufDrawOpts. As the Perl
version of GdkPixbufDrawOpts is a hash, what is the best way of
checking that the hash is a Gtk2::Gdk::Pixbuf::Draw::Opts? isa doesn't
work, because it is a hash, not a gobject. Should I be blessing the
hash?

Everything I've got up to now is committed to the svn repository on the website.

Regards

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

Re: GtkImageView

[Jeffrey Ratcliffe]

On 05/01/2008, Emmanuele Bassi [EMAIL PROTECTED] wrote:
 try with:

   GdkRectangle_copy *

 instead of GtkRectangle_ornull *.

That works, thanks for the help.

Why didn't it work before?

Regards

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

Re: GtkImageView

[muppet]

On Jan 6, 2008, at 1:59 PM, Jeffrey Ratcliffe wrote:

 On 05/01/2008, Emmanuele Bassi [EMAIL PROTECTED] wrote:
 try with:

  GdkRectangle_copy *

 instead of GtkRectangle_ornull *.

 That works, thanks for the help.

 Why didn't it work before?

Memory lifetime.

The object returned to perl was pointing at the spot on the C stack  
where the rect lived.  After the xsub returned, this no longer  
contained a rectangle, and just gave you randomly-changing garbage.  I  
didn't crash because you didn't try to write to it, and the address  
was still inside the valid address space of the process.

The _copy typemap variant instead creates a copy of the object, so the  
reference returned to perl points to its own heap copy of the rectangle.

If you're morbidly curious, see the Wrapping Boxed Types section of  
the Binding HowTo:
http://gtk2-perl.sourceforge.net/doc/binding_howto.pod.html#wrapping%20boxed%20types


--
zella (crying):  I want...
us:  What?
zella (still crying):  I want...  something!


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

Re: GtkImageView

[Emmanuele Bassi]

On Sun, 2008-01-06 at 19:59 +0100, Jeffrey Ratcliffe wrote:
 On 05/01/2008, Emmanuele Bassi [EMAIL PROTECTED] wrote:
  try with:
 
GdkRectangle_copy *
 
  instead of GtkRectangle_ornull *.
 
 That works, thanks for the help.
 
 Why didn't it work before?

GdkRectangle_ornull will not copy the return value, but will just return
a pointer (plus safety check on NULL values); since the GdkRectangle is
put on the stack, this means that you'll get garbage as soon as you try
to access the pointer from outside the function.

GdkRectangle_copy will copy the stack allocated value into the heap,
thus giving back valid data (the memory will be deallocated when the
scalar gets garbage collected).

ciao,
 Emmanuele.

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

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

Re: GtkImageView

[Jeffrey Ratcliffe]

$rectangle = $selector-get_selection

doesn't seem to be producing sensible results. Selections in
examples/interactive.pl are nonsense, whereas the c version is OK. I
assume, therefore, that there is something wrong in
ImageToolSelector.xs:

## call as $rectangle = $selector-get_selection
## void gtk_image_tool_selector_get_selection (GtkImageToolSelector
*selector, GdkRectangle *rect);
GdkRectangle_ornull *
gtk_image_tool_selector_get_selection (selector)
GtkImageToolSelector *  selector
PREINIT:
GdkRectanglerect;
CODE:
gtk_image_tool_selector_get_selection(selector, rect);
RETVAL = rect;
OUTPUT:
RETVAL

Any ideas?

Regards

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

Re: GtkImageView

[Emmanuele Bassi]

On Sat, 2008-01-05 at 22:02 +0100, Jeffrey Ratcliffe wrote:
 $rectangle = $selector-get_selection
 
 doesn't seem to be producing sensible results. Selections in
 examples/interactive.pl are nonsense, whereas the c version is OK. I
 assume, therefore, that there is something wrong in
 ImageToolSelector.xs:
 
 ## call as $rectangle = $selector-get_selection
 ## void gtk_image_tool_selector_get_selection (GtkImageToolSelector
 *selector, GdkRectangle *rect);
 GdkRectangle_ornull *

try with:

  GdkRectangle_copy *

instead of GtkRectangle_ornull *.

 gtk_image_tool_selector_get_selection (selector)
   GtkImageToolSelector *  selector
   PREINIT:
   GdkRectanglerect;

also, remember to initialise at zero, in case the function doesn't:

GdkRectangle rect = { 0, };

so the rest of the bindings don't get garbage.

ciao,
 Emmanuele.

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

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

ATK (was: Re: GtkImageView)

[Torsten Schoenfeld]

On Thu, 2007-12-27 at 16:01 +0100, Jeffrey Ratcliffe wrote:

 What would we gain by wrapping ATK?

ATK is the accessibility toolkit, so I *think* wrapping it would enable
us to implement, in Perl, custom widgets that are accessible.  That
presumably means those widgets could then be usable by blind people via
a screen reader, for example.  If you simply build new aggregate widgets
that comprise of existing GTK+ widgets, accessibility is already taken
care of I think.  It's important for completely new things which are
drawn from Perl code.

-- 
Bye,
-Torsten

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

Re: GtkImageView

[Jeffrey Ratcliffe]

On 27/12/2007, Torsten Schoenfeld [EMAIL PROTECTED] wrote:
 This happens when the type registration facility in Glib::Object
 encounters a type that's not mapped to a corresponding Perl package.
 This usually happens via lines in the various maps files.  Now, we
 don't have such a line for AtkImplementorIface because we don't wrap ATK
 at all yet.  But we do have GtkBuildable support in Gtk2 1.160, so if
 you upgrade, Glib::Object::_Unregistered::GtkBuildable will turn into
 Gtk2::Buildable.

Ah yes. Gutsy has 1.140. Sid has 1.161.

What would we gain by wrapping ATK?

Regards

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

Re: GtkImageView

[Torsten Schoenfeld]

On Wed, 2007-12-26 at 23:46 +0100, Jeffrey Ratcliffe wrote:

 Why do some of the items in the INTERFACES heading have _Unregistered?
 e.g. Gtk2::Widget.
 
 For Gtk2::ImageView, they are:
 
   Glib::Object::_Unregistered::AtkImplementorIface
   Glib::Object::_Unregistered::GtkBuildable

This happens when the type registration facility in Glib::Object
encounters a type that's not mapped to a corresponding Perl package.
This usually happens via lines in the various maps files.  Now, we
don't have such a line for AtkImplementorIface because we don't wrap ATK
at all yet.  But we do have GtkBuildable support in Gtk2 1.160, so if
you upgrade, Glib::Object::_Unregistered::GtkBuildable will turn into
Gtk2::Buildable.

-- 
Bye,
-Torsten

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

Re: GtkImageView

[Jeffrey Ratcliffe]

On 25/12/2007, muppet [EMAIL PROTECTED] wrote:
 Hint:  Glib::MakeHelper::postamble_docs().  I usually use
 Gnome2::Canvas as my template for these things, as it is a very simple
 module that builds atop Gtk2, but most of the modules in the gtk2-perl-
 xs cvs tree should do nicely.

Very cool. Thanks. Just committed the docs for Gtk2::ImageView; I've
still got the other modules to do.

Why do some of the items in the INTERFACES heading have _Unregistered?
e.g. Gtk2::Widget.

For Gtk2::ImageView, they are:

  Glib::Object::_Unregistered::AtkImplementorIface
  Glib::Object::_Unregistered::GtkBuildable

Regards

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

Re: GtkImageView

[Jeffrey Ratcliffe]

On 24/12/2007, muppet [EMAIL PROTECTED] wrote:
 Now that everything is under the Gtk2::ImageView namespace, the
 ignore pattern in the call to Glib::CodeGen::write_boot() is
 ignoring all of the packages in the module, so nothing actually gets
 booted correctly.  You need to change that so that it ignores *only*
 the master package (which is needed to avoid an infinite loop at
 startup -- see the Glib::CodeGen manpage).

Grr. Thanks for pointing that out.

Now I've just got to sort out the documentation and that should be that.

I appreciate all the help. I couldn't have done without it, and I've
learned a great deal in the process.

Regards

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

Re: GtkImageView

[Jeffrey Ratcliffe]

On 22/12/2007, muppet [EMAIL PROTECTED] wrote:
 interactive.pl:  a quick transliteration of gtkimageview/tests/
 interactive.c.  Note that the way this program uses the GtkImageTransp
 values in the UI manager actions doesn't really play nicely with perl
 syntax for enums, so there's a terrible, evil, horrible hack in its
 place.  If you golf this down to more perlish code, using closures and
 such, you can sidestep the problem.

Do you mind my including this in an examples directory, attributing you?

I was getting:

No anim!  Can't call method set_sensitive on an undefined value at
./examples/interactive.pl line 74.

*** unhandled exception in callback:
***   FATAL: invalid enum GtkImageTransp value 1, expecting: color /
GTK_IMAGE_TRANSP_COLOR, background / GTK_IMAGE_TRANSP_BACKGROUND, grid
/ GTK_IMAGE_TRANSP_GRID at ./examples/interactive.pl line 206.
***  ignoring at ./examples/interactive.pl line 602.

which the attached patch fixes. But I don't see how to do it
differently with a closure. I'd appreciate a hint.

I attempted to clean up the namespace with the second patch, but now
the tests fail:

t/animview.NOK 3#   Failed test 'The object isa
Gtk2::ImageView::Anim'
#   in t/animview.t at line 23.
# The object isn't a 'Gtk2::ImageView::Anim' it's a 'Gtk2::ImageView'
t/imagescrollwin...ok 1/3Usage: Gtk2::Table::new(class, rows,
columns, homogeneous=FALSE) at /usr/lib/perl5/Glib.pm line 211.
t/imagetooldragger.ok
t/imagetoolselectorok 1/4Can't locate object method
get_selection via package Gtk2::ImageView::Tool::Selector at
t/imagetoolselector.t line 29.

I must have done something right, as t/imagetooldragger is OK, but
t/imagescrollwin is particularly strange.

Thanks for any clue.

Jeff
Index: examples/interactive.pl
===
--- examples/interactive.pl	(revision 447)
+++ examples/interactive.pl	(working copy)
@@ -83,12 +100,16 @@
 sprintf (%d, %d)-[%d, %d], $r-x, $r-y, $r-width, $r-height;
 }
 
+sub get_enum_nick {
+my ($package, $value) = @_;
+my @v = Glib::Type-list_values ($package);
+return $v[$value]{nick};
+}
+
 sub get_enum_value {
 my ($package, $string) = @_;
 my @v = Glib::Type-list_values ($package);
 for (my $i = 0 ; $i  @v ; $i++) {
 use Data::Dumper;
 print Dumper($v[$i]);
 return $i if $v[$i]{name} eq $string or $v[$i]{nick} eq $string;
 }
 }
@@ -199,11 +220,11 @@
 sub change_transp_type_cb {
 my ($action, $current) = @_;
 my $color = 0;
 my $transp = $current-get_current_value ();
 if ($transp == GTK_IMAGE_TRANSP_COLOR) {
 $color = 0x00;
 }
-$view-set_transp ($transp, $color);
+$view-set_transp (get_enum_nick('Gtk2::ImageTransp', $transp), $color);
 }
 
 sub menu_item_select_cb {
@@ -495,7 +516,7 @@
 $uimanager-insert_action_group ($image_group, 0);
 
 # Transform group
-my $transform_group = Gtk2::ActionGroup-new (transform);
+$transform_group = Gtk2::ActionGroup-new (transform);
 if ($transform_group) {
 $transform_group-add_actions ([EMAIL PROTECTED]);
 $transform_group-set_sensitive (FALSE);
Index: ImageNav.xs
===
--- ImageNav.xs	(revision 441)
+++ ImageNav.xs	(working copy)
@@ -1,7 +1,7 @@
 #include gtkimageviewperl.h
 
 
-MODULE = Gtk2::ImageNav  PACKAGE = Gtk2::ImageNav  PREFIX = gtk_image_nav_
+MODULE = Gtk2::ImageView::Nav  PACKAGE = Gtk2::ImageView::Nav  PREFIX = gtk_image_nav_
 
 
 GtkWidget *
Index: IImageTool.xs
===
--- IImageTool.xs	(revision 441)
+++ IImageTool.xs	(working copy)
@@ -79,7 +79,7 @@
 }
 
 
-MODULE = Gtk2::IImageTool  PACKAGE = Gtk2::IImageTool  PREFIX = gtk_iimage_tool_
+MODULE = Gtk2::ImageView::Tool  PACKAGE = Gtk2::ImageView::Tool  PREFIX = gtk_iimage_tool_
 
 
 gboolean
Index: ImageToolPainter.xs
===
--- ImageToolPainter.xs	(revision 441)
+++ ImageToolPainter.xs	(working copy)
@@ -1,7 +1,7 @@
 #include gtkimageviewperl.h
 
 
-MODULE = Gtk2::ImageToolPainter  PACKAGE = Gtk2::ImageToolPainter  PREFIX = gtk_image_tool_painter_
+MODULE = Gtk2::ImageView::Tool::Painter  PACKAGE = Gtk2::ImageView::Tool::Painter  PREFIX = gtk_image_tool_painter_
 
 
 GtkIImageTool *
Index: maps
===
--- maps	(revision 443)
+++ maps	(working copy)
@@ -1,9 +1,10 @@
 GTK_TYPE_IMAGE_VIEW			GtkImageView		GObject	Gtk2::ImageView
-GTK_TYPE_ANIM_VIEW			GtkAnimView		GObject	Gtk2::AnimView
-GTK_TYPE_IIMAGE_TOOL			GtkIImageTool		GObject	Gtk2::IImageTool
-GTK_TYPE_IMAGE_NAV			GtkImageNav		GObject	Gtk2::ImageNav
-GTK_TYPE_IMAGE_SCROLL_WIN		GtkImageScrollWin	GObject	Gtk2::ImageScrollWin
-GTK_TYPE_IMAGE_TOOL_DRAGGER		GtkImageToolDragger	GObject	Gtk2::ImageToolDragger
-GTK_TYPE_IMAGE_TOOL_SELECTOR		GtkImageToolSelector

Re: GtkImageView

[muppet]

On Dec 23, 2007, at 7:23 PM, Jeffrey Ratcliffe wrote:


On 22/12/2007, muppet [EMAIL PROTECTED] wrote:

interactive.pl:  a quick transliteration of gtkimageview/tests/
interactive.c.  Note that the way this program uses the  
GtkImageTransp

values in the UI manager actions doesn't really play nicely with perl
syntax for enums, so there's a terrible, evil, horrible hack in its
place.  If you golf this down to more perlish code, using closures  
and

such, you can sidestep the problem.


Do you mind my including this in an examples directory, attributing  
you?


I was getting:

No anim!  Can't call method set_sensitive on an undefined value at
./examples/interactive.pl line 74.

*** unhandled exception in callback:
***   FATAL: invalid enum GtkImageTransp value 1, expecting: color /
GTK_IMAGE_TRANSP_COLOR, background / GTK_IMAGE_TRANSP_BACKGROUND, grid
/ GTK_IMAGE_TRANSP_GRID at ./examples/interactive.pl line 206.
***  ignoring at ./examples/interactive.pl line 602.

which the attached patch fixes. But I don't see how to do it
differently with a closure. I'd appreciate a hint.


Unfortunately, i misremembered GtkRadioActionEntry as having a closure  
slot in each item; it does not.  You're stuck with an integer value to  
distinguish them, and in this situation, the integer enumeration value  
is rather ideal.  For perl interoperability this kinda sucks, and  
you're left doing something like the evil hack i had.  Or, you could  
use random integers and switch instead on the $action-name, which you  
conveniently set to the enumeration string name / nick, which is also  
somewhat evil.


Earlier i'd had problems getting the idea of

sub GTK_IMAGE_TRANSP_GRID { get_enum_value ('Gtk2::ImageTransp',  
'grid') }


working, and instead hardcoded it to the integer value; i figure out  
why that is.  You need to have the value table in  
gtkimageviewperl_gtk_image_transp_get_type() be static as well as  
const.  Without this, the value table is on the stack, and the GType  
registry winds up pointing at stack garbage after the get_type  
function has returned, eventually causing SIGSEGV crashes.  Also, the  
g_intern_static_string() call isn't really necessary.  See enum.patch.






I attempted to clean up the namespace with the second patch, but now
the tests fail:


Now that everything is under the Gtk2::ImageView namespace, the  
ignore pattern in the call to Glib::CodeGen::write_boot() is  
ignoring all of the packages in the module, so nothing actually gets  
booted correctly.  You need to change that so that it ignores *only*  
the master package (which is needed to avoid an infinite loop at  
startup -- see the Glib::CodeGen manpage).




boot.diff
Description: Binary data





enum.patch
Description: Binary data



--
One, two, free, four, five, six, sebben, eight, nine, ten, elebben,  
twull, fourteen, sickteen, sebbenteen, eightteen, elebbenteen,  
fiffeen, elebbenteen!

  -- Zella, aged three, counting to twenty.


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

Re: GtkImageView

[Jeffrey Ratcliffe]

On 22/12/2007, muppet [EMAIL PROTECTED] wrote:
 More proactive:  #include gtkanimview.h in gtkimageviewperl.h, and
 make sure you use gtkimageviewperl.h everywhere instead of duplicating
 the #include lines for all the various headers.  The attached patch
 does this.  One reason to do this is that anybody wanting to create an
 XS extension that builds atop yours (as yours builds atop gtk2perl.h)
 will expect everything it needs to come through one header,
 gtkimageviewperl.h.  More immediately, this ensures that every file
 inside your project sees the same set of preprocessor definitions at
 build time.  (Repeat after me: the C preprocessor is Evil.)

Ah. Another inch up the learning curve.

 Oh, and check your license comment blocks; you've attributed your
 binding work to the gtk2-perl team as of four years ago, and have a
 CVS $Header:$ tag showing me as the most recent author, in June
 2003.  ;-)

Well, based on results rather than time spent, apart from the date,
that is probably accurate. I'll fix it anyway.

 A bigger issue:  namespacing.  The classes you define are
 Gtk2::ImageView, Gtk2::ImageToolSelector, etc.  That is, they are
 right in the Gtk2:: namespace, waiting for potential name clashes if
 and when gtk+ adds something called GtkImageView.  Now, of course, the
 same problem exists with the upstream library, but instead of taking
 up a bunch of slots in the Gtk2:: namespace, how about doing something
 like this, instead?

  GtkImageView - Gtk2::ImageView
  GtkImageTransp - Gtk2::ImageView::Transp
  GtkImageToolPainter - Gtk2::ImageView::Tool::Painter

OK. How about:

GtkImageView - Gtk2::ImageView
GtkAnimView - Gtk2::ImageView::Anim
GtkImageNav - Gtk2::ImageView::Nav
GtkImageScrollWin - Gtk2::ImageView::ScrollWin
GtkIImageTool - Gtk2::ImageView::Tool
GtkImageToolDragger - Gtk2::ImageView::Tool::Dragger
GtkImageToolSelector - Gtk2::ImageView::Tool::Selector
GtkImageTransp - Gtk2::ImageView::Transp

 fix-includes.patch: make everything include gtkimageviewperl.h instead
 of various files.

Thanks.

 requirements.patch: in Makefile.PL, look for gtkimageview 1.5.0, since
 these bindings won't compile against older.  You can play with
 ExtUtils::PkgConfig and look at other modules for hints on how to make
 your bindings compile against multiple versions of the upstream library.

Thanks.

 transp-map.patch: GtkImageTransp was listed incorrectly in the maps
 file as mapping to the package name Gtk2::ImageView.  Fix that.

And I left out Gtk2::ImageToolPainter completely. Fixed that.

 interactive.pl:  a quick transliteration of gtkimageview/tests/

Good grief. You can't have been bored - you've got kids, so I can only
assume you couldn't sleep! Thanks.

 interactive.c.  Note that the way this program uses the GtkImageTransp
 values in the UI manager actions doesn't really play nicely with perl
 syntax for enums, so there's a terrible, evil, horrible hack in its
 place.  If you golf this down to more perlish code, using closures and
 such, you can sidestep the problem.

I take it you are talking about the lines like:

sub GTK_IMAGE_TRANSP_COLOR { 0 }

I'll see what I can do.

Regards

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

Re: GtkImageView

[Torsten Schoenfeld]

On Tue, 2007-12-18 at 13:05 +0100, Jeffrey Ratcliffe wrote:

  Sounds like a good idea.  Can you take a stab at it?  The formulations
  might make more sense to newcomers if they're written by someone who
  just recently learned about them.
 
 Your explanations were excellent, so I'll copy them almost verbatim.

OK, committed.  Thanks!

-- 
Bye,
-Torsten

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

Re: GtkImageView

[Torsten Schoenfeld]

On Thu, 2007-12-20 at 01:33 -0500, muppet wrote:

 I think the secondary void value not ignored as it should be warning  
 was just fallout from the compiler being confused about the void*  
 pointer dereference.  (And, yes, i think we ought to change  
 Glib::CodeGen to fix this upstream.)

Like so?
-- 
Bye,
-Torsten
Index: CodeGen.pm
===
RCS file: /cvsroot/gtk2-perl/gtk2-perl-xs/Glib/CodeGen.pm,v
retrieving revision 1.5
diff -u -d -p -r1.5 CodeGen.pm
--- CodeGen.pm	16 Dec 2007 16:32:13 -	1.5
+++ CodeGen.pm	22 Dec 2007 18:24:11 -
@@ -517,7 +517,7 @@ sub gen_boxed_stuff {
 	add_header #ifdef $typemacro
   /* GBoxed $classname */
   typedef $classname $classname\_ornull;
-# define Sv$classname(sv)	(gperl_get_boxed_check ((sv), $typemacro))
+# define Sv$classname(sv)	(($classname *) gperl_get_boxed_check ((sv), $typemacro))
 # define Sv$classname\_ornull(sv)	(gperl_sv_defined (sv) ? Sv$classname (sv) : NULL)
   typedef $classname $classname\_own;
   typedef $classname $classname\_copy;
___
gtk-perl-list mailing list
gtk-perl-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-perl-list

Re: GtkImageView

[muppet]

On Dec 22, 2007, at 1:25 PM, Torsten Schoenfeld wrote:

 On Thu, 2007-12-20 at 01:33 -0500, muppet wrote:

 I think the secondary void value not ignored as it should be  
 warning
 was just fallout from the compiler being confused about the void*
 pointer dereference.  (And, yes, i think we ought to change
 Glib::CodeGen to fix this upstream.)

 Like so?
 cast.patch

Exactly like that.  :-)

Have you noticed any new compiler warnings with this?  I don't expect  
any, but there's always a chance...

--
Doing a good job around here is like wetting your pants in a dark  
suit; you get a warm feeling, but no one notices.
   -- unknown


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

Re: GtkImageView

[Torsten Schoenfeld]

On Sat, 2007-12-22 at 13:34 -0500, muppet wrote:

  Like so?
  cast.patch
 
 Exactly like that.  :-)

Alright, committed.

 Have you noticed any new compiler warnings with this?  I don't expect  
 any, but there's always a chance...

Nope.  I compiled Glib and Gtk2 with PASTHRU_INC=-g -Wall -Werror and
everything went fine.

-- 
Bye,
-Torsten

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

Re: GtkImageView

[Jeffrey Ratcliffe]

On 20/12/2007, muppet [EMAIL PROTECTED] wrote:
 I should stop writing emails with toddlers around.  ;-)

I know that problem :-)

 svn add it); and, the important bit, adds a cast to this line:

if (svp) settings-zoom_rect = * (GdkRectangle *)
 SvGdkRectangle (*svp);

 to fix the dereferencing `void *' pointer.

Ah. Now I see it, I understand. Thanks.

 You'll also want to hush the unused variable `class' warning by not
 including the line SV * class in the argument listing of
 gtk_image_view_new().

Thanks.

I hope I have now finished the bulk of the work. The remaining
bindings compile without error. However, the only constructor that is
passing a correctly blessed object is the main Gtk2::ImageView one,
all the others pass 'Glib::Object::_Unregistered::Gtk*', so in testing
isa, I get failures like:

#   Failed test 'The object isa Gtk2::AnimView'
#   in t/animview.t at line 23.
# The object isn't a 'Gtk2::AnimView' it's a
'Glib::Object::_Unregistered::GtkAnimView'

I've committed what I have to SVN at
http://trac.bjourne.webfactional.com/browser/plgtkimageview/

I assume I am missing something fundamental, and would be grateful for a hint.

Thanks

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

Re: GtkImageView

[muppet]

On Dec 21, 2007, at 5:35 PM, Jeffrey Ratcliffe wrote:


On 20/12/2007, muppet [EMAIL PROTECTED] wrote:

You'll also want to hush the unused variable `class' warning by not
including the line SV * class in the argument listing of
gtk_image_view_new().


Thanks.


No problem.



I hope I have now finished the bulk of the work. The remaining
bindings compile without error. However, the only constructor that is
passing a correctly blessed object is the main Gtk2::ImageView one,
all the others pass 'Glib::Object::_Unregistered::Gtk*', so in testing
isa, I get failures like:

#   Failed test 'The object isa Gtk2::AnimView'
#   in t/animview.t at line 23.
# The object isn't a 'Gtk2::AnimView' it's a
'Glib::Object::_Unregistered::GtkAnimView'


I assume I am missing something fundamental, and would be grateful  
for a hint.



Hrm.  It looks like gtkimageview.h doesn't follow the convention of  
one-stop header for everything in the gtkimageview library; to get  
GTK_TYPE_ANIM_VIEW #defined , you have to #include gtkanimview.h  
separately.  The code generated by Glib::CodeGen in register.xsh wraps  
the registration of the object type for GtkAnimView in #ifdef  
GTK_TYPE_ANIM_VIEW.  ImageView.xs, which #includes register.xsh,  
doesn't #include gtkanimview.h, so that macro isn't defined, and we  
simply don't register the GType to package mapping.


Simple solution:  #include gtkanimview.h in ImageView.xs.

More proactive:  #include gtkanimview.h in gtkimageviewperl.h, and  
make sure you use gtkimageviewperl.h everywhere instead of duplicating  
the #include lines for all the various headers.  The attached patch  
does this.  One reason to do this is that anybody wanting to create an  
XS extension that builds atop yours (as yours builds atop gtk2perl.h)  
will expect everything it needs to come through one header,  
gtkimageviewperl.h.  More immediately, this ensures that every file  
inside your project sees the same set of preprocessor definitions at  
build time.  (Repeat after me: the C preprocessor is Evil.)



Oh, and check your license comment blocks; you've attributed your  
binding work to the gtk2-perl team as of four years ago, and have a  
CVS $Header:$ tag showing me as the most recent author, in June  
2003.  ;-)



A bigger issue:  namespacing.  The classes you define are  
Gtk2::ImageView, Gtk2::ImageToolSelector, etc.  That is, they are  
right in the Gtk2:: namespace, waiting for potential name clashes if  
and when gtk+ adds something called GtkImageView.  Now, of course, the  
same problem exists with the upstream library, but instead of taking  
up a bunch of slots in the Gtk2:: namespace, how about doing something  
like this, instead?


GtkImageView - Gtk2::ImageView
GtkImageTransp - Gtk2::ImageView::Transp
GtkImageToolPainter - Gtk2::ImageView::Tool::Painter



So, attached:

fix-includes.patch: make everything include gtkimageviewperl.h instead  
of various files.


requirements.patch: in Makefile.PL, look for gtkimageview 1.5.0, since  
these bindings won't compile against older.  You can play with  
ExtUtils::PkgConfig and look at other modules for hints on how to make  
your bindings compile against multiple versions of the upstream library.


transp-map.patch: GtkImageTransp was listed incorrectly in the maps  
file as mapping to the package name Gtk2::ImageView.  Fix that.


interactive.pl:  a quick transliteration of gtkimageview/tests/ 
interactive.c.  Note that the way this program uses the GtkImageTransp  
values in the UI manager actions doesn't really play nicely with perl  
syntax for enums, so there's a terrible, evil, horrible hack in its  
place.  If you golf this down to more perlish code, using closures and  
such, you can sidestep the problem.



#!/usr/bin/perl -w
# -*- Mode: perl; tab-width: 4; indent-tabs-mode: nil; c-basic-offset: 4; coding: utf-8 -*-
# vim: set expandtab softtabstop=4 shiftwidth=4 :

use strict;

# Library under test.
use Gtk2::ImageView;

use Glib ':constants';

# //
# / Global data 
# //
my $open_dialog;
my $view;
my $main_window;
my $default_group;
my $image_group;
my $transform_group;
my $is_fullscreen;
my $statusbar;

# Label that displays the active selection.
my $sel_info_label;

# Tools
my $dragger;
my $selector;
my $painter;

# Context ID:s for the Statusbar
my $help_msg_cid;
my $image_info_cid;

# //
# / Opener dialog //
# //
sub init_open_dialog {
$open_dialog = Gtk2::FileChooserDialog-new (Open Image,
 $main_window,
 'open

Re: GtkImageView

[Jeffrey Ratcliffe]

On 19/12/2007, muppet [EMAIL PROTECTED] wrote:
 If that still doesn't work, give us the url of an svn branch that has
 the current code.

I understand what you say, but I can't find a prototype for
SvDrawSettings (or for SvGtkStockItem in Gtk2/xs/GtkStock.xs).

I've committed what I have to SVN at
http://trac.bjourne.webfactional.com/browser/plgtkimageview/

Sorry for my continued stupidity.

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

Re: GtkImageView

[muppet]

On Dec 19, 2007, at 4:13 PM, Jeffrey Ratcliffe wrote:


On 19/12/2007, muppet [EMAIL PROTECTED] wrote:

If that still doesn't work, give us the url of an svn branch that has
the current code.


I understand what you say, but I can't find a prototype for
SvDrawSettings (or for SvGtkStockItem in Gtk2/xs/GtkStock.xs).


I should stop writing emails with toddlers around.  ;-)

A C function definition doubles as a prototype.  I should've said  
signature rather than prototype.  Sorry for the confusion.




I've committed what I have to SVN at
http://trac.bjourne.webfactional.com/browser/plgtkimageview/



I don't have a release version of gtkimageview handy, so this patch  
will build fine against the svn HEAD version of gtkimageview.


It replaces all the occurrences of DrawSettings with  
GdkPixbufDrawOpts; adds the new rect parameter to  
gtk_iimage_tool_pixbuf_changed(); adds the file gtkimageview.typemap  
instead of creating build/perl.typemap in Makefile.PL (don't forget to  
svn add it); and, the important bit, adds a cast to this line:


  if (svp) settings-zoom_rect = * (GdkRectangle *)  
SvGdkRectangle (*svp);


to fix the dereferencing `void *' pointer.

You'll also want to hush the unused variable `class' warning by not  
including the line SV * class in the argument listing of  
gtk_image_view_new().


I think the secondary void value not ignored as it should be warning  
was just fallout from the compiler being confused about the void*  
pointer dereference.  (And, yes, i think we ought to change  
Glib::CodeGen to fix this upstream.)




plgtkimageview-svn.patch
Description: Binary data





--
One, two, free, four, five, six, sebben, eight, nine, ten, elebben,  
twull, fourteen, sickteen, sebbenteen, eightteen, elebbenteen,  
fiffeen, elebbenteen!

  -- Zella, aged three, counting to twenty.


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

Re: GtkImageView

[Jeffrey Ratcliffe]

On 17/12/2007, Torsten Schoenfeld [EMAIL PROTECTED] wrote:
 Sounds like a good idea.  Can you take a stab at it?  The formulations
 might make more sense to newcomers if they're written by someone who
 just recently learned about them.

Your explanations were excellent, so I'll copy them almost verbatim.

In the MORE COOL CODE TRICKS section, I would have:

GdkEvent

gtk2-perl does not have separate typemaps for every event type.  There
is just one for GdkEvent which looks at the event's type at run-time
to decide how to represent it.

So, when binding a new widget, use GdkEvent* for the type of the
argument and insert casts to the specific event required by the widget
(e.g. GdkEventButton*) where needed.  The xsub for
gtk_window_activate_key in Gtk2/xs/GtkWindow.xs might serve as an
example.

Structs

Unfortunately, there's no automatic way to convert raw structs to Perl
land.  These are, however, best represented as hash references with a
key for each member. For an example of this kind of thing, take a look
at the way GtkStockItem is handled in Gtk2/xs/GtkStock.xs.

Once you have the converters newSVStructName and SVStructName, you can
take this one step further by installing a custom typemap for them:
StructName * T_GPERL_GENERIC_WRAPPER in a typemap file installed via
ExtUtils::Depends-add_typemaps in Makefile.PL -- like Gtk2 does for
gtk.typemap, for example.

 You're trying to use a GdkRectangle where a GdkRectangle* is wanted.  I
 think this should work:

Thanks, Torsten and Muppet. I briefly had the same but discarded it
when I got the error message:

IImageTool.xs: In function `SvDrawSettings':
IImageTool.xs:62: warning: dereferencing `void *' pointer
IImageTool.xs:62: error: void value not ignored as it ought to be

  if (svp) settings-zoom_rect = *SvGdkRectangle (*svp);

Which leaves me pretty much in the dark.

 By the way, why 'DrawSettings' instead of 'GdkPixbufDrawOpts'?

The most recent release has 'DrawSettings', but this has been replaced
in SVN with 'GdkPixbufDrawOpts'. This had me confused for a bit.

Sorry I don't seem to be quite as quick on the uptake as I should...

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

Re: GtkImageView

[muppet]

On Dec 18, 2007, at 7:05 AM, Jeffrey Ratcliffe wrote:

 gtk2-perl does not have separate typemaps for every event type.  There
 is just one for GdkEvent which looks at the event's type at run-time
 to decide how to represent it.

As an aside, the reason for this is the way that GdkEvent is  
implemented.  GdkEvent is the structure type, which contains a union  
of all the event types, and a type code that tells you which of the  
union members is valid.


 Once you have the converters newSVStructName and SVStructName, you can

That should be SvStructName() -- note the lower-case v.  (Blame the  
perlapi, not me.)


 You're trying to use a GdkRectangle where a GdkRectangle* is  
 wanted.  I
 think this should work:

 Thanks, Torsten and Muppet. I briefly had the same but discarded it
 when I got the error message:

 IImageTool.xs: In function `SvDrawSettings':
 IImageTool.xs:62: warning: dereferencing `void *' pointer
 IImageTool.xs:62: error: void value not ignored as it ought to be

  if (svp) settings-zoom_rect = *SvGdkRectangle (*svp);

 Which leaves me pretty much in the dark.


In general, the dereferencing a `void*' pointer warning means that  
your pointer isn't cast to a valid type.  I notice now that  
gperl_get_boxed_check() returns a void*, and Glib::CodeGen creates  
macros like this:

   #define SvGtkBorder(sv)   (gperl_get_boxed_check ((sv),  
GTK_TYPE_BORDER))

That is, the generated SvStructType() macros don't contain the cast  
like you'd expect.  In the general case of

 Foo * foo = SvFoo (sv);

this works fine, because C (unlike C++) says that a void* may be used  
where any pointer type is wanted; that is, the conversion is implicit  
in C.  But, the construct

Foo foo = *SvFoo (sv);

turns into

Foo foo = * ((void*) something)

which is *not* valid.  The two solutions are

a)   Foo * foo = * (Foo*) SvFoo (sv);

b)   change Glib::CodeGen to insert the cast into the macro like this:

  #define SvFoo(sv)((Foo*) gperl_get_boxed_check ((sv),  
TYPE_FOO))

In reality, you may as well go for a) to make things work until we get  
b) vetted and rolled out.



Now, the error message,

 IImageTool.xs:62: error: void value not ignored as it ought to be

makes me go back and realize that you are using a hand-written  
function for SvDrawSettings() instead of a Glib::CodeGen-created  
macro.  I don't see anything related to this at 
http://trac.bjourne.webfactional.com/browser/plgtkimageview/ 
, so, from the message, it sounds like your function has the prototype

 void SvDrawSettings (SV * sv);

That means that it returns nothing, and the compiler will complain  
that you're attempting to use a non-existent value.  This is  
incorrect.  Change it to

 DrawSettings * SvDrawSettings (SV * sv);

(note the parallel with the discussion of the macro definitions,  
above), and everything should Just Work.


If that still doesn't work, give us the url of an svn branch that has  
the current code.


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


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

Re: GtkImageView

[Jeffrey Ratcliffe]

On 16/12/2007, Torsten Schoenfeld [EMAIL PROTECTED] wrote:
 Unfortunately, there's no automatic way to convert raw structs to Perl
 land.  In this case, I think the best option would be to represent
 GdkPixbufDrawOpts as a hash reference with keys zoom, zoom_rect, etc.
 For an example of this kind of thing, take a look at the way
 GtkStockItem is handled in Gtk2/xs/GtkStock.xs.

Ah. Thanks! Might I suggest that this and the GdkEvent issue be added
to binding_howto.pod?

 Once you have the converter newSVGdkPixbufDrawOpts[1], you can take this
 one step further by installing a custom typemap for GdkPixbufDrawOpts:
 GdkPixbufDrawOpts * T_GPERL_GENERIC_WRAPPER in a typemap file
 installed via ExtUtils::Depends-add_typemaps in Makefile.PL -- like

OK. Almost working. As my Perl is much better than my C these days, I
just can't find the correct syntax:

IImageTool.xs: In function `newSVDrawSettings':
IImageTool.xs:33: error: cannot convert to a pointer type
IImageTool.xs: In function `SvDrawSettings':
IImageTool.xs:62: error: incompatible types in assignment

where the relevant lines are:

  hv_store (hv, zoom_rect, 9, newSVGdkRectangle (settings-zoom_rect), 0);

and

  if (svp) settings-zoom_rect = SvGdkRectangle (*svp);

where

struct DrawSettings {
gdoublezoom;
GdkRectangle   zoom_rect;
intwidget_x;
intwidget_y;
GdkInterpType  interp;
GdkPixbuf *pixbuf;
intcheck_color1;
intcheck_color2;
};

and

DrawSettings * settings

in both functions.

I assume that I have an int where I should have a pointer or vice
versa, and made the same mistake in both places.

I'd appreciate a hint!

Thanks

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

Re: GtkImageView

[muppet]

On Dec 17, 2007, at 8:11 AM, Jeffrey Ratcliffe wrote:

 OK. Almost working. As my Perl is much better than my C these days, I
 just can't find the correct syntax:

 IImageTool.xs: In function `newSVDrawSettings':
 IImageTool.xs:33: error: cannot convert to a pointer type
 IImageTool.xs: In function `SvDrawSettings':
 IImageTool.xs:62: error: incompatible types in assignment

 where the relevant lines are:

  hv_store (hv, zoom_rect, 9, newSVGdkRectangle (settings- 
 zoom_rect), 0);

Take the address of the zoom_rect structure member like this:

 newSVGdkRectangle (settings-zoom_rect)


 and

  if (svp) settings-zoom_rect = SvGdkRectangle (*svp);

You need to dereference the pointed that SvGdkRectangle() returns.

 settings-zoom_rect = *SvGdkRectangle (*svp);

SvGdkRectangle() is implemented as gperl_get_boxed_check(), which does  
not allow undef, so you should not get a NULL pointer back from it  
unless something is quite wrong.


--
The Master in the art of living makes little distinction between his  
work and his play, his labor and his leisure, his mind and his body,  
his education and his recreation, his love and his religion. He hardly  
knows which is which. He simply pursues his vision of excellence in  
whatever he does, leaving others to decide whether he is working or  
playing. To him he is always doing both.

   -- Zen Philosophy



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

Re: GtkImageView

[Torsten Schoenfeld]

On Mon, 2007-12-17 at 14:11 +0100, Jeffrey Ratcliffe wrote:
  Unfortunately, there's no automatic way to convert raw structs to Perl
  land.  In this case, I think the best option would be to represent
  GdkPixbufDrawOpts as a hash reference with keys zoom, zoom_rect, etc.
  For an example of this kind of thing, take a look at the way
  GtkStockItem is handled in Gtk2/xs/GtkStock.xs.
 
 Ah. Thanks! Might I suggest that this and the GdkEvent issue be added
 to binding_howto.pod?

Sounds like a good idea.  Can you take a stab at it?  The formulations
might make more sense to newcomers if they're written by someone who
just recently learned about them.

  Once you have the converter newSVGdkPixbufDrawOpts[1], you can take this
  one step further by installing a custom typemap for GdkPixbufDrawOpts:
  GdkPixbufDrawOpts * T_GPERL_GENERIC_WRAPPER in a typemap file
  installed via ExtUtils::Depends-add_typemaps in Makefile.PL -- like
 
 OK. Almost working. As my Perl is much better than my C these days, I
 just can't find the correct syntax:
 
 IImageTool.xs: In function `newSVDrawSettings':
 IImageTool.xs:33: error: cannot convert to a pointer type
 IImageTool.xs: In function `SvDrawSettings':
 IImageTool.xs:62: error: incompatible types in assignment
 
 where the relevant lines are:
 
   hv_store (hv, zoom_rect, 9, newSVGdkRectangle (settings-zoom_rect), 0);
 
 and
 
   if (svp) settings-zoom_rect = SvGdkRectangle (*svp);

You're trying to use a GdkRectangle where a GdkRectangle* is wanted.  I
think this should work:

  hv_store (hv, zoom_rect, 9, newSVGdkRectangle ((settings-zoom_rect)), 0);

  if (svp) settings-zoom_rect = *(SvGdkRectangle (*svp));

If the settings struct passed into newSVDrawSettings might be free'd
while the corresponding hash reference still lives, you might have to
use newSVGdkRectangle_copy instead.

By the way, why 'DrawSettings' instead of 'GdkPixbufDrawOpts'?
-- 
Bye,
-Torsten

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

Re: GtkImageView

[Torsten Schoenfeld]

On Wed, 2007-12-12 at 11:26 +0100, Jeffrey Ratcliffe wrote:

 I assume that I have either got the map entry for GdkPixbufDrawOpts
 wrong, or am missing something extra needed as it is a struct.

Yes, GdkPixbufDrawOpts is a raw struct (I think you need to #include
gdkpixbufdrawcache.h to get it, by the way).  It doesn't have an
associated GType, so putting it in the maps file won't work.

Unfortunately, there's no automatic way to convert raw structs to Perl
land.  In this case, I think the best option would be to represent
GdkPixbufDrawOpts as a hash reference with keys zoom, zoom_rect, etc.
For an example of this kind of thing, take a look at the way
GtkStockItem is handled in Gtk2/xs/GtkStock.xs.

Once you have the converter newSVGdkPixbufDrawOpts[1], you can take this
one step further by installing a custom typemap for GdkPixbufDrawOpts:
GdkPixbufDrawOpts * T_GPERL_GENERIC_WRAPPER in a typemap file
installed via ExtUtils::Depends-add_typemaps in Makefile.PL -- like
Gtk2 does for gtk.typemap, for example.  Then the prototype you
mentioned:

void
gtk_iimage_tool_paint_image (tool, opts, drawable)
GtkIImageTool * tool
GdkPixbufDrawOpts * opts
GdkDrawable *   drawable

should just work.

-- 
Bye,
-Torsten

[1] SvGdkPixbufDrawOpts is only be necessary when you need to convert a
perl scalar to a GdkPixbufDrawOpts struct.

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

Re: GtkImageView

[Jeffrey Ratcliffe]

On 11/12/2007, Torsten Schoenfeld [EMAIL PROTECTED] wrote:
 So use GdkEvent* for the type of the argument and insert casts to
 GdkEventButton* where needed.  The xsub for gtk_window_activate_key in
 Gtk2/xs/GtkWindow.xs might serve as an example.

Excellent. Thank you.

Which leads me on to the next problem: In IImageTool.xs, I have:

MODULE = Gtk2::IImageTool  PACKAGE = Gtk2::IImageTool  PREFIX = gtk_iimage_tool_

void
gtk_iimage_tool_paint_image (tool, opts, drawable)
GtkIImageTool * tool
GdkPixbufDrawOpts * opts
GdkDrawable *   drawable

and in maps:

GTK_TYPE_IIMAGE_TOOLGtkIImageTool   GObject 
Gtk2::IImageTool
GDK_TYPE_PIXBUF_DRAW_OPTS   GdkPixbufDrawOpts   GBoxed  
Gtk2::IImageTool

but I get:

IImageTool.c: In function `XS_Gtk2__IImageTool_paint_image':
IImageTool.c:101: error: `GdkPixbufDrawOpts' undeclared (first use in
this function)
IImageTool.c:101: error: (Each undeclared identifier is reported only once
IImageTool.c:101: error: for each function it appears in.)
IImageTool.c:101: error: `opts' undeclared (first use in this function)

I assume that I have either got the map entry for GdkPixbufDrawOpts
wrong, or am missing something extra needed as it is a struct.

Any ideas?

Thanks

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

Re: GtkImageView

[Jeffrey Ratcliffe]

I hope this isn't another stupid question:

How do I define/Where do I get the typemap for GdkEventButton? It
isn't pulled in by #include gtk2perl.h.

Regards

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

Re: GtkImageView

[muppet]

Jeffrey Ratcliffe wrote:
 I hope this isn't another stupid question:

 How do I define/Where do I get the typemap for GdkEventButton? It
 isn't pulled in by #include gtk2perl.h.

Do you mean typemap or typedef?  The typedef, from (eventually) gdk/gdk.h, is
pulled in by gtk2perl.h, yes.

The typemap is another beast, entirely.  Provided you did your Makefile.PL
correctly, that typemap should be folded into your build by ExtUtils::Depends,
which will find the file among the list of extra files installed by Gtk2.


-- 
muppet scott at asofyet dot org

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

Re: GtkImageView

[Torsten Schoenfeld]

On Tue, 2007-12-11 at 15:55 +0100, Jeffrey Ratcliffe wrote:

 How do I define/Where do I get the typemap for GdkEventButton? It
 isn't pulled in by #include gtk2perl.h.

We don't have separate typemaps for all the event types.  We just have
one for GdkEvent* which looks at the event's type at run-time to decide
how to represent it.

So use GdkEvent* for the type of the argument and insert casts to
GdkEventButton* where needed.  The xsub for gtk_window_activate_key in
Gtk2/xs/GtkWindow.xs might serve as an example.

-- 
Bye,
-Torsten

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

Re: GtkImageView

[Jeffrey Ratcliffe]

Having got all tests working for the methods in gtkimageview.h, I have
moved on to gtkanimview.h, a subclass of GtkImageView.

I am getting the error:

t/animview.NOK 1# Failed test (t/animview.t at line 13)
# Tried to use 'Gtk2::AnimView'.
# Error:  Can't locate Gtk2/AnimView.pm in @INC (@INC contains: )

Now Gtk2/AnimView.pm doesn't exist, but AnimView.xs does, containing

MODULE = Gtk2::AnimView  PACKAGE = Gtk2::AnimView  PREFIX = gtk_anim_view_

and should be booted by

GPERL_CALL_BOOT (boot_Gtk2__AnimView);

included in the BOOT: section of ImageView.xs

Any clue what I am missing?

Regards

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

Re: GtkImageView

[Torsten Schoenfeld]

On Mon, 2007-12-10 at 16:16 +0100, Jeffrey Ratcliffe wrote:

 t/animview.NOK 1# Failed test (t/animview.t at line 13)
 # Tried to use 'Gtk2::AnimView'.
 # Error:  Can't locate Gtk2/AnimView.pm in @INC (@INC contains: )
 
 Now Gtk2/AnimView.pm doesn't exist, but AnimView.xs does, containing
 
 MODULE = Gtk2::AnimView  PACKAGE = Gtk2::AnimView  PREFIX = gtk_anim_view_
 
 and should be booted by
 
 GPERL_CALL_BOOT (boot_Gtk2__AnimView);
 
 included in the BOOT: section of ImageView.xs

The error messages seems to indicate that you're trying to use()
Gtk2::AnimView.  That won't work, just like it doesn't work for
Gtk2::Window, ::Button, etc.  Due to the GPERL_CALL_BOOT in
Gtk2::ImageView's BOOT section, use()-ing Gtk2::ImageView should
automatically take care of setting up the Gtk2::AnimView namespace.

-- 
Bye,
-Torsten

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

Re: GtkImageView

[Jeffrey Ratcliffe]

On 10/12/2007, Torsten Schoenfeld [EMAIL PROTECTED] wrote:
 The error messages seems to indicate that you're trying to use()
 Gtk2::AnimView.  That won't work, just like it doesn't work for
 Gtk2::Window, ::Button, etc.  Due to the GPERL_CALL_BOOT in
 Gtk2::ImageView's BOOT section, use()-ing Gtk2::ImageView should
 automatically take care of setting up the Gtk2::AnimView namespace.

Duh! *slaps forehead* Sometimes you can't see the wood for the trees.

Thanks

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

Re: GtkImageView

[Torsten Schoenfeld]

On Fri, 2007-12-07 at 20:31 +0100, Jeffrey Ratcliffe wrote:

 I'd be grateful if someone would tell me what I've missed with the
 enum and whether I have dropped any major clangers before I carry on.

Try switching these lines in gtkimageviewperl.h:

  #include gtkimageviewperl-autogen.h
  #include gtkimageviewperl-gtypes.h

I think the macro definitions in gtkimageviewperl-autogen.h are wrapped
inside #ifdef FOO_TYPE ... #endif.  So if the type macros aren't defined
yet, the newSVFoo and SvFoo macros won't get defined.

-- 
Bye,
-Torsten

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

Re: GtkImageView

[Jeffrey Ratcliffe]

On 08/12/2007, Torsten Schoenfeld [EMAIL PROTECTED] wrote:
 I think the macro definitions in gtkimageviewperl-autogen.h are wrapped
 inside #ifdef FOO_TYPE ... #endif.  So if the type macros aren't defined
 yet, the newSVFoo and SvFoo macros won't get defined.

Thanks for the tip. Unfortunately, it didn't solve the problem, but it
did get me on the right track. That much is now working.

Thanks!

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

Re: GtkImageView

[Jeffrey Ratcliffe]

On 06/12/2007, muppet [EMAIL PROTECTED] wrote:
 So, yes, the upstream library doesn't *need* to provide the
 enumeration GType, but it saves everybody else work if it does.  Also,
 if and when he does add this upstream, you'll have to change your
 bindings to retain compatibility.

OK. That argument has been won. Björn says he'll provide the GType
when he has time (didn't say when that would be!).

 Now, the SvGTypeName symbols are typically does as macros, not
 functions.  In fact, your earlier email showed this symbol defined as
 a macro.   This all suggests that the compiler is not seeing the
 SvGtkImageTransp macro and is instead trying to call it as an
 undefined function.  Do you see any compiler warnings to this effect
 when building the extension?  Are you including the header that
 defines this macro in your .xs file?

I think so. I've committed what I have done to date:

http://trac.bjourne.webfactional.com/browser/plgtkimageview/

As I said, the basic widget and the main methods work. The test suite
(such as it is) and the enum don't.

I'd be grateful if someone would tell me what I've missed with the
enum and whether I have dropped any major clangers before I carry on.

Thanks

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

Re: GtkImageView

[muppet]

On Dec 6, 2007, at 1:19 AM, Jeffrey Ratcliffe wrote:

 On 05/12/2007, BJörn Lindqvist [EMAIL PROTECTED] wrote:
 It is true that the enumeration GTypes probably should be declared in
 the C library, although it is not strictly necessary AFAIK. Take a
 look at how PyGtkImageView gets around it in
 http://trac.bjourne.webfactional.com/browser/pygtkimageview/src/Makefile.am 
 .
 I think a similar workaround should be possible for the Perl  
 bindings.

 But as far as I can see, he has simply the .h, as I do, and his
 corresponding .c is what you said should go in the .xs (thanks).

This is true, the C library is not required to provide a GType for the  
enumeration.  However, without a GType for the enumeration, the  
enumeration cannot be used in any object properties or signal  
arguments; it would have to be passed as an integer, because the type  
system doesn't know about it.  This would then require you to write  
icky, hard-to-maintain, special-case marshalers for all these things  
if you want to use the enumerations in perl.

So, yes, the upstream library doesn't *need* to provide the  
enumeration GType, but it saves everybody else work if it does.  Also,  
if and when he does add this upstream, you'll have to change your  
bindings to retain compatibility.



 /home/jeff/perl/Gtk2-ImageView/blib/arch/auto/Gtk2/ImageView/ 
 ImageView.so:
 undefined symbol: SvGtkImageTransp at
 /usr/lib/perl5/5.8.5/i386-linux-thread-multi/DynaLoader.pm line 230.

 I don't understand why I only get the above error with make test.

The unit tests run with LD_BIND_NOW.  This causes the dynamic linker  
to avoid its default behavior of lazy evaluation,  which is looking  
up the symbols on the first call, and instead causes the program to  
attempt to resolve all dynamic symbols at startup.  So, the function  
really isn't there, and the unit tests are finding this for you.   
Clearly, your standalone script never tries to call the function.

Now, the SvGTypeName symbols are typically does as macros, not  
functions.  In fact, your earlier email showed this symbol defined as  
a macro.   This all suggests that the compiler is not seeing the  
SvGtkImageTransp macro and is instead trying to call it as an  
undefined function.  Do you see any compiler warnings to this effect  
when building the extension?  Are you including the header that  
defines this macro in your .xs file?



--
The one difference between Dali and a crazy man is very simple: Dali  
is not crazy at all.
   -- Salvador Dali


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

Re: GtkImageView

[Jeffrey Ratcliffe]

On 04/12/2007, Emmanuele Bassi [EMAIL PROTECTED] wrote:
 the library should provide the GType for this enumeration, not the
 bindings; you should ask the author to do that, because bindings will
 have to keep a private function and nobody will be able to use that
 enumeration in properties or signal marshallers even in C.

I suggested this to Björn:

On 05/12/2007, BJörn Lindqvist [EMAIL PROTECTED] wrote:
 It is true that the enumeration GTypes probably should be declared in
 the C library, although it is not strictly necessary AFAIK. Take a
 look at how PyGtkImageView gets around it in
 http://trac.bjourne.webfactional.com/browser/pygtkimageview/src/Makefile.am.
 I think a similar workaround should be possible for the Perl bindings.

But as far as I can see, he has simply the .h, as I do, and his
corresponding .c is what you said should go in the .xs (thanks).

 you have to actually write the GType function:

 and then use the usual bindings stuff. you can also look at
 Gnome2::GConf for some custom defined types.

I added your GType function to the .xs (looking at Gnome2::GConf to see where).

I still have the problem that although I can use the widget OK without
error messaging from a stand-alone script, make test gives me:

t/01# Failed test (t/01.t at line 11)
# Tried to use 'Gtk2::ImageView'.
# Error:  Can't load
'/home/jeff/perl/Gtk2-ImageView/blib/arch/auto/Gtk2/ImageView/ImageView.so'
for module Gtk2::ImageView:
/home/jeff/perl/Gtk2-ImageView/blib/arch/auto/Gtk2/ImageView/ImageView.so:
undefined symbol: SvGtkImageTransp at
/usr/lib/perl5/5.8.5/i386-linux-thread-multi/DynaLoader.pm line 230.

I don't understand why I only get the above error with make test.

Regards

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

Re: GtkImageView

[Jeffrey Ratcliffe]

On 23/11/2007, Emmanuele Bassi [EMAIL PROTECTED] wrote:
 you can ask here if it's something relevant with the glib-perl API or
 the build environment.

I seem to be making good progress, but am stuck trying to bind the
following enum:

typedef enum
{
GTK_IMAGE_TRANSP_COLOR = 0,
GTK_IMAGE_TRANSP_BACKGROUND,
GTK_IMAGE_TRANSP_GRID
} GtkImageTransp;

In muppet's how_to, he talking about using glib-mkenums, so I added a
call to the Makefile.PL, producing:

#define GTKIMAGEVIEWPERL_TYPE_IMAGE_TRANSP
gtkimageviewperl_gtk_image_transp_get_type()
GType gtkimageviewperl_gtk_image_transp_get_type (void);

which seems to be included properly. I also defined:

#define SvGtkImageTransp(sv)   (gperl_convert_enum
(GTKIMAGEVIEWPERL_TYPE_IMAGE_TRANSP, (sv))
#define newSVGtkImageTransp(e)   (gperl_convert_back_enum
(GTKIMAGEVIEWPERL_TYPE_IMAGE_TRANSP, (e))

and added the following to the typemap:

GtkImageTransp  T_GPERL_GENERIC_WRAPPER

Although it compiles without error and I can use the widget in Perl, I
get the following error in a test suite:

t/01NOK 1# Failed test (t/01.t at line 11)
# Tried to use 'Gtk2::ImageView'.
# Error:  Can't load
'/home/jeff/perl/Gtk2-ImageView/blib/arch/auto/Gtk2/ImageView/ImageView.so'
for module Gtk2::ImageView:
/home/jeff/perl/Gtk2-ImageView/blib/arch/auto/Gtk2/ImageView/ImageView.so:
undefined symbol: SvGtkImageTransp at
/usr/lib/perl5/5.8.5/i386-linux-thread-multi/DynaLoader.pm line 230.

Any idea why the test suite doesn't even load the module properly?

Regards

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

Re: GtkImageView

[Emmanuele Bassi]

On Tue, 2007-12-04 at 15:16 +0100, Jeffrey Ratcliffe wrote:
 On 23/11/2007, Emmanuele Bassi [EMAIL PROTECTED] wrote:
  you can ask here if it's something relevant with the glib-perl API or
  the build environment.
 
 I seem to be making good progress, but am stuck trying to bind the
 following enum:
 
 typedef enum
 {
 GTK_IMAGE_TRANSP_COLOR = 0,
 GTK_IMAGE_TRANSP_BACKGROUND,
 GTK_IMAGE_TRANSP_GRID
 } GtkImageTransp;

the library should provide the GType for this enumeration, not the
bindings; you should ask the author to do that, because bindings will
have to keep a private function and nobody will be able to use that
enumeration in properties or signal marshallers even in C.

 #define GTKIMAGEVIEWPERL_TYPE_IMAGE_TRANSP
 gtkimageviewperl_gtk_image_transp_get_type()
 GType gtkimageviewperl_gtk_image_transp_get_type (void);
 
 which seems to be included properly. I also defined:
 
 #define SvGtkImageTransp(sv)   (gperl_convert_enum
 (GTKIMAGEVIEWPERL_TYPE_IMAGE_TRANSP, (sv))
 #define newSVGtkImageTransp(e)   (gperl_convert_back_enum
 (GTKIMAGEVIEWPERL_TYPE_IMAGE_TRANSP, (e))

you have to actually write the GType function:

  GType
  gtkimageviewperl_gtk_image_transp_get_type (void)
  {
static GType e_type = 0;

if (G_UNLIKELY (e_type == 0))
  {
const GEnumValue values[] = {
  { GTK_IMAGE_TRANSP_COLOR, GTK_IMAGE_TRANSP_COLOR, color },
  { GTK_IMAGE_TRANSP_BACKGROUND, GTK_IMAGE_TRANSP_BACKGROUND, 
background },
  { GTK_IMAGE_TRANSP_GRID, GTK_IMAGE_TRANSP_GRID, grid },
  { 0, NULL, NULL },
};

e_type =
  g_enum_register_static (g_intern_static_string (GtkImageTransp), 
values);
  }

return e_type;
  }

and then use the usual bindings stuff. you can also look at
Gnome2::GConf for some custom defined types.

ciao,
 Emmanuele.

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

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

Re: GtkImageView

[zentara]

On Fri, 23 Nov 2007 07:53:18 +0100
Jeffrey Ratcliffe [EMAIL PROTECTED] wrote:

On Tue, 07 Aug 2007 08:19:36 +0100, Emmanuele Bassi wrote:
 write your own widget. there's a very small C library providing a widget
 for displaying images called GtkImageView, which is not part of GTK+ and
 has no bindings for Perl; writing bindings might very well take half an
 hour and you could integrate it into your application.

I would like to write the bindings. I wrote a tiny but complete xs
module some time ago as a tutorial for myself, but this would be the
first time I wrote something useful with xs. I would be grateful for
some pointers before I start and waste a load of time going down blind
alleys.

Or should I be asking rather on perl-xs?


Are you looking for the gtk-image-viewer bindings?

http://giv.sourceforge.net/gtk-image-viewer/

zentara


-- 
I'm not really a human, but I play one on earth.
http://zentara.net/japh.html
___
gtk-perl-list mailing list
gtk-perl-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-perl-list

Re: GtkImageView

[Jeffrey Ratcliffe]

On 25/11/2007, zentara [EMAIL PROTECTED] wrote:
 Are you looking for the gtk-image-viewer bindings?

No GtkImageView is another widget. But I was using the bindings from
GtkImageViewer as an example.

Regards

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

Re: GtkImageView

[Emmanuele Bassi]

On Fri, 2007-11-23 at 07:53 +0100, Jeffrey Ratcliffe wrote:
 On Tue, 07 Aug 2007 08:19:36 +0100, Emmanuele Bassi wrote:
  write your own widget. there's a very small C library providing a widget
  for displaying images called GtkImageView, which is not part of GTK+ and
  has no bindings for Perl; writing bindings might very well take half an
  hour and you could integrate it into your application.
 
 I would like to write the bindings. I wrote a tiny but complete xs
 module some time ago as a tutorial for myself, but this would be the
 first time I wrote something useful with xs. I would be grateful for
 some pointers before I start and waste a load of time going down blind
 alleys.

there's the binding-howto in CVS and there's the source code for every
perl module as well. :-)

 Or should I be asking rather on perl-xs?

you can ask here if it's something relevant with the glib-perl API or
the build environment.

ciao,
 Emmanuele.

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

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

GtkImageView

[Jeffrey Ratcliffe]

On Tue, 07 Aug 2007 08:19:36 +0100, Emmanuele Bassi wrote:
 write your own widget. there's a very small C library providing a widget
 for displaying images called GtkImageView, which is not part of GTK+ and
 has no bindings for Perl; writing bindings might very well take half an
 hour and you could integrate it into your application.

I would like to write the bindings. I wrote a tiny but complete xs
module some time ago as a tutorial for myself, but this would be the
first time I wrote something useful with xs. I would be grateful for
some pointers before I start and waste a load of time going down blind
alleys.

Or should I be asking rather on perl-xs?

Regards

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