RE: GUI development language

From: albartell

I still don't agree with this. Sure, you may have to test nine times,

but
typically that doesn't involve changing a line of code. Whereas writing
the
code for three different operating system effectively triples your work.

It *could*, but I would guess you have done a similar amount of work
implementing thick/fat/rich clients on multiple desktops/OSes (am I
guessing right?). So then we are both theorizing on that point.

Actually, no, Aaron. I did a lot of work on thick clients in the 90s,
including Windows, OS/2 and Unix. For example, you'd think writing a
program that ran on Windows and OS/2 would be pretty straightforward, but in
reality there were significant differences (yes, you could run a Windows
application in OS/2, but I'm talking about a native OS/2 application).

Remember, when you try to write a GUI application, you are invoking
literally hundreds of APIs, ranging from drawing a line to positioning a
widget on the screen to selecting a color or a font. Those APIs are
different on every platform, and sometimes there's no direct correlation on
one platform for a feature on another.

And then you have the issues of different tools for each platform (you're
already starting to run into that). Different development tools, different
admin utilities, different command lines. Different languages, unless you
plan on using Java.

A lot of this does go away if you use Java. If you do plan to use Java,
though, you have other deployment and architectural issues. Right off the
bat you're going to have to decide which UI you're going to use: Swing or
SWT. If that's the direction you're going, I'll be interested to see your
decision making process there.

Because you couldn't tell the current browser window to become chromeless.
Instead you had to open up another window. If what I said doesn't ring
true with you I can drop this one, though I still believe I am right ;-)

Ah, I get you. Actually, I agree with you on this point. I think it's
complete horsehockey that you can't switch a browser into chromeless mode
dynamically. But I'd put that into the category of implementation
limitation rather than "hack". But we agree it's a pain, so it's more of a
terminology issue.

I think all you have to do to convince me (or anyone) is to provide a

situation where a rich client will make a user demonstrably more
productive, then show us the cost of writing that rich client code.

I hope to do exactly that in the first quarter of next year. I have some
ideas :-) Stay tuned.

Looking forward to it.

I agree, but I am not necessarily taking the whole IT decision making
process into account here. Like I said before I am trying to debate user
interface and user experience. Once we get past those we can factor in
deployment issues.

Okay. Then it's back to the issues of productivity, and most people on this
list are telling you that short of the integration with the desktop, there's
simply not that much the thick client offers. I think you're going to have
to show us the money, so to speak <grin>.

Joe