Extra, Extra!
This is a followup of the comment in https://community.osarch.org/discussion/2909/ifc-aggregates-vs-parent-child#latest
@sjb007 said:
@falken10vdl Well this is how it used to be, and they (the main devs) intentionally moved away from this. I didn't think it would be accepted because of this. I just ran into consistency issues with the newer method - mainly it just doesn't work properly with the Status filter feature in the Scheduling tab. All I'm doing is restoring an older piece of code that worked better, at least in my usecase.
I propose this PR https://github.com/IfcOpenShell/IfcOpenShell/pull/7308 as a example to add a subpanel of Extras in the addon settings. The idea behind to enable features for special cases, users, etc.
I have taken the example of commit by @sjb007 https://github.com/IfcOpenShell/IfcOpenShell/commit/fb77fca333a003390515bf1b220d794e5b705968.
@sjb007 I have copied your code with pride :) and add it as an Extra that can be enabled.
Example:
In general It is fearly simple to add more features under Extra. In the case the code of the Extra replaces code in the current code base it is simple to add a condition to either execute the original code or the new one based on the property of the settings section.
Cheers!
Comments
I generally like this, but it would cool, if there was some way to get metrics on how much a certain 'extra feature' was used, and if used frequently, to have that feature just pushed to the main branch.
Just trying to figure out a way to prevent increased maintenance of divergent scopes.
But not sure what this would look like.
Could this extra's UI include turning on/off certain PR's?
Is there a metric on Github that can track how often a PR gets pulled?
Brainstorming session.... How about anonymously logging how many times a PR was pulled on the blockchain?
https://chatgpt.com/share/6904d925-921c-8013-9c6a-566d01b7ca7c
I feel there could be some crossover with this, as well
https://community.osarch.org/discussion/3166/bonsaipr-your-weekly-build-with-prs-merged-as-much-as-possible#latest
My humble opinion :)
With bonsaiPR we get feedback from real users to get the PRs working properly and polished.
The PRs can be of type "regular" or 'extra" when created. Eventually they could chage type for several reasons... A regular one is decided to be moved to extra since it is not folliwing the overall strategy (comboluted UI, applicable for niche or corner cases, etc). Also the opposite: something particular is deemed to be promoted usefull for general default use. And in general they may stay with the same type as they where created. Namely, for the extras I think there are many "market" or "locale" specific features that will be toggled by a subset of users.
Having these extras I think is a good way to capitalize knowledge. Take the exampke of the commit from @sjb007. If we do not have this then there will be many forks with valuable knowledge "lost".
If at some point the number of extras becomes "huge" maybe then an "extras" or extensions market/store would make sense to still have a repository of knowledge but build addons with selected extras.
Regarding telemetry, a very simple not intrusive approach would be to do a pull (instead of push telemetry) of dumny assets of the type extraXon.txt or extraXoff.txt triggered by the user changing the status of the settings property. Github would record thos download statistics. Of course this can be easily abused... But the same way as downloading 50 times an addon without using it...
Cheers!
The first Extra is available in the bonsaiPR latest build :)
https://github.com/falken10vdl/bonsaiPR/releases/tag/v0.8.4-alpha251102
Cheers!
The PR is now merged in the main branch. You can enable it in the settings of the addon:
Cheers!