Feature: model.start_model

[Nazz78]

Add a method that is similar to model.start_operation in a sense that it is wrapped in a single operation but different in a sense that it is not visible and it can not be undone.

Use case
Some extensions (eg. Modelur) need to setup the model before it can be used. This consists of adding materials, setting up dictionaries, etc. At the moment best possible solution / workaround for such cases is to wrap it into a single undo operation. The problem with this is twofold: 1) one operation is already recorded into undo stack and user can save practically empty model and 2) if undo is called right after initialization, the will not work properly anymore.

[thomthom]

Can you elaborate on why materials and dictionaries must be setup as the model is created?
As oppose to adding these things on demand as the extension is used?

[Nazz78]

Sure thing Thomas,
In our case we need to setup model so that it is prepared for typical urban design tasks. One the most important things in urban design & planning is working with land uses. In order to setup landuses we write certain parameters (eg. average size of apartment in Residential Land Use or average size of office in Service Land Use) into dictionary to preserve any changes user makes during modeling. The same is the reason for creating new Materials - Land Uses are always denoted by color in urban planning.

Land Uses are such a core property of what urban planning and design is about that it doesn't make sense to wait to create them on-the-fly from our perspective. I guess that technically we could wait until needed, but again, from urban designer's perspective some default land uses should be present/predefined in the model right away...

Does that make sense?

Cheers,
Jernej

[DanRathbun]

I just posed a very similar / same question in another issue:
Issue #6: Model#start_operation method

What about creating a new block form method that allow the grouping of methods that cause a commit ?

transparently do
 component_def = model.definitions.load(path_to_component_file)  
 model.place_component(component_def)
end

Thinking that when statements are executed within this transparently() method, that undo commits are suppressed.

Then the above method call could be used within a normal API operation syntax.

Although, I posed it as a possible global method, I suppose it also could be an instance method of the Sketchup::Model class.

[thomthom]

Logged as SU-38592

[DanRathbun]

I do not understand why a urban design template is not the correct solution in this use case.
The template model could have the materials and dictionary pre-loaded. (This is what a template is for.)

[Nazz78]

@DanRathbun each user can define their own set of default parameters and settings that are set up when new model is opened. So there is no one template to rule them all. Workflow, where you need to first load template is not very user friendly.

[DanRathbun]

Workflow, where you need to first load template is not very user friendly.

Disagree, and the software world would not have template files if your statement was true.

each user can define their own set of default parameters and settings that are set up when new model is opened.

Perhaps each user CAN, but IMO a user is more likely to want to setup project parameters in templates, and then reuse them. I don't know anyone who wants to go through the setup every time they open a new model. Such a workflow is definitely unfriendly and tedious.

---

Sorry, but I must vote 👎 on this request as ...

The problem with this is twofold: 1) one operation is already recorded into undo stack and user can save practically empty model and 2) if undo is called right after initialization, the will not work properly anymore.

... are not an issue at all.

The obvious solution is simply force the user to save the model with the configuration in place, (before they begin modeling,) so that they cannot undo it.

[Nazz78]

Disagree, and the software world would not have template files if your statement was true.

One of the first differences between SketchUp pro and Make you notice is that in Pro you can disable initial window that forces you to pick the template file. For a reason, I believe :-) How many times you use different templates? I only pick it the first time, then I turn that window off.

Perhaps each user CAN, but IMO a user is more likely to want to setup project parameters in templates, and then reuse them. I don't know anyone who wants to go through the setup every time they open a new model. Such a workflow is definitely unfriendly and tedious.

Even if model.start_model is implemented, there is absolutely nothing that prevents users from using templates if they wish so.

Sorry, but I must vote 👎 on this request as ...

Not a problem, its great we can discuss things here and share different opinions.

The obvious solution is simply force the user to save the model with the configuration in place, (before they begin modeling,) so that they cannot undo it.

Only saving will not help, as undo stack is still there after saving operation. I guess you thought

...to simply force the user to open the model...

? In my experience, forcing users to make unneeded steps is not good UX practice. And as said before, they can still do it if they want to. But until today, we received no such feature request from our customers, which also tells me something...

[DanRathbun]

Yes (I thought) saving used to clear the undo stack.

[thomthom]

Yes saving used to clear the undo stack.

Should not do that. Nor have I ever observed that. It'd be considered a bug if that ever happened. Only scenario I can think could do that would be if a ModelObserver did something funky during save....

[DanRathbun]

Hmmm,... my memory must be failing me. Could be I'm thinking of some other application.

Generally, I save manually because I want all edits "set in stone", and do not want to go back. It's seems weird to me that an undo stack would go back beyond a manual save. I can see that it would after an autosave (but I never have such features enabled, as they've always proved problematic for me in all applications.)

---

What if a plugin saved the model, then cycled through a new model, then reloaded the previous one ?

I'm not against having "silent" attribute writes (we've talked about this in the past.)
I just do not feel right about this proposed workflow, and am wary of how the proposed method could be abused.