Hi Roger,
I put together a test example of GSubprocess. It starts Gnuplot, sets up
the pipes and callbacks, and then when Gnuplot is done it opens the
graph in an image widget. The GSubprocess will take care of the file
descripters for you. ...
https://github.com/cecashon/OrderedSetVelociRa
On 2017-01-14 01:51 PM, Eric Cashon via gtk-app-devel-list wrote:
Hi Roger,
A little while back I was testing something similar with
g_spawn_async_with_pipes(). It is neither mission-critical or meticulous but
something I was just testing for the possible use with gnuplot. There is a
drive
Thanks much for the suggestions and code pointer, Eric!
I get the drift that GSubProcess is a more recent package layered over
g_spawn. It consequently seems to have more features but less 3rd-party
documentation outside the reference manual.
Roger
On Sat, 14 Jan 2017, cecas...@aol.com wrote
Hi Emmanuele,
On closer reading there are some details of GSubProcess implementation and
usage that are unclear to me. I have not been able to find anything
resembling a tutorial anywhere, if you are aware of anything useful other
than the base GSubProcess reference manual page please advise.
Hi Roger,
A little while back I was testing something similar with
g_spawn_async_with_pipes(). It is neither mission-critical or meticulous but
something I was just testing for the possible use with gnuplot. There is a
driver.c and a worker.c program. The driver spawns the worker and sets up
Hi Emmanuele,
Thanks very much for that additional explication, and I think your
reasoning on these issues is quite sound. I am being particularly careful
about making changes to working code here for two reasons. First, this is
mission-critical software running on a research vessel at sea --
On Sat, 14 Jan 2017 06:24:18 -1000 (HST)
rbd wrote:
> Hi Emmanuele,
>
> Thank you for the suggestion! I have just now looked over the
> GSubprocess API. It appears to have the necessary functionality and
> would at first inspection integrate well with GUI main loop
> processing.
>
> However, I a
Hi;
On 14 January 2017 at 17:17, infirit wrote:
> Op 01/14/2017 om 06:05 PM schreef Emmanuele Bassi:
>>> However, I am still curious as to whether the fork/exec/SIGCHLDhandler model
>>> of my existing X11/Motif app will or will not work with gtk3. This design
>>> has worked quite well in this par
Op 01/14/2017 om 06:05 PM schreef Emmanuele Bassi:
>> However, I am still curious as to whether the fork/exec/SIGCHLDhandler model
>> of my existing X11/Motif app will or will not work with gtk3. This design
>> has worked quite well in this particular application for many years and I am
>> reluctan
Hi;
On 14 January 2017 at 16:24, rbd wrote:
> However, I am still curious as to whether the fork/exec/SIGCHLDhandler model
> of my existing X11/Motif app will or will not work with gtk3. This design
> has worked quite well in this particular application for many years and I am
> reluctant to ch
Hi Emmanuele,
Thank you for the suggestion! I have just now looked over the GSubprocess
API. It appears to have the necessary functionality and would at first
inspection integrate well with GUI main loop processing.
However, I am still curious as to whether the fork/exec/SIGCHLDhandler
mode
Hi;
Don't use fork()/exec() directly with manual signal connection; use
GSubprocess from GIO, instead, which is a much better API, it's safe, and
it's likely more comprehensive in handling additional cases.
Ciao,
Emmanuele.
On Sat, 14 Jan 2017 at 01:30, rbd wrote:
>
>
> Hi all,
>
>
>
> I have
Hi all,
I have a few questions relating to the use of fork/exec within a gtk3
program. Briefly, (i) can this be made to work at all, and (ii) should I
perform any specific operations related to disconnecting from gtk within
the child process code of my gtk parent in the very brief interval be
13 matches
Mail list logo