Hi Thomas, Happy to add a new bug --
> Eh, by the way, could you open up a bug for it, meaning adding wiki docs > ...?! Just paste your text in. > -- #1461 (looking forward to fixing some of the little critters someday... :-) ) > thanks for your feedback. We'll see what we can come up with. I think > the biggest hurdle is the gap between the 'gui' template's config.json > (nearly empty) and one of the templates like 'migration' or > 'with-contrib' that actually make slight changes to jobs, as you > suggested. We are working to support making "several simple and easy to > follow changes" with high priority (see bug#1417). Maybe we were > initially overstretching the goal of making simple things simple (aka > the 'gui' config.json) a bit, and are now paying ... I don't think you've overstretched at all -- I think all that's really missing for those of us coming to qooxdoo (and not bringing much/any related dev experience in a related project, like qt) is just another level of docs in the wiki. You've done a *fantastic* job with the wiki docs over the last 5-6 weeks (since I first started to dig properly into qx). I'm finding more and more of the system is not just understandable, but damn cool :-) . Obviously, improving docs can be rather hard/boring work for anyone who'd rather be writing code (most of us, I'm sure), but it will mean more clued in developers and less 'dumb' newbie questions in the mid term -- I hate not being able to figure things out on my own, and then needing to beg for help! Cheers, -Chris > Chris Banford wrote: > >> Hi Thomas, >> >> Really an excellent email this one -- I'm sure that this belongs in >> the wiki docs somewhere where new users would read it. >> >> I've figured these things out, but I'm sure it would have been a very >> informative read for me at some point not long ago, and I'm sure there >> will be future qooxdoo converts who will benefit from it... >> >> I've read the docs on the wiki many times and can follow the gist of >> them, but where it get tough it trying to make first steps in >> modifying/changing the contents of the config.json file. A few really >> simple examples of how to start with a project skeleton's >> config.json/manifest files and then make small and easy to follow >> changes, would be a huge help. At the moment I read and think I've got >> some insight on how some specific config bit works, but when I try it >> out I either get cryptic errors in the generatory.py console or it >> just doesn't do anything. >> >> For example: a short and simple wiki page of how to extend an existing >> job (for a newly created Skeleton proj) that then makes several simple >> and easy to follow changes to say 'build' or 'source'. Once new users >> can get something working, it quickly becomes easy to keep >> trying/changing things and soon one has the required insights as to >> what magic is happening behind the curtain :-) . >> >> Keep up the great work! >> >> Cheers, >> -Chris >> >> >> >> >>>> The Tool-chain (config.json, jobs, etc) is still over my head. I'm >>>> hoping that there are a few more wiki docs/how-to's in store, from >>>> those who feel comfortable with this stuff. >>>> >>>> >>> I mentioned in another post there are just three wiki documents >>> concerned with the 0.8 generator configuration. These are: >>> >>> - a general overview page >>> (http://qooxdoo.org/documentation/0.8/generator_config) >>> - a reference page for the config keys >>> (http://qooxdoo.org/documentation/0.8/generator_config_ref) >>> - a page with assorted paragraphs on various config topics that >>> deserve a bit more background >>> (http://qooxdoo.org/documentation/0.8/generator_config_articles) >>> >>> There is also a more general document on the generator, but this is >>> more like your typical product feature-list flyer >>> (http://qooxdoo.org/documentation/0.8/generator). So it's more about >>> impressing than informing you :). >>> >>> Of the basic structure, every application/library must contain a >>> config.json and a Manifest.json file in its top directory. From this >>> directory, a 'source/class' subdirectory is expected, which contains >>> a name space subdirectory and some class files therein. All other >>> subdirectories in the top directory are then created during generator >>> runs ('build', 'api', 'test', ...). >>> >>> The most important of these sudirectories is of course 'source' since >>> it contains your source code. Aside from the '<name space>' >>> subdirectory it has to have a 'resource' subdir (for icons, style >>> files, flash files, etc.) and a 'translation' subdir (for string >>> translation files). All these are mandatory, but might be empty. >>> During a 'generate.py source' a source/script directory is created >>> which contains the generator output (basically a Javascript file that >>> references all necessary class files, icons, etc.). This one has to >>> be referenced from the application's index.html (usually in >>> source/index.html). >>> >>> The 'build' dir (created with 'generate.py build') has a very similar >>> structure as the 'source' dir, with 'script', 'translation' and >>> 'resource' subdirs. The main difference is that everything that is >>> necessary for your application to run is copied under this common >>> root, and that the generator output script in 'build/script' contains >>> the actual class definitions, not just references to their source >>> files. The build dir is therefore self-contained, and doesn't have >>> references that point outside it. >>> >>> Create some vanilla skeleton apps (with >>> 'tool/bin/create-application.py -t [gui|migration] ...') and look at >>> their initial file structure, to get a feel for it. Tailor the >>> source/class/<namespace>/Application.js as the main application entry >>> class, add further classes to your needs, and let the tool chain take >>> care of the rest. You will have to run 'generate.py source' >>> initially, and then once in a while, and you can just try out your >>> app opening source/index.html directly in your browser, reloading it >>> to see changes to the code. If you are comfortable with that, run a >>> 'generate.py build' and open build/index.html in your browser. If >>> that is fine, copy the whole 'build' tree to your web server. >>> >>> HTH, >>> Thomas >>> >>> >>> >>> >> ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ qooxdoo-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
