Comments

I think there probably should be. The floating property should be like a mixin that can be added to a control to render it to the FloatingLayer, and then gives it highestZ, and zIndex properties, so that the newest "floating" control that shows itself can take over the "highestZ" of all the floating controls. the FloatingLayer can keep references to each of it children to manage their zIndex, and maybe provide a basic API to have controls be able to change zIndex based on user input. And as FloatingLayer controls hide/get destroyed, it manages the zIndex so it doesn't just keep going up and up.

@ruben_vreeken, just realized you're talking about 2.4 - in 2.5 we consolidated a lot of the code for onyx.Popup and enyo.Popup with a shared enyo.Scrim kind, so there definitely was some clean-up to be made. We don't have something specific for organizing items in the floating layer - what kind of use cases were you encountering that necessitated this?

@chrisvanhooser, would definitely be interested in seeing your implementation, please share when you get a chance, thanks!

@aaron, In the app I'm working on, I have a floating layer that contains a media player (was needed to make full-screen mode work properly in cordova on android), and occationally a modal popup.

I also have a loading graphic that can display on top of a page, which is currently not implemented as floating layer. I was thinking about moving the loading graphic into the floating layer so I could have simply once loading overlay instance rather than multiple ones.

Upon contemplating the possibility of a floating loading-graphic, I figured making it float could also allow me specific control about which floating components should float below or on top of the loading-graphic. For instance, a user can log in while a particular page is still loading in the background. But the media player would ideally stay below the loading graphic until it's initialized, it's content buffered, and it's ready to start playing.

This idea lead me to investigate enyo's current way of dealing with floating layers and making this post.

I have since found there have not actually been any cases yet that require me to explicitly manage zIndex in the floating layer... so it's not a high priority for me now. Just a case of curiosity I suppose.

I hope to have time this weekend to post what i have.Basically, in the application i am working on now, i needed to make "windows", that could be minimized, and have many different views of them open at once, and be able to switch back and forth. (pretty much like windows task bar, and each window you have loaded)

So, i made a sub kind of enyo.Popup called a DragPopup, that when clicked on, would "take the top" z-index of all the floating popups.When minimized, it would look for the last active window, and then put that in "focus".

I used enyo.Signals to tie everything together, and used the main view as the "container" for everything. So, to create a window, i would use this.app.createWindow(), and then the DragPopup would communitcate via enyo.Signals to each other, and the main view to keep in sync.

But i think it could be simplified with a simple mixin, and the mixin could keep everything in sync with the eventEmitter i think.