[gwt-contrib] Original GWT Logo Assets
Thomas Broyer reached out to get vector versions of the original GWT Logo so I'm going to just throw my copies into the community before they are lost. As far as I remember, these logos were originally created by Michael Lopez in 2006. I'm pretty confident that the illustrator file I have is the final iteration. I've uploaded the logo to my Dropbox and exported it to a few common formats (unfortunately the SVG version does have some issues). Illustrator (original) http://dl.dropbox.com/u/4920373/gwt-logo/gwt-logo.ai PDF http://dl.dropbox.com/u/4920373/gwt-logo/gwt-logo.pdf PNG (1000x940) http://dl.dropbox.com/u/4920373/gwt-logo/gwt-logo.png SVG (This is a failed attempt to use Inkscape to convert from PDF. The entire left side of the box did not survive the process. I home someone more familiar with the inner workings of Inkscape can get a better SVG version) http://dl.dropbox.com/u/4920373/gwt-logo/gwt-logo.svgz -- -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- You received this message because you are subscribed to the Google Groups Google Web Toolkit Contributors group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[gwt-contrib] Re: Change the DevModeOptions page to use the xs linker due to recent Chrome extension permissions c... (issue1356803)
xsiframe is fine if it works. But you'll have to check it because these are not the normal xs restrictions. On Tue, Feb 15, 2011 at 4:28 PM, Unnur Gretarsdottir unn...@google.comwrote: All google3 projects are being switched to xsiframe in a few weeks (currently blocked by lack of a Blaze push). Deprecation/deletions of other linkers for regular GWT will soon follow, but to be honest, will be a GWT 3.0 thing at the very earliest. It's not a burning issue, but I do recommend that you do not switch to the xs linker at this point. It doesn't install in an iframe, and switching from being iframe installed vs. not has proven painful for some teams. Right now - if you're using the std linker (default), your compliant with being installed in an iframe, so if you start using xs, pick up some code dependencies that assume non-iframe, and then need to switch back to iframe based (xsiframe), you may see some issues. Or maybe not It's also possible that xs does not support DevMode - I can't remember off the top of my head. If you care about that, then xsiframe definitely does support it. - Unnur On Tue, Feb 15, 2011 at 1:09 PM, John Tamplin j...@google.com wrote: On Tue, Feb 15, 2011 at 4:03 PM, Chris Conroy con...@google.com wrote: Sorry, didn't see your comment in time for the commit. I just used the same fix Kelly applied in SpeedTracer. I don't think it really matters strongly either way. As I understand it, the xs linker will soon be deprecated since the xsiframe linker provides a superset of its functionality. -- John A. Tamplin Software Engineer (GWT), Google -- 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: Change the DevModeOptions page to use the xs linker due to recent Chrome extension permissions c... (issue1356803)
Awesome. good to know. I need to figure out how it manages to work. On Tue, Feb 15, 2011 at 4:52 PM, Chris Conroy con...@google.com wrote: Actually, it does work. On Tue, Feb 15, 2011 at 4:49 PM, Kelly Norton knor...@google.com wrote: I could be wrong, but I don't think the xsiframe linker is going to work here. On Tue, Feb 15, 2011 at 4:46 PM, Kelly Norton knor...@google.com wrote: xsiframe is fine if it works. But you'll have to check it because these are not the normal xs restrictions. On Tue, Feb 15, 2011 at 4:28 PM, Unnur Gretarsdottir unn...@google.com wrote: All google3 projects are being switched to xsiframe in a few weeks (currently blocked by lack of a Blaze push). Deprecation/deletions of other linkers for regular GWT will soon follow, but to be honest, will be a GWT 3.0 thing at the very earliest. It's not a burning issue, but I do recommend that you do not switch to the xs linker at this point. It doesn't install in an iframe, and switching from being iframe installed vs. not has proven painful for some teams. Right now - if you're using the std linker (default), your compliant with being installed in an iframe, so if you start using xs, pick up some code dependencies that assume non-iframe, and then need to switch back to iframe based (xsiframe), you may see some issues. Or maybe not It's also possible that xs does not support DevMode - I can't remember off the top of my head. If you care about that, then xsiframe definitely does support it. - Unnur On Tue, Feb 15, 2011 at 1:09 PM, John Tamplin j...@google.com wrote: On Tue, Feb 15, 2011 at 4:03 PM, Chris Conroy con...@google.com wrote: Sorry, didn't see your comment in time for the commit. I just used the same fix Kelly applied in SpeedTracer. I don't think it really matters strongly either way. As I understand it, the xs linker will soon be deprecated since the xsiframe linker provides a superset of its functionality. -- John A. Tamplin Software Engineer (GWT), Google -- 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). -- 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). -- 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: Create a red dev mode glass panel when hosted mode fails to load your module, similar to the gra... (issue730802)
Did I already mention how awesome it is that you fixed this? awesome! /kelly On Tue, Aug 10, 2010 at 5:05 PM, fre...@google.com wrote: Committed in r8509 http://code.google.com/p/google-web-toolkit/source/detail?r=8509 http://gwt-code-reviews.appspot.com/730802/show -- 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: Removed trim in ValueBoxBase, forcing parsers to handle trim()ing. (issue738801)
We just helped Philip pick one of the bugs on the list for Q3 to help him
get started with the codebase.
/kelly
On Wed, Aug 4, 2010 at 12:53 PM, rj...@google.com wrote:
Where did this change come from? What's motivating it?
http://gwt-code-reviews.appspot.com/738801/diff/1/2
File user/src/com/google/gwt/user/client/ui/ValueBoxBase.java (left):
http://gwt-code-reviews.appspot.com/738801/diff/1/2#oldcode201
user/src/com/google/gwt/user/client/ui/ValueBoxBase.java:201: if
(.equals(text)) {
This check will have to move after the parsing, or else be declared a
parser responsibility.
http://gwt-code-reviews.appspot.com/738801/show
--
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
Re: [gwt-contrib] Nicer style for the mobile parts of the sample. (issue502801)
Got screenshot? On Mon, May 10, 2010 at 4:41 PM, j...@google.com wrote: Reviewers: jlabanca, Description: Nicer style for the mobile parts of the sample. More useful mobile page stack. Added edit/save for expense entries. Please review this at http://gwt-code-reviews.appspot.com/502801/show Affected files: D /bikeshed/src/com/google/gwt/sample/expenses/gwt/client/Controller.java M /bikeshed/src/com/google/gwt/sample/expenses/gwt/client/ExpensesMobile.java M /bikeshed/src/com/google/gwt/sample/expenses/gwt/client/ExpensesMobileShell.java M /bikeshed/src/com/google/gwt/sample/expenses/gwt/client/ExpensesMobileShell.ui.xml A /bikeshed/src/com/google/gwt/sample/expenses/gwt/client/MobileExpenseDetails.java A /bikeshed/src/com/google/gwt/sample/expenses/gwt/client/MobileExpenseDetails.ui.xml M /bikeshed/src/com/google/gwt/sample/expenses/gwt/client/MobileExpenseEntry.java M /bikeshed/src/com/google/gwt/sample/expenses/gwt/client/MobileExpenseEntry.ui.xml M /bikeshed/src/com/google/gwt/sample/expenses/gwt/client/MobileExpenseList.java A /bikeshed/src/com/google/gwt/sample/expenses/gwt/client/MobilePage.java M /bikeshed/src/com/google/gwt/sample/expenses/gwt/client/MobileReportList.java D /bikeshed/src/com/google/gwt/sample/expenses/gwt/client/Page.java M /bikeshed/src/com/google/gwt/sample/expenses/gwt/client/ScaffoldMobileShell.ui.xml A /bikeshed/src/com/google/gwt/sample/expenses/gwt/client/mobile.css -- http://groups.google.com/group/Google-Web-Toolkit-Contributors -- 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: FormPanel iframe name collisions
No, if two modules with the same name load, it's only through luck: Here's one example of why: http://code.google.com/p/google-web-toolkit/source/browse/trunk/dev/core/src/com/google/gwt/core/linker/IFrameTemplate.js#90 /kel On Mon, Dec 14, 2009 at 5:50 PM, John LaBanca jlaba...@google.com wrote: Isn't it technically possible for multiple apps to have the same module name? For example, I can image an app where the user customizes the interface, and includes the same app twice. Thanks, John LaBanca jlaba...@google.com On Mon, Dec 14, 2009 at 5:49 PM, knor...@google.com wrote: http://gwt-code-reviews.appspot.com/125801/diff/1/4 File user/src/com/google/gwt/user/client/ui/FormPanel.java (right): http://gwt-code-reviews.appspot.com/125801/diff/1/4#newcode298 Line 298: /** Rather than polluting $wnd even more, why not make the id: FormPanel_ + GWT.getModuleName() + (++formId) http://gwt-code-reviews.appspot.com/125801 -- 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
Re: Install Speed Tracer on the Mac?
Hi Jim, We were actually kind of late finding out that extensions would not be enabled on the Mac, so we didn't get a chance to change out the screenshots. In fact, extensions have been turned on in the Mac Dev Channel for the past month but they had to turn them off briefly for the Chrome Beta launch. They will be getting turned back on soon. But if you are really interested in running Speed Tracer on Chrome Mac, you can use the nightly builds (where extensions are turned on). Someone just recently wrote about how to do this: http://flemieux.com/post/275628097/make-speed-tracer-chrome-extension-work-in-chromium-for The one warning I'll offer is that extensions support on the Mac is not quite finished so the Save/Load functionality in Speed Tracer doesn't work and you may run into other small annoyances. However, I use a Mac and this is exactly what I do to use Speed Tracer on my machine. /kel On Wed, Dec 9, 2009 at 7:11 AM, Jim Douglas jdoug...@basis.com wrote: I'm feeling a bit dense -- I see instructions here for installing Speed Tracer on Windows, but no Mac instructions: http://code.google.com/webtoolkit/speedtracer/get-started.html#downloading But there are Mac screen shots on this page, so I'm assuming it's supposed to work. What am I missing here? Specifically, what's the Mac way to add the --enable-extension-timeline-api option to Chrome? Jim. -- You received this message because you are subscribed to the Google Groups Google Web Toolkit group. To post to this group, send email to google-web-tool...@googlegroups.com. To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.comgoogle-web-toolkit%2bunsubscr...@googlegroups.com . For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en. -- 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). -- You received this message because you are subscribed to the Google Groups Google Web Toolkit group. To post to this group, send email to google-web-tool...@googlegroups.com. To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
[gwt-contrib] Re: Remove distro-source/platform dirs
Index: distro-source/mac/src/libswt-webkit-carbon-3235.jnilib That was a prebuilt version of the modified swt library we built. It can definitely go. /kel On Fri, Nov 20, 2009 at 5:52 PM, Scott Blum sco...@google.com wrote: Strange, I'd have thought we'd have pulled that file from /tools. Anyway, please kill it. On Fri, Nov 20, 2009 at 5:48 PM, Amit Manjhi amitman...@google.comwrote: Kelly and Scott are the only ones that have touched this file. Please comment if it is still necessary. On Fri, Nov 20, 2009 at 2:41 PM, j...@google.com wrote: mozilla-hosted-browser.conf is definitely not needed any more. I don't believe libswt is needed for Mac either, but then I am not sure why it was ever here in the first place rather than in jni/mac. http://gwt-code-reviews.appspot.com/105803 -- 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
Re: [gwt-contrib] adding new names to the blackout list
Me, I'm holding out for the 'comefrom' statement. /kel On Tue, Nov 17, 2009 at 9:31 PM, Bruce Johnson br...@google.com wrote: +1 Freeland. You may then also like the planned private goto, which goes somewhere but it doesn't tell you where it's gone. On Tuesday, November 17, 2009, Freeland Abbott fabb...@google.com wrote: Personally, I'm holding out for transient goto... imagine being able to leap to another chunk of code, and then back again when it finishes! On Tue, Nov 17, 2009 at 5:27 PM, Bruce Johnson br...@google.com wrote: I'm especially excited about goto! Think of how powerful and flexible that will be! On Tue, Nov 17, 2009 at 3:13 PM, Daniel Rice (דניאל רייס) r...@google.com wrote: // future reserved words abstract, int, short, boolean, interface, static, byte, long, char, final, native, synchronized, float, package, throws, goto, private, transient, implements, protected, volatile, double, public, What a future it will be... Dan On Tue, Nov 17, 2009 at 3:11 PM, Freeland Abbott fabb...@google.com wrote: I don't promise this is exhaustive, but it catches up to the mozilla and IE references, plus uneval from issue 3965. (Which wasn't on the mozilla pages, despite being reserved there, so I'm in fact almost sure this isn't exhaustive...) -- http://groups.google.com/group/Google-Web-Toolkit-Contributors -- http://groups.google.com/group/Google-Web-Toolkit-Contributors -- http://groups.google.com/group/Google-Web-Toolkit-Contributors -- http://groups.google.com/group/Google-Web-Toolkit-Contributors -- http://groups.google.com/group/Google-Web-Toolkit-Contributors -- 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: Prettier GWT version names for upcoming 2.0 releases
fwiw, I've never found myself sorting GWT distros but I do find myself wanting to uniquely identify them all the time. Why do you think people will be so eager to ignore part of the label? I would actually be surprised if any form of naming fixes the few incidences of the conversation you mention. I tend to think those are because people really do think they are using the release ... only to realize later they never updated their project. /kel On Thu, Aug 13, 2009 at 2:31 PM, Scott Blum sco...@google.com wrote: On Wed, Aug 12, 2009 at 6:39 PM, Bruce Johnson br...@google.com wrote: Senator Blum, Do you mean disturbing as in 1) revolting, 2) distressing, or 3) disordering? Distressing, I think. -- Example #1 -- Please sort the following two lists chronlogically as quickly as you can: List 1: 1.6.2, 1.6.5, 1.6.0, 1.6.1 List 2: 2.0.0-rc2, 2.0.0-ms2, 2.0.0, 2.0.0-rc1 -- Example #2 -- uberuser: There's a bug in GWT where tab panels explode on FF3. gwtcoder: What version are you using? I fixed that in 2.0.0. (+Status:Duplicate) uberuser: I'm using 2.0.0 and it's still broken. gwtcoder: Okay I'll take a look (-Status:Duplicate, +Status:Accepted) gwtcoder: I can't repro this in 2.0.0. Are you sure you're using the 2.0.0 RELEASE and not 2.0.0-rc1 or 2.0.0-ms2? (-Status:Accepted, +Status:NeedsInfo) uberuser: Doh! You're right, I was using 2.0.0-rc1. After upgrading to 2.0.0 RELEASE and recompiling, the problem went away. Sorry, thanks! gwtcoder: No prob, our version numbers are admittedly a bit confusing. (-Status:NeedsInfo, +Status:Duplicate) -- 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: Fwd: Review: JsArrays patch
Internet is alive today in the boonies.LGTM. /kel On Wed, Apr 8, 2009 at 3:58 AM, Freeland Abbott fabb...@google.com wrote: Bruce, with Kelly away and Scott abdicating over JsArrayBase, it falls back to you for this patch. This should have only the non-contentious stuff (namely push and shift)... plus toSource, which I argue is dead-stripped if unused, and plausibly useful for debugging (yes, on Mozilla only, but it tests for definition, and I don't imagine anything else should want that method name). I can make an in-project utility class to do sort, since Kelly was nervous about setting an ill-considered trend for JSO functors. -- Forwarded message -- From: Freeland Abbott fabb...@google.com Date: Tue, Mar 31, 2009 at 9:55 PM Subject: Re: Review: JsArrays patch To: Kelly Norton knor...@google.com Cc: Scott Blum sco...@google.com, Bruce Johnson br...@google.com, GWTcontrib Google-Web-Toolkit-Contributors@googlegroups.com Okay. I'll look into sort and toSource tomorrow; right now I'm away from that project code to see whether I want to try to fight for sort. So this patch should, I hope, be just the easy stuff. Usually when I say something rash like that it turns out I'm very wrong, but we'll see. Regarding JSO, I pulled toSource, but left the I-think-helpful toString(). I know Scott worried about pulling in other types' toString(), but in separate private email I think his worry is unfounded---best I know, we don't analyze JSNI bodies, so while this implementation references toString() if available, it can't change code size by pulling anything in that wasn't already coming for the ride. I think; I'm sure he or someone will correct me if I'm wrong on that! On Tue, Mar 31, 2009 at 5:44 AM, Kelly Norton knor...@google.com wrote: 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 fabb...@google.comwrote: 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 sco...@google.com 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). -- 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
[gwt-contrib] Re: Review: JsArrays patch
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 fabb...@google.com 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 sco...@google.com 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: Review: JsArrays patch
FWIW, in another little project I used a pattern for this that avoids
implementation inheritance that I call self-delegation.
Here's an example:
/** Not put API, but it includes the impl for al getters and setters for all
types. **/
final class JsArray extends JavaScriptObject {
...
public int getInt(int index) {
assert indexIsInBounds(index);
return getIntImpl(index);
}
public void setNumber(int index, double value) {
assert isNumber(value);
setNumberImpl(index, value);
}
private native int getIntImpl(int index) /*-{
return this[index];
}-*/;
private native void setNumberImpl(int index, double value) /*-{
this[index] = value;
}-*/;
...
}
/** Public API */
public final class IntArray extends DataStructure {
public static IntArray create() {
return JavaScriptObject.createArray().cast();
}
protected IntArray() {
}
public int get(int index) {
return this.JsArraycast().getInt(index);
}
public int getSize() {
return this.JsArraycast().getSize();
}
public void set(int index, int value) {
this.JsArraycast().setNumber(index, value);
}
}
/kel
On Fri, Mar 27, 2009 at 1:41 PM, Bruce Johnson br...@google.com wrote:
Let's not add this extra type JsArrayBase into the hierarchy. Why can't we
just push the various methods down? We can always factor upward in the
future. If we need shared implementation, we can factor that out into a
package-private JsArrayImpl class.
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: dynamic module loading
I was typing up an email and then Joel's response arrived covering much of what I was typing, so I'll just add to his points: The first thing I was going to mention is that, as I understand it, pyjamas loads modules by injecting a script tag and then running a timer to determine when the module has loaded. I'm curious why it doesn't just add a callback to the module script to avoid the timer? The second thing is a more general question. GWT's code splitting is largely about doing analysis to determine code dependencies between the various split points. It sounds like pyjamas simplifies split points by just making them modules, but does it do any dead code elimination or does it just translate the entire module to javascript? /kel On Wed, Mar 11, 2009 at 4:42 PM, Joel Webber ѯ(ټ)ѥ j...@google.com wrote: Code splitting, as in http://code.google.com/p/google-web-toolkit/wiki/CodeSplitting The particular design we're pursuing (and by we, I mean Lex) is one that will take asynchronous split-points you define in your application code and have the compiler statically determine the optimal set of generated code to put in each fragment. It takes advantage of the fact that Java (without reflection) is fully statically analyzable to do so. I'm glad to hear that Pyjamas is attempting to attack the code-bloat problem in a somewhat analogous way, and the two implementations may have something to learn from one-another in how they actually fetch the remote code. As for the actual splitting algorithm, Python is an entirely different beast, whose dynamic nature will require possibly-incorrect user guidance as to the dependency graph, and I'm pretty certain it can only asymptotically approach optimal dependencies, with the possibility of error becoming greater the more one tries to find the optimal set of dependencies by hand. I believe Lex started by trying to use script tags, but they have the significant disadvantage that you can't tell when one fails to load, reliably, on all browsers. You can fetch the scripts using XHRs, but there are some significant hurdles to using eval() on the resulting script text, as described by Lex, here: http://lexspoon.blogspot.com/2009/03/many-scopes-of-javascripts-eval.html Hope this clears things up a bit, joel. On Wed, Mar 11, 2009 at 4:31 PM, lkcl luke.leigh...@googlemail.comwrote: On Mar 11, 5:58 pm, Ray Cromwell cromwell...@gmail.com wrote: If by this, you mean code splitting, you might want to look at the GWT trunk. code splitting - as in 'splitting classes into separate javascript cache files and using s = document.createElement(script); s.src = class.name.ui.something.cache.js; document.appendChild(head, s); ' and then going into a timer loop, waiting for it to load ? if that's been done already, _great_. saves _vast_ amounts of duplication of compiled javascript. pyjamas GAE users are hitting the limit with just a simple application, thanks to 500k of pyjamas ui libraries - duplicated 5 times between the 5 platforms. so GWT developers will benefit enormously from the same functionality. l. -- 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: Do 0-timeout deferred commands need to wait for a timer tick?
Heh, I think I always have an opinion on Timers :-) I think Timers should allow 0ms delays and I think we should also have a mechanism for what is commonly called invokeLater. Here's why: Timers should accept 0ms I do think allowing 0ms is kind of wrong because browsers clamp at 10ms-15ms and browser makers are always flirting with the idea of lowering the clamps and occasionally something like Chrome shows up and actually does lower the clamp. Suddenly that app that used to get called back every 10ms is getting called back every 4ms and it's killing batteries on laptops and making my G5 fan spin up in a fury. But even if the developer had specified 1ms, it still would've killed my batteries and given my G5 a workout. With the current set of browsers, 0ms is no different from 1ms, 2ms...10ms. So if we were going to make a stand and say 0ms is bad practice, we should've made our stand stronger and not allowed any of the lower numbers. But allowing 1ms and not 0ms just makes people ask why we don't support this thing that is clearly common practice in the browser. We should have an invokeLater: We actually have it, it's called DeferredCommand. Unfortunately, we let its implementation get too gangled up with another feature called IncrementalCommand and use of DeferredCommand now generates way too much code. Many developers still use DeferredCommand when wanting to invokeLater. After 1.4, I've seen many people avoid DeferredCommands (including myself) in favor of a very simple method wrapping setTimeout around a GWT Command. (I usually call my postCommand(Command)). So people are interested in the semantics of invokeLater apart from Timers, but we may've blocked the primary way to do that in GWT. I think we should lighten DeferredCommand so it can continue to be our invokeLater. /kel On Mon, Jan 12, 2009 at 12:24 PM, Lex Spoon sp...@google.com wrote: I'd like to revive this thread from last month and argue for a different spec: http://groups.google.com/group/Google-Web-Toolkit-Contributors/browse_thread/thread/99a70af45e06ed3d?pli=1 The question there was what a GWT Timer should do with a timeout of 0, which is currently prohibited. The thinking there was to mimick what window.setTimeout does and use the minimum delay. However, I agree with this post by Eugene Lazutkin: http://lazutkin.com/blog/2008/mar/23/javascript-edp-and-0ms-timeouts/ There is a lot of good use for having a mechanism for specifying a callback that you want to run at the top of the event loop. Eugene argues that this is established practice for all kinds of very popular GUI toolkits. I would add that it's showing up in language designs like Erlang and E. This is a powerful tool for apps that are architected around an event queue. We can provide this facility, even though window.setTimeout doesn't do what is necessary. Here's a question, though: should the functionality be provided in a new class, or would it be okay to make Timer do it if the timeout is set to 0? Updating Timer looks cleanest to me.. However, it will occasionally trip up someone very knowledgeable about browsers. Such a person might out-clever themselves by trying to use 0 to mean the minimum delay. Opinions? -Lex -- 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: RR: skip runAsync cruft when there is no call to runAsync
LGTM and the cruft is gone from my trivial app. thanks, /kel On Mon, Dec 8, 2008 at 5:32 PM, Lex Spoon sp...@google.com wrote: Kelly, Can you review the patch I attached to issue 3121? http://code.google.com/p/google-web-toolkit/issues/detail?id=3121 In particular, does it eliminate the cruft in the trivial app you initially tried with, and still leave the app working? Lex -- 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: Why is Timer#schedule(0) bad?
Everone clamps timers now. Chrome launched without a clamp, but even without the clamp setTimeout(..., 0) enqueued an event onto the message loop. There were some old mozilla browsers that didn't yield on setTimeout of 0, but you would probably have to look pretty deep in the archives to find one. Unless things have changed since the last time I looked into this, this is the roll call on timer clamping: Chrome: 4ms (fairly recent change) Safari (mac): 10ms Safari (win): 15ms Firefox: 15ms (or 10ms if flash is running) IE: 15ms Opera: I have no clue. So, that's just a really long way of saying that there is no danger in allowing 0 and technically it is a perfectly legal value ... it's just not very useful. /kel On Mon, Dec 8, 2008 at 11:45 PM, Bruce Johnson [EMAIL PROTECTED] wrote: On Mon, Dec 8, 2008 at 8:34 PM, Ray Cromwell [EMAIL PROTECTED] wrote: I've always assumed that 0 wasn't portable and use 10 by convention. Ideally, you'd want 0 to function like yield(), but I had a nagging suspicious that some browsers might treat 0 as a NOP (that is, run the code immediately without yielding) Even so, the API method itself should accept 0, I think, and we could just round it up to the lowest number acceptable to the browser, such as time = time =0 ? 10 : time or something like that. -- 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: Breaks dom.DOM dependency on user.UserAgent
On Wed, Dec 3, 2008 at 8:18 AM, Bruce Johnson [EMAIL PROTECTED] wrote: On Wed, Dec 3, 2008 at 7:50 AM, [EMAIL PROTECTED] wrote: To be honest, I wish we would start creating larger .gwt.xml files and make each one that exists inheritable. I agree. It was a rookie decision we made early on to over-emphasize fine-grained module reuse, and, like C header files, nobody has enough discipline (or incentive) to ensure they are all truly independently inheritable. A good question is whether we can just change it. The way things are currently, you can't inherit any submodule out of user without getting all of User. You either get errors because you are picking up gunk out of client that doesn't appear to be translatable or you include one of the few modules with a circular reference (SplitPanel or Animation). So given that you can't inherit them now, could we just delete the submodules and inline their contents into User? The only danger is that someone may've have done this: inherits name=com.google.gwt.user.User / inherits name=com.google.gwt.user.DOM / or inherits name=com.google.gwt.animation.Animation / // not realizing that it loops back to pick up all of User So removing DOM.gwt.xml would produce an error for those clients. Doing that would mean that I would get rid of UserAgent.gwt.xml altogether and move its contents into dom.DOM.gwt.xml. (or either create useragent.UserAgent.gwt.xml) The reason not to do this would be if there are other important use cases of modules that switch on User Agent but don't use DOM. I can only think of one right now: StringBuidler in 1.6 is the first place where the JRE can be sensitive to user agent. And you *might* in theory want to do sheer computation in GWT without touching the DOM (e.g. in a Gears worker thread). If we're going to make this kind of change, perhaps we should debate the merits of useragent.UserAgent to be darn sure it isn't the better option. This is enough of an argument to make me a supporter of useragent.UserAgent. Now that you mention it, we have already tried to position it as an independently inheritable module when we introduced UserAgent JRE optimizations. /kel -- 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: Breaks dom.DOM dependency on user.UserAgent
On Wed, Dec 3, 2008 at 10:10 AM, Bruce Johnson [EMAIL PROTECTED] wrote: Hey, that's a nice visualization! Using a nice view like that, we can probably iterate in early 2009 to clean up a lot of this. Ok, but I do want to create useragent.UserAgent now as I selfishly need the ability to exclude User. Anyone have any objections? (Spoiler alert: I'm going to start advocating hard in 2009 to get rid of module XML altogether and use package and class annotations instead.) If you need an additional advocate, I'm with you. Knowing that others are interested in doing this makes me very glad I decided not to write my Modules are broken and encourage bad practices essay/email. :-) /kel -- 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: runAsync fragment loading bug in IE
Yes lgtm to cameron's change, sorry I ignored email for a while. On Nov 10, 2008 6:08 PM, Lex Spoon [EMAIL PROTECTED] wrote: On Mon, Nov 10, 2008 at 2:33 PM, Kelly Norton [EMAIL PROTECTED] wrote: For iframe loading, Came... Can I consider that an LGTM? However, I am wondering how this is going to work in the xs case where the code is loaded into... No, that sounds like a problem all right. For independent reasons, using XHR instead of script tags sounds better, anyway. The downloaded result could then be eval-ed in the correct scope. That strategy would seem to work fine for the XS linker, so long as the call to eval happens within the anonymous function. Lex --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: event code review, part 1.
Ray C., No worries. We are planning to land a pure java code path through event dispatch code. My real objection in the review, which Emily and Ray forced out of me, is that we have never enumerated goals and use cases around sharing GWT-java code with other Java contexts. I want to make sure we have a good sense of what we want to accomplish with these because it is very easy to continue to slip in a change here and a change there to the point where you have no idea what part of the library can run in what context. So the plan is to land the implementation as is, but officially, the fact that there is a java code path through the event dispatch is really just happenstance. Meaning that we're not committing to support it quite yet. Ray Ryan is going to assemble a bit more vision around testability and mockability of GWT apps and libraries so that going forward we'll have a lot more guidance when we face these decisions. /kel On Thu, Nov 6, 2008 at 2:22 PM, Ray Cromwell [EMAIL PROTECTED] wrote: Emily, The issue of sharing the event handlers in non-GWT code is a virtual showstopper for me. One of the initial reasons I was drawn to GWT was the ability to share code between client and server, and now I've taken that to Flash and Android as well. Two things: 1) I run both GWT unit tests and regular unit tests. Smoke tests and shared functionality or non-JSNI code is typically JUnit tested. There are a couple of reasons for this, such as inability to run GWT tests under Maven, JUnit tests running much faster and not requiring XWindows to be running on our build box, differences between hosted mode on Linux/Windows/IE that make it hard to test logic without swapping implementations using deferred binding. Our build process allows us to do fast JUnit tests while developing, and then the continuous integration server launches GWT tests on 3 separate machines in the background. 2) The core logic of my GWT code is shared in my Android version, as well as my Servlet/Applet version. The current design allows me to create something like a 'zoom event' and map it to different dispatchers on Android, Browser, or Servlet (e.g. the servlet can fall back to non-Javascript old-style MapQuest-like interface) If you are going to remove the HashMap version in favor of a pure JS registry, might I suggest using a module property to do this so that I can override it and get back the original HashMap implementation? Otherwise, I'd be forced to fork or override GWT which would be a huge PITA, and could add to code bloat for me if I am forced to duplicate functionality. Overall, I don't see any reason for not using HashMap except performance, and while I could see a speedup in the event dispatching, and better memory efficiency, I'm not sure event dispatching is a hot-spot in current application code. -Ray On Thu, Nov 6, 2008 at 7:45 AM, Emily Crutcher [EMAIL PROTECTED] wrote: Thanks a million for an awesome review! There are a few points that need discussion, I've logged them under http://code.google.com/p/google-web-toolkit/source/branch?spec=issue3083branch=/branches/1_6_clean_events reviews. -- 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] FYI: code reviews done through our googlecode project will CC this list.
I just wanted people to be aware of this. I've changed the settings in our project to always CC the code review comments to this list. /kel -- 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: Code Review: Comment out flaky test in ImageTest
Have you considered disabling those tests only for the platforms where they are flaky? /kel On Wed, Sep 10, 2008 at 1:26 PM, John LaBanca [EMAIL PROTECTED] wrote: If we already comment out some methods, then LGTM. Joel doesn't think it matters, and I just wanted to be consistent not realizing that we've already used both comments and disabled methods. Thanks, John LaBanca [EMAIL PROTECTED] On Wed, Sep 10, 2008 at 1:19 PM, Eric Ayers [EMAIL PROTECTED] wrote: I don't mind doing that. There are several other methods in ImageTest commented out in the same way I did it. Want me to do the same for those? On Wed, Sep 10, 2008 at 1:13 PM, John LaBanca [EMAIL PROTECTED]wrote: I think we usually just rename the test to disabledTestXXX so JUnit doesn't run it. Do you mind doing it that way instead, but leaving the comment? Otherwise, the next time somebody auto-formats, the method will be formatted like a comment. Thanks, John LaBanca [EMAIL PROTECTED] On Wed, Sep 10, 2008 at 1:10 PM, Eric Ayers [EMAIL PROTECTED] wrote: Hello John, I would like for you to review this patch. The testChangeClippedImageToUnclipped() method fails intermittently in our continuous build system on Linux hosted mode. This could be related to issues 863 864 http://code.google.com/p/google-web-toolkit/issues/detail?id=863 http://code.google.com/p/google-web-toolkit/issues/detail?id=864 I've commented out the test, as there are many other tests in this TestCase that are commented out due to the same issues. M user/test/com/google/gwt/user/client/ui/ImageTest.java -- Eric Z. Ayers - GWT Team - Atlanta, GA USA http://code.google.com/webtoolkit/ -- Eric Z. Ayers - GWT Team - Atlanta, GA USA http://code.google.com/webtoolkit/ -- 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 -~--~~~~--~~--~--~---
