On 11-mei-2006, at 8:45, Talin wrote:
> Josiah Carlson wrote:
>> Having identical behavior on all platforms is wonderful, I'm very
>> happy
>> for you and everyone else with a toolkit (programming language,
>> etc.) that
>> does the same. For the rest of us who cannot use PyQt for one
>> re
Josiah Carlson wrote:
> Having identical behavior on all platforms is wonderful, I'm very happy
> for you and everyone else with a toolkit (programming language, etc.) that
> does the same. For the rest of us who cannot use PyQt for one reason or
> another (licensing...), we must rely on non-Qt too
"Giovanni Bajo" <[EMAIL PROTECTED]> wrote:
> It's sufficient to show that a library that uses native widget has to go
> through many hoops to implement any slightly non-standard feature. And
> causes the mental overhead which makes it unpythonic.
I would disagree.
The fact that it can be done, i
Giovanni Bajo wrote:
> Then, I'd like to have a name for 1,0,-1 instead of using the bare numbers (in
> case there are 4 buttons...).
There aren't any standard dialogs in PyGUI with 4 buttons,
so that problem doesn't arise. :-)
I could provide some names, Yes = 1, No = 0, etc. But
since you can
Josiah Carlson wrote:
>> Show me a combo-box with selects among items with both text and a
>> bitmap, done with wxPython, on all platforms.
>
> How about I describe how one can make it happen?
>
> There was a somewhat recent post in wxpython-users which offered a
> reimplementation of wx.PopupWind
"Giovanni Bajo" <[EMAIL PROTECTED]> wrote:
> Show me a combo-box with selects among items with both text and a
> bitmap, done with wxPython, on all platforms.
How about I describe how one can make it happen?
There was a somewhat recent post in wxpython-users which offered a
reimplementation of w
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
Greg Ewing wrote:
>>Qt, Java Swing, and .Net Windows.Forms are all examples of what I would
>>consider "good" API designs. All three of them are powerful,
>>comprehensive, and have relatively clean APIs. I would be perfectly
>>satisfied to have the equivalent of any one of them in the Python sp
>> [Antoine Pitrou]
>> But magic numbers are ugly, even if they are hidden behind an
>> enumeration. If you try to print them for debugging, it will only show
>> the numeric values, which is hardly intuitive.
>> [...]
>> [Giovanni Bajo]
>> No, you're over-generalizing. What if I wanted the buttons
Talin wrote:
> Qt, Java Swing, and .Net Windows.Forms are all examples of what I would
> consider "good" API designs. All three of them are powerful,
> comprehensive, and have relatively clean APIs. I would be perfectly
> satisfied to have the equivalent of any one of them in the Python space.
Giovanni Bajo wrote:
> 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.
In PyGUI I'
Giovanni Bajo wrote:
> 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.
Antoine Pitrou <[EMAIL PROTECTED]> wrote:
>> 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 jus
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
Le mercredi 10 mai 2006 à 03:23 +0200, Giovanni Bajo a écrit :
> 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
> vers
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
Giovanni Bajo develer.com> writes:
> 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
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 rule
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.
On 5/9/06, Ivan Krstic <[EMAIL PROTECTED]> wrote:
> Jim Jewett wrote:
> > By spitting out html and javascript, rather than draw/paint commands.
> I was afraid you were going to say that. I, for one, welcome our new
> AJAX overlords, but to want to task a general GUI toolkit with producing
> HTML a
20 matches
Mail list logo
