GSoC: Kobby Week 8
There has been a lot of development work this past week with Kobby. After posting about some design issues I was attempting to clear up before diving into code, Armin Burgmeier (Creator of infinote) pointed out that the term ’session’ in infinote is used to describe the editing ’session’ of a single document, unlike in Kate where it is used to describe a set of documents. Instead of deciding whether confuse either users or developers, I came up with a new naming scheme for the control dialogs which might actually better represent the actions being performed.
After getting the control dialogs worked out I went to connect the infinote functionality for an XmppConnection and ran into some issues with sigc++ and Qt. Luckilly this was a quick (albeit somewhat dirty) fix. It wasnt much longer before I got the connection functionality working, and ran into the next issue: Needing to use the Glib event system from my Qt app. Luckilly, libinfinity was designed to allow for the plugging in of any event system by implementing the Io interface the library provides to register sockets to be monitored and the handling callback functions (very cool). The only issue now is that as far as I can tell, the way this is implemented doesnt doesnt fit well with Glibmm’s design, meaning I may have to create the C GObject subclass for proxying the C++ wrapper by hand.
Comments
Great to hear you are making good progress.
Are there any screen shots you could post? We are all very keen to see what it will look like
I’m following eagerly your progress about Kobby and I’m really looking forward to see it integrated in our loved KDE. Keep up the good work
Does Qt4 use the Glib event loop by default anyway? I’m pretty sure they can interoperate without problems.
I did some research on integrating the two event loops, but decided it would be easier and a great deal cleaner to have Qt register the sockets to monitor given how easy implementing the Io interface is.
Expect screen shots soon.
If your Qt is built with Glib support, you don’t have to do anything at all to integrate the glib event loop. The reason being: Qt then uses the Glib event loop and so really nothing is being integrated, it just is.
Check out amarok/cmake/modules for a file that checks to see if Qt was compiled with Glib support or not. Amarok’s mp3tunes support needs it.
The default Io implementation in libinfinity uses poll() to monitor for events (which had me confused for a while why it wasn’t ‘just working’), likely because it needs only to watch for sockets and timeouts. I’m sure it would be extremely simple to modify this to use the Glib event loop instead, but I decided I may as well make Qt add the events if I am going to be creating a new implementation already. If there turns out to be any problems doing this later today ill likely just end up using Glib (and might be back asking for advice :)).
Thanks for the heads up!
The only issue now is that as far as I can tell, the way this is implemented doesnt doesnt fit well with Glibmm’s design, meaning I may have to create the C GObject subclass for proxying the C++ wrapper by hand.
I think this should work well enough with glibmm. Perhaps you want to have a look how other GObject interfaces are wrapped in gtkmm (such as GtkEditable, GtkCellLayout or GtkTreeModel). You will need to use _WRAP_VFUNC in gmmproc, and write the infinity_vfuncs.def by hand, though.
Write a Comment