anygui-devel — Discussions about the development of the Anygui package

Re: [Anygui-devel] Moving forward

[Alex M. <al...@ya...>]

"Thomas Heller" <tho...@io...> writes:
    ...
> So far this has of course only a little to do with
> anygui, but maybe could serve some purposes for
> discussion.
> Should I check it in here?
> Say, in a $CVSROOT/nondist/sandbox/mswgui directory?

Sure, why not.

> Further I find it very useful to have checkin messages
> sent to a mailing list (like it is done for Python).
> If we agree, Magnus can set up a anygui-checkins
> mailing list, and I would be willing to set up
> syncmail in CVSROOT (having done this before).

Great!

> Is someone else working on another (Tkinter or wxPython)
> interface to anygui, or do we have to discuss the API
> more?

I'm supposed to be looking at Greg's code and writing
an "empty" nullgui with docstrings and all incorporating
(a strawman-version of) the discussion so far.  So far
I only have a "Mixins.py" that includes the attribute
setting mixin and a reworked Action mixin class -- and
I found out I can't access CVS from this WinNT machine
behind a firewall.  I'm sure I made it once, but I forget
how, they have 'upgraded' (!) the firewall since then,
and I don't even seem to have WinCVS around any more.
Looks like I'm quite effectively cut-off from CVS'ing.

Anybody has suggestions...?  For now I could mail my
stuff to somebody, but I guess I'd better become able
to interact with CVS more normally, pretty soon...


Alex

Re: [Anygui-devel] property-idioms and BDF*'s (was Re: A simpler API?)

[Magnus L. H. <ml...@id...>]

From: "Thomas Heller" <tho...@io...>
>
> Additional thought:
> Suppose a Checkbox, which will probably have a 'on'
> attribute, or a window having a 'visible' attribute -
> setting this attribute will trigger the corresponding
> visual action.
> On the other hand, think of a Listbox having a 'list'
> attribute containing items to display.
> listbox.list = [1, 2, 3, 4, 5] works fine,
> but listbox.list += [6, 7, 8]
> or listbox.list = listbox.list + [6, 7, 8]
> will probably do too much work,
> and listbox.list.extend(6, 7, 8) will
> show the problems.
> 
> I very much prefer using native python datatypes
> as 'model' displayed by the widgets.
> Thoughts?

What about having listbox.list = [1, 2, 3, 4, 5] putting
some wrapping around the list, so that listbox.list returns
a UserList of some sort? Then the extensions etc. won't
be problematic... Right? OK - you won't have native lists
in there, but it will look a lot like it to the user
of the API...

> Thomas


--

  Magnus Lie Hetland         http://www.hetland.org

 "Reality is that which, when you stop believing in
  it, doesn't go away."           -- Philip K. Dick

[Anygui-devel] Moving forward

[Thomas H. <tho...@io...>]

I'm currently playing with a 'native windows' gui
on top of Mark Hammond's win32all extensions,
mainly the win32api and the win32gui modules.

The API is loosely modeled after Greg's pygui.

So far this has of course only a little to do with
anygui, but maybe could serve some purposes for
discussion.
Should I check it in here?
Say, in a $CVSROOT/nondist/sandbox/mswgui directory?

Further I find it very useful to have checkin messages
sent to a mailing list (like it is done for Python).
If we agree, Magnus can set up a anygui-checkins
mailing list, and I would be willing to set up
syncmail in CVSROOT (having done this before).

Is someone else working on another (Tkinter or wxPython)
interface to anygui, or do we have to discuss the API
more?

Would certainly be nice to have more code...

Thomas

Re: [Anygui-devel] property-idioms and BDF*'s (was Re: A simpler API?)

[Thomas H. <tho...@io...>]

> Thomas Heller:
> > > Also, when the setter has noticeable side effects
> > > (as many do in my GUI) I'm not sure I like the
> > > idea of hiding them behind what looks like an
> > > ordinary attribute assignment.
> 
> Well... I guess I just don't quite agree with you
> on that.
Note the additional quoting level above. It was not _my_
opinion, it was Greg or Robin IIRC.

For me the __getattr__/__setattr__ solution is fine.

Additional thought:
Suppose a Checkbox, which will probably have a 'on'
attribute, or a window having a 'visible' attribute -
setting this attribute will trigger the corresponding
visual action.
On the other hand, think of a Listbox having a 'list'
attribute containing items to display.
listbox.list = [1, 2, 3, 4, 5] works fine,
but listbox.list += [6, 7, 8]
or listbox.list = listbox.list + [6, 7, 8]
will probably do too much work,
and listbox.list.extend(6, 7, 8) will
show the problems.

I very much prefer using native python datatypes
as 'model' displayed by the widgets.
Thoughts?

Thomas

Re: [Anygui-devel] pygui

[Amardeep S. <ama...@tc...>]

On Wed, 4 Jul 2001, Greg Ewing wrote:

> Thomas Heller <tho...@io...>:
>
> > How (according to his API) can I make the window
> > behave modally?
>
> Currently, you can't :-(.
>

i am not sure which one you are talking about. but a window can either
be system modal, or application modal. and as far as i know system modal
windows(which would block the whole interface)  are considered evil, and
application modal (which would block only that application ui) is the
current trend atleast in windows, gnome and kde.


> If you look at the Confirm3 class in Alerts.py, you'll
> get some idea of how it will eventually be done, but
> it's not quite there yet. If I remember correctly, the
> plan was to pass a window parameter to the handle_one_event
> method, which would then ignore any input events not directed
> at that window.
>
> It's a bit tricky to get this working properly under X,
> which is probably why I haven't done it yet. (I *don't*
> want to do it by grabbing the display, because I have
> deep philosophical objections to allowing any application
> to take control of the entire UI of a multitasking machine...)
>
> Greg Ewing, Computer Science Dept, +--------------------------------------+
> University of Canterbury,	   | A citizen of NewZealandCorp, a	  |
> Christchurch, New Zealand	   | wholly-owned subsidiary of USA Inc.  |
> gr...@co...	   +--------------------------------------+
>
> _______________________________________________
> Anygui-devel mailing list
> Any...@li...
> http://lists.sourceforge.net/lists/listinfo/anygui-devel
>

-- 
-------------------------------------------------------------
amardeep singh
iit  guwahati
iam...@ya...

Re: [Anygui-devel] Fw: [pythoncard] pyui

[Alex M. <al...@ya...>]

"Magnus Lie Hetland" <ml...@id...> writes:
    ...
> Perhaps this API could be interesting for us to look
> at? (Haven't looked too hard yet myself...)

Haven't looked in any depth, but it has 5 different
layout manager classes, widgets including SplitterPanel
and TabbedPanel, etc -- i.e., maybe a tad too rich
to model anygui on it, if that's what you mean.  As
a target for an anygui backend, I guess it should be
fine (net of the "callback when menu opens" issue --
haven't checked that out).


Alex

Re: [Anygui-devel] property-idioms and BDF*'s (was Re: A simpler API?)

[Magnus L. H. <ml...@id...>]

From: "Alex Martelli" <al...@ya...>
[...]
> "SuperFancy" has an extra overhead of over 1 second
> for 100,000 attribute-settings over "WithSetter" when
> the inst.foo=23 form is used.  That's over 11 microseconds
> each time an attribute does get set this way.

Hm...

> Is this relevant?  Personally, I would tend not to worry
> (premature optimization being the root of all evil),

I tend to agree. (Then again, it seems I generally tend
to agree with Alex <wink>)

> most particularly since, _internally_, I know I can always
> go back to calling self._set_foo(23), slashing overhead
> to 1 microsecond or less -- and I keep around the 
> generic .set() method and init-on-construction, so the
> amount of whatever.foo=23 in bottlenecks from client-code
> seems unlikely to be a worry.

These seem like very strong arguments against worrying, IMO.

Thomas Heller:
> > Also, when the setter has noticeable side effects
> > (as many do in my GUI) I'm not sure I like the
> > idea of hiding them behind what looks like an
> > ordinary attribute assignment.

Well... I guess I just don't quite agree with you
on that. It's just like having an object behaving like
a spreadsheet (e.g.) - you change a value, and then
things dependent on that value change
automati{c/g}ally. In languages where this cannot
be done (e.g. Java), I think accessors are a great
idea. But (as mentioned before) I must say I was
relieved to see the frame.size = (x,y) in JPython/AWT.

> but is NOT a good idea
> where names are equal -- .foo() vs .set_foo(value) is
> unpleasantly dissymmetric -- etc.

Agreed.

> I think this project needs a BDFAW
> (Benevolent Dictator For A While) to take this sort
> of architectural decisions and the responsibilities
> of "project ownership".  Magnus Lie Hetland is the
> obvious candidate, and I hereby nominate him.  Do I
> hear a second?

Thomas Heller:
> Seconded.

Thanks. I'll take "A While" to mean "until there is
a majority for someone else", then <wink>.

Alex Martelli:
> A BDF* can listen to all pro's & con's and
> take (at least temporary) decisions to keep things
> moving forward.

Given the current arguments, I'll have to go with
__getattr__/__setattr__. This is a "gut" thing, so
if there are more arguments (or strong feelings) I'm
open to that... (i.e. not necesserily a "final ruling"
<wink>)

The reasoning on my part is, I guess, as follows:

1. "foo.bar" and "foo.bar = baz" are syntactically
"clean" and obvious ways of setting/getting attributes.
Adding methods for this seems a bit cluttered to me.

2. If the side-effects of assignments are spelled out
clearly in the docs, I don't think they will be
confusing. Also, it is only a matter of maintaining
object intergrity - most people should (after a while)
understand that window.size = (300,200) would set the
size of a window to (300,200).

3. Alex has pointed out that the overhead need not be
too great if one continues to use accessors internally.
(If there are other views on this, please speak up.)
I don't think performance is of central importance to
anygui, just as richness of the widget set isn't. So
if the performance is something we can live with, I don't
think it needs to be optimal. To me, the API itself
is more important, which (in some sense) makes this a
question of aesthetics.

... and the aesthetics part is largely a matter of
taste, I guess (as the priorities will be). If Greg
feels that we are 'raping' his API design, I think
that is a reason to reconsider. (Although, if we
are to have accessors, I think we should have a
get/set pair, rather than a foo/get_foo pair.)

So, in the interesting of expedience and pracmatics
I'll give a preliminary pronouncement (god, I feel
pompous <wink>) to the effect that we will use
__getattr__/__setattr__. I encourage people who have
strong reactions to this to speak up. (Strong reactions
are often important in finding good solutions, IMO.)
Then, in a little while (not too long), I (or whoever
might have claimed my temporary title by then) will
make a more permanent pronouncement - but still only
pertaining to the first release! I think it is absolutely
feasible to change this in a later release, if it
turns out to be a Bad Decision (tm).

> But if Thomas or Greg or Robin want the post,
> that would be fine with me too, as long as we do have
> one hand at the helm.

Sure. Just show up with torches and pitchforks :)

> Alex

P.S: I have a strong tendency to favour consistency
and simplicity, often to the extreme (leading to lots
of silly suggestions being beaten down by Guido,
for instance ;). My love for __setattr__/__getattr__
may be a case of this...

--

  Magnus Lie Hetland         http://www.hetland.org

 "Reality is that which, when you stop believing in
  it, doesn't go away."           -- Philip K. Dick

[Anygui-devel] Fw: [pythoncard] pyui

[Magnus L. H. <ml...@id...>]

Perhaps this API could be interesting for us to look
at? (Haven't looked too hard yet myself...)

--

  Magnus Lie Hetland         http://www.hetland.org

 "Reality is that which, when you stop believing in
  it, doesn't go away."           -- Philip K. Dick

----- Original Message -----
From: "John Miller" <jm...@um...>
To: <pyt...@ya...>
Sent: Wednesday, July 04, 2001 1:45 AM
Subject: [pythoncard] pyui


> I've just become aware of a project that appears to have quite a bit of
> relevance to pythoncard, namely pyui:
>
> http://pyui.sourceforge.net/
>
> What's interesting is that it uses SDL (Simple DirectMedia Layer:
> http://www.libsdl.org/) as its 'graphics engine' (by way of the pygame
> project: http://www.pygame.org). The reason this may be important is
> that it seems that the MacOS (both 9 & X) are supported. I'm really not
> able to evaluate how appropriate pyui would be for pythoncard, so I
> hope someone more able can. The site says pyui features:
>
> *A set of useful GUI widgets including buttons, list boxes, menus, and
> scrollbars
> *Windows with double-buffered drawing, resizability, movability, and
> transparency
> *An extensible event system for interacting with the user interface
> *An interactive python console window
> *Layout managers similar to the Java Swing layout managers
> *Easy integration with pygame/SDL
>
> My guess is that widget robustness isn't on par with wxWindows, but
> trading this for true cross-platform support may well be worthwhile.
>
> At the very least, since I don't recall this project being mentioned in
> this forum, I wanted to make people aware of it and perhaps raise some
> discussion of it...
>
> John Miller
>
>
>
> To unsubscribe from this group, send an email to:
> pyt...@ya...
>
>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>

Re: [Anygui-devel] property-idioms and BDF*'s (was Re: A simpler API?)

[Thomas H. <tho...@io...>]

I think this project needs a BDFAW
> (Benevolent Dictator For A While) to take this sort
> of architectural decisions and the responsibilities
> of "project ownership".  Magnus Lie Hetland is the
> obvious candidate, and I hereby nominate him.  Do I
> hear a second?
Seconded.

Thomas

[Anygui-devel] property-idioms and BDF*'s (was Re: A simpler API?)

[Alex M. <al...@ya...>]

"Greg Ewing" <gr...@co...> writes:

> > Why not just
> > foo to read, foo=whatever to write?
> 
> Intercepting these in Python incurs substantial
> overhead, particularly when setting, in which case
> the overhead is incurred for *all* attribute
> assignments, not just the ones you want to
> intercept.

True.  For example, on this desperately-old box
(PII-266 & NT4...!):

import time

class Plain:
    pass

class WithSetter:
    def set_foo(self, value):
        self.foo = value

class Fancy:
    def __setattr__(self, name, value):
        self.__dict__[name] = value

class SuperFancy:
    def set_foo(self, value):
        self.__dict__['foo'] = value
    def __setattr__(self, name, value):
        if name=='foo': self.set_foo(value)
        else: self.__dict__[name] = value

def timesetting(klass, n):
    start = time.clock()
    inst = klass()
    for i in range(n):
        inst.foo = 23
    stend = time.clock()
    return klass.__name__,stend-start

def x_timesetting(klass, n):
    start = time.clock()
    inst = klass()
    for i in range(n):
        inst.set_foo(23)
    stend = time.clock()
    return 'X'+klass.__name__,stend-start

for i in range(3):
    print "%12s %4.3f"%timesetting(Plain, 100000)
    print "%12s %4.3f"%x_timesetting(WithSetter, 100000)
    print "%12s %4.3f"%timesetting(Fancy, 100000)
    print "%12s %4.3f"%x_timesetting(SuperFancy, 100000)
    print "%12s %4.3f"%timesetting(SuperFancy, 100000)
    print


D:\pygui>python -O timte.py
       Plain 0.212
 XWithSetter 0.589
       Fancy 0.910
 XSuperFancy 0.697
  SuperFancy 1.725

       Plain 0.212
 XWithSetter 0.592
       Fancy 0.908
 XSuperFancy 0.697
  SuperFancy 1.724

       Plain 0.213
 XWithSetter 0.596
       Fancy 0.908
 XSuperFancy 0.696
  SuperFancy 1.719


"SuperFancy" has an extra overhead of over 1 second
for 100,000 attribute-settings over "WithSetter" when
the inst.foo=23 form is used.  That's over 11 microseconds
each time an attribute does get set this way.  (A
decent today's box of course would be 4-5 times faster
than this old codger on this just like on any other
task, but that's partly why I like measuring on this
golden oldie -- it amplifies tiny differences!-).

Is this relevant?  Personally, I would tend not to worry
(premature optimization being the root of all evil), most
particularly since, _internally_, I know I can always
go back to calling self._set_foo(23), slashing overhead
to 1 microsecond or less -- and I keep around the 
generic .set() method and init-on-construction, so the
amount of whatever.foo=23 in bottlenecks from client-code
seems unlikely to be a worry.


> Also, when the setter has noticeable side effects
> (as many do in my GUI) I'm not sure I like the
> idea of hiding them behind what looks like an
> ordinary attribute assignment.

I was very wary of this when it was novel to me (back
when I tried out Delphi, if I recall correctly) and
still eschew it firmly in C++ (where both Borland and
Microsoft offer it as an extension since many years)
since it violates the language's standards.  But there
are plenty of languages where "properties" are quite
idiomatic (Delphi, Visual Basic, Javascript, Eiffel...
it's a cross-language idiom in COM, and thus I would be
surprised if XPCOM lacked it, etc).  And I have noticed
that young programmers, who lack the acculturation of
20+ years of procedural programming and think naturally
in OO terms because they've never been exposed to any
other, take to this like ducks to water -- *of course*
fee.fie=foo may be implicitly invoking some code in fee,
they claim when I try to get them to articulate why,
since *obviously* fee is responsible for its integrity
(some say "its class invariants" or other synonyms) how 
could it possibly be otherwise?

So they chafe mildly under (what they see as) the syntax
overhead of .getFoo(), .setFoo(value) in Java, which
uniformly uses that pair of names -- probably the best
choice if one MUST have explicit calls to accessor and
mutators... other choices seem to do even worse, and I
see why, e.g .foo() to read and .foo(value) to write
may work in Smalltalk where the message is actually
differently-named, foo vs foo:, but is NOT a good idea
where names are equal -- .foo() vs .set_foo(value) is
unpleasantly dissymmetric -- etc.

Over the years I've grown to understand their stance,
I think.  And it seems to me that they are right, and
that Python lets us offer "properties" (when needed),
i.e. implicit call of some method on attributes being
set, with a reasonable cost.  I do understand the
opposite stance, since I've held it for so long (and
STILL defend it in the specific case of C++, for
portability reasons!), but I think it IS a better
choice to move on, towards the brave new world of
'properties'.


Still, I _can_ live (albeit chafing a bit:-) with a
different choice.  I think this project needs a BDFAW
(Benevolent Dictator For A While) to take this sort
of architectural decisions and the responsibilities
of "project ownership".  Magnus Lie Hetland is the
obvious candidate, and I hereby nominate him.  Do I
hear a second?  Thesis: SIG's often get bogged down
for lack of a BDF* -- when consensus cannot be reached,
perhaps on secondary issues, progress slows down or
stops.  A BDF* can listen to all pro's & con's and
take (at least temporary) decisions to keep things
moving forward.  Magnus is an effective, pragmatical
person; he originated this group/project/whatever;
he's motivated to get one 'strawman' release out FAST,
and maybe correct things later in the light of whatever
experience/feedback, which seems just the right track
to me.  But if Thomas or Greg or Robin want the post,
that would be fine with me too, as long as we do have
one hand at the helm.


Alex

Re: [Anygui-devel] A simpler API?

[Thomas H. <tho...@io...>]

> > Why not just
> > foo to read, foo=whatever to write?
> 
> Intercepting these in Python incurs substantial
> overhead, particularly when setting, in which case
> the overhead is incurred for *all* attribute
> assignments, not just the ones you want to
> intercept.
Question is if this overhead is large enough
to be noticeable. Not for me so far...

> Also, when the setter has noticeable side effects
> (as many do in my GUI) I'm not sure I like the
> idea of hiding them behind what looks like an
> ordinary attribute assignment.

It might be confusing or appear too magic,
but so far I certainly like it.

Thomas

Re: [Anygui-devel] pygui

[Thomas H. <tho...@io...>]

> Thomas Heller <tho...@io...>:
> 
> > How (according to his API) can I make the window
> > behave modally?
> 
> Currently, you can't :-(.
> 
> If you look at the Confirm3 class in Alerts.py, you'll
> get some idea of how it will eventually be done, but
> it's not quite there yet. If I remember correctly, the
> plan was to pass a window parameter to the handle_one_event
> method, which would then ignore any input events not directed
> at that window.
> 
> It's a bit tricky to get this working properly under X,
> which is probably why I haven't done it yet. (I *don't*
> want to do it by grabbing the display, because I have
> deep philosophical objections to allowing any application
> to take control of the entire UI of a multitasking machine...)

I don't really know what I'm talking about here, but (judging
from experimentation with Netscape under Linux, there _are_
windows behaving modally without grabbing the whole display).

On MS Windows it's probably totally different: A modal Dialogbox
'automatically' disables it's owner window while it's open...

Thomas

PS: Greg, any hints about how to build pygui on Linux?
Didn't work for me, but I a total linux newbie.

Re: [Anygui-devel] A simpler API?

[Robin D. <ro...@wx...>]

> > Why not just
> > foo to read, foo=whatever to write?
>
> Intercepting these in Python incurs substantial
> overhead, particularly when setting, in which case
> the overhead is incurred for *all* attribute
> assignments, not just the ones you want to
> intercept.
>
> Also, when the setter has noticeable side effects
> (as many do in my GUI) I'm not sure I like the
> idea of hiding them behind what looks like an
> ordinary attribute assignment.

I released an experimental version of wxPython last year sometime that
implemented magic properties like this.  The overwhelming consensus of the
wxPython users was to get rid of it, primarily because it wasn't obvious
that more than just an attribute access was happening (newbie confusion) and
also because it broke a lot of people's existing code, which wouldn't be a
problem in this case of course.

--
Robin Dunn
Software Craftsman
ro...@Al...       Java give you jitters?
http://wxPython.org      Relax with wxPython!

Re: [Anygui-devel] pygui

[Greg E. <gr...@co...>]

Thomas Heller <tho...@io...>:

> How (according to his API) can I make the window
> behave modally?

Currently, you can't :-(.

If you look at the Confirm3 class in Alerts.py, you'll
get some idea of how it will eventually be done, but
it's not quite there yet. If I remember correctly, the
plan was to pass a window parameter to the handle_one_event
method, which would then ignore any input events not directed
at that window.

It's a bit tricky to get this working properly under X,
which is probably why I haven't done it yet. (I *don't*
want to do it by grabbing the display, because I have
deep philosophical objections to allowing any application
to take control of the entire UI of a multitasking machine...)

Greg Ewing, Computer Science Dept, +--------------------------------------+
University of Canterbury,	   | A citizen of NewZealandCorp, a	  |
Christchurch, New Zealand	   | wholly-owned subsidiary of USA Inc.  |
gr...@co...	   +--------------------------------------+

Re: [Anygui-devel] A simpler API?

[Greg E. <gr...@co...>]

> Why not just
> foo to read, foo=whatever to write?

Intercepting these in Python incurs substantial
overhead, particularly when setting, in which case
the overhead is incurred for *all* attribute
assignments, not just the ones you want to
intercept.

Also, when the setter has noticeable side effects
(as many do in my GUI) I'm not sure I like the
idea of hiding them behind what looks like an
ordinary attribute assignment.

Greg Ewing, Computer Science Dept, +--------------------------------------+
University of Canterbury,	   | A citizen of NewZealandCorp, a	  |
Christchurch, New Zealand	   | wholly-owned subsidiary of USA Inc.  |
gr...@co...	   +--------------------------------------+

Re: [Anygui-devel] A simpler API?

[Alex M. <al...@ya...>]

"Thomas Heller" <tho...@io...> writes:
    ...
> > B. why accessors/mutators?
> > 
> > Why foo() to read, set_foo() to write?  (I do like
    ...
> Which is the pattern to use? Something like this:
> 
> class Mixin:
>     def __setattr__(self, name, value):
>         try:
>             setter = getattr(self, '_set_' + name)
>         except AttributeError:
>             # no setting method
>             self.__dict__[name] = value

This latter might interfere with an accessor -- the
accessor would not be called if name is found in
the __dict__.  I don't know if we need to support
attributes having an accessor but no mutator --
but it seems a natural way to model read-only
attributes.  Therefore we might want something
like:

    def __setattr__(self, name, value):
        getattr(self, '_set_'+name, _setany)(name, value)
    def _setany(self, name, value):
        if getattr(self, '_get_'+name, 0):
            raise AttributeError, "%s is read-only"%name
        self.__dict__[name]=value
    def __getattr__(self, name, value):
        try: return getattr(self,'_get_'+name)()
        except AttributeError: raise AttributeError,name

This has the slight disadvantage that all _set_*() methods
should accept a redundant name for signature uniformity
with _setany.  Maybe better therefore to go back to
something closer to your scheme giving up the _setany...:
    def __setattr__(self, name, value):
        try: setter=getattr(self, '_set_'+name)
        except AttributeError:
            if getattr(self, '_get_'+name, 0):
                raise AttributeError, "%s is read-only"%name
            self.__dict__[name]=value
        else: setter(value)

>         else:
>             # let the setting method do it
>             setter(name, value)

I don't think the name needs to be passed, and
indeed:

> class Window(..., Mixin):
>     def _set_width(self, value):

...you're not passing it here, which seemse sensible.

>         # intercept the 'width' attribute
>         self.__dict__['width'] = value
>         if self.is_realized():
>             self.resize(self.width, self.height)

Seems nice to me!


Alex



_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com

Re: [Anygui-devel] Some import magic checked in

[Thomas H. <tho...@io...>]

> > - Last but not least: for obvious reasons I'm
> > against too much import magic - the whole
> > stuff should be compatible with py2exe and
> > installer.
> 
> Couldn't we fool it somehow?
Sure.
I will do this later. Not too important at the moment.

What _is_ important at the moment ;-) is feedback on the
questions I've asked (and will ask soon), because
I'm currently playing with mswgui (or however this will be called).

Thomas

Re: [Anygui-devel] A simpler API?

[Magnus L. H. <ml...@id...>]

From: "Alex Martelli" <al...@ya...>
>

> But when an "API call" actually affects the Model (i.e., is
> interesting for undo/redo purposes) we need to 'snapshot' the
> Model's state in either "incremental difference" terms, or,
> when that is feasible and easier, as a complete persisted
> state.

Hm. I never did read that pattern from the pattern book (Gamma
et al) too thoroughly, but I think the point is to use
Action objects that can modify the model both ways, i.e.
the action can undo itself. If all modifications are done
through such actions (events) then Bob's your uncle
(or something).

> Since the semantics of Model state are totally up to
> the application (and the programmer thereof), how can this
> be "transparent"?

See above. May not be feasible - I don't know.

> > > What gui-toolkit makes undo/redo "trasparent" to the
> > > application...?
> > 
> > Not the application - the programmer. Somewhat like ZODB makes
> > storage "transparent".
> 
> I think I still don't get it.

Well... If you still don't get it after my explanation above,
I may simple be wrong :)

> The best undo/redo support I can think of [...]

You shouldn't have to store the state explicitly... If I press
a key when in a text field, a "key down" event or whatever
is sent, possibly translated into an "insert letter x in
field y at position z" action. This is performed, and put
into the undo-queue/stack. If I later want to undo it, it
is performed in reverse (every action would need how to
reverse itself, or signal that it cannot be undone), i.e.
"remove character from position z in field y".

Perhaps I should take a look at the original pattern again...
Except that I've got all my books packed in boxes because
I'm moving to a new office... :)

> But, "transparent"...?  Am I missing some
> tweak that would allow that...?

It seems you missed my point altogether. It may not be
a valid one, but nonetheless... ;)

> 
> Alex
> 

--

  Magnus Lie Hetland         http://www.hetland.org

 "Reality is that which, when you stop believing in
  it, doesn't go away."           -- Philip K. Dick

[Anygui-devel] Duplication

[Magnus L. H. <ml...@id...>]

Hi!

Please - if you send a mail to the list, there is no
need to send me a copy. I keep getting everything
doubled... :)

--

  Magnus Lie Hetland         http://www.hetland.org

 "Reality is that which, when you stop believing in
  it, doesn't go away."           -- Philip K. Dick

Re: [Anygui-devel] Some import magic checked in

[Magnus L. H. <ml...@id...>]

From: "Thomas Heller" <tho...@io...>


> - Last but not least: for obvious reasons I'm
> against too much import magic - the whole
> stuff should be compatible with py2exe and
> installer.

Couldn't we fool it somehow? I haven't read the
py2exe docs, but perhaps something like

"""
import wxgui, javagui, whatevergui
"""

?

If we can fool it one way - why not the other?

> Thomas

--

  Magnus Lie Hetland         http://www.hetland.org

 "Reality is that which, when you stop believing in
  it, doesn't go away."           -- Philip K. Dick

Re: [Anygui-devel] A simpler API?

[Thomas H. <tho...@io...>]

> B. why accessors/mutators?
> 
> Why foo() to read, set_foo() to write?  (I do like
> the slight, very-handy redundancy of kw args for set
> in constructors and the .set() method).  Why not just
> foo to read, foo=whatever to write?  It's simpler and
> more Pythonic for the client and it's NOT a big trouble
> for us to have a single mixin class translating this
> Pythonic access-style to method calls in __getattr__
> and __setattr__.  I'm definitely -1 on the foo()/set_foo()
> choice -- and while I'm not a GUI expert, I _am_ an OO
> expert and have strong feelings in the matter:-).
> 
Which is the pattern to use? Something like this:

class Mixin:
    def __setattr__(self, name, value):
        try:
            setter = getattr(self, '_set_' + name)
        except AttributeError:
            # no setting method
            self.__dict__[name] = value
        else:
            # let the setting method do it
            setter(name, value)

class Window(..., Mixin):
    def _set_width(self, value):
        # intercept the 'width' attribute
        self.__dict__['width'] = value
        if self.is_realized():
            self.resize(self.width, self.height)

Thomas

Re: [Anygui-devel] Some import magic checked in

[Thomas H. <tho...@io...>]

> "Thomas Heller" <tho...@io...> writes:
>     ...
> > - Compatibility with older python versions
> > is (usually) cheap.
> 
> This is like saying: all the enhancements made in the
> language and libraries over the last 2 years (or more;
> 1.5.2 has been out a LONG time) are of little use.  I
> disagree.
Ok, I give up.
anygui will require Python2.1.

Thomas

Re: [Anygui-devel] Some import magic checked in

[Alex M. <al...@ya...>]

"Thomas Heller" <tho...@io...> writes:
    ...
> - Compatibility with older python versions
> is (usually) cheap.

This is like saying: all the enhancements made in the
language and libraries over the last 2 years (or more;
1.5.2 has been out a LONG time) are of little use.  I
disagree.

But even apart from that, what about the cost for me of 
downloading 1.5.2, installing it (making sure it coexists 
with my existing 2.1 and cvs-2.2 installations), brushing 
up on all the differences so as to try and not use 
anything that differs, and then trying every test N
times (what versions do we have to support?  1.5.2,
2.0, 2.0.1, 2.1, 2.1.1 -- can we skip 1.6 and 1.6.1,
and if so, WHY?).

I can see a huge amount of wasted working hours even
in the *prospect* of trouble from any of these aspect.
"cheap"?  In *WHAT* unit of measure?  Not in hours,
and particularly not in hours weighted by fun -- to
design, develop, document, &c, is fun, but I find
system administration issues such as installing old
releases and try to make them live together with new
ones *NO* fun whatsobloodyever.

And the same goes for the effort of finding out what
I can or cannot do under half a dozen versions (1.5.2
up to 2.1.1).  Lots of potential for time wasting,
finding out where/when the docs saying that this
argument needs to be a function/list/dictionary were
actually right and where/when it could be any callable/
sequence/mapping instead, for example.  Bad enough to
have to do it for one version.

And *where's the return*?  If somebody's using 1.5.2,
their constraints and/or preferences are to avoid
major upgrades -- they're running a 3-yo package with
many know bugs rather than upgrade.  So they're very
unlikely to install a completely new package -- they're
probably happy with Tkinter anyway.


> - If we want to give up on compatibility, I would
> certainly like some motivation - list comprehensions
> are cool, string methods are nice, we absolutely need
> weak refs (or generators) - something like that.
> But we may disagree here.

Exactly.  Why should I go to the bother of listing
a zillion differences which I find useful just to
have you tell me that you disagree on this, that,
and the other?


> - Last but not least: for obvious reasons I'm
> against too much import magic - the whole
> stuff should be compatible with py2exe and
> installer.

I agree that applications written to the anygui
API should be reasonably packageable with py2exe
and installer, with or without the underlying
GUI toolkit (presumably being able to _avoid_
fixing an underlying GUI toolkit is often going
to be the motive for going with anygui, so there
should be an option to avoid packaging the specific
GUIkit the author is using -- particularly given
how huge some kits can be -- as well as also of
including a specific kit).  But this seems to me
to suggest that whatever import magic turns out to
be necessary has to be well-documented, and most
specifically in terms of what to feed distutils
(and py2exe) and/or installer to ensure packaging
either with or without some underlyign kit works;
not necessarily of avoiding import magic altogether.


Alex

[Anygui-devel] pygui

[Thomas H. <tho...@io...>]

Regarding Greg's pygui:
Has anybody got it to work?
I've (under Suse Linux) hacked the Makefile a little
bit so that it compiles, but it doesn't produce anything
but core dumps.

Dialogs in pygui:
Class Window has a style property, which
can be set to 'standard', 'modal_dialog', and
'nonmodal_dialog'. This, however, does only
affect the windows appearance, but does not
make the window behave modally.
How (according to his API) can I make the window
behave modally?

Thomas

Re: [Anygui-devel] A simpler API?

[Alex M. <al...@ya...>]

"Magnus Lie Hetland" <ml...@id...> writes:
    ...
> > > I think so. But I would love to have undo/redo as a (transparent)
> > > part of anygui some day. And it _could_ be interwoven with the
> > > event system, right?
> > 
> > Yes, it could, in that requests to undo/redo could come in
> > as events (and non-undoable/redoable changes could disable
> > the relevant menuitem &c), but I'm not sure what you mean
> > by "transparent" in this context.
> 
> Oh, right. Just that all the API calls are stored in a
> (finitely sized) queue of some sort, and that you can undo/redo
> yourself back and forth... And that the user of anygui need not
> do anything special to achieve that.

But when an "API call" actually affects the Model (i.e., is
interesting for undo/redo purposes) we need to 'snapshot' the
Model's state in either "incremental difference" terms, or,
when that is feasible and easier, as a complete persisted
state.  Since the semantics of Model state are totally up to
the application (and the programmer thereof), how can this
be "transparent"?


> > What gui-toolkit makes undo/redo "trasparent" to the
> > application...?
> 
> Not the application - the programmer. Somewhat like ZODB makes
> storage "transparent".

I think I still don't get it.  The best undo/redo support I
can think of receiving from a framework is still anything but
transparent to me as a programmer, to wit: when a Model is
about to change its state, it can record on the framework's
queue a Memo object which includes callbacks to perform for
Undo and Redo of this particular change (and possibly some
auxiliary info, such as what to show on an "Undo Menu" if the
GUI offers that, "Undo Insert" vs "Undo Delete" &c, whether
the change _is_ undoable at all, that sort of thing).  The
framework can then take care of where to hold the queue and
its items, when to flush it (because saved changes are not
undoable anymore, for example), etc.

But I still wouldn't call this at all "transparent" since
the application programmer is left with the task of getting
the 'Memo object' right.  In API terms it's almost trivial,
as the Memo could be an optional argument to the Model's
"changed()" method -- besides setting the isChanged flag,
the method would presumably communicate suitably with the
framework (so e.g. if changed() is called without args, the
FW knows the change is not undoable and therefore any
undoable changes that might have been queued could be
flushed, etc).  But, "transparent"...?  Am I missing some
tweak that would allow that...?


Alex