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

Re: [Anygui-devel] OK, everyone...

[Terry H. <ha...@an...>]

On Monday 16 February 2004 07:29 am, Alex Martelli wrote:
> On Monday 16 February 2004 02:00 pm, Laura Creighton wrote:
>=20
> 1. people who want to program a GUI that will run on Classic Python, jy=
thon,
>     and IronPython (or other variants on Python for dotNet) -- no curre=
nt
>     toolkit, I think, does reasonable abstraction covering all of wx an=
d/or
>     Qt, Awt and/or Swing, and WindowsForm;
>=20
> 2. similarly, people who want to have a "normal" GUI _and_ an HTML/Dyna=
mic
>     HTML version thereof for running on browsers;
>=20
> 3. even obscurer needs connected to running GUIs on (e.g.) embedded dev=
ices
>     with PyGame, cellphones, text-only connections, Flash, DVD menus, .=
..
>=20
> After all, it's=20
> debatable whether it's _sensible_ to want to code a GUI only once for (=
e.g.)=20
> a smart cellphone's 128 x 128 (if that) screen, a web browser, and a=20
> reasonably sized computer and screen

Nevertheless, that's more or less why I'm still on this list.  I don't wa=
nt to
spend a lot of time rewriting front ends, but there are applications I wi=
ll
want to be highly portable/flexible.  AnyGUI seems like the "right" way
to do that.

I think it's still the Jython/Python cross-platform issue that has the gr=
eatest
relevance for me.  One reason is that as a practical matter, I might want
to see a Jython version of my software available, but given the non-free
nature of the Java (and Swing in particular) it's very undesireable to tr=
ap
myself in Jython.  It would be so much better if the same code would
just run transparently on a C Python platform.

I'm still a bit away from being able to spend time on such a thing, but I
might be able to pick up some slack in a month or so, at least as regards
testing specific cases of Jython/Python apps for compatibility.

The other issue, of course, is that I will want graphics as well as "widg=
ets",
so there will need to be a portable "canvas" type object. Last time I
looked at AnyGUI that part wasn't figured out yet.

Cheers,
Terry

--
Terry Hancock ( hancock at anansispaceworks.com )
Anansi Spaceworks  http://www.anansispaceworks.com

Re: [Anygui-devel] OK, everyone...

[Donnal W. <don...@ya...>]

Greg Ewing wrote:
> Perhaps those are the people who want an API
> that's small, simple and Pythonic, as opposed
> to big, complicated and warped 

My two cents may be irrelevant to the long terms goals of Anygui,
but since it seems that we are in a brainstorming mode here, I'll
toss them in anyway. My ultimate goal is to establish a framework
for the rapid development of custom, data-centric, GUI-based,
clinical applications. (The "clinical" part is optional, of course.
:-)

What I have in mind is an abstraction-presentation architecture
that consists of two separate layers: an abstraction layer for
modeling the data structures of the application, and a presentation
layer for defining the user interface. I have put most of my effort
so far on the abstraction layer, working out a notation (an API)
for defining data structures of (theoretically) limitless
complexity with both independent and dependent elements. The
abstraction layer is to include a built-in persistence mechanism.
Also built into this notation are methods for transparently
connecting components from the presentation layer to specific data
elements. In this way I plan to create a notation (API) similar in
nature to the abstraction layer for defining the presentation
layer.

My interest in Anygui is precisely what Greg Ewing stated above, an
API that is small, simple and (possibly) Pythonic. I say "possibly"
Pythonic because my abstraction layer uses a notation that is not
exactly traditional Python syntax.

<OT>
For example,
    __init__(self, ...) is replaced by
    Assemble(self, ...)

And
    self.myname = Someclass(parent=self) is replaced by
    self.Add('myname', Someclass)
</OT>

At present, I have a preliminary version of the presentation layer
syntax built as a set of thick wrappers around selected wxPython
classes, a strategy that seems to work pretty well. But I have also
considered using the same API for a set of wrappers around classes
from Venster/ctypes, for example, to create a leaner approach for
Windows, and other small GUI toolkits for other platforms. Probably
I should just stick with wxPython, but compared to what I need,
wxPython is such a mammoth. A small, clean approach is attractive.

Greg Ewing continued:
> My goals aren't quite the same as AnyGUI's, because ...
> ...
> However, there's a lot in common between the goals
> of our respective projects in terms of providing a
> simple, standardised, Pythonic API, which I still
> believe is sorely lacking in the Python world.

I agree wholeheartedly!

Donnal Walter
Arkansas Children's Hospital

Re: [Anygui-devel] OK, everyone...

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

Magnus:

> But I keep getting emails from people who say that Anygui is a
> "Good Idea(tm)"

Perhaps those are the people who want an API that's small, simple and
Pythonic, as opposed to big, complicated and warped in the direction
of some other language such as C++ or Tcl.

That's the goal of my own Python GUI project (which I *am* still
working on, by the way, despite appearances to the contrary!).

My goals aren't quite the same as AnyGUI's, because I only intend to
provide *one* implementation for each platform, preferably built as
directly as possible on whatever is provided natively, so that users
don't have to install any extra packages.

However, there's a lot in common between the goals of our respective
projects in terms of providing a simple, standardised, Pythonic API,
which I still believe is sorely lacking in the Python world.

We also seem to share the trait of having been in a not-quite-released
state for some time. :-) It will be interesting to see which of us
manages to release something useful first!

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

Re: [Anygui-devel] OK, everyone...

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

Laura Creighton <la...@st...>:

> I catch myself thinking 'what a cool, interesting bug.  I want to
> understand it.' -- all well and good, but notice I didn't say, 'I want
> to fix it.', which would be more useful for the project.

Even just finding it would be a big help -- most bugs
are trivial to fix once the cause is found!

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

Re: [Anygui-devel] Some thoughts about a plan

[Magnus L. H. <ma...@he...>]

Wezzy <we...@ya...>:
>
> Il giorno 16/feb/04, alle 14:57, Magnus Lie Hetland ha scritto:
> >
> >What do you think?
> 
> I think that starting with simple objectives is a good idea. i'm
> also agreed with you to reduce the backends' list, but i think that
> a native cocoa backend should be a good improvement.

OK, I'm open to suggestions here.

> In fact some people here play with mac and most important mac
> support from the others toolkit is a bit immature, so anygui could
> be a great alternative (at least for simple projects).

Sounds good. But isn't Cocoa supporter through, for example, wxPython
or something? (I really know nothing about that -- just wondering.)

The main reason I chose the five back-ends I did was that I feel
confident that I can work on them myself, if needed (for possible
future bugfixes). But that need not be an absolute requirement.

What is the general feeling about this? Matt and Alex -- you're OS X
guys; what do you think? Perhaps this is the sort of thing you were
envisioning?

> One  more suggestion, probably is a good idea to work on
> documentation, this can help new developer and increase anygui
> users.

Yes, I agree. I think a complete (in the sense that it describes all
the main features and doesn't contain "FIXME"-sections) manual would
be one of the goals of a final release.

I'll gladly (although with some trepidation -- it's been a while) take
on the work of updating the docs. There is a need to, at the very
least, update the description of in-place updates vs. the new model
code. If I recall correctly, we decided to drop in-place modification
in the interest of simplicity (there were just too much semantic
weirdness).

(I've been thinking about switching to using plain text in the docs
and adding mark-up with Atox (atox.sf.net), another project of mine.
Hm. Maybe I could add an Anygui interface to Atox as well? <wink>)

> (i promise that i spend some times by learning better english :-)

I think you're English is quite alright :)

> Fabio "Wezzy" Trezzi

-- 
Magnus Lie Hetland           "The mind is not a vessel to be filled,
http://hetland.org            but a fire to be lighted."  [Plutarch]

Re: [Anygui-devel] PythonWin

[Magnus L. H. <ma...@he...>]

Marco <Si...@ev...>:
>
> Dear Sirs,
> 
> I have joined Python developers for two months and anygui for a week
> (a newbie, indeed).

Hi!

Just a quick note (although you may have received notice from the
mailing list already): You need to subscribe to be able to post
normally.

> On my home computer I have the following
> software:
> 
> Operating system        Windows 98
> Python                        2.3.2
> PythonWin                   win32all build 157
> Tkinter                        8.4.3
> 
> Mswgui is the default gui (I checked it too by backend()). But when
> I make use of the recommended code:
> 
> from anygui import *
> win=Window()
> app=Application()
> app.add(win)
> app.run()
>  
> I get this message of error:
> 
> Runtime error!
> Program: C:\PYTHON23\PYTHONWIN.EXE
> abnormal program termination 
> 
> On the contrary, by using Tkinter and the following code:
> 
> import anygui.backends.tkgui as gui
> win=gui.Window()
> app=gui.Application()
> app.add(win)
> app.run()
> 
> 
> I just get a Tkinter window.
>  
> Why this fact? Is it a Pythonwin bug, a Windows bug, an anygui bug,
> a virus or anything else?

It might very well be caused by Anygui, but I'm no msw expert, so I
can't really say what could cause this sort of exit.

Which version of Anygui are you using? I you're using 0.1.1, perhaps
you could consider trying the CVS version and see if that works
better? The codebase has been dormant for quite some time, but we are
discussing the possibility of packaging up the CVS source as a new
release, and any testing will be helpful.

(Also, it will be much more practical to fix bugs found in the current
CVS version than in 0.1.1.)

> Thank You!
>  
> Marco Siracusano - Si...@ev... - Florence (Italy)

-- 
Magnus Lie Hetland           "The mind is not a vessel to be filled,
http://hetland.org            but a fire to be lighted."  [Plutarch]

[Anygui-devel] PythonWin

[Marco <Si...@ev...>]

Dear Sirs,

I have joined Python developers for two months and anygui for a week (a =
newbie, indeed). On my home computer I have the following software:

Operating system        Windows 98
Python                        2.3.2
PythonWin                   win32all build 157
Tkinter                        8.4.3

Mswgui is the default gui (I checked it too by backend()). But when I =
make use of the recommended code:

from anygui import *
win=3DWindow()
app=3DApplication()
app.add(win)
app.run()
=20
I get this message of error:

Runtime error!
Program: C:\PYTHON23\PYTHONWIN.EXE
abnormal program termination=20

On the contrary, by using Tkinter and the following code:

import anygui.backends.tkgui as gui
win=3Dgui.Window()
app=3Dgui.Application()
app.add(win)
app.run()


I just get a Tkinter window.
=20
Why this fact? Is it a Pythonwin bug, a Windows bug, an anygui bug, a =
virus or anything else?
=20
Thank You!
=20
Marco Siracusano - Si...@ev... - Florence (Italy)

=20

=20

Re: [Anygui-devel] Some thoughts about a plan

[Wezzy <we...@ya...>]

Il giorno 16/feb/04, alle 14:57, Magnus Lie Hetland ha scritto:
>
> What do you think?
>
>

I think that starting with simple objectives is a good idea. i'm also 
agreed with you to reduce the backends' list, but i think that a native 
cocoa backend should be a good improvement. In fact some people here 
play with mac and most important mac support from the others toolkit is 
a bit immature, so anygui could be a great alternative (at least for 
simple projects).
One  more suggestion, probably is a good idea to work on documentation, 
this can help new developer and increase anygui users.

(i promise that i spend some times by learning better english :-)

Fabio "Wezzy" Trezzi

Re: [Anygui-devel] OK, everyone...

[Magnus L. H. <ma...@he...>]

Laura Creighton <la...@st...>:
>
> I think that part of the problem is that while anygui is fun to think about,
> and learn about graphical systems and widget hacking with, it is rather
> less needed now than it was when we first proposed it.

I think you may be right. (I've read Alex's response, and he makes
some interesting points too.)

I think it was really unfortunate that our efforts petered out before
we got some kind of release of the 0.2 codebase. Many people won't use
something that isn't released (reasonably enough). It may be that
Anygui won't be a widespread toolkit, but I still think it deserves at
least one final release based on its current architecture.

> A lot of the people who were initially interested in using anygui, I think, 
> were actually looking for something more like PythonCard.  When that 
> happened, they moved there.  So did Patrick.  So there went the 'I
> want a simple GUI' people.

Yeah. Except me <wink>.

[snip about running everywhere and Tkinter]
> On the other hand, wxPython and PyQt are being ported to everything 
> under the sun.  There was a time when wxWindoes did not run on the Mac,
> but no more, and so on and so forth.

Yeah. And with the new wx package, the aesthetics of the wxPython API
is acceptable even to weirdoes like me... (who don't like names like
wxButton etc.) :]

> Thus the people who had the rationale (I cannot program in XXX, my
> favourite gui, because it does not run everywhere) are now finding
> that it actually does run all the places they were interested.

Yes, I agree.

Thus, trying to compete with (e.g.) wxPython is quite certainly a lost
cause. But I keep getting emails from people who say that Anygui is a
"Good Idea(tm)", so even if it doesn't get much more complete than it
is (except, perhaps, with the addition of menus and basic dialogs) I
think getting a release out, and maintaining it with bugfixes seems
like a useful thing to do. Or, whatever the reason, I, for one, would
like to do it.

> Finally, there were the people who were interested in anygui as a
> teaching tool.  We are still interested, but there never was a lot
> of us.

True.

> And we aren't the most useful people to have on a project, because
> we aren't fanatics about finding things in a broken, half-finished
> state, because we can learn a lot about how things ought to work by
> watching things that don't work properly.

:)

> So we will have fun no matter what you do. I catch myself thinking
> 'what a cool, interesting bug.  I want to understand it.' -- all
> well and good, but notice I didn't say, 'I want to fix it.', which
> would be more useful for the project.

Sure. But: If we get a release out (however basic) there will be a
sort of a feedback-loop in place: If nobody uses Anygui, nobody will
report bugs, and it won't really matter. The more people uses it, the
more people will report bugs, and the more it will matter. Fixing
reported bugs is (I think...) easier than finding them in the first
place.

> But running all the demos in a wide-variety of gui-ends is still a blast.
> The problem is that I get a nagging feeling 'isn't there something else
> you could be doing that would be more useful'?  I think that this is the
> feeling, more than anything, which kills projects.

Sure.

But mightn't getting a release out that is actually usable, and which
could (by a few of us) be maintained mainly in terms of bugfixes, be
worth it? We could then clearly define what Anygui is and what it
isn't and if anyone has use for it, they can use it.

It just seems like a pity that all the effort we've put into it should
just sit there because of the last couple of hurdles...

> Just my two cents,
> Laura

-- 
Magnus Lie Hetland           "The mind is not a vessel to be filled,
http://hetland.org            but a fire to be lighted."  [Plutarch]

[Anygui-devel] Some thoughts about a plan

[Magnus L. H. <ma...@he...>]

Laura raises some valid points (I'll think about them and answer them
more specifically in a while) -- I'd just like to throw in some
thoughts in parallel:

Would it be more realistic, and therefore also motivating (and
therefore even *more* realistic <wink>) to try to achieve a more
modest set of objectives than those we have dreamed up so far? We
could keep the current stuff in a "pie-in-the-sky-TODO-file" and
really trim/slim down the real stuff, and perhaps get somewhere, and
perhaps even feel that we have something we can call a *complete*
Anygui release?

This is based on the situational factor that we cannot assume that
people have lots of time, or can sustain enthusiasm over a long period
of time.

So, simply put, I suggest that we (1) cut down on the back-ends (for
now, anyway), perhaps to the Big Five: wx, qt, msw, tk, and java
(still quite a few), and (2) limit our ambitions to (a) adding menus
(not popup-menus), and (b) file dialogs and plain info/warning
dialogs.

  Note: Work on other back-ends is OK -- we just shouldn't commit
  ourselves to keep maintaining them (unless someone is willing to
  commit...?)

That's it. Nothing more. Then we can focus our efforts on making this
stuff work, and then on making it work better. I think this
functionality is more than enough for lots of useful applications --
at least enough for a release or two that will be stable enough that
people will *dare* to use it. And -- if someone feels like it,
plugging in some new feature (e.g. graphics or what-have-you) that
could be handled as a discrete, fixed-time project.

What do you think?

BTW: If/when we decide to add a Canvas -- maybe we should consider the
DrawBot API (or something close)? Piddle/sping is fine, but DrawBot is
a bit simpler... Just a (pie-in-the-sky-)thought
(http://effbot.org/zone/drawbot.htm).

-- 
Magnus Lie Hetland           "The mind is not a vessel to be filled,
http://hetland.org            but a fire to be lighted."  [Plutarch]

Re: [Anygui-devel] OK, everyone...

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

On Monday 16 February 2004 02:00 pm, Laura Creighton wrote:

   ... [a fair analysis, snipped] ...

It seems to me that the current crop of GUI toolkits and trends therein do not 
support, in roughly decreasing order of importance/magnitude...:

1. people who want to program a GUI that will run on Classic Python, jython,
    and IronPython (or other variants on Python for dotNet) -- no current
    toolkit, I think, does reasonable abstraction covering all of wx and/or
    Qt, Awt and/or Swing, and WindowsForm;

2. similarly, people who want to have a "normal" GUI _and_ an HTML/Dynamic
    HTML version thereof for running on browsers;

3. even obscurer needs connected to running GUIs on (e.g.) embedded devices
    with PyGame, cellphones, text-only connections, Flash, DVD menus, ...

Whether all of this, plus the "using it to teach" people, amount to critical 
mass sufficient to get anygui off the ground again, I dunno.  After all, it's 
debatable whether it's _sensible_ to want to code a GUI only once for (e.g.) 
a smart cellphone's 128 x 128 (if that) screen, a web browser, and a 
reasonably sized computer and screen -- usability factors and tradeoffs would 
no doubt suggest coding N totally separate GUIs for such disparate cases...


Alex

Re: [Anygui-devel] OK, everyone...

[Laura C. <la...@st...>]

I think that part of the problem is that while anygui is fun to think about,
and learn about graphical systems and widget hacking with, it is rather
less needed now than it was when we first proposed it.

A lot of the people who were initially interested in using anygui, I think, 
were actually looking for something more like PythonCard.  When that 
happened, they moved there.  So did Patrick.  So there went the 'I
want a simple GUI' people.

Then there were the people who wanted something that ran _everywhere_.
They didn't want to assume that their customers had any particular gui
kit.  I think that this segment has shrunk.  More and more hardware is
being consigned to the 'too old to matter/we don't care about you any
more' list.  And the perception of the gui kits has also changed.
Tkinter isn't being maintained any more, so when new hardware comes
out, Tkinter will at soem point simply not run on it.  And nobody is
stepping up to change this -- keeping Tkinter on new hardware is nobody's
dream job, it seems.

On the other hand, wxPython and PyQt are being ported to everything 
under the sun.  There was a time when wxWindoes did not run on the Mac,
but no more, and so on and so forth.  Thus the people who had the
rationale (I cannot program in XXX, my favourite gui, because it
does not run everywhere) are now finding that it actually does run
all the places they were interested.

Finally, there were the people who were interested in anygui as a
teaching tool.  We are still interested, but there never was a lot 
of us.  And we aren't the most useful people to have on a project,
because we aren't fanatics about finding things in a broken, half-finished
state, because we can learn a lot about how things ought to work by
watching things that don't work properly.  So we will have fun no
matter what you do. I catch myself thinking 'what a cool, interesting
bug.  I want to understand it.' -- all well and good, but notice I didn't
say, 'I want to fix it.', which would be more useful for the project.

But running all the demos in a wide-variety of gui-ends is still a blast.
The problem is that I get a nagging feeling 'isn't there something else
you could be doing that would be more useful'?  I think that this is the
feeling, more than anything, which kills projects.

Just my two cents,
Laura

Re: [Anygui-devel] OK, everyone...

[Magnus L. H. <ma...@he...>]

Thomas Heller <th...@py...>:
>
[snip]
> I'm sorry to say so, but I have no time nor motivation to work on
> anygui any longer.

I understand. (I've actually noted that already, from an earlier
response.)

Thanks for all your effort so far :)

-- 
Magnus Lie Hetland           "The mind is not a vessel to be filled,
http://hetland.org            but a fire to be lighted."  [Plutarch]

Re: [Anygui-devel] OK, everyone...

[Magnus L. H. <ma...@he...>]

Wezzy <we...@ya...>:
>
> Hi, i'm not an experienced developer but i'm ready learn more. You
> can add me to the list.

Great!

> Unforunaly like Alex and Matthew i'm also interested in Apple Os X
> backend.

That doesn't have to be a problem. I guess several of the back-ends
(e.g. tk, wx, qt, java) work in MacOS.

> I think that anygui is really a good idea!

Me too, actually <wink>

> Fabio "Wezzy" Trezzi

-- 
Magnus Lie Hetland           "The mind is not a vessel to be filled,
http://hetland.org            but a fire to be lighted."  [Plutarch]

Re: [Anygui-devel] OK, everyone...

[Magnus L. H. <ma...@he...>]

Matthew Schinckel <ma...@nu...>:
>
[snipped about pair programming]
>
> Seriously, that sounds great.  I suspect we should make sure we are 
> using the same versions of everything.  At the moment I have a largely 
> vanilla OSX setup, and haven't really done much, other than install the 
> development tools.

If you two could get something going here, that would be Really
Great(tm).

[snip]

-- 
Magnus Lie Hetland           "The mind is not a vessel to be filled,
http://hetland.org            but a fire to be lighted."  [Plutarch]

Re: [Anygui-devel] OK, everyone...

[Magnus L. H. <ma...@he...>]

Alex Martelli <al...@ya...>:
>
[snip]
> We might have some sinergy here... I now also own a Mac (the first
> in my life, 

:)

I've had a few macs many years back, and some of my colleagues have
OSX-boxes. Cool stuff.

> a 12" iBook G4 w/Panther) and am itching to try my hand at some
> MacOS X development.

Sounds good. Itching is always good ;)

> I have no dev't experience there, yet, though PyObjC looks yummy.  I
> have also installed the GPL version of the latest Mac Qt (a toolkit
> with which I do have experience, but not in the latest version and
> only on Linux and Windows) -- PyQt still had some teething trouble
> on the Mac last time I tried it (about 3 weeks ago), but it might be
> OK now, so that could be an alternative, too.

Both sound great; as we already have a Qt back-end it would be very
good if you (the two of you) could have a look at that (although
perhaps there are others with similar interests?)

> "Pair programming" (albeit not side by side, but at a distance:-)
> might provide me with just the right amount of incentive to squeeze
> this project into my overflowing schedule...

Wonderful.

Both of you: Feel free to start tweaking if you want. I guess getting
the existing (clearly suboptimal) test suite to run properly is the
first order of business. If you have other things you'd like to do,
then be my guest.

> Alex

-- 
Magnus Lie Hetland           "The mind is not a vessel to be filled,
http://hetland.org            but a fire to be lighted."  [Plutarch]

Re: [Anygui-devel] OK, everyone...

[Thomas H. <th...@py...>]

Magnus Lie Hetland <ma...@he...> writes:

> I have now finished my Ph.D and have more or less settled into my new
> (for now, temporary) research/teaching position, and it might be time
> to see if it's feasible to get 0.2 out there. I was sort of spurred on
> by the somewhat bitter postings about Anygui (and me) on
> comp.lang.python recently (although I'm not sure whether to be
> motivated or demotivated) -- but the question is, what is a realistic
> assessment of Anygui's future?
>
> So:
>
>   1. Who are interested in continuing some work on Anygui?
>
>      Please either email the list or me, with your back-end
>      preference(s).

I'm sorry to say so, but I have no time nor motivation to work on anygui
any longer.

>   2. Do you have any strategy suggestions?
>
>      How could we structure our process to make it easier to keep the
>      project going? How about the project objectives?

Thomas

Re: [Anygui-devel] OK, everyone...

[Magnus L. H. <ma...@he...>]

Matthew Schinckel <ma...@nu...>:
>
> Hi Magnus/All,
> 
> I might be keen to get involved again - I'm currently set up with a PC 
> (running XP, and a Mac (OSX.3).  I don't have a lot of experience with 
> programming any toolkits here, but am prepared to learn!

Excellent!

> Beosgui is not something I can develop any longer - my Mac with BeOS is 
> waiting to be sold for scrap (!), and I'm not sure I'll be able to 
> install it on either of my new computers - maybe when a workable 
> version of open-beos comes out.

OK. If we're going to get Anygui off the ground (and, yes, I *still*
think that it is possible) I think we need to focus. Perhaps BeOS is
marginal enough that it can wait for a few versions anyway?

> So, the short of this is, I am prepared to do testing for toolkits on 
> OSX/XP (prefer OSX!), and build up to developing as I get confidence.

Great.

> Matt.

-- 
Magnus Lie Hetland           "The mind is not a vessel to be filled,
http://hetland.org            but a fire to be lighted."  [Plutarch]

Re: [Anygui-devel] OK, everyone...

[Wezzy <we...@ya...>]

Hi, i'm not an experienced developer but i'm ready learn more. You can 
add me to the list. Unforunaly like Alex and Matthew i'm also 
interested in Apple Os X backend. I think that anygui is really a good 
idea!

Fabio "Wezzy" Trezzi

Re: [Anygui-devel] OK, everyone...

[Matthew S. <ma...@nu...>]

On 16/02/2004, at 10:05 PM, Alex Martelli wrote:

> On Monday 16 February 2004 12:22 pm, Matthew Schinckel wrote:
>> Hi Magnus/All,
>>
>> I might be keen to get involved again - I'm currently set up with a PC
>> (running XP, and a Mac (OSX.3).  I don't have a lot of experience with
>> programming any toolkits here, but am prepared to learn!
>>
>> Beosgui is not something I can develop any longer - my Mac with BeOS 
>> is
>> waiting to be sold for scrap (!), and I'm not sure I'll be able to
>> install it on either of my new computers - maybe when a workable
>> version of open-beos comes out.
>>
>> So, the short of this is, I am prepared to do testing for toolkits on
>> OSX/XP (prefer OSX!), and build up to developing as I get confidence.
>
> We might have some sinergy here... I now also own a Mac (the first in 
> my life,
> a 12" iBook G4 w/Panther) and am itching to try my hand at some MacOS X
> development.  I have no dev't experience there, yet, though PyObjC 
> looks
> yummy.  I have also installed the GPL version of the latest Mac Qt (a 
> toolkit
> with which I do have experience, but not in the latest version and 
> only on
> Linux and Windows) -- PyQt still had some teething trouble on the Mac 
> last
> time I tried it (about 3 weeks ago), but it might be OK now, so that 
> could be
> an alternative, too.  "Pair programming" (albeit not side by side, but 
> at a
> distance:-) might provide me with just the right amount of incentive to
> squeeze this project into my overflowing schedule...

Heh! I've obviously been emailing only to relative newbies, I've even 
started adding my replies to the top of messages!

Seriously, that sounds great.  I suspect we should make sure we are 
using the same versions of everything.  At the moment I have a largely 
vanilla OSX setup, and haven't really done much, other than install the 
development tools.

< Kinda OT>
Something I have done is play around a bit with the GUI creation tool - 
if you Ctrl-click on an app, and choose Show Package contents (or go 
into a Terminal and cd to the <AppName>.app/Contents/Resources 
directory) you may find a <name>.nib file, that, if Development tools 
has been installed, allows you to tweak the user interface.

I really like the way packages/apps/bundles are handled on OSX - I 
think it's a neat way to do stuff.

The other options are to look at some of the programs that are designed 
for creating interfaces for bash scripts and the like - I started to 
look at this a couple of weeks ago, before I agreed to turn a video a 
guy had created into a DVD...Platypus and iHook seemed like the best 
candidates.
</OT>

Matt.
>
> Alex
>
>
-- 
Matt Schinckel <ma...@nu...>

Re: [Anygui-devel] OK, everyone...

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

On Monday 16 February 2004 12:22 pm, Matthew Schinckel wrote:
> Hi Magnus/All,
>
> I might be keen to get involved again - I'm currently set up with a PC
> (running XP, and a Mac (OSX.3).  I don't have a lot of experience with
> programming any toolkits here, but am prepared to learn!
>
> Beosgui is not something I can develop any longer - my Mac with BeOS is
> waiting to be sold for scrap (!), and I'm not sure I'll be able to
> install it on either of my new computers - maybe when a workable
> version of open-beos comes out.
>
> So, the short of this is, I am prepared to do testing for toolkits on
> OSX/XP (prefer OSX!), and build up to developing as I get confidence.

We might have some sinergy here... I now also own a Mac (the first in my life, 
a 12" iBook G4 w/Panther) and am itching to try my hand at some MacOS X
development.  I have no dev't experience there, yet, though PyObjC looks 
yummy.  I have also installed the GPL version of the latest Mac Qt (a toolkit 
with which I do have experience, but not in the latest version and only on 
Linux and Windows) -- PyQt still had some teething trouble on the Mac last 
time I tried it (about 3 weeks ago), but it might be OK now, so that could be
an alternative, too.  "Pair programming" (albeit not side by side, but at a 
distance:-) might provide me with just the right amount of incentive to 
squeeze this project into my overflowing schedule...


Alex

Re: [Anygui-devel] OK, everyone...

[Matthew S. <ma...@nu...>]

Hi Magnus/All,

I might be keen to get involved again - I'm currently set up with a PC 
(running XP, and a Mac (OSX.3).  I don't have a lot of experience with 
programming any toolkits here, but am prepared to learn!

Beosgui is not something I can develop any longer - my Mac with BeOS is 
waiting to be sold for scrap (!), and I'm not sure I'll be able to 
install it on either of my new computers - maybe when a workable 
version of open-beos comes out.

So, the short of this is, I am prepared to do testing for toolkits on 
OSX/XP (prefer OSX!), and build up to developing as I get confidence.

Matt.

On 16/02/2004, at 8:59 AM, Magnus Lie Hetland wrote:

> I have now finished my Ph.D and have more or less settled into my new
> (for now, temporary) research/teaching position, and it might be time
> to see if it's feasible to get 0.2 out there. I was sort of spurred on
> by the somewhat bitter postings about Anygui (and me) on
> comp.lang.python recently (although I'm not sure whether to be
> motivated or demotivated) -- but the question is, what is a realistic
> assessment of Anygui's future?
>
> So:
>
>   1. Who are interested in continuing some work on Anygui?
>
>      Please either email the list or me, with your back-end
>      preference(s).
>
>   2. Do you have any strategy suggestions?
>
>      How could we structure our process to make it easier to keep the
>      project going? How about the project objectives?
>
> - M
>
> -- 
> Magnus Lie Hetland           "The mind is not a vessel to be filled,
> http://hetland.org            but a fire to be lighted."  [Plutarch]
>
>
> -------------------------------------------------------
> SF.Net is sponsored by: Speed Start Your Linux Apps Now.
> Build and deploy apps & Web services for Linux with
> a free DVD software kit from IBM. Click Now!
> http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click
>
>
-- 
Matt Schinckel <ma...@nu...>

[Anygui-devel] OK, everyone...

[Magnus L. H. <ma...@he...>]

I have now finished my Ph.D and have more or less settled into my new
(for now, temporary) research/teaching position, and it might be time
to see if it's feasible to get 0.2 out there. I was sort of spurred on
by the somewhat bitter postings about Anygui (and me) on
comp.lang.python recently (although I'm not sure whether to be
motivated or demotivated) -- but the question is, what is a realistic
assessment of Anygui's future?

So:

  1. Who are interested in continuing some work on Anygui?

     Please either email the list or me, with your back-end
     preference(s).

  2. Do you have any strategy suggestions?

     How could we structure our process to make it easier to keep the
     project going? How about the project objectives?

- M

-- 
Magnus Lie Hetland           "The mind is not a vessel to be filled,
http://hetland.org            but a fire to be lighted."  [Plutarch]

[Anygui-devel] Re: anygui status query, other thoughts

[Magnus L. H. <ma...@he...>]

Stan <ti...@us...>:
>
>=20
> Hi Magnus,
>=20

Hi! I'm cc'ing this to the python-devel list; I hope you don't mind.

> I'm casting about for the best UI option for Python (for open source
> academic proof-of-concept projects), and am having a rather
> difficult time figuring out where to allocate my limited time.

That I can understand.

> I am quite familiar with Swing, and have played around with Jython,
> but I remain worried that Jython - although it's a great tool - may
> be experiencing a slow death from lack of committed developers.
> Will it incorporate Python 2.3 features and make use of SDK 1.5
> improvements?

I don't know anything about the development status of Jython.

Samuele: Are you here? Perhaps you know something?

> It seems like Finn Bock is the only active developer, and that is
> depressing considering the effort that went into the project, and
> its usefulness.

I guess that is something that will happen to many open source
projects. (Anygui was just criticized for the same thing on
comp.lang.python.)

> Perhaps it is simply too complex for most people to participate in,
> and everyone (such as myself) is waiting on the sidelines.

I don't know.

> Is Anygui still in active development?

Not very actively right now -- but I still think (perhaps na=EFvely?)
that there may be a new release, incorporating all the drastic changes
in CVS.

I see one main need to make this possible: It must be possible to work
on the code base alone (either for me or others) and to release in
small increments.

Currently we've made a *big* change to the entire architecture, and
testing all the back-ends is a bit cumbersome (and really requires you
to have several operating systems installed, or to have more than one
developer available).

> The commit list dates are somewhat old.

Yes, indeed.

> Finally, I wonder what you think of the following idea.  Is there
> value in replacing the popular approach of SWIG-type linking of the
> Python UI layer to the underlying C/C++ UI libraries, with a
> client-server model?

Not sure, really. Could be an interesting concept to try out.

> It would be interesting if one could define a modern UI protocol,
> something like X for the new millennium with the benefit of design
> pattern and XML-RPC experience of recent years, and then have the
> various UI rendering systems implement such servers.
>=20
> What are your thoughts?

I think it's quite interesting.

> Thanks,
>=20
> Stan

--=20
Magnus Lie Hetland           "The mind is not a vessel to be filled,
http://hetland.org            but a fire to be lighted."  [Plutarch]

RE: [Anygui-devel] How active is development?

[Clark, C. <Chr...@ca...>]

> -----Original Message-----
>=20
> Actually, I'm defending my thesis on thursday

Good luck on Thursday Magnus!

Coming back to curses support with anygui; one option would be to use =
the (new) GTK curses interface. It was on slashdot.org a few months =
back, someone implemented the GTK api for a curses front-end =
http://zemljanka.sourceforge.net/cursed/. You could build that and then =
either use anygui (with GTK as the front-end) or use PyGTK (built with =
the curses front end).

I'm a big fan of AnyGUI so please don't take the following as an "anygui =
flame"! -- My experience with anygui is that if you want/need control =
over keyboard events (e.g. has the escape key been pressed, widget tab =
sequence control, etc.) to speed up GUI interaction (or rather, non =
graphical interaction) then anygui currently doesn't offer much/any =
control. For my project ( http://sourceforge.net/projects/yacddb/ )I =
ended up implementing a similar solution to Magnus' idea of supporting =
multiple back ends, I separated the application logic from the GUI; I =
wrote an anygui interface initially so that it can run anywhere and then =
later on implemented a specific GUI to allow finer control (I actually =
cataloged about 500 CD's using the anygui interface so the lack of finer =
control wasn't that big a deal for my project). I suspect for an IM =
client, keyboard short cuts are going to be a big requirement, you =
mileage may vary though.

Chris