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