[gwt-contrib] Re: Comment on ImageResource in google-web-toolkit
Comment by c...@chi.ca: It looks like the applyTo() method has been replaced with Image.setResource() http://google-web-toolkit.googlecode.com/svn/javadoc/2.0/com/google/gwt/user/client/ui/Image.html#setResource(com.google.gwt.resources.client.ImageResource) For more information: http://code.google.com/p/google-web-toolkit/wiki/ImageResource -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: URI-escape cookies (addresses external issue 4365)
All done, thanks. Committed at r7354.
On 2009/12/27 03:29:04, Dan Rice wrote:
> LGTM with minor nits.
> http://gwt-code-reviews.appspot.com/128801/diff/1/3
> File user/src/com/google/gwt/user/client/Cookies.java (right):
> http://gwt-code-reviews.appspot.com/128801/diff/1/3#newcode112
> Line 112: if (uriEncoding) {
> Prettier and less duplicated code to do:
> if (uriEncoding) {
>name = uriEncode(name);
> }
> removeCookieNative(name);
> http://gwt-code-reviews.appspot.com/128801/diff/1/3#newcode115
> Line 115: else {
> } else {
> on same line
> http://gwt-code-reviews.appspot.com/128801/diff/1/3#newcode128
> Line 128: if (uriEncoding) {
> Ditto
> http://gwt-code-reviews.appspot.com/128801/diff/1/3#newcode184
> Line 184: throw new IllegalArgumentException("Illegal cookie
format.");
> Include name and value in exception message, maybe distinguish between
bad name
> and bad value to make debugging easier.
> http://gwt-code-reviews.appspot.com/128801/diff/1/2
> File user/test/com/google/gwt/user/client/CookieTest.java (right):
> http://gwt-code-reviews.appspot.com/128801/diff/1/2#newcode166
> Line 166: // Make sure cookie values are URI encoded
> Probably best to add 'Cookies.setUriEncode(true);' here (redundantly)
to avoid
> dependency between sections of this method.
http://gwt-code-reviews.appspot.com/128801
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] [google-web-toolkit] r7354 committed - URI-escape cookies (addresses external issue 4365)....
Revision: 7354
Author: kpro...@google.com
Date: Mon Jan 4 20:00:50 2010
Log: URI-escape cookies (addresses external issue 4365).
Review by: rice
http://code.google.com/p/google-web-toolkit/source/detail?r=7354
Modified:
/trunk/user/src/com/google/gwt/user/client/Cookies.java
/trunk/user/test/com/google/gwt/user/client/CookieTest.java
===
--- /trunk/user/src/com/google/gwt/user/client/Cookies.java Fri Nov 20
06:32:19 2009
+++ /trunk/user/src/com/google/gwt/user/client/Cookies.java Mon Jan 4
20:00:50 2010
@@ -110,7 +110,7 @@
*/
public static void removeCookie(String name) {
if (uriEncoding) {
- uriEncode(name);
+ name = uriEncode(name);
}
removeCookieNative(name);
}
@@ -124,7 +124,7 @@
*/
public static void removeCookie(String name, String path) {
if (uriEncoding) {
- uriEncode(name);
+ name = uriEncode(name);
}
removeCookieNative(name, path);
}
@@ -174,10 +174,12 @@
public static void setCookie(String name, String value, Date expires,
String domain, String path, boolean secure) {
if (uriEncoding) {
- uriEncode(name);
- uriEncode(value);
-} else if (!isValidCookieName(name) || !isValidCookieValue(value)) {
- throw new IllegalArgumentException("Illegal cookie format.");
+ name = uriEncode(name);
+ value = uriEncode(value);
+} else if (!isValidCookieName(name)) {
+ throw new IllegalArgumentException("Illegal cookie format: " + name
+ " is not a valid cookie name.");
+} else if (!isValidCookieValue(value)) {
+ throw new IllegalArgumentException("Illegal cookie format: " + value
+ " is not a valid cookie value.");
}
setCookieImpl(name, value, (expires == null) ? 0 : expires.getTime(),
domain, path, secure);
===
--- /trunk/user/test/com/google/gwt/user/client/CookieTest.java Fri Nov 20
06:32:19 2009
+++ /trunk/user/test/com/google/gwt/user/client/CookieTest.java Mon Jan 4
20:00:50 2010
@@ -151,7 +151,25 @@
Cookies.removeCookie("test1+test1");
cookies = Cookies.getCookieNames();
assertEquals(curCount, cookies.size());
-
+
+// Make sure cookie names are URI encoded
+Cookies.setUriEncode(true);
+Cookies.setCookie("test1.,/?:@&=+$#", "value1");
+assertEquals(curCount + 1, Cookies.getCookieNames().size());
+Cookies.setUriEncode(false);
+Cookies.removeCookie("test1.,/?:@&=+$#");
+assertEquals(curCount + 1, Cookies.getCookieNames().size());
+Cookies.setUriEncode(true);
+Cookies.removeCookie("test1.,/?:@&=+$#");
+assertEquals(curCount, Cookies.getCookieNames().size());
+
+// Make sure cookie values are URI encoded
+Cookies.setUriEncode(true);
+Cookies.setCookie("testencodedvalue", "value1,/?:@&=+$#");
+Cookies.setUriEncode(false);
+String encodedValue = Cookies.getCookie("testencodedvalue");
+
assertTrue(encodedValue.compareTo("value1%2C%2F%3F%3A%40%26%3D%2B%24%23")
== 0);
+
// Make sure unencoded cookies with bogus format are not added
try {
Cookies.setCookie("test1=test1", "value1");
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] [google-web-toolkit] r7353 committed - Fixes a checkstyle error introduced in r7352....
Revision: 7353
Author: kpro...@google.com
Date: Mon Jan 4 19:21:08 2010
Log: Fixes a checkstyle error introduced in r7352.
Review by: rice (TBR)
http://code.google.com/p/google-web-toolkit/source/detail?r=7353
Modified:
/trunk/user/super/com/google/gwt/emul/java/sql/Timestamp.java
===
--- /trunk/user/super/com/google/gwt/emul/java/sql/Timestamp.java Mon Jan
4 11:06:23 2010
+++ /trunk/user/super/com/google/gwt/emul/java/sql/Timestamp.java Mon Jan
4 19:21:08 2010
@@ -44,7 +44,7 @@
if (hasNanos) {
String nanosString = timeComponents[1];
int len = nanosString.length();
- assert(len > 0); // len must be > 0 if hasNanos is true
+ assert len > 0; // len must be > 0 if hasNanos is true
if (len > 9) {
throw new IllegalArgumentException("Invalid escape format: " + s);
}
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: Benchmark for widget creation times
SGTM. I've got more to add once it's in.
On Mon, Jan 4, 2010 at 8:29 PM, wrote:
> Picked up last rounds of feedback from Joel (EmptyBinder weirdness),
> Thomas and James. Also checkstyle fixes.
>
> Barring further objections, I'll submit this in the morning. There are
> more tests that could be implemented (Joel may have written them
> already), but I'd like to get in what I have.
>
>
>
> http://gwt-code-reviews.appspot.com/127801/diff/2005/2013
> File
>
> reference/Microbenchmarks/src/com/google/gwt/reference/microbenchmark/client/TestDom.java
> (right):
>
> http://gwt-code-reviews.appspot.com/127801/diff/2005/2013#newcode58
> Line 58: e.removeAttribute("id");
> If I delete it I'll have to generate unique ids at runtime, and do
> string concatenation then too. Hard to imagine that being a win.
>
> I like the move-it-around idea, though. Now doing it after detach. Can't
> say I see a big difference that way, get by id still clearly loses.
>
>
> http://gwt-code-reviews.appspot.com/127801/diff/2005/2021
> File
>
> reference/Microbenchmarks/src/com/google/gwt/reference/microbenchmark/client/WidgetCreation.java
> (right):
>
> http://gwt-code-reviews.appspot.com/127801/diff/2005/2021#newcode58
> Line 58: return (new Date()).getTime();
> Thanks, didn't know about that.
>
>
> http://gwt-code-reviews.appspot.com/127801/diff/2005/2021#newcode157
> Line 157: widgets[widgets.length - 1].getElement().getOffsetTop();
> On 2010/01/02 09:01:46, jamesr wrote:
>
>> You should query offsetTop on the element instead of trying to
>>
> grab some
>
>> child element - it'll still do layout on everything in the document.
>>
>
> Another problem with setTimeout(0) is that the the '0' will get
>>
> rounded up to a
>
>> larger value that's not consistent between browsers - one of 4, 10, or
>>
> 15ms.
>
> Done.
>
>
> http://gwt-code-reviews.appspot.com/127801
>
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: Benchmark for widget creation times
Picked up last rounds of feedback from Joel (EmptyBinder weirdness),
Thomas and James. Also checkstyle fixes.
Barring further objections, I'll submit this in the morning. There are
more tests that could be implemented (Joel may have written them
already), but I'd like to get in what I have.
http://gwt-code-reviews.appspot.com/127801/diff/2005/2013
File
reference/Microbenchmarks/src/com/google/gwt/reference/microbenchmark/client/TestDom.java
(right):
http://gwt-code-reviews.appspot.com/127801/diff/2005/2013#newcode58
Line 58: e.removeAttribute("id");
If I delete it I'll have to generate unique ids at runtime, and do
string concatenation then too. Hard to imagine that being a win.
I like the move-it-around idea, though. Now doing it after detach. Can't
say I see a big difference that way, get by id still clearly loses.
http://gwt-code-reviews.appspot.com/127801/diff/2005/2021
File
reference/Microbenchmarks/src/com/google/gwt/reference/microbenchmark/client/WidgetCreation.java
(right):
http://gwt-code-reviews.appspot.com/127801/diff/2005/2021#newcode58
Line 58: return (new Date()).getTime();
Thanks, didn't know about that.
http://gwt-code-reviews.appspot.com/127801/diff/2005/2021#newcode157
Line 157: widgets[widgets.length - 1].getElement().getOffsetTop();
On 2010/01/02 09:01:46, jamesr wrote:
> You should query offsetTop on the element instead of trying to
grab some
> child element - it'll still do layout on everything in the document.
> Another problem with setTimeout(0) is that the the '0' will get
rounded up to a
> larger value that's not consistent between browsers - one of 4, 10, or
15ms.
Done.
http://gwt-code-reviews.appspot.com/127801
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] Possible bug in DOMImplMozilla
I'll look into it tomorrow morning. Thanks, John LaBanca jlaba...@google.com On Mon, Jan 4, 2010 at 2:37 PM, Joel Webber wrote: > Looks like you're right about that. > @jlabanca: Correct me if I'm wrong, but didn't you refactor this stuff a > while back? Mind having a look to make sure I'm not missing something? > > > On Sun, Jan 3, 2010 at 2:37 PM, Thomas Broyer wrote: > >> Hi googlers, >> >> In DOMImplMozilla's initSyntheticMouseUpEvents is a reference to >> $wnd.__captureElem, which is never set (or read) anywhere, making the >> workaround fail as being no-op in practice. >> Shouldn't it be >> @com.google.gwt.user.client.impl.DOMImplStandard::captureElem instead? >> >> -- >> http://groups.google.com/group/Google-Web-Toolkit-Contributors >> > > -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] Removing the deprecated XxxListeners
On Mon, Jan 4, 2010 at 7:45 PM, Joel Webber wrote: > A hearty +1 from me. We've been needing to do this for a while, but have > been so heads-down on new features that it's fallen by the wayside. On that > note, we also need to deprecate the DOM class and fix all the widgets to not > use it (all its functionality was subsumed by Document/Element a long time > ago). We're working on our 2010 roadmap right now, and this will definitely > be a part of it. That's Really. Good. News! (thanks for this birthday gift ;-) ) -- Thomas Broyer /tɔ.ma.bʁwa.je/ -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] Possible bug in DOMImplMozilla
Looks like you're right about that. @jlabanca: Correct me if I'm wrong, but didn't you refactor this stuff a while back? Mind having a look to make sure I'm not missing something? On Sun, Jan 3, 2010 at 2:37 PM, Thomas Broyer wrote: > Hi googlers, > > In DOMImplMozilla's initSyntheticMouseUpEvents is a reference to > $wnd.__captureElem, which is never set (or read) anywhere, making the > workaround fail as being no-op in practice. > Shouldn't it be > @com.google.gwt.user.client.impl.DOMImplStandard::captureElem instead? > > -- > http://groups.google.com/group/Google-Web-Toolkit-Contributors > -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: JSNI references with * as the parameter list
On Mon, Jan 4, 2010 at 1:26 PM, wrote:
> http://gwt-code-reviews.appspot.com/126817/diff/2006/2007
> File dev/core/test/com/google/gwt/dev/jjs/impl/JsniRefLookupTest.java
> (right):
>
> http://gwt-code-reviews.appspot.com/126817/diff/2006/2007#newcode234
> Line 234: JMethod res = (JMethod) lookup("test.Bar::foo(*)", errors);
> It seems weird that this should work. If Bar didn't declare foo() (and
> the lookup went up to the supertype Foo), this would fail to compile.
> It breaks the otherwise-Java style of name lookups used by JSNI to care
> about where the method is declared. It also rewards the unnecessary
> (and ugly) practice of re-defining a method overload just to make it the
> "default".
> It's simplest to explain to users that the @class::method(*) wildcard
> syntax selects the one method out of the entire supertype/superinterface
> hierarchy whose name is "method" without having to get into discussions
> about which type a method is declared on.
>
As would be expected, the trickiest part of this patch has to do with
overloading and inheritance. These are dark corners that good code will not
rely on, but our tools have to do something with them.
I'm not in love with the current algorithm, but what precisely shall we do?
It's certainly important, but let's be careful not to bike shed the corner
cases.
For this particular test case, I thought that if someone defines Bar and Bar
has exactly one foo method, then Bar::foo(*) should be allowed, regardless
of what Bar inherits. It's easy enough to disallow such a reference, but
should we? We have a choice here between supporting good code and
eliminating bad code. I fear that if we try to eliminate all the bad code
programmers could write, we will never be able to accept any code at all.
It's just a design guideline, though. Does anyone else have an opinion
about this question?
If we want to rule that case out, then my next suggestion would be to count
overloads exactly as a Java compiler would. That would mean that methods
overriding each other would not count as extra overloads. The main
trickiness would be dealing with inheritance that includes bridge methods.
That wouldn't be insurmountable, but it's more complicated than the current
solution.
FWIW, the current algorithm is as follows. I think it's pretty easy to work
with. If the user asks for Foo::bar(*), then start in class Foo and look
for methods named bar. If you see exactly one, then that's the one they
mean. If you see more than one, then the reference is ambiguous. If you
see zero, then recurse into inherited superclasses and methods.
Also, on that vein, add test code for looking up wildcards on
> interfaces.
Good idea, I will.
Lex
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] [google-web-toolkit] r7352 committed - Fix external issue 4048 - make java.sql.Timestamp emulation...
Revision: 7352
Author: r...@google.com
Date: Mon Jan 4 11:06:23 2010
Log: Fix external issue 4048 - make java.sql.Timestamp emulation
more lenient about the formatting of the nanoseconds field.
Review by: jat
http://code.google.com/p/google-web-toolkit/source/detail?r=7352
Modified:
/trunk/user/super/com/google/gwt/emul/java/sql/Timestamp.java
/trunk/user/test/com/google/gwt/emultest/java/sql/SqlTimestampTest.java
===
--- /trunk/user/super/com/google/gwt/emul/java/sql/Timestamp.java Mon May
18 11:47:32 2009
+++ /trunk/user/super/com/google/gwt/emul/java/sql/Timestamp.java Mon Jan
4 11:06:23 2010
@@ -29,19 +29,36 @@
}
String[] timeComponents = components[1].split("\\.");
-if (timeComponents.length != 2) {
+boolean hasNanos = true;
+int nanos = 0;
+
+if (timeComponents.length == 1) {
+ // Allow timestamps without .f nanoseconds field
+ hasNanos = false;
+} else if (timeComponents.length != 2) {
throw new IllegalArgumentException("Invalid escape format: " + s);
-} else if (timeComponents[1].length() != 9) {
- throw new IllegalArgumentException("Invalid escape format: " + s);
}
Date d = Date.valueOf(components[0]);
Time t = Time.valueOf(timeComponents[0]);
-int nanos;
-try {
- nanos = Integer.valueOf(timeComponents[1]);
-} catch (NumberFormatException e) {
- throw new IllegalArgumentException("Invalid escape format: " + s);
+if (hasNanos) {
+ String nanosString = timeComponents[1];
+ int len = nanosString.length();
+ assert(len > 0); // len must be > 0 if hasNanos is true
+ if (len > 9) {
+throw new IllegalArgumentException("Invalid escape format: " + s);
+ }
+
+ // Pad zeros on the right up to a total of 9 digits
+ if (len < 9) {
+nanosString += "".substring(len - 1);
+ }
+
+ try {
+nanos = Integer.valueOf(nanosString);
+ } catch (NumberFormatException e) {
+throw new IllegalArgumentException("Invalid escape format: " + s);
+ }
}
return new Timestamp(d.getYear(), d.getMonth(), d.getDate(),
t.getHours(),
===
--- /trunk/user/test/com/google/gwt/emultest/java/sql/SqlTimestampTest.java
Mon Jul 6 13:52:38 2009
+++ /trunk/user/test/com/google/gwt/emultest/java/sql/SqlTimestampTest.java
Mon Jan 4 11:06:23 2010
@@ -174,5 +174,40 @@
Timestamp expected = new Timestamp(2000 - 1900, 1 - 1, 1, 12, 34, 56,
123456789);
Timestamp actual = Timestamp.valueOf("2000-01-01 12:34:56.123456789");
assertEquals(expected, actual);
+
+expected = new Timestamp(2000 - 1900, 1 - 1, 1, 12, 34, 56, 0);
+actual = Timestamp.valueOf("2000-01-01 12:34:56");
+assertEquals(expected, actual);
+
+expected = new Timestamp(2000 - 1900, 1 - 1, 1, 12, 34, 56, 1);
+actual = Timestamp.valueOf("2000-01-01 12:34:56.1");
+assertEquals(expected, actual);
+
+expected = new Timestamp(2000 - 1900, 1 - 1, 1, 12, 34, 56, 12000);
+actual = Timestamp.valueOf("2000-01-01 12:34:56.12");
+assertEquals(expected, actual);
+
+expected = new Timestamp(2000 - 1900, 1 - 1, 1, 12, 34, 56, 12300);
+actual = Timestamp.valueOf("2000-01-01 12:34:56.123");
+assertEquals(expected, actual);
+
+expected = new Timestamp(2000 - 1900, 1 - 1, 1, 12, 34, 56, 12340);
+actual = Timestamp.valueOf("2000-01-01 12:34:56.1234");
+assertEquals(expected, actual);
+
+expected = new Timestamp(2000 - 1900, 1 - 1, 1, 12, 34, 56, 12345);
+actual = Timestamp.valueOf("2000-01-01 12:34:56.12345");
+assertEquals(expected, actual);
+
+expected = new Timestamp(2000 - 1900, 1 - 1, 1, 12, 34, 56, 123456000);
+actual = Timestamp.valueOf("2000-01-01 12:34:56.123456");
+assertEquals(expected, actual);
+
+expected = new Timestamp(2000 - 1900, 1 - 1, 1, 12, 34, 56, 123456700);
+actual = Timestamp.valueOf("2000-01-01 12:34:56.1234567");
+assertEquals(expected, actual);
+
+expected = new Timestamp(2000 - 1900, 1 - 1, 1, 12, 34, 56, 123456780);
+actual = Timestamp.valueOf("2000-01-01 12:34:56.12345678");
}
}
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: RFE: deprecate user.client.Element and user.client.DOM
I think I just inadvertently replied to this on another thread, but yes -- this is something we need to get on our roadmap very soon. On Dec 21 2009, 6:10 pm, Thomas Broyer wrote: > Hi Googlers, > > How about deprecating c.g.g.user.client.Element and > c.g.g.user.client.DOM altogether and "port" all existing widgets to > c.g.g.dom.client.*? > A first "pass", say in 2.1, wouldn't break public APIs, still using > c.g.g.user.client.Element as public and protected methods' return type > and fields; only the second pass (in 2.2 or even 2.3) would completely > get rid of c.g.g.user.client.Element. > > As for c.g.g.user.client.DOM, there are a few methods that have no > equivalent in c.g.g.dom.client.* (getChild/insertChild/etc. for > instance, which deal with child elements, not child nodes). Those > would have to either be moved to c.g.g.dom.client.Element or removed > altogether in the end (which means "deprecated with replacement API" > vs. "just deprecated" in the mean time). > Most widgets have complete control over their DOM, so changing from > "child element" to "child node" shouldn't break them. > > I volunteer to providing patches (probably one widget at a time), but > I'd like to know upfront if I'd waste my time or if it'd have a chance > of being accepted. -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] Re: TabLayoutPanel not working on IE8
Thanks, Alejandro. I'll reproduce this locally and enter an issue for it. It
sounds like the issue might have something to do with having a block-level
element *inside* the tabs two existing divs. float:left on just the
outer-most element is supposed to work here, but perhaps that's not enough
on IE.
On Mon, Jan 4, 2010 at 12:30 PM, Alejandro D. Garin wrote:
> On Mon, Jan 4, 2010 at 2:01 PM, Joel Webber wrote:
>
>> Which element did you have to add float:left to? It's set manually in code
>> to the outermost tab element, which is all that *should* be necessary.
>>
>>
>>
> Hi,
> I ran into the same issue with IE7/8 using the css example you suggested
> here:
>
>
> http://groups.google.com/group/google-web-toolkit-contributors/browse_thread/thread/e9d6b9d7ad02b66f
>
> but adding float:left to:
>
> .gwt-TabLayoutPanelTab {
> background: url(tab-inactive-left.png) no-repeat bottom left;
> float:left;
> }
>
> solves the problem.
>
> Alejandro.
>
> --
> http://groups.google.com/group/Google-Web-Toolkit-Contributors
>
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] Removing the deprecated XxxListeners
A hearty +1 from me. We've been needing to do this for a while, but have been so heads-down on new features that it's fallen by the wayside. On that note, we also need to deprecate the DOM class and fix all the widgets to not use it (all its functionality was subsumed by Document/Element a long time ago). We're working on our 2010 roadmap right now, and this will definitely be a part of it. On Mon, Dec 21, 2009 at 5:58 PM, Thomas Broyer wrote: > Hi Googlers, > > I thought this was targeted to 2.0 but it didn't make it into it. What > I'm talking about is the complete removal of the event listeners, > which have been replaced by handlers since GWT 1.6. > > I volunteer to provide the patch, but given that this is a bit of work > I'm asking here if I should start working on it, or if someone already > started the work, or if you'd rather have them stay for some > additional months (in this case, better spend time on more important > things). > > Let me know ;-) > > -- > http://groups.google.com/group/Google-Web-Toolkit-Contributors > -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: JSNI references with * as the parameter list
http://gwt-code-reviews.appspot.com/126817/diff/2006/2007
File dev/core/test/com/google/gwt/dev/jjs/impl/JsniRefLookupTest.java
(right):
http://gwt-code-reviews.appspot.com/126817/diff/2006/2007#newcode234
Line 234: JMethod res = (JMethod) lookup("test.Bar::foo(*)", errors);
It seems weird that this should work. If Bar didn't declare foo() (and
the lookup went up to the supertype Foo), this would fail to compile.
It breaks the otherwise-Java style of name lookups used by JSNI to care
about where the method is declared. It also rewards the unnecessary
(and ugly) practice of re-defining a method overload just to make it the
"default".
It's simplest to explain to users that the @class::method(*) wildcard
syntax selects the one method out of the entire supertype/superinterface
hierarchy whose name is "method" without having to get into discussions
about which type a method is declared on.
Also, on that vein, add test code for looking up wildcards on
interfaces.
http://gwt-code-reviews.appspot.com/126817
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] Re: TabLayoutPanel not working on IE8
On Mon, Jan 4, 2010 at 2:01 PM, Joel Webber wrote:
> Which element did you have to add float:left to? It's set manually in code
> to the outermost tab element, which is all that *should* be necessary.
>
>
>
Hi,
I ran into the same issue with IE7/8 using the css example you suggested
here:
http://groups.google.com/group/google-web-toolkit-contributors/browse_thread/thread/e9d6b9d7ad02b66f
but adding float:left to:
.gwt-TabLayoutPanelTab {
background: url(tab-inactive-left.png) no-repeat bottom left;
float:left;
}
solves the problem.
Alejandro.
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: JsDuplicateFunctionRemover
The code looks good, but I'd like to try it out before a final approval.
Can you repost a patch with the missing little bits fixed up?
http://gwt-code-reviews.appspot.com/126818/diff/1/2
File dev/core/src/com/google/gwt/dev/jjs/JavaToJavaScriptCompiler.java
(right):
http://gwt-code-reviews.appspot.com/126818/diff/1/2#newcode264
Line 264: options.getOutput(), symbolTable, propertyOracles);
Did you end up needing to change GenerateJavaScriptAST? If so, please
add it to the patch. However, it looks like this change could be
reverted.
http://gwt-code-reviews.appspot.com/126818/diff/1/2#newcode319
Line 319: JsStackEmulator.StackMode.STRIP &&
These are good helper methods but are missing from the patch.
http://gwt-code-reviews.appspot.com/126818/diff/1/3
File dev/core/src/com/google/gwt/dev/js/JsDuplicateFunctionRemover.java
(right):
http://gwt-code-reviews.appspot.com/126818/diff/1/3#newcode47
Line 47: public boolean visit(JsFunction x, JsContext ctx)
{
There should be a check for functions that have no name, shouldn't
there?
http://gwt-code-reviews.appspot.com/126818/diff/1/3#newcode51
Line 51: * TODO: if constructors ever inlined into seed functions,
revisit this
This TODO is a good point. To make it more helpful: (a) drop the "TODO"
from here, because there's nothing in particular planned to be done, and
(b) add a note on
GenerateJavaScriptAST.GenerateJavaScriptVisitor.generateSeedFuncAndPrototype
that any change there needs to be reflected over here.
http://gwt-code-reviews.appspot.com/126818
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] Re: StackLayoutPanel has no styles at all??
You're right, there is no notification to stack-header widgets of their
selection state. I'll make a note to add a standard way for them to be
notified of this.
As for standard CSS, with the current design (i.e., your own widget is the
only header element), there's nothing to add a default style to. Perhaps we
can find a way to add a default "wrapper" element to each stack header, but
such that the header widget still fills the space.
On Mon, Jan 4, 2010 at 11:06 AM, dflorey wrote:
> Correct me if I'm wrong but I found it quite hard to apply a
> "selected" style to the selected stack panel header.
> I came up with a workaround like this:
>
> StackLayoutPanel danielStackPanel = new StackLayoutPanel
> (Style.Unit.PX) {
> @Override
>public void showWidget(Widget widget) {
>// Find associated header (map) and apply "selected"
> style to header
>// Remove "selected" style from all other header widgets
>}
> }
> But for some reason that I don't remember (I tried that out
> yesterday...) it did not work. I guess the style order was interfering
> somehow...
>
> I really would prefer if some of the useful styles would be set by
> default.
>
> On Jan 4, 4:47 pm, Joel Webber wrote:
> > Coming up with a general structure for stack header widgets (a la
> > TabLayoutPanel tabs), such that you could achieve whatever style you
> like,
> > proved very difficult in practice. I basically punted and just allowed
> you
> > to add an arbitrary widget, which you can style however you like.
> >
> > I'm quite open to alternative structures that work more like tabs. The
> > problem I ran into is that you typically want a stack header to extend
> > vertically to cover the entire space between stacks. The layout system
> does
> > this automatically, but it is rather difficult to place the "content" of
> a
> > header wherever you want it.
> >
> >
> >
> > On Sun, Jan 3, 2010 at 1:41 PM, dflorey wrote:
> > > Maybe I'm dumb but I do not find any styles associated with the new
> > > StackLayoutPanel...
> > > And no methods to add click listeners etc.
> > > I'd expect the same styles as on StackPanel:
> >
> > > CSS Style Rules
> >
> > > .gwt-StackPanel { the panel itself }
> > > .gwt-StackPanel .gwt-StackPanelItem { unselected items }
> > > .gwt-StackPanel .gwt-StackPanelItem-selected { selected items }
> > > .gwt-StackPanel .gwt-StackPanelContent { the wrapper around the
> > > contents of the item }
> >
> > > I tried to set the primary name but no effect.
> >
> > > Any ideas?
> >
> > > --
> > >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: TabLayoutPanel not working on IE8
Which element did you have to add float:left to? It's set manually in code to the outermost tab element, which is all that *should* be necessary. On Mon, Jan 4, 2010 at 10:57 AM, dflorey wrote: > Very strange. I've added float:left to each tab explicitly and now it > is working. > I guess it may be useful to provide a working default style. > If you are interested I can post my funky rounded-border animated > webkit/firefox style ;-) > > On Jan 4, 4:37 pm, Joel Webber wrote: > > I assume we're talking about the TabLayoutPanel issue, where the > individual > > tabs are expanding to full width, and stacking up vertically. This > appears > > to be happening in both IE8 and IE7 modes. > > > > This doesn't seem to happen normally -- the code in TabLayoutPanel uses > > float:left to cause the tabs to stack up horizontally. This style > property > > seems to be intact in your app, so something else must be interfering > with > > it. Would you mind looking at it to see if perhaps there's another > property > > that might be confusing IE? If we can figure out what it is, there may be > a > > way to prevent it in the future. > > > > > > > > On Sun, Jan 3, 2010 at 12:47 PM, dflorey > wrote: > > > Yes. You can have a look at my current testpage at > > >http://www.floreysoft.net > > > It's just a bunch of new LayoutPanel with css styles only. > > > > > On Jan 3, 6:30 pm, John Tamplin wrote: > > > > On Sun, Jan 3, 2010 at 5:56 AM, dflorey > wrote: > > > > > - TabLayoutPanel is working fine on Chrome and Firefox but on IE8 > > > > > (didn't try other IE's) it is completely broken > > > > > > Are you in standards mode? Quirks mode is not supported with the new > > > layout > > > > panels on IE. > > > > > > -- > > > > 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 > -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: Comment on TroubleshootingOOPHM in google-web-toolkit
Comment by rda...@google.com: @yaoancheng: Sorry to hear that you're having troubles using the plugin. Here is some additional information that may help. Regarding #1, you can actually start two development mode sessions at the same time. What you need to do is modify the launch configuration so that the "Automatically Select an Unused Port" option is selected, and add the following argument to the Program Arguments section: -codeServerPort auto Regarding #2, you should see the Development Mode View in Eclipse, instead of the Development Mode Window. See http://code.google.com/eclipse/docs/running_and_debugging_2_0.html for a screenshot. If you want to see the request log information from Jetty, change the log level in the launch configuration to TRACE. Then, that information will show up. For #3, you can clear out the tree node by clicking on the icon with overlapping X's. That will clear the nodes for all terminated launches. As for #4, you are right. That is a feature that we'll add in a future version of GPE. If you want to use the plugin, and have the development mode window show up instead of Eclipse's development mode view, set the "USE_REMOTE_UI" environment variable FOR YOUR LAUNCH CONFIGURATION to the value "false". For more information: http://code.google.com/p/google-web-toolkit/wiki/TroubleshootingOOPHM -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] Re: Please add ClientBundle as optional parameter in each widget cstr
On Mon, Jan 4, 2010 at 11:24 AM, BobV wrote: > On Mon, Jan 4, 2010 at 11:17 AM, dflorey wrote: > > The only show stopper I see right is that Messages/Contacts are not > > yet part of the ClientBundle, so I came up with something like this > > (copy&paste from branch source): > > You can bridge them with a GwtCreateResource or add a new > ResourceGenerator type to ClientBundle that will make Messages / > Constants a first-class resource type. How hard would it be to allow a method returning some subtype of LocalizableResource in ClientBundle, and have the generated code just do GWT.create on it automatically? -- John A. Tamplin Software Engineer (GWT), Google -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] Re: Please add ClientBundle as optional parameter in each widget cstr
On Mon, Jan 4, 2010 at 11:17 AM, dflorey wrote: > The only show stopper I see right is that Messages/Contacts are not > yet part of the ClientBundle, so I came up with something like this > (copy&paste from branch source): You can bridge them with a GwtCreateResource or add a new ResourceGenerator type to ClientBundle that will make Messages / Constants a first-class resource type. -- Bob Vawter Google Web Toolkit Team -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: Please add ClientBundle as optional parameter in each widget cstr
If you are interested I've already done this for my table branch in
the incubator. It's a little bit outdated - I need to port the branch
to 2.0... :-(
The only show stopper I see right is that Messages/Contacts are not
yet part of the ClientBundle, so I came up with something like this
(copy&paste from branch source):
/**
* An {...@link ImageBundle} that provides images for {...@link
AbstractScrollTable}
* .
*/
public static interface Css extends CssResource {
/**
* Widget style name.
*
* @return the widget's style name
*/
@ClassName("gwt-ScrollTable")
String defaultStyleName();
String headerTable();
String dataTable();
String footerTable();
String headerWrapper();
String dataWrapper();
String footerWrapper();
}
/**
* Resources used.
*/
public interface ScrollTableStyle extends ClientBundle {
/**
* The css file.
*/
@Source("com/google/gwt/gen2/widgetbase/public/ScrollTable.css")
@NotStrict
Css css();
/**
* An image used to fill the available width.
*
* @return an image resource of this image
*/
@Source("scrollTableFillWidth.gif")
ImageResource scrollTableFillWidth();
/**
* An image indicating that a column is sorted in ascending order.
*
* @return an image resource of this image
*/
@Source("scrollTableAscending.gif")
ImageResource scrollTableAscending();
/**
* An image indicating a column is sorted in descending order.
*
* @return an image resource of this image
*/
@Source("scrollTableDescending.gif")
ImageResource scrollTableDescending();
@Source("headerBackground.png")
@ImageOptions(repeatStyle = RepeatStyle.Horizontal)
ImageResource headerBackground();
}
public interface ScrollTableMessages extends Messages {
@DefaultMessage("Shrink/Expand to fill visible area")
String shrinkExpandTooltip();
@DefaultMessage("Shows only dates that are equal")
String dateOperatorEqualTooltip();
@DefaultMessage("Shows only dates that not equal")
String dateOperatorUnequalTooltip();
@DefaultMessage("Show only dates before the given date")
String dateOperatorBeforeTooltip();
@DefaultMessage("Show only dates after the given date")
String dateOperatorAfterTooltip();
@DefaultMessage("Show only dates between the given dates")
String dateOperatorBetweenTooltip();
}
public interface ScrollTableResources {
ScrollTableStyle getStyle();
ScrollTableMessages getMessages();
}
On Jan 4, 4:28 pm, Joel Webber wrote:
> What John said. There are a few difficult design problems in doing this
> properly -- i.e., with no overhead for those just using plain CSS, nor for
> those using CssResource/ClientBundle "themes". I am confident the problem is
> soluble, though.
>
>
>
> On Mon, Jan 4, 2010 at 10:21 AM, John LaBanca wrote:
> > We definitely plan to use ClientBundles to provide default stylings for all
> > widgets, but we haven't really talked about how to go about doing that yet.
> > Ideally, we want to use ClientBundles without breaking apps that are
> > already using the existing CSS style themes.
>
> > We could add ClientBundles to all widgets to serve as a default style, and
> > we can also provide a DeferredBinding to an "Unstyled" ClientBundle for each
> > widget. If a user inherits one of the existing CSS style themes, the
> > Standard/Chrome/Dark.gwt.xml files will inherit the Unstyled deferred
> > binding, thus disabling the ClientBundles for backway compatibility.
>
> > Thanks,
> > John LaBanca
> > jlaba...@google.com
>
> > On Mon, Jan 4, 2010 at 10:04 AM, BobV wrote:
>
> >> On Sun, Jan 3, 2010 at 6:10 AM, dflorey wrote:
> >> > It would be great if the new ClientBundle would be used to style all
> >> > gwt widgets.
>
> >> I think John probably has some ideas here.
>
> >> > (btw: Why is it called ClientBundle and not ResourceBundle as it
> >> > bundles up different resources...)
>
> >> To avoid the conflict with java.util.ResourceBundle.
>
> >> --
> >> Bob Vawter
> >> Google Web Toolkit Team
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: StackLayoutPanel has no styles at all??
Correct me if I'm wrong but I found it quite hard to apply a
"selected" style to the selected stack panel header.
I came up with a workaround like this:
StackLayoutPanel danielStackPanel = new StackLayoutPanel
(Style.Unit.PX) {
@Override
public void showWidget(Widget widget) {
// Find associated header (map) and apply "selected"
style to header
// Remove "selected" style from all other header widgets
}
}
But for some reason that I don't remember (I tried that out
yesterday...) it did not work. I guess the style order was interfering
somehow...
I really would prefer if some of the useful styles would be set by
default.
On Jan 4, 4:47 pm, Joel Webber wrote:
> Coming up with a general structure for stack header widgets (a la
> TabLayoutPanel tabs), such that you could achieve whatever style you like,
> proved very difficult in practice. I basically punted and just allowed you
> to add an arbitrary widget, which you can style however you like.
>
> I'm quite open to alternative structures that work more like tabs. The
> problem I ran into is that you typically want a stack header to extend
> vertically to cover the entire space between stacks. The layout system does
> this automatically, but it is rather difficult to place the "content" of a
> header wherever you want it.
>
>
>
> On Sun, Jan 3, 2010 at 1:41 PM, dflorey wrote:
> > Maybe I'm dumb but I do not find any styles associated with the new
> > StackLayoutPanel...
> > And no methods to add click listeners etc.
> > I'd expect the same styles as on StackPanel:
>
> > CSS Style Rules
>
> > .gwt-StackPanel { the panel itself }
> > .gwt-StackPanel .gwt-StackPanelItem { unselected items }
> > .gwt-StackPanel .gwt-StackPanelItem-selected { selected items }
> > .gwt-StackPanel .gwt-StackPanelContent { the wrapper around the
> > contents of the item }
>
> > I tried to set the primary name but no effect.
>
> > Any ideas?
>
> > --
> >http://groups.google.com/group/Google-Web-Toolkit-Contributors
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: TabLayoutPanel not working on IE8
Very strange. I've added float:left to each tab explicitly and now it is working. I guess it may be useful to provide a working default style. If you are interested I can post my funky rounded-border animated webkit/firefox style ;-) On Jan 4, 4:37 pm, Joel Webber wrote: > I assume we're talking about the TabLayoutPanel issue, where the individual > tabs are expanding to full width, and stacking up vertically. This appears > to be happening in both IE8 and IE7 modes. > > This doesn't seem to happen normally -- the code in TabLayoutPanel uses > float:left to cause the tabs to stack up horizontally. This style property > seems to be intact in your app, so something else must be interfering with > it. Would you mind looking at it to see if perhaps there's another property > that might be confusing IE? If we can figure out what it is, there may be a > way to prevent it in the future. > > > > On Sun, Jan 3, 2010 at 12:47 PM, dflorey wrote: > > Yes. You can have a look at my current testpage at > >http://www.floreysoft.net > > It's just a bunch of new LayoutPanel with css styles only. > > > On Jan 3, 6:30 pm, John Tamplin wrote: > > > On Sun, Jan 3, 2010 at 5:56 AM, dflorey wrote: > > > > - TabLayoutPanel is working fine on Chrome and Firefox but on IE8 > > > > (didn't try other IE's) it is completely broken > > > > Are you in standards mode? Quirks mode is not supported with the new > > layout > > > panels on IE. > > > > -- > > > 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
Re: [gwt-contrib] StackLayoutPanel has no styles at all??
Coming up with a general structure for stack header widgets (a la
TabLayoutPanel tabs), such that you could achieve whatever style you like,
proved very difficult in practice. I basically punted and just allowed you
to add an arbitrary widget, which you can style however you like.
I'm quite open to alternative structures that work more like tabs. The
problem I ran into is that you typically want a stack header to extend
vertically to cover the entire space between stacks. The layout system does
this automatically, but it is rather difficult to place the "content" of a
header wherever you want it.
On Sun, Jan 3, 2010 at 1:41 PM, dflorey wrote:
> Maybe I'm dumb but I do not find any styles associated with the new
> StackLayoutPanel...
> And no methods to add click listeners etc.
> I'd expect the same styles as on StackPanel:
>
> CSS Style Rules
>
> .gwt-StackPanel { the panel itself }
> .gwt-StackPanel .gwt-StackPanelItem { unselected items }
> .gwt-StackPanel .gwt-StackPanelItem-selected { selected items }
> .gwt-StackPanel .gwt-StackPanelContent { the wrapper around the
> contents of the item }
>
> I tried to set the primary name but no effect.
>
> Any ideas?
>
> --
> http://groups.google.com/group/Google-Web-Toolkit-Contributors
>
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] Re: TabLayoutPanel not working on IE8
I assume we're talking about the TabLayoutPanel issue, where the individual tabs are expanding to full width, and stacking up vertically. This appears to be happening in both IE8 and IE7 modes. This doesn't seem to happen normally -- the code in TabLayoutPanel uses float:left to cause the tabs to stack up horizontally. This style property seems to be intact in your app, so something else must be interfering with it. Would you mind looking at it to see if perhaps there's another property that might be confusing IE? If we can figure out what it is, there may be a way to prevent it in the future. On Sun, Jan 3, 2010 at 12:47 PM, dflorey wrote: > Yes. You can have a look at my current testpage at > http://www.floreysoft.net > It's just a bunch of new LayoutPanel with css styles only. > > On Jan 3, 6:30 pm, John Tamplin wrote: > > On Sun, Jan 3, 2010 at 5:56 AM, dflorey wrote: > > > - TabLayoutPanel is working fine on Chrome and Firefox but on IE8 > > > (didn't try other IE's) it is completely broken > > > > Are you in standards mode? Quirks mode is not supported with the new > layout > > panels on IE. > > > > -- > > 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
Re: [gwt-contrib] Please add ClientBundle as optional parameter in each widget cstr
What John said. There are a few difficult design problems in doing this properly -- i.e., with no overhead for those just using plain CSS, nor for those using CssResource/ClientBundle "themes". I am confident the problem is soluble, though. On Mon, Jan 4, 2010 at 10:21 AM, John LaBanca wrote: > We definitely plan to use ClientBundles to provide default stylings for all > widgets, but we haven't really talked about how to go about doing that yet. > Ideally, we want to use ClientBundles without breaking apps that are > already using the existing CSS style themes. > > We could add ClientBundles to all widgets to serve as a default style, and > we can also provide a DeferredBinding to an "Unstyled" ClientBundle for each > widget. If a user inherits one of the existing CSS style themes, the > Standard/Chrome/Dark.gwt.xml files will inherit the Unstyled deferred > binding, thus disabling the ClientBundles for backway compatibility. > > Thanks, > John LaBanca > jlaba...@google.com > > > > On Mon, Jan 4, 2010 at 10:04 AM, BobV wrote: > >> On Sun, Jan 3, 2010 at 6:10 AM, dflorey wrote: >> > It would be great if the new ClientBundle would be used to style all >> > gwt widgets. >> >> I think John probably has some ideas here. >> >> > (btw: Why is it called ClientBundle and not ResourceBundle as it >> > bundles up different resources...) >> >> To avoid the conflict with java.util.ResourceBundle. >> >> -- >> Bob Vawter >> Google Web Toolkit Team >> > > -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] Please add ClientBundle as optional parameter in each widget cstr
We definitely plan to use ClientBundles to provide default stylings for all widgets, but we haven't really talked about how to go about doing that yet. Ideally, we want to use ClientBundles without breaking apps that are already using the existing CSS style themes. We could add ClientBundles to all widgets to serve as a default style, and we can also provide a DeferredBinding to an "Unstyled" ClientBundle for each widget. If a user inherits one of the existing CSS style themes, the Standard/Chrome/Dark.gwt.xml files will inherit the Unstyled deferred binding, thus disabling the ClientBundles for backway compatibility. Thanks, John LaBanca jlaba...@google.com On Mon, Jan 4, 2010 at 10:04 AM, BobV wrote: > On Sun, Jan 3, 2010 at 6:10 AM, dflorey wrote: > > It would be great if the new ClientBundle would be used to style all > > gwt widgets. > > I think John probably has some ideas here. > > > (btw: Why is it called ClientBundle and not ResourceBundle as it > > bundles up different resources...) > > To avoid the conflict with java.util.ResourceBundle. > > -- > Bob Vawter > Google Web Toolkit Team > -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] Re: Dev-Mode is not starting up, GWT compile works fine
On Mon, Jan 4, 2010 at 4:46 AM, dflorey wrote: > I've been running trunk but reverted back to 2.0 plugin. > If you have an updated trunk, you shouldn't have this problem. If you do, please let me know. -- John A. Tamplin Software Engineer (GWT), Google -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: Please add ClientBundle as optional parameter in each widget cstr
On Jan 4, 4:04 pm, BobV wrote: > On Sun, Jan 3, 2010 at 6:10 AM, dflorey wrote: > > It would be great if the new ClientBundle would be used to style all > > gwt widgets. > > I think John probably has some ideas here. > > > (btw: Why is it called ClientBundle and not ResourceBundle as it > > bundles up different resources...) > > To avoid the conflict with java.util.ResourceBundle. :-) > > -- > Bob Vawter > Google Web Toolkit Team -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] Please add ClientBundle as optional parameter in each widget cstr
On Sun, Jan 3, 2010 at 6:10 AM, dflorey wrote: > It would be great if the new ClientBundle would be used to style all > gwt widgets. I think John probably has some ideas here. > (btw: Why is it called ClientBundle and not ResourceBundle as it > bundles up different resources...) To avoid the conflict with java.util.ResourceBundle. -- Bob Vawter Google Web Toolkit Team -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: Comment on ImageResource in google-web-toolkit
Comment by osorioja...@gmail.com:
Hey guys! Thx for this great work!
Im not beeing able to link my imageresources with my widget (MVP).
ImageResource does not have applyTo() Method which i need...
http://www.gwtapps.com/doc/html/com.google.gwt.user.client.ui.AbstractImagePrototype.html
{{{
/**
* Transforms an existing {...@link Image} into the image represented by this
* prototype.
*
* @param image the instance to be transformed to match this prototype
*/
public abstract void applyTo(Image image);
}}}
For more information:
http://code.google.com/p/google-web-toolkit/wiki/ImageResource
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: Dev-Mode is not starting up, GWT compile works fine
I've been running trunk but reverted back to 2.0 plugin. On Jan 4, 9:47 am, John Tamplin wrote: > On Sun, Jan 3, 2010 at 1:02 PM, dflorey wrote: > > I had to remove all gwt dependencies from the run configuration and > > restore the defaults to get rid of this error. > > Just in case someone else struggles... > > What version are you running? That was added as an optimization for webmode > after 2.0 and reverted after it was discovered to cause problems in devmode. > > -- > John A. Tamplin > Software Engineer (GWT), Google -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] Re: Dev-Mode is not starting up, GWT compile works fine
On Sun, Jan 3, 2010 at 1:02 PM, dflorey wrote: > I had to remove all gwt dependencies from the run configuration and > restore the defaults to get rid of this error. > Just in case someone else struggles... What version are you running? That was added as an optimization for webmode after 2.0 and reverted after it was discovered to cause problems in devmode. -- John A. Tamplin Software Engineer (GWT), Google -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
