Re: Differences between Gtk2::SimpleList and Gtk2::Ex::Simple::List
On Sep 29, 2014, at 6:36 AM, Thomas Funk t.f...@web.de wrote: Hi there, I am wondering what're the differences between those two modules apart from the fact that Gtk2::SimpleList is deprecated in favor of Gtk2::Ex::Simple::List? I've googled around but found nothing told me the reasons... Would be great if someone can explain it (or give me a link). As i recall, we realized that placing arbitrary perl modules directly into the Gtk2 namespace was a bad idea in the long run, opening us up to the possibility of name clashes and other problems as the upstream code grew. Moving from the original to the new name allowed fixing a couple of warts, and the new code continued to evolve. Another question I have is, is it possible to use Gtk2::SimpleList to create a treeview? This is only interesting if it's not a problem to use Gtk2::SimpleList in new code ;-) Thanks in advance, Thomas -- I've been using emacs for 20+ years and have barely touched lisp. I wouldn't know lambda calculus if it took all its clothes off and waved a placard that reads I am lambda calculus in blinking 48-point Comic Sans. -- Dave Hodgkinson, on london.pm ___ gtk-perl-list mailing list gtk-perl-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-perl-list
Re: ExtUtils::PkgConfig test failures on OpenBSD
On Dec 7, 2012, at 6:49 PM, Brian Manning wrote: Hi all, Devs with CPAN access to Gtk2-Perl modules have probably been receiving test failure reports for ExtUtils::PkgConfig on OpenBSD similar to this one [1]. I had some tuits last night and dug into the problem. You know that old joke that about your job being replaced with a Perl script? Well, on OpenBSD, the pkg-config binary from freedesktop.org [2] actually has been replaced with a Perl script [3]. The OpenBSD Perl script rewrite of the pkg-config binary is not honoring the --max-version command line switch, which causes one of the tests for this switch in ExtUtils::PkgConfig to fail. I just spotted the actual bug in their Perl pkg-config replacement, and will submit a patch shortly. My question here is, is the noise from this test worth adding a SKIP case for the tests in ExtUtils::PkgConfig on OpenBSD, or can we/should we just ignore the test failures until it's fixed upstream? Once deployed, any random software will tend to live forever. If it's easy to detect and skip, then be nice. If not, then the stock answer will be upgrade your pkg-config. Thanks, Brian [1] http://www.cpantesters.org/cpan/report/d2fbd25c-3bec-11e2-8669-e1a096fec937 [2] http://www.freedesktop.org/wiki/Software/pkg-config [3] http://www.openbsd.org/cgi-bin/man.cgi?query=pkg-config -- Yvonne: Let's do that one again so i can win. Zella: No. ___ gtk-perl-list mailing list gtk-perl-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-perl-list
Re: Next Gtk2-Perl release deadline: December 22nd at midnight UTC
On Dec 9, 2011, at 7:14 PM, Torsten Schoenfeld wrote: Let me hijack this thread to publicly thank you, Brian, for helping out with the releases. It really is a relief for me not having to worry about that. It also means that our users now again get the regular releases they deserve. Hear, hear! You guys are doing a great job. -- Well done, Android. Aperture Science reminds you that Android Hell is a real place, and you will be sent there at the first sign of defiance. -- GlaDOS ___ gtk-perl-list mailing list gtk-perl-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-perl-list
Re: RFC: Handling of floating references
On Aug 21, 2011, at 1:34 PM, Torsten Schoenfeld wrote: The attached patch generalizes the way we handle objects with floating references (for example, Glib::InitiallyUnowned descendants) such that it becomes correct also for Glib::Object::Introspection. The patch contains the rationale. Can anyone see something wrong with this? Looks good to me. You might be wondering why I didn't take the following approach: Register a custom sink func for GInitiallyUnowned that does ref_sink+unref, and then in gperl_object_new simply enforce own=1 for GInitiallyUnowned descendants. This would indeed be mostly equivalent to the patch, and would conceptually be cleaner. But I worry that their might be some weird class out there that does not descend from GInitiallyUnowned to get floating ref behavior but instead uses gobject's floating refs manually, via g_object_force_floating. 0001-Handle-ownership-of-objects-with-floating-refs-corre.patch -- Sallah! I said no camels! That's five camels! Can't you count? -- Indiana Jones ___ gtk-perl-list mailing list gtk-perl-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-perl-list
Re: Gtk2::Notebook and switch-page signal
On Jan 27, 2011, at 3:26 AM, Kiss Gabor (Bitman) wrote: What exactly are you trying to do? If you want to switch to a page you should use $notebook-set_current_page ($page_num). The page is already selected that is not a problem. However I want to trigger the signal handler function. I thought I don't call it directly. I checked: set_current_page() does not emit switch-page signal if page is already selected. I should have switch to another page then back. I'm afraid this should be avoided. Anyway the original question is: could somebody explain what gpointer mean in switch-page(Gtk2::Notebook, gpointer, Glib::UInt)? :-) Long ago when gtk+ was new, many signal arguments were made a void* type because in C you can just cast the pointer to what it's supposed to be. This was problematic for bindings, but only when people actually tried to use that functionailty, so many of them were overlooked. For this signal, in git master, the gpointer argument is now a proper GTK_TYPE_WIDGET representing the new selected child, suggesting someone attempted to fix this. You may be able to get a usable thing by doing $child = Glib::Object-new_from_pointer ($the_gpointer_value); if you really want to try using it. However, if it breaks, you get the keep the pieces. One problem with the signal documentation is that we get the signal signatures by asking the library at runtime for the types of the parameters. This information doesn't include parameter names, and doesn't explain which signals are private and which are public. Many of the very old things in gtk+ have signals when they actually just wanted virtual functions, so they're not always intended for application usage. -- Yvonne: Let's do that one again so i can win. Zella: No. ___ gtk-perl-list mailing list gtk-perl-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-perl-list
Re: Gtk2::EntryCompletion cursor-on-match
On Nov 6, 2010, at 7:53 AM, Zettai Muri wrote:
Hi All,
Am trying to connect to events again and this time in a Gtk2::EntryCompletion.
I have borrowed some of the code from:
http://www.koders.com/perl/fidB8CEA21DDF39929C30B4914E5CD897D03858890E.aspx?s=gtk2#L14
Below is what I have so far:
I've added inline the changes you need to make it work.
#!/usr/bin/perl
package main;
use strict;
use Gtk2 -init;
use Glib ':constants';
# Read in glade file with gui
my $builder = Gtk2::Builder-new;
$builder-add_from_file(EntryCompletion.glade);
my $main_window;
my $entry;
retrieve_widgets ();
# Create the completion object
my $completion = Gtk2::EntryCompletion-new;
# Assign the completion to the entry
$entry-set_completion ($completion);
# Create a tree model and use it as the completion model
$completion-set_model (create_completion_model ());
# Use model column 0 as the text column
$completion-set_text_column (0);
connect_signals;
# Maximise window
#$main_window-maximize;
# Run main loop.
Gtk2-main;
sub retrieve_widgets
{
# Get Widgets from gui file
$main_window = $builder-get_object('window1') || die Can't find
window.\n;
$entry = $builder-get_object('entry1') || die Can't find window.\n;
}
sub connect_signals
{
# Quit when user clicks on the close button/alt-f4 etc.
$main_window-signal_connect (destroy = sub { Gtk2-main_quit; });
# according to the gtk source, the cursor-on-match signal
# will be emitted only if the completion's inline-selection
# property is set to true.
$completion-set (inline_selection = TRUE);
$completion-signal_connect('cursor-on-match' = sub {
print(Cursor on Match\n);
# This is an event signal and must return TRUE if the event
# was handled or FALSE to let the default behavior go.
return FALSE;
});
}
# Creates a tree model containing the completions
sub create_completion_model {
my $store = Gtk2::ListStore-new (Glib::String::);
# Append one word
$store-set ($store-append, 0, GNOME);
# Append another word
$store-set ($store-append, 0, total);
# And another word
$store-set ($store-append, 0, totally);
return $store;
}
I'm just trying to get the cursor-on-match event to trigger my print
statement.
I was under the impression that the following would trigger the event:
1. In the entry field type 'to' (without the quotes).
2. This brings up the EntryCompletion and shows 'total' and 'totally'
3. Using the up and down arrow keys you can highlight the possible matches.
- At this point as I moved the selection up and down I thought this
would trigger the 'cursor-on-match' event. However I'm not getting
anything printed to my screen.
Is someone able to tell me how I match this event?
Have attached the glade file if that helps.
EntryCompletion.glade
--
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: Change Mouse Cursor
On Nov 5, 2010, at 6:08 AM, Mario Kemper wrote: The problem is that you connect the button_press_event to two different callbacks. I've changed your code in order make things work as you have described. It's quite alright to connect more than one callback to the same signal -- but you have to be careful about ordering and the return value. If you return true from an event signal, that means i handled the event, stop propagating it, so no more handler callbacks will be invoked. +1 for the Gtk2::EVENT_PROPAGATE constant. -- Aw, my lemon is empty. -- Yvonne, at dinner ___ gtk-perl-list mailing list gtk-perl-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-perl-list
Re: Question about cancelling sub-routine
On Aug 12, 2010, at 11:07 PM, Mike Martin wrote:
This works
if ($append == 1){
die (main::encode_loop) if $count == 100; # this is a count as a test
- the loop goes from 1-150
}
but if I try to put it as the action for a cancel sub it fails silently
$widget{btn_cancel}-signal_connect('clicked', sub {
die (main::encode_loop)
);
any suggestions
Need more context. Is the loop you're trying to kill on the main thread, on a
background thread, or a chain of idle events? Does the btn_cancel callback run
when clicked or wait to run until after the loop finishes?
As written, die() from a button callback is rather pointless. That will cause
the exception in the event handler, which will be caught and eaten (see old
threads from '04 or so for why that is, and the faq [1] for some info on what
it does).
If the encode_loop you're trying to cancel is on the main thread, then most
likely the callback doesn't run until after the encode_loop completes, because
that loop is blocking the main thread. You'd need to do Gtk2-main_iteration
while Gtk2-events_pending on each iteration of your encode_loop to handle
events and possibly catch the cancel button event. The event would have to set
a flag that the encode_loop checks because of the aforementioned die()-eating
behavior.
If the encode_loop is on another thread, you'll have to poke a thread-shared
variable that your other thread reads, or otherwise forcibly kill the other
thread.
[1]:
http://live.gnome.org/GTK2-Perl/FrequentlyAskedQuestions#My_app_doesn.27t_die_when_there.27s_a_problem_in_a_signal_callback.2C_I_just_get_some_strange_error_message.2C_what.27s_up_with_that.3F
--
Aw, my lemon is empty.
-- Yvonne, at dinner
___
gtk-perl-list mailing list
gtk-perl-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-perl-list
Re: (Fwd) Bug#582410: libgtk2-perl: FTBFS on mips: Failed test 'callbacks encountered'
On Jul 17, 2010, at 10:28 AM, gregor herrmann wrote:
see below: libgtk2-perl has problems on the mips build daemon in
Debian. Maybe some of you guys has any idea what's going on there?
[snip]
On Thu, May 20, 2010 at 06:57:26PM +0300, Niko Tyni wrote:
Package: libgtk2-perl
Version: 1:1.221-6
Severity: serious
This package is not migrating to testing because it failed to build
on mips.
# Failed test 'callbacks encountered'
# at t/GtkCellRenderer.t line 228.
# Structures begin differing at:
# $got-[2] = 'size'
# $expected-[2] = 'render'
# Looks like you failed 1 test of 20.
t/GtkCellRenderer.t
Dubious, test returned 1 (wstat 256, 0x100)
Failed 1/20 subtests
This is reproducible on gabrielli.d.o.
It's something of a heisenbug: running with the perl debugger
('perl -d -Iblib/lib -Iblib/arch t/GtkCellRenderer.t') fails the first time,
but after a restart ('R') the tests pass.
The callback that doesn't get called is gtk2perl_cell_renderer_render(),
in xs/GtkCellRenderer.xs.
The class callbacks get initialized properly in
gtk2perl_cell_renderer_class_init(), but gtk+ never calls the renderer
one.
It would be somewhat interesting to eliminate xvfb from the loop, but
I can't seem to get an X11 connection to gabrielli.
Unfortunately I won't have the time to look further into this in the
next few weeks. Hope this note helps somebody else a bit.
There's 1.222 available upstream, but looking at the changes, I very
much doubt it fixes this.
This behavior implies that there are cases in which the cell renderer is never
being asked to draw itself. Since it works sometimes and not others, it seems
unlikely that this is a problem with the bindings, but instead some interesting
interaction between gtk+ and/or the display server.
The build log indicates that the code was built against gtk+ 2.20.x, which is
roughly in the right time frame to have offscreen rendering and some treeview
drawing speed fixes. Either of these might cause the cell renderers not to be
rendered. Is it possible to test this same binding code against an older or
newer gtk+?
The build log also shows the unit tests complaining that the display is missing
the RENDER extension, which means that the tests were running with a DISPLAY.
I presume it is to this that your xvfb comment refers.
If the DISPLAY variable is empty, the unit tests will skip the attempts to do
real drawing and such, and only test binding and marshaling code. This build
mode is intended for use by automated packaging systems, and may be the best
option.
--
Baseball is complicated. I think I'd rather stick with learning about
motorcycle engines.
-- Elysse, baffled by the rules of baseball
___
gtk-perl-list mailing list
gtk-perl-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-perl-list
Re: g_bus_watch_proxy and introspection
On May 23, 2010, at 11:41 AM, Tomeu Vizoso wrote: This implies that GDestroyNotify is per callback, but in this case we have two callbacks and a single GDestroyNotify. What are bindings supposed to do in this case? Provided that both callbacks are invalidated when the object is destroyed, then you use a bit of glue code to use them together. Make a little structure containing the info for both callbacks, and attach that as the user data. The callback marshaller would look up the right slot, and the destroy notifier would invalidate and destroy both callbacks. This is not only something that bindings have to deal with -- users of the C api would have to do something similar. -- elysse: You dance better than some. me: Some what? elysse: Some asparagus. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Goo::Canvas deadlock on Gtk2::Gdk::Threads-enter
On May 10, 2010, at 2:18 AM, Xi Yang wrote: Is that means while I want to change UI in a working thread, it always needs to be done in a Idle time? Not exactly. Idle callbacks are always invoked on the main loop thread, even if queued from another thread, so you can use this to ensure that ui work happens only on the mainloop's thread. Alternatively, you can do ui stuff from a worker thread if you grab the gdk lock, first. In perl, this gets tricky because of the way scalars may or may not be shared between threads. What you can do depends on how you have set up your stuff. -- Baseball is complicated. I think I'd rather stick with learning about motorcycle engines. -- Elysse, baffled by the rules of baseball ___ gtk-perl-list mailing list gtk-perl-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-perl-list
Re: Goo::Canvas deadlock on Gtk2::Gdk::Threads-enter
On May 7, 2010, at 3:07 AM, Xi Yang wrote:
The following app has a GooCanvas, and has a button which will add a rect on
canvas after clicked. It deadlocks while click on Add button.
##
#!/usr/bin/perl
use strict;
use threads;
use threads::shared;
use Glib qw/TRUE FALSE/;
use Gtk2 qw/-init -threads-init/;
use Goo::Canvas;
Glib::Object-set_threadsafe(TRUE);
# create window
my $win = Gtk2::Window-new;
$win-signal_connect( destroy = sub { Gtk2-main_quit; } );
$win-set_title('children rendering test');
my $vbox = Gtk2::VBox-new( FALSE, 6 );
$win-add($vbox);
# create Add button
my $hbox = Gtk2::HBox-new(FALSE,6);
$vbox-pack_start($hbox,FALSE,FALSE,0);
my $but_add_node = Gtk2::Button-new('Add');
$hbox-pack_start($but_add_node,FALSE,FALSE,0);
$but_add_node-signal_connect('clicked'=\on_add);
# create the c anvas
my $canvas = Goo::Canvas-new();
my $root = $canvas-get_root_item;
$canvas-set_size_request( 800, 500 );
$vbox-pack_start( $canvas, FALSE, FALSE, 0 );
# enter mainloop
$win-show_all;
Gtk2::Gdk::Threads-enter;
Gtk2-main;
Gtk2::Gtk::Threads-leave;
If you're going to use gdk_threads_enter() and gdk_threads_leave() to protect
your callbacks, then you need to call gdk_threads_enter() before calling
Gtk2-main. The main loop will release the lock before it starts each
iteration.
http://mail.gnome.org/archives/gtk-devel-list/2007-January/msg00137.html
http://blogs.operationaldynamics.com/andrew/software/gnome-desktop/gtk-thread-awareness.html
sub on_add {
Gtk2::Gdk::Threads-enter;
Goo::Canvas::Rect-new(
$root,100,100,50,120
);
Gtk2::Gdk::Threads-leave;
}
##
Hotmail: Trusted email with powerful SPAM protection. Sign up
now.___
gtk-perl-list mailing list
gtk-perl-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-perl-list
--
Well done, Android. Aperture Science reminds you that Android Hell is a real
place, and you will be sent there at the first sign of defiance.
-- GlaDOS
___
gtk-perl-list mailing list
gtk-perl-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-perl-list
Re: Possible row selection interfering with Update
On Apr 9, 2010, at 7:26 PM, Zettai Muri wrote:
You're changing the selection mode on the first update. By moving the
$treeselect-set_mode('single') line from update_line() to init(), i could
no longer get the first time it acts weird behavior. Doubtless, changing
the mode causes the iter to be different.
Thank you for this, however I was hoping to also make it possible for the
user to select and delete multiple rows.
Any recommendations on how to provide this functionality while avoiding the
first update behaviour?
Leave the view in multiple selection mode, and use this instead of
get_selected():
@paths = $selection-get_selected_rows
Returns the Gtk2::TreePath of each selected row, or an empty list if no
rows are selected. The model is not returned, as documented in the C
API reference. To get the model, try
$selection-get_tree_view-get_model.
So your selection changed code would be
my @paths = $selection-get_selected_rows ();
if (@paths == 1) {
# exactly one selected, display it
display_row (...);
} else {
# either multiple rows selected, or nothing selected.
# clear the display.
undisplay (...);
}
# or you might want to allow modifying multiple elements
# at once, so you'd treat @path == 0 and @path 1 differently
and then the delete key handler would look like this (untested!):
my $model = $selection-get_tree_view-get_model;
foreach my $path (reverse $selection-get_selected_rows ()) {
$model-remove ($model-get_iter ($path));
}
After moving the tree selection setup to init, you may be interested in
using the two-return form of get_selection() and adding error checking:
my ($model, $iter) = $treeselection-get_selected;
return unless $iter;
In update_line() I have done the following:
# Get selected line number
my ($model, $iter) = $treeselection-get_selected;
return unless $iter;
#my $model = $tv_items-get_model;
#my $iter = $treeselection-get_selected;
However, now no update occurs. How should I be implementing this?
Did you set the selection mode at initialization?
--
Well done, Android. Aperture Science reminds you that Android Hell is a real
place, and you will be sent there at the first sign of defiance.
-- GlaDOS
___
gtk-perl-list mailing list
gtk-perl-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-perl-list
Re: How read glade file to gtk2?
On Mar 22, 2010, at 7:47 AM, Xiao Yafeng wrote:
I guess is ppm package of Gtk2, but not much sure since my script
could run on ubuntu correctly.
On Ubuntu Karmic, i needed to install libgtk2-perl (and did libgtk2-perl-doc to
get the manpages).
Gtk2::Builder requires that you have a new enough gtk+ to support it. If you
can't get it to run, verify that you have gtk+ 2.12 or later, and version
1.160 or newer of the Gtk2 perl module.
The script below runs just fine on Karmic. It's just a collection of the
snippets from this thread, with minor tweaks.
#!/usr/bin/env perl
use Gtk2 -init;
my $builder = Gtk2::Builder-new();
my $ui = '
?xml version=1.0?
interface
requires lib=gtk+ version=2.16/
!-- interface-naming-policy project-wide --
object class=GtkWindow id=window
child
object class=GtkVPaned id=vpaned1
property name=visibleTrue/property
property name=can_focusTrue/property
property name=orientationvertical/property
child
object class=GtkLabel id=label1
property name=visibleTrue/property
property name=label translatable=yesHello world/property
/object
packing
property name=resizeFalse/property
property name=shrinkTrue/property
/packing
/child
child
placeholder/
/child
/object
/child
/object
/interface
';
$builder-add_from_string ($ui);
my $object = $builder-get_object(window);
$object-show_all();
$object-signal_connect (destroy = sub {Gtk2-main_quit});
Gtk2-main();
__END__
--
Sallah! I said no camels! That's five camels! Can't you count?
-- Indiana Jones
___
gtk-perl-list mailing list
gtk-perl-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-perl-list
Re: Possible row selection interfering with Update
On Mar 27, 2010, at 5:19 PM, Zettai Muri wrote:
Hi All,
Please find attached my main.pl file along with the GtkBuilder file I have
the gui in. I couldn't think of a great example but it is using the same
code and widget types in my main project.
I am running the program on Windows XP with camelbox installed as 'perl
main.pl'
The problem is that only the shopper name updates not all of the new
information entered into the text views. I have to re-select the line,
re-enter the new information in the text views and then it updates the second
time around. It's easier to see if you run the program.
To Reproduce:
[snip excellent instructions, thanks]
Hope you can see what I'm talking about. It only occurs on the first
attempted update click.
Is someone able to tell me what I'm doing wrong? Can't work out why the
first time the update click only captures the shopper name but then works the
second time with the shopper name and the info entered into the text views.
I could reproduce the behavior by following the instructions exactly.
Initially, i clicked around a bit before following the instructions, and it
seemed fine.
You're changing the selection mode on the first update. By moving the
$treeselect-set_mode('single') line from update_line() to init(), i could no
longer get the first time it acts weird behavior. Doubtless, changing the
mode causes the iter to be different.
I was also getting some warnings on stdout.
*** unhandled exception in callback:
*** variable not allowed to be undef where GtkTreeIter is wanted at main.pl
line 262.
*** ignoring at main.pl line 66.
It's best not to ignore those. ;-)
After moving the tree selection setup to init, you may be interested in using
the two-return form of get_selection() and adding error checking:
my ($model, $iter) = $treeselection-get_selected;
return unless $iter;
The lines
# Update the view
$tv_items-set_model($model);
are not actually necessary; if you were swapping out the model to freeze
updates, then that would be necessary, but you're not, so it's not. In fact,
the set_value calls immediately above are enough to make everything Just Work.
Oh, and in connect_signals(), you have each clicked handler getting $widget
and $event off the stack; but there's no $event parameter to the clicked
signal.
--
Zella, carrying a kite in a long plastic box: It's like book!
Yvonne, carrying the wooden kite string spool: It's like a wood!
___
gtk-perl-list mailing list
gtk-perl-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-perl-list
Re: Custom TreeModel
On Jan 21, 2010, at 5:33 PM, Kevin Ryde wrote: Dave Howorth dhowo...@mrc-lmb.cam.ac.uk writes: are not valid when the model is changed, even though get_flags returns 'iters-persist'. Hmm. That's not quite right is it? Is it referring to the way a Gtk2::TreeIter object in a signal callback is no good outside that callback (unless copied)? Like the next sentence about -foreach? That passage found its way into the docs because of the discussion starting here: http://mail.gnome.org/archives/gtk-perl-list/2007-November/msg00016.html -- 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: Testing for memory leaks in GTK
On Jan 5, 2010, at 4:45 PM, Erik de Castro Lopo wrote: Tomeu Vizoso wrote: RefDbg is useful in these cases. Where can I get some more info on that? Google knows all: http://www.google.com/search?q=refdbg first hit: http://refdbg.sourceforge.net/ -- 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-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: 'Suspect' libglib-2.0 when launching Ardour2.8.4
On Dec 13, 2009, at 9:30 PM, G. GuitarLord wrote: The /usr/lib/libglib-2.0.so is a symbolic link that points to libglib-2.0.so.0.2200.0. Which, in turn, is installed from the compiled glib2.22.0 directory. SO, the 'nm' command you told me to run checks the file it is supposed to check...I just saw this, don't know if it helps... YUM, however, still thinks that the Glib2 version is 2.14.6... I guess that compiling and installing a new Glib system-wide, does not have any impact, as long as it is done without errors, right? You pretty much never want to do an install from source to /usr on a system managed by yum or dpkg or the like. You have overwritten data in /usr that is supposed to be managed by the rpm database managed by yum. In the future, either install the new glib to a private location, or use an upgrade rpm. There should be a way to ask rpm to restore the version that you have overwritten. -- Yvonne: Let's do that one again so i can win. Zella: No. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GLib/perl and GArray, GType
On Feb 5, 2009, at 2:42 PM, Torsten Schoenfeld wrote:
Wouter Verhelst wrote:
I seem to be misunderstanding the GParamSpecGType docs when they talk
about how is_a_type works when it's G_TYPE_NONE.
I don't quite understand what you're talking about here, muppet. The test
cases in your patch all work fine for me, even those that are commented out
can be made to work. I attach an updated patch with more tests. Commit?
I appear to have been on crack. Yes, commit.
Doesn't seem to work the way it should. When I do this:
$model-set(type = Nspos::Db::Order);
the warning message looks like this:
Glib-GObject-WARNING **: value ((gpointer) 0x1c) of type `GType' is
invalid or out of range for property `type' of type `GType' at (...)
This is the error message you get when you try set a GType property to a
GType that is not a descendant of the GType property's is_a_type (that is,
the fourth argument to Glib::ParamSpec-gtype). So, in your example, it
seems that Nspos::Db::Order is not a descendant of type's is_a_type -- at
least as far as Glib's type system is concerned.
Index: GParamSpec.xs
===
--- GParamSpec.xs (revision 1083)
+++ GParamSpec.xs (working copy)
@@ -263,6 +263,9 @@ BOOT:
#if GLIB_CHECK_VERSION(2,4,0)
gperl_register_param_spec (G_TYPE_PARAM_OVERRIDE,
Glib::Param::Override);
#endif
+#if GLIB_CHECK_VERSION(2,10,0)
+ gperl_register_param_spec (G_TYPE_PARAM_GTYPE, Glib::Param::GType);
+#endif
=for enum Glib::ParamFlags
=cut
@@ -569,6 +572,23 @@ scalar (class, name, nick, blurb, flags)
### GParamSpec* g_param_spec_value_array (const gchar *name, const gchar
*nick, const gchar *blurb, GParamSpec *element_spec, GParamFlags flags)
+#if GLIB_CHECK_VERSION(2, 10, 0)
+
+=for apidoc
+=for arg is_a_type The name of a class whose subtypes are allowed as values
of the property. Use Cundef to allow any type.
+=cut
+GParamSpec*
+g_param_spec_gtype (class, name, nick, blurb, is_a_type, flags)
+ const gchar *name
+ const gchar *nick
+ const gchar *blurb
+ const gchar_ornull *is_a_type
+ GParamFlags flags
+C_ARGS:
+ name, nick, blurb, is_a_type ? gperl_type_from_package (is_a_type) :
G_TYPE_NONE, flags
+
+#endif
+
accessors
@@ -1198,3 +1218,36 @@ get_default_value (GParamSpec * pspec_un
## G_TYPE_PARAM_POINTER, Glib::Param::Pointer -- no members
## G_TYPE_PARAM_OBJECT, Glib::Param::Object -- no members
## G_TYPE_PARAM_OVERRIDE, Glib::Param::Override -- no public members
+
+
+MODULE = Glib::ParamSpec PACKAGE = Glib::Param::GType
+
+#if GLIB_CHECK_VERSION(2, 10, 0)
+
+=for section DESCRIPTION
+
+=head1 DESCRIPTION
+
+This object describes a parameter which holds the name of a class known to
the
+GLib type system. The name of the class is considered to be the common
+ancestor for valid values. To create a param that allows any type name,
+specify Cundef for the package name. Beware, however, that although
+we say any type name, this actually refers to any type registered
+with Glib; normal Perl packages will not work.
+
+=cut
+
+=for apidoc
+If Cundef, then any class is allowed.
+=cut
+const gchar_ornull *
+is_a_type (GParamSpec * pspec_gtype)
+CODE:
+ GParamSpecGType * p = G_PARAM_SPEC_GTYPE (pspec_gtype);
+ RETVAL = p-is_a_type == G_TYPE_NONE
+ ? NULL
+ : gperl_package_from_type (p-is_a_type);
+OUTPUT:
+ RETVAL
+
+#endif
Index: t/e.t
===
--- t/e.t (revision 1083)
+++ t/e.t (working copy)
@@ -5,7 +5,7 @@
use strict;
use utf8;
use Glib ':constants';
-use Test::More tests = 243;
+use Test::More tests = 259;
# first register some types with which to play below.
@@ -210,6 +210,56 @@ foreach (@params) {
#
+# Since this is conditional on version, we don't want to overcomplicate
+# the testing logic above.
+#
+SKIP: {
+ skip GParamSpecGType is new in glib 2.10.0, 16
+ unless Glib-CHECK_VERSION (2, 10, 0);
+ @params = ();
+
+ $pspec = Glib::ParamSpec-gtype ('object', 'Object Type',
+ Any object type,
+ Glib::Object::,
+ G_PARAM_READWRITE);
+ isa_ok ($pspec, 'Glib::Param::GType');
+ isa_ok ($pspec, 'Glib::ParamSpec');
+ is ($pspec-is_a_type, 'Glib::Object');
+ push @params, $pspec;
+
+ $pspec = Glib::ParamSpec-gtype ('type', 'Any type', Any type,
+ undef, G_PARAM_READWRITE);
+ isa_ok ($pspec, 'Glib::Param::GType');
+ isa_ok ($pspec, 'Glib::ParamSpec');
+ is ($pspec-is_a_type, undef);
+ push @params, $pspec;
+
+ Glib::Type-register ('Glib::Object' = 'Baz', properties =
\...@params);
+
+ my $baz = Glib::Object
Re: Gtk2::MessageDialog title
On Nov 23, 2009, at 3:49 PM, Kevin Ryde wrote: muppet sc...@asofyet.org writes: But beware that the gnome human interface guidelines say that alert windows should have no title, You'd probably want the application name in there at least, to know what's to blame, in particular if it gets iconified so the message text can't be seen. Alerts are supposed to be modal and parented to prevent that. With a compliant window manager, at least. -- 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: Gtk2::MessageDialog title
On Nov 20, 2009, at 11:01 PM, Zettai Muri wrote:
Is it possible to set the title of a MessageDialog?
Of course. Gtk2::MessageDialog isa Gtk2::Dialog isa Gtk2::Window, so
just just Gtk2::Window::set_title(). See below.
But beware that the gnome human interface guidelines say that alert
windows should have no title, as the title would normally just
duplicate the text of the message... so, depending on what you're
doing, you might actually want to blank out the title.
http://library.gnome.org/devel/hig-book/stable/windows-alert.html.en
I have the following:
sub show_duplicate_dialog
{
#
# A modal dialog. Note that the message is a printf-style format.
#
my($duplicate) = @_;
my($dialog) = Gtk2::MessageDialog-new (undef,
'destroy-with-parent',
'error', # message type
'ok', # which set of buttons?
#printf format:
\%s\ already selected.,
$duplicate);
$dialog-set_title (Fooo);
my($response) = $dialog-run;
$dialog-destroy;
}
But can't work out how to add a title to the dialog box that appears.
For each widget in Gtk2 there is a man page; each man page has a
HIERARCHY section, which shows the class ancestry for that type. Or
you can look at the C api reference on gtk.org, which has the same
info in a different format.
--
Applause is an addiction, like heroin or checking your email.
-- Sideshow Mel
___
gtk-perl-list mailing list
gtk-perl-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-perl-list
Re: Gtk2::TreeModel - foreach
On Nov 19, 2009, at 4:15 PM, Jeff Hallock wrote: -Original Message- From: gtk-perl-list-boun...@gnome.org [mailto:gtk-perl-list- boun...@gnome.org] On Behalf Of Zettai Muri Sent: Thursday, November 19, 2009 3:56 PM To: Martin Schlemmer; gtk-perl-list@gnome.org Subject: Re: Gtk2::TreeModel - foreach Where does the $user_data (scalar) part of the method come into play? Is it possible to get an extended example that shows how this is used? Is this data within the ListStore or some other data passed to the method? How does the method act on this data? Again thanks for the help. If you supply $user_data - then you it will be passed in as the last argument to the ForEach function. If you're thinking, but i can just use a closure for that, then you're already thinking perlishly. The C api has user data pointers all over the place, because C doesn't have closures. In perl, you get the option of using a closure or passing different parameters to a single function. You'd choose to use the single function plus user data instead of a closure in a situation in which the closure would introduce a reference cycle. Pretty much any other time, you'd use a closure. -- I can't believe i'm having to arbitrate who gets to have what dress on whose monkey. -- Me, exasperated at the ridiculousness of parenthood. ___ gtk-perl-list mailing list gtk-perl-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-perl-list
Re: dynamic mixing of primitives and background picture - semi-gui cropping utility
On Nov 11, 2009, at 1:47 AM, postdo...@yahoo.fr wrote:
Thanks for the input.
Any pointer on how to do the in app drawing?
Get the pixels from the pixbuf, treat them as a string of binary data
and use pack() and unpack() to manipulate it. There's an example in
the Gtk2 source tarball, if i recall correctly. You can also check
the list archives.
Also, is there a way to make the window scroll automatically to the
appropriate corner of the image when the keys 1-4 are pressed.
It'd be nice to have that when viewing the full-size picture.
Set the adjustments' values, something like this (completely untested):
sub set_adj_to_max {
my $adj = shift;
my ($upper, $page_size) = $adj-get ('upper', 'page-size');
$adj-set_value ($upper - $page_size);
}
sub set_adj_to_min {
my $adj = shift;
$adj-set_value ($adj-get ('lower'));
}
sub scroll_to_corner {
my $which = shift;
my $hadj = $scrolled_window-get_hadjustment ();
my $vadj = $scrolled_window-get_vadjustment ();
if ($which eq 'northwest') {
set_adj_to_min ($hadj)
set_adj_to_min ($vadj);
} elsif ($which eq 'northeast') {
set_adj_to_max ($hadj);
set_adj_to_min ($vadj);
} elsif ($which eq 'southeast') {
set_adj_to_max ($hadj);
set_adj_to_max ($vadj);
} elsif ($which eq 'southwest') {
set_adj_to_min ($hadj);
set_adj_to_max ($vadj);
}
}
--
I can't believe i'm having to arbitrate who gets to have what dress on
whose monkey.
-- Me, exasperated at the ridiculousness of parenthood.
___
gtk-perl-list mailing list
gtk-perl-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-perl-list
Re: dynamic mixing of primitives and background picture - semi-gui cropping utility
On Nov 8, 2009, at 10:33 AM, postdo...@yahoo.fr postdo...@yahoo.fr
wrote:
Dear Fellow Gtk-Perlers,
See my attempt below at a semi-gui jpeg lossless cropping utility.
The idea is to cycle through a few jpeg files, set the crop
parameters by moving sliders with cursor keys, and crop the jpegs
losslessly.
y program works, but is quite Mc Gyver-like. I go back and forth
between perlmagick and gtk2 to draw the cropping rectangle and the
background picture. And I think it should be much faster to only
redraw the part of the background were the previous crop rectangle
was instead of redrawing the whole thing.
A little background: I have a bunch of jpegs that are produced by a
camera shooting old slides (a cheap and dirty slide scanner). They
all have black borders due to the copying setup. What I aim is to
check that the crop parameters are correct on each picture. Lossless
means cropping along multiple of 8 pixels using appropriate outside
utilities (namely jpegtran).
Thanks for any input!
Guillaume
auto_crop_new
You forgot use strict!
Instead of hard-coded numeric key values, you should use the keysyms
hash.
use Gtk2::Gdk::Keysyms;
...
if ($key_val == $Gtk2::Gdk::Keysyms{GDK_Up}) {
etc
(Or mess around with an accelerator table. For what you have, the key
value processing is probably nice and user-friendly, as it requires no
modifier keys.)
Instead of connecting to delete-event to quit the main loop, do that
in the destroy signal on the window. Then you can add q as a
hotkey, and just call $window-destroy and the right thing will happen.
In auto_crop(), should check $color for an empty value; i loaded up a
jpeg that didn't have a border, and imagemagic returned no border for
it, causing a bunch of uninitialized value warnings.
Oh, actually my imagemagick is too old to support the special info:
name. You might want to do a version check on convert before doing
that stuff.
If you want to learn about gdk, you can try to do the drawing all in
the app instead of bouncing back and forth with imagemagick. You
could also take the slow route and draw on the pixels in perl, but
that's a bit icky.
--
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: Problems with GHashTable in signal handler
On Oct 25, 2009, at 8:55 AM, Jörn Reder wrote: Hi, I try to use the create-plugin-widget signal of Gtk2::WebKit::WebView, which passes a GHashTable to the callback. Here it's signature from the docs: GtkWidget* user_function (WebKitWebView *web_view, gchar *mime_type, gchar *uri, GHashTable*param, gpointer user_data) : Run Last / Action (from http://webkitgtk.org/reference/webkitgtk-WebKitWebView.html#WebKitWebView-create-plugin-widget ) Perl dies with this error message when my signal handler is called: GType GHashTable (146176672) is not registered with gperl Since signal handling is completely covered on Glib level I don't think this problem is related to Gtk2::WebKit. The Glib perldoc says GHashTable is bound to the native Perl hash datatype. I grep'ed the sources of Glib and Gtk2 to find any examples of passing GHashTables to Perl - with no luck. Any help on this is appreciated ;) Actually, the docs say The GLib types GList (a doubly-linked list), GSList (singly-linked list), GHashTable, GArray, etc have all been replaced by native Perl datatypes. That is, replace by, not bound to. GHashTable is not really bindable, because it is a generic mapping of arbitrary pointer to arbitrary pointer; you must know something about what is in it in order to use it, and we can't create a generic wrapper for that. Therefore, for each function that passes a hash table, we map that by hand to a perl hash. However, it's not actually very common for the gnome APIs to pass GHashTables around -- they're normally used for implementation. In fact, i can't really think of where we've had to do this... libgobject started registering a GType for GHashTable in 2.10, to make it possible to say this signal argument is a hash table instead of this signal argument is a pointer. However, as the gobject- introspection guys pointed out, this isn't terribly useful; you need to know more information, like this object is a hash table whose keys are strings and whose values are gobjects. We don't have that at a generic level. So the only real option that you have is to create a custom marshaller for this signal, implemented in Gtk2::WebKit::WebView. This marshaller would be used only for this signal, where we know that the hash table is supposed to be a map of strings to strings. You'd do something like call g_hash_table_foreach() to push all the keys and values in the hash table into a new hash, and pass a reference to that new hash to perl in place of the hash table. (The closer you stick to the C api, the fewer problems people will have here.) If you're supposed to allow the callback to modify the hash, then you'll have to push those changes back the other way when the callback returns. Read gperl_marshal.h for a template and helpers. There are a few examples of custom marshallers in Gtk2, nearly all used for arguments that are unfriendly to non-C languages (e.g. write-through integer parameters, C arrays, and G_TYPE_POINTER args that you're supposed to cast to something else). Search Gtk2 for gperl_signal_set_marshaller_for and follow where that takes you. From Glib::xsapi: void gperl_signal_set_marshaller_for (GType instance_type, char * detailed_signal, GClosureMarshal marshaller) You need this function only in rare cases, usually as workarounds for bad signal parameter types or to implement writable arguments. Use the given marshaller to marshal all handlers for detailed_sig- nal on instance_type. gperl_signal_connect will look for mar- shallers registered here, and apply them to the GPerlClosure it creates for the given callback being connected. Use the helper macros in gperl_marshal.h to help write your mar- shaller function. That header, which is installed with the Glib module but not #included through gperl.h, includes commentary and examples which you should follow closely to avoid nasty bugs. Use the Source, Luke. WARNING: Bend over backwards and turn your head around 720 degrees before attempting to write a GPerlClosure marshaller without using the macros in gperl_marshal.h. If you absolutely cannot use those macros, be certain to understand what those macros do so you can get the semantics correct, and keep your code synchronized with them, or you may miss very important bugfixes. -- Me: What's that in your mouth? Zella: *swallows laboriously* Nothing. Me: What did you just swallow? Zella: A booger. Me: Baby girl, don't eat boogers. That's gross. Zella: But it was in my nose. ___ gtk-perl-list mailing list gtk-perl-list@gnome.org
Re: How do I destroy window without freezing window?
On Sep 11, 2009, at 2:52 PM, Perl Whore wrote:
my $dialog = Gtk2::Dialog-new (
[snip]
$dialog-set_default_response ('ok');
$dialog-signal_connect (response = sub {
shift;
my $response = shift;
if ($response eq 'yes'){ Gtk2-
main_quit; }
if ($response eq 'no'){ Gtk2-
main_quit; exit; }
});
$dialog-show;
Gtk2-main;
You're not actually destroying the window. You need to do that or the
window doesn't go away until the process exits. Also, you're not
letting the main loop run to finish the destruction of the window,
which is further fail. Since no event loop is running, the window
appears frozen.
But since you want to block execution until the dialog is answered, I
think you mean to do this, instead:
# run the dialog modally, and return when the user responds.
my $response = $dialog-run ();
# kill the dialog now.
$dialog-destroy ();
# and now act on the response.
exit if $response eq 'no;
--
Teeter tots are shaped like marshmallows.
-- Zella.
___
gtk-perl-list mailing list
gtk-perl-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-perl-list
Re: problem with Gtk2::Helper STDOUT
On Sep 10, 2009, at 7:16 AM, Landry Breuil wrote:
i'm asking here after turning around a strange problem for days...
i can't get to make Gtk2::Helper watch the STDOUT of the current
program
(not from a forked child or whatever). The idea is to do smth like
'tail' but
in a Gtk Widget or VTE Widget, but showing current process STDOUT.
As Matthew already mentioned, i don't think this is really a gtk+
issue, but the fact that STDOUT is a write-only file handle always
pointing at the end.
You may get more mileage out of a minor modification of your program,
making evil use of some very perlish things:
#!/usr/bin/perl -w
use strict;
use Glib 1.040, qw(TRUE FALSE);
use Gtk2;
use Data::Dumper;
use Gtk2::Helper;
Gtk2-init();
my $window = Gtk2::Window-new;
$window-signal_connect (delete_event = sub {exit});
$window-set_default_size (400, 300);
my $vbox = Gtk2::VBox-new;
$window-add ($vbox);
my $scroller = Gtk2::ScrolledWindow-new;
$vbox-add ($scroller);
my $textview = Gtk2::TextView-new;
my $buffer = $textview-get_buffer;
$buffer-create_mark ('end', $buffer-get_end_iter, FALSE);
$buffer-signal_connect (insert_text = sub { $textview-
scroll_to_mark ($buffer-get_mark ('end'), 0.0, TRUE, 0, 0.5);});
$scroller-add ($textview);
my $button = Gtk2::Button-new ('go');
$button-signal_connect (clicked = \button_handler);
$vbox-pack_start ($button, FALSE, FALSE, 0);
$window-show_all;
Gtk2-main;
exit;
sub button_handler {
$button-set_sensitive (FALSE);
# create a new tied handle with a callback that will
# copy what ever we print to the window.
tie *STDOUTANDWINDOW, 'LineCopy', *STDOUT, sub {
$buffer-insert ($buffer-get_end_iter, $_[0])
});
select STDOUTANDWINDOW;
print STDERR FOO1\n;
print FOO2\n;
# sleep 1 is evil, use a timeout, instead.
Glib::Timeout-add (1000, sub { Gtk2-main_quit; FALSE });
Gtk2-main;
print STDOUTANDWINDOW FOO3\n;
$buffer-insert ($buffer-get_end_iter, done);
$button-set_sensitive (TRUE);
# undo what we did.
untie *STDOUTANDWINDOW;
select STDOUT;
};
package LineCopy;
sub TIEHANDLE {
my ($class, $handle, $callback) = @_;
return bless { buffer = '', handle = $handle, callback =
$callback };
}
sub PRINT {
my $self = shift;
foreach (@_) {
$self-{callback} ($_) if $self-{callback};
print { $self-{handle} } $_;
}
}
--
The trees on the bus go pyoo pyoo pyoo...
-- Yvonne, singing, um, something
___
gtk-perl-list mailing list
gtk-perl-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-perl-list
Re: New to GTK+ and a question about Combo boxes.
On Aug 31, 2009, at 10:29 PM, Steve Manes wrote:
I'm building a Perk-GTK application on Windows which includes a
date element, which is three ComboBoxes clustered together in an
Hbox: month, day, year.
Since there are several places in the application where a date is
added, I built a function to return an Hbox containing those three
combo boxes:
sub make_date
{
[snip packing a bunch of stuff into a new hbox]
return $hbox;
}
$E is a global hash I'm using for the time being to keep track of
all the elements -- at least until I get more expert with GTK.
My questions:
1) How come whenever I resize the window the ComboBoxes themselves
also expand? I've tried every combination in the pack_start
function to no avail.
You didn't mention whether they expand vertically or horizontally. If
they're expanding vertically, it's not a problem with your hbox
packing, but with how you pack the hbox into the window -- if you let
the hbox expand inside a vbox, you'll get what i think you're talking
about.
If they're still expanding horizontally, please post a bit more code
-- just enough that we can run it and play with it.
Screenshots would help. ;-)
2) How come the pulldown lists appear (for lack of a better term)
double spaced? Is there a fix for that?
Do you have newlines in your strings? Perhaps it's a theme issue?
3) How come I can't seem to get rid of the padding between the three
ComboBoxes? I'd like there to be no space between them.
4) One more oddity: if I stick the output of this function in a
table cell like this:
$table-attach_defaults(make_date('dob', 1950, 2010), 3, 4, $row,
row+1);
and then give the table a small row spacing, like $table-
set_row_spacings(2), the comboboxes expand to like 3x their normal
height.
This one sounds like you need to attach() instead of attach_defaults
(), and choose the please don't expand in any direction options.
--
me, while driving the car: Okay, girls, what do you want for lunch?
yvonne: I wan' noo-tulls!
zella: I want lavaloli! Can we go to the lavaloli store?
me: Um, where *is* the ravioli store?
zella: At the lavaloli store!
yvonne: I want noo-tulls! Let's go to the noo-tull store!
___
gtk-perl-list mailing list
gtk-perl-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-perl-list
Re: Speeding up thumbnail generation (like multi threaded). Thoughts please.
On Aug 29, 2009, at 8:08 AM, Mark wrote:
Oke, i did some ltracing now. Here is the ltrace output for 5 images
that get thumbnailed. I hope anyone here could help me a bit in
explaining this output since it's not all obvious to me.
Before you read the output. i put a 2 second sleep after a image is
done and the pixbuffs are removed from memory. This makes it a lot
more easy to identify where the image loading/scaling/saving is
happening.
The output is here: http://codepad.org/ydtCcJ5d
I find rows of timestamps hard to read for a sense of how long each
thing took, so i loaded this up in a home-grown trace visualizer i
created a while back (inspired by Federico's time charts -- this is an
interactive version). It's missing the ability to zoom the timeline,
so the left side is a bit squished, but you can get the idea. Here's
a screenshot of the first image's data:
http://asofyet.org/muppet/tmp/thumbnail-lprof-viz.png
You can see that the blue lines with gaps in between represent SYS_read
() (reading the input file), then another, smaller gap for the scaling
(doing the work), followed by a chunk of orage for the memcpy()s and
writes (outputting the thumnail). As you'd expect, it takes longer to
read the full file than to write the thumbnail.
Now for the splitting up that i did to sort out io and cpu.
This is all in the 1251553123 timeframe so it's just one image.
1251553123.625556
_ZStlsIcSt11char_traitsIcESaIcEERSt13basic_ostreamIT_T0_ES7_RKSbIS4_S5_T1_E
(0x613de0,
0x701ac0, 16, 15416, 0x7a4b2a90) = 0x613de0
1251553123.625635 _ZNSsC1Ev(0x7a4b2f90, 0x6ed100, 8, 8,
0x5f7974696e616d75) = 0x7fcaa64de158
1251553123.625683
_ZNSt18basic_stringstreamIcSt11char_traitsIcESaIcEE3strERKSs
(0x7a4b2de0,
0x7a4b2f90, 0x7a4b2f90, 8, 0x5f7974696e616d75) = 0x781578
1251553123.625733 _ZNSsD1Ev(0x7a4b2f90, 0x781578, 0x781578, 0,
0x781778) = 0x7fcaa64de158
1251553123.625781
_ZStlsISt11char_traitsIcEERSt13basic_ostreamIcT_ES5_PKc
(0x7a4b2df0,
0x40c950, 16, 0, 0x781778) = 0x7a4b2df0
1251553123.625830
_ZStlsIcSt11char_traitsIcESaIcEERSt13basic_ostreamIT_T0_ES7_RKSbIS4_S5_T1_E
(0x7a4b2df0,
0x701ac0, 88, 88, 0x2f6e6f6974616d69) = 0x7a4b2df0
1251553123.625878
_ZNKSt18basic_stringstreamIcSt11char_traitsIcESaIcEE3strEv
(0x7a4b2fa0,
0x7a4b2de0, 0x7a4b2de0, 88, 0x5f7974696e616d75) =
0x7a4b2fa0
1251553123.625929 _ZNSsaSERKSs(0x7a4b2f60, 0x7a4b2fa0,
0x7a4b2fa0, 0x7fcaa64de140, 0x69525f7974696e61) = 0x7a4b2f60
1251553123.625977 _ZNSsD1Ev(0x7a4b2fa0, 0, 0x786c50, 0x5cf210,
0x69525f7974696e61) = 0x782018
I have no clue what is going on in those _Z* functions.. what are
those?
Those are the real symbol names of C++ functions and methods. The C++
compiler encodes the return type and parameter types into the real
symbol names, as described by the C++ ABI. If you pass the -C or --
demangle option to ltrace, he'll make those into something readable.
Anyway, above you can see stuff like basic_ostream and
basic_stringstream char_traits, so this is some app code doing C++
standard library I/O.
1251553123.626120 gdk_pixbuf_new_from_file(0x782018, 0x7a4b2f88,
0x7a4b2f88, 0x4a992f63, 0x69525f7974696e61 unfinished ...
1251553123.626161
SYS_open(/home/mark/ThumbnailingBenchmarks/2000_Wallpapers-
Reanimation/Sea_of_Humanity_Rio_de_Janeiro_Brazil,
0, 0666) = 4
1251553123.626216 SYS_fstat(4,
0x7a4b1b20) = 0
1251553123.626238 SYS_mmap(0, 4096, 3, 34, 0x)
= 0x7fcaa928a000
1251553123.626273 SYS_read(4, \377\330\377\340, 4096)
= 4096
1251553123.626355 SYS_lseek(4, 0,
0) = 0
1251553123.626379 SYS_rt_sigprocmask(0, 0, 0x7a4a1af0, 8,
0) = 0
1251553123.626417 SYS_read(4, \377\330\377\340, 65536)
= 65536
1251553123.636544 SYS_read(4,
Ob\316Z\330\271\003\030\007\004TJ\t-\312N\347fi
\001\344\236\347\332\271/\023\370b\373Z
\324\214\366\332\2040\256\320\241Y7c
\025\240\276\201\320\223\003\257\004,
65536) = 65536
1251553123.643681 SYS_read(4,
\221\301\256\332)u9gwt\212_\331r\\[[\264eS1\202\304\234\222ME
\007\207\334\027\3350\371rOTz\307\332-\322\3365\221\227l8
\022\006k*\326[\247.\032W#\034\214\340\032\350\216\333\034\365%\016v
\254n\256\213\003\002~\320\243\007\200Mmj7\247G
\360\235\265\265\276\331U\345b\\...,
65536) = 65536
1251553123.650134 SYS_read(4,
\3749w\241\276\254/\2368\334\022eq\202\207\270\375j\343Bo
\2315\251\234\261t\242\242\357\243\330\304\360\307\207\216\257i`
\333\205\241\215\216\340\374\345Go
\326\275.\337\341\235\265\314\022\006\324\345x\336m\...@\031a\\
\356\203\033\266\224#\323\360#\212\365\241R
\314\001\233\216\325\351\220=\325\207\207#i%\020\334L...,
65536) = 65536
1251553123.656189 SYS_read(4,
\357\255\254\214w\321\233\231y\367o\017\234\n\3...@\0047s\323\004R
\205,
65536) = 65536
1251553123.662128 SYS_read(4,
\272\206\250\222i\236'm\303\316{\333wU'\223\217\363\372S
\224
Re: how to handle multiple windows.
On Aug 26, 2009, at 9:47 AM, Sreejith S wrote:
Hi...
thnk..u..al
I have multiple windows in my Gtk2-Perl project.i have already
designed and
coded each one.How can i call a window from another window,when i
press a button in the main window.I also need to pass some values from
one window to other as arguments...
That depends rather intimately on how you have set up your code to
create the windows.
In general, your Button's clicked handler can scrape together
whatever it needs and then call the function that constructs your
other window. For example,
$window1_doit_button-signal_connect (clicked = sub {
my $arg1 = $window1_arg1_entry-get_text ();
my $arg2 = $window1_arg2_checkbox-get_active ();
create_window_2 ($arg1, $arg2);
});
The main loop is still running, so assuming that create_window_2()
calls -show on the new window, everything should Just Work.
There are other issues if window2 is a modal dialog, etc, so, as
hinted above, more information will get you a better answer.
--
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: How to set the color of a row based on the data in one coloumn Gtk::Treeview
On Aug 19, 2009, at 5:05 PM, Ragavendar Swamisai wrote:
Hi,
I am trying to create a TreeView (with SimpleList) and I have a column
where its value is set dynamically, and when the value in the column
is set to a specific string I want to set the complete row to say RED.
I am able to do that for a column using the 'attr' key in the
SimpleList.
Any pointers or code snippet will be helpful.
The easiest way is to have a hidden row in your column that contains
the color you want to use. You'd calculate that when you insert the
data. Then, loop across all the columns in the view, adding an
attribute to control the color, like this:
foreach my $col ($view-get_columns ()) {
# NOTE: in newer gtk+, this is get_cells()
foreach my $cell ($col-get_cell_renderers ()) {
# assuming you're talking about the foreground color, and
that the
# model stores this as a string color name.
$col-add_attribute ($cell, foreground =
HIDDEN_COLOR_COLUMN_INDEX);
}
}
If you want the background color, you may need to tweak.
If it needs to be more dynamic than that, or not use a column to store
this value, then you will need to use a cell data function, which
replaces your attributes, which means you want to do it by hand
instead of using SimpleList.
--
Applause is an addiction, like heroin or checking your email.
-- Sideshow Mel
___
gtk-perl-list mailing list
gtk-perl-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-perl-list
Re: Gtk2::SimpleList crashes
On Aug 15, 2009, at 3:24 PM, Peter Daum wrote:
Originally, I tried to find a way to delete all values matching
certain criteria
from a Gtk2::SimpleList (which always crashed). Eventually, I found,
that I don't
have to get fancy to cause that crash - the following will do it:
my @da...@{$slist-{data}};
@{$slist-{data...@data;
Gtk-CRITICAL **: gtk_list_store_get_value: assertion `VALID_ITER
(iter, list_store)' failed at /usr/lib/perl5/Gtk2/SimpleList.pm line
248, F line 35.
GLib-CRITICAL **: g_hash_table_lookup: assertion `hash_table !=
NULL' failed at /usr/lib/perl5/Gtk2/SimpleList.pm line 248, F line
35.
Segmentation fault
Can anybody tell me what's wrong with that code snippet?
Is there any workaround?
Can you post a script and your software versions? I can't reproduce
on my (rather ancient) system with this:
#!/usr/bin/perl -w
use strict;
use Gtk2 -init;
use Gtk2::SimpleList;
my $slist = Gtk2::SimpleList-new ('Stuff' = 'text');
@{ $slist-{data} } = qw(one two three four five six seven);
my @data = @{ $slist-{data} };
@{ $slist-{data} } = @data;
print Gtk2::VERSION $Gtk2::VERSION\n;
print Gtk2::SimpleList::VERSION $Gtk2::SimpleList::VERSION\n;
print Gtk2-GET_VERSION_INFO .join(.,Gtk2-
GET_VERSION_INFO).\n;
print Gtk2-get_version_info .join(.,Gtk2-
get_version_info).\n;
--
Gtk2::VERSION 1.080
Gtk2::SimpleList::VERSION 0.15
Gtk2-GET_VERSION_INFO 2.4.0
Gtk2-get_version_info 2.4.14
--
Y: That's funny!
Z: (silent)
Y: That's not funny.
Z: (silent)
Y: Is that funny?
Z: (nods)
Y: Then why didn't you laugh?
Z: Sometimes, whenever it's funny, I don't laugh. But sometimes, I do.
Y: When is it funny?
Z: Whenever you say poop and fart and pee and butt, I laugh.
Y: Oh, okay.
___
gtk-perl-list mailing list
gtk-perl-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-perl-list
Re: Glib::IO-add_watch - file descriptor got locked till the end of all incoming data
On Aug 3, 2009, at 2:14 PM, anguila wrote: Solved, I just put a new line to set the end of line and it works :) If you control both sides, that's the cleanest solution. Rock. i cant use sysread because i doesnt know the length of the input each time. That's generally not a problem if the file handle is set to non- blocking; sysread() should read what's available up to the buffer size you give. -- The trees on the bus go pyoo pyoo pyoo... -- Yvonne, singing, um, something ___ gtk-perl-list mailing list gtk-perl-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-perl-list
Re: Glib::IO-add_watch - file descriptor got locked till the end of all incoming data
On Aug 2, 2009, at 3:03 AM, anguila wrote:
I want to update a treeview and this is the reason why i'm using the
add_watch function. The child is sending data all the time for many
reasons and the problem that i have is the file handler which have
the incoming data from child to parent. With watcher each time the
child sent data the $line = $reader must save this data in $line
and call the function.
But dont know why the $reader just get locked till the end of
all $writerwrite() and then it save all those data into $line, and
i dont want that, i want to save the data of -write in $line each
time child send data.
Any idea?
$watcher{$pid} = Glib::IO-add_watch($reader-fileno(),
['in', 'hup'], sub {
my ($fileno, $condition) = @_;
print -cond = $condition\n;
if ($condition 'in') {
print -reading from parent!!!\n;
$line = $reader;
Don't mix and match buffered reads and an unbuffered event watcher.
The operator will read until end of line, but the watch is based on
select(), and fires when any data is available on the file
descriptor. The end of line may not have arrived yet, and the will
block until the end of line does arrive.
You want to use sysread() here. This may involve keeping a partial
string checking to see if it contains an entire line.
--
Teeter tots are shaped like marshmallows.
-- Zella.
___
gtk-perl-list mailing list
gtk-perl-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-perl-list
Re: Gtk2::Assistant page flow
On Jul 16, 2009, at 1:17 PM, Peter Juhasz wrote:
There is one more thing (for now, anyway) I'd like to ask your help
about.
I want to set up a Gtk2::Assistant. On the first page of the assistant
there is an Entry field. What I'm trying to achieve is that if the
value entered into this field is invalid (empty or already present in
the database), then an error message would pop up and the assistant
would reset to the first page, to let the user correct their mistake.
Here is a minimal example of what I tried:
#
#!/usr/bin/perl
use strict;
use warnings;
use utf8;
use Gtk2 -init;
use Gtk2::Ex::Dialogs;
use Glib ':constants';
my %gui_strings = (
id_empty_error_title = Error: empty id,
id_empty_error_text = You did not give a valid identifier.,
assistant1_title = Id,
assistant2_title = Confirm,
assistant2_label = Well done!,
);
my $id;
my $assistant = Gtk2::Assistant-new;
Gtk2::Ex::Dialogs-set_parent_window( $assistant );
$assistant-signal_connect (delete_event = sub { Gtk2-main_quit; });
my $page = Gtk2::Entry-new();
$assistant-append_page ($page);
$assistant-set_page_title ($page, $gui_strings{assistant1_title});
$assistant-set_page_complete ($page, TRUE);
$assistant-set_page_type ($page, 'intro');
$page-show_all;
my $page2 = Gtk2::Label-new($gui_strings{assistant2_label});
$page2-show;
$assistant-append_page ($page2);
$assistant-set_page_title ($page2, $gui_strings{assistant2_title});
$assistant-set_page_complete ($page2, TRUE);
$assistant-set_page_type ($page2, 'confirm');
$assistant-signal_connect (cancel = \cancel_callback);
$assistant-signal_connect (close = \cancel_callback);
$assistant-signal_connect (apply = sub {
# do whatever we have to do with the id, here we just print it
print $id.\n;
});
$assistant-signal_connect (prepare = sub {
my $page_num = $assistant-get_current_page();
$id = $page-get_text();
if ($page_num == 1 and $id eq ) {
new_and_run Gtk2::Ex::Dialogs::ErrorMsg ( title =
$gui_strings{id_empty_error_title},
text =
$gui_strings{id_empty_error_text} );
$assistant-set_current_page(0);
return;
}
});
$assistant-show_all;
Gtk2-main;
sub cancel_callback {
my $widget = shift;
$widget-destroy;
Gtk2-main_quit;
}
#
However, there is a problem. When I leave the entry field empty, the
dialog pops up as expected. But what I get after pressing OK on the
dialog is a blank assistant page! Only after pressing Forward again do
I get back my original first page of the assistant.
What am I doing wrong? The problem is consistent on both Linux and
Windows by the way.
The prepare signal is used to prepare the page before showing it.
It cannot be used to abort a page, which your code seems to want to do.
Also, set_page_complete() is intended to sallow the Forward action
once the contents of the page are set up correctly. Your code sets
the complete flag on each page at construction time, and i think this
is your problem. If, instead, you don't set the continue flag true
until the first page contains a valid identifier, you won't even need
your validation dialog.
When you create your entry, connect to its changed signal, and
validate the input on each keystroke. If the input is valid, set the
page complete flag to true, and the Forward button will enable itself.
If the validation is too expensive (e.g. you have to check with a
database or something), then you have options:
- In your handler for the entry's changed signal, set a timer to
expire in half a second or so to defer the validation until the user
stops typing.
- Do your validation in apply instead.
--
The trees on the bus go pyoo pyoo pyoo...
-- Yvonne, singing, um, something
___
gtk-perl-list mailing list
gtk-perl-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-perl-list
Re: hiding progressbar in a Gtk2::TreeViewColumn
On Jul 24, 2009, at 11:34 PM, anguila wrote:
Trying the first option it seems not recognize sensible option:
GLib-GObject-WARNING **: unable to set property `visible' of type
`gboolean' from value of type `gchararray'
With the second option it works, but still visible:
$tc_pbar-set_cell_data_func ($pbar,
sub {
my ($column, $cell, $model, $iter) = @_;
my $string = $model-get_string_from_iter ($iter);
if ($string!~/\d:\d:0/) {
# we should show the progress bar
$cell-set (visible = FALSE, value = $value);
Is that a typo? (Should be TRUE here, not FALSE.)
} else {
# we should NOT show the progress bar, so don't
$cell-set (visible = FALSE,value=22);
print pbar to off!\n;
}
});
All the 3rd child want to make pbar visible=false. I tried and i
can change the value of all 3rd childs to 22 and it works, but
visible=false doesn't change the state of visibility and i dont
understand why because is a attribute og Gtk2::CellRenderer and it
should works, but it doesn't.
Any idea?
Perplexing. A quick scan of the gtk+ sources on git.gnome.org shows
that the cell's visible property is honored by TreeViewColumn when
processing each row, so this should work just fine. I may be
misreading that (gtktreeviewcolumn.c is 3755 lines and a web browser
is not as good for reading code as vim).
Sanity check: do you have the constants TRUE and FALSE defined?
(e.g. from 'use Glib qw(:constants)'). Is strict turned on? If perl
is not being properly strict, it may be interpreting the bareword
FALSE as a string, and 'FALSE' is not an empty string and therefore is
logically true.
What if you set the other properties before setting visible, e.g.
} else {
# we should NOT show the progress bar
$cell-set (text = '', value = 0, width = 0, visible =
FALSE);
--
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: hiding progressbar in a Gtk2::TreeViewColumn
On Jul 24, 2009, at 4:21 PM, anguila wrote: Any idea how to hide this progressbar? If i'm understanding you correctly, then simply don't create a view column just for the progressbars -- pack the progress into the last column with the last column's text renderer, and decide whether to show it on a per-row basis. You can pack as many renderers as you want into one view column, and they will share space; then when you hide the progressbar, the remaining contents should soak up its space. I think that using an attribute to control the progress bar renderer's visible property should work, or else use a cell data function. -- 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: hiding progressbar in a Gtk2::TreeViewColumn
On Jul 24, 2009, at 6:04 PM, anguila wrote:
but with the 3th child how can i set the property of progressbar at
visible = false, this will affect to the other parents using same
model, isn't it?
You must set up some way to discern that from the model. The column
will inspect its attributes list or cell data func for every row, to
set up each cell for this row and draw. I can't really experiment to
show you an example (i'm on vacation, away from a machine on which to
hack), but here is some pseudocode:
# first, create and arrange
$column = Gtk2::TreeViewColumn-new ();
$treeview-append_column ($column);
$progress_renderer = Gtk2::CellRendererProgress-new ();
$column-pack_start ($progress_renderer, FALSE);
$text_renderer = Gtk2::CellRendererText-new ();
# set expand to TRUE so he will take up all remaining space
$column-pack_start ($text_renderer, TRUE);
# in any case, the remainder text in the text renderer is
unchanged...
$column-set_attributes ($text_renderer, text =
COL_REMAINDER_TEXT);
First possibility:
# another column in the model, COL_PBAR_VISIBLE, tells us whether
# we need to use the progressbar. Map this directly to the
visible
# property on the renderer.
$column-add_attributes ($progress_renderer,
value = COL_PBAR_VALUE,
visible = COL_PBAR_VISIBLE);
Or, next possibility:
# if we have to use some complicated condition to calculate whether
# to use the progressbar, the cell data func is more appropriate.
$column-set_cell_data_func ($progress_renderer,
sub {
my ($column, $cell, $model, $iter) = @_;
my $value = calculate_progress ($model, $iter);
if (defined $value) {
# we should show the progress bar
$cell-set (visible = TRUE, value = $value);
} else {
# we should NOT show the progress bar, so don't
$cell-set (visible = FALSE);
}
});
Remember that cell data functions are called rather often, so you
don't want to do something expensive there.
The principle is that the attributes on each cell in the column are
somewhat distinct. You might have to add_attributes() for the text
renderer after setting the data func, the docs are not entirely clear
and i can't experiment at the moment.
--
The stereo, playing the Beastie Boys' Rhymin' and Stealin': I'll
steal your girlie like I stole your bike!
Elysse: You mean, take off the chain and ride away?
___
gtk-perl-list mailing list
gtk-perl-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-perl-list
Re: How to find out the API coverage of Perl bindings
On Jul 12, 2009, at 3:35 AM, Emmanuel Rodriguez wrote: The python maintainer of the same library told me that he gets a warning for symbols that are not covered by his bindings. Is there a way to do the same for the Perl bindings? That's most likely because pygtk and friends use some header scrapers to generate a large portion of uninteresting bindings. We didn't use that when starting gtk2-perl because, well, for uninteresting bindings, all you need is a function prototype, and generating the input to a code generator seemed a little perverse. Have you considered the glib introspection repository stuff? I recall that Torsten had some success a while back, but haven't heard anything since... -- Overheard during a game of Lego Star Wars II: Zella: I can't do it! Yvonne: You have to do it! Zella: I'm trying! Yvonne: There is no try! ___ gtk-perl-list mailing list gtk-perl-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-perl-list
Re: Confused about $data=undef in API documentation
On Jul 11, 2009, at 10:58 AM, Joseph Thames wrote: Hello, I am confused about your use of $data=undef in the Glib documentation, as in: unsigned = $instance-signal_connect ($detailed_signal, $callback, $data=undef) • $detailed_signal (string) • $callback (subroutine) • $data (scalar) arbitrary data to be passed to each invocation of callback Does this simply mean that undef (NULL) is the default value of the $data parameter, or does it mean that passing unique user_data to a callback is not yet supported in this API? Yes, it means that if you don't specify that argument, it will be treated as though you passed undef. The syntax is borrowed from C++'s default parameters. I am trying to figure out a way to employ a common callback function for an unlimited number of menu items (determined at run-time) by passing unique user_data for each signal. This does not seem to be supported by the $builder-connect_signals method, which can only pass the same user_data to a group of unique callback functions. Your single callback is free to inspect the widget / object names (as set in the xml) and dispatch to the correct place based on that. -- 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: Glib 64bit test failing in MinGW
On Jun 8, 2009, at 3:00 PM, Ari Jolma wrote: How do I submit bug reports related to Perl-Gtk2? File the bug in gnome's bugzilla: http://bugzilla.gnome.org/enter_bug.cgi?product=gnome-perl and then optionally ping us about it here at the list. -- elysse: You dance better than some. me: Some what? elysse: Some asparagus. ___ gtk-perl-list mailing list gtk-perl-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-perl-list
Re: [PATCH] Gtk2.xs (gtk_init): do gtk_init_check in PL_minus_c mode
On May 24, 2009, at 2:49 PM, Torsten Schoenfeld wrote:
[CC'ing the mailing list for input.]
Alexey Tourbin wrote:
I'm not sure if this patch can be applied as is, but there is a
problem
with gtk_init.
gtk_init will terminate the program if the GUI cannot be initialized.
This can make syntax check impossible, which is too bad a
consequence.
Hack gtk_init to invoke gtk_init_check in syntax check mode.
I'm ambivalent about this. It fixes a real issue, but it does so by
altering behavior in a way that doesn't seem completely safe. On
the other hand, I can't think of any case where this change would
cause undesired effects. Can you, gtk-perl-list?
If we're in check mode, no code is supposed to execute. Since it
behaves this way currently, it's broken and unusable. So, making the
change would enable new stuff. Good.
If we're not in check mode, which is how all existing code currently
works, this should change nothing. Good.
You could make the change explicit and give a special case for -c:
if (ix == 2) {
RETVAL = gtk_init_check (...);
} else if (PL_minus_c) {
/* And here's a nice place to comment on the
rationale... */
warn (In syntax check mode, calling gtk_init_check()
instead of gtk_init();
RETVAL = gtk_init_check (...);
} else {
gtk_init (...);
}
--
The stereo, playing the Beastie Boys' Rhymin' and Stealin': I'll
steal your girlie like I stole your bike!
Elysse: You mean, take off the chain and ride away?
___
gtk-perl-list mailing list
gtk-perl-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-perl-list
Re: Toolbar tooltip setter and getter question
On May 24, 2009, at 2:48 AM, Cowley Harris wrote:
Hi All,
I looked through the gtk documentation and found that the function
gtk_toolbar_set_tooltips () has been depreciated since 2.14 and that I
should be setting gtk-enable-tooltips to false instead.
However I can't find that option in gtk2-perl, only the tooltips
flag. Which doesn't seem to work either.
It's a property on the settings object, not on the toolbar object.
$toolbar-get_settings-set ('gtk-enable-tooltips' = TRUE);
On an interesting note, updating to gtk+-2.17 and Glib 2.20 has
apparently screwed up gnome for me, I don't have any system menu bars
any more and have to start everything from the terminal. I kind of
like it in a retro way, but my wife is going to kill me.
It's best to use sandboxes for this sort of thing, for exactly this
reason.
To install a nonstandard or development gtk+, use jhbuild. Then you
can set up an installation of gtk2-perl in the same installation root,
and mangle the environment in shells for which you want to use it.
More info:
http://mail.gnome.org/archives/gtk-perl-list/2009-January/msg00027.html
--
Sallah! I said no camels! That's five camels! Can't you count?
-- Indiana Jones
___
gtk-perl-list mailing list
gtk-perl-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-perl-list
Re: Layout problems when getting widgets from glade file
On May 16, 2009, at 11:08 AM, Peter E Dennis wrote: What I'm trying to do is to get the program using the glade file to look like the one that isn't. I would ideally like to be able to use glade than hand code the entire gui. Try setting the default window size for the main window with Gtk2::Window::set_default_size. Thanks, I tried: Gtk2::Window::set_default_size($main_window, 5, 5); and it remains the same size as before in 'with_glade.png' It really seems to be something to do with the packing of the label. Before I add it, the window appears as 'no_label.png' but after I add the label to the Gtk2::Table it expands horizontally. Double-check all of the packing and sizing options in the glade file against the corresponding ones in your all-perl version; i noticed at least a few differences in a cursory glance. The boxes have spacing 5 in your code, 0 in glade; the button was expand=FALSE, fill=TRUE in code but expand=TRUE, fill=TRUE in glade, etc. In fact, the expand is a likely culprit. -- 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: Layout problems when getting widgets from glade file
On May 16, 2009, at 12:27 PM, Cowley Harris wrote: $vbox1-set_size_request(300, 60); remembering that it is just a request and may be ignored. Actually, size request is used as the widget's minimum size. The layout logic will not shrink the widget below its size request, but may give the widget more space than it requests. This is more apparent when trying to size a toplevel window; you generally want set_default_size() for that, as the default size will let the user shrink *and* grow the window, while set_size_request() will only let the user grow the window. -- Of course there are true copper bottomed mistakes, like spelling the word “rabbit” with three m’s, or wearing a black bra under a white blouse, or, to make a more masculine example, starting a land war in Asia. -- John Cleese, The Importance of Mistakes ___ gtk-perl-list mailing list gtk-perl-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-perl-list
Re: Subclassing question
On May 16, 2009, at 12:42 PM, Torsten Schoenfeld wrote: Technically, this is due to gperl_value_from_sv using g_value_set_boxed instead of g_value_set_static_boxed. The former copies the boxed object. I can't think of a reason not to use g_value_set_static_boxed there (other than being defensive). When I do this change, Glib's and Gtk2's test suites still pass. muppet, do you remember why gperl_value_from_sv uses g_value_set_boxed instead of g_value_set_static_boxed? Initially, we assumed that a boxed object always holds a copy. I was blissfully unaware of various deep subtleties when that code was new. :-) That gets wrapped up in are you allowed to change this thing through your reference? questions, but i think the important ones of those are taken care of for us upstream. If that actually works, then i think we get a functionality win (some of the marshaler behave more usefully) that would be worth some bug reports, so i think it's worth pushing it out in an unstable release to see what happens. Specific things to test would include custom treemodels and complex perl widget or cellrenderer implementations. -- The front of your fridge may be cheap and nasty, but I hope the next time you look at the back of your fridge, you'll regard it with suitable admiration. -- Tim Hunkin, The Secret Life of Machines ___ gtk-perl-list mailing list gtk-perl-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-perl-list
Re: Is there anyone out there?
Cowley Harris wrote: 1) Is this project still going? Doesn't seem to be much (any) emails coming through on the mailing list. That strikes me as a rather odd observation. A quick look at the mailing list archives ( http://mail.gnome.org/archives/gtk-perl-list/ ) shows a steady stream of messages every month. When I tried to review the archives I got a 404 error. I used the link from the Documents page, not the one on the FAQs page. Oh, dear --- looks like markmail changed the link format. http://perl.markmail.org/search/#query:list%3Aorg.gnome.gtk-perl-list is what you want, i'll get that updated when i get home this evening. Thanks for pointing that out. I understand that that it is volunteer based project and in a stable state, but I've just recently invested a lot of time learning what turned out to be a dead project and would rather not do the same again. At the same time I wanted to start learning the API and migrating to Gtk2 as soon as possible. I think a difference between Tk and Gtk2 is that Gtk2 is based on a modern and active upstream, while Tk is long stable and, well, kinda ugly by comparison. For some examples, there doesn't seem to be any recent tutorials (latest I found with a date was 2006). The main English version for Gtk2-perl is half completed and is still in alpha. The search the list archives link 404s on me. (The one on the documentation page, not the one I just found on the FAQ page). On the main page, the most recent news leads to svn, while at svn.gnome.org you have the message All content on this site is obsolete. You have to admit, the gnome project's switch to git is practically on the heels of their switch to subversion. It took us an embarrassingly long time to get away from sourceforge cvs. I'm just pointing out that the sourceforge site has a ghost-town feel to it. And as it turns up first on a google search, it could be off-putting to people who may be migrating from Perl-Tk who are evaluating the alternatives. I think as I have new eyes I'm going to see the stuff you may be oblivious too. I think you're right, honestly. We should knock down the cobwebs. Please report any broken links here. I'm also offering to help out with the documentation as per the Intro. Excellent. Patches here. Start anywhere you like. -- 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: Is there anyone out there?
On May 14, 2009, at 5:49 PM, muppet wrote: Cowley Harris wrote: When I tried to review the archives I got a 404 error. I used the link from the Documents page, not the one on the FAQs page. Oh, dear --- looks like markmail changed the link format. Stranger -- it looks like the file somehow got corrupted, with the ht in http for that link changing to some strange non-ascii junk. At any rate, it's fixed, now. -- 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: About Treeview update with thread
On May 13, 2009, at 10:32 AM, 唐瑞博 wrote:
For the gdk lock method, I have used Gtk2::Gdk::Threads-enter and
Gtk2::Gdk::Threads-leave in my background thread, it seem that it
can update all the widgets(like button, labes) correctly excepte the
Gtk2::TreeModel(I used a Gtk2::ListStore actually). when i use the
Gtk2::TreeModel-set() method, it will fail and says Usage:
Gtk2::TreeModel-set($liststore, $iter, $col.) , and then the
exit. I checked my code and found that I have a column with type
Glib::Scalar in my treemodel, in this column i assign a pointer to
an new constructed object ( the object is not a subclass of
Glib::Object, and have not decleared as shared), I do not know if
the fail have relationship with this object?
This certainly smells like you're running afoul of perl threading.
Run away!
For the Glib::Idle method method, I put Glib::Idle-add
(\update_treeview, $tid) to my background thread, and it appear
the same error as first method. According to your reply, i think
the update_treeview should be run in the Main thread, but after my
check, i found it runs in the background thread actually, so when
the background thread access the Gtk2::TreeModel-set, it will fail
as the first method.
A quick test with glib in C shows that calling g_idle_add() on a
background thread causes the main loop on the main thread to execute
the callback.
But a similar test in perl, using threads-self-tid(), shows the same
thread executes everything. Something is up. We're probably using
the wrong context when executing callbacks for the main loop.
However, i'm not sure how we would differentiate. Hrm.
(Files attached.)
#!/usr/bin/perl -w
use Glib;
Glib::Object-set_threadsafe (1);
use threads;
sub callback {
print callback on .threads-self-tid().\n;
0;
}
my $loop = Glib::MainLoop-new;
sub background {
sleep 1;
print queuing callback on .threads-self-tid().\n;
Glib::Idle-add (\callback);
sleep 1;
print queuing callback on .threads-self-tid().\n;
Glib::Idle-add (\callback);
sleep 1;
print queuing mainloop kill on .threads-self-tid().\n;
Glib::Idle-add (sub {
print killing mainloop on .threads-self-tid().\n;
$loop-quit;
0;
});
}
my $thread = threads-create(background);
print running mainloop on .threads-self-tid().\n;
$loop-run;
$thread-join;
loop.c
Description: Binary data
Run away! (At least until we figure it out.)
For the third method, i used a Thread::Queue as pipe, the background
thread enqueue the need updated data to the pipe, in my main thread,
i use Glib::Timeout-add(1000, \$update_treeview) to update my GUI,
every 1 second will to update the GUI, in this method I access the
Gtk2::TreeModel-set in the Main thread, so the error does not
appears. And all works well. Although update UI is not realtime,
also can acceptable. I do not know if there are any better
solutions for my issue or if there is any improvement for this method?
If you use an io watch to monitor the pipe, instead of a 1 second
timeout, then the updates will be roughly as fast as the data shows up.
--
Sallah! I said no camels! That's five camels! Can't you count?
-- Indiana Jones
___
gtk-perl-list mailing list
gtk-perl-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-perl-list
Re: Is there anyone out there?
On May 13, 2009, at 8:39 AM, Cowley Harris wrote: 1) Is this project still going? Doesn't seem to be much (any) emails coming through on the mailing list. It's still going. However, the maintainers are volunteers and have other things to do in life, and the bindings are rather stable, so we're not exactly a hotbed of activity. 2) If the Gtk2-perl project still has some life in it, what work is ongoing for the tutorial? It seems to stop half-way through it. I've emailed the two guys listed a few days ago, one email seems defunct, the other is yet to reply. The tutorial is based on the C version that is about 6-7 years old. Again, it was a volunteer effort. 3)If work is still ongoing on the tutorial, is there a date for an update?, If not, does anybody mind if I continue where the others left off? Who would I contact to send an updated version? If you make a patch available here on the list, we'll get it committed. Looking around, i think the tutorial is still hosted on sourceforge, so that might require a bit of swizzling. :-/ 4)The last notice said that the project has been switch to svn. However svn has been depreciated on sourceforge. Is there a plan to change to git? http://git.gnome.org/cgit/perl-Gtk2/ -- me, while driving the car: Okay, girls, what do you want for lunch? yvonne: I wan' noo-tulls! zella: I want lavaloli! Can we go to the lavaloli store? me: Um, where *is* the ravioli store? zella: At the lavaloli store! yvonne: I want noo-tulls! Let's go to the noo-tull store! ___ gtk-perl-list mailing list gtk-perl-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-perl-list
Re: About Treeview update with thread
On May 8, 2009, at 10:51 PM, 唐瑞博 wrote: hi, In my project, The GUI have a treeview and a 'Run' Button,Treestore may have thourands of datas. When i click the 'Run' button, the logci will process the treestore datas one by one(this is a long time procedure), when one data process complete, i need to update the Treeview immediately. In order to avoid the GUI lag, I use a thread to do the backend processing. The problem is when the thread to update the Treeview, the logic will fail. - Remember to grab and release the gdk lock around the gui accesses from the other thread, or - Instead of immediately modifying the treemodel in your background thread, install a single-shot idle that will do it. This effectively defers the work to the main thread so that only one thread touches the ui. -- Sallah! I said no camels! That's five camels! Can't you count? -- Indiana Jones ___ gtk-perl-list mailing list gtk-perl-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-perl-list
Re: Binding for a function receiving a C callback without arguments
Emmanuel Rodriguez wrote: I need to write the bindings for a C function that receives a callback which has no arguments. [snip] Someome knows of an exisinting C API that has a similar callback and how I can overcome this? Save yourself and the authors of other bindings some grief, and convince the upstream to add a user data pointer to *all* callback functions. You have derived for yourself the proof of why this is necessary. ;-) -- 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: Idea: Can we modify Devel::REPL or combine with Perl Object Environment to have programmatic interaction with a gtk2-perl process like in other languages?
Mitchell Laks wrote: I like perl and gtk2 and would rather use it than xyz (other languages :)). Can we set up a working interactive REPL with gtk2-perl as with pygtk for instance. I can use Devel::REPL to start and build the gui but then I lose the interaction control once I start Gtk2-main; I would like to redefine callbacks, change widgets on the fly etc as we continue the interaction using Devel::REPL. I have done it with pygtk of course using the program pygtkconsole.py. Do we modify Devel::REPL or set up something with perl POE? I think we should be able to do this with gtk2-perl, although I am still learnining some of this stuff so I wanted your opinions on the details. Could we use perl POE? Hw to keep access to the working program? Now I know that there are issues with gui threads. However can you imagine doing something with perl POE? Remco Wouts did something along those lines: http://mail.gnome.org/archives/gtk-perl-list/2005-January/msg00128.html as did i: http://asofyet.org/muppet/software/gtk2-perl/gish.html http://asofyet.org/muppet/software/gtk2-perl/gws.html There should be some ideas in there on how to fix the mainloop issue. :-) -- 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: Restoring a List View's position
On Mar 16, 2009, at 2:59 AM, Matthew Braid wrote:
I initially tried using $treeview-get_visible_range and
$treeview-scroll_to_cell, but get_visible_range seems to be a little
flakey on my system and often aborts with a message about some
assertion failing (something != nil I think). So after realising that
eval {} over a failed Gtk assertion just doesn't work (yay), I tried
directly manipulating the scrollbars instead.
Were you asking for the visible range after having removed the model?
On store, I do this:
$store{POS} = $list-get_vadjustment-get_value;
and on restore I:
$list-get_vadjustment-set_value($store{POS});
This doesn't error, but it also doesn't do anything - scrollbar
steadfastly stays where it is.
You may need to wait for the adjustment change to take effect. Try
setting the new scrollbar positions in an idle handler. This may
result in undesirable flicker, in which case, your next idea isn't
terribly inappropriate.
I starting looking into storing the coords of the currently visible
cells and using scroll_to_point, but now I'm dealing with screen
coordinates and that seems a bit low level for what should simply be
'scroll to this entry in the list'.
Well, if you want it to look to the user as though the view is just as
he left it, then simply scrolling a certain row onscreen may not be
sufficient. If i understand correctly, when you scroll to the list
item, it's somewhat random as to where it will be (depends on your
parameters). So, scroll to point isn't that bad of a compromise.
What is it that I'm missing?
You might try asking on gtk-app-devel-list, as this is a general gtk+
question, not restricted to perl.
--
Sallah! I said no camels! That's five camels! Can't you count?
-- Indiana Jones
___
gtk-perl-list mailing list
gtk-perl-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-perl-list
Re: GObject Introspection as part of the GNOME platform
Johan Dahlin wrote: As far as I can see there aren't any easy solutions. We're depending on libffi to calculate struct sizes for the typelib which is very much host and compiler dependent. g-ir-compile really needs to run on the target system the way things are setup right now. The same applies for the small generated program which introspects signals properties, but that's probably easier to solve. In my opinion, supporting cross-compilation shouldn't be a blocker for integration into glib proper. It's more of a 'nice feature' to support. I'm sure people putting gnome on phones will disagree. You could do tricks like using the cross compiler to generate assembly instead of machine code from specially-crafted, generated C code, and then parse the resulting assembly to extract the structure sizes and offsets. -- muppet scott at asofyet dot org ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Gtk2::ImageView memory issue
On Mar 6, 2009, at 5:40 PM, Jeffrey Ratcliffe wrote:
2009/3/6 Torsten Schoenfeld kaffeeti...@gmx.de:
GBoxed descendants have their own memory management infrastructure
and thus
also their own typemap variants: for functions returning newly
constructed
instances of GBoxed descendants, use the _own typemap variant. Then,
I've had to write code to convert the GBox struct to a hash and back
again - e.g.
static SV *
newSVGdkPixbufDrawCache (GdkPixbufDrawCache * cache)
{
HV * hv = newHV();
hv_store (hv, last_pixbuf, 11, newSVGdkPixbuf (cache-
last_pixbuf), 0);
hv_store (hv, old, 3, newSVGdkPixbufDrawOpts (cache-old), 0);
hv_store (hv, check_size, 10, newSViv (cache-check_size), 0);
return newRV_noinc ((SV *) hv);
}
Is the _own variant useful here?
No. _own is for when your perl wrapper will hold onto the actual
boxed object. This is what the default wrappers do. You are
converting the boxed object from a C struct to a native perl object
(the hash) and back, so you don't need to hold on to the C object,
therefore, you don't need _own.
How can I test that the _free method is being called?
Simplest is to wrap it:
static void
wrap_gdk_pixbuf_draw_cache_free (void * the_thing)
{
g_print (OMG I'M ABOUT TO FREE A GdkPixbufDrawCache AT %p\n,
the_thing);
gdk_pixbuf_draw_cache_free (the_thing);
}
Then register wrap_gdk_pixbuf_draw_cache_free () as the destroy
function instead of gdk_pixbuf_draw_cache_free() and watch for the
messages on stdout.
--
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: Perl bindings for libchamplain
On Mar 4, 2009, at 3:11 AM, Emmanuel Rodriguez wrote: I'm trying to write the Perl bindings for libchamplain (http://blog.pierlux.com/projects/libchamplain/en/) and I'm struggling with a simple enum. The C library defines the enum ChamplainViewMode which I have added to my map file. I'm able to generate the XS code and to compile the module to a .so but when I try to load the Perl module in a sample file I get: perl: symbol lookup error: blib/arch/auto/Clutter/Ex/Champlain/Champlain.so: undefined symbol: SvChamplainViewMode The maps file assumes you want to generate all these macros for each thing in the maps file. If the C library does not define a GType for this enum, then either 1. remove it from the maps file 2. provide your own conversion function with this name 3. provide your own GType mapping Which one you use depends on how the enum is used. If it's used as an object property, the C library really ought to have the GType. -- Well done, Android. Aperture Science reminds you that Android Hell is a real place, and you will be sent there at the first sign of defiance. -- GlaDOS ___ gtk-perl-list mailing list gtk-perl-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-perl-list
Re: accelgroup closure comments
On Mar 1, 2009, at 12:10 PM, Torsten Schoenfeld wrote: Kevin Ryde wrote: Nosing around AccelGroup connects, I think the fixme comment doubting the GClosure ref counting is ok, ie. the code is ok as it stands. Yeah, I agree. Committed. Thanks! Yay! Unfortunately we thus lose the occasion to imagine muppet swearing until he is blue in the face. :-) Never fear, it happens quite often. -- Yvonne: Let's do that one again so i can win. Zella: No. ___ gtk-perl-list mailing list gtk-perl-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-perl-list
Re: [PATCH] fix POD generation with COPYRIGHT section in source
On Feb 18, 2009, at 10:57 AM, Torsten Schoenfeld wrote: I think the problem occurs due to the =for position COPYRIGHT in xs/GnomeCanvas.xs. It's handled by Glib::GenPod::podify_pods() which means that the whole POD paragraph is returned, including the leading =for and the trailing =cut. So we get a double =cut for modules with such a =for position COPYRIGHT directive[1]. Aha! I knew i was missing something. So, while not having your patch breaks for some modules, i imagine adding your patch might break for other modules. Yeah. I think one solution would be to always output complete POD paragraphs with a trailing =cut, instead of relying on one final =cut. As in the attached patch. It fixes the Gnome2::Canvas problem while apparently not breaking anything else. Index: GenPod.pm That looks good. Should we worry at all about trying to strip trailing =cuts embedded in user text? -- The front of your fridge may be cheap and nasty, but I hope the next time you look at the back of your fridge, you'll regard it with suitable admiration. -- Tim Hunkin, The Secret Life of Machines ___ gtk-perl-list mailing list gtk-perl-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-perl-list
Re: [PATCH] fix POD generation with COPYRIGHT section in source
On Feb 13, 2009, at 8:03 PM, Ryan Niebur wrote: err, now it's attached. fix-pod-generation-for-copyright.txt If i'm reading GenPod.pm correctly, then i don't think this is right. xsdoc2pod() opens a whole bunch of sections, and the =cut is meant to close them all. I see that the docs say replace the generated COPYRIGHT section completely, but i don't think this is intended to mean so you should add your own =cut. In other words, i think it's wrong for the copyright text to include a =cut of its own. In fact, i don't see a =cut in Gnome2::Canvas's Makefile.PL. So, while not having your patch breaks for some modules, i imagine adding your patch might break for other modules. Perhaps GenPod.pm should filter out any =cuts that it finds in your copyright strings? Or maybe *shudder* use a state machine to keep track of whether we have written a =cut and write one at the end? Ick. DISCLAIMER: i was only reading source, not actually running anything. -- Me: What's that in your mouth? Zella: *swallows laboriously* Nothing. Me: What did you just swallow? Zella: A booger. Me: Baby girl, don't eat boogers. That's gross. Zella: But it was in my nose. ___ gtk-perl-list mailing list gtk-perl-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-perl-list
Re: GError location filename as wide chars
On Feb 11, 2009, at 7:31 PM, Quentin Sculo wrote: But I fear it's not possible to fix this without breaking existing code :( It's also quite possible that it's not possible to get these things to work correctly with the existing code. -- Yvonne: Let's do that one again so i can win. Zella: No. ___ gtk-perl-list mailing list gtk-perl-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-perl-list
Re: GError location filename as wide chars
On Feb 11, 2009, at 5:17 PM, Torsten Schoenfeld wrote: Kevin Ryde wrote: I expect anyone with non-ascii in the path to their perl code files is probably asking for trouble, but I think a filename_display_name() would at least get it displaying right. It's a little tricky to test this. I used the foo.pl below in a filename with some utf8, run in a utf8 locale. Without filename_display_name() the stringized bit gives an extra A etc, per the usual odour of bad utf8 (or bad odour of utf8, as the case may be :-) The looks good to me. muppet? I personally believe, that as a U.S. American, i cannot resolve UTF-8 issues, because, as a U.S. American, i don't have character maps, and our encodings over here should help us over there and do over here, for the keymap and such as. Translation: I do not feel qualified to comment. -- Yvonne: Let's do that one again so i can win. Zella: No. ___ gtk-perl-list mailing list gtk-perl-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-perl-list
Re: Glib-log() and %-style format strings
On Feb 5, 2009, at 7:48 AM, Torsten Schoenfeld wrote:
muppet wrote:
g_log (log_domain, SvGLogLevelFlags (log_level), message);
Well, that should be
g_log (log_domina, SvGLogLevelFlags (log_level), %s, message);
In a similar vein: how about the attached patch?
Index: GClosure.xs
===
--- GClosure.xs (revision 1071)
+++ GClosure.xs (working copy)
@@ -390,7 +390,7 @@ gperl_callback_invoke (GPerlCallback * c
error);
g_free (error);
/* this won't return */
- croak (SvPV_nolen (errstr));
+ croak (%s, SvPV_nolen (errstr));
}
sv = gperl_sv_from_value (v);
if (!sv) {
Good find. Ship it!
--
Sallah! I said no camels! That's five camels! Can't you count?
-- Indiana Jones
___
gtk-perl-list mailing list
gtk-perl-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-perl-list
Re: Glib-log() and %-style format strings
Torsten Schoenfeld wrote: Aloha, this always produces a segmentation fault on my machine: perl -MGlib -e'Glib-log(q/Test/, qw/warning/, q(%s %s));' The reason is that we pass the message string (%s %s in this case) unaltered down to g_log(): g_log (log_domain, SvGLogLevelFlags (log_level), message); Well, that should be g_log (log_domina, SvGLogLevelFlags (log_level), %s, message); in order to protect against nasty embedded % chars. I don't think that g_log() provides any formatting features that perl doesn't already trump. (I'm surprised, i thought we'd fixed that long ago.) -- 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: boxed re-registration key freeing
On Jan 27, 2009, at 5:58 PM, Kevin Ryde wrote: Chasing it down in gdb it looks like Gtk2.xs register.xsh registers Gtk2::Border with gperl_register_boxed, and then the Gtk2::Entry boot code re-registers it. [...] Is GtkEntry.xs meant to register Gtk2::Border, or can it be left to register.xsh? The idea is that the maps file defines the class and mapping and all that, and then we override the registration to provide a different wrapper class. It looks like gperl_boxed_register() takes precautions to insert into the hash with the destructor second, to avoid this sort of problem. Why isn't that working? -- 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: boxed re-registration key freeing
On Jan 28, 2009, at 4:01 PM, Kevin Ryde wrote: muppet sc...@asofyet.org writes: It looks like gperl_boxed_register() takes precautions to insert into the hash with the destructor second, to avoid this sort of problem. Why isn't that working? g_hash_table_insert() on info_by_package leaves the key string set to the one in the original boxed_info, but it's then freed. I think g_hash_table_replace() will change to the key string of the new boxed_info. Same string contents of course, new pointer. Augh, i should read more closely. You said that last time, but i missed it. :-) Yes, i think that using replace instead of insert would be the way to go. -- 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: cancel gtk_main_quit and return to the main window
On Jan 23, 2009, at 5:30 PM, Emanoil Kotsev wrote:
muppet wrote:
show an empty gray window appears.
You have the return value's meaning backwards.
not quite sure ... I didn't post it but I use
use Glib qw{ TRUE FALSE };
I was thinking it means what it says
The Glib constants do, indeed, mean what they say. What i meant was
that you were returning the wrong value from the delete-event signal
handler. You were returning TRUE to mean let this propagate and
destroy the window, but a return of TRUE from the delete-event
handler means i handled this event, stop propagation.
Bareword Gtk2::EVENT_STOP not allowed while strict subs in use
at ./testing line 354.
Bareword Gtk2::EVENT_PROPAGATE not allowed while strict subs in
use
at ./testing line 357.
Execution of ./testing aborted due to compilation errors.
Ooops, mea culpa. Those were added in r2086, which hasn't made it
into a stable release yet. They're in unstable 1.210.
That doesn't really work with stuff created by glade. Once you
destroy it, you must reload it from the xml file. So, people
typically just hide their glade-created windows instead of destroying
them.
yeah already proved this :-), so what try next, I'm out of ideas.
Swap the TRUE and FALSE in your gtk_main_quit (and maybe call it
something else, that's a misleading name ;-), and it should work as
you want.
--
So this new album took us quite a while, to get it together, to find a
title and things like that - and we were travelling quite a bit - we
made a few sort of gestures in the East, and a few gestures in the
West, and then we got thrown out because of our gestures - this is
something that we decided was an apt title for a thing that's called
'The Song Remains The Same'.
-- Robert Plant, rambling to introduce a song
___
gtk-perl-list mailing list
gtk-perl-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-perl-list
Re: cancel gtk_main_quit and return to the main window
On Jan 22, 2009, at 5:44 PM, Emanoil Kotsev wrote:
the problem is, as far as I understand it, that I create a gtk
obejct from
glade. when I hit the [x] button on the window
(window1::gtk_main_quit )
the gtk widget ($Gtk2-{Gtk2Main}) related to this window seems to
die. I
want to cancel it so I call a function quit which returns true if
data is
saved and false if data is modified but not stored.
Doesn't really matter, but when it receives false from quit() and I
call
show an empty gray window appears.
You have the return value's meaning backwards.
http://library.gnome.org/devel/gtk/stable/GtkWidget.html#GtkWidget-delete-event
Returns: TRUE to stop other handlers from being invoked for the
event. FALSE to propagate the event further.
But your code was
sub window1::gtk_main_quit {
# TODO: recreate the SaveAllWindow on destroy
if ( ! quit() ) {
$Gtk2-{MainWindow}-show();
$Gtk2-{SaveAllWindow}-hide();
return FALSE;
} else {
Gtk2-main_quit();
return TRUE;
}
}
Which says, if we don't want to quit, show the main window, hide the
saveall window, and propagate to the default handler which will
destroy the window. Else, kill the main loop and inhibit destruction
of the window.
We recently added some constants intended to disambiguate this kind of
stuff. So, you should rework that as
sub window1::gtk_main_quit {
# TODO: recreate the SaveAllWindow on destroy
if ( ! quit() ) {
$Gtk2-{MainWindow}-show();
$Gtk2-{SaveAllWindow}-hide();
return Gtk2::EVENT_STOP; # true
} else {
Gtk2-main_quit();
return Gtk2::EVENT_PROPAGATE; # false
}
}
and it ought to work as you wanted.
Basically I was thinking to recreate the window (using destroy and
new), but
destroying the first window/gtk object it destroys also the notebook
as
being part of the widget (window1), so I was thinking to put the
notebook
into a separate widget and pack it into the window
That doesn't really work with stuff created by glade. Once you
destroy it, you must reload it from the xml file. So, people
typically just hide their glade-created windows instead of destroying
them.
--
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: Can't add new GTK 2.16 methods to GtkStyle
On Jan 21, 2009, at 1:56 PM, Emmanuel Rodriguez wrote: Question do I actually need to wrap PL_sv_undef with a SV? Can't I just do ST (i - 2) = PL_sv_undef; ? I've tried both solutions and the unit tests work. I've also tried fetching properties that don't exist and I got no segmentation fault. You are right. I picked up the habit of wrapping the things from an xs tutorial long ago and can't seem to shake it. -- Teeter tots are shaped like marshmallows. -- Zella. ___ gtk-perl-list mailing list gtk-perl-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-perl-list
Re: g_malloc overhead
On Jan 18, 2009, at 11:43 AM, Martín Vales wrote: What are the advantages of use a glib_mem_vtable ???. I think we have the same malloc function in all operating systems? This vtable allows you to swap in a different allocator with next to no effort. Maybe it has special OOM handling, or uses a special pool or allocation algorithm tuned to your use-case, or does debugging logging work, or whatever. The fact that the default is the same everywhere is a bit beside the point of having the functionality. -- Me: What's that in your mouth? Zella: *swallows laboriously* Nothing. Me: What did you just swallow? Zella: A booger. Me: Baby girl, don't eat boogers. That's gross. Zella: But it was in my nose. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Can't add new GTK 2.16 methods to GtkStyle
On Jan 20, 2009, at 2:13 PM, Emmanuel Rodriguez wrote: Here's a new version of the patch with the fixes requested. GtkStyle.patch Comment suffers cut and paste bug -- refers to g_object_get_property(), i think you mean gtk_style_get_property(). Don't need braces around C if blocks with only one statement in them. Indentation on g_type_class_unref() is wonky. If we actually hit the warn (Invalid property ...) case, i think that the return list will contain the property name instead of the value. Should that case include ST (i - 2) = newSV (PL_sv_undef) so that we give back undef for bad property names? Or should we croak on bad property names, flagging that as programmer error? -- 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: g_malloc overhead
On Jan 18, 2009, at 11:43 AM, Martín Vales wrote: What are the advantages of use a glib_mem_vtable ???. I think we have the same malloc function in all operating systems? This vtable allows you to swap in a different allocator with next to no effort. Maybe it has special OOM handling, or uses a special pool or allocation algorithm tuned to your use-case, or does debugging logging work, or whatever. The fact that the default is the same everywhere is a bit beside the point of having the functionality. -- Me: What's that in your mouth? Zella: *swallows laboriously* Nothing. Me: What did you just swallow? Zella: A booger. Me: Baby girl, don't eat boogers. That's gross. Zella: But it was in my nose. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Hi - popup window vs top_level window
On Jan 18, 2009, at 5:32 AM, Dafna Hirschfeld wrote: On my main window I want to have an advanced button that when clicked, it opens a new window with advanced options. From what I understood, GtkDialog is used only for small amount of input so it's not suitable for advanced window. So now I wander whether I have to use a popup window or a top_level window, I didn't really get the difference between them. GtkDialog is fine for both modal and non-modal windows. If you want a window that floats over your app's main window and has buttons on the bottom, then you want a dialog. You can either use $dialog-run() to make the user interact with it before doing anything else (modal), or just $dialog-show() to let it stay up indefinitely (non-modal). Popups are borderless windows used for things like tooltips or menus. Very most likely, you don't want a popup. -- Sallah! I said no camels! That's five camels! Can't you count? -- Indiana Jones ___ gtk-perl-list mailing list gtk-perl-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-perl-list
Re: Can't add new GTK 2.16 methods to GtkStyle
On Jan 18, 2009, at 4:42 AM, Emmanuel Rodriguez wrote: On Sat, Jan 17, 2009 at 10:38 PM, muppet sc...@asofyet.org wrote: On Jan 17, 2009, at 2:44 PM, Torsten Schoenfeld wrote: Then the GValue will need to be initialized for which you need to know the type of the property. I think this will have to look something like this (modulo error checking): GParamSpec *pspec = gtk_widget_class_find_style_property ( g_type_class_peek (widget_type), property_name); g_value_init (value, G_PARAM_SPEC_VALUE_TYPE (pspec)); Oooh, good eye, i completely overlooked that. Thanks for the advice. The methods get_property() and get() have been added. I've added get() because I have assumed that that's is what gtk_style_get_valist should be named. Careful --- that will most definitely be a naming conflict with Glib::Object::get(). $style-get (...);- should that be Glib::Object::get() or Gtk2::Style::get() ? -- 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: progressbar into treeview
On Jan 18, 2009, at 11:06 PM, anguila wrote: So.. i guess i can't. how can i have a liststrore with progressbar? On Mon, Jan 19, 2009 at 4:58 AM, anguila angu...@gmail.com wrote: Im trying to make a downloader and i want to have a treeview with the name of the file and the % downloaded. And when i add a progressbar into a treeview i just get a segmentation fault... :S What i'm doing wrong? You can't add arbitrary widgets to a treeview, no. But you can use a cell renderer that shows progress. If you're using gtk+ newer than 2.6 (which is anything made in the last four years) then you can use Gtk2::CellRendererProgress. http://library.gnome.org/devel/gtk/stable/GtkCellRendererProgress.html http://gtk2-perl.sourceforge.net/doc/pod/Gtk2/CellRendererProgress.html -- Zella, carrying a kite in a long plastic box: It's like book! Yvonne, carrying the wooden kite string spool: It's like a wood! ___ gtk-perl-list mailing list gtk-perl-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-perl-list
Re: Can't add new GTK 2.16 methods to GtkStyle
On Jan 17, 2009, at 2:09 PM, Emmanuel Rodriguez wrote:
I'm trying to complete the patch set for GTK 2.16 but I can't get the
file GtkStyle.xs to compile.
I get the following errors when I try to build the module:
[ XS xs/GtkStyle.xs ]
Error: 'GType' not in typemap in GtkStyle.xs, line 582
Error: 'void' not in typemap in GtkStyle.xs, line 593
make: *** [xs/GtkStyle.c] Error 1
Looks like if I can't use GType as an argument type of an XS
parameter.
Indeed, no. GType is completely hidden from perl. We use package
names, instead.
Here's the code:
#if GTK_CHECK_VERSION (2, 15, 0)
void
gtk_style_get_property (style, widget_type, property_name, ...)
Remove the ... and replace return type of void with SV *. A
CODE xsub must return a value, and we don't use pass-by-reference
for these.
GtkStyle*style
GType widget_type
Change that one to
const char * widget_package
That's char, not gchar.
const gchar *property_name
PREINIT:
GValue value = {0,};
Add
GType widget_type;
CODE:
Add
widget_type = gperl_type_from_package (widget_package);
if (widget_type == 0)
croak (package %s is not registered with GPerl,
widget_package);
if (! g_type_is_a (widget_type, GTK_TYPE_WIDGET))
croak (%s is not a subclass of Gtk2::Widget,
widget_package);
gtk_style_get_property (style, widget_type, property_name,
value);
RETVAL = sv_2mortal (gperl_sv_from_value (value));
g_value_unset (value);
OUTPUT:
RETVAL
#endif
I'm stock please help.
--
Santa ate all the cookies!
-- Zella's first, indignant words on Christmas morning, '07.
___
gtk-perl-list mailing list
gtk-perl-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-perl-list
Re: Patch GtkSelection 2.16
On Jan 17, 2009, at 12:29 PM, Emmanuel Rodriguez wrote: Hi, Here's the patch for upgrading GtkSelection to Gtk 2.16. This patch is tricky and needs some revision because the new method added gtk_selection_data_get_selection() exists already and is aliased to 13 methods! Here's the old definition: [snip] I renamed the old implementation get_selection_. I used such an ugly syntax in order to stress that this is a private method, at least that's what the lack of documentation seems to be telling. Not necessary. If you look in cases 0 and 1, you'll see /* selection doesn't have an accessor yet. */ RETVAL = newSVGdkAtom (d-selection); but the other cases look like this: #if GTK_CHECK_VERSION (2, 14, 0) RETVAL = newSVGdkAtom (gtk_selection_data_get_target (d)); #else RETVAL = newSVGdkAtom (d-target); #endif So, the existing get_selection() is just a single xsub that is aliased to all those others to reduce the amount of duplicated boilerplate code that gets compiled. All you have to do is change the first case to #if GTK_CHECK_VERSION (2, 15, 0) /* FIXME 2.16.0 */ RETVAL = newSVGdkAtom (gtk_selection_data_get_selection (d)); #else RETVAL = newSVGdkAtom (d-selection); #endif And you're done. For extra points, you could golf the code a little bit with these definitions up before the first MODULE: #if ! GTK_CHECK_VERSION (2, 15, 0) /* FIXME 2.16 */ # define gtk_selection_data_get_selection (d) ((d)-selection) #endif #if ! GTK_CHECK_VERSION (2, 14, 0) # define gtk_selection_data_get_target (d) ((d)-target) # define gtk_selection_data_get_data_type (d) ((d)-data_type) # define gtk_selection_data_get_format (d) ((d)-format) ... #endif and unconditionally use the accessors in the switch. Index: t/GtkClipboard.t The clipboard test looks pretty good. -- If the monkey could type one keystroke every nanosecond, the expected waiting time until the monkey types out Hamlet is so long that the estimated age of the universe is insignificant by comparison ... this is not a practical method for writing plays. -- Gian-Carlo Rota ___ gtk-perl-list mailing list gtk-perl-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-perl-list
Re: Patch GtkPrintOperation 2.16
On Jan 17, 2009, at 12:40 PM, Emmanuel Rodriguez wrote: Here's the patch for upgrading GtkPintOperation to Gtk 2.16. The two new methods are really tricky as set_defer_drawing() has to be called from the signal callback 'draw-page' and draw_page_finish() will cause segmentation fault if set_defer_drawing() isn't called previously. I've documented this in the XS through POD. Looks good to me, though i have not tested it. The docs are a nice touch. -- 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: Patch GtkPrintSettings 2.16
On Jan 17, 2009, at 12:42 PM, Emmanuel Rodriguez wrote: Hi, Here's the patch for GtkPrintSettings 2.16. This was a trivial patch (at last!). Looking good. +#if GTK_CHECK_VERSION (2, 15, 0) +unless Gtk2-CHECK_VERSION(2, 15, 0); Do tag these with FIXME 2.16 comments, so that it's easier to track down all the places that need to be updated when we switch over to stable. -- Santa ate all the cookies! -- Zella's first, indignant words on Christmas morning, '07. ___ gtk-perl-list mailing list gtk-perl-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-perl-list
relocation reduction [Re: Gtk2 1.210 (unstable) available]
On Jan 16, 2009, at 1:40 PM, Thierry Vignaud wrote: Torsten Schoenfeld kaffeeti...@gmx.de writes: Overview of changes in Gtk2 1.210 = * Split out our pango bindings into the standalone Pango module and depend on it. * Add constants Gtk2::EVENT_STOP and EVENT_PROPAGATE for use in event handlers * Fix the stack handling in Gtk2::CellRenderer::get_size(). This still doesn't include muppet's work on shrinking big number of relocations done in perl-Gtk2 on startup... :-( Sorry about that. $dayjob has been stealing more cycles than i have for over a year. Last i recall about this, i hadn't found a way to do this that wasn't full of evil. Was this patch good for you? http://asofyet.org/muppet/software/gtk2-perl/relocations-2.patch (It'll need to be updated, of course.) -- elysse: You dance better than some. me: Some what? elysse: Some asparagus. ___ gtk-perl-list mailing list gtk-perl-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-perl-list
Re: GtkBindingSet etc
On Jan 15, 2009, at 6:20 PM, Kevin Ryde wrote: (how to include added files in an svn diff?). $ svn add newfile $ svn diff Voila. It goes ok. I think $bindingset-activate(keyval,modifiers,object) can do the dispatch part of what I was pondering for object add-ons, but I'm now not certain if the rc stuff actually leaves me any more configurable than before ... the priority mechanism seems geared towards widgets. GtkBindings.xs If the priority enumeration is really just a set of markers in a continuous (well, for integers) number space, then we probably want traditional perl constants instead of enum strings. Yes, gtk_binding_entry_clear() and gtk_binding_entry_remove() are different. (I have never seen this stuff before, i am reading the gtk + sources from svn.) clear will leave an entry in place, but with no contents, by destroying what's already there and creating a new one. remove will destroy the entry and leave nothing in its place. clear is deprecated, so not binding it is probably best. The varargs add_signal is not language binding friendly, so i think you've done best using add_signall. GtkBindings.t You have noinit = 1 in the args for TestHelper, followed immediately by use Gtk2 -init. This means the test will fail if you run with DISPLAY unset (the typical case for automated builds and packaging systems). I don't think you want to do that. TestHelper brings in Gtk2 for you, and will init automatically (with a SKIP in case of failure) unless you tell it noinit. binding-set-1.diff -- 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: Patch for GtkOrientable et GtkEntry (again) 2.16
On Jan 11, 2009, at 10:44 AM, Emmanuel Rodriguez wrote:
Here's the patch for adding GtkOrientable, a new interface added in
Gtk 2.16. I tried to do my best and took a look at other interfaces
(Gtk2::Editable and Gtk2::Buildable). This patch might need some
guidance.
I've resubmitted GtkEntry, because I realized that svn diff doesn't
take into a count the files that it doesn't know (the ones svn
status lists with '?'). This new version adds the typemap for 2.16.
Looking pretty good. However, your patch folded inline in the message
instead of being an attachment. Also, please break the orientable and
entry patches into two different files, so we can commit them
separately.
+MODULE = Gtk2::Orientable PACKAGE = Gtk2::Orientable PREFIX =
gtk_orientable_
+
+=for object Gtk2::Orientable - Interface for flippable widgets
+=cut
+
+=for apidoc __hide__
+=cut
+void
+_ADD_INTERFACE (class, const char * target_class)
+CODE:
+{
+ static const GInterfaceInfo iface_info = {
+ (GInterfaceInitFunc) NULL,
+ (GInterfaceFinalizeFunc) NULL,
+ (gpointer) NULL
+ };
+ GType gtype = gperl_object_type_from_package (target_class);
+ g_type_add_interface_static (gtype, GTK_TYPE_ORIENTABLE,
iface_info);
+}
This will compile and should run alright, until somebody tries to use
this to create a perl widget that implements Gtk2::Orientable. In
order to make the interface implementable, you'll have to add an
interface init function that wires in a bunch of marshalers to invoke
perl ALLCAPSMETHODS. You can see an example of this in some of our
other iface wrappers. (Warning: It can get pretty involved.)
--
Leia/Lois: Aren't you a little fat for a stormtrooper?
Luke/Chris: Well, stay here and rot, you stuck-up bitch.
-- Family Guy, Blue Harvest (A Star Wars parody)
___
gtk-perl-list mailing list
gtk-perl-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-perl-list
Re: Patch for GtkOrientable et GtkEntry (again) 2.16
On Jan 11, 2009, at 5:27 PM, Kevin Ryde wrote: muppet sc...@asofyet.org writes: Gtk2::Orientable. In order to make the interface implementable, you'll have to add an interface init function that wires in a bunch of marshalers to invoke perl ALLCAPSMETHODS. Are there any methods? Looks like someone thought a single property could be done by ginterface. Yeah, i didn't look first. ;-) The property might be problematic. Would it be correct for the bindings' interface wrapper to do the property override? -- 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: Patch for GtkEntry 2.16 (incomplete)
On Jan 10, 2009, at 10:57 AM, Emmanuel Rodriguez wrote: I didn't managed to add all the new methods of GtkEntry. It was harder than what I though as the widget has been greatly modified! The introduction of a new Gtype (GIcon) and a new Enum got me struggling for a while... I managed to solve the Enum problem by creating a new typemap file for 2.16. But I can't fix the GIcon issue. The icon modifications use a GIcon from Gio, as far as I know we don't even have Gio in the perl bindings. The bindings are incomplete because I couldn't add: gtk_entry_get_gicon gtk_entry_set_icon_from_gicon Can someone help me on this one? Looks like we'll have to have a go at GIcon over in Glib before these can be added. I'll have a look at that this evening, time permitting. Our policy has previously been don't bind stuff for which there is already equivalent or more popular support in perl, but i think GIO may bend that rule somewhat. It's more of an abstract IO framework than a replacement for file handles. Any opinions? Otherwise the new methods have been added with unit tests. By the way, go ahead and add the prototypes for all the new symbols, and just leave them commented out with an explanation for why they're not bound. This helps us know what we're missing and why. PS: In GTK 2.16, an entry can now act as a progress bar and can accept icons at the begging and/or at the end (similar to the search text field in firefox). I hope for gtk+ 3.x they make GtkEntry fry bacon and eggs and wash your laundry. :-) GtkEntry.patch For new functions that take pointer arguments (not counting the instance pointer), be sure to check with the upstream sources as to whether NULL is valid,. Looks pretty good so far. -- 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: Patch for GtkCellView 2.16
On Jan 10, 2009, at 2:40 AM, Emmanuel Rodriguez wrote: Same as the previous patch but with the proper gtk version check. Please, if something is wrong comment it to me as soon as possible as I will start to do the others modules. This one looks good. I'll need a bit more time to digest in full (kids + really old fedora + jhbuild = time sink), but there appear to be no zomg ur doon it rong things in here. :-) GtkCellView.patch -- So this new album took us quite a while, to get it together, to find a title and things like that - and we were travelling quite a bit - we made a few sort of gestures in the East, and a few gestures in the West, and then we got thrown out because of our gestures - this is something that we decided was an apt title for a thing that's called 'The Song Remains The Same'. -- Robert Plant, rambling to introduce a song ___ gtk-perl-list mailing list gtk-perl-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-perl-list
Re: default signal closure via bindingset
On Jan 9, 2009, at 4:01 PM, Kevin Ryde wrote:
The program below gets two errors
GLib-CRITICAL **: g_hash_table_lookup: assertion `hash_table !=
NULL' failed at /home/gg/bug/glib-sig-ret-undef/foo.pl line 44.
[gperl_value_from_sv] FIXME: unhandled type - 0 ((null)
fundamental for (null))
I think the first is gperl_fundamental_wrapper_class_from_type()
called
when wrapper_class_by_type is NULL. Is that supposed to be at least
possible? Maybe when _gperl_sv_from_value_internal() gets a signal's
return value which is a new fundamental type from some C code, when
neither that new type nor anything else has ever yet told to
gperl_register_fundamental_full()?
That is not supposed to be possible. We're supposed to do all the
type registration when loading the module, before any code using the
things gets called. But you're also not supposed to pass around
GValues with type G_TYPE_NONE, so far as i know. It makes me think
something else is afoot. Try the fix below, first.
I think the second is because gperl_signal_class_closure_marshal()
tries
to gperl_value_from_sv() into a GValue which is G_TYPE_NONE. Dunno
if a
return_value location like that is supposed to be allowed, but
gtk_binding_entry_activate() calls g_signal_emitv() that way.
That sounds like it could be a problem. We use the presence of a
return value pointer to determine whether we're supposed to expect any
return values, but here they've passed ... *brane asplode*
Try this: at the top of gperl_signal_class_closure_marshal(),
if (return_value) {
/* Try to cover for people doing strange things */
if (G_TYPE_NONE == G_VALUE_TYPE (return_value))
return_value = NULL;
}
This will cause return_value to be NULL later in the function where we
decide what flags to pass to call_method(). G_VOID|G_DISCARD will
cause the interpreter to toss anything returned from the subroutine so
that we don't have to worry about it.
--
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: Volunteers for wrapping new API?
On Jan 9, 2009, at 4:09 PM, Emmanuel Rodriguez wrote: I can give it a try as the weekend is arriving and it's cold outside ;) I don't have the most recent version of GTK nor perl Gtk2. I'm using the stock versions provided by Ubuntu 7.10, which is not even the most recent Ubuntu! I have a few questions: I hope that this is the right way for sending the patches for the next release of Gtk2. I will reply to the best of my knowledge to my own questions, please correct me if there's a better answer. I hope that this will help all new comers willing to contribute. Yes, please send patches to the list for review and discussion. And do not be offended by critique. ;-) What's the URL for perl Gtk2 trunk? svn co http://svn.gnome.org/svn/perl-Gtk2/trunk Installing the following modules from SVN might help to build the latest Gtk2: http://svn.gnome.org/svn/perl-Glib/trunk http://svn.gnome.org/svn/perl-Pango/trunk In Ubuntu/Debian I had to install the modules this way: perl Makefile.PL INSTALLDIRS=vendor make sudo make install PREFIX=/usr No! (see below) It's a pity because this will install the newest version over the existing one. But it should be possible to reinstall the original version of the OS with : sudo apt-get install libglib-perl libgtk2-perl --reinstall What's the best way for installing the newest Gtk2 and all it's dependencies? I tried to use jhbuild but it didn't work, so I had to install the Gtk2 libraries over the existing ones :( NnOooo.. jhbuild is recommended. You very much want to be able to distinguish between your stable distro gtk+ and the unstable development version. Be warned, it takes a long time to bootstrap with jhbuild. The README in each gtk2-perl module's tarball or svn checkout has this to say about installing development versions in a non-standard place: To avoid installing to a system directory, since this is a beta release, you can change the installation prefix at Makefile.PL time with perl Makefile.PL PREFIX=/some/other/place This will install the module to the subdirectory lib/perl5 under the given prefix. If this is not already in perl's include path, you'll need to tell perl how to get to this library directory so you can use it; there are three ways: in your environment (the easiest): # assuming a bourne-style shell PERL5LIB=/some/other/place/lib/perl5/site_perl export PERL5LIB on the perl command line: perl -I /some/other/place/lib/perl5/site_perl yourscript in the code of your perl script: use lib '/some/other/place/lib/perl5/site_perl'; I install the perl modules to the same sandbox root i use for my jhbuild install -- $HOME/sandboxes/gnomesvn -- and when i need to work with that sandbox, i source a script that sets up my shell's environment for that sandbox. You can also use jhbuild shell. To compile and test it's faster to specify the files to build than to do make. Calling make without arguments will rebuild everything, at least it did so on my system. That's very long and annoying. Instead, for faster results do this: make xs/GtkCellView.c xs/GtkCellView.o blib/arch/auto/Gtk2/Gtk2.so Typing make with no arguments will build the default target, all, which includes the docs. If you just say make blib/arch/auto/Gtk2/Gtk2.so then make will take care of rerunning xsubpp and compiling the necessary stuff. Test the patch make test or run the test directly: perl -Iblib/lib -Iblib/arch t/GtkCellView.t This is easier with -Mblib, e.g. perl -Mblib t/GtkCellView.t Since we support all stable versions, your new support needs to be made conditional. There are a few classes of this: 1. in XS and C code, new symbols are wrapped in #if GTK_CHECK_VERSION(...) for the version of gtk+ in which the symbol was introduced. It's best to go by the @since tags in the gtk-doc for the new function over in the gtk+ source. 2. in perl and .t code, tests for new symbols go into SKIP blocks, conditional on the gtk+ version in which the symbol was added. Look around at several other files, and you'll see the convention we use. -- Well done, Android. Aperture Science reminds you that Android Hell is a real place, and you will be sent there at the first sign of defiance. -- GlaDOS ___ gtk-perl-list mailing list gtk-perl-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-perl-list
Re: Mixing XS with Gtk2::TreeStore
On Dec 27, 2008, at 6:41 AM, Emmanuel Rodriguez wrote: I have a perl program that displays a tree with a lot of nodes (18_000) using Gtk2::TreeView and Gtk2::TreeStore. Populating the tree store takes close to 2 seconds, which I find slow. I want to improve the speed of the application by rewriting the slow part in XS. Stop. Custom XS should be a last resort, as it ratchets up the difficulty of maintaining and deploying your application, and is often unnecessary. Let's do some sanity checks first: a. Are you doing all this adding to the TreeStore while it is hooked up to the TreeView? If so, don't. Every time you insert, remove, or modify a TreeModel's row, it fires a notification so that any Views may update themselves. If you're adding thousands of rows in one go, this will slow you waaay down for no reason. You want to unhook the model from the view, do mass modifications, then rehook the model, like this: $model = $view-get_model (); $view-set_model (undef); fill_model ($model); $view-set_model ($model); b. Are you mirroring a data structure? That is, do you have a TreeStore that you keep in sync with some other perl data structure? If so, you are wasting a lot of memory and time. Either use the TreeStore as your native data store, or write a custom TreeModel that adapts the TreeModel interface to your native data store. You'll probably find that a. takes care of 90% of your speed problems, or you have different problems that will be solved by b. If a. doesn't solve your speed problems, and b. is infeasible or you're already doing it and it doesn't help, then it makes sense to dive into the dirty world of custom XS for your application. By the way, it would really help to see a minimal example that represents what your code is doing. So I rewrote the code used to fill the tree in a sample C file and it works fine. But if I wrap that same C code through XS I get segmentation fault each time that I try to store data into the Gtk2::TreeStore. In my case both the tree view and the tree store are created from Perl and manipulated through XS. If I run the perl interpreter through a debugger I can see that the segmentation fault occurs when I call gtk_tree_store_insert_with_values(). What's more strange is that the stack trace shows me that GTK ends up calling Perl and Gtk2 (the perl library) functions even though the tree store is empty. Is it possible to populate a Perl Gtk2::TreeStore from XS? Yes, we'll call back into perl to handle marshaling of data types while inserting values into the model. Perhaps I should be adding Perl data types to the tree store? Your stack trace indicates that you *are* adding Perl data types to your tree. Did you create your store with a column type of 'Glib::Scalar'? Here's the stack trace produced by gdb, frame #7 is my XS function: #0 0x080b8f53 in Perl_mg_get () #1 0x080da43f in Perl_sv_setsv_flags () #2 0x080dadd4 in Perl_newSVsv () #3 0xb7c69df7 in gperl_sv_copy () from /usr/lib/perl5/auto/Glib/ Glib.so perl-Glib sets up a boxed wrapper for SVs which uses gperl_sv_copy() as the copy method. #4 0xb7c09c12 in boxed_proxy_collect_value (value=0xbf82e9f8, n_collect_values=1, collect_values=0xbf82e9b8, collect_flags=0) at /build/buildd/glib2.0-2.16.4/gobject/gboxed.c:317 #5 0xb72aad53 in gtk_tree_store_set_valist_internal (tree_store=0x84214d8, iter=0xbf82eaa4, emit_signal=0xbf82ea54, maybe_need_sort=0xbf82ea50, var_args=0xbf82ea88 \001) at /build/buildd/gtk+2.0-2.12.9/gtk/gtktreestore.c:948 #6 0xb72acee7 in IA__gtk_tree_store_insert_with_values (tree_store=0x84214d8, iter=0xbf82eaa4, parent=0x0, position=0) at /build/buildd/gtk+2.0-2.12.9/gtk/gtktreestore.c:1441 #7 0xb7c46758 in my_populate_treeview (xargs=0xbf82eafc, node=0x8612128, parent=0x0, pos=0) at xs/code.c:215 #8 0xb7c46575 in populate_treeview (treeview=0x859d120, node=0x8603788, namespaces=0x85f8c6c) at xs/code.c:165 #9 0xb7c4382f in XS_Xacobeo__XS_populate_treeview (my_perl=0x8153008, cv=0x8527418) at lib/Xacobeo/XS.c:92 #10 0x080c22d3 in Perl_pp_entersub () #11 0x080c0cab in Perl_runops_standard () #12 0x0806727b in perl_run () #13 0x08063792 in main () All help is welcome. -- Well done, Android. Aperture Science reminds you that Android Hell is a real place, and you will be sent there at the first sign of defiance. -- GlaDOS ___ gtk-perl-list mailing list gtk-perl-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-perl-list
Re: Mixing XS with Gtk2::TreeStore
On Dec 27, 2008, at 12:19 PM, Emmanuel Rodriguez wrote:
On Sat, Dec 27, 2008 at 4:14 PM, muppet sc...@asofyet.org wrote:
On Dec 27, 2008, at 6:41 AM, Emmanuel Rodriguez wrote:
Stop. Custom XS should be a last resort, as it ratchets up the
difficulty
of maintaining and deploying your application, and is often
unnecessary.
Let's do some sanity checks first:
Let me present more deeply the problem. I have a Perl application that
displays an XML document with both source code syntax highlighting and
a DOM tree view. For now the problem I have is showing the DOM tree in
the tree view. For the moment, I'm using a TreeStore because there are
many examples showing how to work with a TreeStore. Populating the
TreeStore with the DOM tree is my current bottleneck. The application
is based on XML::LibXML which in turn is using libxml2. So the there's
already a quite decent data model: XML::LibXML::Document.
The slowness is due to the nature of XML::LibXML where each node and
field access is performed through XS. A small document of 400K can
very easily return over 170_000 DOM nodes. Walking such a tree in Perl
is slow (about 0.5sec) when combining it with the operations of a
TreeStore it takes 1.2 sec. Now imagine loading a 20 Megs document...
Alright, this is a different beast from how i interpreted your
original message. Context helps. :-)
So, your current design is to mirror the DOM in the TreeStore by
holding a reference to each element in the corresponding node in the
tree.
Two approaches come to mind:
x) Create a custom TreeModel implementation that directly accesses the
DOM. With some caching you could avoid having to walk the DOM on each
access, at the expense of memory, but it's unclear whether this would
actually be more efficient than letting TreeStore do that caching work.
y) Glue the DOM and TreeStore together in C code as a custom subclass
of TreeStore (or possibly a custom TreeModel, as above, but in C), and
create a perl binding for that object.
I think that something like y) was what you were initially trying to
do, correct? However, it sounds like you were still creating the
objects in perl and trying to implement only the bare minimum, the
populate function, in C.
sub create_model {
my $model = Gtk2::TreeStore-new(
'Glib::Scalar', # An instance to XML::LibXML::Element
'Glib::String', # The name of the Element
);
}
There it is -- the first column is 'Glib::Scalar', which is a generic
wrapper for a perl SV. Down in C, you'll see that as an SV. What's
inside depends on what you loaded into it. You can't just assume it's
a pointer. In fact, since XML::LibXML also wraps stuff up in XS goo,
you don't really know for sure how to get to the juicy C pointer
inside without scrubbing through the XML::LibXML source. I don't know
if they export helper functions in the vein of gtk2-perl's
gperl_get_object(), but you'll have to do some research.
This marshaling difficulty is one reason that i would recommend
actually writing the whole glue thing up as a GObject in C, and then
binding that GObject to perl, instead of trying to do only the
populate function. That way, you feed in one XML::LibXML object from
perl, and everything else happens in C.
Is there an example on how to implement a custom TreeModel?
I think the list archives will help most. The iters are the biggest
stumbling blocks in perl, thanks to how the C api works. For what
you're doing, i think i've talked myself into thinking you do, indeed,
want to do the work in C.
GTK+ 2.0 Tree View Tutorial
http://scentric.net/tutorial/
leveraging GtkTreeModel
http://davyd.livejournal.com/252351.html
Your stack trace indicates that you *are* adding Perl data types to
your
tree. Did you create your store with a column type of
'Glib::Scalar'?
Yes the TreeStore has slot for passing the XML::LibXML::Node that's
been displayed in the TreeView. I didn't realized that I had to pass
an SV* there. I was trying to pass a simple C pointer and expected it
to be magically transformed to a Perl type!
Hehe, magic takes work. ;-)
--
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: execution of timers from other callbacks
On Dec 17, 2008, at 12:00 PM, zentara wrote: Hi, I saw something on the gtk2-c list that got me thinking. :-) In the following code, a timer is placed in a button callback, but without a non-blocking-delay or a forced-loop-update in the for loop, the timer dosn't run until the button callback returns..even with very large numbers in the for loop. So is this a rule? That timeouts and idle_adds won't be scheduled until the callback they are in finishes, or you force the eventloop to check itself? Where is this documented? Or is it suposed to be obvious? :-) Here's the call flow: gtk_main() g_main_loop_run() g_main_context_dispatch() timeout callback timeout add spin in a loop Since you didn't return from the timeout callback, the main loop didn't run, and therefore your timeout doesn't fire. You must a) return from the callback, which implies i. break your work into chunks and handle each chunk in an idle callback ii. fork a subprocess to do the work, with pipes for communication and all that b) use a new main loop, as in your non_blocking_delay() function, which implies that you are simply waiting for something c) eat events manually, which implies you're doing real work, and if it's going to take a while, you don't want to do it this way -- elysse: You dance better than some. me: Some what? elysse: Some asparagus. ___ gtk-perl-list mailing list gtk-perl-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-perl-list
Re: GLib/perl and GArray, GType
On Dec 11, 2008, at 9:47 AM, Wouter Verhelst wrote: On Thu, Dec 11, 2008 at 12:31:09AM -0500, muppet wrote: Now, it's fairly easy for you to create a function that knows how to convert an array of whatever, and create a typemap for that. Then you can use that all over the place in your own code. Sounds like that could work. Having said that, I've not done much XS code beyond this project, and since your code has generated all my typemaps there (thanks, BTW), I wouldn't know where to start. Care to give me a pointer? ;-) Clue * clue_p = a_big_clue; [Okay, that was a horrible joke, i have to admit.] The easiest would be to use typedef to create aliases for arrays and lists, so as to reflect their contents and give them unique symbols. typedef GList * FooListOfGtkWidget Then, in the file typemap, you can associate type mapping code with the typedef: TYPEMAP FooListOfWidgetsT_LIST_OF_WIDGET INPUT T_LIST_OF_WIDGET $var = av_to_glist_of_widget ($arg); OUTPUT T_LIST_OF_WIDGET $arg = av_from_glist_of_widget ($var); You can also get really cute and try to infer the type name from the $var and $arg variables, as with T_GPERL_GENERIC_WRAPPER. There's more information on this in Lperlxstut. I had knocked together a patch that implements this, but working the kinks out of value coercion in the unit test expanded to fill all my available time for the evening, which was about half an hour. :- ( I'll try to get you a working patch later this week. That'd be great, thanks; and if you don't make it this week, there's no rush -- I know what's going on, and this is (mostly) a hobby project anyway. I seem to be misunderstanding the GParamSpecGType docs when they talk about how is_a_type works when it's G_TYPE_NONE. So, the unit test is a bit incomplete, and i can't guarantee that this works as intended. Please try it out and let me know what you think. The patch is against SVN trunk HEAD, but should be easy to apply to a recent release -- not much has actually changed in these parts. GParamSpecGType.patch Description: Binary data -- 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: GLib/perl and GArray, GType
On Dec 9, 2008, at 5:09 PM, Wouter Verhelst wrote: I've been using GObject and the GLib perl module to write some object/relational mapper. Mostly for fun (stop looking at me weird!), but it's working out quite well. Hey, some of us like writing language bindings, so you're in good company for weird. One thing I'm not very happy about is the way I have to work with GArrays and GTypes in the XS API. Every time my API returns more than one object, it uses GArrays to do this (although I'm thinking of changing that to GLists). As far as I can see in perldoc Glib::xsapi, the perl module doesn't do any black magic to make sure that GArrays (or GLists, or GSLists, or whatever) are automatically converted from and to perl lists. Is this correct? If so, it's not a huge deal--I can live with having to allocate an array and deallocate after having converted it to a perl list, but it would be nice to not have to do this *every time*. It gets boring :-) The GArray and GList do not specify the type of what they contain. Therefore, there's no generic way to convert them. You're always open to somebody deciding to be cute and have the first element be an object, the second be an int cast as a pointer, and the third be a boxed type. You'll crash on the second one, and probably the third one, too. Now, it's fairly easy for you to create a function that knows how to convert an array of whatever, and create a typemap for that. Then you can use that all over the place in your own code. By the way, the glib folks have discussed this before, in the context of the introspection api, for all the same reasons. Secondly, perldoc Glib suggests that every time you want to use a GType, the Perl version will be that you use a package name. A particular part of my API has a property that is a GType; it uses g_param_spec_gtype(), and this works from C. Unfortunately, the Glib module doesn't see this; I get errors about Foo::Bar not being a valid integer (despite it having been registered as a GObject package). Is there any way to make this work, other than an ugly hack of adding a perl-specific 'foo_bar_get_type_property' sub in the XS file? Hey, GParamSpecGType looks damned handy. It's new in 2.10, and appears to be unsupported in trunk of perl-Glib. It looks like it uses GValues that hold G_TYPE_GTYPE, so we should be able to set up marshaling logic in GValue.xs that calls gperl_package_from_type() and gperl_type_from_package() to do the magical conversions. I had knocked together a patch that implements this, but working the kinks out of value coercion in the unit test expanded to fill all my available time for the evening, which was about half an hour. :- ( I'll try to get you a working patch later this week. -- 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: calling main_quit from signal_connect - is it possible/legal ?
On Nov 23, 2008, at 5:27 PM, Sergei Steshenko wrote: Other than lack of decorations the 'popup' window seems to solve the problem - I hide the main window and show the 'popup' one, so there are no events to be registered by widgets since there are no widgets. Unresponsive UIs, with no progress indication and no Cancel button, are a horrible, horrible thing. Your users will despise you. You can still fork your app to have the main work run in another process, and communicate progress info to the other process, so allow pulsing a progress bar and watching for the user to hit a Cancel button. The subprocess is preferable to a thread here because the cancel action can be simply kill $child. -- Sallah! I said no camels! That's five camels! Can't you count? -- Indiana Jones ___ gtk-perl-list mailing list gtk-perl-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-perl-list
Re: treeiter stamp sign extension
On Dec 1, 2008, at 6:40 PM, Kevin Ryde wrote: In a custom TreeModel I was foolish enough to let my iter stamp generation come up with a 32-bit value. A cpan testers report on an int=32bit long=64bit system had me making 0x807012D8, but after storing that to a TreeIter then getting it back in an arrayref to a method call the array had instead 0x807012D8. You've fallen prey to perl's IV being defined as an integer large enough to hold a pointer. So, even though the platform is sizeof(int)=4, sizeof(IV) will be 8 because sizeof(void*)=64. To be honest, this isn't something we considered when wrapping that stuff. I think it's a case of don't do that on my part, but are stamps meant to be treated unsigned and zero extended (even though the C is a signed gint of course)? I doubt anybody actually considered that. On an int==long==32bit or int==long==64bit I guess stamps are always seen unsigned at the perl level, and there's no extension to worry about. But when gint is 32bit and UV is 64bit I wonder if it might want some casts [untested!], in sv_from_iter() av_push (av, newSVuv ((guint) iter-stamp)); and maybe in to_arrayref() truncate for the compare [also untested!] if (iter-stamp != (gint) stamp) If you don't mind testing that out, i think that's probably the best approach. -- Diane, ten-oh-three, Great Northern Hotel. Sheriff Truman and I have just been with the one-armed man, or what's left of him. In another time, another culture, he may have been a seer, or a shaman priest, but in our world, he's a shoe salesman, and lives among the shadows. -- Special Agent Dale Cooper ___ gtk-perl-list mailing list gtk-perl-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-perl-list
Re: treemodel foreach doc
On Dec 1, 2008, at 6:51 PM, Kevin Ryde wrote: The pod for treemodel-foreach() could helpfully show a sample call rather than just describe it. I always reckon a picture is worth a thousand words with such things :-). Looks good. -- Me: What's that in your mouth? Zella: *swallows laboriously* Nothing. Me: What did you just swallow? Zella: A booger. Me: Baby girl, don't eat boogers. That's gross. Zella: But it was in my nose. ___ gtk-perl-list mailing list gtk-perl-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-perl-list
Re: I have a problem
On Nov 30, 2008, at 1:42 PM, Dafna Hirschfeld wrote: I wanted to build a toolbar and insert buttons to it. I noticed that the documentation of Gtk2::Toolbar is very poor - it just lists all it's methods but has no description on what the methods do or about the meaning of the parameters. As mentioned in the master manpage (perldoc Gtk2), the perl api reference is meant to be used in conjunction with the C API reference documentation at http://www.gtk.org/documentation.html . The mangpage Gtk2::api explains how to do the mental translations between C and Perl. The idea is to avoid duplicating the documentation effort, and invariably having our copy drift out of sync with the upstream. We always welcome documentation patches. (And we're still open for volunteers to come up with a way to translate the gtk-doc xml files into pod...) Searching in Google brought me to this conversation and this page Now I am really confused, if those methods are deprecated why isn't it written in the documentation?, and why the new methods are not documented? Because we're lame and didn't come up with a way to tag deprecated stuff in the XS docs. Actually, the technical reason is that the bindings support being built against older versions of gtk+ 2.x in which those methods were *not* deprecated. The new methods are, indeed, documented. Look for the ones tagged Since: gtk+ 2.4. And another thing, when I run this code in order to get my version I get the output: Glib 1.190 Gtk2 1.190 Glib built for 2.16.4, running with 2.16.5 Gtk2 built for 2.12.11, running with 2.12.11 And I don't understand exactly what does it means, what is the different between built for and running with? and what is the 1.190 in the first 2 lines mean? This manual page explains the three version numbers: http://gtk2-perl.sourceforge.net/doc/pod/Glib/version.html -- Well done, Android. Aperture Science reminds you that Android Hell is a real place, and you will be sent there at the first sign of defiance. -- GlaDOS ___ gtk-perl-list mailing list gtk-perl-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-perl-list
Re: I have a problem
On Nov 30, 2008, at 5:13 PM, Sergei Steshenko wrote: Glib built for 2.16.4, running with 2.16.5 apparently means that you have version mismatch - Perl Glib was originally built based on C glib-2.16.4, but now your system has C glib-2.16.5. Of course, a micro version mismatch is fine. The three-part version numbers are major.minor.micro. Gtk+ promises that changes in micro version are just bugfixes. No rebuild of the perl module is needed. If your mismatch is a minor version, then one of two things happens: if the runtime version is an older minor version than you were built for, we fail with an error at startup. If the runtime version is a newer minor version than you were built for, then you are simply missing perl support for the new stuff in the C library. This is easily fixed by rebuilding the perl module. (Always use the newest stable perl module.) If your mismatch is a major version, then nothing works at all. -- The stereo, playing the Beastie Boys' Rhymin' and Stealin': I'll steal your girlie like I stole your bike! Elysse: You mean, take off the chain and ride away? ___ gtk-perl-list mailing list gtk-perl-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-perl-list
Re: calling main_quit from signal_connect - is it possible/legal ?
On Nov 22, 2008, at 5:13 AM, Chas. Owens wrote: On Mon, Nov 17, 2008 at 21:10, Sergei Steshenko [EMAIL PROTECTED] wrote: snip I am not going to call Gtk2-main_quit just for fun, I want to execute a really lengthy subroutine taking up to, say, 10 seconds. I've noticed that shorter (a couple of seconds) subroutines work fine, but the long ones sometimes interfere with GUI behavior - it looks like some events are either lost or are recognized out of order. snip The best way to deal with this is to continue to handle events during you long subroutines. You can handle all pending events by saying Gtk2-main_iteration while Gtk2-pending_events; If your subroutine has loops, then it is a good idea to put the code above at the top of the loops; otherwise, spread a few instances of the code through your subroutine. If it's going to be really long, you might be better off using fork() and pipes to do the work in a subprocess and leave the ui responsive. This also gives you the ability to add a cancel button to the ui, which would simply kill() the child process and clean up. -- Well done, Android. Aperture Science reminds you that Android Hell is a real place, and you will be sent there at the first sign of defiance. -- GlaDOS ___ gtk-perl-list mailing list gtk-perl-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-perl-list
Re: Is there interest in GOption support?
On Nov 16, 2008, at 1:21 PM, Mario Kemper wrote: Am Sonntag, den 16.11.2008, 12:50 +0100 schrieb Torsten Schoenfeld: The question now is: would you use this instead of any of the dozens of options parsers Perl already has? The patch adds quite a bit of code to Glib which we don't want to commit without there being demand for the feature. I'd love to see this implemented as well. Thanks. Looks like the Ayes have it. -- 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: Gtk2::SpinButton with blank value
On Nov 13, 2008, at 4:15 PM, Jeffrey Ratcliffe wrote:
Still with me?
Looks like Tadej's suggestion of the output signal may pay off.
#!/usr/bin/perl -w
package BlankableSpinButton;
use strict;
use Gtk2;
use Glib::Object::Subclass
Gtk2::SpinButton::,
signals = {
output = \_do_output,
},
;
sub latch_blank {
my ($spin) = @_;
$spin-{latch_blank} = 1;
$spin-update ();
}
sub unlatch_blank {
my ($spin) = @_;
$spin-{latch_blank} = 0;
$spin-update ();
}
sub _do_output {
my ($self) = @_;
print _do_output @_\n;
if ($self-{latch_blank}) {
$self-set_text ('');
$self-queue_draw ();
return 1;
} else {
return $self-signal_chain_from_overridden ();
}
}
package main;
use warnings;
use strict;
use Gtk2 -init;
use Glib qw(TRUE FALSE);
use Gtk2::SimpleList;
my $slist = Gtk2::SimpleList-new ('Value' = 'int');
@{ $slist-{data} } = ( 1..10 );
$slist-get_selection ()-set_mode ('multiple');
my $window = Gtk2::Window-new ();
$window-signal_connect (destroy = sub { Gtk2-main_quit () });
my $vbox = Gtk2::VBox-new ();
$window-add ($vbox);
my $adj = Gtk2::Adjustment-new (0, 0, , 1, 10, 1000);
my $spinbutton = BlankableSpinButton - new (adjustment = $adj);
$spinbutton-set_numeric (FALSE);
$spinbutton-set_text ('');
$vbox-add ($spinbutton);
$vbox-add ($slist);
$window-show_all ();
$slist-get_selection ()-signal_connect (changed = sub {
my @indices = $slist-get_selected_indices ();
if (@indices == 0) {
$spinbutton-latch_blank ();
$spinbutton-set_sensitive (FALSE);
} elsif (@indices == 1) {
$spinbutton-unlatch_blank ();
$spinbutton-set_sensitive (TRUE);
$spinbutton-set_value ($slist-{data}[$indices[0]][0]);
} else {
$spinbutton-set_sensitive (TRUE);
$spinbutton-latch_blank ();
}
});
$slist-get_selection ()-unselect_all ();
Gtk2-main;
__END__
--
Sallah! I said no camels! That's five camels! Can't you count?
-- Indiana Jones
___
gtk-perl-list mailing list
gtk-perl-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-perl-list
