Post by m***@nokia.comPost by Till Oliver Knoll- "Lion" fullscreen support
- "Automatic document save" ...
...
- "Sandbox model" - at least make sure the file dialogs are called from the
proper OS process having file privileges
Post by m***@nokia.comDigging up an old thread, but I just noticed it and wanted to comment.
These are features I would like to see in Qt 5 as well.
It's been a while ago since I posted this ad-hoc list of "Lion features". In the
meantime I have done some investigations on my own, on an "application level".
Here are my findings (roughly from memory, details to be elaborated/looked up
elsewhere):
- "Full-screen support"
That is no big deal, code-wise: Basically it boils down to setting a "window
flag" NSWindowCollectionBehaviorFullScreenPrimary. In my own code I did this
within a *.mm ("objective C++") file, with OS X API calls such as:
NSView *nsview = (NSView *) mainWindow.winId();
NSWindow *nswindow = [nsview window];
[nswindow setCollectionBehavior:NSWindowCollectionBehaviorFullScreenPrimary];
And that's it! Almost. It adds this "fullscreen" icon to your window title bar
with which you can toggle into/from fullscreen.
If you want to control this from your own code - e.g. from a separate "Window"
or "View" menu entry - you can call the following OSX API. Inside some slot:
QMainWindow *mainWindow = ...;
NSView *nsview = (NSView *) mainWindow->winId();
NSWindow *nswindow = [nsview window];
[nswindow toggleFullScreen:nil]; // That's the magic here!
The following code is useful to figure out the "fullscreen" state:
QMainWindow *mainWindow = ...;
NSView *nsview = (NSView *) mainWindow->winId();
NSWindow *nswindow = [nsview window];
NSUInteger masks = [nswindow styleMask];
bool result = masks & NSFullScreenWindowMask;
A few #ifdefs here (#if MAC_OS_X_VERSION_MAX_ALLOWED >= MAC_OS_X_VERSION_10_7 is
your friend), a few runtime checks there, and my code compiles and runs on both
OS X 10.6 and 10.7 (on 10.6 off course the fallback is the available
QWidget::showFullScreen mechanism).
So my wish here would be that "Qt does all that for me" ;) That is when my Qt
application runs on Lion (runtime checks!) it would default to the "Lion
fullscreen mode" upon QWidget::showFullScreen(), or optionally use the existing
fullscreen approach when some additional Qt style flag would be set (like
"PlatformFullScreen" vs "QtFullScreen" or whatever...).
However with a Qt 4.7.3 (and also with Qt 4.8 Beta I think) I had some issue
with the "native" (or "unified") toolbar, especially when trying to toggle the
visibility of the toolbar: sometimes the toolbar was not properly restored
("invisible"), even though the Qt API claimed it was "visible". And it somewhat
flickers when going from "fullscreen" back to "normal" (well, it's more like
some "animation" which makes it first invisible and then visible again).
I tried to hack around this by setting the "visible" state explicitly. Also
calling setUnifiedTitleAndToolBarOnMac() when changing state seemed to help a
little.
What I absolutely did not manage was something like "Show toolbar in normal
view, but hide it when going fullscreen - show it again when going to normal
view again". After toogling back and forth all of a sudden the toolbar would not
show up, or only a few pixel height toolbar was visible etc.
I think in general that "unified toolbar" code should be looked at again when
testing "Lion fullscreen support"... ;)
Also restoring directly into "Lion fullscreen mode" upon application start did
not work right away, as the "fullscreen animation" seems only to work once Qt
has painted the window at least once. So my workaround here was to use a QTimer
(in the slot I would call my own "showFullScreen" flavour) with a "visually
pleasant timeout" of 200 ms (a value of 0 caused "flickering") in the c'tor of
the QMainWindow. Maybe also something where Qt could improve (note again that
the ordinary QWidget::showFullscreen() works flawlessly here!).
- Automatic Document Save / Resume State
I haven't looked into this issue yet, as it basically expects your application
to use the NSDocument model approach (which Qt applications don't have). So this
would involve much more work. I think basically provide a "fake" NSDocument
structure and map all OS X calls to some Qt signals (from a new QDocument
class?) which would inform the Qt application "now is the time to save into this
file path!" or "Please restore your state from that file path!" etc.
Basically replicating Apple's API, but in a platform-independent API ;) As I
said, I have no idea how complex - but certainly no free lunch...
- Sandbox model
So this should be easier! As a matter of fact this is somewhat
language/framework independent, as it mostly has to do with providing an XML
"entitlements" configuration file (which goes into the application bundle) and
code-signing your binaries/bundle.
http://developer.apple.com/library/mac/#documentation/Security/Conceptual/CodeSigningGuide/
For instance you can grant your application the right to read/write files as
specified by the user (via file dialog). From the Apple docs:
"Any time an application running inside a sandbox invokes an NSOpenPanel or
NSSavePanel dialog, rather than showing the panels directly, AppKit
automatically asks the Powerbox to present the dialog. From a developer
perspective, there are no code changes required in terms of how these panels are
used; this process is fully transparent."
So as long as Qt/Mac would use NSOpenPanel etc. properly there should be no code
changes required - in theory!
In practise I found out that Qt crashes as soon as I request a (native!) file
dialog. Details here (unfortunatelly I received no answers yet):
http://lists.qt.nokia.com/pipermail/qt-interest/2011-August/035597.html
- GUI
I guess widgets adaptions are already being worked on. The only widget I noticed
so far which requires some touch are the scrollbars which now should auto-hide
under "Lion".
Cheers, Oliver