GTK+ module #48
On Sun, 05 Jul 2015 17:01:09 -0700
I see. One option would be for the module to add a text UI command to pop up the menu under the cursor, and then this could be accessed from the terminal, or by using the cons module and a netcat wrapper, or with the httpd module and curl. Triggering the action using a command line argument would be nice but modules currently don't have access to argv. This could perhaps be a separate executable that allows for controlling a remote baresip using CLI arguments.
That's reasonable. Based on the "principle of least surprise" I would be wary of having the window close automatically based on heuristics, but in the case of an ended call it may be okay. Linphone closes a call's pane a few seconds after the call ends.
That sounds good. A list of recent URIs could be implemented in the module.
At first I was calling the module gtk_menu, but then I changed it to just gtk, thinking that it is enough trouble to get GTK+ working here that if someone wants a slightly different GTK+ UI, it could be added on to this one and have parts (de-)activated using config settings. Of course, if someone wants to create a drastically different GTK+ UI, then sure, one could be renamed.
If this module used a fifo, what commands would it accept?
4,5,6,7,8,9 can be done using the text UI. (although 6 doesn't necessarily update the module UI, that could be changed by modifying core) 3 is not that useful. 2 might be useful. 1 I've added a text command for. So there is not much here that would benefit from having another interface for, because it can mostly already be activated using the text UI. Of course another text UI module for a fifo interface might be useful.
I read in the GNOME developer pages that GTK+'s Win32 backend doesn't support making GTK+/GDK calls from multiple threads using the gdk_threads_enter()/gdk_threads_leave() lock as this module is now doing. If there are any Windows users here who are interested in this module and can confirm that it doesn't work, I would consider rewriting parts of it to use asynchronous queues instead of gdk_threads_enter()/gdk_threads_leave().
thank you Charles for this nice and clean patch, I have merge it into master with 1 additional
many people have asked for a GUI and you are the first person to submit some actual code
I suggest we use the new module "gtk" as a starting point, and can iterate from here.
Keep up the good work Charles! Keep them patches coming :)
Thanks for merging. That's cool that it works on OSX. Does the status icon show up in the menu bar?
I am able to build it with make STATIC=1. I'll work on getting the functions a common prefix.
I made some changes, in a gtk-safer branch, to only call GTK+/GDK functions in the GTK+ thread, in the hope that it would eliminate some bugs. I'm still getting some segfaults though. The changes might be useful for getting the module working on Win32 (or with GTK3, where the gdk thread locks are deprecated - but so are status icons) . The code is more complicated though because of more message passing indirection. So there are still some bugs in any case. I suspect one problem may be calling mem_deref being called in the GTK+ thread causing some corruption with baresip's datastructures. Or it could be some mistake I didn't notice. I'll do some more experimenting to try to figure it out.
I was able to resolve one bug, which was that quitting from GTK+ was causing a segfault. This is resolved by loading the module with "module", not "module_app". When the app requests to close, all modules are unloaded and then it seems that execution returns into the gtk module's unloaded code. I suspect this could be worked around by calling ua_stop_all from a re timer, but I didn't try that because I'm not sure what the advantage of using module_app would be (or why the same bug doesn't happen using "module").
What would you envision being in a window that would appear when the module is loaded? Would this be a preferences window for editing config and accounts? Or a contact list window?