SketchUp does not make its menus readable, they can not be accessed or included in custom plugin toolbars. This plugin can only make toolbars for plugin commands (sorry, it got missing from the description in the SCF plugins store, it's still mentioned in the SU extension warehouse).

SketchUp's native commands need to be replicated one by one. You can install LaunchUp, which comes with a lot of copies of SketchUp's native commands.

SketchUp's UI has two ways to modify the color of a textured material: You can color-shift the texture image (it still preserves color differences, but with an emphasis at a different Sketchup::Color)
and you can colorize the texture image (boolean, preserves only the brightness, sets the hue and saturation to a specific color).

The API does not differentiate between the two, so when you read color from a color-shifted material and set the same value again, it will be not just be color-shifted but colorized. It's better not to use these properties in Ruby scripts.

You can however "bake" the color-shift/colorization into a texture when exporting textures with the Sketchup::TextureWriter.

Bonjour, dans SketchUp, tu peux ajouter des chemins de chargement:
path = "/chemin/au/dossier/des/plugins" $LOAD_PATH << path
Après, tu peux charger "tout" des ce dossier:
require_all(path)

Si tu ne veux pas repeter ça chaque fois, tu peux enregistrer le suivant dans un fichier "load_plugins.rb":

require 'sketchup.rb'
path = "/chemin/au/dossier/des/plugins"
$LOAD_PATH << path
require_all(path)

et modifier le raccourci sur le bureau par clique-droit → Propriétés → cible et ajoute /RubyStartup "/chemin/à/load_plugins.rb"

This is risky, and does not solve the fact that even a well-maintained XP system (before april 2014) had a 6× higher chance to get infections than other Windows-based systems.

I have no clue what holds people away from moving to a secure newer or alternative supported system. The base of your computing activities must be something you can trust.

Or wait for 64bit Windows Explorer to run (thumbnailing) extensions of different bitness. Just don't require to run the thumbnailer in the same process.
Things can be worked on from both sides

But who's faster? I haven't given up my bet on SketchUp…

@unknownuser said:

Are you sure you can't simply make a (big) plugin to fulfil those dreams?

The question is whether the type of requests can be satisfied by making a plugin of inifinite size.
SketchUp's plugin API gives only a finite amount of methods, and is for creating/modifying geometry (and it's actually quite good and well-structured). What plugins cannot touch is everything that concerns the core (performance, UI paradigms, UI scalability, platform availability, including mobile). Simply said, plugin authors cannot turn it into the 3d app of 2020.

The same question applies to down-tuning Blender. Do Blender's extensibility options allow to fulfill these wishes, including customizing features near the core (inferencing), without requiring upstream changes (that is persuading all the Blender foundation).

Michalis's link looks very promising!

Cool! Can you tell more about the difference/advantage whether the window border and window chrome belongs to SketchUp or another application?
It's still a window and if I didn't want it to occlude SketchUp I would put it side-by-side, no matter whether its SU-owned or another program. Or is it about a pdf viewer with minimal UI?

And a question that could be of interest: How is the workflow, does it read local pdfs or does it need uploading?

Plugins can not influence the position of the toolbar (they can only tell SketchUp to show/hide a toolbar, and Sketchup remembers the position). Since these toolbars are created with a timeout (after all other plugins have been loaded), there was initially a problem wher the toolbar didn't remember its position. After report it was improved in SU2013 so that SketchUp should remember the position even after timeout. In which SketchUp version does it happen to you?
I have reduced the timeout, maybe that caused the problem?

Pilou, it's right that for non-ruby makers it is difficult to find the right place. The same is true even for ruby developers!!!
Marking strings with a '*' only works around the source of the problem. You would have to do the same edits again everytime when an update is released. If we want to support more options/languages/etc., we can separate code and data into different files.

The LanguageHandler has been published too early with an unfinished design and without considering the feedback that ruby developers gave. Since it's now part of the API, I'm not sure if there will ever be changes. It might certainly be "just enough" for new plugins, but it was too limited to make older plugins use it in place of our own translation libraries and many other plugins have also not switched to this new API.

If you are curious how one can translate a webdialog with one single method call, take a look into my Translate.rb (like in AttributeInspector or ToolbarEditor).

@anton_s said:

I never thought Hashes were faster than Arrays.
Ruby saves developers from using primitive data types how data is stored in RAM, but it has more abstract, optimized data types.
Arrays are likely implemented as a double linked list (correct my if I'm wrong) and hashes as some sort of trees. You can see in Wikipedia what each of them are good at (see indexing).

I wonder why 2048 is considered "maximum texture size" even if graphic cards may support 16k?

@unknownuser said:

Any way to force SU to go bigger

Draw edges to split faces and texture images into "tiles", with each tile displaying 2048×2048 pixels?
It's possible but not trivial to do with the Ruby API ( UVHelper.get_XYZ is missing, and workaround is slow), and for the modeler such a model would be harder to modify.

@oricatmos said:

That's too bad, since this could be useful.

If you are curious about raytracing, take a look at this script based on Adam's raytracer. The preview took about 3/4 hour.
I really see no advantage of having an imperfect built-in (or Ruby plugin) raytracer, while there are already so many dedicated renderers with better illumination models, more speed and more realistic output.

Since the draw_points (kills next operation) bug, I haven't used anymore the API's wrapper methods but use those with GL constants. I feel it keeps my code look more consistent.

Did you find out which is the maximum of points that causes problems? Is there a maximum for
draw/ draw2d with GL constants (which directly interfaces with OpenGL)? I'd rather think a wrapper would take care of such limitations than introduce new ones.

It's not inefficient (rather the opposite). It's a change that developers have wanted to happen already years ago. User data (like plugins) belong into the user folder, it's on all operating systems like that and even Microsoft strongly recommends it. The previous location needed administrator permissions (to manipulate system files) every time a user wanted to install a plugin.

As it seems, under Trimble the SketchUp team has finally the courtesy and resources to realize bigger improvements (to achieve more than adding a Google Earth button). But still changes take time.

… to reduce side effects and factors that you don't know.
A comparison with all things replicated (same model, same plugins, same observers) is more complicated and less meaningful than a comparison with all things reduced to the minimum.

What does the code do?
Apart from pure mathematical calculations, programming languages can also have side effects and interact with the environment (and such side effects make things hard to reproduce and bugs hard to discover).
Although the ruby version is maybe still the same, the SketchUp environment is changed and performance is affected by entity creation (which then can even call observers of other plugins) or interaction with the user interface.

I uploaded a workaround for IE 11's bug (ToolbarEditor 1.1.2).

Currently the plugin writes each snippet to a ruby file (in %APPDATA%) and stores the metadata with the plugin's preferences in the registry.
A json or yaml format would also not be a bad idea. I chose rb because it contains runnable code and I don't need to extract the code from a part of the file (or deal with escaping etc.). The metadata is also written in the comment of the ruby file, but I haven't decided yet to parse it out of the comment again, because there would be many sources of error (or the comment would have to strictly follow a specific syntax.

Thanks for these well-designed and documented code examples!
The raytest is so much more useful when used in a loop (ie. for finding an entity in for example vertical direction).

Sorry to reveal it, but actually there is no magic about the thumbnails. One does not "need" SketchUp or other special software to generate thumbnails, but every file saved by SketchUp already includes a ready-made thumbnail.

The only obstacle for displaying the thumbnail is that you have to know at which position in the binary skp the thumbnail starts. Windows Explorer and many other programs don't know the position, and doesn't search for the thumbnail.
Software that shows thumbnails either has a compiled list for how to get the thumbnail for specific filetypes (Mystic Thumbs) or maybe seeks through the file to detect if there is somewhere an image that it could display.

For Explorer32bit SketchUp ships already an extension that tells Explorer at what position an skp file contains a thumbnail. I have no idea what holds SketchUp back from doing this for Explorer64bit, I doubt it requires porting the full SketchUp and its 3d engine to 64bit.