Community components and subsystems?

I was thinking: It seems like lately people have been writing custom reusable Urho3D components or otherwise wanting Urho3D to have more useful components.

Would it make sense to start a separate community repository that consists of a collection of small, useful components that can easily be added to your project next to Urho?

1 Like

My opinion is that small useful components should go to core.
Also a carefully selected set of bigger high level components
should go to core to set as basis, as these will be well tested and
work well after upgrades. The alternate repository might not work with latest versions of Urho,
which is hard problem as we can’t expect individual developers to be up to date - many
prefer not to update at all.

I like the idea. Alternatively a page on the wiki could simply index these community components without moving/copying repositories around while still keeping them close to Urho’s source.

1 Like

I don’t think high level utility stuff should necessarily go to core.

Maybe it might be possible to add a new folder for these components under Urho3D/Source/Community or something along those lines?

That would either increase maintenance costs or will not be up to quality. So I really doubt there are resources (in time and hands) to do that in foreseable future. I think adding components to core is way to go

@slapin You’re not making any sense.

2 Likes

Well, for something specialized there could be something like “contrib” stuff in main repository, which is maintained like
"experimental" code.
But that doesn’t mean Urho should avoid hight-level components in core - there is basic set which is expected to have,
like IK, Ragdolls, AI components like Behavior Tree, etc. with carefully created editors and easy to use by people.
Otherwise these will have to be constantly reinvented. There is no enough high-level components in Urho.

Somehow I wonder if i should feel offended or not. Please explain.

Please read my message again and don’t feel this way.

I don’t understand why you feel it this way. I suggested a way to handle this so ti be still able to do it with limited efforts.
I’m really sorry if I broke your dream.

On the one hand, putting things into Urho core helps community reuse them.
On the other hand, it will bloat Urho core.

Urho core is simple and lightweight for now. I am not about actual code size, I am mostly about generic achitecture. It has few basic blocks that could be reused in the million of differect tasks.

One we start adding things to Urho code, it will lose its elegance. It will be getting bloated… E.g. I dislike RibbonTrail. It is nice feature, but I doubt that it is as generic and reusable as e.g. StaticModel. For me it’s something that should lay as 3rdparty asset like Skybox or smth else.

Possible soluion is to put all these things into Urho3D.lib but separate them from Urho core file and class tree.

As currently things are, not including stuff with core means that the stuff is basically unusable - it will not be updated,
it will not be built. Also making people start easier with their project is much more preferred than keeping things lightweight. If you don’t use things you don’t need they are not included with your software and do not consume resources.

I like the idea too. To prevent the code rot, we could setup nightly CI (or something like that) on those components and subsystem against the current master branch of Urho3D repo. Granted that it will not verify the correctness nor the functionality provided by them, but at the very least we know immediately enough which one break and does not build cleanly. And in order not to burden the core developers, we could setup the CI build notification to be sent to the maintainer(s) of each component/subsystems directly. Maintainer that fails to perform the maintainer role can be replaced or in the event no one else could replace him/her then the component/subsystem itself could be ejected from the community repository (or being marked as DEPRECATED / ONLY WORK WITH specific old version of Urho3D).

If we really decide to do this, IMHO, the community repo should be resided in the urho3d org in GitHub. It does not only have a maximum visibility there but also technically it is easier to setup all the above when they are centralised. Note that I do not mean to say you can’t have your own components/subsystems outside if/when we have this setup in place.

2 Likes

I agree that it would be best if it will work. Thanks!

However, before doing that there should be established skeleton build system to build entire repository of modules against current Urho tree and guidelines to a tree structure and naming convections.

Yes, of course when it has been decided. But we are only brainstorming the idea now, so let’s not derail the discussion with the implementation detail yet.

I need to stress an idea that if this repository will have any chance do doverge from main Urho or have any difficulties
building it (in relation to main tree) it is not worth it. It should not become class 2 citizen in infrastructure,
so it is “still part of Urho” and separation is “for maintenance needs”. Otherwise it will become nightmare to maintain and support so it eventually die out (probably engraving some good things). So it should not be a case for “lets remove features” direction of some community members (who apparently need some kind of OSG/Ogre3D/Irrlicht to just play their shader games and do not care for much else). So that means it is a subject to bugs in issue tracker and release management.

I like the idea too, but I’m not really enthusiastic about having them in the core:
I’ve chosen Urho3D because it’s not bloated with things I don’t need or I will never use.

In my opinion, just a wiki page which lists them would work.
On the other way it would be cool to have a separate repository where can be optionally downloaded and built by using CMake options.
I’m not sure about the maintainability of the last one though.

Just want to clarify. We can have many repositories in the same “urho3d” org. So the new community repo(s), should we agree to put them there, won’t bloat the existing “urho3d/Urho3D” repo.

Perhaps it is too early to talk about having a convenience way/tool to auto download/configure the optional components/subsystems, but the idea is certainly intriguing. In my day work I use https://start.spring.io/ to quickly generate a new Java/Kotlin project. I agree with you that it will be cool if we are heading to that direction.

3 Likes

I strongly agree with this sentiment.

@weitjong I quite like the idea of adding a repository under Urho3D/Community (or maybe we’ll be able to come up with a snazzier name, something epic, like THUNDERDOME). What can I do to help get this in motion?

2 Likes