following on from this-thread I have started working on a GUI addon for OFW.
Features I want to include:
With the interface colour and style being loaded from XML. Thats the plan anyway.
Anyone think of anything else they would like to see?
What is the recommended naming conventions for addons from ofw 0.05 onwards, I was thinking ofControlGui for this one.
Hi Chris,
Looks like a solid list to me.
Definitely like the innitiative!
One question/remark though:
Most of the features you mention are quite straightforward as to how they would function. But I guess a ‘timeline’ can mean lots of different things, as they come in all kinds of shapes and loaded with different functionalities.
Some ‘inspirational’ timeline tools:
(that might already come in handy as they both send out their values over OSC!)
Iannix - ‘an OSC poly-temporal meta-sequencer’ (from La Kitchen)
http://iannix.la-kitchen.fr/
TimelinerSA - ‘a multipurpose Timeline’ (from the VVVV camp)
http://vvvv.org/tiki-index.php?page=TimelinerSA&highlight=timeliner
Cheers,
-Tim
I started drafting out the structure of how to create a generic gui class & objects and realised this will quickly get complex. I’d been discussing with Andreas some of the features & structure issues, and we thought it best to start this on the forum & get everyone involved in the decisions from the beginning.
Here was all I started, it really is nothing, but gives an idea:
http://www.chrisoshea.org/storage/gui.zip
It would be great to hear your thoughts on the following…
– class structure -------------------------------------------
My first thought of structure for the classes
It was pointed out that for others to add new object types, they would have to modify the manager class quite a bit. Instead I should use a uiObject type and then button/slider/checkbox inherits this uiObject.
Because the number of ui objects are unknown, I am using std::vector to hold each object.
Any thoughts on the class structure?
– input events --------------------------------------------------------
We can’t inherit the mouse events from testApp, correct? So within each testApp mouseDown etc you would have to put:
guiClass.mouseDown(x,y);
– gui events --------------------------------------------------------
When a user clicks a button, what should the action be? Should a generic function in testApp be called, then use switch statements to do something with that action. What about creating event listeners like in flash for each object & definining our own function?
– colours / style sheets ---------------------------------------------
Should each individual button & slider be colour changable, or one general stylesheet gui?
What other properties do I need?
foreGround color
background color
border color
mouse over color
mouse pressed color
– typeface --------------------------------------------------------
Should we have a ofTrueTypeFont within the gui manager and then a seperate function to load a font, or pass a ofTrueTypeFont from the testApp by reference?
I have gone for the second option in ofControlGui with this:
void init(ofTrueTypeFont & _type);
However perhaps the first is better
– tabs / panels ---------------------------------------------------
Gui objects should be able to be grouped, then hidden/shown as needed to create multi layout interfaces.
In controlP5 for processing these are Tabs I believe. Andreas mentioned in his code he has Panels.
I can imagine for each object you could set the panel it belongs to:
guiClass.createPanel(“panel1”, “Layers”); // id, label, size & position etc
button.setPanel(“panel1”)
Any thoughts on these?
– xml ---------------------------------------------------
In theory when the new ofXml is out with 0.05, you could build the whole user interface from an xml file, with that file storing a list of all objects, positions & events.
For now I will use xml for a style sheet, with loadStyleFromXml(“red.xml”) and saveStyleToXml() functions.
Any of your thoughts on the above most welcome,
Thanks
I’ve uploaded what I’m currently using here:
http://www.nanikawa.com/temp/ParameterUI.zip
It looks like this:
http://flickr.com/photos/hahakid/2262339861/
I’ve been meaning to convert it to OF and post it, but unfortunately I suffer from chronic lack of time.
Also, the latest version of the code is not incorporated in my clean “starter template”, but in a client project, so the .zip only contains the UI code and will not compile as is, I’m just posting as a reference as me and Chris were discussing pros and cons of how to approach it yesterday.
I think the way I went about it got a bit messy, so hopefully we’ll be able to come up with a better way together, I’m very keen on doing some programming on this as this is a big deficiency in my projects at the moment.
So, onto roughly how it works.
The last thing I do before defining main() is this:
AParameterUI* parameterUI;
#include "uiDefinition.h"
#include "ParticleUiDefinition.h"
int main( int argc, char** argv )
That way, for instance “ParticleUIDefinition.h” can define functions that reference objects we have defined earlier, an example would be this callback for a float3 sider
void changedSwayingAxis( float _newVal, int arg1, int arg2, int arg3 )
{
if( arg3 == 0 ) { interactiveWowScene.particleSystem->swayingAxis.x = _newVal; }
else if ( arg3 == 1 ) { interactiveWowScene.particleSystem->swayingAxis.y = _newVal; }
else if ( arg3 == 2 ) { interactiveWowScene.particleSystem->swayingAxis.z = _newVal; }
}
Referencing interactiveWowScene which was defined earlier in the main.cpp file.
This is the part that I find the messiest and if you look at ParticleUIDefinition.h you’ll see how much code it takes to make the interface you see in the screenshot I linked to earlier.
Everything inherits from a base object AParameterUIObjectBase and panels have a:
vector< AParameterUIObjectBase* > uiObjects;
Adding for instance a checkbox is done like this (from ParticleUIDefinition.h)
AParameterUIObjectCheckbox* tmpSwayingCheckBox = tmpMovementPanel->addCheckbox( "Do Swaying", interactiveWowScene.particleSystem->doSwaying );
tmpSwayingCheckBox->changedParameterCallback = &doMovementToggleFunction;
tmpSwayingCheckBox->funcPointerSet = true;
tmpSwayingCheckBox->p_boolVal = &interactiveWowScene.particleSystem->doSwaying;
The first line gets a reference to to the checkbox (and internally the Panel adds it to it’s uiObjects list), giving it the start value. ( this is redundant since I implemented pointers to the values themselves.)
The second line sets a function pointer to call with the new value when clicked.
The third line could be eliminated by checking (changedParameterCallback != NULL)
The fourth line gives the checkbox object a pointer to the bool it is supposed to be checking, this is so that it will update it’s internal case in case something else changes the bool’s value.
This probably doesn’t make a lot of sense as is, but I just wanted to throw something into the discussion, I think it’s an extremely important component for people like us to have.
/A
Nice - hahakid.
I saw that image from another thread and I was going to post it here. Pretty slick UI!
Also I just stumbled on this today - it is a short text on user interface design from this guy who built a massive multiplayer game from scratch on his own. The rest of his work is pretty incredible but there is some nice stuff he talks about in this text:
Might be good for ideas - http://www.quelsolaar.com/technology/seduce.html
Anyway I will chime in on this topic
A base ui object is definitely the way to go.
Personally I would keep functionality quite minimal but give it as much information as possible about things like mouse click location, drag time, drag direction etc etc
You could have some basic functions (boundingBox hit etc) that could be easily overridden for more complex behaviors by people extending the base object.
If the base object is structured simply it will allow for a nice range of gui tools.
I learned this the hard way with Laser Tag - it took me a couple of tries to build a base brush class that would be useful but would not limit the brushes that were extending it.
Any thoughts on the class structure?
I Would have to think about it more but something like:
[guiengine /manager]
[gui settings]
[gui appearance]
[gui communication]
-event callbacks
[gui objects]
Now that I look of it I am not sure if that is a overall class structure or a wishlist - but I would imagine something like that. I think an important decision would be whether the manager owns the gui objects or whether we create them and then register them with the gui manager class.
– input events --------------------------------------------------------
We can’t inherit the mouse events from testApp, correct? So within each testApp mouseDown etc you would have to put:
guiClass.mouseDown(x,y);
This is one of my biggest frustrations - obviously it would be great to register mouse and keyboard events with the of core - so that you don’t have to fill the testApp mousePressed, mouseReleased, key pressed etc with all the relevent gui events.
If you do go this way (I am not sure how you would avoid it at the moment) one thing I like to do with keyPressed is first send the keypress to my gui and then return true or false if the key is mapped to something - that way you can avoid duplicate key press events
testApp:keyPressed(int key){
if( !gui.keyPressed(key) ){
//gui is not using this key -
// put you misc testApp key events here
}
}
– gui events --------------------------------------------------------
When a user clicks a button, what should the action be? Should a generic function in testApp be called, then use switch statements to do something with that action. What about creating event listeners like in flash for each object & definining our own function?
I think callbacks are the way to go - my gui class for laser tag didn’t have callbacks and it was pretty miserable - I had to ask my gui for every setting whether it had changed its value - then if it had I would request its new value. Uggg. But callbacks can be tricky and could make the code quite complicated - I would cede this to someone who knows more on this subject.
– colours / style sheets ---------------------------------------------
Should each individual button & slider be colour changable, or one general stylesheet gui?
What other properties do I need?
Thats a tough one.
The objects could have abstract properties like strong, normal, highlight, etc that define their importance, mode etc and then the stylesheet could just interpret these with a color - font weight etc.
I would go maybe go with general stylesheets that defines the whole gui and then people can tweak the stylesheet if they want to change the appearance.
For color I would do rgba rather than rgb - as it might be quite useful down the road.
– typeface --------------------------------------------------------
Should we have a ofTrueTypeFont within the gui manager and then a seperate function to load a font, or pass a ofTrueTypeFont from the testApp by reference?
I have gone for the second option in ofControlGui with this:
void init(ofTrueTypeFont & _type);
However perhaps the first is better
I am not sure - I might imagine you would need to have more than one typeface, especially as OF loads the typeface in at the requested size - so you would need two ofTrueTypeFont objects to have two different sizes of the same typeface.
One thing I have found is that type in gui’s can really slow things down especially on laptops with limited graphics hardware. This can be as much as 10-15 fps when drawing a lot of type to the screen. It is so much that in Laser Tag all non dynamic type is actually ofImages and the gui’s for some of my other installations have an option to just show the text of the selected control.
– tabs / panels ---------------------------------------------------
Gui objects should be able to be grouped, then hidden/shown as needed to create multi layout interfaces.
In controlP5 for processing these are Tabs I believe. Andreas mentioned in his code he has Panels.
I can imagine for each object you could set the panel it belongs to:
guiClass.createPanel(“panel1”, “Layers”); // id, label, size & position etc
button.setPanel(“panel1”)
Any thoughts on these?
I imagine that could work fine with specifying relative coords to the panel rather than absolute screen coords for each gui. I think that could be a really nice feature and of course collapsable, grouped, all that stuff would be really useful. You could reposition the panels and then their position could be saved to xml so they remember how you had them.
– xml ---------------------------------------------------
In theory when the new ofXml is out with 0.05, you could build the whole user interface from an xml file, with that file storing a list of all objects, positions & events.
For now I will use xml for a style sheet, with loadStyleFromXml(“red.xml”) and saveStyleToXml() functions.
Sounds good!
Anyway I don’t think I am an expert on this subject at all - so maybe someone else has better advice.
Theo
Any of your thoughts on the above most welcome,
Thanks
great thread! thought I’d jump in on this:
This is one of my biggest frustrations - obviously it would be great to register mouse and keyboard events with the of core - so that you don’t have to fill the testApp mousePressed, mouseReleased, key pressed etc with all the relevent gui events.
this is a frustration for me too — we don’t want to make the code too complicated, but in my ideal world there’d be some sort of solution for this.
for example, a way to create objects that extend a base class ofEventReceiver and register themselves with OF, so that OF calls them one by one to give them mouseEvents, etc.
ie
class blah : public ofEventReceiver {
blah() { ofRegisterEventReceive(this);
}
};
at the OF level, you could have a std::vector of (ofEventReceiver *) that grows with all calls to ofRegisterEventReceive.
then when events happen at the OF level, they get passed to everyone one by one (this is where return false or true might come in handy for objects “owing” the event).
anyway it’s just a thought, and it could come in handy for example, if this isn’t at the OF level, to have some sort of system like this in the gui management level…
take care!
zach
got to this site completely randomly, but noticed a few gui samples - could be helpful to take a look at :
http://www.robthebloke.org/opengl-programming.html
ps : his pointers tutorialhas a pretty awesome code example for anialiating your computer and a corresponding hand drawn image of what that looks like.
haha, that tutorial is awesome, very informative too!
/A
Just a query - doesn’t the random memory map trace look a little similar to the sort of output your drawing software makes Zach?? That caricatured squiggle of a human looks strangely familiar.
Ghost in the Machine!? Eller hur?
So, I figured I’d had a few too many to work on client work tonight anyway and started the process of converting the rudimentary UI I had to OF.
I’m a bit stuck with regards to actually setting variables in the “testApp” (or “OFSAptr”?). This might have a lot to do with how I went about it in the past, I’d have a .h file that defined some functions that accessed objects that were available from main.cpp, but in OF the basic app is an instance of a class, so it’s a bit different.
Anyway I’m uploading what I’ve got so far here:
http://www.nanikawa.com/temp/ParameterUIOfConversion.zip
in case anyone is interested. Only in XCode project format I’m afraid, but it should just be a matter of adding overwriting the files in a copy of “advancedGraphicsExample” and adding the extra files to the project.
Hit “p” on your keyboard to bring up the UI.
What I was stuck on was setting the “spin” variable in the testApp. A few more hours with OF and I’m sure the way to go about it will reveal itself.
I’m sure this will make a lot more sense to me tomorrow 
Oh, this was very much a quick and dirty conversion in an hour, so it’s still using whatever dependencies it had in my own libraries, which I’ve copied over, but the idea is to move this over to OF so there is something available until a better solution comes along.
/A
Hi Andreas
(i’m in the workshop now)
You can’t access variables directly in testApp, you have to pass the parent into your class.
You would need something like this:
in AParameterUI.h
class testApp;
class AParameterUI
public:
void setParent(testApp * _parent);
private:
testApp * parent;
}
and in AParameterUI.cpp
#include "testApp.h"
void AParameterUI::setParent(testApp * _parent){
parent = parent;
}
then you can do parent->spin =
make sure on .h you have ‘class testapp’ at the top and in the .cpp have the include, as otherwise you get a recursively included file.
Do you mind if I take some elements from your Ui and integrate them into this Ui addon, to keep them using ofw specific drawing & type?
I’ve just tried building your example. It won’t work at the moment as AParameterUIObjectBase.h includes glut.h
1>AParameterUIPanel.cpp
1>c:\openframeworks\v0.04\app\work\andreasui\src\parameterui\AParameterUIObjectBase.h(26) : fatal error C1083: Cannot open include file: ‘GL/glut.h’: No such file or directory
Hi Chris, that’s an easy one since OF uses GLUT already, I just replaced my code for including OpenGL and GLUT with the line:
#include "ofConstants.h"
I’ve uploaded the src folder here: http://www.nanikawa.com/temp/ParameterUIConversion-src.zip
You are more than welcome to make it “more OF”, the only thing I wouldn’t want is for us to double our efforts, so if I find time to work on this in the short term I won’t touch the drawing code.
The best way to go about setting the vars is something I’d love to get some more brains on as it should be as un-intrusive to the rest of the app as possible.
Also as I mentioned sometimes you need to call functions, so you can do stuff like:
glClearColor( _newVal, _newVal, _newVal, 1.0f );
There is code in there as well to get a pointer to a value so the UI can update if the var is changed from somewhere else.
/A
Hi Andreas
When trying to build the new files I get lots of link problems:
1>AParameterUI.cpp
1>C:\Program Files\Microsoft Platform SDK for Windows Server 2003 R2\Include\winsock2.h(112) : error C2011: ‘fd_set’ : ‘struct’ type redefinition
1> C:\Program Files\Microsoft Platform SDK for Windows Server 2003 R2\Include\winsock.h(54) : see declaration of ‘fd_set’
1>C:\Program Files\Microsoft Platform SDK for Windows Server 2003 R2\Include\winsock2.h(147) : warning C4005: ‘FD_SET’ : macro redefinition
1> C:\Program Files\Microsoft Platform SDK for Windows Server 2003 R2\Include\winsock.h(88) : see previous definition of ‘FD_SET’
1>C:\Program Files\Microsoft Platform SDK for Windows Server 2003 R2\Include\winsock2.h(156) : error C2011: ‘timeval’ : ‘struct’ type redefinition
1> C:\Program Files\Microsoft Platform SDK for Windows Server 2003 R2\Include\winsock.h(97) : see declaration of ‘timeval’
1>C:\Program Files\Microsoft Platform SDK for Windows Server 2003 R2\Include\winsock2.h(212) : error C2011: ‘hostent’ : ‘struct’ type redefinition
1> C:\Program Files\Microsoft Platform SDK for Windows Server 2003 R2\Include\winsock.h(153) : see declaration of ‘hostent’
1>C:\Program Files\Microsoft Platform SDK for Windows Server 2003 R2\Include\winsock2.h(225) : error C2011: ‘netent’ : ‘struct’ type redefinition
1> C:\Program Files\Microsoft Platform SDK for Windows Server 2003 R2\Include\winsock.h(166) : see declaration of ‘netent’
1>C:\Program Files\Microsoft Platform SDK for Windows Server 2003 R2\Include\winsock2.h(232) : error C2011: ‘servent’ : ‘struct’ type redefinition
1> C:\Program Files\Microsoft Platform SDK for Windows Server 2003 R2\Include\winsock.h(173) : see declaration of ‘servent’
1>C:\Program Files\Microsoft Platform SDK for Windows Server 2003 R2\Include\winsock2.h(244) : error C2011: ‘protoent’ : ‘struct’ type redefinition
1> C:\Program Files\Microsoft Platform SDK for Windows Server 2003 R2\Include\winsock.h(185) : see declaration of ‘protoent’
Hmm, I’ve only tried it on the mac, I can give it a go on the PC tomorrow.
It might have something to do with me including:
#include <windows.h> // included in all Windows apps
#include <winuser.h> // Windows constants
in AParameterUI.cpp and some other files in the Utils folder.
1>C:\Program Files\Microsoft Platform SDK for Windows Server 2003 R2\Include\winsock2.h(112) : error C2011: ‘fd_set’ : ‘struct’ type redefinition
this usually relates to windows conflicting with a network library that uses winsock2.h (like ofNetwork or ofOsc, etc). windows.h include winsock.h, which conflicts… the trick is either to use the “WINDOWS_MEAN_AND_LEAN” which we do in 0.05 or to control the include order. you could try swapping out the windows.h and winuser.h with ofConstants.h and see if that helps, or just commenting them out all together.
theo was demoing the gui stuff today for me, it looks super nice ! thanks for throwing it up -
take care,
zach
Hi
I’ve found this library for openGL gui construction:
http://www.clutter-project.org
It’s really a foundation over which you can create your own GUI library so there is no predefined look. I haven’t tried it but it seems very complete.
There are some explanations in the form of presentation here:
http://www.clutter-project.org/presenta-…-utter-foo/
with examples:
http://www.clutter-project.org/presenta-…-ample-code
They also have a reference implementation called tidy:
http://www.clutter-project.org/blog/?p=41
Huh - looks pretty powerful! Like the combination with webkit!
At the moment I am experimenting with HaHaKid’s gui code - its pretty minimal at the moment but the lack of dependancies mean its very quick to get up and running with openFrameworks. I also like it because it is not trying to be a OS style gui (With menus etc) its more like a control panel gui - like ControlP5 for processing: http://www.sojamo.de/libraries/controlP-…-index.html
Theo
This is a really an awesome project thanks alot!
An OF “addon” or “module” called **ofxParameterUI ** that works with pre release v0.05. There is source available for Xcode and VS2005. It’s really nice having tweening and sliders in OF. Next to create knobs and some menus objects such as radial menus and keyboards.
Anyway… here is a screenshot and source:
**Source **: http://ofx.nuigroup.com/ofxParameterUI-v0.05-addon.zip (977kb)
Interesting thread, lots of good stuff in it.
I’ve also felt a need for a simple gui and started to work on my own. But before I go into that I’d just like to bring up an old topic and some thoughts that come up when reading this thread and writing the gui.
I’ve been pushing for it before, but reading threads like this and the manyMouse thread etc it’s becoming more and more apparent that OF would gain massively by settling on an event system (I advocate poco :). If not OF could end up with dozens of different callback and event approaches in addons, which potentially would be painful…
Wehn it comes to colors, I’m using a Color class that I think is quite handy instead of passing rgba floats around and I’m thinking that something similar could be nice for of.
I’ve also been thinking that push and pop drawing operations would be nice. I don’t now what the overhead would be for this but it would make it easier to isolate drawing more within classes, such as gui elements. Right now if you set a color you don’t know if it will affect something that’s drawn later on…
ofPushColor();
ofPopColor();
ofPushCircleResolution();
ofPopCircleResolution();
etc would take care of that…
and btw, what’s a networked gui object? sounds interesting…
Ok, back to the gui stuff I’m working on. I’m only interested in something for debugging and behind the scenes stuff, and don’t really want to spend time on it, so I’m trying to keep what I’m working on functional but without slick effects or graphics. Very much like controlP5 which I too dig… I have it pretty much planned out and _just_ need to fix some input field logic, put in some poco events and adjust the gui so it has nice contrast on top of any background and it will cover the gui stuff I usually need (though chris post got me thinking about a timeline). I think it might be nice to have something that can be used both for gui stuff and for other interactive elements though, just like DisplayObjects in Flash, which is another reason why I’m trying to stay a way from heavy gui-only things like xml styles, though that could be nice.
It’s going to be cleaned up and reworked a bit, but now that I found this thread I’ve committed some code to cppglue.googlecode.com, if you want to have a look at it (gui is in GUI and the base classes are in Graphics). Thoughts and suggestions are welcomed, I’d like to get the API as solid as possible before spending time on specific gui elements or optimizations…
It’s set up similar to DisplayObject and DisplayContainer in Flash but I call my base classes Widget and WidgetContainer (for uknown reasons, might change that). The idea is that you use a WidgetContainer to manage several widgets (or containers) at once, group them, translate them, making them behave like radio buttons etc. If you need a custom widget you just extend the base widget class and do your stuff within setup(), update(), draw(). A widget is very similar in structure to testApp except that they have access to some more gui logic and events and can be organized in containers. Just like with DisplayObjects in flash they could be used to render pretty much anything.
Right now the WidgetContainer stands in for a display list, it works but I’m thinking about complimenting it with a real display list so that all widgets would have globally unique id’s. In the more far away future I can imagine adding some more 3d support (z-indexes etc) and support for multiple inputs (like manyMouse)…
Anyway, the poco events aren’t there yet (but they should be quick to add in the base class), and I’ve been dreading the boring input field. But once that is done I’ll make an example and show how you could listen to events such as a widget being clicked on or the mouse entering over it etc…
For now let’s just say that it looks and works like controlP5 and here’s an example of how you could throw some stuff out on the screen:
void testApp::setup(){
// rootContainer is a WidgetContainer instance
Widget* w = rootContainer.addChild(0, new WidgetContainer(200,200)); //the new WidgetContainer is returned as a Widget pointer
((WidgetContainer*)w)->setRadioContainer(true); // casting to the correct widget (int this case a WidgetContainer) and setting a parameter on it
((WidgetContainer*)w)->addChild(1, new RectToggle(0,0,10,10, true)); // adding a widget to the WidgetContainer
((WidgetContainer*)w)->addChild(2, new RectToggle(0,20,10,10));
// adding some more widgets to the rootContainer…
w = rootContainer.addChild(1, new RectButton(100,100,30,30));
w->setDraggable(true); //no need to cast here since setDraggable is a Widget method
w=rootContainer.addChild(2, new TextLabel(350,50, “HELLO”));
w->setDraggable(true);
w=rootContainer.addChild(6, new InputField(350,90, 100, 18, “HELLO”));
w=rootContainer.addChild(3, new RectSlider(200,300,300,10));
w=rootContainer.addChild(4, new RectSlider(50,300,10,100, true));
w=rootContainer.addChild(5, new CircleKnob(400,400,50));
((CircleKnob*)w)->setValue(10);
rootContainer.setup();
}
//--------------------------------------------------------------
void testApp::update(){
rootContainer.update();
}
//--------------------------------------------------------------
void testApp::draw(){
rootContainer.draw();
rootContainer.drawInfo(); // shows all widgets positions etc
}
//--------------------------------------------------------------
void testApp::keyPressed(int key){
rootContainer.keyPressed(key);
}
//--------------------------------------------------------------
void testApp::keyReleased(int key){
rootContainer.keyReleased(key);
}
//--------------------------------------------------------------
void testApp::mouseMoved(int x, int y ){
rootContainer.mouseMoved(x, y);
}
//--------------------------------------------------------------
void testApp::mouseDragged(int x, int y, int button){
rootContainer.mouseDragged(x, y, button);
}
//--------------------------------------------------------------
void testApp::mousePressed(int x, int y, int button){
rootContainer.mousePressed(x, y, button);
}
//--------------------------------------------------------------
void testApp::mouseReleased(){
rootContainer.mouseReleased();
}
puh, that was a long post…