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

Re: [Anygui-devel] A simpler API?

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

"Magnus Lie Hetland" <ml...@id...> writes:

> Do we need a simpler API? Just a thought... My

Yes, for all reasons you list.  But maybe we should
also take a step back and evidence all the specific
design decisions in Greg's excellent API, just so we
are sure they're optimal for out purposes rather than
just accepting them by default.  Starting from the
start...:

> I'll try to think about what we _really_ need for
> a 0.1-release... I hope someone else will too :)

Right -- I'm doing so, therefore I put my reflections
on the list for everybody to share and comment.


One general reflection first... Greg's excellent spec
is designed as stand-alone.  anygui is intended to be
often just a "cap" on some richer underlying GUI
framework.  Therefore, I think there must be
*architected* ways for client-code of anygui to
determine _which_ underlying GUI framework is in
use AND gain direct access to the underlying-framework
objects that anygui is internally using.  This will
enable an interesting usage pattern: program to
anygui for minimal GUI functionality, fully portable
and close to hassle-free -- then add nice-to-have
tweaks if and only if the actual underlying is, say,
wxPython (or whatever the client-code author knows
well and wants to support first and foremost).

I'm not sure of where this "query/access the underlying
stratum" is best placed, architecturally -- global
functions of a dedicated control module, probably --
maybe a property on each object returning an "underlying
framework object" or tuple thereof.  A given backend to
anygui may respond None to such requests, meaning "I'm
not gonna tell you (as there's nothing good you could
do with it anyway)" or similar.  But an architected way
to pose the questions is what seems important to me
right now.


OK, now for some specific issues/doubts/objections...:


A. why document/view?

I agree we need some organizing principle in the
overall architecture, but why document/view (or
rather model/view) rather than the classic MVC
(model/view/controller)?  MVC isn't much more
complex after all.  I can live with doc/view, but
I'd like to make sure this is a deliberate design
decision rather than a "just-happened" -- I'm no
GUI expert, it just seems to me that MVC buys you
more for very little cost.

To clarify, the issue is with e.g. this sentence
in the tutorial: "Our View class will have two 
responsibilities: (1) drawing the blobs on the 
screen; (2) handling user input actions".  Why
should one class have two responsibilities, rather
than splitting them -- have the View just care
about viewing, and a separate Controller class
to handle user-input needings mods to the Document?


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:-).

C. event handling

Why not more uniformity between mouse-events, key-events
and command-events?  The latter should not be so tightly
bound (conceptually, terminologically, ...) to menus.  The
highly-dynamic just-in-time determination of enabled
status &c is cool for "local" interfaces where turnaround
can be assumed "instantaneous from the user's viewpoint",
of course.  Although it can give problems for the DHTML
implementation I had in mind, I guess it should still be
kept, for simplicity's sake.  Maybe (perhaps not in the
1st release) we could allow an object to state "please
don't call my setup_menus() until further notice, here
is what I think should be enabled/checkmarked in case
you need to know".  But back to simplicity -- if (command
events) "are handled in a similar way to events", why the
"are not explicitly represented as Event objects"?  What
if any is the down-side of uniformity of representation?
And why are mouse-down events ignored if "the View object 
in which they occur [...] does not handle them", rather
than behaving like others?  Conceptual simplicity for
the client-coder of the anygui interface would seem to
benefit from uniformity here.  Am I missing something?

(I'm also thinking of model_changed "messages" from
models to views, &c.  Shouldn't all of these events be
modeled rather uniformly...?)

Specifically
C1. Event should be generalized to model any kind of
event, not _just_ mouse & keys.  Properties which may
not be determinable (where, when, &c) should be
specified as None.  Also, _which_ button was clicked
(when there's more than one!) must be easily found, and
of course so must "what key was pressed" for key events,
and I don't see either of those clarified in the specs at
Doc\Event.html.

D. Application class
D1. std_menu_bar(): I think we're missing Help as a standard
    command (and probably Redo; but I'm unsure about Revert,
    is that meant to be the Undo-latest-Undo command...?
    but apparently not, given revert_cmd in Document...).
    Hmmm, maybe SelectAll, too?
D2. if we do consider Help standard, a help_cmd() method in
    the Application class to provide some minimal metadata
    about the app (name, version, author's email, &c) in an
    alertbox might be worth it (perhaps providing encouragement
    to client-coders to supply at least such minimal stuff:-)

E. FileRef/DirRef
Do we truly need these new abstractions...?  Couldn't we
do with something simpler/closer to what Python gives us...?

F. Why not SPING for drawing?
Couldn't we somehow reuse the riches in SPING/Piddle rather
    than having a newly-invented, albeit simple, drawing API?
    If the 'native' drawing API of anyguy's Canvas was specified
    as exactly coincident with what a SPING back-end must/can
    expose, wouldn't this be a big overall win?  Client-code would
    draw with SPING (or whatever's on top of it), anygui's implementer
    could be lazy and get away with drawLine/Polygon/Image/String
    OR go hog-wild with quality...
...am I missing something...?

Z. Tiny/nitpicky stuff (not worth discussing at this point
but things I noticed and wondered about while studying...):
Z1. shouldn't a RadioGroup always deal with lists of RadioButton?
    specialcasing everything so that a single RadioButton need
    not be passed as a singleton list seems misplaced, given that
    lists are the common case.  Also, setting value to a value
    that is not of any radiobutton currently in the group should
    presumably be specified to raise ValueError and leave value
    unchanged.  And what happens when remove is called for the
    radiobutton that's currently selected, or when two radiobuttons
    have the same value...?
Z2. Action's 3rd case shouldn't be a generic tuple but specifically
    a tuple with 2 or 3 items -- a callable, then a sequence, then
    optionally as the 3rd item a dictionary of keyword-args -- surely
    this is more general and no less simple than a generic tuple
    (affording no way to 'curry' keyword-args)
Z3. how does setup_menus guess which menu commands are relevant
    to the specific dropdown menu that the user is trying to
    dropdown...?  It doesn't seem to me the MenuState object
    has that info -- am I missing something?  Shouldn't a Menu
    object also be passed to setup_menus...?
Z4. I think TextField should have a method for select-all rather
    than requiring: query text, set selection to (0, len(text)).
    Shouldn't there be a background-color possibility too?
Z5. Shouldn't we have a standard Button-displaying-Pixmap class?
Z6. Shouldn't ScrollFrame expose properties/&c to let client-code
    determine/affect scrollstate?
Z7. I'm not sure I understand Frame.place -- is it just me, or
    is the spec confusing, or...?
Z8. Shouldn't it be possible to 'disable' a button/textfield/...?



Phew -- enough for now I hope... please everybody, feel
free to respond to any subset of this big mail (next time
I'll try to cut it into smaller pieces -- hadn't thought
of that this time, and it's a bit of a hassle to cut it
up now, so...).


Alex

[Anygui-devel] A simpler API?

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

Do we need a simpler API? Just a thought... My
experience from the early days of Piddle development
tells me that a simple API can be a good thing --
to get the project off the ground. If designed
correctly, the small API may be extended at a later
time, yet will be easier to implement quickly.

And a working software package will probably gain
more support than an almost-working one...
Dissatisfied users are a great source of feedback
and volunteer work <0.5 wink>

Another advantage with a simple API is that it will
work with backends such as htmlgui (HTML 4.0 based)
which Alex has been thinking about.

Maybe I'm off the mark -- maybe Greg's API (e.g.)
is simple enough... (It isn't exactly complicated.)
I just thought perhaps we could cut some corners
wrt. (among other things) the menu setup etc...

I'll try to think about what we _really_ need for
a 0.1-release... I hope someone else will too :)

--

  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] Some import magic checked in

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

Hi!

I've made a first attempt at implementing some import
magic for anygui (found in the anygui cvs repository).
Basically, the structure of the package is (currently)
as follows:

  anygui/
    |
    +--- __init__.py
    |
    +--- impl/
           |
           +--- __init__.py
           |
           +--- wxgui.py
           |
           +--- tkgui.py
           |
           +--- ...

The __init__ of the impl directory currently does
nothing (and could probably have been omitted, since
the impl module cannot be imported directly anytay...
See below.)

The various *gui.py files (currently only wxgui.py
and tkgui.py) are (as one might guess) meant tom contain
implementations for the various backends. In addition
to implementing the GUI API they should also provide
a (module-)global boolean variable called "viable",
which indicates whether the backend is viable in the
current Python system. This is used by anygui when
choosing a backend.

In the current version only wxgui.py and tkgui.py exist,
and they only contain dummy implementations of a class
called Window, meant to demonstrate the import mechanism.

The main magic is in the anygui/__init__.py file.
It installs an instance of the class "anygui" instead
of the module (thanks to Alex for this nifty trick).
This makes it possible to intercept module access
through __getattr__. The reason for this is that I
wanted to delay the choice of backend until the user
has had his or her say in the matter. In a way one
might say that the choice of backend is 'lazy' --
it is done at the point where it is needed, where
something is actually imported or used from the
anygui module.

*Before* this happens, the user may set an attribute
in anygui called "wishlist", containing a prioritized
list of backend names. These will be tried (in order)
before any other backends that may exist. If no
wish list is supplied, the default backend list is
used without modification. Some more intelligence
might be needed there -- at the very least some
intelligent ordering of the backends is needed...
The current ordering is:

  1. msw:  Microsoft Windows native
  2. x:    X-Windows native
  3. mac:  Macintosh native
  4. wx:   wxPython
  5. tk:   Tkinter
  6. java: Java

Both abbreviations and backend-selections were just
made off the top of my head. This is more a proof
of concept than anything... :)

Of course, since I only included (dummy) backends for
wx and tk, the others will fail (i.e. not be used).

OK. Enough talk. Here are two examples -- one using
the default order, and one providing a wishlist:

>>> from anygui import *
>>> w = Window('Hello, world!')
>>> w
<C wxFrame instance at _dd0ce8_wxFrame_p>

>>> import anygui
>>> anygui.wishlist = ['tk', 'java', 'mac']
>>> from anygui import *
>>> w = Window('Hello, world!')
>>> w
<tkgui.Window instance at 00DD7EBC>

Now, already in these simple tests I noticed a problem...
It seems that making a Tk window withoug showing it
isn't trivial. (Or it may be trivial -- I'm not really
an expert ;) So these two examples don't behave exactly
the same -- the first produces a hidden window, while
the second opens a Tk main window. Well, well. I'm
sure we'll be able to tackle that.

And another thing... To find the backend modules, I'm
using the traceback module (quite hackish... Any better
ways?) It seems that this doesn't quite work in
Jython 2.1a1 -- that's why I didn't include a javagui.py
for now. (I've submitted a bug-report to the Jython
crew.)

--

  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] Possible problem with Greg's API

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

After reading through the docs on Greg's API, I have
noticed a possible problem: The menu setup phase...
It requires an event to be captured at the point where
the user selects a menu (either by clicking or by
using the keyboard), and to do some processing before
the menu actually appears. I'm not sure how many
backends we'll be able to do that in, except the native
ones (for which the API was originally intended).
I'm not even sure how to do such a thing in Java.
(I don't think mouse events can be intercepted in the
menu bar in AWT... It may be possible in Swing.)

I'm not sure how to handle this - perhaps the
menu setup could be done at the time when the "target"
properties of the widgets were set (i.e. a widget
gets the focus), since there would be no visible
difference to the user (except some processing
every time a widget gets the focus...)

Any thoughts?

--

  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] Design Overview

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

Hi!

I have put together a preliminary design document.

It can be find at the anygui document manager:
https://sourceforge.net/docman/?group_id=30226

Any (constructive ;) comments are welcome.

If anyone wants to be added as developers, just
email me about it. I think what needs doing first
is (1) to decide on the API, and (2) implement an
abstract version of it, which doesn't do anything,
but which contains the necessary infrastructure
etc. so that people can start coding back-ends.

Any takers (for any tasks)? Any opinions?

--

  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] Fw: Mail delivery failed: returning message to sender

[robind <ro...@wx...>]

> > >    Let me know what you think.
> >
> > Looks very interesting. The resource-thing seems good for builder apps,
> > which is nice. But one of my main goals is to make it easy to build
> > GUIs programmatically... Any thoughts on how that should be done/combin=
ed
> > with the resource scheme?

I havn't tried it yet, but everything you can do in the resource format sho=
uld be doable as keywork args to the __init__ method.  My focus for the fir=
st bit was to make the resource format work, but I want it to be generally =
useful as well.

--Robin

P.S.  I'm away for the weekend and only have a terribly slow modem connecti=
on for short bits of time so don't be surprised if I don't answer any other=
 questions for a few days...

[Anygui-devel] Getting started

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

I would like this project to get started as soon as
possible, partly because it seems similar projects
have died slow deaths in the past, and partly because
I may need anygui myself in the near future :)

So, what do we need to get started, assuming that we
have some volunteers (as it seems we have ;) ?

I believe the first thing we need is a clearly designed,
well thought-out API. After an API has been defined,
development on backends may be done completely in
parallel, which is a Good Thing (tm).

Of course, we could use years and years designing a
GUI API, but I'd rather not <wink>. I think Greg's API[1]
seems like a good candidate.

Its design doesn't seem too controversial to me
(in that it should be possible to make people use it :)
What do you think?

And, Robin, how compatible/incompatible do you think
Greg's design is with your generic gui? How much
tweaking (either way) would be necessary to incorporate
the "nice bits" from both, do you think? (I would _really_
like to have you working on the wxPython implementation
of anygui :)

Is the API too simple? Too complex? Does it have features
that may be difficult to implement on some platforms?
Does it offend anyones Pythonic sense of aesthetics?

Any thoughts? Any other candidates?

As for volunteers: Greg is working on an X-windows
(native) implementation for his GUI.
Thomas Heller has volunteered to do a native version
for MS Windows version. It seems that Alex Martelli
might be interested in trying to make a DHTML/HTML
backend, and Robin has already done some work on a
generic GUI based on wxPython. If we can coordinate
this, we already have several platforms. I'm sure
getting someone (like me <wink>) to do a Tkinter
and/or Java AWT/Swing version should be possible as
well. (Native Mac, anyone?)

[1] http://www.cosc.canterbury.ac.nz/~greg/python_gui/

--

  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] What a coincidence...

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

Hi all,

It's quite a coincidence that this group was formed when it was as over in
the PythonCard group formed just last week there has been talk of creating a
generic UI interface that could drive multiple backends.  I got a litte
inspiration on some design patterns for it a few days ago and have just
posted the first results of my little brainstorm.  It's a very rough and
very incomplete generic gui package and a just as rough wxPython backend.
You can see some more info at

    http://groups.yahoo.com/group/pythoncard/message/237

and download it from

    http://alldunn.com/temp/GenericGUI.zip

Let me know what you think.

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

[Anygui-devel] Re: Goals

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

From: Thomas Heller
>
> Should anygui really be only a front end for existing
> GUI toolkits?

The reason for that is the hope that we can make a very
light, pure-Python package that might (some day) be part
of the standard Python distribution. To actually use it,
you would have to have some GUI package installed (as
with the anydbm package) - or at least a web browser
(with Alex's DHTML idea).

> If we define a standard portable GUI API we can always
> implement it in a native version for any major platform.

Yes. That would be very nice too - but the we would need
to have binary code as part of the package...

> This would be a very small and light toolkit, which
> I would see as a large benefit (looking at wxPython for
> example).

I agree with you on that. My point is that if people
already *have* Tkinter, for instance (which they will
have with ActivePython), then anygui will work
automatically.

> Assuming this small toolkit would be available,
> why would anyone use the frontend to a more
> heavyone? He would only get the disadvantages,
> but could not use the advantages.

Depends on what disadvantages you mean... To me,
the disadvantages of using wxPython or Tkinter are:

1. They are complex, hard to learn for beginners, and
even seasoned Pythoneers, not mainly interested in GUI.

2. They require exactly that package to be installed for
the program to work.

anygui should avoid both of these disadvantages.

Now, if we were able to implement backends directly, that
would be nice too. The more backends, the merrier. It's
just that for that to work, people will have to install
our specific anygui-gui-package, which is more work than
simply using another widespread one.

If it is possible to get the binary backend you suggest
as a (small) component of the standard Python
distribution, I would be very happy! I just seems a bit
far off...

What I suggest is the following: We develop a front-end
which consists of a pure Python package which defines an
API and which can automatically detect a set of possible
backends. We also develop a set of backends. These can
either be pure Python implementations that use other
GUI-packages like Tkinter or wxPython, or they can
include C-code for native GUI-support.

We may bundle it all together, or split the native GUI
packages out as a separate thing, so they simply become
lightweight substitutes for wxPython, Tkinter etc.,
specially designed for anygui.

I'm in favour of the latter solution, since it preserves
anygui as a clean front-end with no C-code. To get any
actual GUI you would need some GUI-backend.

What do you think? How things are packaged/bundled is
not really important, I think... I just want to make
something that works soon, and that will be usable on almost
any Python-installation.

> 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] Re: what a great idea!

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

> from: Alex Martelli
>      
> It seems there aren't archives of the ML yet, so I hope
> I'm not just duplicating somebody else's comments, but...

The list is completely new... As is the idea. (I just had it
a couple of days ago...)

> I really find this idea GREAT,

I'm glad you like it ;)

I've basically been wanting a standard (and simple) GUI package
for Python from about day 1, but haven't liked Tkinter much...
And find wxPython a bit ... well... not as simple and
well-documented as I would like. (A book would certainly help.)

> and hope I can be of some
> help to bring it to fruition.

I hope so too. (And I certainly think you can ;)

> Perhaps exactly because I'm
> *not* a GUI-GUy, I think it's a drag that most newbies must
> go through the soul-searching "which of half a dozen good
> to great GUIs do I program to" -- each with its pluses and
> minuses.

I agree totally.

> If anygui exists, we can just tell the newbie to
> program to it, for the presumably very simple GUIs he needs
> as a newbie, and voila -- his programs can then target
> wxWindows or Tkinter or whatever.

Exactly. It would also make any simple GUI-program more
portable. And hopefully, it would require less code than
most current packages...

> I even have some hope
> that we can make the absolutely-minimal subset of anygui
> required for compliance SO minimal that I can write a backend
> to Dynamic HTML... ok, so, maybe I'm daydreaming, but...

I think that sounds wonderful! I've been wondering what
should be done about the "dumbgui" part (as with "dumbdbm"),
but HTML/DHTML would be a very nice solution, using the
module webbrowser.py, etc. Yay! Now even text-only people
can use anygui, as long as they have lynx or something
similar installed.

I'm feeling realy enthusiastic at the moment ;)

> 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] what a great idea...!

[Alex M. <Ale...@th...>]

It seems there aren't archives of the ML yet, so I hope
I'm not just duplicating somebody else's comments, but...

I really find this idea GREAT, and hope I can be of some
help to bring it to fruition.  Perhaps exactly because I'm
*not* a GUI-GUy, I think it's a drag that most newbies must
go through the soul-searching "which of half a dozen good
to great GUIs do I program to" -- each with its pluses and
minuses.  If anygui exists, we can just tell the newbie to
program to it, for the presumably very simple GUIs he needs
as a newbie, and voila -- his programs can then target
wxWindows or Tkinter or whatever.  I even have some hope
that we can make the absolutely-minimal subset of anygui
required for compliance SO minimal that I can write a backend
to Dynamic HTML... ok, so, maybe I'm daydreaming, but...


Alex

[Anygui-devel] Goals

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

> 
> Hi!
> 
> This is an attempt to revive the efforts of making a
> "standard" Python GUI.
>  I realise that standardising
> one as preferable to others might not be desirable,
> and that is not the purpose of this project. The
> purpose is to build a pure Python package called
> anygui which will function in a manner similar to
> anydbm in that it will look for existing backends,
> and use what is available.

Should anygui really be only a front end for existing
GUI toolkits?
If we define a standard portable GUI API we can always
implement it in a native version for any major platform.
This would be a very small and light toolkit, which
I would see as a large benefit (looking at wxPython for
example).

Assuming this small toolkit would be available,
why would anyone use the frontend to a more
heavyone? He would only get the disadvantages,
but could not use the advantages.

Thomas