I want to think about what a new GUI library for processing might need. One that could eventually become a candidate for a "core" GUI Library. So I want to keep Processing's design principles in mind. e.g. accessibility, ease of use, minimalism and extensibility.
I am thinking about the following goals:
Spark discussion for a core GUI library
Easy to use and setup: "easiest" of all the GUI libs for P5
Minimal: Basic set of UI elements. clean / simple design.
Extensible: Allow customized drawing of existing UI elements and adding completely new ones.
And here's a slew of features/ideas I have in mind:
Support the "sketching" metaphor of processing: quickly drop in some UI elements to control parameters.
Basic set of "most important" UI elements (what are they?): button/toggle for bangs and booleans, slider or numberbox for floats, ...
Sensible/usable defaults for UI element parameters (position, size, ranges). it should be possible to create UI elements using empty constructors.
Ability to change position, size and options "in-app" (using drag&drop and snap-to-grid). layout is automatically saved and restored.
Minimal graphics (also to reduce overhead added by UI): simple color scheme (2 or 3 colors + font)
Draw on top of everything, hotkeys to show and hide UI
(Auto)save/restore of parameters. presets.
Auto connect UI elements to parameters and functions via name, using reflection.
Support for separate window for the controls
Quick customization of: color scheme, font, default sizes, default layout
Clean API. allow arbitrary datatypes for the state of UI elements. Event handling system at the core, like GUIDO. extensibility as core feature.
Any thoughts on this? Am I missing something critical?
Let me pitch some ideas to you all, in hope for some feedback on what could be suitable for my GSoC application.
1. Workshop/teaching mode
Building on a suggestion by Karsten Schmidt at his recent workshop at http://resonate.io I would like to enforce processings role as a teaching tool:
* Ability to adjust font-size without restarting.
* Highlighting of recent edits to the code (suggestion by K.S.), highlighting of current line.
* Special layout of PDE with vertical split-screen: Code (+ Console) left, scaled Canvas right. Split position adjustable.
* Debugger. Classical stepping, breakpoints, variable inspector. Ability to see visual results mid-draw(). (to learn how each frame is built up).
I guess the Debugger is a sizable project in its own right and the rest is probably too small for a GSoC project..?
Do you think there are other important features for a PDE debugger apart from the “standard-ones” I mentioned above?
2. Community Service & Evaluation
I've been hanging around the forum lately, answering programming questions and giving hints. It's a pretty nice work and rewarding too. There are discussions from line-drawing to visually proving Fermat’s theorem. So I'm thinking to make a project out of it, trying to focus the knowledge generated on the forums.
* Tend the forums, answering questions, providing help and code.
* Keep track of the type of questions, building stats. Make sense of what is going on in the community, with the possibility to feed this back into development.
* Build a library of well documented code examples for the most common questions.
"While the library is near complete, there is still some work to be done, which includes building out support for as many capture devices as possible, as well as improving playback to allow for smoother scrubbing of a video."
can anybody give some more details on this? what more could be reasonably done on processing.video in the scope of a gsoc project, apart from openCV integration?