Visual programming, looking for graphics layer

[Ian Bicking]

On Thu, 2002-11-14 at 04:09, Terry Hancock wrote:
> Hi Ian,
> On Wednesday 13 November 2002 11:31 pm,  Ian Bicking wrote:
> > After implementing a little Logo interpreter, I wanted to do
> > something more novel and interesting, like
> > Boxer.  In the extremely likely case you don't know anything about
> > Boxer, the website is at:
> > 
> >   http://www.soe.berkeley.edu/boxer/
> > 
> > It's a neat teaching language, where it has some graphical ways to
> > present programming structure.  Sadly its only available for Macs, and I
> > don't know if development is active.  But I've put up a little graphic
> > taken from one of the papers (and fixed up a bit) to give a feel:
> > 
> >   http://colorstudy.com/tmp/boxer-capture.gif
> 
> I've always been interested by visual metaphors for programming (I've never 
> found one of actual practical use to me, but I keep hoping to -- there's a 
> couple, like "overflow" that I want to spend some time to learn).  Anyway,
> that's fairly interesting  (not really enough information on the web pages to 
> form a real opinion, though -- might have to dig deeper).

Yeah, I'm not really looking for a language for my own use, but I'm more
interested in making programming more accessible for others.  I haven't
heard of "overflow" -- what's that?

> > The hard part is that this sort of layout is fairly hard to do.  Not
> > only do you have text inside different sorts of boxes, but an important
> > part of the language is that you also have non-text literals (like
> > colors and shapes, and even lists may be represented in a graphical
> > fashion).  All these need to be manipulatable.
> 
> Most of these things seem like fairly common GUI widgets to me -- the sticky 
> part is probably editing them interactively.

Yes, the editing part is difficult.  The boxes also don't seem to fit
into any widget I can think of -- they can be nested and manipulated,
but the only manipulatable thing like that I can think of is windows,
and decorated windows are way too distracting.  I think there's some
false cognates in using normal widgets too.

So I'm thinking pyui is really the right thing to use -- or at least the
basis for the right thing.  It's someplace I can create portable
widgets, for instance.

> > I'm hoping to get some advice or pointers on something already available
> > that can make this easier.  I could use pygame, maybe even with pyui,
> > but that's still a long way from what I'd have to do for even the most
> > minimal functionality.  I've also had a hard time understanding pyui's
> > architecture -- there's something magic in there and I can't tell where
> > things actually get *done*... but I'm sure that's surmountable.  Maybe
> > that's where I should be looking.
> 
> I've been tinkering with PyUI (trying to implement the AWT renderer so it can 
> be used in Jython -- following up the browser applets thread I started a few 
> days ago).  Clearly, I'm not an expert yet, but I plan to spend a lot of time 
> with it -- maybe we can figure it out together?
> 
> Briefly, it appears to me that a PyUI renderer starts up and calls a program 
> to run under PyUI using that renderer. The program creates widgets to respond 
> to various events. At that point, the program idles, waiting for events 
> posted from the renderer to PyUI's events mechanism which drives the 
> modification of the GUI model inside of PyUI. The model is rendered to the 
> display by the renderer. Interestingly, it doesn't really appear to matter 
> whether the renderer polls for events or catches events (as in interrupts).  
> The renderer is pretty simple, and just has to handle drawing and catching 
> the events. So far the most complicated thing seems to be fonts.
> 
> I'm not sure what exactly you meant by "things" and "done", but I hope that 
> summary is helpful in some way.
> 
> The one thing I find frustrating with PyUI (as it is now), is that many of 
> the primitive data structures "rect", "pos", "font" aren't really very well 
> defined.  I'm not sure if this is a problem for the application programmer, 
> though.

Yes, I'd be interested in trying to figure out PyUI.  I contacted that
author at one time and didn't get a response (I was trying to figure out
how to use raw pygame with pyui) -- I suspect that it isn't being
actively worked on at the moment, or that the author has obligations
elsewhere.

Right now I see only an announcement list for pyui -- maybe a good place
to start would be to get one of the project admins to set up a
discussion list -- then even if we don't get very far, it will live on
in history ;)

When I was looking at pyui, I wasn't able to figure out where the
rendering really happened.  Instance variables were being used, and I
wasn't able to find where they were created or where they ended up. 
Stuff like that.  I wanted to pick it apart, and I just couldn't figure
it out -- which is unusual with Python code.

  Ian