Sketchup 8, serious observer bug?

l.frisken

I've run into some trouble with sketchup's application observer and model observer when using the onSaveModel, onNewModel and onOpenModel. Basically, whenever I save, open or create a new model it lags like crazy... ok, maybe not crazy, but 5 seconds is enough to get on my nerves, and I'm sure that's pretty unacceptable for any script, as it will most likely get in the way of the user... I've stripped down the problem to this code and it still occurs, so I'm thinking it probably isn't fault of mine, but if you think it is, please let me know

Interestingly enough, my code runs without a hitch in sketchup 7, so I'm thinking its a new problem. I'm surprised no-one else has run into this problem yet, or does no-one use app/model observers?! or perhaps it's just my computer? (yes I have reinstalled sketchup 8 just to make sure, and yes I have tried with a totally clean script directory.)

Any help here would be greatly appreciated, because I'm relying on this to fix/hack around another problem I'm having:

Is there any way to register an operation that will be invisible to the user? I havn't found a way, and I would like to save all my script's properties into sketchup's attribute dictionary in one hit without having to worry that the user might accidentally undo the saving of the properties. I finally decided that the only way to get around this would be to save the properties when the current model is saved.

class My_model_observer < Sketchup;;ModelObserver

  def onSaveModel(model)

    puts "SAVING MODEL"

  end

end



class MY_app_observer < Sketchup;;AppObserver

	def onNewModel(model)

    puts "NEW MODEL"

	end



	def onOpenModel(model)

    puts "OPENING MODEL"

	end

end



Sketchup.add_observer(My_app_observer.new)

Sketchup.active_model.add_observer(My_model_observer.new)

TIG

Instead you could add actions into the 'deactivate()' section of the Tool then your @x values can be written with model.set_attributes() if a @flag is set [set it after the user has OK'd values in dialog etc so when the Tool ends the settings get auto-saved outside of any undo trap?]

thomthom

@tig said:

Instead you could add actions into the 'deactivate()' section of the Tool then your @x values can be written with model.set_attributes() if a @flag is set [set it after the user has OK'd values in dialog etc so when the Tool ends the settings get auto-saved outside of any undo trap?]

eh? he doesn't mention anything about any tool...

TIG

@thomthom said:

@tig said:

Instead you could add actions into the 'deactivate()' section of the Tool then your @x values can be written with model.set_attributes() if a @flag is set [set it after the user has OK'd values in dialog etc so when the Tool ends the settings get auto-saved outside of any undo trap?]

eh? he doesn't mention anything about any tool...

*No...*but if it's in a class the 'deactivate(view)' is identified as a built-in Tool method opposing 'activate' - easy enough to add...
I can't believe he's writing a 'tool' that couldn't be a 'Tool' ??

thomthom

@tig said:

I can't believe he's writing a 'tool' that couldn't be a 'Tool' ??

If it's something that is always running - sort of speak. Something that keeps track of items in your model, then you can't keep a tool active for the whole duration of the session. But - knowing more about the general purpose might be useful to determine alternatives.

@l.frisken said:

ok, maybe not crazy, but 5 seconds is enough to get on my nerves

That bare-bone sample you provided cause a 5min lag on your computer?
What OS?

@l.frisken said:

or does no-one use app/model observers?!

I've used the AppObserver for some of my plugins where I need to attach ModelObservers to each new model session. Vertex Tools is one of them - Haven't noticed anything myself, nor have I heard any reports of any lag.

@l.frisken said:

Is there any way to register an operation that will be invisible to the user? I havn't found a way, and I would like to save all my script's properties into sketchup's attribute dictionary in one hit without having to worry that the user might accidentally undo the saving of the properties. I finally decided that the only way to get around this would be to save the properties when the current model is saved.

AFIK there isn't a way to make an operation fully transparent to the undo stack.
What type of data is it you want to store anyway?

l.frisken

Thanks for the replies guys!

@thomthom said:

eh? he doesn't mention anything about any tool...

thomthom is right, it's not a "Tool", its an exporter for sketchup to luxrender.

Previously, settings were saved to the sketchup attribute dictionary when any change was made to the setting in the settings editor. This system does work, but it also means that after changing settings, or perhaps using/loading a preset it leaves stuff behind in the undo stack, which the user might inadvertently undo and thus lose any changes they made to the settings. I've changed it save all the settings to a temporary array until the model is saved. Which works fine in sketchup 7, but sketchup 8 seems to be having problems.

@thomthom said:

That bare-bone sample you provided cause a 5min lag on your computer?
What OS?

Not 5 minutes, but 5 seconds rather. I might do a little more testing to further narrow the problem. But for someone who likes to save fairly regularly, 5 extra seconds is kind of annoying, and I'm imagining it might annoy some users as well. The same lag occurs when opening a new model with these observers activated.
BTW: I'm using windows xp sp 2.

@thomthom said:

AFIK there isn't a way to make an operation fully transparent to the undo stack.
What type of data is it you want to store anyway?

I'm just trying to store a mapping of settings to their values.

thomthom

@l.frisken said:

Previously, settings were saved to the sketchup attribute dictionary when any change was made to the setting in the settings editor. This system does work, but it also means that after changing settings, or perhaps using/loading a preset it leaves stuff behind in the undo stack, which the user might inadvertently undo and thus lose any changes they made to the settings.

But isn't it just as likely the user might want to undo these setting changes?

@l.frisken said:

but 5 seconds rather. I might do a little more testing to further narrow the problem. But for someone who likes to save fairly regularly, 5 extra seconds is kind of annoying, and I'm imagining it might annoy some users as well. The same lag occurs when opening a new model with these observers activated.
BTW: I'm using windows xp sp 2.

Have you tried that bare-bone example with no other plugins installed?
When I've had problems with observers I've often had problems correctly identifying the source of the issue. Often it was another part of my script which just made it look like it was an observer issue.
And it could be some conflict with other plugins. When you are stomped with observers it can be worth testing them in very isolated environments.

TIG

I recently wrote the 'Octane Render Exporter' - and it is a 'Tool' [any 'class' that is suitably loaded and contains appropriate 'methods' is one??? A 'tool' doesn't always need to spot mouse movements, clicks etc]. You 'run' it as tool Sketchup.active_model.select_tool(Octane.new) - which then does an initialize() and an activate(), runs all the subsidiary methods and when you are done it uses a ' deactivate(view)' method - and as part of that closing method it checks to see if the user 'canceled' the web-dialog [it's a simple @flag] and if not then all of the Exporter's web-dialog's current settings are saved into the model as appropriate attributes. These are then recycled next time the user runs the tool in that model and are read in as the new default settings. Obviously these latest settings are only remembered across sessions if the model is eventually 'saved' by the user.
It takes a blink of an eye to get / to set literally dozens of these settings as the web-dialog opens / closes. You could also make the dialog 'modal' so that the user can't close the model with the web-dialog open and thereby loose settings - I have done this because with my tool you can do several operations with the dialog remaining open and it's only on a 'close' that the current 'fields' get saved as attributes...
I do think its best to remember mosts settings like these as 'model specific attributes' since the user might have different requirements in each model. My Exporter does read/write one of the 'setting' as an entry with the SketchUp App [registry etc] - that is the 'current version' of the 'Octane Render' app to be used - the user must sets the path to a valid exe file and that is used in all models thereafter - as it's in beta testing it allows the user to test different versions of the exe...

l.frisken

@thomthom said:

But isn't it just as likely the user might want to undo these setting changes?

yes, but unfortunately, they can currently undo changes they made in the settings editor even when it's closed. They won't be able to tell that they've undone them. Perhaps, like me they might think they just mispressed the ctrl-z key, or just keep pressing it until something visual undoes (like the removal of a line), and later discover that they've just undone all the changes that they made to the settings, and there is no way to redo, because they've continued on with their work.

This is entirely plausible because I've done it myself! While it isn't too much of a loss at the moment, I can see it getting pretty bad later on, plus, any little change like ticking a box or whatever adds another undo to the stack, which means that when alternating between modelling and changing render settings, they have to delete the changes they made in the settings editor AND press undo many times just to get a visual response... (hmm I could have made that bit shorter )

@unknownuser said:

Have you tried that bare-bone example with no other plugins installed?

yes, in both sketchup 7 and 8, but I'm thinking I'd better try mucking around some more to see whether it's another problem with my sketchup installation, because it doesn't seem to be giving you guys any problems. But you are right, because it could be an observer in another script interfering with this one or something. Oh well, unfortunately the solution isn't that simple

Thanks for the help anyway thomthom (and TIG of course ). Hopefully I can get a reasonably feature complete su2lux out soon for people here to test. I'm going to be doing a bit of Arch-Vis work over the coming holidays, so I have a vested interest in this project!

edit:
oops, didn't see that last post TIG, I'd better reply to that too!

l.frisken

@tig said:

It takes a blink of an eye to get / to set literally dozens of these settings as the web-dialog opens / closes. You could also make the dialog 'modal' so that the user can't close the model with the web-dialog open and thereby loose settings - I have done this because with my tool you can do several operations with the dialog remaining open and it's only on a 'close' that the current 'fields' get saved as attributes...

So what happens when the user tries to render/export with the settings dialog still open? I would like it to be possible not to have to close the dialog every time you want to render the scene, so it will be easy to make quick changes... I'm guessing you've probably handled it similar to me in that you have a temporary attribute dictionary, that gets save synced to sketchup on demand. So that it should be possible to export your scene whether the dialog is open or not... Either way, does implementing the "syncing" action in the deactivate(view) prevent it from being registered in the undo stack? Your solution to the problem does sound like it could work for me. Could I not also do it like like this? WebDialog.set_on_close{ save_settings(blabla)}

If I do it the way you suggested at least the user will will have the option to undo the changes, I just worry about it getting in the way of the modelling workflow, because it essentially creates a point where the user can no longer undo changes they made in the model. There really should be two undo stacks running in parallel ?

thomthom

do you have to write the settings to the model for every interaction you make to the model? what about writing them when your dialog closes?

thomthom

@l.frisken said:

There really should be two undo stacks running in parallel ?

I do think we should be able to make transactions that does not appear in the undo stack at all. At least set attributes. Because when you set model properties in SU you don't see them in the undo stack.

TIG

@thomthom said:

do you have to write the settings to the model for every interaction you make to the model? what about writing them when your dialog closes?

That's what I do - as you work the values can be read from the web-dialog as you go when you click some button it remembers the settings as attributes affected by that button.
The web-dialog has all of its fields available to be 'read' as you deactivate() so it can save all of them. if the users 'closes', or not if the users 'cancels' - but changes made during intermediate operations will be remembered as 'you go'...

morisdov

If i disable google update service and hide associated exe, i am experiencing noticable delay on closing sketchup or opening a new model.

First i thought i had AppObservr bugs.
Even though i try to code defensively against exceptions and presume surprises.

l.frisken

@morisdov said:

If i disable google update service and hide associated exe, i am experiencing noticable delay on closing sketchup or opening a new model.

First i thought i had AppObservr bugs.
Even though i try to code defensively against exceptions and presume surprises.

Yes! That's probably it. I'll check before I confirm that was my problem, but if it is then this is definitely google's responsibility. I do normally close the update service because I don't like to have random processes running in the background on my computer... But this definitely shouldn't affect sketchup usage!

thomthom

I didn't think Google Update Service was related to SU... Thought it was SketchUp itself that did this check. I've only ever gotten update noticed when I've run SU.

mozzie

A bit OT, but the right people seem to be here.
Are there any known problems with Settings?
The menu comes up OK and Render exports an LXS file, with a dialogue to start LuxRender, all good
But the Settings doesn't bring up anything at all?
SU8 Win7 64bit Lenovo Laptop ATI video card.

<edit> i do have the SU2KT and SU2POV installed, so it may be some interference.
I don't want to uninstall these just yet as I'm finding both useful, but I will investigate ...

l.frisken

ah mozzie,
It's actually not too OT at all
There are a number of known problems with SU2LUX's settings atm,
and I ran into this problem when trying to fix them.
If you want I can share what I have so far, and it should work
fine on SU7 and perhaps SU8 if the problem is restricted to
my machine but I suspect it isn't... (not that there is too much
to be desired in SU8 free anyway...)

mozzie

Well, I'm happy to test it out, on SU7 & 8 Pro. But programming? Nope.
But with TIG and ThomThom commenting here you've already got some deep SU Ruby knowledge.
If we can ask them to get involved ....

As suggested, there's nice exporters for POVray and Kerkythea, which means we may be able to draw on others in the forums too.
Supporting another good OSF renderer in SU would be helpful to all involved.
What functions do you think needs to be done to move this project along, and then to the next level?