Thursday, July 16, 2009

Cross platform GUI portability, part 2

So, if you read my first post on the subject of cross platform GUIs, you probably think I missed one aspect, which is that on cross platform GUI toolkits. Don't these guys, in one shape or the other, solve this problem? If you ask me, the answer is no, and I will now set up to make my point here.

The problem is that the main issue persists: Do you want your app to look like Windows on Windows and like Mac on OSX. Always. For all intents and purposes? Or do you want your application to look and feel like "your application", on all platforms? Whichever path you choose, there are solid good reasons for both approaches. And that is the issue. wxWindows, Java, wxWidgets, all fine technologies, but they do not solve the basic issue.

Is the solution to make the GUI adaptable to both approaches on all platforms, and have it configurable to support all these aspects? In a sense, I think that is true, but on the other hand I feel that the effort needed to achieve this is terribly counter productive. It really is. It is cool and it looks nice, but in the end, really does little to drive technology forward, in a philosophical sense.

I have seen a few commercial toolkits doing this, with great technical success. The drawback:
  • These toolkits are usually expensive.
  • Now you have a third API to program against, not Win32, not OSX, but something else. Not to mention Gnome or KDE then.
  • What good does it do to your application, really? I have seen applications built with these toolkits expose a 100% Windows look and feel on Macintosh! And it looks real neat, and achieving the task of having Windows look-and-feel on a Mac is not an easy task, and these toolkits are advanced. But the value for the end user, once the interface they want to use is set? Not much.
To an extent, this reminds me of the 1980s, early 1990 mix of different networking technologies, where some vendors were pushing cross networking APIs. Usefule, well, sort of. Valuealble there and then, well, yes, to an extent. Useful in the long run? Nope. Definitively not at all. And then you have all this code, when you realize that TCP/IP is all you need to care about, written not against a TCP/IP library, but against some other kind of weirdo library that has a cost, but which provides you with cross network portability across TCP/IP, IPX/SPX, BanyanVines and DecNet. Which would be useful if it wasn't for the fact that no one is using anything else than TCP/IP.

Things aren't even close to that situation with GUIs, and I will make a shot at a cross platform wxWidgets based app later this year. But for now, I am pretty much convinced that independent how much I try, I have to make compromises between functionality, OS/GUI integration, usability and code overhead.
  • No, I am NOT going to sprinkle #ifdefs across my code.
  • Yes, I know I need to make compromises.
  • Yes, I am aware that my knowledge on Win16 7 Win32 is of limited use.
Despite this, I want to try it. And to easy the minds of my MyQuery users, no, the target for this will NOT be MyQuery, but something else...

About to go to bed.

1 comment:

alexvinidiktov said...

wxWindows, Java, wxWidgets, all fine technologies, but they do not solve the basic issue.

wxWindows and wxWidgets are the same thing. wxWidgets used to be called wxWindows.