GUI Panel problem

ask a question about how I can implement a panel like “debug” in BabylonJS, which is a structure in my own Ztree plug-in tree.

II don’t know whether it can be created in Babylon, can you tell me?
And the other functions that need to be implemented are the model structure loaded into the scene and a series of functions such as adding, deleting, modifying, etc. The one I am doing now does not relate to the relationship between the model and the node before, but just implements dragging. I wonder if there is a better way to write it in Babulon?
This is my project on the server, which can be viewed

Hey, why not just using the inspector?

Hi guys. Some URL’s:

TS src:

Dist version:

Quick question for anyone: If ranwei wanted to translate all the text… into umm… Asian-like words/fonts… would that all be done inside ? Maybe search for all occurrences of textContent, and modify at those points?

Thoughts? Perhaps we should be using messages/stringbundles for easier translation to other languages? (Wingy ducks inbound flying shoes being thrown at him) :slight_smile: (Wingy checks W3C manual regarding separation of presentation from structure.)

Perhaps our BJS core error messages should be stringbundled, too… and playground GUI labels… stringbunded for easy i18n, as well? (Wingy’s dog runs under the fridge). :slight_smile:

Stringbundles are LOTS of work. Every place (within inspector) where coder/author wishes to use an “English word” or any “other English”, they would instead use sys.getString(curBundle, “stringRefName_msg”). There is a bundle for many languages, each containing the SAME “key” stringRefName_msg, but each one returning a different value (text) in THAT bundle’s language. SO, when ranwei opens the inspector, he/she chooses a language, and the inspector “tries” to change all its little text pieces… to ranwei’s chosen language. EVERY occurrence of ANY text-to-screen in the inspector, is “looked-up” and retrieved from a stringebundle, before being displayed. ERF!

I don’t know if this is how Windows OS translates, but it “was” how XUL did/does it. (Mozilla and maybe Firefox GUI) and maybe XAML as well. Anyway, a somewhat implausible system, but NOT doing it… has ramifications, too.

Back on-subject almost: If ranwei wanted to remove/modify the event that happens… when any of 10+? treeItem-types… is clicked-upon or moused-over, where/how might that happen? Thoughts? (thx)

I’m think ranwei needs a stand-alone “Scene Explorer” (by itself)… which is far less complicated than full inspector (but might not work without it)… and then … what? Ranwei would still need to deal-with the many types of treeItems (representing many BJ nodes/scene-stuff), and assign click/over events to each. So, he would still LIKELY want to import all the default treeItem types… and modify those, both translation-wise and click-on event-handler-wise. Erf.

We sort of need a “Scene Graph TreeView-Hackers Starter Kit” :smiley: Or maybe… “Build Your Own Inspector - Scripting Language v1.0”? hah. ouch!

However, it is not so complicated at present, but it can achieve some hierarchical relations of scenes, such as adding layers, deleting layers, searching, modifying names, etc. These functions are also bound to the model in my scene. If the layers are deleted, the model will be deleted accordingly

1 Like

nod. It all depends upon “how deep” you want to inspect/edit. For example, nodes - lights, cameras, and mesh - each node-type has many properties that COULD be inspected and edited, yet they are different properties. SO, perhaps EACH TYPE needs its own type of inspector and editor.

One mesh property is .material. Materials have LOTS of properties, and there are many TYPES of materials, some having speical properties ONLY for their own type. Is a special editor needed for each type? Who knows?

The BJS inspector has already made many decisions about “how deep” inspections and editing SHOULD be provided… for each type of scene-item (for ITS design-purpose).

The current inspector is a nice piece of work, imho. My advice, start with IT, and then modify it until it works like you wish. As you modify it, you will learn more and more about “going deeper” and “going less-deep”. Only YOU can know how deep you want to inspect/edit… but… if you START with current inspector, you will have something working, easy. Then start modifying it… tiny steps… and do lots of learning about BJS inspector at same time.

Also, the inspector is nicely programmed, and I think learning the current inspector REAL WELL… would help MY progamming skills… and maybe same for you, too. Grab your own version of the JS, insert divider lines and lots of comments to yourself… and soon, you will be inspector pro and understand it perfectly. THEN… modifications are easy, and easily reversable. (if you have good version-management skills) :slight_smile:

Also, you might get new ideas and discoveries for the default inspector, and you can contribute those ideas to BJS… in the future. IF you are using same “system” for YOUR inspector… as the defualt BJS inspector… then your new ideas can be EASILY test-driven in the default inspector. You are using the same system, so your new ideas will easily “plug-into” the default inspector. Easy implementation.

AND… you will be an inspector pro, and be very helpful to many others who wish to customize the default inspector.

To sum, I think there are MANY advantages to starting-with a default inspector, and customizing IT… as you wish. Doing that… has a bright future for you and for BJS community, imho. Party-on.

Sorry, I really don’t understand what you said, the translation is not accurate, so you want me to use the babylonJS native inspector?

Well, I am not pro… but yes… I think you should START with it, and then modify it, if you wish.

Perhaps you wish to de-power it, or change some click events on SOME tree-items.

But only you make decisions for YOUR project. I don’t know how deep/complex you wish YOUR inspector to be. Only you know that. :slight_smile:

but I don’t even know where to change the inspector code

I gave you URL’s to where to DL the typescript source or the JS bundle. Yes, you do not know how and where to modify the default inspector… until you learn how it works… by studying its code, adding divider lines, and adding many many comments as you learn, and saving new versions over and over.

It might take 1-3 months of study, depending upon your experience. But afterwards, you will be powerful. :slight_smile:

three months?I only have one week

You agreed to a 1-week deadline on building a custom inspector? Then maybe your current goal is to move deadline to 3 months. :slight_smile:

With 1-week deadline… I say no, nothing better than default inspector package. Easy-install… powerful “out-of-the-box”, and easily meets 1-week deadline.

  • That’s the path you’re talking about. Download it locally

If you are not a TypeScript programmer, then… JS “distribution” version - here:

You might wish to read forum and docs about installing inspector (yeah, locally). I have never done it, but I hear that it is easy.

Is this one all right

Hi, that is not the inspector. That is the fabulous BJS scene editor, I think. :slight_smile: Different thing.

Is this thread solved, as best it CAN be?

@wingnutt The thread as been dupplicated numerous time unfortunately and @julien-moreau answered here: Do you use Playground, Editor, or a local editor for your BJS dev?

1 Like