In a post some days ago I pointed out that menu handling is substantially different between Harmattan and Sailfish Silica. I may even have mentioned jumping through flaming hoops ...
Well the solution I now have is not perfect. I would still categorize it as a workaround, but it is one that I can live with as it fits my needs, and I am aware of the weaknesses.
From a user's point of view (and we should never forget our users) the differences in Menu Handling are these:
A Harmattan menu is launched from the Toolbar which sits at the bottom of the screen occupying valuable screen real-estate.
The Silica Menu is launched by swiping the screen (up in the case of a PushUpMenu, down in the case of a PullDownMenu). While no screen real-estate is consumed by a ToolBar, the menu is indicated by a MenuIndicator. The trouble is that the new user will naturally try and open the menu by the indicator: that's the intuitive thing to do: but it is the part of the screen that cannot be used to open the menu: if you drag there you will slide the whole app away!
2) Behaviour on Opening
When the Harmattan Menu opens, it slides over other content on the page, without any programmer intervention, and as the menu is non-transparent, there is no "interference" between menu items and components now under the open menu.
The Silica Menu, at least in the demo new project, causes other page content (page childs) to slide away with the menu as it opens
So how do these affect us as programmers? Read on:
Thoughts on Menu Launching
The confusing idiom of dragging anything but the menu indicator is something the Sailfish Jolla guys will need to do some thinking about, but I see a problem where a page already hosts flickable items. As an example, my LandedSettings app has four ListViews on the MainPage (or in Silica speak FirstPage). These have variable content read in from an SQLite settings DB, and the content displayed in one ListView depends on the content in a parent ListView.It is quite possible that he total height of all four ListViews is greater than the available screen height, so in the original Harmattan implementation, flicking the screen up or down would flick the stack of ListViews. The Menu could still be opened, because it was launched from the ToolBar - which was like a kind of "reserved area" at the bottom of the screen.
Now with Silica I have a conflict. Following the Silica idiom, flicking the screen should open a menu: yet I still need to be able to handle screen content taller than the visible screen!
At the moment the workaround is to reserve a small area at the bottom of the screen just above the MenuIndicator. When this area is flicked, the menu opens. When the rest of the screen if flicked, the stack of ListViews scroll. Defacto I have an invisible Toolbar.
But it remains a workaround. Possibly I will totally abandon the Menu for LandedSettings: the current entries are for testing purposes only; or maybe I need to find a much better idiom then the 4 fully expanded ListViews. Some out-of-the-box thinking is required!
Perhaps the pertinent point is that the Silica menu opening idiom is forcing me to think about the whole screen design, and may result in a completely different approach to that which worked naturally with Harmattan. Time will prove if the end result is better or a kludge!
Thoughts on Menu Opening
From a technical point-of-view the greatest problem I have so far is getting other page childs to slide away when the menu opens. I must confess that I have not really invested much time in this yet, and may have got overly distracted in polishing the workarounds.
To recap: the Silica Menu, at the moment a PushUpMenu, is embedded with the declaration of the AUIPageWithMenu control. The programmer will import this control, and add an instance to his project. let's call it MyPage. MyPage will in turn have various child components, Buttons, Rectangles, Labels etc. Following the Silica idiom all these childs of MyPage should slide up when the embedded PushUpMenu opens.
But despite reparenting these childs I have not got that working yet.
So for the moment I have a 2 part workaound
1) Change the Menu Z axis property bound to the Menu's active property.
When the menu is opened, Z should be high, so as to be painted (and thus slide) above all other components. At the moment I set it to an arbitrary 9999 as this is a workaround, but were this to be the final solution i would probably have to have logic to find the highest current Z, and make the open menu Z higher.
When the menu is closed the Z property of the menu should be low. This is important, as if the menu is closed, but has a high Z property, the Flickable no longer works, and the menu cannot be opened! The menu "steals" mouse input even though is is closed if it has a higher Z then other items!
With this workaround in place, the Menu should now slide over the childs of MyPage, but this leads us to the next problem and its workaround:
2) Change the Opacity of other childs of the Page
The menu now slides over other content, but given that everything Silica is glassy, and therefore transparent, the menu becomes hard to read if we have other text or distracting items underneath it.
My workaround is to fade these "other items" by reducing their opacity property. They remain visible, but less prominent than the Menu. The technique used is interesting enough that I will post a separate article on it, together with an open question.
So for the moment my Sailfish implantation of menu handling does not yet slide other content away: instead the menu (should) slide over other content, and fade other page content while open.
Watch this space for more news, the battle is not yet decided!