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

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

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

"Magnus Lie Hetland" <ml...@id...> writes:
    ...
> > (What is it that doesn't work, by the way? I deleted
> > my 1.5.2 a while back :)

In 1.5.2, and I believe in 2.0, there was a specific
typecheck at some point that forced values in sys.modules
to be actual module objects.  This served absolutely no
real purpose (typechecks rarely do!-) and was removed at
some point during the development of 2.1 (I fancy a small
suggestion I advanced on a NG discussion may have had
something to do with it, but I might be wrong on that).


Alex

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

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

> From: "Alex Martelli" <al...@ya...>
> > "Thomas Heller" <tho...@io...> writes:
> >     ...
> > > The disadvantage is that this does not work for
> > > Python 2.0 and below.
> > > Quite some people still use 1.5.2.
> > 
> > Is this a disadvantage?  I have zero interest in
> > doing any amount of extra work to support any old 
> > release of Python - "2.1 and up" is what I thought
> > we were working for.
> 
After some thinking I still would like to say the
following:

- Compatibility with older python versions
is (usually) cheap.

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

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

Thomas

Re: [Anygui-devel] A simpler API?

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

From: "Alex Martelli" <al...@ya...>
> "Magnus Lie Hetland" <ml...@id...> writes:
[...]
> The roles of the widgets in a tuple would have
> to be documented by the backend's author of course, but
> then using them in any way WOULD be backend-specific.

OK. You would have to know the backend anyway, so...
As long as the protocol is this simple:

  "For this backend, the attribute Button.impl will contain
   the tuple (foo, bar, baz), where foo is ..." etc.

Then that would be simple and consistent across all backends,
and the only difference would be how these implementing
widgets actually _work_ (which is a part of the backend,
really). I don't know how this works in swigged native
backends, but I guess it would be easy to do something like
this there as well.

> Oh, sure, it IS what any Windows user is used to these
> days (the 'icons' being called buttons of the toolbar
> or coolbar or whatever:-).  Presumably, btw, a command
> may also be invokable with some keyboard shortcut (at
> least in some backends).

Yup. These really ought to be tied in with undo/redo ;)

(And I think we may safely forget the Icons for now...)

> > Fair enough. But is it easy to _implement_? I can't see how
> > to do it in Java, for instance. But, as I said, that may be
> > just because ... I don't know how to do it. Or maybe I'm
> > talking about something completely different from you...
> 
> ...or maybe it _can't_ be done in Java/AWT, if the toolkit
> doesn't favour you with a callback/event/whatever when a
> menu is about to popup/scrolldown/whatever.  Now *THAT*
> would be serious.

I think that is actually the case. At least I've never seen
anything like such a callback (or event type) in AWT, and
I've used it for quite a few years...

There may be something like it in Swing (I see no reason
why ther couldn't be, since it's "pure" Java), but I haven't
really seen it there either...

I'll have a look. Do we have these callbacks on all other
platforms? Native Mac? wxPython? Tkinter? Can we simulate
it somehow (by doing the setup at target selection time,
as I mentioned earlier), at least on platforms that don't
support it? Any other work-arounds?

And another thing - I think maybe we should just forget
AWT and go with Swing. (Then again, maybe not...)

> I'm too rusty on that, sorry.  So how do you normally
> enable/disable, &c, menu-entries in AWT?

Hm. I haven't done that much. I guess you'd do that
in some ad-hoc manner, depending on events/program state :P

But as I said, I'll take a look. I guess Robin can probably
answer this about wxPython...

> > Remember that it was inspired by Python <wink>
> 
> *WHAT*?!  *EEEEEEEEEEK...*   So why didn't they just USE
> Python?!

No idea. I guess they wanted something... Err... "Simpler"?
No... More like C/Java, perhaps. Hm.

> If the mapping is a builtin dictionary, and all the info
> about enabling/disabling &c is static in there, it should
> be zippy-fast.  But what I had in mind was that such a
> mapping could be "posted" by an object (assuming the
> enabled/disabled states it desires vary rarely) and then,
> if the GUI is being painted remotely from the engine
> running behind it, the remote-GUI-painter can have a local
> copy of the mapping to consult so it doesn't have to make
> the user wait before a menu drops-down... *IF* the enab/disab
> state on the menu IS entirely static, at least.

Right. And the local cache would of course be a combination of
the relevant dicts... Or will there always be only one?

> > Sounds like a good idea to me.
> 
> ...maybe... I think it needs more work.

I'm sure you're right.

> > ?-)
> 
> (and I'm an
> almost-archetipal movie-cultist, so I should know...:-).

Errr... OK. :)

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

> What gui-toolkit makes undo/redo "trasparent" to the
> application...?

Not the application - the programmer. Somewhat like ZODB makes
storage "transparent".

> > Hm. I guess it is. But a default implementation that doesn't
> > really help you can be more annoying than not having it there,
> > IMO.
> 
> So it's disabled by default so the author is reminded to add
> some modicum of help and enable it...?-)

Perhaps we could even have som simple AI check whether the help
material is useful enough to allow enabling the menu? <wink>

> > _or_ the backend can implement all the methods... You don't
> > really need Sping for that. Hm. I don't know. Maybe Sping is
> > overkill for the first release?
> 
> If it's at all hard to do, I guess; I was hoping to luck
> out and find it very very easy to integrate:-).

Ah. There is one backend for Tkinter and one for wxPython...
And the Java 2D API is so rich it would be trivial to implement
it there. And there is QuickDraw for Mac... Hm.

> > I've never done any serious programming in X at all... But, yes. I
> > think we may assume that there is quite a lot of thought behind the
> > API as it stands.
> 
> So I'll see what I can do to rip it out in the course of
> the next few days...:-).

Good.

> 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

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

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

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


> "Thomas Heller" <tho...@io...> writes:
>     ...
> > The disadvantage is that this does not work for
> > Python 2.0 and below.
> > Quite some people still use 1.5.2.
> 
> Is this a disadvantage?  I have zero interest in
> doing any amount of extra work to support any old 
> release of Python - "2.1 and up" is what I thought
> we were working for.

Again we seem to agree. That's what I was thinking
too :)

"To the __future__, and beyond!" ;)

> I think we should clarify this with the highest
> priority, because it may affect who chooses to
> expend what amount of work on anygui -- just as
> I will not contribute if there is some constraint
> about being backwards compatible with 2.0, 1.5,
> or whatever, so I guess others won't _unless_ the
> constraint is present.

Well, that's some ultimatum... <0.5 wink>

I think we should go with the current state of the
art. Heck - I'd even use generators if we needed
them ;)

I suspect it will be a while before anygui is really
widely used anyway, and by then 1.5.2 will probably
be _very_ old...

Any other opinions? Should I perhaps set up a poll?
Or can people live with 2.1+?

(I'm not sure pre-2.0 needs to be such a heavy
constraint, but - I haven't really thought that 
long and hard ;)

> 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

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

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

This was meant for the list... Sorry about the
forwarding.

----- Original Message ----- 
From: "Magnus Lie Hetland" <ml...@id...>
To: "Thomas Heller" <tho...@io...>
Sent: Tuesday, July 03, 2001 2:55 AM
Subject: Re: [Anygui-devel] Some import magic checked in


> From: "Thomas Heller" <tho...@io...>
> >
> > The disadvantage is that this does not work for
> > Python 2.0 and below.
> > Quite some people still use 1.5.2.
> 
> I guess that's a large-scale issue... Should we stay
> compatible with pre-2.0? I guess we may not really
> need any of the new features.
> 
> (What is it that doesn't work, by the way? I deleted
> my 1.5.2 a while back :)
>  
> > We should define the list depending on the
> > operating system IMO.
> 
> Fair enough. Which backend is selected would, of course,
> depend on the OS anyway, but... Doesn't matter to me.
> 
> > Here's a way without using traceback, I have no idea,
> > however, if this works in Jython:
> 
> > !         self.__dirname = __path__[0]
> 
> Right! I was in a hurry and grabbed the first solution
> I found :)
> 
> (How come this doesn't work when the script is executed
> rather than imported? Hm. I guess I'd better look it up :)
> 
> > 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?

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

"Magnus Lie Hetland" <ml...@id...> writes:
    ...
> Ah. Yes. Right. Hm. If there is a one-to-one
> correspondence between anygui widgets and foogui
> widgets, a simple attribute (in each widget etc.) would
> do... But would that always be the case? I really hope

I assumed one-to-many -- where the "gimme the underlying
widget[s]" property/method/whatever would return the
single corresponding widget OR the tuple of corresponding
widgets.  The roles of the widgets in a tuple would have
to be documented by the backend's author of course, but
then using them in any way WOULD be backend-specific.

> > I miss the "icons", I think.  Should I brush up on Swing,
> > or can you clarify how those might fit in "an action" (or
> > "a command")?
>
> Ah. Commands may be associated with menu items, buttons,
> or toolbar-...-err-buttons. These may use the title, desc.,
> icon etc. associated with the action. (E.g. scissors
> with "cut" etc.) I don't think we need to do it that way,
> but it was kind of cute, IMO :)

Oh, sure, it IS what any Windows user is used to these
days (the 'icons' being called buttons of the toolbar
or coolbar or whatever:-).  Presumably, btw, a command
may also be invokable with some keyboard shortcut (at
least in some backends).


> > > I'm not sure it _is_ that simple... In terms of implementation
> > > in other backends, I mean. But then again, I may just be
> > > a bit dense :)
> >
> > It's definitely the natural approach on MFC, for example.
> > (Your "is this enabled/disabled/checked" callbacks also get
> > invoked on idletime for toolbar-visualization purposes, as
> > well as when a dropdown or popup menu is about to appear).
>
> Fair enough. But is it easy to _implement_? I can't see how
> to do it in Java, for instance. But, as I said, that may be
> just because ... I don't know how to do it. Or maybe I'm
> talking about something completely different from you...

...or maybe it _can't_ be done in Java/AWT, if the toolkit
doesn't favour you with a callback/event/whatever when a
menu is about to popup/scrolldown/whatever.  Now *THAT*
would be serious.


> > For dynamic HTML, if you can stomach Javascript and XSLT,
> >
>
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dncodecorn/
> > html/corner052499.asp
> > offers one example, and it doesn't seem to me the callbacks
> > to enable/disable stuff would be problematic given the
> > amount of work it's dynamically doing to build and
> > popup the menus anyway.
>
> Right. But do you have that access in all platforms? Using
> AWT, for instance, all the menu-stuff is done magically --
> all you have access to is the resulting command. (Or am I
> perhaps wrong here? Could you do something with a mouse
> listener?)

I'm too rusty on that, sorry.  So how do you normally
enable/disable, &c, menu-entries in AWT?


> > Simpler examples may be those
> > at http://popup.jscentral.com/ or maybe even better
> > http://choisworld.com/dynamic13.html (you need to View/Source
> > on this one -- again you need some stomach for Javascript,
> > which makes it a hard go for me since I detest JS,
>
> Remember that it was inspired by Python <wink>

*WHAT*?!  *EEEEEEEEEEK...*   So why didn't they just USE
Python?!


> > I was rather
> > thinking of a mapping, itemname->(enabled/disabled and
> > checked/unchecked).
>
> IC. Would this necessarily be faster than a method? (Or
> wasn't that the point?)

If the mapping is a builtin dictionary, and all the info
about enabling/disabling &c is static in there, it should
be zippy-fast.  But what I had in mind was that such a
mapping could be "posted" by an object (assuming the
enabled/disabled states it desires vary rarely) and then,
if the GUI is being painted remotely from the engine
running behind it, the remote-GUI-painter can have a local
copy of the mapping to consult so it doesn't have to make
the user wait before a menu drops-down... *IF* the enab/disab
state on the menu IS entirely static, at least.


> > Maybe we could somehow leverage the mechanism that Python
> > already provides for us when we call getattr: go to the
> > object's dict first, perhaps check also a default dict
> > (from the object's class), if neither gives satisfaction
> > call __getattr__ (so the call only happens if no other
> > answer can be provided -- this would still let an object
> > do SOME occasional menuitem-setup, but only for rare
> > items for which it cannot provide a stock, static response
> > by setting the entries in appropriate dictionaries).
>
> Sounds like a good idea to me.

...maybe... I think it needs more work.


> > > Hm. Probably. Reminds me of the JavaBeans framework where
> > > vetoing attribute changes is handled by events... But
> > > that may be stretching things :)
> >
> > Yes, probably.  I love generality, uniformity, and
> > event-driven programming, but "this here is a song
> > about anyguy"...
>
> ?-)

"remember Alice? It's a song about Alice" (which I'd SWEAR
Arlo once sang "remember Alice? this here is a song about
Alice"), "Alice's Restaurant", By Arlo Guthrie, cfr e.g.
http://www.arlo.net/lyrics/alices.shtml.  Other sources
have the quote as "remember Alice? There's a song about
Alice" (e.g. http://www.fortunecity.com/tinpan/parton/2/alice.html).
Arthur Penn's 1968 movie is cult-worthy IMVHO (and I'm an
almost-archetipal movie-cultist, so I should know...:-).


> > > Hm. Maybe we should just leave this out for the first release?
> > > (Though transparent undo/redo handling would be _extremely_
> > > useful, IMO. Perhaps we could integrate an action pattern
> > > with the event system? <0.6 wink>)
> >
> > OK, OK, you're right, we can't really do it.  I just kept
> > thinking, if we have Undo as standard, we should also have
> > Redo.  Maybe leave _both_ out in anygui 0.1 ... ?
>
> 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.  What gui-toolkit makes
undo/redo "trasparent" to the application...?


> > > Yeah... Perhaps we could link this to docstrings, or
> > > __author__ etc? (But we still might not need this for the
> > > first release, IMO...)
> >
> > Not for 0.1, OK.  But "Help" in a standard place should be
> > there -- isn't that pretty standard across GUI frameworks?
>
> Hm. I guess it is. But a default implementation that doesn't
> really help you can be more annoying than not having it there,
> IMO.

So it's disabled by default so the author is reminded to add
some modicum of help and enable it...?-)


> > Maybe, if we do NOT want to make having SPING installed a prereq
> > for using anygui at all,
>
> I wouldn't want it as a prerequisite, no... But using the same
> API would allow us to plug it in somehow...
>
> > we might have it "fail-soft" -- if SPING
> > is not around, anygui falls back to a truly-seriously-minimal
> > drawing API,
>
> _or_ the backend can implement all the methods... You don't
> really need Sping for that. Hm. I don't know. Maybe Sping is
> overkill for the first release?

If it's at all hard to do, I guess; I was hoping to luck
out and find it very very easy to integrate:-).


> > > Another thing: Is the component layout system OK? I don't like
> > > coordinates much... (And I have gotten used to Java's layout
> > > managers, so I may be a bit biased...)
> >
> > These issues are cognates.  Frame.place (plus a Component's
> > "elasticity" in move & size, currently 0 or 1 only) are what
> > determine component-layout.  (And I think TK's good old simple
> > layout managers can whup any Java layout mgrs
>
> OK. Not much of a Tk expert... But I can use a BorderLayout for
> quite a lot ;)
>
> > So maybe we should study the
> > specs & perhaps the code behind them again (but it's been
> > even longer since I programmed to XLib, so I can't guarantee
> > the latter...:-).
>
> I've never done any serious programming in X at all... But, yes. I
> think we may assume that there is quite a lot of thought behind the
> API as it stands.

So I'll see what I can do to rip it out in the course of
the next few days...:-).


Alex

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

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

> > The disadvantage is that this does not work for
> > Python 2.0 and below.
> > Quite some people still use 1.5.2.
> 
> Is this a disadvantage?  I have zero interest in
> doing any amount of extra work to support any old 
> release of Python - "2.1 and up" is what I thought
> we were working for.
> 
> I think we should clarify this with the highest
> priority, because it may affect who chooses to
> expend what amount of work on anygui -- just as
> I will not contribute if there is some constraint
> about being backwards compatible with 2.0, 1.5,
> or whatever, so I guess others won't _unless_ the
> constraint is present.

IMO the 'additional work' is not too much,
but maybe this is because I've not yet get used
to list comprehensions.

What do other people on the list think?
I could live with this constraint, I just
would prefer to support most versions
currently in use...

Thomas

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

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

"Thomas Heller" <tho...@io...> writes:
    ...
> The disadvantage is that this does not work for
> Python 2.0 and below.
> Quite some people still use 1.5.2.

Is this a disadvantage?  I have zero interest in
doing any amount of extra work to support any old 
release of Python - "2.1 and up" is what I thought
we were working for.

I think we should clarify this with the highest
priority, because it may affect who chooses to
expend what amount of work on anygui -- just as
I will not contribute if there is some constraint
about being backwards compatible with 2.0, 1.5,
or whatever, so I guess others won't _unless_ the
constraint is present.


Alex

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

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

Comments inline.

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

The disadvantage is that this does not work for
Python 2.0 and below.
Quite some people still use 1.5.2.

> 
> *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
> 
We should define the list depending on the
operating system IMO.

> 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.)
Here's a way without using traceback, I have no idea,
however, if this works in Jython:

Index: __init__.py
===================================================================
RCS file: /cvsroot/anygui/anygui/__init__.py,v
retrieving revision 1.1.1.1
diff -c -r1.1.1.1 __init__.py
*** __init__.py 2001/07/02 04:23:22 1.1.1.1
--- __init__.py 2001/07/02 14:55:52
***************
*** 9,17 ****
  
      def __init__(self):
          self.__backend = None
!         # Is there a better way to do this? (Doesn't work in Jython 2.1a1)
!         import traceback
!         self.__dirname = os.path.dirname(traceback.extract_stack()[-1][0])
          self.__backends = BACKENDS
  
      def __try_to_get(self, modulename):
--- 9,15 ----
  
      def __init__(self):
          self.__backend = None
!         self.__dirname = __path__[0]
          self.__backends = BACKENDS
  
      def __try_to_get(self, modulename):


Thomas

Re: [Anygui-devel] Developing the API

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

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

> > From: "Alex Martelli" <al...@ya...>
> > 
> > 
> > > "Magnus Lie Hetland" <ml...@id...> writes:
> > [snip]
> > > > Anyone who wants to take a crack at it? (Alex?)
> > > 
> > > OK, I'm volunteered then
> > 
> > Yay!
> > 
> > > (I plan to steal shamelessly from Greg's sources,
> > > of course -- somebody had better let him know...!).
> > 
> > I've asked for (and received) his permission to use
> > his API/impl. as a starting-point.
> > 
> So we take Greg's API as the first target for anygui?

Possibly slightly modified, I guess... (Such as removing
accessor methods and the FileRef/DirRef objects.)
Maybe Alex will even segue to right over to the MVC-model
too...

> Then I'll start working on the native windows impl.

I'm sure starting to work on it can't hurt -- adjusting
to Alex's version (or later adjustments suggested on the
list) should (hopefully) not be too hard...

Or do you think the API sould be more fixed first? I
suspect that if we keep it a bit fluid for now, useful
things may crop up while implementing the backends...

> Magnus, please add me as developer:
> the SF id is theller.

Done.

> 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] Developing the API

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

> From: "Alex Martelli" <al...@ya...>
> 
> 
> > "Magnus Lie Hetland" <ml...@id...> writes:
> [snip]
> > > Anyone who wants to take a crack at it? (Alex?)
> > 
> > OK, I'm volunteered then
> 
> Yay!
> 
> > (I plan to steal shamelessly from Greg's sources,
> > of course -- somebody had better let him know...!).
> 
> I've asked for (and received) his permission to use
> his API/impl. as a starting-point.
> 
So we take Greg's API as the first target for anygui?
Then I'll start working on the native windows impl.

Magnus, please add me as developer:
the SF id is theller.

Thomas

[Anygui-devel] A new goal

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

I just thought of another Noble Goal (tm) for our
project. By coding the backends nicely, anygui can
be a nice entry for learning the basics of a specific
gui-package. "I know how to do it in anygui... Now,
let's see how that translates to wxPython..."

That, of course, means that the backends shouldn't
be _too_ magic (or to filled with underscore-prefixes,
perhaps... Or that may just be me ;)

--

  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] Developing the API

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

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


> "Magnus Lie Hetland" <ml...@id...> writes:
[snip]
> > Anyone who wants to take a crack at it? (Alex?)
> 
> OK, I'm volunteered then

Yay!

> (I plan to steal shamelessly from Greg's sources,
> of course -- somebody had better let him know...!).

I've asked for (and received) his permission to use
his API/impl. as a starting-point.

> 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

Re: [Anygui-devel] A simpler API?

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

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


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

[about access to backend]

Well put. I agree.

> > Then, each time someone
> > felt the need to make such a replacement, they could
> > submit it... (I, for one, would like a tree-widget
> > substitution... And a status bar... And...)
>
> _Excellent_ idea.

Perhaps we could even get our own (sub-)section in the
vaults of parnassus...

"Get your generic widgets here!" ;)

> Yes, but client-code that wants to do peculiar stuff
> when backend is 'wx' (I would NOT bother predefining
> such constants, strings seem good here:-) still needs
> to access the "underlying object[s]" for a given anygui
> level object (Component, Frame, ...?other?...).

Ah. Yes. Right. Hm. If there is a one-to-one
correspondence between anygui widgets and foogui
widgets, a simple attribute (in each widget etc.) would
do... But would that always be the case? I really hope
we can find a _really_ simple solution for this...
If we need a different protocol for each backend, I
certainly would like the idea a lot less.

> Is Greg on the list?

Nope. I cc'ed a mail to him off the list where I mentioned
his work on the X-backend. I didn't want to badger him
about getting on the list... (I assumed he would if he
wanted to :)

> Maybe we could ask him?  Sure
> we do have other GUI-experts around...?

Don't know. Any GUI-experts here?

Oh, well. I guess we all know _some_ GUI-stuff... And
after all, this API is meant for non-GUI-experts ;)

> > Hm. Swing actions are nice here... With names, icons,
> > etc. etc.
>
> I miss the "icons", I think.  Should I brush up on Swing,
> or can you clarify how those might fit in "an action" (or
> "a command")?

Ah. Commands may be associated with menu items, buttons,
or toolbar-...-err-buttons. These may use the title, desc.,
icon etc. associated with the action. (E.g. scissors
with "cut" etc.) I don't think we need to do it that way,
but it was kind of cute, IMO :)

> > I'm not sure it _is_ that simple... In terms of implementation
> > in other backends, I mean. But then again, I may just be
> > a bit dense :)
>
> It's definitely the natural approach on MFC, for example.
> (Your "is this enabled/disabled/checked" callbacks also get
> invoked on idletime for toolbar-visualization purposes, as
> well as when a dropdown or popup menu is about to appear).

Fair enough. But is it easy to _implement_? I can't see how
to do it in Java, for instance. But, as I said, that may be
just because ... I don't know how to do it. Or maybe I'm
talking about something completely different from you...

>
> For dynamic HTML, if you can stomach Javascript and XSLT,
>
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dncodecorn/
> html/corner052499.asp
> offers one example, and it doesn't seem to me the callbacks
> to enable/disable stuff would be problematic given the
> amount of work it's dynamically doing to build and
> popup the menus anyway.

Right. But do you have that access in all platforms? Using
AWT, for instance, all the menu-stuff is done magically --
all you have access to is the resulting command. (Or am I
perhaps wrong here? Could you do something with a mouse
listener?)

> Simpler examples may be those
> at http://popup.jscentral.com/ or maybe even better
> http://choisworld.com/dynamic13.html (you need to View/Source
> on this one -- again you need some stomach for Javascript,
> which makes it a hard go for me since I detest JS,

Remember that it was inspired by Python <wink>

> but the
> point is the needed functionality IS right there in the
> Dynamic HTML object-model...).

Well, that's nice.

> > How would you represent that info? Or do you simply mean
> > that we should have an advisory boolean variable as
> > a filter before calling setup_menus?
>
> A boolean variable won't cut it, I fear.

Ah. I was afraid of that.

> I was rather
> thinking of a mapping, itemname->(enabled/disabled and
> checked/unchecked).

IC. Would this necessarily be faster than a method? (Or
wasn't that the point?)

> Maybe we could somehow leverage the mechanism that Python
> already provides for us when we call getattr: go to the
> object's dict first, perhaps check also a default dict
> (from the object's class), if neither gives satisfaction
> call __getattr__ (so the call only happens if no other
> answer can be provided -- this would still let an object
> do SOME occasional menuitem-setup, but only for rare
> items for which it cannot provide a stock, static response
> by setting the entries in appropriate dictionaries).

Sounds like a good idea to me.

> > Hm. Probably. Reminds me of the JavaBeans framework where
> > vetoing attribute changes is handled by events... But
> > that may be stretching things :)
>
> Yes, probably.  I love generality, uniformity, and
> event-driven programming, but "this here is a song
> about anyguy"...

?-)

> I don't think using event objects to model events that
> are currently unmodeled will reduce the number of classes
> and methods in the API,

:(

> I'm just thinking in terms of
> documenting/explaining the anygui API to newbies.

:)

(Barf. I'm using far too many smileys... May have something
to do with the fact that I spent last night programming.)

> I think I could save a paragraph or three if uniformity
> reigned:-).

A good thing.

> > Hm. Maybe we should just leave this out for the first release?
> > (Though transparent undo/redo handling would be _extremely_
> > useful, IMO. Perhaps we could integrate an action pattern
> > with the event system? <0.6 wink>)
>
> OK, OK, you're right, we can't really do it.  I just kept
> thinking, if we have Undo as standard, we should also have
> Redo.  Maybe leave _both_ out in anygui 0.1 ... ?

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?

> > Yeah... Perhaps we could link this to docstrings, or
> > __author__ etc? (But we still might not need this for the
> > first release, IMO...)
>
> Not for 0.1, OK.  But "Help" in a standard place should be
> there -- isn't that pretty standard across GUI frameworks?

Hm. I guess it is. But a default implementation that doesn't
really help you can be more annoying than not having it there,
IMO.

But if/when we include a "standard menu setup", I guess help
should be part of it. (And maybe an "about" choice...)

[FileRef/DirRef]
> I did try to study what those were for but it still was not
> clear to me -- apparently attempting to model very general
> platforms where files are not necessarily representable by
> path strings or similar kinds of URI's.  Or maybe I'm
> missing something here.

Hm. I say we leave them out -- I'm sure we can put them in
later if we need them.

> Maybe, if we do NOT want to make having SPING installed a prereq
> for using anygui at all,

I wouldn't want it as a prerequisite, no... But using the same
API would allow us to plug it in somehow...

> we might have it "fail-soft" -- if SPING
> is not around, anygui falls back to a truly-seriously-minimal
> drawing API,

_or_ the backend can implement all the methods... You don't
really need Sping for that. Hm. I don't know. Maybe Sping is
overkill for the first release?

> that only supplies what the backend canvas does,
> dressing it up the _very minimum_ needed to ensure the signatures
> of those drawing methods that also exist in minimal state are the
> same as those SPING exposes when it's present.  This might reduce
> the total-minimal-footprint needed for very-elementary anygui use.

Right. The footprint. Hm.

> If any unsupported drawing method is called when SPING's not found,
> an alert pops up with an ad for SPING including a clickable URL
> for download and dynamic inst^H^H^H^H OK I'm letting imagination
> run away *again*, sorry, forget this para and go back to the
> previous one that seems more soberly doable:-).

<LOL>

> > Actually, I would really like to have styled text too... It
> > seems that all of our backends can handle it... But perhaps not
> > for our first release ;)
>
> Agreed.  And similarly for using a general canvas as a background
> and...:-)

And... And... Right.

> > Another thing: Is the component layout system OK? I don't like
> > coordinates much... (And I have gotten used to Java's layout
> > managers, so I may be a bit biased...)
>
> These issues are cognates.  Frame.place (plus a Component's
> "elasticity" in move & size, currently 0 or 1 only) are what
> determine component-layout.  (And I think TK's good old simple
> layout managers can whup any Java layout mgrs

OK. Not much of a Tk expert... But I can use a BorderLayout for
quite a lot ;)

> So maybe we should study the
> specs & perhaps the code behind them again (but it's been
> even longer since I programmed to XLib, so I can't guarantee
> the latter...:-).

I've never done any serious programming in X at all... But, yes. I
think we may assume that there is quite a lot of thought behind the
API as it stands.

> 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

Re: [Anygui-devel] Developing the API

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

"Magnus Lie Hetland" <ml...@id...> writes:
    ...
> be done? I would really like a nullgui.py, with
> abstract (yet instantiable(?)) classes... Another
> possibility is to just list the various classes
> and their superclasses... And their methods.
> (But then, why not make a null-implementation? ;)
> 
> Anyone who wants to take a crack at it? (Alex?)

OK, I'm volunteered then (I plan to steal shamelessly
from Greg's sources, of course -- somebody had better
let him know...!).


Alex

Re: [Anygui-devel] A simpler API?

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

"Magnus Lie Hetland" <ml...@id...> writes:
    ...
> > *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.
>
> Hm. I agree with you, with the proviso that this is
> well thought-out... If this becomes an easy cop-out
> (or whatever one might call it ;) then the genericity
> of anygui may be lost...
>
> I guess (as with most things Pythonic) this can be solved
> by an appeal to people's sense of style. I.e. make it
> the "anygui way" to always provide a pure anygui
> alternative to your backend-passthrough tweaks...

anygui provides a small subset of what a rich GUI API
like wxWindows' might supply.  It may grow a bit in
successive releases, but it will never come even close
to covering everything -- sliders, spinners, notebooks
aka 'propertypages/propertysheets' in MFC terms,
dockable subwindows, coolbars, ...  What I had in mind
with this proposal was that anygui clients would
program their GUI's to anygui's API (if they don't
mean to do that, why are they using anygui at all?-),
in terms that can be much less refined (e.g., separate
toplevel windows in lieu of notebooks or dockables) BUT
keep the ability to access sophisticated stuff IF the
underlying framework provides it AND they know what to
do with it (reparent a frame to notebook-page and/or
dockable, that sort of thing -- or, say, have a textfield
as the number-entry means in anygui terms, but replace
it with a slider or spinner when running on certain
underlying frameworks...).

If we provide this decently well, then a GUI originally
sketched in anygui terms can later be "grown" in terms
of one (or a few) other underlying frameworks without
having to throw away and reprogram much of what one has
already done.  Yes, ideally the "simple fallback 100%
pure anygui approach" would be maintained and kept up
to date so the overall app can still run anywhere (with
less-slick look&feel, but still run) -- but that does
not have to be a _must_, just, as you suggest, a strong
stylistic & pragmatical suggestion ("one day you'll need
your app to be running RIGHT NOW on a peculiar palmtop
device you've never seen before -- why not pay the small
premium to ensure it does...?").


> Yes... I agree that this is a good thing. And it would
> probably remove some objections to using anygui.
>
> An idea: We could make some simple system/protocol for
> making pure anygui replacements for fancy "native"
> widgets, and collect them in one place (like the
> anygui distribution <wink>). Then, each time someone
> felt the need to make such a replacement, they could
> submit it... (I, for one, would like a tree-widget
> substitution... And a status bar... And...)

_Excellent_ idea.


> I guess so. It would be very easy to get this info from
> the anygui module/object itself... For instance:
>
> >>> import anygui
> >>> print anygui.backend
> None
> >>> from anygui import *
> >>> anygui.backend
> 'wx'
>
> Or something... (Of course "constants" like WX = 'wx' etc.
> could be defined...)

Yes, but client-code that wants to do peculiar stuff
when backend is 'wx' (I would NOT bother predefining
such constants, strings seem good here:-) still needs
to access the "underlying object[s]" for a given anygui
level object (Component, Frame, ...?other?...).


> > I'm no
> > GUI expert, it just seems to me that MVC buys you
> > more for very little cost.
>
> I'm no expert either... And simply assumed that
> Greg was.

Is Greg on the list?  Maybe we could ask him?  Sure
we do have other GUI-experts around...?


> > Why foo() to read, set_foo() to write?
>
> I was thinking about commenting that too -- I would
> much rather have __getattr__/__setattr__ stuff...
> I _really_ like Jython AWT/Swing "magic" like:
>
>   f = Frame()
>   f.size = (400, 300)
>
> :)

We may be too much in agreement, you and I -- I, too,
had in mind the nice way Jython Pythonizes AWT here!-)


> > 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.
>
> Hm. Swing actions are nice here... With names, icons,
> etc. etc.

I miss the "icons", I think.  Should I brush up on Swing,
or can you clarify how those might fit in "an action" (or
"a command")?


> > 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.
>
> I'm not sure it _is_ that simple... In terms of implementation
> in other backends, I mean. But then again, I may just be
> a bit dense :)

It's definitely the natural approach on MFC, for example.
(Your "is this enabled/disabled/checked" callbacks also get
invoked on idletime for toolbar-visualization purposes, as
well as when a dropdown or popup menu is about to appear).

For dynamic HTML, if you can stomach Javascript and XSLT,
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dncodecorn/
html/corner052499.asp
offers one example, and it doesn't seem to me the callbacks
to enable/disable stuff would be problematic given the
amount of work it's dynamically doing to build and
popup the menus anyway.  Simpler examples may be those
at http://popup.jscentral.com/ or maybe even better
http://choisworld.com/dynamic13.html (you need to View/Source
on this one -- again you need some stomach for Javascript,
which makes it a hard go for me since I detest JS, but the
point is the needed functionality IS right there in the
Dynamic HTML object-model...).


> > 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".
>
> How would you represent that info? Or do you simply mean
> that we should have an advisory boolean variable as
> a filter before calling setup_menus?

A boolean variable won't cut it, I fear.  I was rather
thinking of a mapping, itemname->(enabled/disabled and
checked/unchecked).  Before calling setup_menus check if
the object has 'posted' (and not yet retracted) such a
mapping (maybe as a property...?).  If the mapping is
there, then use it in lieu of calling setup_menus -- with
a series of calls to .get('itemname', (None, None, None))
(not sure how to best represent the default response of
"leave enabling/disabling and checkmarking both alone").

Maybe we could somehow leverage the mechanism that Python
already provides for us when we call getattr: go to the
object's dict first, perhaps check also a default dict
(from the object's class), if neither gives satisfaction
call __getattr__ (so the call only happens if no other
answer can be provided -- this would still let an object
do SOME occasional menuitem-setup, but only for rare
items for which it cannot provide a stock, static response
by setting the entries in appropriate dictionaries).


> > (I'm also thinking of model_changed "messages" from
> > models to views, &c.  Shouldn't all of these events be
> > modeled rather uniformly...?)
>
> Hm. Probably. Reminds me of the JavaBeans framework where
> vetoing attribute changes is handled by events... But
> that may be stretching things :)

Yes, probably.  I love generality, uniformity, and
event-driven programming, but "this here is a song
about anyguy"...


> > Specifically
> > C1. Event should be generalized to model any kind of
> > event, not _just_ mouse & keys.
>
> Agreed. This might (hopefully) make the API simpler too.
> I think it would be nice to have as few classes, methods,
> and classes as possible :)

I don't think using event objects to model events that
are currently unmodeled will reduce the number of classes
and methods in the API, I'm just thinking in terms of
documenting/explaining the anygui API to newbies.  I
think I could save a paragraph or three if uniformity
reigned:-).


> > 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?
>
> Hm. Maybe we should just leave this out for the first release?
> (Though transparent undo/redo handling would be _extremely_
> useful, IMO. Perhaps we could integrate an action pattern
> with the event system? <0.6 wink>)

OK, OK, you're right, we can't really do it.  I just kept
thinking, if we have Undo as standard, we should also have
Redo.  Maybe leave _both_ out in anygui 0.1 ... ?


> > 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:-)
>
> Yeah... Perhaps we could link this to docstrings, or
> __author__ etc? (But we still might not need this for the
> first release, IMO...)

Not for 0.1, OK.  But "Help" in a standard place should be
there -- isn't that pretty standard across GUI frameworks?


> > E. FileRef/DirRef
> > Do we truly need these new abstractions...?  Couldn't we
> > do with something simpler/closer to what Python gives us...?
>
> Ah... There was the second objection I forgot. I guess these
> are tied with the Document system or something (i probably
> didn't read it thoroughly enough), but this is one of the
> things I find slightly annoying about some other packages...
> That they duplicate a lot of the features we already have.
> Makes a bad case for inclusion in the standard libraries :)

I did try to study what those were for but it still was not
clear to me -- apparently attempting to model very general
platforms where files are not necessarily representable by
path strings or similar kinds of URI's.  Or maybe I'm
missing something here.


> > F. Why not SPING for drawing?
>
> I thought about that myself. And as one of the creators of
> Piddle, I would, of course, like to use it :)
>
> > Couldn't we somehow reuse the riches in SPING/Piddle rather
> >     than having a newly-invented, albeit simple, drawing API?
>
> It seems like this new API is more or less a subset... Or
> at least closely related to PostScript.

Yes, that does appear to be the design intent.


> >     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?
>
> I think so. Sping is more complex... But perhaps tying in with
> Sping could draw some interest to both projects? After all, the
> goal of the original Piddle project was very close to this --
> making a generic API for graphic stuff.

Maybe, if we do NOT want to make having SPING installed a prereq
for using anygui at all, we might have it "fail-soft" -- if SPING
is not around, anygui falls back to a truly-seriously-minimal
drawing API, that only supplies what the backend canvas does,
dressing it up the _very minimum_ needed to ensure the signatures
of those drawing methods that also exist in minimal state are the
same as those SPING exposes when it's present.  This might reduce
the total-minimal-footprint needed for very-elementary anygui use.

If any unsupported drawing method is called when SPING's not found,
an alert pops up with an ad for SPING including a clickable URL
for download and dynamic inst^H^H^H^H OK I'm letting imagination
run away *again*, sorry, forget this para and go back to the
previous one that seems more soberly doable:-).


> > 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?
>
> Actually, I would really like to have styled text too... It
> seems that all of our backends can handle it... But perhaps not
> for our first release ;)

Agreed.  And similarly for using a general canvas as a background
and...:-)


> > Z7. I'm not sure I understand Frame.place -- is it just me, or
> >     is the spec confusing, or...?
    ...
> Another thing: Is the component layout system OK? I don't like
> coordinates much... (And I have gotten used to Java's layout
> managers, so I may be a bit biased...)

These issues are cognates.  Frame.place (plus a Component's
"elasticity" in move & size, currently 0 or 1 only) are what
determine component-layout.  (And I think TK's good old simple
layout managers can whup any Java layout mgrs -- the kind I
knew back in AWT 1.0 at least, haven't done any GUI'ing with
Java for QUITE a while now:-).  So maybe we should study the
specs & perhaps the code behind them again (but it's been
even longer since I programmed to XLib, so I can't guarantee
the latter...:-).


Alex

Re: [Anygui-devel] Developing the API

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

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

> > Hi!
> > 
> > I was thinking that perhaps we should start fiddling
> > around with the API in more specific terms...
[snip]
> > (But then, why not make a null-implementation? ;)
> > 
> Good idea. I'm for it.
> One thing I would like to mention:
> It's easy to mess up a CVS repository so that you
> cannot sensibly browse it any more. You cannot
> really remove files or directories. So this
> should be done in a 'playground' directory.

Hm. Seems like a good idea. (Maybe I should have gone
with a dist/nondist split like the Python CVS after
all... :P)

Perhaps you would like to set up a little playground
directory? (Probably just a matter of adding a directory
somewhere, but I'm not too experienced with CVS yet...
Perhaps it should be a separate package or something?)

And again: Anyone who wants to be added as developers
(the more the merrier... :), just mail me your
SourceForge username, and I'll add you.

> 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] Re: Goals

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

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

> I've done some quick experiments: It seems that it may be
> possible to do a _pure python_ implementation of a windows
> native gui on top of Mark Hammonds win32all extensions.

Wonderful! That seems to fit right the (or my intended)
spirit of anygui :)

> 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] Developing the API

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

> 
> Hi!
> 
> I was thinking that perhaps we should start fiddling
> around with the API in more specific terms... I.e.
> write up something and put it under CVS control,
> and just go wild (while maintaining the discussion
> on this list). Any suggestions on how this should
> be done? I would really like a nullgui.py, with
> abstract (yet instantiable(?)) classes... Another
> possibility is to just list the various classes
> and their superclasses... And their methods.
> (But then, why not make a null-implementation? ;)
> 
Good idea. I'm for it.
One thing I would like to mention:
It's easy to mess up a CVS repository so that you
cannot sensibly browse it any more. You cannot
really remove files or directories. So this
should be done in a 'playground' directory.

Thomas

Re: [Anygui-devel] Re: Goals

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

[...]
> 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.
> 
I've done some quick experiments: It seems that it may be
possible to do a _pure python_ implementation of a windows
native gui on top of Mark Hammonds win32all extensions.
This will use win32gui and win32api - not win32ui, which
wraps the MFC.
These are not included in Pythonlabs distribution, but
in ActiveState's.

Thomas

[Anygui-devel] Developing the API

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

Hi!

I was thinking that perhaps we should start fiddling
around with the API in more specific terms... I.e.
write up something and put it under CVS control,
and just go wild (while maintaining the discussion
on this list). Any suggestions on how this should
be done? I would really like a nullgui.py, with
abstract (yet instantiable(?)) classes... Another
possibility is to just list the various classes
and their superclasses... And their methods.
(But then, why not make a null-implementation? ;)

Anyone who wants to take a crack at it? (Alex?)

I'm all for "playful programming" (my down-played
version of "extreme programming" ;), i.e. playing
with the code rather than talking it to death...
Or perhaps _while_ talking it to death...

(Such a null-implementation would be a nice template
for the various real implementations 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

Re: [Anygui-devel] layout methods

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

"Amardeep Singh" <ama...@tc...> writes:

> what layout methods are you planning to use - fixed layout ?
> i think most modern gui toolkits are settling on layout containers
> including gtk, qt and swing rather than using fixed layout.

Assuming Greg's document is out current working document,
it's not fixed-layout.  Each Component c has properties
hmove, vmove, hstretch, vstretch, which, if set, cause
c's position/size to be modified when its container's
size changes (right now they're booleans, but I doubt it
would be a problem to change them into real numbers in
the range 0.0 to 1.0 to obtain partial-movement).  Each
Frame (container) f has a somewhat-confusing 'place'
method that lets 1 or more components be 'placed' in
absolute terms, or with reference to f, or with reference
to other components (in f? unclear) possibly with offset,
as well as setting move/stretch properties -- and you
can also specify stepping-direction for placing multiple
components, and spacing and/or borders.  To be honest I
find this 'place' approach (and its interactions with
components' move/stretch properties) the only somewhat
confusing part of the current tentative specs.  Looks like
we're trying to crowd too much functionality into one
method -- or maybe, it just isn't "clicking" for me.


> also, although not suitable for a first release, it would be better if
> architecture is designed such that it is easy to create a gui using an
> xml description on it eg. pygtk+libglade

I fail to see anything that could make it hard at all to
"snapshot" a GUI's current state (into xml or whatever),
or to "replay" that snapshot to rebuild the GUI in its
current state.  Maybe you can provide some example of
what we should be avoiding lest we inadvertently make
such things hard...?

By the way, Greg's docs are at:
    http://www.cosc.canterbury.ac.nz/~greg/python_gui/


Alex

Re: [Anygui-devel] layout methods

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

From: "Amardeep Singh" <ama...@tc...>


> what layout methods are you planning to use - fixed layout ?

I hope not.

> i think most modern gui toolkits are settling on layout containers
> including gtk, qt and swing rather than using fixed layout.

Yes - I think this is much better when trying to be generic...
Widgets rarely look the same across platforms.

> also, although not suitable for a first release, it would be better if
> architecture is designed such that it is easy to create a gui using an
> xml description on it eg. pygtk+libglade

Well... Robin has been doing something along these lines. Not with
XML, but I don't think it would be too hard to add. Just a pair
of export/import functions or something...

--

  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?

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

From: "Alex Martelli" <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.

Good point.

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

Hm. I agree with you, with the proviso that this is
well thought-out... If this becomes an easy cop-out
(or whatever one might call it ;) then the genericity
of anygui may be lost...

I guess (as with most things Pythonic) this can be solved
by an appeal to people's sense of style. I.e. make it
the "anygui way" to always provide a pure anygui
alternative to your backend-passthrough tweaks...

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

Yes... I agree that this is a good thing. And it would
probably remove some objections to using anygui.

An idea: We could make some simple system/protocol for
making pure anygui replacements for fancy "native"
widgets, and collect them in one place (like the
anygui distribution <wink>). Then, each time someone
felt the need to make such a replacement, they could
submit it... (I, for one, would like a tree-widget
substitution... And a status bar... And...)

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

I guess so. It would be very easy to get this info from
the anygui module/object itself... For instance:

>>> import anygui
>>> print anygui.backend
None
>>> from anygui import *
>>> anygui.backend
'wx'

Or something... (Of course "constants" like WX = 'wx' etc.
could be defined...)

> 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 was a bit puzzled about this as well...

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

I'm no expert either... And simply assumed that
Greg was.

> 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?

Yes... It seems easy to use this as well...

  class Component(View,Controller): ...

rather than

  class Component(View): ...

> B. why accessors/mutators?
> 
> Why foo() to read, set_foo() to write?

I was thinking about commenting that too -- I would
much rather have __getattr__/__setattr__ stuff...
I _really_ like Jython AWT/Swing "magic" like:

  f = Frame()
  f.size = (400, 300)

:)

[snip]

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

Me too. (Not the expert bit, but the feeling bit ;)

I think that was my only objection at first reading.

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

Hm. Swing actions are nice here... With names, icons,
etc. etc.

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

I'm not sure it _is_ that simple... In terms of implementation
in other backends, I mean. But then again, I may just be
a bit dense :)

> 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".

How would you represent that info? Or do you simply mean
that we should have an advisory boolean variable as
a filter before calling setup_menus?

> 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?

Beats me.

> 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?

Don't know. I (as you may have noticed) like generality and
consistency. I would like all events to behave similarly.

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

Hm. Probably. Reminds me of the JavaBeans framework where
vetoing attribute changes is handled by events... But
that may be stretching things :)

> Specifically
> C1. Event should be generalized to model any kind of
> event, not _just_ mouse & keys.

Agreed. This might (hopefully) make the API simpler too.
I think it would be nice to have as few classes, methods,
and classes as possible :)

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

Again, I just keep agreeing with you.

> 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?

Hm. Maybe we should just leave this out for the first release?
(Though transparent undo/redo handling would be _extremely_
useful, IMO. Perhaps we could integrate an action pattern
with the event system? <0.6 wink>)

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

Yeah... Perhaps we could link this to docstrings, or
__author__ etc? (But we still might not need this for the
first release, IMO...)

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

Ah... There was the second objection I forgot. I guess these
are tied with the Document system or something (i probably
didn't read it thoroughly enough), but this is one of the
things I find slightly annoying about some other packages...
That they duplicate a lot of the features we already have.
Makes a bad case for inclusion in the standard libraries :)

> F. Why not SPING for drawing?

I thought about that myself. And as one of the creators of
Piddle, I would, of course, like to use it :)

> Couldn't we somehow reuse the riches in SPING/Piddle rather
>     than having a newly-invented, albeit simple, drawing API?

It seems like this new API is more or less a subset... Or
at least closely related to PostScript.

>     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?

I think so. Sping is more complex... But perhaps tying in with
Sping could draw some interest to both projects? After all, the
goal of the original Piddle project was very close to this --
making a generic API for graphic stuff.

>  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...?

Nope.

> 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?

Actually, I would really like to have styled text too... It
seems that all of our backends can handle it... But perhaps not
for our first release ;)

> Z7. I'm not sure I understand Frame.place -- is it just me, or
>     is the spec confusing, or...?

<ahem>

I didn't even read all of it...

> Z8. Shouldn't it be possible to 'disable' a button/textfield/...?

Yup.

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

Big mails are fine by me. This is a technical discussion,
after all :)

Another thing: Is the component layout system OK? I don't like
coordinates much... (And I have gotten used to Java's layout
managers, so I may be a bit biased...)

> 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] layout methods

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

what layout methods are you planning to use - fixed layout ?
i think most modern gui toolkits are settling on layout containers
including gtk, qt and swing rather than using fixed layout.

also, although not suitable for a first release, it would be better if
architecture is designed such that it is easy to create a gui using an
xml description on it eg. pygtk+libglade

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