Talin <[EMAIL PROTECTED]> wrote: >> I don't agree with much of what you propose basically because I >> think it's hopeless to create a wrapper API above all the toolkits. >> There are far too many "details" which are different (just thinking >> of events, application event loops, signals/slots, HW accelerated >> painting primitives, multithreading dispatching). I dare anyone to >> develop such an API so that it's production-ready (which is *not* a >> Yes/No dialog) within the Py3k time constraint. I reckon that this >> is pratically unfeasable (and, say what, totally useless). > > Java did it, so it can't be all *that* hard :)
Sorry, I don't know anything about Java. But didn't they take a couple of iterations (= several years) before getting to the right point? I saw late Java applications looking native enough, but I remember the first ones with that horrible non-native GUI (SWING maybe?), and I remember screams of Javas co-workers when trying to do something serious with it. But, if Java *really* did it, let's *copy* it. My point is exactly that: Qt *did* it, so let's use it. wxWidgets does *exactly* what you want: it's a common abstraction over different native toolkit libraries. wxPython is very widespread and accepted by the community. Why oh why redesigning something from scratch. > The main challenge is choosing the right level of abstraction. > You don't want to be creating code that does different things > on different platforms; You want to let the platform handle those > details for you. OK, so menus behave differently on Win32 vs. > OS X. So what? You shouldn't be handling individual mouse clicks > at that level anyway. > > Similarly, it would be nightmarishly difficult to try and > re-create the color chooser dialog on OS X, so why bother? Just > use the one provided by the OS. (Unless you are using .Net, > in which case you probably *want* to replace the color dialog :) You probably know that Qt does exactly what you say (use native menus on Mac OS X, and native color picker on all operating system), and it's still thousands and thousands of lines of well-designed code. Another issue (which by itself is going to get headaches to any GUI designed) is how many native widgets can be used and how many needs to be redone. This is a very delicate issue: in my experience, the solution of wxWidgets of going totally native (that is, being just a wrapper around native widgets) is unfortunate, because it coerces the programmer to use the lower common subset of features across all platforms, to be consistent. This is why wxWidgets reference manual is filled with "this works on Windows only, this works on Mac only, this works with GTK only". OTOH, Qt decided to redo all the widgets from scratch (but not the common dialogs of course), and then even reproduce the native look & feel from scratch (hell, it even follow the user's custom theme selection under XP). It's the hard, longest way, but it's the one that pays most. Show me a combo-box with selects among items with both text and a bitmap, done with wxPython, on all platforms. Giovanni Bajo _______________________________________________ Python-3000 mailing list [email protected] http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
