[gwt-contrib] Re: code review requested - allow OpenJDK to compile GWT

[John Tamplin]

On Sat, Mar 28, 2009 at 11:55 PM, Scott Blum  wrote:

> Two things:
> 1) Do you have to use a temp, or can you do something
> like artifacts.  find(EmittedArtifact.class)?  Or whatever
> the syntax is.
>

It could also be:
for (EmittedArtifact artifact : artifacts.find(EmittedArtifact.class)) {
etc if you prefer -- do you think that is cleaner?  The problem here is that
OpenJDK can't seem to properly infer A=EmittedArtifact from the return type
SortedSet> where EmittedArtifact extends
Artifact (defined as Artifact>).
This is just one case of a general class of recursive definitions which
OpenJDK fails to infer, and the Sun guy working on it has determined that
the old javac accepted in violation of JLS.  Since this seems very similar
to the definition of Enum, I can only guess Enum is special-cased.

Still another option would be to pass an explicit type token for the return
type.  We currently do not use the ability to return a different type, so
this would not require changing the call-sites if we did this:
  public > SortedSet find(Class
artifactType) {
return find(artifactType, artifactType);
  }

  public , T extends Artifact>
  SortedSet find(Class returnType, Class artifactType) {
...
  }

Would that be preferable?  It would make it harder to introduce something
that wouldn't compile on OpenJDK, as you would get a compile error and would
have to add a second type token if you tried to return a different type, and
it avoids having to infer the return type in all current uses.

2) What's the plan for preventing regressuions or new occurrences of this in
> the future?
>

I think when we upgrade our continuous build system, we should build with
OpenJDK.  Until then, I can build with OpenJDK so whenever I build trunk it
would be noticed.

-- 
John A. Tamplin
Software Engineer (GWT), Google

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

[gwt-contrib] Re: Style accessors

[Ray Ryan]

Looking at this more closely now, its a pretty chatty API.

What's with all the "Map because Enum.valueOf does not work in GWT" stuff?
That's untrue, yes? It's not as efficient as it should be (
http://code.google.com/p/google-web-toolkit/issues/detail?id=2046), but I
hate polluting our API due to a compiler flaw, especially for such tiny
lists of values.
All these "clearFoo" methods are really noisy. I hate to encourage null as a
parameter value, but I'd actually rather see setFoo(null) than five thousand
clear*() methods. An alternative would be to have an UNSET value in each
enum, but that seems nearly as cumbersome as all these clear methods.

We'd also have to change the numeric ones from int and double to Integer and
Double--is the compiler good about that?

The getBlahAsString methods are more noise. The appropriate properties
should implement String asString() (leaning on toString() in a public api is
a bad habit to encourage). Perhaps they can implement a StringBasedStyle
interface defining that method.

rjrjr

2009/3/29 Freeland Abbott 

> As we'd discussed earlier, here's a cut at giving our Style class explicit
> accessors for the various property attributes.
>
> (Not that it matters, but the only thing I *really* hate about our
> checkstyle alphabetization is that it splits clear/get/setFoo apart.  C'est
> la vie.)
>
>

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

[gwt-contrib] Open source? How?

[Allan Jacobs]

http://code.google.com/webtoolkit/makinggwtbetter.html#compiling
describes how to download and compile GWT source.  Download, it says,
starts with the Subversion command line

svn checkout http://google-web-toolkit.googlecode.com/svn/trunk/ trunk

This is not quite accurate.  Outsiders can only get a copy using

svn checkout http://google-web-toolkit.googlecode.com/svn/trunk/
google-web-toolkit-read-only

This is understandable:  there needs to be a mechanism to control code
commits.

But, there is a side effect.  The source code cannot be compiled using
the build.xml in the read-only copy.  There are a small set of tools
that are required.  Most of these can be assembled using other
download sites.  One jar file, gwt-customchecks.jar is not publicly
available.

Is this a mistake by the engineering team?  Or, should I start hacking
the build.xml?

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

[gwt-contrib] Style accessors

[Freeland Abbott]

As we'd discussed earlier, here's a cut at giving our Style class explicit
accessors for the various property attributes.

(Not that it matters, but the only thing I *really* hate about our
checkstyle alphabetization is that it splits clear/get/setFoo apart.  C'est
la vie.)

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

Index: user/src/com/google/gwt/dom/client/Style.java
===
--- user/src/com/google/gwt/dom/client/Style.java	(revision 5099)
+++ user/src/com/google/gwt/dom/client/Style.java	(working copy)
@@ -1,12 +1,12 @@
 /*
  * Copyright 2008 Google Inc.
- * 
+ *
  * Licensed under the Apache License, Version 2.0 (the "License"); you may not
  * use this file except in compliance with the License. You may obtain a copy of
  * the License at
- * 
+ *
  * http://www.apache.org/licenses/LICENSE-2.0
- * 
+ *
  * Unless required by applicable law or agreed to in writing, software
  * distributed under the License is distributed on an "AS IS" BASIS, WITHOUT
  * WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the
@@ -17,17 +17,724 @@
 
 import com.google.gwt.core.client.JavaScriptObject;
 
+import java.util.HashMap;
+import java.util.Map;
+
 /**
  * Provides programmatic access to properties of the style object.
- * 
+ *
  * @see Element#getStyle()
  */
 public class Style extends JavaScriptObject {
 
+  /**
+   * Enum for the border-style property.
+   */
+  public static enum BorderStyle {
+ NONE,
+ HIDDEN,
+ DOTTED,
+ DASHED,
+ SOLID;
+// Map because Enum.valueOf does not work in GWT
+static Map map = new HashMap();
+static {
+  map.put("none", NONE);
+  map.put("hidden", HIDDEN);
+  map.put("dotted", DOTTED);
+  map.put("dashed", DASHED);
+  map.put("solid", SOLID);
+}
+  }
+
+  /**
+   * Enum for the cursor property.
+   */
+  public static enum Cursor {
+ DEFAULT,
+ AUTO,
+ CROSSHAIR,
+ POINTER,
+ MOVE,
+ E_RESIZE,
+ NE_RESIZE,
+ NW_RESIZE,
+ N_RESIZE,
+ SE_RESIZE,
+ SW_RESIZE,
+ S_RESIZE,
+ W_RESIZE,
+ TEXT,
+ WAIT,
+ HELP,
+ COL_RESIZE,
+ ROW_RESIZE;
+// Map because Enum.valueOf does not work in GWT
+static Map map = new HashMap();
+static {
+  map.put("default", DEFAULT);
+  map.put("auto", AUTO);
+  map.put("crosshair", CROSSHAIR);
+  map.put("pointer", POINTER);
+  map.put("move", MOVE);
+  map.put("e-resize", E_RESIZE);
+  map.put("ne-resize", NE_RESIZE);
+  map.put("nw-resize", NW_RESIZE);
+  map.put("n-resize", N_RESIZE);
+  map.put("se-resize", SE_RESIZE);
+  map.put("sw-resize", SW_RESIZE);
+  map.put("s-resize", S_RESIZE);
+  map.put("w-resize", W_RESIZE);
+  map.put("text", TEXT);
+  map.put("wait", WAIT);
+  map.put("help", HELP);
+  map.put("col-resize", COL_RESIZE);
+  map.put("row-resize", ROW_RESIZE);
+}
+  }
+
+  /**
+   * Enum for the display property.
+   */
+  public static enum Display {
+ NONE,
+ BLOCK,
+ INLINE,
+ INLINE_BLOCK;
+// Map because Enum.valueOf does not work in GWT
+static Map map = new HashMap();
+static {
+  map.put("none", NONE);
+  map.put("block", BLOCK);
+  map.put("inline", INLINE);
+  map.put("inline-block", INLINE_BLOCK);
+}
+  }
+
+  /**
+   * Enum for the font-style property.
+   */
+  public static enum FontStyle {
+ NORMAL,
+ ITALIC,
+ OBLIQUE;
+// Map because Enum.valueOf does not work in GWT
+static Map map = new HashMap();
+static {
+  map.put("normal", NORMAL);
+  map.put("italic", ITALIC);
+  map.put("oblique", OBLIQUE);
+}
+  }
+
+  /**
+   * Enum for the font-weight property.
+   */
+  public static enum FontWeight {
+ NORMAL,
+ BOLD,
+ BOLDER,
+ LIGHTER;
+// Map because Enum.valueOf does not work in GWT
+static Map map = new HashMap();
+static {
+  map.put("normal", NORMAL);
+  map.put("bold", BOLD);
+  map.put("bolder", BOLDER);
+  map.put("lighter", LIGHTER);
+}
+  }
+
+  /**
+   * Enum for the list-style-type property.
+   */
+  public static enum ListStyleType {
+ NONE,
+ DISC,
+ CIRCLE,
+ SQUARE,
+ DECIMAL,
+ LOWER_ALPHA,
+ UPPER_ALPHA,
+ LOWER_ROMAN,
+ UPPER_ROMAN;
+// Map because Enum.valueOf does not work in GWT
+static Map map = new HashMap();
+static {
+  map.put("none", NONE);
+  map.put("disc", DISC);
+  map.put("circle", CIRCLE);
+  map.put("square", SQUARE);
+  map.put("decimal", DECIMAL);
+  map.put("lower-alpha", LOWER_ALPHA);
+  map.put("upper-alpha", UPPER_ALPHA);
+  map.put("lower-roman", LOWER_ROMAN);
+  map.put("upper-roman", UPPER_ROMAN);
+}
+  }
+
+  /**
+   *  Enum for the overflow prope

[gwt-contrib] Re: Open source? How?

[Ray Ryan]

Read the next section, titled Compiling from Source

rjrjr

On Mon, Mar 30, 2009 at 9:52 AM, Allan Jacobs wrote:

>
> http://code.google.com/webtoolkit/makinggwtbetter.html#compiling
> describes how to download and compile GWT source.  Download, it says,
> starts with the Subversion command line
>
> svn checkout http://google-web-toolkit.googlecode.com/svn/trunk/ trunk
>
> This is not quite accurate.  Outsiders can only get a copy using
>
> svn checkout http://google-web-toolkit.googlecode.com/svn/trunk/
> google-web-toolkit-read-only
>
> This is understandable:  there needs to be a mechanism to control code
> commits.
>
> But, there is a side effect.  The source code cannot be compiled using
> the build.xml in the read-only copy.  There are a small set of tools
> that are required.  Most of these can be assembled using other
> download sites.  One jar file, gwt-customchecks.jar is not publicly
> available.
>
> Is this a mistake by the engineering team?  Or, should I start hacking
> the build.xml?
>
> >
>

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

[gwt-contrib] Re: code review requested - allow OpenJDK to compile GWT

[Scott Blum]

John and I discussed this face to face.  It turns out that the find() method
has, perhaps, and unnecessarily complicated specification that pushes
generic compile time sugar arguably past the point of usefulness --- and
definitely past what OpenJDK allows.
So our tentative resolution is to simplify the declaration of find() and
make it slightly less powerful.  It turns out none of our own code is making
any use whatsoever of the extra flexibility it currently has.

On Mon, Mar 30, 2009 at 11:20 AM, John Tamplin  wrote:

> On Sat, Mar 28, 2009 at 11:55 PM, Scott Blum  wrote:
>
>> Two things:
>> 1) Do you have to use a temp, or can you do something
>> like artifacts.  find(EmittedArtifact.class)?  Or whatever
>> the syntax is.
>>
>
> It could also be:
> for (EmittedArtifact artifact : artifacts. EmittedArtifact>find(EmittedArtifact.class)) {
> etc if you prefer -- do you think that is cleaner?  The problem here is
> that OpenJDK can't seem to properly infer A=EmittedArtifact from the return
> type SortedSet> where EmittedArtifact extends
> Artifact (defined as Artifact>).
> This is just one case of a general class of recursive definitions which
> OpenJDK fails to infer, and the Sun guy working on it has determined that
> the old javac accepted in violation of JLS.  Since this seems very similar
> to the definition of Enum, I can only guess Enum is special-cased.
>
> Still another option would be to pass an explicit type token for the return
> type.  We currently do not use the ability to return a different type, so
> this would not require changing the call-sites if we did this:
>   public > SortedSet find(Class
> artifactType) {
> return find(artifactType, artifactType);
>   }
>
>   public , T extends Artifact>
>   SortedSet find(Class returnType, Class artifactType) {
> ...
>   }
>
> Would that be preferable?  It would make it harder to introduce something
> that wouldn't compile on OpenJDK, as you would get a compile error and would
> have to add a second type token if you tried to return a different type, and
> it avoids having to infer the return type in all current uses.
>
> 2) What's the plan for preventing regressuions or new occurrences of this
>> in the future?
>>
>
> I think when we upgrade our continuous build system, we should build with
> OpenJDK.  Until then, I can build with OpenJDK so whenever I build trunk it
> would be noticed.
>
> --
> John A. Tamplin
> Software Engineer (GWT), Google
>

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

[gwt-contrib] Re: Open source? How?

[John Tamplin]

On Mon, Mar 30, 2009 at 12:52 PM, Allan Jacobs wrote:

>
> http://code.google.com/webtoolkit/makinggwtbetter.html#compiling
> describes how to download and compile GWT source.  Download, it says,
> starts with the Subversion command line
>
> svn checkout http://google-web-toolkit.googlecode.com/svn/trunk/ trunk
>
> This is not quite accurate.  Outsiders can only get a copy using
>
> svn checkout http://google-web-toolkit.googlecode.com/svn/trunk/
> google-web-toolkit-read-only
>

The difference between these two commands is simply what directory on your
local machine the repository is checked out into -- you can name it whatever
you like (I typically name it after the changes I am working on there).


> This is understandable:  there needs to be a mechanism to control code
> commits.
>
> But, there is a side effect.  The source code cannot be compiled using
> the build.xml in the read-only copy.  There are a small set of tools
> that are required.  Most of these can be assembled using other
> download sites.  One jar file, gwt-customchecks.jar is not publicly
> available.
>

The only reference I see to gwt-customchecks.jar si in common.ant.xml, and
there it refers to it as
${gwt.root}/eclipse/settings/code-style/gwt-checkstyle.xml -- since that is
part of the GWT trunk itself, I am not sure why you are having difficulties.


> Is this a mistake by the engineering team?  Or, should I start hacking
> the build.xml?
>

As Ray mentioned, the next step is to check out the tools directory, which I
assume contains the set of tools you are missing.  If after doing that you
still have problems, please post the error messages you get.  You should be
able to follow the instructions in that document and just run ant to get a
complete build of what we ship.

-- 
John A. Tamplin
Software Engineer (GWT), Google

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

[gwt-contrib] Re: code review requested - allow OpenJDK to compile GWT

[John Tamplin]

On Mon, Mar 30, 2009 at 1:57 PM, Scott Blum  wrote:

> John and I discussed this face to face.  It turns out that the find()
> method has, perhaps, an unnecessarily complicated specification that pushes
> generic compile time sugar arguably past the point of usefulness --- and
> definitely past what OpenJDK allows.
> So our tentative resolution is to simplify the declaration of find() and
> make it slightly less powerful.  It turns out none of our own code is making
> any use whatsoever of the extra flexibility it currently has.
>

Here is the patch which does what Scott suggested.  Any objections?

-- 
John A. Tamplin
Software Engineer (GWT), Google

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

Index: dev/core/src/com/google/gwt/core/ext/linker/ArtifactSet.java
===
--- dev/core/src/com/google/gwt/core/ext/linker/ArtifactSet.java	(revision 5074)
+++ dev/core/src/com/google/gwt/core/ext/linker/ArtifactSet.java	(working copy)
@@ -61,6 +61,7 @@
 return treeSet.containsAll(c);
   }
 
+  @Override
   public boolean equals(Object o) {
 return treeSet.equals(o);
   }
@@ -68,28 +69,29 @@
   /**
* Find all Artifacts assignable to some base type. The returned value will be
* a snapshot of the values in the ArtifactSet. The following two examples
-   * result in an equivalent set:
+   * result in an equivalent set (assuming there were no EmittedArtifacts
+   * present not of type PublicResource or GeneratedResource):
* 
* 
-   * SortedSet search = artifactSet.find(PublicResource.class);
-   * search.addAll(artifactSet.find(GeneratedResource.class);
+   *   SortedSet search = new TreeSet();
+   *   search.addAll(artifactSet.find(PublicResource.class));
+   *   search.addAll(artifactSet.find(GeneratedResource.class));
* 
* 
* or
* 
* 
-   * SortedSet search = artifactSet.find(EmittedArtifact.class);
+   *   SortedSet search = artifactSet.find(EmittedArtifact.class);
* 
* 
-   * @param  a type bound possibly wider than the desired type of artifact
* @param  the desired type of Artifact
* @param artifactType the desired type of Artifact
* @return all Artifacts in the ArtifactSet assignable to the desired type
*/
-  public , T extends A> SortedSet find(
+  public > SortedSet find(
   Class artifactType) {
 // TODO make this sub-linear (but must retain order for styles/scripts!)
-SortedSet toReturn = new TreeSet();
+SortedSet toReturn = new TreeSet();
 for (Artifact artifact : this) {
   if (artifactType.isInstance(artifact)) {
 toReturn.add(artifactType.cast(artifact));
@@ -113,6 +115,7 @@
 }
   }
 
+  @Override
   public int hashCode() {
 return treeSet.hashCode();
   }

[gwt-contrib] Re: code review requested - allow OpenJDK to compile GWT

[Scott Blum]

I think the javadoc is now more confusing than useful, due to the weird
caveat about public/generated resources.
How about we just kill all the javadoc from "The following two examples..."
up to the @param list?  Or else, give the most useful and common example,
using a for-each loop with the result of a find().

On Mon, Mar 30, 2009 at 2:33 PM, John Tamplin  wrote:

> On Mon, Mar 30, 2009 at 1:57 PM, Scott Blum  wrote:
>
>> John and I discussed this face to face.  It turns out that the find()
>> method has, perhaps, an unnecessarily complicated specification that pushes
>> generic compile time sugar arguably past the point of usefulness --- and
>> definitely past what OpenJDK allows.
>> So our tentative resolution is to simplify the declaration of find() and
>> make it slightly less powerful.  It turns out none of our own code is making
>> any use whatsoever of the extra flexibility it currently has.
>>
>
> Here is the patch which does what Scott suggested.  Any objections?
>
>
> --
> John A. Tamplin
> Software Engineer (GWT), Google
>

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

[gwt-contrib] Re: Review: JsArrays patch

[Kelly Norton]

Few things:
Overall, I'd like to be more conservative landing things in JavaScriptObject
for a couple of reasons: (1) It's hard to take a mulligan with these because
of their constraints (2) there is always a trivial work around to create
application specific subclasses (with toll free casting).

>> From r5082: I don't think toSource is appropriate for JavaScriptObject.
It only works on mozilla browsers.
>> JsArray.push: As I recall, this[this.length] = value is faster than
this.push(value) on all browsers. It's not a complexity change like
array.pop() is, but it can be significant. (How I do wish we had continuous
perf testing).

>> javadoc: The javadoc for these should be written to describe what the
function does. "Direct mapping to underlying sort" is a good implementation
note, but we should actually way what it does and not rely on developers
having an understanding of the JavaScript equivalent.

>> sort(JavaScriptObject): I'd like to avoid this one if we can. It just
opens up larger questions about the right way to do this. We don't currently
have a convention for representing JavaScript functions in Java. Someone
should probably have a good story there before we add something like this to
JavaScriptObject.

/kel

On Fri, Mar 27, 2009 at 2:15 PM, Freeland Abbott  wrote:

> I think the argument is more for "unnecessary" rather than "bad"...
> although without JsArrayBase (we can make it package-protected, and call it
> JsArrayImpl if anyone cares), we duplicate the JSNI implementation for a
> couple trivial methods.  I thought refactoring them into one place was nice,
> but trivial enough that I'm not fighting over it.  Revised patch attached; I
> can go either way on this.
>
>
>
>
>
> On Fri, Mar 27, 2009 at 2:06 PM, Scott Blum  wrote:
>
>> I'm going to punt this review to Bruce & Kelly, 'cause I have no idea why
>> having JsArrayBase would be bad. :)
>>
>> On Fri, Mar 27, 2009 at 1:28 PM, Freeland Abbott <
>> gwt.team.fabb...@gmail.com> wrote:
>>
>>> Scott, we already talked about this, but here's the patch for public
>>> review.
>>>
>>> The basic goal is to surface the native length, sort, push, and shift
>>> operators for JsArrays... I know you mentioned that IE6's push may be slower
>>> than indexed extension, and thus a candidate for deferred binding, but I
>>> wanted to get a basic implementation in first.
>>>
>>> There should be only checkstyle changes from what we discussed (though
>>> that obviously doesn't help the rest GWTC).  I also added some checkstyle
>>> fixes to JavaScriptObject, introduced by my c5082.
>>>
>>
>>
>


-- 
If you received this communication by mistake, you are entitled to one free
ice cream cone on me. Simply print out this email including all relevant
SMTP headers and present them at my desk to claim your creamy treat. We'll
have a laugh at my emailing incompetence, and play a game of ping pong.
(offer may not be valid in all States).

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

[gwt-contrib] Re: [google-web-toolkit commit] r5072 - Add favicon.ico files for each of the samples.

[Scott Blum]

Shoot.  Wish we'd done this in 1.6. :)

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

[gwt-contrib] [google-web-toolkit commit] r5101 - Edited wiki page through web user interface.

[codesite-noreply]

Author: sumitchan...@google.com
Date: Mon Mar 30 11:56:20 2009
New Revision: 5101

Modified:
wiki/IssueReportSample.wiki

Log:
Edited wiki page through web user interface.

Modified: wiki/IssueReportSample.wiki
==
--- wiki/IssueReportSample.wiki (original)
+++ wiki/IssueReportSample.wiki Mon Mar 30 11:56:20 2009
@@ -1,7 +1,7 @@
  #summary An example of a well reported issue on the GWT Issue Tracker.

  Issue Report Summary:
-CloseHandler.onClose() doesn't fire when added to PopupPanel
+CloseHandler.onClose() doesn't fire when added to !PopupPanel

  Found in GWT Release (e.g. 1.5.3, 1.6 RC):
  GWT 1.6.2
@@ -27,6 +27,7 @@

  Here is the PopupPanel that I'm trying to add the KeyUpHandler to:

+{{{
  public class NewsPopup extends PopupPanel {
private List articles = new ArrayList(16);
private Article lastArticle = new Article();
@@ -58,11 +59,13 @@
  // Set last article to the last selected article
}
  }
+}}}

  The Article widget is a simple class that wraps a Label indicating the  
article title.

  Here is the CloseHandler I'm trying to add to the news popup in the entry  
point onModuleLoad() method:

+{{{
  final NewsPopup newsPopup = new NewsPopup();
  newsPopup.addCloseHandler(new CloseHandler() {
@Override
@@ -70,6 +73,7 @@
  newsPopup.rememberLastArticle();
}
  });
+}}}

  Workaround if you have one:


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

[gwt-contrib] Re: JavaScriptException with 1.6.2

[Joel Webber]

I made some changes in event handling for 1.6, which might have caused this
(though it's not yet immediately obvious how). I'll be digging into it
tonight -- everyone please update this thread if any more information
surfaces.

On Mon, Mar 30, 2009 at 8:25 AM, nicolas de loof
wrote:

> Some more infos about this bug :
>> it happens in eventTargetsPopup as the NativeEvent beeing passed has no
>> eventTarget set.
>>
>> Find attached a screen capture from the developper that detected this
>> issue. Maybe the stacktrace can help you.
>>
>>
>>
>>
>> On Fri, Mar 27, 2009 at 6:07 PM, Scott Blum  wrote:
>>
>>> Do you know what event this was?  What do you do with the popup to get it
>>> to trigger?  Or does it just happen with no user interaction?
>>>
>>>
>>> On Fri, Mar 27, 2009 at 11:46 AM, nicolas de loof <
>>> nicolas.del...@gmail.com> wrote:
>>>
 Some more infos :
 We got this exception running in hosted mode browser (with -noserver) on
 windows
 No error when using an empty PopupPanel, also fine when containing a
 label, but fails when including a Table.

 Hope this helps ...


 On Fri, Mar 27, 2009 at 3:57 PM, Thomas Broyer wrote:

>
>
>
> On 26 mar, 19:18, John Tamplin  wrote:
> > On Thu, Mar 26, 2009 at 1:40 PM, Scott Blum 
> wrote:
> > > That's not good  it looks like Nicolas found an object for
> which trying
> > > to evaluate (!!o.nodeType) throws an exception.
> >
> > If my atrophied high-school French is correct, I believe the error is
> that o
> > is null at that point.
>
> It actually says that 'nodeType' (not 'o'!) is Null or is not an
> object.
>
> The thing is: I cannot understand why IE (this looks like an IE
> exception message, don't you think?) would throw such an exception
> while evaluating "!!" on such a null/undefined (it would effectively
> throw if 'o' were null, but it would say that "'o' is null or is not
> an object", or if we were trying to get or set a property or call a
> method on o.nodeType).
>
> Am I wrong?
>
>



>>>
>>>
>>>
>>
>
> >
>

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

[gwt-contrib] [google-web-toolkit commit] r5100 - Created wiki page through web user interface.

[codesite-noreply]

Author: sumitchan...@google.com
Date: Mon Mar 30 11:54:58 2009
New Revision: 5100

Added:
wiki/IssueReportSample.wiki

Log:
Created wiki page through web user interface.

Added: wiki/IssueReportSample.wiki
==
--- (empty file)
+++ wiki/IssueReportSample.wiki Mon Mar 30 11:54:58 2009
@@ -0,0 +1,94 @@
+#summary An example of a well reported issue on the GWT Issue Tracker.
+
+Issue Report Summary:
+CloseHandler.onClose() doesn't fire when added to PopupPanel
+
+Found in GWT Release (e.g. 1.5.3, 1.6 RC):
+GWT 1.6.2
+
+Encountered on OS / Browser (e.g. WinXP, IE6-7 | Fedora 10, FF3):
+WinXP, IE6-8, Chrome, hosted mode | MacOSX Leopard Safari 3.2.1, hosted  
mode
+This is not an issue on WinXP FF3.
+
+
+Detailed description (please be as specific as possible):
+
+If I add a CloseHandler to a PopupPanel, the onClose() method nevers seems  
to fire. I've tried adding the same CloseHandler to other widgets like a  
MenuBar and it worked fine in all browsers there.
+
+You can reproduce this issue by doing the following:
+
+1) Setup your test application with the repro code snippet below.
+
+2) Start the application in hosted mode and click to put focus on the news  
popup widget.
+
+3) With the news popup open, try closing the popup and expect the  
onClose() method to fire. You'll notice that on the browsers listed above,  
the onKeyUp method isn't being fired.
+
+Repro code snippet (to help us reproduce the issue):
+
+Here is the PopupPanel that I'm trying to add the KeyUpHandler to:
+
+public class NewsPopup extends PopupPanel {
+  private List articles = new ArrayList(16);
+  private Article lastArticle = new Article();
+  private Grid articlesGrid = new Grid(4,4);
+  VerticalPanel articlePanel = new VerticalPanel();
+
+  public NewsPopup() {
+super();
+int i = 0, j = 0;
+for(Article article : articles) {
+  if(i == 4) {
+i = 0;
+  }
+
+  if(j == 4) {
+j = 0;
+  }
+
+  articlesGrid.setWidget(i, j, article);
+  i++;
+  j++;
+}
+  }
+
+  /**
+   * Retains the last article that was selected when the news popup is  
closed.
+   */
+  public void rememberLastArticle() {
+// Set last article to the last selected article
+  }
+}
+
+The Article widget is a simple class that wraps a Label indicating the  
article title.
+
+Here is the CloseHandler I'm trying to add to the news popup in the entry  
point onModuleLoad() method:
+
+final NewsPopup newsPopup = new NewsPopup();
+newsPopup.addCloseHandler(new CloseHandler() {
+  @Override
+  public void onClose(CloseEvent event) {
+newsPopup.rememberLastArticle();
+  }
+});
+
+Workaround if you have one:
+
+Maintain state everytime there is a change to the news panel, but this  
gets expensive.
+
+
+Links to relevant GWT Developer Forum posts:
+
+http://groups.google.com/group/Google-Web-Toolkit/browse_thread/thread/samplelink
+
+
+= Introduction =
+
+Add your content here.
+
+
+= Details =
+
+Add your content here.  Format your content with:
+  * Text in *bold* or _italic_
+  * Headings, paragraphs, and lists
+  * Automatic links to other wiki pages
\ No newline at end of file

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

[gwt-contrib] Re: JavaScriptException with 1.6.2

[Joel Webber]

Still trying to see how this can happen in practice. The only way I can get
the expression !!o.nodeType to give the aforementioned error on IE is to set
o to null or undefined. This could happen (on any browser) if event.target
is null, but that *should* be illegal. We could try to work around this by
adding a null check in Node.is() (or upstream in
PopupPanel.eventTargetsPopup()), but I'd really like to see precisely what
went wrong before getting quite that defensive.
Is there any chance you could provide a code snippet that causes this in
practice? I know we have tables in popups all over the place, because the
DialogBox class does this (by using a DockPanel in a PopupPanel), so it's
got to be a bit more subtle or complex than that.

Thanks,
joel.

On Mon, Mar 30, 2009 at 3:01 PM, Joel Webber  wrote:

> I made some changes in event handling for 1.6, which might have caused this
> (though it's not yet immediately obvious how). I'll be digging into it
> tonight -- everyone please update this thread if any more information
> surfaces.
>
>
> On Mon, Mar 30, 2009 at 8:25 AM, nicolas de loof  > wrote:
>
>> Some more infos about this bug :
>>> it happens in eventTargetsPopup as the NativeEvent beeing passed has no
>>> eventTarget set.
>>>
>>> Find attached a screen capture from the developper that detected this
>>> issue. Maybe the stacktrace can help you.
>>>
>>>
>>>
>>>
>>> On Fri, Mar 27, 2009 at 6:07 PM, Scott Blum  wrote:
>>>
 Do you know what event this was?  What do you do with the popup to get
 it to trigger?  Or does it just happen with no user interaction?


 On Fri, Mar 27, 2009 at 11:46 AM, nicolas de loof <
 nicolas.del...@gmail.com> wrote:

> Some more infos :
> We got this exception running in hosted mode browser (with -noserver)
> on windows
> No error when using an empty PopupPanel, also fine when containing a
> label, but fails when including a Table.
>
> Hope this helps ...
>
>
> On Fri, Mar 27, 2009 at 3:57 PM, Thomas Broyer wrote:
>
>>
>>
>>
>> On 26 mar, 19:18, John Tamplin  wrote:
>> > On Thu, Mar 26, 2009 at 1:40 PM, Scott Blum 
>> wrote:
>> > > That's not good  it looks like Nicolas found an object for
>> which trying
>> > > to evaluate (!!o.nodeType) throws an exception.
>> >
>> > If my atrophied high-school French is correct, I believe the error
>> is that o
>> > is null at that point.
>>
>> It actually says that 'nodeType' (not 'o'!) is Null or is not an
>> object.
>>
>> The thing is: I cannot understand why IE (this looks like an IE
>> exception message, don't you think?) would throw such an exception
>> while evaluating "!!" on such a null/undefined (it would effectively
>> throw if 'o' were null, but it would say that "'o' is null or is not
>> an object", or if we were trying to get or set a property or call a
>> method on o.nodeType).
>>
>> Am I wrong?
>>
>>
>
>
>



>>>
>>
>> >>
>>
>

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

[gwt-contrib] Re: JavaScriptException with 1.6.2

[nicolas de loof]

I'll try to setup a smallest project and reproduce the issue.
On Mon, Mar 30, 2009 at 9:28 PM, Joel Webber  wrote:

> Still trying to see how this can happen in practice. The only way I can get
> the expression !!o.nodeType to give the aforementioned error on IE is to set
> o to null or undefined. This could happen (on any browser) if event.target
> is null, but that *should* be illegal. We could try to work around this by
> adding a null check in Node.is() (or upstream in
> PopupPanel.eventTargetsPopup()), but I'd really like to see precisely what
> went wrong before getting quite that defensive.
> Is there any chance you could provide a code snippet that causes this in
> practice? I know we have tables in popups all over the place, because the
> DialogBox class does this (by using a DockPanel in a PopupPanel), so it's
> got to be a bit more subtle or complex than that.
>
> Thanks,
> joel.
>
>
> On Mon, Mar 30, 2009 at 3:01 PM, Joel Webber  wrote:
>
>> I made some changes in event handling for 1.6, which might have caused
>> this (though it's not yet immediately obvious how). I'll be digging into it
>> tonight -- everyone please update this thread if any more information
>> surfaces.
>>
>>
>> On Mon, Mar 30, 2009 at 8:25 AM, nicolas de loof <
>> nicolas.del...@gmail.com> wrote:
>>
>>> Some more infos about this bug :
 it happens in eventTargetsPopup as the NativeEvent beeing passed has no
 eventTarget set.

 Find attached a screen capture from the developper that detected this
 issue. Maybe the stacktrace can help you.




 On Fri, Mar 27, 2009 at 6:07 PM, Scott Blum  wrote:

> Do you know what event this was?  What do you do with the popup to get
> it to trigger?  Or does it just happen with no user interaction?
>
>
> On Fri, Mar 27, 2009 at 11:46 AM, nicolas de loof <
> nicolas.del...@gmail.com> wrote:
>
>> Some more infos :
>> We got this exception running in hosted mode browser (with -noserver)
>> on windows
>> No error when using an empty PopupPanel, also fine when containing a
>> label, but fails when including a Table.
>>
>> Hope this helps ...
>>
>>
>> On Fri, Mar 27, 2009 at 3:57 PM, Thomas Broyer wrote:
>>
>>>
>>>
>>>
>>> On 26 mar, 19:18, John Tamplin  wrote:
>>> > On Thu, Mar 26, 2009 at 1:40 PM, Scott Blum 
>>> wrote:
>>> > > That's not good  it looks like Nicolas found an object for
>>> which trying
>>> > > to evaluate (!!o.nodeType) throws an exception.
>>> >
>>> > If my atrophied high-school French is correct, I believe the error
>>> is that o
>>> > is null at that point.
>>>
>>> It actually says that 'nodeType' (not 'o'!) is Null or is not an
>>> object.
>>>
>>> The thing is: I cannot understand why IE (this looks like an IE
>>> exception message, don't you think?) would throw such an exception
>>> while evaluating "!!" on such a null/undefined (it would effectively
>>> throw if 'o' were null, but it would say that "'o' is null or is not
>>> an object", or if we were trying to get or set a property or call a
>>> method on o.nodeType).
>>>
>>> Am I wrong?
>>>
>>>
>>
>>
>>
>
>
>

>>>
>>>
>>>
>>
>
> >
>

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

[gwt-contrib] Comment on CodeSplitting in google-web-toolkit

[codesite-noreply]

Comment by adam.tacy:

A suggestion for the common coding patterns: I've found that I needed three  
cases more often than not and so extended the ModuleClient interface as  
follows:

public interface ModuleClient {
void onLoad(Module instance);
void onAlreadyLoaded(Module instance);
void onUnavailable();
}

The addition is the onAlreadyLoaded() method which can be used if the code  
is already loaded.  This is useful if you want to do additional work on the  
first load and only a subset or different work if already loaded.

A very simple example is where the RunAsync code might return a widget.   
The onLoad() could add that widget to the DOM and then configure some items  
on it, the onAlreadyLoaded() method may not want to add the widget to the  
DOM and only show it.


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

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

[gwt-contrib] Comment on CodeSplitting in google-web-toolkit

[codesite-noreply]

Comment by adam.tacy:

A suggestion for the common coding patterns: I've found that I needed three  
cases more often than not and so extended the ModuleClient? interface as  
follows:

{{{
public interface ModuleClient {
 void onLoad(Module instance);
 void onAlreadyLoaded(Module instance);
 void onUnavailable();
}
}}}

The addition is the onAlreadyLoaded() method which can be used if the code  
is already loaded. This is useful if you want to do additional work on the  
first load and only a subset or different work if already loaded.

A very simple example is where the RunAsync code might return a widget. The  
onLoad() could add that widget to the DOM and then configure some items on  
it, the onAlreadyLoaded() method may not want to add the widget to the DOM  
and only show it.



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

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

[gwt-contrib] [google-web-toolkit commit] r5105 - Edited wiki page through web user interface.

[codesite-noreply]

Author: sumitchan...@google.com
Date: Mon Mar 30 14:22:16 2009
New Revision: 5105

Modified:
wiki/IssueReportSample.wiki

Log:
Edited wiki page through web user interface.

Modified: wiki/IssueReportSample.wiki
==
--- wiki/IssueReportSample.wiki (original)
+++ wiki/IssueReportSample.wiki Mon Mar 30 14:22:16 2009
@@ -15,7 +15,7 @@

  *Detailed description (please be as specific as possible)*:

-If I add a !CloseHandler to a !PopupPanel, the onClose() method nevers  
seems to fire. I've tried adding the same !CloseHandler to other widgets  
like a MenuBar and it worked fine in all browsers there.
+If I add a !CloseHandler to a !PopupPanel, the onClose() method nevers  
seems to fire. I've tried adding the same !CloseHandler to other widgets  
like a !MenuBar and it worked fine in all browsers there.

  You can reproduce this issue by doing the following:


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

[gwt-contrib] [google-web-toolkit commit] r5104 - Edited wiki page through web user interface.

[codesite-noreply]

Author: sumitchan...@google.com
Date: Mon Mar 30 14:21:56 2009
New Revision: 5104

Modified:
wiki/IssueReportSample.wiki

Log:
Edited wiki page through web user interface.

Modified: wiki/IssueReportSample.wiki
==
--- wiki/IssueReportSample.wiki (original)
+++ wiki/IssueReportSample.wiki Mon Mar 30 14:21:56 2009
@@ -4,9 +4,11 @@
  !CloseHandler.onClose() doesn't fire when added to !PopupPanel

  *Found in GWT Release (e.g. 1.5.3, 1.6 RC)*:
+
  GWT 1.6.2

  *Encountered on OS / Browser (e.g. WinXP, IE6-7 | Fedora 10, FF3)*:
+
  WinXP, IE6-8, Chrome, hosted mode | MacOSX Leopard Safari 3.2.1, hosted  
mode
  This is not an issue on WinXP FF3.


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

[gwt-contrib] [google-web-toolkit commit] r5106 - Edited wiki page through web user interface.

[codesite-noreply]

Author: sumitchan...@google.com
Date: Mon Mar 30 14:22:55 2009
New Revision: 5106

Modified:
wiki/IssueReportSample.wiki

Log:
Edited wiki page through web user interface.

Modified: wiki/IssueReportSample.wiki
==
--- wiki/IssueReportSample.wiki (original)
+++ wiki/IssueReportSample.wiki Mon Mar 30 14:22:55 2009
@@ -65,7 +65,7 @@

  The Article widget is a simple class that wraps a Label indicating the  
article title.

-Here is the CloseHandler I'm trying to add to the news popup in the entry  
point onModuleLoad() method:
+Here is the !CloseHandler I'm trying to add to the news popup in the entry  
point onModuleLoad() method:

  {{{
  final NewsPopup newsPopup = new NewsPopup();
@@ -83,4 +83,5 @@


  *Links to relevant GWT Developer Forum posts*:
+
   
http://groups.google.com/group/Google-Web-Toolkit/browse_thread/thread/samplelink

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

[gwt-contrib] [google-web-toolkit commit] r5103 - Edited wiki page through web user interface.

[codesite-noreply]

Author: sumitchan...@google.com
Date: Mon Mar 30 14:21:12 2009
New Revision: 5103

Modified:
wiki/IssueReportSample.wiki

Log:
Edited wiki page through web user interface.

Modified: wiki/IssueReportSample.wiki
==
--- wiki/IssueReportSample.wiki (original)
+++ wiki/IssueReportSample.wiki Mon Mar 30 14:21:12 2009
@@ -3,15 +3,15 @@
  Issue Report Summary:
  !CloseHandler.onClose() doesn't fire when added to !PopupPanel

-Found in GWT Release (e.g. 1.5.3, 1.6 RC):
+*Found in GWT Release (e.g. 1.5.3, 1.6 RC)*:
  GWT 1.6.2

-Encountered on OS / Browser (e.g. WinXP, IE6-7 | Fedora 10, FF3):
+*Encountered on OS / Browser (e.g. WinXP, IE6-7 | Fedora 10, FF3)*:
  WinXP, IE6-8, Chrome, hosted mode | MacOSX Leopard Safari 3.2.1, hosted  
mode
  This is not an issue on WinXP FF3.


-Detailed description (please be as specific as possible):
+*Detailed description (please be as specific as possible)*:

  If I add a !CloseHandler to a !PopupPanel, the onClose() method nevers  
seems to fire. I've tried adding the same !CloseHandler to other widgets  
like a MenuBar and it worked fine in all browsers there.

@@ -23,7 +23,7 @@

  3) With the news popup open, try closing the popup and expect the  
onClose() method to fire. You'll notice that on the browsers listed above,  
the onKeyUp method isn't being fired.

-Repro code snippet (to help us reproduce the issue):
+*Repro code snippet (to help us reproduce the issue)*:

  Here is the !PopupPanel that I'm trying to add the !KeyUpHandler to:

@@ -75,11 +75,10 @@
  });
  }}}

-Workaround if you have one:
+*Workaround if you have one*:

  Maintain state everytime there is a change to the news panel, but this  
gets expensive.


-Links to relevant GWT Developer Forum posts:
-
+*Links to relevant GWT Developer Forum posts*:
   
http://groups.google.com/group/Google-Web-Toolkit/browse_thread/thread/samplelink

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

[gwt-contrib] [google-web-toolkit commit] r5102 - Edited wiki page through web user interface.

[codesite-noreply]

Author: sumitchan...@google.com
Date: Mon Mar 30 14:20:14 2009
New Revision: 5102

Modified:
wiki/IssueReportSample.wiki

Log:
Edited wiki page through web user interface.

Modified: wiki/IssueReportSample.wiki
==
--- wiki/IssueReportSample.wiki (original)
+++ wiki/IssueReportSample.wiki Mon Mar 30 14:20:14 2009
@@ -1,7 +1,7 @@
  #summary An example of a well reported issue on the GWT Issue Tracker.

  Issue Report Summary:
-CloseHandler.onClose() doesn't fire when added to !PopupPanel
+!CloseHandler.onClose() doesn't fire when added to !PopupPanel

  Found in GWT Release (e.g. 1.5.3, 1.6 RC):
  GWT 1.6.2
@@ -13,7 +13,7 @@

  Detailed description (please be as specific as possible):

-If I add a CloseHandler to a PopupPanel, the onClose() method nevers seems  
to fire. I've tried adding the same CloseHandler to other widgets like a  
MenuBar and it worked fine in all browsers there.
+If I add a !CloseHandler to a !PopupPanel, the onClose() method nevers  
seems to fire. I've tried adding the same !CloseHandler to other widgets  
like a MenuBar and it worked fine in all browsers there.

  You can reproduce this issue by doing the following:

@@ -25,7 +25,7 @@

  Repro code snippet (to help us reproduce the issue):

-Here is the PopupPanel that I'm trying to add the KeyUpHandler to:
+Here is the !PopupPanel that I'm trying to add the !KeyUpHandler to:

  {{{
  public class NewsPopup extends PopupPanel {
@@ -82,17 +82,4 @@

  Links to relevant GWT Developer Forum posts:

-http://groups.google.com/group/Google-Web-Toolkit/browse_thread/thread/samplelink
-
-
-= Introduction =
-
-Add your content here.
-
-
-= Details =
-
-Add your content here.  Format your content with:
-  * Text in *bold* or _italic_
-  * Headings, paragraphs, and lists
-  * Automatic links to other wiki pages
\ No newline at end of file
+http://groups.google.com/group/Google-Web-Toolkit/browse_thread/thread/samplelink
\ No newline at end of file

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

[gwt-contrib] Re: Style accessors

[Ray Cromwell]

I have an alternative approach that results in a less chatty (exposed to
developer) API while preserving absolutely optimal compiler output that I'll
be using for GQuery. I use a type-safe enum pattern where the enums
themselves are implemented as a JSO. The overall result is to effectively
subclass java.lang.String with tighter types. I'm calling this the
"type-safe JSO enum" pattern.
Here's how it works:  Start with an interface for enumerated values:

 interface CssProp {
void set(Style s, T value);
T get(Style s);
  }


Create a single method for setting property values, as an example:
public static > void css(T prop, Style s, S val) {
prop.set(s, val);
  }

We could like to call this as so:

css(VERTICAL_ALIGN, element.getStyle(), TOP); // legal
css(VERTICAL_ALIGN, element.getStyle(), LEFT); // edit time/compile time
error

and we want the generated code to be:
element.style['verticalAlign']='top';

with no extra classes, no extra clinits, no nothing.

Let's implement an example for VerticalAlign:

public class VerticalAlign
implements CssProp,
TakesLength, TakesPercentage {

  public static VAlignValue TOP;

  public static VAlignValue BOTTOM;

  public static VerticalAlign VERTICAL_ALIGN;

  public VerticalAlign() {
TOP = VAlignValue.create("top");
BOTTOM = VAlignValue.create("bottom");
  }

  public static void init() {
VERTICAL_ALIGN = new VerticalAlign();
  }

  final public void set(Style s, VAlignValue value) {
s.setProperty("verticalAlign", value.value());
  }

  public VAlignValue get(Style s) {
return s.getProperty("verticalAlign").equals(TOP.value()) ? TOP :
BOTTOM;
  }

  public VAlignValue get() {
return TOP;
  }

  public void setLength(Style s, Length l) {
s.setProperty("verticalAlign", l.value());
  }

  public void setPercentage(Style s, Percentage p) {
s.setProperty("verticalAlign", p.value());

  }

  final static public class VAlignValue extends JavaScriptObject {

protected VAlignValue() {
}

public static VAlignValue create(String val) {
  return GWT.isScript() ? createWeb(val) : createHosted(val);
}

public String value() {
  return GWT.isScript() ? valueWeb() : valueHosted();
}

private static native VAlignValue createWeb(String val) /*-{
  return val;
}-*/;

private static native VAlignValue createHosted(String val) /*-{
  return [val];
}-*/;

private native String valueWeb() /*-{
   return this;
}-*/;

private native String valueHosted() /*-{
   return this[0];
}-*/;
  }
}

There are two versions of the enums, one for Hosted Mode and one for Web
Mode, due to Hosted Mode's inability to return a String from a method
returning a JSO.  In any case, I have verified using the trunk that this
results in the desired output, moreover, the optimality is not changed by
polymorphic implementations of CssProp. Calls to css() are boiled down to an
elegant inlined style assignment.

Now, not all CSS properties take a closed set of enum values, some take
multiple enum values, or an open set of values typed by units, like lengths
(e.g. 10px, 100%, 1.2em). Here, you introduce interfaces like TakesLength,
TakesPercentage, etc.

public static void css(TakesLength prop,
  Style s, Length val) {
prop.setLength(s, val);
 }

public static void css(TakesPercentage prop,
  Style s, Percentage val) {
prop.setPercentage(s, val);
}

With the Percentage and Length being JSOs as well with statically importable
type constructors, e.g. web-mode version

public native Percentage pct(int pct) /*-{
 return pct+"%";
}-*/;


This let's you write:

css(VERTICAL_ALIGN, elem, pct(25)); // compile succeeds

but you can't write

css(BACKGROUND_COLOR, elem, px(10)); // error, BACKGROUND_COLOR doesn't take
Length types

Again, this results in optimal output, except that the JsStaticEval pass of
the compiler currently won't statically collapse a JS expression like '100'
+ '%' into '100%'.

In my IDE (IntelliJ), this all results in a very pleasant development
experience. The IDE autocompletes all CSS property types, and then
auto-completes only valid enums for that property, or valid constructor
functions.

-Ray


2009/3/29 Freeland Abbott 

> As we'd discussed earlier, here's a cut at giving our Style class explicit
> accessors for the various property attributes.
>
> (Not that it matters, but the only thing I *really* hate about our
> checkstyle alphabetization is that it splits clear/get/setFoo apart.  C'est
> la vie.)
>
>
> >
>

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

[gwt-contrib] [google-web-toolkit commit] r5107 - Edited wiki page through web user interface.

[codesite-noreply]

Author: sumitchan...@google.com
Date: Mon Mar 30 14:58:52 2009
New Revision: 5107

Modified:
wiki/IssueReportSample.wiki

Log:
Edited wiki page through web user interface.

Modified: wiki/IssueReportSample.wiki
==
--- wiki/IssueReportSample.wiki (original)
+++ wiki/IssueReportSample.wiki Mon Mar 30 14:58:52 2009
@@ -25,54 +25,18 @@

  3) With the news popup open, try closing the popup and expect the  
onClose() method to fire. You'll notice that on the browsers listed above,  
the onKeyUp method isn't being fired.

-*Repro code snippet (to help us reproduce the issue)*:
+*Shortest code snippet which demonstrates issue (please indicate where  
actual result differs from expected result)*:

-Here is the !PopupPanel that I'm trying to add the !KeyUpHandler to:
+Although in my case I am using a subclass of the PopupPanel (a news panel)  
to maintain information about the currently selected article, I boiled down  
the issue to this simple code snippet:

-{{{
-public class NewsPopup extends PopupPanel {
-  private List articles = new ArrayList(16);
-  private Article lastArticle = new Article();
-  private Grid articlesGrid = new Grid(4,4);
-  VerticalPanel articlePanel = new VerticalPanel();
-
-  public NewsPopup() {
-super();
-int i = 0, j = 0;
-for(Article article : articles) {
-  if(i == 4) {
-i = 0;
-  }
-
-  if(j == 4) {
-j = 0;
-  }
-
-  articlesGrid.setWidget(i, j, article);
-  i++;
-  j++;
-}
-  }
-
-  /**
-   * Retains the last article that was selected when the news popup is  
closed.
-   */
-  public void rememberLastArticle() {
-// Set last article to the last selected article
-  }
-}
-}}}
-
-The Article widget is a simple class that wraps a Label indicating the  
article title.
-
-Here is the !CloseHandler I'm trying to add to the news popup in the entry  
point onModuleLoad() method:
+in onModuleLoad() method:

  {{{
-final NewsPopup newsPopup = new NewsPopup();
-newsPopup.addCloseHandler(new CloseHandler() {
+final PopupPanel popup = new PopupPanel();
+popup.addCloseHandler(new CloseHandler() {
@Override
public void onClose(CloseEvent event) {
-newsPopup.rememberLastArticle();
+Window.alert("Popup closed");
}
  });
  }}}

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

[gwt-contrib] [google-web-toolkit commit] r5110 - Added minimal release notes for 1.6.3

[codesite-noreply]

Author: sco...@google.com
Date: Mon Mar 30 15:30:25 2009
New Revision: 5110

Modified:
releases/1.6/distro-source/core/src/release_notes.html

Log:
Added minimal release notes for 1.6.3

Modified: releases/1.6/distro-source/core/src/release_notes.html
==
--- releases/1.6/distro-source/core/src/release_notes.html  (original)
+++ releases/1.6/distro-source/core/src/release_notes.html  Mon Mar 30  
15:30:25 2009
@@ -29,6 +29,7 @@
Google Web Toolkit Release Notes

@GWT_VERSION@
+   1.6.2
1.5.3
1.5.2
1.5.1 (RC2)
@@ -50,14 +51,18 @@
Release Notes for @GWT_VERSION@
Fixed Issues

-ConstantMap is really immutable now (it always  
should
-have been); it also no longer generates serialization warnings when
-attempting to serialize Map
-TreeMap and TreeSet are now
-serializable
+Various http://code.google.com/p/google-web-toolkit/issues/detail?id=3496";>servlet
  
classpath issues introduced in 1.6.2 are resolved.
+JSP compilation should work out of the box in hosted mode.

+

+  
+  Release Notes for 1.6.2 (RC)
+  
+ Please see http://code.google.com/docreader/?p(google-web-toolkit-doc-1-6)s(google-web-toolkit-doc-1-6)t(ReleaseNotes_1_6)">What's
  
new in GWT 1.6? (online)
+  

+  

Release Notes for 1.5.3
Fixed Issues

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

[gwt-contrib] [google-web-toolkit commit] r5111 - Edited wiki page through web user interface.

[codesite-noreply]

Author: sumitchan...@google.com
Date: Mon Mar 30 15:39:19 2009
New Revision: 5111

Modified:
wiki/IssueReportSample.wiki

Log:
Edited wiki page through web user interface.

Modified: wiki/IssueReportSample.wiki
==
--- wiki/IssueReportSample.wiki (original)
+++ wiki/IssueReportSample.wiki Mon Mar 30 15:39:19 2009
@@ -36,7 +36,7 @@
  popup.addCloseHandler(new CloseHandler() {
@Override
public void onClose(CloseEvent event) {
-Window.alert("Popup closed");
+Window.alert("Popup closed");   // < Nothing happens;  
never see alert dialog box
}
  });
  }}}

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

[gwt-contrib] [google-web-toolkit commit] r5109 - Make JDT Ant's default compiler. This makes JSPs work out of the box.

[codesite-noreply]

Author: sco...@google.com
Date: Mon Mar 30 15:29:58 2009
New Revision: 5109

Modified:
 
releases/1.6/dev/core/src/com/google/gwt/dev/shell/jetty/JettyLauncher.java

Log:
Make JDT Ant's default compiler.  This makes JSPs work out of the box.

Review by: tobyr

Modified:  
releases/1.6/dev/core/src/com/google/gwt/dev/shell/jetty/JettyLauncher.java
==
---  
releases/1.6/dev/core/src/com/google/gwt/dev/shell/jetty/JettyLauncher.java 
 
(original)
+++  
releases/1.6/dev/core/src/com/google/gwt/dev/shell/jetty/JettyLauncher.java 
 
Mon Mar 30 15:29:58 2009
@@ -431,6 +431,15 @@
  // Suppress spammy Jetty log initialization.
  System.setProperty("org.mortbay.log.class",  
JettyNullLogger.class.getName());
  Log.getLog();
+
+/*
+ * Make JDT the default Ant compiler so that JSP compilation just works
+ * out-of-the-box. If we don't set this, it's very, very difficult to  
make
+ * JSP compilation work.
+ */
+String antJavaC = System.getProperty("build.compiler",
+"org.eclipse.jdt.core.JDTCompilerAdapter");
+System.setProperty("build.compiler", antJavaC);
}

public ServletContainer start(TreeLogger logger, int port, File  
appRootDir)

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

[gwt-contrib] [google-web-toolkit commit] r5108 - Added JDTCompilerAdapter to JDT jars to enable JDT to be Ant's default compiler.

[codesite-noreply]

Author: sco...@google.com
Date: Mon Mar 30 15:29:08 2009
New Revision: 5108

Modified:
tools/lib/eclipse/jdt-3.4.2-src.zip
tools/lib/eclipse/jdt-3.4.2.jar

Log:
Added JDTCompilerAdapter to JDT jars to enable JDT to be Ant's default  
compiler.


Modified: tools/lib/eclipse/jdt-3.4.2-src.zip
==
Binary files. No diff available.

Modified: tools/lib/eclipse/jdt-3.4.2.jar
==
Binary files. No diff available.

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

[gwt-contrib] Re: Style accessors

[Ray Cromwell]

I think there's a couple of issues.  The lang wrapper classes for
int/double/etc pull in a lot of compiler cruft, because the compiler doesn't
currently know how to de-box these wrappers when it can. Last time I looked,
Java Enums add a lot of bloat to the compiled output, not just at the
definition site, but from anything that references them, you get clinit
calls. I'm not saying enums are always bad, but if you're going to go wild
creating lots and lots of them, be advised there will be bloat (somewhat
fixed by Lex's eager-clinit pruning patch).
Third, the reliance on method names for the properties would make some
patterns really painful. Just try to write a method that clears all styles
using only these methods, or clears any subset. A very natural thing to do
would be to want to write something like this:

public void clearStyle(Set currentStyle) {
   for(Property p : currentStyle) {
 clear(p);
   }
}

public void applyStyle(Map style) {
   for(Entry entry : style.entrySet()) {
  set(entry.getKey(), entry.getValue());
   }
}

And then store multiple styles in your app, letting users customize them via
a UI dialog. Doing this with a bunch of methods would lead to a really big
hardcoded dispatch function.

I'm not completely opposed to a bunch of individual methods, since their
cost if zero if they are never called, but IMHO, what many people really
want is a type-safe equivalent to style.setProperty().

-Ray

On Mon, Mar 30, 2009 at 9:29 AM, Ray Ryan  wrote:

> Looking at this more closely now, its a pretty chatty API.
>
> What's with all the "Map because Enum.valueOf does not work in GWT" stuff?
> That's untrue, yes? It's not as efficient as it should be (
> http://code.google.com/p/google-web-toolkit/issues/detail?id=2046), but I
> hate polluting our API due to a compiler flaw, especially for such tiny
> lists of values.
> All these "clearFoo" methods are really noisy. I hate to encourage null as
> a parameter value, but I'd actually rather see setFoo(null) than five
> thousand clear*() methods. An alternative would be to have an UNSET value in
> each enum, but that seems nearly as cumbersome as all these clear methods.
>
> We'd also have to change the numeric ones from int and double to Integer
> and Double--is the compiler good about that?
>
> The getBlahAsString methods are more noise. The appropriate properties
> should implement String asString() (leaning on toString() in a public api is
> a bad habit to encourage). Perhaps they can implement a StringBasedStyle
> interface defining that method.
>
> rjrjr
>
> 2009/3/29 Freeland Abbott 
>
>> As we'd discussed earlier, here's a cut at giving our Style class explicit
>> accessors for the various property attributes.
>>
>> (Not that it matters, but the only thing I *really* hate about our
>> checkstyle alphabetization is that it splits clear/get/setFoo apart.  C'est
>> la vie.)
>>
>>
>
> >
>

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

[gwt-contrib] Re: Review: JsArrays patch

[Ray Cromwell]

On Mon, Mar 30, 2009 at 11:44 AM, Kelly Norton  wrote:

> Few things:
>
> >> JsArray.push: As I recall, this[this.length] = value is faster than
> this.push(value) on all browsers. It's not a complexity change like
> array.pop() is, but it can be significant. (How I do wish we had continuous
> perf testing).
>

Did you guys compare variadic push as well? e.g., what's faster

this.push(a,b,c,d);

vs

this[this.length]=a;
this[this.length]=b;
this[this.length]=c;
this[this.length]=d;

? I wonder if push() is not natively accelerated by in reality, just
implemented as this[this.length]=x over arguments.

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

[gwt-contrib] Announcing GWT 1.6 RC2

[Scott Blum]

The GWT team is happy to announce the availability of Google Web Toolkit 1.6
RC2.  Download it here:

http://code.google.com/p/google-web-toolkit/downloads/list?q=1.6.3


For an overview of the new features in 1.6, please see the announcement:

http://googlewebtoolkit.blogspot.com/2009/03/google-web-toolkit-16-rc2-now-available.html


The only real difference from RC1 should be some fixes I made for the hosted
mode Jetty configuration issues that were reported with RC1:

http://code.google.com/p/google-web-toolkit/issues/list?can=2&q=milestone:1_6_RC2+status:Fixed,FixedNotReleased


--Scott, on behalf of the GWT team

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

[gwt-contrib] Please fix eclipse project files for cross-platform development

[Vitali Lovich]

Hi,

Would it be possible to update the Eclipse classpath for gwt-user to be
platform agnostic?

Since Eclipse doesn't support variable project references, one way would be
to move .classpath to .classpath-template & provide scripts that instrument
the .classpath file based on the environment (requires 1 extra step by the
user prior to importing the project).

Even smoother would be if this could be an ant task (something like ant
eclipse-config), although I'm not sure what kind of support ant might have
for regular expression replacement in files..

Not super important (especially with git), but just annoying that I need to
maintain the project files even if I'm not working on Eclipse.  And I
understand if you want to keep it as less handle for Windows users.

Thoughts?

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