Brilliant! thank you! On Nov 22, 6:22 pm, Thomas Broyer <[email protected]> wrote: > On 22 nov, 12:00, Michael <[email protected]> wrote: > > > I have been using the GWT 2.1.0's MVP framework for a couple of weeks > > now, and I really like it. > > > However the flickering during place "transitions" really bothers me, > > and today I tried to do something about it. > > > Sofar I've found > > this:http://code.google.com/p/google-web-toolkit/source/detail?r=9049 > > > Notice the second part, "Also undoes demo-time hack that left stopped > > widgets in place to reduce flicker" > > > Using an activitymanager that leaves the stopped widgets in place > > removed the flickering. But I assume there's a problem with this > > approach? > > Seehttp://tbroyer.posterous.com/gwt-21-activities(which needs some > update...) > """In response to a user action (“show this mail conversation”, “go > back to inbox”, etc.), the current activity has to be stopped and > another started. As the next activity is starting (remember, this is > already the current activity from the ActivityManager's point of > view), the current activity (previous one actually) is still > displayed, but it's already logically stopped (its onStop() method has > already been called). Please note that this behavior will change in > the next release: the display region's widget will be set to null as > soon as the activity is stopped and until the next one is fully > initialized. > > It's your job as a developer to choose which behavior you want: the > view is disabled, or it might trigger navigation. > > Technically, it could still handle all user events but, because it's > already stopped, it can be replaced at any given time and you won't > have any notification (well, there's the widget's onUnload(), but > anyway it's probably already too late to do anything useful). I'd > therefore advise you to not do it, except to trigger navigation as > it's about leaving the activity (which, you'll agree, doesn't > conflicts with the already-stopped status of the activity). > > The rule of thumb is thus to disable any action when an activity is > stopped (i.e. from its onStop() method), except possibly navigation. > It's up to you to decide whether this is done by disabling (graying > out) widgets or just turning a deaf ear to their events.""" > > > Anyone have a suggestion to a better strategy for removing the > > flickering? Some sort of cache was mentionend in the above link. > > In the AcceptsOneWidget you give to the ActivityManager, just handle a > 'null' widget differently, assuming your activities will never call > setWidget(null) themselves (if they need to, you could have them pass > a non-null IsWidget whose asWidget returns null). > final SimplePanel realPanel = new SimplePanel(); > activityManager;setWIdget(new AcceptsOneWidget() { > public void setWidget(isWidget widget) { > if (widget == null) { > // note that widget.asWidget() == null goes the other path > // here, you can do whatever you want to "reduce flicker"; if > you don't call realPaneL;setWidget(null), then the view will lie > around > // you could also "mask" and/or "blur" it with a "glass > panel" > } else { > realPanel.setWidget(widget); > } > } > > > > > > > > }
-- 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.
