I'm guessing you already saw this, but just in case: http://examples.qcu.be/assets/_core/php/examples/other/includes_outside.php

Also, you probably saw this: http://qcu.be/content/one-qcubed-installation-different-projects
Since then, I actually have some new thoughts. But I have successfully used one installation with 3-4 different projects.

If you find it useful and want to add, let me know. That way we can get a fully documented scenario how to do this.

Agsel - if you could write up all your thoughts in a single example, it would be SO amazing. Could you?

Agsel, yes I saw that post and was wondering if there was any updates/changes to that approach. I'd love to see what you've done.

I could try to update this and create a single manual out of this. My biggest problem is that I have changed the core code and I have some trouble keeping the qcubed installation up to date. But I will try to find a way and then I can write the manual which corresponds to the latest version.

If someone told me, how to best develop qcubed, I'd be happy to hear. My problem is, that I have one checkout from SVN. Now, I have made changes into this (translation, timer and some my own, which I haven't yet made public). Now, each update from svn is a lot of work - have to merge stuff etc. Also, creating patches is a problem. For example, I have changed qcubed.inc.php several times because of different tickets/problems. Now, it's hard to create a patch where only relevant changes are in. May-be I should do one thing at a time with qcubed installation?

Agsel - I would love to work with you to find the best way to make your contribution easy.

Here's how I do it:
1) I have my own application - the one for my business - that uses stable releases of QCubed only. I very rarely change the core components on that one - and I almost NEVER (literally, almost never) change the core files. I do this for ease of upgrades
2) I have a separate folder for each of the "trunks" of QCubed (1.0, 1.1, 2.0). Whenever I'm working on a core component that I want to share with QCubed community, I'd work in this branch. I'd work on one component at a time (for example, QTimer). When I'm done, I'd create a patch, upload it to Trac, and then REVERT my changes, syncing back to the original that's in the SVN. Then I'm right back with the rest of the community. And I can work on the next thing.

Let me know if you think if this might work for you!

Alex. So, when a new version of qcubed comes out, you update your own application's core base? I mean, copy (overwrite) everything?

My concern is that if a newer version changes something which would break my application, I could not just overwrite existing qcubed core with the new one. And if my qcubed is in my own SVN repo, then overwriting files might mess up the repo (at least I have had this problem).

But I haven't tried it with qcubed. Will try it out. I can add this to the manual also, if I find it somewhat challenging.

Yes - when the new version of QCubed comes out, i overwrite the QCubed base part. Completely. Throw the old stuff out, replace with the new. Then, before committing my application to source control, I review each changed QCubed file to make sure it's not gonna break me.

The good news is that the core team is working really hard to maintain backward compatibility - so that if you don't touch the core files, updating the core between, say, 1.0.2 and 1.0.3 is a no-brainer. Nothing is broken, no back-compat is affected at all.