Hi there,

I think the most advanced GUI we saw was http://www.thbbpt.net/interfascia/.

I think you would be mroe then welcome, a proper GUI lib for Processing would boosts its prominence in doing usable stuff with it, so I guess it would be tremendous.

Swing would limit you to Java 2 and later, which is becoming less of an issue, but an issue none-the-less.  SWT would require the program to run as standalone, since it requires native libraries.

However, while not simple to integrate in its current form, thinlet is a small (39KB) Java 1.1 (and applet) compatible gui with quite a number of features.  It allows for custom widgets (ie, a Processing canvas), but it would take a little bit of hacking to get them to play well with each other.  Certainly a project worth exploring though, for anyone interested in advanced GUI work with Processing, but doesn't want to let go of Applet and Java 1.1 support.

Marcello

Personally I think that it sounds very attractive with the concept of exporting stuff to applications that use OS looking widgets. And project custom widgets too.

And I'd go for applications any day to get rid of the applet sandbox which makes java (and processing in extension) much more limited than the competition.

cello wrote on Nov 15^th, 2005, 3:54am:


...apart from Flash, which runs in a lot more people's browsers, and strikes me as the most obvious competition (what with ActionScript doing many - most - of the same things as Processing...)

About using Swing or AWT: I've tried using Swing Components with Processing, but there are serious issues with mixing Swing's lightweight components with Processing (such as heavy flickering).

A while ago I wrote a library that uses AWT, but I've been told by Ben that it still mixes light- and heavyweight components which may break on some systems. Still, I have never seen it misbehave on Windows and I use it for applications which need not run on other platforms, so it may be an option.

I've been thinking about writing a second version which would use native processing drawing methods. However there is already another library which works in that manner, and it's pretty far into development, so I'm not sure which way to go from here.

One of the beauties of Processing is the simplicity of its environment. One window + play button + stop button. What more do you need? For teaching programming to newbies, as I've been doing this year, Processing has been a godsend. That play button is great! It's so reassuring.

Previously, I taught introductory programming using Director, and spent the first half-hour of the class showing students how to get rid of all the excess crap. Our online tutorials start this way, as well.

So I would be worried if Processing turned into a beheamoth like Director, similar to what's now happening with Flash. Little by little functionalities are added, and the thing grows out of control. Most importantly, those development environments were once one good thing, and now have been layered with four, five, six, twenty different development logics. Its a mess.

Now, with that out of the way, and if we keep these goals of simplicity in mind, I think we can still discuss graphical development additions.

For one, I think some students would appreciate having a better way of visualizing items in the data folder. That might be a start.

I suggested another idea to Casey this summer, it's an idea that I've been exploring in another context. It's the idea of code reversability : the ability to generate code graphically, which in turn generates graphical code. This is different than MAX/MSP/PureData/EyesWeb. The idea might sound a little weird, but I'm sure you all get the jist. I think in the context of Processing the pedagogical interest of this is self-evident.

All this would would have to be done by someone else that Ben and Casey, I'm sure. They've already contributed enough and probably want to move on to other projects once out of beta.

Befunge is totally cool and I love all that stuff. There are other things like it. But I don't think it's exactly what I was talking about. Maybe I should look into it and see if I understand its use a little better. I always thought it was something more conceptual, anyway not really implemented in anything.

A question: did you mean Mindcrappity smack or braincrappity smack? Or did you mean the pseudo-situationist plug-in libraries for Max from several years back (I fought with those, didn't see anything like that).

I've been screwing around with things like what you describe for a while, and I love all that playful conceptual stuff, but I was thinking of something more pedagogical. I'm not sure that I can really give any specific examples for Processing, I'm more following an intuition, but the idea would be that you have code that can be generated visually, for example. I supose that in some ways Swing does this, but it would be interesting to find something more adapted to Processing. Rather than making buttons (I still don't understand why people want buttons, but hey, it's a free world), you would make more Processing-like code.

Who knows: drawing, then having code built from that. I've always been amazed at how programs like Flash still look like MacPaint. It's kind of a joke. Well, it might be funny to actually take the MacPaint interface, build it into Processing as a tool plug-in, but when you draw your MacPaint drawing, you actually build the code. Obviously, that's not reversable, that's just inverse programming. But it's a first step towards reversability. If you push the logic far enough you can get it to be reversable.

If I'm not making sense, don't worry. It's late and I've been teaching all day.