Re: gtk_init() command-line args

[rbd]

Hi Michael,

Thanks very much for the reference! Looks like all of the arguments of 
interest to gtk begin with '--', so anything beginning with only a single 
'-' ought to be safe from gtk_init() harvesting.


Roger

On Wed, 16 May 2018, Michael Gratton wrote:


On Wed, May 16, 2018 at 7:34 AM, rbd <r...@soest.hawaii.edu> wrote:
Can someone point me to an official gtk3 documentation source which clearly 
lists all of the command-line arguments parsed and then stripped from 
argv[] by gtk_init()?


The "Running and debugging GTK+ Applications" document is the only thing I 
know of: <https://developer.gnome.org/gtk3/stable/gtk-running.html>. They are 
mostly debugging and legacy X11 workarounds, it seems. There are also similar 
docs for GLib and GIO, but those don't mess with your argv, AFAIK.


Of course, you really should be using G[tk]Application, which will call this 
for you, and aso provides a structured way of handing command line arg 
parsing. ;) Especially since that (IIRC) the plan for GTK+4 is to remove all 
GTK-specific command line args anyway.


//Mike

--
⊨ Michael Gratton, Percept Wrangler.
? <http://mjog.vee.net/>



___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

gtk_init() command-line args

[rbd]

Hi all,

Can someone point me to an official gtk3 documentation source which 
clearly lists all of the command-line arguments parsed and then stripped 
from argv[] by gtk_init()? I cannot find this information anywhere 
(although it would not be the first time I missed something right in 
front of my nose).


I want to ensure that I do not code any args of my own that are only going 
to be mysteriously stripped away by gtk_init(). And I would also just like 
to know what amazing things I can do for free with whatever args 
gtk_init() is actually looking for.


Thanks!

Roger Davis
Univ. of Hawaii
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: GtkFileChooser problem

[rbd]

Hi,
i recall having struggled with a file chooser some years ago,
but after some iterations got something that worked for me
for simple file operations. It was however impossible at that
time to tell the file chooser to open a file OR a dir so i ended
reinventing the wheel and wrote my own file chooser widget
( if you are interested in that drop a mail, but it is a lot
of code, some 1000+ lines).
Nonetheless attached inline you will find a copy of what did
work for me in the hope that it helps you. This is for gtk 2.0 tough
and maybe needs some adaptations.


Thanks very much for the example code, Tito! I have something that works 
well enough for me to be usable despite the oddities of the existing API 
and UI behavior, but I will inspect your code to see if there is anything

there that I can use to improve my situation.

Grazie,

Roger
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: GtkFileChooser problem

[rbd]

Hi all,

I have done some further experimentation with regard to my GtkFileChooser 
problem and discovered that the piece of my code that seems to be 
triggering this problem is the call to gtk_file_chooser_set_current_name() 
-- if I remove that then I do not get the error described in my last 
message.


Looking closer at the documentation I see a statement that says this 
function should not be used when an existing file is being specified, so I 
will take responsibility for ignoring that warning. I have to say, 
however, that this seems to me to be an unacceptable restriction -- why 
shouldn't I be able to initialize the text entry field at the top of the 
dialog to a completely clear and unambiguous presentation of the default 
name that will be returned by the dialog? And, why does a 
GTK_FILE_CHOOSER_ACTION_CREATE_FOLDER dialog which is supposedly designed 
to work with either pre-existing or yet-to-be-created filesystem objects 
(i) try to create something that already exists and then (ii) complain 
when that creation attempt fails, whether or not I call 
gtk_file_chooser_set_current_name() to set the text entry field?


I have noticed other inconsistent and weird behavior in the UI of this 
widget through my further experimentation today:


(1) When I do use gtk_file_chooser_set_current_name() to initialize the 
text entry field as shown in my original code, when I click the dialog's 
OK response button I get the error I have described. But if instead of 
clicking that button I activate the cursor in the text entry field and hit 
RETURN (without making any change to that field), everything works fine. 
Why is only clicking the OK button problematic?


(2) Independently of whether or not I use 
gtk_file_chooser_set_current_name() to initialize the text entry field to 
the name of a pre-existing current working directory (CWD), I have noticed 
that the OK response button will often be grayed out (and hence 
unclickable) even when the final path component of that CWD is selected in 
the dialog's large directory contents subwindow when the dialog is first 
mapped. Often I can fix this only by clicking on different directory 
contents subwindow objects (i.e., other subdirectories), perhaps several 
times, and then re-clicking on the subdirectory object which corresponds 
to my CWD (and which was originally selected). Only then does the OK 
response button get activated and become clickable.


I can appreciate that this widget may require a complicated 
implementation, and that in particular it may be difficult to properly 
correlate the text entry field with the directory contents subwindow. I 
have to say, however, that I think it would be worthwhile to get rid of 
the confusing limitations and behaviors noted above.


If there is further documentation on these issues somewhere that would 
help me to understand and avoid them better I would very much like to see 
it.


Thanks!

Roger Davis
Univ. of Hawaii

___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

GtkFileChooser problem

[rbd]

Hi all,

I am having a problem with GtkFileChooser when the chooser action is set to 
GTK_FILE_CHOOSER_ACTION_CREATE_FOLDER, i.e., I want to allow the user to 
specify any existing or as-yet-nonexistent directory. The documentation says 
that use of GTK_FILE_CHOOSER_ACTION_CREATE_FOLDER:


"... Indicates a mode for creating a new folder. The file chooser will let the 
user name an existing or new folder."


This certainly implies that if the user specifies an existing directory the 
dialog will not complain that it cannot create the specified directory because 
it already exists. Unfortunately, this is exactly what is happening to me! I 
get a popup message that says:


The folder could not be created
   Error creating /yadayadayada...: File exists

The chooser dialog remains visible while this message is displayed and after it 
is dismissed, waiting for me to select something else.


Curiously, this seems to happen only when I specify the current working 
directory (CWD) of the process. If I specify any other pre-existing directory 
this error does not occur. If I run this program from a different directory and 
specify my original CWD where it failed before, the error does not occur. It 
seems perfectly reasonable to me to make the CWD the default directory of 
choice for the user and I do not want to change this.


Can anyone explain this bizarre behavior? I am using gtk 3.22.24 (MacPorts 
release) under MacOS 10.12.6.


The relevant code follows, somewhat simplified from its original state to make 
it more intelligible here. Please advise if you see something stupid.


GtkWidget *d;
GtkFileChooser *fc;
char cwdbuf[BIGBUF];
int rspID;

if ((d= gtk_file_chooser_dialog_new("Dir Select", NULL, 
(GtkFileChooserAction) GTK_FILE_CHOOSER_ACTION_CREATE_FOLDER, "Cancel", 
GTK_RESPONSE_CANCEL, "Continue", GTK_RESPONSE_ACCEPT, NULL)) == (GtkWidget *) 
0)

return -1;

fc= GTK_FILE_CHOOSER(d);

if (getcwd(cwdbuf, (size_t) MAXPATHLEN) == (char *) 0)
return -1;
gtk_file_chooser_set_current_name(fc, cwdbuf);

rspID= gtk_dialog_run(GTK_DIALOG(d));

The error occurs within gtk_dialog_run() of course, as the dialog remains 
displayed and I can change the selection after I dismiss the error message.


I have also tried doing

gtk_file_chooser_set_create_folders(fc, FALSE);

prior to calling gtk_dialog_run() but that makes no difference.

Thanks in advance for any ideas!

Roger Davis
Univ. of Hawaii
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: gtkdialog maximum size

[rbd]

I second Stefan's suggestion of encapsulating your dialog panel within a 
scrolled window, and in fact I have made it a habit to implement that for 
every major toplevel window in all of my GUI software. You never know when 
an app that was designed for a nice fat desktop display will end up being 
run on a teeny-weeny laptop. Use the screen dimension discovery functions 
and the toplevel window size hints to set a maximum size on your toplevel 
window so that it's always guaranteed to be fully visible, even if the 
larger embedded scrolled window is only partially visible. You don't ever 
want to be in a position where your 'Click to Continue' button is 
completely inaccessable because it's hanging off the bottom of the screen.


Another solution I have used in the couple of odd cases where I was forced 
to show an especially large dialog, e.g., to configure plot parameters for 
a rather complex mapping display with dozens of display options, is to 
group your dialog components into subsets and access each group 
independently via a secondary dialog window which you display only when 
the user clicks on an 'Edit Group X Parameters' button in the main dialog.


I'm not a big fan of small font sizes to make things fit -- if you've 
already got what is practically a fullscreen window filled to overflowing, 
then making all those widgets smaller is just going to leave you with an 
illegible mess. Solve your problem through better organization, not 
miniaturization.


Roger Davis
Univ. of Hawaii
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: Re-drawing GtkDrawingArea surface on motion-notify-event

[rbd]

Hello Marcin,

I have written a number of gtk3 apps that perform the type of rubberband 
line drawing you have described. Although I was originally porting apps 
from an Xlib drawing environment where XOR was available to do 
lightning-fast 'undraws' of existing line segments and was skeptical of 
Cairo performance possibilities due to its lack of an XOR drawing op, I 
was very pleasantly surprised by its rendering speed (as Eric noted). In 
one of my apps, for instance, on a 2009 Macbook Pro laptop I can drag a 
wireframe with a dozen line segments around on a full-screen background 
field with only barely noticeable lag.


My suggestion to you would be to do the very easiest thing first and see 
if performance is acceptable -- if not, then do as Dov suggested and try 
redrawing only the smallest rectangle that encloses your line segment. You 
could also try using Cairo's clipping path, although I have no experience 
with that performance-wise.


Roger Davis
Univ. of Hawaii



From: Marcin Kolny 
To: gtk-app-devel-list@gnome.org
Subject: Re-drawing GtkDrawingArea surface on motion-notify-event
Message-ID:

Re: watching a file descriptor in gtk3

[rbd]

Eric (cecas...@aol.com) sent me the following earlier today in response to 
another discussion thread I started a few days ago re: GSubProcess:



I put together a test example of GSubprocess. ...


https://github.com/cecashon/OrderedSetVelociRaptor/blob/master/Misc/Pipes/gnuplot5.c


In an amazing bit of coincidence, Eric's example contains the following 
bit of code which would seem to have some bearing on this file descriptor 
watch discussion thread:


 GSource *source=g_pollable_input_stream_create_source((GPollableInputStream*)err_stream, 

NULL);

 g_source_attach(source, NULL);
 g_source_set_callback(source, (GSourceFunc)read_err, NULL, NULL);


Could this be yet another way to skin my cat? Perhaps better than the 
GIOChannel, if not the g_source_add_unix_fd() solution? Looks like I could 
create my own GInputStream with


  GInputStream *gis= g_unix_input_stream_new(mypipefd, FALSE);

and then use that stream (which should also be a GPollableInputStream, 
yes?) in the call to g_pollable_input_stream_create_source(). I had not 
intended to use stream (i.e., buffered) i/o, but there's probably no harm 
in doing so. This seems like a perspiration-free way to create the GSource 
I need.


Thanks doubly, Eric!

Roger

___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: watching a file descriptor in gtk3

[rbd]

Hi Emmanuele,

Thanks for the additional documentation references! They were generally 
informative, although I think the one you mentioned as being apropos of my 
particular case was actually designed to be used for a source specifically 
other than file descriptors -- it was useful nonetheless, however.


Roger


On Mon, 23 Jan 2017, Emmanuele Bassi wrote:


Hi;

On 23 January 2017 at 22:09, rbd <r...@soest.hawaii.edu> wrote:


It is not quite that bad.  The documentation for g_source_add_unix_fd()
is inadequate, but although not immediately obvious the prepare, check
and finalize handlers can in fact usually just be set to NULL (provided
you have set the 'events' argument for g_source_add_unix_fd()
correctly) so you only need to provide the dispatch handler, which
executes your callback when an event occurs.

The poor quality of the documentation is the real problem here.  I
would give it a try and see how you get on with it.



Nothing about the g_source_* functions is obvious from the official docs,
either immediately or otherwise! ;-> Seriously, one of the least illuminated
points there actually has to do with timeouts, exactly where in the
check->prepare->dispatch sequence the poll() gets done, etc.


Of course, patches and bugs for the documentation are welcome.

A good set of articles on GSource and the main context API in GLib is
on Philip Withnall's blog; Philip actually contributed back that
documentation in the API reference, but this kind of discussions on
how the implementation works is ill-suited for an API documentation.

See:

 - https://tecnocode.co.uk/2014/03/27/what-is-gmaincontext/
 - https://tecnocode.co.uk/2015/05/05/a-detailed-look-at-gsource/
 - 
https://tecnocode.co.uk/2014/04/19/ensuring-functions-are-called-in-the-right-context/

The second article also covers your use case pretty accurately.

Ciao,
Emmanuele.

--
https://www.bassi.io
[@] ebassi [@gmail.com]


___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: watching a file descriptor in gtk3

[rbd]

Thanks for all the further explication, Chris!


The problem is that the main loop would enter a busy loop.  Well, maybe
a 'busy-ish' loop.  If you call up g_idle_add() with a repeating
callback (one which returns TRUE) which does nothing except examine a
non-blocking select(), you will end up with one CPU core using
approximately 100% CPU.  The default idle priority
G_PRIORITY_DEFAULT_IDLE will put the idle event somewhat at the end of
the main loop's event queue, but when there is nothing else to do it
will continue executing it.  (On a multi-core system this might not be
immediately apparent - you need to be able to interpret top or whatever
other tool you use to see it.)

You could make this work with a timeout, say of around 50mS delay,
which puts the main loop to sleep for a while between iterations.


I hear you about the busyloop/timeout stuff. I have some familiarity with 
these issues from the ancient Xlib (and single-core/-CPU!) days, and 
appreciate your insight into how this impacts the glib/gtk mainloop.



It is not quite that bad.  The documentation for g_source_add_unix_fd()
is inadequate, but although not immediately obvious the prepare, check
and finalize handlers can in fact usually just be set to NULL (provided
you have set the 'events' argument for g_source_add_unix_fd()
correctly) so you only need to provide the dispatch handler, which
executes your callback when an event occurs.

The poor quality of the documentation is the real problem here.  I
would give it a try and see how you get on with it.


Nothing about the g_source_* functions is obvious from the official docs, 
either immediately or otherwise! ;-> Seriously, one of the least 
illuminated points there actually has to do with timeouts, exactly where 
in the check->prepare->dispatch sequence the poll() gets done, etc.



The GIOChannel interface is not well designed by today's standards.  It
confuses concerns by combining a wrapper for poll() with an object for
locale-based reading to and writing from files.  It is against modern
design practice to combine purposes in this way.  But it is old (it goes
back to GTK+-1.2 days) when large multi-purpose objects were all the
rage. We know better now.

Its naming is also now highly confusing as it is not related to glib's
gio namespace, which also provides numerous i/o functions, with an
emphasis on asynchronicity (but which unfortunately suffers from an
overly java-like approach to its stream objects - it may also be a
victim of its times).


Interesting history. Mixed-purpose utilities are a bit off-putting, but 
reliability and amount of available, easily understandable documentation 
go quite a long ways towards putting them back on again! My input is 
binary so I'd be turning off the encoding (and probably buffering) stuff 
anyway.


Thanks again for all your help!

Roger
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: gtk3 and fork/exec of non-gtk child

[rbd]

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/OrderedSetVelociRaptor/blob/master/Misc/Pipes/gnuplot5.c

This might not be what you are looking for since it is a little higher 
level than using a spawn function but there are a lot of things set up 
with GSubprocess that make it worth consideration. Options. You can do 
some nice plotting with GTK+ and Gnuplot also.


Eric


Thank you very, very much, Eric! I will definitely take a look at that.

Roger

PS: I think you submitted this to the wrong thread by mistake (I just 
opened a second topic on this list), so I am replying in the correct 
thread instead.


___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: watching a file descriptor in gtk3

[rbd]

Hi Chris,

Thanks very much for all of that information -- it was very helpful!


I do not fully understand your question (especially I don't understand
your reference to using "g_idle_add_full() and do my own non-blocking
select() inside my callback", which would not work), ...


I won't be trying the above approach unless all else fails (see below), 
but I am curious as to why you say that I could not successfully call a 
non-blocking select() (or poll(), if you prefer) on my file descriptor of 
interest inside a callback registered via g_idle_add_full(), then read 
from that descriptor if select() tells me there's something there. This is 
not as logically sensible as registering a separate input source to be 
polled inside the main loop, but I can't see why it wouldn't work.



... This may (or may not) help:


https://sourceforge.net/p/cxx-gtk-utils/git/ci/master/tree/c++-gtk-utils/io_$

Thanks very much for the above code sample -- unfortunately it confirms my 
very worst expectations of what might be involved with using 
g_source_add_unix_fd(), etc., to monitor a file descriptor, i.e., create a 
new GSource, code up a whole set of GSourceFuncs routines to implement a 
process which is not well-described in the docs, etc. I'm clearly barking 
up the wrong tree on that!



...


https://developer.gnome.org/glib/stable/glib-IO-Channels.html#g-io-add-watch


By the way, if you are thinking of using GIOChannel, you might also want
to look at the implementation of gdk_input_add() and
gdk_input_add_full() in gtk+-2. Although now deprecated in gtk+-2, you
can still use those functions if you happen to be building against
gtk+-2.


Using gtk3, not 2.



If you are using gtk+3 you can set up a read watch as follows (I have
not done a test compile on this snippet but it is what I have on
occasions done in the past, and it avoids keeping an explicit GIOChannel
object in scope if you only want to execute a callback when a
descriptor is ready for input - you can use the internal reference
counting to control channel lifetime):


guint start_read_watch(int fd, GIOFunc func) {
 GIOChannel *channel = g_io_channel_unix_new(fd);
 guint id = g_io_add_watch(channel,
   G_IO_IN | G_IO_HUP | G_IO_ERR,
   func,
   NULL);


GIOChannel is the ticket, I think, thanks for pointing me there (where I 
would probably have never gotten on my own)! Unlike 
g_source_add_unix_fd(), of which I could find no useful example code 
whatsoever other than the code you sent me, there seem to be a fair number 
of examples around on basic use of GIOChannel to more or less do what I 
want to do (I hope). This 2005 Robert Love article in particular was quite 
useful:


http://www.linuxjournal.com/node/8545/print

Still not as drop-dead simple as libXt/Motif's XtAppAddInput() (and I 
cannot believe that I am actually favorably comparing Motif to any 
more contemporary API whatsoever ;-> ), but simple enough to be useful.


Thanks a bunch again, Chris!

Roger
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

watching a file descriptor in gtk3

[rbd]

Hi all,

I need to monitor a Unix file descriptor for input within my gtk3 program. 
I believe that I need to somehow be using g_source_add_unix_fd() and 
friends but am finding the documentation confusing. Are there any simple 
examples which show how to do this anywhere? (I looked but could not find, 
apologies for any oversight on my part.)


I am porting an old Motif app which used

XtAppAddInput( ... fd ... callbackproc ...)

to register an input handler callbackproc() to be called whenever there 
was input pending on fd. Whatever I use to replace this should NOT block 
for any user-perceivable amount of time when checking fd for pending 
input, which will typically be very small (under 80 bytes) and occurring 
between a few times per second and a few times per hour.


Absent a working understanding of how to use g_source_add_unix_fd(), etc., 
my inclination is to just use g_idle_add_full() and do my own non-blocking 
select() inside my callback. Seems like g_source_add_unix_fd() is perhaps 
better suited to this task, but I can't figure out what I need to do vs. 
what glib can do without me, i.e., do I really need to create and attach 
my own GSource and code my own entire set of GSourceFuncs? That would seem 
to be a hugely complicated effort compared to the simple XtAppAddInput() 
call, or even to coding my own select() stuff inside a g_idle_add_full() 
callback. Monitoring a few stray file descriptors within a gtk3 program 
would seem to be a not-unusual need, so I am hoping someone will tell
me that there is an existing GSource somewhere that I can just add my own 
fd into, but that is not at all obvious from the documentation.


Thanks!

Roger Davis
Univ. of Hawaii

___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: gtk3 and fork/exec of non-gtk child

[rbd]

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 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
some communication. You just need to set the location path of the worker in
driver.c. Sort of simple but I had some trouble figuring out how some of
this worked so... it might be helpful.

https://github.com/cecashon/OrderedSetVelociRaptor/tree/master/Misc/Pipes

I haven't used GSubprocess and don't know of a short starter there.

Eric





___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: gtk3 and fork/exec of non-gtk child

[rbd]

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. Or, if 
there is a better forum to ask these questions, also please advise.


Here's what is still unclear to me about the suitability of GSubProcess 
for my code:


(1) Is there a ROCK-SOLID guarantee that the death of all child processes 
will be reported one-for-one with GSubProcess? My understanding of 
fork/exec/SIGCHLDhandler is that it is possible for there to be only one 
SIGCHLD made pending on a process even if multiple children have exited. 
This is dealt with by having the SIGCHLDhandler implement a loop which is 
capable of waitpid()ing on multiple children. How does GSubProcess cope 
with this issue? Is SIGCHLD even used at all, or is there a hidden 
SIGCHLDhandler somewhere that does waitpid()-ish looping? My app 
absolutely must know when each and every child dies (within a reasonable 
latency) or it's worthless.


(2) I see a g_subprocess_new() but no corresponding 
g_subprocess_destroy(). I will potentially have many children exiting and 
restarting and would prefer not to burn through the heap with scads of 
expired useless GSubProcess objects. I am not at all familiar with 
glib/gobject/gio in general, so I assume I am missing something totally 
obvious here.


(3) The GSubProcess doc page does not explicitly state this, but I get the 
impression from reading related pages (GAsyncResult) that the handler I 
register with g_subprocess_wait_async() is required to call 
g_subprocess_wait_finish(). Is this true?


Thanks!

Roger
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: gtk3 and fork/exec of non-gtk child

[rbd]

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 -- if it 
fails, (i) there will be no programmer on board who can fix it and poor 
off-ship comms make it virtually impossible for a programmer on shore to 
fix it either, and (ii) the jaw-dropping daily ship operation costs make 
failure absolutely unacceptable (and employment-threatening ;-> ). Second, 
despite the fact that the operating environment for the child processes is 
complex and unstable (they are communicating with sensors that might 
euphemistically be described as moderately ephemeral), the original code 
seems to cope with it quite adequately. Thus, the "ain't broke ---> don't 
fix" law applies strongly here. The part of the code that IS broken is the 
Motif, which has become increasingly difficult to maintain (as X11 itself 
will likely be in a few more years), hence the gtk3 port.


I think that perhaps what I will do is create two versions, one with 
GSubProcess and one with fork/exec. The former will be used preferentially 
unless it breaks, at which time the latter can be substituted as a 
fallback. Given your statement that I don't need to do anything special 
after forking (like deregister a gtk input handler or anything else 
related to gtk?), then the following fork-to-exec segment should work, 
yes?


pid= fork();
if (pid == 0) {
for (i= 3; i < 20; i++)
(void) close(i);
execlp("yada", "yada", "yada", 0);
exit(-1);
}

Note that I am still using the original brute force loop to close 
miscellaneous non-stdio descriptors. Probably one or more of these will be 
gtk-related, would that be a problem? If so, I would need to be more 
meticulous on this point, perhaps tracking down all of the parent's 
other open descriptors and making them close-on-exec like gtk's.


Thanks so much for your help!

Roger

On Sat, 14 Jan 2017, Emmanuele Bassi wrote:


Hi;

On 14 January 2017 at 16:24, rbd <r...@soest.hawaii.edu> 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 change it unless there is a strong argument that it either (i)
no longer works as well as it did because of circumstances peculiar to gtk3
vs. X11/Motif or (ii) is likely to stop working in the near-to-medium future
given current gtk3(/4?) development direction.


If you're not calling any GTK/GDK/X11 functionality in the children,
then you don't need to do anything special after forking. This has
been true for years, and will remain true for the foreseeable future.
The only thing you have to worry about are the usual interactions
between forking and system calls like malloc, or threading primitives.

Instead of GSubprocess, you could even use g_spawn_async() and friends:

 https://developer.gnome.org/glib/stable/glib-Spawning-Processes.html

Which is what GSubprocess uses anyway, though it's harder to set up
and still does not provide everything you may need without having to
reimplement it yourself.

The reason why I'm suggesting you to use the API provided by GLib and
GIO is that it's reliable, well tested, and maintained to take into
account changes in the userspace of modern system. For instance,
GSubprocess uses O_CLOEXEC to avoid leaking file descriptors from
parent to child; it uses a watcher thread to ensure that communication
and Unix signals are handled correctly, race free, and delivered to
the right main context; it controls the environment used to spawn the
child process in a safe way; it allows non-blocking handling of
communication between parent and multiple children.

In short: I would not generally recommend throwing away working code,
but I would strongly suggest using the safest implementation provided
by the platform you're targeting. Old code may be still working, but
does not imply that it's working according to the best practices of
modern systems. If the code in question is as old as you mention,
written for a very different era, then you may end up paying the
technological debt later on.

Ciao,
Emmanuele.

___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: gtk3 and fork/exec of non-gtk child

[rbd]

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 
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 change it unless there is a strong argument that it 
either (i) no longer works as well as it did because of circumstances 
peculiar to gtk3 vs. X11/Motif or (ii) is likely to stop working in the 
near-to-medium future given current gtk3(/4?) development direction.


Thanks again!

Roger

On Sat, 14 Jan 2017, Emmanuele Bassi wrote:


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 <r...@soest.hawaii.edu> wrote:


  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 between

  the fork() and the exec()? Following are details of my situation
  which I

  believe is extremely simple, and I want to use the very simplest
  working

  solution.



  I am porting someone else's old X11/Motif process management GUI
  to gtk3.

  It makes extensive use of fork/exec and a SIGCHLD signal handler
  (which

  waitpid(.. WNOHANG)s on terminated children) to manage somewhere
  between 5

  and 20 or so child processes. These children do NOT have any GUI
  and are

  background data logging processes which read serial and/or
  network data

  sources and write reformatted output to serial, network and/or
  disk

  destinations. The management GUI is a simple tabular display
  with one row

  per child that shows whether each child is running or not and
  has a

  clickable button allowing the operator to start/stop/restart
  that

  particular child. The manager needs to remain running for time
  periods as

  long as 3 months.



  Porting this to gtk3 seemed trivial until I started reading
  these archives

  yesterday and encountered numerous warnings about using
  fork/exec with

  gtk. It's unclear whether or not they apply to me since my child
  processes

  will have absolutely no GUI of any kind (not gtk, X11 or
  anything else)

  either related to or even completely independent of the gtk GUI
  running in

  the manager process. Opinion about this does not seem to be
  uniform: some

  people say that fork/exec works just fine if you have a simple
  scenario,

  others give dire warnings and recommend more complicated systems
  of forks

  within threads, use of various glib spawn/task functions, etc. I
  do not

  want to (i) expend more effort than is truly needed, or (ii)
  unnecessarily

  burden the code with complexity specific to the needs of
  gtk/glib that

  will all have to be unraveled and redone ten years from now when
  the

  inevitable next-generation API displaces gtk. (No offense
  intended, but

  I've seen this movie a few times. ;-> )



  Following is the existing fork-to-exec segment of the child code
  in the

  X11/Motif manager. Only a couple things of interest take place
  here: (i)

  an Xt input handler process registered at program startup via

  XtAppAddInput() which was periodically reading some non-X11 file

  descriptor is deregistered, and (ii) a bunch of other non-stdio
  file

  descriptors are closed (presumably including the X11 display
  socket). The

  latter was written as a brute force loop that just tries to
  close

  everything in sight whether it might have been open or not, even
  though

  the manager seems to be opening only a couple of other file
  descriptors

  outside of X11.



           pid= fork();

           if (pid == 0) {

                   XtRemoveInput(xtinputid);

                   for (i= 3; i < 20; i++)

                           (void) close(i);

                   execlp("yada", "yada", "yada", 0);

                   exit(-1);

           }



  Given that I want the gtk/gdk/etc. library code running within
  my parent

  manager process to remain ignorant of all children and continue
  operating

  as if the

gtk3 and fork/exec of non-gtk child

[rbd]

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 between 
the fork() and the exec()? Following are details of my situation which I 
believe is extremely simple, and I want to use the very simplest working 
solution.


I am porting someone else's old X11/Motif process management GUI to gtk3. 
It makes extensive use of fork/exec and a SIGCHLD signal handler (which 
waitpid(.. WNOHANG)s on terminated children) to manage somewhere between 5 
and 20 or so child processes. These children do NOT have any GUI and are 
background data logging processes which read serial and/or network data 
sources and write reformatted output to serial, network and/or disk 
destinations. The management GUI is a simple tabular display with one row 
per child that shows whether each child is running or not and has a 
clickable button allowing the operator to start/stop/restart that 
particular child. The manager needs to remain running for time periods as 
long as 3 months.


Porting this to gtk3 seemed trivial until I started reading these archives 
yesterday and encountered numerous warnings about using fork/exec with 
gtk. It's unclear whether or not they apply to me since my child processes 
will have absolutely no GUI of any kind (not gtk, X11 or anything else) 
either related to or even completely independent of the gtk GUI running in 
the manager process. Opinion about this does not seem to be uniform: some 
people say that fork/exec works just fine if you have a simple scenario, 
others give dire warnings and recommend more complicated systems of forks 
within threads, use of various glib spawn/task functions, etc. I do not 
want to (i) expend more effort than is truly needed, or (ii) unnecessarily 
burden the code with complexity specific to the needs of gtk/glib that 
will all have to be unraveled and redone ten years from now when the 
inevitable next-generation API displaces gtk. (No offense intended, but 
I've seen this movie a few times. ;-> )


Following is the existing fork-to-exec segment of the child code in the 
X11/Motif manager. Only a couple things of interest take place here: (i) 
an Xt input handler process registered at program startup via 
XtAppAddInput() which was periodically reading some non-X11 file 
descriptor is deregistered, and (ii) a bunch of other non-stdio file 
descriptors are closed (presumably including the X11 display socket). The 
latter was written as a brute force loop that just tries to close 
everything in sight whether it might have been open or not, even though 
the manager seems to be opening only a couple of other file descriptors 
outside of X11.


pid= fork();
if (pid == 0) {
XtRemoveInput(xtinputid);
for (i= 3; i < 20; i++)
(void) close(i);
execlp("yada", "yada", "yada", 0);
exit(-1);
}

Given that I want the gtk/gdk/etc. library code running within my parent 
manager process to remain ignorant of all children and continue operating 
as if there were none, my more particular questions with regard to this 
child process code are:


(1) Do I need to deregister the gtk input handler that I will be 
substituting for the old Xt input handler?


(2) Do I need to explicitly call any kind of gtk shutdown or main loop 
exit function or should I very clearly avoid doing so?


(3) Should I do the same kind of brute force file descriptor closedown as 
the original code? Analogously to X11, I have to think this would close at 
least one gtk-opened decriptor, which might be something that I should 
definitely either do or NOT do.


(4) I read one archive reference that said children should always use 
_exit() rather than exit() in this context. Is that true, and if so does 
that apply only to the cleanup after a failed execlp() in this fragment or 
should it be done for all exit instances within the child's own source 
code as well? This processing system includes dozens of child process 
programs and doing the latter would be a real pain (and perhaps have other 
unwanted consequences for the child).


My gut instinct is that given that the exec() will give the child process 
an essentially clean slate EXCEPT for inheritance of open descriptors, I 
probably do want to close all non-stdio descriptors one way or another 
prior to the exec -- the essential question is how to do this in a way 
that causes no impact whatsoever to the gtk ennvironment of the manager 
parent.


Thanks!

Roger Davis
Univ. of Hawaii

___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: deprecated gtk_cairo_create

[rbd]

On Fri, 30 Dec 2016, cecas...@aol.com wrote:


Hi Roger,

Would this be similar to using a GtkLayout and a GtkDrawingArea? If you add
a drawing area to a layout you get draw scrolling and the layout can update
the part of the drawing area shown on the screen even though the drawing
might be on a larger area.

Eric


Hi Eric,

Actually yes, I put my drawing area inside a layout inside a scrolled 
window inside a toplevel window. I wouldn't be surprised if there were a 
half-dozen better ways to the same end, but I got this to work for me and 
I'm stickin' with it 'til it breaks. ;-> The outer layers (layout through 
toplevel) actually constitute another principal object type of my toolkit 
(a Frame) which is used to encapsulate other non-Canvas objects such as 
large dialog panels and textwindows. Seemed like an easy way to make all 
of my toplevels downsizable and scrollable.


Roger
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: deprecated gtk_cairo_create

[rbd]

Hello Sergei,

Unfortunately the use of the gtk3 DrawingArea is a bit obscure and 
difficult to figure out. However, I have been able to make use of it very 
effectively in conjunction with Cairo drawing ops.


For various reasons I have created a GUI toolkit library which lies 
between my app code and gtk3. This library includes an object known as a 
Canvas, which is essentially a toplevel window with scrollbars parenting a 
DrawingArea. The Canvas object includes a private off-screen Cairo drawing 
surface which I create and control completely, and I do all of my 
application drawing onto that surface. Then, I use the gtk3 draw signal 
mechanism to copy whatever recatngular areas I want from my private 
surface onto the DrawingArea. gtk3 passes to my drawing event handler a 
pointer to a Cairo context which addresses the DrawingArea's own Cairo 
surface, so all I need to do in the draw event handler is set a source 
surface on that context (in my case, the source surface is my own private 
Cairo surface), and copy a rectangle. As far as I know there is no safe 
way to access the Cairo surface of a gtk3 DrawingArea other than through 
the Cairo context pointer passed into the drawing event handler.


Following is some incomplete, stripped down code which may help to explain 
the above ideas. I hope this helps!


Roger Davis
Univ. of Hawaii

# code follows ###

/* Here are the relevant parts of the Canvas structure */
typedef struct {
...
GtkWidget *drawarea;/* created by gtk_drawing_area_new() */
int width, height;  /* size of DrawingArea */
cairo_surface_t *surface; /* my private Cairo surface */
...
} Canvas;

gboolean
canvasdrawevt(GtkWidget *w, cairo_t *cr, gpointer gp)
/*
   This internal routine handles draw signals sent by GTK+3 to a Canvas'
   GtkDrawingArea widget. These signals will typically be generated by
   expose events or by program calls to gtk_widget_queue_draw_area()
   generated from within canvasflushregion(). This routine merely copies
   the rectangle(s) of interest from the off-screen Cairo drawing surface
   of the canvas into the actual GtkDrawingArea widget.
*/
{
Canvas *c;

if (gp == (gpointer) 0)
return FALSE;
c= (Canvas *) gp;
if (w != c->drawarea)
return FALSE;

/* here I set the source to my private
   surface which I have already drawn */
cairo_set_source_surface(cr, c->surface, 0, 0);

/* note that according to various (and occasionally obscure)
   GTK+3 docs, the context cr passed into this routine has
   already been clipped to any exposed rectangle(s) of interest
   (or whatever canvasflush{reg}() has marked for redraw via
   its call to gtk_widget_queue_draw_area()), so the following
   call to copy the whole drawing surface is not as expensive
   as it looks! */
cairo_rectangle(cr, 0, 0, (double) c->width, (double) c->height);
cairo_fill(cr);

return TRUE;
}

/* Here is how the important parts of the Canvas are created ... */

Canvas *
canvascreate(gint width, gint height, ... )
{
Canvas *c;
int i;
GtkWidget *win, *lo, *sw;
GdkGeometry geom;

if ((c= (Canvas *) calloc((MemSizeType) 1, sizeof(Canvas))) == (Canvas 
*) 0)
return (Canvas *) 0;

...

/* create the DrawingArea */
c->width= width;
c->height= height;
if ((c->drawarea= gtk_drawing_area_new()) == (GtkWidget *) 0) {
canvasdestroy(c);
return (Canvas *) 0;
}
gtk_widget_set_size_request(c->drawarea, width, height);
gtk_widget_set_can_focus(c->drawarea, TRUE);
...

/* attach the drawing event handler */
g_signal_connect((gpointer) c->drawarea, "draw", 
G_CALLBACK(canvasdrawevt), (gpointer) c);
...

/* create our private Cairo surface on which we will draw
   everything */
if ((c->surface= cairo_image_surface_create(CAIRO_FORMAT_ARGB32, (int) 
width, (int) height)) == (cairo_surface_t *) 0) {
canvasdestroy(c);
return (GITCanvas *) 0;
}
...

return c;
}

/* Call this routine to copy our private Cairo surface to the DrawingArea
   whenever we want (i.e., after we have done all our drawing into the
   former).  A call to this routine will result in our drawing event
   handler above being called asynchronously at some later time (but
   probably just about immediately). */
void
canvasflushregion(Canvas *c, int x0, int x1, int y0, int y1)
{
unsigned int w, h;

/* my real code checks x0/x1/y0/y1 for
   correctness before proceeding! */
...

w= (unsigned int) (x1-x0+1);
h= (unsigned int) (y1-y0+1);

/* the following call will result in GTK+3/GDK sending a draw
   signal 

GTK+3 CSS style function questions

[rbd]

Hi all,

My GTK+3 app includes several GtkButton widgets which I am setting to 
specific background and foreground (i.e., label) colors. Furthermore, the 
colors of each of these buttons are changed over time in response to user 
activity. My current code seems to work OK but I have a few questions re: 
optimization vs. safety in my use of the GTK style routines.


Here is a condensed version of the relevant code (questions follow below):


GtkWidget *button;
GtkCssProvider *gcp;
GtkStyleContext *gsc;
char fgrgbtext[10], bgrgbtext[10], cssbuf[512];

button= gtk_button_new_with_label((gchar *) "yadayada");
gsc= gtk_widget_get_style_context(button);

/* set arbitrary hex color strings */
(void) strcpy(fgrgbtext, "#00");
(void) strcpy(bgrgbtext, "#d264ff");
(void) sprintf(cssbuf, "GtkButton {\ncolor: %s;\nbackground-color: 
%s;\nbackground-image: -gtk-gradient(linear, center top, center bottom, 
from(%s), to(%s));\n}\n", fgrgbtext, bgrgbtext, bgrgbtext, bgrgbtext);


gcp= gtk_css_provider_new();
gtk_css_provider_load_from_data(gcp, cssbuf, -1, 0);
gtk_style_context_add_provider(gsc, GTK_STYLE_PROVIDER(gcp), 
GTK_STYLE_PROVIDER_PRIORITY_APPLICATION);



Keeping in mind that I am repeatedly changing the colors of several of 
these buttons over and over again under user control, my questions are:


(1) It seemed safest to statically allocate and maintain a distinct 
GtkCssProvider object for each of my buttons, otherwise multiple buttons 
might somehow wind up referencing the same style setting, i.e., colors. Or 
is this unnecessary, i.e., perhaps gtk_style_context_add_provider() copies 
the GtkCssProvider's contents into the widget and then the latter never 
references the actual GtkCssProvider object again?


(2) The GTK manual says a widget's GtkStyleContext is owned by the widget 
and should not be freed. Will the pointer to a particular widget's 
GtkStyleContext returned by gtk_widget_get_style_context() be unchanging 
over the life of the app or is it possible that it may change over time 
for whatever reason (e.g., by GTK internally destroying and recreating the 
widget's style context)? Is it safe for me to maintain my own static 
pointers to my various buttons' style contexts, or should I always 
retrieve the necessary context via gtk_widget_get_style_context() just 
prior to altering a particular button's style?


(3) Do I need to call gtk_style_context_add_provider() every time I want 
to change the same button's color, or should (must?) I only call that 
function once the very first time I set the button's colors, and then just 
call gtk_css_provider_load_from_data() with my updated cssbuf style 
description string containing the new colors every time I want to 
subsequently alter the colors? Will a bad thing happen if I repeatedly 
call gtk_style_context_add_provider() with the very same 
GtkStyleContext/GtkCssProvider object pair?


(4) Is there an authoritative reference on the syntax of style description 
strings created for use with gtk_css_provider_load_from_data()? Is there 
somewhere I can find a complete listing of every single property substring 
that might impact the appearance of a GtkButton, for example? I had to 
puzzle this stuff out from a half-dozen blog posts in various places, 
which was quite a pain in the ass. (Although I am infinitely grateful to 
the bloggers, of course!) I can never find my own 
phone/glasses/keys/whatever, though, so I freely admit the possibility 
that I'm missing the obvious somewhere in the existing GTK+3 manual.


Thanks!

Roger Davis
Univ. of Hawaii

___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

GtkColorChooser questions

[rbd]

Hi all,

I am trying to use the GtkColorChooserDialog (3.14 under CentOS7 and also 
3.18 under MacOS/MacPorts) and have two questions:


(1) My app will potentially do a substantial amount of custom color 
creation. Every time I make a new custom color with GtkColorChooserDialog, 
the next time I open the dialog to make another custom color, my previous 
custom color gets added as a new color swatch to the right of the custom 
color button at the bottom of the dialog. This ultimately leads to a LOT 
of unwanted color swatches in the dialog. It gets even worse as it seems 
that these custom colors are remembered when I exit the program and 
restart. I do NOT want to see every custom color I have created since the 
beginning of time appear as its own swatch in this custom color display! 
How do I disable this behavior so that I NEVER see new custom color 
swatches displayed in the dialog? I have tried calling 
gtk_color_chooser_add_palette() but that seems to only get rid of the 
row/column standard swatch display, while leaving all the unwanted custom 
color swatches in place. I have found that 'gsettings reset 
org.gtk.Settings.ColorChooser custom-colors' will clear the custom color 
swatches between program runs, but (i) that's a solution beyond the 
expertise of many of my users, and (ii) I want this unwanted swatch 
proliferation within each program execution to stop as well.


(2) Running the GtkColorChooserDialog via gtk_dialog_run() seems to always 
result in a two-step operation for the user. First, a palette of swatches 
is displayed. Then, if the user clicks the custom button (or asks to 
customize an existing color), the HSV color field tool displays and can be 
used to create a new color. I find the whole palette swatch display step a 
waste of time -- what I really want to do is to go straight to the HSV 
color field selector after first initializing the color field, via program 
subroutine call and not user GUI activity, to an initial arbitrary RGB 
setting. Is there a way to do this?


I have only tried the GtkColorChooserDialog so far, and not the 
GtkColorButton or GtkColorChooserWidget, as I saw nothing in their 
documentation that hinted I would get better results by using either of 
them directly instead of the GtkColorChooserDialog. If I'm mistaken please 
advise! (All things being equal I'd prefer using the dialog for 
programmatic convenience.)


Any suggestions (other than write my own color chooser, which I fear may 
be my ultimate fate)?


Roger Davis
Univ. of Hawaii

___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list