Received! I can confirm the the bug is also ocurring in my computer. I’ll let you know when this is bug fixed.
@eugen, I just let you know that in the new VisualARQ 2.0 Beta, the VisualARQ object insert dialogs are now dockable dialog for a better workflow:
Thanks for these! =]
I’m insistive, I know:
Could you also please make the Styles dialog window non-modal, too, and resizable, while you’re at it?
As of now, it’s not possible to navigate the viewport when the styles dialog is open.
Clumsy, because for example, when you want to change, say, a wall style, and work on properties like, say, the section hatch pattern, you often might want to zoom/pan around the VP to check the hatch result, but you can’t.
As mentioned: no scene refresh will be triggered until Apply is clicked in the dialog, so non-modality shouldn’t be a performance problem, right?
Resizability of the window: I already had the case of running short of space in the top left area where the styles are listed because I needed so many window styles.
I for my part generally dislike non-resizable dialogs a lot. The Rhino options window is also non-resizable in V5, but they changed this in V6 WIP.
By the way: are you planning to release a VA version for Rhino 6 WIP anytime soon, or are there still too many SDK changes?
Thanks a lot!
Plese, keep being insistive… This is the only way we know which direction to take.
I’ll take a look at your suggestion. There are two different ways to implement this:
- Convert the style editor into a dockable panel. This option requires too much work, and having a panel with an “Apply button” seems weird. Also, we should support running command while the panel is shown.
- Keep the dialog as a dialog, with the OK, Cancel and Apply buttons, show them using the same commands, and call any Rhino getter until the dialog is close. The getter is necessary in order for the command to run until OK or Cancel are pressed, and to allow the user to interact with the viewport. This option seems pretty easy to implement.
I’ve tried to do this so many times, but there are too many dialog tabs, and we need then to be able to adjust to the new size, or the dialog will be ugly, or the controls will be clipped. Our plan for VisualARQ 2.x is to reduce the number of styles editor tabs, and use only tabs with the same properties control that we are using in the dockable panels, which already is resizable.
We’re waiting until Rhino 6 WIP C++ SDK gets frozen. Currently, the C++ SDK is changing every day, so we’ll need to update our code to compile with the new changes every time a WIP is released. So if a WIP is released on Tuesday, we pick the new SDK, change our code to compile against it (this may require seconds or hours, who knows), then test it, build the public version and upload to the web. If we are lucky, this process could take minimum a full day of work of a developer. Currently, we prefer to focus all our resources in improve VisualARQ 2.0 for Rhino 5. This is the same reason we’re not working on the Mac version yet.
“having a panel with an “Apply button” seems weird”
Revit has this… as an ex-revit user it doesn’t seem weird to me… though it does seem counter intuitive to have to click ‘apply’ to commit things since there is also an option to have ‘mouse-un-focus’/‘mouse-focus-viewport’ trigger apply automatically…
That said; please continue NOT taking your queues from Revit!
That’s true, but the dockable panel in Revit only edits the currently selected objects, not families or types. The type edit dialogs are modal dialogs, while the family editor is an entire work space change.
Using the edit box un-focus event to apply changes sounds good, but there could be performance issues, because if you want to make several changes in different edit boxes you will need to wait for the regeneration of all affected objects. We can use a timer so the change will only be applied if you don’t do any new change in X milliseconds, or do not apply if the focus is going to a new control on the same panel…
I see what you’re saying, and totally agree…
I think the modal issue is only an issue because/if it breaks the workflow.
The (Revit) print dialogue for example; its modal, but you can still zoom in/out in the viewport (print dialogue stays in the way).
Seems crazy to need the viewport mid-print, but sometimes you forget something… or the sheet doesn’t look like it has enough revisions (so you zoom in to check)… alternative is you stop the print workflow, cancel your way out, wait for viewport refresh, zoom, check, reprint…
Not sure my print dialogue example is a terrific example; but Eugen’s example of being able to navigate the viewport definitely seems relevant.
Good news: in the next VisualARQ 2.0 Beta the styles editor is no longer modal. I’ve done what I explained some post above: apparently the dialog is modal, but the Rhino frame is not disabled. Apparently everything works fine. During the command, you can:
- Rotate, pan and zoom viewports.
- Change display modes.
- Work with the layers manager.
- Work with the levels and sections manager.
- (Probably all you can do while running any other command like “Line”).
As soon as you try to run a command, the styles editor is automatically closed and all non-applied changes are discarded (like if you press the “Cancel” button).
If during the Beta stage we find problems with this feature, we’ll roll-back it for VisualARQ 2.0 Final Release.
I hope we can release VisualARQ 2.0 Beta 5 this week.
Very good news, thanks a lot!!
Resizability: I see the issue, and you seem to have experimented a lot already. However, almost always a feasible solution can be found, I trust. There could be minimum sizes etc.
Did you think about that wish of mine to have one generalized styles window? One that shows walls, windows, … all of them.
Somewhat like the Rhino options dialog.
SDK changes: I totally understand. Never mind.
Eugen, we will consider this feature for future versions. However, right now if you run the vaStyleProperties command on a multiple selection of VisualARQ objects, the Styles dialog opens for each style of the selected objects:
The styles dialog is non-modal now, that’a nice! Thanks!
Nice release! =)
Here’s another small one:
With vaProfileFromCurve, custom Window/Door profiles can be created. They appear then in a list in the window/door style dialog.
When you want the profile to change at a later stage, you pick the curve again with vaProfileFromCurve and use the same name. Still, the windows/doors that are based on this profile do not update automatically. It’s necessary to change the window’s profile to another profile, than back to the overwritten profile.
Could be simpler…
Hope this makes sense.
Hi Eugen, that makes absolutely sense. We need to review this.
Hi Eugen, this is an old topic, but I just let you know that VisualARQ 2 fixes that bug.
Thanks a lot! =)
Got another wish:
It should be possible to rectangle-select multiple handles at once.
It is possible already to select many by using SHIFT-LMB, but of course it would be more comfortable to do this with one stroke.
Just as a reminder: the small bug with one of the handles pointing away still persists.
Just noticed there’s a glitch with the viewport ruler. It sometimes redraws wrongly, depending on the camera direction.
Hi Eugen, that would be useful, indeed. However this request is technically difficult to implement, since we should avoid situations such as selecting a vertical control arrow and a stretch control point at the same time, which do different things. We will study it.