So, let's see: They take this SlidingPanel which implements HasOneWidget (and though AcceptsOneWidget) as their 'root'-Panel for the Activity. The ActivityManager calls setWidget(widget) when a PlaceChange happens. So they did an @Override setWidget(Widget widget). When this method gets called, the SlidingPanel looks if it already contains (inside the List<Widget>) the widget (if not appends it) and calls show(index). show(index) looks if the new index is left or right of the current index and then: - add the new widget from the List<Widget> to the LayoutPanel - set current widget to 0% left and 100% width - set new widget to 100% left (newIndex > oldIndex) or -100% left (newIndex < oldIndex) and 100% width - run the animation - remove old Widget from the LayoutPanel
It's a bit like they ignore the standards they created with Activities. 'Cause in theory it's possible to show as many activities as you like in parallel... ;) On 13 Okt., 15:54, Thomas Broyer <[email protected]> wrote: > The Expenses sample does just that; have a look at how it's done. > > Basically, the widget implementing AcceptsOneWidget will append the new > child and slide it into view, and then remove the old child; instead of > replacing one by the other. -- You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
