[Plugin] bim-tools 0.13.4(june 22, 2015)

[driven]

@brewsky said:

For the temp file, would it be a good idea to only check the OS using something like:
tempdir = ENV["TMPDIR"] # MAC
[/code]

I know a lot of PC coders think this is the best and easiest place to write temp file to, but it returns
/var/folders/lN/lNON23AjHxezeYON7yETPU+++TI/-Tmp-/ and is only cleared on a after a FULL shutdown and StartUp.
the other is "/tmp", which clears after a restart [i.e. all most mac users ever do, and with a lack of crashes...]

It's actually one of OSX's shortcut's to "./private/tmp" and you often see ENV["TMPDIR" || "/tmp"] used outside of SU.

john

[brewsky]

@thomthom said:

Note the pattern that you don't need if else structure to pick between a set of variables that might be nil.

Yeah I figured that out from your example webdialogpatch file! There still is a lot of smooth looking rubyishness to learn

[brewsky]

@driven said:

I know a lot of PC coders think this is the best and easiest place to write temp file to

so would you suggest something like this? (don't know how to shorten this)

if ENV["TMPDIR"] != nil
  tempdir = "/tmp" # MAC
else
  tempdir = ENV["TEMP"] # PC
end

btw /tmp sounds very logical, I would use that on linux too...

[brewsky]

This is what I have now, seems to work OK on windows. Do you see any problems for mac?

def initialize(bt_lib)
	
	# Create WebDialog instance
	@dialog = UI;;WebDialog.new
	
	pathname = File.expand_path( File.dirname(__FILE__) )
	@walls = File.dirname(__FILE__) + "/parts/wall.rb"
	@exporter = File.join( pathname, 'IFCexporter.rb' )
	@imagepath = File.dirname(__FILE__) + "/images/"
	@bt_lib = bt_lib
	
	# replacement of set_html by a temporary html-file because of security restrictions in safari
	tmpDir = File.expand_path( ENV['TMP'] || ENV['TEMP'] || ENV['TMPDIR'] || "/tmp" )
	tmpPath = tmpDir + 'btDialog.html'
	tmpFile=(File.open(tmpPath, 'w+'))
	tmpFile.rewind
	tmpFile.puts html
	tmpFile.rewind   
		
	self.walls()
	self.project_data()
	self.export()
		
	@dialog.show
	@dialog.set_file(tmpPath)
	
end

[thomthom]

You're not closing the temp file. Use a block to open it so it automatically closes.

Is the rewind really needed?

[driven]

I'll try it...

to go into the Dir you need a [ / ] tmpPath = tmpDir + '**%(#BF0000)[/]**btDialog.html'
otherwise it just joins the names, is created beside the directory and won't get cleared.

It take twos clicks to create and open, i.e. click in plugins once shows nothing, click again and WD opens, just using "/tmp" is instantaneous.

you really need .show_modal on a mac... unless you write some visibility observer. [some scripts have that]

I had also added a tm=echo $RANDOM`` to create a unique name.
Can be done with ruby and Time.now variant. [TT does that]
but you also lost the file deletion at the start, so not sure if refreshing will work.

@TT I found, with other tests that the rewind was needed unless you close and use IO to read the content.
the file was being read from EOF which of course is empty.
The first one is probably redundant on a new file, but for over-writing I read it was quicker.

At the moment, I'm just looking at the basic WebDialog, but if I select a shape and click Create I get

Error; #<ArgumentError; Duplicate points in array>
/Library/Application Support/Google SketchUp 8/SketchUp/Plugins/bim-tools/parts/wall.rb;165;in `add_face'
/Library/Application Support/Google SketchUp 8/SketchUp/Plugins/bim-tools/parts/wall.rb;165;in `geometry'
/Library/Application Support/Google SketchUp 8/SketchUp/Plugins/bim-tools/parts/wall.rb;49;in `initialize'
/Library/Application Support/Google SketchUp 8/SketchUp/Plugins/bim-tools/parts/wall.rb;28;in `new'
/Library/Application Support/Google SketchUp 8/SketchUp/Plugins/bim-tools/parts/wall.rb;28;in `walls_from_selection'
/Library/Application Support/Google SketchUp 8/SketchUp/Plugins/bim-tools/parts/wall.rb;26;in `each'
/Library/Application Support/Google SketchUp 8/SketchUp/Plugins/bim-tools/parts/wall.rb;26;in `walls_from_selection'
/Library/Application Support/Google SketchUp 8/SketchUp/Plugins/bim-tools/bt_dialog.rb;107;in `walls'

john

[Pixero]

Just found some time to test it.
I like the workflow.
Here are some questions:
I found that copying a BIM tools entity or even the source geometry doesn't copy its BIM features. Will this work in the future?
Is there a way of setting defaults to the BIM tools like for example a offset of zero?

Looking forward to see things like windows/door openings.
I also hope that we soon will be able to have (at least a basic) export to Revit to start testing how it works in a real project. As it is now it's just something to play with.
Please don't wait with the exporter until all features are done.

[brewsky]

@driven said:

otherwise it just joins the names, is created beside the directory and won't get cleared.

Hmmm, I have been too quick in thinking it worked, I also stripped out all parts(like the delete temp file) that gave an error on my pc...

What I have done now is just use TT's patched webdiaog class and changed a single line so it might use the /tmp folder as you suggested. Line 27 now reads:
tempdir = File.expand_path( ENV['TMP'] || ENV['TEMP'] || ENV['TMPDIR'] || "/tmp" )

And this is the current bt_dialog code:

def initialize(bt_lib)
	
	# Create WebDialog instance, patched for OSX
	require 'bim-tools/lib/WebdialogPatch.rb'
	@dialog = WebDialogPatch.new
	
	pathname = File.expand_path( File.dirname(__FILE__) )
	@walls = File.dirname(__FILE__) + "/parts/wall.rb"
	@exporter = File.join( pathname, 'IFCexporter.rb' )
	@imagepath = File.dirname(__FILE__) + "/images/"
	@bt_lib = bt_lib
	@dialog.set_html( html ) 
	
	self.walls()
	self.project_data()
	self.export()
	
	@dialog.show
	
end

@driven said:

At the moment, I'm just looking at the basic WebDialog

I don't understand where all these geometry errors come from, nothing like that here

When the webdialog is fixed, I would really appreciate it if you could also try the new 0.10a version on your MAC. I think it's best to fix these kind of errors in the latest version because everything geometry-related has changed drastically.

Thanks again for all the help!

[brewsky]

@pixero said:

Just found some time to test it.

Thanks for trying it!

@pixero said:

I like the workflow.

Thanks! I try to stay as close as possible to the normal SketchUp workflow(that i like so much )

@pixero said:

Here are some questions:
I found that copying a BIM tools entity or even the source geometry doesn't copy its BIM features. Will this work in the future?

Yes, surely! What i have now is a basic framework, and when I get rid of some more bugs i think it's ready for expanding functionality!

@pixero said:

Is there a way of setting defaults to the BIM tools like for example a offset of zero?

For the "old" 0.9 version I had a config file for setting default values, I will also add this to the new version.

@pixero said:

Looking forward to see things like windows/door openings.

Me too! That will be the next step, after upgrading the IFC-exporter. Openings also worked pretty well in the 0.9 version, based on standard "cutting components".

@pixero said:

I also hope that we soon will be able to have (at least a basic) export to Revit to start testing how it works in a real project. As it is now it's just something to play with.
Please don't wait with the exporter until all features are done.

That's also what I'm trying to do to get the best results. I don't want to make too many features at the same time. Just small steps, and every new function first needs IFC export before starting on the next...

[driven]

@brewsky said:

I would really appreciate it if you could also try the new 0.10a version on your MAC.

where, exactly [i.e. a direct link] do I get 0.10a, I've been to your site a few times and keep getting the other??

probably just being dim...

Also, I want to explain the basic difference between .show an .show_modal on mac.

with .show when you click off the dialog it disappears behind the active window. The only way to retrieve it is to have code that brings it back after an action ends [only works if your still in the same tool] or move the window out of the way to click it back to 'front'.

with .show_modal the window stays in front [while in 'SU' context], so you can see it while you do other things in the tool or even if you change tools. The 'downside is it requires a click to 'bring to focus' and a second click to 'do', unless you 'Cmd Click' which bypasses the focus requirement.

If a tool 'highjacks' SU and blocks changing tools etc. [as this does currently, but I hope will be fixed], it is possible to to use !visable? then .show after each action, but show_modal is easier.

The main point I'd like to make is there is no problem having platform conditional methods in a cross platform script.

SU does it all the time, after all mac SU is Cocoa, a different version of Ruby, and different browser engine, so using specific mac code is the right way to do mac things... maybe, my code wasn't wrapped properly to hide the system calls from PC's but that shouldn't be to hard [says the ruby nuubee]

post a link and I'll try and do some more testing later
john

[brewsky]

@driven said:

where, exactly [i.e. a direct link] do I get 0.10a

I'm sorry! I could have known it would get lost in the thread... I posted it somewhere halfway the discussion because it's only a bit of an unstable preview. This is the link to the post:
[url]http://forums.sketchucation.com/viewtopic.php?
f=323&t=34007&sid=a1cea85c17015237152249205e1c68d2&start=45#p387104[/url]

@driven said:

The main point I'd like to make is there is no problem having platform conditional methods in a cross platform script.
I think I had the wrong idea about the SketchUp API, it's documented as a single cross-platform API, but in reality the same method seems to have a different result calling it on PC or MAC. If the result differs, it might be better to also name them differently?
I guess, when this is the case for more API calls, then conditional methods is indeed the way to go, especially
for this show / show_modal case(I got an empty window using modal on PC)

@driven said:

maybe, my code wasn't wrapped properly to hide the system calls from PC's but that shouldn't be to hard [says the ruby nuubee]
I really appreciate your help fixing the code for Mac. The reason I picked TT's custom web dialog class is because I can easily copy that to the other version of my plugin.
I want it to work as good as possible for Mac and PC. Wouldn't it be best to further optimise TT's class together so everyone can use it for their projects? Like add the /tmp folder and maybe the rewind option you used?

[Dan Rathbun]

You cannot get away from platform specific quirks (oddities, etc.) As John said, Mac uses the obsolete Ruby v1.8.5-p0, and Safari for webdialogs. PC uses Ruby v1.8.6-p287, and MSIE WebBrowser.

The first step is to be sure these global boolean constants are defined:

MAC = ( Object;;RUBY_PLATFORM =~ /(darwin)/i ? true ; false )
OSX = MAC unless defined?(OSX)
WIN = ( not MAC ) unless defined?(WIN)
PC = WIN unless defined?(PC)

Using boolean constants is MUCH faster that using string platform name constants !!

On the Mac, "modal" translates to "always on top", but does NOT cause App blocking, like it does on PC.
Then in your code:

MAC ? dlg.show_modal() ; dlg.show()

or

if WIN
  show()
else
  show_modal()
end

Also.. Ruby is a dynamic language. It can be defined and configured at runtime. Some coders prefer to have Mac definitions and PC definitions in separate files. (A SINGLE module or class definition, can span MULTIPLE files. They do NOT need to be in ONE file.)

module BIMTOOLS

  require('bimtools/lib/mac_methods.rb') if MAC
  require('bimtools/lib/win_methods.rb') if WIN

  # ... more code here that relys upon methods loaded
  # into THIS module by one of the two files above.

end

... BUT some prefer to DYNAMICALLY define platform specific methods in the same file (they think it may be easier to maintain.) Ex:

module BIMTOOLS

  # define a "info" module function here;
  #
  if MAC
    def self.info()
      #
      # ... code specific the Mac/OSX platform
      #
    end
  elsif WIN
    def self.info()
      #
      # ... code specific the Windows platform
      #
    end
  else
    # perhaps raise an exception here ?
  end

    # ... more code here that relys upon
    #  methods defined per platform above.

end

The advantage to dynamically defining methods that are platform specific.. is runtime speed. They will not be slowed down by any further platform conditional evaluations, because they are evaluated only at loadtime. (And a Mac will not magically morph into a PC, in mid-session.)

[Dan Rathbun]

Also in the [ Code Snippets ] sticky thread, I am endevouring to collect links on Platform Specific Quirks and Issues.

see: [Info] Platform Issues / Differences / Specifics

[thomthom]

Some notes on WebDialog and the differences between platforms: http://forums.sketchucation.com/viewtopic.php?f=180&t=23445

[Pixero]

I tried the export to IFC in v 0.9.2 and export worked fine and looked right with the FZK Viewer but when trying to import into Revit 2012 I got these errors: http://dl.dropbox.com/u/7990360/Bimtest01_Error%20Report.html

[brewsky]

@pixero said:

I tried the export to IFC in v 0.9.2 and export worked fine and looked right with the FZK Viewer but when trying to import into Revit 2012 I got these errors: http://dl.dropbox.com/u/7990360/Bimtest01_Error%20Report.html

Thanks for trying and reporting back! I have had success importing the IFC's into ArchiCAD and Arkey(dutch CAD software we use at work) but I also got an error importing into bimserver.org. I haven't got around to further look into it. Can you also send me the IFC file? The errors revit reports only point to a row number, it does not explain on what kind of element it fails.

For the entire IFC export I still don know what's the best way to go, at the moment I see 3 possibilities:

• build the IFC translator myself(that's what I have done until now, but a huge amount of work to ever get full export AND import.
• use the TNO IFCengine dll( should work very well, I believe they have a MAC version as well, is free to use, but is not open source )
• use/contribute to [url]ifcopenshell.org[/url](I would like that best on the long term, but it is a work in progress itself)
  I think for the moment I will add some more functionality(and fixes ) to my existing exporter, as long as there are only walls and windows and the like, I think that is quickest.

Anyone some more tips on this matter?

[brewsky]

@dan rathbun said:

You cannot get away from platform specific quirks (oddities, etc.)

@dan rathbun said:

The advantage to dynamically defining methods that are platform specific.. is runtime speed. They will not be slowed down by any further platform conditional evaluations, because they are evaluated only at loadtime. (And a Mac will not magically morph into a PC, in mid-session.)

It seems like a good idea to me to start a side-project to catch and streamline all these platform specific quirks.
Like you say, create a general module that dynamically serves you the right methods based on the current platform. Set up a bit like Thomthom's webdialogpatch-class.

module CROSSPLATFORM
  class CpWebDialog < WebDialog
    def show()
      if MAC
        show_modal()
      elsif WIN
        # this is not correct because it points to itself
        # but I hope you get what I mean...
        show() 
      end
    end
  end
end

# call something like
dialog = CROSSPLATFORM;;CpWebDialog.new

# call show the same way on MAC and PC
dialog.show

So all everyone has to do in your plugin-code is point to the "CROSSPLATFORM" module for these kinds of "quirky" API-calls.

It can imagine it's way too much overhead to include all these for every small plugin, but maybe make it "pluggable" by just adding a separate .rb for all used functions to a "crossplatform"-subfolder and dynamically require all ruby files present in this folder...

But still beeing a bit of a newbie, I probably miss a thing or two

[driven]

Hi,

identifying the differences is the biggest hurdle. Most rubies need little or no 'fettling'.

I've got this working to the extent of mimicking your 'youTube' clip, plus the minimise button which took forever to get hold of.... It was only after I noticed it's missing from your demo....

Two big issues for me. why are you using 1999 XHTML? it's 2012...
#Note that XHTML 1.0 previously defined that documents adhering to the compatibility guidelines were allowed to be served as text/html, but HTML 5 now defines that such documents are HTML, not XHTML.
Safari was having troubles with this so I changed it to
%(#008040)[<!DOCTYPE html>
<head>
<meta charset=utf-8' />
<title>BIM-Tools - webdialog</title>
<link href='" + @pathname + "/bt_dialog.css' rel='stylesheet' type='text/css' />
</head>
<body>]
, which works for what you have so far...
Personally I think it should all be html 5 first, then add conditionals for older IE when it that all works.

the other was you have two different image paths, niether was relative to the 'temp' html to I move it

@tm=(rand(9999).to_s.strip)
		@tmpPath=(@pathname + '/btDialog_' + @tm + '.html')

into the ui folder (which is as fast as '/tmp' to create, but harder to delete...), then I put a second copy of image folder in there as well. So I've got the background image, minus the js...

john

[thomthom]

@driven said:

Two big issues for me. why are you using 1999 XHTML? it's 2012...

Two words: Internet Explorer

Only the very latest, IE9, support some HTML5. To support IE8 and IE7 will still some people use (heck, some even use IE6!!!) one need to use the good ol' fashioned HTML4 or XHTML1.0.

@driven said:

Personally I think it should all be html 5 first, then add conditionals for older IE when it that all works.

No point then, if the content is the same - if you're not using any of the HTML5 features.

Mind you, I'm very tempted in dropping support for IE older than version 9 in my future plugins. Damn-it people, the upgrade is free! <rant/>

[Jim]

IE 9 does not run on Windows XP, which is still the world's most-used OS; although Win 7 is catching up.