There's http://forums.sketchucation.com/viewtopic.php?f=323&t=38431 (Selection Manager) which I posted a couple days ago.

What do you have to do to get a plugin added to this index?

Ah, I was aware of SelectionMemory, but only being able to manage one selection set kind of defeated the point. I didn't know the second one, but it doesn't say if it can save them in the model, and I don't exactly like the UI -- Glad I didn't waste my efforts

@unknownuser said:

so downloading it quickly in case you revoke it

Haha, don't worry, that won't happen Seeing tools like TOS, EBBy* and co being free, I won't charge for something as simple as managing selections

I want to announce my first public plugin for SketchUp, the Selection Manager.

Now, before I start describing it, I have to say that I was very surprised that there was no such plugin yet; means that if there actually is one, please let me now...

Description:
The purpose of Selection Manager is to be able to save named selections and recall them later, even after restarting SketchUp and reloading a model.

Features:

• keep multiple, named selections around
• Modify saved selections by adding/removing new entities to it
• Automatically update a saved selection if parts of it get deleted
• Save and load selections with/from the model

Usage:
The plugin adds a new sub menu to the context menu, called "Selection Manager". This menu contains the following items:

• Add new selection -- Asks for a name under which to save the selection. If the name is already in use, the user gets asked whether the existing one should be replaced or extended.
• Load selections from model -- Loads saved selections from the model. See the caveats section for more information.

Additionally, the menu has one sub menu per saved selection, which features the following items:

• Select -- Recalls the saved selection
• Add to selection -- Adds the current selection to the saved selection
• Remove from selection -- Removes the current selection from the saved selection
• Remove -- Completely remove the saved selection. Warning: There is no confirmation dialog.

Caveats:

• Loading the selections from a model can take some time. My tests, with ~70k entities and a couple of selections, took between 0.5 and 1 seconds.
• The selections get saved as attributes on the entities. To avoid copying those when copying an entity, the attributes will only be set temporarily during saving; they will also get removed as soon as "Load selections from model" has been used. That means that the selections should be loaded right after opening the model and that they cannot be loaded again, without opening the model again.

Installation:
Just download the attached .rb file and place it right in the Plugins\ directory.

selection_manager.rb

Saying that Ruby doesn't have variables is plain wrong though. Even if the variables just hold references to objects, they're still variables, and the term "instance variable" is found throughout most object oriented programming languages (and I think the fact that Matz himself calls them variables is proof enough that Ruby has variables :))

Of course it might be wrong to compare BASIC variables and Ruby variables, but then it's also wrong to compare apples and oranges.

okay, maybe it's because of one of the plugins I am using. Anyway, the point is that the ruby interpreter is only being run for events, rendering ruby threads useless

@unknownuser said:

I'm not seeing what you are seeing. I see it printing "iteration 0" the first time I run it. Then when I run it the second time I get two lines, then three etc...

Well, you did, in your own way, prove that threads don't work properly (which is exactly what I wanted to demonstrate).

However, what one was supposed to do, and what one was supposed to see was:

1. execute the line of code, once
2. don't do anything => it won't display anything, even though it should every 0.1 seconds
3. move your mouse in the viewport (where the actual model is displayed) => you will see that now the thread will be executed.

you, kind of, did the same by executing new ruby commands, which also executed the threads you created.

If this was pure Ruby, you would install the sqlite3-ruby gem (http://gemcutter.org/gems/sqlite3-ruby), which requires the sqlite3 header files to compile and a more recent version of Ruby.

I think the only solution for SketchUp is to find a sqlite binary and write wrapper classes around that one (I really doubt that there's a ready solution for that already).

About multicore support
I don't exactly see how support of multiple CPU cores would enhance SketchUp's speed.

Admittedly, I haven't been working with huge models yet, but nevertheless I only noticed two cases in which CPU power matters: loading/saving* and using Ruby scripts. And exactly here lies the problem: Ruby itself, especially the very old version (1.8.0) that is being used in SketchUp, does not support native threads, but only green threads (and those won't even work properly in an integrated environment like SketchUp).

Now it is not an easy task to just add support for native threads to Ruby, and it won't be of any use if the scripts don't make use of threads themselves (and none of them does as of now, because they don't work, as I stated earlier**).

As a result of this, SketchUp could at most really make use of two cores, using one for the UI and one for processing/ruby scripts (and as I've understood, Google is indeed working on that and made underlying preparations already with the release of 7.1)

*: with the current file size of bigger models, an unlimited amount of CPUs/cores won't be indefinitely increasing speed anyway, because the underlying filesystem and even more underlying performance of HDDs is the real bottleneck.

**: an integrated Ruby interpreter will only be able to execute commands if the main application, SketchUp in this case, calls out to it. This also means that Ruby threads (not to be confused with native threads) will pause until SketchUp calls the interpreter. This is done for events like moving the mouse and of course other UI interactions (and that monitoring stuff, forgot its name right now), but only for those. As long as the user isn't interacting with the applications, threads will pause (and thus would intensive calculations).

A way to demonstrate this is to execute the following code in the Ruby console:
Thread.new { 5.times {|i| puts "iteration #{i}"; sleep 0.1 } }

This, if it worked, showed "iteration 0" to 4 within 0.5 seconds. However, it won't print anything until you move your mouse in the model.

An updated version of Ruby
I would really appreciate if the used Ruby would be updated to one of the two recent versions, 1.8.7 or 1.9.1 -- I do favour 1.8.7 though, because 1.9.1 breaks compatibility in some regards (I do, however, not know if 1.8.7 is fully compatible to 1.8.0 :/)

Also, there should be no problem in shipping the stdlib with SketchUp, I think.

A plugin manager
Like some of the others in this forum, I would appreciate a well thought-out plugin manager, with per-plugin metadata like author, license, version and dependencies (and legacy support for current plugins, that miss those information for obvious reasons).

The plugin manager could also work like APT (a package manager on Linux), with support for so-called repositories, updates and dependency resolving, thus providing a one-click interface for installing and updating plugins.