Word of warning to developers

[scottlininger]

Have people seen any errors from other ways that scripts mess with each other besides naming overlaps? For example, observers from script A are messing with the model before my observers from script B fire off?

[todd burch]

There have been right-click context menu issues with validation routines. The classic issue here is HouseBuilder causing a beep if installed whenever any right click was done. Not so much a conflict as an annoyance.

I remember an issue one time with some script extending a base class of Ruby (like NullClass) and it causing issues. Don't remember the specifics.

What should probably be promoted is script authors subclassing Sketchup classes to extend them, as opposed to just extending them.

[tomasz]

@unknownuser said:

Have people seen any errors from other ways that scripts mess with each other besides naming overlaps?

I've got two scripts on my black list.
1st place : Matchbox Plugin 1.1 by antantantant
Population.rb

class Array
  def * (n)
    temp = Array.new()
    i = 0
    if n.kind_of? Float
      each {|v| temp[i] = v*n
            i = i + 1}
    end
    return temp
  end
  
  def + (n)
    if n.kind_of? Array
      i = 0
      temp = Array.new()
      while i < [self.length, n.length].max
        temp.push(self[i] + n[i])
        i = i + 1
      end
    return temp
    elsif n.kind_of? Float
      each {|v| v = v + n}
    end
  end
end

Arrrrgggghhhhhhh..... !! Do NOT modify built-in Ruby methods, please!!

2nd place: Train Simulator 1.2 exporter by Paul Gausden
mstsx.rb

class Sketchup;;Color
	 def ==(c)
		 return (c.alpha==self.alpha and c.red==self.red and c.green==self.green and c.blue==self.blue)
	 end
 end

Modification of original SU method, which can : 1st - give different results than other Ruby programmers expect, 2nd - prevents != method to work correctly.

Those bugs makes my life and users of my exporter harder.

[sepo]

Matchbox is also on the Podium NO NO list.

[deerwood]

Hi all,

though I not yet had any name clash problem, may I suggest a rule adopted from the Java world? The essential idea is to qualify/prefix "packages" with something unique in our internet world. Namely the domain of the author, reversed, optionally followed by some more specific info.

So e.g. Jim's "jitter.rb" is qualified by "com_blogspot_sketchuptips" and the specific info beeing "jitter".

And Ricks "GoldenGauge" is qualified by "com_smustard" (or maybe "com_smustard_wilson_rick") and the specific info beeing "golden_gauge".

Following that idea the plugins working code would not reside any longer directly inside the "plugins" directory (unless it is an essential thing/library) but in some directory named after the domain inside "plugins".

E.g. Jim's plugins ALL reside in "plugins/com_blogspot_sketchuptips" and ALL of the Smustard ones are present under the "plugins/com_smustard" directory, optionally further down in a dir named after the author ("..../wilson_rick") or a project ("..../common" or "..../utils").

And, please, all other excellent plugin writers here around: I apologize to not have named you. But you'll get the idea, hopefully.

To call/activate such a plugin on startup of SU there must be a minimal Ruby script directly in the "plugins" dir, requiering the real code. These would be one liners, but then named after the complete path to the plugins code. E.g. "jitter" would have this Ruby in the "plugins" dir (named "com_blogspot_sketchuptips_jitter.rb"):

require 'com_blogspot_sketchuptips/jitter.rb'

But it should be easy to just call a script common to a domain, that does advanced handling of (sub)scripts to be included. That script then just requires, what the final user wants to have. These require scripts (down to any level of the dir hierarchy) could easily be tweaked by users, by just commenting out "require" statements.

Packaging of plugins into this hierarchie/concept is easy for every developer of plugins.

Every plugin's author is known/can be reached (as long as his domain is existent).

Cluttering of the plugins directory is reduced greatly, especially when the feature of just require'ing subdirs reqire scripts is used.

What do YOU think?

Best regards, deerwood

[RickW]

Interesting concept, and for creating Module names, it could work. However, locating files in subfolders by organization/author name conflicts with Organizer.rb.

Currently, Organzier allows users to create subfolders in the Plugins folder that then become submenus in the Plugins menu, with the scripts located in those subfolders likewise having menu items in the respective submenus. For example, you could create a "Draw-Create" subfolder, then move all scripts that draw or create geometry in that subfolder. In the Plugins menu, there would be a Draw-Create submenu, and each file in that subdirectory would be represented in the submenu. It's a fast way for users to clean up both their Plugins menu and Plugins folder at the same time, while grouping scripts by like function.

I think that a script that parses the new template file and can display the pertinent script information in a webDialog will go a long way towards helping users who want or need to know the author/contact information or version number to check for updates.

[deerwood]

Dear Rick, all,

@rickw said:

Interesting concept, and for creating Module names, it could work. However, locating files in subfolders by organization/author name conflicts with Organizer.rb.

sorry, I wasn't aware of the organizer.rb. Hmm. Still not giving up on the subfolder idea , what about more closely mimic that Java concept by having under "plugins" max 2..4 letter folders named after the top level domains, e.g. "com", "edu", "org", "net", "tv", "de" or "co"? Isn't the length of TLD's restricted?

The organizer then could just ignore short folder names directly under "plugins", or, if neccessary, have a list of (additional) TLD names to ignore.

Under the TLD folders there would be the appropriate domain name folders of the authors. So someones/Jims/yours/mine plugins would reside in

• plugins

• co

• uk

• someone

• someone-else

• com

• blogspot

• sketchuptips* smustard

• de

• georg-rehfeld

For the module/class names I'm not any longer really happy with my proposal, because the names would be so exceptionally long/unusabale. Or did I miss some Ruby feature?

Just brainstorming, not more.

Best regards, Georg (aka deerwood)

[Chris Fullmer]

I think I'm not seeing what the problem is with having plugins just placed in the root plugins folder?

[deerwood]

Hi Chris,

as told, I had no name clashes yet in any way. But I see myself "managing" my plugins already, though I'm still a newby.

Especially because there are soooooo many, very helpfull plugins around/published in this forum (wow, thanks to all providers). I have to find a way to try these out and find the ones appropiate for my way of working with SU ... ever changing as I get these new great additions and learn to use them.

And then: Rick warned, I wrote, what came up into my mind. Maybe, that is poor/not appropriate. It is meant as just a base idea ... brain storming, as stupid as it may be, should not be taken literally. Take just one idea out of it or come up with a totally different general approach. Collect as much of ideas as possible. Later on one or the other may be able to make use of the idea.

Best regards, Georg/deerwood

[DavidBoulder]

Good thread. I may get in to a large ruby project soon, and I'm glad I ran across this. Will give me insight on how best to name and organize my code/scripts.

[MartinRinehart]

I don't like the initials idea. I'm probably here early enough to lock up "mr" but Mike Roberts and Mary Ryan may not be so happy when they get here next year.

The Java sort-of-standard proposed by Sun (inverted website names) never got popular. Too long. A ten-pound cure for a one-pound problem.

I think that using the name of the plugin should be SOP. VisMap is in a module named VisMap. That means that before you release anything, you Google it, which is a good idea for a lot of reasons.

A Wiki or Google doc re bad plugins would be most helpful. "X is bad" is not helpful, but "X is bad because..." would tell you what not to do so that you don't end up on the bad list.