I have a feature request: Please allow the document windows to be opened in OS X’s Fullscreen mode (I don’t mean the DT-internal fullscreen mode that opens with cmd-F7).
This was shortly possible in El Capitan before v2.8.7, see this forum post.
Thanks a lot!
EDIT: To elaborate a bit. I think the intended behavior of OS X’s fullscreen mode is that when an app is in fullscreen mode, all new windows also open in fullscreen mode (in a new space). All stock apps of OS X and all the third party apps I tested behave that way. So in a way DT now shortly behaved as OS X intended, even if this was not the intended behavior from the devs.
In my opinion, it doesn’t really makes sense to have the main window in fullscreen mode and then have a document window in front of it, and it didn’t really make sense with Yosemite either. If I click then on the main window, the document window vanishes behind the fullscreen app. The only way to get it back to front is via the menu bar. That’s really odd and no other app I know does that.
My proposal is to make DT behave like the rest of the apps (that is like pre v2.8.7 unter El Capitan). But maybe there is a way to have an option in the preferences (or maybe just a hidden preference) to toggle this behavior, something like „Never open document windows in fullscreen“, for those who find it useful.
I understand that others might find the current behavior useful.
Maybe there can be found a compromise: the document windows open in front of the main screen, just like they do now. But I can put the document manually into fullscreen by pressing the green button. That way, both parties get what they want.
For what it’s worth, I would vote for the ability for document windows to be opened in fullscreen mode, because that would enable them to work properly with the new split-screen mode of El Capitan.
I usually prefer to take notes into a separate document window, and would like to be able to have a split-screen working environment with a PDF on one side and the DEVONThink document on the other.
My opinion of the fullscreen behavior was primarily based on my use pre-El Capitan. Having used El Capitan for a while now, I can fully appreciate the utility of the split-screen mode.
Additionally, if DEVONthink did allow for document windows to be opened fullscreen, the El Capitan feature of allowing the user to a) hide the toolbar, b) maximize the database window size (not full screen), then c) open documents in a smaller window, does 99% of what I wanted before El Capitan. That should appeal to anyone desiring the current window behavior.
I believe allowing document windows to be opened fullscreen will appeal to a larger group of users, thus I fully support this request as well. Or put more succinctly, I’ve changed my mind!
Greg, thank you very much for coming back and posting your revised opinion.
Has there been any discussion between the developers about this? Any results that might be worth sharing? I just spent a whole semester wishing I was able to make those windows fullscreen and am very eager to hear any news about this.
I appreciate the reasoning behind two different full screen modes. Both of them are however non-standard. The Document full screen is specific to DT. The Window full screen is common to all apps, but the path+terminology to apply it is non-standard (View->Full Screen->Window instead of View->Enter Full Screen). This plays havoc with my standard keystroke settings for all apps (command-escape to enter/exit full screen window mode).
Please consider fixing the inconsistencies in position of menu and terminology for the Window Full Screen. I propose the layout below is fully consistent to (the majority of) apps on macOS.
View->…
View->Customize Toolbar
View-> —
View->Enter Full Screen // (standard) menu choice to put a WINDOW in full screen
View->Document in Full Screen // menu choice to put a DOCUMENT in full screen
But as such, it allows that DTP is granted grace to avoid finding proper ways to conform to well-respected standards. I’m raising havoc against this as a respectable option.
Allow then that I use “convention” rather than standard.
The statement that a given app can be customized and the statement that other apps do not follow a convention are invalid to support that an app that does not follow an otherwise observable convention cannot be questioned for doing so.
What objective reasons stand against my proposal? What functionality of DT will be broken when convention is restored instead of continuing with the current method?
I am used to the current way … or … You can customize around it … or … A few other apps don’t do it that way … Are not objective reasons why it cannot (or indeed should not) be changed.
I am rallying on one thing here, the use of non-conventional placement and menu phrasing in the UI for a user to create a full screen window.
Sorry that you deleted your posts. I don’t see them as stepping on toes. Rather as challenging my own oft-stubborn laments with equally-held passion.
It is not that I despise DT and want to destroy it. It is that I am oft frustrated by how inept some aspects of it are in its UI design and want to make it better.
In any case, a “nuke and repave” operation can be a good thing for this, as one of my favorite apps demonstrated when it went through a version upgrade last year.