fork()
in my GTK+ app?
This is not really a GTK+ problem, and the problem is not related to fork()
too. If the 'x io error' occurs then you probably use the exit()
function
in order to exit from the child process.
When GDK opens an X display, it creates a socket file descriptor. When you use
the exit()
function, you implicitly close all the open file descriptors,
and the underlying X library really doesn't like this.
The right function to use here is _exit()
.
Erik Mouw gave the following piece of code about the fork()/exit() problem (slightly modified)
int pid = fork();
if(pid==-1)
{
perror("fork");
exit(-1);
}
else if(pid==0) /* child */
{
retval=system("a command"); /* can use exec* functions here */
_exit(retval); /* notice _exit() instead of exit() */
}
else /* parent */
{
for(;;)
{
if(waitpid(pid, &status, WNOHANG) == pid)
{
waitpid(pid, &status, WUNTRACED); /* anti zombie code */
break;
}
}
return(WEXITSTATUS(status));
}
There is now a known problem in the GtkEntry widget. In the
gtk_entry_insert_text()
function, the following lines limit
the number of chars in the entry to 2047.
/* The algorithms here will work as long as, the text size (a
* multiple of 2), fits into a guint16 but we specify a shorter
* maximum length so that if the user pastes a very long text, there
* is not a long hang from the slow X_LOCALE functions. */
if (entry->text_max_length == 0)
max_length = 2047;
else
max_length = MIN (2047, entry->text_max_length);
From: Peter Mattis
The reason buttons don't move their child down and to the right when they are depressed is because I don't think that's what is happening visually. My view of buttons is that you are looking at them straight on. That is, the user interface lies in a plane and you're above it looking straight at it. When a button gets pressed it moves directly away from you. To be absolutely correct I guess the child should actually shrink a tiny amount. But I don't see why the child should shift down and to the left. Remember, the child is supposed to be attached to the buttons surface. Its not good for it to appear like the child is slipping on the surface of the button.On a more practical note, I did implement this at one point and determined it didn't look good and removed it.