On 5/9/06, Giovanni Bajo <[EMAIL PROTECTED]> wrote:
> ??? Events, slots and signals are all public parts of a GUI API.
They happen to be public parts of many existing GUI APIs.
This does not mean that they need to be exposed unchanged as part of
the default python UI API. I know that there are differences between
signal/slots and events, but I also know that they *usually* don't
matter much. If they matter to you, then you are probably a candidate
for a 3rd party library which can be updated more than once every year
or two.
> 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 believe you.
It is probably complex enough to justify using its own 3rd-party
graphics library instead of the default library.
The standard library should not be bulked up to handle this special case.
> Qt *did* it, so let's use it. wxWidgets does *exactly* what you want: ...
So which is better? There are disagreements. Both will continue to
exist. Using either is a huge commitment, because they aren't typical
python.
This mental cost is something that developers shouldn't pay unless
their *own* project cares enough about the non
least-common-denominator stuff to need a specific choice.
> Say I need a pushbutton, with toggle state, which contains a
> embossed rectangle which is filled of red when the button is
> pressed and filled of green when the button is raised.
> ... [more examples] ...
If your needs are that specific ("must be green", as opposed to "state
must be obvious"), then I'm not sure the standard library even
*should* support them. That said, your specific cases are simple
enough that I wouldn't object to the UI API supporting them; I'm just
pointing out that you are likely to be someone who needs a third-party
library anyhow, and tailoring the standard library to you is likely to
be wasted effort.
> Then, I'd like to have a name for 1,0,-1 instead of using the bare numbers
> (in case there are 4 buttons...). So, we're back to what Qt does: you're using
> magic numbers too. I don't think there's a way out.
I do not claim that PyGUI is perfect. I don't think even the author
(Greg) claims that.
My personal preference would be (singleton) objects in the UI package
for yes, no, and cancel. The yes object should evaluate true; no and
cancel should evaluate false. If you needed to know exactly which
appeared, you could test identity. Labels could be internationalized.
More importantly, the package could be implemented by multiple
libraries. The Qt version of No would have an __index__ method
returning 4; someone else's might subclass from string, and print as
"No". You wouldn't have the full power of the underlying Qt (or wx or
Tk) engine, but you wouldn't have the full complexity either, and you
wouldn't have to care which was present.
-jJ
_______________________________________________
Python-3000 mailing list
Python-3000@python.org
http://mail.python.org/mailman/listinfo/python-3000
Unsubscribe:
http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
