Re: Gtk2 1.160 build errors (Torsten Schoenfeld)



Torsten,

I'm using perl version 5.8.5 on Red Hat 4.

Regards,
Michael

----- Original Message ----
From: "gtk-perl-list-request gnome org" <gtk-perl-list-request gnome org>
To: gtk-perl-list gnome org
Sent: Friday, October 19, 2007 10:44:20 AM
Subject: gtk-perl-list Digest, Vol 42, Issue 14

Send gtk-perl-list mailing list submissions to
    gtk-perl-list gnome org

To subscribe or unsubscribe via the World Wide Web, visit
    http://mail.gnome.org/mailman/listinfo/gtk-perl-list
or, via email, send a message with subject or body 'help' to
    gtk-perl-list-request gnome org

You can reach the person managing the list at
    gtk-perl-list-owner gnome org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of gtk-perl-list digest..."


Today's Topics:

   1. Re: Gtk2 1.160 build errors (Torsten Schoenfeld)
   2. Re: Cairo 1.042 available (Torsten Schoenfeld)
   3. Re: Repacking a table (muppet)
   4. Strange test failures on 64 bit systems (Torsten Schoenfeld)
   5. gtktreeview.c assertion failed (Dave Howorth)
   6. Re: gtktreeview.c assertion failed (Emmanuele Bassi)
   7. Re: gtktreeview.c assertion failed (Dave Howorth)


----------------------------------------------------------------------

Message: 1
Date: Thu, 18 Oct 2007 18:21:03 +0200
From: Torsten Schoenfeld <kaffeetisch gmx de>
Subject: Re: Gtk2 1.160 build errors
To: gtk-perl-list gnome org
Cc: Francesco Zucca <francesco zucca gmail com>
Message-ID: <1192724463 5137 6 camel localhost localdomain>
Content-Type: text/plain

On Thu, 2007-09-27 at 21:27 -0400, muppet wrote:

> ... SO ...  that code *should* be fine.  Some parens wouldn't hurt  
> (e.g.,  my $func = ($flags & 'value') ? 'signal_connect_after' :  
> 'signal_connect';) but should not be necessary...  unless the  
> particular version of the perl interpreter used by the original  
> poster is somehow misparsing the line.
>
> So, Michael, what version of perl are you using?

Francesco Zucca reported the same problem off list.  He sees the error
with perl 5.8.6 on Slackware 10.2 but *not* with perl 5.8.8 on Slackware
12.0.  I can't find anything that looks related in perl's Changes file.

--
Bye,
-Torsten



------------------------------

Message: 2
Date: Thu, 18 Oct 2007 18:33:18 +0200
From: Torsten Schoenfeld <kaffeetisch gmx de>
Subject: Re: Cairo 1.042 available
To: gtk-perl-list gnome org
Message-ID: <1192725198 5137 8 camel kaffeetisch>
Content-Type: text/plain

On Tue, 2007-10-16 at 23:26 +0200, A. Pagaltzis wrote:

>     unless ( eval 'use Test::Number::Delta; 1;' ) {
>         my $reason = "Test::Number::Delta not available";
>         *delta_ok = sub { SKIP: { skip $reason, 1 } };
>     }

Good idea.  Committed.

--
Bye,
-Torsten



------------------------------

Message: 3
Date: Thu, 18 Oct 2007 12:46:12 -0400 (EDT)
From: "muppet" <scott asofyet org>
Subject: Re: Repacking a table
To: gtk-perl-list gnome org
Message-ID:
    <28070 192 146 101 24 1192725972 squirrel webmail asofyet org>
Content-Type: text/plain;charset=iso-8859-1


Johan Aberg wrote:
> I'm trying to update the items packed in the table but I'm not sure I
> understand how to do it. I was trying to destroy everything in the
> table and then loop over my new images and then call attach to rebuild
> the table with new the images. For various reasons in my design,  I
> can not just simply keep the images and just replace their pixbuffers
> to update the content of the table.

That seems like an odd limitation.  The Gtk2::Image widgets are just views for
your images and should be interchangeable.  Can't you fix your design?  After
all, if you wind up having to manipulate a table as you propose below, you're
doing something that is not very idiomatic for the toolkit and there's likely
to be an easier way.

For example, can you use a Gtk2::IconView instead of this manual table thing?


> My question is, is it possible to repack after the main event loop has
> been started? I seems to be able to destroy items, but not add table
> items once the program is running?

Yes.  Your solution will involve Gtk2::Container::remove() and
Gtk2::Container::get_children().

Note that Gtk2::Table does not appear to have a way to get the widget at some
location, so you need to know which child is which when you iterate over the
list of children.


> When I destroy an item with children, does GTK2 remove the children
> and free up the memory they allocated?

For the most part, yes.  Watch for reference cycles.  This is yet another
reason you'd likely be better off keeping only the pixbufs...


--
muppet <scott at asofyet dot org>



------------------------------

Message: 4
Date: Thu, 18 Oct 2007 19:42:12 +0200
From: Torsten Schoenfeld <kaffeetisch gmx de>
Subject: Strange test failures on 64 bit systems
To: gtk-perl-list gnome org
Message-ID: <1192729332 5137 23 camel kaffeetisch>
Content-Type: text/plain

Aloha,

for a while now, I've been receiving failure reports from CPAN testers
on 64 bit machines:

<http://www.nntp.perl.org/group/perl.cpan.testers/2007/09/msg662595.html>
<http://www.nntp.perl.org/group/perl.cpan.testers/2007/09/msg662661.html>
<http://www.nntp.perl.org/group/perl.cpan.testers/2007/10/msg676223.html>

They involve breakage of Glib's lazy package loader in various places
and/or an error about the "[m]odification of a read-only value attempted
at t/PangoLayout.t line 134."  There seems to be an accumulation of
these on 64 bit systems.  The second failure has also been seen on a
non-64 bit system, though:

<http://www.nntp.perl.org/group/perl.cpan.testers/2007/09/msg657927.html>

Does anyone have any clue what the problem might be?

--
Bye,
-Torsten



------------------------------

Message: 5
Date: Fri, 19 Oct 2007 10:43:19 +0100
From: Dave Howorth <dhoworth mrc-lmb cam ac uk>
Subject: gtktreeview.c assertion failed
To: gtk-perl-list gnome org
Message-ID: <47187C37 5020603 mrc-lmb cam ac uk>
Content-Type: text/plain; charset=UTF-8

I have a program that's using two Gtk2::TreeViews with a Gtk2::TreeStore
model and when I drag and drop nodes in the tree I'm getting gtk
warnings like this:

Gtk-CRITICAL **: file gtktreeview.c: line 4812 (validate_visible_area):
assertion `has_next' failed.
There is a disparity between the internal view of the GtkTreeView,
and the GtkTreeModel.  This generally means that the model has changed
without letting the view know.  Any display from now on is likely to
be incorrect.


The two TreeViews both show views of the same TreeStore and drag'n'drop
is enabled between them. This is to make it easier for users to drag
nodes from one place in the tree to a distant place. The GTK+ Tree and
List Widget Overview specifically says "One of the prime benefits of the
MVC design is that multiple views can be created of a single model". So
I think I'm OK to do this.

This is the code I use to enable drag'n'drop in each TreeView:

    my $target_entry = {
        target  => 'GTK_TREE_MODEL_ROW', # the drag type
        flags   => ['same-app'],# Gtk2::TargetFlags
        info    => 0,           # some app-defined integer identifier
        };

    $tree_view->enable_model_drag_dest(
                        ['move'],
                        $target_entry,
                );

    $tree_view->enable_model_drag_source(
                        'button1-mask',
                        ['move'],
  &nb sp;                     $target_entry,
                );


The warning seems to occur if I drag a node that is visible in the other
TreeView, even if I drop the node onto itself (i.e. drag just a few
pixels). The second TreeView updates correctly but I see the warning. If
the node I'm dragging is not visible in the other tree - either because
I've collapsed that part of the tree or because it's scrolled off the
bottom - then I don't get the warning. The warning also doesn't appear
if I enable drag'n'drop using 'same-widget' instead of 'same-app'.

I haven't been able to find any useful links about this problem. Has
anybody seen anything like it before? Or have any idea how to
investigate it? Or work around it?

Thanks, Dave

Perl Gtk2 module version 1.145
Built for gtk+ 2.6.4
Running with gtk+ 2.6.4


------------------------------

Message: 6
Date: Fri, 19 Oct 2007 10:56:11 +0100
From: Emmanuele Bassi <ebassi gmail com>
Subject: Re: gtktreeview.c assertion failed
To: gtk-perl-list gnome org
Message-ID: <1192787771 19532 4 camel sprite oh>
Content-Type: text/plain

On Fri, 2007-10-19 at 10:43 +0100, Dave Howorth wrote:
> I have a program that's using two Gtk2::TreeViews with a Gtk2::TreeStore
> model and when I drag and drop nodes in the tree I'm getting gtk
> warnings like this:

if you're getting GTK+ warnings then I suggest you write a minimal test
case in C reproducing the same behaviour and attach it to a newly opened
bug report in GNOME's Bugzilla[1]; but...

> Perl Gtk2 module version 1.145
> Built for gtk+ 2.6.4
> Running with gtk+ 2.6.4

... you do realize that 2.6.4 is a release made 2.5+ years ago (march
2005) and that even in the old 2.6 branch it has been superseded by
other 6 bug fixing releases? and that we're now at gtk+ 2.12.1? it might
be a bug in gtk+ itself and you're never going to get it looked at, let
alone get it fixed.

ciao,
Emmanuele.

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



------------------------------

Message: 7
Date: Fri, 19 Oct 2007 15:44:10 +0100
From: Dave Howorth <dhoworth mrc-lmb cam ac uk>
Subject: Re: gtktreeview.c assertion failed
To: gtk-perl-list gnome org
Message-ID: <4718C2BA 6060809 mrc-lmb cam ac uk>
Content-Type: text/plain; charset="utf-8"

Emmanuele Bassi wrote:
> On Fri, 2007-10-19 at 10:43 +0100, Dave Howorth wrote:
>> I have a program that's using two Gtk2::TreeViews with a Gtk2::TreeStore
>> model and when I drag and drop nodes in the tree I'm getting gtk
>> warnings like this:
>
> if you're getting GTK+ warnings then I suggest you write a minimal test
> case in C reproducing the same behaviour and attach it to a newly opened
> bug report in GNOME's Bugzilla[1]; but...

Thanks for the fast reply, Emmanuele. I've modified tree_store.c from
the gtk-demo program to have two trees with drag'n'drop enabled (using
code borrowed from testtreeview.c). The source is attached and I've
attached a diff to highlight the changes.

However, this program works but it doesn't show the problem. Since I've
no idea what's going wrong in my Perl program, I have even less idea of
how to modify the C program to make it break. It seems to me that
producing a simple Perl program that shows the problem might be a more
productive use of my time.

>> Perl Gtk2 module version 1.145
>> Built for gtk+ 2.6.4
>> Running with gtk+ 2.6.4
>
> ... you do realize that 2.6.4 is a release made 2.5+ years ago (march
> 2005) and that even in the old 2.6 branch it has been superseded by
> other 6 bug fixing releases? and that we're now at gtk+ 2.12.1? it might
> be a bug in gtk+ itself and you're never going to get it looked at, let
> alone get it fixed.

I know that it's old but getting users to upgrade every time there is a
new release is not the best use of everyone's time :) Besides, if it was
a problem in 2.6.4 that's been fixed in 2.12.1 I'd hope to have found
some clue in my searches and/or got a response from somebody who's seen
the problem. I'll run tests on 2.12.1 if I find something that looks
like a definite bug in 2.6.4.

Cheers, Dave
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: tree_store.c
Url: /archives/gtk-perl-list/attachments/20071019/7ff5ff4b/attachment.c
-------------- next part --------------
A non-text attachment was scrubbed...
Name: tree_store.diff
Type: text/x-patch
Size: 3292 bytes
Desc: not available
Url : /archives/gtk-perl-list/attachments/20071019/7ff5ff4b/attachment.bin

------------------------------

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


End of gtk-perl-list Digest, Vol 42, Issue 14
*********************************************



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]