We closed this forum 18 June 2010. It has served us well since 2005 as the ALPHA forum did before it from 2002 to 2005. New discussions are ongoing at the new URL http://forum.processing.org. You'll need to sign up and get a new user account. We're sorry about that inconvenience, but we think it's better in the long run. The content on this forum will remain online.
IndexProcessing DevelopmentLibraries,  Tool Development › Standard UI Class for Processing
Pages: 1 2 3 
? Standard UI Class for Processing (Read 9205 times)
Re: ? Standard UI Class for Processing
Reply #30 - Dec 17th, 2006, 12:07am
 
Interfascia already has preliminary look and feel classes, and I'm working on ways to override the built-in draw() methods in each component to allow custom drawing of controls.

B
Re: ? Standard UI Class for Processing
Reply #31 - Dec 19th, 2006, 8:23pm
 
brendn wrote on Dec 16th, 2006, 9:39pm:
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.

there are no plans to include any sort of ui library. my perspective:

+ scope creep makes it nearly impossible: at what point do you cut off the features to be included radio buttons are in, sure, but what about the little "spinner" thing big tabs, little tabs yech.. the "suggestions" board is already full of random things that people want added to the api in general, a minimal ui library would be red meat for the suggestion wolves!

+ ui management is enormously complex: how do you deal with things like using tab to move focus around all the objects how do you deal with accessibility or (gulp) internationalization..

+ i don't want there to be a processing "look" any more than some feel that there already is, and would prefer people to think about their components and how they relate to their project.

+ implementing some sort of "skinning" capability might partially address the "look" issue, but only with a significant increase in complexity.

so to anyone who is motivated to work on it, i think it would be great if we have some ui libraries. obviously this thread is long and people want something, but it's not something i personally want to get into any time soon.

personally, i'd just like to have a simple button class and an editable text field that could be embedded without too much trouble. the processing book has a couple simple ui classes (button and scrollbar), and i'm working on another book in which i might add a textfield thing, but i don't think we'll make it part of the core (or its own library). button may be the only exception to this.

as i have said many other places on this board and in the reference, you can also embed your processing applet (which is itself a component) into any other swing or awt interface, should you want "traditional" components. i too think swing is dreadful, but it's what some people want to use, and for most java applications, it's the only real option. (ok swt or whatever else is maybe fine too.. i'm not here to start a ui war and am not interested in taking any sides)

(edit - fixed the 'skinning' paragraph to make clearer that english is indeed my native language)
Re: ? Standard UI Class for Processing
Reply #32 - Dec 20th, 2006, 1:50am
 
all good points. thanks for the response.

brendan -- i sent you a bunch of bug/annoyance reports for interfascia, but no reply, not sure the board message thing is working? don't have any other contact info for you...

Re: ? Standard UI Class for Processing
Reply #33 - Dec 24th, 2006, 7:52pm
 
Since Interfascia is something of a subject in this thread, I thought I'd mention:

The Look and Feel class in Interfascia calls smooth(). This means that it can't be used with P3D, which seems to me a big deal.
Pages: 1 2 3