[gwt-contrib] [google-web-toolkit] r6369 committed - Rearrange ant test targets....
Revision: 6369
Author: j...@google.com
Date: Tue Oct 13 23:49:20 2009
Log: Rearrange ant test targets.
The continuous build systems need to have gwt.hosts.dev.remote and
gwt.hosts.dev.selenium set to those hosts which have the devmode plugin
installed for devmode tests to be run at all, until HtmlUnit is made
reliable
enough to enable by default.
Patch by: jat
Review by: amitmanjhi, jlabanca (TBR)
http://code.google.com/p/google-web-toolkit/source/detail?r=6369
Modified:
/changes/jat/noswt-merge6200/user/build.xml
===
--- /changes/jat/noswt-merge6200/user/build.xml Tue Sep 29 11:05:28 2009
+++ /changes/jat/noswt-merge6200/user/build.xml Tue Oct 13 23:49:20 2009
@@ -3,6 +3,14 @@
property name=project.tail value=user /
property name=test.args value= /
+ !-- support old variables names --
+ condition property=gwt.hosts.web.remote
value=${gwt.remote.browsers}
+isset property=gwt.remote.browsers /
+ /condition
+ condition property=gwt.hosts.web.selenium
value=${gwt.selenium.hosts}
+isset property=gwt.selenium.hosts /
+ /condition
+
!-- BrowserManagerServer_Stub compiled using rmic, which doesn't
generate full source code --
property name=emma.filter.exclude value=*BrowserManagerServer_Stub*
/
@@ -100,39 +108,137 @@
/gwt.checkstyle
/target
- target name=remoteweb-test depends=test.remoteweb
-echo message=DEPRECATED: remoteweb-test has been renamed
test.remoteweb/
+ target name=remoteweb-test depends=test.web.remote
+echo message=DEPRECATED: remoteweb-test has been renamed
test.web.remote/
/target
- target name=test.remoteweb description=Run a remoteweb test at the
given host and path if=gwt.remote.browsers
-echo message=Performing remote browser testing at
${gwt.remote.browsers} /
-property name=test.remoteweb.args value=${test.args} /
-fileset id=test.remoteweb.tests dir=${javac.junit.out}
includes=${gwt.junit.testcase.web.includes}
excludes=${gwt.junit.testcase.web.excludes} /
-gwt.junit test.args=${test.args} -out www -runStyle
RemoteWeb:${gwt.remote.browsers} -batch module -precompile parallel
test.out=${junit.out}/remoteweb test.cases=test.remoteweb.tests
+ target name=test.remoteweb depends=test.web.remote
+echo message=DEPRECATED: test.remoteweb has been renamed
test.web.remote/
+ /target
+
+ target name=test.web.remote description=Run a remoteweb test at the
given host and path if=gwt.hosts.web.remote
+echo message=Performing web remote testing at
${gwt.hosts.web.remote} /
+property name=test.web.remote.args value=${test.args} /
+fileset id=test.web.remote.tests dir=${javac.junit.out}
includes=${gwt.junit.testcase.web.includes}
excludes=${gwt.junit.testcase.web.excludes} /
+gwt.junit test.args=${test.args} -web -out www -runStyle
RemoteWeb:${gwt.hosts.web.remote} -batch module -precompile parallel
test.out=${junit.out}/web-remote test.cases=test.web.remote.tests
extraclasspaths
path refid=test.extraclasspath /
/extraclasspaths
/gwt.junit
/target
- target name=selenium-test depends=test.selenium
+ target name=test.dev.remote description=Run a remoteweb test at the
given host and path if=gwt.hosts.dev.remote
+echo message=Performing dev-mode remote testing at
${gwt.remote.browsers} /
+property name=test.dev.remote.args value=${test.args} /
+fileset id=test.dev.remote.tests dir=${javac.junit.out}
includes=${gwt.junit.testcase.hosted.includes}
excludes=${gwt.junit.testcase.hosted.excludes} /
+gwt.junit test.args=${test.args} -out www -runStyle
RemoteWeb:${gwt.hosts.dev.remote} -batch module -precompile parallel
test.out=${junit.out}/dev-remote test.cases=test.dev.remote.tests
+ extraclasspaths
+path refid=test.extraclasspath /
+ /extraclasspaths
+/gwt.junit
+ /target
+
+ target name=test.emma.remote description=Run a remoteweb test at the
given host and path if=gwt.hosts.dev.remote
+echo message=Performing emma remote testing at
${gwt.hosts.dev.remote} /
+property name=test.emma.remote.args value=${test.args} /
+fileset id=test.emma.remote.tests dir=${javac.junit.out}
includes=${gwt.junit.testcase.hosted.emma.includes}
excludes=${gwt.junit.testcase.hosted.emma.excludes} /
+gwt.junit test.args=${test.args} -out www -runStyle
RemoteWeb:${gwt.hosts.dev.remote} -batch module -precompile parallel
test.out=${junit.out}/emma-remote test.cases=test.emma.remote.tests
+ extraclasspaths
+path refid=test.extraclasspath /
+pathelement location=${gwt.tools.redist}/emma/emma.jar /
+ /extraclasspaths
+/gwt.junit
+ /target
+
+ target name=test.emma.selenium description=Run a remoteweb test at
the given host and path if=gwt.hosts.dev.selenium
+echo message=Performing emma selenium testing at
${gwt.hosts.dev.selenium} /
+property name=test.emma.remote.args value=${test.args} /
+
[gwt-contrib] [google-web-toolkit] r6370 committed - Rearrange ant test targets....
Revision: 6370
Author: j...@google.com
Date: Wed Oct 14 00:44:30 2009
Log: Rearrange ant test targets.
The continuous build systems need to have gwt.hosts.dev.remote and
gwt.hosts.dev.selenium set to those hosts which have the devmode plugin
installed for devmode tests to be run at all, until HtmlUnit is made
reliable
enough to enable by default.
Patch by: jat
Review by: amitmanjhi, jlabanca (TBR)
http://code.google.com/p/google-web-toolkit/source/detail?r=6370
Modified:
/trunk/user/build.xml
===
--- /trunk/user/build.xml Tue Oct 13 16:57:19 2009
+++ /trunk/user/build.xml Wed Oct 14 00:44:30 2009
@@ -3,6 +3,14 @@
property name=project.tail value=user /
property name=test.args value= /
+ !-- support old variables names --
+ condition property=gwt.hosts.web.remote
value=${gwt.remote.browsers}
+isset property=gwt.remote.browsers /
+ /condition
+ condition property=gwt.hosts.web.selenium
value=${gwt.selenium.hosts}
+isset property=gwt.selenium.hosts /
+ /condition
+
!-- BrowserManagerServer_Stub compiled using rmic, which doesn't
generate full source code --
property name=emma.filter.exclude value=*BrowserManagerServer_Stub*
/
@@ -13,9 +21,12 @@
property name=gwt.junit.testcase.web.includes
value=${gwt.junit.testcase.includes} /
property name=gwt.junit.testcase.web.excludes value= /
+ property name=gwt.junit.testcase.dev.includes
value=${gwt.junit.testcase.includes} /
+ property name=gwt.junit.testcase.dev.excludes value= /
+
!-- CoverageTest.java fails due to a javac bug in sun/OpenJDK's Java.
See the file contents for details --
- property name=gwt.junit.testcase.hosted.emma.includes
value=**/*Suite.class,com/google/gwt/dev/jjs/test/*Test.class /
- property name=gwt.junit.testcase.hosted.emma.excludes
value=**/CoverageTest.class,**/CompilerSuite.class /
+ property name=gwt.junit.testcase.dev.emma.includes
value=**/*Suite.class,com/google/gwt/dev/jjs/test/*Test.class /
+ property name=gwt.junit.testcase.dev.emma.excludes
value=**/CoverageTest.class,**/CompilerSuite.class /
!-- Only IFrameLinker actually supports -noserver mode; run the other
linker tests if and when they are supported --
property name=gwt.junit.testcase.noserver.includes
value=**/IFrameLinkerTest.class /
@@ -34,10 +45,10 @@
pathelement location=${gwt.build}/out/dev/bin-test /
pathelement location=test-super /
pathelement location=test_i18n_${gwt.i18n.test.InnerClassChar} /
- pathelement location=${gwt.tools.lib}/cglib/cglib-2.2.jar/
- pathelement location=${gwt.tools.lib}/easymock/easymock.jar/
- pathelement
location=${gwt.tools.lib}/easymock/easymockclassextension.jar/
- pathelement location=${gwt.tools.lib}/objectweb/asm-3.1.jar/
+pathelement location=${gwt.tools.lib}/cglib/cglib-2.2.jar/
+pathelement location=${gwt.tools.lib}/easymock/easymock.jar/
+pathelement
location=${gwt.tools.lib}/easymock/easymockclassextension.jar/
+pathelement location=${gwt.tools.lib}/objectweb/asm-3.1.jar/
/path
!-- Platform shouldn't matter here, just picking one --
@@ -90,7 +101,8 @@
/gwt.javac
/target
- target name=build depends=compile description=Build and package
this project
+ target name=build depends=compile
+ description=Build and package this project
mkdir dir=${gwt.build.lib} /
gwt.jar
fileset dir=src excludes=**/package.html /
@@ -110,33 +122,153 @@
/gwt.checkstyle
/target
- target name=test.remoteweb depends=compile, compile.tests
- description=Run a remoteweb test at the given host and path
if=gwt.remote.browsers
-echo message=Performing remote browser testing at
${gwt.remote.browsers} /
-property name=test.remoteweb.args value=${test.args} /
-fileset id=test.remoteweb.tests dir=${javac.junit.out}
includes=${gwt.junit.testcase.web.includes}
excludes=${gwt.junit.testcase.web.excludes} /
-gwt.junit test.args=${test.args} -out www -web -runStyle
RemoteWeb:${gwt.remote.browsers} -batch module -precompile parallel
test.out=${junit.out}/remoteweb test.cases=test.remoteweb.tests
+ target name=test.remoteweb depends=test.web.remote
+echo message=DEPRECATED: test.remoteweb has been renamed
test.web.remote/
+ /target
+
+ target name=test.web.remote
+ description=Run a remoteweb test at the given host and path
+ if=gwt.hosts.web.remote
+echo message=Performing web remote testing at
${gwt.hosts.web.remote} /
+property name=test.web.remote.args value=${test.args} /
+fileset id=test.web.remote.tests dir=${javac.junit.out}
includes=${gwt.junit.testcase.web.includes}
excludes=${gwt.junit.testcase.web.excludes} /
+gwt.junit test.args=${test.args} -out www -web -runStyle
RemoteWeb:${gwt.hosts.web.remote} -batch module -precompile parallel
test.out=${junit.out}/web-remote test.cases=test.web.remote.tests
[gwt-contrib] Refactored DisclosurePanel and better DisclosurePanelParser
Reviewers: jgw, Message: Thanks in advance, Joel. Please review this at http://gwt-code-reviews.appspot.com/78817 Affected files: M user/src/com/google/gwt/uibinder/parsers/DisclosurePanelParser.java M user/src/com/google/gwt/uibinder/rebind/XMLElement.java M user/src/com/google/gwt/uibinder/sample/client/WidgetBasedUi.ui.xml A user/src/com/google/gwt/uibinder/sample/client/down.png A user/src/com/google/gwt/uibinder/sample/client/right.png M user/src/com/google/gwt/user/client/ui/DisclosurePanel.java A user/src/com/google/gwt/user/client/ui/DisclosurePanelHeader.java M user/src/com/google/gwt/user/client/ui/DisclosurePanelImages.java M user/src/com/google/gwt/user/client/ui/DisclosurePanelImagesRTL.java A user/src/com/google/gwt/user/client/ui/OpensAndCloses.java --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: Refactored DisclosurePanel and better DisclosurePanelParser
My 2 c€nts http://gwt-code-reviews.appspot.com/78817/diff/15/1029 File user/src/com/google/gwt/user/client/ui/DisclosurePanel.java (right): http://gwt-code-reviews.appspot.com/78817/diff/15/1029#newcode62 Line 62: super(DOM.createAnchor()); Couldn't you use a FocusImpl instead, and therefore fix issue 1449? (might have implications with using focusable widgets within the header though, particularly when using FocusImplOld, so maybe there rather shouldn't be a ClickableHeader at all within DisclosurePanel, and defer the focus/open/close handling to the header widget instead; and provide a wrapper equivalent to this ClickableHeader for non-focusable/non-clickable widgets) http://gwt-code-reviews.appspot.com/78817 --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: RR : Add lightweight Scheduler API
http://gwt-code-reviews.appspot.com/77820/diff/1004/1005#newcode23
Line 23: public class Scheduler {
The public Scheduler class is now abstract.
http://gwt-code-reviews.appspot.com/77820/diff/1004/1005#newcode123
Line 123: public static void schedulePause() {
schedulePause has been removed.
http://gwt-code-reviews.appspot.com/77820
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---
[gwt-contrib] Re: maximal sharding of builds and linkers
IMPLEMENTATION NOTES This patch updates the Linker API to be shardable. It updates the compiler to deal with this new API, and it updates the built-in linkers to support it. The main API change is that Linker.link has an extra boolean argument. That method is to be called once per permutation with the argument set to true. It is then called at the end of compilation with the argument set to false. Linker classes that don't implement this new method are still supported, but they go through simulated sharding code paths. Additionally, Compiler and GWTCompiler always use simulated sharding. Additionally, to make multi-computer builds more efficient, artifacts are not provided by default to the final call to Linker.link. Instead, artifacts go through a thinning-down process. All EmittedArtifacts are turned into BinaryEmittedArtifacts, thus dropping any extra fields the original artifacts might have had. Other artifacts are simply dropped, unless they are marked as @Transferable. The API change itself is in classes Linker and in the two new annotations Transferable and Shardable. The bulk of the real changes are in class Link. Instead of doLink, there is now doSimulatedShardingLink and doLinkFinal. The former is used if any linkers haven't been updated and so need to have calls to the non-sharding API mixed in. The latter is used when all linkers have been updated and the Precompile/CompilePerms/Link entry points are being used. Link also has new methods related to thinning out the artifact set for transfer from CompilePerms computers to the Link computer: linkOnePermutationToJar and scanJars are the pair used for true sharding, and simulateTransferThinning is used for simulated sharding. CompilePerms and Precompile are updated to support sharded linking in addition to their old code paths. If all linkers have been updated, then Precompile only counts the permutations, CompilePerms does a precompile, and CompilePerms calls the per-permutation part of the new Linker API. If any linker hasn't been updated, then a non-sharded compile is still used. I believe the linker changes are straightforward. Each one is updated to be shardable, and to transfer the minimum possible from CompilePerms to Link. The rest of the patch is a variety of little odds and ends. There is a new little hierarchy of BinaryEmittedArtifacts. Implementations of that abstract class exist for jar entries and for wrapping a preexisting EmittedArtifact. There is one skimpy test case. It checks that if one final linker produces an artifact that other final linkers will see it. This is also a test that PRE/PRIMARY/POST is respected for final linkers. To factor out Link a little bit, the patch adds an OutputFileSet interface. That interface can target a directory or a jar. LinkerContext now has getLinkerShortName(Class) for reasoning about the emitted file names of private linker artifacts. This is needed in final calls to Linker.link because they deal with binary emitted artifacts. Linkers can't know their own short name, because it depends on what the module's gwt.xml file has. LinkerContext also has getModuleScriptReferences() and getModuleStylesheetReferences(). This means we don't have to create artifacts that get passed all the way through to the final link step. I can add it back if necessary, but this way is simple and should run fast. http://gwt-code-reviews.appspot.com/78805 --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: RR : Add lightweight Scheduler API
Assuming you've tested the RESCUE SSW behavior and that Joel likes it, this LGTM. http://gwt-code-reviews.appspot.com/77820 --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: Refactored DisclosurePanel and better DisclosurePanelParser
Broadly, I'm not entirely sure what we're trying to achieve by promoting DisclosurePanelHeader to a public top-level class. It's pretty complex, for a seemingly simple problem. If you were to replace it wholesale within an application, you will pretty much be replacing the entire widget. It seems that being able to (a) replace the images, and (b) replace the header contents with an arbitrary widget, would handle all reasonable use-cases. And it doesn't really solve the problem Thomas mentions with the focusable part of the header (i.e., the anchor) interfering with form elements placed within it. Am I missing something here? http://gwt-code-reviews.appspot.com/78817/diff/15/1029 File user/src/com/google/gwt/user/client/ui/DisclosurePanel.java (right): http://gwt-code-reviews.appspot.com/78817/diff/15/1029#newcode62 Line 62: super(DOM.createAnchor()); On 2009/10/14 12:33:13, t.broyer wrote: Couldn't you use a FocusImpl instead, and therefore fix issue 1449? (might have implications with using focusable widgets within the header though, particularly when using FocusImplOld, so maybe there rather shouldn't be a ClickableHeader at all within DisclosurePanel, and defer the focus/open/close handling to the header widget instead; and provide a wrapper equivalent to this ClickableHeader for non-focusable/non-clickable widgets) I don't actually believe that switching from using an anchor to FocusImpl will make much of a difference. They both have the effect of wrapping the contained widget in a focusable area, which is necessary to make them keyboard-accessible. It's not immediately obvious how we could *both* make the header focusable, *and* not interfere with form elements stuck inside it. http://gwt-code-reviews.appspot.com/78817 --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: Allows multiple sources on a ui:style
On 2009/10/13 21:00:25, Ray Ryan wrote: Another one for you, Joel. This allows multiple source files to be specified for a ui:style, just like any other CssResource. It also allows you to put body text on a ui:style that has sources. The body becomes just one more source file, the last one--nice for local tweaks on centrally defined styles, perhaps. That doesn't actually work yet, though. It exposes a bug on ResourceGeneratorUtil, logged separately. Bob and I figure that fix can happen post MS2, and needn't gate this one. LGTM. http://gwt-code-reviews.appspot.com/77819 --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] RR : GWT 2.0 Bugfix when rewriting static calls with JMultiExpr qualifiers
Reviewers: scottb,
Message:
Review requested. The explanation is longer than the bugfix.
Description:
This fixes a problem where a statically-initialized field could be
referred to before it has been initialized by its clinit.
I found this pattern would result in invalid code generation;
class NiceApi {
static Foo IMPL = new FooImpl();
static NiceApi get() { return IMPL; }
interface InnerIntf {}
abstract void instance(InnerIntf inner);
}
class NiceApiImpl extends NiceApi {
static Object SOME_FIELD = new Object();
void instance(InnerIntf inner) {
instanceImpl(innerIntf);
}
static void instanceImpl(InnerIntf inner) {
SOME_FIELD.doSomething(inner);
}
}
could get reduced to
doSomething(SOME_FIELD, (FooImplClinit(), moreCode));
Please review this at http://gwt-code-reviews.appspot.com/78818
Affected files:
M dev/core/src/com/google/gwt/dev/jjs/impl/MakeCallsStatic.java
Index: dev/core/src/com/google/gwt/dev/jjs/impl/MakeCallsStatic.java
diff --git a/dev/core/src/com/google/gwt/dev/jjs/impl/MakeCallsStatic.java
b/dev/core/src/com/google/gwt/dev/jjs/impl/MakeCallsStatic.java
index
7a7f6b8481c606693a634d9ae1219c56444d2437..1fe417ad801aef52a677c146aece7f5744c91e68
100644
--- a/dev/core/src/com/google/gwt/dev/jjs/impl/MakeCallsStatic.java
+++ b/dev/core/src/com/google/gwt/dev/jjs/impl/MakeCallsStatic.java
@@ -19,6 +19,7 @@ import com.google.gwt.dev.jjs.SourceInfo;
import com.google.gwt.dev.jjs.ast.Context;
import com.google.gwt.dev.jjs.ast.JAbstractMethodBody;
import com.google.gwt.dev.jjs.ast.JClassType;
+import com.google.gwt.dev.jjs.ast.JExpression;
import com.google.gwt.dev.jjs.ast.JMethod;
import com.google.gwt.dev.jjs.ast.JMethodBody;
import com.google.gwt.dev.jjs.ast.JMethodCall;
@@ -31,6 +32,7 @@ import com.google.gwt.dev.jjs.ast.JStatement;
import com.google.gwt.dev.jjs.ast.JThisRef;
import com.google.gwt.dev.jjs.ast.JType;
import com.google.gwt.dev.jjs.ast.JVisitor;
+import com.google.gwt.dev.jjs.ast.js.JMultiExpression;
import com.google.gwt.dev.jjs.ast.js.JsniMethodBody;
import com.google.gwt.dev.js.ast.JsContext;
import com.google.gwt.dev.js.ast.JsExpression;
@@ -320,15 +322,31 @@ public class MakeCallsStatic {
return new MakeCallsStatic(program).execImpl();
}
- static JMethodCall makeStaticCall(JMethodCall x, JMethod newMethod) {
+ static JExpression makeStaticCall(JMethodCall x, JMethod newMethod) {
// Update the call site
JMethodCall newCall = new JMethodCall(x.getSourceInfo().makeChild(
MakeCallsStatic.class, Devirtualized function call), null,
newMethod);
-// The qualifier becomes the first arg
-newCall.addArg(x.getInstance());
-newCall.addArgs(x.getArgs());
-return newCall;
+/*
+ * If the qualifier is a JMultiExpression, invoke on the last value.
This
+ * ensures that clinits maintain the same execution order relative to
+ * parameters in deeply-inlined scenarios.
+ */
+// (a, b).foo() -- (a, foo(b))
+if (x.getInstance() instanceof JMultiExpression) {
+ JMultiExpression multi = (JMultiExpression) x.getInstance();
+ int lastIndex = multi.exprs.size() - 1;
+ newCall.addArg(multi.exprs.get(lastIndex));
+ newCall.addArgs(x.getArgs());
+ multi.exprs.set(lastIndex, newCall);
+ return multi;
+} else {
+ // The qualifier becomes the first arg
+ // a.foo(b) -- foo(a,b)
+ newCall.addArg(x.getInstance());
+ newCall.addArgs(x.getArgs());
+ return newCall;
+}
}
protected SetJMethod toBeMadeStatic = new HashSetJMethod();
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---
[gwt-contrib] Re: RR : Make StyleInjector use Scheduler.scheduleFinally() API
On 2009/10/14 04:58:42, bruce wrote: LGTM with a typo fix. An idea for an incredibly trivial improvement if you just want to change something more for the heck of it. http://gwt-code-reviews.appspot.com/78816/diff/1/2 File user/src/com/google/gwt/dom/client/StyleInjector.java (right): http://gwt-code-reviews.appspot.com/78816/diff/1/2#newcode341 Line 341: * The codewith/code parameter is used to support the deprecated API. with = which http://gwt-code-reviews.appspot.com/78816/diff/1/4 File user/test/com/google/gwt/dom/client/StyleInjectorTest.java (right): http://gwt-code-reviews.appspot.com/78816/diff/1/4#newcode136 Line 136: delayTestFinish(500); (Ignore if you please) The '500' here seems like it wants to be a symbolic constants, along with the other bare '500's elsewhere in the file. LGTM2. http://gwt-code-reviews.appspot.com/78816 --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Comment on UiBinderI18n in google-web-toolkit
Comment by benzheren:
I am following example on wiki:
http://code.google.com/p/google-web-toolkit/wiki/UiBinderI18n
to try out UiBinderi18n in the latest 2.0 MS 1 release. I wrote a
sample ui.xml file like this:
{{{
?xml version=1.0 encoding=UTF-8?
ui:UiBinder xmlns:ui='urn:ui:com.google.gwt.uibinder'
xmlns:g='urn:import:com.google.gwt.user.client.ui'
ui:defaultLocale=en_us
ui:generateKeys=com.google.gwt.i18n.rebind.keygen.MD5KeyGenerator
ui:generateFormat=com.google.gwt.i18n.rebind.format.PropertiesFormat
ui:generateFilename=myapp_translate_source
ui:generateLocales=default
g:HTMLPanel
table align=center
tbody
tr
td style=font-weight: bold;
colspan=2
ui:msg
key=enterYourNamePlease enter your name:/ui:msg
/td
/tr
tr
td id=nameFieldContainer
g:TextBox
ui:field=nameField /
/td
td id=sendButtonContainer
g:Button
ui:field=sendButton text=Send /
/td
/tr
/tbody
/table
/g:HTMLPanel
/ui:UiBinder
}}}
But it does not generate any file, shall I do something extra to make
it work?
Thanks!
For more information:
http://code.google.com/p/google-web-toolkit/wiki/UiBinderI18n
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---
[gwt-contrib] Re: Refactored DisclosurePanel and better DisclosurePanelParser
First, sorry to throw something like this at you at the last second. What was that Bruce said about getting enough sleep and making good decisions? The other goal, which I realize know I didn't hit, was to be able to put the stock header in one spot and the panel it opens or closes in another spot. It's something I've had to do in real apps surprisingly often, and I thought I saw an easy way to get there. But because DisclosurePanelHeader isn't master of its own clickiness, that's a fail. I'll put DPanel back the way it was, but using ImageResource. (Thanks to git I have that exact spot working already in my local repository.) While we're chatting, what do you like better: g:DisclosurePanel g:header Whoopie doo /g:header g:LabelI am the hidden part/g:Label /g:DisclosurePanel or g:DisclosurePanel g:header Whoopie doo /g:header g:body g:LabelI am the hidden part/g:Label /g:body /g:DisclosurePanel I implemented the former, but know I think the latter is better. On Wed, Oct 14, 2009 at 8:43 AM, j...@google.com wrote: Broadly, I'm not entirely sure what we're trying to achieve by promoting DisclosurePanelHeader to a public top-level class. It's pretty complex, for a seemingly simple problem. If you were to replace it wholesale within an application, you will pretty much be replacing the entire widget. It seems that being able to (a) replace the images, and (b) replace the header contents with an arbitrary widget, would handle all reasonable use-cases. And it doesn't really solve the problem Thomas mentions with the focusable part of the header (i.e., the anchor) interfering with form elements placed within it. Am I missing something here? http://gwt-code-reviews.appspot.com/78817/diff/15/1029 File user/src/com/google/gwt/user/client/ui/DisclosurePanel.java (right): http://gwt-code-reviews.appspot.com/78817/diff/15/1029#newcode62 Line 62: super(DOM.createAnchor()); On 2009/10/14 12:33:13, t.broyer wrote: Couldn't you use a FocusImpl instead, and therefore fix issue 1449? (might have implications with using focusable widgets within the header though, particularly when using FocusImplOld, so maybe there rather shouldn't be a ClickableHeader at all within DisclosurePanel, and defer the focus/open/close handling to the header widget instead; and provide a wrapper equivalent to this ClickableHeader for non-focusable/non-clickable widgets) I don't actually believe that switching from using an anchor to FocusImpl will make much of a difference. They both have the effect of wrapping the contained widget in a focusable area, which is necessary to make them keyboard-accessible. It's not immediately obvious how we could *both* make the header focusable, *and* not interfere with form elements stuck inside it. http://gwt-code-reviews.appspot.com/78817 --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: Refactored DisclosurePanel and better DisclosurePanelParser
On 2009/10/14 15:43:38, jgw wrote: Broadly, I'm not entirely sure what we're trying to achieve by promoting DisclosurePanelHeader to a public top-level class. It's pretty complex, for a seemingly simple problem. If you were to replace it wholesale within an application, you will pretty much be replacing the entire widget. It seems that being able to (a) replace the images, and (b) replace the header contents with an arbitrary widget, would handle all reasonable use-cases. Say I want to add an online indicator as in the chat panel in GMail? or I want to add a button in the header (my use case: I have a disclosure panel for data filters, much similar to GMail saved searches or labels, and initially I'd have liked to put the create filter button in the header, but that would have meant re-implementing the image toggle, so I gave up in included it within the disclosure panel's content)? also think about Reader's menu in its left pane panels. And it doesn't really solve the problem Thomas mentions with the focusable part of the header (i.e., the anchor) interfering with form elements placed within it. The only issue if you replace the anchor with a FocusImpl is in the case it is a FocusImplOld (i.e. in WebKit, although Safari 4 and Chrome 3 now correctly implement tabIndex as a way to make any element focusable –I don't know about mobile webkits such as the iPhone and Android, but they're not officially supported afaik–, and in old gecko, which was still supported only because of the hosted mode), because it'll steal the focus from a focusable child (see issue 1471) http://gwt-code-reviews.appspot.com/78817/diff/15/1029 File user/src/com/google/gwt/user/client/ui/DisclosurePanel.java (right): http://gwt-code-reviews.appspot.com/78817/diff/15/1029#newcode62 Line 62: super(DOM.createAnchor()); On 2009/10/14 15:43:39, jgw wrote: I don't actually believe that switching from using an anchor to FocusImpl will make much of a difference. They both have the effect of wrapping the contained widget in a focusable area, which is necessary to make them keyboard-accessible. but the anchor impacts your CSS, as you'll inherit its color:blue style in your header text. It's not immediately obvious how we could *both* make the header focusable, *and* not interfere with form elements stuck inside it. Hence my other proposition, to have two public disclosure headers: one that can only contain text, as is the case today, and one that can contain widget (in this case, only the image is focusable and clickable). And if you want to replace the whole header with your own (which handles the image display, as of today), that's still possible, but you'd also have to handle focusability and clicks (for backwards compatibility, widgets that do not implement OpensAndCloses –or should it be OpensAndCloses.Handler?– would automatically be wrapped within a special, private header based on e.g. a FocusPanel). http://gwt-code-reviews.appspot.com/78817 --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: Refactored DisclosurePanel and better DisclosurePanelParser
Thomas, this all makes sense but I don't think we can make it happen for 2.0. Certainly not MS2, and probably not for the RC (though it's tempting, DisclosurePanel is so close to being so much more useful). Do you mind creating an issue on the public tracker capturing this? On Wed, Oct 14, 2009 at 9:45 AM, t.bro...@gmail.com wrote: On 2009/10/14 15:43:38, jgw wrote: Broadly, I'm not entirely sure what we're trying to achieve by promoting DisclosurePanelHeader to a public top-level class. It's pretty complex, for a seemingly simple problem. If you were to replace it wholesale within an application, you will pretty much be replacing the entire widget. It seems that being able to (a) replace the images, and (b) replace the header contents with an arbitrary widget, would handle all reasonable use-cases. Say I want to add an online indicator as in the chat panel in GMail? or I want to add a button in the header (my use case: I have a disclosure panel for data filters, much similar to GMail saved searches or labels, and initially I'd have liked to put the create filter button in the header, but that would have meant re-implementing the image toggle, so I gave up in included it within the disclosure panel's content)? also think about Reader's menu in its left pane panels. And it doesn't really solve the problem Thomas mentions with the focusable part of the header (i.e., the anchor) interfering with form elements placed within it. The only issue if you replace the anchor with a FocusImpl is in the case it is a FocusImplOld (i.e. in WebKit, although Safari 4 and Chrome 3 now correctly implement tabIndex as a way to make any element focusable –I don't know about mobile webkits such as the iPhone and Android, but they're not officially supported afaik–, and in old gecko, which was still supported only because of the hosted mode), because it'll steal the focus from a focusable child (see issue 1471) http://gwt-code-reviews.appspot.com/78817/diff/15/1029 File user/src/com/google/gwt/user/client/ui/DisclosurePanel.java (right): http://gwt-code-reviews.appspot.com/78817/diff/15/1029#newcode62 Line 62: super(DOM.createAnchor()); On 2009/10/14 15:43:39, jgw wrote: I don't actually believe that switching from using an anchor to FocusImpl will make much of a difference. They both have the effect of wrapping the contained widget in a focusable area, which is necessary to make them keyboard-accessible. but the anchor impacts your CSS, as you'll inherit its color:blue style in your header text. It's not immediately obvious how we could *both* make the header focusable, *and* not interfere with form elements stuck inside it. Hence my other proposition, to have two public disclosure headers: one that can only contain text, as is the case today, and one that can contain widget (in this case, only the image is focusable and clickable). And if you want to replace the whole header with your own (which handles the image display, as of today), that's still possible, but you'd also have to handle focusability and clicks (for backwards compatibility, widgets that do not implement OpensAndCloses –or should it be OpensAndCloses.Handler?– would automatically be wrapped within a special, private header based on e.g. a FocusPanel). http://gwt-code-reviews.appspot.com/78817 --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: RR : Add lightweight Scheduler API
Yes, please, please, please make this instance based. Every serious app I've seen winds up creating its own interface to wrap around our static calls to make them testable (and the ones on commands in particular), and it's generally a painful retrofit. It also becomes a real difficultly for those writing test runners. On Wed, Oct 14, 2009 at 7:32 AM, br...@google.com wrote: Assuming you've tested the RESCUE SSW behavior and that Joel likes it, this LGTM. http://gwt-code-reviews.appspot.com/77820 --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: RR : Add lightweight Scheduler API
On Wed, Oct 14, 2009 at 1:03 PM, Ray Ryan rj...@google.com wrote: Yes, please, please, please make this instance based. Every serious app I've seen winds up creating its own interface to wrap around our static calls to make them testable (and the ones on commands in particular), and it's generally a painful retrofit. It also becomes a real difficultly for those writing test runners. The current version of the patch is instance-based. I assume it's ok to have Scheduler be an abstract base class? -- Bob Vawter Google Web Toolkit Team --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: RR : Add lightweight Scheduler API
On Wed, Oct 14, 2009 at 10:04 AM, BobV b...@google.com wrote: On Wed, Oct 14, 2009 at 1:03 PM, Ray Ryan rj...@google.com wrote: Yes, please, please, please make this instance based. Every serious app I've seen winds up creating its own interface to wrap around our static calls to make them testable (and the ones on commands in particular), and it's generally a painful retrofit. It also becomes a real difficultly for those writing test runners. The current version of the patch is instance-based. I assume it's ok to have Scheduler be an abstract base class? Would I be able to mock it out in a JRE test? If not, providing an interface that the base class implements would be very helpful. -- Bob Vawter Google Web Toolkit Team --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: RR : Add lightweight Scheduler API
LGTM On Wed, Oct 14, 2009 at 10:06 AM, Ray Ryan rj...@google.com wrote: On Wed, Oct 14, 2009 at 10:04 AM, BobV b...@google.com wrote: On Wed, Oct 14, 2009 at 1:03 PM, Ray Ryan rj...@google.com wrote: Yes, please, please, please make this instance based. Every serious app I've seen winds up creating its own interface to wrap around our static calls to make them testable (and the ones on commands in particular), and it's generally a painful retrofit. It also becomes a real difficultly for those writing test runners. The current version of the patch is instance-based. I assume it's ok to have Scheduler be an abstract base class? Would I be able to mock it out in a JRE test? If not, providing an interface that the base class implements would be very helpful. -- Bob Vawter Google Web Toolkit Team --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: Refactored DisclosurePanel and better DisclosurePanelParser
How's this sound for a proposal to wrap all this up, then:- Drop the public DisclosureHeader class, as Ray suggested earlier. - Implement the g:header/g:body/ version of the parser (I agree it's probably clearer). - Create a separate issue (possibly eclipsing issue 1449, possibly simply clarifying it), that captures the desire to be able to add focusable widgets to the header without conflicting with the anchor. ? On Wed, Oct 14, 2009 at 12:55 PM, Ray Ryan rj...@google.com wrote: Thomas, this all makes sense but I don't think we can make it happen for 2.0. Certainly not MS2, and probably not for the RC (though it's tempting, DisclosurePanel is so close to being so much more useful). Do you mind creating an issue on the public tracker capturing this? On Wed, Oct 14, 2009 at 9:45 AM, t.bro...@gmail.com wrote: On 2009/10/14 15:43:38, jgw wrote: Broadly, I'm not entirely sure what we're trying to achieve by promoting DisclosurePanelHeader to a public top-level class. It's pretty complex, for a seemingly simple problem. If you were to replace it wholesale within an application, you will pretty much be replacing the entire widget. It seems that being able to (a) replace the images, and (b) replace the header contents with an arbitrary widget, would handle all reasonable use-cases. Say I want to add an online indicator as in the chat panel in GMail? or I want to add a button in the header (my use case: I have a disclosure panel for data filters, much similar to GMail saved searches or labels, and initially I'd have liked to put the create filter button in the header, but that would have meant re-implementing the image toggle, so I gave up in included it within the disclosure panel's content)? also think about Reader's menu in its left pane panels. And it doesn't really solve the problem Thomas mentions with the focusable part of the header (i.e., the anchor) interfering with form elements placed within it. The only issue if you replace the anchor with a FocusImpl is in the case it is a FocusImplOld (i.e. in WebKit, although Safari 4 and Chrome 3 now correctly implement tabIndex as a way to make any element focusable –I don't know about mobile webkits such as the iPhone and Android, but they're not officially supported afaik–, and in old gecko, which was still supported only because of the hosted mode), because it'll steal the focus from a focusable child (see issue 1471) http://gwt-code-reviews.appspot.com/78817/diff/15/1029 File user/src/com/google/gwt/user/client/ui/DisclosurePanel.java (right): http://gwt-code-reviews.appspot.com/78817/diff/15/1029#newcode62 Line 62: super(DOM.createAnchor()); On 2009/10/14 15:43:39, jgw wrote: I don't actually believe that switching from using an anchor to FocusImpl will make much of a difference. They both have the effect of wrapping the contained widget in a focusable area, which is necessary to make them keyboard-accessible. but the anchor impacts your CSS, as you'll inherit its color:blue style in your header text. It's not immediately obvious how we could *both* make the header focusable, *and* not interfere with form elements stuck inside it. Hence my other proposition, to have two public disclosure headers: one that can only contain text, as is the case today, and one that can contain widget (in this case, only the image is focusable and clickable). And if you want to replace the whole header with your own (which handles the image display, as of today), that's still possible, but you'd also have to handle focusability and clicks (for backwards compatibility, widgets that do not implement OpensAndCloses –or should it be OpensAndCloses.Handler?– would automatically be wrapped within a special, private header based on e.g. a FocusPanel). http://gwt-code-reviews.appspot.com/78817 --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] [google-web-toolkit] r6372 committed - Clean up formatting and ant -p output in ant build files....
Revision: 6372
Author: j...@google.com
Date: Wed Oct 14 11:08:29 2009
Log: Clean up formatting and ant -p output in ant build files.
Patch by: jat
Review by: jlabanca (desk)
http://code.google.com/p/google-web-toolkit/source/detail?r=6372
Modified:
/trunk/common.ant.xml
/trunk/user/build.xml
===
--- /trunk/common.ant.xml Tue Oct 13 16:57:19 2009
+++ /trunk/common.ant.xml Wed Oct 14 11:08:29 2009
@@ -340,13 +340,15 @@
taskdef resource=emma_ant.properties classpathref=emma.taskdef.lib
/
- target name=compile.emma.if.enabled description=Instruments emma
classes unless=emma.compiled
+ !-- Instruments emma classes --
+ target name=compile.emma.if.enabled unless=emma.compiled
delete dir=${javac.emma.out} /
property name=emma.compiled value=true /
antcall target=-compile.emma.if.enabled /
/target
- target name=-compile.emma.if.enabled description=Instruments emma
classes if=emma.enabled
+ !-- Instruments emma classes --
+ target name=-compile.emma.if.enabled if=emma.enabled
mkdir dir=${javac.emma.out} /
path id=emma.classpath
pathelement location=${javac.out} /
@@ -359,7 +361,8 @@
/emma
/target
- target name=-create.emma.coverage.if.enabled description=Create the
emma coverage directory if=emma.enabled
+ !-- Create the emma coverage directory --
+ target name=-create.emma.coverage.if.enabled if=emma.enabled
delete dir=${test.emma.coverage} /
mkdir dir=${test.emma.coverage} /
/target
@@ -367,7 +370,8 @@
!-- Default implementations of the required targets; projects should
override the ones that matter --
target name=all depends=verify /
- target name=verify depends=checkstyle, test description=Runs tests
and checkstyle static analysis /
+ target name=verify depends=checkstyle, test
+ description=Runs tests and checkstyle static analysis /
target name=checkstyle /
target name=test depends=build /
target name=build /
===
--- /trunk/user/build.xml Wed Oct 14 08:30:35 2009
+++ /trunk/user/build.xml Wed Oct 14 11:08:29 2009
@@ -11,7 +11,10 @@
isset property=gwt.selenium.hosts /
/condition
- !-- BrowserManagerServer_Stub compiled using rmic, which doesn't
generate full source code --
+ !--
+BrowserManagerServer_Stub compiled using rmic, which doesn't generate
+full source code
+ --
property name=emma.filter.exclude value=*BrowserManagerServer_Stub*
/
import file=${gwt.root}/common.ant.xml /
@@ -24,15 +27,21 @@
property name=gwt.junit.testcase.dev.includes
value=${gwt.junit.testcase.includes} /
property name=gwt.junit.testcase.dev.excludes value= /
- !-- CoverageTest.java fails due to a javac bug in sun/OpenJDK's Java.
See the file contents for details --
+ !--
+CoverageTest.java fails due to a javac bug in sun/OpenJDK's Java. See
the
+file contents for details
+ --
property name=gwt.junit.testcase.dev.emma.includes
value=**/*Suite.class,com/google/gwt/dev/jjs/test/*Test.class /
property name=gwt.junit.testcase.dev.emma.excludes
value=**/CoverageTest.class,**/CompilerSuite.class /
- !-- Only IFrameLinker actually supports -noserver mode; run the other
linker tests if and when they are supported --
+ !--
+Only IFrameLinker actually supports -noserver mode; run the other
linker
+tests if and when they are supported
+ --
property name=gwt.junit.testcase.noserver.includes
value=**/IFrameLinkerTest.class /
property name=gwt.junit.testcase.noserver.excludes value= /
- !--
+ !--
Whether I18NSuite should test e.g. Foo$InnerMsgs_fr.properties (if the
value is dollar) or Foo_Inner_fr.properties (for bar)
--
@@ -70,22 +79,26 @@
!-- Build the BrowserManagerServer_Stub to allow remote browser
testing --
rmic base=${javac.out}
-
classname=com.google.gwt.junit.remote.BrowserManagerServer
- stubversion=1.2/
+classname=com.google.gwt.junit.remote.BrowserManagerServer
+stubversion=1.2/
/target
!--
Compile test code for dev to pick up TypeOracleTestUtils and others.
+Compiles test dependencies in dev/core
--
- target name=compile.dev.tests description=Compiles test dependencies
in dev/core
+ target name=compile.dev.tests
gwt.ant dir=../dev target=compile.tests /
/target
+ !--
+ Compiles the test code for this project
+ --
target name=compile.tests
-depends=compile.dev.tests, compile.emma.if.enabled
-description=Compiles the test code for this project
+ depends=compile.dev.tests, compile.emma.if.enabled
mkdir dir=${javac.junit.out} /
-gwt.javac srcdir=test excludes=com/google/gwt/langtest/**
destdir=${javac.junit.out}
+gwt.javac srcdir=test excludes=com/google/gwt/langtest/**
+destdir=${javac.junit.out}
classpath
pathelement
[gwt-contrib] Re: Refactored DisclosurePanel and better DisclosurePanelParser
On 2009/10/14 16:45:38, t.broyer wrote: On 2009/10/14 15:43:38, jgw wrote: Broadly, I'm not entirely sure what we're trying to achieve by promoting DisclosurePanelHeader to a public top-level class. It's pretty complex, for a seemingly simple problem. If you were to replace it wholesale within an application, you will pretty much be replacing the entire widget. It seems that being able to (a) replace the images, and (b) replace the header contents with an arbitrary widget, would handle all reasonable use-cases. Say I want to add an online indicator as in the chat panel in GMail? or I want to add a button in the header (my use case: I have a disclosure panel for data filters, much similar to GMail saved searches or labels, and initially I'd have liked to put the create filter button in the header, but that would have meant re-implementing the image toggle, so I gave up in included it within the disclosure panel's content)? also think about Reader's menu in its left pane panels. And it doesn't really solve the problem Thomas mentions with the focusable part of the header (i.e., the anchor) interfering with form elements placed within it. The only issue if you replace the anchor with a FocusImpl is in the case it is a FocusImplOld (i.e. in WebKit, although Safari 4 and Chrome 3 now correctly implement tabIndex as a way to make any element focusable –I don't know about mobile webkits such as the iPhone and Android, but they're not officially supported afaik–, and in old gecko, which was still supported only because of the hosted mode), because it'll steal the focus from a focusable child (see issue 1471) http://gwt-code-reviews.appspot.com/78817/diff/15/1029 File user/src/com/google/gwt/user/client/ui/DisclosurePanel.java (right): http://gwt-code-reviews.appspot.com/78817/diff/15/1029#newcode62 Line 62: super(DOM.createAnchor()); On 2009/10/14 15:43:39, jgw wrote: I don't actually believe that switching from using an anchor to FocusImpl will make much of a difference. They both have the effect of wrapping the contained widget in a focusable area, which is necessary to make them keyboard-accessible. but the anchor impacts your CSS, as you'll inherit its color:blue style in your header text. It's not immediately obvious how we could *both* make the header focusable, *and* not interfere with form elements stuck inside it. Hence my other proposition, to have two public disclosure headers: one that can only contain text, as is the case today, and one that can contain widget (in this case, only the image is focusable and clickable). And if you want to replace the whole header with your own (which handles the image display, as of today), that's still possible, but you'd also have to handle focusability and clicks (for backwards compatibility, widgets that do not implement OpensAndCloses –or should it be OpensAndCloses.Handler?– would automatically be wrapped within a special, private header based on e.g. a FocusPanel). [Repeat of what I said earlier on email but should have said here] How's this sound for a proposal to wrap all this up, then: - Drop the public DisclosureHeader class, as Ray suggested earlier. - Implement the g:header/g:body/ version of the parser (I agree it's probably clearer). - Create a separate issue (possibly eclipsing issue 1449, possibly simply clarifying it), that captures the desire to be able to add focusable widgets to the header without conflicting with the anchor. ? http://gwt-code-reviews.appspot.com/78817 --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: RR : GWT 2.0 Bugfix when rewriting static calls with JMultiExpr qualifiers
Bob, this patch looks good. But I have to admit I can't understand why
it's currently broken.
Explain to me again why this transformation breaks?
(a, b).foo() -- foo((a,b))
I didn't completely follow the pattern you showed.
http://gwt-code-reviews.appspot.com/78818/diff/1/2
File dev/core/src/com/google/gwt/dev/jjs/impl/MakeCallsStatic.java
(right):
http://gwt-code-reviews.appspot.com/78818/diff/1/2#newcode336
Line 336: if (x.getInstance() instanceof JMultiExpression) {
Nitpick: can you swap these two lines?
http://gwt-code-reviews.appspot.com/78818
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---
[gwt-contrib] Re: RR : GWT 2.0 Bugfix when rewriting static calls with JMultiExpr qualifiers
Also: test case por favor? http://gwt-code-reviews.appspot.com/78818 --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] [google-web-toolkit] r6373 committed - Edited wiki page through web user interface.
Revision: 6373
Author: tamplinjohn
Date: Wed Oct 14 12:02:28 2009
Log: Edited wiki page through web user interface.
http://code.google.com/p/google-web-toolkit/source/detail?r=6373
Modified:
/wiki/UsingOOPHM.wiki
===
--- /wiki/UsingOOPHM.wiki Tue Oct 13 17:10:54 2009
+++ /wiki/UsingOOPHM.wiki Wed Oct 14 12:02:28 2009
@@ -38,26 +38,8 @@
Download and run the
[http://google-web-toolkit.googlecode.com/svn/trunk/plugins/ie/prebuilt/GwtDevModeIePluginInstaller.msi
GWT Dev Mode Plugin for IE] installer.
= Using OOPHM =
-OOPHM is currently in trunk (it is not and will not be available with any
version of GWT earlier than 2.0), but is not enabled by default because the
UI needs some work and some features are missing, plus it just hasn't had
enough testing to be sure it is completely usable as a replacement. So, to
use it now, you need to add gwt-dev-oophm.jar at the beginning of your
classpath. There are a number of ways to do it:
-
-== Getting the right Classpath ==
-
- * *webAppCreator*
- If you are creating a war-style project, you can just use webAppCreator
and it will generate an ant target oophm for you. You can just run ant
oophm and it will run your application using OOPHM instead of legacy
hosted mode. If you have an existing project, you can delete the build.xml
file and then run webAppCreator with -ignore and it won't overwrite any
existing files.
-
- * *Eclipse*
- If you have an existing launch config for Eclipse, simply edit the
classpath for that launch config and add gwt-dev-oophm.jar at the top of
the classpath.
-
-blockquote _Life is more complicated if you are running Eclipse on a
Macintosh, and working with GWT source rather than release jars. In that
case you will need to make sure that -XstartOnFirstThread is not in your
launch config arguments, and you will have to remove the SWT jar from your
gwt-dev-mac project._
-
-_However, if you want to run legacy hosted mode again (e.g. to run a
GWTTestCase), you will have to restore the SWT jar to gwt-dev-mac_
-
-_Here's a recipe: OophmForMacBasedGwtContributors_ /blockquote
-
- * *Others*
- Basically, wherever you set the classpath that includes
gwt-dev-{platform}.jar, make sure that gwt-dev-oophm.jar is searched before
the platform-specific jar.
-
-== Running ==
-Just execute the GWTShell or !HostedMode classes as usual. A swing UI
will show up and it will try and launch firefox with the proper URL -- it
does this by just running firefox URL, so if you don't have the path set
properly or if you need to run a different executable it will fail -- in
that case, just copy the URL from the log window and paste it in the
browser you want to use.
+OOPHM is currently in trunk (it is not and will not be available with any
version of GWT earlier than 2.0), and is now enabled by default.
+
+If you are using the Eclipse plugin, you may need to manually create a
plain Java launch config until version 1.2 is available (1.12 has some
support).
Note that calls between Java and JS are synchronous, and that means the
plugin has to block the browser while a Java method is executing. If you
are debugging your Java code, the browser will appear hung until you return
back to browser-side code.
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---
[gwt-contrib] Add a HelpInfo link for old plugins
Reviewers: amitmanjhi,
Description:
A warning is printed when a really old plugin connects to the code
server. This adds a HelpInfo link, which points at the UsingOOPHM web
page for now, giving users information about getting a later plugin.
In the future, this will be changed to a better location.
Please review this at http://gwt-code-reviews.appspot.com/78819
Affected files:
dev/oophm/src/com/google/gwt/dev/shell/BrowserChannelServer.java
Index: dev/oophm/src/com/google/gwt/dev/shell/BrowserChannelServer.java
===
--- dev/oophm/src/com/google/gwt/dev/shell/BrowserChannelServer.java
(revision 6372)
+++ dev/oophm/src/com/google/gwt/dev/shell/BrowserChannelServer.java
(working copy)
@@ -16,12 +16,15 @@
package com.google.gwt.dev.shell;
import com.google.gwt.core.ext.TreeLogger;
+import com.google.gwt.core.ext.TreeLogger.HelpInfo;
import com.google.gwt.dev.shell.JsValue.DispatchObject;
import java.io.IOException;
import java.io.InputStream;
import java.io.OutputStream;
+import java.net.MalformedURLException;
import java.net.Socket;
+import java.net.URL;
import java.util.HashMap;
import java.util.Map;
import java.util.Set;
@@ -233,8 +236,27 @@
moduleName = oldLoadModule.getModuleName();
userAgent = oldLoadModule.getUserAgent();
protocolVersion = 1;
+HelpInfo helpInfo = new HelpInfo() {
+ @Override
+ public String getAnchorText() {
+return UsingOOPHM wiki page;
+ }
+
+ @Override
+ public URL getURL() {
+try {
+ // TODO(jat): better landing page for more info
+ return new URL(
+
http://code.google.com/p/google-web-toolkit/wiki/UsingOOPHM;);
+} catch (MalformedURLException e) {
+ // can't happen
+ return null;
+}
+ }
+};
logger.log(TreeLogger.WARN, Connection from old browser plugin
--
-+ please upgrade to a later version for full functionality);
++ please upgrade to a later version for full functionality,
null,
+helpInfo);
break;
case CHECK_VERSIONS:
String connectError = null;
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---
[gwt-contrib] Re: Proposed API Addition - @WithModuleParameters on test cases
I've uploaded another patch set, which merges in the latest changes from the trunk. On Mon, Oct 12, 2009 at 2:34 AM, John Tamplin j...@google.com wrote: On Mon, Oct 12, 2009 at 12:03 AM, John LaBanca jlaba...@google.comwrote: @jat - When do you think we'll merge the htmlunit branch into trunk so we can check in this patch? We are supposed to ship MS2 on Wednesday, so it has to be real soon. -- John A. Tamplin Software Engineer (GWT), Google --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: Add a HelpInfo link for old plugins
LGTM
On Wed, Oct 14, 2009 at 12:05 PM, j...@google.com wrote:
Reviewers: amitmanjhi,
Description:
A warning is printed when a really old plugin connects to the code
server. This adds a HelpInfo link, which points at the UsingOOPHM web
page for now, giving users information about getting a later plugin.
In the future, this will be changed to a better location.
Please review this at http://gwt-code-reviews.appspot.com/78819
Affected files:
dev/oophm/src/com/google/gwt/dev/shell/BrowserChannelServer.java
Index: dev/oophm/src/com/google/gwt/dev/shell/BrowserChannelServer.java
===
--- dev/oophm/src/com/google/gwt/dev/shell/BrowserChannelServer.java
(revision 6372)
+++ dev/oophm/src/com/google/gwt/dev/shell/BrowserChannelServer.java
(working copy)
@@ -16,12 +16,15 @@
package com.google.gwt.dev.shell;
import com.google.gwt.core.ext.TreeLogger;
+import com.google.gwt.core.ext.TreeLogger.HelpInfo;
import com.google.gwt.dev.shell.JsValue.DispatchObject;
import java.io.IOException;
import java.io.InputStream;
import java.io.OutputStream;
+import java.net.MalformedURLException;
import java.net.Socket;
+import java.net.URL;
import java.util.HashMap;
import java.util.Map;
import java.util.Set;
@@ -233,8 +236,27 @@
moduleName = oldLoadModule.getModuleName();
userAgent = oldLoadModule.getUserAgent();
protocolVersion = 1;
+HelpInfo helpInfo = new HelpInfo() {
+ @Override
+ public String getAnchorText() {
+return UsingOOPHM wiki page;
+ }
+
+ @Override
+ public URL getURL() {
+try {
+ // TODO(jat): better landing page for more info
+ return new URL(
+
http://code.google.com/p/google-web-toolkit/wiki/UsingOOPHM;);
+} catch (MalformedURLException e) {
+ // can't happen
+ return null;
+}
+ }
+};
logger.log(TreeLogger.WARN, Connection from old browser plugin --
-+ please upgrade to a later version for full functionality);
++ please upgrade to a later version for full functionality,
null,
+helpInfo);
break;
case CHECK_VERSIONS:
String connectError = null;
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---
[gwt-contrib] Re: Proposed API Addition - @WithModuleParameters on test cases
@John L: You taking this one? On Wed, Oct 14, 2009 at 12:08 PM, Pascal Muetschard pmuetsch...@google.comwrote: I've uploaded another patch set, which merges in the latest changes from the trunk. On Mon, Oct 12, 2009 at 2:34 AM, John Tamplin j...@google.com wrote: On Mon, Oct 12, 2009 at 12:03 AM, John LaBanca jlaba...@google.comwrote: @jat - When do you think we'll merge the htmlunit branch into trunk so we can check in this patch? We are supposed to ship MS2 on Wednesday, so it has to be real soon. -- John A. Tamplin Software Engineer (GWT), Google --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] [google-web-toolkit] r6374 committed - Removing a statement from CoverageTest that triggers a javac bug....
Revision: 6374
Author: jlaba...@google.com
Date: Wed Oct 14 12:38:52 2009
Log: Removing a statement from CoverageTest that triggers a javac bug.
Patch by: jabanca
Review by: jat
http://code.google.com/p/google-web-toolkit/source/detail?r=6374
Modified:
/trunk/user/test/com/google/gwt/dev/jjs/test/CoverageTest.java
===
--- /trunk/user/test/com/google/gwt/dev/jjs/test/CoverageTest.java Mon Jul
20 22:35:44 2009
+++ /trunk/user/test/com/google/gwt/dev/jjs/test/CoverageTest.java Wed Oct
14 12:38:52 2009
@@ -101,7 +101,7 @@
* see Google's internal issue 1628473. This is likely to be an
hindrance
* if and when GWT attempts to read bytecode directly.
*/
- new NamedLocal().new NamedLocalSub().foo();
+ // new NamedLocal().new NamedLocalSub().foo();
}
public void bar() {
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---
[gwt-contrib] [google-web-toolkit] r6375 committed - Removing emma exclusions from build file now that we removed the line ...
Revision: 6375
Author: jlaba...@google.com
Date: Wed Oct 14 12:48:54 2009
Log: Removing emma exclusions from build file now that we removed the line
that triggers a javac bug in CoverageTest.
Patch by: jlabanca
Review by: jat
http://code.google.com/p/google-web-toolkit/source/detail?r=6375
Modified:
/trunk/user/build.xml
===
--- /trunk/user/build.xml Wed Oct 14 11:08:29 2009
+++ /trunk/user/build.xml Wed Oct 14 12:48:54 2009
@@ -27,13 +27,6 @@
property name=gwt.junit.testcase.dev.includes
value=${gwt.junit.testcase.includes} /
property name=gwt.junit.testcase.dev.excludes value= /
- !--
-CoverageTest.java fails due to a javac bug in sun/OpenJDK's Java. See
the
-file contents for details
- --
- property name=gwt.junit.testcase.dev.emma.includes
value=**/*Suite.class,com/google/gwt/dev/jjs/test/*Test.class /
- property name=gwt.junit.testcase.dev.emma.excludes
value=**/CoverageTest.class,**/CompilerSuite.class /
-
!--
Only IFrameLinker actually supports -noserver mode; run the other
linker
tests if and when they are supported
@@ -153,7 +146,7 @@
/target
target name=test.dev.remote
- depends=compile, compile.tests, -test.dev.includes
+ depends=compile, compile.tests
description=Run dev-mode tests with remote browsers
if=gwt.hosts.dev.remote
echo message=Performing dev-mode remote testing at
${gwt.remote.browsers} /
@@ -171,14 +164,14 @@
/target
target name=test.emma.remote
- depends=compile, compile.tests, -test.dev.includes
+ depends=compile, compile.tests
description=Run emma tests with remote browsers
if=gwt.hosts.dev.remote
echo message=Performing emma remote testing at
${gwt.hosts.dev.remote} /
property name=test.emma.remote.args value=${test.args} /
fileset id=test.emma.remote.tests dir=${javac.junit.out}
-includes=${gwt.junit.testcase.dev.emma.includes}
-excludes=${gwt.junit.testcase.dev.emma.excludes} /
+includes=${gwt.junit.testcase.dev.includes}
+excludes=${gwt.junit.testcase.dev.excludes} /
gwt.junit test.args=${test.args} -out www -runStyle
RemoteWeb:${gwt.hosts.dev.remote} -batch module -precompile parallel
test.out=${junit.out}/emma-remote
test.cases=test.emma.remote.tests
@@ -190,14 +183,14 @@
/target
target name=test.emma.selenium
- depends=compile, compile.tests, -test.dev.includes
+ depends=compile, compile.tests
description=Run emma tests with Selenium-RC servers
if=gwt.hosts.dev.selenium
echo message=Performing emma selenium testing at
${gwt.hosts.dev.selenium} /
property name=test.emma.remote.args value=${test.args} /
fileset id=test.emma.selenium.tests dir=${javac.junit.out}
-includes=${gwt.junit.testcase.dev.emma.includes}
-excludes=${gwt.junit.testcase.dev.emma.excludes} /
+includes=${gwt.junit.testcase.dev.includes}
+excludes=${gwt.junit.testcase.dev.excludes} /
gwt.junit test.args=${test.args} -out www -runStyle
Selenium:${gwt.hosts.dev.selenium} -batch module -precompile parallel
test.out=${junit.out}/emma-selenium
test.cases=test.emma.selenium.tests
@@ -266,7 +259,7 @@
/target
target name=test.dev.selenium
- depends=compile, compile.tests, -test.dev.includes
+ depends=compile, compile.tests
description=Run dev-mode tests using Selenium RC servers
if=gwt.hosts.dev.selenium
echo message=Performing dev-mode testing using Selenium RC at
${gwt.hosts.dev.selenium} /
@@ -321,8 +314,8 @@
depends=compile, compile.tests
description=Run emma tests with HtmlUnit
fileset id=test.emma.htmlunit.tests dir=${javac.junit.out}
- includes=${gwt.junit.testcase.dev.emma.includes}
- excludes=${gwt.junit.testcase.dev.emma.excludes} /
+ includes=${gwt.junit.testcase.dev.includes}
+ excludes=${gwt.junit.testcase.dev.excludes} /
gwt.junit test.args=${test.args}
test.out=${junit.out}/emma-htmlunit
test.cases=test.emma.htmlunit.tests
@@ -334,7 +327,7 @@
/target
target name=test.dev.htmlunit
- depends=compile, compile.tests, -test.dev.includes
+ depends=compile, compile.tests
description=Run dev-mode tests with HtmlUnit.
property name=gwt.junit.testcase.dev.includes
value=${gwt.junit.testcase.includes} /
@@ -359,13 +352,6 @@
echo message=DEPRECATED: test.hosted has been renamed test.dev/
/target
- target name=-test.dev.includes if=emma.enabled
-property name=gwt.junit.testcase.dev.includes
-value=${gwt.junit.testcase.dev.emma.includes} /
-property name=gwt.junit.testcase.dev.excludes
-value=${gwt.junit.testcase.dev.emma.excludes} /
- /target
-
target name=test.noserver
depends=compile, compile.tests
[gwt-contrib] Re: Proposed API Addition - @WithModuleParameters on test cases
Yes, as soon as we get the build stabilized, I'll commit this. Thanks, John LaBanca jlaba...@google.com On Wed, Oct 14, 2009 at 3:20 PM, Bruce Johnson br...@google.com wrote: @John L: You taking this one? On Wed, Oct 14, 2009 at 12:08 PM, Pascal Muetschard pmuetsch...@google.com wrote: I've uploaded another patch set, which merges in the latest changes from the trunk. On Mon, Oct 12, 2009 at 2:34 AM, John Tamplin j...@google.com wrote: On Mon, Oct 12, 2009 at 12:03 AM, John LaBanca jlaba...@google.comwrote: @jat - When do you think we'll merge the htmlunit branch into trunk so we can check in this patch? We are supposed to ship MS2 on Wednesday, so it has to be real soon. -- John A. Tamplin Software Engineer (GWT), Google --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Initial implementation of TabLayoutPanel.
Reviewers: rjrj_google.com, jlabanca, Please review this at http://gwt-code-reviews.appspot.com/78820 Affected files: A user/javadoc/com/google/gwt/examples/TabLayoutPanelExample.java M user/src/com/google/gwt/user/client/ui/LayoutPanel.java A user/src/com/google/gwt/user/client/ui/TabLayoutPanel.java A user/test/com/google/gwt/user/client/ui/TabLayoutPanelTest.java --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: Refactored DisclosurePanel and better DisclosurePanelParser
Okay Joel, ready for another look. The only big changes to DisclosurePanel are that it is now ImageResource based, and I've ruthlessly deprecated its convenience constructors. http://gwt-code-reviews.appspot.com/78817 --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: Refactored DisclosurePanel and better DisclosurePanelParser
Uploaded a tweak to tidy up image initialization. http://gwt-code-reviews.appspot.com/78817 --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: Initial implementation of TabLayoutPanel.
Reviewing this now. Tag, I'm it. http://gwt-code-reviews.appspot.com/78820 --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] [google-web-toolkit] r6376 committed - The test target in user now runs sequentially because browser manager ...
Revision: 6376
Author: jlaba...@google.com
Date: Wed Oct 14 13:51:57 2009
Log: The test target in user now runs sequentially because browser manager
queues up too many requests in parallel.
Patch by: jlabanca
Review by: jgw
http://code.google.com/p/google-web-toolkit/source/detail?r=6376
Modified:
/trunk/user/build.xml
===
--- /trunk/user/build.xml Wed Oct 14 12:48:54 2009
+++ /trunk/user/build.xml Wed Oct 14 13:51:57 2009
@@ -417,14 +417,14 @@
property.ensure name=distro.built location=${gwt.dev.staging.jar}
message=GWT must be built before performing any tests. This can
be fixed by running ant in the ${gwt.root} directory. /
limit failonerror=true hours=${test.timeout}
-parallel threadsPerProcessor=${gwt.threadsPerProcessor}
+sequential
antcall target=test.dev/
antcall target=test.emma/
antcall target=test.web/
antcall target=test.draft/
antcall target=test.nometa/
antcall target=test.noserver/
-/parallel
+/sequential
/limit
/target
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---
[gwt-contrib] Re: Initial implementation of TabLayoutPanel.
http://gwt-code-reviews.appspot.com/78820/diff/1/2
File user/javadoc/com/google/gwt/examples/TabLayoutPanelExample.java
(right):
http://gwt-code-reviews.appspot.com/78820/diff/1/2#newcode41
Line 41: rp.layout();
I wonder if we could tie into the FinallyCommand mechanism to automate
and batch these initial layout calls? Not today, obviously, but food for
thought.
http://gwt-code-reviews.appspot.com/78820/diff/1/4
File user/src/com/google/gwt/user/client/ui/TabLayoutPanel.java (right):
http://gwt-code-reviews.appspot.com/78820/diff/1/4#newcode61
Line 61: */
When I provide my own widget, will it be able to receive events? E.g.,
will I be able to implement a tab with a close box on it?
We had talked about allowing the client to provide a tab factory. Why
didn't that work out?
http://gwt-code-reviews.appspot.com/78820/diff/1/4#newcode387
Line 387: public void setTabHTML(int index, String text) {
I'd still rather see something like:
panel.getTab(i).setHTML(), etc. You'd have so many fewer methods.
http://gwt-code-reviews.appspot.com/78820
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---
[gwt-contrib] Re: Initial implementation of TabLayoutPanel.
LGTM http://gwt-code-reviews.appspot.com/78820/diff/1/4 File user/src/com/google/gwt/user/client/ui/TabLayoutPanel.java (right): http://gwt-code-reviews.appspot.com/78820/diff/1/4#newcode61 Line 61: */ That customizability is my main concern. If the widget is actually master of its own events, everything else is angels dancing on the heads of pins. So if I want to, say, put a popup volume slider on each of my Tabs, I'm good? http://gwt-code-reviews.appspot.com/78820 --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: Initial implementation of TabLayoutPanel.
LGTY for now?
http://gwt-code-reviews.appspot.com/78820/diff/1/2
File user/javadoc/com/google/gwt/examples/TabLayoutPanelExample.java
(right):
http://gwt-code-reviews.appspot.com/78820/diff/1/2#newcode41
Line 41: rp.layout();
On 2009/10/14 21:06:03, Ray Ryan wrote:
I wonder if we could tie into the FinallyCommand mechanism to automate
and batch
these initial layout calls? Not today, obviously, but food for
thought.
Definitely want to think about this a bit more. I've got a comment to
this effect in one of my git branches. It's a bit tricky because some
panels want to allow animated layout(), but I still think we can do
better than this.
http://gwt-code-reviews.appspot.com/78820/diff/1/4
File user/src/com/google/gwt/user/client/ui/TabLayoutPanel.java (right):
http://gwt-code-reviews.appspot.com/78820/diff/1/4#newcode61
Line 61: */
On 2009/10/14 21:06:03, Ray Ryan wrote:
When I provide my own widget, will it be able to receive events? E.g.,
will I be
able to implement a tab with a close box on it?
Yes, this works fine (I've tested it by hand in a local project). Yes, I
need to add actual JUnit tests for this as well.
We had talked about allowing the client to provide a tab factory. Why
didn't
that work out?
Kelly and I sat down to talk about it, and came to the conclusion that
it would be about a bazillion times easier to just create two divs for
each tab, which can be used for the majority of rounded-corner tricks
one might want. This drastically simplifies the API surface area,
because the Tab itself becomes a private implementation detail. We may
need to revisit it later to make sure we haven't missed any reasonable
styling cases, but I think we'll be fine (also remember that you can, if
absolutely necessary, add extra elements to a widget, added to a tab,
for styling purposes -- but I expect this won't ever really be
necessary).
http://gwt-code-reviews.appspot.com/78820/diff/1/4#newcode387
Line 387: public void setTabHTML(int index, String text) {
On 2009/10/14 21:06:03, Ray Ryan wrote:
I'd still rather see something like:
panel.getTab(i).setHTML(), etc. You'd have so many fewer methods.
I'm willing to consider it, but was mainly aiming to get something close
enough to the existing TabPanel that it wouldn't be hard to port. Maybe
we can revisit this again after MS2 (I still have a nasty warning in the
javadoc about the API changing without warning)?
http://gwt-code-reviews.appspot.com/78820
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---
[gwt-contrib] Re: Initial implementation of TabLayoutPanel.
If I could chime in... http://gwt-code-reviews.appspot.com/78820/diff/1/4 File user/src/com/google/gwt/user/client/ui/TabLayoutPanel.java (right): http://gwt-code-reviews.appspot.com/78820/diff/1/4#newcode365 Line 365: SelectionEvent.fire(this, index); Any chance this could be gated on a issueEvent argument? In most cases the handling of a user-select is the same as a programmatic select, but it's nice to have the option. It does clutter up the API a bit though http://gwt-code-reviews.appspot.com/78820 --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] [google-web-toolkit] r6377 committed - Creating a branch for the Remote UI Communication implementation....
Revision: 6377 Author: rda...@google.com Date: Wed Oct 14 14:33:21 2009 Log: Creating a branch for the Remote UI Communication implementation. svn copy https://google-web-toolkit.googlecode.com/svn/tr...@6376 https://google-web-toolkit.googlecode.com/svn/branches/remote-ui-communication After the work is completed, this work will be merged up to the 2.0 MS2 release branch. http://code.google.com/p/google-web-toolkit/source/detail?r=6377 Added: /branches/remote-ui-communication --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Log a deprecation warning for CellPanelParsers
Reviewers: jgw,
Message:
Here's an easy one. It logs lines like this:
[WARN] gwt:DockPanel is deprecated. Use the appropriate LayoutPanel
instead.
Please review this at http://gwt-code-reviews.appspot.com/78821
Affected files:
M user/src/com/google/gwt/uibinder/parsers/CellPanelParser.java
Index: user/src/com/google/gwt/uibinder/parsers/CellPanelParser.java
diff --git a/user/src/com/google/gwt/uibinder/parsers/CellPanelParser.java
b/user/src/com/google/gwt/uibinder/parsers/CellPanelParser.java
index
67d8ca2c6ff0a836638c8c608c4e8111fbb11d0e..e677aff77ea15a385b50e32aae5e993ddd28b2f5
100644
--- a/user/src/com/google/gwt/uibinder/parsers/CellPanelParser.java
+++ b/user/src/com/google/gwt/uibinder/parsers/CellPanelParser.java
@@ -46,8 +46,9 @@ public class CellPanelParser implements ElementParser {
*
* @throws UnableToCompleteException
*/
- public static void parseCellAttributes(XMLElement cellElem, String
fieldName,
+ static void parseCellAttributes(XMLElement cellElem, String fieldName,
String childFieldName, UiBinderWriter writer) throws
UnableToCompleteException {
+
// Parse horizontal and vertical alignment attributes.
if (cellElem.hasAttribute(HALIGN_ATTR)) {
String value =
@@ -81,7 +82,10 @@ public class CellPanelParser implements ElementParser {
public void parse(XMLElement elem, String fieldName, JClassType type,
UiBinderWriter writer) throws UnableToCompleteException {
-for (XMLElement child : elem.consumeChildElements()) {
+writer.warn(
+%s:%s is deprecated. Use the appropriate LayoutPanel instead.,
+elem.getPrefix(), elem.getLocalName());
+ for (XMLElement child : elem.consumeChildElements()) {
String ns = child.getNamespaceUri();
String tagName = child.getLocalName();
if (ns.equals(elem.getNamespaceUri()) tagName.equals(CELL_TAG)) {
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---
[gwt-contrib] [google-web-toolkit] r6378 committed - Updated branch-info.txt to match this branch.
Revision: 6378 Author: rda...@google.com Date: Wed Oct 14 16:15:18 2009 Log: Updated branch-info.txt to match this branch. http://code.google.com/p/google-web-toolkit/source/detail?r=6378 Modified: /branches/remote-ui-communication/branch-info.txt === --- /branches/remote-ui-communication/branch-info.txt Tue Oct 13 16:57:19 2009 +++ /branches/remote-ui-communication/branch-info.txt Wed Oct 14 16:15:18 2009 @@ -1,21 +1,8 @@ -Created from tr...@6101 +Created from tr...@6376 -svn copy -r6226 \ -https://google-web-toolkit.googlecode.com/svn/branches/farewellSwt \ - https://google-web-toolkit.googlecode.com/svn/changes/jat/noswt-merge6200 - -Merges -== -svn merge https://google-web-toolkit.googlecode.com/svn/trunk \ --r6101:6142 -svn merge --ignore-ancestry -r6142:6200 \ -https://google-web-toolkit.googlecode.com/svn/trunk -(via changes/jat/noswt-merge6200) -svn merge https://google-web-toolkit.googlecode.com/svn/trunk \ - -r6200:6239 . -svn merge https://google-web-toolkit.googlecode.com/svn/trunk \ - -r6239:6249 . -svn merge https://google-web-toolkit.googlecode.com/svn/trunk \ - --ignore-ancestry -r6249:6270 . -svn merge --ignore-ancestry -r6280:6359 \ -https://google-web-toolkit.googlecode.com/svn/changes/jat/abstractui +svn copy https://google-web-toolkit.googlecode.com/svn/tr...@6376 \ +https://google-web-toolkit.googlecode.com/svn/branches/remote-ui-communication + +Merged from trunk += + --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] [google-web-toolkit] r6379 committed - Removed two unnecessary lines that were re-defining a property...
Revision: 6379
Author: amitman...@google.com
Date: Wed Oct 14 17:59:39 2009
Log: Removed two unnecessary lines that were re-defining a property
Patch by: amitmanjhi
http://code.google.com/p/google-web-toolkit/source/detail?r=6379
Modified:
/trunk/user/build.xml
===
--- /trunk/user/build.xml Wed Oct 14 13:51:57 2009
+++ /trunk/user/build.xml Wed Oct 14 17:59:39 2009
@@ -329,10 +329,6 @@
target name=test.dev.htmlunit
depends=compile, compile.tests
description=Run dev-mode tests with HtmlUnit.
-property name=gwt.junit.testcase.dev.includes
-value=${gwt.junit.testcase.includes} /
-property name=gwt.junit.testcase.dev.excludes
-value=${gwt.junit.testcase.excludes} /
fileset id=test.dev.htmlunit.tests dir=${javac.junit.out}
includes=${gwt.junit.testcase.dev.includes}
excludes=${gwt.junit.testcase.dev.excludes} /
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---
[gwt-contrib] [google-web-toolkit] r6380 committed - Ignoring the testNoOverrideInheritedSharedCssClasses for the time bein...
Revision: 6380
Author: amitman...@google.com
Date: Wed Oct 14 18:26:27 2009
Log: Ignoring the testNoOverrideInheritedSharedCssClasses for the time
being, while
I debug it. It is failing in hosted mode consistently.
Patch by: amitmanjhi
http://code.google.com/p/google-web-toolkit/source/detail?r=6380
Modified:
/trunk/user/test/com/google/gwt/uibinder/sample/client/UiBinderTest.java
===
---
/trunk/user/test/com/google/gwt/uibinder/sample/client/UiBinderTest.java
Tue Oct 13 16:57:19 2009
+++
/trunk/user/test/com/google/gwt/uibinder/sample/client/UiBinderTest.java
Wed Oct 14 18:26:27 2009
@@ -236,6 +236,7 @@
WidgetBasedUi.Style style();
}
+ @DoNotRunWith(Platform.Htmlunit)
public void testNoOverrideInheritedSharedCssClasses() {
Bundle bundle = GWT.create(Bundle.class);
WidgetBasedUi ui = GWT.create(WidgetBasedUi.class);
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---
