Bug: Display corruption in fullscreen graph window with OS X, and a few other issues

[Nils Enevoldsen]

I am using Stata 13.1 on OS X 10.10. When the graph window is in Full Screen mode, the top area of the graph is corrupted. Specifically, a portion of the bottom of the graph is duplicated at the top of the graph. The portion of the top of the graph that is affected is approximately as thick as the Stata window toolbar (not the menubar) would be if it were not hidden by Full Screen mode. The graphical bug can be temporarily fixed by entering and exiting graph edit mode, but can be made to reappear by using Mission Control to switch away from and back to the graph window. If you have trouble replicating, I may be able to provide exact replication steps with screenshots.

While we're at it, another full screen issue I experience is the height and functionality of the tabs in the Do-File Editor. They are narrow cursor targets, because when the cursor hits the top edge of the screen the menubar and toolbar slide down, obscuring the tabs. Safari and Finder, for examples, alleviate the first issue by not having tabs butt up against the top of the screen, and alleviate the second issue by sliding down the tabs when the menubar and toolbar descend. You might reconsider whether the toolbar should be hidden at all in full screen mode. Maybe it could force small icons & no text in full screen mode, instead of disappearing entirely.

Pinch-to-zoom, in at least the Do-File Editor, does not update the zoom selector tool in the toolbar.

One feature I would use extensively for my workflow is an indicator in the Do-File Editor for whether Stata is currently running commands, or has completed without errors, or has completed with errors. As it is, I frequently run a selection from the Do-File Editor, move to the main window to check whether it has completed, and switch back to the Do-File Editor. A status indicator would smooth my workflow a lot.

Sometimes when running a selection of code that generates a graph from a full screen Do-File Editor, the Graph window opens as a window on top of my full screen Do-File Editor. I'm not sure what the proper behavior is, but perhaps it would be opening the Graph window in full screen mode without changing spaces.

[Nils Enevoldsen]

In addition to the issues above, I also sometimes see a visually bugged fullscreen window layout in the results/command window. This happens intermittently when I fullscreen the window. Restoring and re-fullscreening the window sometimes fixes the issue. A screenshot is attached showing the command window floating above its intended position.

This may have something to do with the resolution change when using my external monitor. My notebook's scaled resolution is 900 vertical pixels, my external monitor (depicted in the screenshot) is 1050 vertical pixels.

[Chinh Nguyen (StataCorp)]

We'll investigate the corrupted graphs in full screen mode. That problem seems to be unique to Yosemite as I don't remember it happening in Mavericks. We don't see the problem here but we do see some visual "tearing" of the top part of the graph as it is being animated to full screen mode which resolves itself once the animation has finished. My first impression is that it's a Yosemite bug and here's why I think so. Stata's graph window supports live resizing. When you resize the window, its contents are updated as the window is resized. Some of Stata's graphs can be very complicated and take a long to render. So what Stata does is store a bitmap copy of the graph in memory and rather than rerender the graph as the window is being resized, it just renders a scaled bitmap copy so that you get a rough preview of the graph as it's being resized. When the window is finished resizing, Stata then rerenders the graph. The visual tearing I see when the graph is resized in full screen mode indicates to me there is a problem with the bitmap rendering in full screen mode on Yosemite.

We're investigating how to handle the menubar and toolbar sliding down. Apple doesn't provide a notification when that happens (which is odd because they're pretty good about that) so we have to figure out how to detect it happened.

The pinch to zoom bug has already been fixed but is awaiting to be released in a future update.

The Do-file Editor progress indicator sounds like a good idea and we'll consider it.

The problem you're seeing with full screen mode and the Results and Command windows is a bug in the splitview control that we use. Apple's splitview tool is very limited in its abilities so we use a third party one. However, the third party one predates full screen mode by many years and we haven't been able to figure out how to fix it.

Stata is different from most other applications in that there are many different kinds of windows and I don't think that Stata is well suited for full screen mode. Full screen mode really only makes sense in Stata if Stata's interface was completely tabbed so that there are no separate windows.

[Nils Enevoldsen]

I think your choices for fixing the tab strip sliding down are:

1. Use NSToolbar, or
2. Use the undocumented "rvlf" Carbon events

Except for the occasional annoyance, like those I have mentioned above, I actually love using Stata in fullscreen. Just fullscreen each window, and navigate between them with the keyboard or with gestures. It feels like using a tabbed interface with invisible tabs. If you activate Mission Control, the "tabs", i.e. thumbnails, even become visible. It works a treat, and feels roomy and clean. If I'm working in the results window, I know that my data browser is always one space to my right, accessible by a swipe or a Control + →. Toggling between windows in windowed mode felt bouncy, and if I wanted to switch to the results window I had to locate it first, either by moving windows around, by activating Mission Control and hunting for it, by stepping through Command + ~ until I stumbled across it, or, worst of all, by fiddling with the exact window locations to ensure that each window has a chunk that peeks out from behind all other windows. Stata's ⌘ + # shortcuts would compensate, except that of course they don't work when Stata is not the active application.

Anyway, that's why I like fullscreen. :-)

[Chinh Nguyen (StataCorp)]

Using NSToolbar doesn't solve the problem with the text at the top of the editor from being obscured by the toolbar. You have to slide down the tab control and the editor content.

The undocumented 'rvlf' events are kind of helpful but pretty much a hack (and requires linking in the Carbon framework which Stata hasn't ever required). The biggest issue I've seen is that I'm asking the OS where the full screen mode toolbar is and it's telling me the toolbar is 6 pixels higher than it really is (which I've verified by taking a screenshot and looking at it in Photoshop). I can hardcode the 6 pixel adjustment but that may not be future proof. I need to know why the OS is giving me the wrong coordinates. Also, the animation of the menu and toolbar sliding in and out suddenly becomes very janky when it has to animate the Do-file Editor tab control and content down and up too.

[Nils Enevoldsen]

Using NSToolbar doesn't solve the problem with the text at the top of the editor from being obscured by the toolbar.

That's not a problem. Obscuring the top few lines of content are how all auto-revealing fullscreen toolbars are supposed to work. Don't slide down the content. The proper behavior is implemented in Xcode, Finder, Safari, Mail, Calendar, Maps, iBooks, Pages, Keynote, Numbers, etc. (The iTunes behavior seems uniquely poor. Don't copy iTunes.)

Obscuring the tab strip is the problem.

In fact, even that is only a problem due to the proximity of the tab strip to the top of the screen. If the tab strip were lower – say because there was a toolbar above it – then you'd have a choice between two reasonable behaviors: (1) slide down the tab strip when the menubar is revealed, a la Safari and Finder, or (2) cover the tab strip when the menu bar is revealed, a la Numbers. The former option is probably the better one for a window such as the do file editor.

I agree that relying on undocumented Carbon events is to be avoided if possible.

[Chinh Nguyen (StataCorp)]

Oh, well in that case, that's easy. I never use fullscreen mode and didn't notice that the content was obscured by the toolbar. I had been working on making sure the content isn't obscured which I got working but like I said, the animation is janky.

I should point out that the toolbar full screen accessory view API used to achieve this has been deprecated in 10.10.

[Nils Enevoldsen]

One feature I would use extensively for my workflow is an indicator in the Do-File Editor for whether Stata is currently running commands, or has completed without errors, or has completed with errors. As it is, I frequently run a selection from the Do-File Editor, move to the main window to check whether it has completed, and switch back to the Do-File Editor. A status indicator would smooth my workflow a lot.

I was pleased to find this implemented in Stata 14. Thanks!

[Nils Enevoldsen]

FWIW, the splitview bug in fullscreen appears to be gone. I would usually experience it a few times a day, but I haven't experienced it in the past few days. I'm guessing it was a change to fullscreen behavior in El Capitan that fixed it.