On 5/9/06, Giovanni Bajo <[EMAIL PROTECTED]> wrote: > 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. > 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. 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. 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. -jJ _______________________________________________ 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
