Gregory Haynes' Weblog

The third and final beta for Kobby is now available for download, along with libqinfinity.  This version got a major facelift (as shown in the screenshot) which will hopefully make it much more attractive to first time users.  There were also several build system related bugs which popped up after the previous beta that have now been squashed.  Also, joining a document with an already used username (which i'm sure is common among testers) doesn't cause the end of the world.

 Screenshot:

Kobby is definately in need of some usability improvements before the 1.0 release, so if there are any suggestions (as always) don't hesitate to let them be known (kobby@groups.google.com).

 Enjoy!

Version 1.0 Beta 2 of Kobby and Libqinfinity are now available.  This beta features several build system fixes, among other things, which I hope will encourage more people to test the application.  Please don't hesitate to voice your opinion on the mailing list or by filing a bug report.

Aside from build system fixes, this beta uses the recently released Libinfinity 0.3 and is more stable than the previous release.

 Enjoy!

 P.S: I was also able to get the editor functioning in OS X (portability rocks!), but I'll save that for a later post.

About a year ago I began working on a collaborative text editor for KDE during GSoC 2008. Since then, a great deal has changed in the editor and even more has changed it's supporting libraries. Now, just in time for the GSoC 2009 acceptance, I think the editor has finally reached a point where a beta release is in order.

Kobby Version 1.0 Beta 1
http://github.com/greghaynes/kobby/downloads

Libqinfinity Version 1.0 Beta 1
http://github.com/greghaynes/libqinfinity/downloads

Obligatory Screenshot:


There are still a lot of features missing from the editor I would like to have before calling it usable for the general public (undo/redo support and infinote server control), but I am going to save those for a later version as I'm sure there are plenty of bugs to squash for this version.

As with any testing release, your input is greatly appreciated. Don't hesitate to send out an email to kobby AT groups DoT google DoT com or sign up to make modifications to the Kobby or Libqinfinity wiki sites.

Its been a while since I posted about my progress with Kobby, but the editor is definately making headway.  I actually managed to get basic editing working again, but ill blog about this another time when I feel the time is appropriate.

Like many people, I am a fan of del.icio.us, but lately I have also started using Konqueror as my web browser of choice.  Immediately after making this switch I noticed the lack of a del.icio.us  plugin similar to Firefox's, which has caused my bookmaring rates to take a nosedive.  Now, after a few days work, all is back to normal and I can bookmark sites for del.icio.us  from inside Konqueror using the new (and barely tested) konqueror del.icio.us  plugin.  Its very simple at the moment (allows only for adding bookmarks), but if youre at all like me this is a huge help.

The Sreenshot:

Enjoy!

For those who do not know, Libinfinity is an extensible collaborative editing library and is the core of the collaborative editor Gobby as well as my recent project to create a KDE counterpart: Kobby.  In order to use this library in a C++/Qt environment I created Libinfinitymm and Libqinfinitymm this past summer which wrap Libinfinity's GObjects, and add some code for use with the Qt event system.  While these libraries do what they need to, they are far heavier of a dependancy than they probably should be.  It would be a nightmare to port them to non *nix platforms in the future due to the use of code generation in Libinfinitymm.  As a result, when I began work on updating Libinfinitymm to work with the latest Libinfinity I decided to give writing a pure C++/Qt interface for the Libinfinity a try.  So far, things have turned out much better than expected, and I can say with almost absolute certainty that I will be switching Kobby to make use of this new Library in the next couple of days.

I have noticed interest recently from several projects pertaining to implementing Libinfinity in a Qt environment, and I highly suggest anyone considering doing this give Libqinfinity a look.  Unlike its predecessor, it has a very simplistic design and does not try to hide access to the Libinfinity interface underneath.  It also depends only on Libinfinity and Qt, and uses CMake for building so you should not lose out on portability by chosing to use it.  Although it is still being developed, all of the core features which are needed for interacting with an infinote server are complete.

Edit: It's been pointed out to me that the code generation used in Libinfinitymm (and Glibmm) is not a portability issue as I mentioned.

 

A commit was just posted to Kobby allowing users to join a note on an Infinote server and insert text.  There is still a VERY long way to go before the editor can actually be called 'usable' in any sense, but this is a huge milestone in the editor's development.

Over the past week, A lot of work went into getting Kobby 'over the hump' in a development sense.  At the start of the week the editor was capable of browsing Infinote servers, and not much more.  After spending a few days digging through the Gobby codebase to figure out some of the session joining quirks of Libinfinity, and writing an awesome testing application for Libinfinitymm, I was able to get basic session joining working (horray!).  From there, it wasnt much more work to get very basic text insertion functioning.  There is still a whole lot more to be done in this area, and in order for it to function properly I had to embed some GObject code in the Kobby editor itself (yuck).

Even with the long road ahead, expect to see lots of noticable functionality being added to the editor in the coming weeks now that the development focus has moved on to the GUI side of things.

Heres a screenshot as of tonight:

While visiting the website of one of my favorite software projects (lighttpd) I noticed they had migrated off of Trac, and onto a new project management system I had never heard of, Redmine. Recently, I have had the misfortune of needing to set up a Trac system. As a result of this experience I spent a while hunting for a better python based solution, but I never thought to consider ruby a competitor (learning what all the ruby hype is about is still on my to do list). Since then, I have set up several trac sites, for libinfinitiymm and kobby. Even so, I jumped at the opportunity to transfer these projects off of trac and onto Redmine, which doesn't bog my server down from a single page request (and actually is impressively fast), has a much cleaner interface, and provides much more control over the various administration tasks (such as control over project pages without having to edit ini files).

I don't mean to claim that trac is altogether a bad project, nor am I unappreciative of the time their developers have put into creating a very capable solution to project management (its not you, trac, its me.). I am more upset at the lack of python alternatives which, like django, show the power and ability for clean, flexible design that python developers seem to love. Nonetheless, here it is...

Goodbye Trac, Welcome Redmine: http://libinfinitymm.greghaynes.net

I decided to upgrade my remote server last month in hope of hosting/writing various web applications my managed hosting plan wouldn't allow for, so I broke down and got a dedicated server.  Originally, this worked out wonderfully and I was able to get a couple trac sites up for projects I have been working on.  Of course I decided to try and make use of all those pieces of software I wish were used more prevalently but aren't for some unknown reason, one of them being PostgreSQL.  Little did I realize, there are still large web applications to date which bind directly to a database server, one being Wordpress.  After looking around the worpress developer pages it seems like the developers are going with the approach of treating this like a 'feature' and not a bug, allowing them to sweep it under the rug rather than change aspects of their API.  After considering switching back to MySQL to be able to use my favorite blog system for all of a couple seconds, I decided to switch blog systems.  After many failed attempts at using various systems, I settled on Serendipity.  So far, I am very glad to have made this change, although it does seem to be a little 'rough around the edges' from a design perspective, it has run rock solid thus far and seems to have a lot of features missing from the more popular blog systems, like Wordpress.  Seeing as this is my first post from this new system, I guess we'll see how things go.

 

Also, if anyone is wondering where all the old comments went:  Although I was able to transfer the old posts, the program I was using wasnt capable enough to pull all the old comments, and im not up for pulling by hand at the moment. Sorry.

Its been a couple weeks since I last blogged about Kobby, and much has happened since then. In my last post I was having issues implementing a Qt socket event plugin for libinfinity, but thanks to some advice from Armin Burgmeier I was able to get this working very quickly. Since then, I have created and then added some features to the Connection Manager for Kobby to make it a little more user friendly (see below)



After getting this worked out I started on the next big step, browsing support in libinfinitymm, which not only includes traversing the directory tree of the Infinote server, but also creating and removing nodes. While looking through the infinote repository I noticed an awesome test application which creates a sort of interactive shell with the server using the client library, so I decided a great way to go about testing my C++ bindings for the Client Browser portion of libinfinity would be to replicate this test, which I just completed this afternoon. Hopefully, I will be able to implement a GUI for this by monday (meaning more screenshots) now that all the backend issues seem to be out of the way.

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.

After over a month of working on a C++ wrapper for the infinote libraries I was finally able to start development of the collaborative editing KTextEditor plugin this week. Its amazing what getting to see some of your development work in action, no matter how little, can do for inspiration. This week I plan on completing the session management interface and all its appendages (join session dialog, create session dialog, etc...) and hopefully will have functionality for users to connect to infinote servers by the weeks end. For those of you wondering what I'm referring to by session management: The infinote libraries allow for a set of documents, which comprise a session, to be hosted on a server and be collaboratively edited simultaneously. The Kobby session manager will allow users to join any number of sessions, keeping track of the documents in each editing session and opening/closing them when joining/leaving an infinote session. This brings up some design issues: Because a session could have a large number of documents, downloading and opening all the documents upon joining a session doesn't seem like a good idea. The options I see are (a) creating a document management interface to select documents to open off the infinote server or (b) having a lazy-opening implementation where documents on the server are added to the editing session, but are not pulled off the server until they are actually selected by the user (anyone know for sure if this is possible?). For now, I'm going to take the document manager interface route, but the lazy implementation sounds like a tempting project, maybe worthy of an option in the configuration interface.

Now that exams are over I have been able to spend the past week getting to really work on my GSOC project. In this time I created a c++ wrapper for libinfnity, which is the library my project will be using. The git repository can be found on Gitorious. Libinfinity has a very flexible object oriented design (the online docs are AWOL, so heres my copy), and should make the rest of my project pretty straightforward. In order to implement the collaborative editing component you need to just supply an object which implements InfTextBuffer (now Infinity::TextBuffer), so making a Kate Document implement this interface should be a breeze compared to the glib/gmmproc funk I've been dealing with the past week. For the rest of the week I have a fair amount of testing/code scrubbing to get done, but hopefully not long after i'll have some results to show off Now, back to coding.

This week I have been working on creating a C++ wrapper for libinfinity. The library uses a gobject API and is very extensible, so ditching it in favor of a non-glib library would be a real waste. Luckily, there are tools like gmmproc (an internal glibmm tool) which auto-generates the C++ classes to wrap gobject based libraries, given that you don't mind using the gtkmm source code as your documentation. Aside from having a fun time dissecting various libraries to figure out how to use gmmproc, the application is absolutely awesome. The tool reads from definition files (which can also be auto-generated from other glibmm/pygtk tools) which store data on the library's object names, their member functions, parameters, etc. and parses .hg and .ccg files which contain C++ code with macros (such as _WRAP_METHOD) into source files which are fed to the compiler. Some documentation can be found in the gtkmm book: http://www.gtkmm.org/docs/gtkmm-2.4/docs/tutorial/html/chapter-wrapping-c-libraries.html. After getting the hang of the tool usage, wrapping the library is a breeze, so a usable version will be on its way very soon.

For this year's Google Summer of Code I will be creating a KTextEditor plugin which allows for collaborative document editing. The proposal abstract can be found at http://code.google.com/soc/2008/kde/appinfo.html?csaid=9433F3446323A693.

The goal of this project is to bring in editor collaboration to KDE. This will allow users to share document trees and watch remote modifications made to them in real time. More so, in order to do this users will no longer have look outside of the editor or IDE. While I have had this project in mind it is amazing how many times I wish I had an editor with the ability to do this, mostly while sitting at a cafe trying to help out someone with a piece of code. This alone has me very excited to get this project working.

Luckily, a very powerful library for all the backend work exists, libinfinity (git://git.0x539.de/git/infinote.git). This library handles all the network communication and security, synchronization, and document hosting, while providing me with a nice TextBuffer interface to glue my plugin to. Writing this plugin will be the meat of my work this summer. Aside from that, I will be adding some nifty client-side features such as document re-visioning, and hopefully adding user access control to the library.

For now, I'm left trying to clear off my plate as much as possible before schools end so I can really devote a couple months to developing an open source project.

This week I hacked out an extremely trivial chat room client and server in java. The protocol is very close to xmpp, where all messages are in XML and contained within a message tag. The server model is pretty simple: it just rebroadcasts all messages recieved to all users. Eventually some sender confirmation can be added by making the server compare the 'from' attribute of the opening message tag with the socket it came from. The server is also single threaded and makes use of Java's nonblocking i/o facilities for all read/write operations. The code for the client and server are completely separate, so if nothing else the server can be useful for other projects.

chatroomapp.jar