Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Tk 8.5.11 fullscreen broken on MacOS X 10.7 Lion?

57 views
Skip to first unread message

Jerry Orjuela

unread,
Jan 28, 2012, 10:49:50 PM1/28/12
to
Hello All,

Prior to MacOS X 10.7, the following code produced a true full screen
(blank, no Dock, no menubar, window title bar or other decorations; a
full, white screen):

package require Tk
button .button -text "Exit" -command exit
wm attributes . -fullscreen 1

Note that one has to click somewhere in the whitespace first to make the
window topmost, which clears everything else away (Dock, menubar, etc).
The code also works as-is under Ubuntu 11.10, and PC-BSD 9.0.

Under MacOS X 10.7, the bounds of the window only extends to the menubar
and the Dock, and clicking in whitespace to make the window topmost
makes the menubar and Dock disappear, showing the underlying desktop
(and any windows or icons that are there). Also, the window title bar
remains.

Is there something else that has to be specified for Lion that I've
missed, or is this a known problem?

Thanks,
-Jerry

--
Substitute herculesh for pseudo in my email address if replying direct.

Kevin Walzer

unread,
Jan 29, 2012, 8:46:56 AM1/29/12
to
I've noticed this myself--Lion seems to use a different API for
fullscreen apps. I don't think a fix will be too difficult, and I'll be
working on it soon.

--Kevin

--
Kevin Walzer
Code by Kevin
http://www.codebykevin.com

Kevin Walzer

unread,
Jan 29, 2012, 11:01:59 PM1/29/12
to
On 1/28/12 10:49 PM, Jerry Orjuela wrote:
> Under MacOS X 10.7, the bounds of the window only extends to the menubar
> and the Dock, and clicking in whitespace to make the window topmost
> makes the menubar and Dock disappear, showing the underlying desktop
> (and any windows or icons that are there). Also, the window title bar
> remains.
>
> Is there something else that has to be specified for Lion that I've
> missed, or is this a known problem?

Lion has a significantly different API that sets fullscreen mode
automatically via a special button that is drawn on the title bar. The
user clicks the button to set fullscreen mode. There is no way to
interact with this button programatically from Tk. Consequently, I am
working on a patch that sets the wm attributes -fullscreen command to
no-op on Lion and above. A bit more testing and documentation updates
are needed, but I'll commit it soon.

Christian Gollwitzer

unread,
Jan 30, 2012, 1:26:40 AM1/30/12
to
Am 30.01.12 05:01, schrieb Kevin Walzer:
> Lion has a significantly different API that sets fullscreen mode
> automatically via a special button that is drawn on the title bar. The
> user clicks the button to set fullscreen mode. There is no way to
> interact with this button programatically from Tk. Consequently, I am
> working on a patch that sets the wm attributes -fullscreen command to
> no-op on Lion and above. A bit more testing and documentation updates
> are needed, but I'll commit it soon.

This can't be the whole story: Not every window has the fullscreen
button. The app must somehow support it. And some apps automatically go
to fullscreen mode, for example the DVD player, as soon as you insert a
DVD.

Christian

Christian Gollwitzer

unread,
Jan 30, 2012, 2:40:53 AM1/30/12
to
Am 30.01.12 07:26, schrieb Christian Gollwitzer:
Programmatic action for fullscreen:

http://developer.apple.com/library/mac/#documentation/Cocoa/Reference/ApplicationKit/Classes/NSWindow_Class/Reference/Reference.html#//apple_ref/occ/instm/NSWindow/toggleFullScreen:


Many thanks for your work!

Christian

Kevin Walzer

unread,
Jan 30, 2012, 11:25:14 AM1/30/12
to
On 1/30/12 2:40 AM, Christian Gollwitzer wrote:
> Programmatic action for fullscreen:
>
> http://developer.apple.com/library/mac/#documentation/Cocoa/Reference/ApplicationKit/Classes/NSWindow_Class/Reference/Reference.html#//apple_ref/occ/instm/NSWindow/toggleFullScreen:
>
>
>
> Many thanks for your work!
Yes, that's the API I'm working with. The issue I'm running into is
integrating that API with Tk's awareness of a full screen via the
WM_FULLSCREEN flag. If the user clicks on the fullscreen button, that
doesn't trigger a change in Tk's sense of the window state. On X11 and
Windows, Tk drives the full-screen setting by registering the
WM_FULLSCREEN flag and then re-drawing (or instructing the window
manager) to re-draw. I'm still figuring out how to get this working with
the new button.

Kevin Walzer

unread,
Jan 31, 2012, 11:10:38 PM1/31/12
to
On 1/28/12 10:49 PM, Jerry Orjuela wrote:

> Is there something else that has to be specified for Lion that I've
> missed, or is this a known problem?
>

After a lot of experimentation, I've concluded that there isn't a
feasible fix to the issue, for several reasons:

1. It's not a Lion-specific issue, it's a Cocoa-specific issue. Cocoa
(the preferred UI framework for Apple) doesn't allow as much flexibility
in changing window styles as did Carbon (the deprecated Apple UI that Tk
Aqua was originally built on). As a result, Tk can no longer change the
window style on the fly to a borderless, full-screen window--the current
implementation is the best it can do with manual drawing. The difference
you are seeing is the difference between Carbon and Cocoa Tk.

2. I've looked at a few different alternative API's, but they are either
poorly supported, cf. NSView enterFullScreenMode:screen withOptions:],
or they are Lion-specific, cf. [NSWindow toggleFullScreen], which works
well for resizing the window BUT doesn't play nice with Tk's internal
sense of window state (is it fullscreen or not)? Additionally, I am
reluctant to use a 10.7 Lion-only API because Tk-Cocoa's minimum version
is 10.5, Leopard.

I'm sorry that I wasn't able to put together a fix for this issue. I've
spent several hours on it, partly because I have been meaning to
experiment with the shiny new full-screen API in Lion--it's pretty slick
the way the window animates out to full-screen and back with just a few
lines of code. But getting this to actually work well with Tk's
internals was giving me nothing but headaches.

As a result, I'm going to have to leave it as is, because it's the only
working implementation, even though it doesn't work as well as we'd
like. Cocoa has many advantages over Carbon, and it was absolutely
necessary for Tk to adapt to Apple's preferred API (a thousand kudos to
Daniel Steffen for his heroic solo work on the port), but there are some
areas where the Cocoa implementation has limitations that the Carbon
version did not. This is one of them.

--Kevin

Christian Gollwitzer

unread,
Feb 6, 2012, 4:25:18 PM2/6/12
to
Hi Kevin,

Am 01.02.12 05:10, schrieb Kevin Walzer:
> I'm sorry that I wasn't able to put together a fix for this issue. I've
> spent several hours on it, partly because I have been meaning to
> experiment with the shiny new full-screen API in Lion--it's pretty slick
> the way the window animates out to full-screen and back with just a few
> lines of code. But getting this to actually work well with Tk's
> internals was giving me nothing but headaches.

is it possible to put the Lion fullscreen support under
"::tk::unsupported::MacWindowStyle"? IIRC this is the place for other
mac specific windows (like sheets from above). This way it could be
accessible by a script without the headaches of portability to other OS
versions.

Christian

Kevin Walzer

unread,
Feb 6, 2012, 5:11:12 PM2/6/12
to
Tthe OP asked about an implementation of a standard cross-platform
command, [wm attributes -fullscreen]. It would be straightforward enough
to add a window flag that would turn on the fullscreen capability on
Lion, but that's not the same thing as running the [wm attributes]
command and have it work transparently without modification.

Kevin Walzer

unread,
Feb 6, 2012, 5:17:12 PM2/6/12
to
P.S. Patches welcome. I actually also spent a lot of time trying to
implement the basic fullscreen functionality (outside of the wm
attributes command) and ran into weird issues with window geometry: when
the window became fullscreen via the fullscreen button, Tk buttons would
no longer respond to presses, apparently because Tk didn't realize the
window had been resized. The button-click event would fire when the
mouse was pressed at a location beneath the button, about 20 pixels or
so. Very strange.
0 new messages