SketchUp 8 M2 is out!

[opal]

@unknownuser said:

@driven said:

open a drawing that uses the old template then do save as template?

john

(obvious I think but just incase)

delete all the geometry and purge first (unless you want certain materials etc in your template)

should be obvious.. but rolls eyes at self it wasn't. Ty will do

[Bob James]

Hope these will be more readable. Done, by the way, on my laptop, which sees the same plugins as work and home desktops.

---

---

---

---

[Panga]

@unknownuser said:

Out of curiosity, what are you modeling today, and how 'heavy' would your model have to be before you'd be satisfied with the level of detail?

Hi John, and thanks to you and google team for all the job done to improve SU with each release. I just wanted to put my word in this discussion as I'm often pushing SU to its limits...Have you ever tried to model a solar farm on SU ? Believe me it turns you to in a very very very patient man...

For example one of my last work was about : 9 265 148 edges / 3 689 820 faces. I'am heavily using layers and 'proxies' to simplify my work, win time, and being able to produce such models, but I often need to put all the real stuff in the viewport (real components instead of proxies, and all layers on) and at this time...well, I got plenty of time to surf on sketchucation and other places waiting SU to respond...

So, some of us really need better performance for high poly model...@last guys and Google made such a great piece of software that now, not only architects, but many many other people are using it for their job...and even if it SU was made for architectural and conceptual drawing, today we're doing so much more with it...So whatever you can say, we'll always ask you for better performance !! Don't get me wrong, for working in SU since the 4th version, I can testify that progress has been done and I sincerely thanks you for that, but the more you'll give to us, the more we'll ask for

Maybe most of people do not work with such models and do not need the precision that give us those High poly models, but I just want to be sure that you guys do not ignore that the performance we're claiming for is really important for us...not just a geek or obsessive wish !!

Ps: Hope, my english is enough "performant" for my message being understandable

Long life to SU !

[jeff hammond]

@unknownuser said:

should be obvious.. but rolls eyes at self it wasn't. Ty will do

lol.. yeah, it happens..

@bob james said:

The entire plugins folder is in Dropbox and linked to SU, that way SU at home is seeing the same plugins folder as SU at work.

right.. i have a similar setup branching out to 3 computers
the difference is that my actual plugin folder on each computer is in it's proper location with symlinks going to the dropbox folder instead of me running my plugins through a link to another location..

i really don't have a clue as to wether or not there's a performance difference or possibilities for problems doing it your way and maybe it's totally fine.. it just seems cleaner or more proper to keep the actual plugins in their intended spot..

but i guess this isn't really the right thread for this discussion..

[TIG]

Bob

I have a few - but not exhaustive - comments...

The filmandstage.rb file belongs in Tools - so move it.
The extensions.rb AND sketchup.rb files MUST be the current ones in Tools NOT these ones in Plugins! [probably out of date legacy files from a much older version ? so remove them]...
So... any files that the latest installer puts into Tools should be there, and any files with the same name that you see inside Plugins should not be there!

You have a few scripts even I don't have - I thought I was anally retentive...
You have lots of scripts that I suspect you rarely use if you think about it... Consider disabling those...

[Bob James]

@unknownuser said:

(that said, i think you might want to reconsider how you're dropboxing those.. why not sync the actual plugin folder instead of each individual file?)

The entire plugins folder is in Dropbox and linked to SU, that way SU at home is seeing the same plugins folder as SU at work.
UPDATE:
For specific info on using Dropbox symbolic links see http://forums.dropbox.com/topic.php?id=19392

For a more general approach see, for example, http://www.howtogeek.com/howto/16226/complete-guide-to-symbolic-links-symlinks-on-windows-or-linux/

[Bob James]

@tig said:

The filmandstage.rb file belongs in Tools - so move it.
The extensions.rb AND sketchup.rb files MUST be the current ones in Tools NOT these ones in Plugins! [probably out of date legacy files from a much older version ? so remove them]...
So... any files that the latest installer puts into Tools should be there, and any files with the same name that you see inside Plugins should not be there!

You have a few scripts even I don't have - I thought I was anally retentive...
You have lots of scripts that I suspect you rarely use if you think about it... Consider disabling those...

Actions:

1. Move filmandstage.rb to Tools
2. Remove extensions.rb and sketchup.rb from the plugins folder
3. Inspect the new Tools folder and remove any files from the plugins folder that appear in the Tools folder.

@tig said:

You have lots of scripts that I suspect you rarely use if you think about it... Consider disabling those...

I just find it hard to pass up the great tools you Ruby gurus create - even if I only use them now and then.
True, some are rarely used, but if I take them out by re-naming them I doubt I could rememeber which I'd need to re-name after shuting down and re-booting.
The ideal world would allow me to group plugins by category of what, in general, they do; and be able on the fly to activate/de-activate from a drop-down menu.

Thank you, TIG, for taking the time to point these out. Much appreciated because the problem with greyed-out functions happens to me all the time and I waste a lot of time re-booting.
@Jeff
See how "our" sub-topic fits here? I make those changes once in Dropbox and, voila!, they are changed on all three machines: home, work and laptop

[Bob James]

@unknownuser said:

...the difference is that my actual plugin folder on each computer is in it's proper location with symlinks going to the dropbox folder instead of me running my plugins through a link to another location..

i really don't have a clue as to wether or not there's a performance difference or possibilities for problems doing it your way and maybe it's totally fine.. it just seems cleaner or more proper to keep the actual plugins in their intended spot..

Dropbox puts a copy of the plugins folder in its proper location on your hard drive - that is, it's not only on Dropbox.
In my attachment of my SU folder you can see the plugins folder. I originally re-named my plugins folder to "plugins copied to DB" (just in case I screwed up the process ). After making the symbolic link (correctly as it turned out), dropbox copied the Dropbox version into the SU folder. (The Plugins-1 is another paranoia copy ). It's interesting to have both Dropbox/Plugins and SU/Plugins folders open at the same time, make a change in DB and see it instantly change on my hard-drive SU/Plugins

@unknownuser said:

but i guess this isn't really the right thread for this discussion..

I think it's closely enough associated with the general topic of "how to fix the plugin situation so that the greyed out problem goes away".

---

[jeff hammond]

@bob james said:

Dropbox puts a copy of the plugins folder in its proper location on your hard drive - that is, it's not only on Dropbox.

oh, i see.. yeah, i'm doing something a little differently then..
in my user/home directory (not sure what the windows equiv is.. but it's just this place on my drive.), i have a dropbox folder and that's what is syncing to the dropbox servers(?)..

inside my dropbox folder (the one on my computer), i have a symbolic link (alias'.. or maybe it's called a shortcut on windows?) which is coming from my plugins folder.. my actual plugins folder isn't directly connected to dropbox.. i have a middleman in there.. (which i've also been using to install my rubies from lately.. i just put them in my dropbox folder and they are sent to my plugins folders on all the computers)

but yeah, i think a few people are doing some sort of cloud syncing with plugins lately.. i wonder what, if any, problems may arise (well, i know of a few problems that could come up.. i'm talking about sketchup performance problems in particular)

[rv1974]

Hi John!
First off thank you for refining our beloved baby.
May I put my humble request here please:
I beg for solving 'grey menu' issue! It's close to impossible to work 'this way'.
And could it issued as kinda 'hotfix' ASAP before the main release?
Thank you in advance

[Krisidious]

@rv1974 said:

Hi John!
First off thank you for refining our beloved baby.
May I put my humble request here please:
I beg for solving 'grey menu' issue! It's close to impossible to work 'this way'.
And could it issued as kinda 'hotfix' ASAP before the main release?
Thank you in advance

you should read the previous 8 pages real quick.

[rv1974]

@krisidious said:

@rv1974 said:

Hi John!
First off thank you for refining our beloved baby.
May I put my humble request here please:
I beg for solving 'grey menu' issue! It's close to impossible to work 'this way'.
And could it issued as kinda 'hotfix' ASAP before the main release?
Thank you in advance

you should read the previous 8 pages real quick.

Well I did before posting here. You see I had this issue before M2 (which had no cure for this).
The answer 'Grayed-out context menus are typically a problem with one or more of the scripts you have installed'
does not sound good to me. Even if this statement is right (which is doubtful), The one third party ruby MUST NOT ruin the whole application.There must be protection against it. So I do believe that it's host software critical defect that should be fixed ASAP.
Purging the plugins folder (your recipe) which I I did a couple of times before did not help (at least in my case).
And basically I think the quantity turns into the quality: More nagging customers the better

[Khai]

anyone know if the "flicks" bug has been fixed?
(where you zoom into a model, rotate round it, and suddenly the view is thrown several miles from the model and can be almost impossible to find the model again. resetting the views etc has little effect)

it was so bad in 8 I went back to 7... but from what I can tell, I maybe the only person it happens to

[thomthom]

@khai said:

anyone know if the "flicks" bug has been fixed?
(where you zoom into a model, rotate round it, and suddenly the view is thrown several miles from the model and can be almost impossible to find the model again. resetting the views etc has little effect)

it was so bad in 8 I went back to 7... but from what I can tell, I maybe the only person it happens to

Do you mean where the camera zoom in big steps if you have the cursor over empty space? It's a big difference in the zoom steps depending on whether the cursor is over geometry when you zoom or not.

[Alan Fraser]

I can't say that I've ever come across the 'flicks' bug (as described) in all my years of using SU. I've occasionally imported 3rd part geometry which has come in very small and is difficult to navigate...especially if it's a long thin shape (easy to overshoot); but that's about the extent of it.

[TIG]

rv1974

You seen to misunderstand.
As more plugins were developed the gray-out issue was reported.
It was a mystery for some time until the cause was stumbled upon - it was noticed that several of Fredo's tools made 'commands' within context-handlers, so this rapidly increased the number of 'commands' used in Sketchup and could overwhelm it - so in effect it then started disabling some earlier 'commands' to make space for the new ones.
Thankfully once it was realized Fredo [and a few others] quickly fixed their code, and we now know of no plugins that have this 'fault'.
However, the gray-out reports continued to increase as new tools became available with additional 'commands' needed to use with their toolbars/context-menus etc.
This adds to the total number of commands Sketchup has to handle and so it can reach the fatal limit.
For some unexplained reason, this number-of-commands is relatively low - perhaps in the hundreds - so if you have lots of plugins auto-loading from the Plugins folder then you can get the gray-out menu items. A good solution would be for Sketchup to handle considerably more commands - x2 or x10 etc... BUT that needs Google to redo parts of their code...

Currently, there are several ways of reducing the number of commands loading and thereby avoid the gray-out issue.
If a tool is an Extension and you are unlikely to use it very often, then you can deactivate it in Preferences and restart, if you need the tool later you can always activate it again...
If the tool simply loads from a .rb/.rbs file in the Plugins folder you can find the file and rename it - so xxx.rb becomes xxx.rb! etc - only .rb and .rbs files will auto-load, so after a restart the "!" versions are ignored [note that any companion scripts in subfolders do not auto-load and so they need not be renamed at all]. Later, you decide you really do need to use a particular tool you can always open the Ruby Console and load it manually, thus load "xxx.rb!" - the code inside a .rb! file is still read OK and then the tool will load, it's active just for that session [unlike an Extension which would have to be disabled again to stop it loading every time].
As an alternative to renaming scripts you could simply move their files to a Disabled_Plugins folder but that is more drastic...
There are many scripts that you probably don't need to be loaded up every single day... do some spring-cleaning and stop getting gray-outs...

[thomthom]

@tig said:

For some unexplained reason, this number-of-commands is relatively low - perhaps in the hundreds

Google sources says it's 1000.

[TIG]

It's probably something like 1024 - following some 'binary logic'.
Which is better than 512... but not as good as 2048 or even 4096 !
Presumably someone somewhere in Google needs to 'allocate more memory' to this ?

[thomthom]

You'd think so, but he seemed quite specific to it being 1000...
http://forums.sketchucation.com/viewtopic.php?f=15&t=27941#p243583

@jhauswirth said:

The problem is Ruby scripts are calling-
UI::Command.new
and not attaching the new command to a menu item.

If you want to verify this run-

for i in 0..1000 do
cmd = UI::Command.new("Tester") { UI.messagebox("Hello World") }
end

I can see Ruby scripts creating new commands on each right mouse click.
Every new command creates a unique command ID in SU and there are only 1000
command IDs available. Normally a command is attached to a menu and when
the menu goes away the IDs are recycled, but since these commands are not
attached to a menu, they don't get recycled.
I'm going to try and figure out how to dump the list of commands (they have
menu item text) so that people can see who's causing the problem.

[TIG]

Well if it is exactly 1000, then they just need to change it to say 2000 or 10000 !!!
This is NOT rocket-science after all...

I am frankly amazed that Google have not fixed this seemingly straightforward issue... BUT instead they have chosen to expend effort on inventing RBZ/installers etc, which as you know, I feel fixes a problem that didn't exist [or if it did exist then it simply replaced it with an alternative problem]... all while the population explosion of installed plugins continues [which is at least theoretically made even easier by RBZ] - which is still wreaking havoc in the context-menus with gray-outs... which should have been fixed!