One of the great things about Trolltech’s hard work into Qt has been the ability to use styles.  It’s a great concept, not only that you can tailor your application to a native look and feel at the drop of a hat simply by switching the style used, but that you can even derive your own style from QStyle (or any style based on QStyle) to create your own look and feel.

It’s absolutely great!

…Except for when it doesn’t work.

I won’t even begin to go into a long rant on just exactly why the native-OS styles don’t have “emulation” to execute on non-native platforms (the very point of using Qt), even if it is at a performance loss.  No, that Epic Fail  is blatantly obvious and doesn’t need a whole blog entry just on its own.

No, what I’m going to talk about today is where styles are broken.

Take, for example, the great ability to use a brush instead of a color in a palette.  In this way you can, most obviously, turn a background into not just a solitary color, but a pixmap, or even a gradient.  You can do all sorts of funky things with brushes.  It’s a wonderful concept in Qt.  … Except for when it doesn’t work.

Now I don’t know just how many styles this affects, but I do know that while basing a custom style on QCleanlooksStyle I found a number of bugs, and while walking through some of them through the debugger they step back through QCleanlooksStyle into QWindowsStyle and even QCommonStyle.  Now I get how some of these have been around for so long that maybe somehow someone just forgot that they needed upgrading.

Maybe.

Even if the ability to use a background pixmap has been around since Qt 3…

Or maybe there were just some serious bugs in Qt4.7.0.  (When will Nokia get around to actually releasing the 4.7.3 SDK instead of a “release candidate”?  And why didn’t they release a 4.7.1 or 4.7.2 SDK?  For professional developers who don’t work off of anything “official” this is a grievous oversight.)  But suffice it to say, turn on QCleanlooksStyle and then set your palette’s Window brush to, say, a gradient, and BAM! Bugs.

I think one of my favorite, one of the perfect examples, happens to reside right in QCleanlooksStyle itself.  One of the nice things about Qt is that you can look at the code.  And right there in drawControl, is little old QStyle::CE_Splitter.  Now I love that the Linux world has taken things like splitters and sliders and made them more … visible.  Lines and circles and dashes and all sorts of visual cues that this is something you want to touch.  In other styles things like splitters can be darned hard to realize are movable objects.

But, one of the epic fails in the Cleanlooks implementation of the splitter is … the failure to properly support the brush of the palette.  As soon as you un-colorify your palette, you’re asking for trouble.  Because plenty of things in styles, like splitter, like frames for that matter, just assume that you want to fill in an area of space with a color.  And be it a bug or by intent, at least in version 4.7.0, once you set a palette to use a brush it nukes the color.  So if you ask for the color specifically, you just get black.  And so all of those nicely colored areas are suddenly filled with black.  Black splitters.  To say it doesn’t look right is an understatement.  And all because they try to fill a rect with a palette’s Window color.

Now, of course the easy solution would be to use the frigging brush! Obviously.

But the thing is, they’re trying to be fancy, to say, highlight a selected splitter by lightening up the color.  Which works if your palette is only drawing with colors.  But works not at all if your palette is brush-happy.

And yet, there’s an easy better fix.  Instead of filling a rect with a 5% lighter color, why not use the awesome power of Qt to do something even better?  Set the painter’s opacity to 5% and paint a white rect instead.  Because that works just great with both color and brush.

Is it really too much to ask that the Trolls do a simple validation of their styles by setting a simple QLinearGradient Window brush to test the drawing of each and every style?

I can only hope that in future versions of Qt (heck, hopefully in the 7.4.3 SDK if it ever gets past beta into actual release) all of these style bugs can be fixed so that the beauty of Qt can truly shine.

So you’re a developer for the iPad, iPhone, iPod Touch, etc. and you want to use, say, Flash to write your app.  Well, that hasn’t gone so well in the past.  What with Apple first vehemently denying you that option.  Though Apple, perhaps out of the kindness of their hearts, or because they were under scrutiny from the Department of Justice and the Federal Trade Commission, started to release that stranglehold on development restrictions by allowing some apps to have third-party development tools involved, if you had written consent and it was only to provide minimal additional functionality to a homegrown app.

But rest assured, that Apple has seen the error of their ways, and now completely allows third-party development!  Err … almost.

In a company statement, Apple’s new stance is:  “We are relaxing all restrictions on the development tools used to create iOS apps, as long as the resulting apps do not download any code.*”

(* = Underlining is my own emphasis.)

So there you have it.  Soon you’ll be able to go back to developing apps for iOS with your naughty naughty third-party tools.  Just so long as your apps don’t ever download any code.

Err … yeah.  So no updates then?  No install apps?  No download managers?  No third-party web browsers or email clients?  Etc.

This should be interesting to see how Apple officially words this in the SDK…

But I guess it’s at least yet another step in the right direction.  Maybe sooner or later Apple will finally get it.

Or maybe not.

Apple is, after all, king of The Closed System.  It wouldn’t be Apple if they didn’t prevent you from developing on/for them.

There’s small reason to rejoice today if you’re a software developer.  Apple has loosened up it’s no-interpreted-code policy in the iPhone SDK used for development of apps on the iPhone, the iPod Touch, and the iPad.

The old iPhone SDK end user licensing agreement (EULA) stated quite clearly and adamantly that, “No interpreted code may be downloaded or used in an Application except for code that is interpreted and run by Apple’s Documented APIs and built-in interpreter(s).“  This prevented anyone from using languages like Adobe’s Flash or Sun/Oracle’s Java.  Or Python.  (My personal favorite language.)  Amongst many others.  It also prevented the use of third-party development tools such as Adobe’s iPhone packager, which converts Flash scripts into native iPhone machine code.  Or third party libraries such as .NET, Mono, Qt, etc.

It’s a limitation that many developers feel is not only senseless and needlessly inhibitive, but even has the government fighting (DoJ and FTC) for the chance of an antitrust investigation into Apple for their non-competitive practices.

The new iPhone SDK however has a change of heart.

Kind of.

Sort of.

Maybe.

Just a little bit.

A few minor changes of wording in the iPhone SDK leave a little bit of theoretical wiggling room.  Such as, “Unless otherwise approved by Apple in writing, no interpreted code may be downloaded or used in an Application except for code that is interpreted and run by Apple’s Documented APIs and built-in interpreter(s).“  Which makes it sounds as if, theoretically, you could request from Apple a waiver to release your interpreted-code app.

Maybe.

Because then that theoretical possibility of using an interpreted language is further qualified in the iPhone SDK with, “Notwithstanding the foregoing, with Apple’s prior written consent, an Application may use embedded interpreted code in a limited way if such use is solely for providing minor features or functionality that are consistent with the intended and advertised purpose of the Application.“  My own emphasis on the key qualifiers there.  So of course you still need to write the majority of your code in an Apple-approved language.  You still can’t use any third-party development tools, libraries, or languages.

It still doesn’t really fix anything.  Except for perhaps a few rare instances of development, quite possibly in minor things like spam filters, spell checkers, and small pieces of engines used in games.

But maybe it sounds a lot less closed to antitrust investigations perhaps?

We’ll see.

One thing is for certain, Apple does not equal Open.

The Apple iPhone has been garnering the interests of the Department of Justice (DoJ) and the Federal Trade Commission (FTC).  But not in the way one might think.  Oh no.  Not at all.

Apple’s recent ban on coding languages for iPhone apps has got the feds “locked in negotiations” over who gets to investigate Apple for its anti-competitive practices, according to The New York Post.  Yes, that’s right, antitrust regulations just may soon be bopping Apple on the nose for being naughty.

For those of you not following the drama, Apple (and purportedly CEO Steve Jobs) have something very much against Flash.  So much so that Apple has imposed regulations into their new software development kit (SDK) that “only Applications must be originally written in Objective-C, C, C++, or JavaScript as executed by the iPhone OS WebKit engine, and only code written in C, C++, and Objective-C may compile and directly link against the Documented APIs.“  Thereby preventing any real interpreted language such as Java, Python,0r Flash from being used.  Or for that matter any intermediary libraries such as the likes of Qt meant to make multi-platform development possible.  In fact, even cross-platform development tools like Appcelerator’s Titanium, PhoneGap, and Unity 3D may not pass Apple’s muster, as they allow programming in languages other than Apple’s approved list, even if they do translate into Objective C before compiling.  It doesn’t matter if the end result of the app is native execution, and possibly doesn’t matter if the result is native compiling.  So long as the original code isn’t in an Apple-approved language, the app is banned according to Apple’s wording!

Needless to say, Apple is going to great lengths here to make their iPods, iPhones, and iPads closed rather than open.  And seems to have a particular grudge specifically with Adobe Flash.  Something which may have just gone a step too far for the regulatory agencies to allow to continue unchecked.  Or may not.  An investigation doesn’t necessarily mean that Apple has done anything wrong.  It could be found that Apple is behaving within the law.

But for Apple to have even pushed that envelope that far, Apple, a company long accusing others of doing these wrongs as a means of promoting their rightness, is a very bad thing.

There’s a small flurry of hubbub going around in the iPhone/iPad community.  It would seem that in the latest iPhone SDK was found evidence that the iPad will one day have video conferencing built in.  Almost.  Maybe.  Well … it might have.

The evidence comes in two parts.  The first part is a variable in the code specifically for handling if a device has a front camera, you know, to take pictures of you the user as you look at the screen.  This hasFrontCamera variable seems to indicate some kind of video-phone option since, well, why else would it be there?

But why would anyone think that it would be for the iPad instead of the much more likely iPhone?  The devil is in the details graphics.  Also in the iPhone SDK was a graphic for two buttons, to reject or accept an incoming video conference call.  The thing is, the graphic is too wide for use on an iPhone.  Which pretty much just leaves the iPad.

So does that mean that Apple is actually bringing video conferencing to the iPad in the future?

No.

It doesn’t.

Since we know full well that even Apple didn’t seem to know what, exactly, it was doing with its iPad for a rather long time, it’s much more likely that this evidence uncovered from the iPhone SDK is not evidence of a future, but simple remnants of a confused past.  It’d make far more sense for the iPad to be a video phone if it were firstly a phone.  Further, all evidence so far points to a pretty lackluster performance capability of the iPad, which also doesn’t speak well to something as sophisticated as video conferencing.

Frankly, based on the evidence, I’d sooner believe that Apple is just working on a new iPhone with a larger screen resolution than I’d believe that the iPad might do anything interesting.  And honestly, I don’t even believe that will happen any time soon.

But to each their own.  You can certainly dream all that you like.  It won’t make it true, but you can dream it all the same.