Posts made by tomot

Point well taken. Its an odd coincidence, which transpired with my desperate attempt to become SU14 compliant. ......S**T happens!

I found the problem!
I just installed my original Bootable Disk image HDD
It has NO Icon Problem, with SU14.

So I looked thru the code. and yes an _ (underscore) went missing in the icon title.
I'm current looking at a 3rd Bootable Backup to see whats happening with it.

I strongly suspect this may have been a file saving error. Caused by my Editor.
SU8 shows no errors, because the _ is not missing.

@tig said:

@tomot

I asked for a screen-shot of your Plugins subfolder showing the icon files, and a snippet of the code that is trying to use them for the buttons, so we could be sure they 'exist' and the code matches the path etc.

Please trust me, there is no change in the snippet of code, pertaining to the use of the 3 icons, otherwise SU8 would show the same error. BUT SU8 has no "green-yeuk!" icon

---

@tt_su said:

Can you supply a full working example with code and icons? ZIP or RBZ we can install and debug?

You got mail!

Here are the 2 example I sited again

concrete_frame_icon1.png
concrete_frame_icon4.png
concreteaddon_icon.png <--- this is the "green-yeuk!" icon

The other example was the truss icon:

truss_icon.png <--- this is the "green-yeuk!" icon

I can't seem to produce a screen capture of the tooltip which shows correctly when the
"green-yeuk!" icon is highlighted by my mouse, these Rubies still run, the "green-yeuk!" icon just annoyingly sits there

But again I must emphasize, I see no reason why these Icons trade there "green-yeukyness"
based on what what computer they run on. Once more there is NO "green-yeukyness" icon in SU 8 which also runs happily on both computers.

Why the Hell can't we refine our own Tar Sands Oil in Canada?
Are Canadians technically inept?
Are we intimidated because we are too politically correct to transport oil over Native land?
Why do we need to transport Oil to the US via pipeline for processing?

Have you ever heard anyone in the media either CNN or CBC, ask those questions?

And just in case your still thinking of saving the planet ..... forget it!, its over!
No one is concerned about consuming GMO's or consuming Seafood from the Pacific Oceann.....stay tuned. Fukushima is destroying the Eco system of the Planet for the next 100 years and more, forget about Climate Change or a potential pipeline leak, they will pale in comparison.

If I make the statement at my blog "My scripts are SU 2014 compliant" is that really true?
It appears, as illustrated in (my attachment), that Ruby 2.0 is inconsistent in flagging spaces in scripts. That being said, how can I trust scripts which appear to be Ruby 2.0 compliant, on my computer, are compliant on my customers computer?

I'm still of the opinion that, Ruby was a poor choice to begin with, as an API scripting language for SketchUp. Now 10 years later they tightening up on defining Ruby scripting errors, using Ruby 2.0. I can think of no other scripting language, Lisp, GDL, Python, Mel, that would want to introduce this kind of havoc with its customer base. The Main reason Software become bloatware is because of bad past decisions. Cardinal rule, never drop support for past failures, or you will alienate your customers. Even major SketchUp add on Makers, don't look very capable when it comes to writing Ruby Code capable of passing the Ruby 2.0. I feel sorry for Vray this might set them back another 4 years. LOL!

I don't think Python developers would ever dream of going down this road of misadventure, considering the large amount of major 3d Programs which use Python as a Scripting Language.

In addition, is it even possible to find a Script Editor that will pick up all Ruby " spaces " and delete them in a Script.

---

This extra space issue is a HUGE problem! I picked up that habit from looking at code posted by other members over the years
Are you saying 0.upto(@co34nx-1)do|i| would be Ruby 2.0 compliant?

Interestingly I have documented that SU 2014 is also derelict and inconsistent in picking up "spaces" in Rubies.

The example below passed without Ruby 2.0 detection

%(#BF0000)[if ($sl404 < 2)
UI.messagebox( "Less than 2 risers is not allowed")
return nil
end

    if ($sl404 >$sl303-2)
       UI.messagebox( "Less than 2 risers after Landing is not allowed")
    return nil
    end]

I see Ruby 2.0 does not even like spaces in # comments (see attachment)

---

Tig , thanks again for your detailed explanation, As I stated above I'm aware of how to fix the UTF8 issue. I would like go back to my original question, which Jim responded to, regarding upto. (see attached pic)

I agree its vast improvement of the old method. It was a bit tedious to constantly start SU, open ruby console, start ruby script, take note of errors, quit SU.

---

Before SU 2014! One would never see loading errors in Ruby scripts.
My attached error text file, is simply a Copy and Paste into Notepad for illustration purposes of errors produced by SU 2014 while trying to load scripts.

Are you saying If I Cut and Paste the errors into Notepad ++ I would get a better idea of what are errors and what are not errors?

Thanks for your help. Nothing has changed Permission wise etc.
There are 3 icons in the folder. What would cause only 2 to be read?
Another question if SU8 has no problems opening these Icons on either my computers, one with win7 32 and the other with win7 64, why can't Su2014 do the same?
Particularly when my example uses the same naming characters on each computer.
Yet the results are totally unexpected.

I would hope someone at Trimble will take note of this:

@jim said:

The 3rd is best, but all are functional. Your error is in the code you are not showing.

OUCH!..... after spending all this time to find API SU 2014 errors I don't want to, revisit finding the non API version again just to find the rest of the error statement.

But I will submit an API SU 2014 error list, for one of my Rubies:
90% of which are not actual errors as noted by line numbers as noted my ^
I know the char (UTF-8) reference is the only one that appears to be valid.

---

SU API Error.txt

I just found another example (see attachment)

---

Which of the 3 following upto statements is supposed to be API and SU 2014 compliant?
I'm specially referring to the correct location of do.

0.upto(@co34nx-1) do|i| API flags no Syntax error!

0.upto(@co34nx-1)do |i| API flags no Syntax error!

0.upto(@co34nx-1) do |i| API flags a Syntax error!

I double checked this on both systems, the 3 icons reside in the same folder.
I'm also fully aware of the new plugin folder location
I'm curious because my SU 8 install has never faulted in reading these icons

concrete_frame_icon1.png
concrete_frame_icon4.png
concreteaddon_icon.png

FYI:
In order to check if my Plugins are API and SU 2014 compliant. I'm using 2 eval versions of SU 2014 on 2 separate computers.

1. OS win7 32bit no Icons are missing
2. OS win7 64bit Icon is missing. (see attachment)

---

@andrews said:

@unknownuser said:

Unfortunately you can't buy critical thinking, it only develops after one has been on the planet for a very long time.

I fail to see how levying such character judgments is expected to motivate me or my colleagues toward further action. I'd prefer we steer clear of such unproductive endeavors.

Thanks for your detail response, I apologize! my last quote was not directed at you, it was simply an observation, and in hindsite should have been part of a larger discussion but which is totally out of place at this forum.

@andrews said:

@bmike said:

Did they move it on the Mac? Otherwise its in Application Support...

Your intended clarification may be confusing, as there are multiple application support directories.

The location of the plugin folder for SU8 and before was buried inside the root-level app support folder:
[pre:2w7fink1]/Library/Application Support/Google SketchUp 8/SketchUp/plugins[/pre:2w7fink1]This is a system controlled (i.e. machine-wide) location that requires root privileges to modify, and is therefore a very unfriendly way of doing things.

For the 2013 release, we moved the preferred plugins location inside the user's personal app support folder. It remains the same for 2014. In that sense, as of the 2014 release, Windows and Mac are now both the same in preferring to have plugins within each user's personal Plugins folder instead of in a shared location.

The full pathname for Mac plugins in 2013 and 2014 is:
[pre:2w7fink1]/Users/<username>/Library/Application Support/SketchUp xxxx/SketchUp/Plugins/
aka
~/Library/Application Support/SketchUp xxxx/SketchUp/Plugins/[/pre:2w7fink1] Where of course, "xxxx" is 2013 or 2014.

I believe the code still looks for plugins in /Library as a secondary location, but as is the case with Windows, you really should use the user-specific location instead of the system-wide location unless you have a really good reason to do otherwise.

Andrew

Andrew:
I think the common courtesy would have been to respond to my inquiry directly. Do you not think it would be appropriate to include a statement in the API that I can direct customers to where SU 2014 users, on Apple iMac's should expect to find the plugins folder?

It would be really helpful to have an official reference from Trimble I can point to. I'm starting to lose credibility! Already one irate SU2014 Customer is upset by scripts are not SU 2014 compliant. Even after explaining I no prior knowledge about SU 2014. He's telling me my scripts should all be in .RBZ format and should be installable in the Extension menu.

You guys are creating a nightmare, not a solution. Solutions require critical thinking
Unfortunately you can't buy critical thinking, it only develops after one has been on the planet for a very long time.

I don't have a MAC. One of my Customers wants to know where the plugins directory is located on a MAC, for SU 2014 ?

---

@tig said:

Sketchup v2014 uses a newer [better] version of Ruby.
This has meant that in anticipation of the release, over the past weeks authors have been doing a lot of reworking of Plugins, discreetly in the background.

Your older Plugins will probably cause issues with v2014.
Do not copy them across.
It's highly recommended that you install fresh versions from the PluginStore etc.
Many of these are already updated to work with v2014 [as well as earlier versions].

There may of course be issues with some older plugins that haven't been updated [yet]...
Please report these in each Plugin's thread, so that the author is made aware of an issue and hopefully a v2014 friendly update will be forthcoming: sometimes there is major recoding needed, but often the .rb file just needs its "encoding" changing to "UTF-8 without BOM" rather than "ANSI", which can be easily done in Notepad++...

Trimble seems to think authors have nothing else to do. Was it not more important to create a 64bit version? Instead we have the entire Ruby add on Industry checking code for errant spaces, degree vs º etc.
I dumped one of my Plugin folder for SU 8 into SU2014 The list of error was 4 pages long. Most errors were from major add on makers, I wont name names, other were mine some of which were derived from copying ruby code from other code writers. If I was a Trimbler now! I would not be so proud.

I'm telling customers not to buy my scripts if they intend to use them in SU2014. I simply don't have time with an 8 hour eval copy of SU2014, to see if my Rubies are API compliant. Also I would starve if I had to survive on $5.00 scripts.