Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow adding existing folders #40

Merged
merged 1 commit into from
Feb 10, 2016

Conversation

mattfelsen
Copy link
Contributor

Small change here, but maybe a useful one? I have different classes that create a folder containing their parameters, and implement a ofxDatGuiFolder* getGuiFolder(). From ofApp, which manages the gui, I call this and build a panel which has controls for all my different classes under collapsible folders. This is sort of a stop-gap fix until multiple panels snapping together exists (which is probably a more legit approach), but does the job for me and might be useful to others. 👍 ?

@braitsch
Copy link
Owner

braitsch commented Feb 8, 2016

Hi, I would caution against passing raw pointers around now that shared_ptrs & unique_ptrs exist in cpp11. Eventually all gui->add methods will generate a unique_ptr for every component they construct or possibly a shared_ptr if there is a common enough use case for components to be shared across guis.

Also just curious, how is this a stop-gap fix for multiple panels snapping together?

@mattfelsen
Copy link
Contributor Author

Agreed about smart pointers. I just went with a raw pointer since they're used throughout the addon and I just went with the flow. Not sure how unique_ptr would work here...if I did gui->addSlider() and stored the result so I could later call slider->getValue() on it, then I would need a copy and the ofxDatGui* instance would need a copy, so all the components would have to be shared_ptrs I would think?

Regarding the snapping...I have a class with a number of parameters that I want to control via a gui. I'd like to be able to have each instance make a panel, and have all the panels snap together so they're easily moved as a unit. What I'm doing instead is putting all the params into a folder accessible via a getter, and adding that folder to a single main panel which I can then move as a single unit, and can expand/collapse the various folders for the various instances. Hopefully that makes sense...if not I can take a screenshot when I'm back at the office tomorrow.

@braitsch
Copy link
Owner

Yep, they'd likely need to be shared_ptrs as per the points you mention but let's table a refactor for now until other features in the roadmap are addressed.

Snapping panels together & moving them as a single unit has come up on the forums and it's something I eventually plan to address for both vertical and horizontal layouts. I just need to think a bit more about how I want to implement this as it quickly gets complicated when you take into account dynamic component resizing, folders expanding and the application of themes.

braitsch added a commit that referenced this pull request Feb 10, 2016
@braitsch braitsch merged commit cbaed64 into braitsch:master Feb 10, 2016
@mattfelsen mattfelsen deleted the feature-add-existing-folder branch April 5, 2016 01:53
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants