@tig said:

http://forums.sketchucation.com/viewtopic.php?p=345933#p345933
View-Parts >> a Scene tab per 'part'...

Err, yah, read that, got the plugin. As mentioned in those comments it simply doesn't work sensibly if you have components nested. And I don't mean it 'fails to make scenes for inner components' - I didn't expect it to do that. If you open a component with other components nested within, select one or more and use view-parts you gets load of empty scenes and your original scene is emptied of the chosen components as well.

Copying the component you want to work with doesn't improve things much either. It also doesn't play well with layers. Copying the component, moving it to Layer0 and exploding it at least appears to do something sensible, which is a start. I think the plugin needs to do a whole lot more than it currently does.

There's also the issue of what a duplicate component actually is; simply having the same definition name doesn't seem to mean much when some might be flipped - for the purposes of doing component drawings in LO that is not a duplicate because you will almost certainly want to have a separate drawing to make sure you get two pairs of table legs suitably mirrored and not four identical ones! Simple rotating or translating transforms do not matter here, but any sort of scaling would. Has anyone already written a snippet that does such a compare? I've noted comments about the actual transforms not being identical across copies of the same component so we would need to compare the actual transform values.

@unknownuser said:

I think the approach taken by viewports has a better chance of being useful, simply making a new scene where everything except the component is invisible seems like it must be as minimal as it gets. At least it doesn't have to disrupt the original drawing(s).

Sigh. Except of course there is the immense fun that the component/hidden rules cause when you have nested components. Since nested components seems like a really good idea in general it is quite important to handle them well. A pointer to a good explanation of those rules would be interesting.

ViewParts hides components and thus we can very easily end up with everything hidden, everywhere. I think that is probably not going to help make parts drawings in LO! Thus I guess we have to adopt some of the idea from Comp2Layer in building a layer for the chosen component(s) and making that layer invisible everywhere except in the scene(s) where we want it. The obvious question is whether it is more effective to

1. make a single layer, put copy of each component on it and then make a scene for each components where
   a) that layer is the only one visible
   b) all other components on the layer are made hidden.
2. or make a separate layer for each component and a separate seen for each.
   I can't recall seeing anything that might explain which is more efficient should the list of components get really big. Imagine the guy that does models of oil refineries choosing all the bolts and asking for component scenes for them!

Well, I've tried both suggested plugins from above and neither of them really do anything much like I'd hoped for.

By way of explanation -

• Viewparts actually functions as installed, which is good. What is bad is the way it seems to remove the selected components from your original page. They're not actually removed of course, just made hidden, seemingly as a side effect of the way the individual scenes are created. I suspect that should be simple to fix. I don't really like the 'extra' pages made with the whole selection and the 'initial' page. It might make some sense if you are only working in SU but I'm using LO and all we need is a page with each component. LO can handle the view orientation etc. I'm not at all sure about the whole 'excluding duplicate components' thing; why would you not want that? Is there any reason to have several pages of the same component created? Is there some SU thing I'm not aware of even after 7 years of use that makes it possible to have multiple copies of the 'same component' that are not actually the same? And the code; well I'm not a fan of Ruby's syntax or semantics to be honest, it's a very poor imitation of Smalltalk with lots of annoying cruft from C++ etc thrown in. I wish they'd used Smalltalk for a script language…
• Comp2Layer didn't actually appear to work at all initially. It seems to try to install a context menu only - no menubar item - and that simply wouldn't appear for me. I fudged it to add a menubar entry and was able to try it out. The context menu related code appeared to be similar to that which works in some other plugins, so no idea what was going wrongI didn't much like what it did; moving the selected component to a new layer is all very well but the damn new layer ought to be set to visible in the original page! If you select several components they all get moved to the same new layer which appears to be named by the first component in the selection. The copy of the component (only the first selected one) is added off some distance but within the same group/component that it came from, thus making for an odd selection box.
  I think the approach taken by viewports has a better chance of being useful, simply making a new scene where everything except the component is invisible seems like it must be as minimal as it gets. At least it doesn't have to disrupt the original drawing(s). I think I'll see if I can improve on the idea.
  I would be interested in any answers to my question about the duplicate components (above). I don't get that yet.

Thanks guys. I'l try both and see which one does it best for my purposes. In defence of my search-fu I'll just mention that comp2layer is not mentioned at all in the sticky list of plugins and view parts is only mentioned by title with no description whatsoever.

@unknownuser said:

after having to deal with iTunes for my daughter's iPod Touch I don't really like apple products but I am not counting the iPhone out yet.

You don't need iTunes to use an iPhone. You used to, long ago, but not now.

I can't spot any plugin that does this -

make a scene for each component
puts an instance of the component in the scene
names it something sensible

I guess it would be sensible to make it work for all selected components or all if nothing selected. I suggest the name might be something like component name + 'component scene'. It would probably be best to make a scene for unique instances and not multiple scenes merely because there are a gazillion instances around. I'm not sure what one ought to do with components containing other components; I think my initial suggestion would be to limit the scenes to the lowest level of component but I can see wanting to be able to have scenes of more complex items as well.

Such a plugin would make it really nice and simple to prepare for making a Layout doc that is intended to show each component separately for dimensioning etc.

I'm willing to try to write such a plugin myself if none exists but I warn you, I'll be asking lots of questions in that case

@noelwarr said:

a) These are Catalan words and they describe the tools that are available to my machine.

Really? It probably won't surprise you to hear that I know no Catalan at all. I suspect my mother learned a little many, many years ago because she and her red-headed friend Nancy hitch-hiked across Andorra (amongst other parts of Europe) around 1957 or so. I understand they got into quite a few adventures such as sleeping under hedges in snowdrifts….

@noelwarr said:

Every machine is different so the UI needs to be different for every machine. At the moment this means you would need to edit "ui.rb" as well as "postprocessor.rb". It is poorly thought out I agree, but my efforts were concentrated in the "concepts.rb" and "parser.rb" files and getting them right. I belive that the best solution would be to have the "ui.rb", "concepts.rb" and "parser.rb" files stay untouched.
It seems obvious to me that a class called something like "CNC" or "Machine" should be declared somewhere in "postprocessor.rb". It should have a method tools() that retrieves the tools available to that machine. This can be piped to the UI and should be easy enough for hobbyists to edit for their machine. This class should also contain other methods to aid the postprocessing. Things like number_of_axes(), pods?(), max_spindle_speed()...

Sounds a good idea. I'd hazard a guess that somewhere in Ruby-land there is a standard way to provide lists of UI related words and phrases that you can choose from at runtime, depending upon a chosen language setting. It's a fairly standard technique that works tolerably well most of the time.

@noelwarr said:

b) I thought there was a good chance it would fail on macs but decided to make a concious effort to not loose sleep over it. Something told me that the answer would come to me in the form of a wise man called Tim I'll fix it soon.

One lives to serve.

As for comments - I always advise against living up to the old joke that goes "Comments? Why do you think it's called code?". A friend put it even better; "Don't document the code, code the document"

Noel, excellent start on a really interesting project.
I grabbed the code and notice a couple of things immediately:
a) you've used some words that would need translating before I had a clue what was going on ('cuchilla', 'graus', etc)
b) you've done something I've seen done many, many, times in Smalltalk and Ruby etc - made filenames by concatenating literal strings including the directory separators. Bad move, it makes for OS specific code when you don't want it. There should be useful methods to build a suitable path that avoids that issue. A quick google suggests using things like File.join instead of pwd + '\' + foo

Ouch! That's near to twice the price of a Mac mini for a slightly faster machine with no OS X. Not my taste, but if it floats your boat feel free.

I do advise careful use of the a word. It tends to call down parachuting fanatics in much the same way as aul Rand.

Claims that the buildings could not have collapsed due to 'merely' the aircraft fuel etc are completely forgetting the ChemTrail tanks installed on the planes. Goodness knows how hot that stuff burns. And of course since the flights were interrupted, the tanks would not have been activated and so would have been full. Think about it sheeple!

For complex organic shaped roves you should probably find a really good panel beater and a really good welder and do a metal roof.

Oh, you wanted an economically plausible answer? Don't ask a timber-frame house builder...

One should also note that McKeith is a fraud - http://www.guardian.co.uk/media/2007/feb/12/advertising.food

@unknownuser said:

(2 Timothy 3:16)

I am Timothy (strictly speaking Lt.Col. Sir Tim, but never mind) and you are abusing my words and my patience. You are acting as a bad guest in someone's house and generally like a total cad and bounder. Anyone with an ounce of decency would withdraw and cease such poor behaviour.

The real thing to celebrate right now - and it's caused by the actual 'reason for the season', planetary axial tilt - is the shortest day, tomorrow. Because once we're past that the days start to get longer and we're heading towards better weather.

Maybe there are a few people that prefer the shorter, darker, colder days and if so I will happily support their right to celebrate the summer solstice and the coming of winter. But me, I'm celebrating the winter solstice. Besides, it's our 31st wedding anniversary.

@dropout said:

I find it interesting that Dawkins will state categorically that the world was not created by God but will suggest that life may have been seeded here by extraterrestrials (interview in Expelled - no intelligence allowed) or that it had something to do with crystals. That sounds even more far fetched to me.

If you can quote that farrago of lies with a straight face you've disqualified yourself as any sort of serious commenter.

@dale said:

What a beautiful house, and I really admire your attention to detail, but given your background in computers and code, I'm sure detail is second nature.

That and being borderline sociopath/obsessive-compulsive…

For anyone else contemplating their own build I'd reiterate that obsession with detail thing; so many contractors are happy to let precision slip because it's just a job to them, day in, day out. If you show them the potential for making something nicer than they usually get to do, take part in the process and the work, turn up with enthusiasm every day, then it is amazing how much harder most of them will try. Details matter during the build, after the build as you live there and later when you want to change things.

It's also good to live on the Fine Homebuilding website for a year or two to learn (at least) the words and phrases that communicate some knowledge of what you're up to. Better yet, you're likely to know something new in the field that might interest your subcontractors.

@dale said:

Oh and I still consult for a Nanaimo Company, and do make it down to the Island from time to time.
Maybe we can meet sometime, and I can buy you a beer.
Cheers

Nice idea Dale. Sounds like a plan…

Oh, and

@dale said:

Since I haven't been on the tools for 7 years or so, I got lazy and figured out the compound miters in Skp.

I can't count the number of special printouts I did from the SU model to illustrate a detail of the roof decking angles, or rafter tenons, or electrical layout or, or, or. Invaluable.

It's always worth remembering the spirit of that old joke about how "I spent most of my money on pleasures of the flesh, fine booze and food. The rest I seem to have wasted"
Do some things that please you, whatever they are. Buy something beautiful just because.

Hey Dale, isn't it fun doing the inside 'details'? I've been doing trim on my self-build timber frame for what seems like forever and it still has a want to go. I think the trick is to make sure you make some progress every day and just keep at it.

I have a build blog athttp://www.rowledge.org/tim/building/building/blog.html for anyone interested - including full SU and LO files.

That's certainly not the sort of output I get; it looks like you're a Windows guy so maybe it's some detail of the video driver version/preferences/settings/bug ? It seems there are plenty of things that can go wrong in that area.

Oh, SU can't be completely discounted; it's a couple of years ago now but I had a long period of total-lockup issues on an iMac because something about the component browser would suck up memory until nothing was left and the system just locked. There's a thread somewhere in the SU bugs forum all about it.