Access to UI Tray

[J-E-L]

Feature Requests

1.a. The Posibility to Close Tray Window, 1.b. Get the Status of open Trays(we can inform the User to close it) Because if Outliner or Components Window is open, Ruby may run really slow!

[Eneroth3]

I don't think extensions should interfere with too much the UI. Users may be confused if panels disappear and not know how to restore it (or even not understanding it has disappeared and just keep searching for it in the tray). It's better to have the underlying problem of open panels slowing down SketchUp fixed.

There are a few use cases for opening panels though, as how native Paint Bucket tool opening Materials.

[thomthom]

Because if Outliner or Components Window is open, Ruby may run really slow!

I'd argue that if that's the use-case then the issue should be about fixing that instead of implementing new features for workarounds.

[DanRathbun]

I don't think extensions should interfere with too much the UI.

Agree. But I also would not vote against a block form method that would only allow temporary hiding of the Outliner whilst the block runs.

[MSP-Greg]

Another option is to have some sort of 'panel UI freeze', where (similar to start_operation), a plugin could stop UI updates.

Main problem would be how/when to 'unfreeze' the tray if the plugin code did not do so...

[Eneroth3]

Agree. But I also would not vote against a block form method that would only allow temporary hiding of the Outliner whilst the block runs.

Another option is to have some sort of 'panel UI freeze', where (similar to start_operation), a plugin could stop UI updates.

Main problem would be how/when to 'unfreeze' the tray if the plugin code did not do so...

No and no.

Preventing the panels from updating should be done my Model#start_operation itself. The API shouldn't be extended with hacks when the actual problem could be solved instead.

If modifying trays is added to the API it should be for the rare use cases where it's needed, not as workaround for something else that is broken.

Once something is added to a public API it is very hard to remove it. Super specific implementations, like disabling UI updates from within a code block, would become obsolete once the underlying problem has been fixed, and then make the API harder to understand and to maintain.

[J-E-L]

The option of 'panel UI freeze', where (similar to start_operation), is a good Idea.

This Option shoud be part of a Tool Class. To prevent a forgotten freeze, on exit a Tool SketchUp automaticly unfreeze the UI. Like SketchUp do the "view.draw" only inside a Tool.

[Eneroth3]

This Option shoud be part of a Tool Class.

Drawing to the model directly from a command is just as valid as drawing inside of a tool. The implementation of not having panels redraw while drawing geometry should not be for tools only.

Like SketchUp do the "view.draw" only inside a Tool.

There has been several request to also be able to do this outside of a custom ruby tool. Some use cases are 1) displaying a north arrow in the corner of the view, 2) show the active edit path (name of all open groups/components) in the corner of the screen, 3) replicate Top, Bottom, Left, Right, Front and Back text, but relative drawing axes. The API should be flexible without these arbitrary limitations.

The option of 'panel UI freeze', where (similar to start_operation), is a good Idea.

I still don't see why. Why not simply disable panel redraw between the existing start_operation and commit_operation? These methods already exists! The problem of a plugin failing to "unfreeze" (commit) is already solved. SketchUp already has a way to "break out" of an operation that for some reason never was committed, and start updating the viewport anyway.

[thomthom]

The second param of start_operation is "disable_ui" - which should prevent UI from refreshing for the duration of the operation. I'm not sure why the Outliner doesn't stop refreshing - but I'd call that a bug.

[DanRathbun]

@SoapSkinBubble Because if Outliner or Components Window is open, Ruby may run really slow!

What SketchUp versions are you seeing this on ? And do you see it when using the disable_ui argument in a undo operation ?

Another option is to have some sort of 'panel UI freeze', where (similar to start_operation), a plugin could stop UI updates.

The likely way this would be implemented would be a module method upon the Sketchup module like Sketchup::freeze_gui= true or similar.

I dislike this idea and the way it would be disconnected from operations (whether they be silent or not.)

Since the issue arises whilst creating geometry or objects ( components / materials ) for a model when certain inspector panels are open, a block form method of the model's instance is more appropriate and Rubyish.

Preventing the panels from updating should be done my Model#start_operation itself. The API shouldn't be extended with hacks when the actual problem could be solved instead.

Except that the addition of the disable_ui argument was itself a kind of "hack", rather than fixing the problem. (IF the problem can even ever be totally fixed. Populating data trees, and thumbnail images lists will always slow down a geometry creation loop.)

Super specific implementations, like disabling UI updates from within a code block, would become obsolete once the underlying problem has been fixed, and then make the API harder to understand and to maintain.

Your arguments are somewhat contradictory. You argue FOR a "super-specific" hack (the disable_ui parameter for Model#start_operation,) but then state that these implementations are bad for the API.

In reality, the Model#start_operation ... Model#commit_operation pattern is not Rubyish at all, which is why many coders do not notice it in all the noise of the API documentation, or have issues learning how to use it. (The pattern is needed sometimes for Ruby Tools, etc., but is not new "user-friendly".)

As I mentioned in issue https://github.com/SketchUp/api-issue-tracker/issues/52, I (and others, Daniel Bowring, etc.,) have been advocating an operation block form method since 2012 (or earlier.)

There have also been other discussions (some filed as FR issues,) about a block form method that may disable the UI, but does NOT create an undo operation or fire certain observer callbacks. (Obviously restricted to certain things like updating attributes or loading materials or definitions. I'm against silent operations for main model geometry creation.)

---

We've fixated in this thread on 1a and it's cause, etc.

1b is still valid but is actually unrelated and should be in another issue of it's own. (We asked for this when the Trays were first implemented, so there may already be an internal issue logged.)

[Eneroth3]

Dan, I really don't see how disable_ui would be a hack. The only thing that's odd with it is that it doesn't default to true, but the documentation already explains it is kept at false for backward compatibility. Even if it had been a hack it isn't an excuse to add more hacks. Quite the contrary, the odd default value is an oddity that is forever stuck in the API to ensure backward compatibility. Adding new methods for the sole purpose of being used as a work around for an existing method not functioning properly, would too forever be an awkward addition to the API, making it harder to understand, use, maintain and test.

[DanRathbun]

We disagree then now, as we often do. I feel it was implemented in a "hacky" way, and should have been true as default. It is a hack, IMO, as it's equal to the old metaphor "sticking your finger in the dike to stop a leak", and meets your own rule of not fixing the underlying problem. (I do not agree with their backward compatibility stance, as no one would want it like this.)

This whole thread discussion may be moot. The OP has not said what version there are having "slowness" in , or whether they were properly using an operation. (Ie, no "important reproducible code" to prove the issue.)

[Eneroth3]

If I'm not mistaken we both agree the disable_ui argument is rather odd. It would have made much more sense to have the UI not redrawing within operators from the start.

However, as this is a public API it cannot be changed anyhow without breaking existing code - unknown code. I have at least one extension published myself that rely on redrawing within operators. If I remember correctly the operation is started once the user initiate moving an object, then the object is transformed on mouse move for live updates, and finally the operation is either committed when the user clicks again, or aborted in case the user changes tool. I'm not saying this is a good extension that used the API the way it was intended, but there are extensions like that one out there, used by SketchUp users. The underlying problem couldn't be fixed because it would break backward compatibility.

It is very easy to add new features to a public API, but nearly impossible to remove something once it has been added and is being used (and misused).

[kengey]

I like the way that operations are able to not not redraw the ui (thus redraw). Imagine creating a tool like push-pull, where a user can try different states before finalizing his decision. If, when in an operation, ui updates were not possible, a commit should be done for every intermediate change, quickly filling the undo stack (yes, even transparent operations fill the stack, I believe).

[J-E-L]

I have a complex Tool (3skeng Pipe Tool) that does a lot of "start_operation" and "abort_operation" to do not fill the Undo Stack. This Tool is very slow when Outliner is open. There are 2 Solulions for me.

1. Close ore freeze outliner. (At this Time we tell the Users close the Trays)
2. Fill Undo Stack and insert a lot of unused Component Definitions.

[Eneroth3]

What SketchUp version(s) have you tried this in?

[J-E-L]

It is an old Problem! I see it under SketchUp (Win 10 and OSX) 2016 2017 and 2018. I made two Videos in a smal Drawing to Show the effect!

Slow running Ruby happens if "Outline and/or Componets" Tray is open!

[J-E-L]

Videos.zip

The Video was made with "start_operation('any Name')" If I use "start_operation('any Name',true)", the Selction of the Components is faster, but after ".commit_operation" it need a Long time too update the UI.

On a bigger Drawing it looks like SketchUp is chrashed!

[thomthom]

Logged as SU-40228