Re: open/fork from a callback hang the windows (gtk2::helper)

2015-01-15 Thread Jeffrey Ratcliffe
On 15 January 2015 at 07:21, Prunk Dump prunkd...@gmail.com wrote:
 On all gtk2::helper examples I've found, the open call is made
 before Gtk2-main. How can I do if the windows is already displayed
 and if I'm inside gtkmain ?

I use Glib::Timeout() to update the progress bar. I start the
subprocess with IPC::Open3::open3(), and Glib::IO-add_watch() to
monitor the output.

You can see the gory details in

https://sourceforge.net/p/gscan2pdf/code/ci/master/tree/lib/Gscan2pdf/Frontend/CLI.pm

Search for _watch_cmd

Regards

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


Re: open/fork from a callback hang the windows (gtk2::helper)

2015-01-15 Thread Brian Manning
On Thu, Jan 15, 2015 at 9:21 AM, Prunk Dump prunkd...@gmail.com wrote:
 But if I fork the command with open in a callback, the gtkmain
 thread hangs until the command finish. I'm sure that the open call is
 non-blocking.

 sub my_callback {

my $fd = FileHandle-new()
open($fd, mycommand | ) or quitCallback(can't fork)

 }
 -- hang on return

 I don't really understand why. Maybe Gtk make the callbacks with new
 threads and wait the result with waitpid ?

No, threads aren't the answer here.

I'm guessing that your script hangs because you never read from the
opened filehandle in your callback, so mycommand never exits because
it's waiting for it's data to be read.

 On all gtk2::helper examples I've found, the open call is made
 before Gtk2-main. How can I do if the windows is already displayed
 and if I'm inside gtkmain ?

There's an example in the Gtk-Perl FAQ that uses
Gtk2::Helper-add_watch after the GUI has been displayed;

https://wiki.gnome.org/Attic/GTK2-Perl/FrequentlyAskedQuestions#How_do_I_keep_my_GUI_updating_while_doing_a_long_file_read.3F

Instead of calling open() in the callback as in your code snippet, you
make the open() call by itself, assign the filehandle created by the
open() call to a $variable, then add a watch on that filehandle
$variable via Gtk2::Helper-add_watch/Glib::IO-add_watch.
Gtk2::Helper-add_watch is just a wrapper around Glib::IO-add_watch
anyways.

Jeffery also suggested previously using IPC::open3 and
Glib::IO-add_watch to accomplish the same thing.

The FAQ also has an example of using the threads module, if you're
really trying to use threads, but using open() and adding a watch to
the filehandle will do what I think you are asking for, with less
pain.

Thanks,

Brian

http://perldoc.perl.org/functions/open.html
http://perldoc.perl.org/perlipc.html#Using-open()-for-IPC
___
gtk-perl-list mailing list
gtk-perl-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-perl-list


Using Alien on Windows for Gtk-Perl module installation, was Re: Installing Glib::Object::Introspection

2015-01-15 Thread Brian Manning
On Mon, Jan 12, 2015 at 3:15 PM, Ed . ej...@hotmail.com wrote:
 I have a vision of a Windows-compatible way of abstracting the finding of
 non-perl libraries, using Alien::*, probably using Alien::Base. This would
 mean there would be an Alien::Glib, etc, which on install would either find
 or build and install in perl's site library glib, and at runtime would
 dynaload it into perl.

 What are your thoughts?

The first thing that comes to my mind is compilers.  On Windows, it's
not guaranteed that a compiler is installed; this is why Strawberry
bundles a copy of MinGW with it's install, so it can compile Perl
modules that have XS extensions.  Also, the interaction of software
compiled with different C compilers is not guaranteed, i.e. if you
compile Perl with one compiler, and then compile XS modules with
another, things may not work as you expect.  This is true even on Unix
systems; it's generally best to use the same compiler for everything
that is meant to run together, like Perl and Perl modules that have XS
code.

In principle, I whole-heartedly support making things easier for end
users.  I'm not sure right now that Alien would do that, at least on
Windows platforms, without more thought towards how to set up and/or
guarantee a stable base to install Perl/Perl modules on top of.

I'd love to be proved wrong with something that sets your build
environment up on Windows (compilers, support binaries), and then does
the grunt-work of installing things for you (Glib/Gtk2/Gtk3 and
friends).

Does this answer your question?

Thanks,

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