Dialog Extension

[JCPalmer]

Here is the tester / Demo page of the Dialog extension I am doing.  Taken a while.  All development done except multi-camera / modal stack.  Not published yet in respository.

 

https://googledrive.com/host/0B6-s6ZjHyEwUfjlzYXJKMC1zLXdIaV81REJhbjdfRmczQTJFOEpjWWg2SUIwZVRRS0VsR28

 

Please look over.  I saw that on my Mac that fonts did not look that good.  FYI, make the window the size you wish before loading.  HTML set for loading in CocoonJS, & does not re-size with window.

 

Jeff

[Samuel Girardin]

Fonts are perfects on windows with ie or chrome.

[jahow]

Everything works perfectly fine here! The result is impressive, although the FPS is pretty low when zoomed out and displaying some panels (ex.: Look&Feel panel, 1000 meshes total, 20 FPS).

 

Do you have specific uses intended for this?

[Wingnut]

It's just plain amazing, Jc.  Well done!

 

Can I ask about stringBundles and messageBundles, etc?  Are there provisions for multi-language (i18n)?  (thx)

 

https://www.google.com/search?q=xul+window+types&source=lnms&tbm=isch

 

A fun search for various types of xul windows/panels... makes ya think about where Jeff's dialog COULD go, from here.

[jahow]

I didn't know about XUL... this looks like an endless stream of possibilities

[JCPalmer]

Thank you for trying this out & your feedback.  Let me go through some of your responses.

 

First, there is no internationalization.  If one were to build that, it is usually built on top of a windowing system.  This would be the case here too, except:

• I do not know if string in Javascript is 16 bit or not, which you would need for unicode, multi-byte languages.
• Blender's built in font does not handle those letters.  You would have to switch the typeface to an os system font (truetype?).  Blender does this, but I have not tried it.  In any case the character code being > 128 would require it go in a file / module ending in _EXT.  This is how I allowed those french / german vowels without making the file too big.

@Wingnut, I do not know what these bundles you speak of are (part of internationalization?)

 

I have just done more testing on mac.  I thought it might have been my ignorance on how to operate an arc rotate camera without a mouse.  I just plugged in a real mouse, and zoomed in, and it does not look good.  It is a 5 year old machine, so results probably not important.

 

I have not run this on CocoonJS yet.  The Url is too long, and is redirected using Googledrive.  Will do this from my local server.  When I tried to load it from Safari on a retina iPad air 2,  the forcing of the hardware level to 1 made everything huge, and clicking on the buttons did nothing.  Not sure if that is a bug, or just  self inflicted.

 

The gracious comments of lets say 'surprise of how well this worked' are probably due to the speed advantage Tower of Babel 2.0 inline code has over Fileloader & .babylon files.  TOB can serve up meshes on an industrial scale.  Fileloader has many speed inhibitors:

• It relies on JSON.  I am pretty sure every every time you request a mesh the entire .babylon is parsed.  You could have a .babylon for each letter, 96, but that causes as many problems as it solves.
• FileLoader does not support cloning.  This is more than just a speed problem, but also a CPU / GPU memory problem.
• No OO programing capability. You a stuck with getting a BABYLON.Mesh.  With inline code, you can specify a base class.  TOB 2.0 has a base class property in Blender. I fully take advantage of this here make the 'A' class inherit from DIALOG.Letter, which inherits fro DIALOG.BasePanel.
• I do not know how the JSON parser is implemented, but I know the javascript parser is written in a compiled language.

The result is when you click on the LAF button, nearly 700 meshes fly up in almost the blink of the eye.  Fileloader might even crash some systems with low memory trying to do that.  

 

@jahow, you helped more than you know saying 1000 meshes.  There is either a memory leak in TOB mesh factories or in Babylon.JS itself.  Debug shows 792 meshes should exist.  Click another section and come back and it is 792.  I did some random series of clicks and the number started growing.  Need to investigate.

 

Have to stop.  This is already too long.

[Wingnut]

Thanks for the info, Jeff!  Yes, stringBundles are for i18n.  They are a flat database of key/value. 

 

All GUI "widgets" that can contain text... can/should use attributes like label="$run_button_label" or maybe label="$colors_panel_label".

 

Then, everytime you populate a widget with some text, you would run a function called getString(token, whichbundle);  Then use THAT returned text.  Or getMessage(token, bundle).  Study firefox stringbundles for more/better info, I suppose.

 

The English stringBundle (sometimes a .properties file) for the above example... might look like this...

 

run_button_label = "Run";

colors_panel_label = "Choose a color";

 

etc.

 

I learned this from xul (I spent 5-6 years having fun with it, building a Mozilla extension). 

 

By doing this, you can change the language of an entire application... just by switching its stringbundle.  This keeps translators from needing to muck-around in the code.

 

Of course XUL is xml-based, so maybe things are different, but... no.  Using stringbundles (for labels) and messagebundles (for error reporting and other 'messages')... is pretty wise. 

 

It won't slow tab-panel changing speeds very much, because all the tab-panes are built at init-time.  They just switch z-order with each tab-press.  No stringbundle queries needed at tab-click time. 

 

*shrug*

[jahow]

Sweet, I'm happy I could help Good luck with that bug-hunting!