Move Login/loading screen to a optional plugin. Fix IAssetFactory further.

[jonnenauha]

Had some downtime at home and decided to move the login/loading screen stuff to an optional plugin. This was kind of glaring misuse of UiAPI and what it should not have.

The console and taskbar stuff might be next in line to be removed from UiAPI, but those can already be disabled easily new TundraClient( { taskbar : false, console : false });

[antont]

cool, seems like a good step!

I don't have time to really test right now, perhaps in late afternoon. Feel free to merge yourself if you think it's best to put in right away -- AFAIK it is, but don't wanna just press merge without running :)

One related thing I've been trying to understand lately is this plugin mechanism vs. use-webtundra-as-library-for-apps thinking. Current understanding:

Plugins are things that are useful to have as a part of the SDK, to provide some common functionality (like dom integration or scene parsing) which can be used by different apps. Or just as dev helpers. A good new example might be the AR enabling plugin discussed on wed. The initialize - postinitialize mechanism enables to make these plugins cooperate nicely in cases where they somehow need to know of each other to not clash or so.

In WebTundra 1.0 language, apps (like pong or car driving) are ideally normal web apps that just use the SDK as a lib. I think in webrocket / dev2 terms they are 'custom clients': can define their own entry point HTML, main.js replacement if necessary, modify the TundraClient creation and just use additional js files (called from main or from the html I guess) to do the app logic.

For these apps / custom clients the plugin mechanism is not relevant, right? Because they don't provide some API for e.g. in-scene ec_script apps to use. And they don't need the initialize - postinitialize biz to coop with other plugins. So for example in the WebTundraCar porting we actually should not have put the car code into a plugin but just as normal JS code outside the SDK?

Or is there some reason why such apps would be good to make as plugins?

The same question perhaps applies to this login screen too: is the login screen actually just the UI of one app, could be just a part of a 'default tundra client' example app? That app / custom client would just have these widgets in it's html + the necessary js code to feed the login params from the form to the connect call. Would it make sense to move html/index.html & main.js to examples/DefaultTundraClient/ or so and have that login UI there?

Is there any benefit of this being a plugin actually? I don't see it providing any API that other parts would use. Does it need the init - postinit mechanism?

Please no pressure to reply in length here, am just reporting recent thinking and we can talk live if you have time at some point :) .. I can for example summarize afterwards here for the record.

[antont]

I tested this now with the idea to merge finally. Even if this is better as an example or something later, anyhow separating away from the main.js to a plugin is the major step towards whatever it is exactly how we want it finally.

But am puzzled now because behaviour changed. Comparing current dev2 and this proposed change (i.e. admino/webrocket head):

Startup is identical, both show the login screen similarly. Great that it comes from a plugin now.

Then when I connect to a local server, running stock Tundra scenes/Physics2/, it differs:

• current dev2 completes the login, login screen goes away, black screen shows at the end (with no ogre mesh support and no three.js asset usage that is expected and correct
• the version from this pullreq never completes the login, the 'loading 3d space' stays there indefinitely

I bet this is no biggie but would be nice to understand before merge. I try to debug if/when have time & energy, hints would be welcome. I wonder if it has to do with the login screen or the asset related changes.

[antont]

ok found the reason finally while debugging - was first checking the assetapi transfer checks etc. but they never fired in either version (probably due to all assets fetch failing).

what hides it in current dev2 is simply the call in main in onConnected handler: https://github.com/realXtend/WebTundra/blob/dev2/src/main.js#L168

[jonnenauha]

Yes I noticed this also. The real reason why it does not hide is that transfers never complete successfully, they all fail. The transfer tracking and all that looks to work perfectly fine. Its just the "hide loading screen" monitoring I do in AssetAPI.update https://github.com/realXtend/WebTundra/blob/dev2/src/core/asset/AssetAPI.js#L286

That start monitoring flag never goes to true as no requests have a valid factory in your Ogre asset filled scene. Meaning that it does not know "all transfers finished" (although failing).

It's a stupid bug and I already have a todos there in this pull request to move monitoring of transfers to the plugin from AssetAPI. Here https://github.com/realXtend/WebTundra/pull/63/files#diff-827b6fc43ba471278d831a56a7348cb0R698 and here https://github.com/realXtend/WebTundra/pull/63/files#diff-827b6fc43ba471278d831a56a7348cb0R300

[jonnenauha]

In a scene where any asset request find a proper factory the screen should hide ok :) Don't merge this yet, I fill fix that monitoring now. I probably have to add new events to AssetAPI for the plugin to be able to do non-polling monitoring of the request queue. And some timer stuff for a "no assets request executed" scene.

[jonnenauha]

@antont Give it a go now :)