Skip to content
July 24, 2014 / dantti

Cutelyst 0.3.0 is now C10K ready!

Release early, release often has never been my strength especially since I don’t do a fair scheduling of all the projects I’m involved…

So since I was in need to better polish Cutelyst I took more time on it, and the result is great, around 100% speed up and a few new features added.

Cutelyst uWSGI plugin now has support for –thread, which will create a QThread to process a request, however I strongly discourage its usage in Cutelyst, the performance is ~7% inferior and a crash in your code will break other requests, and as of now ASYNC mode is not supported in threaded mode due to a limitation in uWSGI request queue.

Thanks to valgrind I managed to make a hello world application from 5K request per second on 0.2.0 to 10K req/s on 0.3.0 on an Intel Core2Duo 2.4Ghz (or 44K req/s on an AMD Phenom II 965 x4 3.4Ghz), however if you enable Grantlee templating you get around 600 req/s so if I happen to have time I will be looking into improving its performance.

Response::body() is now a QIODevice so you can set a QFile* of something else and have Cutelyst to send it back.

Now points to a gitorious Wiki which is slowly getting populated, and API is available as

The 0.3.0 tarball can be downloaded here

Have fun :)

July 5, 2014 / dantti

Cutelyst 0.2.0 is out!

Five months ago I announced the very first release of Cutelyst, a web framework powered by Qt 5. Time passes and I started shaping my real world applications written with it, I should probably release a newer version earlier but it’s not very nice to keep releasing API that changes a lot, however next version (0.3.0) will still contains API changes. What changed from 0.1.0 to 0.2.0:

  • I have setup a documentation website
  • I started a WordPress like blog written with Cutelyst this right now is a nice example app, if you like it please help :)
  • Changed the API to expose the forked behavior thus being able to setup database connection in each new process avoiding a mess
  • UWSGI got a patch to deal with workers that don’t want to work, in other words when something on post-fork fails like reaching the dababase connection limit the worker can exit and won’t be restarted.
  • A bunch of bugfixed of course
  • Make use of categorized logging (ie qCDebug)
  • Allow for UWSGI to restart the application as soon as your application .so file changes, this greatly improve development speed :)
  • Encapsulated the post body into a QIODevice subclass on UWSGI engine this means a QFile is –post-buffering limit is reached, or a custom IODevice that deals with the request memory buffer
  • A parser to get uploaded content “multipart/form-data” which is fast and can work with lots of data

For the next version I’ll try to get a properQt loop integration. Download here Have fun!

May 5, 2014 / dantti

Apper 0.9.0 released

This new release doesn’t bring new features but it’s an important one since it supports PackageKit 0.9.x API, also this is the first release which uses the first 100% async calls on PackageKit-Qt.

Making Pk-Qt sync-free wasn’t so complicated but since I had to rethink the API the client code of Apper also needed to be adapted, I must say that I was lazy sometimes and just created a QEventLoop in Apper to wait for the reply… and this basically means that there will be new bugs in Apper, and hopefully some will be fixed.

It’s interesting that using DBus doesn’t means the code talking to it is async, the proxy classes generated by qdbus2cpp do a blocking call everytime you ask for a property, so you have to avoid it and do a GetProperties call which returns to a callback, although this worked well for PackageKitQt I failed to do the same for libnm-qt, and that is because it’s nearly impossible to make it somehow reliable due to NetworkManager itself not using gdbus, so you can’t have a reliable snapshot of it, unless you do an introspection call which is also insane, so I prefer to wait for when they switch to gdbus :P

Apper 0.9.0 depends on Qt4, KDE4 libs and PackageKitQt 0.9.2.

I’m not giving it much attention lately since I’m slowly building Apper on Qt5 which will be using QtQuick2, as my time is short supporting this old version is mainly to make packagers happy :)

April 19, 2014 / dantti

Apper 0.8.2 reeased!


this is just a quick bug fix release, the last one depending on PackageKit 0.8 series, it doesn’t have new features apart from having some fixed support for appstream 0.6.

For the next 0.8.3 version PackageKit 0.9 will be required.

For more information you can look at the git logs.

Have fun :)

February 11, 2014 / dantti

Cutelyst the Qt/C++ Web Framework just got it’s first version released!

Three months ago Custelyst was started,

it was somehow a proof of concept to see if I could build something that could be used in the real world, but the more I progressed on getting all the pieces together the happier with the overall result I got. And the initial result is here today!

I have made a few benchmarks comparing some simple pages delivery using Django (python) and Perl Catalyst, and overall the time to first byte was around 3 times faster than both, comparing RAM usage it was like 2MB vs 50MB from the Perl version and 20MB of the Python one, the CPU time was also much smaller if compared to both which probably means it could handle more requests, but this isn’t a completely fair benchmark (as always) because there are several other things to measure…

Below I’ll try to clarify some doubts raised from my last post and what makes this new Web Framework unique:

But there is already QDjango and Tufao…

I didn’t know about these ones when I first started Cutelyst, but after taking a look at them, both misses a templating system (or integration with one), I also didn’t like the way one would register actions to be dispatched, IMO the way it’s done in Cutelyst is easier and nicer. And they doesn’t count with WSGI integration, they have their own HTTP parser/server. I also didn’t like looking at code :P

Why not DJango or any other well established framework out there?….

Apart from QDjango and Tufao there are no other (AFAIK) Qt based frameworks, there are indeed some C++ ones that I knew before but I didn’t like the way of doing things there, in fact when I started with Perl Catalyst I really liked how it was written. So in short I don’t know well enough other languages and I have no plans wasting my time learning other languages, I’d rather try to master at least one (although I know I’m far from it).

What’s in this release?

  • Glad you asked (duh!)
  • Production ready integration with uWSGI, meaning Cutelyst has a uWSGI plugin that will load your application (which will also be a plugin), and thus thanks to uWSGI it will have out of the box support for FastCGI, HTTP(s), uWSGI (protocol) and probably some other.
  • ClearSilver templates integration, this templating system is written in C and it’s amazingly fast, but it’s also incredible limited to what you can do in the view.
  • Grantlee (Django) templates integration, it’s used in KDE PIM to allow for easy templating of HTML, it’s slower than ClearSilver but offers much more fexibilities on your views, and since it’s also written in Qt the introspection comes for free.
  • Complete Path dispatcher, which means if you Port a Perl Catalyst Application that was using Path actions it will work as expected. This dispatcher matches an url to a Q_INVOKABLE method depending on it’s signature, The Catalyst Chained dispatcher is not implemented yet.
  • Session plugin, easy to use way of persisting data across requests, right now it’s done with a QSettings file, but integration with Redis and MongoDB are planned.
  • Authentication plugin, allowing you to authenticate your users using different Realms/stores, currently a StoreMinimal is implemented which can be used mostly for testing purposes (ie on the code you add your users)
  • StaticSimple plugin, allows for serving static content reducing the complexity of serving static content while developing your app.

If you are concerned about API/ABI stability I don’t promise it just right now it’s almost stable, probably 0.2 or 0.3 versions will have a promised stable API.

And yes, I have just put it on production is running it right now (but the site is user restricted).

My plans now is to setup with docs and examples, as well as writing a web blog, bug tracker and wiki based on it.

Have fun!


November 1, 2013 / dantti

Cutelyst a Qt web framework

Do you recall that “Qt everywhere” branding?

Well that’s one of the things I really like in Qt, being able to deploy everywhere with minimal to zero changes in source code. But sometimes your application needs a web interface some sort of web backend or web admin, and when that happens it breaks that slogan (AFAIK)…

I got in contact with web languages (not HTML) only when at university, ColdFusion and PHP where the first ones, and while PHP was sort of cool because it has a syntax close to C, I never really like it. I’m not a web designer nor know how to do pretty websites, but in today’s world building web apps is inevitable.

So years ago I learned about RubyOnRails, and people where talking all the good stuff about it, it’s was the framework of the hype, although I knew Ruby wasn’t the fastest scripted language my need didn’t demand that, so I got a book, read it cover to cover and happily started my web app, a week latter I got a complex problem with an apparently impossible solution. It seemed that RoR makes easy things stupidly easy and complex things impossible…

The I met Catalyst a Perl framework, got exited again, but I knew nothing about Perl so I read more 3 books and was started to love the language, I still do, but last weekend when trying to resurrect and old Catalyst application I got an error which I had no idea how to fix, on IRC I was told the problem could be that I mixed CPAN packages with distro packages, not very convinced I realized the bigger problem I was actually facing, I’m not fluent in Perl, well no matter how many books you read about a language you only get fluency in it after speaking it almost everyday, this applies to computing languages too of course.

So if 99% of the time (or less now with QML) I’m programming C++ it means that I know a lot more about how to debug it than with Perl, so Cutelyst! Writting web apps in Qt/C++ will be much more efficient to me and hopefully to you too.

I share lots of the Catalyst API and design ideas, tho the implementation is of course completely different. Also for the sake of HTML templating I plan to create a Grantlee View plugin.

You can take a look at the proof of concept:

Have fun.

August 6, 2013 / dantti

Thoughts on Quick2

Some days ago I was listening the radio and a famous Brazilian comedian was saying how stupid it is to express you thoughts about things because latter you probably regret what you said, and realize how dumb you are… although I partly agree with him I decided to share this as maybe someone is facing the same problems I’m facing.

I don’t want to spread FUD, so if my tests/conclusion or everything I said is wrong please explain and I’ll update or drop the text entirely :P

Lately I’ve been working a lot on an Qt5/Quick2 application and I decided to share some thoughts about this new piece of tech. The application that I’m working on basically has to index >16k of videos and music files, and show their covers so the user can choose what to listen/see, it’s an app for jukebox machines. Xapian rocks!

First I need to say that I really like Quick2, the name is right about how fast can you write your app,  on Quick2 we have some very cool graphics effects like blur, shadows and others, and those are quite interesting for this kind of app. I can blur the background, draw shadows on the CD covers and so on. The multimedia part is also very easy to use, so how to play a video or music file is not something you worry about (tho I need to find a way to play files that I encrypt stupid recorders).

Most people also probably heard about Scene Graph which is the new rendering of QML 2 which uses OpenGL (EGL iirc), this brings many improvements on performance and quality, and expands the QML2 possibilities.

However maybe you are considering it for your own projects, the QWidgets vs QtQuick is something many developers don’t know the answer yet. To me it’s now a bit more clear on what to choose.

Every now and then I listen people saying that OSX is good because it’s software made for the hardware, and while in parts I agree with that the same is valid for Quick2. Martin recently wrote an interesting blog about “what makes a lightweight desktop lightweight“, which describes the problem of properly describing a technology.

My point is that with Quick2 we need to set a barrier between legacy and supported hardware, to me this is quite complicated because you can have some very powerful CPUs from like 8yo coupled with very slow GPU, and brand new hardware with the opposite configuration, Raspberry PI for example has a rather slow CPU with a great GPU.

So while QWidgets/Quick1 performed quite well on those old machines Quick2 doesn’t. To exemplify I have a computer to test my jukebox application that has a crap VIA graphics with a 3.2 intel D CPU. When I went to deploy/test my super cool and animated application there, I almost cried, after removing blur/shadow/transparency effects I could get a maximun of 10fps on fullscreen with 1024×768. Toggling the composite switch didn’t make any difference (nice work KWin team), and using other Window Managers also didin’t improve the poor experience.

Aaron give me a hint about llvmpipe, which is something I had heard but never truly understand what it was, basically llvmpipe is a software render for this exactly case where the GPU can’t handle the OpenGL instructions, but after some investigation it seems all new distros have it to render on these poor GPUs. Now that I knew about it I went to look at CPU usage and it was pretty high and leaking…

Before you jump on the wrong conclusion that Quick2 is bad please note that for any hardware capable of OpenGL it’s an excellent choice because it can offload the rendering stuff from your CPU to the GPU. And this is where we have a new era of “lightweight” of desktops as they use less CPU.

Something that does bother me is that Plasma 2 will need newer hardware specs, I won’t be able to run KDE SC 5 (or whatever it will be called) on such hardware, I went on thinking that it would be nice to have something like lxde-qt as our QWidget shell and still use Qt5 with our KDE stuff. On the long run I believe we won’t be able to share much of the GUI apps as Quick2 will probably become more and more common, not to mention it’s a nicer way of developing GUI stuff.

And if you wonder what I’m going to do, I not totally sure, but right now I have 2 user interfaces on the same binary, one QWidget based and another Quick2. I thought about going back to Quick1/Qt4, but then I wouldn’t have the cool Quick2 stuff. Thanks to the model based approach I’m sharing most code between the two interfaces. And yes, since QWidget on Qt5 still uses raster rendering it provides a much more responsive experience for the application.

I hope this gives you some clarity if you might be targeting hardware like that, in the future I hope to be able to deploy on Raspberry PIs but the lack of RTC doesn’t make it an option right now.

If you know some magic way to improve FPS please let me know, I’d love to have a single GUI :D


Get every new post delivered to your Inbox.