Why? Having two socket connections make up one client can't really work
out, considering they're two different streams which can't be synchronized
between.


On Tue, Feb 3, 2015 at 12:05 AM, G Hasse <gor...@raditex.nu> wrote:

>  Den 2015-02-03 03:26, Jasper St. Pierre skrev:
>
>
>
> On Mon, Feb 2, 2015 at 5:07 PM, G Hasse <gor...@raditex.nu> wrote:
>
>>  Den 2015-02-02 22:57, Gulshan Singh skrev:
>>
>> 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.
>
> /gh
>
>
>    I've made a simplified example of this and asked it on StackOverflow:
>> http://stackoverflow.com/questions/28287520/cant-type-in-gtkentry-after-exiting-forked-window-manager
>>
>> Any help is appreciated.
>> On Fri Jan 30 2015 at 1:12:55 PM Gulshan Singh <gsingh2...@gmail.com>
>> wrote:
>>
>>> I'm working on a display manager here:
>>> https://github.com/gsingh93/display-manager/tree/tutorial (make sure
>>> you're on the `tutorial` branch, not `master`).
>>>
>>>  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.
>>>
>>>  Here are the relevant two functions:
>>>  ```
>>> static void* login_func(void *data) {
>>>     GtkWidget *widget = GTK_WIDGET(data);
>>>     const gchar *username = gtk_entry_get_text(user_text_field);
>>>     const gchar *password = gtk_entry_get_text(pass_text_field);
>>>
>>>      gdk_threads_add_idle(set_status_label_text, "Logging in...");
>>>     pid_t child_pid;
>>>     if (login(username, password, &child_pid)) {
>>>         gdk_threads_add_idle(hide_widget, widget);
>>>
>>>          // Wait for child process to finish (wait for logout)
>>>         int status;
>>>         waitpid(child_pid, &status, 0);
>>>         gdk_threads_add_idle(show_widget, widget);
>>>
>>>          gdk_threads_add_idle(set_status_label_text, "");
>>>
>>>          logout();
>>>     } else {
>>>         gdk_threads_add_idle(set_status_label_text, "Login error");
>>>     }
>>>     gdk_threads_add_idle(set_password_entry_text, "");
>>>
>>>      return NULL;
>>> }
>>>
>>>  static gboolean key_event(GtkWidget *widget, GdkEventKey *event) {
>>>     if (event->keyval == ENTER_KEY) {
>>>         pthread_create(&login_thread, NULL, login_func, (void*) widget);
>>>     } else if (event->keyval == ESC_KEY) {
>>>         gtk_main_quit();
>>>     }
>>>     return FALSE;
>>> }
>>>  ```
>>> 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.
>>>
>>> Any help would be appreciated.
>>>
>>
>>
>>  _______________________________________________
>> gtk-list mailing 
>> listgtk-list@gnome.orghttps://mail.gnome.org/mailman/listinfo/gtk-list
>>
>>
>>
>> _______________________________________________
>> gtk-list mailing list
>> gtk-list@gnome.org
>> https://mail.gnome.org/mailman/listinfo/gtk-list
>>
>>
>
>
> --
>   Jasper
>
>
>


-- 
  Jasper
_______________________________________________
gtk-list mailing list
gtk-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-list

Reply via email to