Guest post by A first alpha version of a Qt implementation for the Android mobile operating system has been announced by Romanian software developer Bogdan Vatra. Since Nokia in co-operation with Microsoft have announced that it does not intend to develop a Windows Phone variant of the GUI framework, Qt for Android represents the only remaining route/platfrom to providing mobile phone apps developed using Qt.
The intent of this new software, called the Necessitas Suite, is to be able to deploy existing Qt software on any Android platform. The aim is for all Qt applications once compiled and deployed to one android platform, will run on any other newer android platform and will last for years without any recompilation. Developers should be able to create, manage, compile debug and deploy Qt-based mobile apps using a first class citizen IDE.
The the Necessitas Suite, which has been developed independently from Nokia and Google, provides the Ministro installer for system-wide shared Qt libraries, with the Qt framework, and with an Android version of the Qt Creator development environment. Documentation files offering installation and programming instructions are also available. The Necessitas Suite source code is released under the terms of the BSD licence. The developer explicitly points out that the framework is currently in alpha state: the API is not stable, and he recommends that developers not deploy any apps created with it on Google’s Android Market. The release is considered important because it is intended as an incentive for developers to start building a community around this project.
So it contains no Qt code, itself?
As I understand it, Qt libraries are available licensed under the LGPL license.
http://qt.nokia.com/about/licensing/
LGPL includes a linking exception.
http://en.wikipedia.org/wiki/GPL_linking_exception
Yes, but ‘linking’ and ‘containing code from’ are two different things.
I’m not saying it’s in violation, just that it’s interesting, technically.
http://en.wikipedia.org/wiki/GPL_linking_exception
I would imagine that the Necessitas Suite links the Qt libraries at compile time. As I understand it, this is also known as “static linking”. Using static linking, the target system (in this case Android) does not need to have the libraries pre-installed, as they will be included in the Necessitas Suite as shipped, as allowed by the linking exception of the LGPL.
Edited 2011-02-23 00:04 UTC
Actually, different parts are licensed differently.
http://sourceforge.net/p/necessitas/wiki/Necessitas%20licensing…
Wait, they did work in the Qt source tree, and tried to dual-license it? Public domain is far more permissive than LGPL.
Man, I smell a controversy I didn’t smell an hour ago…
You must have a very peculiar sense of smell.
The statement is as follows: “Additionally to that, I (Bogdan Daniel Vatra ) hereby release all my work, inside Qt source tree, into the public domain.”
The author of any work can do whatever he/she wants with that work, including releasing it to the Qt source tree and also releasing it to the Public Domain at the same time, if that is what the author wants to do.
Edited 2011-02-23 00:53 UTC
Ah. I just misread it.
Though I don’t remember what I got mixed up… *shrug*
Hmm… just thought of something: I thought Qt required copyright assignment.
If that’s the case, then things get confusing.
http://lwn.net/Articles/410407/
Since 1998 TrollTech entered into an agreement with the KDE Free Qt Foundation which gives the foundation the ability to relicense the Qt codebase as BSD.
http://blogs.fsfe.org/adridg/?p=628
“Our goal with the new site is to make this process as simple and welcoming as possible, and that^aEURTMs why we will no longer ask for copyright assignment.”
Contributor agreement is here:
http://qt.nokia.com/merge_requests/agreement
Edited 2011-02-23 05:53 UTC
Cool but do they not sell non-free licenses any more, then?
What’s Skype using, then… I’m gonna need to talk to a lawyer before I can figure this all out…
As far as I know there are still non-free licenses available for Qt for developers wishing to write for-profit applications with restrictive EULAs.
Skype uses an number of different UIs for different platforms:
http://en.wikipedia.org/wiki/Skype
I didn’t see a description of this right off. Does this run as pure native on the linux kernel or does this interface with the java stuff? If the java stuff is mostly bypassed this has some great promise (IMHO).
Qt itself is C++. Qt applications are mostly written in C++ also, but any language which has bindings available can be used. KDE desktop widgets, for example, use Qt and they can be written in Python or Javascript.
Qt provides excellent themeing capabilities, such that applications written under different toolkits (for example GTK and Qt) can be presented to the user as indistinguishable.
Here is an example:
http://www.kde.org/announcements/4.6/plasma.php
http://www.kde.org/announcements/4.6/screenshots/46-w06.png
as before, a great example of all efforts at visual integration coming from the Qt-KDE side. GTK apps are integrated into KDE by an Oxygen theme (made by KDE dudes) for GTK. Qt apps fit into a GTK environment thanks to a Qt theme made by Trolltech^H^H^HNokia
anyway, the example you give has little to do with Qt and more to do with some dedicated KDE folks making use of GTK’s themability to make a theme for it that matches KDE’s theme.
It runs natively using the Android NDK along with the OpenGL ES APIs. There’s almost no interaction with the Java stuff AFAIK. So I guess the answer is “on the kernel”.
This is excellent. I have a viewsonic g tablet (tegra2) running tnt lite (android) and the interface is constantly choppy. Frankly my n900 feels snappier and smoother interface wise. The native stuff should help with the responsiveness…it could even give google “an out” regarding their troubles with oracle and dalvik.
Sure there is interaction with Java.
Only with Android 2.3 it is possible to create pure C or C++ activities.
In prior versions you can only access native code via JNI.
So there is the need to have a Java wrapper to start the application and interact with Android APIs when required, at least if targeting devices older than 2.3.
For they might have to endure alien QT applications shoved down their throats. Well see if QT on Android is as bad as QT on Mac, I somehow suspect that it will be even worse.
So Android’s native API is Java (which is cool) , then you try to shove the whole QT monstrosity on top of Java winding tool kit, good luck with that. i just wonder how accepting Android users will be of apps that look, feel, behave absolutely nothing like native Android apps.
I just wish developers would realize how badly they are short changing users by shoving these “cross platform” UIs down their throats. This is no such thing as a “cross platform” that fits in properly with the native UI.
Its no wonder why there will be no QT on Windows Phone. Windows Phone is nice, all the apps fit perfectly, I’ve heard it described as one can not tell where the OS stops and the apps start. There is NO WAY to achieve this kind of ‘synergy’ with a “cross platform” UI toolkit.
If I were an Android user, the last thing I would want is an app that looks like some warmed over KDE app running a theme that tries to mimic the native underlying toolkit.
Shut up, and drink your Kool-Aid.
Kool-Aid huh, sorry bud, but looks like you already finished off the pitcher.
Guess, according to you, anyone who does not worship at the alter of Qt is drinking the kool aid? Think about it.
Sorry you are unable to think a little critically and realize that people want to use different platforms and not have QT OS shoved down their throats.
Edited 2011-02-23 02:14 UTC
Sorry you are unable to think a little critically and realize that Qt is by far the best way available for people to be able to use multiple different platforms.
Edited 2011-02-23 02:27 UTC
I’m calling Apple People cultists.
It’s a broad brush, but I do make a distinction between “people” and “users”.
“This developer didn’t use xcode and 100% native widgets! EVERYTHING MUST LOOK LIKE IT CAME WITH MY COMPUTER!”
Shut up.
Guess you’ve never had the pain of trying to use a QT app on OSX. It is so freaking bad that I use it Ubuntu inside parallels.
FYI, I have an HTC 7 Trophy which runs WP7, and its a nice phone, and I’m glad I will never have the horror of seeing a QT app on it.
QT is fine for KDE where it is the native toolkit, but its just a UI disaster everywhere else because it does not use the native controls. Rather, it tries to emulate them and it does a piss poor job.
Actually, if it’s not using native widgets, the dev did something wrong.
Exactly so
http://images1.videolan.org/vlc/screenshots/0.9.2/osx-0.9.2-ASS-sof…
… but I guess the OP isn’t one to let the inconvenient facts get in the way of a good whinge!
Edited 2011-02-23 04:05 UTC
VLC on Mac UI is written with Cocoa! No QT here!
Just because an app may use QT for a linux version does not mean its used elsewhere. Similarly with Skype, again, Mac version is 100% pure native Cocoa.
Why you may ask? simply because of what a disaster QT is on the Mac.
No, it’s because even the slightest deviation makes you Apple people have a fucking seizure.
“OH NOES! the button looks slightly different! Should I push it! Whatever shall I do! Steve and all his angels help me!”
According to qt.nokia.com, VLC on a Mac is a Qt customer:
http://qt.nokia.com/images/customers/coolapps/vlcmac.jpg/view
http://qt.nokia.com/images/customers/coolapps/vlcmac.jpg/image_view…
AFAIK Skype on a Mac doesn’t use Qt … but then again I never claimed that it did.
There are enough Qt customers to use as examples that one doesn’t have to claim programs that aren’t using Qt:
http://qt.nokia.com/images/customers/coolapps
Edited 2011-02-23 22:13 UTC
Wrong, VLC on Mac is native, QT free, take a look at the source:
http://git.videolan.org/?p=vlc.git;a=tree;f=modules/gui/macosx;h=c6…
So, you see, any decent app out there that may use QT on Linux uses Cocoa on Mac, NOT QT!
There is as far as I know, only a single commercial that uses QT, thats Maya. Also you know what, they don’t even bother trying to use the Mac like theme on the Mac, and the Windows like theme on Windows, rather they use some KDE looking theme on all platforms.
Its called the ‘uncanny valley’ effect, where something looks close, but is just off and looks really really odd, like QT on Mac or Windows. So Maya just said to hell with it, and used a KDE looking theme so Mac/Windows users don’t bother with trying to figure out what’s weird looking about it.
Pfft.
I have been able to find traces of both a Qt version and a Cocoa version of VLC for Mac. At one point a couple of years ago Qt on a Mac was giving VLC trouble, apparently, and so a Cocoa version was started.
That was some time ago. Right now, none of your rants against Qt are true any longer, and contemporary Qt applications look entirely native. Clementine is a good example:
http://images.clementine-player.org/screenshots/clementine-0.5-1.pn…
http://images.clementine-player.org/screenshots/clementine-0.5-4.jp…
Native system fonts, native menus, native widgets, native windows, native notifications, native system tray supoort, native desktop icons, native method of launching, native windows decroations … native GUI, really.
Perhaps, having gone over to a Cocoa solution for Mac OSX some time ago when it was necessary and your rants had slightly more truth to them, VLC for Mac may not have returned to Qt now that your accusations are utterly out of date.
According to Nokia and the Qt website they have returned to Qt. If they have not, then all this means is that VLC are doing un-necessary extra work now in maintaing a Cocoa version of the UI when the Qt version would now be integrated on a Mac just as well as it is integrated on other platforms.
PS: As far as commercial applications go, VirtualBox has an Enterpriise edition as well as an open source edition:
http://www.virtualbox.org/attachment/wiki/Screenshots/mac_os_x.png
That example took less than one minute to come up with.
Edited 2011-02-24 02:07 UTC
He’s not making this up. VLC’s switch away from Qt on the Mac was recent, and motivated because they vlc was widely regarded as “looking horrible” on the Mac.
Since I have no life, I went and checked out the VLC source tree. Grab it as described here: http://www.videolan.org/vlc/download-sources.html . Look under /modules/gui/. Note immediately that the macosx/ directory is outside the qt4/ directory. Check out /modules/gui/macosx/; note that everything within is written in Objective C, using OS X (well, OpenStep) system libraries. Run ‘for file in *; do grep -i “Qt” $file; done’; observe that there are very few matches. Throw in ‘-l’, and notice that those matches are in 3 files. One of which is a URL string, and another of which refers to QuickTime. The third is a mention of “LIBQT4” in Makefile.in. Given that QT4 isn’t referenced anywhere else in this chunk of the source tree, I assume this is a fluke.
NB I love Qt, and have been employed as a professional developer on a Qt project. This does not preclude acknowledging reality.
Edited 2011-02-24 16:48 UTC
Fortunately I don’t have to use a mac. Unfortunately, macs are separatists enough that you virtually have to write native applications for it, or put up with the macs almost complete inability to integrate outside applications well.
Don’t let it update just now …
http://arstechnica.com/microsoft/news/2011/02/everything-that-can-g…
(although this snafu may be constrained to Samsung WP7 phones, so you may be OK).
It does a far better job than anything else available for the same purpose.
Qt applications run well enough on Windows, for example, for it not to be a problem, as shown by a few examples:
http://www.videolan.org/vlc/download-windows.html
http://www.scribus.net/canvas/Scribus
http://www.virtualbox.org/
http://www.wolfram.com/mathematica/
http://www.clementine-player.org/
Actually, Clementine doesn’t look that bad on a mac:
http://images.clementine-player.org/screenshots/clementine-0.5-4.jp…
or on Windows for that matter:
http://images.clementine-player.org/screenshots/clementine-0.5-1.pn…
Methinks thou dost protest too much!
Edited 2011-02-23 03:45 UTC
Which Qt program in OSX is so awful? Yes it has some remaining issues but calling it a disaster is a tad extreme.
Have you lost your job because of Qt? Did Qt fsck your wife? Did Qt kill your brother?
Why do you have that non-sense hate towards Qt? I mean, everyone has his/her preferences and that deserves respect, but bashing Qt just because you do not like it, does not make any sense.
Qt is by far the best C++ cross platform toolkit available in the world today. I like .NET Windows Forms and Presentation Foundation and I worked a lot with Java Swing, but just Qt provides me a rich set of widgets in all platforms I work on.
Qt on Mac is really really good and it uses the native rendering system (Cocoa) to draw its widgets, so, your “Qt on Mac is a disaster” is just speculation. If the developer was not able to create a nice native UI on mac using Qt, is not Qt’s fault. Look at Qt Creator on the Mac, it is beautiful and looks very very native.
Easy now. Qt on mac is rather good, but i wouldn’t call it REALLY good. Language bindings are tricky, and at times you’ve got to compile qt yourself to have the right flavour for you particular binding.
It does draw native widgets, but only a subset of what cocoa does natively, and you really have to go out of your way to make it look and behave like people (well, mac people) expect a quality OSX app to do.
Interface designer on the mac is a prime example on how great an qt app may looks with KDE, and how poor it looks (and behaves) in OSX.
What i’m saying is that while it’s true qt does draw native widgets in OSX, at times it’s as rough as google translate can be when doing word for word translations. Details get lost in the process.
My own experience tell me that you have to tweak even qt gui code to fit well with the OS/DE your targeting, at least with desktop applications.
Why do I detest QT, 2 big reasons:
1: Used to work in a group run by a proud Mac hater, who’s mantra was “I hate Macs, I hate Macs, I want to f@ck Mac users”. Now they were funded by an agency that stated their app must be open source. So, the person in charge gave the edict that it will be written in QT because if they used another env like C#, he reasoned that because it was open source, others would develop a Mac native version, and with it being QT, it was just miserable enough on the Mac to make users hate it, but not so miserable in that someone would bother to write a native Mac version.
2: QT is much like when I see Americans in Rome screaming louder and louder in English at shop keepers who only speak Italian. I like Objective-C. The reason I use Macs is because I like to write in Objective-C. If GNUStep worked better, I might switch to Linux. I don’t want to be forced to use / develop in QT. I don’t care if Objective-C does not work well on Windows/Linux because I don’t want to force my language on them. But this notion of QT everywhere is in fact forcing C++/QT on everyone.
So, 1, and 2 are connected. When there is a half assed solution like a QT app, there is less motivation to write a true native app, thus forcing QT on people that don’t want it.
My computer is a dual boot between OSX and Win7. I use Win7 because I like writing in C# and I use OSX because I like writing in Objective-C. Don’t force this half assed, jack of all trades, master of none QT crap down my throat.
So if you like Macs and you like C#, try the MonoMac bindings the Mono project is implementing
http://tirania.org/minimac
Ok, you like Objective-C and I respect that; but you are bashing Qt saying that they force to do C++/Qt development on all platforms it runs, but that is actually quite similar to Apple forcing us to develop on Objective-C if we want to write something we would want it to be in their AppStores.
Edited 2011-02-23 20:06 UTC
Qt is by no means limited to use with C++.
For example:
http://www.pyside.org/
(LGPL-licensed Python bindings for the Qt cross-platform application and UI framework)
A list of the languages which have Qt bindings:
http://en.wikipedia.org/wiki/Qt_%28framework%29#Bindings
This looks interesting, Qt bindings for D:
http://www.dsource.org/projects/qtd
Examples of results:
http://www.dsource.org/projects/qtd/wiki/Screenshots
Edited 2011-02-23 22:24 UTC
There’s even a project for Scheme bindings. Stalled, but likely to revive soon. (don’t want to digress too much, so I’ll spare y’all the details)
This is utter gibberish and double-talk.
None of this has any technical merit, or even any logic.
So you dislike QT because of personal, subjective language preference and negative association based on past experience – or, in other words, you dislike it for reasons that have nothing whatsoever to do with QT’s actual merits?
Not all apps call for a GUI that fits in with the system. Pretty much anything that “thinks outside the box” of standard widgets laid out on a grid is fair game. Apps with very innovative and/or visual-centric UIs have no need to fit in. Games, apps for creating music, VJing, creating photo collages, painting/drawing, 3D modeling… I can think of plenty of cases where using the standard UI widgets could be just as much a hindrance as it can be a help for something like a Twitter app.
Precisely.
Here is an example of a whole class of applets called “Plasmoids” that don’t follow the traditional Windows-Icons-Menu approach for laying out KDE applications:
http://techbase.kde.org/Development/Tutorials/Plasma
There is a lot of flexibility in developing them also, but they are still all meant to be used on the one desktop environment.
I belive it’s quite a valid concern. With the whole GUI layer being written in managed language the path for intergrating native apps is basically closed besides games and “world in itself” systems like, say some office suite.
Edited 2011-02-23 10:42 UTC
Android users will not “have to” endure Qt applications. They can just not install them. It’s not like Android doesn’t already have several competing apps for pretty much every common task you’d use a smart phone for (multiple mail clients, web browsers, rss feed-readers, media players, and so on). They’ll install new, Qt-based applications if-and-only-if they’re better than the native apps that are already available.
We will. It’s not a foregone conclusion that it’s going to be. Personally, I think it’s going to be awesome.
You’re confused about what’s actually going to happen. When people talk about “Qt on mobile devices,” they’re really talking about Qt Quick, which is an entirely different beast than the normal widget set and C++ API. One of Qt Quick’s major design goals is to be good at developing mobile phone applications.
Edited 2011-02-24 16:05 UTC
“Since Nokia in co-operation with Microsoft have announced that it does not intend to develop a Windows Phone variant of the GUI framework, Qt for Android represents the only remaining route/platfrom to providing mobile phone apps developed using Qt.”
Well, that’s inaccurate. Qt is capable of running just fine on iPhone and webOS too–anywhere there is a native, OpenGL-based platform, in fact. The ports just aren’t quite as far along. But the demo apps all work, and assuming that Nokia’s Project Lighthouse keeps making progress (which is supposedly still the plan), it should become even easier to port Qt to more platforms in the future.
http://labs.qt.nokia.com/category/labs/lighthouse/
QML app running on the iPhone:
http://www.youtube.com/watch?v=MjYJdi48B8Q
Qt on webOS:
http://www.precentral.net/qt-apps-preware-more-way
Point taken.
This is very nice indeed! Now coding interfaces for Android will not suck anymore, now that I can use Qt Quick
Seriously, does Google hate Interface Developers? What the hell is that Android SDK?
http://arstechnica.com/microsoft/news/2011/02/everything-that-can-g…
Oh dear. Perhaps it might not be to bold to suugest that Nokia may not have made the absolute best choice?
Just saying.
Funny, yesterday I had a long discussion with Peter Bright on twitter because I acted as a troll and called his articles “MS fanboy bullshit”.
In the end I apologize for that, it was very ugly from my part..
Probably it’s just a coincidence, but it’s curious to see him criticizing MS today
It’s happening to a small slice of devices (Samsung devices, and some Samsung devices at that, specifically those who run an older version of the firmware included in the Samsung phones.).
The problem is very small, however a vocal minority can make an issue seem bigger than it is.
Android doesn’t have this problem, but I suppose it’s easy not to have upgrade problems when Google let’s carriers block updates indefinitely. Lol.
Wonder if any Android user will actually pay for a half-assed 5 minute port of a KDE app?
I keep hearing about how “easy” it is to create “cross-platform” apps with QT. Well, every QT app I’ve ever seen really shows it! — they all look like they were thrown together in 5 minutes!
I doubt that many Android users would pay for an app that behaves completely alien, and looks like its been assembled at gun point.
My oh my, but someone seems to have an agenda to disparage here!
Qt applications look far better on a mac:
http://images.clementine-player.org/screenshots/clementine-0.5-4.jp…
http://www.virtualbox.org/attachment/wiki/Screenshots/mac_os_x.png
than Cocoa applications look anywhere else, that’s for sure!
Edited 2011-02-23 04:10 UTC
No, not disparage, but rather ENCOURAGE
Encourage devs to use the native toolkit on different platforms.
Encourage devs to create apps that leverage the strengths of different platforms.
Encourage devs to give users the native experience they deserve.
Encourage devs not to create lazy half-assed, “cross platform” UI apps.
Encourage users to use different platforms and have a native experience.
Encourage devs to learn about the different native languages: Objective-C, C# and Java of each platform.
Meanwhile, some developers who want the widest market for their write-once application will simply ignore your “encouragement”, use Qt and get a fine-looking well-behaved native-widget application on multiple platforms with a minimum of fuss and without having to do any re-writes.
With more people to sell to for less work, guess which developers will be better off?
This is precisely what developers should avoid. Do not shortchange an experience to make a quick buck.
Seriously, use a programming pattern and separate your UI from your backend logic. Write a native UI frontend for every host platform and you will reap the benefits of superior integration.
Qt is good, hell it’s nice, but it’s not native. On mobile, the feeling of nativity is even more pronounced because the interaction methods are relatively more limited.
Someone who’s used Android for a while is going to very harshly feel the differences in a Qt application. Most of these native controls have very specific animation timings, gesture responsiveness, and so on, which means that anything even slightly off is indeed noticeable.
We’re not talking about interpreted programs, but compiled ones, with different resultant code depending on the target platform.
“Qt uses the native graphics APIs of each platform it supports”
http://qt.nokia.com/products
For example, I’ve used Qt Creator in Linux and Windows and the controls were the ones from each operating system.
For someone who’s “used Qt Creator”, you’re quite frankly wrong. Qt uses the themeing APIs of the respective platforms to get colors and such correct, but it does not use the native platform widgets.
You are both correct … It may not use the native platform widgets … but it does use the native graphics APIs of each platform it supports.
http://qt.nokia.com/products/library/modular-class-library
However, the Qt widgets can be made to conform to native widget appearance via the use of the Qstyle class:
http://doc.qt.nokia.com/4.7/qstyle.html
http://doc.qt.nokia.com/4.7/qmacstyle.html
and style sheets:
http://doc.qt.nokia.com/4.7/stylesheet.html
By using these facilities, and bearing in mind the few limitations they impose, Qt applications can achieve a high level of integration with the Mac OSX desktop, including widgets of native appearance which follow the selected desktop theme.
Edited 2011-02-24 03:27 UTC
That just states it uses a native rendering subsystem, which is great for perf, but not much beyond that.
I love the flexibility, I really do, but a consistent native experience is as much about behavior as it is about look. The term “Look and FEEL” was coined for a reason.
I don’t think it’s much of a problem on the desktop, as I’ve said before. However on mobile clients it becomes more of an issue in my opinion. Generally the way you interact with a device using finger gestures verus a mouse is way different. So there’s a lot less room for behavioral error, things like target hit areas and the such need to remain consistent, there’s a lot of small things that a lot of non-developers don’t take into account, but that really do matter.
It doesn’t matter if it’s uniform across all platforms, but if users of platform X are conditioned to expect things a certain way, you’re going to create a barrier to entry which I think is severely understated.
I like Qt, I think QML is great, and should be invested in more, but trying to be everything to everyone just makes you mediocre. It has legitimate gaps it can fill in Linux and become very successful in the process, and I just think it’s bound to shine more there (and perhaps places like set top boxes ..)
I have no citations from Nokia about widgets, but at least I had about native applications:
and it seems it was worth nothing, you said “Qt is good, hell it’s nice, but it’s not native.” and nothing seemed to happen. Who am I supposed to believe?
Native within the context of using native common controls. If you dont understand tbe topic, then dont hit “submit comment” and turn this into a semantics argument.
> Who am I supposed to believe?
So you say that I don’t understand… and you are turning it nasty. Well, if you don’t understand rhetorical questions (with a very clear answer), don’t hit “submit comment”.
Seriously, software developers know the benefits of using native controls but do not have unlimited time and resources. Learning a new language and system takes time that many do not have.
That’s ridiculous. Most mobile applications are games which don’t need to look native. IOS applications of all types don’t have a consistent look.
Then find another field. This isn’t about commoditizing software development, this isn’t a race to the bottom. You are supposed to pay attention to detail, you’re supposed to design a maintainable, scalable, app. This isn’t something you should just now be doing, this should be programming practices you’re following – anyway – .
Writing anything even remotely complex and if your shop has any kind of credebility, you ‘ll already be using a separation of concerns.
This whole thing stinks, and all it will do is lower the quality of applications to where they’re all carbon copies of each other on every platform. At some point, being so much about money, actually decreases your bottom line.
I’ve found as a trend in these comments, that it’s very easy for a few non programmers to sit there and say what programmers should do, or ought to be doing, but what they’re expected to do and told to do at work is a completely different thing all together. I know at least at my job, sacrificing code quality for turn around time is generally frowned upon. Both personally and as a policy.
If you get to the point in the commoditization of the software development industry, where the need to “learn” is used as a negative, then we’ve already reached a very sad state.
Besides, it’s Qt, it’s C++, you’re already learning and maneuvering through extremely obtuse and unwieldly programming concepts.
Don’t look at good practicies as the enemies, look at a cumbersome and outdated language as the problem.
What?
This was just doubletalk, strawman garbage.
A minimum of development fuss. Arranging to distribute Qt with your app is somewhat annoying.
All three major desktop PC OSes have pretty much identical UI paradigms with minor differences that can easily be abstracted away.
Targeting native APIs on desktop makes zero sense. It’s a waste of time.
MacOSX is application centric whereas Windows is funnily enough Windows centric (so is KDE and GNOME).
They are not the same.
What on earth does that even mean?
I think he meant Document Centric approach vs Application Centric approach.
Document centric refers to the main window is just the document you are working on, with floating windows allowing to modify/operate over the document. An example of this is Photoshop in MacOS: Main window only showing the image, and tools in separate floating windows.
Application centric is when the main window contains everything, document and tools, all in the same window. An example of this is Photoshop in Windows: where the image and tools are part of the main window.
Ah, ok.
A bit of a digression, but at least I know what the sentences meant, in isolation.
I seen them used interchangably by different people … but thanks.
Encourage User/Developers to do things your way because no other way of doing things could possibly make any rational sense for anyone else.
Loose the OS snobbery troll.
These two statements are contradictory.
Not all ISVs have the resources to create native ports. Mac users should be glad with an application is written in Qt and not .NET.
There are plenty of open source projects that could use a native interface, why don’t you stop being lazy and go volunteer your time?
MonoMac is 10 times the development platform that Qt is on the Mac, when it comes to integrating with the host system. They actually do use Cocoa, and use it well.
The Mono folks have a lot of experience with wrapping Obj-C APIs in .NET magic. Stop with the baseless slamming.
Calm down and let the market decide, will you?
(I meant to address parent).
Edited 2011-02-23 11:06 UTC
Interesting how there are no apps listed in your comment, nor a description of what is so wrong with them. Actually, there’s really a lack of information in your comment. Reads more like a pointless rant.
I think the “issue” this mac person might be having is Clementine.
http://images.clementine-player.org/screenshots/clementine-0.5-4.jp…
Looks just like a native Mac application, and it has a couple of features that Apple people might not want iDevice users to know about:
http://www.clementine-player.org/
Cross-platform – works on Windows, Mac OS X and Linux.
Native desktop notifications on Linux (libnotify) and Mac OS X (Growl).
Transcode music into MP3, Ogg Vorbis, Ogg Speex, FLAC or AAC.
Plays MP3, WMA, Vorbis, AAC, FLAC or ALAC audio files.
… and the biggy …
Copy music to your iPod, iPhone, MTP or mass-storage USB player.
Any owner of an iPod or iPhone wouldn’t need iTunes, nor a Mac, to enjoy their music.
<sarcasm>We just can’t allow that kind of freedom for people now, can we? Got to try to put them off somehow.
PS: Then there is VLC for Mac and its ability to play WebM video on a Mac. Might that be an issue also? Can’t let people do that now, can we? </sarcasm>
Edited 2011-02-23 05:13 UTC
I do know many of us (apple users) tend to be somewhat shallow, and so be it. Maybe were spoiled with good interface design. I dont know.
Let me just point out a few glicthes in clementine from that screenshot you linked to;
* It’s clearly made for a window with borders
* Way too many dividers
* Little or no padding between interface elements
As much as i like clementine in KDE, the minimal effort made to make it look and feel like a “real” cocoa app is a fail in my book. Even if those are native widgets.
That said, many “real” cocoa applications also look like someone shat on them. Take a look here (warning, funny stuff); http://readthefuckinghig.tumblr.com/
“what Steve likes” != “good”
It’s one step above GNOME in “users are stupid, and need to be coddled” design.
“I like it” isn’t an argument for “good”, either.
Stop freaking out whenever something looks slightly different. Don’t blame applications for your lack of understanding of/caring for the underlying actions your “magic” mouse is causing.
Why should anyone comply with a third-party’s human interface guidelines?
If I want all the buttons on the bottom and a f–king psychedelic blowfish to appear whenever you mouseover, that’s my decision.
You don’t have to like it, you don’t have to use it.
The “my way or the highway” attitude of Apple people enrages me, as in my experience it extends past their computer use and into their general attitude.
I’ve had Apple people argue that I should use Mac OS instead of Linux, even after I explain that it simply doesn’t suit the way I interact with a computer.
When I finally get fed up with them refusing to either change the subject or end the conversation I show them my stumpwm/xterm/conkeror/emacs setup and they look at me like I’m a heretic and stop talking to me.
I’m fine with that.
Yeah, I get really heated when it comes to what that evil company does to the world.
Computers _matter_, and shouldn’t be treated as toys.
Edited 2011-02-23 18:39 UTC
Actually User Interface Guidelines are very important, and every serious environment uses them. Including Gnome, KDE, Windows, Android, and etc. It’s not only a Apple thing.
Consistency is one of the most important principles of usability, and usability is a very important thing when you actually *care* about your users.
If you do a software for you, ok, do it’s interface the way you want it, but if you want to somebody else use it, please show the proper respect to these people with good usability.
Pfft.
So what you’re saying is that it’s _wrong_ to make applications for OSX that work differently than the applications that come with OSX, because it might confuse the users…
Conform or GTFO?
Well, I already chose the latter, so…
This is no longer an operating system. It’s a friggin Fisher Price workbench. This thing goes in that hole. That thing goes in this hole, and nothing actually allows you to build anything for yourself.
Suppose I think I have better guidelines than Apple, I should never port my application to their operating system?
Actually, that’s true, because if I did I’d just get shit thrown at my by the users.
Aquamacs is an example of what happens when people fall for this crap. It’s always noticeably behind Emacs, and it’s _internally_ inconsistent, since they can’t change the keybindings for everything that runs on Emacs to suit the OSX guidelines.
“OSX is great because it has features foo, bar, and baz!” Well, none of that matters, since if I use it, I _must_ put up with an interface that baffles me (as in, I don’t understand why anyone ever thought it a good idea), and if I wrote an application for it, I couldn’t release it, because Apple People would lynch me.
Yeah, I use hyperbole sometimes.
Figure out when.
Edited 2011-02-24 00:12 UTC
Yeahh, continue thinking like that kid… http://www.masternewmedia.org/news/images/jakob_nielsen_thumbs_up.j…
That sure was productive.
Kinda proves my point, actually.
Macman, stop trolling. Android has a far less unified look out of the box than iOS and WP7. This could be a side effect of Google and the OHA targetting the group of technically proficient, digital nomads. This is a group of people more interested in functionality and unfettered connectivity everywhere, than a strict adherance to some HIG. A QT app probably won’t look out of place more than any of the other (dalvik) apps with “quirky” interfaces in the market today.
So you are preaching to the wrong choir. You’d be better of on a mac forum, pontificating on the woe’s of us poor, QT-suffering Android users. Meanwhile, when can we expect the first QT apps in the Android Market?
So why is whenever someone does not like QT or KDE its trolling?
I guess its cool to hate Apple, its cool to hate C#/Mono, but whenever anyone does not like QT, its trolling.
I think GTK is a good toolkit, C#/Winforms/WPF is simply brilliant, Objective-C is a joy to work with. GNU Octave (MATLAB language), Mathematica and Fortran90+ is what I use for numerics.
Out of all the languages / toolkits out there, the only one I truly detest is QT.
The only “cross platform” toolkit that gets even close to getting it right is Eclipse’s SWT where they do use native widgets.
No, its not what you are saying but how you are saying it that qualifies a number of your posts as trolls. You come off in your posts as an a**hole.
It’s trolling because you’re just asserting “it’s a disaster” and providing no evidence.
Does Mathematica use Qt?
http://qt.nokia.com/qt-in-use/story/customer/mathematica-by-wolfram…
Not on the Mac, Mathematica ONLY USES QT ON LINUX. How can I confirm this, grab the binary, look at the symbol table and what it links to. Not one shred of QT here. Look at every shared lib that Mathematica links to, and again, not one shred of QT.
Now, I have not used Mathematica on Windows for some time, but I have no reason to see why it should use QT because it has a mature and very good native UI on Windows, there is no reason for them to re-write it. Only reason they re-wrote the Linux UI is it was an ancient Motif UI and needed serious updating.
I’ll suppose you are telling the truth there.
.
Anyone that would have read the link would have seen:
^aEURoeBeing able to rely on Qt Development Frameworks^aEURTM developers to help us stay on top of portability problems is a plus for us. Qt certainly increased the quality of the product we are bringing to market.^aEUR
John Fultz, Senior Developer, Wolfram Research
So Fultz is talking about “portability” when they port nothing? Unless you are telling false things.
AND WRITING IN ALL CAPS IS LIKE SHOUTING, but you already knew that.
I suppose we have all now read the reasons (you know, portability and so on), so this discussion could have been avoided, but…
I can understand your concern on desktop, where native widgets are important*. But on mobile, almost no one uses native widgets, and yet, they are very successful.
Another thing to say, is that Android UI development is very “ugly”, from my point of view. Lack of good documentation, lack of decent UI guidelines, lack of standard naming on widgets, unnecessary complexity on everything you will do.
Technologies like Qt Quick are a good way to approximate designers and developers, because it’s very easy to understand and code even for designers. And when you get more involvement from designers, you usually get better apps (just don’t tell this to them, some of they are arrogant enough)
*just on a side note: Qt uses native Cocoa widgets on Mac. If you experienced a bad Qt app on Mac, it’s the developers fault, not Qt. VirtualBox is a good example of Qt application that behaves well on Mac
That’s a common misconception: Qt uses the operating system’s theme manager to draw its widgets in a native style. But it doesn’t use Cocoa widgets on the Mac, rather its own:
http://lists.trolltech.com/qt-interest/2008-04/msg00769.html
Look up the source code of your favorite Qt widget
.
“The aim is for all <insert name here> applications once compiled and deployed to one <insert platform name here> platform, will run on any other newer <insert platform name here> platform and will last for years without any recompilation.”
I’ve heard that for fifteen years now, and I’m not yet sooo old.
pleasant dreams, hope many believe in it.
If only it was true with QT from a version to another on a PC for example …
Edited 2011-02-23 16:10 UTC