I'd much rather have an awesome FE for linux than a crappy one for cross-compatibility sake.
Don't use Qt! Please!!
Over the past 2 years developing nghost, I've learned a lot about a number of different things. One thing I've noticed is how technical issues can really effect your end goal.
As many of you know, nGhost2 runs big. It consumes a lot of memory because it stores all graphics in system memory instead of using your video memory. This is a technical limitation of using SDL's software rendering for the underlying graphics. Also, because it's in software rendering land, eye-candy effects are not possible, or would run terribly slow, even on new hardware.
To add to that, nGhost2 development is slow. We've basically created our own framework for building nGhost (hence libnghost). We've done many things like thread and process management, database, and GUI from scratch. Every time we want to add a new feature, many times we have to write the underlying infrastructure code to support the feature. This adds to the development time, and discourages new developers (they have to learn yet another system).
This has led me to take a look at well established toolkits and frameworks. First we looked at clutter. Clutter allows for beautiful eyecandy and effects. It's OpenGL accelerated, low footprint, and has gstreamer bindings for media playback. However, it lacks nice things like thread and process management, dbus controls, and we'd still have to write our own GUI elements for things like listboxes, input boxes, etc. It's also written in C, so in order to use it with code we've already written, specifically our database engine, we'd have to wrap many things in c++ code. Not fun at all.
Compare that with a toolkit like Qt. Qt has the ability to use an OpenGL canvas and embed Qt widgets inside. Qt has thread and process management features. Qt is c++. Qt has nice DBus bindings, phonon media backend, xml parsers, etc.
I believe that we can achieve the same eyecandy goodness as clutter and gain accelerate development by using Qt in nGhost3. It likely would run faster and use less memory than nGhost2. It would save us time not having to develop much infrastructure code. Features could be developed fast, and I believe it would interest more developers to use and develop nGhost because it's much easier to develop Qt than to learn yet another system in clutter+ng3 tools.
I'd like to hear what the community thinks of the idea. I want to start development on this soon. So feedback is key.
If we do use Qt for ng3, some may wonder: "Since Qt is cross platform, will nGhost be cross-platform as well?" The answer to this I will answer now:
In ng3 we want to extensively use niceties like DBus, inotify, etc which don't exist in the windows/mac-osx worlds. There are ways to disable these, if they were developed as plugins to make cross-platformness possible. However, unless there is a huge demand from the community for nGhost on platformX, we will develop ng3 only for Linux. If you feel differently, make your voice heard now.
Former author of LinuxICE, nghost.
Current author of nobdy.
aiming for cross-platform will mean too many restrictions. In the end the user should not be concerned what OS is under the hood as long as the FrontEnd provides everything the user could need.
... and yet at the same time, as you yourself stated, these functions can be placed in plugins to make it cross platform and not lose any functionality. The trick is in the implementation - how do we make the plugin system robust enough to "bolt on" any given behavior.
If the question is whether to make it cross-platform at the price of cool functionality, then the answer is simply don't make it cross-platform. If the question changes to whether to make it cross-platform by moving such functionality (inotify, dbus, etc) into plugins and sacrifice nothing... then the answer is equally simple - make it cross-platform.
I had looked at this question myself when I wrote up evilcpc, and decided that I would make the base framework do very little... but I would write "plugin packages" that would operate on that framework to do all the real work. We're probably looking for something in-between that and what we've got now.
Here are my thoughts after reading the title AND thread-
I think the title is inaccurate.
It seems to me that the real focus of the question is this:
"Should ng3 use QT to make development easier for those who develop the application?"
I may be presumptuous, but reading the first post (I am NOT a developer) I get the impression that using QT would make the act of creating nghost far easier, once those who do the real work get used to it. This is likely to make it work better, get bugs fixed faster and perhaps even increase functionality.
And these are all GOOD things.
And they seem to be the first things mentioned in the first post, and have a lot more typing dedicated to the subject.
Actually becoming cross-platform takes only a few lines and the intent to remain linux-only is stated at the end.
So I did not vote.
I have no interest in nghost being cross-platform: I do not and will not use Windows on my computers.
But in truth, I am not using nghost right now either: I also don't use Ubuntu, and getting nghost to work properly in Debian or Mepis linux has always been a bit of a problem. The use of QT might help with that, which benefits me personally, so there is my personal self-interest showing up.
I would think that if a standard framework and/or open code exists that can make the lives of the nghost devs easier, linux users would have a better, more stable and more frequently updated frontend for their car computers.
Sounds like win/win to me.
We will be moving forward with Qt and Clutter for nGhost3. We will also be using the multi-process architecture approach where plugins are developed as plugins but run as a separate process for speed, security, and stability of the system. It also allows the system to utilize the goodnesses from window managers like compiz.
Bookmark this thread for updates on development of nGhost3:
Oh, and sadly (for some), nGhost3 will not be cross-platform. The multi-process IPC (DBus) doesn't run on windows afaik.
Former author of LinuxICE, nghost.
Current author of nobdy.