Introduction and toolkit abstraction
Dave Cridland
dave at cridland.net
Wed Sep 1 12:06:05 EEST 2004
On Wed Sep 1 03:30:21 2004, Sean Middleditch wrote:
> To be honest, there already is a fairly popular cross-platform
> toolkit
> that uses native widgets - wxWindows. It supports GTK+ and, I
> think,
> Qt. (And if it doesn't, nothing stops that from changing.) Why
> aren't
> most major Linux apps written in wxWindows? Of all the apps I've
> ever
> used, only *one* was written in that toolkit. I don't know why -
> but
> maybe if you found the answer to that one you'd have more insight
> into
> the problems of making an "official toolkit abstraction library."
I don't know why either. I really like wxWidgets, as it now has to be
called thanks to the glories of Microsoft trademarks. Specifically, I
like wxPython. It's seamless across UNIX, Windows, and (almost?) Mac.
It'll handle a bunch of native toolkits, or be a toolkit in its own
right.
I think it's fantastic. I'm a big fan. It's GPL compatible, but a
permissive license for the commercial apps (of which there are many,
such as the AOL software). Sure it's not perfect, and the C++ is
weird enough that I use the wxPython binding instead, but it works.
I don't know why, when I mention it in the pub, people screw up their
faces - people whose views I generally respect.
FWIW, it doesn't handle Qt, primarily because it's designed to be
cross-platform, and hence it seems to trip up on licensing clauses
somehow - I've never quite figured out why. A Qt port was started
before the licensing tripped it up and stalled it into oblivion, from
what I've read in archives and places. Maybe this licensing issue has
cleared up now.
Personally, I think that an application wishing to be multi-desktop
could do much worse than use wxWidgets, and let the user decide which
desktop and toolkit to actually integrate with.
Dave.
More information about the xdg
mailing list