I've been looking at what needs to be done to implement fullscreen mode on mac as a hacktoberfest contribution. At first I was just thinking about adding a fullscreenControl property but then I realised it probably should be a decoration. Now I've come to the conclusion that it would be better to implement a more flexible windowCollectionBehavior property so that we can fiddle with any of the behaviors. I was thinking of implementing it something like the decorations with a list that is parsed although I guess it could be an array of booleans... any thoughts welcome on that.

The next question is whether it's reasonable to update the fullscreen property to the modern meaning of fullscreen on a mac depending on the value of the windowCollectionBehavior. I think it is, however, it presents a further issue because currently switching to/from fullscreen mode re-opens the window rather than changing its properties. I strongly suspect that will break the animation even if we toggle to fullscreen in the new window. I'm guessing you don't want to add a platform specific ifdef here because all that should be handled by the platform api.

In both cases (toggle to fullscreen via script and via user clicking the widget) we probably need to handle the fullscreen mode etc and it looks from the comments that Ian added the re-open window because of fullscreen mode.

Invoking the KISS principal, I'd perhaps suggest focusing on just the fullscreen control and associated functionality first. The windowCollectionBehavior as it stands would be entirely Mac-specific - I think some more research should be done on other desktop platforms first to see if they have any similar ideas which could be mapped to. (Obviously spaces are similar to a similar thing X11 window managers have always have, and Gnome definitely has some recent abstraction in the area).

I'd suggest that the property on the window be called 'fullscreenBox' - this is an analog of existing individual decoration properties.

I'm perfectly happy with the idea of making 'fullscreen' actually use the recent (I don't think it is in 10.6, so we'd need compatibility) OS support for it... As you point out it might need a little bit of restructuring in the code, I can certainly take a look and give some advice here in due course

We will probably need to add a 'fullscreen()' and 'unfullscreen()' platform-specific operation that can be applied as the fullscreen property is toggled.

@monte: I haven't had a chance to dig into the code yet to give advice about structure - however, if you want to hack something in that works on Mac and then submit a PR, it might help to see how it should be structured (i.e. just get something working and we can work on making sure it has clean abstractions - the Cocoa port itself started out this way!)

I have, however, been pondering the windowCollectionBehavior. The main reason I'm having difficulty with it is its platform-specificness. The reality is there is always going to be differences between platforms which are hard to generalize or abstract or, indeed, there is no point in doing so. So, perhaps, what we need here is a formalism which allows objects carrying a native object behind them (at the moment that is pretty much just stacks - i.e. the window - but this will not be the case in future when we add nativized elements for the main controls through the widget architecture) to specify platform-specific properties in a way which doesn't keep increasing the zoo of properties on any one object.

set the platformFeatures["mac.windowCollectionBehavior"] of stack "Foo" to ...

This might seem a little verbose - however, remember we are talking about specific per-platform aspects. By making this explicit it means code is easily grokked for these cases and if unifying higher-level abstractions eventually wrap them, then it is easy to update code to make it cross-platform.

The underlying mechanism would be a general thing we can put in the engine - each platform would declare a list of 'known features', so setting can be type-checked and converted at execution time and the (appropriately reduced for the currently running platform) underlying array can be passed through to the platform-specific code to use at it needs to.

Maybe I'm overthinking this a bit - although stacks (windows) might not be the best thing to analyse for its usefulness as there may not be many per-platform properties that exist. However, if we start looking at other native controls for insight, it might well justify the modest amount of work needed to add the mechanism and validate its usefulness.

The current state my experiments are in is as a decoration "fullscreen" and a callback "fullscreenChanged <entered boolean>".

At the same time as sending the callback I'm also setting the ECS_FULLSCREEN extended state but I think I need to do a couple of other things in order to get fullscreen mode to work. I guess if I could make SetFullscreen retain the same window (at least on Mac > 10.6) then I could just call that which should do whatever is meant to happen to make fullscreen mode work.

One of the issues with using a decoration is the NSWindow.collectionBehaivior is only set in the event you have a titlebar etc so you can't have a window with some custom look that has its own fullscreen button that toggles in and out of fullscreen. That's one reason why I thought of moving to a collection behavior property. The other is there's other goodies there and doing something that supports only one of them seemed silly.

The other thing is that the animation is different to every other app. In LiveCode the content of the window including the title bar stretches during the transition then normalises when it gets there. I'm not sure how feasible it is to control that but it would be nice if it looked like other apps...

With regard to the platform specific properties I'm not so sure. I personally think it's ok to have platform specific features appear to be part of the language. Everyone seems to hate the iPhone/mobile syntax. Whether in this instance there's an abstraction we can make to cover similar behavior on other platforms I hadn't considered but as you say it's a possibility.