Could this also be used as a general pattern to batch DOM updates from
multiple Widgets performing updates? e.g. a current approach to avoid the
overhead, of say, installing a dozen widgets, is to concatenate all the HTML
together, slam it into innerHTML, and then wrap the widgets around the HTML.
On 2 sep, 19:56, codesite-nore...@google.com wrote:
Revision: 6073
Author: jlaba...@google.com
Date: Wed Sep 2 10:55:41 2009
Log: Removing an assertion that introduced a breaking change.
Patch by: jlabanca
Review by: jgw (TBR)
http://gwt-code-reviews.appspot.com/64802/diff/1/2
File dev/mac/src/com/google/gwt/dev/BootStrapPlatform.java (right):
http://gwt-code-reviews.appspot.com/64802/diff/1/2#newcode117
Line 117: return 32.equals(System.getProperty(sun.arg.data.model));
On 2009/09/03 05:56:42, jat wrote:
If this is
Later meaning within the next day
http://gwt-code-reviews.appspot.com/59805
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---
LGTM
I'll submit this later
http://gwt-code-reviews.appspot.com/59805
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---
Just a few remarks relating to the design changes...
*RequiresLayout.java* : We expose now animation routines in this interface.
With those new animation methods this interface becomes more constraining
when you have to provide a subclass. What about a panel provider that would
not want to
LGTM. I have no objection to loosening up these assertions when a case like
this comes up. Others (e.g., input type='password') may have to be loosened
up at some point as well.
On Thu, Sep 3, 2009 at 3:01 AM, Thomas Broyer t.bro...@gmail.com wrote:
On 2 sep, 19:56,
http://gwt-code-reviews.appspot.com/63801
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---
http://gwt-code-reviews.appspot.com/63801
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---
Looks like we want a different solution for test.web.htmlunit, but here's
the haltonfailure flag for gwt.junit
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---
LGTM
Thanks,
John LaBanca
jlaba...@google.com
On Thu, Sep 3, 2009 at 11:47 AM, Freeland Abbott fabb...@google.com wrote:
Looks like we want a different solution for test.web.htmlunit, but here's
the haltonfailure flag for gwt.junit
--~--~-~--~~~---~--~~
Reviewers: Lex, schuck_google.com,
Description:
This change to the dashboard updates the settings parser to read symbol
maps files created with the CompactSymbolLinker.
Please review this at http://gwt-code-reviews.appspot.com/65802
Affected files:
Reviewers: Lex,
Description:
Hi Lex,
could you review this patch for me? It eliminates some dead links in
the dashboard when displayDependencies is turned off.
Thanks!
kathrin
Please review this at http://gwt-code-reviews.appspot.com/65803
Affected files:
Oooh, sorry. You were asking the *hard* question, not the easy one.
I think the short answer is that there's no easy answer. See
http://code.google.com/p/google-web-toolkit/issues/detail?id=1431 for some
of the reasons. Another short answer is I don't get this stuff but Joel
does.
rjrjr
On Wed,
On 2009/09/03 04:05:36, Ray Ryan wrote:
Okay, name - field was trivial, done.
LGTM so far. I modified a bit of the mail sample to use this, and it
worked a charm.
A couple of minor nits:
- I assume that DS_Store and ButtonTest are accidentally attached to
this patch.
- Could use some
Revision: 6078
Author: jlaba...@google.com
Date: Thu Sep 3 10:59:12 2009
Log: Removing HtmlUnit from ant test target until the tests are more
reliable. Also fixed a checkstyle error and a minor bug in a couple of
tests.
Patch by: jlabanca
Review by: jat
http://gwt-code-reviews.appspot.com/63801
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---
On 2009/09/03 17:40:20, jgw wrote:
On 2009/09/03 04:05:36, Ray Ryan wrote:
Okay, name - field was trivial, done.
LGTM so far. I modified a bit of the mail sample to use this, and it
worked a
charm.
A couple of minor nits:
- I assume that DS_Store and ButtonTest are accidentally attached
LGTM
http://gwt-code-reviews.appspot.com/64804
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---
Reviewers: cromwellian,
Message:
Ray,
Can you confirm that this patch fixes the Snow Leopard issue. It's the
same patch as before with the typo fixed and the error message slightly
expanded.
Please review this at http://gwt-code-reviews.appspot.com/64805
Affected files:
M
On 2009/09/03 19:07:53, knorton wrote:
Ray,
Can you confirm that this patch fixes the Snow Leopard issue. It's the
same
patch as before with the typo fixed and the error message slightly
expanded.
Since we have the 32-bit issue on other platforms, should we do this in
common code instead?
On 2009/09/03 19:07:53, knorton wrote:
Ray,
Can you confirm that this patch fixes the Snow Leopard issue. It's the
same
patch as before with the typo fixed and the error message slightly
expanded.
Works on Snow Leopard with IntelliJ as launcher against GWT 2.0 trunk.
LGTM.
Revision: 6079
Author: fabb...@google.com
Date: Thu Sep 3 12:14:51 2009
Log: giving gwt.junit a haltonfailure attribute.
Review by: jlabanca
http://code.google.com/p/google-web-toolkit/source/detail?r=6079
Modified:
/trunk/common.ant.xml
===
---
In the rare cases it fails, the user will just get what they get by
default now. Seems like we should go ahead and do it for all the
platforms. I'll add the checking to HostedModeBase, but have it call
back into BootStrapPlatform for the error message so we can keep the OS
X specific hints.
On 2009/09/03 17:50:24, jgw wrote:
Committed at r6080.
@Sami: Note that this is not set in stone yet -- let's continue the
discussion about those interfaces in the meantime.
http://gwt-code-reviews.appspot.com/63801
--~--~-~--~~~---~--~~
@Ray: To clarify, you need to add -d32 to the launch config though, right?
On Thu, Sep 3, 2009 at 3:22 PM, cromwell...@gmail.com wrote:
On 2009/09/03 19:07:53, knorton wrote:
Ray,
Can you confirm that this patch fixes the Snow Leopard issue. It's the
same
patch as before with the typo
Sure, does sun.arch.data.model work everywhere?
/kel
On 2009/09/03 19:17:16, jat wrote:
On 2009/09/03 19:07:53, knorton wrote:
Ray,
Can you confirm that this patch fixes the Snow Leopard issue. It's
the same
patch as before with the typo fixed and the error message slightly
expanded.
I can't say it'll work everywhere, but it's in the official Sun Hotspot
FAQ:
http://www.j2ee.me/docs/hotspot/HotSpotFAQ.html#64bit_detection
On 2009/09/03 19:21:06, knorton wrote:
Sure, does sun.arch.data.model work everywhere?
/kel
On 2009/09/03 19:17:16, jat wrote:
On 2009/09/03
If you are on IntelliJ IDEA, I'm not sure about Eclipse. OSX has this app
called Java Preferences.app that changes the system /usr/bin/java so that
it points to which VM you want, so when you type java -version from the
command line, you'll get the appropriate VM. That is, if you select 32-bit,
it
Revision: 6080
Author: j...@google.com
Date: Thu Sep 3 12:28:14 2009
Log: - Changed Requires/ProvidesLayout = Requires/ProvidesResize; some
small doc
additions.
- Added RequiresLayout; moved doc into it.
- Added LayoutPanelExample.
- Added DockLayoutPanel.
- A bit of cleanup here and there.
It looks like there's enough pushback on this that we may want to drop it
for now and have someone look into why at least one internal app is having
bizarre refresh problems. Mothballing this patch for now.
On Thu, Sep 3, 2009 at 11:24 AM, John Tamplin j...@google.com wrote:
On Thu, Sep 3, 2009
On 2009/08/26 15:21:26, t.broyer wrote:
Just so you know, I haven't forgotten about this, but I'm really swamped
this week. I'm out next week, but will have a look at this as soon as I
get back (unless someone else beats me to it).
http://gwt-code-reviews.appspot.com/61813
Doing it all platforms style.
I also confirmed that this does the right thing on Leopard when you run
both the 1.5 and 1.6 vms.
http://gwt-code-reviews.appspot.com/64805
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
Yes, this is definitely going to be a part of the 2.0 release. Which is why
I am glad to have all the feedback I can get :)
On Thu, Sep 3, 2009 at 4:10 PM, Sami Jaber sami.ja...@gmail.com wrote:
No pb Joel, now that I better understand the kind of issue you faced, let's
say ok to this naming
The mechanism is just brilliant. I have reservations about the api.
bikeshed
it seemed kinda nice to have one less type
Except that we have one more type, BatchedCommand, which looks exactly like
Command, except with a different name, and you have to subclass it rather
than implement it...
A
Revision: 6081
Author: jlaba...@google.com
Date: Thu Sep 3 13:43:19 2009
Log: Fixes a bug in DOMImplTrident#getTagName() where it does not handle an
undefined scope name.
Patch by: kerjin2001
Review by: jlabanca
http://code.google.com/p/google-web-toolkit/source/detail?r=6081
Modified:
committed as r6081
http://gwt-code-reviews.appspot.com/59805
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---
++Ray.
On Thu, Sep 3, 2009 at 4:38 PM, Ray Ryan rj...@google.com wrote:
The mechanism is just brilliant. I have reservations about the api.
bikeshed
it seemed kinda nice to have one less type
Except that we have one more type, BatchedCommand, which looks exactly like
Command, except
++(++Ray)
Anything we can do to sensibly get this crap out of .user and into .core (or
some other common location) would be very, very good.
If, as a side-effect, we could get DeferredCommand to *not* use
IncrementalCommand (the latter brings in fairly significant dependencies
that are enough to
Revision: 6082
Author: j...@google.com
Date: Thu Sep 3 14:01:13 2009
Log: Add a dialog to let the user allow/deny connections.
http://code.google.com/p/google-web-toolkit/source/detail?r=6082
Added:
/changes/jat/plugins/plugins/ie/oophm/oophm/AllowDialog.cpp
Thanks. Updated with some checkstyle fixes. Running tests, should submit
soon.
http://gwt-code-reviews.appspot.com/64801
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---
Revision: 6084
Author: j...@google.com
Date: Thu Sep 3 14:56:24 2009
Log: Missing paren in debug message.
http://code.google.com/p/google-web-toolkit/source/detail?r=6084
Modified:
/changes/jat/plugins/plugins/common/AllowedConnections.cpp
===
---
Revision: 6088
Author: tamplinjohn
Date: Thu Sep 3 16:19:08 2009
Log: Edited wiki page through web user interface.
http://code.google.com/p/google-web-toolkit/source/detail?r=6088
Modified:
/wiki/UsingOOPHM.wiki
===
--- /wiki/UsingOOPHM.wiki Thu Sep
I like it a lot Ray. (To be completely honest, I knew you were going to say
all that, so I decided to sandbag and let you do the typing :-)
I question if it's really appropriate to explicitly say PreEventLoop and
PostEventLoop considering that...sometimes...the event loop can actually
run
Okay, here's a strawman for a new-and-improved proposal. All these would be
in core.
// Deferred command = on the other side of the event loop
interface DeferredCommands {
public static DeferredCommands get();
public void add(Command cmd);
public void add(Command cmd, boolean asap); //
Is there a reason why we just don't add Runnable and CallableV to the JRE
emul and use those instead of Command? This design seems to parallel some of
the patterns in ExecutorService. I could see some of those patterns being
useful (like completion queues, which would be useful for staged
Comment by jason.carver:
I'm in Windows XP, using the latest FF35 plugin from trunk and compiling my
GWT project against the latest from trunk, but I'm still getting the No
GWT plugin found or hosted-mode connection failed error. I'm also using
-noserver. I am definitely running the
47 matches
Mail list logo
