I strongly advice designing an application in this
way. Every window in an application should be a
separate process. Between processes you should
find a good protocol. This protocol should be
transported over some message buss. (example: www.spread.org)
This will break under Wayland, which has a strong tie
for one socket connection = one client. Threads can be
used successfully, but they require care and expertise.
The recommended approach is to use worker threads which
share as little as possible with the main thread.
Then Wayland is totaly broken... (In my opinion).
Regardless, this really should be using more
event-based programming than threads for this sort of
communication.
When a user successfully logs in, I fork
a new process that starts the window manager
and wait for that process to terminate.
Since this is a long running operation, I
need to do this in a new thread so I don't
block the GTK thread.
However, I need to do various GTK
operations during this long running thread,
such as updating label text or hiding the
window. I've read online that I should be
using `gdk_threads_add_idle` to do this.
The problem is when the process I forked
ends (the fork happens in the `login`
function, I see my display manager screen
again but I can no longer type in any of the
text boxes.
If there isn't anything obvious wrong in
the above code, I'd appreciate it if someone
could run the display manager and take a
look at what's wrong. You can run it with
Xephyr. I start Xephyr with the command
`Xephyr -ac -br -noreset -screen 800x600 :2
&` and then I run `DISPLAY=:2
./display-manager`. Note that when
you log in, it executes the contents of
~/.xinitrc. In my case, I have that set to
`exec awesome`, and everything works fine.