We need a system to let the factory know we need the native video player plugin. Story: https://www.pivotaltracker.com/story/show/49005547
The "share" icon gets displayed when the user accesses a details page, it allows to share the item. The "share" icon is displayed in the topbar at the same position as the "refresh" icon. In a proper implementation, the "share" icon would only be displayed if there is a "share" add-on. Clicking on that icon would start the "share" activity. Right now, add-ons are not checked and the hook is not triggered. The action needs to be hardcoded in the "share" function of "sleek.phone.js". Notes: - the icon is a copy of the "refresh" icon for the time being, pending a better icon. - the case when a datasource contains only one item is not supported, meaning the "refresh" icon will be displayed in that case, not the "share" icon. - the case when the item cannot be shared (static local content) is not supported either, meaning the "share" icon is always displayed.
…sion. The #title span was blocking the clicks because it was put over the toolbar and had a property display:inline (default one). By changing the property to inline-block, the element is not masking the toolbar anymore. Related to https://www.pivotaltracker.com/story/show/45389923
Since the new update to the view and the introduction of the hidden property, this was broken. Indeed, the view now applies directly a jQuery.show to its element. We used a "display:none" in the css to hide the toolbar when needed. To circumvent that, we now use "visibility:hidden". This should fix https://www.pivotaltracker.com/story/show/29702415 for good.
The bug was due to the fact that changes made to the main HTML content had not been applied to the optimized versions of the HTML pages. Related bug in Pivotal: https://www.pivotaltracker.com/story/show/47881841
The flickering effect occurred because the toolbar gets rendered more than once for some reason. In the end, the solution was to force the rendering of the toolbar through the GPU. I took the opportunity of the change to simplify the rendering of the toolbar a bit as it was using a combinaison of floats and absolute positioning that was not really necessary. The utils.less now features a ".accelerate" shortcut. Note that setting "backface-visibility" to "hidden" is not enough anymore to force an element through the GPU on iPad retina devices. The shortcut gets replaced by a combinaison of "backface-visibility", "perspective" and "translateZ". They should not all be needed but that should not have any drawback in practice.
The "getContentWidth" and "getContentHeight" functions assumed that all tabs were composed of a list and detail views but that is no longer the case as some of the tabs may only contain a detail view. The code of these functions had to check the dimensions of the detail view because, many commits before the latest one, the width of a slide panel in the framework was not the width of the viewport but the sum of all the widths of the panels it contained. That is no longer the case, we can now simply check the dimensions of the container element to determine the available width and height.
With this change, IE9 should properly render all element. There is no gradient, since we don't want to use the non-standard filter css property. Only the background color of the toolbar was not being set, hence IE9 displaying a quite ugly white toolbar. This fixes https://www.pivotaltracker.com/story/show/45389923
During application startup, all the sections were displayed at once one on top of the others with a spinner up until the first route was executed. Also switched to the latest version of the framework that handles the "hidden" initialization option and that also does not update the DOM for nothing when the code calls "show/hide" whereas hidden state is already correct.
For some reason, there is a difference in behavior between the non compiled version and the compiled version of the "onReady" utility toolbelt. In the compiled version on desktops, it sends in the underyling event as first parameter. The Sleek.initialize function takes a potential callback function as first parameter. The template crashed when it received the event object. I updated the code to ensure that the initialize function never receives the event object. Related bug in Pivotal: https://www.pivotaltracker.com/story/show/47715579
The Samsung TV version now derives from the TV version of Sleek to maximize the amount of code that is shared across versions, as most of the code of the Samsung TV version was actually a copy and paste of the code of the default TV version. The "load more" feature should now also work on the Samsung version. I haven't checked the code on an actual device. While the update does not bring anything "worrysome" in the sense that the updates do not change a lot from a rendering perspective, history shows that the template is likely still broken in practice ;)
The commit brings in the latest version of the framework that provides a more consistent update mechanism across views that do not force a full refresh when not needed. Sleek now renders views once when they get created. Updates made to the models and collections bound to the views trigger the additional magic needed to update the content displayed. This is probably not enough to fix the flickering effect on iPads, but that should still improve things and avoid useless updates that could happen in the past. Samsung TV version still not operational.
The specific image collection is useful to filter out images that are too large as Samsung TV models tend to crash when requested to render such images. The collection used to derive from Backbone.Collection directly but the "joshlib!collection" class now adds useful logic to fetch more items in a collection and to trigger load events when new items are fetched.
The latest version of the framework brings a better tracking of views, in particular for the DynamicContainer view. Things that still do not work well: - The Samsung version is borked. More fixes needed. The code has not been updated to drop the "<li>" level to start with and the specific "collection" needs to derive from "joshlib!collection". - The flickering effect should still be around. Ghost views are not kept around anymore, which is good, but they are still created temporarily. It should be easier to track things down now that we have better logs.
…leek Conflicts: app/joshfire-framework app/sleek.js app/sleek.phone.js
…to the factory before it can be used. Once the factory work is done and in prod, we can advertise that feature.