Yes, loading-times might be a little longer when importing obj-files. Needs some time to sort and arrange data into the right place and also the way the data to work with is organized in memory it needs some time to build the display-lists from. Since it's not an action game but an editor that has no time pressure, I don't bother 1 or 5 seconds here. All shipped examples in .TBGL3dEd-Format (except the triceratops) are on screen at the moment I click them in filelist but also the triceratops needs less than a quarter second here.
Important seems to me that the data later work fast. If you read meshes above 5 MB - ok, it might display them- but the program is not intended to edit such big meshes. It's just supposed to edit mesh-groups which get attached to bones later with some other tool, to create small object as crates, furniture or to edit static interior meshes up to around 5000 faces which get build into scenes with some scene/world-editor later. So this program is only part 1 of the complete project.
Using "UI"? No - not for this project.
I don't like using callback-stuff and always to stumble across some hurdles which seem minor important on the first sight but detain me for hours from desired results. Callbacks need cumbersome ways to store other functions parameters because they're not valid in callback-function - so is like writing a script in two different languages to me. If I would like to use controls that behave as stupid as windows does and if it would be fun to me to deal with unforseen behaviour for countless hours just because windows-developers think it all has to work their ways, then I would use windows-controls probably.
Now, since I've written the gadgets once - I get working controls onto the screen in no time flat. Just have to add one field to my array, set it's properties - done. And the good thing about this is: If I need some control that does not exist yet - I just can create it exactly the way I need it.
So the "real" project hidden behind all this 3d is the Gadget-UI that now grows in background from the needs in different TBGL-situations/applications.
Just as a reminder - I use tB since october last year. Currently I'm still learning the basics which are Core & File-Module mostly. These have real great functions and methods that I don't know from any other language - and I still discover new ones which makes it interesting to use and try out. Sometimes they are entry-point to think different ways and awake weired new ideas. And I use TBGL-module of course - to be honest: TBGL is that easy and straightforward, Petr and his little helpers did a real great job here - and I probably never had tried out thinBasic without it.
I don't like the idea to move around, scale or rotate by scrolling some sliders - that's most indirect and cumbersome way and also scrollbars and sliders have an lower and upper limit. That does not fit for movement in endless worldspace. But probably there's no other possibility of movement when using windows-controls but I know I would not like always have to move the mouse over some slider before I can do the actual movement. If you wan't to move around by changing some control as you would do with sliders or scrollbars - use the textboxes in this program to their full functionality... point there with mouse - if you see some yellow background behind some numeral turn mousewheel...
Who needs sliders or scrollbars? that's so 1992...
Bookmarks