[gwt-contrib] Add a getter for XHR's responseType. (issue1830803)
Reviewers: jtamplin, cromwellian,
Message:
Follow-up to https://gwt-code-reviews.appspot.com/1820806
See http://code.google.com/p/google-web-toolkit/issues/detail?id=7386#c8
Description:
Add a getter for XHR's responseType.
Issue 7386
Please review this at https://gwt-code-reviews.appspot.com/1830803/
Affected files:
M user/src/com/google/gwt/xhr/client/XMLHttpRequest.java
Index: user/src/com/google/gwt/xhr/client/XMLHttpRequest.java
diff --git a/user/src/com/google/gwt/xhr/client/XMLHttpRequest.java
b/user/src/com/google/gwt/xhr/client/XMLHttpRequest.java
index
d35d1964cb30c4a3f1c895bdce2db50665f3e32f..aedb80697b26f086391ef305c24a0571c05855bc
100644
--- a/user/src/com/google/gwt/xhr/client/XMLHttpRequest.java
+++ b/user/src/com/google/gwt/xhr/client/XMLHttpRequest.java
@@ -162,8 +162,8 @@ public class XMLHttpRequest extends JavaScriptObject {
/**
* Aborts the current request.
* p
- * See a href=http://www.w3.org/TR/XMLHttpRequest/#abort;
- * http://www.w3.org/TR/XMLHttpRequest/#abort/a.
+ * See a href=http://www.w3.org/TR/XMLHttpRequest/#the-abort-method;
+ * http://www.w3.org/TR/XMLHttpRequest/#the-abort-method/a.
*/
public final native void abort() /*-{
this.abort();
@@ -172,8 +172,8 @@ public class XMLHttpRequest extends JavaScriptObject {
/**
* Clears the {@link ReadyStateChangeHandler}.
* p
- * See a href=http://www.w3.org/TR/XMLHttpRequest/#onreadystatechange;
- * http://www.w3.org/TR/XMLHttpRequest/#onreadystatechange/a.
+ * See a
href=http://www.w3.org/TR/XMLHttpRequest/#handler-xhr-onreadystatechange;
+ *
http://www.w3.org/TR/XMLHttpRequest/#handler-xhr-onreadystatechange/a.
*
* @see #clearOnReadyStateChange()
*/
@@ -189,8 +189,8 @@ public class XMLHttpRequest extends JavaScriptObject {
/**
* Gets all the HTTP response headers, as a single string.
* p
- * See a
href=http://www.w3.org/TR/XMLHttpRequest/#getallresponseheaders;
- * http://www.w3.org/TR/XMLHttpRequest/#getallresponseheaders/a.
+ * See a
href=http://www.w3.org/TR/XMLHttpRequest/#the-getallresponseheaders-method;
+ *
http://www.w3.org/TR/XMLHttpRequest/#the-getallresponseheaders-method/a.
*
* @return the response headers.
*/
@@ -201,8 +201,8 @@ public class XMLHttpRequest extends JavaScriptObject {
/**
* Get's the current ready-state.
* p
- * See a href=http://www.w3.org/TR/XMLHttpRequest/#readystate;
- * http://www.w3.org/TR/XMLHttpRequest/#readystate/a.
+ * See a
href=http://www.w3.org/TR/XMLHttpRequest/#dom-xmlhttprequest-readystate;
+ * http://www.w3.org/TR/XMLHttpRequest/#dom-xmlhttprequest-state/a.
*
* @return the ready-state constant
*/
@@ -223,8 +223,8 @@ public class XMLHttpRequest extends JavaScriptObject {
/**
* Gets an HTTP response header.
* p
- * See a href=http://www.w3.org/TR/XMLHttpRequest/#getresponseheader;
- * http://www.w3.org/TR/XMLHttpRequest/#getresponseheader/a.
+ * See a
href=http://www.w3.org/TR/XMLHttpRequest/#the-getresponseheader-method;
+ *
http://www.w3.org/TR/XMLHttpRequest/#the-getresponseheader-method/a.
*
* @param header the response header to be retrieved
* @return the header value
@@ -236,8 +236,8 @@ public class XMLHttpRequest extends JavaScriptObject {
/**
* Gets the response text.
* p
- * See a href=http://www.w3.org/TR/XMLHttpRequest/#responsetext;
- * http://www.w3.org/TR/XMLHttpRequest/#responsetext/a.
+ * See a
href=http://www.w3.org/TR/XMLHttpRequest/#the-responsetext-attribute;
+ * http://www.w3.org/TR/XMLHttpRequest/#the-responsetext-attribute/a.
*
* @return the response text
*/
@@ -246,10 +246,22 @@ public class XMLHttpRequest extends JavaScriptObject {
}-*/;
/**
+ * Gets the response type.
+ * p
+ * See a
href=http://www.w3.org/TR/XMLHttpRequest/#the-responsetype-attribute;
+ * http://www.w3.org/TR/XMLHttpRequest/#the-responsetype-attribute/a
+ *
+ * @return the response type
+ */
+ public final native String getResponseType() /*-{
+return this.responseType || ;
+ }-*/;
+
+ /**
* Gets the status code.
* p
- * See a href=http://www.w3.org/TR/XMLHttpRequest/#status;
- * http://www.w3.org/TR/XMLHttpRequest/#status/a.
+ * See a
href=http://www.w3.org/TR/XMLHttpRequest/#the-status-attribute;
+ * http://www.w3.org/TR/XMLHttpRequest/#the-status-attribute/a.
*
* @return the status code
*/
@@ -260,8 +272,8 @@ public class XMLHttpRequest extends JavaScriptObject {
/**
* Gets the status text.
* p
- * See a href=http://www.w3.org/TR/XMLHttpRequest/#statustext;
- * http://www.w3.org/TR/XMLHttpRequest/#statustext/a.
+ * See a
href=http://www.w3.org/TR/XMLHttpRequest/#the-statustext-attribute;
+ * http://www.w3.org/TR/XMLHttpRequest/#the-statustext-attribute/a.
*
* @return the status text
*/
@@ -272,8 +284,8 @@ public class XMLHttpRequest extends JavaScriptObject {
/**
*
[gwt-contrib] Re: Update Maven sample pom.xml files to use maven-compiler-plugin's annotation processing functiona... (issue1828803)
http://gwt-code-reviews.appspot.com/1828803/diff/1/samples/dynatablerf/pom.xml File samples/dynatablerf/pom.xml (right): http://gwt-code-reviews.appspot.com/1828803/diff/1/samples/dynatablerf/pom.xml#newcode55 samples/dynatablerf/pom.xml:55: !-- Doesn't yet work in eclipse. See maven-processor-plugin below. This dependency is no longer needed (and the comment wrong) http://gwt-code-reviews.appspot.com/1828803/diff/1/samples/dynatablerf/pom.xml#newcode110 samples/dynatablerf/pom.xml:110: source1.6/source Those tabs should be spaces. http://gwt-code-reviews.appspot.com/1828803/diff/1/samples/dynatablerf/pom.xml#newcode128 samples/dynatablerf/pom.xml:128: version2.3.0-1/version Latest version is 2.5.0-rc1, which depends on GWT 2.5.0-rc1 (so the plugin dependencies below are no longer needed; FYI, it also removes the unneeded dependency on gwt-servlet) FYI, I'll publish 2.5.0-rc2 as soon as GWT 2.5 RC2 is out, and similarly for the final release. All in all, I'd keep the plugin dependencies in (minus gwt-servlet), as it's unlikely gwt-maven-plugin 2.5.0-rc2 is released on the same week as GWT 2.5 RC2, making it impossible to bump gwtVersion in time for the GWT release (there would be a version mismatch between the project dependencies and the plugin dependencies) or making the samples unusable for a few days (in case both versions are changed, in prevision to the gwt-maven-plugin release). In the long term, I'd like the gwt-maven-plugin to be adopted (rewritten?) by the GWT project, but that's another story ;-) http://gwt-code-reviews.appspot.com/1828803/diff/1/samples/dynatablerf/pom.xml#newcode193 samples/dynatablerf/pom.xml:193: !-- Mark the project for Google Plugin for Eclipse (GPE) -- Is this still needed? Isn't the GPE smart enough? (I thought it'd automatically add the nature and build command upon detecting the use of the gwt-maven-plugin and/or gwt-user dependency) http://gwt-code-reviews.appspot.com/1828803/ -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: Add a getter for XHR's responseType. (issue1830803)
LGTM Did you test it? It probably needs testing on IE6 if GWT still officially supports it, since I recall some weirdness about getting exceptions if you referenced properties that didn't exist on native objects that were exposed to JS. https://gwt-code-reviews.appspot.com/1830803/ -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: Add a getter for XHR's responseType. (issue1830803)
On 2012/09/12 14:32:37, jtamplin wrote: Did you test it? It probably needs testing on IE6 if GWT still officially supports it, since I recall some weirdness about getting exceptions if you referenced properties that didn't exist on native objects that were exposed to JS. Just ran the following http://jsfiddle.net/m3Saz/ in IE6. It prints undefined on getting and throws on setting. BTW, in this test, both Firefox 15 and Aurora (16) are failing when setting to arraybuffer: Error setting to 'arraybuffer': [Exception... An attempt was made to use an object that is not, or is no longer, usable code: 11 nsresult: 0x8053000b (InvalidStateError) location: http://fiddle.jshell.net/m3Saz/show/ Line: 45] It's works when setting to dummy though (and returns the empty string). It works if I call xhr.open() before trying to set the responseType, which means the XMLHttpRequest API we chose (create(ResponseType)) is not going to work in Firefox (this is a bug in Firefox though, the spec says it should work, but still). So maybe we need a setter instead of (or in addition to) an argument create() ? Chrome (23-dev) is OK (printing the empty string, then arraybuffer and arraybuffer) I'll try on IE7, IE8 and IE9 next (currently downloading the VMs from the MSDN). https://gwt-code-reviews.appspot.com/1830803/ -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: Add a getter for XHR's responseType. (issue1830803)
On 2012/09/12 16:03:13, tbroyer wrote: I'll try on IE7, IE8 and IE9 next (currently downloading the VMs from the MSDN). Results from https://browserlab.adobe.com IE7, IE8 and IE9: works as an expando (no error; prints undefined, arraybuffer, dummy) Chrome 18 / Windows: throws on setting to dummy, otherwise OK Safari 5.1 / OSX: expando (undefined, arraybuffer, dummy) Firefox 11 (Windows / OSX): throws on setting (probably the same bug as in FF15 and Aurora but they also throw when setting to dummy, haven't tried with open() though) https://gwt-code-reviews.appspot.com/1830803/ -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: - Extended the a11y role API with methods that have UIObject parameter. (issue1828804)
I haven't looked at the changes (from the description, they should be simple and straightforward) but what bothers me is that it introduces a cyclic dependency: c.g.g.user depends on c.g.g.aria which now also depends on c.g.g.user. Also, that dependency isn't reflected in the .gwt.xml (so one could say it's not really a cyclic dependency, but then you'll have source code not found for UIObject if you don't use c.g.g.user in your app). I think we should rather introduce an HasElement interface (e.g. in c.g.g.dom) that UIObject would implement. http://gwt-code-reviews.appspot.com/1828804/ -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: - Extended the a11y role API with methods that have UIObject parameter. (issue1828804)
We've decided against this change for now (increases the size of the API too much). A HasElement interface sounds somewhat reasonable but we can add that later if needed. I suppose if Element implemented HasElement, returning itself, we could avoid doubling the number of methods, but this seems overly tricky when calling getElement() yourself isn't hard. http://gwt-code-reviews.appspot.com/1828804/ -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: - Extended the a11y role API with methods that have UIObject parameter. (issue1828804)
On 2012/09/12 19:18:12, skybrian wrote: We've decided against this change for now (increases the size of the API too much). A HasElement interface sounds somewhat reasonable but we can add that later if needed. I suppose if Element implemented HasElement, returning itself, we could avoid doubling the number of methods, but this seems overly tricky when calling getElement() yourself isn't hard. Plus: some widgets already have ARIA roles. So maybe a better long-term solution would be to add methods on generic widgets to allow one to set a role for it (e.g. setWidgetRole(Widget, Role) on DockLayoutPanel, setRole(Role) on SimplePanel, etc.), so that those widgets with already-specified roles (e.g. Tree/CellTree, CellTable, TabPanel, etc.) cannot be given a new role without some trickery (at the very least a call to getElement(), which is a generally-understood signal that from now one, if something break, blame yourself). http://gwt-code-reviews.appspot.com/1828804/ -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: Add a getter for XHR's responseType. (issue1830803)
Hmm, I'm inclined to skip this patch for GWT 2.5. The typo fix at least makes it work on some browsers... https://gwt-code-reviews.appspot.com/1830803/ -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: Add a getter for XHR's responseType. (issue1830803)
On 2012/09/12 20:47:20, skybrian wrote: Hmm, I'm inclined to skip this patch for GWT 2.5. The typo fix at least makes it work on some browsers... If I understand Thomas' test results, the getter works properly everywhere -- it is the existing setter which fails on FF11+. So, this patch doesn't add anything broken, but you can 't actually use any non-default response type on FF+ even with what is in trunk now. I think we don't want to screw up the API just to deal with a non-compliant browser -- making a setter would require the callers to set it after the fact (and it seems like it would be a race condition if the reply comes back before you set it). Is there a FF bug for this? https://gwt-code-reviews.appspot.com/1830803/ -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: Update Maven sample pom.xml files to use maven-compiler-plugin's annotation processing functiona... (issue1828803)
http://gwt-code-reviews.appspot.com/1828803/ -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: Move GAE Auth functionality from Expenses over the MobileWebApp sample. (issue1829803)
On 2012/09/12 22:50:12, rdayal wrote: Ping...I'd like to get this into 2.5. http://gwt-code-reviews.appspot.com/1829803/ -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] GWT 2.5 RC1 increases mgwt showcase by 22%
Hi Ray, hi John,
I haven`t had the time to track down why this got optimized in 2.4 but does not
in 2.5 anymore. We are seeing huge gains on many different mgwt apps with GWT
2.5.
@John
With mobile browsers you get a lot of small inconsistencies across many
different places. I initially went ahead and build an interface with different
implementations and used deferred binding in the gwt.xml file.
The problem was the amount of overhead you had to do for a simple one liner. So
I went ahead and used a Generator to build an interface that is based on a
property provider. The interface basically just returns true or false.
All the stuff used to compile out in gwt 2.2 so we could do something like:
if(MGWT.getIsDetection().isIphone()){
//do some small workaround
}
So right now we have a lot of places where we use those one liners to fix
things. (we also use a lot of deferred binding as well).
@Ray
I am really interested in knowing why this used to work and right now it
doesn't.
I just went ahead and changed the code inside the client bundle to cache an
instance of OsDetection to get around the clinit.
OsDetection detection = MGWT.getOsDetection();
if (detection.isAndroidPhone()) {
bundle = GWT.create(MGWTClientBundleBaseThemeAndroid.class);
}
if (detection.isAndroidTablet()) {
bundle = GWT.create(MGWTClientBundleBaseThemeAndroidTablet.class);
}
This actually dropped code size of more than 29%. I think we got a lot of
places still being affected by this change, but at this point I can go through
the codebase and apply the workaround or even decide to bite some bullets on
more direct deferred binding. The thing I am still wondering about what broke
that we do see this problem now. I could offer some work time to go and build
every version between GWT 2.5rc1 and GWT 2.4 to get a better feeling for what
the actual commit is and if this is something we need to look further?! What do
you think?
-Daniel
Am 12.09.2012 um 00:03 schrieb Ray Cromwell cromwell...@google.com:
I finally tracked this down, it appears Android client bundles are not
being optimized out of the Iphone build, for example. This code:
public MGWTThemeBaseThemeStandardImpl() {
if (MGWT.getOsDetection().isAndroidPhone()) {
bundle =
GWT.create(MGWTClientBundleBaseThemeAndroid.class);
}
if (MGWT.getOsDetection().isAndroidTablet()) {
bundle =
GWT.create(MGWTClientBundleBaseThemeAndroidTablet.class);
}
if (MGWT.getOsDetection().isIPhone()) {
if (MGWT.getOsDetection().isRetina()) {
bundle =
GWT.create(MGWTClientBundleBaseThemeRetina.class);
} else {
bundle =
GWT.create(MGWTClientBundleBaseThemeIPhone.class);
}
}
if (MGWT.getOsDetection().isIPad()) {
if (MGWT.getOsDetection().isIPadRetina()) {
bundle =
GWT.create(MGWTClientBundleBaseThemeIPadRetina.class);
} else {
bundle =
GWT.create(MGWTClientBundleBaseThemeIPad.class);
}
}
...
}
on GWT 2.5 is optimized into:
function MGWTThemeBaseThemeStandardImpl_0(){
($clinit_MGWT() , false) (this.bundle = new
MGWTClientBundleBaseThemeAndroid_iphone_safari_default_InlineClientBundleGenerator_0);
this.bundle = new
MGWTClientBundleBaseThemeIPhone_iphone_safari_default_InlineClientBundleGenerator_0;
}
This is essentially if(false) { android bundle}
I'm a little perplexed since the compiler has never really optimized
stuff like (clinit(), boolean) blah, since it would need to hoist
the clinit() out of there which it doesn't do yet. I probably won't be
able to fix this for 2.5, but one workaround is to inline the
GWT.create(OsDetection) into the bundle theme and avoid calling MGWT
(which has a non-empty clinit)
On Sun, Jul 29, 2012 at 8:16 AM, Daniel Kurka kurka.dan...@gmail.com wrote:
I didn't have the time yet to build a test case without mgwt put here is a
very basic entry point.
Compiled with GWT 2.4 its around 30k with GWT 2.5-rc its 45k (many styles
not being removed):
I have attached an entrypoint which can be run with the latest mgwt jar in
the classpath:
https://oss.sonatype.org/service/local/artifact/maven/redirect?r=snapshotsg=com.googlecode.mgwta=mgwte=jarv=LATEST
inherits name=com.googlecode.mgwt.MGWT /
Let me know if you need more input.
-Daniel
2012/7/23 Daniel Kurka kurka.dan...@gmail.com
We are not using any cell widgets (we wrote our own for mgwt, because the
current ones don work for mobile).
I already have a good guess where this might be coming from. I'll try to
provide a decent test case for it (without mgwt
Re: [gwt-contrib] submit chrome dev mode plugin to chrome web store?
Hi Rajeev, what is the status here? Can I help? -Daniel Am 19.08.2012 um 17:10 schrieb Robert Hanson iamroberthan...@gmail.com: @Rajeev, you mentioned that you were going to post the plugin to the Chrome store. Is that still the plan, or did you run into some issues there? I'm working on some documentation that is about to go to press, and just want to make sure I have the right instructions in there. Thanks. Rob On Tue, Aug 7, 2012 at 11:39 AM, Rajeev Dayal rda...@google.com wrote: Hey Daniel, We do need to post the chrome devmode plugin to the webstore. I'll take care of that this week. I also need to rebuild the devmode plugin, as there were some fixes that went into it a while back that were never put into a distributable binary. Rajeev On Mon, Aug 6, 2012 at 6:53 PM, Istvan Soos is...@google.com wrote: Hi, A quick fix that might help: 1. right click on the chrome iconPropertiesShortcut 2. add in target: --enable-easy-off-store-extension-install 3. open chrome and navitage to extensions ( chrome://chrome/extensions/ ) 4. drag and drop on it the plugin (should be in your download folder if you tried to install it before and didn't succeed) Regards, Istvan On Mon, Aug 6, 2012 at 12:44 PM, Daniel Kurka kurka.dan...@gmail.com wrote: Hi everyone, today at work I was setting up a GWT installation on windows for a new coworker and noticed that with chrome 21 we can not install extension anymore. (They need to be in the chrome web store). I also noticed an issue popping up on the issue tracker on the exact same thing: http://code.google.com/p/google-web-toolkit/issues/detail?id=7569 Does anyone have this covered or are we just hearing about this change to chrome right now? -Daniel -- http://groups.google.com/group/Google-Web-Toolkit-Contributors -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] submit chrome dev mode plugin to chrome web store?
Sorry, this totally fell off the plate. Daniel, would you be able to submit it to the Chrome Webstore? On Wed, Sep 12, 2012 at 7:07 PM, Daniel Kurka kurka.dan...@gmail.comwrote: Hi Rajeev, what is the status here? Can I help? -Daniel Am 19.08.2012 um 17:10 schrieb Robert Hanson iamroberthan...@gmail.com: @Rajeev, you mentioned that you were going to post the plugin to the Chrome store. Is that still the plan, or did you run into some issues there? I'm working on some documentation that is about to go to press, and just want to make sure I have the right instructions in there. Thanks. Rob On Tue, Aug 7, 2012 at 11:39 AM, Rajeev Dayal rda...@google.com wrote: Hey Daniel, We do need to post the chrome devmode plugin to the webstore. I'll take care of that this week. I also need to rebuild the devmode plugin, as there were some fixes that went into it a while back that were never put into a distributable binary. Rajeev On Mon, Aug 6, 2012 at 6:53 PM, Istvan Soos is...@google.com wrote: Hi, A quick fix that might help: 1. right click on the chrome iconPropertiesShortcut 2. add in target: --enable-easy-off-store-extension-install 3. open chrome and navitage to extensions ( chrome://chrome/extensions/) 4. drag and drop on it the plugin (should be in your download folder if you tried to install it before and didn't succeed) Regards, Istvan On Mon, Aug 6, 2012 at 12:44 PM, Daniel Kurka kurka.dan...@gmail.com wrote: Hi everyone, today at work I was setting up a GWT installation on windows for a new coworker and noticed that with chrome 21 we can not install extension anymore. (They need to be in the chrome web store). I also noticed an issue popping up on the issue tracker on the exact same thing: http://code.google.com/p/google-web-toolkit/issues/detail?id=7569 Does anyone have this covered or are we just hearing about this change to chrome right now? -Daniel -- http://groups.google.com/group/Google-Web-Toolkit-Contributors -- http://groups.google.com/group/Google-Web-Toolkit-Contributors -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] GWT 2.5 RC1 increases mgwt showcase by 22%
I'm bogged down at the moment, but when I get free time, I can
probably figure this out via -Dgwt.jjs.traceMethod on the client
bundle in question. Probably will have to wait a few days.
On Wed, Sep 12, 2012 at 4:04 PM, Daniel Kurka kurka.dan...@gmail.com wrote:
Hi Ray, hi John,
I haven`t had the time to track down why this got optimized in 2.4 but does
not in 2.5 anymore. We are seeing huge gains on many different mgwt apps with
GWT 2.5.
@John
With mobile browsers you get a lot of small inconsistencies across many
different places. I initially went ahead and build an interface with
different implementations and used deferred binding in the gwt.xml file.
The problem was the amount of overhead you had to do for a simple one liner.
So I went ahead and used a Generator to build an interface that is based on a
property provider. The interface basically just returns true or false.
All the stuff used to compile out in gwt 2.2 so we could do something like:
if(MGWT.getIsDetection().isIphone()){
//do some small workaround
}
So right now we have a lot of places where we use those one liners to fix
things. (we also use a lot of deferred binding as well).
@Ray
I am really interested in knowing why this used to work and right now it
doesn't.
I just went ahead and changed the code inside the client bundle to cache an
instance of OsDetection to get around the clinit.
OsDetection detection = MGWT.getOsDetection();
if (detection.isAndroidPhone()) {
bundle = GWT.create(MGWTClientBundleBaseThemeAndroid.class);
}
if (detection.isAndroidTablet()) {
bundle = GWT.create(MGWTClientBundleBaseThemeAndroidTablet.class);
}
This actually dropped code size of more than 29%. I think we got a lot of
places still being affected by this change, but at this point I can go
through the codebase and apply the workaround or even decide to bite some
bullets on more direct deferred binding. The thing I am still wondering about
what broke that we do see this problem now. I could offer some work time to
go and build every version between GWT 2.5rc1 and GWT 2.4 to get a better
feeling for what the actual commit is and if this is something we need to
look further?! What do you think?
-Daniel
Am 12.09.2012 um 00:03 schrieb Ray Cromwell cromwell...@google.com:
I finally tracked this down, it appears Android client bundles are not
being optimized out of the Iphone build, for example. This code:
public MGWTThemeBaseThemeStandardImpl() {
if (MGWT.getOsDetection().isAndroidPhone()) {
bundle =
GWT.create(MGWTClientBundleBaseThemeAndroid.class);
}
if (MGWT.getOsDetection().isAndroidTablet()) {
bundle =
GWT.create(MGWTClientBundleBaseThemeAndroidTablet.class);
}
if (MGWT.getOsDetection().isIPhone()) {
if (MGWT.getOsDetection().isRetina()) {
bundle =
GWT.create(MGWTClientBundleBaseThemeRetina.class);
} else {
bundle =
GWT.create(MGWTClientBundleBaseThemeIPhone.class);
}
}
if (MGWT.getOsDetection().isIPad()) {
if (MGWT.getOsDetection().isIPadRetina()) {
bundle =
GWT.create(MGWTClientBundleBaseThemeIPadRetina.class);
} else {
bundle =
GWT.create(MGWTClientBundleBaseThemeIPad.class);
}
}
...
}
on GWT 2.5 is optimized into:
function MGWTThemeBaseThemeStandardImpl_0(){
($clinit_MGWT() , false) (this.bundle = new
MGWTClientBundleBaseThemeAndroid_iphone_safari_default_InlineClientBundleGenerator_0);
this.bundle = new
MGWTClientBundleBaseThemeIPhone_iphone_safari_default_InlineClientBundleGenerator_0;
}
This is essentially if(false) { android bundle}
I'm a little perplexed since the compiler has never really optimized
stuff like (clinit(), boolean) blah, since it would need to hoist
the clinit() out of there which it doesn't do yet. I probably won't be
able to fix this for 2.5, but one workaround is to inline the
GWT.create(OsDetection) into the bundle theme and avoid calling MGWT
(which has a non-empty clinit)
On Sun, Jul 29, 2012 at 8:16 AM, Daniel Kurka kurka.dan...@gmail.com wrote:
I didn't have the time yet to build a test case without mgwt put here is a
very basic entry point.
Compiled with GWT 2.4 its around 30k with GWT 2.5-rc its 45k (many styles
not being removed):
I have attached an entrypoint which can be run with the latest mgwt jar in
the classpath:
https://oss.sonatype.org/service/local/artifact/maven/redirect?r=snapshotsg=com.googlecode.mgwta=mgwte=jarv=LATEST
inherits name=com.googlecode.mgwt.MGWT /
Let me know if you need more input.
-Daniel
Re: [gwt-contrib] submit chrome dev mode plugin to chrome web store?
Hi Rajeev, I just gave it a try and it seems that we need to do some actual changes to make this work. The chrome web store is complaining about the manifest version of the plugin: An error occurred: Manifest version 1 is unsupported. Please upgrade to manifest version 2. I will give this another look tomorrow. It`s getting too late in Germany right now. -Daniel Am 13.09.2012 um 01:09 schrieb Rajeev Dayal rda...@google.com: Sorry, this totally fell off the plate. Daniel, would you be able to submit it to the Chrome Webstore? On Wed, Sep 12, 2012 at 7:07 PM, Daniel Kurka kurka.dan...@gmail.com wrote: Hi Rajeev, what is the status here? Can I help? -Daniel Am 19.08.2012 um 17:10 schrieb Robert Hanson iamroberthan...@gmail.com: @Rajeev, you mentioned that you were going to post the plugin to the Chrome store. Is that still the plan, or did you run into some issues there? I'm working on some documentation that is about to go to press, and just want to make sure I have the right instructions in there. Thanks. Rob On Tue, Aug 7, 2012 at 11:39 AM, Rajeev Dayal rda...@google.com wrote: Hey Daniel, We do need to post the chrome devmode plugin to the webstore. I'll take care of that this week. I also need to rebuild the devmode plugin, as there were some fixes that went into it a while back that were never put into a distributable binary. Rajeev On Mon, Aug 6, 2012 at 6:53 PM, Istvan Soos is...@google.com wrote: Hi, A quick fix that might help: 1. right click on the chrome iconPropertiesShortcut 2. add in target: --enable-easy-off-store-extension-install 3. open chrome and navitage to extensions ( chrome://chrome/extensions/ ) 4. drag and drop on it the plugin (should be in your download folder if you tried to install it before and didn't succeed) Regards, Istvan On Mon, Aug 6, 2012 at 12:44 PM, Daniel Kurka kurka.dan...@gmail.com wrote: Hi everyone, today at work I was setting up a GWT installation on windows for a new coworker and noticed that with chrome 21 we can not install extension anymore. (They need to be in the chrome web store). I also noticed an issue popping up on the issue tracker on the exact same thing: http://code.google.com/p/google-web-toolkit/issues/detail?id=7569 Does anyone have this covered or are we just hearing about this change to chrome right now? -Daniel -- http://groups.google.com/group/Google-Web-Toolkit-Contributors -- http://groups.google.com/group/Google-Web-Toolkit-Contributors -- http://groups.google.com/group/Google-Web-Toolkit-Contributors -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Deprecating DeRPC classes
https://developers.google.com/web-toolkit/doc/latest/DevGuideServerCommunication#DevGuideDeRPC says about Direct-Eval RPC: This feature did not work out as planned, and the GWT team strongly discourages its use. However, the classes RpcServlet, RpcService etc. are not marked as deprecated. It's easy to mistype RemoteService as RpcService, which doesn't cause any warning. If this happens, it can be very difficult to spot the problem, and it's not trivial to revert to RemoteService, see for example: http://code.google.com/p/google-web-toolkit/source/diff?spec=svn11258r=11229format=sidepath=/trunk/samples/validation/src/main/java/com/google/gwt/sample/validation/client/GreetingService.javaold_path=/trunk/samples/validation/src/main/java/com/google/gwt/sample/validation/client/GreetingService.javaold=10642 -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: - Extended the a11y role API with methods that have UIObject parameter. (issue1828804)
Hmm. If it were named HasAriaElement, then it would make sense that not all widgets implement it. Only those that need to be customized for proper Aria support would have it. http://gwt-code-reviews.appspot.com/1828804/ -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
