Processing 1.0 - Processing Discourse - ? Standard UI Class for Processing

Markavian

Re: ? Standard UI Class for Processing
Reply #15 - Jun 13^th, 2005, 2:29am

Ok, this the original place where I intended to discuss a standard GUI libary. Since my last post several things have happened:

1) I emailed brendan again but didn't get a response.

2) Phillip Seifned released his SpringGUI class/libary which ports AWT components into Processing. I was very impressed when I saw this, you should go see the example here:
http://www.repeatwhiletrue.com/SpringGUI/examples/allElements/index.html
Information/Download:
http://www.repeatwhiletrue.com/SpringGUI/

3) After seeing Phillip's work, and understanding how vastly different our approaches were I pushed on with my version/vision of a GUI class. I am pleased to show a working example here:
http://mkv25.net/applets/MyGUI_a2/

There is no supporting documentation (yet) but I feel that the major features (minus the components) are all in place.

From the examples above ^
What components/features would people want in a GUI class?

I've short-listed these basic items as targets for a proper release:
- Button
- PinSlider
- (TextInput)
- (CheckBox)
- (RadioButton)

All my components so far feature _scale and _rotation variables which I think are quite handy. All objects draw from the centre _x, _y outwards - and this is the point they rotate and scale from.

I have also put quite of bit of effort into the MyGUIStyle class so that people can easily customize the colours. This is all shown off in my example (MyGUI_a2)

Ricard

Re: ? Standard UI Class for Processing
Reply #16 - Jun 13^th, 2005, 1:48pm

the MyGUI looks great! tanks for it!

few ideas:
- 2D minimalist version of the interface (without shadows) (maybe even with a change of alpha when onFocus) (I guess this is very personal...)
- panels or containers (kind of like windows) if possible with resize, minimize move around,... These panels could contain things like PGraphics and other GUI stuff (I know this one is really hard)
- other components could be knobs, progress bars,...

Markavian

Re: ? Standard UI Class for Processing
Reply #17 - Jun 13^th, 2005, 5:14pm

As preference goes, the shadows can be removed, and alpha could be added. However, these features are major parts of how the components are drawn. People can easily develop their own versions of my components that use their own draw methods. I'll stick to my set of shadows as I've already planned out all the different states in a bitmap on my HDD. I've tried to emulate all the different states you see in the windows gui:

For reference they include:
no hover
hover
focus + hover
focus + no hover
pressed / drag

You can also have drag + no hover, but I decided to leave that state out. Anyhow, each of those 5 state combinations have their own draw methods and colours.

I definitely agree that some sort of component holder is a must. The applications vary from scroll panes to windows that you drag around.

I think you could have a window with an animation running it, either by letting people supply their own custom methods (such as in http://jim.jklabs.net/ where you can specify custom methods defined in your main code), or by drawing off screen and setting the PImage contents of the window to match.

I'll give that some thought, but I'll work on radio buttons and checkboxes first. (checkboxes first, they're easier). Oh and documentation. And I was thinking about 3D buttons as well...

I got an interesting compliment from a friend saying she couldn't tell MyGUI it was written in Java, it looked like Flash to her. Very flexible scale and rotate functions in p5:)

Oh the other thing I wanted to say is: Anyone with some technical knowledge could they check over the structure of MyGUI and its components and suggest any improvements? I want to try and make this relatively efficient to run.

I did co some work on a light-weight mode where only components that were activated would have their draw methods called but it was difficult to implement on the user side of things because they had to order background drawing in certain places and it made the code messy.

Markavian

Re: ? Standard UI Class for Processing
Reply #18 - Jun 18^th, 2005, 12:50am

Latest update:
http://mkv25.net/applets/MyGUI_a4/

I've written in support for MyGUIGroup objects. _visible and _disabled states now work.

Rotation system has been changed from radians to degrees to be more user friendly (its easier to round up to 90 degrees then PI).

Flat shading has been applied to all current components. A disabled draw state has been added. I wrote a more advanced tint function in MyGUIStyle so that tints can be applied at a % amount (between 0 min and 1 max tint).

There is a bug where multiple components in overlaying groups can both have focus at the same time, I couldn't program a fix for this, so dragging the button around may interact a bit funny - I'm not too concerned, people probably won't want to use that sort of feature too often (touch wood).

I've started documenting the methods a bit more neatly, still lots of work to do inc. researching Javadoc properly.

Next up I'm hoping to start programming the other objects/components on my list.

Markavian

Re: ? Standard UI Class for Processing
Reply #19 - Jun 23^rd, 2005, 12:39am

Progress! I've figured out how to properly put together my library, so that it works as a library, and works with processing:

A dawn of a new age? Perhaps

Here I show my humble random squares applet which utilises the MyGUI class to give control of the squares over to the mouse, no more hidden key board commands I say!

http://mkv25.net/applets/guiRandomSquares/

If you want to use/play I've published the class here: Unzip into your processing-install/libraries/ folder
http://mkv25.net/MyGUI/

No documentation at all, tons of features. Email processing@mkv25.net for info.

« Last Edit: Jun 27^th, 2005, 4:30am by Markavian »

Markavian

Re: ? Standard UI Class for Processing
Reply #20 - Jun 27^th, 2005, 4:24am

Daa daa - the latest and greatest:

http://mkv25.net/MyGUI/
Download the latest version here.

I've also spent all of today typing away making Javadoc tags in eclipse. The joy!. Not quite finished with the documentation yet but I've uploaded what I've got.

I will be putting together an actual examples website for MyGUI at somepoint as well. For the moment, the javadoc doc is the best source of information for you.

Installation : unzip MyGUI_####.zip into processing-####/libraries/ so that it creates the document structure:
processing-####/libraries/MyGUI/libary/MyGUI.jar

Heres are test examples of implementing MyGUI:
http://mkv25.net/applets/baseConversion/
http://mkv25.net/applets/guiTest3/
http://mkv25.net/applets/guiRandomSquares/

Markavian Full Member Offline Posts: 174	Re: ? Standard UI Class for Processing Reply #21 - Dec 3^rd, 2005, 6:03pm Note: MyGUI Version 0007 is incompatable with the latest versions of processing. It broke with 0093, and has a null pointer error with 0097. I'm looking into this and hope to release a working version soon.

Markavian

Re: ? Standard UI Class for Processing
Reply #22 - Dec 29^th, 2005, 8:05pm

Its like I'm talking to myself in this post.

Ok, I've released a fixed / updated version of MyGUI that now works as it did before but with the newer Processing 0098.

You can find the latest version of the library here:
http://www.mkv25.net/MyGUI/MyGUI_0009.zip

And documentation as always from:
http://www.mkv25.net/MyGUI/doc/

Some sample applets:
http://www.mkv25.net/applets/guiRandomSquares/
http://www.mkv25.net/applets/guiFonts/
http://www.mkv25.net/applets/guiTest3/
http://www.mkv25.net/applets/baseConversion/

Markavian

Re: ? Standard UI Class for Processing
Reply #23 - Apr 2^nd, 2006, 12:36am

Q: Sooo.. hi Markavian, how are you this month?

A: Well, good thanks... Someone emailed me about radio buttons for MyGUI. Sadly I don't have the time to write them in, but I did offer some advice and information on how to extend MyGUI. While sorting out a example I found a bit of bug 'extending' the abstract MyGUIObject class, because I hadn't declared it public.

Get the latest release here. Sorry, no fixes for OpenGL / D3D mode. Not been able to look into that.

http://www.mkv25.net/MyGUI/MyGUI_0010.zip

Also I set up this example, a basic 'Box' class that extends MyGUIObject and works in the MyGUI framework:
http://www.mkv25.net/applets/MyGUIExtended/

And for extra information and examples, I released the source .java files:
http://www.mkv25.net/MyGUI/MyGUI_0010_source.zip

Plenty for everyone to play with if they have time.

Feel free to post any questions or discuss here, I'll try to keep my eye on the message board a bit more frequently.

jhv2

Re: ? Standard UI Class for Processing
Reply #24 - May 22^nd, 2006, 1:01am

Hi Markavian, how are you this month?

I'm an on-again off-again user of Processing, and am excited to be exploring your work, instead of copy-and-pasting friend’s classes for sidebars and radio buttons. On behalf of all of the less code savvy out there, thank you for posting MyGUI, looks great.

Mr. Fry and Mr. Reas have done a fantastic job of documenting individual functions in Processing in the Reference section of the site, and I really value being able to see these little mini-applets demonstrating functions alongside the code that implements the feature.

I wonder if you have done, or are planning to do the same for MyGUI. A few visits to the distribution website have proven that I need to learn more before using your library.

Again, thank you for this fantastic work and I appreciate that this request potentially means even more work. However it should be noted that your efforts and the efforts of others like yours have made the Processing community the rich fantastic place that it is.

Continued success in all your endeavors,

J

brendn

Re: ? Standard UI Class for Processing
Reply #25 - Aug 15^th, 2006, 4:43am

Hey, Markavian. You keep mentioning that you're trying to email me, but I never get the messages. Are they getting bounced? I've occasionally had issues with my mail account, it may be time to speak to the hosting people.

Try emailing interfascia (at) thbbpt (dot) net. It's a new account, I just tested it.

I don't know how you feel about all the different projects to develop GUI libraries for processing. I personally think it's wasteful to duplicate all the code for each project. Perhaps discussing a roadmap of each of the projects makes sense.

Brendan

Brendan Berg
contact (at) superstable (dot) net

jayboyd

Re: ? Standard UI Class for Processing
Reply #26 - Dec 16^th, 2006, 7:52pm

So, um... attempting to revive this thread...

Three thinks I would like to see, and assume others would as well, are:

Containers
Menus
Layout managers

These would presumably be implemented in this order, actually.

I am also wondering, and this seems like the place to ask, wwhat the P5 developers are considering with GUI libraries and incorporating any of the fine work done by contributors. It seems that some GUI functionality, by allowing more complex state-aware apps and providing one of the most basic and ubiquitous aspects of software for the learning student, while being very non-trivial to develop individually, could both greatly extend the teaching uses of P5 while also making P5 much more complicated and spurring far more usage questions and problems.

I am also still not clear on the exact problems of using Swing, other than the inclusion historically (but not in P5 1.0) of Java 1.1. Even so, a simplified GUI API has some value.

Thanks for the excellent GUI libs contributed though. Very very handy to have : )

brendn

Re: ? Standard UI Class for Processing
Reply #27 - Dec 16^th, 2006, 9:39pm

I have plans with the Interfascia library to implement all three. I guess this is as good a place as any to start discussing a road map, which may end up being its own thread.

The GUIController object handles the drawing and event handling of all the components it contains. I can simply add some logic for handling enabling/disabling and showing/hiding the container. This also gives Tab-panes for free because each pane can be a container.

Menus shouldn't be too hard.

Layout managers are tricky. I prefer the idea of having a WSYWIG interface builder. It may be more intuitive, and it gives the programmer more control. I've never been happy with the automatically generated layouts using Swing layout managers.

Which brings me to Swing. The Java UI libraries are somewhat confusing and bloated. I realize this is a personal opinion, but the hierarchy tree for the Java API is extremely convoluted. A lightweight and simplified GUI library is probably what will serve Processing best in the long run.

And yes, I also wonder if Ben and Casey will be including a core GUI library. I know there are three or so of them out there, and I hate to see duplication of effort, but at the same time, each offers something that the others don't.

B

Brendan Berg
contact (at) superstable (dot) net

jayboyd

Re: ? Standard UI Class for Processing
Reply #28 - Dec 16^th, 2006, 11:58pm

Quote:

The GUIController object handles the drawing and event handling of all the components it contains. I can simply add some logic for handling enabling/disabling and showing/hiding the container. This also gives Tab-panes for free because each pane can be a container.

It may make sense to make a separate container class, independent of the control heirarchy. If nothing else, for proper encapsulation, but for future extension as well. And also, presumably you'd want to be able to have multiple containers independent of each other, or containers that are individually hidden or shown (again, like a menu).

Menus seem quite important as they offer UI elements that do not obscure the sketch. controlP5 allows hiding and showing, but in a very non-standard way for end users.

Yes, lightweight and simple APIs seem like the right approach. Ultimately, it seems that a solid GUI toolkit would contain:

menus (with submenus)
buttons
radio buttons
text fields (including multiline)
drop menus
sliders
knobs (processing totally needs knobs, for some reason)
containers

As for event handling, I am a big fan of Actions, a la Swing, where you instance your own object that has some action method, and can pass this same object to multiple GUI elements (as with a menu item and button serving same purpose). You end up with the very learning-friendly API something like myButton.setAction(myActionObject). I suppose a step further would be passing a single function, but function passing always gets into hinky syntax or reflection that may confuse students. There's something I don't like about setCommand("myFunctionName") from a code purist stance. Likewise I'm not so sure about wrapping too closely the Java ActionEvent stuff, since this either means the learning student is *supposed* to learn more Java, or worse, the API is mutated or simplified such that someone who actually does know Java GUI stuff finds things confusing and not working as they would expect.

I will continue to throw in thoughts here, rather than contribute any actual code : )

You have a valid point about layout managers, though they are less work to implement than external GUI layout tools. But then here's a chance to do it better than Sun! I think, truthfully, that learning to use layout managers, they become less work than absolute positioning of everything, although I suppose most sketches are absolute-sized...

jayboyd YaBB Newbies Offline Posts: 4	Re: ? Standard UI Class for Processing Reply #29 - Dec 16^th, 2006, 11:59pm oh and look and feel settings of some sort