Today I spent some time configuring my Qt Creator based development environment to build both Parsek and the protocol library. While the protocol library is a standalone library, by doing this I will have more power to simultaneously debug both ends of the program. I also need to do this to resolve an issue of the client getting stuck during the login procedure. In addition, I am in the process of setting up a tp-server to run. Up until now I have been using the demo servers for testing. Creating my own server will now allow me to monitor the client’s activity from the server side. It is taking some time to get all this organized but it is all sorted out by tomorrow.

Another thing I am looking at is getting the protocol library to build in Windows along with Parsek. I believe maintaining both Windows and Linux compatible builds is important. There are a few problems in the socket and network code in the protocol library that are holding it back from properly compiling in Windows. I’ve already sorted out issues regarding the lack of <stdint.h> in Windows. I spoke with llnz about rewriting some of the socket code to make it compatible with Windows. It mostly involves changing header files and changing some of the function calls. If it ends up being feasible I will try to get this done quickly so future developers can use the protocol library on Windows.

This post is going to be an overview of the current status of Parsek. Let’s have a look at the objectives of this project.

Full Integration with Protocol Library
Current Status: Testing still required
Expected Completion: July 20th
Deliverable: Synchronized Clock

Integrating the KDE/Qt application with the new protocol library has proven to be difficult. The key part of this task involved integrating the Qt application’s event loop with the protocol library’s EventLoop class. The intended design of Parsek is to provide a fully asynchronous client to users. The combination of Boost libraries, network programming, and the Qt tookit has provided a series of challenges. There are still some problems in Parsek’s EventLoop that need to be fixed. I’m planning on building the protocol library in my application for debugging purposes to see where my application is getting stuck. Parsek’s EventLoop may be failing to handle some callbacks from the protocol. I expect it to still take another week before all these problems preventing proper client/server communication are fixed. The deliverable will be what I call the full function clock. The client’s clock will be synchronized with the server and update in real time. It will also receive EOT events. Parsek will also be able to display general game information from the server.

Starmap
Current Status: Only basic widget in place
Expected Completion: July 31st
Deliverable: Basic display of system

I believe once the issues with the server communication are fixed, the starmap will not take long to complete. Right now, as I cannot properly receive information from the server, it is impossible to test the starmap. I’m thinking of temporary testing the starmap by manually creating objects on the client side. That will be the alternative approach to testing the starmap if I cannot get the client to download the data. Qt will provide a lot of the functionality that will make this task easier to complete.

Message System
Current Status: Model in place, basic widget complete, testing required
Expected Completion: August 7th
Deliverable: Full display of game messages

The message system again needs some more time for testing. I believe it will functional quickly. I am still trying to design the message system to update in real time as messages are received. The plan is have a dynamic message display that can be easily sorted by the user.

Object System
Current Status: Not started
Expected Completion: August 14th
Deliverable: Display of system’s objects through starmap and separate tree-based display and information widget

This will by far be the most complicated task of the project. In fact, I can’t say I’m optimistic about having it complete by the end of the GSOC deadline. However, I am certain significant progress will be made in the Parsek client towards having a full featured object display system. The client will be able to the display the system’s object through the starmap and a separate searchable and filterable tree-based widget. In addition, a seperate widget will display information about selected objects. The widget will be configured for media support and displaying the object’s parameters. Another feature I am hoping to implement is the ability for the user to spawn additional object information widgets which would allow them to compare multiple objects simultaneously. Think of it like tabbed object browsing.

Order System
Current Status: Not started
Expected Completion: After GSOC

I don’t expect this part of the project to be completed before the final deadlines. I still plan on working on Parsek after GSOC is over so I hope to still add the order system. At this point I want to focus on the other tasks as I believe they are more important to Parsek.

General Overview
According to the initial plan, a lot of these tasks should already be complete. Clearly the project is behind the original schedule. Creating the eventloop class was difficult and provied interesting challenges. A lot of time was wasted I predict there are still more issues to work out. Despite the slow pace, I believe there is value in the work being done. Even if I fail to complete other tasks, integrating the Qt application with the protocol library’s eventloop and provide asynchronous real-time updating of game information will prove be valuable for future developers. It will serve as a demonstrable example of integrating the protocol library with a GUI toolkit. I plan to provide significant documentation to help future developers trying to complete similar tasks. I’m still confident that once issues with the client connectivity are resolved, many of the other tasks will be able to be accomplished quickly. Despite a significant setback of not including a working order system by the end of GSOC, the Parsek client should at least provide users the ability to watch games as a spectator. In addition, I believe working on simultaneous Linux+gcc and Windows+MSVC builds will prove to be valuable. This will ensure the code for Parsek and the protocol library is fully portable across both systems and allow future developers on either side of the fence to help out with project. Each system has its advantages when testing as well.

My work on Parsek has been challenging. The most important time spent on the project thus far has been overcoming various learning curves to understanding a complex client/server program. I have spent a lot of time getting familiar with the system so I plan to continue on working on Parsek and Thousand Parsec after GSOC is over. I have ideas for improving Parsek and providing great features like integration with a battleviewer or similar 3D system while remaining quick, responsive, and portable.

Read that little status bar! Finally connected!

Just fixed that bug. Yes, as you can read from the status bar, it is finally connected. (Yes I know there’s nothing else in the app, the widgets haven’t been loaded.)

Today I was able to finally get to the eventloop to properly compile. Thanks to caduel on the Qt Centre forums I was able to resolve some of the problems with the build. The QHash containers now correctly store the callback timers and their corresponding signals. There still might be some issues regarding the cleanup at the destructor but I think that the removal of the callback signal after it is called should take care of any problems here. There was also an issue with Boost complaining about exceptions in the case the callback signal is called when empty. This case shouldn’t occur either way but I was able to resolve this problem by adding #define BOOST_NO_EXCEPTIONS and an empty void boost::throw_exception(std::exception const & e) {} function. In the case (I can’t think of any need for it) that the exceptions would need to be handled, it can now be implemented.

So while the class was able to compile with all the new changes, the client still gets stuck when connecting on the call eventloop->listenForSocketRead(sock) in the protocol’s gamelayer class. I hope to try to resolve this issue tomorrow. I think it might just be the result of a silly bug that I’m trying to track down. Thankfully the debugger in Qt Creator is very helpful so I’m hoping this will be a quickly squashed problem. With the end of the midterm evaluation period coming up, I plan to have a report online detailed the next steps of the project and so forth online as soon as these last couple of issues with the eventloop are resolved.

Please see my thread on Qt Centre here. Also thanks again to caduel on the forums there – I would still be stuck where I was a week ago without him. There’s also some good info there about getting CMake, Qt, and Boost to all play ball together.

Well it is almost 2 in the morning and I’m sitting here in my underwear hacking away. Please excuse the crude one line post last night. I was just extremely frustrated and really didn’t feel like blogging about a damn thing! So today I tried to divide my work between the continual effort to get the Eventloop to work and some developing the models required for object/order/etc manipulation. I got familiar with the methods used in the protocol library to download and manipulate the data caches. As far as the Eventloop goes, well the screenshot below kinda sums it up.

Fuck Me! WTF! Bloody hell!

As you can see it still isn’t looking great. I think right now my problem is with my use of the QHash class to store the read and write sockets. Actually, I don’t even think that is it but rather the use of QHash to store the callback timers and callback signals. The compiler complains about using QHash to store a boost::signal. I guess using a Qt to container to store a boost object isn’t the smartest thing to do. I have to come up with a way to store the timers and signals in different containers but still have them be able to correctly identify each other. I’m going to find a way to work around this issue tomorrow. There’s also a couple of other errors that I’m trying to resolve. With the help of some people in the #qt channel and the Qt Centre Forum, I hope to have these issues resolved tomorrow.

Here is the header file.
Here is the cpp file.

This is just a quick check in to say one thing… come back tomorrow!

I broke my promise about daily blog posts. I guess I was never good at keeping a promise. I decided to go off the grid for a few days at my parent’s house so I could focus on work. This involved no internet and no cellphone for  a few days. There’s no wireless at my parent’s but I’m pretty sure the god awful default network manager in KDE wouldn’t have been able to connect anyway. So thankfully I was able to get some work done over the weekend, probably solely because of my lack of access to reddit. I wasn’t able to get the testing I wanted to do today done but I’m pretty sure proper connectivity and event handling in Parsek will soon be functional.

So there’s a couple of things to look forward to this week. I plan to have a build of Parsek with functional connectivity finally online. In addition, for GSOC midterm evaluation this week, I’ll be posting a report detailing what progress has been made so far, what stills needs to be done and how I plan to modify my existing plan to push this project forward through August. That will hopefully be online by the end of the week.

It’s a short one so that’s all for now.

Not much exciting happening today. I didn’t get much chance to do any programming. I had to run around and take care of a bunch of chores today. Life sucks when the girlfriend you’re living with goes away for a month. I did get a chance to conceptualize some ideas during my travel time thanks to my iPhone. I spent a lot of time poking around the Qt documentation trying to find examples and looking at code in the protocol library. Thanks to gitweb you can check out TP code right in your browser. So I’ve come with idea to wrap TpSocket in a QAbstractSocket and then use the QSocketNotifier class to monitor for incoming/outgoing data. I still need to work out the details but I hope to have this up by the end of weekend.

Today I spent quite a bit of time porting over the project to Windows. This indeed may sound shocking. It involved installing Qt and Boost and building the protocol library using mingw and msvc. I can’t say I was able to get very far with msvc. It’ll take a little bit of work before it compiles in Visual Studio. I also had to install KDE and the KDE libraries to get Parsek to build. It was actually really easy. You can find some cool stuff on the KDE on Windows project here and here. So why am I wasting time doing all this just so I can compile in Windows? Truth be told, I’m not really sure. I’m mostly curious to see if Visual Studio or QtCreator + msvc compiler will help. QtCreator can now support Microsoft’s debugger also. All this may sound like blasphemy but I’m hoping the least it could do is provide some insight into the problem. Besides, KDE software is now meant to be cross-platform.

While I was waiting around for installers to finish, I spent a lot of time looking at libtpproto-cpp code. While thinking about the changes I needed to make to get it compile under Windows, I also thought it might be a good idea to rewrite the Boost-based signals for event handling and callback routines using Qt signals. Basically, the idea would be to, as quickly as possible, overhaul the protocol library so it is more Qt friendly and doesn’t use Boost at all. This would avoid my difficulty in finding a solution to handle Boost signals in the Qt application (the error which was causing my compile failure yesterday). This is not to say there wouldn’t be a need for a light Boost-based protocol library so there could potentially be two versions or a single version that can be configured to use only Boost or Qt, not both. Maybe this sounds like a another lousy idea but I figure it would at least help get a better understanding of the protocol library and help in my ultimate goal of handling the TPSocket manipulation and event handling using Qt classes better integrated with the GUI. I’ll try to think this one over and see if it’s up for discussion. Rewriting a library using a different framework and then trying to compile it under Linux and Windows.. hopefully I’ll only make it a short setback.

I’m about to close up shop for the night so it’s time to check in here. I spent the day again working on integrating the libtpproto-cpp protocol’s event loop. I’m working on two approaches at the same time. One is to rewrite the TPSocket* handler using Qt and create an eventloop using QAbstractEventDispatcher and QSocketNotifier classes. This approach is a little bit outside my knowledge of Qt but I’m trying to piece it together. The second approach I’m trying is to hack a modified version of the SimpleEventLoop class from the protocol into the Qt client. This has not yet been succesful either. Compiling Parsek fails where the eventloop class reads a callback signal like this (*timer.signal)(); where timer.signal is boost::signal that is connected to the callback. Boost creates an error like this:

parsekeventloop.cpp:(.text._ZNK5boost9function0IvEclEv[boost::function0::operator()() const]+0×27): undefined reference to `boost::throw_exception(std::exception const&)’ .

The good news is that I have narrowed the error down to that point and I’m going to continue working on both approaches to the fixing the event loop. In between hacking on the event loop, I spent sometime working on the implementation of this status listener class.

class ParsekStatusListener : public QObject, public TPProto::GameStatusListener
{
Q_OBJECT
public:
void connected();
void disconnected();
bool redirected(const std::basic_string< char >&)
void accountCreated(bool);
void loggedIn(bool);
void eotStarted();
void eotEnded();
void timeToEot(uint32_t);

public Q_SIGNALS:
void signalConnected();
void signalDisconnected();
void signalAccountCreated(bool);
void signalLoggedIn(bool);
void signalEotStarted();
void signalEotEnded();
void signalTimeToEot(quint32);
};

Tomorrow I hope to maybe get a lid on this event loop “black magic” as a friend called it and continue working on getting Parsek fully connected.