Window close button not showing a saved document properly

This is after i saved my file and the title bar no longer shows “filename.3dm — Edited”. The dot in the close button is supposed to disappear when the document is saved, like this:

(this last screenshot was from a new blank file)

This seems to be an intermittent problem i’m experiencing with some of my files that i’ve been working on for some time. If i create a new file, it seems to behave correctly… not sure if it’s maybe related to file size?

Not sure, but wouldn’t this be an OS issue as opposed to a Rhino issue ? But it probably only happen to Rhino files … ?

First is new rhino

This is when I hover over

I never see them grey or with dots?

randy

I use the “Graphite” appearance (look under System Preferences -> General), which gets rid of the red-amber-green buttons, which i find distracting. The dot is a new thing introduced in Snow Leopard, i think. It’s meant to indicate that a file has been modified and has unsaved changes. It’s only in the last couple of builds that i’ve noticed the dot no longer disappears when files are saved.

Cool, I like colour though. Glad to know that.

Rhino does not directly control whether the dot is visible or not in the close button. When the problem you describe happens again, what does Edit > Undo say in the application menu?

When there is an undoable action, it will say something like Edit > Undo Circle if the last command you ran was the Circle command.

When you say that you saved your file, I assume that you mean that you selected File > Save in the application menu. If you did something else, please describe what you did.

Yes, i did File -> Save (or Command-S) to save the file.

My Edit menu shows Undo Hide as my last action.

I forgot this, but saving a file does not erase your Undo stack. Was Hide the last command you ran before performing the Save?

I cannot duplicate this. When I save a file, the black dot disappears from the red close button.

Please repeat your test with the 2014-07-28 WIP release and post your OpenGL settings.

Yes, i believe it was.

For what it’s worth, the file that exhibits this behaviour is HUGE. Loads of layers and iterative work in progress. Probably hundreds of objects. When i made a duplicate of the file and deleted all the layers, the little black dot started behaving normally.

Here are my OpenGL settings:

Software information

Software versions
Rhinoceros version: 5.0 Wenatchee 2014-07-28 (519)
OS X version: Version 10.9.4 (Build 13E28)

Plug-ins
None

Hardware information

Computer hardware
Hardware model: Macmini4,1
Processor: Intel Core2 Duo CPU P8800 @ 2.66GHz
Memory: 8 GB
Architecture: Intel 64 bit

Video hardware
Graphics: NVIDIA GeForce 320M 256 MB
Memory: 256 MB
Screen size: 1920 x 1200
Displays: Cinema HD

Third party kernel extensions
None

USB devices
Kensington: Kensington USB Mouse
Mitsumi Electric: Apple Extended USB Keyboard
Apple Computer, Inc.: Apple Cinema HD Display
Apple Inc.: Bluetooth USB Host Controller
Apple Computer, Inc.: IR Receiver

Bluetooth devices
None

OpenGL information

OpenGL software
OpenGL version: 2.1 NVIDIA-8.24.15 310.90.9.05f01
Render version: 2.1
Shading language: 1.20
Maximum texture size: 8192 x 8192
Z-buffer depth: 24 bits
Maximum viewport size: 8192 x 8192

Implementation settings
Use texture compression: No

Appearance settings
Antialiasing: None
Mip map filtering: None
Anisotropic filtering: None

This file also exhibited this behaviour under Mavericks (10.9.4) and the latest Yosemite beta, using the 2014-07-28 build of Rhino.

Sorry to bump this old thread, but i found a little more detail on this, from Apple’s UI standards.

This is the header bar from a file i’m currently working on. I just saved it, but the dot still appears in the close button. This doesn’t always seem to be the case, as newly opened files often work as they should, where the dot disappears once the file is saved.

From Apple’s UI guidelines:

As much as possible, avoid displaying a dot in the document window’s close button. In earlier versions of OS X, a document with unsaved changes always displayed a dot in the close button, which indicated the “dirty state.” To encourage users to embrace the Auto Save experience, you want them to get out of the habit of checking the close button to see if they need to save their work. In general, only apps that are not document-based should regularly display a dot to indicate unsaved changes.

I wonder if it has something to do with AutoSave or TimeMachine backups. I’m working with two machines… my desktop machine and a laptop. I store all of my files on my MacBook Pro, so if i ever have to work at home, i’ve always got them on hand. So any files i’m working on are usually accessed remotely from my desktop. Both machines are running the latest version of Yosemite.

At any rate, it seems that Apple wants developers to get away from using the dot entirely since implementing AutoSave. It’s a little thing, but little things bug me. A lot. :wink:

the saved state dot works properly for me (for what it’s worth)… that said, i’m not doing anything with remote accessing other than iCloud/dropbox.

As I stated earlier, Rhino does not directly control whether the dot is visible or not. It is Apple’s frameworks that decide whether to show the dot or not. Rhino has been using Auto Save since it’s introduction in 10.7

I suspect that working with remote files is part of the issue here, and it would help if you describe how to duplicate the circumstances when saving your model continued to show a black dot. If you are working on a remote file, then I don’t think Auto Save will work for that file. It would help to have a detailed description of how to duplicate this.

Was there an outcome to this? I just logged in to report it but found others had already. My file is a small local file on a Macbook Pro. It’s disconcerting to see a dot because that means “there are unsaved changes”. If it’s not possible to control it then I suppose there’s nothing can be done, but it’s the first time I’ve come across a problem with this button not changing state and I’ve used a fair few apps.

Not a showstopper, by the way, since once you know it behaves like that then you can click save and ignore it.

Best regards

My spec is

Software information

Software versions
Rhinoceros version: 5.0 (5A854)
IronPython version: 5.1.2015.131
Language: en (MacOS default)
OS X version: Version 10.9.5 (Build 13F1077)

Plug-ins
None

Third party kernel extensions
com.deterministicnetworks.driver.dniregistry (1.0.7)
com.deterministicnetworks.driver.dne (1.0.18)
com.citrix.driver.net6im (1.1.9)
com.Cycling74.driver.Soundflower (1.6.6)
com.McAfee.kext.AppProtection (1.1.0d1)
com.mcafee.kext.Virex (1.1.0d1)
com.sierrawireless.driver.SierraDIPSupport (1.0.0)

Hardware information

Computer hardware
Hardware model: MacBookPro8,1
Processor: Intel Core i5-2415M CPU @ 2.30GHz
Memory: 8 GB
Architecture: Intel 64 bit

Video hardware
Graphics: Intel HD Graphics 3000 512 MB
Memory: 512 MB
Screen size: 1280 x 800
Displays: Color LCD (114dpi 1x)

USB devices
Apple Inc.: FaceTime HD Camera (Built-in)
Apple Inc.: Apple Internal Keyboard / Trackpad
Apple Inc.: Bluetooth USB Host Controller
Canon: CanoScan
Samsung Electronics Co., Ltd.: M2020 Series
Mitsumi Electric: Apple Optical USB Mouse
Apple Inc.: Apple Keyboard
Apple Computer, Inc.: IR Receiver

Bluetooth devices
None

OpenGL information

OpenGL software
OpenGL version: 2.1 INTEL-8.24.16
Render version: 2.1
Shading language: 1.20
Maximum texture size: 8192 x 8192
Z-buffer depth: 24 bits
Maximum viewport size: 8192 x 8192

Implementation settings
Use texture compression: No

Appearance settings
Antialiasing: 4x
Mip map filtering: None
Anisotropic filtering: None

I just tested this locally. It works as expected.
It seems to be that it doesn´t show the correct status when opening from and saving to a Shared Drive (AFP).

OS X 10.11.6 (“El Capitan”)
Rhino 5.2.1