@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.
One suggestion is this:
- Code: Select all
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.