The simplest way is to allow the user to select any entities. Just care only about those selected entities that are edges:
edges = Sketchup.active_model.selection.grep(Sketchup::Edge)
Let's say you now need to be sure there is a minimum of edges:
return UI.messagebox("You need to select two or more edges.") if edges.length < 2

The cleanest way would be to implement your own tool class for selecting entities. You would use a PickHelper to get whatever is below the point that the user clicked, and only if it is an edge you would add it to an array or selection (actually you do not really need to add it to the real selection), and then draw/highlight what is selected.
Don't do this until you have enough experience.

If something does not work, please give complete (and minimal!) examples and say what does not work. All I could say about Sketchup.active_model.selection.each is that it raises an error because it is an iterator method with missing block ("each" is not "edge").

@dan rathbun said:

@aerilius said:

Would it be advisable what I showed above?

NO. It is poor practice.
Observer classes should at least be a subclass of one of the API superobservers.

This is likely to have proper types ( is_a?(Sketchup::Observer)) and avoid unimplemented methods.

But the current solution in the first example is overcomplicated and distracts from the idea of what an observer is used for. An observer is an object that is notified about a certain events, and in the above case the "tool" class needs to be notified somehow. I agree that this observer should implement the interface of the specific observer (in order to have the behavior of a SelectionObserver, it must implement all its methods etc.).

But (in other ooo programming languages) it is legitimate to implement multiple interfaces, and my class would be able to observe multiple API objects. In Ruby, subclass inheritance does not allow this:
class MyTool < Sketchup::SelectionObserver, Sketchup::MaterialsObserver
In Ruby something like multiple inheritance can rather be achieved by mixin modules, and interfaces probably should be done as mixin modules(?).
class MyTool include(Sketchup::SelectionObserver, Sketchup::MaterialsObserver)

So I agree totally that the API should provide the observers as modules.

@aerilius said:

Is it guaranteed that SketchUp will not raise errors in future if some methods are not implemented?

We can so far only adhere to the documentation (and everything not mentioned will break in future), but considering the limited examples, I don't see that as a source to develop further skills. So this was rather supposed to get more people involved, especially some experienced with the internals or design patterns of the API.

@dan rathbun said:

… there is an add method upon the model's selection collection instance.

I fixed the mistake. Initially I had changed the example (model → selection) of how I wanted to illustrate the question, but it changes nothing on the core topic in question.

@anton_s said:

This is how I think Sketchup Observers work.

Then it's probably how the Sketchup::Selection class works, to which selection observers are added.

So far always when I used an observer, I followed the API example and created a subclass of one of SketchUp's observer classes. This poses some challenges for delegating an observer event to a private method in an instance of my main class.
Very simple example:

<span class="syntaxdefault"><br />class MyTool<br />  def initialize<br />    </span><span class="syntaxkeyword">@</span><span class="syntaxdefault">webdialog </span><span class="syntaxkeyword">=</span><span class="syntaxdefault"> UI</span><span class="syntaxkeyword">;;</span><span class="syntaxdefault">WebDialog</span><span class="syntaxkeyword">.new()<br /></span><span class="syntaxdefault">    </span><span class="syntaxcomment"># …<br /></span><span class="syntaxdefault">    Sketchup</span><span class="syntaxkeyword">.</span><span class="syntaxdefault">active_model</span><span class="syntaxkeyword">.</span><span class="syntaxdefault">selection</span><span class="syntaxkeyword">.</span><span class="syntaxdefault">add_observer</span><span class="syntaxkeyword">(</span><span class="syntaxdefault">MySelectionObserver</span><span class="syntaxkeyword">.new)<br /></span><span class="syntaxdefault">  end<br /><br />  def updateSelectionInWebDialog</span><span class="syntaxkeyword">(</span><span class="syntaxdefault">entities</span><span class="syntaxkeyword">)<br /></span><span class="syntaxdefault">    </span><span class="syntaxcomment"># passes entities to webdialog…<br /></span><span class="syntaxdefault">  end<br />end<br /><br />class MySelectionObserver </span><span class="syntaxkeyword"><</span><span class="syntaxdefault"> Sketchup</span><span class="syntaxkeyword">;;</span><span class="syntaxdefault">SelectionObserver<br />  def onSelectionBulkChange</span><span class="syntaxkeyword">(</span><span class="syntaxdefault">selection</span><span class="syntaxkeyword">)<br /></span><span class="syntaxdefault">    </span><span class="syntaxcomment"># needs to call instance method of MyTool instance<br /></span><span class="syntaxdefault">    </span><span class="syntaxcomment"># * either I keep a public globally accessible variable/constant/method to get the current instance of MyTool<br /></span><span class="syntaxdefault">    </span><span class="syntaxcomment"># * or I pass the MyTool instance (as self) to the initialize method of this observer instance<br /></span><span class="syntaxdefault">  end<br />end<br /></span>

Now seeing that an observer does not need to be its own class, but rather an arbitrary class (like MyTool) that can behave like the specific observer should = "implements the interface" (or in Ruby: "responds to" onSelectionBulkChange), I could simplify it like this:

<span class="syntaxdefault"><br /></span><span class="syntaxcomment"># implements onSelectionBulkChange from Sketchup;;SelectionObserver<br /></span><span class="syntaxdefault">class MyTool<br />  def initialize<br />    </span><span class="syntaxkeyword">@</span><span class="syntaxdefault">webdialog </span><span class="syntaxkeyword">=</span><span class="syntaxdefault"> UI</span><span class="syntaxkeyword">;;</span><span class="syntaxdefault">WebDialog</span><span class="syntaxkeyword">.new()<br /></span><span class="syntaxdefault">    Sketchup</span><span class="syntaxkeyword">.</span><span class="syntaxdefault">active_model</span><span class="syntaxkeyword">.</span><span class="syntaxdefault">selection</span><span class="syntaxkeyword">.</span><span class="syntaxdefault">add_observer</span><span class="syntaxkeyword">(</span><span class="syntaxdefault">self</span><span class="syntaxkeyword">)<br /></span><span class="syntaxdefault">  end<br /><br />  def updateSelectionInWebDialog</span><span class="syntaxkeyword">(</span><span class="syntaxdefault">entities</span><span class="syntaxkeyword">)<br /></span><span class="syntaxdefault">    </span><span class="syntaxcomment"># passes entities to webdialog…<br /></span><span class="syntaxdefault">  end<br /><br />  def onSelectionBulkChange</span><span class="syntaxkeyword">(</span><span class="syntaxdefault">selection</span><span class="syntaxkeyword">)<br /></span><span class="syntaxdefault">    updateSelectionInWebDialog</span><span class="syntaxkeyword">(</span><span class="syntaxdefault">selection</span><span class="syntaxkeyword">.</span><span class="syntaxdefault">entities</span><span class="syntaxkeyword">)<br /></span><span class="syntaxdefault">  end<br />end<br /></span>

This does not follow the documentation. There are also some differences:

• I could use one class (MyTool) to act as observer for different SketchUp entities ( onSelectionBulkChange, onViewChanged, onLayerAdded)
• SketchUp's observer classes define all callback methods with empty implementation. Thus a subclass inherits them (and you can call them but nothing happens) where as my not-subclass does not respond to all callbacks.
  SketchUp currently does not raise a NotImplementedError. But theoretically it could do so (and it's not specified by the documentation).
• Once more it becomes clear that many object oriented concepts (interfaces, abstract classes/methods) don't directly apply to Ruby (which has no more than plain classes/modules). Yet Ruby programming can be very object-oriented (we would include mixin modules or extend objects with mixin modules).

How do you use observers, as subclass of a Sketchup observer class or as your own class that implements that interface?

Would it be advisable what I showed above? Is it guaranteed that SketchUp will not raise errors in future if some methods are not implemented?

Screenshot?
In many cases, SketchUp's large icons are far too tiny (24px), at least for touch screens (and they even don't dpi-scale properly). I had never imagined that 16px could be not small enough for some users. Anyways, some modernization and flexibility there is needed, especially in terms of the Ruby API so that developers are allowed to provided more crisp graphics.

I believe the incentive for the 4px margin introduced in 2013 was to have a cleaner workspace and better distinguishable buttons. I believe it was referred to scientific studies.

SU8M2: 8.0.11752
SU8M5: 8.0.16846 (plus récente)

Il semble le collègue n'a pas mis à jour SketchUp
Le bouton existe depuis SketchUp 8 version de maintenance 2.

Comme il a une license, il peut simplement télécharger gratuitement la plus récente version 8 Pro.

Ah… et le bouton va fonctionner seulement pour les plugins .rbz, on installe les autres (.rb ou .zip) manuellement dans le dossier Plugins (après les avoir décompressés).

There are no methods to read (or modify) individual pixels, but you can export a material's texture image using Sketchup::TextureWriter.
Create a temporary group (so the material doesn't have any distortion), apply the texture and load it to the texture writer.

@unknownuser said:

It may well become a trimble account login

I've be wondering about that possibility for long. Or at least add more OpenId providers. It just happens by hazard (or conspiration) that I already had a Google account, but I would certainly not create a new one just because one website doesn't support any openids that I have.

I have no answer. Someone else might help out.
I understand that some users see it as a one-time action to download a plugin, without permanent membership (by having a account).
It reminds me a bit of the newspaper sites where you have to pay with a FB like. The more registered users, the more fans/better stats has SketchUp?

I remember there was the set_html issue (although it was reported not to happen anymore). Is that a possible cause?

Under Google, the SketchUp web services (ie. 3D Warehouse) where integrated with Google's infrastructure. Of course that was still the case after money exchange, so any change to the accounts system would need to be built. The 3D Warehouse accounts are now separated, but use (only) Google as OpenID identity provider for signing in. You also have to consider that all "old" SketchUp users already had a Google account anyways, and the SketchUp team are also still friends with their colleagues at Google.

An interesting topic… …do you think about anything for or against that current status quo?

The old button must have been a plugin, so it has ruby code. Without that ruby code there won't be a button. Could you look up where that plugin was located (installed) in the old SketchUp version (SU8 had the plugins under Program Files/Google/Google SketchUp 8/Plugins) and then you could just install it in SketchUp 2014 (under <your_user>/AppData/Roaming/SketchUp/SketchUp 2014/SketchUp/Plugins).

This plugin is rather for small code snippets (~1-10 lines). Of course one can make such a script that inserts a component, but that depends on what exactly it should do.

Point3ds are "real" objects and have an identity (two objects with same properties are not the same object). Things that we can compare have a method == that checks whether two objects are "equal" (trivial for numbers and strings). SketchUp's Geom::Point3d.== method checks for example if all coordinates (x, y, z) are equal, and then says two points are equal.

uniq appears to check for identity and not for equality. So we need to do it on our own, with checking for equality:

roof = roof.inject([]){ |array, point| array.any?{ |p| p == point } ? array ; array << point }

It does the same as:

roof2 = []
roof.each{ |point|
  # Check if we have already added any points to 'roof2' that are equal with 'point'.
  any = false
  roof2.each{ |p|
    break any = true if p == point
  }
  # If 'roof2' does not contain an equal point, we can add it.
  roof2.push(point) if not any
}
roof = roof2

The method <Sketchup::Menu>.add_submenu(<String>) → <Sketchup::Menu> is called on an existing upper-level menu and returns a submenu (which is of same type as any normal menu).
The method <Sketchup::Menu>.add_item(<UI:Command>) → <Fixnum> is called on a menu (or sub- or subsubmenu) and adds a menu item.

So of course you can apply the methods repeatedly, ie.

command = UI;;Command.new("a command"){ puts "command executed" }
# Get a reference to one of SketchUp's top level menus;
toplevel_menu = UI.menu("Plugins")
# This is a Sketchup;;Menu!

# And add an item;
toplevel_menu.add_item(command)

# Or add a submenu;
submenu1 = toplevel_menu.add_submenu("first level submenu")
# This gives again a menu!

# And add again a submenu;
submenu2 = submenu1.add_submenu("second level submenu")

# And add an item;
submenu2.add_item(command)

The SketchUp API lacks a method to draw images to the viewport. It's still open, whether such a method should also support sizing (variable width/height) or even matrix transformations (to draw textures). No matter what, OpenGL image drawing is certainly better performant than drawing pixel by pixel.

So that is what this experiment is about: How far can we get with the current API methods? The method draw2d(GL_Points, Array<Geom::Point3d>) allows us to draw individual pixels. Has anyone used it in larger scale?
I used it here to draw PNG images to test whether it makes sense to apply it in a plugin, or rather wait until an API method is added.

Version: 1.0.2

Date: 28.06.2014

ae_PNGLoader_1.0.2.rbz

Usage:
Install the attached plugin in SketchUp.
Menu Plugins → [Test] PNG Loader Tool
It will draw a PNG image. By left-clicking you can switch to bigger images. By double-clicking you can try to load your own PNG image (SU 2014).

For loading new png images, I use ChunkyPNG, a pure Ruby library. However, it requires some of the standard libs that are shipped with SketchUp 2014. And it appears it is not able to read every PNG file, but only those with special encoding (255 indexed web-save colors). But it's enough to show the principle. It seems the biggest obstacle is to read image files. (Another API request?: expose internal image reading methods)

The idea is to change the structure of the image data by sorting pixels by color. To each color is assigned a list of pixel coordinates, which can efficiently be drawn with the API method. This data is then marshalled and stored in a file.

Je ne sais pas à propos de DIBAC, mais beaucoup d'autres plugins ne supportent pas être chargés d'un répertoire non standard. C'est un bogue dont il faut faire rapport aux dévéloppeurs. Si c'est le cas avec DIBAC, il faudrait (aux devs) utiliser des chemin relatifs avec File.dirname(__FILE__) au lieu de Sketchup.find_support_file().

You could theoretically read the screen dimensions using JavaScript, divide by two and subtract half of the dialog's width and height (you can read the inner width without window border using JavaScript).

This is not recommended. If it is not essential to the functioning of you plugin, think again if you can get along without it. This causes your dialog to launch initially with different dimensions and then "jump". On a multi-monitor setup, you don't know whether the dialog is on the second monitor, and the above formula will give you coordinates for the first monitor. The dialog will jump to the first monitor, if it was launched (by registry preferences) on the second one.

@trogluddite said:

So yes, planned obsolescence for sure - there is no technical reason that XP cannot continue to be upgraded to keep it "secure", because it is being done as we speak!

Then you have never maintained legacy software or been involved with change management?

The cost of change (no matter what type) is low in the design phase, still low during development, but after completion it causes huge effort within the ties of an architecture that never has been made to be changed like that.

The reason why it makes no sense to continue XP for ever is not only that the head of development (Win 7, employs from the ground up different technologies (that share little with XP), but also that patches can barely avoid the worst case – still during the support time Microsoft wasn't able to keep XP's security on par with its later systems (see the 6× higher infection rate).

The way to get for ever updates for software is to accept updates/upgrades when they come, that is what the developers have been producing all the years! Best is not to disconnect, but use rolling releases.

Of course you are right, not all scenarios (corporations etc.) can adopt rolling updates, but that comes with the downside of having to do somewhen a big step, with all the other software and hardware that couldn't be upgraded all the years.