Mac truncates tool names question.

driven

hi all,

I've been [finally] trying to learn some ruby, and in testing OI.readline I stumbled on this...

When I add a second argument "r", in the way suggested in some reference as essential in ruby 1.8.5, I get truncated Tool names coming back from the log file.

The log, itself, is not truncated, and nor is the array with the single argument.

I wondered if the API, also calls for Tool information with the two arguments?

john

>  l=IO.readlines("./tmp/SketchUpUndo0.log")  # readlines(name, sep, limit [, open_args]) 
 
 l[1..-1].each {|element| element.chomp!("File Save\n") }

 l_a = l[1..-1].dup

 l_b = l_a.dup.reverse
["Tool(PaintTool)\n", "Tool(RectangleTool)\n", "Tool(RectangleTool)\n", "Tool(CircleTool)\n", "Tool(CircleTool)\n", "Tool(PolyTool)\n", "Tool(PolyTool)\n", "Tool(PolyTool)\n", "Tool(MoveTool)\n", "Tool(MoveTool)\n", "Tool(MoveTool)\n", "Tool(RotateTool)\n", "Tool(RotateTool)\n", "Tool(ScaleTool)\n", "Tool(ScaleTool)\n", "Tool(ScaleTool)\n", "Tool(MeasureTool)\n", "Tool(MeasureTool)\n", "Tool(ProtractorTool)\n", "Tool(SelectionTool)\n", "Tool(SelectionTool)\n", "Tool(3DTextTool)\n", "Tool(TextTool)\n", "Tool(DimensionTool)\n", "Tool(OffsetTool)\n", "Tool(OffsetTool)\n", "Tool(ExtrudeTool)\n", "Tool(ExtrudeTool)\n", "Tool(PushPullTool)\n", "Tool(FreehandTool)\n", "Tool(ArcTool)\n", "Tool(SketchTool)\n", "Tool(SketchTool)\n", "Tool(EraseTool)\n", "Tool(RubyTool)\n", "Start(Change Axes)Commit(17)\n", "Start(Close)Commit(16)\n", "Start(Macro)Tool(SelectionTool)\n", "Tool(RubyTool)\n", "Tool(SelectionTool)\n", "Start(Macro)Tool(SelectionTool)\n", "Start(Change Axes)Commit(13)\n", "Start(Open)Commit(12)\n", "Start(Change Axes)Commit(11)\n", "Start(Open)Commit(10)\n", "Start(Change Axes)Commit(9)\n", "Start(Open)Commit(8)\n", "Tool(SelectionTool)\n", "Start(Macro)Tool(SelectionTool)\n", "Start(Change Axes)Commit(6)\n", "Start(Close)Commit(5)\n", "Start(Change Axes)Commit(4)\n", "Start(Open)Commit(3)\n", "Tool(SelectionTool)\n", "Tool(RubyTool)\n", "Start(Macro)Tool(CameraOrbitTool)\n", "Start(Macro)Tool(RubyTool)\n", "Tool(RubyTool)\n", "Tool(PaintTool)\n", "Tool(PaintTool)\n", "Tool(NorthTool)\n", "Tool(NorthTool)\n", "Tool(NorthTool)\n"]
> l=IO.readlines("./tmp/SketchUpUndo0.log", "r") 
 
 l[1..-1].each {|element| element.chomp!("File Save\n") }

 l_a = l[1..-1].dup

 l_b = l_a.dup.reverse 
["cleTool)\nTool(RectangleTool)\nTool(RectangleTool)\nTool(PaintTool)\n", "cleTool)\nTool(Cir", "eTool)\nTool(ScaleTool)\nTool(ScaleTool)\nTool(ScaleTool)\nTool(RotateTool)\nTool(RotateTool)\nTool(MoveTool)\nTool(MoveTool)\nTool(MoveTool)\nTool(PolyTool)\nTool(PolyTool)\nTool(PolyTool)\nTool(Cir", "eTool)\nTool(Measur", "Tool)\nTool(Measur", "actor", "otr", "udeTool)\nTool(OffsetTool)\nTool(OffsetTool)\nTool(DimensionTool)\nTool(TextTool)\nTool(3DTextTool)\nTool(SelectionTool)\nTool(SelectionTool)\nTool(Pr", "udeTool)\nTool(Extr", "eehandTool)\nTool(PushPullTool)\nTool(Extr", "cTool)\nTool(Fr", "aseTool)\nTool(SketchTool)\nTool(SketchTool)\nTool(Ar", "t(Change Axes)Commit(17)\nTool(RubyTool)\nTool(Er", "t(Close)Commit(16)\nStar", "o)Tool(SelectionTool)\nStar", "t(Macr", "o)Tool(SelectionTool)\nTool(SelectionTool)\nTool(RubyTool)\nStar", "t(Macr", "t(Change Axes)Commit(13)\nStar", "t(Open)Commit(12)\nStar", "t(Change Axes)Commit(11)\nStar", "t(Open)Commit(10)\nStar", "t(Change Axes)Commit(9)\nStar", "t(Open)Commit(8)\nStar", "o)Tool(SelectionTool)\nTool(SelectionTool)\nStar", "t(Macr", "t(Change Axes)Commit(6)\nStar", "t(Close)Commit(5)\nStar", "t(Change Axes)Commit(4)\nStar", "t(Open)Commit(3)\nStar", "bitTool)\nTool(RubyTool)\nTool(SelectionTool)\nStar", "aOr", "o)Tool(Camer", "t(Macr", "o)Tool(RubyTool)\nStar", "t(Macr", "thTool)\nTool(PaintTool)\nTool(PaintTool)\nTool(RubyTool)\nStar", "thTool)\nTool(Nor", "thTool)\nTool(Nor"]

thomthom

http://code.google.com/apis/sketchup/docs/ourdoc/toolsobserver.html

@unknownuser said:

BUG: In SketchUp 6 and SketchUp 7.0, tool names on the Mac have some of their first characters truncated. For instance, on Windows, a tool is "CameraOrbit". On the Mac, is comes across as "raOrbit". Therefore, use the tool_id to keep track of which tool you need to watch for, or use logic that corrects for the error. There is an example method of one way to do this shown below. (This example is not a comprehensive list of the tool names.)

Dan Rathbun

As I recall, Scott told me that in v8, this issue was only HALF fixed.

One of the these was fixed, but the other was not. Can't remember which.

ToolsObserver : the tool_name argument in the callback methods.

Tools.active_tool_name() return string.

driven

hi Thomas/Dan,

The bug is appears to be gone in v8, I just noticed that the "r" added odd formating that broke up the strings.

I'm looking for the most efficient way of not using observers to get the information 'per model'

By reading the log, I'm trying to push the info to a 'per model' cache, and gather tool 'use' statistics.

I'm trying to then write this back to either an add_note or a web Dialog on demand, primarily as an exercise.

The cache itself is storing Time.now strings, but I'm struggling lots updating the 'data' files.

If cache files static 'per model_unique_Id' exists, I want to push only updated content, else create a new unique file with the full content.

john

Dan Rathbun

@driven said:

I'm looking for the most efficient way of not using observers to get the information 'per model'

Reading and writing to a file, is bound to be much slower than accessing memory (especially if the tool is also doing file access of some kind,) unless you are actually accessing a virtual (memory) disk.

I'd think an observer is easier. (Ruby has an extended Observer class of it's own, that you might be able to use to write your own observer, where the API's C++ observers don't give you what you need.)

BTW, on the PC at least, the ToolsObserver only reports correct tool_id and tool_name for Sketchup's native C++ tools. For custom Ruby tools, active_tool_name is always "RubyTool", and active_tool_id is always the same integer, something around or slightly more than 50,000. (Yesterday it was giving me 50006 for any custom tool I activated.)
We have asked many times to have this fixed. It will need to have a UI::Tool protoclass, so all tools have methods that return their name and id. (Currently the observer does not appear to even attempt to call these methods in a custom tool object.)
I played a bit with a base UI::Tool protoclass in the SKX forum, but it is not how it will be.. (I see a few things that I'd need to revise, since currently custom tools don't get an id. I would just have the tool_id() method return self.object_id, which means they will change each time Ruby is loaded. But take a look if your interested, but keep in mind it still needs a lot of work.)

driven

The problem, I perceive, with the observers is they are 'per model' so will need to always turned on for all models, and you end up with app observers to watching model observers, like in Jim's 'super' observer.

I thought as I'm writing to file anyway, and SU has already collected what I want, why not just use that.

Do you think that's likely to have a greater impact on performance?

thomthom

@driven said:

Do you think that's likely to have a greater impact on performance?

Test it.

I also suspect that Observers will be faster. But to be sure - it must be tested.

Dan Rathbun

You can create a cache in memory using an array of hashes, that can have values that are arrays or hashes themselves. That should be much faster. Then write to file only once at the end of the session.

Why will the user want to see tool usage data displayed on the screen ?

thomthom

@dan rathbun said:

Why will the user want to see tool usage data displayed on the screen ?

Rich and TIG recently made a plugin that displayed what tool was activated in order to aid video tutorials. Guessing this would fall into similar use.

driven

@dan rathbun said:

Why will the user want to see tool usage data displayed on the screen ?

One idea I'm working is tracking how my 8yr old makes a model, without 'interfering' [which is how she perceives me watching].

If she's following a tutorial and it goes pear shaped, we can look at the tool steps that don't match... only standard tools.

I often read the SU log, but it gets cleared if you change models or restart, so is only good for single model sessions.
john

Dan Rathbun

@dan rathbun said:

For custom Ruby tools, active_tool_name is always "RubyTool", and active_tool_id is always the same integer, something around or slightly more than 50,000. (Yesterday it was giving me 50006 for any custom tool I activated.)

Actually just tested this again... (because something seemed weird, as I was sure in the past that I had gotten different tool ids for custom tools.)

And what is happening is that unique tool ids DO get assigned (it seems,) if the tool is associated with a UI::Command object. Then in this case the tool_id is actually the command id. How this happens, I have not yet figured out.