Comparing Sketchup::Color objects

Developers Ruby API
1

The following line of code

Sketchup::Color.new(1, 2, 3) == Sketchup::Color.new(1, 2, 3)

returns true on macOS (SU 2022) and false on Windows (SU 2017).

This kind of things are a nightmare to anyone trying to target both platforms on different versions (like myself). I found a proper solution to comparing colors (by checking the corresponding RGB components), but I can’t comprehend why == fails in SU 2017… Or perhaps the equality is implemented differently on Windows altogether?

Overall, very unhappy.

2

he Color #== method checks to see if the two Sketchup::Colors are equal. This checks whether the RGBA values are the same. *In versions prior to SketchUp 2018 two color objects with the same values would be considered different.

2 Likes
4

Just found that out while you typed… What a stupid thing to implement equality like in the 1980s. At address level. I sometimes hate this API from the bottom of my heart.

1 Like
5

You mistake the situation. Before SketchUp 2018 the API did not implement a Sketchup::Color#== method.

This meant that color objects inherited the “plain” Ruby Core BasicObject#== method which states …

Equality — At the Object level, #== returns true only if obj and other are the same object.

Typically, this method is overridden in descendant classes to provide class-specific meaning.

So the “typical overriding” in the Sketchup::Color subclass did not happen until the 2018 release. It was requested by the extension developer community.

You can use a backward compatible method in your extension submodule like so …

  def color_same?(color, other)
    color.red == other.red &&
    color.green == other.green &&
    color.blue == other.blue &&
    color.alpha == other.alpha
  end

You will need to have patience with the API. SketchUp is 20 years old and the API continues to be improved slowly. Believe us when we say that it was much, much worse back in the v7 days when Google owned it.

1 Like
6

Thanks for the detailed insight, Dan!

I’m trying to be patient in general, but this thing really confused me and checking the docs was the last thing I would have tried… It’s been too many of these inconsistencies along the way and I wish there was some sort of page that went through some of the common pitfalls.

I remember in the beginning that I was trying to use the filter function from Ruby, only to find that SU2017 comes with an older version of the language that only knows about select. Easy to fix things if you know about them, but they all add up and create frustration as well as a feeling of having a program that only “runs on my computer”.

Anyway, enough with my rant. I’m glad to hear that things are looking up, and with this I hope that such “surprises” will be a thing of the past as we continue to move away from old SU versions.

7

Lesson learned. Checking the docs is the first thing to do.

The second thing is to check the official API tracker for bug reports or feature requests for still unimplemented enhancements.

Even I myself ran into that one, so I avoid using the filter alias to this day.

The SketchUp API only extends the Ruby core, so coders must use Ruby core docs to keep up with Ruby core changes. I might have the change lists linked in the my Ruby Resources compilation.

Well, as this had to do with the Core vs the API, these kinds of “braking changes” will recur as SketchUp updates to new Ruby versions. Sometimes the SketchUp Extensibility folks will publish a “breaking changes” guide for devs when updates happen (usually with major Ruby version upgrades.)

1 Like