Right, this is a question about application design philosophy more than anything. As usual, i’ve gone on a bit, but I’ve implemented ‘easyRead™’ for the short of patience.
The main goal of [size=200]tampon[/size] is to provide an intuitive framework to use to build applications. Not that you can’t build apps already with juce but, without knowledge of the fundamentals of sound app architecture, it [size=200]is[/size] difficult to do stuff more sophisticated than basic tools.
It’s [size=150]going to be based around a Document/View system[/size], and is going to take care of a lot of stuff that should be taken for granted (but currently is still time consuming to assemble, or even know to assemble).
Of course [size=150]one[/size] of the [size=150]main design goal[/size]s of the Doc/View system [size=150]is to separate the[/size] model ([size=150]document[/size] data) [size=150]from the[/size] view (on screen [size=150]editor[/size]), making it easier to change the UI without needing to touch the document code.
Now, [size=150]with the Jucer,[/size] the most important parts of the [size=150]document[/size] - the child [size=150]Components[/size] - [size=150]are used directly by the editor[/size]. Because of the nature of Components, as they are added to a parent, they are removed from the one they are in. This sort of violates the model, as you’re supposed to be able to create multiple views of a document if you so desired.
Obviously having it [size=150]this[/size] way [size=150]makes things[/size] pretty [size=150]simple[/size]. Plus, it’s not really a problem as it only requires a single view. I want to make sure that the tampon framework does allow for such basic ‘quick-fix’ design models, [size=150]but[/size] I also want it to be a guide for application design too (for newcomers with ambition greater than their architectural knowledge).
So my question is: [size=150]are you happy that it operates in this way?[/size] It saves time and effort in many ways, but also violates some design guidelines (though that may only present a problem if it were to expand in unforeseen ways). [size=150]Were there a time-saving framework to facilitate it, do you think you might have bothered ensuring that the Components displayed on the editor are not the same objects stored in the document?[/size]
[i’m not saying i have a problem with the jucer i’m just trying to make sure that i have my priorities in the right order.]