Tag Archives: c#

New client languages for Qt WebChannel

At the company I’m working at, we’re employing Qt WebChannel for remote access to some of our software. Qt WebChannel was originally designed for interfacing with JavaScript clients, but it’s actually very well suited to interface with any kind of dynamic language.

We’ve created client libraries for a few important languages with as few dependencies as possible: pywebchannel (Python, no dependencies), webchannel.net (.NET/C#, depends on JSON.NET) and webchannel++ (header-only C++14, depends on Niels Lohmann’s JSON library).

Python and .NET are a pretty good match: Their dynamic language features make it possible to use remote methods and properties like they were native. Due to being completely statically typed, C++ makes the interface a little more clunky, although variadic templates help a lot to make it easier to use.

As with the original Qt WebChannel C++ classes, transports are completely user defined. When sensible, a default implementation of a transport is provided.

Long story short, here’s an example of how to use the Python client. It’s designed to talk with the chatserver example of the Qt WebChannel module over a WebSocket. It even supports the asyncio features of Python 3! Relevant excerpt without some of the boilerplate:

async def run(webchannel):
    # Wait for initialized
    await webchannel
    print("Connected.")

    chatserver = webchannel.objects["chatserver"]

    username = None

    async def login():
        nonlocal username
        username = input("Enter your name: ")
        return await chatserver.login(username)

    # Loop until we get a valid username
    while not await login():
        print("Username already taken. Please enter a new one.")

    # Keep the username alive
    chatserver.keepAlive.connect(lambda *args: chatserver.keepAliveResponse(username))

    # Connect to chat signals
    chatserver.newMessage.connect(print_newmessage)
    chatserver.userListChanged.connect(lambda *args: print_newusers(chatserver))

    # Read and send input
    while True:
        msg = await ainput()
        chatserver.sendMessage(username, msg)


print("Connecting...")
loop = asyncio.get_event_loop()
proto = loop.run_until_complete(websockets.client.connect(CHATSERVER_URL, create_protocol=QWebChannelWebSocketProtocol))
loop.run_until_complete(run(proto.webchannel))

pywebchannel can also be used without the async/await syntax and should also be compatible with Python 2.

I would also really like to push the code upstream, but I don’t know when I’ll have the time to spare. Then there’s also the question of how to build and deploy the libraries. Would the qtwebchannel module install to $PYTHONPREFIX? Would it depend on a C# compiler (for which support would have to be added to qmake)?

In any case, I think the client libraries can come in handy and expand the spectrum of application of Qt WebChannel.

qyotoassemblygen progress

Some time back I have started a tool called qyotoassemblygen [0], which will hopefully ease the generation of .NET/Mono bindings based on SMOKE libraries. It basically introspects a SMOKE library and generates a System.CodeDom tree from that information. The CodeDom can then be used to generate C# code and/or compile an assembly.
Although some parts were rather difficult and had to be rewritten again and again (like checking whether a method has to be marked “override” or “virtual”), I can now announce that it”s quite stable and generates all of the Qt assemblies just fine :). I”m currently working on getting the KDE assemblies to build, which is really just a matter of sorting out *Private classes.

By using plugins the tool is not bound to Qt-based bindings, so we could as well generate assemblies for other toolkits, like Wt (for which there is already a smoke lib, thanks to Richard :)). Plugins will also make it easy to add syntactic sugar like event support for Qyoto (which I hope I can implement for KDE SC 4.5).

If everything works as expected, we can hopefully drop kalyptus completely in the next release and reduce our maintenance cost considerably 🙂

[0] http://websvn.kde.org/trunk/playground/bindings/qyotoassemblygen

Qyoto on Windows!

Now that the new smokegenerator is in trunk and generating smoke on windows shouldn”t be a pain anymore, I thought that I could dig out my nearly unused Vista partition on my laptop and start porting Qyoto to Windows.
First thing I did was removing the preinstalled Vista and installing it again to get rid of all the preinstalled crap Dell thought I needed. Next was installing Visual C++ and C# (the Express editions are free as in beer and work ok – nothing in comparison to KDevelop4 though) and KDE 4.3. Thanks to all of the KDE Windows team – you make Windows much more bearable! I also installed msys – can”t live without a proper shell anymore.

Now came the actual porting: To support MS .NET and not only Mono, I needed to add support for csc.exe (the MS C# compiler) to the existing C# macros. As I recently discovered how to add support for a new language to cmake (which lacks documentation but is really easy once you understood it) I simply rewrote the C# macros as a new cmake language plugin. Compilation was pretty straight-forward, then.
But as was to be expected, the examples simply crashed upon start. Long story short: Some of them work now and this is how it looks:

Qt tutorial t5 with Qyoto

This is still really unstable and crashes every few minutes with an AccessViolationException. Have to figure out why it does that.. But first I have to do some other things, mainly porting the remaining kalyptus-generated smoke modules to the new smokegenerator. This shouldn”t take too long, so I think I can complete the Windows port soon 🙂 So stay tuned!

Update: The AccessViolationExceptions should be fixed now. If you want to try Qyoto on Windows and have problems getting it to compile or run, please send a mail to the kde-bindings mailinglist and include the complete error and backtrace. You can also search the mailing list archives since this topic came up quite often recently.