[vbox-dev] MacOs Native Fullscreen
Sergey Dubov
Sergey.Dubov at oracle.com
Mon Apr 29 14:02:02 GMT 2013
Lucas Dupin <oi at lucasdup.in> писал(а) в своём письме Mon, 29 Apr 2013
16:20:26 +0400:
> Hi Sergey,
Hi.
>> I just have a few words to tell about native MacOS X fullscreen feature:
>> 1. Within the current Runtime UI architecture having native MacOS X
>> fullscreen support is not something easy (if possible at all).
>> Fullscreen-mode is not just "an arrow at the right corner", its
>> internal mechanism which takes into account different aspects of
>> VirtualBox GUI behavior.
>> When GUI changes mode representation (from normal to fullscreen,
>> seamless or scale) through the menu action it recreates internal
>> Runtime UI logic >>and finally machine-window(s), so entering
>> fullscreen "the true Mac way" is not quite possible in such case.
>> Note: The VirtualBox Runtime UI architecture was developed in 2010,
>> before the MacOS X Lion (2011) and ML (2012) was introduced, so such
>> things >>like "animated fullscreen support" was not taken into account
>> at all.
> Maybe we could just not change to UiMachineFullscreenWindow if you click
> the arrow and keep the legacy fullscreen support if the user prefers to
> use it.
> It would work like this:
> 1. OSX 10.8 user clicks on the arrow of press cmd+shift+F to go native
> fullscreen
> 2. All OSX users would still be able to press cmd+F
As I said, VirtualBox fullscreen mode is not just "an arrow at the right
corner".
On entering fullscreen UI session recreates UIMachineLogic to
UIMachineLogicFullscreen child, which recreates UIMachineWindow(s) to
UIMachineWindowFullscreen(s) children and so on to the UIMachineView(s)
children. Fullscreen logic takes into account multi-screen layout (the
possibility to map and reorder guest screens among the host screens) and a
lot of other things related to fullscreen mode only. The thing which you
are proposing is to keep GUI in previous mode (normal and/or scale) and
just to enlarge it to fullscreen size using animated Lion/ML mechanism. It
will creates much more problems and even weird bugs than resolve.
>
>> 2. Moreover, iirc we are still supporting build on MacOS X SDK 10.5 and
>> wish to do so for now.
> I agree we must support 10.5. I think some simple respondsToSelector
> calls would solve the problem, maybe we'll need a define somewhere.
>
>> 3. And finally MacOS X Lion which supports "native fullscreen mode"
>> doesn't have possibility to enter fullscreen on other than primary
>> screen (multi->>screen fullscreen support appeared in MacOS X Mountain
>> Lion) which is totally unacceptable.
> Ok, here we have a issue but what if we keep the legacy fullscreen
> support on Lion and implement the native only for mountain Lion? Someday
> you'll have to do it, >right?
Well, as you know Oracle management determines the current priorities for
our project.
if there will be a paying customer request or other important reason to
have exactly native MacOS X fullscreen support for Mountain Lion I'll
implement it but not quite the way you are proposing, its more like a hack
as you said :) For now its not something extremely urgent and/or important.
>
>
> Can you help me with this vmmr0.r0 problem? It's hard to guess what to
> do without being able to test.
>
> Best,
> Sent from my iPad
>
> On 29/04/2013, at 07:08, "Sergey Dubov" <Sergey.Dubov at oracle.com> wrote:
>
>> Lucas Dupin <oi at lucasdup.in> писал(а) в своём письме Sun, 28 Apr 2013
>> 18:22:19 +0400:
>>
>>> Hey guys,
>>> I'm working on Mac OS native fullscreen support for VirtualBox.
>>> It's my first time hacking the source, so I'll need some help. Ok?
>>>
>>> I've already found the class where you call showFullscreen() and
>>> modified the UIMachineWindow to show the arrow on the right corner of
>>> the title >>>bar.
>>> The code is self contained so I don't think we're going to have
>>> compatibility issues, even with older versions of MacOs, like 10.6.
>>>
>>> One minor caveat is that you'll need MacOS SDK 10.7 to compile the
>>> source. I don't think it's a problem since you'll still be able to
>>> target older >>>versions, like 10
>>> What I really need to do now is to test the code I've written in a
>>> proper way but I can't manage to turn my Virtual Machines on.
>>> I ran the loadall.sh script, so I don't think it's a kernel module
>>> problem.
>>>
>>> Could you give me some directions on what to do? The error I receive
>>> is:
>>> Failed to load VMMR0.r0 (VERR_GENERAL_FAILURE)
>>>
>>> And the details say:
>>> Result Code: NS_ERROR_FAILURE (0x80004005)
>>> Component: Console
>>> Interface: IConsole {db7ab4ca-2a3f-4183-9243-c1208da92392}
>>>
>>>
>>> In debug mode, this is the stacktrace:
>>> Thread 11 Crashed:: EMT-0
>>> 0 VBoxRT.dylib 0x000000011082ba0d
>>> rtkldrConvertError(int) + 973 (ldrkStuff.cpp:197)
>>> 1 VBoxRT.dylib 0x000000011082bf8a rtldrkLdrOpen +
>>> 762 (ldrkStuff.cpp:880)
>>> 2 VBoxRT.dylib 0x0000000110724f9c
>>> rtldrOpenWithReader + 1052 (ldrEx.cpp:160)
>>> 3 VBoxRT.dylib 0x000000011072763d RTLdrOpen + 541
>>> (ldrFile.cpp:278)
>>> 4 VBoxRT.dylib 0x0000000110871614
>>> supLoadModule(char const*, char const*, char const*, void**) + 1204
>>> >>>(SUPLib.cpp:1854)
>>> 5 VBoxRT.dylib 0x0000000110873a00 SUPR3LoadModule
>>> + 160 (SUPLib.cpp:1606)
>>> 6 VBoxVMM.dylib 0x00000001101fd14e
>>> pdmR3LoadR0U(UVM*, char const*, char const*, char const*) + 830
>>> >>>(PDMLdr.cpp:673)
>>> 7 VBoxVMM.dylib 0x00000001101fc3dc
>>> PDMR3LdrLoadVMMR0U + 44 (PDMLdr.cpp:82)
>>> 8 VBoxVMM.dylib 0x0000000110305b16
>>> vmR3CreateU(UVM*, unsigned int, int (*)(UVM*, VM*, void*), void*) + 38
>>> >>>(VM.cpp:586)
>>> 9 VBoxVMM.dylib 0x0000000110312113
>>> vmR3ReqProcessOneU(UVM*, VMREQ*) + 643 (VMReq.cpp:1254)
>>> 10 VBoxVMM.dylib 0x000000011031327e VMR3ReqProcessU
>>> + 1262 (VMReq.cpp:1170)
>>> 11 VBoxVMM.dylib 0x000000011030fab8
>>> vmR3EmulationThreadWithId(RTTHREADINT*, UVMCPU*, unsigned int) + 856
>>> >>>(VMEmt.cpp:123)
>>> 12 VBoxVMM.dylib 0x000000011030bce4
>>> vmR3EmulationThread + 52 (VMEmt.cpp:62)
>>> 13 VBoxRT.dylib 0x00000001107754d9 rtThreadMain +
>>> 473 (thread.cpp:698)
>>> 14 VBoxRT.dylib 0x00000001108648ec
>>> rtThreadNativeMain(void*) + 444 (thread-posix.cpp:312)
>>> 15 libsystem_c.dylib 0x00007fff95ed47a2 _pthread_start
>>> + 327
>>> 16 libsystem_c.dylib 0x00007fff95ec11e1 thread_start +
>>> 13
>>>
>>>
>>> Best,
>>> Lucas Dupin
>>
>>
>> Hi Lucas.
>>
>> I just have a few words to tell about native MacOS X fullscreen feature:
>> 1. Within the current Runtime UI architecture having native MacOS X
>> fullscreen support is not something easy (if possible at all).
>> Fullscreen-mode is not just "an arrow at the right corner", its
>> internal mechanism which takes into account different aspects of
>> VirtualBox GUI behavior.
>> When GUI changes mode representation (from normal to fullscreen,
>> seamless or scale) through the menu action it recreates internal
>> Runtime UI logic >>and finally machine-window(s), so entering
>> fullscreen "the true Mac way" is not quite possible in such case.
>> Note: The VirtualBox Runtime UI architecture was developed in 2010,
>> before the MacOS X Lion (2011) and ML (2012) was introduced, so such
>> things >>like "animated fullscreen support" was not taken into account
>> at all.
>> 2. Moreover, iirc we are still supporting build on MacOS X SDK 10.5 and
>> wish to do so for now.
>> 3. And finally MacOS X Lion which supports "native fullscreen mode"
>> doesn't have possibility to enter fullscreen on other than primary
>> screen (multi->>screen fullscreen support appeared in MacOS X Mountain
>> Lion) which is totally unacceptable.
>>
>> Taking into account these facts I'd say implementing and maintaining
>> something *only* for MacOS X Mountain Lion is not our way.
>>
>> --With Best Regards,
>> [Oracle/VirtualBox] Sergey Dubov
>>
>>
--
With Best Regards,
[Oracle/VirtualBox] Sergey Dubov
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.virtualbox.org/pipermail/vbox-dev/attachments/20130429/284488b6/attachment.html>
More information about the vbox-dev
mailing list