Different languages, unless you plan on using Java.
That is my current direction - Java. We are in/approaching proof of concept
stage and are trying to "break" the different technologies involved with
Java and create "rules" for deployment (i.e. Java 1.3 just doesn't cut it
because so much has been added in the JRE for 1.6 that makes it much easier
to run Java applications - on Windows that is).
With the explosion of Apple's Mac I think it warrants looking past
Microsoft-only desktops. I was surprised to learn that BestBuy is selling
Mac Powerbook's and iMacs. Don't know when they will start entering the
business space because right now I think it is mostly hobbyists and software
developers that use Macs within the walls of a business, but there's nothing
like planning for the future just in case there is a huge influx.
If that's the direction you're going, I'll be interested to see your
decision making process there.
I am hesitant to use the different technologies that haven't been around for
at least 4 years. Swing is getting "safe", I just haven't used it as much.
I don't believe I have developed with SWT at all - is that what Eclipse RCP
is using? I have debated seeing what I could develop using Eclipse RCP in
regards to business apps...
Right now I am using, believe it or not, AWT for my Java desktop apps. As
far as UI components go it currently has everything I need, but I don't
think that will remain true for to much longer. We will eventually want
richer UI controls that come in the new UI frameworks and then we get to
decide on build vs. migrate.
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>.
I think a few people have agreed with browser and a few have agreed with
rich client. So much of this conversation is based on where one feels most
productive. I have always felt more productive with something outside the
browser simply because everything works better/faster. That is obviously
not an opinion we share so I can leave it at that.
Good conversation! All business left at the door, right? We'll have to go
out for a cold one at iSeries DevCon in October? :-)
Later,
Aaron Bartell
http://mowyourlawn.com
-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx
[mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Joe Pluta
Sent: Wednesday, September 05, 2007 8:57 AM
To: 'Midrange Systems Technical Discussion'
Subject: 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
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx To subscribe, unsubscribe,
or change list options,
visit:
http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take a
moment to review the archives at
http://archive.midrange.com/midrange-l.
midrange.com
