chili-epfl / qimchi

Modular QML framework for AR, robotics and tangible interfaces
1 stars 4 forks source link

Move demos to subdirectory #11

Closed ayberkozgur closed 10 years ago

ayberkozgur commented 10 years ago

We should move all demos (currently only chilitags-demo but certainly more in the future) to a subdirectory like samples/.

qbonnard commented 10 years ago

I guess it depends on what's the least annoying regarding the build system. The idea was to make it easy to add and remove qimchi plugins as well as applications using them. About this, we might actually want to use git tsubmodules to make them all equal.. no ?

ayberkozgur commented 10 years ago

Yes, for quite some time I was thinking about moving all our qml plugins to their own repos and introduce them as git submodules to the main qimchi repo. What's more, we can move the chilitags qml plugin into the chilitags repo itself, this would be very tidy.

Pros with the submodule approach: 1) Very intuitive approach 2) Would keep individual repositories very clean commit-wise 3) Would be able to introduce basically any other qml plugin out there as a submodule with the help of a custom build script

Cons: 1) chili-epfl group might be flooded with mini-qml-repos. This could be prevented by putting a prefix like qml- in front of every qml plugin we have. Maybe we could also use the Teams functionality of github? 2) qimchi repo itself might be too empty: Couple of 10-line build scripts and a few READMEs. We could put all the demos in qimchi that uses the external plugins. In the end, this would not hurt the repo that much since it makes sense conceptually.

qbonnard commented 10 years ago

I'd say the cons are good problems to have: 1) is a problem if there are too many contributions... For now we probably won't have more than 10 repos. And the chili-epfl group is already a mess anyway ;) Luckily there is a search function 2) I'd say the idea framework is just that: more documentation than code. The way I see it, the "qimchi" repo would have only documentation, and point at sample application repos, which -like actual applications- would be a selection of the plugins (via git submodules) and some application-specific code. Then we would just have one repo per (sample) application.

But for now, I guess it's better to stick to one monolithic repository, as long as it's not a problem. Since qimchi is still in the early development phase, I think it's just easier to get everything at once. When it's ready to be used for new developments, we can think about splitting cleanly...

ayberkozgur commented 10 years ago

Completed by ccd15b8702e31df19884f3b9c4ecd756b9deb816.