Talin wrote:
> (Think of a music scoring program, which
> displays various kinds of Midi events in a piano roll view, a drum
> machine view, a text view, or a music notation view.)
There is another way of handling things like this, using
a technique known as "double dispatching". For example
t
Josiah Carlson uci.edu> writes:
> Greg Ewing canterbury.ac.nz> wrote:
> > In the interests of keeping it small (both in terms of API
> > and code size) I don't consider it vital to provide a huge
> > number of widgets. I'd rather have a compact library with
> > 10 well-chosen generally-useful wi
On Tuesday 09 May 2006 02:42, Greg Ewing wrote:
> Paul Boddie wrote:
> > I think it would be
> > a bad thing if something in the standard library claimed to provide, or
> > just gave the vague impression of providing, a definitive solution for
> > all environments
>
> I would never claim that PyGUI
At 06:19 AM, 9 May 2006 +, Talin <[EMAIL PROTECTED]> wrote:
>Now, generic functions are good at dealing with these kinds of
>situations. However, generic functions (as they are usually concieved)
>can only deal with specific, concrete types, not "types which satisfy
>some constraint".
In Haske
On Tue, May 09, 2006, Paul Boddie wrote:
>
> My worry would be that if another toolkit were dropped into "pole
> position" to replace Tkinter, and then people ignored it just as much
> as they ignored Tkinter, choosing other toolkits, then this would
> involve a lot of maintenance to keep the repla
> A far as widgets go, I think I'd be satisfied (mostly) with the following
> (this is just off the top of my head, and not a definitive list):
>
> Window
> Dialog
> Button / Checkbox / Radio
> Scrollbar
> Slider
> Listview
> Combo box / drop-down
> Scrollview
> Group box
> Tre
Phillip Eby writes:
> In Haskell, interfaces are defined using "typeclasses". A typeclass is
> basically a collection of generic functions. For example, you could define
> ...
> Further, Haskell has a concept of "typeclass instances" which basically
> give you adaptation. For example, suppose
> True: as noted, Tkinter only covers the "big three".
Paul,
Let's stop talking about the "big three" with respect to UI platforms.
There are three big operating system platforms, true. And clearly
each has its own associated window system. But there's also AJAX and
the two big virtual environm
At 09:35 AM 5/9/2006 -0700, Bill Janssen wrote:
>Phillip Eby writes:
> > In Haskell, interfaces are defined using "typeclasses". A typeclass is
> > basically a collection of generic functions. For example, you could
> define
> > ...
> > Further, Haskell has a concept of "typeclass instances" whi
On 5/9/06, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> At 06:19 AM, 9 May 2006 +, Talin <[EMAIL PROTECTED]> wrote:
> >Now, generic functions are good at dealing with these kinds of
> >situations. However, generic functions (as they are usually concieved)
> >can only deal with specific, concrete
Phillip J. Eby wrote:
> At 06:19 AM, 9 May 2006 +, Talin <[EMAIL PROTECTED]> wrote:
>
> In Haskell, interfaces are defined using "typeclasses". A typeclass is
> basically a collection of generic functions. For example, you could
> define a "sortable" typeclass that includes the generic fun
Hi
Le mardi 09 mai 2006 à 09:30 -0700, Bill Janssen a écrit :
> I have to confess I don't see the point of some of them: Listview and
> Gridview are trivial if there's a reasonable layout system,
Listviews (and likewise Gridviews) have more functionality than a simple
layout. An average listview
Bill Janssen wrote:
>>A far as widgets go, I think I'd be satisfied (mostly) with the following
>>(this is just off the top of my head, and not a definitive list):
>>
>> Window
>> Dialog
>> Button / Checkbox / Radio
>> Scrollbar
>> Slider
>> Listview
>> Combo box / drop-down
>> Scrollview
Hi,
Le mardi 09 mai 2006 à 12:46 -0400, Phillip J. Eby a écrit :
> Unless this can be done by a third party, it's not at all the same
> thing. Currently in Python for a third party to add a mixin, they would
> have to hack the class's __bases__, which I am not suggesting here at all.
>
> In f
Antoine Pitrou writes:
> It is a similar argument to saying "we already offer scrollbar widgets,
> we don't need to provide scrollable views because the developer can
> build them himself".
But that seems a reasonable argument, to me. I'm not saying that
they shouldn't be in the GUI, I'm just say
On Tuesday 09 May 2006 13:10, Antoine Pitrou wrote:
> Interestingly, there was a GNU addition to C++ named "signatures" which
> achieved roughly the same thing: some kind of compile-time duck-typing.
>
> http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_5.html#SEC112
I remember that, thinking it wa
At 09:56 AM 5/9/2006 -0700, Mike Krell wrote:
>On 5/9/06, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
>>At 06:19 AM, 9 May 2006 +, Talin <[EMAIL PROTECTED]> wrote:
>> >Now, generic functions are good at dealing with these kinds of
>> >situations. However, generic functions (as they are usually co
Bill Janssen wrote:
> There are three big operating system platforms, true. And clearly
> each has its own associated window system. But there's also AJAX
How exactly would a good Python GUI "cover" AJAX?
--
Ivan Krstic <[EMAIL PROTECTED]> | GPG: 0x147C722D
___
At 09:57 AM 5/9/2006 -0700, Talin wrote:
>Let me offer the following example as a basis for discussion, and see how
>it would work in such a system. (People who have different ideas as to how
>it should be done feel free to chime in -- I want to hear what other
>techniques are out there.)
>
>Let
Phillip J. Eby telecommunity.com> writes:
> Assuming we used argument declarations to do overloading, and that actual
> types (other than 'object') are considered to be more specific than
> typeclasses, you would have something like:
>
> @overloaded
> def flatten(arg:supports(iter)):
Phillip J. Eby telecommunity.com> writes:
> Assuming we used argument declarations to do overloading, and that actual
> types (other than 'object') are considered to be more specific than
> typeclasses, you would have something like:
Lets start a new top-level thread to discuss this specific
p
On 5/9/06, Ivan Krstic <[EMAIL PROTECTED]> wrote:
> Bill Janssen wrote:
> > There are three big operating system platforms, true. And clearly
> > each has its own associated window system. But there's also AJAX
> How exactly would a good Python GUI "cover" AJAX?
By spitting out html and javascr
Does this mean you have no more actual technical reasons to oppose this change, but are just stomping your foot and implying bad things about Winter? Because there are people who agree with him, and I haven't seen any really compelling reasons to avoid this ten-line modification. Seriously, are y
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 and Javascript, running a HTTP server, and automagically deal
On 5/9/06, joe user <[EMAIL PROTECTED]> wrote:
Does this mean you have no more actual technical reasons to oppose this change, but are just stomping your foot and implying bad things about Winter? Because there are people who agree with him, and I haven't seen any really compelling reasons to avoi
i was having lots of thoughts about types in general, and what they mean
in python, and i came to the conclusion they types are basically useless.
after all, "proper duck typing" is something like:
def myfunc(myarg):
myarg.mymethod(1,2,3)
RATHER THAN
def myfunc(myarg):
assert type(myarg)
I'm not implying anything about Winter (whom I actually respect)
except that I don't see the merit of his proposal, and that I don't
see the value of more argument on such a small issue.
And why are you hiding behind an alias?
--Guido
On 5/9/06, joe user <[EMAIL PROTECTED]> wrote:
> Does this me
On Tue, May 09, 2006 at 10:31:02PM +0200, tomer filiba wrote:
> i.e., "is the object addable?" == "hasattr(obj, '__add__')".
Even this is meaningless: '1'+1. So duck typing is:
try:
return a+b
except TypeError:
return "Oops..."
> iterable_protocol = ["__iter__"]
> sequence_protocol = ["
Talin writes:
> Lets start a new top-level thread to discuss this specific
> proposal.
tomer filiba writes:
> i'm sure my idea has flaws, but i'm very much pro-changing the type system.
[...]
> types are just an ancient relic, an implementation detail if you wish, that
> was brought from st
Terry Reedy wrote:
> "Greg Ewing" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]
>> Terry Reedy wrote:
>>
>>> -the ability to ignore platforn standards and give an app a unique look
>>> and
>>> feel. A start on this, for instance, is being able to give dialog boxes
>>> a
>>> cust
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
Michael Chermside mcherm.com> writes:
> Talin writes:
> > Lets start a new top-level thread to discuss this specific
> > proposal.
>
> tomer filiba writes:
> > i'm sure my idea has flaws, but i'm very much pro-changing the type system.
>[...]
> > types are just an ancient relic, an imple
Oleg Broytmann oper.phd.pp.ru> writes:
> On Tue, May 09, 2006 at 10:31:02PM +0200, tomer filiba wrote:
> > i.e., "is the object addable?" == "hasattr(obj, '__add__')".
>
>Even this is meaningless: '1'+1. So duck typing is:
I don't think I agree with this interpretation. Someone earlier
gave
> By spitting out html and javascript, rather than draw/paint commands.
And perhaps SVG for the drawing/painting.
Bill
___
Python-3000 mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-3000
Unsubscribe:
http://mail.pyth
Oleg Broytmann a écrit :
> On Tue, May 09, 2006 at 10:31:02PM +0200, tomer filiba wrote:
>
>>i.e., "is the object addable?" == "hasattr(obj, '__add__')".
>
>
>Even this is meaningless: '1'+1. So duck typing is:
>
> try:
>return a+b
> except TypeError:
>return "Oops..."
>
>
Well, w
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, 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
Le mardi 09 mai 2006 à 20:44 -0400, Jim Jewett a écrit :
> 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.
Bill Janssen wrote:
> I also don't really see the point of the "standard
> application dialogs", as they are so easy to build yourself.
They can be very handy. Also, platforms may have
conventions about where to put the various buttons,
etc.
FWIW, PyGUI already has all the ones Talin mentioned
ex
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
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
Travis E. Oliphant wrote:
> Just get a
> window-area from each platform's lowest-level tool and then draw your
> widgets to the screen directly.
But then you have something that looks totally non-native
on all platforms. While it may be useful to have such a thing,
it's not what PyGUI is designe
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
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
> Currently in Python for a third party to add a mixin, they would
> have to hack the class's __bases__, which I am not suggesting here at all.
I'm not suggesting it either. Here's what I meant:
Consider the type "sequential_ordering", which has methods
len() => INTEGER
iter(
> to want to task a general GUI toolkit with producing
> HTML and Javascript, running a HTTP server, and automagically dealing
> with all the server-side logic seems a bit like a really bad joke.
You've never looked at X11 under the covers (it looks like Mac OS X's
window system is very similar).
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
At 06:48 PM 5/9/2006 -0700, Bill Janssen wrote:
>Using mixins, you'd do something like:
>
>class adapted_mytype (sequential_ordering, mytype):
> def len(self):
> return self.nitems()
>
>You can now use "adapted_mytype", which respects both the
>"sequential_ordering" protoco
> One problem with styled text is deciding how far you
> go with feature support. If you're not careful, you
> can end up trying to embed an entire word processor
> into the GUI library.
Yes.
> Nowadays I suppose HTML is the obvious way?
It's certainly the wxWidgets, AJAX, and Java/Swing way.
B
Antoine Pitrou wrote:
> button = gui.Button(...)
> button.on_clicked += my_on_clicked_button
> Has anyone had any experience with this idiom? Are there any drawbacks?
> It looks more elegant than inheritance and overriding methods to me.
PyGUI currently has a form of this, except that you
only g
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.
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'
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.
> If I understand your proposal correctly, this approach doesn't do anything
> beyond what Java does, and is inferior to already-available adaptation and
> interface systems for today's Python.
Inferior is in the eye of the beholder, I suppose. This is what
Python 2.x already provides.
> this
54 matches
Mail list logo
