Avoid running hard coded commands about uzbl HOT 6 OPEN

The problem is that any of the calls from gui.c will have to go through the commands API since it cannot call into the (future) uzbl thread from the gui thread. Same with variables.c depending on which thread the code in variables.c is meant to run in (I prefer the uzbl thread (which could call the functions directly), but maybe the gui thread is better?).

from uzbl.

The exact separation of the threads is not clear to me and maybe it something we would have to untangle when we get to that. But even then I think going through the commands API would be a bad idea as there's other mechanism for safely passing those "messages" across threads like gio g_task_run_in_thread.

And the big one in gui.c is js on page which I guess would be gui thread call in the end anyway?

from uzbl.

sry. g_task_run_in_thread was not the one I was thinking of. By I think I remember reading you could attach them to specific main loops

from uzbl.

js page in WebKit2 is a write to the extension's socket/pipe and a wait for the response. We can't block the GUI thread on that.

from uzbl.

hmm, ok. so page like it's implemented now doesn't actually work then? I forget what is just placeholders :)

To get the extension working as big task on it's own but I think you're right saying we should not be trying to block when communicating with it (Not even sure we could). In the gui we could get away with fire and forget for what we're doing now but in the commands we need a way of waiting for the response. Having a nice wrapper api for running javascript would help then to avoid bloating commands.c even more.

from uzbl.

Re variables it's very tempting to run it with the gui because of all the gobject properties we are setting. But I think conceptually it belongs in the uzbl thread so I think that's the correct choice even if it's a bit more work.

from uzbl.