Posts made by slbaumgartner

slbaumgartner

@slbaumgartner said:

Move the script from the onLoad event to the last element in the body. This is a much discussed and criticized aspect of the WebDialog startup on the Mac.

I am sorry but I don't know what you mean by last element in body.

Can you provide an example:

<html>
>   <head>
>   </head>
>   <body onLoad="startup();">
>   </body>
> </html>
> 
> <script>
>   function startup() {
>     nextFrame();
>   }
> </script>

Thanks in advance

Remove the onLoad from <body> and then move the <script> … </script> up as the last element before </body>. You will also need either to invoke the startup() function you have defined after the } or else just call nextFrame(); without the function (if you don't also need it elsewhere). The script will be run as the last step of loading the body on both Windows and Mac.

slbaumgartner

@renderiza said:

Hi,

I received this suggestion to fix my "Rename by Layer" plugin but I am not sure how to solve it. Can someone help me figure this out? I have no mac so its hard to work bugs for them.

@unknownuser said:

In RND_Renamer/rnd_renamer.html:

Comment on line 8:
<body onLoad="startup(), stopwatch(this.value);">
Using BODY onLoad will cause a blank WebDialog windows under OSX when it opens. The content appear after right clicking or resizing. To work around this, move the functions calls from this event to a SCRIPT element at the bottom of the page, or use the DOMContentLoaded event. (Though this need more work for cross browser compatibility unless you use a framework like jQuery.)

Not sure how to solve it.

Move the script from the onLoad event to the last element in the body. This is a much discussed and criticized aspect of the WebDialog startup on the Mac.

slbaumgartner

@unknownuser said:

@chedda & slbaumgartner

i think this post is referring to another problem which has popped up for some users.. that is, they're talking about all toolbars are exhibiting this problem-- not just the top toolbar.. so instead of needing to open a new window in order for the icons to appear, they have to go View->Tool Palettes and turn them on one-by-one (since you can't turn on/off multiple toolbars at once).

here's another thread which discusses it:
http://sketchucation.com/forums/viewtopic.php?f=11&t=188

(sort of a lot to wade through there as i also thought the post was originally about the top toolbar problem.. but it's something else going on as well)

Ah! No doubt you are correct. But I bet the cause is related…different sequence of startup processing than on windows.

slbaumgartner

@chedda said:

Yes this is a royal pain in the ass. I always launch sketchup, close window and then open new. In mac talk that's cmd w & cmd n. If you want to open a specific file it will work the same way cmd o and navigate to it. Or just simply double click it when the app is running. There is no need to keep adding tools to the toolbar. This should have been fixed in the last update it's a no brainer.

I do the same and yes, it is a pain.

This problem has been present in SU on the Mac for a long time. Despite prior complaints here on sketchUcation, the programmers have not done anything about it. My best guess is that the initial window opens automatically before the Ruby plugins are loaded, which makes it impossible to put those tools on the initial toolbar.

slbaumgartner

@renderiza said:

How can I remove the first four letters of a string?

Here is a test that is giving me strange result...

a = "hello there"
a[1] #=> "101"

I was expecting this...

a = "hello there"
a[1] #=> "e"

What I am doing wrong?

a[1] returns the character in the second position of the string, and in the version of Ruby embedded in SketchUp a character is displayed as its numeric value, not its ASCII representation. You can use a[1].chr to get a string containing the ASCII.

In your second example, a[1,1] is a length 1 slice from the string, which is also a string (not a character) so it displays as a string.

slbaumgartner

@db11 said:

Hoping to finally be able to spring for SU Pro sometime this fall and I have a few questions:

For those users that have experience with SU Pro 2013 on both platforms, which is preferred and why?

For Mac users running SU for Windows under BootCamp or Parallels, what has your experience been?

How well does SU 2013 [Windows] run under BootCamp?

Is Parallels a better/worse option?

Is there a big hit in performance running under a the Parallels virtual machine?

Is BootCamp the better option for that reason?

Would you recommend simply staying Mac all-round, or is it worth it to manage the windows version on a mac? (I'm not about to switch to a windows machine, but I am considering running SU [Windows] for broader plug-in compatibility and better materials management.)

Do I need a separate license for Windows and Mac versions if they are both installed on the same machine?

Thanks for your input.

[ThomThom: hoping you see this, since I understand you've recently added a Mac to your arsenal for testing purposes. I would be especially interested to hear your take to date]

I have a MBP Retina with Windows 7 running under Parallels. I run either SU 8 Free or 2013 Make, but I don't think the differences with Pro affect my comments. On the whole, they are both serviceable - with slight reservations.

In a nutshell, neither version copes completely well with the Retina display. In native Mac mode, the inference engine points are so small they can be hard to see. The interface for textures and materials is more confusing than on Windows. Plus I agree with Dave R that I prefer the Windows dockable toolbars and other auxiliary windows vs the Mac ones that chronically either pop over things or slide off the side of the screen. Under Windows/Parallels, there are occasional glitches when one or another item tries to run in pixels instead of screen points and is either tiny (certain dialogs) or places things half as far out as the cursor would suggest (e.g. customizing the toolbar). Since both have issues, your choice ends up being based on which kind of glitches bother you the most.

Steve

slbaumgartner

@ttype said:

I have drawn a table and I'd really like to hear what you think about it. Especially about the way it is assembled and from someone who has already built some tables in a real shop in a real life.

The idea in general was to create a solid table where I like the bottom side of the top more than I usually do. And well, I like it, but I am really not sure whether I am simply too optimistic as far as the laws of nature/wood and the solid thing are concerned.

[attachment=1:3c385125]Wellassorted.png[/attachment:3c385125]

Hi,

I have made quite a few tables, including ones with breadboard ends (which is effectively what you have designed). There are some problems with making your design from wood.

The biggest problem, as Dave R has noted, is that you have to allow for seasonal movement between the width of the top pieces and the length of the end caps. Typically wood will change width by about 1% through the course of the year. This movement poses problems for your design.

If you try to glue the top boards of your design to the end cap + leg assemblies, either the top will split or the joint will tear apart. So, if you can't glue the joint between the top boards and end caps, the only thing holding the end caps onto your top is the notches in the blue boards! If the table gets an endwise shove while carrying weight, the leg assemblies will fold under and the table will collapse! Also, those notches are themselves a problem, because there is no space for the two tan boards between the blue ones to expand.

Here are some ideas: If you can stand the look, you could add apron boards lengthwise between the legs. These would both keep the ends together and would provide greater resistance to wracking. As an alternative, you might bolt the ends onto the top (using elongated holes to allow for movement). You could countersink and plug the ends of the bolt holes to conceal them (though then you can't tighten them if things work loose).

As a picky point, how were you planning to install the lock pins in the tenons that join the legs to the end boards? The holes don't reach either face, so there is nowhere to drive them in! Also, there are some spurious blocks inside the joints that don't have notches in the corresponding top boards.

Steve

slbaumgartner

@s_k_e_t_c_h_y said:

Hmm,
I'm not sure I do that? Here is a cut-down version of what I'm doing. Hopefully I'm not breaking too many good practice rules, but please let me know.

Basically I have a lot of class variables (all the @@xyz) which have defaults, but get overridden after the HTML configure() has been ran. When configure() is complete is calls draw() then statistics() to implement the customized design in SketchUp. I use blocking threads to initialize these so that the configure has been finished().

All of my shapes from draw() get pushed into @@geodesic which is a group so that all sub-shapes from the draw are bound together at the end.

Insight appreciated...

# Add a menu item to launch our plug-in.
> UI.menu("PlugIns").add_item("Draw Geodesic") {
>   
>   #Instantiate and configure the Geodesic
>   geo = Geodesic.new
>   geo.configure()  
> }
> 
> class Geodesic
> 	#Main Configuration items
> 	@@g_frequency = 3
> 	@@g_radius = 150
> 	@@g_platonic_solid = 20
> 	@@g_fraction = 0.6
> 	@@g_center = Geom;;Point3d.new ([0, 0, -@@g_radius + 2 * @@g_radius * @@g_fraction])
> 	
> 	@@draw_primitive_solid_faces = 0
> 	@@primitive_face_material = [rand(255), rand(255), rand(255)]
> 
> 	@@draw_tesselated_faces = 0
> 	@@tesselated_face_material = [rand(255), rand(255), rand(255)]
> 	
> 	#Metal hub configuration
> 	@@draw_metal_hubs = 1
> 	@@metal_hub_outer_radius = 2.25
> 	@@metal_hub_outer_thickness = 0.25
> 	@@metal_hub_depth_depth = 4
> 
> 	#Wood strut configuration
> 	@@draw_wood_struts = 1
> 	@@wood_strut_dist_from_hub = 3
> 	@@wood_strut_thickness = 1.5
> 	@@wood_strut_depth = 3.5
> 	@@wood_strut_material = Sketchup;;Color.new(255,215,0)
> 
> 	#Wood frame configuration
> 	@@draw_wood_frame = 1
> 	@@frame_separation = 12
> 	
> 	#Dome reference data is stored in these arrays
> 	@@geodesic = Sketchup.active_model.entities.add_group		#Main object everything contributes to
> 	@@primitive_points = []
> 	@@strut_points = []
> 	@@triangle_points = []
> 	
> 	#Dome shape data is stored in these arrays
> 	@@strut_hubs = []
> 	@@struts = []
> 	@@frame_struts = []
> 
> 	
> 	#tolerance factor to circumvent small number errors
> 	@@g_tolerance = 0.5
> 	
> 	#HTML pop-up menu to configure and create the Geodesic Dome
> 	def configure
>            # ... code ...
>         end
> 
> 	def draw
>            # ... code ...
>         end
> 
> 	def statistics
>            # ... code ...
>         end
> 
>         private
> 
>         #lots of support functions here
> 
>

SIncerely, Paul.

Presumably you build your data in the various arrays @@primitive_points, @@strut_points, @@triangle_points, @@strut_hubs, @@struts, @@frame_struts by appending elements to the arrays. Do you clear out these arrays at the start of configure or draw? If not, because they are class variables the values will continue to accumulate until you close and restart SketchUp.

slbaumgartner

@aarhus8000 said:

I'm still not receiving this update when I click 'Check Web for Update' in SketchUp Pro 2013.

It says I'm up-to-date and my version is 13.0.4123.

Anyone else experiencing this?

I'm sure I can go to sketchup.com and download the latest version but I would prefer if the auto-update worked.

Kristian

Same here. The auto update must not be ready yet.

slbaumgartner

@tt_su said:

So since DOMContentReady works, which triggers before body.onload, then it is very strange that body.onload cause this blank window. Which also means it's not the async nature of OSX's callbacks. Maybe DOM modifications during body.onload mistriggers some events within WebKit - the onload event triggers, but maybe DOM modifications interfere with the event that cause WebKit to redraw.

And given that it works under IE it appear to be an WebKit bug related to the onload event. Because there is nothing that should say, logically, that it shouldn't work. When events that triggers earlier works, then why would the late onload not trigger?

It could even be a WebKit issue only seen when used as WebDialog. Who knows.

I agree with your reasoning. onload is supposed to be called after the DOM is fully parsed and all page resources have been fetched. It make no sense that bodyLoad() would work in the DOMContentReady callback and then fail later in onload unless the problem is something specific to how the onload event is processed.

I did some browsing around in the WebKit source. It will take me some time to understand how events in general, and onload in particular, are handled. But I found comments in the change logs about special traps involving the onload event. If I understand, certain web pages do dirty things in their onload handlers that caused a crash when the DOM was rendered, so long ago WebKit added patches to avoid the crash.

I wondered if setting window.location.href in the onload handler would trigger one of these traps, so I tried an onload handler that set href to an http: URL. It worked fine - displayed the specified page instead of TestUp. That inclines me to agree with your final suggestion - it would seem to be some interaction between the implementation of the skp: protocol and the onload event processing.

Anyway, the bottom line is don't call Ruby from the onload handler!!

slbaumgartner

@driven said:

martin wrote about it ages ago

http://www.martinrinehart.com/models/rubies/ruby2javascript_javascript2ruby.html#gotchas

and with 'TestUp' it has never worked on mac, the moving bodyLoad() to the end, was a refinement when this didn't work...

    # This blurring forces an update so the mac displays TestUp
>     # immediately after loading its content.
>     if @is_mac
> 
>       @webdlg.show_modal
>       @webdlg.execute_script('window.focus()')
>     end
>   end

john

After re-reading Martin's blog and trying a few things, I noticed (on the Mac):

TestUp creates a WebDialog and saves it in @webdlg. It uses this instance variable in all its Ruby callbacks,
discarding the dialog argument passed back from javascript. For example:


      @webdlg.add_action_callback('gui_ready') do |dlg, param|
        gui_ready
      end

when the action_callback "guy_ready" is fired from javascript, it is relayed to the (no-argument) Ruby method of the same name, which uses @webdlg instead of the dlg argument. If Martin is correct, this will cause problems because the @webdlg obtained from the constructor is not yet fully wired to the page; one should always use the argument passed back in the action callback. He speculates that, in particular, the instance obtained from the constructor is not really ready to run when the onload fires. But once the page is loaded and running, actions initiated on it work fine against @webdlg. Also note that the developer console always uses the argument passed to its action callbacks, even though it retains the original dialog in an instance variable.

you get the white screen only if bodyLoad() is called from the onload event. If you don't call it at all, per TT's assertion you get the background images loaded via CSS - though for lack of bodyLoad() the right-hand part of the screen is empty. Finally, if you call bodyLoad() in an explicit script at the bottom of the body, all is well.

slbaumgartner

@bernardobaldissera said:

@unknownuser said:

which mouse do you have and did you install any accompanying software with it?

I have a Microsoft Mouse 3500. It has a software, Microsoft Intellipoint, but I can only set up generic commands to the central button. Even if I configure command + control as the function of the central button, it doesn't work out.

I have a Microsoft Mouse 3000, which I assume is similar to your 3500. In the Intellipoint software, I made these button assignments:

Left Button = Click
Right Button = Secondary Click
Wheel Button = Handled by Mac OS
Upper Button = Back (I don't use the upper button in SU, so this setting doesn't matter to me)

I also checked the Enable vertical scrolling button on the Scrolling tab.

With those settings my mouse works the same in SU as it does on Windows. The only issue is that Intellipoint does not start automatically after the Mac boots; I have to open the settings to get it going. There's no doubt a way to make it start on boot, but I'm too lazy to look it up.

Steve

slbaumgartner

@tt_su said:

The initial TestUp HTML isn't completely empty, it has the basic framework for the UI element - the CSS styles should have applied it's style to that.

Was the HTML changed? The version I downloaded last winter has this body (after moving bodyLoad()):


  <body>
    <a href="javascript&#058;;" id="btnRunTests" onclick="run();return false;">&nbsp;</a>
    <input id="runList" type="hidden" />
    <span id="headsUpDisplay"></span>
    <div id="divGui"></div>
    <script type="text/javascript">
      bodyLoad()
    </script>
  </body>

There's nothing visible there. Even the <a> is whitespace! CSS can't insert content into elements!

@tt_su said:

I think someone mentioned that it was working fine before, (and it does work fine under Windows), so I somewhat suspect there's some change in WebKit's onload event that cause some unexpected mistrigger - in terms of kicking in the redraw for the window - maybe some optimization gone wrong…

It never worked for me until I moved bodyLoad() per the above snippet. The difference in Windows is without doubt due to its different handling of skp: and synchronous javascript. The bodyLoad() callback will complete before return from the event handler. Has Apple distributed a new version of WebKit? I know there was an update to Safari, but the WebKit accessed by other apps is not the same as Safari.

@tt_su said:

If only we had a simple bare bone example, that would make it easier to compare. It's difficult with TestUp to change one thing and not break everything.

Agreed! TestUp is very complex, not a good sample to experiment with!

slbaumgartner

The requirement to run on a machine without a local installation of Ruby complicates the situation. Rubies generally assume that they are running on a standard installation. This means they expect all the standard distribution libraries, as well as their own suite, to be available where Ruby can find them. But SU ships with a bare-bones interpreter without any libraries. So, there is no way to avoid the fact that you will need to provide every file required (recursively) by anything you want to use. It might actually be easier to include a ruby distribution with your application, though that certainly does make a heavyweight plugin! You can manipulate $LOAD_PATH to cause SU's Ruby to find required files in non-default places.

slbaumgartner

@tt_su said:

That worked! Though I wonder why.

I've seen this on several other WebDialogs on the Mac as well. Here's my theory as to the reason (feel free to poke holes, I'd love to get to the bottom of this):

First of all, I believe this happens on TestUp but not on the developer console because TestUp's HTML is a blank page that just defines javascript functions and provides a divGui element for them to target. All of the visible content of the page is created by subsequent calls from SU Ruby to javascript functions on the page. In contrast, developer console's HTML creates and lays out all of its divs. Until SU Ruby runs, the TestUp page really is blank.

The reason you see the blank page is that WebKit interprets the onload event to mean that all parts of the page have been loaded and it is ready to display. WebKit does not expect the onload event callback function to load additional content to the page via something like skp: protocol (after all, what does "loaded" mean if the onload callback can load additional pages?). So when bodyLoad() returns immediately (due to the well-worn asynchronous aspect of javascript and the skp: protocol on Mac), WebKit displays the still-blank page before Ruby has had time to do anything with it. Evidently, WebKit does not subsequently notice that the Ruby calls generate new page elements, so it does not spontaneously do a repaint. The user has to do something such as right-click to cause a repaint, and then the new content shows. Perhaps there is a javascript function that could force a repaint at the conclusion of the Ruby?

When the bodyLoad() call is moved to an ordinary script at the bottom of the body, it seems that WebKit detects the invocation of an additional content load and pauses to let it happen before painting the page. The pause gives Ruby a chance to call the javascript that populates the page. This part of the theory still bothers me a bit, because of all the other cases in which WebKit not waiting for an skp: causes WebDialog bugs. Maybe the difference is that in this case the call is within the context of the initial page load? But then how does WebKit know that Ruby is finished and the page is ready to paint?
Thoughts?
Steve

slbaumgartner

@driven said:

Just found a BIG PROBLEM with the 'TIG' and new 'FREDO' path trick on my mac.

My User 'private' settings for 'BOTH' are now available to any account on my computer or connected to my network.

By stepping up stream, external to ENV["TMPDIR"] you are bypassing the LOCK to other user accounts and network traffic.

So my SFC Password Cookie and my Fredo settings are usable from any account, I do not expect a Plugin to share this type of information with the world.

Please move these back into User Space asap.

This could be a huge problem on a work or university network...

john

Confirm: the parent of ENV[TMPDIR] has permissions drwxr-xr-x on my Mac - that means it is readable by anyone, though only the owner (me) can write new files there. ENV[TMPDIR] itself is drwx------, which means it is inaccessible to anyone but me. This is not a big deal if you are the only user on your computer, but a serious issue if anyone else has access.

Steve

slbaumgartner

@thomthom said:

I used HTML5 Drag and Drop API for my installer utility: http://sketchucation.com/forums/viewtopic.php?t=51330

But I found that it didn't work under OSX because the WebDialog hides when the parent SketchUp window loses focus.

Yes, that is one of the frustrating aspects of OSX. When the app loses focus, its secondary windows all hide - they aren't merely invisible behind other windows, they actually cease to be displayed. If the app is set up for drag and drop, the main window and its secondary windows will pop back to the top when you drag onto the main window, at which point you can drag onto the secondary window. But, it does not appear that SU is set up for drag and drop, even as of 2013 - at least I can't get it to work.

Steve

slbaumgartner

@tig said:

BUT...
No one has still answered my question...
What is wrong with using the container folder for the ENV for the OS's user's 'Temp' folder?

One last try and then I will shut up. Your suggestion is what we used to call a "bad hack". It is a hack because it uses an unofficial trick to work around an issue. It is bad because it is only works today due to oversights and mistakes on the part of the OS developers. The fact that the parent directories of temp locations are writable is an oversight, not by intent. They simply never considered that programmers would do what you suggest, so they didn't bother to lock the gate or sweep the floor. They could decide to secure their house at any time, at which point this technique will fail. Do you really want your plugin users to plague you with support calls when Windows 9 or Mac OS X 10.9 changes the rules? Why not look for an OS-endorsed and stable technique rather than take this risk?

Steve

slbaumgartner

@tig said:

On a modern PC the user's Temp folder's 'container' is going to be C:/Users/User/AppData/Local/: or something slightly different on XP...
On a MAC it's a seemingly meaningless folder name that contains the user's temp folder [named ' T']: something like /var/folders/rp/b9k42l5x7xngx_8tckgs0zdr0000gn/
Both of these 'containers' are consistently made and are intended to be always be fully read/writable by the user and the user's applications - that is why they are there.
The Unix-like /tmp folder should never be needed, and it's not returned by ENV [my earlier illustrations of a hierarchy of temp folders had it in as a 'fall back' should all else failed]...

Other apps use the 'Local' folder to store their data in their own subfolders.
The differences between Local and Roaming were also spelled out in one of my earlier posts in this thread.

OK, so your notion is to find the user's temp folder and backtrack to its parent on the assumption that the parent is a stable, writable location.

I think you are half right: that folder will be writable. But the other half is why you are consternated by the weird path name synthesized by Mac OS X and also why this attack will fail.

Mac OS X uses its underlying UNIX library's temporary folder library, which was designed for the purposes I described. The odd folder name is a globally unique id that assures the temp files for this run of this app for this user won't collide with any other user or app's temp files. The paradigm is that an app requests a temporary file from the OS when it needs working space, gets a file handle in return, uses that file until completed, then closes the file. The app never needs to look at the full path to the temp file and has no assurance from the OS that the same folder will be used on another run or for a second temp file (after all, what if you start two instances of the same app at the same time? Do you want their working files to stomp on each other?). So, the problems arise from wanting to store persistent data using a facility that was designed for temporary data.

As already noted, Mac OS X expects that applications will put individual users' configuration data into "/Users/<userid>/Library/Application Support/<appname>/<subfolders as desired>", which is stable and is always writable by the userid. This is the nearest equivalent to Windows "C:\Users\User\AppData\Local<appname>". I don't know: is this folder entangled with magic redirection such as ThomThom described? On Mac OS X, ~/Library is hidden by default, but that's a Finder setting that has no effect on read/write access.

Steve

slbaumgartner

@tig said:

This discussion seems to go on and on and ignore the simplest of solutions.
Find the users 'Temp' folder [names vary with OS etc]...
I have previously outlined how to get this for MAC and PC.
This 'Temp' folder is useful for holding temporary data, it can be purged by the system, so permament data needs to reside elsewhere...
This 'Local/Temp' folder is in a 'folder tree'.
The folder containing the 'Temp' folder can be found using File.dirname(tempfolderpath).
That container folder can be used to make your own subfolder to hold your more permanent data.
That container folder has the same unrestricted rights for the User as the Temp folder itself.
It is intended to hold app-specific folders/data...
Just open the C:/Users/User/Local folder to see this...

What is the problem in doing it this way?
I have done it thus for a long time, without any issues whatsoever...

TIG - already answered. All of the tmp, temp, etc folders are meant for working files used while a program is running. No OS that I know of promises to keep such files around after the program exits. It may have been working for you, but that is only because the OS is lazy about cleaning up. This could change with any update. Also, most "disk cleanup" programs will erase the contents of these folders, so you are running risk of a user blowing away your data and then blaming you.

Steve