Looks sort of like the houses of refuge we used to have along the coast here. Not many left.

PLUGIN UPDATE

@paulofukuta said in [Plugin] Multiple Component Edit Warning:

When I install the Edit Flag v2.4.0 plugin in SketchUp in Brazilian Portuguese, the tool name does not appear. How could I fix this bug?

There were unicode character bugs in some of the language files resulting in silent failures for the menu command labels.

I fixed all the bugs in the language files with version 2.4.2 (see below).

@elijahpekaar said in [Plugin] Multiple Component Edit Warning:

@ashscott Is there a possibility of getting an updated version for 2024 sketchup?

I am the author of Ash's extension. (He hasn't been here in almost 2 years and not posted in the forum for almost 7 years.)

Changes for SketchUp 2024 and Ruby 3:

v 2.4.2 : 2024-04-27 by Dan Rathbun

• Updates specific to SketchUp 2024+ and Ruby 3.2:
  - Changed File.exists? call to File.exist?

• Re-focus the Sketchup window, so that the Edit Flag warning dialog no longer seizes the focus from the main modeling window.

• Fixed the scrollbars showing in the edit warning dialog.

• Added system font identifiers for both platforms to the "font-family" style for the dialog. The text should now show in the system font.

• Localization:
  - Fixed unicode characters in files: es, fr, it, pt-BR, pt-PT
  - Added language hash files: cs, ko, ja, pl, sv, uk, zh-TW, zh-CN.
  - Localized the extension description and name for the Extension Manager.

• The extension is now signed.

• --> Get the latest version in the SketchUcation Plugin Store
• --> Get v2.4.2 at the SketchUp Official forum

@ezyuzin Any reasons why?

@robertWan said in AI-Created Extension for SketchUp – Issues with CTRL Modifier Functionality:

Using Sketchup::InputModifier::CTRL to check if the CTRL key is pressed.

Where did you get Sketchup::InputModifier::CTRL from? This is NOT a constant defined by SketchUp's Ruby API. Nor is there an InputModifier submodule. Be careful as the AIs have been known to just "invent" coding objects or functions to satisfy themselves in providing "solutions" (which are not guaranteed to work.)

FYI, the toplevel constants defined by SketchUp's Ruby API are listed at: Top Level Namespace

In the tool's onLButtonDown callback method, I think you should be using COPY_MODIFIER_KEY or COPY_MODIFIER_MASK instead of MK_CONTROL to test the flags passed in by the SketchUp engine. See the Sketchup::Tool abstract class overview.

Also, your extension submodule should be wrapped within a unique top-level namespace module. Ie:

module RobertWan # top-level namespace
  module CustomSelectionTool # extension submodule

    class SelectPlaneTool
      # ... the tool code ...
    end

    def self.activate_select_plane_tool
      Sketchup.active_model.select_tool(SelectPlaneTool.new)
    end

    if !file_loaded?(__FILE__)
      UI.menu('Plugins').add_item('Select Plane Tool') {
        CustomSelectionTool.activate_select_plane_tool
      }
      file_loaded(__FILE__)
    end

  end # extension submodule
end # top-level namespace

The easiest fix for Ruby 2 and higher, is to use a refinement that only that file can "see" and use.
I inserted the following at the top of the file (after deleting the Set reassignment):

require 'set'

# Create a refinement for the Set class:
module DBUR
  module RefinedSet
    refine ::Set do
      alias :insert :add
      alias :contains? :include?
    end
  end
end

# Use the refinement:
using DBUR::RefinedSet

By request from @paddyclown, here is the "fixed" file.
It still needs a drastic overhaul, but this will get it working (fingers crossed):

DBUR_QuickSelection.rb

@Didier-Bur ping (I do not know how to send this by PM in this new forum interface.)

The Gemini AI says:

The term "gobbledygook" was coined in 1944 by Maury Maverick, a congressman from Texas.

During World War II, Maverick was the chairman of the Smaller War Plants Corporation. Frustrated with the excessively long, vague, and pompous language of bureaucratic memos, he issued a memorandum to his staff telling them to "stay off gobbledygook language." He defined it as "talk or writing which is long, pompous, vague, involved, usually with Latinized words."

Maverick explained that he came up with the word by thinking of the sound a turkey makes—a "gobbledygobbling" sound. He felt that the pretentious and convoluted language of officialdom sounded just as ridiculous as a turkey's gobble.

@Dan-Rathbun said in C SDK save in 2022 or 2023 formats:

What is different in the v22 and v23 file formats that need to be maintained?

I took a quick look at the release notes and I see only 2 new features that would be saved into the SKP file data:

v23 : Added Ruby Overlays and the model now has a flag collection with a Boolean state for overlays.

v24 : Added the Ambient Occlusion style properties (a state flag and numeric setting.)

Opening a SKP file on any older version back to 21 would just ignore any unknown data. This is known as SketchUp's versionless format since v21.

So WHY would you need to backsave to what v22 or v23 saved as ?

Ie, v22 did not add any new features that made the SKP any different from what v21 saved.

And, v23 only adds the listing for the overlays collection and would just ignore the new AO style attributes (added in v24) it does not know about. It might leave the attributes as is within the model data but do nothing with them, OR ignore them so as to not write them out when it saves a v23 SKP.

I think it is expected that you use SUModelSaveToFileWithVersion() with a SUModelVersion_SU2021 constant.

What is different in the v22 and v23 file formats that need to be maintained?

The only other thing I can think of is to compile 2 external utilities with old versions of the SketchUp SDK and have these utilities backsave the SKP files using the SUModelVersion_Current constant.

The Gemini AI says:

The term "gobbledygook" was coined in 1944 by Maury Maverick, a congressman from Texas.

During World War II, Maverick was the chairman of the Smaller War Plants Corporation. Frustrated with the excessively long, vague, and pompous language of bureaucratic memos, he issued a memorandum to his staff telling them to "stay off gobbledygook language." He defined it as "talk or writing which is long, pompous, vague, involved, usually with Latinized words."

Maverick explained that he came up with the word by thinking of the sound a turkey makes—a "gobbledygobbling" sound. He felt that the pretentious and convoluted language of officialdom sounded just as ridiculous as a turkey's gobble.

@i5963c I would say it is a bug, although it is likely been this way forever.
Check the SketchUp API tracker at GitHub to see if it has been reported yet.

The GUI 3D Text tool puts the resultant text geometry within a component context.
This way it can be moved around, rotated, etc.

The API use of Entities.add_3d_text should also be inserting into a component or group context. This context can also have subgroups. So the workaround is to apply a transitional transform to the "g" subgroup and align it.

Unfortunately, the vertical text alignment constants are for drawing text to the view for tools and overlays. So they will not apply to 3D text.

@i5963c said in SVG or other vector file import WITH colors:

It should be possible to adapt the extension to translate these color names into equivalent RGB values, but this is currently not implemented, as I don't use SU2025.

To be specific, SketchUp 2025+ no longer comes "out of the box" with the "Colors-Named" W3C materials collection.

But, users may be able to import them from the new 3D Warehouse (it now has resources.)

However, for a Ruby extension this is not a problem as the SketchUp Ruby API still supports the color names. See: https://ruby.sketchup.com/Sketchup/Color.html#names-class_method
So your code just assigns one of the color names to a Drawingelement and SketchUp converts it into a material (and adds it to the "In Model" collection.)
See: https://ruby.sketchup.com/Sketchup/Drawingelement.html#material=-instance_method

The only caveat is that SketchUp does not support some of the gray/grey spellings variants, and may be missing a couple of the more obscure color names.

There is a commercial plugin called Many Importer that claims to import SVG (and other formats.) But it does not support textures.
There is a link to it's website on the Extension Warehouse store page. Search the EW for "SVG" and you'll find it.

There might have been some test done to see if importing SVG into SketchUp was feasible. I seem to recall someone opening a topic thread about it. (Cannot remember which forum.) Anyway, this could be a new topic for SVG.

The main challenge is that SVG is a 2D drawing format not a 3D model format. I.e., SketchUp has edges with 0 width. SVG has strokes with width. How would you want the 2D vector drawing objects to be converted into SketchUp geometry?

Another challenge (not unsurmountable) is that SketchUp 2025 discontinued the "out of the box" distribution of W3C colors which SVG still uses as it is a web XML format.

Aside: It might be more appropriate to import SVG into LayOut.

Looks sort of like the houses of refuge we used to have along the coast here. Not many left.

The easiest fix for Ruby 2 and higher, is to use a refinement that only that file can "see" and use.
I inserted the following at the top of the file (after deleting the Set reassignment):

require 'set'

# Create a refinement for the Set class:
module DBUR
  module RefinedSet
    refine ::Set do
      alias :insert :add
      alias :contains? :include?
    end
  end
end

# Use the refinement:
using DBUR::RefinedSet

By request from @paddyclown, here is the "fixed" file.
It still needs a drastic overhaul, but this will get it working (fingers crossed):

DBUR_QuickSelection.rb

@Didier-Bur ping (I do not know how to send this by PM in this new forum interface.)

Please reorganize your extension as a TRUE SketchUp extension.
See: https://ruby.sketchup.com/file.extension_requirements.html

Also, take note of the various numeric conversion methods that the SketchUp API has added to the Numeric class. (You do not need to write your own conversion formulae.) Here is an example that will default to model units, if the unit argument is blank:

    def convert_to_inches(value, unit = nil)
      units = Sketchup.active_model.options["UnitsOptions"]
      if unit.nil? # use model units
        case units["LengthFormat"]
        when Length::Architectural, Length::Fractional
          return value.inch 
        when Length::Engineering
          return value.feet 
        else # Length::Decimal
          unit = units["LengthUnit"]
        end
      end
      case unit
      when :in, Length::Inches then value.inch
      when :m,  Length::Meter then value.m 
      when :cm, Length::Centimeter then value.cm
      when :mm, Length::Millimeter then value.mm
      when :ft, Length::Feet then value.feet
      when :yd, 5
        # NOTE: constant Length::Yard (5) was added for SU2020,
        #  use 5 to avoid NameError exception in older versions.
        value.yard # yards to inches
      else
        value.inch # if inches or unknown
      end
    end

Also, this is a good read for dealing with units in SketchUp:

Dealing with Units in SketchUp

There are extensions to the base classes in SketchUp’s Ruby API which often new SketchUp plugin developers overlook. If you aren’t aware of them you might find yourself reinventing many…

Procrastinators Revolt! (www.thomthom.net)

FYI, I did report this to Trimble.

FYI ... Julia Eneroth has released her own edition of this feature that uses the SketchUp 2023 (and later) Overlay feature. So, for those that despise popup windows, you can see the instance path as a text overlay upon the model view instead.

Eneroth Component Breadcrumbs
https://extensions.sketchup.com/extension/880e8e68-2bd1-4451-949b-44d23ce0e2c7/eneroth-component-breadcrumbs

@Dan-Rathbun said in C SDK save in 2022 or 2023 formats:

What is different in the v22 and v23 file formats that need to be maintained?

I took a quick look at the release notes and I see only 2 new features that would be saved into the SKP file data:

v23 : Added Ruby Overlays and the model now has a flag collection with a Boolean state for overlays.

v24 : Added the Ambient Occlusion style properties (a state flag and numeric setting.)

Opening a SKP file on any older version back to 21 would just ignore any unknown data. This is known as SketchUp's versionless format since v21.

So WHY would you need to backsave to what v22 or v23 saved as ?

Ie, v22 did not add any new features that made the SKP any different from what v21 saved.

And, v23 only adds the listing for the overlays collection and would just ignore the new AO style attributes (added in v24) it does not know about. It might leave the attributes as is within the model data but do nothing with them, OR ignore them so as to not write them out when it saves a v23 SKP.