We've got another thread on the list for the reworked website design (that includes a spinner as a side effect of this thread, if you want so). http://groups.google.com/group/pyjamas-dev/browse_thread/thread/654bf005b8b4b0ae/6f1066f3ee040d42
In my eyes the site is now ready to be uploaded. The last story left is about the spinner: As also mentioned in this thread it's current being included as a simple image in the index.html (startup container) file and hidden by the violet/pink header of the website as soon as it is created by the javascript. -- Showing the spinner and hiding it when loading is completed should fully go into the bootstrap.js script. 2012/1/29 C Anthony Risinger <[email protected]>: >> ah that reminds me: peter could you please make the new spinner a >> separate file, then make it selectable as an option via pyjsbuild, i >> think with two options already it should be obvious how to do that, >> but perhaps make it an argument that you pass by name? > > this can already be done with: > > --bootstrap-file=BOOTSTRAP_FILE > > ... simply create a new bootstrap file implementing the bootsplash, or > use the existing one. I have noticed that the 'bootstrap*.js' files are in ./pyjs/src/pyjs/builtin/public/, and they are obviously copied over to <app_name>/output/ for any Pyjamas application translated to javascript using pyjs (see: def merge_resources() in pyjs/src/pyjs/sm.py, line 87). This is not totally clean as the application only needs only one of the bootstrap files! And the fact that the two bootstrap script file at absolutely identical, apart from one having __pygwt_earlyUser() empty and the other not for obvious reasons, makes me ask: Can't we make this better and simply externalyse the __pygwt_earlyUser() function? We must make it easy for the "end user" (developers using Pyjamas for their projects) to 1.) add code that needs to execute "early" (provide a generic facility) 2.) choose from a set of ready-made "early activities" (implementations of the generic facility) One of those from 2) would be "show a startup animation (or progress bar)". It looks very much to me that the --bootstrap-file parameter is _too generic_, because who would rewrite/heavily customize/replace Pyjamas core functionaliy, and then pass this on to pyjsbuild with a command line parameter?? I believe the Pyjamas core should stay there untouched, and we should provide hooks or ways to inject code into the bootstrap code. (I think, actually, that's what new users expect nowadays when they start using a new development framework.) PROPOSAL 1: * We externalise the __pygwt_earlyUser() function, removing it from bootstrap.js, also replacing the call to __pygwt_earlyUser() by: if (__pygwt_earlyUser) __pygwt_earlyUser() * The externalised __pygwt_earlyUser() functions should live in separate .js file in a dedicated folder, e.g. ./pyjs/src/pyjs/builtin/public/opt/ * Now, the more difficult part: Either a.) Instead of the --bootstrap-file parameter we introduce an --earlyUser parameter (obviously matching the tail of the related function: __pygwt_earlyUser), which would tell pyjsbuild to also copy the named script file from the externalised functions files folder (.../opt/, if not a file is referenced directly) to the output/ folder Or, maybe better b.) Allow a configuration setting in the Pyjamas application/project for the "earlyUser" thing, thus avoiding the need for the command line parameter (the developer would have to remember or put in a build script), which does the thing in a.) even with a "normal" pyjsbuild * The pyjsbuild script would add an additional script-tag to the container (HTML) file to load the "earlyUser" script before bootstrap.js (or something); __pygwt_earlyUser() would then be defined in bootstrap.js and would be executed as usual. Sound good? When this is done we could make a startup animation or progress bar the default setting for Pyjamas development. Maybe. Peter
