Post a Comment
RE: Comment by Praxis
100% wrong info, disregard. "
Enlighten us then. Are you denying that Maemo became Meego and that Maemo was entirely based on GTK+? Are you then saying that rather than using the Qtopia style API (which is to Qt as Hildon was to GTL+) there is something "else"?
Honestly, I lost interest in Nokia when they screwed over the developers by excluding N800 from Freemantle, when the differences between the N800 and N810 were pretty minimal.
Maemo is a GNU/Linux system. Of course you need GNU/Linux if you want to make apps for Maemo. This has nothing to do with Apple-style locking. You can run GNU/linux in Virtualbox on MacOS X and on Windows with the Nokia-provided Ubuntu Image. It includes scratchbox to emulate ARM processor. Think of the virtual machine as your phone simulator. If you are going to develop for the iPhone you are going to install a phone simulator to test your app. For Maemo you use Virtualbox with the nokia provided image that includes scratchbox, Xephyr and everything you need to test/compile. Talking about the Virtual machine, you can replace it with your own system if you are already running GNU/linux on your machine. This is perfectly logical. You can also develop your app straight on the device since it is running its own OS (no shit!)
You can still use your own OS and whatever tool you want to develop (eclipse, notepad, qtcreator, whatever).
This nothing to do with Apple's XCode/MacOS X lockin, get you facts straight.
Why? An emulator is an emulator. Platform lock in is what Microsoft and Apple do, surely? There was no reason that the tools could not have been ported - Scratchbox was cross platform IIRC. I was a developer, not a platform engineer - I wasn't interested in spending months porting their environment to another platform, but it should really have not been made so hard.
Seemed an awful lot like it to me.
I'm sorry, but that is just a pathetic excuse. I did this. Developing code for an emulated platform under an emulated platform is absolutely INSANE!!! It was SLOW. It was generally behind the latest firmware builds. I'm not a Linux user, it was alien and extremely uncomfortable,
Not back in the Chinook days it didn't. Also, the images did NOT support Virtual box until fairly recently. They were all based on VMWare. There's not "free" version of VMWare for Mac. The fact that they support VirtualBox now is good, but too late. VirtualBox would not run VMWare images out of the box when I was developing for Maemo and even when converted, the XServer wasn't configured. Great. I need to learn about XOrg to use a convoluted build system that supports a second XServer (xephr) to emulate another System? Ah, no.
So - we tried native. It was an ABSOLUTE MESS!! We wanted to use something simple, so off we went to install a LINUX distro. Quickly we discovered that to do a simple install we'd need to use pre built packages. But as Maemo SDK only supported one package system... it needed to be Debian, so Ubuntu seemed reasonable. FAIL. We were not LINUX sysadmins, we did not need to know how to configure a foreign system to run a set of command line tools that function identically as said same tools might under Windows or Mac OS X. I think it was Diabolo by the time I actually managed to get the SDK to install and compile code. We then had a requirement to support Mono... so we attempted to move to OpenSUSE because we needed the latest Mono packages - and that was an absolute ballache. IIRC, we were required to compile from source. I essentially got a reprieve as the N800 was end of lifed and the work we required was deemed commercially undesirable. At this point I still balk at the install procedure. I can install VisualStudio in about 10 clicks, and it will let me develop for WinMobile with no extra effort. XCode is about the same for iPhone. Selling my soul to Linus Torvolds and spending days on end getting the environment set up is not my idea of fun. Even on a Debian based system, it was not trivial or straight forward to configure unless you REALLY know what you are doing.
Sure you can. I did. I also used to develop directly on a Zaurus Sl5500. It's almost as painful as developing in a VM. Also, even with a host mode USB (OTG) adapter and a USB keyboard, it was still completely impractical.
Bullshit. You can code Mac and iPhone apps in any of those environments too. You can even run Mac OS X in emulation on Windows. All things are possible. However, Nokia STILL made it a completely unpleasant experience. It was *as good as* a LINUX lock in, because I was still required to use LINUX and I really didn't want to. The Device OS may be Linux, but that has absolutely no significance when cross compiling from, say Windows and targeting an ARM LINUX based target.
Why? An emulator is an emulator. Platform lock in is what Microsoft and Apple do, surely? There was no reason that the tools could not have been ported - Scratchbox was cross platform IIRC. I was a developer, not a platform engineer - I wasn't interested in spending months porting their environment to another platform, but it should really have not been made so hard.
scratchbox is just the ARM emulator. Maemo runs X11, gtk and all the tools that are emulated by VirtualBox. Porting scratchbox alone woult not help. If you don't want to spend months learning how Maemo works you will have a hard time developing for it.
Seemed an awful lot like it to me.
No it is definitely not the same thing.
I'm sorry, but that is just a pathetic excuse. I did this. Developing code for an emulated platform under an emulated platform is absolutely INSANE!!! It was SLOW. It was generally behind the latest firmware builds. I'm not a Linux user, it was alien and extremely uncomfortable,
All emulators are slower than the device. With Maemo you can tet your application on X86 with debian because it is the same system. You can't do that on iOS.
Not back in the Chinook days it didn't. Also, the images did NOT support Virtual box until fairly recently. They were all based on VMWare. There's not "free" version of VMWare for Mac. The fact that they support VirtualBox now is good, but too late. VirtualBox would not run VMWare images out of the box when I was developing for Maemo and even when converted, the XServer wasn't configured. Great. I need to learn about XOrg to use a convoluted build system that supports a second XServer (xephr) to emulate another System? Ah, no.
So - we tried native. It was an ABSOLUTE MESS!! We wanted to use something simple, so off we went to install a LINUX distro. Quickly we discovered that to do a simple install we'd need to use pre built packages. But as Maemo SDK only supported one package system... it needed to be Debian, so Ubuntu seemed reasonable. FAIL. We were not LINUX sysadmins, we did not need to know how to configure a foreign system to run a set of command line tools that function identically as said same tools might under Windows or Mac OS X. I think it was Diabolo by the time I actually managed to get the SDK to install and compile code. We then had a requirement to support Mono... so we attempted to move to OpenSUSE because we needed the latest Mono packages - and that was an absolute ballache. IIRC, we were required to compile from source. I essentially got a reprieve as the N800 was end of lifed and the work we required was deemed commercially undesirable. At this point I still balk at the install procedure. I can install VisualStudio in about 10 clicks, and it will let me develop for WinMobile with no extra effort. XCode is about the same for iPhone. Selling my soul to Linus Torvolds and spending days on end getting the environment set up is not my idea of fun. Even on a Debian based system, it was not trivial or straight forward to configure unless you REALLY know what you are doing.
Maemo is pretty much debian. If you want to develop for debian and test on debian you need debian. It's that simple. All other mobile platforms provide an emulator. Maemo runs X11, gtk and stuff. You need that to develop for Maemo. It's perfectly logical.
Bullshit. You can code Mac and iPhone apps in any of those environments too. You can even run Mac OS X in emulation on Windows. All things are possible. However, Nokia STILL made it a completely unpleasant experience. It was *as good as* a LINUX lock in, because I was still required to use LINUX and I really didn't want to. The Device OS may be Linux, but that has absolutely no significance when cross compiling from, say Windows and targeting an ARM LINUX based target.
Android has Android lockin, iOS has iOS lockin. Running applications on Maemo requires Maemo. It's just simple logic.
The new thing is that Qt Quick is the unifying component on UI level. Talking of "Qt" obfuscates that fact.
Mobile developers won't need to deal with MeeGo Touch or Orbit (or the desktop QWidgets).
Biggest significance for Linux devopers:
- You will write your app in Qt Quick instead of MeeGo Touch
For Symbian developers:
- Current apps (that work on Symbian^3) will continue to work on future phones. No need to rewrite your legacy Avkon app in Qt if you don't want to.
- No need to fear S^4 bogeyman that makes your S^3 phone obsolete. You *will* get the new apps (e.g. current N8 will run them just fine).
- For new development, you should use Qt Quick.
All? Really?
Here is a list of 177 desktop applications, some of them quite notable:
http://en.wikipedia.org/wiki/Category:Software_that_uses_Qt
... which suggests that your counting might be slightly off.
All? Really?
Don't act like that. You know perfectly well that he rather meant all the apps he considers important to himself, not what are important for some other party.
Hell, even I could only find one single application on that list that I use: Skype. Kopete is nice but it is so totally out-of-place on GNOME desktop that I just rather use Pidgin instead. So yeah, for _my_ tastes and needs all the best applications indeed are GTK+.
Pidgin is so totally out of place of a KDE desktop that I'd rather use Kopete.
I'd rather use Amarok than Banshee.
I'd rather use KDE PIM than Evolution.
I'd rather ... but as you say, it depends on the desktop you use. I wouldn't debate that.
My actual point is that there are actually very few gtk-based applications for which one cannot get a Qt-based application that is just as good.
Openoffice and Firefox are about it.
Even then, KDE can make a gtk+ application (such as Openoffice and Firefox) fit far better on the KDE desktop than the GNOME desktop seems to be able to do for Qt-based applications.
One simply uses qtcurve or similar for which the same theme is available for both KDE and gtk. On the KDE desktop, select the same them for gtk applications as the KDE desktop theme, and you are set. An integrated desktop, gtk and qt applications side-by-side and indistinguishable as to which is which. No jaringly out-of-place applications.
http://liquidweather.net/howto/index.php?id=93
http://liquidweather.net/howto/assets/images/9714-1.png
(not that this is necessarily a good theme to select mind you, but it does illustrate the point)
AFAIK you cannot get close to doing this in GNOME. AFAIK in GNOME there is no ability to configure the Qt themes to make Qt applications match visually with the selected GNOME theme. You actually seem to agree with this.
Having said that ... in comparison on a Windows desktop, visual styles for applications are all over the shop, there is almost no consistency at all. So GNOME is not the only desktop which has this kind of problem.
This is the real point I am making I suppose ... which after all rather does make mincemeat of the point that the OP tried to imply (that there were no decent qt applications was the implication).
Exactly. Why not just have the desktop support applications built with either GTK or with Qt toolsets? Why not even arrange for the desktop to set the same theme and fonts and widget styles for both, in the same operation, so that all the applications chnage their look in sympathy?
Or, more to the point ... why does the GNOME desktop fail to do that?
Or, more to the point ... why does the GNOME desktop fail to do that?
Simply put, GNOME is about GNOME, not other toolkits or desktop environments. Configuring other DEs or toolkits doesn't belong in core GNOME, it belongs in either a separate application or the other DE. Including such an application is the responsibility of the distro maintainers.
GTK doesn't "belong" to GNOME. The letters GTK stands for "the GIMP ToolKit".
http://en.wikipedia.org/wiki/Gtk
GTK+ (GIMP Toolkit) is a cross-platform widget toolkit for creating graphical user interfaces. It is one of the most popular toolkits for the X Window System, along with Qt.
GTK+ was initially created for the GNU Image Manipulation Program (GIMP), a raster graphics editor, in 1997 by Spencer Kimball and Peter Mattis, members of eXperimental Computing Facility (XCF) at University of California, Berkeley.
GTK+ is licensed under the LGPL free software license and is part of the GNU Project, which aims to create a whole free-software operating system.
The GNOME Foundation is the developer listed for GTK now, but that isn't the way it began.
Why on earth shouldn't the GNOME desktop support users running applications made toolkits other than GTK in an integrated way? By ignoring toolkits other than GTK, the GNOME desktop just manages to make itself less functional, it doesn't help anyone at all in any way.
Then you have less applications that people can use. It's all about development and applications. The more applications you can feasibly make at home on your desktop, getting over toolkit envy, the greater the support and userbase of that desktop. It's what Microsoft has done pretty well over the years.
That's why many people feel that Gnome is stagnating and even dying when it comes to the application base around it and why there's even rumblings where Qt is openly talked about. That shocked me a bit.
Simply put, Gnome will steadfastly not support non-GTK applications in any way shape or form no matter how small the effort is or the pyaoff, probably because they know deep down that developers would prefer not to develop with GTK and GTK would possibly all but die.
Simply put, GNOME is about GNOME, not other toolkits or desktop environments.
That's one of my major beefs with GNOME devs. QT and KDE devs will bend over backwards to support GNOME/GTK+ stuff (themes, glib event loop, gstreamer support, etc) yet the GNOME devs couldn't care less about making GNOME/GTK+ apps work with other toolkits/DEs.
Totally out of topic, but, have you tried to use Clementine? It is a very nice port of AmaroK 1.4 to Qt4; I actually prefer using it instead of AmaroK 2.x in my Linux box and it is my main audio player in my mac too.
http://code.google.com/p/clementine-player/
Edited 2010-10-22 04:20 UTC
Just yesterday I just started experimenting with the Windows port on my netbook in an attempt to break away from my beloved Winamp Lite.
I don't have any real experience with Amarok so can't compare, and am still discovering Clementine's features. Liking it so far.
Agreed. Not only that, but I can't think of a GTK app that has no equivalent or similar application written in QT. Note that neither OpenOffice, nor Firefox are GTK apps - they use their own toolkits. However, there are several QT/KDE apps that have no replacement in GTK (for example, Scribus).
Edited 2010-10-22 07:45 UTC
Well, consider the app which started development of GTK : GIMP. There's nothing coming close on KDE, I think.
But I would. I use kde and gnome at different places, but applications I use are all mixed up, since I use a lot of gtk and qt applications as well. And since I use both desktops, I kind of got used to different file selector, printing, etc. dialogs and it doesn't bother me anymore (I mean the difference doesn't, but gtk versions of the same functionalities do, and quite often).
I don't think application use depends on the desktop environment. If it does for some people, then those people just miss out on a great number of very good applications, just because they use a different toolkit, which I'd say is stupid.
AFAIK you cannot get close to doing this in GNOME. AFAIK in GNOME there is no ability to configure the Qt themes to make Qt applications match visually with the selected GNOME theme. You actually seem to agree with this.
not completely true. In the default installation, Qt has a theme that uses GTK itself to paint, so witll use whatever theme is selected in GNOME http://labs.qt.nokia.com/2008/05/13/introducing-qgtkstyle/
now, that to me is ruining the look of an otherwise perfectly good application, but tasetes are tastes i guess :p
so it's important that it's possible
AFAIK you cannot get close to doing this in GNOME. AFAIK in GNOME there is no ability to configure the Qt themes to make Qt applications match visually with the selected GNOME theme. You actually seem to agree with this.
not completely true. In the default installation, Qt has a theme that uses GTK itself to paint, so witll use whatever theme is selected in GNOME http://labs.qt.nokia.com/2008/05/13/introducing-qgtkstyle/
now, that to me is ruining the look of an otherwise perfectly good application, but tasetes are tastes i guess :p so it's important that it's possible "
That is a Qt project. GNOME itself ignores Qt, doesn't it? This is one of my main reasons for ignoring GNOME, because it seems to be trying to put barriers in my way from running applications that I might want to run.
If there was some active attempt by GNOME to accommodate outside applications in an integrated way, please someone tell me about it and I might pay some attention to GNOME thereafter.
Edited 2010-10-22 09:13 UTC
Pidgin is so totally out of place of a KDE desktop that I'd rather use Kopete.
I'd rather use Amarok than Banshee.
I'd rather use KDE PIM than Evolution.
I'd rather ... but as you say, it depends on the desktop you use. I wouldn't debate that.
My actual point is that there are actually very few gtk-based applications for which one cannot get a Qt-based application that is just as good.
Openoffice and Firefox are about it.
Even then, KDE can make a gtk+ application (such as Openoffice and Firefox) fit far better on the KDE desktop than the GNOME desktop seems to be able to do for Qt-based applications. "
Neither OpenOffice or Firefox are native GTK+ applications. They just have modifications to make them look like they are. Same way some KDE based distributions have generally made modifications to make them look like native Qt apps.
http://liquidweather.net/howto/index.php?id=93
http://liquidweather.net/howto/assets/images/9714-1.png
(not that this is necessarily a good theme to select mind you, but it does illustrate the point)
AFAIK you cannot get close to doing this in GNOME. AFAIK in GNOME there is no ability to configure the Qt themes to make Qt applications match visually with the selected GNOME theme. You actually seem to agree with this.
That's easy, they have qt3-config and qt4-config for changing which theme the KDE / Qt applications are using for Gnome. So even then just like KDE with GTK+ apps, you can make Qt apps look more natural within Gnome.
This is the real point I am making I suppose ... which after all rather does make mincemeat of the point that the OP tried to imply (that there were no decent qt applications was the implication).
Agreed, Windows programs all decide themselves what they should look like with very little to keep things consistent. Which is why I have always found the "It doesn't look consistent" argument for Linux desktop environments to be utterly ridiculous.
Getting back into the Amiga, it was just as strange there, with MUI, Reaction, Class Action, etc. Indeed they had different frameworks on it too. Though I still haven't seen anything as cool as MUI on any other platform...
He said all the good applications are GTK - plain and simple. He may or may not have meant what you think he meant. That said, my own personal list of cool QT/KDE apps include:
Digikam - nothing like that for any platform. Supports one click upload to all important online services, from facebook to picasa and a dozen others. UI is cool, and it's excellent for basic photo adjustments. There is nothing like that written in GTK - not as featureful anyway. In fact, I couldn't find anything free that comes close for Win 7 either.
Scribus - no equivalent in GTK. You may not need it, but there is no other FOSS desktop publishing software matching its functionality.
Skype you already mentioned, Google Earth is also on the top of my list.
Amarok - I know many people prefer the old 1.4 series, but I liked the 2.x ones. Clementine doesn't cut it for me. Had to settle with foobar2000
KDEnlive - nothing comes close to the easy of use and feature richness of this app. Has been stable for the past 6 months. Impossible to find FOSS replacement for Win 7 (blender is overkill - kdenlive, you can sit down and use it immediately). GTK equivalents are jokes in comparison.
These are just off the top of my head - the ones you won't find any equivalent on GTK. I can't think of anything GTK that has no replacement in QT/KDE, but it was quite easy to come up with examples for the other way around.
At any rate, since none of us possess telepathic abilities, all the cool apps are GTK might have just as easily been a snarky remark as an innocent (albeit ignorant) comment.
Damn you! Forgot about Inkscape
) Yeah, that would be a good example for a GTK app, although Karbon is not bad:
http://www.koffice.org/karbon/karbon-screenshots/
Unfortunately I had some stability issues with it, but haven't tried it recently. Anyway, you are correct, Inkscape is really good.
Sure, but that's a moot point since the opposite is also true; Pidgin is totally out-of-place in KDE.
I can't think of many GTK applications that doesn't have equally good QT/KDE counterparts.
Woh guys! I didn't think there would be a huge debate about it.
I should've just said that Qt doesn't have a decent web browser. And, Yes, Firefox clearly uses Gtk+ for somethings, though they are working on a Qt version. Anyways, I use Chrome.
Given how much of my computer use consists of me surfing the internet, it means a lot for my browser to mesh with my desktop and other apps.
This goes beyond just the bland looking theme. It's the dialogs. Ever save a file in Firefox; then try to find it again in Dolphin/Konqueror?
You might have shortcuts to help you on Dolphin but they will be nowhere in the dialog because it's not using Dolphin's setting it's using Nautilus'. The same goes for importing, exporting, and saving a page or target.
None of this even touches the reduced performance you get using more than one toolkit at a time.
Now it's much clearer what you wanted to say - your issues are with integration, not with the applications. Dolphin is not as well integrated with GNOME as it is with KDE. That does not mean that Nautilus is better (and I guess you can make the argument the other way around).
The point is, KDE has lots of great apps, some have no equivalent GTK counterparts. And some of those great apps are real heavy-hitters, ie feature-rich, polished applications (Scribus, Digikam, Google Earth).
Opera
konqueror
rekonq
arora
Yes, clearly there are no decent browsers using QT...
You could also turn that around and ask why Firefox doe s not use the same shortcuts as Dolphin/Konqueror.
Nonsense. Its 2010, not 1990. Using more than one toolkit at the same time does not affect performance.
You can configure Firefox to use KDE-style file dialogs, and it even picks up the shortcut icons/places things.
Really? Can you quantify that? It's a very funny claim, if you really think about it.
I actually tend to think at least 50% if not more of the really solid linux apps are Qt based, it's just that many Gnome users seldom see them or know about them. Not that I blame them, KDE is still a little buggy and depending on the distro can be a little complicated at times.
Some of the best applications on Linux like Digikam, Amarok, Scribus, KMail, Konqueror, vlc use Qt.
at lest Rich Green, Nokias CTO, said that:
http://mynokiablog.com/2010/10/21/symbian3-users-no-need-to-wait-fo...
If you ever doubted getting that sweet, sweet, sweet Nokia N8 because of it not getting S4. Now is the time. 
No, touchscreens are really not my thing, nor are high-end phones which look especially sweet and attractive in the "I want to steal that" way.
OTOH, I'm quite satisfied with my Nokia E63, the only thing I'd possibly see replace it is a debugged version (same price, same battery life, same keyboard, just get the firmware fixed). So I'm highly interested in the future of Symbian on mid-end Eseries...
Qt is an excellent cross platform GUI (and other APIs) toolkit. This is a great decision on Nokia's part because the existing Symbian toolkits pale in comparison, and JavaME, well, sucks. And to have a unified toolkit across both Symbian and MeeGo is a great idea. Plus the full desktop version of Qt works on Linux, Mac, Solaris, and Windows. Finally, Qt is both closed source and open source (you can choose your license, depending on your use/business plan), and it has a huge ecosystem and developer mind share.
And of all GUI toolkits I've tried (WinForms, Swing, SWT, GTK, WxWidgets, Qt), Qt is the best. It is really pleasant to work with. Heck it even makes C++ development pleasant. Don't like C++, then you can use one of the bindings, PyQt (the Python binding) the most notable.
Another thing of note here - Nokia are still far and away the largest seller of cell phones on the planet. In the smart phone arena, they have lost market share to iPhone and Android. But they're still huge there. Plus, they sell more "regular" feature phones than anybody. Indeed, in spite of all the Apple and Android and Blackberry hype, Nokia are the 800 pound gorilla in cell phones.
"Don't like C++, then you can use one of the bindings, PyQt (the Python binding) the most notable."
PyQt/PySide are the only bindings worth using... I wouldn't use any of the others on any project I had to maintain.
Nokia needs to readopt Jambi, pay Miguel to do the .NET bindings, and consider adopting the D Programming Language.
I would say that Python is the only dynamic language worth using, but you know how sensitive those Ruby guys are... (I kid, I kid! ;-)
I was surprised to see Nokia dropping Java support, given Java's popularity in phones and in the enterprise, but even more surprised to see no complaints (am I looking in all the wrong places?). I saw no community rise up to maintain Java support (MeeGo is an open platform, right?), so... is Java really a player on Nokia phones? Any idea why not?
Qt# (Qt on C#) was started and then faded. If the community cares so little for Qt on .Net, why should Nokia care about .Net on MeeGo?
And D? It's cool and all that, but it's a pretty small programming community to warrant a significant investment by Nokia.
Just $0.02 from an old engineer...
I was surprised to see Nokia dropping Java support, given Java's popularity in phones and in the enterprise, but even more surprised to see no complaints (am I looking in all the wrong places?). I saw no community rise up to maintain Java support (MeeGo is an open platform, right?), so... is Java really a player on Nokia phones? Any idea why not?
Qt# (Qt on C#) was started and then faded. If the community cares so little for Qt on .Net, why should Nokia care about .Net on MeeGo?
And D? It's cool and all that, but it's a pretty small programming community to warrant a significant investment by Nokia.
Just $0.02 from an old engineer...
Yes, you're right - we Ruby guys are sensitive, caring types!
I think it is a characteristic of the Python community in that they will say that everyone should use Python and be rude about other languages. Whereas Ruby guys will say use Ruby if it suits you, but feel free to use something else like Python if it doesn't suit you, and we won't hold it against you. In fact we will be interested to hear how you get on.
The is a current C#/.NET Qt bindings project called Qyoto. When KDE moves from svn to git Qyoto will be re-engineered somewhat. Instead of generating the C# classes from the Qt header sources, it will generate the bindings directly from the language independent 'Smoke' libraries that various Qt/KDE language bindings projects use. This should make it much easier to maintain, and easier to add new libraries to the bindings.
"Yes, you're right - we Ruby guys are sensitive, caring types!"
Some would say "over-sensitive". You did realize I was just pulling your chain, right? ;-)
I've actually found the Pythonistas to be the most open and accepting open source community of any I've tried. As a long-time Perl enthusiast, I never felt patronized by Pythonistas. It's one reason I use more Python than Perl now (though I still use both, and we use more Perl on my work team than Python).
I've tried Ruby as well, but I haven't really adopted it (or adapted to it?). If I did a lot of web programming, Rails might win me over, but as it is, I just haven't gotten the hang of it or really found a good use case to drive me to use it. Probably a personal quirk - I use Java and C, but C++ just grates on my nerves like fingernails on a chalkboard. Oh, well.
Hope you won't hold a little chain-tug against me. :-D
On a more general (and on-topic) note, I've looked at Qyoto, but it seems to be targeted only for desktop use, not MeeGo and Symbian programming. Could you point me to any examples of Qyoto for the latter?
I've actually found the Pythonistas to be the most open and accepting open source community of any I've tried. As a long-time Perl enthusiast, I never felt patronized by Pythonistas. It's one reason I use more Python than Perl now (though I still use both, and we use more Perl on my work team than Python).
I was replying to a comment on this thread which was rude about non-python Qt bindings for no apparent reason. I can see why people like Python even if I personally prefer Ruby, and there is never any reason to be rude whatever your preference.
No it isn't there yet. I started working on Smoke libs for MeeGo touch and the Qt Mobility apis at this years KDE Akademy, but I haven't managed to do anything since. Those projects need to go into Gitorious. Then we need to move Arno Rehn's 'AssemblyGen' project into the KDE git repo. Finally we need to move the KDE language bindings like Qyoto from svn to git, and get Qyoto working with AssemblyGen. All this will probably take a good six months.
About GTK+ efforts for Meego:
http://blogs.gnome.org/foundation/2010/10/13/gtkmeego-handset-integ...



