Introduction and toolkit abstraction

[Lars Hallberg]

Dave Cridland wrote:

> 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.

First, I do *not* think ther is much point in making gtk/gnome apps us 
qt/kde dialogs and the other way around. Let gnome apps be gnome apps, 
and kde apps be kde apps. Lets make them work together in with drag n 
drop, cut and paste, start up notifikation, shutdown/logout handling 
etc. Lets live withe the differens in look and feel if we mix them 
(theming standards to minimize the different is good thou). I do hope 
for all environment to have an option to suport different concept (on 
the users choce) like drag-n-save. Ther is a verry limeted set of core 
concepts, it *is* possable for all environment an ther apps to suport 
all concepts, if not at once at least by choce. And that is ecensial to 
integration between environments.

But I realy hope for toolkit abstraktion in allot of apps. wxWidgets is 
one option, I mainly hope for another. But it shuld be the app 
developers job to choce the toolkit abstraktion tool, and the users job 
to chose widgetset/envirionment.

I belewe XUL pointing the way for god toolkit abstraktion. In the end, 
it might be a good thing if freedesktop could be the place to make 
XML-format, core widgets, dom-api/abi standards. Probably both kde/gt 
and gnome/gtk need costom textwidgets, treewidgets etc to be built, that 
uses a dom api, but I think a dom api is 'right' for those widgets 
anyway. But it is far to erly to standardize now, it is still alot of 
reserch like projects going on - let the stuff mature a while more! But 
the XUL concept promice allot.

I think a qt/kde or gtk/gnome implementation of XUL shuld use native 
grafics, rely on native 'theming' for look. The skining feature of XUL 
shuld in those environment be used primarly for incrising the apps 
integration to the chosen environment (Yes, I asume skin will be chosen 
depending on 'bakend'). If You whant groovy grafical 'no guidline' skin 
using the mozilla XUL backend chold be a choce (for the user).

Hovever, preferable the ui will be built on so high level abstraction 
that most stuf comes out farly right by chosing backend (or rater, by 
just being run in that environment), without the need for a skin.

Costum widget can be built in XUL, but nativ qt/kde implementation cold 
also be built and loaded. So it be possable to work everywher, whithout 
sacrifice to much on the 'favorite' envirenments! The clear separetion 
of ui from logic that follows from this will probably benefit apps and 
app portability allot!

No, it will probably *not* be perfekt. But I belive it to be better then 
the curent situation, wher we use apps fore one environment in the 
other, or have *huge* duplikation of effort, or have big apps using ther 
own toolkit and not integrating well anywhere. subperfekt integration 
into the enviorenment the user is using is a huge improvment!

/LaH