Re: Dipping my toes in cross-platform GUI

Tom1s # hilidhe wrote:


I'll tell you my experience. Take it at its face value.

Any library worth the plastic in the CD it is shipped on is far more
complex than it appears on the surface (even after reading the manual).
To obtain satisfactory results from it would require becoming more or
less proficient if not fluent with it. To achieve desired fluency
with the library you have to spend countless hours designing your
program with and around the concepts implemented in that library. Do
not kid yourself that all libraries that serve similar purpose are
the same. They are close, but the common denominator is the tip of
the iceberg. The differences is what lies beneath. And those are
what will give you trouble and what needs to be comprehended in at
least some detail if you want to learn and use the library properly.

Now, you have your own task at hand -- the application in the problem
domain you're good at. Be it quantum physics or sales order tracking,
you're out to solve that problem, to improve the lives of physicists,
salespeople, accountants, etc. *That* is what you're going to spend
the overwhelming majority of your designing/coding time. Even if it
comes natural to you, you will still need to test, and debug, and to
test again, and document, and plan, and ... You get the picture.

Given that you have your own problem to solve, you simply have NO TIME
to compare several libraries. That's why you've come to Usenet with
your question: what libraries are out there, what's their advantages,
what to look out for, etc. You don't want to try to make the decision
without weighing all the pro and contra. That's wise.

It seems, however, that you think that somebody has done what you do
not have time for, i.e. compared several libraries to arrive at the
conclusion to use a particular one. Nope. Most of us, just like you,
do not have time to compare several of libraries based on *our own*
experience learning and using them. Rarely do we have experience of
programming at the level required for implementing such libraries for
more than one operating system.

Whatever you hope to learn about those libraries is already available
on each libraries' mailing list (trust me, every decent library has
one, and if it doesn't have it, it's not worth spending time reading
about anyway).

Here is what I've seen happen: a young guy without any experience
using any of the popular {UI|Network|WWW|Hardware|...} libraries
comes to a shop where one of them is in use. How did it get chosen?
Somebody might or might not remember. Maybe the guy who convinced
the manager to start using this particular library has already
moved on to new job, who knows... Doesn't really matter. There
are resident experts, from whom the young guy learns the tips and
tricks, the idioms and the quirks. He becomes proficient in using
the library. Then he matures and finds himself wanting to advance
his career. Elsewhere. Where would he look? If he's young
enough, energetic, he might look for something totally different.
He might look for a shop that uses a different library altogether.
He doesn't mind learning another one. Or, maybe he prefers to
keep working in the same problem domain and the other stuff just
doesn't matter much to him.

Will he learn the second library to be able to compare them? Nope.
He'll learn the new library and the first one will fade in his
memory. He could barely remember the names of some classes from
the old library after a couple of years of using the new one. What
is worse, some subtle differences are so subtle (but make sense now
that he's using the library in which they dominate), they make him
think that the other one was organised the same way, thus creating
the illusion that all of them are the same, really. No, really,
they are. Aren't they?...

Here is the advice part of the story. Pick one and learn it. Use
it to the best of your ability; they are all equally capable when
employed properly. If you have doubts about its abilities, you
will have to create an abstraction layer in your own application
to be able to switch to a different library should there be a need
to. That's about twice (or thrice) the work than simply use the
same library without even thinking of switching later. Decide for
yourself, do you have twice or thrice the resources to plan for
a possible switch in the future? Or perhaps it doesn't matter at
all *what* library to use, what matters is that you're using one,
and it provides enough abstraction for your code to carry you over
the troubles of porting your {UI|Network|etc.} functionality to
the next platform.

Of course, if you already know *all* requirements the library has
to meet, then pose the question "does it do <blah>?" to the very
makers of each library to see if it will work for you. If that's
the case, we really can't help you, but folks in the mailing list
(which I may have already mentioned) could.

Good luck!

V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask