Re: [gwt-contrib] New Google Groups apparent with GWT ?

[Joel Webber]

I believe it is, though I think they may have taken Gmail's Javascript  
rich-text editor (the one from the Closure library). I'm pretty happy with  
it, too.


On 10:55 am, stuckagain  wrote:

Hi, I'm writing this message using the new Groups... and what do I
see... it is now written in GWT! Looking sweet! Although I see a bit a
lag when typing (in IE8) David


--
http://groups.google.com/group/Google-Web-Toolkit-Contributors

[gwt-contrib] Re: Fix some timeout typos, and increase delay on RequestFactoryTest. (issue1163801)

[Joel Webber]

kthx. Let me know if you need me to do anything.

On 2:35 pm, Ray Ryan  wrote:

Yup, but I've pointed Bob at it instead. Not that your scrutiny isn't
welcome…


--
http://groups.google.com/group/Google-Web-Toolkit-Contributors

[gwt-contrib] Re: Fix some timeout typos, and increase delay on RequestFactoryTest. (issue1163801)

[Joel Webber]

Ready for review now?

On 2:32 pm, Ray Ryan  wrote:

http://gwt-code-reviews.appspot.com/1163801/show


--
http://groups.google.com/group/Google-Web-Toolkit-Contributors

Re: [gwt-contrib] protected com.google.gwt.user.client.ui.Widget.addHandler(H, Type)

[Joel Webber]

The point of that method being protected is that under normal circumstances
you don't want to be able to add handlers to a widget that's not capable of
firing them in the first place. So a widget subclass creates
addFooHandler(), then uses this method internally.

Are you saying you want to add a custom event handler to a widget, then
force that widget to fire the event from external code? Sounds like it wants
to be a subclass.

Le 9 novembre 2010 01:56, cokol  a écrit :

> why is com.google.gwt.user.client.ui.Widget.addHandler(H, Type)
> protected? in case I want to fire a custom event on a widget so that
> the widget is not aware of custom event handler, it makes it difficult
> to manage.
>
> thanks
>
> --
> http://groups.google.com/group/Google-Web-Toolkit-Contributors
>

-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors

Fwd: [gwt-contrib] Re: Comment on WhyWidgetIsAClass in google-web-toolkit

[Joel Webber]

[+rjrjr]
I haven't put much thought into widget interfaces recently (I've been busy
wrestling low-level stuff on other fronts), but clearly Ray and others have
been thinking about this problem (based upon the appearance of IsWidget,
which seems to have worked out well). Thoughts?

-- Message transféré --
De : 
Date : 4 novembre 2010 10:56
Objet : [gwt-contrib] Re: Comment on WhyWidgetIsAClass in google-web-toolkit
À : Google-Web-Toolkit-Contributors@googlegroups.com


Comment by stephen.haberman:

Hurray for structural typing. :-)

That being said, I think you're coupling "benefits of a concrete base class"
with "cannot use interfaces for widgets"--to me, they're separate concerns
because you can:

* Enforce a concrete class internally within the widget impls by immediately
doing "asWidget()" whenever a widget comes into the API

* Allow external clients to /think/ you support widget interfaces, by
providing IsWidget method overloads where ever you take widgets.

Note that this is already being done in GWT 2.1's Panel.add(IsWidget
widget).

What makes this really useful is if Panel itself had an interface:

https://github.com/stephenh/gwt-mpv/blob/master/user/src/main/java/org/gwtmpv/widgets/IsPanel.java

Then presenter/etc. code can add fake widgets to fake panels, be thoroughly
unit tested, but at GWT time they all turn into real/Widget-extending
widgets.

Also, union types become needed less if you just have per-widget
interfaces--e.g. IsTextBox. IsTextBox inherently defines the union of its
HasValue/etc. characteristic interfaces (/plus/ the the
TextBox-specific methods that are not in a characteristic interface and so
could never be accessed before), so client code just uses IsTextBox.

(Unless the code really does need to be generic across widgets that don't
share a IsXxx interface.)


For more information:
http://code.google.com/p/google-web-toolkit/wiki/WhyWidgetIsAClass

-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors

-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors

Re: [gwt-contrib] factory methods

[Joel Webber]

Specific examples might be helpful here. I can see how this might be useful
in some specific cases, but wrapping every new in a template method sounds
like a horribly contorting way to have to write all one's code.

Le 13 octobre 2010 05:19, cokol  a écrit :

> many other developers, including me, would appreciate if you'd use
> protected factory methods in non-final classes (even if the class is
> not abstract), like:
>
> a no-go:
> 
> void func() {
>  A = new A();
>  A.doSomething();
> }
>
> instead, a better pattern:
> ---
> protected A createA() {
>  return new A();
> }
>
> void func() {
>  A = createA();
>  A.doSomething();
> }
> -
>
>
> because in some situations the integration of GWT into existing
> environment becomes a little nightmare, and it would be great pay more
> attention to DI
>
> thank you!!
>
> --
> http://groups.google.com/group/Google-Web-Toolkit-Contributors
>

-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors

Re: [gwt-contrib] panel does not fire attach events (issue981801)

[Joel Webber]

Hmm... I didn't even realize AttachEvent had been added. John & Ray, you
might want to take a look at this -- in the original design this super
invocation wouldn't have mattered, because widget's onLoad() was empty
(onAttach/Detach() weren't really meant to overridden outside of Panel and
Composite -- onLoad/Unload() were the methods to override). But now it
appears that Widget.onLoad() has actual code in it. Could this not be moved
to onAttach?

Le 11 octobre 2010 14:05,  a écrit :

> Reviewers: ,
>
> Description:
> Panel's onLoad does not call super.onLoad. This is a simple fix that
> just adds the missing onLoad call.
>
> I have another patch set which fires the attach event in
> onAttach/onDetach, given these are more stable methods that user's are
> less prone overriding them.
>
> Please review this at http://gwt-code-reviews.appspot.com/981801/show
>
> Affected files:
>  user/src/com/google/gwt/user/client/ui/Panel.java
>  user/test/com/google/gwt/user/client/ui/WidgetOnLoadTest.java
>
>
> Index: user/test/com/google/gwt/user/client/ui/WidgetOnLoadTest.java
> ===
> --- user/test/com/google/gwt/user/client/ui/WidgetOnLoadTest.java
> (revision 8929)
> +++ user/test/com/google/gwt/user/client/ui/WidgetOnLoadTest.java
> (working copy)
> @@ -121,9 +121,12 @@
> }
>
> TestPanel tp = new TestPanel();
> +TestAttachHandler tpa = new TestAttachHandler();
> +tp.addAttachHandler(tpa);
> +
> TestWidget tw = new TestWidget();
> -TestAttachHandler ta = new TestAttachHandler();
> -tw.addAttachHandler(ta);
> +TestAttachHandler twa = new TestAttachHandler();
> +tw.addAttachHandler(twa);
>
> tp.add(tw);
> RootPanel.get().add(tp);
> @@ -134,9 +137,9 @@
> assertTrue(tp.onAttachOrder < tp.onLoadOrder);
> assertTrue(tp.onDetachOrder < tp.onUnloadOrder);
> assertTrue(tw.onAttachOrder < tw.onLoadOrder);
> -assertTrue(tw.onLoadOrder < ta.delegateAttachOrder);
> +assertTrue(tw.onLoadOrder < twa.delegateAttachOrder);
> assertTrue(tw.onDetachOrder < tw.onUnloadOrder);
> -assertTrue(tw.onUnloadOrder < ta.delegateDetachOrder);
> +assertTrue(tw.onUnloadOrder < twa.delegateDetachOrder);
>
> // Also trivial. Ensure that the panel's onAttach/onDetach is called
> before
> // its child's onAttach/onDetach.
> @@ -150,6 +153,9 @@
> // detached/unloaded.
> assertTrue(tp.onUnloadOrder < tw.onUnloadOrder);
>
> +assertTrue(tp.onLoadOrder < tpa.delegateAttachOrder);
> +assertTrue(tp.onUnloadOrder < tpa.delegateDetachOrder);
> +
> // Make sure each widget/panel's elements are actually still attached
> to the
> // DOM during onLoad/onUnload.
> assertTrue(tp.domAttachedOnLoad);
> Index: user/src/com/google/gwt/user/client/ui/Panel.java
> ===
> --- user/src/com/google/gwt/user/client/ui/Panel.java   (revision 8929)
> +++ user/src/com/google/gwt/user/client/ui/Panel.java   (working copy)
> @@ -183,6 +183,7 @@
>*/
>   @Override
>   protected void onLoad() {
> +super.onLoad();
>   }
>
>   /**
> @@ -193,6 +194,7 @@
>*/
>   @Override
>   protected void onUnload() {
> +super.onUnload();
>   }
>
>   /**
>
>
> --
> http://groups.google.com/group/Google-Web-Toolkit-Contributors
>

-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors

Re: [gwt-contrib] 2 questions about TabBar internals

[Joel Webber]

Thanks for pointing these out, Jay. If you could put together a quick patch,
we'd be glad to commit it.

Le 6 octobre 2010 16:52, jay  a écrit :

> While debugging my code I ran across two things within the TabBar
> class that I seemed strange... (Line numbers are from svn 8960.)
>
> 1.
> com.google.gwt.user.client.ui.TabBar.ClickDelegatePanel#onBrowserEvent
> -- There's a comment on line 149: "// No need for call to super.", and
> yet there *is* a call to super.onBrowserEvent. I assume the comment
> should be deleted?
>
> 2. com.google.gwt.user.client.ui.TabBar#TabBar -- Line 201 is
> "first.setHeight("100%");" and guess what's on line 206? The same
> thing! I'm guessing one of these is not necessary.
>
>
> Thanks,
>
> jay
>
> --
> http://groups.google.com/group/Google-Web-Toolkit-Contributors
>

-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors

Re: [gwt-contrib] Why is getOffsetWidth/getOffsetHeight returning 0 even after onLoad is called for LayoutPanel children?

[Joel Webber]

getOffsetWidth/Height() always read the current state of the widget's
backing element, which won't be updated until the layout panels are done
laying themselves out. All the layout panels have the potential to be
animated, and defer actually laying things out until the end of the current
event (in this case, the current "event" is likely the module startup). This
is pretty important for optimization, because layout can be expensive, and
you don't want to do any layout work until the app's done fiddling with its
structure. That's why you're seeing the "correct" value in a DeferredCommand
-- it's guaranteed to run after the current event.

If you really need to force layout earlier, you can call
LayoutPanel.forceLayout(). But be careful with this, because you can end up
forcing more layouts than you mean to (in the example you show, it would be
fine, but if you were to take a similar structure and nest it within another
that *also* called forceLayout(), you would end up doing extra work).

Hope that helps,
joel.

Le 27 septembre 2010 11:20, Damon Lundin  a écrit :

> I posted this over on the normal group but hopefully I can get some
> useful responses here.  I am attempting to use the new GWT
> LayoutPanels and unfortunately they are causing me some grief.  We are
> using the layout panels (RootLayoutPanel, DockLayoutPanel,
> LayoutPanel, etc) to arrange the overall layout of the panel.  Then,
> the children of one of these panels needs to know how big it is so
> that it can size one of its children properly to cause a scroll bar to
> appear.  As far as I can tell, the only way to do this is by calling
> getOffsetWidth and getOffsetHeight.  I know that these methods will
> return 0 if the widget is not attached but I am finding that in even
> putting the calls in onLoad, these methods are still returning 0.
> Clearly I don't understand when GWT and/or the browser figures out
> what the sizes of these layout panels are.
>
> Below is a simplification of my problem.  The widget added to the
> RootLayoutPanel cannot determine its size when it is attached to the
> DOM.  I made sure the widget had something in it and to prove that it
> ends up with a size, I added the call to the deferred command to
> display the size again.
>
> If you simply replace "RootLayoutPanel" with "RootPanel" then it will
> output the full window width.  What am I doing wrong here?
>
> final FlowPanel testWidget = new FlowPanel() {
>protected void onLoad() {
>int width = getOffsetWidth();
>Window.alert("width=" + width);  // Outputs "0"
>}
> };
>
> testWidget.add(new Label("Something"));
>
> RootLayoutPanel.get().add(testWidget);
>
> Window.alert("width=" + width);  // Outputs "0"
>
> DeferredCommand.add(new Command() {
>public void execute() {
>int width = testWidget.getElement().getOffsetWidth();
>Window.alert("width=" + width); // Outputs non-zero
>}
> }
>
> The value of 0 comes from FF 3.6.  IE6 has almost the same problem
> except that in the cases where FF returns 0, IE6 is returning 60
> (presumably the default size of the label).  In both cases, it returns
> the full Window width in the DeferredCommand.
>
> --
> http://groups.google.com/group/Google-Web-Toolkit-Contributors
>

-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors

Re: [gwt-contrib] Re: Let MenuItem implement HasEnabled (issue846801)

[Joel Webber]

Sorry about that. Will look at it this afternoon (US/EST).

Le 20 septembre 2010 04:45,  a écrit :

> Ping!
>
> On 2010/09/07 16:49:52, rjrjr wrote:
>
>> Please!
>>
>
>  On Tue, Sep 7, 2010 at 8:01 AM, Joel Webber <mailto:j...@google.com>
>>
> wrote:
>
>  > @rjrjr: I notice you own the bug -- do you have time to look at
>>
> this, or
>
>> > would you like me to take it off your hands?
>> >
>> > Le 6 septembre 2010 04:48, <mailto:johan.rydb...@gmail.com> a écrit
>>
> :
>
>> >
>> > Reviewers: ,
>> >>
>> >> Description:
>> >> Let MenuItem implement HasEnabled and update MenuBar to use this
>> >> information when selecting items.
>> >>
>> >> The themes are also updated with a gwt-MenuItem-disabled rule.
>> >>
>> >> This is an attempt to fix
>> >> http://code.google.com/p/google-web-toolkit/issues/detail?id=1649
>> >>
>> >>
>> >> Please review this at
>>
> http://gwt-code-reviews.appspot.com/846801/show
>
>> >>
>> >> Affected files:
>> >>  user/src/com/google/gwt/user/client/ui/MenuBar.java
>> >>  user/src/com/google/gwt/user/client/ui/MenuItem.java
>> >>
>>
> user/src/com/google/gwt/user/theme/chrome/public/gwt/chrome/chrome.css
>
>> >>
>> >>
>>
> user/src/com/google/gwt/user/theme/chrome/public/gwt/chrome/chrome_rtl.css
>
>> >>  user/src/com/google/gwt/user/theme/dark/public/gwt/dark/dark.css
>> >>
>>
> user/src/com/google/gwt/user/theme/dark/public/gwt/dark/dark_rtl.css
>
>> >>
>> >>
>>
>
> user/src/com/google/gwt/user/theme/standard/public/gwt/standard/standard.css
>
>> >>
>> >>
>>
>
>
> user/src/com/google/gwt/user/theme/standard/public/gwt/standard/standard_rtl.css
>
>> >>
>> >>
>> >> --
>> >> http://groups.google.com/group/Google-Web-Toolkit-Contributors
>> >>
>> >
>> >
>>
>
>
>
>
> http://gwt-code-reviews.appspot.com/846801/show
>
> --
> http://groups.google.com/group/Google-Web-Toolkit-Contributors
>

-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors

Re: [gwt-contrib] Re: How to detect HTML5 support?

[Joel Webber]

Daniel,

Which HTML5 features are you thinking of emulating on older browsers? It
seems to me that the only ones realistically emulatable are a few of the
input types -- most of the stuff like canvas, audio/video, et al would be
impossible without direct browser support. It might be kind of possible to
support a few of the things like local storage, but it would have to depend
on an ugly combination of flash/gears. Is this the kind of thing you're
thinking of?

Cheers,
joel.

Le 14 septembre 2010 07:00, dflorey  a écrit :

> Thanks for your reply. Yes, I know that html5 support is a mess.
> I guess I'll split up my stuff into separate projects supporting a
> single feature/property like webDB (requires native webDB / gears
> detection property), css3 transforms etc.
> Thanks for the link, very impressive!
>
> Daniel
>
> On Sep 14, 11:24 am, Thomas Broyer  wrote:
> > On Sep 13, 6:04 pm, dflorey  wrote:
> >
> > > I'm working on a HTML5 widget library that will emulate html5 when it
> > > is not supported by the browser (html5 form elements etc.)
> > > I don't know what is the best approach to take advantage of deferred
> > > binding to use the native/emulated classes.
> > > Is it better to extend the user agent to be able to detect Chrome7/
> > > Safari etc. (CSS3 transforms) or is it better to introduce a new
> > > property?
> >
> > If you want to "do it right", you'll actually have to add a bunch of
> > properties, because there's nothing like "HTML5 support". Even if you
> > only talk about form additions, some browsers support a few new  > type> values but not all, some say they support a given type but don't
> > provide any specific UI and/or validation (e.g.  in
> > WebKit), some browsers support validation (Chrome 7 is said to support
> > validation on html5test.com, but it won't abort submission if a
> > constrained input field –such as type=date or type=email– contains an
> > invalid value). And this is only about new input types and form
> > validation!
> >
> > BTW, have you looked athttps://code.google.com/p/gwt-ns/?
>
> --
> http://groups.google.com/group/Google-Web-Toolkit-Contributors
>

-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors

Re: [gwt-contrib] Wrong error message...

[Joel Webber]

Whoops, looks like I missed a rename :)
Thanks for the heads-up.

Le 13 septembre 2010 11:03, dflorey  a écrit :

> ...in ResizeComposite:25
>
> "java.lang.AssertionError: LayoutComposite requires that its wrapped
> widget implement HasLayout"
>
> should be
>
> "java.lang.AssertionError: LayoutComposite requires that its wrapped
> widget implements RequiresResize"
>
> --
> http://groups.google.com/group/Google-Web-Toolkit-Contributors
>

-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors

Re: [gwt-contrib] PopupPanel rolldown animation is only accesable with incubator!?

[Joel Webber]

@jlabanca: Sounds like a bit of an anachronism in the code. Is this
something we can clean up now (and do you need a hand getting it done if
so)?

Le 13 septembre 2010 03:50, stuckagain  a écrit :

> Hi,
>
> While factoring out a dependency on GWT incubator I stumbled upon the
> way the animation type is selected in the PopupPanel.
>
> This is what the javadoc says:
> /**
>   * Sets the animation used to animate this popup. Used by gwt-
> incubator to
>   * allow DropDownPanel to override the default popup animation. Not
> protected
>   * because the exact API may change in gwt 1.6.
>   *
>   * @param animation the animation to use for this popup
>   */
>  void setAnimation(ResizeAnimation animation) {
>resizeAnimation = animation;
>  }
>
> So basically I will have to put my code in the same package if I want
> to re-enable the rolldown animation instead of the centered one for
> PopupPanel...
>
> David
>
> --
> http://groups.google.com/group/Google-Web-Toolkit-Contributors
>

-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors

Re: [gwt-contrib] GWT Compiler or widget.gwt.xml file optimisation for 2.1 ?

[Joel Webber]

This is slightly off-topic, but I'm curious -- would having a formal nightly
build actually be acceptable for use within your locked-down environment?
And would the same go for "offline" dev-mode plugin installers?

Le 12 septembre 2010 08:43, David  a écrit :

> Eric,
>
> No I'm not using the draftCompile option, I will see if it improves even
> more.
>
> And yes, after removing the incubator from my project the whole
> project compile process only took 1/3rd of the time (7 minutes instead
> of 22 minutes). I guess the main reason is probably because we had to
> import both gen2 and widgetideas in.
>
> I am not able/allowed to get the trunk downloaded due to corporate
> policies. That's why in the past I asked if the GWT team did not want
> to consider daily builds/dev builds. So I will have to wait until 2.1
> is out.
>
> And when it is, I guess I will again have to ask for non installers
> for the IE/Firefox/Chrome plugins that do not mandate an internet
> connection :-S. So maybe for the poor corporate developers in very
> secure environments that fight to get GWT accepted: think about us!
> ;-)
>
> David
>
> On Fri, Sep 10, 2010 at 8:48 PM, Eric Ayers  wrote:
> > Hi David,
> >
> > Are you using the -draftCompile option? The reason I ask is that using
> this
> > option cuts out the optimization steps to make the compile run faster.
>  The
> > end result i that running the JDT compiler takes dominates the compile
> time
> > when using it.   Everything on the sourcepath is compiled at least once
> to
> > build the TypeOracle.  Every class that is actually used is run through
> the
> > JDT compile library twice.  So, removing even unreferenced files from the
> > source path should have a significant impact.
> >
> > We are considering all kinds of performance improvements, but keeping
> > modules small and independent and referencing the smallest number needed
> is
> > going to always give the best compilation performance.  In the future, if
> > you need one widget from a module that is full of unreferenced code, you
> > could define a custom one that includes just the paths you need to
> minimize
> > compile time.
> >
> > If you like, run your build with a tip of trunk GWT and add
> > -Dgwt.speedtracerlog=/tmp/speedtracer.html both with and without the
> > incubator dependencies and I can tell more about why your compile time
> > improved so dramatically.
> >
> > -Eric.
> >
> > On Fri, Sep 10, 2010 at 11:02 AM, stuckagain 
> wrote:
> >>
> >> Hi,
> >>
> >> I managed to finally factor our the incubator widgets from my medium
> >> sized application and now that I have no dependencies left I saw the
> >> compile time decrease with 66%. Which is an amazing.
> >>
> >> We were only using 2 widgets yet this library had such a huge impact.
> >>
> >> Are there any plans to improve on this in the future ?
> >>
> >> David
> >>
> >> --
> >> http://groups.google.com/group/Google-Web-Toolkit-Contributors
> >
> >
> >
> > --
> > Eric Z. Ayers
> > Google Web Toolkit, Atlanta, GA USA
> >
> > --
> > http://groups.google.com/group/Google-Web-Toolkit-Contributors
>
> --
> http://groups.google.com/group/Google-Web-Toolkit-Contributors
>

-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors

Re: [gwt-contrib] GWT Compiler or widget.gwt.xml file optimisation for 2.1 ?

[Joel Webber]

Wait, are you saying that your compile time went down *by* 2/3 (meaning to
1/3 of its original duration)?
And this is a result of pulling the incubator off of the classpath (and
hoisting out a couple of widgets)?

That would seem to be a pretty big difference!
@Eric: This might be interesting fodder for compiler optimizations.

Le 10 septembre 2010 11:02, stuckagain  a écrit :

> Hi,
>
> I managed to finally factor our the incubator widgets from my medium
> sized application and now that I have no dependencies left I saw the
> compile time decrease with 66%. Which is an amazing.
>
> We were only using 2 widgets yet this library had such a huge impact.
>
> Are there any plans to improve on this in the future ?
>
> David
>
> --
> http://groups.google.com/group/Google-Web-Toolkit-Contributors
>

-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors

[gwt-contrib] Re: Deletes the bikeshed. (issue816801)

[Joel Webber]

Don't worry, I'm sure it will come back next time we need to do something
"big" that needs time to settle. This ended up being a much, much better
pattern than the incubator, which just became a dumping ground with
version-skew hell...

Le 10 septembre 2010 03:28,  a écrit :

> Amen, nevertheless Bikeshed is still a good example for those who has
> strong willing to know and use the GWT, at least for me.
>
> On 2010/08/31 02:36:17, jlabanca wrote:
>
>> Bikeshed will always have a special place in my heart.  I remember not
>>
> that long
>
>> ago the first time I committed a Cell based widget to bikeshed, and
>>
> all those
>
>> hours we spent together tweaking the Expenses sample.  But alas, the
>>
> Expenses
>
>> sample has grown up and moved out to trunk, and the Scaffold app has
>>
> moved into
>
>> Roo.  Bikeshed is a beast from an ancient time, with no place in the
>>
> modern
>
>> world.  You will be missed bikeshed.  By most.
>>
>
>
>
> http://gwt-code-reviews.appspot.com/816801/show
>

-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors

Re: [gwt-contrib] [conference]

[Joel Webber]

Allez Nicolas!

Le 9 septembre 2010 09:18, nicolas de loof  a
écrit :

> For info,
>
> I'll speak at JugSummerCamp  conference
> tomorrow on GWT 2.
> Long live GWT :D
>
> Nicolas
>
> --
> http://groups.google.com/group/Google-Web-Toolkit-Contributors

-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors

Re: [gwt-contrib] Let MenuItem implement HasEnabled (issue846801)

[Joel Webber]

@rjrjr: I notice you own the bug -- do you have time to look at this, or
would you like me to take it off your hands?

Le 6 septembre 2010 04:48,  a écrit :

> Reviewers: ,
>
> Description:
> Let MenuItem implement HasEnabled and update MenuBar to use this
> information when selecting items.
>
> The themes are also updated with a gwt-MenuItem-disabled rule.
>
> This is an attempt to fix
> http://code.google.com/p/google-web-toolkit/issues/detail?id=1649
>
>
> Please review this at http://gwt-code-reviews.appspot.com/846801/show
>
> Affected files:
>  user/src/com/google/gwt/user/client/ui/MenuBar.java
>  user/src/com/google/gwt/user/client/ui/MenuItem.java
>  user/src/com/google/gwt/user/theme/chrome/public/gwt/chrome/chrome.css
>  user/src/com/google/gwt/user/theme/chrome/public/gwt/chrome/chrome_rtl.css
>  user/src/com/google/gwt/user/theme/dark/public/gwt/dark/dark.css
>  user/src/com/google/gwt/user/theme/dark/public/gwt/dark/dark_rtl.css
>
>  user/src/com/google/gwt/user/theme/standard/public/gwt/standard/standard.css
>
>  
> user/src/com/google/gwt/user/theme/standard/public/gwt/standard/standard_rtl.css
>
>
> --
> http://groups.google.com/group/Google-Web-Toolkit-Contributors
>

-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors

Re: [gwt-contrib] IE6/7/8 huge speed problems when adding Stylenames on the fly.

[Joel Webber]

[+some people who have looked at this problem in the past]

Le 19 août 2010 09:36, stuckagain  a écrit :

> Hi,
>
> I found out that using something like addStylename() in an onmouseover
> can have really catastrophic effects on performance in IE (6/7 and 8).
> In fact IE8 seems to be worse than the older versions. In my
> applications the browser locks up for many seconds even minutes
> running at 100% CPU. DynaTrace reveals that the browser is busy doing
> layout calculations.
>
> For example we were doing a style change when moving the mouse over a
> big table. In some situations this would block the browser for many
> seconds (sometimes minutes, depending on the complexity of the UI).
>
> If I just directly set the style attribute changes directly in the
> code it takes almost no CPU with the same complex UI. The problem here
> is that I loose a lot of flexibility in my UI to use CSS to do the
> styling (what if I want to change more than just the color for
> example).
>
> I know there is something like CssResource, but as I understand it, it
> will not solve the issue in this case since I still need to use an
> addStyleName.
>
> Would there be a way, or wouldn't it be an great Idea, that GWT would
> have support in CssResource to copy style attributes from the
> CssResouce directly in the styles of the element that I am
> targetting ? That way I would not need a addStylename/addClassname but
> I still have the flexibility to write down these changes in a CSS
> file.
>
> Or did I overlook such a feature ?
>
> As I understood, the declarative UI mechanism in GWT is doing such
> things, but in our apps we can not use this.
>

We haven't built anything like this, but we've definitely seen this problem
before. It doesn't seem unreasonable to be able to extract the text of a
CSSResource rule's properties (a bit unfortunate, since it only affects IE
and would be slower everywhere else -- maybe it would be better to provide a
more abstract mechanism that could "do the right thing" everywhere). There
is also some complexity added by the fact that the fastest way to apply such
a style would be "Element.style = '{css string}'". But the only efficient
way to do this would be to set the whole thing at once (meaning you couldn't
easily mix them).

If I recall correctly (Kelly, Jaime, & John please check me on this), the
speed problems on this case in IE tended to be a combination of layout and
style matching. Layout can be mitigated a bit if you "separate" the table
from the rest of the page by putting it in a position:absolute container
(putting it in a layout panel does this), but that may not help enough
and/or fit your design.

-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors

Re: [gwt-contrib] HTML5 tags in com.google.gwt.dom.DOM.gwt.xml module

[Joel Webber]

Le 15 août 2010 10:40, Cristiano  a écrit :

> Hello all,
> I need to work with new HTML5 elements: video and SVG's tags.
>
> Now I'm doing some experiment and I'm working out this HTML5 support
> by myself on a modified src of GWT: I'm adding some new "Element"
> subclasses for some example element (,,,) and
> extending the com.google.gwt.dom.client.Document.java and
> com.google.gwt.user.client.DOM.java classes by adding in a
> straightforward way all the SVG and video element creation methods I
> need for my tests.
>
> I want to ask you if is there anyone else who is doing the same on an
> official branch of GWT or into the incubator, so not to do a duplicate
> work.
>

Jaime and Philip have started looking at this, but I don't believe they've
committed anything yet (and I doubt they'd mind a little help). There are
also a couple of projects out there that have begun this as well (see
below). Maybe it's time to start a concerted effort to clean up all our
HTML5 libraries and wrappers?

  http://code.google.com/p/gwt-mobile-webkit/
  http://code.google.com/p/gwt-html5-media

-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors

[gwt-contrib] Re: "This is a bug in JSORestrictionsChecker"

[Joel Webber]

Le 11 août 2010 15:11, BobV  a écrit :

> > At first glance, this would appear to anger the SingleJSO gods. However,
> > because NodeImpl contains implementations of all Node methods, there is
> no
> > actual ambiguity as to which method implementation to bind to. The "this
> is
> > a bug" wording in the error also raised my eyebrows a bit :)
>
> Is NodeImpl abstract?


Tried both with and without. But there is only one JSO implementation of
each method in the Node interface, so there can be no ambiguity in which one
to call.

-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors

[gwt-contrib] "This is a bug in JSORestrictionsChecker"

[Joel Webber]

Bob & Lex,

I just ran into an "interesting" error message while experimenting with some
JSO stuff that you might be able to shed some light on. First, here's the
error:

> InternalCompilerException: Already seen an implementing JSO subtype
(DocumentImpl) for interface (Node) while examining newly-added type
(ElementImpl). This is a bug in JSORestrictionsChecker.

The structure that triggered this is the following:

interface Node
interface Element extends Node
interface Document extends Node

class NodeImpl extends JSO implements Node
class ElementImpl extends NodeImpl implements Element
class DocumentImpl extends NodeImpl implements Document

At first glance, this would appear to anger the SingleJSO gods. However,
because NodeImpl contains implementations of all Node methods, there is no
actual ambiguity as to which method implementation to bind to. The "this is
a bug" wording in the error also raised my eyebrows a bit :)

If I'm correct about the lack of actual ambiguity here, it would seem that
the restrictions checker is just being a bit too aggressive. Do either of
you have any sense for how difficult it would be to fix this (and the
associated code in the compiler itself that generates the method dispatch
code)? I'm perfectly willing to dig into it myself, but thought you might be
able to provide a bit of context.

Thanks,
joel.

-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors

Re: [gwt-contrib] Re: Make GWT template javascript suitable for XHTML

[Joel Webber]

The best way would be to upload a patch to http://
gwt-code-reviews.appspot.com/ . That makes it much easier to understand the
diffs.

Le 1 août 2010 11:07, Henri  a écrit :

> I updated function computeScriptBase() in IFrameTemplate.js to work
> with DOM javascript functions instead of document.write, which seems
> to work, and would like you to look at it. How can I send this file to
> you?
>
> On Jul 23, 3:17 pm, Joel Webber  wrote:
> > We've tried to get rid of the document.write() tricks before, but with no
> > success. There's always some squirrely case that crops on (especially on
> IE)
> > that's forced us to put them back in. There are also a couple of specific
> > corner cases that rely on document.write(), which would need to be
> > preserved:
> > 1. computeScriptBase() uses it to find the "current" script element, so
> it
> > can compute the base url from which it was loaded.
> > 2. It's used to determine when script injection (i.e., 

Re: [gwt-contrib] Phasing in a new, unified linker

[Joel Webber]

[+matt, who's one of the few people I know outside of Google creating custom
linkers]

I'm 100% on board with this as well. These things weren't all that carefully
designed for extension from the beginning, so it's going to be difficult to
make significant changes to them without breaking existing linker
extensions. Having one "true" linker, except for fundamentally different
cases (like Chrome and Firefox extensions) would be hugely convenient.

Le 26 juillet 2010 12:37, Scott Blum  a écrit :

> SGTM as far as process.
>
> Is the new linker designed to curtail extension, or to sanely encourage it?
>  The existing primary linkers ended up getting extended in brittle ways.
>
> On Mon, Jul 26, 2010 at 12:06 PM, Lex Spoon  wrote:
>
>> Joel, Miguel, GWTers,
>>
>> I am trying to phase in a new linker as the default GWT linker, and I
>> could use some feedback on how that is accomplished.
>>
>> My first thought was to modify the cross-site linker in place, as was
>> started by this patch:
>>
>> http://gwt-code-reviews.appspot.com/674802/show
>>
>>
>> After further thought, though, the changes in that patch are simply not
>> backward compatible. The most fundamental problem is that there are
>> currently linkers extending the XSLinker class, and any major change to
>> XSLinker will break these other ones. Additionally, the cross-site linker
>> has $wnd==window, but that's no longer true in the unified linker. Both of
>> these problems won't affect most apps, but an indeterminate few will be
>> broken by simply committing the above patch.
>>
>> Here's an alternate phase-in plan that avoids the above two problems:
>>
>> 1. Make a new linker class and new linker name, so as not to disturb any
>> code inheriting from our existing linkers. Commit the above patch under the
>> new names. Anyone who can live without dev mode support can use it
>> immediately.
>>
>> 2. Add development mode support to the new linker.
>>
>> 3. Redirect the "std" linker to the new one. We could add a deprecated
>> "iframe" name for the iframe linker for anyone who desperately needs it.
>> Note that people using the "std" linker must already be using $wnd in the
>> necessary places.
>>
>> 4. Deprecate the iframe and xs linkers, and after a year or two remove
>> them. Users of the cross-site linker will need to make sure they use $wnd in
>> the right places before they change over.
>>
>>
>> A benefit of this approach is that most apps use the "std" linker and will
>> simply pick up the improvements without needing any changes. Updating people
>> currently on the cross-site linker is trickier, but I don't see any way to
>> get around the $wnd/window problem. Their code simply needs to be updated.
>>
>> -Lex
>>
>>
>>  --
>> http://groups.google.com/group/Google-Web-Toolkit-Contributors
>>
>
>

-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors

Re: [gwt-contrib] Make GWT template javascript suitable for XHTML

[Joel Webber]

We've tried to get rid of the document.write() tricks before, but with no
success. There's always some squirrely case that crops on (especially on IE)
that's forced us to put them back in. There are also a couple of specific
corner cases that rely on document.write(), which would need to be
preserved:
1. computeScriptBase() uses it to find the "current" script element, so it
can compute the base url from which it was loaded.
2. It's used to determine when script injection (i.e., 

Re: [gwt-contrib] Re: IE9 Preview 3 issues

[Joel Webber]

Thanks, Brendan. I entered issue 5125 to capture the general IE9 support
issue. I agree that it seems likely we'll be able to shift to an IE9 that
derives from the "standard" browser base classes. Nothing would make me
happier :)

Le 24 juin 2010 15:08, Brendan Kenny  a écrit :

> I haven't verified this on another machine, but it appears that the
> new IE9 Preview (when in full IE9 standards mode) no longer accepts
> markup in document.createElement(), which is DomImplTrident's approach
> to creating several elements (like buttons). I've filed an issue here:
> http://code.google.com/p/google-web-toolkit/issues/detail?id=5058
> It seems like any GWT project that uses buttons or input elements
> (among others) will trigger the error and stop running. To see it in
> action, visit showcase with the console open, or run the following in
> the console:
> var b = document.createElement("");
>
> The good thing (for the web) is that this seems to be the correct
> behavior wrt standards. For GWT, IE9's DOM impl might get to be a lot
> closer to DomImplStandard. Microsoft also doesn't include normal
> navigation in the preview, so regular users won't be using it as their
> browser and run into this problem too soon, but this change does
> appear to be coming.
>

Le 24 juin 2010 15:19, Brendan Kenny  a écrit :

> Also--and I haven't completely figured this out yet--something seems
> to be going on with support for IE's ancient filters. I'm not aware of
> any use of filters in GWT outside of maybe a PNG transparency fix (for
> IE6? not sure), but I'm sure there are third party module authors that
> use them to add HTML5/CSS3-style features.
>
> element.filters is throwing an error and element.style.filter is being
> ignored (again, just checked on my machine). This must be partly a bug
> (it's just wrong that checking "!document.body.filters" would fail),
> but it might be a sign that filters are going away.
>
> I use filters for IE in a module for cross-browser CSS3-like
> transformations, and I believe that this will leave me without a way
> to support them in IE9, so I'll definitely be keeping up with this.

-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors

Re: [gwt-contrib] Re: UiBinder. Code style for constant parsers.

[Joel Webber]

Le 22 juin 2010 07:03, Konstantin.Scheglov  a
écrit :

>
> > Pretty much everything we've done so far has been limited to
> automatically
> > exposing the Java-level APIs in all their ugliness. The h/v alignment
> values
> > are implemented somewhat manually, but for things like enums I really
> like
> > the idea that they can be exposed completely automatically.
> >
> > On the other hand, it would be nice to have prettier names. Perhaps we
> could
> > find some sort of convention for exposing prettier names for
> [pseudo-]enums.
> > What about a shortName() method on the enum itself?
>
>   Hm...
>  Yes, I think that it is possible to create some generic parser for
> enum-like constants.
>  However because they are not real enums, following things come to
> mind:
>
> 1. During registration in AttributeParsers we will need to pass list
> of values;
> 2. To check for shortName() using reflection;
> 3. To test that each such constant parser instance works correctly, I
> would write special ui.xml file.
>
>  Also one more thing worries me. Do you think that it is OK to add
> into GWT classes on this level information which is used only by some
> presentation of GWT? I mean that parsing ui.xml files is part of
> UiBinder, so it should be problem of UiBinder how to parse it.


It *does* seem a little odd to have to add a UiBinder-specific "short name"
to every enum (or enum-alike) used as a widget property (especially if they
somehow end up in the compiled output). On the other hand, it would also
kind of suck to have to put them in a completely separate place, which most
widget authors would simply forget to do.

On second thought, maybe we can actually get away with just convention. Most
enums (e.g., Style.Unit) have names that are upper-case by convention, but
we could allow UiBinder to specify them in a case-insensitive manner without
ambiguity. That would leave only a handful of special cases (like the
TextAlignmentParser patch you just sent).

@rjrjr, konstantin: How does that sound to you both?

-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors

[gwt-contrib] Re: UiBinder. Parser for TextAlignConstant (issue612803)

[Joel Webber]

@rjrjr: What say ye? Have you considered doing something like this before,
and perhaps found a way to generalize it such that we don't have to create a
separate attribute parser for every enum?

Le 22 juin 2010 07:14,  a écrit :

> Reviewers: jgw,
>
> Description:
> It uses "friendly" names.
>
> I will post patch with adding support for names like this for
> horizontal/vertical alignments (in addition, not replace to keep
> compatibility with existing code) later.
>
> Please review this at http://gwt-code-reviews.appspot.com/612803/show
>
> Affected files:
>  user/src/com/google/gwt/uibinder/attributeparsers/AttributeParsers.java
>
>  
> user/src/com/google/gwt/uibinder/attributeparsers/TextAlignConstantParser.java
>  user/test/com/google/gwt/uibinder/UiBinderJreSuite.java
>
>  
> user/test/com/google/gwt/uibinder/attributeparsers/TextAlignConstantParser_Test.java
>  user/test/com/google/gwt/uibinder/test/UiJavaResources.java
>
>
>

-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors

Re: [gwt-contrib] UiBinder tweaks for GWT Designer

[Joel Webber]

Konstantin,

I've not gone over these proposals in great detail, but it does seem like a
reasonable idea to build "design time" hooks into UiBinder-generated code.
One very important caveat would be that it must be possible for the compiler
to strip them out completely in production mode (this seems likely, but we'd
have to be very careful to make sure it happens in practice).

I'm going to have to defer to Ray on the architectural details (I haven't
touched this generator in a while), and I suspect he'd want to make sure the
proposed mechanisms would be generally useful for other kinds of design
tools. He's on vacation this week, so I doubt he'll be able to look into it
until next week at the earliest.

@rjrjr: Please do have a look at this when you have a moment, and if you'd
like me to look at anything in particular, I'd be happy to.

Cheers,
joel.

Le 23 juin 2010 06:40, Konstantin.Scheglov  a
écrit :

>
>  To support UiBinder in GWT Designer we need to have several changes
> in UiBinder generators, writer and parsers.
>  I will describe below these changes as they are done now.
>  In real patch I will group as much implementation details as
> possible into single class like DesignTimeUtils or GWTDesignerSupport.
> It will check for GWT Designer presence and do something only in this
> case.
>
>  So, main question is following. Will GWT team accept patch with such
> changes?
>  This would allow us avoid creating internal patches for 2.0 and each
> future version of GWT.
>
>
> 1. Declare in binder implementation interface and field with it.
> Something like this:
>   public static interface WBPObjectHandler {void handle(String
> path, Object object);}
>   public WBPObjectHandler wbpObjectHandler;
>In method createAndBindUi() directly after creating each Widget
> instance (but before applying setX() methods) "wbpObjectHandler" is
> used to notify GWT Designer about new widget and its path in XML. GWT
> Designer bind Widget instance to model (using path) and also asks
> default values for all properties using getX() methods.
>
>  Path in XML is "/" separated string of indexes.
>  For example in
> 
>
>
>
>
> 
>
>  "0/1" is FlowPanel
>  "0/1/0" is Button
>
> 2. Declare in binder implementation Map with values of attributes.
>   public final java.util.Map wbpAttributes = new
> java.util.HashMap();
>  and fill it, here is example if code generated for ui.xml above
>
>if (wbpObjectHandler != null) wbpObjectHandler.handle("0/1/0",
> f_Button2);
>f_Button2.setText("New Button");
>wbpAttributes.put("0/1/0 text", "New Button");
>f_FlowPanel1.add(f_Button2);
>if (wbpObjectHandler != null) wbpObjectHandler.handle("0/1",
> f_FlowPanel1);
>f_FlowPanel1.setStyleName("" + style.panel() + "");
>
>  GWT Designer needs to know attribute values to show them to user in
> properties table. Not all properties have getter, so we can not get
> these values for existing Widget object.
>
>
> 3. In special parsers for panels, remember also values of attributes
> for artificial elements. For example "Cell" in CellPanelParser (and
> "Dock" in DockPanel).
>
>// Parse horizontal and vertical alignment attributes.
>if (cellElem.hasAttribute(HALIGN_ATTR)) {
>  String value = cellElem.consumeAttribute(HALIGN_ATTR,
> hAlignConstantType);
>  writer.addStatement("%1$s.setCellHorizontalAlignment(%2$s,
> %3$s);",
>  fieldName, childFieldName, value);
>  //XXX   writer.addStatement("wbpAttributes.put(\"%s\", %s);",
> widgetElem.getPath() + " Cell." + HALIGN_ATTR, value);
>  //XXX >Instantiations
>}
>
>
>
> 4. To allow quick updates of design canvas as user changes properties,
> without reloading GWT context each time, we should:
> 4.1. Generate Binder implementation class with new name each time, so
> be able to define each time new class in same ClassLoader. Right now
> we just add current time to the name of class.
>//XXX // generate class with new name each time, to allow refresh in
> same ClassLoader
>implName += "_wbp" + System.currentTimeMillis();
>//XXX >Instantiations
> 4.2. To parse/render UI.XML file content without saving, i.e. from
> memory/editor, generate should try to read document from memory.
> Something like this:
>  private Document getW3cDoc(MortalLogger logger, String templatePath)
>  throws UnableToCompleteException {
>//XXX {
>  String content = System.getProperty("wbp.gwt.UiBinder " +
> templatePath);
>  if (content != null) {
>Document doc = null;
>try {
>  doc = new
> W3cDomHelper(logger.getTreeLogger()).documentFor(content);
>} catch (SAXParseException e) {
>  logger.die("Error parsing XML (line " + e.getLineNumber() +
> "): "
>  + e.getMessage() + " " + content, e);
>} catch (Throwable e) {
>  logger.die("Error parsing XML  " + content, e);
>}
>return doc;
>  }
>}
>//XX

Re: [gwt-contrib] Re: Improving event handling, as initiated in 1.6

[Joel Webber]

Just to let everyone know, I've finally gotten around to picking up this
task again, and have updated the linked wave with my proposals. Please feel
free to chime in; I could use the feedback.

Le 11 juin 2010 11:13, Thomas Broyer  a écrit :

> On Thu, Jun 10, 2010 at 11:59 PM, Dan  wrote:
> > I don't suppose you could bump the wave Thomas?   I seem to not have
> > access to do anything but add blank replies...
>
> I've added you to the wave. Don't know what happened as you're a
> member of GWT-Contrib, which has full access to the wave...
>
> --
> http://groups.google.com/group/Google-Web-Toolkit-Contributors
>

-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors

Re: [gwt-contrib] UiBinder. Code style for constant parsers.

[Joel Webber]

Le 19 juin 2010 10:34, Konstantin.Scheglov  a
écrit :

>
>  Why existing horizontal/vertical alignment parsers use so unfriendly
> names for alignments? "ALIGN_RIGHT" looks not very good in XML. Why
> not just "right"? This would be more natural for people with HTML
> background.
>
>  I ask because I have already TextAlignConstantParser and not sure
> which style to use - same as in existing parsers, or more friendly.
> Right now it looks so:
>
>  private static final String PREFIX =
> "com.google.gwt.user.client.ui.TextBoxBase.ALIGN_";
>  private static final HashMap values = new
> HashMap();
>
>  static {
>values.put("left", PREFIX + "LEFT");
>values.put("center", PREFIX + "CENTER");
>values.put("right", PREFIX + "RIGHT");
>values.put("justify", PREFIX + "JUSTIFY");
>  }


Pretty much everything we've done so far has been limited to automatically
exposing the Java-level APIs in all their ugliness. The h/v alignment values
are implemented somewhat manually, but for things like enums I really like
the idea that they can be exposed completely automatically.

On the other hand, it would be nice to have prettier names. Perhaps we could
find some sort of convention for exposing prettier names for [pseudo-]enums.
What about a shortName() method on the enum itself?

-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors

Re: [gwt-contrib] mail patch

[Joel Webber]

Thanks, Stephen.
@Dan: Is this still applicable, or has it been fixed already?

Le 9 juin 2010 13:21, Stephen Haberman  a écrit :

> Hi,
>
> I was playing with the Mail example this morning and saw a stack trace
> casting the Message class to Comparable for the TreeMap inside of the
> MailSelectionModel.toString(). Seemed to happen most reliably when
> clicking "select all on this page". A simple fix is attached.
>
> Thanks,
> Stephen
>
>
> --
> http://groups.google.com/group/Google-Web-Toolkit-Contributors

-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors

Re: [gwt-contrib] Any ETA for 2.1?

[Joel Webber]

We're also working to get the new widgets & libraries stabilized well before
that, though we don't have hard dates. One thing to look for would be the
removal of the "Note: This class is new and its interface subject to
change." warnings in the javadoc. Or just ask here :)

Le 21 juin 2010 14:29, Chris Ramsdale  a écrit :

> While this shouldn't be taken as a binding set of dates, we are looking to
> wrap up a 2.1 RC in late Q3, with GA release in early Q4.
>
>
> On Mon, Jun 21, 2010 at 12:30 PM, Thomas Broyer wrote:
>
>> Hi Googlers^H^H G-men!
>>
>> Do you have any ETA for 2.1 M2 (or RC1?), and/or 2.1 "GA"?
>>
>> We're looking at RequestFactory, ActivityManager and data presentation
>> widgets for a new project, but they're far from complete now
>> (particularly RequestFactory, and ActivityManager isn't plugged with
>> the History). So we'd like to know when do you think they'll be
>> "usable enough" so we can start use them, or if we should rather plan
>> on using something else (GWT-RPC, our already-existing-though-not-
>> perfect PlaceManager, etc.)
>>
>> --
>> http://groups.google.com/group/Google-Web-Toolkit-Contributors
>>
>
>  --
> http://groups.google.com/group/Google-Web-Toolkit-Contributors
>

-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors

Re: [gwt-contrib] Re: DockPanelParser and width/height attributes

[Joel Webber]

I'll have a look this afternoon. w.r.t. the other patch, I'm running all the
tests right now. Thanks for both of these!

Le 18 juin 2010 11:08, Konstantin.Scheglov  a
écrit :

>
>  I've added patch for review.
>  http://gwt-code-reviews.appspot.com/633802/show
>
> BTW, I've added also other patch yesterday and would like to add more
> of them in future (TextAlignConstant parser, AbsolutePanel support,
> etc). What is procedure for asking review? Sorry if I'm too
> impatient. ;-)
>
> On Jun 18, 5:26 pm, Joel Webber  wrote:
> > That certainly looks like a leftover implementation detail that could be
> > cleaned up. If you don't mind putting together a patch I'd be happy to
> > commit it.
> >
> > Le 18 juin 2010 08:23, Konstantin.Scheglov <
> konstantin.scheg...@gmail.com> a
> > écrit :
> >
> >
> >
> > >  Is there reason to have separate handling for width/height
> > > attributes?
> > >  As I can see, CellPanelParser.parseCellAttributes() already handles
> > > these attributes and generates same statements.
> >
> > >  // And they can optionally have a width.
> > >  if (child.hasAttribute("width")) {
> > >writer.addStatement("%1$s.setCellWidth(%2$s, \"%3$s\");",
> > >fieldName, childFieldName,
> > > child.consumeRawAttribute("width"));
> > >  }
> >
> > >  // And they can optionally have a height.
> > >  if (child.hasAttribute("height")) {
> > >writer.addStatement("%1$s.setCellHeight(%2$s, \"%3$s\");",
> > >fieldName, childFieldName,
> > > child.consumeRawAttribute("height"));
> > >  }
> >
> > >  // Parse the CellPanel-specific attributes on the Dock element.
> > >  CellPanelParser.parseCellAttributes(child, fieldName,
> > > childFieldName, writer);
> >
> > > --
> > >http://groups.google.com/group/Google-Web-Toolkit-Contributors
>
> --
> http://groups.google.com/group/Google-Web-Toolkit-Contributors
>

-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors

Re: [gwt-contrib] DockPanelParser and width/height attributes

[Joel Webber]

That certainly looks like a leftover implementation detail that could be
cleaned up. If you don't mind putting together a patch I'd be happy to
commit it.

Le 18 juin 2010 08:23, Konstantin.Scheglov  a
écrit :

>
>  Is there reason to have separate handling for width/height
> attributes?
>  As I can see, CellPanelParser.parseCellAttributes() already handles
> these attributes and generates same statements.
>
>  // And they can optionally have a width.
>  if (child.hasAttribute("width")) {
>writer.addStatement("%1$s.setCellWidth(%2$s, \"%3$s\");",
>fieldName, childFieldName,
> child.consumeRawAttribute("width"));
>  }
>
>  // And they can optionally have a height.
>  if (child.hasAttribute("height")) {
>writer.addStatement("%1$s.setCellHeight(%2$s, \"%3$s\");",
>fieldName, childFieldName,
> child.consumeRawAttribute("height"));
>  }
>
>  // Parse the CellPanel-specific attributes on the Dock element.
>  CellPanelParser.parseCellAttributes(child, fieldName,
> childFieldName, writer);
>
> --
> http://groups.google.com/group/Google-Web-Toolkit-Contributors
>

-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors

Re: [gwt-contrib] FileUpload.setEnabled(false) causing invalid access of stack red zone 0x141055ff8 rip=0x101098a05

[Joel Webber]

Even if that were a stupid thing to do, it shouldn't be crashing like that
:) I suspect that most browsers would either silently fail or throw an
exception under those circumstances, but that should be pretty harmless.

What browser/platform are you seeing this on? At a glance, the bug looks
like something to do with the plugin's marshalling code.


Le 4 juin 2010 13:47, Aaron Steele  a écrit :

> I'm seeing something fairly funky occur if I disable a FormUpload
> widget in a FormPanel.onSubmit() handler (here's the code:
> http://pastebin.com/SSSqGtB1). Basically the Dev server and browser
> crashes with the following console message:
>
> Invalid access of stack red zone 0x141055ff8 rip=0x101098a05
>
> Running it with log=SPAM prints the following output over and over and
> over again until the crash:
>
> Invoke native method
> @com.google.gwt.dom.client.Element::setPropertyBoolean(Ljava/lang/String;Z)
> - this=JavaScript object(12)
> - arg[0]=string: 'disabled'
> - arg[1]=bool: true
> - return void
> Invoke native method
> @com.google.gwt.dom.client.Element::setPropertyBoolean(Ljava/lang/String;Z)
> - this=JavaScript object(7)
> - arg[0]=string: 'disabled'
> - arg[1]=bool: true
> - return void
>
> What's the expected behavior if a FormUpload is disabled in the
> FormPanel.onSubmit() handler (if disabling a FormUpload is kind of a
> stupid thing to do, uh, FHMP)?
>
> --
> http://groups.google.com/group/Google-Web-Toolkit-Contributors
>

-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors

Re: [gwt-contrib] Tabless

[Joel Webber]

I'm fine with leaving h/v undeprecated for the time being. It is worth
pointing out that the vertical alignment *within* cells of a vertical panel
isn't usually useful, because as John says, it tightly wraps its content
vertically. Getting a vertical panel to stretch out vertically such that
there is any freedom of vertical movement for its children is both unusual
and hard to achieve.

Le 3 juin 2010 12:56, Ray Ryan  a écrit :

> No argument. And since we've never, ever managed to actually delete a
> deprecated class so far as I know, the issue may not come up for a while…
>
>
> On Thu, Jun 3, 2010 at 9:53 AM, Amir Kashani wrote:
>
>> While I think deprecating these widgets is definitely the right move, I
>> don't think the normal policy of removing them after one release will work
>> (is this still the actual policy?). Breaking an application's dependence on
>> these widgets and switching to the new equivalents is a particular daunting
>> task for a large application as it has to happen all at once. That is,
>> either the entire app becomes standards compliant or none of it. That could
>> be a awful lot of tables & CSS to fix.
>>
>> - Amir
>>
>> On Wed, May 26, 2010 at 8:36 AM, Ray Ryan  wrote:
>>
>>> Joel, can we  @Deprecate all the redundant non-flow panels yet? It's
>>> getting harder and harder for people to discover the right thing to do.
>>>
>>>
>>> On Wed, May 26, 2010 at 7:15 AM, Joel Webber  wrote:
>>>
>>>> The FlowPanel (just a simple  that leaves its children's styles
>>>> unmodified) already allows you to do this. For the vertical case, this 
>>>> tends
>>>> to happen naturally with block-level children.
>>>>
>>>> The horizontal case is trickier, however. Using float:left captures
>>>> some, but definitely not all cases (vertical alignment is quite hard).
>>>> inline-block isn't supported on all browsers (and has behavior quirks even
>>>> on modern browsers). Basically, there's no simple answer that actually 
>>>> works
>>>> across browsers, so we haven't yet tried to offer a widget that does this
>>>> automatically. Your best bet is to actually just use a FlowPanel and style
>>>> its children using the kinds of tricks described in the linked Wikipedia
>>>> article. Maybe one day we'll get hbox/vbox/flexbox across browsers, but
>>>> until then horizontal alignment is extremely difficult to generalize.
>>>>
>>>> Cheers,
>>>> joel.
>>>>
>>>> Le 25 mai 2010 06:39, Ivo  a écrit :
>>>>
>>>> The next GWT Developments, will have alternatives to the VerticalPanel
>>>>> and HorizontalPanel, using no table tags??
>>>>> http://en.wikipedia.org/wiki/Tableless_web_design
>>>>>
>>>>> For instance, the HorizontalPanel could have a alternative named
>>>>> HorizontalFlowPanel, that instead of generate this code:
>>>>>
>>>>> 
>>>>>  
>>>>>  
>>>>>   cell1
>>>>>  
>>>>>  
>>>>>   cell2
>>>>>  
>>>>>  
>>>>> 
>>>>>
>>>>> Generate that:
>>>>>
>>>>> 
>>>>>  cell1
>>>>> 
>>>>> 
>>>>>  cell2
>>>>> 
>>>>>
>>>>> This alternative is lighter for the browser, and for the developer
>>>>> when we needs to know what code are GWT generating. You have some
>>>>> development in this area?
>>>>>
>>>>> --
>>>>> http://groups.google.com/group/Google-Web-Toolkit-Contributors
>>>>>
>>>>
>>>>  --
>>>> http://groups.google.com/group/Google-Web-Toolkit-Contributors
>>>>
>>>
>>>  --
>>> http://groups.google.com/group/Google-Web-Toolkit-Contributors
>>>
>>
>>  --
>> http://groups.google.com/group/Google-Web-Toolkit-Contributors
>>
>
>  --
> http://groups.google.com/group/Google-Web-Toolkit-Contributors
>

-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors

Re: [gwt-contrib] Tabless

[Joel Webber]

That's all basically correct. The VerticalPanel alignment methods are a
little funky to reimplement in FlowPanel -- someone would have to sit down
and actually try all the cases to make sure they work (I'm fairly sure
text-alignment: will do it, but I'd need to confirm).

Le 3 juin 2010 12:11, Ray Ryan  a écrit :

> So that'd mean deprecating DockPanel, SplitPanel, TabPanel and
> VerticalPanel. Any others? We shouldn't deprecate RootPanel, right?
>
> The deprecation language will probably need to point out that the new
> panels aren't just drop in replacements — that they require standards mode,
> and are most easily used under a RootLayoutPanel. Is that accurate? Anything
> else to say?
>
> For VerticalPanel, we'd tell them to use FlowPanel instead, but what could
> we tell them about its alignment methods? Is there generic advice to offer
> for doing that kind of thing in a FlowPanel?
>
> On Wed, May 26, 2010 at 8:41 AM, Joel Webber  wrote:
>
>> Well... HorizontalPanel is still useful in some instances, and we have no
>> way of providing the same behavior in a general way because CSS layout is a
>> bloody mess. I'd be ok with deprecating the others (StackPanel, TabPanel,
>> VerticalPanel, and DockPanel) though.
>>
>> Le 26 mai 2010 11:36, Ray Ryan  a écrit :
>>
>>>  Joel, can we  @Deprecate all the redundant non-flow panels yet? It's
>>> getting harder and harder for people to discover the right thing to do.
>>>
>>> On Wed, May 26, 2010 at 7:15 AM, Joel Webber  wrote:
>>>
>>>> The FlowPanel (just a simple  that leaves its children's styles
>>>> unmodified) already allows you to do this. For the vertical case, this 
>>>> tends
>>>> to happen naturally with block-level children.
>>>>
>>>> The horizontal case is trickier, however. Using float:left captures
>>>> some, but definitely not all cases (vertical alignment is quite hard).
>>>> inline-block isn't supported on all browsers (and has behavior quirks even
>>>> on modern browsers). Basically, there's no simple answer that actually 
>>>> works
>>>> across browsers, so we haven't yet tried to offer a widget that does this
>>>> automatically. Your best bet is to actually just use a FlowPanel and style
>>>> its children using the kinds of tricks described in the linked Wikipedia
>>>> article. Maybe one day we'll get hbox/vbox/flexbox across browsers, but
>>>> until then horizontal alignment is extremely difficult to generalize.
>>>>
>>>> Cheers,
>>>> joel.
>>>>
>>>> Le 25 mai 2010 06:39, Ivo  a écrit :
>>>>
>>>> The next GWT Developments, will have alternatives to the VerticalPanel
>>>>> and HorizontalPanel, using no table tags??
>>>>> http://en.wikipedia.org/wiki/Tableless_web_design
>>>>>
>>>>> For instance, the HorizontalPanel could have a alternative named
>>>>> HorizontalFlowPanel, that instead of generate this code:
>>>>>
>>>>> 
>>>>>  
>>>>>  
>>>>>   cell1
>>>>>  
>>>>>  
>>>>>   cell2
>>>>>  
>>>>>  
>>>>> 
>>>>>
>>>>> Generate that:
>>>>>
>>>>> 
>>>>>  cell1
>>>>> 
>>>>> 
>>>>>  cell2
>>>>> 
>>>>>
>>>>> This alternative is lighter for the browser, and for the developer
>>>>> when we needs to know what code are GWT generating. You have some
>>>>> development in this area?
>>>>>
>>>>> --
>>>>> http://groups.google.com/group/Google-Web-Toolkit-Contributors
>>>>>
>>>>
>>>>  --
>>>> http://groups.google.com/group/Google-Web-Toolkit-Contributors
>>>>
>>>
>>>  --
>>> http://groups.google.com/group/Google-Web-Toolkit-Contributors
>>>
>>
>>  --
>> http://groups.google.com/group/Google-Web-Toolkit-Contributors
>>
>
>  --
> http://groups.google.com/group/Google-Web-Toolkit-Contributors
>

-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors

[gwt-contrib] Re: RR : Rework ImageResourceGenerator to address several issues (issue335802)

[Joel Webber]

Crap, sorry. I/O ate my brain. Reviewing now.

Le 2 juin 2010 10:04,  a écrit :

> Ping.
>
> http://gwt-code-reviews.appspot.com/335802/show
>

-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors

Re: [gwt-contrib] Tabless

[Joel Webber]

Well... HorizontalPanel is still useful in some instances, and we have no
way of providing the same behavior in a general way because CSS layout is a
bloody mess. I'd be ok with deprecating the others (StackPanel, TabPanel,
VerticalPanel, and DockPanel) though.

Le 26 mai 2010 11:36, Ray Ryan  a écrit :

> Joel, can we  @Deprecate all the redundant non-flow panels yet? It's
> getting harder and harder for people to discover the right thing to do.
>
> On Wed, May 26, 2010 at 7:15 AM, Joel Webber  wrote:
>
>> The FlowPanel (just a simple  that leaves its children's styles
>> unmodified) already allows you to do this. For the vertical case, this tends
>> to happen naturally with block-level children.
>>
>> The horizontal case is trickier, however. Using float:left captures some,
>> but definitely not all cases (vertical alignment is quite hard).
>> inline-block isn't supported on all browsers (and has behavior quirks even
>> on modern browsers). Basically, there's no simple answer that actually works
>> across browsers, so we haven't yet tried to offer a widget that does this
>> automatically. Your best bet is to actually just use a FlowPanel and style
>> its children using the kinds of tricks described in the linked Wikipedia
>> article. Maybe one day we'll get hbox/vbox/flexbox across browsers, but
>> until then horizontal alignment is extremely difficult to generalize.
>>
>> Cheers,
>> joel.
>>
>> Le 25 mai 2010 06:39, Ivo  a écrit :
>>
>> The next GWT Developments, will have alternatives to the VerticalPanel
>>> and HorizontalPanel, using no table tags??
>>> http://en.wikipedia.org/wiki/Tableless_web_design
>>>
>>> For instance, the HorizontalPanel could have a alternative named
>>> HorizontalFlowPanel, that instead of generate this code:
>>>
>>> 
>>>  
>>>  
>>>   cell1
>>>  
>>>  
>>>   cell2
>>>  
>>>  
>>> 
>>>
>>> Generate that:
>>>
>>> 
>>>  cell1
>>> 
>>> 
>>>  cell2
>>> 
>>>
>>> This alternative is lighter for the browser, and for the developer
>>> when we needs to know what code are GWT generating. You have some
>>> development in this area?
>>>
>>> --
>>> http://groups.google.com/group/Google-Web-Toolkit-Contributors
>>>
>>
>>  --
>> http://groups.google.com/group/Google-Web-Toolkit-Contributors
>>
>
>  --
> http://groups.google.com/group/Google-Web-Toolkit-Contributors
>

-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors

Re: [gwt-contrib] Tabless

[Joel Webber]

The FlowPanel (just a simple  that leaves its children's styles
unmodified) already allows you to do this. For the vertical case, this tends
to happen naturally with block-level children.

The horizontal case is trickier, however. Using float:left captures some,
but definitely not all cases (vertical alignment is quite hard).
inline-block isn't supported on all browsers (and has behavior quirks even
on modern browsers). Basically, there's no simple answer that actually works
across browsers, so we haven't yet tried to offer a widget that does this
automatically. Your best bet is to actually just use a FlowPanel and style
its children using the kinds of tricks described in the linked Wikipedia
article. Maybe one day we'll get hbox/vbox/flexbox across browsers, but
until then horizontal alignment is extremely difficult to generalize.

Cheers,
joel.

Le 25 mai 2010 06:39, Ivo  a écrit :

> The next GWT Developments, will have alternatives to the VerticalPanel
> and HorizontalPanel, using no table tags??
> http://en.wikipedia.org/wiki/Tableless_web_design
>
> For instance, the HorizontalPanel could have a alternative named
> HorizontalFlowPanel, that instead of generate this code:
>
> 
>  
>  
>   cell1
>  
>  
>   cell2
>  
>  
> 
>
> Generate that:
>
> 
>  cell1
> 
> 
>  cell2
> 
>
> This alternative is lighter for the browser, and for the developer
> when we needs to know what code are GWT generating. You have some
> development in this area?
>
> --
> http://groups.google.com/group/Google-Web-Toolkit-Contributors
>

-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors

[gwt-contrib] Re: Adds a mobile-friendly drag-scroll implementation. (issue530801)

[Joel Webber]

We should definitely consider how we're going to bring gesture/touch events
into the existing event framework. I went ahead and wrote this the simple
way because it will only ever need to work on mobile webkit browsers, which
all safely support addEventListener() and don't leak memory.

Le 14 mai 2010 15:07,  a écrit :

>
> Joel, I think post I/O perhaps we should add touch events support to
> dispatchEvent() rather than call addEventListener directly, so you'd be
> able to invoke sinkEvents(Event.TOUCH_EVENTS);. I did this for my apps
> and have working code.
>
>
>
> http://gwt-code-reviews.appspot.com/530801/diff/1/9
> File /bikeshed/src/com/google/gwt/mobile/client/TouchHandler.java
> (right):
>
> http://gwt-code-reviews.appspot.com/530801/diff/1/9#newcode57
> /bikeshed/src/com/google/gwt/mobile/client/TouchHandler.java:57: },
> capture);
> Memory leak?
>
>
> http://gwt-code-reviews.appspot.com/530801/show
>

-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors

Re: [gwt-contrib] Setting DocType or Standards mode within generated cache.html files

[Joel Webber]

Erin,

The DOCTYPE of the script HTML won't affect the behavior of the outer page.
You should only have to put a simple  in the outer page --
that's it. If you're still having troubles with LayoutPanel after that, ping
me.

Cheers,
joel.

Le 13 mai 2010 15:04, Erin  a écrit :

> I am trying to use the TabLayoutPanel, but having issues within IE.
> Using Debug bar, I can see that the frame created from the generated
> files has document mode of IE5 Quirks. There is no DocType set within
> the generated cache.html. I have tried just adding the DocType
> definition to the page that my jJavascript reference to the module is
> on, but though the frame containing the main page is IE7Standards, the
> frame containing the module is still Quirks. Is there a setting that
> can be made in the java code or the module definition(gwt.xml) that
> can set the DocType on the frames created to hold the gwt module
> generated code.
>
> I would appreciate any assistance.
>
> Thanks,
>
>  Erin
>
> --
> http://groups.google.com/group/Google-Web-Toolkit-Contributors
>

-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors

Re: [gwt-contrib] Re: use ParameterizedType at GWT#create method (issue429801)

[Joel Webber]

I'm not the right one to review this, but I just wanted you to (a) apologize
for your email getting caught by the spam filter (which I just fixed), and
(b) let you know that we're all pretty slammed getting ready for I/O, so it
might be a while before anyone has time to take a look. This looks like a
fairly complex change, so it would be very helpful if you could post some
sort of (at least rough) design document.

Le 1 mai 2010 03:50,  a écrit :

> Hi All
>
> This patch is my first contribution.
> I don't know whom to ask for this review.
> Please teach it to me?
>
>
> http://gwt-code-reviews.appspot.com/429801/show
>
> --
> http://groups.google.com/group/Google-Web-Toolkit-Contributors
>

-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors

Re: [gwt-contrib] History misses token set by Window.Location.replace()

[Joel Webber]

Sorry, I spoke to soon. Again, see the comments on the issue, but it looks
like it *might* be possible to make this work, but it's going to require a
fair amount of spelunking on IE to catch all the corner cases.

Le 7 mai 2010 08:17, Joel Webber  a écrit :

> I've added comments to the bug so they don't get lost.
> The short form of the story is that I'm not sure it's possible to make this
> work in the general case because of various cross-browser issues (I'm always
> happy to be proven wrong, though!)
>
> Le 6 mai 2010 18:58, jarrod  a écrit :
>
> In my module's entry point, I check the current History token, and if
>> it is blank, I set it to a default value. This allows my normal MVP
>> mechanisms to show the default view on startup.
>>
>> I set the default value using Window.Location.replace() so as not to
>> create an entry in the browser's history stack. Unfortunately, History
>> misses this new token and returns the blank one from before I replaced
>> the URL.
>>
>> This looks like a defect to me. Anyone? I filed an issue with code
>> samples...
>> http://code.google.com/p/google-web-toolkit/issues/detail?id=4919
>>
>> --
>> http://groups.google.com/group/Google-Web-Toolkit-Contributors
>>
>
>

-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors

Re: [gwt-contrib] History misses token set by Window.Location.replace()

[Joel Webber]

I've added comments to the bug so they don't get lost.
The short form of the story is that I'm not sure it's possible to make this
work in the general case because of various cross-browser issues (I'm always
happy to be proven wrong, though!)

Le 6 mai 2010 18:58, jarrod  a écrit :

> In my module's entry point, I check the current History token, and if
> it is blank, I set it to a default value. This allows my normal MVP
> mechanisms to show the default view on startup.
>
> I set the default value using Window.Location.replace() so as not to
> create an entry in the browser's history stack. Unfortunately, History
> misses this new token and returns the blank one from before I replaced
> the URL.
>
> This looks like a defect to me. Anyone? I filed an issue with code
> samples...
> http://code.google.com/p/google-web-toolkit/issues/detail?id=4919
>
> --
> http://groups.google.com/group/Google-Web-Toolkit-Contributors
>

-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors

Re: [gwt-contrib] Re: Selection/Cursor for RichTextArea implementation

[Joel Webber]

You can always just put it up in a little code.google.com (or github, as you
see fit) project. That usually makes it easier for others to try it out.

Le 30 avril 2010 14:03, kozura  a écrit :

> Ok, understood, just didn't want it to get lost in the mix.  Maybe for
> now I'll just attach the library as-is to the issue, and worry about
> making it GWT-compliant later.
>
> Thanks,
> jk
>
> On Apr 30, 11:57 am, John LaBanca  wrote:
> > External contributions are always welcome, but we've all been heads down
> for
> > the last couple of weeks getting ready for Google I/O.  We promise to be
> > more attentive and look at your proposal once I/O is over.
> >
> > Thanks,
> > John LaBanca
> > jlaba...@google.com
>
> --
> http://groups.google.com/group/Google-Web-Toolkit-Contributors
>

-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors

Re: [gwt-contrib] RootLayoutPanel

[Joel Webber]

Kerr,

Can you show me roughly the code needed to get into this state? It sounds
like it could be a problem, but I'm having a slightly hard time imagining
the precise code that got you here.

Cheers,
joel.

Le 15 avril 2010 12:34, kerrr  a écrit :

> Hi,
>
> I've been playing around with RootLayoutPanel and have some questions
> about how it works.
>
> I had a UI layed out by placing widgets in lements on a page using
> RootLayout.get("foo").add(widget).  This was fine.  I wanted to try
> adding a LayoutPanel on top to achieve a LightBox style effect.  This
> was all goign well untill I wanted to gt rid of the LayoutPanel.  I
> couldn't work out how to do it.  I removed the LayoutPanel from the
> RootLayoutPanel but none of the underlying ui could be clicked.
> Eventually I discovered that I needed to remove the RootLayoutPanel
> from the RootPanel.  This works but leaves the singleton
> RootLayoutPanel detached and calling RootLayoutPanel.get() again
> simply returns the detached RootLayoutPanel.  Trying to add anything
> to it throws an exception.  You can work around this my reattaching
> the RootLayoutPanel yourself, but this seems a bit ugly.
>
> So here are my thoughts on an improvement.  Please let me know if
> there is any reason why this would cause a problem.
>
> 1. Have RootLayoutPanel detach itself automatically from its parent if
> all it's children are removed.
> 2. Defer attaching the RootLayoutPanel to RootPanel untill a child is
> added to it.
>
> I'm planning on implementing my own replacement RootLayoutPanel to see
> how it works, but please let me know if there is anything I should
> consider when doing this.
>
> Cheers
> Kerr
>
> --
> http://groups.google.com/group/Google-Web-Toolkit-Contributors
>

-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors

Re: [gwt-contrib] Javascript generation suggestion

[Joel Webber]

Ray, weren't you looking at something like this recently?

Le 15 avril 2010 17:42, Domingos  a écrit :

> Hello everyone,
>
> Here I am going to suggest other solution to represent the JVM class
> singleton behaviour. Look at my suggestion below:
>
>
> var $clinit186 = function() {
>  // static initialization
> };
>
> SomeClass .prototype.aMethod = function() {
>$clinit186();
>var mth = SomeClass .prototype.aMethod = function(p1, p2) {
>
>};
>mth.apply(this, arguments);
> };
>
>
> var instance = new SomeClass();
> instance.aMethod (1, 2);
>
>
>
>
> This solution seams to be much more light weight than da current
> solution:
>
> var $clinit186 = function() {
>$clinit186 = nullMethod;
>// static initialization
> };
>
> SomeClass.prototype.aMethod = function(p1, p2) {
>
> };
>
>
> var instance = new SomeClass();
> ($clinit186(), instance.aMethod (1, 2));
>
>
> What do you people think about?
>
> Best Regards,
> Domingos
>
> --
> http://groups.google.com/group/Google-Web-Toolkit-Contributors
>

-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors

Re: [gwt-contrib] Text Area enhancement

[Joel Webber]

Allahbaksh,

That seems like it would be useful, though looking at the code I'm a little
wary as to whether it works in all circumstances (font-size changes, etc).
The first step would be to convert it to Java (usually pretty
straightforward) and test it under all the circumstances you can think of --
change the font-size, resize the element, try it on all browsers, and so
forth.

Cheers,
joel.

Le 19 avril 2010 03:02, Allahbaksh Asadullah  a
écrit :

> Hi,
> I want to get the coordinates of the Cursor position in TextArea so
> that I can show the popup appropriately. Please find the similar
> implementation of  http://enobrev.info/cursor/.
>
> I am not sure whether a new method to get the coordinates of the
> cursor is really helpful to other but I think it would grea.
>
> Warm Regards,
> Allahbaksh
>
> --
> http://groups.google.com/group/Google-Web-Toolkit-Contributors
>

-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors

Re: [gwt-contrib] Re: Comment on EnumOptimizations in google-web-toolkit

[Joel Webber]

[+cromwell: What's the current state of the enum optimizations? I seem to
recall they were partially done, but forgot where the doc is]

On Mon, Apr 12, 2010 at 11:28 AM,  wrote:

> Comment by piotr.swigon:
>
> Joel,
>
> I would like to ask if anything has changed regarding enums implementation
> in GWT 2.0.X ? We're having a discussion in gwt-google-apis if we should
> start using enums instead of string-enum pattern, and some information about
> current state would be highly appreciated.
>
>
> For more information:
> http://code.google.com/p/google-web-toolkit/wiki/EnumOptimizations
>
> --
> http://groups.google.com/group/Google-Web-Toolkit-Contributors
>
> To unsubscribe, reply using "remove me" as the subject.
>

-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors

Re: [gwt-contrib] Re: RFC: Web worker proposal and proof of concept

[Joel Webber]

Brendan,

At a quick glance, this looks pretty much like I would have expected a good
workers library to look like. Is there any way I *could* convince you to
make a wave of it? It's a pretty big description, and would probably diverge
badly on a mailing list (@everyone: If anyone who frequents this list
doesn't yet have a wave account, don't hesitate to ping me so I can get you
invites).

If I understand correctly, it looks like you've made this work without
patching GWT proper. Assuming that's correct, are there any changes that
would have made it simpler or more efficient?

Cheers,
joel.

On Thu, Apr 8, 2010 at 9:41 PM, Brendan Kenny  wrote:

> Gah, well, it should have been a wave.
>
> Aside from the assorted grammatical problems, the library is
> https://code.google.com/p/gwt-ns/
> and the all important goal of "To patching of GWT" should of course be
> "NO patching."
>
> Also, I'm not sure if the workflow of the current implementation is
> entirely clear.
>
> 1) A class extends the WorkerEntryPoint and does what it needs to do,
> dealing with messages from its parent as they arrive. If it fulfills
> the requirements listed above under "Valid Worker Modules," it can be
> instantiated and used as a web worker.
> 2) The parent project instantiates a worker from a worker module as
> listed under "To Use a Worker." The object created can only give
> messages, receive them, and be terminated.
> 3) Developers compile *only* the parent project. The invoked generator
> and linkers handle the rest.
>
>
> On Apr 8, 8:05 pm, Brendan Kenny  wrote:
> > This might be a bit unusual. I have a fairly reasonable proposal for
> > supporting web workers in GWT proper, and a working proof of concept
> > that shouldn't come anywhere near the core toolkit. Everyone seems
> > busy with what looks like 2.1 and the upcoming I/O, so I'm not
> > expecting miracles, but I would appreciate any wider perspective and
> > maybe some Compiler insight to make the implementation less of a
> > complete hack.
> >
> > A few months ago I put together a module to get workers working nicely
> > with the GWT compiling/linking process. It was originally just on a
> > bit of a lark, but it's proven so easy to use (thanks to GWT, not me)
> > that I've ended up developing a few projects with it, two examples of
> > which I've posted over with the code (http://code.google.com/p/gwt-
> > ns/). I finally have some time to come back to the module and finish
> > some lingering issues, but thought I might try and get some other
> > perspectives first. If there's a GWT 2.1 web worker skunkworks project
> > already in progress, please let me know now =)
> >
> > To give credit where its due: several files came from the Speedtracer
> > worker overlay code and one or two files came from GALGWT. I've
> > preserved copyright notices everywhere, and everything else is also
> > Apache 2.0 licensed. I also finally got around to watching 2008's GWT
> > Extreme! and found out my compilation scheme is very similar to what
> > Ray Cromwell was up to two years ago (which probably happens a lot).
> > He called it the Generator+Linker+Generator+Linker pattern, though in
> > this case it's more Generator+Linker(+Generator+Linker)*.
> >
> > Anyway, like Ray Ryan, I wish this were a wave, but I'll stick to the
> > board for now. I tried to keep it short, but it got rather long, so if
> > there is interest I can make it look a bit more like an actual design
> > document in a wave and hook it up to the water cooler.
> >
> > === Motivation ===
> > Web workers, as currently specifiedhttp://
> www.whatwg.org/specs/web-workers/current-work/
> > have two primary requirements. They are separate Javascript files,
> > loaded in a worker constructor that
> > 1. Doesn't access the DOM
> > 2. Don't share state or context with other execution contexts (e.g.
> > their parent script).
> > Once a worker is loaded and running, the worker and its parent can
> > pass messages to each other, usually in JSON form.
> >
> > At least for transitional worker support, I'm suggesting a third
> > condition
> > 3. No single code execution will throw a slow script warning, even
> > when run *normally* in an older/slower browser.
> > This does necessarily limit functionality, e.g. ruling out the usual
> > worker examples of blocking I/O and long running calculations. The
> > first isn't really welcome in the GWT world, anyways, and really any
> > synchronous operation is a bad fit for GWT/Javascript. This condition
> > can also just be considered transitional; I'll go with it for now and
> > just assert that another level of deferred binding could give allow
> > more flexibility on this point.
> >
> > Accepting these three conditions, a true worker object becomes
> > functionally equivalent to a simple isolated object with only post and
> > receive message methods in its exposed interface (an Actor, if you're
> > into that sort of thing). In practice, the only difference is that
> > some newer platforms 

Re: [gwt-contrib] TabLayoutPanel: Distinguish between user- and code-initiated SelectionEvents

[Joel Webber]

[I just commented directly on the linked issue]

On Thu, Apr 8, 2010 at 11:17 PM, jarrod  wrote:

> I would really like to see a way to distinguish between
> SelectionEvents (and BeforeSelectionEvents) in TabLayoutPanel based on
> whether the event occurred in response to a user action (e.g. clicking
> a tab) or a programmatic call (e.g. TabLayoutPanel#selectTab).
>
> I have created an issue for this request:
> http://code.google.com/p/google-web-toolkit/issues/detail?id=4834
>
> Any thoughts on a possible work around? Will sub-classing
> TabLayoutPanel mean I need to also sub-class the TabLayoutPanelParser
> for use with UiBinder?
>
> --
> http://groups.google.com/group/Google-Web-Toolkit-Contributors
>
> To unsubscribe, reply using "remove me" as the subject.
>

-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors

Re: [gwt-contrib] Did Double.doubleToLongBits() get removed?

[Joel Webber]

The Quake code has only ever been tested on WebKit (Nitro & V8), so I would
check it carefully before using. float/doubleToLongBits() in Javascript is a
truly, truly foul piece of work that is horrifically inefficient. Use with
caution.

On Fri, Apr 2, 2010 at 2:35 PM, John Tamplin  wrote:

> On Wed, Mar 31, 2010 at 8:49 AM, Dennis  wrote:
>
>> in
>> http://groups.google.com/group/google-web-toolkit-contributors/browse_thread/thread/a5193c6a82eddb5e/ba5dbb35ecc0f512
>> Ray Cromwell submitted an implementation for (amongst others)
>> Double.doubleToLongBits().
>>
>> I can't find this in the current gwt 2.0.3 - has this been removed at
>> some point?
>>
>
> It wasn't ever included, apparently because it wasn't totally stable across
> browsers.
>
> --
> John A. Tamplin
> Software Engineer (GWT), Google
>
>  --
> http://groups.google.com/group/Google-Web-Toolkit-Contributors
>

-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors

To unsubscribe, reply using "remove me" as the subject.

Re: [gwt-contrib] TabLayoutPanel suggestion: Add tab-position property

[Joel Webber]

On Wed, Mar 24, 2010 at 1:01 PM, dflorey  wrote:

> I've been missing that one as well.
> I can provide patches if desired.
>
> --


On Wed, Mar 24, 2010 at 11:40 AM, dflorey  wrote:

>
> I just needed a TabLayoutPanel with Tabs on the bottom instead of tabs
> on the top. I copied the TabLayoutPanal and changed the orientation.
> I'd like to suggest to add this feature as an option in another cstr.
> It requires just 3 lines of code ;-)
>

[sorry for the slow response -- swamped lately]
Would you mind entering issues for these and pointing me at them? I know it
sounds kind of pedantic for little changes, but we're trying to manage our
workflow more carefully these days. Patches always speed things up, of
course :)

Cheers,
joel.

-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors

Re: [gwt-contrib] Re: LayoutImplIE6 and onResize()

[Joel Webber]

John,

Sorry for the slow response -- I've had a browser window open for several
days to respond, but I keep getting pulled off onto other things.

It sounds like this is indeed an ordering bug. It's hard to be sure
precisely when IE's going to call onresize() (onmove() and onresize() are
obscure non-standard events that aren't documented all that well). But what
you're saying makes perfect sense, and I'll try to find a way to get the
ordering straight. Would you mind entering an issue (or pointing me to it if
you already have) that captures this?

It may take me a little while to get a test case together and work out a
solution. Please let me know anything you discover that might help.

Thanks,
joel.

On Wed, Mar 31, 2010 at 5:51 AM, jd  wrote:

> Does anyone think this is a bug?  Or is it expected behaviour?
>
> On Mar 23, 10:40 pm, jd  wrote:
> > Something else related to this problem:  when a DockLayoutPanel is
> > animated to resize its children, onResize() is called *before* the
> > resize but my child component was expecting to examine its new size.
> >
> > The JavaDoc for onResize says "This method must be called whenever the
> > implementor's size has been modified."
> >
> > "Has been modified" signifies that it should be called *after* the
> > resize has occurred which would definitely be more useful and
> > expected.
> >
> > Currently, onResize is not called at the end of the animation because
> > the animations onComplete() calls Layout.layout() and not
> > Layout.layout(0, callback).  i.e. if the callback was passed then
> > onResize() should also get called at the end of the animation.
> >
> > John
> >
> > On Mar 20, 12:31 pm, jd  wrote:
> >
> >
> >
> > > Hi,
> >
> > > I am experiencing a problem using a DockLayoutPanel with IE6 where a
> > > child widgets RequiresResize.onResize() is fired before the
> > > LayoutImplIE6 has updated the widgets width and height with new
> > > values.
> >
> > > I have a child widget that needs to know when it is resized so it can
> > > resize a nested MapWidget.  I must do this because setting the maps
> > > height to 100% does not work inside a DockLayoutPanel child in IE7
> > > because the element is positioned absolutely using top, bottom, left,
> > > right.  Using this same absolute positioning for the child map does
> > > work in IE7 but obviously not in IE6.
> >
> > > My current solution is to implement RequiresResize and explicitly
> > > resize the map to the dimensions of the container.  This works well in
> > > all browsers except IE6 because the container element has not yet been
> > > resized by LayoutImplIE6
> >
> > > It looks like this is due to the RootLayoutPanel registering its
> > > window resize handler before the LayoutImplIE6 registers its handler.
> >
> > > I could work around this problem by either making the map a direct
> > > child of the DockLayoutPanel which means that the browser specific
> > > resize problems are handled by the Layout.
> >
> > > Alternatively, I could use another nested LayoutPanel or implement
> > > browser specific resize logic myself.
> >
> > > But it seems that onResize() is designed for situations like this?
> >
> > > Thanks,
> >
> > > John
>
> --
> http://groups.google.com/group/Google-Web-Toolkit-Contributors
>
> To unsubscribe, reply using "remove me" as the subject.
>

-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors

Re: [gwt-contrib] DockLayoutPanel addLayoutCompleteHandler

[Joel Webber]

I was hoping that because most people (not using the Maps API) wouldn't need
this, it wouldn't be necessary to provide a special case for "layout
complete" outside of the existing animation callbacks. Does it not work to
put the Map in a RequiresResize container and call its layout method when
onResize() is called?

On Thu, Mar 18, 2010 at 2:42 AM, jd  wrote:

> Hi, I use DockLayoutPanel with Google maps and there is a known issue
> where any component inside a DockLayoutPanel that depends on the size
> of its container must be initialized like this:
>
> root.animate(0, new AnimationCallback()
> {
>  public void onLayout(Layer layer, double progress)
>  {
>  }
>
>  public void onAnimationComplete()
>  {
>  // init internal widget
>  }
> }
>
> I was thinking it might be more obvious to include a handler after the
> layout is complete?
>
> addLayoutCompleteHandler()?
>
> --
> http://groups.google.com/group/Google-Web-Toolkit-Contributors
>
> To unsubscribe from this group, send email to
> google-web-toolkit-contributors+unsubscribegooglegroups.com or reply to
> this email with the words "REMOVE ME" as the subject.
>

-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors

Re: [gwt-contrib] Re: Array implementation for Lightweight Collections. Pure Java implementation only. (issue232801)

[Joel Webber]

I think we're talking about two different things here. Rodrigo's (valid)
point is that implementing immutability sanely early on is a good idea. And
this implementation is pretty much analogous to the one you describe from
Cocoa.

The question at hand is whether it makes sense to get an immutable
collection from a mutable one, with no copies. There are two ways to do
this:
1. Create an immutable "view" of a mutable list, but with no guarantees that
the list won't be mutated by the original owner later.
2. "Freeze" a mutable list into an immutable view of said list, making the
former "runtime immutable".

(1) solves the problem of a class giving access to one of its internal
collections without having to guard against external mutation. (2) can be
used to replicate the "builder" pattern.

I don't have a strong opinion about (2) myself, but (1) is pretty damned
important, because it's the source of innumerable stupid defensive copies in
JRE code. The provider of such an interface would just have to be very clear
about whether the "immutable" list might be modified later (because it's a
view on a mutable one).

On Mon, Mar 22, 2010 at 5:23 PM, Ray Ryan  wrote:

> I think you're missing my point. An object is immutable if there exists no
> api to mutate it. That should be enough.
>
> Let me put it another way. It's lame that the JRE achieves immutability by
> turning mutate methods into runtime errors. It will be equally lame of us to
> do the same, especially since we can't enforce it at production time. It
> would be much better to provide an api such that there is not even possible
> to compile the mutate call (without cheating with casts, but then you know
> you're being bad).
>
> The Cocoa approach to this is to have interfaces like NSArray be immutable,
> and then have NSMutableArray extend NSArray. If we're going to roll our own
> collection classes, it seems to me we could do the same: e.g.
> LiteImmutableList and List extends LiteImmutableList.
>
> rjrjr
>
>
> On Mon, Mar 22, 2010 at 2:12 PM, Rodrigo Chandia wrote:
>
>> I like the *concept* of immutability being introduced early in the
>> development. The initial implementation may be limiting for some use cases,
>> but I believe it is a useful concept to expand on. If specific needs require
>> simultaneous mutable and immutable access we can provide implementations to
>> address that problem (copy on write semantics, for example).
>>
>> 2010/3/22 Ray Ryan 
>>
>> I guess I'm overstating my opposition. It's not really dangerous, but it
>>> just doesn't seem useful. Just by existing I think it'll promote confusion
>>> and perhaps bad habits. Why bother?
>>>
>>> I think the 90% use case is for something like the following (writing in
>>> JRE terms here):
>>>
>>> private final List magicValues;
>>> {
>>>List buildValues = new ArrayList();
>>>buildValues.add("able");
>>>buildValues.add("baker");
>>>buildValues.add("charlie");
>>>magicValues = Collections.unmodifiableList(buildValues);
>>> }
>>>
>>> Ta da: it's a read only structure and no copy was made. In our world, we
>>> could do better:
>>>
>>> private final ImmutableLiteList magicValues;
>>> {
>>>LiteList buildValues = new LiteList();
>>>buildValues.add("able");
>>>buildValues.add("baker");
>>>buildValues.add("charlie");
>>>magicValues = buildValues.immutableView(); // more equivalent of
>>> cast()
>>> }
>>>
>>> The user never thinks in terms of freezing, just cutting off access. No
>>> extra dev mode mechanism to maintain, and basically the same idiom already
>>> in use in Java.
>>>
>>
>>
>  --
> http://groups.google.com/group/Google-Web-Toolkit-Contributors
>
> To unsubscribe from this group, send email to
> google-web-toolkit-contributors+unsubscribegooglegroups.com or reply to
> this email with the words "REMOVE ME" as the subject.
>

-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors

To unsubscribe from this group, send email to 
google-web-toolkit-contributors+unsubscribegooglegroups.com or reply to this 
email with the words "REMOVE ME" as the subject.

Re: [gwt-contrib] Proposal for including easyXDM as a new cross-domain Transport/RPC

[Joel Webber]

[+matt]

I can't speak to any experience with either of these libraries, but this
also sounds like the work Matt's been doing here:
  http://code.google.com/p/gwt-rpc-plus/

Can anyone speak to the relationship
between these libraries? I'd love to see a standard way of dealing with XDM
make it into the GWT core.

On Sun, Mar 21, 2010 at 10:59 AM, Sean Kinsey  wrote:

> I've seen many questions on the net on how to enable cross-domain
> requests with GWT, and most of the solutions I've seen mentioned has
> been less efficient than what I know the easyXDM library can offer.
>
> For those who has never heard of it, easyXDM is a library that
> conveniently abstracts away all the hassle of hash/fragments,
> window.name and postMessage, and that exposes a simple and reliable
> Socket that allows strings to be passed between two documents (no
> reloads, so both documents can keep state).
> Whatever kind of transport being used internally (based on what the
> browser offers etc) the stack will provide _reliability_, queuing (and
> fragmenting if necessary) and security.
>
> Whats interesting with the library is that it also contains an Rpc
> class, that allows you to invoke methods, with complex arguments
> (JSON), and with or without return values.
>
> From the consumers calling an RPC method is as easy as doing
> //set up rpc object, only a few simple lines
> var rpc = new easyXDM.Rpc(...
>
>
> rpc.nameOfMethod(arg1, arg2, arg3, function
> methodToHandleResponse(response){
> ...
> });
>
>
> Why don't you give it a try?
> The library has several easy to follow examples at http://easyxdm.net/;
> the Rpc sample can be found at
> http://consumer.easyxdm.net/current/example/methods.html
>
> Regards
> Sean Kinsey
>
> --
> http://groups.google.com/group/Google-Web-Toolkit-Contributors
>
> To unsubscribe from this group, send email to
> google-web-toolkit-contributors+unsubscribegooglegroups.com or reply to
> this email with the words "REMOVE ME" as the subject.
>

-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors

To unsubscribe from this group, send email to 
google-web-toolkit-contributors+unsubscribegooglegroups.com or reply to this 
email with the words "REMOVE ME" as the subject.

Re: [gwt-contrib] Re: IE9 preview support ?

[Joel Webber]

I just installed the preview the other day as well, and most things seem to
be working ok (the UA script should detect it as IE8 for the time being). As
others point out on this thread, the DOMContentLoaded thing is expected
(because they added addEventListener()) but likely harmless.

I haven't had time to look into it too deeply yet, but I'm really hoping
that they're far enough along in standards implementation that we can switch
away from the DOMImplTrident base and consider IE9 a "standard" browser.
We'll see how that goes in practice soon...

On Sun, Mar 21, 2010 at 9:24 PM, Brendan Kenny  wrote:

> I get the same DOMContentLoaded error, but that's as expected. Check
> out the "addEventListener event registration" section in the release
> notes:
>
> http://ie.microsoft.com/testdrive/info/ReleaseNotes/Default.html#WPKI
>
> My applications all work as well--even while throwing that error--
> which is weird. I wouldn't think the bootstrap script would work if
> the event is detected as implemented but never fires, but there it is.
>
> I'm a big fan of Microsoft's choice of chrome for the preview...no one
> will be using this as their default browser and complaining
> accordingly.
>
> On Mar 21, 2:32 pm, Matt Mastracci  wrote:
> > I'm seeing the same thing in our application. I haven't had time to dig
> into it, but I'm seeing 'unknown event DOMContentLoaded' in the developer
> tools console.  The GWT Showcase example works, however.  Maybe some sort of
> doctype issue?
> >
> > On 2010-03-20, at 4:53 AM, nicolas.deloof wrote:
> >
> >
> >
> > > Hi,
> >
> > > I tried my GWT 2.0 webapp with the recent test build of IE9 and it
> > > doesn't display. I wonder IE9 is not recognized as IE, event whit "IE8
> > > mode" set.
> >
> > > The browser may use a unsuported user-agent ID, is there allready any
> > > test done on this "new" browser ? roadmap to support its better
> > > support for standards ?
> >
> > > Cheers,
> > > Nicolas
> >
> > > --
> > >http://groups.google.com/group/Google-Web-Toolkit-Contributors
> >
> > > To unsubscribe from this group, send email to
> google-web-toolkit-contributors+unsubscribegooglegroups.com or reply to
> this email with the words "REMOVE ME" as the subject.
>
> --
> http://groups.google.com/group/Google-Web-Toolkit-Contributors
>
> To unsubscribe from this group, send email to
> google-web-toolkit-contributors+unsubscribegooglegroups.com or reply to
> this email with the words "REMOVE ME" as the subject.
>

-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors

To unsubscribe from this group, send email to 
google-web-toolkit-contributors+unsubscribegooglegroups.com or reply to this 
email with the words "REMOVE ME" as the subject.

Re: [gwt-contrib] ClientBundle produce memory leaks in IE6

[Joel Webber]

I am able to reproduce this leak as well, and can confirm that it only
happens on IE6 (not 7+). If I use a standard image url rather than a
ClientBundle, the leak goes away. Interestingly, though, it doesn't appear
to be a "standard" circular-ref leak, because Microsoft's own leak detector
doesn't flag it, and the memory is recouped when you navigate away from the
page (IE7+ will try to clean up some kinds of leaks when you leave the page,
but IE6 makes no such attempt).

This implicates the ClippedImageImplIE6 code, which has been a nasty thorn
in our side for some time. I've tried without success to replicate the leak
in a simple Javascript snippet, but that likely means I just haven't stepped
on whatever particular set of problems is causing it.

@Adrien: Would you mind entering an issue for this so we can track it? I'm
likely to use this as another opportunity to push for removing that
god-awful code (see issues 1765, 3236, 3573, and 3588).

Thanks,
joel.

On Fri, Mar 19, 2010 at 10:50 AM, AdrienA  wrote:

> Hello,
>
> I find out a problem with the using of ClientBundle wich produce
> memory leaks in IE6.
>
> To proove that, I have realised a very simple application (you can
> find the source code at this address :
>
> http://google-web-toolkit-contributors.googlegroups.com/web/SampleCode-memoryLeakFromClientBundleOnIE6.zip
> )
>
> In this application, there is just one popup which contains 1000 times
> the same image creating by a ClientBundle.
>
> I open and close several times this popup and I observe the memory
> leaks in IE6 (with the soft "Process Explorer" for example).
>
> The result is alarming :
> http://www.googleonlinestorage.com/pictures/3077dd392df167271d24f526e41b637e.gif
>
>
> Is the problem already known? Maybe there is something to do ?
>
>
> Thank you,
> Adrien AUBRY
>
>
> --
> http://groups.google.com/group/Google-Web-Toolkit-Contributors
>
> To unsubscribe from this group, send email to
> google-web-toolkit-contributors+unsubscribegooglegroups.com or reply to
> this email with the words "REMOVE ME" as the subject.
>

-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors

To unsubscribe from this group, send email to 
google-web-toolkit-contributors+unsubscribegooglegroups.com or reply to this 
email with the words "REMOVE ME" as the subject.

Re: [gwt-contrib] Multiple inheritance in Widget hierarchy

[Joel Webber]

John,

The background behind that weird type hierarchy is that it stems from a time
before overlay types existed. Originally c.g.g.user.client.Element was a
simple opaque handle that had to be passed to the DOM.*() methods to get
anything done (same for Event). After the compiler got overlay type support
we added c.g.g.dom.client.Element as a superclass to user.Element, and
refactored all the DOM.*() methods to use the new dom.* node/element
hierarchy.

Unfortunately we couldn't banish user.Element altogether without breaking
everyone, so we ended up with a number of warts like
setElement(user.Element). It's been on our TODO list for some time to
deprecate user.Element and remove all references to it, but no one's found
the time yet. As you've probably discovered, we just end up using JSO.cast()
to work around this where necessary, but of course that won't work in "real"
Java.

If I understand what you're doing correctly, it sounds like clearing this up
would simplify your life. But it might take a while, because we have to go
through a fair amount of work to get there.

@kathrin & amit: How did you guys deal with this in the HtmlUnit testing
stuff? Sounds like it would have come up there.

Cheers,
joel.

On Thu, Mar 18, 2010 at 12:45 AM, jd  wrote:

> Hi,
>
> I am reposting this question here as the user list got no reply and I
> guess it is more a dev question:
>
> I am experimenting with compiling GWT code with a standard JDK so I
> can use the same code to generate HTML on both the client and the
> server.  So far it seem to be working OK but will only be practical if
> I can also get UIBinder and i18n working.
>
> My goal is to create HTML pages that can be crawled and indexed and
> also allow GWT code to add, load and modify the page.  Others have
> recommended building two parallel sites - an html one and a GT one
> which seems a bit redundant.
>
> My experiement has put a real w3c Node inside every GWT Node and
> replace native methods with ones that manipulate the w3c node.  Then
> finally I take the full w3c node from any element and convert it into
> html.
>
> I found that the object hierarchy needed to be changed to be valid
> Java.  An example of the issue is with the Anchor widget:
>
>  public Anchor() {
>setElement(Document.get().createAnchorElement());
>setStyleName("gwt-Anchor");
>  }
>
> com.google.gwt.dom.client.AnchorElement extends
> com.google.gwt.dom.client.AnchorElement but setElement expects a
> com.google.gwt.user.client.Element so AnchorElement must extend both
> classes which is impossible.
>
>
> I have modified AnchorElement and friends to extends
> com.google.gwt.user.client.Element instead which seems to have
> worked.
>
>
> My question is:  Is this impossible inheritance hierarchy intentional
> to stop this kind of messing about?
>
> Cheers,
>
> John
>
> --
> http://groups.google.com/group/Google-Web-Toolkit-Contributors
>

-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors

Re: [gwt-contrib] GWT's JsonpRequest conflicts browser caching

[Joel Webber]

That's definitely a valid point, and I understand how it would defeat
caching. However, I believe using a hash for the callback name would make it
impossible to properly deal with two requests to the same URL, because there
would be no way to distinguish which AsyncCallback should get which
response. This could lead to very difficult-to-debug errors.

It's not immediately obvious to me that there's a way to deal with this
correctly in the general case (though ideas are of course welcome). It might
be worth considering to allow the user to name the callback explicitly, but
it would have to come with dire warnings about making multiple overlapping
requests with the same callback name. Thoughts?

On Fri, Mar 12, 2010 at 3:48 PM, Frank  wrote:

> I had a look at JsonpRequest and JsonpRequestBuilder provided by GWT
> 2.0 for cross domain HTTP requests. Very nice, worked right away.
>
> However, there is one serious flaw...
>
> Like many other JSONP implementations, GWT's JsonRequest generates a
> unique callback name for each single jsonp request containing a serial
> number (e.g., __gwt_jsonp__.I1.onSuccess, __gwt_jsonp__.I2.onSuccess,
> and so on). This callback name is appended to the URI of the GET
> request, e.g.,
> http://service.whatsoever.com/book/12345678?callback=__gwt_jsonp__.I37.onSuccess
> .
>
> A response header such as "Cache-Control: public, max-age=..." telling
> the browser to cache the resource, will not have any effect because
> the URI was skewed. Getting one and the same resource (e.g., /book/
> 12345678) with many different URIs makes browser caching through Cache-
> Control impossible.
>
> My proposal for GWT's JsonRequest is to provide an alternative
> strategy for generating callback names. If you use a hash value of the
> URI rather than a serial number, browser caching through Cache-Control
> would work.
>
> --
> http://groups.google.com/group/Google-Web-Toolkit-Contributors
>

-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors

Re: [gwt-contrib] Re: Avira and HTML/CryptedGen (again)

[Joel Webber]

This is Avira, isn't it? Ddi you ever hear anything back from them about
this? It seems like it really ought to be fixed on their end, though I
applaud your spelunking for a workaround :)

On Tue, Mar 16, 2010 at 3:08 PM, Matt Mastracci wrote:

> On Mar 16, 12:42 pm, Matt Mastracci  wrote:
>
> > > Holy cow -- how do they think that is an acceptable measure?  Surely
> they could at least change the warning to say "potentially dangerous JS" or
> something rather than declaring it a virus.
>
> > This probably will likely affect a significant number GWT applications
> that use RPC. Avira seems to check files ending in .js* and .html* for this
> pattern.  I verified that the scanner intercepts these patterns in HTTP
> traffic and detects them in IE cache files.  There might be some negative
> patterns as well: Avira doesn't block my message in the Google Groups web
> interface, but it does block it when viewing the raw message source.
>
> Even better: it turns out that if you put the string "google" anywhere
> in the file matching CryptedGen, it no longer matches the heuristic. I
> imagine that it would pick up the string from the class metadata for
> those not using -XdisableClassMetadata.
>
> So this is a virus:
>
> "for eval .fromcharcode .charcodeat math.min 0,0,0,0,0,0"
>
> And this is not:
>
> "google for eval .fromcharcode .charcodeat math.min 0,0,0,0,0,0"
>
> The easiest solution for us seems to be putting the string "Google Web
> Toolkit" in a comment in our header.
>
> Matt.
>
> --
> http://groups.google.com/group/Google-Web-Toolkit-Contributors
>

-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors

Re: [gwt-contrib] Support runAsync with the cross-site linker.

[Joel Webber]

That's great news, and will really help with efforts to make our linkers
more sane. Out of curiosity, what's the strategy for loading fragments into
the enclosing namespace (and yes, that's the sound of me being too lazy to
dig into the patch)?

On Mon, Mar 15, 2010 at 6:17 PM,  wrote:

> Reviewers: cromwellian,
>
> Description:
> Support runAsync with the cross-site linker.
>
>
> Please review this at http://gwt-code-reviews.appspot.com/213801
>
> Affected files:
>  M
> dev/core/src/com/google/gwt/core/ext/linker/impl/SelectionScriptLinker.java
>  M dev/core/src/com/google/gwt/core/linker/IFrameLinker.java
>  M dev/core/src/com/google/gwt/core/linker/XSLinker.java
>  M dev/core/src/com/google/gwt/core/linker/XSTemplate.js
>  M dev/core/src/com/google/gwt/dev/jjs/JavaToJavaScriptCompiler.java
>  M dev/core/src/com/google/gwt/dev/jjs/impl/FragmentLoaderCreator.java
>  A
> dev/core/src/com/google/gwt/dev/jjs/impl/HandleCrossIslandReferences.java
>  M dev/core/src/com/google/gwt/dev/jjs/impl/JsFunctionClusterer.java
>  M dev/core/src/com/google/gwt/dev/js/JsToStringGenerationVisitor.java
>  A dev/core/test/com/google/gwt/dev/js/JavaScriptStringTest.java
>  M user/src/com/google/gwt/core/CompilerParameters.gwt.xml
>  M user/src/com/google/gwt/core/Core.gwt.xml
>  A user/src/com/google/gwt/core/XSLinker.gwt.xml
>  user/src/com/google/gwt/core/client/impl/AsyncFragmentLoader.java
>  A user/src/com/google/gwt/core/client/impl/CrossSiteLoadingStrategy.java
>  M user/src/com/google/gwt/core/client/impl/XhrLoadingStrategy.java
>  M user/test/com/google/gwt/core/client/impl/AsyncFragmentLoaderTest.java
>  M user/test/com/google/gwt/core/client/impl/XhrLoadingStrategyTest.java
>  A user/test/com/google/gwt/dev/jjs/CompilerSuiteCrossSite.gwt.xml
>  A user/test/com/google/gwt/dev/jjs/CrossSiteRunAsyncFailure.gwt.xml
>  A user/test/com/google/gwt/dev/jjs/CrossSiteRunAsyncMetrics.gwt.xml
>  A user/test/com/google/gwt/dev/jjs/CrossSiteRunAsyncSuite.java
>  M user/test/com/google/gwt/dev/jjs/RunAsyncFailure.gwt.xml
>  M user/test/com/google/gwt/dev/jjs/RunAsyncMetricsIntegrationTest.gwt.xml
>  user/test/com/google/gwt/dev/jjs/public/empty-gwt-stats.js
>  A user/test/com/google/gwt/dev/jjs/test/CrossSiteRunAsyncFailureTest.java
>  A user/test/com/google/gwt/dev/jjs/test/CrossSiteRunAsyncMetricsTest.java
>  A user/test/com/google/gwt/dev/jjs/test/CrossSiteRunAsyncTest.java
>  M user/test/com/google/gwt/dev/jjs/test/RunAsyncFailureTest.java
>  A
> user/test/com/google/gwt/user/client/runasync/CrossSiteLoadingStrategyForRunAsyncFailureTest.java
>  D
> user/test/com/google/gwt/user/server/runasync/RunAsyncFailureIFrameLinker.java
>
>
> --
> http://groups.google.com/group/Google-Web-Toolkit-Contributors
>

-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors

Re: [gwt-contrib] 3 PopupPanel related bugs

[Joel Webber]

Thanks, George. I'll put these on our schedule to look at as soon as we can.

On Fri, Mar 5, 2010 at 9:41 AM, ggeorg wrote:

> Hi,
>
> please have a look at:
>
>  - http://code.google.com/p/google-web-toolkit/issues/detail?id=4720&can=4
>  - http://code.google.com/p/google-web-toolkit/issues/detail?id=4664&can=4
>  - http://code.google.com/p/google-web-toolkit/issues/detail?id=4662&can=4
>
> the patch for the last one is not valid.
>
> Thanks,
> George.
>
> --
> http://groups.google.com/group/Google-Web-Toolkit-Contributors
>

-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors

Re: [gwt-contrib] Updates the IFRame and XS selection script templates to support

[Joel Webber]

@Ian: I know, it's nasty. These things have gotten a bit out of hand, and we
have a big, fat TODO to come back and clean this up (as well as to bring
together various other linkers under a more coherent umbrella). But we
probably won't be able to get around to it for at least another quarter,
unfortunately.

On Mon, Mar 8, 2010 at 12:37 PM, Ian Petersen  wrote:

> Just idle curiosity here, but why did you have to make the same change
> twice?  I know you're modifying selection scripts, and maybe that
> means you need to violate DRY for some reason, but it strikes me as a
> potential refactoring.
>
> Ian
>
> On Mon, Mar 8, 2010 at 9:23 AM,   wrote:
> > Reviewers: jgw,
> >
> > Description:
> > Updates the IFRame and XS selection script templates to support
> > inlined selection scripts.  There are two changes involved:
> >
> > 1. There is a baseUrl meta property that can be used to override
> > the choice of base URL.
> >
> > 2. Meta tags can be made to apply to only module MODULENAME by putting
> > "MODULENAME::" at the beginning of the "name" attribute of the meta tag.
> >
> > Review by: j...@google.com
> >
> > Please review this at http://gwt-code-reviews.appspot.com/159810
> >
> > Affected files:
> >  M dev/core/src/com/google/gwt/core/linker/IFrameTemplate.js
> >  M dev/core/src/com/google/gwt/core/linker/XSTemplate.js
> >
> >
> > Index: dev/core/src/com/google/gwt/core/linker/IFrameTemplate.js
> > ===
> > --- dev/core/src/com/google/gwt/core/linker/IFrameTemplate.js   (revision
> > 7685)
> > +++ dev/core/src/com/google/gwt/core/linker/IFrameTemplate.js   (working
> > copy)
> > @@ -120,6 +120,10 @@
> > ,markerId = "__gwt_marker___MODULE_NAME__"
> > ,markerScript;
> >
> > +if (base = metaProps['baseUrl']) {
> > +  return;
> > +}
> > +
> > $doc.write('');
> > markerScript = $doc.getElementById(markerId);
> >
> > @@ -189,6 +193,12 @@
> >   var meta = metas[i], name = meta.getAttribute('name'), content;
> >
> >   if (name) {
> > +name = name.replace('__MODULE_NAME__::', '');
> > +if (name.indexOf('::') >= 0) {
> > +  // It's for a different module
> > +  continue;
> > +   }
> > +
> > if (name == 'gwt:property') {
> >   content = meta.getAttribute('content');
> >   if (content) {
> > @@ -347,6 +357,7 @@
> >   // --- STRAIGHT-LINE CODE ---
> >
> >   // do it early for compile/browse rebasing
> > +  processMetas();
> >   computeScriptBase();
> >
> >   var strongName;
> > @@ -361,7 +372,6 @@
> > strongName = "";
> >   }
> >
> > -  processMetas();
> >
> >   // --- WINDOW ONLOAD HOOK ---
> >
> > Index: dev/core/src/com/google/gwt/core/linker/XSTemplate.js
> > ===
> > --- dev/core/src/com/google/gwt/core/linker/XSTemplate.js   (revision
> > 7685)
> > +++ dev/core/src/com/google/gwt/core/linker/XSTemplate.js   (working
> > copy)
> > @@ -104,6 +104,10 @@
> > ,markerId = "__gwt_marker___MODULE_NAME__"
> > ,markerScript;
> >
> > +if (base = metaProps['baseUrl']) {
> > +  return;
> > +}
> > +
> > $doc.write('');
> > markerScript = $doc.getElementById(markerId);
> >
> > @@ -173,7 +177,13 @@
> >   var meta = metas[i], name = meta.getAttribute('name'), content;
> >
> >   if (name) {
> > -if (name == 'gwt:property') {
> > +name = name.replace('__MODULE_NAME__::', '');
> > +if (name.indexOf('::') >= 0) {
> > +  // It's for a different module
> > +  continue;
> > +}
> > +
> > +   if (name == 'gwt:property') {
> >   content = meta.getAttribute('content');
> >   if (content) {
> > var value, eq = content.indexOf('=');
> > @@ -287,8 +297,8 @@
> >   }
> >
> >   // do it early for compile/browse rebasing
> > +  processMetas();
> >   computeScriptBase();
> > -  processMetas();
> >
> >   // --- WINDOW ONLOAD HOOK ---
> >
> >
> >
> > --
> > http://groups.google.com/group/Google-Web-Toolkit-Contributors
>
> --
> http://groups.google.com/group/Google-Web-Toolkit-Contributors
>

-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors

Re: [gwt-contrib] UIObject methods return type improvement.

[Joel Webber]

We could argue the merits of method chaining (I'll let the compiler guys
speak to whether or not this is better, worse, or indifferent for code
generation) -- but the bigger problem is that we'd have to change the style
of code throughout the system to make it useful, but any attempt to do so
would break existing subclasses that override these methods.

On Tue, Mar 2, 2010 at 7:19 PM, Qcho  wrote:

> Hi, I am currently working on a project using GWT.
>
> Maybe is a good suggestion to change the return value of functions
> such as addStyleDependentName or addStyleName from void to the UI
> modified itself, so you can do things like this:
>
> DockLayoutPanel appPanel = new DockLayoutPanel(Unit.EM);
>appPanel.addNorth(new HTML("hh1").addStyleName("header"),
> 4);
>appPanel.addNorth(new HTML("hh2").addStyleName("subHeader"),
> 10);
>appPanel.addSouth(new HTML("foot").addStyleName("footer"),
> 4);
>appPanel.addWest(new HTML("nav").addStyleName("navigation"),
> 10);
>
> this code wont compile since the chaining of addStyleName returns void
> and not the Widget element.
>
> Simple example provided.
>
> --
> http://groups.google.com/group/Google-Web-Toolkit-Contributors
>

-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors

Re: [gwt-contrib] Re: JSON.parse vs. eval

[Joel Webber]

What Thomas said. But yes, if we could make a good safe-eval JSON parser
available, that would be great. The old "json" library is both unsafe
(because it uses eval()) and ugly (because it was written long before
overlay types).

On Sat, Feb 20, 2010 at 10:22 AM, Thomas Broyer  wrote:

>
> On Feb 16, 2:32 pm, mozSte  wrote:
> > Hi all,
> >
> > I'm a newbie, so excuse me if this was posted/solved already.
> >
> > I have a quick suggestion on the implementation of a safeEval (or
> > safer, anyway) parsing to the JSONUtils class.
> >
> > public static native  T
> > safeEval(String json) /*-{
> > if(JSON)
> > {
> > return JSON.parse(json);
> > }
> > else
> > {
> > return eval('('+json+')');
> > }
> > }-*/;
> >
> > object JSON is present as native JSON parser in all modern browsers,
> > so with this code you'll likely get more secure and also faster code.
> >
> > Do you see any drawback in using this code?
>
> It evals the "if" each time you call safeEval; and the fallback to
> eval isn't "safe" at all (I'd at least add a check using the regexp
> from RFC 4627).
>
> > Is it already present in
> > some other GWT module?
>
> I wrote a JSON module at work (we might open source it someday) that
> uses deferred binding to use native parsing when we're sure it is
> available (IE8), eval() when we're sure it isn't (IE6 and Opera) and
> runtime detection otherwise (Firefox and Safari/Chrome), when the
> check is done once only!
> I proposed a patch to GWT but unfortunately it has some problems so I
> (temporarily) withdrawn it: http://gwt-code-reviews.appspot.com/86803/show
>
> --
> http://groups.google.com/group/Google-Web-Toolkit-Contributors
>

-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors

Re: [gwt-contrib] Size improvements with latest trunk

[Joel Webber]

That's great news. I'm particularly happy given that (IIRC) Ray confirmed
that these have no negative impact on parse time (please tell me I'm
remembering this correctly!).

On Tue, Feb 16, 2010 at 8:21 PM, Ray Cromwell  wrote:

> Awesome, thanks a lot for the data and debugging. I guess that brings
> the gain since 1.7 to 28% now. :)
>
> -Ray
>
>
> On Tue, Feb 16, 2010 at 5:16 PM, Matt Mastracci 
> wrote:
> > I ran a few different compiles with our codebase to test some of the
> improvements in trunk for Ray. I've only measured the post-gzip/zip size
> improvements below - the numbers for the website sizes are an average of the
> size for gzip -9 over all of the browser permutations:
> >
> > GWT 2.0.0:
> >
> > dotspots.com (initial fragment, gzipped): 73299
> > dotspots.com/popup (initial fragment, gzipped): 89715
> > Publisher script (initial fragment, gzipped): 54424
> > Chrome extension (final zipped size): 83790
> > Firefox extension (final zipped size): 103257
> >
> > GWT trunk (as of r7589):
> >
> > dotspots.com (initial fragment, gzipped): 73983
> > dotspots.com/popup (initial fragment, gzipped): 89260
> > publisher script (initial fragment, gzipped): 55307
> > Chrome extension (final zipped size): 84771
> > Firefox extension (final zipped size): 103707
> >
> > GWT trunk (as of r7589), with compiler.stackMode = strip:
> >
> > dotspots.com (initial fragment, gzipped): 69185
> > dotspots.com/popup (initial fragment, gzipped): 83768
> > publisher script (initial fragment, gzipped): 52040
> > Chrome extension (final zipped size): 80980
> > Firefox extension (final zipped size): 0
> >
> > GWT trunk (as of r7589), with compiler.stackMode = strip + Compact
> Integer Seed Functions patch:
> >
> > dotspots.com (initial fragment, gzipped): 67937
> > dotspots.com/popup (initial fragment, gzipped): 82242
> > publisher script (initial fragment, gzipped): 51089
> > Chrome extension (final zipped size): 80058
> > Firefox extension (final zipped size): 98661
> >
> > Overall improvements (from 2.0.0 to trunk+stack strip+patch):
> >
> > dotspots.com (initial fragment, gzipped): 7.3%
> > dotspots.com/popup (initial fragment, gzipped): 8.3%
> > publisher script (initial fragment, gzipped): 6.1%
> > (xpi/crx omitted, since there's a large constant factor)
> >
> > In other words: WOOHOO!
> >
> > Matt.
> >
> > --
> > http://groups.google.com/group/Google-Web-Toolkit-Contributors
>
> --
> http://groups.google.com/group/Google-Web-Toolkit-Contributors
>

-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors

Re: [gwt-contrib] Feature Request: VisibilityEvent

[Joel Webber]

Wow, I had completely forgotten about onpropertychange() -- like onresize(),
there's some interesting and useful stuff floating around in IE, even if it
is nonstandard.

If you can get something like this wired up across browsers, that would be
really useful. I would be particularly interested in seeing how this might
be generalized -- if, e.g., we could get a standard interface to something
like onpropertychange() (note how it explicitly *includes* style changes in
the MSDN doc), we could use it for a lot of things.

On Mon, Feb 15, 2010 at 1:30 PM, Jarrod Carlson wrote:

> Yes, there are some serious hurdles to being able to support this kind of
> feature. I haven't tried it yet, but I suggested the feature because I
> understand both Mozilla and WebKit support a DOMAttrModified sort of native
> event:
>
>
> http://www.w3.org/TR/DOM-Level-2-Events/events.html#Events-eventgroupings-mutationevents
>
> I also understand IE has some limited support for a proprietary alternative
> (onpropertychange).
>
> It sounds like it might be possible to get some sort of support working,
> although I have no doubt that some additional voodoo would be required to
> level the support across browsers.
>
> On Mon, Feb 15, 2010 at 10:46 AM, Joel Webber  wrote:
>
>> I'm not sure if it's possible to do this correctly in the general case.
>> You can currently override setVisible(), but that only works if it's called
>> explicitly. Most importantly, there's no way I know of to get the DOM to
>> tell you when an element becomes visible/hidden; to synthesize this would
>> require that all changes to visibility of a parent walk the entire child
>> hierarchy to inform all of its children of the change. Even worse, it can
>> happen for random reasons like a change to the Style object or CSS class
>> name.
>>
>> If we can find a way to get the DOM to inform us of this kind of change,
>> I'm all for it though.
>>
>> On Sat, Feb 13, 2010 at 11:30 PM, jarrod wrote:
>>
>>> One feature I would like to see added to GWT is a DOM or logical event
>>> to notify handlers of a Widget's visibility changes.
>>>
>>> In the spirit of keeping things loosely coupled, say for instance I
>>> have a TabLayoutPanel which contains several Widgets. Those Widgets do
>>> not necessarily know that they are contained within a TabLayoutPanel
>>> that might show or hide them at will.
>>>
>>> Thus it would be quite helpful if a Widget could (especially through
>>> UiBinder) be notified when it becomes "visible" to the user.
>>>
>>> Any thoughts?
>>>
>>> --
>>> http://groups.google.com/group/Google-Web-Toolkit-Contributors
>>>
>>
>>  --
>> http://groups.google.com/group/Google-Web-Toolkit-Contributors
>>
>
>
>
> --
> ~jj
>
> --
> http://groups.google.com/group/Google-Web-Toolkit-Contributors
>

-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors

Re: [gwt-contrib] Feature Request: VisibilityEvent

[Joel Webber]

I'm not sure if it's possible to do this correctly in the general case. You
can currently override setVisible(), but that only works if it's called
explicitly. Most importantly, there's no way I know of to get the DOM to
tell you when an element becomes visible/hidden; to synthesize this would
require that all changes to visibility of a parent walk the entire child
hierarchy to inform all of its children of the change. Even worse, it can
happen for random reasons like a change to the Style object or CSS class
name.

If we can find a way to get the DOM to inform us of this kind of change, I'm
all for it though.

On Sat, Feb 13, 2010 at 11:30 PM, jarrod  wrote:

> One feature I would like to see added to GWT is a DOM or logical event
> to notify handlers of a Widget's visibility changes.
>
> In the spirit of keeping things loosely coupled, say for instance I
> have a TabLayoutPanel which contains several Widgets. Those Widgets do
> not necessarily know that they are contained within a TabLayoutPanel
> that might show or hide them at will.
>
> Thus it would be quite helpful if a Widget could (especially through
> UiBinder) be notified when it becomes "visible" to the user.
>
> Any thoughts?
>
> --
> http://groups.google.com/group/Google-Web-Toolkit-Contributors
>

-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors

Re: [gwt-contrib] GWT 2.0.2 still broken when there is no history.

[Joel Webber]

[+jlabanca: can you take a look at this?]

On Mon, Feb 15, 2010 at 9:06 AM, stuckagain  wrote:

> People,
>
> Somehow testings needs to be a bit enhanced. GWT 2.0.2 which is
> supposed to fix issue 4585 does not seem to work correctly. Although
> the original stack is no longer produced when showing the popup, I now
> get the stack when closing down the PopupPanel.
>
> Can this bug be re-opened ?
> http://code.google.com/p/google-web-toolkit/issues/detail?id=4584
>
>
> 2010/02/15 14:59:20 SEVERE Unknown:Uncaught Exception
> java.lang.NullPointerException
>at
> com.google.gwt.user.client.ui.PopupPanel.setState(PopupPanel.java:
> 1397)
>at
> com.google.gwt.user.client.ui.PopupPanel.onUnload(PopupPanel.java:
> 1025)
>at com.google.gwt.user.client.ui.Widget.onDetach(Widget.java:329)
>at com.google.gwt.user.client.ui.Widget.setParent(Widget.java:402)
>at com.google.gwt.user.client.ui.Panel.orphan(Panel.java:210)
>at
> com.google.gwt.user.client.ui.ComplexPanel.remove(ComplexPanel.java:
> 63)
>at
> com.google.gwt.user.client.ui.AbsolutePanel.remove(AbsolutePanel.java:
> 159)
>at com.google.gwt.user.client.ui.PopupPanel
> $ResizeAnimation.onInstantaneousRun(PopupPanel.java:314)
>at com.google.gwt.user.client.ui.PopupPanel
> $ResizeAnimation.setState(PopupPanel.java:208)
>at
> com.google.gwt.user.client.ui.PopupPanel.setState(PopupPanel.java:
> 1374)
>at
> com.google.gwt.user.client.ui.PopupPanel.hide(PopupPanel.java:585)
>at
> com.google.gwt.user.client.ui.PopupPanel.hide(PopupPanel.java:571)
>
> --
> http://groups.google.com/group/Google-Web-Toolkit-Contributors
>

-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors

Re: [gwt-contrib] Patch for RichTextEditor

[Joel Webber]

Sebastian,

Sorry it's taken so long for anyone to respond. This sounds like useful
functionality, and I would suggest creating an issue (
http://code.google.com/p/google-web-toolkit/issues/) and a patch for public
discussion (http://gwt-code-reviews.appspot.com/). That way it will be
easier for people to try out your patch and refine it.

Cheers,
joel.

On Fri, Jan 22, 2010 at 9:55 AM, Sebastian  wrote:

> Hello,
>
> I was missing the ability to format a block with  -  tags. I
> researched the topic and build a patch which allows to insert block
> tags. It makes use of the FormatBlock command.
>
> I would like to ask, if you are interested in the patch and discuss
> the coding decision I took.
>
> 1)
> I couldn't find any guidance on testing. I have tested with Safari 4,
> Firefox 3.5, IE 6, IE 8 and IE 8 in IE 7 mode.
>
> 2)
> Currently only the tags  to , ,  and  work
> stable across browsers. To limit the choice of tags, I have created an
> enum to limit the possible values.
>
> public static enum BlockTag {
>H1, H2, H3, H4, H5, H6, PRE, ADDRESS, P;
>  final String OPEN = "<";
>  final String CLOSE = ">";
>  public String toTag() {
>return OPEN+name()+CLOSE;
>  }
>}
>
> The advantage is that you cannot provide the wrong tags. The
> disadvantage is that you cannot provide tags which are for example
> supported in newer browser versions.
>
> The rest of the tag is just a new method in RichTextAreaImplStd.
>  public void formatBlock(RichTextArea.BlockTag blockTag) {
>execCommand("FormatBlock", blockTag.toTag());
>  }
>
> Shall I leave it that way or turn it into a String parameter?
>
> 3)
> Should I create a bug tracking entry for this?
>
> If somebody is interested, here are some links, I found interesting
> while exploring the topic.
>
> http://discerning.com/topics/software/ttw.html
> http://help.dottoro.com/ljcvtcaw.php
> http://www.quirksmode.org/dom/execCommand.html
>
> Best Regards
>
> Sebastian Hennebrueder
>
> --
> http://groups.google.com/group/Google-Web-Toolkit-Contributors
>

-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors

Re: [gwt-contrib] StackPanelLayout and applying additional style when hovering header.

[Joel Webber]

Thanks, Marko. I'll take a look at it today.

On Tue, Feb 9, 2010 at 4:07 AM, Marko Vuksanovic
wrote:

> I thought it would be nice if it was possible to have hovering effect
> on StackPanelLayout header so I created an issue for that (issue nuber
> is 4561, or direct link
>
> http://code.google.com/p/google-web-toolkit/issues/detail?can=2&q=4561&colspec=ID%20Type%20Status%20Priority%20Milestone%20Owner%20Summary&id=4561
> )
> and submitted a patch. It would be nice if somebody from the gwt team
> had a look at this...
>
>
> /Marko
>
> --
> http://groups.google.com/group/Google-Web-Toolkit-Contributors
>

-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors

[gwt-contrib] Re: html5 + gwt ... or gears?

[Joel Webber]

Karl-Heinz,

We are planning on adding built-in support for the HTML5 AppCache, but have
not done so yet. I believe there are some projects already in existence
working to do this, such as "gwt-mobile-webkit" (
http://code.google.com/p/gwt-mobile-webkit/). I haven't used this project
personally, but it looks like they're working on AppCache support at
present.

Cheers,
joel.

On Fri, Feb 5, 2010 at 4:08 AM, Karl-Heinz Troyer  wrote:

>  *hi gwt dev team!
> *
> it seems gears does not come forward.
> are there any plans to do the same with html5? and when?
> how can i provide an offline app with html5 and gwt?
> gears is even not supported on chrome for mac.
> our app has to run on some platforms where i can request html5
> compatibility, but not gears
> thanks in advance,
>
>  --
> regards / mit freundlichen grüssen
>
>[image: chance123] 
>   *ing. karl-heinz troyer*  troyer information
> systems gmbh
> alte hohenzeller strasse 2 / a-4910 ried im innkreis / austria
> skype  / tel +43 676 9330080 / 
> info
>   a
> worldwide success story http://info.chance123.net
>
>
>

-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors<>

[gwt-contrib] Re: GWT 2.0.1: is the history support iframe now mandatory ?

[Joel Webber]

I just clarified the issue a bit and assigned it. Thanks for catching
this.

On Feb 5, 6:00 am, "Konstantin.Scheglov"
 wrote:
>   I've added this issue yesterday, found during running tests for GWT
> Designer.
>
> http://code.google.com/p/google-web-toolkit/issues/detail?id=4584
>
> On Feb 4, 6:36 pm, Joel Webber  wrote:
>
>
>
> > It shouldn't be -- if you kick off History's static initializer, it will
> > GWT.create(HistoryImpl.class), and thus attempt to find the iframe, but I
> > believe it's been this way for a long time. Are you sure you're not
> > referencing History somewhere?
>
> > On Thu, Feb 4, 2010 at 10:34 AM, stuckagain  wrote:
> > > Hi,
>
> > > I rebuild my apps with 2.0.1 and noticed that they no longer start.
> > > In DevMode is see an error about the History Support that fails to
> > > initialize.
>
> > > My apps do not support history, so I did not include the IFrame... has
> > > this become mandatory or is this a little oops ?
>
> > > David
>
> > > --
> > >http://groups.google.com/group/Google-Web-Toolkit-Contributors

-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors

[gwt-contrib] Re: GWT 2.0.1: is the history support iframe now mandatory ?

[Joel Webber]

I just clarified the issue a bit and assigned it. Thanks for catching
this.

On Feb 5, 6:00 am, "Konstantin.Scheglov"
 wrote:
>   I've added this issue yesterday, found during running tests for GWT
> Designer.
>
> http://code.google.com/p/google-web-toolkit/issues/detail?id=4584
>
> On Feb 4, 6:36 pm, Joel Webber  wrote:
>
>
>
> > It shouldn't be -- if you kick off History's static initializer, it will
> > GWT.create(HistoryImpl.class), and thus attempt to find the iframe, but I
> > believe it's been this way for a long time. Are you sure you're not
> > referencing History somewhere?
>
> > On Thu, Feb 4, 2010 at 10:34 AM, stuckagain  wrote:
> > > Hi,
>
> > > I rebuild my apps with 2.0.1 and noticed that they no longer start.
> > > In DevMode is see an error about the History Support that fails to
> > > initialize.
>
> > > My apps do not support history, so I did not include the IFrame... has
> > > this become mandatory or is this a little oops ?
>
> > > David
>
> > > --
> > >http://groups.google.com/group/Google-Web-Toolkit-Contributors

-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors

Re: [gwt-contrib] GWT 2.0.1: is the history support iframe now mandatory ?

[Joel Webber]

It shouldn't be -- if you kick off History's static initializer, it will
GWT.create(HistoryImpl.class), and thus attempt to find the iframe, but I
believe it's been this way for a long time. Are you sure you're not
referencing History somewhere?

On Thu, Feb 4, 2010 at 10:34 AM, stuckagain  wrote:

> Hi,
>
> I rebuild my apps with 2.0.1 and noticed that they no longer start.
> In DevMode is see an error about the History Support that fails to
> initialize.
>
> My apps do not support history, so I did not include the IFrame... has
> this become mandatory or is this a little oops ?
>
> David
>
> --
> http://groups.google.com/group/Google-Web-Toolkit-Contributors
>

-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors

Re: [gwt-contrib] Re: GWT Incubator Status Update and Schedule

[Joel Webber]

[+fred, just to make sure he sees this]

On Mon, Feb 1, 2010 at 11:26 AM, dflorey  wrote:

> See:
>
>
> http://groups.google.com/group/google-web-toolkit-contributors/browse_thread/thread/4f5fb0cbd007fa25/e6a70c6a26a444cd?lnk=gst&q=compatibility+animations#e6a70c6a26a444cd
>
> On 1 Feb., 17:23, dflorey  wrote:
> > What about Fred Sauer's gwt voices project?
> > AFAK it has an elegant approach how to provide flash based fallback if
> > certain capabilities are not supported by the browser itself.
> >
> > On 1 Feb., 14:25, Joel Webber  wrote:
> >
> >
> >
> > > To be clear, we do recognize the importance of starting to support
> HTML5
> > > constructs that don't work on all browsers, though we need to find a
> clear
> > > way to indicate to developers that a particular library or widget won't
> work
> > > in some cases. None of us have ever worked through all the nuances of
> how
> > > this should be done yet, and probably won't have time to do so until at
> > > least Q2. That said, if you want to start the discussion, I'm all ears!
> >
> > > On Thu, Jan 28, 2010 at 10:44 AM, Ray Ryan  wrote:
> > > > As you'll see in the first note in this thread, Incubator is closing
> down.
> >
> > > > Having your work in its own project is exactly the right thing to do.
> If it
> > > > becomes an appropriate addition for GWT proper, we'll eagerly help
> you
> > > > integrate it. In the meantime, the community can use it and shape it
> without
> > > > waiting for the GWT team to get in the mix.
> >
> > > > rjrjr
> >
> > > > On Thu, Jan 28, 2010 at 4:56 AM, Mark Renouf  >wrote:
> >
> > > >> I've developed "gwt-html5-media", which implements all the common
> > > >> functionality described in the "Media Element" section of the HTML5
> > > >> spec, including the specific functionality for Video and Audio tags,
> > > >> including all of the events and settings. I could use some help
> > > >> testing and improving it and perhaps some advice on how to better
> > > >> handle usage of the large number of new native events available
> > > >> (currently side-steps the main GWT sinkEvents code instead using
> it's
> > > >> own, since it exhausts the available number of free bitfield
> > > >> definitions there).
> >
> > > >>http://code.google.com/p/gwt-html5-media/
> >
> > > >> Would something like this be welcome in incubator or simply as a
> side
> > > >> project for eventual inclusion into GWT? I'd like to see the HTML5
> > > >> support rounded out so this plus the Canvas support would me a major
> > > >> step forward. I know there is also another pure-canvas
> implementation
> > > >> for GWT within the SpeedTracer project. I'm not sure if VML fallback
> > > >> is worth the complexity if the only browser supporting it does not
> > > >> support any other HTML5 features anyhow... but that's a point for
> > > >> debate elsewhere I suppose ;-)
> >
> > > >> On Jan 12, 1:04 pm, John LaBanca  wrote:
> > > >> > Incubator Users -
> >
> > > >> > The Google Web Toolkit Incubator project began as a proving
> grounds for
> > > >> new
> > > >> > widgets to be vetted before joining the ranks of the GWT trunk.
> We've
> > > >> seen
> > > >> > some success stories over the last year with EventHandlers,
> > > >> ClientBundle,
> > > >> > and DatePicker, but for many of the widgets and libraries,
> Incubator has
> > > >> > become an elephant graveyard.
> >
> > > >> > In order to address this issue, we will start graduating some of
> the
> > > >> > libraries to GWT trunk, move some into separate projects, and
> > > >> discontinue
> > > >> > development on others. Ultimately, we will wind down the incubator
> > > >> project
> > > >> > completely.
> >
> > > >> > The schedule below shows the fate of each subproject in incubator.
> It's
> > > >> a
> > > >> > tentative schedule, meaning that it could change as priorities
> shift.
> >
> > > >> > GWT 2.1
> >
> > > >> >- *PagingScrollTable and FastTree*

Re: [gwt-contrib] Re: GWT Incubator Status Update and Schedule

[Joel Webber]

To be clear, we do recognize the importance of starting to support HTML5
constructs that don't work on all browsers, though we need to find a clear
way to indicate to developers that a particular library or widget won't work
in some cases. None of us have ever worked through all the nuances of how
this should be done yet, and probably won't have time to do so until at
least Q2. That said, if you want to start the discussion, I'm all ears!

On Thu, Jan 28, 2010 at 10:44 AM, Ray Ryan  wrote:

> As you'll see in the first note in this thread, Incubator is closing down.
>
> Having your work in its own project is exactly the right thing to do. If it
> becomes an appropriate addition for GWT proper, we'll eagerly help you
> integrate it. In the meantime, the community can use it and shape it without
> waiting for the GWT team to get in the mix.
>
> rjrjr
>
> On Thu, Jan 28, 2010 at 4:56 AM, Mark Renouf wrote:
>
>> I've developed "gwt-html5-media", which implements all the common
>> functionality described in the "Media Element" section of the HTML5
>> spec, including the specific functionality for Video and Audio tags,
>> including all of the events and settings. I could use some help
>> testing and improving it and perhaps some advice on how to better
>> handle usage of the large number of new native events available
>> (currently side-steps the main GWT sinkEvents code instead using it's
>> own, since it exhausts the available number of free bitfield
>> definitions there).
>>
>> http://code.google.com/p/gwt-html5-media/
>>
>> Would something like this be welcome in incubator or simply as a side
>> project for eventual inclusion into GWT? I'd like to see the HTML5
>> support rounded out so this plus the Canvas support would me a major
>> step forward. I know there is also another pure-canvas implementation
>> for GWT within the SpeedTracer project. I'm not sure if VML fallback
>> is worth the complexity if the only browser supporting it does not
>> support any other HTML5 features anyhow... but that's a point for
>> debate elsewhere I suppose ;-)
>>
>>
>>
>> On Jan 12, 1:04 pm, John LaBanca  wrote:
>> > Incubator Users -
>> >
>> > The Google Web Toolkit Incubator project began as a proving grounds for
>> new
>> > widgets to be vetted before joining the ranks of the GWT trunk. We've
>> seen
>> > some success stories over the last year with EventHandlers,
>> ClientBundle,
>> > and DatePicker, but for many of the widgets and libraries, Incubator has
>> > become an elephant graveyard.
>> >
>> > In order to address this issue, we will start graduating some of the
>> > libraries to GWT trunk, move some into separate projects, and
>> discontinue
>> > development on others. Ultimately, we will wind down the incubator
>> project
>> > completely.
>> >
>> > The schedule below shows the fate of each subproject in incubator. It's
>> a
>> > tentative schedule, meaning that it could change as priorities shift.
>> >
>> > GWT 2.1
>> >
>> >- *PagingScrollTable and FastTree*
>> >We are working on a new set of data backed widgets for GWT 2.1 that
>> will
>> >include APIs for trees and tables. We will build upon the lessons
>> learned
>> >with these incubator widgets, but the API for the new data backed
>> widgets
>> >will evolve significantly from the current APIs. When the data backed
>> >widgets are added to GWT trunk, we will stop development on
>> >the PagingScrollTable and FastTree.
>> >
>> >- *Locale Selection*
>> >Selecting the locale on the server requires one less round trip to
>> the
>> >server on startup and is needed for effective use of
>> >runtime locales selection.  This library will be included in GWT 2.1.
>> >
>> > GWT 2.2
>> >
>> >- *CollapsiblePanel*
>> >This widget will probably become a subclass of DockingLayoutPanel,
>> >similar to SplitLayoutPanel.
>> >
>> >- *SliderBar and ProgressBar*
>> >Both of these widgets currently require the use of a global timer,
>> which
>> >has performance implications. If we can implement these without a
>> resize
>> >timer, we will include them in GWT 2.2. If we cannot, we will
>> discontinue
>> >development on them.
>> >
>> >- *Logging*
>> >The logging API may make it into GWT 2.1 if time permits.
>> >
>> >- *Form Validation*
>> >We will take a closer look at the form validation API in GWT 2.2..
>> >
>> > Separate Project:
>> >
>> >- *SoundResource*
>> >SoundResource is a promising API for including sound in an
>> application,
>> >but it makes sense to wait for HTML 5 features to become widely
>> adopted
>> >before including it. We would like to move SoundResource into the
>> gwt-voices
>> >project:http://code.google.com/p/gwt-voices/.
>> >
>> >- *Graphics*
>> >The graphics library provides a single, platform independent API that
>> >works on top of Canvas and VML. The library is not ready for GWT
>> trunk, but
>> >this project is worth pursuing.
>> >

Re: [gwt-contrib] Re: Changing JsArray to JsArray

[Joel Webber]

Correct me if I'm wrong, but isn't the closure collections library more like
JRE-ish collections than simple JSO wrappers? My impression of most JS code
was that if it needed a string map or simple array, people tended to just
use raw objects, knowing that there are certain strange behaviors they have
to avoid.

That said, if there's a way to make them "play nice" together, I'm all for
it.

On Tue, Jan 26, 2010 at 7:46 AM, Stefan Haustein wrote:

>
>> Collections are very, very amenable to bikeshedding, so I want to have a
>> pretty well thought-out plan so as to avoid endless "what if" threads, if at
>> all possible. Of course, if the design is bad, people will hopefully say so
>> and we'll do something different. But I just don't want to start with so
>> little that it doesn't have enough intertia to achieve escape velocity.
>>
>>
> Bruce,
>
> for collections in general, maybe we should also consider using / linking /
> emulating closure collections. With stuff like Bach on the horizon, we may
> otherwise end up with too many collection frameworks, creating a situation
> similar to strings in C++.
>
> For simple arrays, I think it may make sense to re-visit the original idea
> of extending the scope of JsArray to JsArray Object>.
>
> Stefan
>
> --
> http://groups.google.com/group/Google-Web-Toolkit-Contributors
>

-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors

[gwt-contrib] Re: SuggestBox loses focus when hovering over suggestions

[Joel Webber]

Sure thing. Looking now.

On Fri, Jan 22, 2010 at 11:17 AM, John LaBanca  wrote:

> ping - can you get to this today? It should go into GWT 2.0.1
>
> Thanks,
> John LaBanca
> jlaba...@google.com
>
>
>
> On Wed, Jan 20, 2010 at 2:32 PM,  wrote:
>
>> Reviewers: jgw,
>>
>> Description:
>> The SuggestBox loses focus when the mouse hovers over the list of
>> suggestions because MenuBar steals keyboard focus on hover.  This is
>> particularly annoying if a user leaves the cursor just beneath the text
>> box.  As soon as the suggestions are shown, the text box loses focus.
>>
>> In fact, there are other cases where this can be annoying, such as just
>> having a MenuBar and TextBox in the same app:
>> http://code.google.com/p/google-web-toolkit/issues/detail?id=3884
>>
>> Fix:
>> 
>> This patch adds an option to MenuBar to disable focus on hover, which
>> fixes the problem at the expense of losing keyboard focus. SuggestBox
>> now uses the new option.
>>
>> Testing:
>> ===
>> Manually verified that this works for MenuBar and SuggestBox.
>>
>>
>>
>> Please review this at http://gwt-code-reviews.appspot.com/132816
>>
>> Affected files:
>>  user/src/com/google/gwt/user/client/ui/MenuBar.java
>>  user/src/com/google/gwt/user/client/ui/SuggestBox.java
>>
>>
>>
>

-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors

[gwt-contrib] Re: gwt-phys2d: 2D physics engine for GWT

[Joel Webber]

[+gwt-contrib]

That's pretty impressive. Have you tried it on any larger scene graphs? I'd
love to see how it scales. It looks quite smooth on Chrome already.

On Fri, Jan 22, 2010 at 3:05 AM, Neil Halelamien  wrote:

> I quasi-ported the Phys2d Java physics library to run with GWT and gwt-
> g2d (for HTML5 canvas rendering). You can see the result (and download
> the library source) here:
>
>
> http://edgeofvision.com/2010/01/22/initial-release-of-gwt-phys2d-javascriptgwt-physics-engine/
> http://gwt-phys2d.appspot.com
>
> If anybody's interested in actually using this and/or contributing,
> I'd be happy to clean things up and create a Google Code project for
> it. It was pretty much just a self-education project though, so I
> probably won't be doing too much more with it myself. I imagine it
> might be handy for a GWT game programming project out there, though.
>
> -- Neil
>
> --
> You received this message because you are subscribed to the Google Groups
> "Google Web Toolkit" group.
> To post to this group, send email to google-web-tool...@googlegroups.com.
> To unsubscribe from this group, send email to
> google-web-toolkit+unsubscr...@googlegroups.com
> .
> For more options, visit this group at
> http://groups.google.com/group/google-web-toolkit?hl=en.
>
>

-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors

Re: [gwt-contrib] LayoutPanel & Button in Mozilla

[Joel Webber]

Agreed that this is a really irritating bug in Firefox. Have you tried
w/h:100% just on the button itself? This is required for  and
 on all browsers, though it's not baked into the Layout code by
default, because it mis-lays-out slightly (pushes borders and margin off the
edge).

On Wed, Jan 20, 2010 at 7:58 AM, ggeorg wrote:

> Hi,
>
> is there a workaround for :
>
>  public void onModuleLoad() {
>LayoutPanel panel = new LayoutPanel();
>
>panel.add(new Button("Hello!"));
>
>RootLayoutPanel.get().add(panel);
>  }
>
> left: 0px; right: 0px; together do not work in Firefox 3.5.6 (top:
> 0px; bottom: 0px; work).
>
> There is also the same problem with TextBox in both Firefox and IE8.
> With TextBox even vertical alignment does not work.
>
> What I found so far is
> http://www.quirksmode.org/css/tests/mozie_button.html,
> but -moz-box-sizing: content-box; does not help. Maybe there is
> something else. Button.setWidth("100%") works perfect, but it fails
> for  elements with margin and border.
>
> Thanks,
> George.
>
> --
> http://groups.google.com/group/Google-Web-Toolkit-Contributors
>
-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors

Re: [gwt-contrib] Re: More on TabLayoutPanel styles

[Joel Webber]

Good point as well, thanks. I've updated issue 4259 to capture this.

On Tue, Jan 19, 2010 at 2:08 PM, dflorey  wrote:

> One more issue:
> Using LazyPanel does not work in the new TabLayoutPanel. I guess the
> setVisible() method is no longer called on this widget (is it called
> on one of the parent panels?)
>
>
> On Jan 19, 5:07 pm, Joel Webber  wrote:
> > On Mon, Jan 18, 2010 at 6:17 AM, dflorey 
> wrote:
> > > Hi,
> > > I've been trying to usw the new TabLayoutPanel for different layouts.
> > > Here are my findings:
> >
> > > 1. The .gwt-TabLayoutPanelTabs style gets applied to the wrapper
> > > element with width set to >16000 px. This makes it impossible to
> > > create a border around the tab bar.
> > > As a workaround I had to apply a style to wrapper element like this:
> > > ((Element) tabPanel.getElement().getChild(1)).setClassName(".gwt-
> > > TabLayoutPanel-wrapper");
> > > This is very ugly and will fail as soon as the TabLayoutPanel impl
> > > changes.
> > > Please consider applying the ".gwt-TabLayoutPanelTabs" style to the
> > > appropriate wrapper element.
> >
> > This is a good point. I'll need to add another wrapper element around the
> > tabs to make this work, but I don't think that will cause any problems.
> > There *is* a wrapper created by the Layout class, but it's unsafe to
> apply
> > arbitrary styles to it (in particular, decorations such as border,
> margin,
> > and padding will confuse it -- it's actually there to work around
> > measurement problems with such decorations). I've added a comment to
> issue
> > 4429 (default TLP styles) to capture this.
> >
> > 2. The setStyle(Primary)Name methods will not change the substyles.
> >
> > > When using different TabLayoutPanels with different styles in the same
> > > application you'll have to overwrite each css property as you'll
> > > inherit all styles by default. It would be much better to change all
> > > substyles as it has been the case with the "old" gwt widgets
> >
> > Actually, I can't think of any cases off the top of my head where we've
> > automatically updated sub-styles like this. For example, the old
> StackPanel
> > only modifies the top-most class name. The problem is that there are
> cases
> > where we'd be forced to walk arbitrarily large numbers of children every
> > time the style name is changed. We decided it was best to avoid this, and
> > require the (admittedly somewhat uglier, and imperfect) use of descendent
> > selectors. The right long-term approach is probably closer to what you
> > suggest below.
> >
> > or - even better - to pass a ClientBundle defining all styles as an
> optional
> >
> > > argument to the cstr of the TabLayoutPanel.
> > > A default style factory could provide default styles if no
> > > ClientBundle is provided. Replacing the default style factory using
> > > deferred binding could make the default styles themable.
> > > I've used this approach in my own app and it works fine.
> >
> > Essentially, yes. Though it's a fairly complex design problem in the
> general
> > case to do so in a way that ensures there's no unnecessary overhead, and
> > supports all the common use cases. This is definitely a Q1 goal, and
> we'll
> > make a point to share design docs as soon as we have a rough idea of what
> it
> > should look like.
>
> --
> http://groups.google.com/group/Google-Web-Toolkit-Contributors
>
-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors

Re: [gwt-contrib] More on TabLayoutPanel styles

[Joel Webber]

On Mon, Jan 18, 2010 at 6:17 AM, dflorey  wrote:

> Hi,
> I've been trying to usw the new TabLayoutPanel for different layouts.
> Here are my findings:
>
> 1. The .gwt-TabLayoutPanelTabs style gets applied to the wrapper
> element with width set to >16000 px. This makes it impossible to
> create a border around the tab bar.
> As a workaround I had to apply a style to wrapper element like this:
> ((Element) tabPanel.getElement().getChild(1)).setClassName(".gwt-
> TabLayoutPanel-wrapper");
> This is very ugly and will fail as soon as the TabLayoutPanel impl
> changes.
> Please consider applying the ".gwt-TabLayoutPanelTabs" style to the
> appropriate wrapper element.
>

This is a good point. I'll need to add another wrapper element around the
tabs to make this work, but I don't think that will cause any problems.
There *is* a wrapper created by the Layout class, but it's unsafe to apply
arbitrary styles to it (in particular, decorations such as border, margin,
and padding will confuse it -- it's actually there to work around
measurement problems with such decorations). I've added a comment to issue
4429 (default TLP styles) to capture this.

2. The setStyle(Primary)Name methods will not change the substyles.
> When using different TabLayoutPanels with different styles in the same
> application you'll have to overwrite each css property as you'll
> inherit all styles by default. It would be much better to change all
> substyles as it has been the case with the "old" gwt widgets
>

Actually, I can't think of any cases off the top of my head where we've
automatically updated sub-styles like this. For example, the old StackPanel
only modifies the top-most class name. The problem is that there are cases
where we'd be forced to walk arbitrarily large numbers of children every
time the style name is changed. We decided it was best to avoid this, and
require the (admittedly somewhat uglier, and imperfect) use of descendent
selectors. The right long-term approach is probably closer to what you
suggest below.

or - even better - to pass a ClientBundle defining all styles as an optional
> argument to the cstr of the TabLayoutPanel.
> A default style factory could provide default styles if no
> ClientBundle is provided. Replacing the default style factory using
> deferred binding could make the default styles themable.
> I've used this approach in my own app and it works fine.
>

Essentially, yes. Though it's a fairly complex design problem in the general
case to do so in a way that ensures there's no unnecessary overhead, and
supports all the common use cases. This is definitely a Q1 goal, and we'll
make a point to share design docs as soon as we have a rough idea of what it
should look like.
-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors

Re: [gwt-contrib] Re: AutoHide PopupPanel on History Events

[Joel Webber]

> "Say I have a GWT-powered eBook reader."
That would be really cool :)

Ok, fair enough. Let's just leave it as is then.
LGTM.

On Wed, Jan 13, 2010 at 3:55 PM, Isaac Truett  wrote:

> I like it except for one scenario:
>
> Say I have a GWT-powered eBook reader. I hide some navigation controls
> in the corner; mouse over and they pop up. I want them to disappear if
> you click outside the popup, so auto-hide=true. But If you click "next
> page" I want to set a history token (for the next page) and I want the
> controls to stay visible so that you don't have to mouse back over the
> trigger in the corner in order to flip the page again, or flip back.
> If auto-hide-on-click implied auto-hide-on-history then you would have
> to jump through some more hoops (keep track of the popup state and
> re-show after history change if it was visible before).
>
>
> On Wed, Jan 13, 2010 at 3:43 PM,   wrote:
> > An idea: What if we just considered "auto-hide on history" to be
> > equivalent to "auto-hide"? I definitely see that we can't hide *all*
> > popups on history events, but ones mark auto-hide seem like fair game.
> > What do you think?
> >
> > http://gwt-code-reviews.appspot.com/132804
> >
> > --
> > http://groups.google.com/group/Google-Web-Toolkit-Contributors
> >
>
> --
> http://groups.google.com/group/Google-Web-Toolkit-Contributors
>
-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors

Re: [gwt-contrib] Request to add setSplitPosition for SplitLayoutPanel

[Joel Webber]

This sounds quite reasonable to me. I just added issue 4489 to track this.
I've marked it for the 2.0.1 update, as it seems pretty obvious, but there's
a small probability that if I run into some kind of snag it will get punted.

On Tue, Jan 12, 2010 at 4:56 PM, Gabriel Guerrero <
gabrieldavidguerr...@gmail.com> wrote:

> Hi guys,
>
> First I have to say great work in the new layout system I’m so amazed
> how simple was solved and how good it is .
>
>  My request is to add a setSplitPosition method for the
> SplitLayoutPanel class, I did not find an issue for this, so I'm
> asking for it here first . The method as you could imagine is to
> change the position of the splitter after the split panel was created,
> also will be nice if there is an option to animate this.
>
> The following is a proposed solution for this issue, this is how I
> solved in my code, is also a good work around for anyone needing this
> now.
>
> package com.test.client;
>
> import com.google.gwt.user.client.ui.SplitLayoutPanel;
> import com.google.gwt.user.client.ui.Widget;
>
> public class MySplitLayoutPanel extends SplitLayoutPanel{
>
>public void setSplitPosition(Widget widgetBeforeTheSplitter, double
> size, boolean animate){
>LayoutData layout =  (LayoutData)
> widgetBeforeTheSplitter.getLayoutData();
>layout.oldSize = layout.size;
>layout.size=size;
>if (animate)
>animate(500);
>else
>forceLayout();
>}
> }
>
> So you'll just need to add that method to the SplitLayoutPanel class.
>
>
> Also If you want to test it . Here is the class I used to test it
>
> package com.test.client;
>
> import com.google.gwt.core.client.EntryPoint;
> import com.google.gwt.dom.client.Style.Unit;
> import com.google.gwt.event.dom.client.ClickEvent;
> import com.google.gwt.event.dom.client.ClickHandler;
> import com.google.gwt.user.client.ui.Button;
> import com.google.gwt.user.client.ui.DockLayoutPanel;
> import com.google.gwt.user.client.ui.HTML;
> import com.google.gwt.user.client.ui.RootLayoutPanel;
> import com.google.gwt.user.client.ui.SimplePanel;
> import com.google.gwt.user.client.ui.SplitLayoutPanel;
> import com.google.gwt.user.client.ui.TabLayoutPanel;
>
> /**
>  * Entry point classes define onModuleLoad().
>  */
> public class GWTTest implements EntryPoint {
>/**
> * This is the entry point method.
> */
>public void onModuleLoad() {
>
>final MySplitLayoutPanel p2 = new MySplitLayoutPanel();
>
>final HTML html = new HTML(" style='background-color:green'>ss div>");
>final HTML html2 = new HTML(" style='background-color:blue'>ss div>");
>
>p2.addSouth(html, 0);//This is initially hidden and it will
> be made
> visible
>// when the expand button is click
>
>p2.add(html2);
>
>TabLayoutPanel tabPanel = new TabLayoutPanel(2.8, Unit.EM);
>tabPanel.add(new HTML("this content"), "this");
>tabPanel.add(p2, "that");
>tabPanel.add(new HTML("the other content"), "the other");
>
>SplitLayoutPanel p = new SplitLayoutPanel();
>p.addWest(new HTML("navigation"), 128);
>p.add(tabPanel);
>
>Button button = new Button("Expand");
>button.addClickHandler(new ClickHandler() {
>
>public void onClick(ClickEvent event) {
>p2.setSplitPosition(html, 128,true);
>}
>});
>
>SimplePanel simplePanel = new SimplePanel();
>simplePanel.setWidget(button);
>
>DockLayoutPanel appPanel = new DockLayoutPanel(Unit.EM);
>appPanel.addNorth(simplePanel, 2);
>appPanel.addSouth(new HTML("footer"), 2);
>appPanel.add(p);
>RootLayoutPanel.get().add(appPanel);
>}
> }
>
>
>
> Im not sure if it was the best way to solved, but is the only solution
> I could find without changing the original class
>
> --
> http://groups.google.com/group/Google-Web-Toolkit-Contributors
>
-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors

Re: [gwt-contrib] setStylePrimaryName() on TabLayoutPanel has no effect

[Joel Webber]

AFAICT, it works fine. The style rules can get a little ugly, but if you are
explicit about descendant selectors, it behaves as expected. For example, if
you start with the rules described in the javadoc:

.gwt-TabLayoutPanel { }
.gwt-TabLayoutPanel .gwt-TabLayoutPanelTab { }
/* etc */

Then create a different set, like so

.MyTLP { }
.MyTLP .gwt-TabLayoutPanelTab { }
/* etc */

And call TabLayoutPanel.setStyle[Primary]Name("MyTLP"), you'll get the new
styles.

On Wed, Jan 13, 2010 at 9:23 AM, dflorey  wrote:

> Is this intended?
>
> --
> http://groups.google.com/group/Google-Web-Toolkit-Contributors
>
-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors

Re: [gwt-contrib] Fixes RichTextArea setEnabled and isEnabled

[Joel Webber]

@jlabanca: Given that this hits two of your favorite parts of the system,
mind having a look?

On Tue, Jan 12, 2010 at 2:26 PM,  wrote:

> Reviewers: ,
>
> Description:
> Current methods setEnabled and isEnabled in RichTextArea widget come
> from its parent class FocusWidget. This implementation changes and reads
> the attribute disabled of the element. Setting this attribute to the
> iframe element does nothing, so the correct way to handle this feature
> is to use document.designMode or body.contentEditable attributes
> depending on the browser.
>
> Please review this at http://gwt-code-reviews.appspot.com/131802
>
> Affected files:
>  user/src/com/google/gwt/user/client/ui/RichTextArea.java
>  user/src/com/google/gwt/user/client/ui/impl/RichTextAreaImpl.java
>  user/src/com/google/gwt/user/client/ui/impl/RichTextAreaImplIE6.java
>  user/src/com/google/gwt/user/client/ui/impl/RichTextAreaImplStandard.java
>
>
>
> --
> http://groups.google.com/group/Google-Web-Toolkit-Contributors
>
-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors

Re: [gwt-contrib] All the content of RichTextEditor is deleted in FF first time you push a key

[Joel Webber]

Ok, I'm a complete idiot. Please ignore stupid chatter between me and John
about our internal repository. There is nothing in GWT (internally or
externally) called RichTextEditor, so I just assumed RichTextArea was being
referred to on this thread.

On Fri, Jan 8, 2010 at 2:45 PM, Joel Webber  wrote:

> [-gwtc] He's not likely to know about google3 :)
>
>
> On Fri, Jan 8, 2010 at 2:38 PM, John LaBanca  wrote:
>
>> Are you using RichTextArea that is part of GWT, or another widget called
>> RichTextEditor (in google3?).
>>
>> Thanks,
>> John LaBanca
>> jlaba...@google.com
>>
>>
>>
>> On Fri, Jan 8, 2010 at 2:26 PM, Joel Webber  wrote:
>>
>>> If you're not explicitly selecting the RTA's text (using
>>> formatter.selectAll(), and it's becoming selected by default, please do file
>>> a bug for this. It's likely a mozilla bug, but there's probably something we
>>> can do to forcibly work around it. Do post a snippet that reproduces the
>>> exact behavior if possible -- these things often happen for subtle reasons
>>> that are hard to reproduce without a very specific order of operations.
>>>
>>> Thanks,
>>> joel.
>>>
>>> On Fri, Jan 8, 2010 at 2:08 PM, Manuel Carrasco Moñino <
>>> man...@apache.org> wrote:
>>>
>>>> Hello,
>>>>
>>>> When a RichTextEditor is added to a page and then you set the HTML
>>>> content, it is displayed fine, then when you focus the editor and write any
>>>> letter with your keyboard, all the content is erased. If you push undo
>>>> (ctrl-z) the content is displayed again. The problem seems to be that when
>>>> you add content to the editor, the first time, this content goes selected,
>>>> so when you introduce any text it is override.
>>>>
>>>> Do you think it is a bug?, is it possible to unselect the text after
>>>> adding it to the editor.
>>>>
>>>> Thanks
>>>> Manolo
>>>>
>>>>
>>>>
>>>> --
>>>> http://groups.google.com/group/Google-Web-Toolkit-Contributors
>>>>
>>>
>>>
>>> --
>>> http://groups.google.com/group/Google-Web-Toolkit-Contributors
>>>
>>
>>
>> --
>> http://groups.google.com/group/Google-Web-Toolkit-Contributors
>>
>
>
-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors

Re: [gwt-contrib] All the content of RichTextEditor is deleted in FF first time you push a key

[Joel Webber]

[-gwtc] He's not likely to know about google3 :)

On Fri, Jan 8, 2010 at 2:38 PM, John LaBanca  wrote:

> Are you using RichTextArea that is part of GWT, or another widget called
> RichTextEditor (in google3?).
>
> Thanks,
> John LaBanca
> jlaba...@google.com
>
>
>
> On Fri, Jan 8, 2010 at 2:26 PM, Joel Webber  wrote:
>
>> If you're not explicitly selecting the RTA's text (using
>> formatter.selectAll(), and it's becoming selected by default, please do file
>> a bug for this. It's likely a mozilla bug, but there's probably something we
>> can do to forcibly work around it. Do post a snippet that reproduces the
>> exact behavior if possible -- these things often happen for subtle reasons
>> that are hard to reproduce without a very specific order of operations.
>>
>> Thanks,
>> joel.
>>
>> On Fri, Jan 8, 2010 at 2:08 PM, Manuel Carrasco Moñino > > wrote:
>>
>>> Hello,
>>>
>>> When a RichTextEditor is added to a page and then you set the HTML
>>> content, it is displayed fine, then when you focus the editor and write any
>>> letter with your keyboard, all the content is erased. If you push undo
>>> (ctrl-z) the content is displayed again. The problem seems to be that when
>>> you add content to the editor, the first time, this content goes selected,
>>> so when you introduce any text it is override.
>>>
>>> Do you think it is a bug?, is it possible to unselect the text after
>>> adding it to the editor.
>>>
>>> Thanks
>>> Manolo
>>>
>>>
>>>
>>> --
>>> http://groups.google.com/group/Google-Web-Toolkit-Contributors
>>>
>>
>>
>> --
>> http://groups.google.com/group/Google-Web-Toolkit-Contributors
>>
>
>
> --
> http://groups.google.com/group/Google-Web-Toolkit-Contributors
>
-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors

Re: [gwt-contrib] All the content of RichTextEditor is deleted in FF first time you push a key

[Joel Webber]

If you're not explicitly selecting the RTA's text (using
formatter.selectAll(), and it's becoming selected by default, please do file
a bug for this. It's likely a mozilla bug, but there's probably something we
can do to forcibly work around it. Do post a snippet that reproduces the
exact behavior if possible -- these things often happen for subtle reasons
that are hard to reproduce without a very specific order of operations.

Thanks,
joel.

On Fri, Jan 8, 2010 at 2:08 PM, Manuel Carrasco Moñino wrote:

> Hello,
>
> When a RichTextEditor is added to a page and then you set the HTML content,
> it is displayed fine, then when you focus the editor and write any letter
> with your keyboard, all the content is erased. If you push undo (ctrl-z) the
> content is displayed again. The problem seems to be that when you add
> content to the editor, the first time, this content goes selected, so when
> you introduce any text it is override.
>
> Do you think it is a bug?, is it possible to unselect the text after adding
> it to the editor.
>
> Thanks
> Manolo
>
>
>
> --
> http://groups.google.com/group/Google-Web-Toolkit-Contributors
>
-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors

Re: [gwt-contrib] Re: History support broken on chrome

[Joel Webber]

Feel free to do so, though it would be really helpful if you can pin down
precisely what difference exists in your code that's causing it to behave
differently from the samples. No need to attach a complete app -- just a
snippet or general outline should be sufficient.

On Fri, Jan 8, 2010 at 4:43 AM, dflorey  wrote:

> Shall I file an issue for that?
>
> On Jan 6, 5:56 pm, dflorey  wrote:
> > I changed the method but still no luck. I'm running chrome 4.0.266.0
> > The app hangs after second back.
> >
> > On Jan 6, 5:32 pm, dflorey  wrote:
> >
> >
> >
> > > I just copied the example code:
> http://code.google.com/webtoolkit/doc/latest/DevGuideCodingBasicsHist...
> >
> > > I'll change my code to use newItem(..., false) and let you know if
> > > this works.
> > > Thanks so far!
> >
> > > On Jan 6, 5:02 pm, Thomas Broyer  wrote:
> >
> > > > On Jan 6, 3:47 pm, Joel Webber  wrote:
> >
> > > > > Daniel,
> >
> > > > > I'm seeing Showcase work fine on both Chrome/Mac and
> Chrome/Windows.
> >
> > > > Just test our app too, works fine.
> >
> > > > > Forhttp://www.floreysoft.com/I'mseeingdifferentbehaviors on each:
> >
> > > > > Windows: Everything seems to work fine, except for some strange
> shuffle when
> > > > > backing into the first history state, which keeps me from going
> forward out
> > > > > of this position.
> >
> > > > Using Chrome 4.0.266.0 (Dev Channel) on floreysoft, I experience the
> > > > behavior Daniel describes: first "back" works, second one hangs, with
> > > > Chrome showing the throbber.
> >
> > > > > Is there anything unusual going on in your app's history event
> handler?
> > > > > Perhaps something like calling History.newItem() in response to a
> history
> > > > > event?
> >
> > > > We do call History.newItem(..., false) in response to history events
> > > > and our app works OK, so at least newItem(..., false) isn't a
> problem,
> > > > but newItem(...) or newItem(..., true) would certainly be!
> >
> > > > It might be an issue with iframes too.
>
> --
> http://groups.google.com/group/Google-Web-Toolkit-Contributors
>
-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors

Re: [gwt-contrib] Re: [google-web-toolkit] r7364 committed - Adds the module name to the generated ID of FormPanel's iframe to ensu...

[Joel Webber]

On Thu, Jan 7, 2010 at 9:57 AM, John LaBanca  wrote:

> createUniqueId() guarantees a unique id for the document, but makes no
>> guarantees about uniqueness within the global namespace ($wnd). I think it
>> would be a worthwhile addition to create such a method in the future,
>> though.
>
>
> And to that point, we are generating a unique name for the hidden iframe,
> not a unique ID.  I'm not sure what effect it would have to have names that
> are not unique in the global namespace.
>

I'm an idiot, sorry. This is for the 'name' attribute of a form panel, not a
global variable. I'm not precisely sure to what extent "name" and "id"
overlap in their namespaces, but IIRC there are some subtle interactions.
This code should work fine, but Thomas' idea to use doc.uid would probably
be fine as well.
-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors

Re: [gwt-contrib] Re: [google-web-toolkit] r7364 committed - Adds the module name to the generated ID of FormPanel's iframe to ensu...

[Joel Webber]

createUniqueId() guarantees a unique id for the document, but makes no
guarantees about uniqueness within the global namespace ($wnd). I think it
would be a worthwhile addition to create such a method in the future,
though.

On Thu, Jan 7, 2010 at 4:12 AM, Thomas Broyer  wrote:

>
>
> On Jan 7, 12:23 am, John Tamplin  wrote:
> >
> > What about the case of multiple instances of the same module?
>
> How about simply using Document.get().createUniqueId() ?
>
> --
> http://groups.google.com/group/Google-Web-Toolkit-Contributors
>
-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors

Re: [gwt-contrib] Re: History support for StackLayoutPanel

[Joel Webber]

Apparently I've lost the ability to read, and was looking at TabLayoutPanel
:)
Just filed 4453 to track this.

On Wed, Jan 6, 2010 at 11:49 AM, dflorey  wrote:

> Where did you find these? Or are these the methods planned?
>
> I'm talking about the StackLayoutPanel not TabLayoutPanel...
>
> On Jan 6, 4:25 pm, Joel Webber  wrote:
> > Are addSelectionHandler(), addBeforeSelectionHandler(), selectTab(int),
> and
> > selectTab(Widget) not sufficient for this?
> >
> >
> >
> > On Wed, Jan 6, 2010 at 4:05 AM, dflorey  wrote:
> > > Hi,
> > > it would be very convenient if StackLayoutPanel would support
> > > SelectionHandler and a setItem(int index) method to implement history
> > > support.
> >
> > > --
> > >http://groups.google.com/group/Google-Web-Toolkit-Contributors
>
> --
> http://groups.google.com/group/Google-Web-Toolkit-Contributors
>
-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors

Re: [gwt-contrib] History support for StackLayoutPanel

[Joel Webber]

Are addSelectionHandler(), addBeforeSelectionHandler(), selectTab(int), and
selectTab(Widget) not sufficient for this?

On Wed, Jan 6, 2010 at 4:05 AM, dflorey  wrote:

> Hi,
> it would be very convenient if StackLayoutPanel would support
> SelectionHandler and a setItem(int index) method to implement history
> support.
>
> --
> http://groups.google.com/group/Google-Web-Toolkit-Contributors
>
-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors

Re: [gwt-contrib] Re: History support broken on chrome

[Joel Webber]

Daniel,

I'm seeing Showcase work fine on both Chrome/Mac and Chrome/Windows. For
http://www.floreysoft.com/ I'm seeing different behaviors on each:

Windows: Everything seems to work fine, except for some strange shuffle when
backing into the first history state, which keeps me from going forward out
of this position.

Mac: History items seem to be created correctly, and change when you click
back/forward, but the app itself often fails to respond to them altogether.

Is there anything unusual going on in your app's history event handler?
Perhaps something like calling History.newItem() in response to a history
event?

Cheers,
joel.

On Wed, Jan 6, 2010 at 4:53 AM, dflorey  wrote:

> Works fine in IE too
>
> On Jan 6, 10:51 am, dflorey  wrote:
> > For the some reason the history support is not working properly on
> > chrome.
> > I've just added the history example to the main tab panel and it is
> > working fine on firefox but works on chrome only for the first "back".
> > You can double check here:http://www.floreysoft.net
>
> --
> http://groups.google.com/group/Google-Web-Toolkit-Contributors
>
-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors