Jim Jewett <[EMAIL PROTECTED]> wrote: >>> To just create a preference picker and an OK/Cancel dialog -- the >>> mental overhead really shouldn't be much worse than using a single >>> python module from the standard library. (And yes, this rules out >>> using pretty much any existing framework as the API.) > >> Does it? > >>>>> from qt import * >>>>> app = QApplication([]) >>>>> QMessageBox.question(None, "Confirmation", "Are you sure you want >>>>> to >> exit?", QMessageBox.Yes, QMessageBox.No) >> [ dialog popups ] >> 3 >>>>> QMessageBox.Yes, QMessageBox.No >> (3, 4) > > You do realize that you just returned the integer 4, when you wanted > something False? That is mental overhead.
No, you're over-generalizing. What if I wanted the buttons Ok/Cancel instead? Or "Abort"/"Retry"/"Cancel"? The mental overhead is having to remember different APIs from the Yes/No case, if you're going to use a specialized version returning just a boolean. >> 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). > > So don't think about them. > > Events (or slots, or signals) which are internal to the GUI do not > need to be exposed. ??? Events, slots and signals are all public parts of a GUI API. > When it is needed, translating between from a signal to an event or an > event to a slot may not be the most graceful solution, but it will > work. No, it won't. Events and signals are pretty different concepts. If you're not making a difference between them, you're generalizing too much and losing power. Anyway, it's not *me* that it's saying so. I'm just an average programmer which wasted far too many hours working with unreasonable, broken, incomplete, over-generalized, over-simplified, slow GUI APIs. Look at the API of Qt: it is a successful, production-ready toolkit for a reason. > Why should the application writer have to specify hardware > acceleration? If the wrapper library can't provide reasonable > defaults, then just don't use it. I was just trying to say that designing something like QPainter, with a common API which totally abstracts from the OS details but still allows hardware acceleration on most platforms (GDI+ on Windows, for instance) is very very complex (and it went through several revisions and refinements). I don't expect anyone to come out with a better API on their first try. Of course, they could just copy it. But then, why don't adopt it? 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
