Sometimes I want a method to wait until a webdialog is closed to give a return value. But all tries so far have frozen SketchUp and then also the webdialog. (Example usage: unit tests or API methods that don't work with async Proc callbacks)
WebDialogs are more cross-platform and scale better than SketchUp's own antique UI. Text fits on buttons. Following best practices makes them easily work with any dpi.
Autodesk is looking a lot into mobile and web technologies (the SketchUp people can sing a song of that).
It would be really bad if Autodesk also gains the lead on the web.
**@thomthom said:
You're using a webdialog for the import - you can use the XML parsing capabilities of the web-browser:
http://www.w3schools.com/xml/xml_parser.asp
**
I'm working on a solution with a DOM xml parser.
It's more than 5 times faster than REXML (and probably much more in newer browsers). 
Can you right-click on the missing icons and get the image file path? Maybe some commands return an unusual file path?
Or it is a timing issue, maybe Fredo uses layz-loading techniques, or his tools take longer to load?
I don't see the difference yet from
OBJECTLIST = {}
Can you elaborate?
I could not reproduce the problem with the same toolbar names (工具栏, 正常, 具) after restarting SketchUp and opening the toolbar editor. I will continue try.
I updated the webdialog with improvements for higher dpi settings.
I added improvements for higher dpi settings.
I found why the placeholder text disappeared and added it back. And I updated the webdialog for higher dpi settings.
A small update to improve the webdialog when using higher dpi settings.
By the way, how many toolbars did you have roughly?
The information that I found says that there could be another url length limit around 500 (officially urls in IE can be 2083 characters long). This should not anymore an issue in ToolbarEditor 1.0.4.
With this test in the Ruby Console we could confirm whether this caused the error:
count=0;w=UI;;WebDialog.new;w.set_html("<html></html>");w.add_action_callback("a"){|d,p| count=p.length if p.length>count};w.show{ w.execute_script("var s='';for(var i=0;i<3000;i++){ s+='b';window.location.href='skp;a@'+s;}") }
It then envokes an Internet Explorer error (I get "Could not complete the operation due to error 800700a").
When I then enter " count" into the Ruby console, I get 2077.
Do you get the same error that you got previously ("The data area passed to a system call is too small")?
If data or id could be wrong, no Ruby callback would happen. If url were wrong, IE would navigate to a not existing site. Nothing that gives such an error.
Hi lionk,
can you try ToolbarEditor 1.0.4? It should now remember toolbar names and display Chinese correctly.
I could solve 1., 2. and 3., but I don't get an error when searching in LaunchUp for 面 or 测. Do you use the latest version of LaunchUp? Which version if Internet Explorer do you use?
The surface representation is probably much more complicated. SketchUp has only faces and edges as primitives and is thus not really appropriate for chemical/biological visualizations (that are more focussed on atom positions, angles and electon density). This plugin just places components of spheres (which is easy) but I have no idea how the surface representation is stored in pdb and how to generate smooth SketchUp geometry from it.
It is probably easier to let a molecule/protein modeler do the surface generation and then export it to faces/edges to do SketchUp stuff with it. I've seen for example pymol can export to vrml (SketchUp Pro) and obj (free SketchUp importer plugin).
http://www.pymolwiki.org/index.php/Surface
Hi, thanks for the reports!
As for 2. it looks like the "-" button has focus and accepts enter. I think I can make sure that this doesn't happen.
4., 5. I have no control about that, I wished it worked in SketchUp as it should.
I also had for some time sketchy edges in 8.0.16846 (and 7 etc.) but at the moment not, I'm not sure what is going on, but this is a part of Wine that is changing much (the DIB engine, you could also try if 2d export works now). The SketchUp version in the screenshot unfortunately isn't anymore available.
Hi,
You are using a system that is not officially supported by Boulder/SketchUp team. Don't expect them to throw gifts at you. We would better go forking SketchUp and building a program that is really open to everyone.
What you see is very likely not a pure graphics card issue (the drivers are quite sufficient with SketchUp's humble requirements. I use a graphics chip that some here call the worst ever, but I get excellent graphics.).
Sketchy edges in SketchUp are rendered using software rendering, on top of the model. The model is usually rendered with hardware acceleration (especially in Wine where this is the only option). Software rendering is a bigger challenge for Wine because it requires libraries that match those of Windows. However they only very recently implemented those in Wine 1.5.04 (but strange that I still only get sketchy edges in some versions of SketchUp).
You should try to add the latest development channel to your software updates.
There is no use for that file in the Sips version, so the require line shouldn't be there. I fixed it.
Ahh, je crois Adébéo est déjà très occupé à acheter SketchUp de Trimble 
(Peut-être SketchUp Heroes est le nouveau Basecamp?)