Single Window Modeling

[quote=“RStrickler, post:27, topic:5408, full:true”]
Thanks Marlin. I actually seem to be experiencing the opposite of that. It sets the default width, then I minimize both left and right as much as they will go. This still fits everything on both sides. Then when I select an object it expands the right bar about 10% to fit the object properties content. Deselect and it shrinks back.[/quote]

if you set it to the narrowest width then use a dialog that requires more width, it’s going to expand further… so set it to that width and it won’t move around (though there will be empty space with the dialogs not requires that much width)

the commands _Layer and _Properties will give you individual panels which you can put on another display.

Hi Marlin,

I have mixed feelings on single window modelling. It’s a huge improvement when working with one screen, but when using dual monitors (which I’m assuming most people who use CAD packages use) it’s less than ideal. The worst though, is switching back and forth between one and two monitors. In single window modelling the command options in sidebar makes the most sense, but when using dual monitors the popup is the best as having the sidebars taking up space on the main monitor defeats the whole purpose of multiple monitors

It would be great to be able to use the sidebars, but drag them and for that matter all toolbars off to the other monitor, but keep everything pinned together. It just seems odd for a modelling tool to be built around a 1 monitor setup at the sacrifice of dual or more monitors.

Alternately would it be possible to default to the popup when the sidebar is closed and default to within the sidebar when open it’s open? I feel like this would be more natural as you’d get the best of both and in a seamless, responsive manner. This could even make sense in addition to the option of being able to drag the sidebars to a separate display.

Also is there any way to get rid of the viewport options buttons? Using keyboard shortcuts or double clicking the viewport labels to change views and switch between 1-up and 4-up isn’t that hard to do and for my workflow it’s a pretty big waste of space. A balance might involve having those options available from a single button in the top tool pallet or when right clicking the display label?

thanks again for all the hard work and innovative improvements, I really like the overall direction you’re going.

Stuart

There is more work to be done to support multiple monitors. You can open all the panels in the sidebars as floating panels using the Window menu, and put them on a second monitor, but OS X Mavericks refuses to restore them on the second monitor when you reopen Rhino. I have not figured out a workaround to this annoying behavior yet. One workaround (if I remember right) is to turn off “Displays have separate Spaces” in Mission Control in System Preferences. But this disables the Mavericks multiple monitor handling that I prefer.

Thanks for the reply, and yes that’s what I’ve been doing with the floating panels. The weird thing is that it restores all but the main tool pallet when quitting and re-opening Rhino (probably doesn’t need fixing as I’d hope the long term solution would be being able to detach the sidebars or similar)

Also there is a workaround for keeping the floating pallets in the secondary screen, which is to open rhino / your first rhino document from the monitor that you want your tools in, then dragging the main window into the other monitor.

Re-posting a thought here which gained 0 traction when posted as a topic. With an understanding that I may be the only one who cares, here goes again with the “hope” that placing it in the “right” spot makes a difference. I’ll give up henceforth…promise.

When making a projected presentation on the road with Rhino, one typically uses a laptop. With laptops getting smaller all the time, optimization of screen space can be key to the presenter.

Perhaps the following image is not a technical possibility, but in my view something along the lines of it would help under the aforementioned scenario. Thanks!

i get what you’re saying and it does seem as if some of the toolbar (containing the sidebar switches/ ortho-snap-history-etc) could be consolidated with the window frame options (viewport controls)…

that said, i’m not entirely sure if there are other options which may go there in the future but if so, it’s probably wise to leave some space for future additions.

–anyway… about presenting to clients… i had a meeting on monday and set up rhino like this.

that’s my entire laptop screen… no crops (though scaled down for posting here)

• full screen
• right-click on toolbar → hide toolbar
• i toggle the sidebars via screen edges (_ToggleRightSidebar _ToggleLeftSidebar)
• my osnaps are toggled with a 3finger downswipe (_ToggleOsnapPanelUnderCursor)

you can also toggle and individual layers panel and properties panel if desired…

to me, the presentation possibilities with rhino are pretty excellent as you can get rid of almost everything except the viewport while still having fingertip access to all of if.

1 Like

Clever Jeff, thanks! I learned something. I’m a little more caveman like…I see it I click it :wink:

ha. yeah, I’m caveman like too.

it’s just that in the case of rhino for mac, I’ve been using it for quite a while now – prior to a lot of these toggling options being available.

and they didn’t come in all at once so I was able to learn each feature one at at time as they were implemented/tested instead of needing to take it all in at once.

Loving toggling the right toolbar via the right screen edge. Very productive/slick. Thanks!

Trying to create a toggle for the bottom screen edge. Can’t get it to work “smooth”…it’s finicky…have to wobble the mouse around a bit. Takes some effort. Am I missing something? Seems like there is “interference” with window resize and the bottom edge, but I do not have that problem at the right.

The cool part about right-screen-edge/ToggleRightSidebar is that one is going over there anyway, so it’s a quick “bang/bang” to toggle on/off. Can’t seem to make something similar (bang/bang) happen at the bottom edge. Takes effort to set off the macro.

hmm… yeah. i see what you’re saying… i’ve never used the bottom screen edge but i just tried and and only got it to activate a macro twice out of maybe 25 attempts.

@marlin anything you can do to make the bottom screen edge more responsive?

And it would be great to utilize all four edges.

Regarding the TOP edge, I found I did not want to use it because I set off the macro too often while going after a menu. LEFT edge (and this is mostly my doing since I like a hidden OS X dock on the left I use for maximized application/document switching, rather than other methods) I would trigger its macro when going after the Dock. Anything clever under this scenario that would help? Can it recognize a “bang” movement?

FWIW - I can’t use a track pad. Makes me nauseous. No idea why or how many are like me. Multiple button old school mice work for me…and the screen edges are like having 4 more buttons. Was never fond of remembering keyboard shortcuts.

I’d like to have a quicker and more dependable response on ALL edges (side edges also). I feel they are a bit to unreliable at times… And the bottom edge isn’t responding at all…
The left screen edge on my 27" monitor isn’t working either, when I have my laptop lid open (my laptop is on the left side).

It would also be nice to have the side edges divided in half. That way you could assign two macros to both.
Thanks :smiley:

Philip

Philip’s thought made it occur to me:

  1. If the Top edge macro ignored the menus such would solve that problem.

  2. If the specific edge shared with the OS X Dock, when set to automatically hide/show, could ignore the dock region such might help.

The problem with the bottom edge detection is fixed in the 2014-05-20 WIP release. Exotic suggestions like trying to detect whether the Dock is visible or not are just not possible.

Yea, I sorta had that feeling post post. For the Top edge, would ignoring the menus qualify as exotic?

1 Like

The screen edges code has been tweaked in the 2014-05-20 WIP release and works better. Detecting a bottom edge touch is now reliable.

I’m not sure what you mean here. Are you asking that top screen edge touches get ignored on the left half of the top edge where the application menu is? If that’s your question, that’s not possible either. The actual display of the menu is up to the Apple frameworks, and I am unable to determine how wide it is. Also the right side of the top edge gets filled up with controls of different sorts, and I don’t know what is there, either.

Using the top edge is probably only practical for the secondary screen. It’s included for the primary screen mostly for consistency.

As an alternative, you might consider getting a mouse with lots of buttons. Logitech has some good candidates.

Correct. Sorry for not including an illustration. A method to determine the space illustrated in yellow above would make Top edge practical on the primary screen. Not being a programmer, however, I take your word for it. Sounds exotic. Makes useful sense for a secondary screen, and consistency is logical.

Indeed! Uncanny timing. Just yesterday my trusty approx. decade old top of the line (at the time) Logitech died. Ran out and bought a Logitech Performance Mouse MX as replacement. Per Logitech’s web site it has 9 buttons. My question is - how many can I make usable in Mac Rhino?

So, without Logitech Control Center installed, beyond left/right/middle(wheel down) clicks, Rhino automatically responds to the indicated Performance MX button numbers shown below.
.

Trying to get Rhino to recognize the remaining buttons, which are wheel left, wheel right, and “tilt.” (Logitech calls “mouse tilt” a button…and that equals 10 buttons total per my math???) I installed Logitech Control Center. With LLC installed I could not get Rhino to respond to anything beyond left/right/middle in the default config. I created a Rhinoceros application config in LCC and played around with several settings for the buttons without success…Rhino recognized nothing beyond left/right/middle until I uninstalled LCC.

It is quite possible, however, that I did not try hard enough, missed something, etc… I wanted to ask first before continuing to bang my head.

Thank you!

RE: Build 2014-06-30 Fixes - The top screen edge macro now ignores top screen edge touches directly above the application menu. These touches only invoke the macro when
you touch the top screen edge to the right of the Help menu item. This
makes the top screen macro much more usable.

YES! YES! YES! Thank you for that.

Personally, while I love using the the right screen edge tough to trigger _ToggleRightSidebar; still, could more control over the right sidebar be an enhancement to some, if possible. Perhaps the following is in the works…? In future is it going to be possible to define which of the icons is displayed - turn some off/on?

To optimize screen real estate further while the sidebar is open, would it be possible to enable further reduction of the width of the sidebar even if such were to create a crop condition (allow the crop) such as is illustrated below.

At present, as far I I can tell, width is constrained by the 8 icons, etc.

Yes, something like that will be implemented later.

I don’t think this is a good idea. The general scheme is to allow UI features to be completely visible or completely hidden, with several options for temporarily show a panel. Quibbling over a few pixels by hiding part of a panel is going to cause problems.

Compare your screen shot above with another screen shot you posted - the first screen shot in this thread. They are almost identical, but in the other thread you were wondering where the color well for Display Color had gone. In the other thread the right half of the panel had been inadvertently been hidden by a wide layer name and you needed to drag the panel wider to see the color well. I think partially hiding a panel will lead to many support problems like this.

Currently the minimum width of the right sidebar is fixed to a specific number of pixels that will prevent the contents of a sidebar panel from being hidden. It is not bound to the number of available panels in the sidebar.