-
-
Notifications
You must be signed in to change notification settings - Fork 2.6k
This issue was moved to a discussion.
You can continue the conversation there. Go to discussion →
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
OpenFrameworks - room for improvement #6866
Comments
Hi @dimitre What I recall and think would be mostly useful was the idea of modularizing OF. Have a very basic core and all the rest is treated as addons, communications, networks, 3D, sound, video, graphics, etc. The way that OF is used right now will still be possible, but with this modularization one could easilly disable the modules that are not needed, which should compile faster and into smaller apps. What ideas do you have in mind? |
Hey @roymacdonald first of all thanks for all your activity in community helping others and keeping the forum alive. |
Fresh OFFirst of all, some people out there I've been talking have the perception OF project is stalled.
Edited some suggestions as already done as I've noticed recently |
Glad to help. I agree with what you point out. During the last OF conference in Denver, already more than 2 years ago, we discussed this a lot and we ended up having the idea of revamping the whole site, even with some working demos for it which looked really nice. I am kinda disappointed that all the work done there went into the dark and never came out. I understand that soon after it covid came and, well we all know what happened, yet after that there has been plenty of time to at least make public the documents we wrote then. There were also some other really cool and useful stuff like the package manager by @thomasgeissl , which already works and the idea was to integrate with OF and project generator. But in order to change this perception of OF being stalled, most probably, updating the website would have the biggest effect and maybe we should start from there. I am willing to make an effort and put time into such, but we need to be clever on how to use out limited person/hour resources which are not that much. I think that organizing a hackathon during some weekend can work and we can get it all done if we have a few committed people . |
Sure @roymacdonald it would be great to have a way of sharing ideas and results from the conference, so others could pick up or add or discuss more. |
Folders naming and locationit would be great to change some parts of structure for a major version like 0.12.0 and moving templates to root, not inside scripts. it is just strange that this folder sits there, together with lots of .sh folders. |
Just fyi @dimitre there is a 0.12.0 task-list issue here: It outlines what we are aiming for, for 0.12.0. Thanks for all the help so far! |
That's looking great @thomasgeissl ! |
@dimitre |
Yeah this change is really not needed @roymacdonald. About backwards compatibility I don't think it is needed in this case, each release has its own projectGenerator |
I agree with dimitre's opinion about moving templates to root. I think this is not absolutely needed, but I think it on the root directory is better. |
GIT AccessPeople commited to OF with availability should have access to GIT so innofensive PRs can be merged without overloading @ofTheo. It would be great to have @2bbb and @roymacdonald |
hey Roy, it is entirely coded in oF. Your territory to find and fix some bugs. I am with Roy regarding the templates, would be nice to move, but since it will cause a lot of problems, this should only happen with the next (real) major release - 1.0.0 in this case. |
@dimitre and all - thanks for this! ofSite:
Next Release:
Git Merging PRs:
Simplifying Contribution / Plaltforms:
Really appreciate all the energy and would love to help get more people involved in the process! |
Hey @ofTheo great! Git Releases are going to be very helpful! |
@dimitre totally agree! |
Coding styleAgain : just personal opinion. virtual void hideCursor() {}
virtual void showCursor() {}
virtual void setWindowPosition(int x, int y) {}
virtual void setWindowShape(int w, int h) {}
virtual glm::vec2 getWindowPosition() {return glm::vec2(); }
virtual glm::vec2 getWindowSize(){return glm::vec2(); }
virtual glm::vec2 getScreenSize(){return glm::vec2(); }
virtual void setOrientation(ofOrientation orientation){ }
virtual ofOrientation getOrientation(){ return OF_ORIENTATION_DEFAULT; }
virtual bool doesHWOrientation(){return false;} I think we can remove now the comment dividers before functions in examples, like this //-------------------------------------------------------------- And clean some unused functions (not all of them) from some examples where declaring all the functions are not pertinent. ex: //--------------------------------------------------------------
void ofApp::mouseEntered(int x, int y){
}
//--------------------------------------------------------------
void ofApp::mouseExited(int x, int y){
}
//--------------------------------------------------------------
void ofApp::windowResized(int w, int h){
}
//--------------------------------------------------------------
void ofApp::gotMessage(ofMessage msg){
}
//--------------------------------------------------------------
void ofApp::dragEvent(ofDragInfo dragInfo){
}
All of this 3 suggestions are related to read less, scroll less and less eye jumps |
Thank you all for getting on to this. @dimitre I do have git access, it is only that I agreed not to merge PRs. @ofTheo I completely agree that more than one dev should look at a PR before merging. I can take the time to look at these and merge if needed. But please let me know what would be the correct procedure for such. I still think that changing folder structure for a minor release is not a good idea, simply because a minor release should't break a previously working project.
I like having these! lol. It helps me to find out where each function ends/starts specially on larger projects. But sure, having all those empty functions looks unnecesary but I think that it is very handy, specially when you are a beginner to have then right there. I am not sure if I would remove these. As of the website, Thanks again for all the help and time you put into this! |
my personal opinions about details on macOS. (this is not genral, sorry if those don't fit the purpose of this room)
no-ARC env is too legacy and compiler doesn't care some wrong codes. I posted PR already. (but I think this need to test by more people.)
some users around me got trouble about project format be made not XML by editing templates/osx/emptyExample.xcproj.. |
thanks @2bbb this room should encompass everything, personal opinion, platforms. |
Done: Memory LayoutI've took some time to read OF code and appreciate all the work done! Beautiful. openFrameworks/libs/openFrameworks/app/ofMainLoop.cpp Lines 230 to 234 in c5ef119
I think we should change function parameter to const and & where appliable to avoid temporary increasing shared_ptr use_count, or using std::move inside the function if copying a shared pointer to another. (not in the example above which uses weak_ptr) There is some discussion on this already merged PR: Related PRs: |
Recently, many return values changed from I will try fixed those, but so many commits will be needed. |
I think, better way is overload with |
Thanks all! While PRs which fix small things like increasing the use count of shared_ptrs etc are good to address. Considering how much work there is to maintain OF and get releases out, PRs which move the needle on release milestones or close open issues for existing bugs are far more helpful. Usually if a PR isn't merged it is due to there being some hesitation of it possibly creating a new bug or breaking existing patterns. eg: #6882 Anyway, all this to say would love to direct some of this energy towards 0.12.0 and PRs which solve issues/bugs people are currently having ( and while also fixing warnings etc too 🙂 ) Thanks so much!! |
here are some project manager updates. it still needs some refactoring and testing.
this should clone and build it, but in the case of an m1 mac, it will fail with arch arm64, ofxGit2 is not updated and will fail to link.
any feedback is very welcome. It is probably best to move the discussion over to ofPackageManager's repo. edit: I updated the release link to the most recent version |
In addition, we need to add |
This issue is from my hope to save beginners get trouble about communication with arduino and other library... |
Done: Folder other/serialTestI've noticed the .ino file with the same logic is there three times, two as .ino and one as .cpp First PR : removing binaries TODO: remove redundant .ino / .cpp |
I just wanted to chime in about the templates folder -- one thing I am worried about, if its moved to the root level, is that people may click on and interact with a template, which would sort of hose their entire OF folder since those are not meant to be opened. I agree that having it in "scripts" seems sort of messy. Perhaps there's a more organized approach, such as:
(or instead of utilities, internal?) with a clear readme about what utilities are. another option is to have templates in the PG folder, but that folder is sort of messy on different platforms (on windows, it's full of DLLs, etc) |
rename
|
In association with: Arguments of |
Great. for me the most unusual function which is different from the others is ofStringReplace, because it doesn't return a value, but sets a variable passed as a parameter |
@roymacdonald I like the idea of a hackathon or setting a day to be more available and try to advance things using slack. |
Hi @dimitre and everyone else. I've been a bit unavailable lately as I have been traveling and I wont stop until early May. Then I will be available and it would be great to have a hackathon, but before that it is most likely that I will not be. |
Experimentalshould OF have an experimental branch? |
@dimitre |
@roymacdonald by having more people there able to commit, changes can be voted and tested there. |
Done: XCConfig optional include at the endedit: now an issue here: it would be great to have something like so if somebody want to have configuations that survive ProjectGenerator rebuild they can be there useful for overwriting pbxproj or xcconfig configurations, or setting custom data for the app like
|
Done : Reducing .h includes in .h files.There are some cases includes are there but they are unneeded (I've made some PRs targeting that but I'm sure there are more out there) and others can be changed to forward declaration like this : |
Re improvements to |
@smeyfroi Yeah would love to feature more OF work on the main site. Another option could be behance which has a fair amount of OF content: https://www.behance.net/search/projects?tracking_source=typeahead_search_direct&search=openframeworks&sort=published_date Edit: added an issue here for those that have thoughts |
What's the best way for me to start helping this project? @ofTheo @ofZach I'm time poor in general, quite new to oF, but willing to help with tasks that are easily within my grasp. So... I'm mediocre in C++, picking it up again specifically to use oF after last using it commercially in the days of C++98! I'm studying for an art degree in my spare time, with a day job in software (currently ruby, bash, some js, previously python, java), though I mostly spend my work hours managing a decent sized AWS estate. One reason I'm nervous about the oF codebase is because of its highly cross-platform nature. I wonder whether the implications of that re development could be documented more clearly, because for me that's quite a barrier: last time I touched Windows was probably decades ago, and my knowledge of low-level graphics ops is minimal at best, never mind thinking about the differences between a Pi and a MacBook. I imagine CI automation might be the answer there, if that's a reliable enough setup. I find the issues list overwhelming, though clearly it's not stopping @dimitre! 👍 I wonder whether I might be best starting to help triage the issues (tagging/re-tagging to bucket them up), or if there's anything I can do around the hosting and so on? A successful repo that I sort of follow is the neovim project. They have a lot of active participants on what must be a very difficult legacy codebase. Yet they've managed to refactor, excise legacy, and add complex new functionality. Is their model for managing the dev process something to look at? (They tag and triage issues quite nicely, for example.) Anyway, I'm making no grand promises, but it'd be handy to have a way into helping with whatever limited resource I can give. Feel free to DM: email on my GH profile. 😀 |
Thanks @smeyfroi ! Things that can be helpful to the project:
|
Great. |
Great. PR incoming for |
Libs version / URL in a log fileit would be great to have a txt file in the libs folder contaning info for each lib:
|
Github Discussionsit would be great to have the feature discussions enabled in Github, so some issues can be moved there |
@dimitre yes - if you want to kick it off happy to add that. 👍 I think we want to make sure though to use it in a way that makes sense, so we aren't duplicating conversations in issues / or the forum. |
@ofTheo great! As I've seem some issues being moved to discussions we can do it without duplicating anything. |
@ofTheo just as a follow up I don't have access to repository settings here. |
This issue was moved to a discussion.
You can continue the conversation there. Go to discussion →
First of all thank you for the incredible project and collective effort put in OF.
I've been using for more than 10 years, and I've decided to read carefully the code to see if some things could be improved there.
And IMHO there are. so I'm opening this issue here and inviting you to discuss ideas or post new ones.
The text was updated successfully, but these errors were encountered: