On Friday, June 8, 2012 12:09:51 AM UTC+2, Stephen Haberman wrote:
AFAICT, Safari 2 is no longer part of the supported browsers list, so
my take on it would be to clean-up the codebase and remove every
safari2-specific path.
There are overall a lot of cleanup (remove event listeners
On Friday, June 8, 2012 7:46:30 AM UTC+2, Thomas Broyer wrote:
(I wonder though: how are events handled? how are they registered? I'll
look at the UiBinder/UiRenderer code and/or the generated code)
Let me clarify: how are native events mapped to DomEvents? (DragStartEvent
in the sample)
I wonder if we shouldn't rather aim at integrating the
ServletContainerLauncher with SuperDevMode; which could also be seen as:
building a DevMode where the code server (the part to which the DevMode
browser plugin connects, and runs your client code in the JVM) would be
replaced by
Just to check, was everything okay with the CLA I signed?
On 7 June 2012 16:56, James Horsley james.hors...@gmail.com wrote:
Thanks Rajeev. Let me know if there's anything else you need with it.
On 7 June 2012 16:18, Rajeev Dayal rda...@google.com wrote:
Thomas, thanks for jumping in.
Yes, documentation is still forthcoming.
On Fri, Jun 8, 2012 at 3:43 AM, Thomas Broyer t.bro...@gmail.com wrote:
Let me clarify: how are native events mapped to DomEvents?
The event is guessed from the type of the first parameter in the event
handler. DragStartEvent.getAssociatedType() ==
Just to finish this off in case anyone else has the same problem -
this was fixed in r11031.
https://code.google.com/p/google-web-toolkit/source/detail?r=11031
On Wed, Jun 6, 2012 at 6:52 PM, Chris Price pric...@gmail.com wrote:
I've just tried to take the demo for a spin but I had a few
Yep, you're on the CLA list.
On Fri Jun 08 05:15:45 GMT-400 2012, James Horsley james.hors...@gmail.com
wrote:
Just to check, was everything okay with the CLA I signed?
On 7 June 2012 16:56, James Horsley james.hors...@gmail.com wrote:
Thanks Rajeev. Let me know if there's anything else you
Reviewers: rdayal,
Description:
Complete text-* support for Style
Reposting of 1736803
Thanks Patrick!
Please review this at http://gwt-code-reviews.appspot.com/1737804/
Affected files:
M user/src/com/google/gwt/dom/builder/client/DomStylesBuilder.java
M
Moving org.json into gwt-dev makes sense because the compiler actually
uses it. I'd like to see it repackaged, but perhaps we can wait until
someone complains?
I'm not sure about validation. Many people don't use it and I sorta
think GWT's validation support ought to be split out of gwt-user
LGTM. With a Nit.
http://gwt-code-reviews.appspot.com/1565806/diff/8001/user/test/com/google/gwt/editor/client/DirtyEditorTest.java
File user/test/com/google/gwt/editor/client/DirtyEditorTest.java
(right):
Line length.
Oh no! That was completely fine before adding those generics. :-)
I was putzing around with ant trying to get it to fail the compile so
didn't have Eclipse to flag the error.
Resubmitting.
http://gwt-code-reviews.appspot.com/1565806/
--
Just to finish this off in case anyone else has the same problem -
this was fixed in r11031.
https://code.google.com/p/google-web-toolkit/source/detail?r=11031
Thanks for the info. I had the same problem but now it works. Now lets hope
the compilation process will become a lot faster
I'm definitely interested in getting simple servlets to run in Super
Dev Mode in a way similar to classic Dev Mode. I haven't investigated,
so I don't know if it's better to reuse the existing implementation or
write a fresh one and leave behind some crud.
I don't think we want to try too hard to
I was putzing around with ant trying to get it to fail the compile so
didn't have Eclipse to flag the error.
Huh, I thought I had Eclipse configured to show checkstyle errors like
that--but I don't see it. I see other errors like methods not in
alphabetical order.
Resubmitting.
I hope the
LGTM
On 2012/06/08 18:27:29, stephenh wrote:
I was putzing around with ant trying to get it to fail the compile
so didn't
have Eclipse to flag the error.
Huh, I thought I had Eclipse configured to show checkstyle errors like
that--but
I don't see it. I see other errors like methods not
I'm not sure about validation. Many people don't use it and I sorta
think GWT's validation support ought to be split out of gwt-user into a
separate jar. If there's no actual bug than I'm inclined to leave it
alone for now.
This would absolutely kill compatibility with gwt-validation.
Submitted as r11033
http://gwt-code-reviews.appspot.com/1737804/
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
On Fri, Jun 8, 2012 at 2:26 PM, Brian Slesinsky skybr...@google.com wrote:
I'm definitely interested in getting simple servlets to run in Super
Dev Mode in a way similar to classic Dev Mode. I haven't investigated,
so I don't know if it's better to reuse the existing implementation or
write a
think GWT's validation support ought to be split out of gwt-user
into a separate jar.
This would absolutely kill compatibility with gwt-validation
I know very little about gwt-validation and GWT's javax validation, but
wouldn't having GWT's validation in a separate jar make it easier for
On 2012/06/08 18:02:44, skybrian wrote:
Moving org.json into gwt-dev makes sense because the compiler actually
uses it.
I'd like to see it repackaged, but perhaps we can wait until someone
complains?
I'm not sure about validation. Many people don't use it and I sorta
think GWT's
Chris, I'm not sure what you mean by This. Do you mean the patch as
it stands or something I've been speculating about?
On Fri, Jun 8, 2012 at 11:43 AM, Chris Ruffalo chris.ruff...@gmail.com wrote:
This would absolutely kill compatibility with gwt-validation.
I guess I didn't make myself clear, I was agreeing. GWT's validation
should *always* be in a separate module from gwt-user. What I should have
said Otherwise, this would completely kill...
I don't think that moving javax.validation into gwt-user would be a good
idea. Especially if it comes
How big is your app? (KLOC) Internally, we'd had success with 10s
refresh on some fairly largish apps. I'm wondering if something else
isn't going on. Note that the first compile usually takes long, but
subsequent ones are faster. Are you using UiBinder? One issue could be
generators using too
Okay, I think we should just fix JSON in this patch and figure out
validation as a separate patch.
- Brian
On Fri, Jun 8, 2012 at 12:04 PM, Chris Ruffalo chris.ruff...@gmail.com wrote:
I guess I didn't make myself clear, I was agreeing. GWT's validation
should *always* be in a separate
Reviewers: rdayal,
Description:
Checkstyle fixes
Repost of 1565806
Thanks Stephen!
Patch by: stephen.haber...@gmail.com
Please review this at http://gwt-code-reviews.appspot.com/1725807/
Affected files:
M
dev/core/src/com/google/gwt/core/ext/linker/impl/StandardPublicResource.java
M
LGTM.
http://gwt-code-reviews.appspot.com/1733805/
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
On 2012/05/31 16:11:23, stephenh wrote:
Ping Ping.
Thanks--added a new patchset with a performance note in the javadocs.
Committed as r11032.
http://gwt-code-reviews.appspot.com/1614806/
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
On 2012/05/22 16:11:49, tbroyer wrote:
LGTM.
https://gwt-code-reviews.appspot.com/1713803/
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
Submitted as r11034
http://gwt-code-reviews.appspot.com/1565806/
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
On Fri, Jun 8, 2012 at 8:43 PM, Chris Ruffalo chris.ruff...@gmail.com wrote:
I'm not sure about validation. Many people don't use it and I sorta
think GWT's validation support ought to be split out of gwt-user into a
separate jar. If there's no actual bug than I'm inclined to leave it
alone
Submitted as r11034
http://gwt-code-reviews.appspot.com/1725807/
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
Submitted as r11035
http://gwt-code-reviews.appspot.com/1733805/
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
I just checked again, one of the internal apps we are trying
SuperDevMode against has about 400,000 lines of code and combines in
about 7-8 seconds. So maybe your app has 6x as much code? If not, it
gives us a clue that perhaps there's some other edge condition causing
the compile to be slow.
On Fri, Jun 8, 2012 at 8:46 PM, John Tamplin j...@google.com wrote:
On Fri, Jun 8, 2012 at 2:26 PM, Brian Slesinsky skybr...@google.com wrote:
I'm definitely interested in getting simple servlets to run in Super
Dev Mode in a way similar to classic Dev Mode. I haven't investigated,
so I don't
I've just tried SuperDevMode for the first time. I have around 250KLOC, of
which around 200KLOC are translated to javascript.
The code server reported 3 minutes for the initial compile (with 2
permutations), then 37 seconds for the first compile from the browser, and then
consistently 18-19
Hmm, that's still not where we'd like to be. Our design goal is 10s.
Are you using UiBinder, Gin, ImageResource, I18N, GWT RPC? I'm
wondering if one of the generators may or may not have an issue with
incremental compilation.
This may not do anything, but try it anyway, add these JVM flags
lgtm
http://gwt-code-reviews.appspot.com/1729804/
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
LGTM
http://gwt-code-reviews.appspot.com/1729804/
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
I'm not using UiBinder or Gin.
I am using GWT RPC, I18N and ImageResource.
I have approximately:
- 100 methods across several ClientBundles returning an ImageResource.
- 700 I18N methods spread over about 30 interfaces (my initial 2 permutations
were for the default locale)
- for GWT RPC, I
Reviewers: conroy,
Description:
Firefox 13 DevMode Plugin
Please review this at http://gwt-code-reviews.appspot.com/1738803/
Affected files:
M plugins/xpcom/FFSessionHandler.cpp
M plugins/xpcom/JSRunner.cpp
M plugins/xpcom/JavaObject.cpp
M plugins/xpcom/JavaObject.h
M
Opps, sorry, the speedtracer log is always on anyway. Look in the
super-dev-mode work dir, e.g.
/tmp/gwt-codeserver-*/modulename/speedtracer.html
I think the issue might be that I18N generators don't implement
IncrementalGenerator, and so they run every compile, even if nothing
in your interfaces
LGTM
http://gwt-code-reviews.appspot.com/1727806/
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
On Fri, Jun 8, 2012 at 1:49 PM, Thomas Broyer t.bro...@gmail.com wrote:
ServletContainerLauncher is simple enough to be reused here. The
default implementation based on Jetty 6 could be pushed in a separate
JAR and the SuperDevMode would warn users if it finds a
WEB-INF/web.xml, isn't run in
On Saturday, June 9, 2012 12:24:43 AM UTC+2, Brian Slesinsky wrote:
On Fri, Jun 8, 2012 at 1:49 PM, Thomas Broyer t.bro...@gmail.com wrote:
ServletContainerLauncher is simple enough to be reused here. The
default implementation based on Jetty 6 could be pushed in a separate
JAR and
Reviewers: cromwellian,
Description:
Don't allow enum ordinalization if a custom enum method references
values() directly
Addresses issue 7067
(http://code.google.com/p/google-web-toolkit/issues/detail?id=7067)
Please review this at http://gwt-code-reviews.appspot.com/1730804/
Affected files:
LGTM
http://gwt-code-reviews.appspot.com/1730804/
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
Reviewers: skybrian, tbroyer,
Description:
Add new CSS FunctionValue type as a first-class representation of value
functions, hook it up into the @def replacer.
This means that gradients can now take @def constants. This also fixes
issues with function arguments losing spaces - no more
This is ready for re-review, BTW.
http://gwt-code-reviews.appspot.com/1727803/
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
Well, 3 years ago, BobV removed support for Safari 2 from GWT-RPC:
http://code.google.com/p/google-web-toolkit/source/detail?r=5666
Cool. I'll work on a patch to update isOrHasChild.
- Stephen
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
49 matches
Mail list logo
