Re: [gwt-contrib] GWT RC2 - Events are being hid by Layout layers in UIBinder
Thanks Joel.
My current workaround is to use the old Horizontal/VerticalPanel widgets,
so no harm, no foul. Looking forward to more examples!
Stuart
On Mon, Nov 30, 2009 at 12:20 PM, Joel Webber j...@google.com wrote:
Stuart,
Hiding/showing layers is slightly tricky (or at least non-obvious). I'm
still working on examples in the documentation that should make it a lot
clearer.
In a nutshell, you need to actually show/hide the layer elements
themselves. You can get the layer's element (referred to as a widget's
container element) using *LayoutPanel.getWidgetContainerElement(Widget).
Showing/hiding this element rather than the widget itself should get rid of
any event problems. I'll make a point to add an example of this to the
documentation.
I didn't want to require the existence of the elements, but it proved
impossible to support arbitrary CSS any other way (the existence of these
elements makes it possible to efficiently account for margins, borders, and
padding on the child widgets' elements).
Cheers,
joel.
On Thu, Nov 26, 2009 at 2:33 AM, Stuart Moffatt
stuartmoff...@gmail.comwrote:
Env: GWTRC2 Safari Mac OS X.
UI binding:
{{{
g:LayoutPanel ui:field=layoutPanel
g:layer
myclient:MyEditor ui:field='myEditor'/
/g:layer
g:layer
myclient:MyLister ui:field='myLister'/
/g:layer
/g:LayoutPanel
}}}
These two custom widgets sit right on top of each other visually. The
reason is I want them to replace each other. Since MyLister is added
last, I can trigger events from it. When I fire a certain event from
MyLister, MyLister hides via setVisible(false) and MyEditor displays
via setVisible(true) However, because MyEditor is a layer below
MyLister, all events are hidden. E.g. onClick in widget in MyEditor
does not fire.
Is there any way (declaratively or programmatically) to swap the
positions of the layers so that the visible layer is on top and can
respond to events?
sfm
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] Revisiting the script-via-iframe default linkage
On Mon, Nov 30, 2009 at 10:28 PM, Matt Mastracci matt...@mastracci.com wrote: 2. onerror works some of the time in some of the browsers. It fails on various combinations of resolve errors, error status codes and other failure conditions. For all browsers (except Opera) that don't support it directly, It can be emulated with onreadystatechange/onload and lack of a JSONP callback. Can you expand on that? IE has script-tag callbacks that should be usable to detect download errors. What did you get working on other browsers? If there's a way to detect download failures on Firefox and on Webkit-based browser, then JSONP downloads are better than I thought. Lex -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] Revisiting the script-via-iframe default linkage
Ray/Lex, I'm starting to think that the dynamic iframe might not be a bad first approach to this problem either. A single linker would be able to provide cross-domain-capable, multi-module-safe code that doesn't require any additional post-processing to support loading of fragments. It also runs in the global scope, saving the extra few ms per global access (http://blog.j15r.com/2009/08/where-should-i-define-javascript.html ). The method used to load the first and additional fragments could become a linker property. For our cross-domain loads, I'd like to have a strategy that tries to use cross-domain XMLHttpRequest first, assuming appropriate Access-Control-* headers on the other end, then falls back to script tags if this isn't available. The default could be something simple like script tags, or even standard XMLHttpRequest, assuming the auxiliary scripts are stored on the same domain. It still has the disadvantage of being slightly more magical, requiring tricks to work around IE's window event security, but the advantages are pretty substantial. It should be possible to write this linker as a drop-in replacement for today's XSLinker and IFrameLinkers without touching any code outside of com.google.gwt.core.linker. Matt. On 30-Nov-09, at 5:09 PM, Ray Cromwell wrote: Lex, JSONP loading + dynamic iframe seems like a straightforward viable option that doesn't require a lot of complicated compiler work, what do you think of providing this as an option? -Ray On Mon, Nov 30, 2009 at 12:29 PM, Lex Spoon sp...@google.com wrote: (Reposting to get it on the mailing list; first try bounced.) Hey, Matt, I agree with your analysis about the code-splitting issues. I've worked out a preliminary patch to do var renaming, but I haven't shared it yet because it's in a pretty early state. I could share it if you or someone is eager enough to see it that you're willing to hack some code to get to use it. To really get it polished up into a committable state, the main issue will be figuring out when to enable the rewrites.Whether to enable it or not depends on the choice of linker. For the off-domain loading, I was thinking to look into a JSONP-like downloader. That, too, is something that should only optionally be enabled, because it has worse download failure reporting. Thus, again the hardest part will be figuring out when to enable it. -- http://groups.google.com/group/Google-Web-Toolkit-Contributors -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] Revisiting the script-via-iframe default linkage
Thanks for the test code and data, Matt! It sounds like enough browsers are covered that error reporting is no longer a major decider between XHR vs. script tags. Regarding iframes, be aware that some GWT users can't use them. I don't know all the reasons why, but one example reason is that iframes don't work reasonably on iPhones. So, we need to support non-iframe linkers for at least some use cases. Lex -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: Removes the use of FinallyCommand in StackLayoutPanel.
LGTM http://gwt-code-reviews.appspot.com/115804 -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] get RPC policy name from Java code
Reviewers: robertvawter_google.com,
Description:
Some GWT users want to build GWT RPC requests themselves, e.g. via
building a raw HTML form. To do this, they need to supply the RPC
policy name as part of the request, just like GWT RPC normally does.
How shall they get the policy name?
This patch exports the information via ServiceDefTarget. To get the
policy name then looks similar to the way a the URL is set for where the
RPC server lives:
String policyName = ((ServiceDefTarget)
GWT.create(MyRpcService.class)).getSerializationPolicyName();
Please review this at http://gwt-code-reviews.appspot.com/115805
Affected files:
user/src/com/google/gwt/user/client/rpc/ServiceDefTarget.java
user/src/com/google/gwt/user/client/rpc/impl/RemoteServiceProxy.java
Index: user/src/com/google/gwt/user/client/rpc/impl/RemoteServiceProxy.java
===
--- user/src/com/google/gwt/user/client/rpc/impl/RemoteServiceProxy.java
(revision 7217)
+++ user/src/com/google/gwt/user/client/rpc/impl/RemoteServiceProxy.java
(working copy)
@@ -212,6 +212,10 @@
clientSerializationStreamWriter.prepareToWrite();
return clientSerializationStreamWriter;
}
+
+ public String getSerializationPolicyName() {
+return serializationPolicyName;
+ }
/**
* @see ServiceDefTarget#getServiceEntryPoint()
Index: user/src/com/google/gwt/user/client/rpc/ServiceDefTarget.java
===
--- user/src/com/google/gwt/user/client/rpc/ServiceDefTarget.java
(revision
7217)
+++ user/src/com/google/gwt/user/client/rpc/ServiceDefTarget.java
(working
copy)
@@ -34,6 +34,12 @@
super(Service implementation URL not specified);
}
}
+
+ /**
+ * Return the strong name of the serialization policy to be used with
this RPC
+ * instance.
+ */
+ String getSerializationPolicyName();
/**
* Gets the URL of a service implementation.
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] Revisiting the script-via-iframe default linkage
To be clear, I don't know of any cases where people *can't* use iframes. There are some cases where teams have chosen to use script tags for an assumed performance benefit, but I don't know of anyone ever having measured it. Most of the time people use script tags for cross-site or late-loading behavior. If we could make iframes work for these cases, and show that there's no performance benefit to script tags, it may be less of an issue. The iPhone only has problems rendering iframes (it essentially drops their content into the outer page as though it were inline), but that's about it. On Tue, Dec 1, 2009 at 11:44 AM, Lex Spoon sp...@google.com wrote: Thanks for the test code and data, Matt! It sounds like enough browsers are covered that error reporting is no longer a major decider between XHR vs. script tags. Regarding iframes, be aware that some GWT users can't use them. I don't know all the reasons why, but one example reason is that iframes don't work reasonably on iPhones. So, we need to support non-iframe linkers for at least some use cases. Lex -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] [google-web-toolkit] r7218 committed - Cherry picking trunk c7178, c7185 into 2009.11.20 snapshot....
Revision: 7218
Author: sco...@google.com
Date: Tue Dec 1 09:29:17 2009
Log: Cherry picking trunk c7178, c7185 into 2009.11.20 snapshot.
- Fixes CustomButton's ability to have a text body
- UiBinder AttributeParsers can now distinguish from null
http://code.google.com/p/google-web-toolkit/source/detail?r=7218
Modified:
/branches/snapshot-2009.11.20-r7061/user/src/com/google/gwt/uibinder/attributeparsers/StrictAttributeParser.java
/branches/snapshot-2009.11.20-r7061/user/src/com/google/gwt/uibinder/elementparsers/BeanParser.java
/branches/snapshot-2009.11.20-r7061/user/src/com/google/gwt/uibinder/elementparsers/CustomButtonParser.java
/branches/snapshot-2009.11.20-r7061/user/src/com/google/gwt/uibinder/elementparsers/DisclosurePanelParser.java
/branches/snapshot-2009.11.20-r7061/user/src/com/google/gwt/uibinder/elementparsers/LayoutPanelParser.java
/branches/snapshot-2009.11.20-r7061/user/src/com/google/gwt/uibinder/rebind/XMLElement.java
/branches/snapshot-2009.11.20-r7061/user/src/com/google/gwt/uibinder/rebind/messages/MessagesWriter.java
/branches/snapshot-2009.11.20-r7061/user/test/com/google/gwt/uibinder/attributeparsers/IntAttributeParserTest.java
/branches/snapshot-2009.11.20-r7061/user/test/com/google/gwt/uibinder/attributeparsers/LengthAttributeParserTest.java
/branches/snapshot-2009.11.20-r7061/user/test/com/google/gwt/uibinder/attributeparsers/StringAttributeParserTest.java
/branches/snapshot-2009.11.20-r7061/user/test/com/google/gwt/uibinder/rebind/XMLElementTest.java
/branches/snapshot-2009.11.20-r7061/user/test/com/google/gwt/uibinder/test/client/UiBinderTest.java
/branches/snapshot-2009.11.20-r7061/user/test/com/google/gwt/uibinder/test/client/WidgetBasedUi.java
/branches/snapshot-2009.11.20-r7061/user/test/com/google/gwt/uibinder/test/client/WidgetBasedUi.ui.xml
===
---
/branches/snapshot-2009.11.20-r7061/user/src/com/google/gwt/uibinder/attributeparsers/StrictAttributeParser.java
Wed Nov 11 22:08:47 2009
+++
/branches/snapshot-2009.11.20-r7061/user/src/com/google/gwt/uibinder/attributeparsers/StrictAttributeParser.java
Tue Dec 1 09:29:17 2009
@@ -82,11 +82,13 @@
* UnableToCompleteException is thrown.
*/
public String parse(String value) throws UnableToCompleteException {
-
+if (.equals(value.trim())) {
+ logger.die(Cannot use empty value as type %s,
type.getSimpleSourceName());
+}
try {
return converter.convert(value, new FieldReferenceDelegate(type));
} catch (IllegalFieldReferenceException e) {
- logger.die(Cannot parse value: \%s\, value);
+ logger.die(Cannot parse value: \%s\ as type %s, value,
type.getSimpleSourceName());
return null; // Unreachable
}
}
===
---
/branches/snapshot-2009.11.20-r7061/user/src/com/google/gwt/uibinder/elementparsers/BeanParser.java
Mon Nov 16 10:04:26 2009
+++
/branches/snapshot-2009.11.20-r7061/user/src/com/google/gwt/uibinder/elementparsers/BeanParser.java
Tue Dec 1 09:29:17 2009
@@ -135,8 +135,8 @@
writer.die(In %s, class %s has no appropriate set%s() method,
elem,
elem.getLocalName(), initialCap(propertyName));
}
-
-String value =
elem.consumeAttributeWithDefault(attribute.getName(),
+String n = attribute.getName();
+String value = elem.consumeAttributeWithDefault(n,
null, getParamTypes(setter));
if (value == null) {
===
---
/branches/snapshot-2009.11.20-r7061/user/src/com/google/gwt/uibinder/elementparsers/CustomButtonParser.java
Wed Nov 11 22:08:47 2009
+++
/branches/snapshot-2009.11.20-r7061/user/src/com/google/gwt/uibinder/elementparsers/CustomButtonParser.java
Tue Dec 1 09:29:17 2009
@@ -1,12 +1,12 @@
/*
* Copyright 2007 Google Inc.
- *
+ *
* Licensed under the Apache License, Version 2.0 (the License); you may
not
* use this file except in compliance with the License. You may obtain a
copy of
* the License at
- *
+ *
* http://www.apache.org/licenses/LICENSE-2.0
- *
+ *
* Unless required by applicable law or agreed to in writing, software
* distributed under the License is distributed on an AS IS BASIS,
WITHOUT
* WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the
@@ -19,6 +19,7 @@
import com.google.gwt.core.ext.typeinfo.JClassType;
import com.google.gwt.uibinder.rebind.UiBinderWriter;
import com.google.gwt.uibinder.rebind.XMLElement;
+import com.google.gwt.uibinder.rebind.XMLElement.Interpreter;
import com.google.gwt.user.client.ui.Image;
import java.util.HashSet;
@@ -41,39 +42,49 @@
faceNames.add(downDisabledFace);
}
- public void parse(XMLElement elem, String fieldName, JClassType type,
- UiBinderWriter writer) throws UnableToCompleteException {
-
-// Parse children.
[gwt-contrib] Re: get RPC policy name from Java code
Access to the strong name isn't available anywhere else. LGTM, but add a test to RemoteServiceServletTest to at least assert that the return value is non-null. http://gwt-code-reviews.appspot.com/115805 -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Flow analysis framework definition and solver.
LGTM. Aside from documentation and naming, there is one question about
which nodes are re-added to the worklist in the solver.
Can you post a large enough set of code to include an actual analysis
and optimization? I don't think we should commit any of this code until
there it is causing at least some improvement, however small.
http://gwt-code-reviews.appspot.com/112811/diff/1/3
File dev/core/src/com/google/gwt/dev/jjs/impl/flow/AnalysisSolver.java
(right):
http://gwt-code-reviews.appspot.com/112811/diff/1/3#newcode28
Line 28: public interface AnalysisSolverN, E, T, G extends GraphN, E,
T, G {
Why the interface? Unlike the other interfaces in this package, I don't
see why a second implementation would ever coexist in the same code
base.
http://gwt-code-reviews.appspot.com/112811/diff/1/4
File
dev/core/src/com/google/gwt/dev/jjs/impl/flow/AnalysisSolverImpl.java
(right):
http://gwt-code-reviews.appspot.com/112811/diff/1/4#newcode30
Line 30: * backwards working. Both of directions will always produce a
fixed point,
Since forward only influences the initial visit order of the nodes in
the CFG, I don't think it's worth calling out in the class comment.
Talk about it in the constructor, and say that what it does is affect
the initial visit order.
http://gwt-code-reviews.appspot.com/112811/diff/1/4#newcode94
Line 94: MapE, A solution = iterate(newSubgraph,
subgraphSolution? I find this method tricky, so careful names would
help.
http://gwt-code-reviews.appspot.com/112811/diff/1/4#newcode112
Line 112: return result;
No need to make a temp and return it. Just return it.
http://gwt-code-reviews.appspot.com/112811/diff/1/4#newcode127
Line 127: * Solve analysis
Solve a non-integrated analysis. (Or, come up with a better name than
non-integrated?)
http://gwt-code-reviews.appspot.com/112811/diff/1/4#newcode142
Line 142: worklist.add(nodes.get(i));
I see a lot of random access on lists in this function. Making them
ArrayLists instead of Lists would prevent accidental bad performance if
anyone tries to substitute something else.
http://gwt-code-reviews.appspot.com/112811/diff/1/4#newcode167
Line 167: throw new IllegalArgumentException();
Be consistent with this exception message and the previous one?
http://gwt-code-reviews.appspot.com/112811/diff/1/4#newcode181
Line 181: addSuccessors(g, worklist, node);
Doesn't this add more nodes than necessary to the work list? If only
one output edge changes, then only that node's target edge needs to be
visited again.
http://gwt-code-reviews.appspot.com/112811/diff/1/4#newcode185
Line 185: for (int i = 0; i inEdges.size(); i++) {
Analogous questions here as for the previous loop.
http://gwt-code-reviews.appspot.com/112811/diff/1/4#newcode205
Line 205: * Solve integrated analysis.
Solve an integrated analysis by using an IntegratedFlowFunctionAdapter
and recursing into {...@link #solve()}
http://gwt-code-reviews.appspot.com/112811/diff/1/4#newcode327
Line 327: private A extends AssumptionA MapE, A iterate(G g,
This method deserves a method comment.
http://gwt-code-reviews.appspot.com/112811/diff/1/5
File dev/core/src/com/google/gwt/dev/jjs/impl/flow/Assumption.java
(right):
http://gwt-code-reviews.appspot.com/112811/diff/1/5#newcode30
Line 30: Self meet(Self value);
The least upper bound is a *join*, not a meet.
http://gwt-code-reviews.appspot.com/112811/diff/1/7
File dev/core/src/com/google/gwt/dev/jjs/impl/flow/FlowFunction.java
(right):
http://gwt-code-reviews.appspot.com/112811/diff/1/7#newcode24
Line 24: * not clear yet.
To clear up this paragraph, keep the first sentence, and then say the
rest as: Typical flow functions update either outgoing assumptions
(forward flow) or incoming assumptions (backward flow) but not both.
http://gwt-code-reviews.appspot.com/112811/diff/1/10
File
dev/core/src/com/google/gwt/dev/jjs/impl/flow/IntegratedFlowFunction.java
(right):
http://gwt-code-reviews.appspot.com/112811/diff/1/10#newcode22
Line 22: * node transformation based on already computed assumptions.
Do I undestand correctly that in typical cases, the replacement graph
would be a single node, e.g. a nop node or a node that has fewer
connecting edges?
I started to say there are caching issue to consider here, but if the
typical replacements are a single node then it doesn't matter.
http://gwt-code-reviews.appspot.com/112811/diff/1/11
File dev/core/src/com/google/gwt/dev/jjs/impl/flow/NodeAssumptions.java
(right):
http://gwt-code-reviews.appspot.com/112811/diff/1/11#newcode24
Line 24: * node, which allows us to use this class to represnt graph
assumptions.
represent. Although, given the second sentence, isn't this more
accurately described as the assumptions about a *subgraph* ? The
subgraph is often exactly one node, but it doesn't have to be.
http://gwt-code-reviews.appspot.com/112811/diff/1/11#newcode26
Line 26: * @param A
Please add a doc string.
http://gwt-code-reviews.appspot.com/112811/diff/1/13
File
[gwt-contrib] GPE 2.0-RC2 and GWTShell
Hey all, I installed the GPE 2.0-RC2 build (after cleaning out the old one) and I'm running into some issues. The plugin thinks that we're using the old-style layout, so it's attempting to launch GWTShell which won't initialize a local Jetty w/war.xml. I've worked around it by creating a local copy of GWTShell that delegates to DevMode, but I'd like to figure out why it's using the wrong launch target. What is the heuristic for determining whether a project uses the war layout vs. the GWTShell layout? Thanks, Matt. -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] GPE 2.0-RC2 and GWTShell
@Miguel: I've hit this before when upgrading projects, and I keep forgetting what the trick was. I seem to recall the plugin was making the project layout determination at the time the GWT nature is added, but I'm not 100% certain. On Tue, Dec 1, 2009 at 3:55 PM, Matt Mastracci matt...@mastracci.comwrote: Hey all, I installed the GPE 2.0-RC2 build (after cleaning out the old one) and I'm running into some issues. The plugin thinks that we're using the old-style layout, so it's attempting to launch GWTShell which won't initialize a local Jetty w/war.xml. I've worked around it by creating a local copy of GWTShell that delegates to DevMode, but I'd like to figure out why it's using the wrong launch target. What is the heuristic for determining whether a project uses the war layout vs. the GWTShell layout? Thanks, Matt. -- http://groups.google.com/group/Google-Web-Toolkit-Contributors -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] GPE 2.0-RC2 and GWTShell
Ahh - there's a webAppNature in .project that gets set when you enable GWT. I disabled GWT support, re-added it and now the .project has a com.google.gdt.eclipse.core.webAppNature. This seems to be the trigger for enabling DevMode vs. GWTShell. Thanks, Matt. On 1-Dec-09, at 1:57 PM, Joel Webber wrote: @Miguel: I've hit this before when upgrading projects, and I keep forgetting what the trick was. I seem to recall the plugin was making the project layout determination at the time the GWT nature is added, but I'm not 100% certain. On Tue, Dec 1, 2009 at 3:55 PM, Matt Mastracci matt...@mastracci.com wrote: Hey all, I installed the GPE 2.0-RC2 build (after cleaning out the old one) and I'm running into some issues. The plugin thinks that we're using the old-style layout, so it's attempting to launch GWTShell which won't initialize a local Jetty w/war.xml. I've worked around it by creating a local copy of GWTShell that delegates to DevMode, but I'd like to figure out why it's using the wrong launch target. What is the heuristic for determining whether a project uses the war layout vs. the GWTShell layout? Thanks, Matt. -- http://groups.google.com/group/Google-Web-Toolkit-Contributors -- http://groups.google.com/group/Google-Web-Toolkit-Contributors -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] GPE 2.0-RC2 and GWTShell
That is right, at the time that the project is GWT-enabled it checks for the existence of a war/WEB-INF/web.xml. If that exists it will think that it is dealing with a war-style project and then it will use the HostedMode if it is available or DevMode when launching the application. With that version of the plugin, if you have a war/WEB-INF/web.xml file in your project, then you can go to the project properties, and disable gwt for the project apply the changes, go back in and re-enable GWT.That should make it think that it is dealing with a war layout project and it won't use GWTShell. There are a few problems with this heuristic that we need to revisit post 1.2/2.0. On Tue, Dec 1, 2009 at 4:14 PM, Matt Mastracci matt...@mastracci.comwrote: Ahh - there's a webAppNature in .project that gets set when you enable GWT. I disabled GWT support, re-added it and now the .project has a com.google.gdt.eclipse.core.webAppNature. This seems to be the trigger for enabling DevMode vs. GWTShell. Thanks, Matt. On 1-Dec-09, at 1:57 PM, Joel Webber wrote: @Miguel: I've hit this before when upgrading projects, and I keep forgetting what the trick was. I seem to recall the plugin was making the project layout determination at the time the GWT nature is added, but I'm not 100% certain. On Tue, Dec 1, 2009 at 3:55 PM, Matt Mastracci matt...@mastracci.com wrote: Hey all, I installed the GPE 2.0-RC2 build (after cleaning out the old one) and I'm running into some issues. The plugin thinks that we're using the old-style layout, so it's attempting to launch GWTShell which won't initialize a local Jetty w/war.xml. I've worked around it by creating a local copy of GWTShell that delegates to DevMode, but I'd like to figure out why it's using the wrong launch target. What is the heuristic for determining whether a project uses the war layout vs. the GWTShell layout? Thanks, Matt. -- http://groups.google.com/group/Google-Web-Toolkit-Contributors -- http://groups.google.com/group/Google-Web-Toolkit-Contributors -- http://groups.google.com/group/Google-Web-Toolkit-Contributors -- Miguel -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] GPE 2.0-RC2 and GWTShell
One correction: When launching web apps, we use DevMode if the SDK supports it and HostedMode otherwise. 2009/12/1 Miguel Méndez mmen...@google.com That is right, at the time that the project is GWT-enabled it checks for the existence of a war/WEB-INF/web.xml. If that exists it will think that it is dealing with a war-style project and then it will use the HostedMode if it is available or DevMode when launching the application. With that version of the plugin, if you have a war/WEB-INF/web.xml file in your project, then you can go to the project properties, and disable gwt for the project apply the changes, go back in and re-enable GWT.That should make it think that it is dealing with a war layout project and it won't use GWTShell. There are a few problems with this heuristic that we need to revisit post 1.2/2.0. 2009/12/1 Joel Webber j...@google.com @Miguel: I've hit this before when upgrading projects, and I keep forgetting what the trick was. I seem to recall the plugin was making the project layout determination at the time the GWT nature is added, but I'm not 100% certain. On Tue, Dec 1, 2009 at 3:55 PM, Matt Mastracci matt...@mastracci.comwrote: Hey all, I installed the GPE 2.0-RC2 build (after cleaning out the old one) and I'm running into some issues. The plugin thinks that we're using the old-style layout, so it's attempting to launch GWTShell which won't initialize a local Jetty w/war.xml. I've worked around it by creating a local copy of GWTShell that delegates to DevMode, but I'd like to figure out why it's using the wrong launch target. What is the heuristic for determining whether a project uses the war layout vs. the GWTShell layout? Thanks, Matt. -- http://groups.google.com/group/Google-Web-Toolkit-Contributors -- Miguel -- Miguel -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] [google-web-toolkit] r7219 committed - Javadoc fixes....
Revision: 7219
Author: j...@google.com
Date: Tue Dec 1 13:59:12 2009
Log: Javadoc fixes.
Patch by: jat
Review by: jgw (desk)
http://code.google.com/p/google-web-toolkit/source/detail?r=7219
Modified:
/trunk/user/src/com/google/gwt/i18n/client/DateTimeFormat.java
/trunk/user/src/com/google/gwt/i18n/client/LocaleInfo.java
===
--- /trunk/user/src/com/google/gwt/i18n/client/DateTimeFormat.java Mon Nov
30 20:39:13 2009
+++ /trunk/user/src/com/google/gwt/i18n/client/DateTimeFormat.java Tue Dec
1 13:59:12 2009
@@ -112,6 +112,13 @@
* tdcodeTuesday/code/td
* /tr
*
+ * tr
+ * tdcodec/code/td
+ * tdstandalone day of week/td
+ * tdText/td
+ * tdcodeTuesday/code/td
+ * /tr
+ *
* tr
* tdcodea/code/td
* tdam/pm marker/td
===
--- /trunk/user/src/com/google/gwt/i18n/client/LocaleInfo.java Mon Mar 2
23:51:53 2009
+++ /trunk/user/src/com/google/gwt/i18n/client/LocaleInfo.java Tue Dec 1
13:59:12 2009
@@ -115,7 +115,7 @@
}
/**
- * @return a NumberConstants interface for this locale.
+ * @return a DateTimeConstants instance for this locale.
*/
public final DateTimeConstants getDateTimeConstants() {
ensureDateTimeConstants();
@@ -130,7 +130,7 @@
}
/**
- * @return a NumberConstants interface for this locale.
+ * @return a NumberConstants instance for this locale.
*/
public final NumberConstants getNumberConstants() {
ensureNumberConstants();
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Fwd: Flow analysis framework definition and solver.
Forwarding since I wasn't member of the group.
-- Forwarded message --
From: mike.aizat...@gmail.com
Date: Tue, Dec 1, 2009 at 1:52 PM
Subject: Re: Flow analysis framework definition and solver.
To: sp...@google.com,
google-web-toolkit-contributors@googlegroups.com,
cromwell...@google.com
Reviewers: Lex, google-web-toolkit-contributors_googlegroups.com,
cromwellian_google.com,
Message:
Lex,
I can definitely publish some analyses for this framework. There's one
issue, though:
- Each CFG-based analysis is quite small and simple. They depend,
however, on CFG building functionality (156K of code, 200K with tests).
- Side-effects methods is non-integrated analysis, and you were
concerned about it's runtime performance (I didn't see any serious
performance degradation on huge project though). But it's really simple
32K analysis+call graph builder, which is also useful for other stuff.
Like my recent same parameter value.
I can create a separate CFG changelist + CFG-based analyses changelist.
I just worry that I will have to maintain several changelist branches +
main branch with all the code together. I would certainly prefer to land
this code into SVN even before it's actually plugged into compiler.
http://gwt-code-reviews.appspot.com/112811/diff/1/3
File dev/core/src/com/google/gwt/dev/jjs/impl/flow/AnalysisSolver.java
(right):
http://gwt-code-reviews.appspot.com/112811/diff/1/3#newcode28
Line 28: public interface AnalysisSolverN, E, T, G extends GraphN, E,
T, G {
On 2009/12/01 20:36:45, Lex wrote:
Why the interface? Unlike the other interfaces in this package, I
don't see why
a second implementation would ever coexist in the same code base.
Done.
http://gwt-code-reviews.appspot.com/112811/diff/1/4
File
dev/core/src/com/google/gwt/dev/jjs/impl/flow/AnalysisSolverImpl.java
(right):
http://gwt-code-reviews.appspot.com/112811/diff/1/4#newcode30
Line 30: * backwards working. Both of directions will always produce a
fixed point,
On 2009/12/01 20:36:45, Lex wrote:
Since forward only influences the initial visit order of the nodes in
the CFG, I
don't think it's worth calling out in the class comment. Talk about
it in the
constructor, and say that what it does is affect the initial visit
order.
Done.
http://gwt-code-reviews.appspot.com/112811/diff/1/4#newcode94
Line 94: MapE, A solution = iterate(newSubgraph,
On 2009/12/01 20:36:45, Lex wrote:
subgraphSolution? I find this method tricky, so careful names would
help.
Done.
http://gwt-code-reviews.appspot.com/112811/diff/1/4#newcode112
Line 112: return result;
On 2009/12/01 20:36:45, Lex wrote:
No need to make a temp and return it. Just return it.
Done.
http://gwt-code-reviews.appspot.com/112811/diff/1/4#newcode127
Line 127: * Solve analysis
On 2009/12/01 20:36:45, Lex wrote:
Solve a non-integrated analysis. (Or, come up with a better name than
non-integrated?)
Done.
http://gwt-code-reviews.appspot.com/112811/diff/1/4#newcode142
Line 142: worklist.add(nodes.get(i));
On 2009/12/01 20:36:45, Lex wrote:
I see a lot of random access on lists in this function. Making them
ArrayLists
instead of Lists would prevent accidental bad performance if anyone
tries to
substitute something else.
Done.
http://gwt-code-reviews.appspot.com/112811/diff/1/4#newcode167
Line 167: throw new IllegalArgumentException();
On 2009/12/01 20:36:45, Lex wrote:
Be consistent with this exception message and the previous one?
Done.
http://gwt-code-reviews.appspot.com/112811/diff/1/4#newcode181
Line 181: addSuccessors(g, worklist, node);
On 2009/12/01 20:36:45, Lex wrote:
Doesn't this add more nodes than necessary to the work list? If only
one output
edge changes, then only that node's target edge needs to be visited
again.
Done.
http://gwt-code-reviews.appspot.com/112811/diff/1/4#newcode185
Line 185: for (int i = 0; i inEdges.size(); i++) {
On 2009/12/01 20:36:45, Lex wrote:
Analogous questions here as for the previous loop.
Done.
http://gwt-code-reviews.appspot.com/112811/diff/1/4#newcode205
Line 205: * Solve integrated analysis.
On 2009/12/01 20:36:45, Lex wrote:
Solve an integrated analysis by using an IntegratedFlowFunctionAdapter
and
recursing into {...@link #solve()}
Done.
http://gwt-code-reviews.appspot.com/112811/diff/1/4#newcode327
Line 327: private A extends AssumptionA MapE, A iterate(G g,
On 2009/12/01 20:36:45, Lex wrote:
This method deserves a method comment.
Done.
http://gwt-code-reviews.appspot.com/112811/diff/1/5
File dev/core/src/com/google/gwt/dev/jjs/impl/flow/Assumption.java
(right):
http://gwt-code-reviews.appspot.com/112811/diff/1/5#newcode30
Line 30: Self meet(Self value);
On 2009/12/01 20:36:45, Lex wrote:
The least upper bound is a *join*, not a meet.
Done.
http://gwt-code-reviews.appspot.com/112811/diff/1/7
File dev/core/src/com/google/gwt/dev/jjs/impl/flow/FlowFunction.java
(right):
http://gwt-code-reviews.appspot.com/112811/diff/1/7#newcode24
Line 24: * not clear
[gwt-contrib] Re: Flow analysis framework definition and solver.
On Tue, Dec 1, 2009 at 4:52 PM, mike.aizat...@gmail.com wrote: I can create a separate CFG changelist + CFG-based analyses changelist. I just worry that I will have to maintain several changelist branches + main branch with all the code together. I would certainly prefer to land this code into SVN even before it's actually plugged into compiler. Well, it would be sitting in svn and not being tested in any way except that it compiles. If you want to commit the pieces somewhere, why don't we make an svn branch? Shall I do that? We can then put in the patches as they are committed on the branch, and merge it to trunk once enough is in that it does something. For using this framework to walk the callgraph, I understand that the implementation is simple, but simple things often don't perform well. An easily O(n^3) graph traversal is okay if n is only the size of one method, but is problematic if we are talking about a whole program. Mostly, though, I'd simply like to divide the issue. Since the patch is already large, let's do the intra-proc part first. Lex -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: Flow analysis framework definition and solver.
Well, it would be sitting in svn and not being tested in any way except that it compiles. If you want to commit the pieces somewhere, why don't we make an svn branch? I don't think svn branch will help much. It will only add headaches. What do you say if I would merge all LGTM'ed changes together into single git branch on my workstation? This would at least help me reduce the number of branches to maintain to 3: dev branch, under review branch, LGTM'ed branch. I can also actively export that branch to github if you need. For using this framework to walk the callgraph, I understand that the implementation is simple, but simple things often don't perform well. An easily O(n^3) graph traversal is okay if n is only the size of one method, but is problematic if we are talking about a whole program. I don't see where you get O(n^3). Solver algorithm complexity is O(e * l) where e is number of edges, and l is lattice height. For a simple boolean lattice l = 2, so this should be quite efficient from algorithmic point of view. Mostly, though, I'd simply like to divide the issue. Since the patch is already large, let's do the intra-proc part first. Ok. I'll cut the CFG change. On Tue, Dec 1, 2009 at 2:20 PM, Lex Spoon sp...@google.com wrote: On Tue, Dec 1, 2009 at 4:52 PM, mike.aizat...@gmail.com wrote: I can create a separate CFG changelist + CFG-based analyses changelist. I just worry that I will have to maintain several changelist branches + main branch with all the code together. I would certainly prefer to land this code into SVN even before it's actually plugged into compiler. Well, it would be sitting in svn and not being tested in any way except that it compiles. If you want to commit the pieces somewhere, why don't we make an svn branch? Shall I do that? We can then put in the patches as they are committed on the branch, and merge it to trunk once enough is in that it does something. For using this framework to walk the callgraph, I understand that the implementation is simple, but simple things often don't perform well. An easily O(n^3) graph traversal is okay if n is only the size of one method, but is problematic if we are talking about a whole program. Mostly, though, I'd simply like to divide the issue. Since the patch is already large, let's do the intra-proc part first. Lex -- Regards, Mike -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Increase Java stack size for JUnit tests
Reviewers: jgw,
Description:
UiBinderTest requires 256k stack size. This patch increases the stack
size to 512k.
Please review this at http://gwt-code-reviews.appspot.com/115806
Affected files:
common.ant.xml
Index: common.ant.xml
===
--- common.ant.xml (revision 7218)
+++ common.ant.xml (working copy)
@@ -187,6 +187,7 @@
junit dir=@{test.out} fork=yes printsummary=yes
failureproperty=junit.failure tempdir=@{test.out}
jvmarg line=-Xmx768m /
+jvmarg line=-Xss512k /
jvmarg
value=-demma.coverage.out.fi...@{test.emma.coverage}/coverage.emma /
jvmarg value=-Demma.coverage.out.merge=true /
sysproperty key=gwt.args value=@{test.args} /
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] [google-web-toolkit] r7221 committed - Fix for hosted.html missing plugin warning in IE7+ quirks mode....
Revision: 7221
Author: j...@google.com
Date: Tue Dec 1 15:17:53 2009
Log: Fix for hosted.html missing plugin warning in IE7+ quirks mode.
Found by: cramsdale
Patch by: scottb
Review by: jgw (desk check)
http://code.google.com/p/google-web-toolkit/source/detail?r=7221
Modified:
/trunk/dev/core/src/com/google/gwt/core/ext/linker/impl/hosted.html
===
--- /trunk/dev/core/src/com/google/gwt/core/ext/linker/impl/hosted.html Mon
Nov 30 07:50:48 2009
+++ /trunk/dev/core/src/com/google/gwt/core/ext/linker/impl/hosted.html Tue
Dec 1 15:17:53 2009
@@ -173,20 +173,19 @@
} else {
topDoc.documentElement.style[overflow] = hidden;
}
-
+
// Steal focus.
glass.focus();
-
- if (navigator.userAgent.indexOf(MSIE 6) = 0) {
+
+ if ((navigator.userAgent.indexOf(MSIE) = 0) (topDoc.compatMode
== BackCompat)) {
+// IE quirks mode doesn't support right/bottom, but does support this.
+glassStyle.width = 125%;
+glassStyle.height = 100%;
+ } else if (navigator.userAgent.indexOf(MSIE 6) = 0) {
+// IE6 doesn't have a real standards mode, so we have to use hacks.
glassStyle.width = 125%; // Get past scroll bar area.
-if (topDoc.compatMode == BackCompat) {
- // Works in quirks mode.
- glassStyle.height = 100%;
-} else {
- // Use a nasty CSS expression in standards mode; ideally we'd use the
- // onresize event, but the outer window won't let us add one in IE6.
-
glassStyle.setExpression(height, document.documentElement.clientHeight);
-}
+// Nasty CSS; onresize would be better but the outer window won't let
us add a listener IE.
+
glassStyle.setExpression(height, document.documentElement.clientHeight);
}
}
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: More UiBinder javadoc
On 2009/12/01 15:32:21, jgw wrote: On 2009/12/01 06:34:15, Ray Ryan wrote: Joel, can you review this? In fact, can you submit it for me, since it seems like you early rising Atlantoids may roll GA before I get in? Also, I haven't doc'd LayoutPanel itself, because I don't quite understand its constraints. Have it in you? LGTM. I've added LayoutPanel doc as well, and will commit the lot with minor tweaks as soon as the build's green again :) Committed at r7223. http://gwt-code-reviews.appspot.com/116803 -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] [google-web-toolkit] r7222 committed - Increasing the stack size when running JUnit tests because UiBinderTes...
Revision: 7222
Author: jlaba...@google.com
Date: Tue Dec 1 15:21:09 2009
Log: Increasing the stack size when running JUnit tests because
UiBinderTest requires more than 256k.
Patch by: jlabanca
Review by: jat
http://code.google.com/p/google-web-toolkit/source/detail?r=7222
Modified:
/trunk/common.ant.xml
===
--- /trunk/common.ant.xml Thu Nov 12 12:28:34 2009
+++ /trunk/common.ant.xml Tue Dec 1 15:21:09 2009
@@ -187,6 +187,7 @@
junit dir=@{test.out} fork=yes printsummary=yes
failureproperty=junit.failure tempdir=@{test.out}
jvmarg line=-Xmx768m /
+jvmarg line=-Xss512k /
jvmarg
value=-demma.coverage.out.fi...@{test.emma.coverage}/coverage.emma /
jvmarg value=-Demma.coverage.out.merge=true /
sysproperty key=gwt.args value=@{test.args} /
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] [google-web-toolkit] r7223 committed - Adding UiBinder doc for widgets that require it....
Revision: 7223
Author: j...@google.com
Date: Tue Dec 1 15:21:10 2009
Log: Adding UiBinder doc for widgets that require it.
Review: http://gwt-code-reviews.appspot.com/116803
http://code.google.com/p/google-web-toolkit/source/detail?r=7223
Modified:
/trunk/user/src/com/google/gwt/user/client/ui/CustomButton.java
/trunk/user/src/com/google/gwt/user/client/ui/DialogBox.java
/trunk/user/src/com/google/gwt/user/client/ui/DisclosurePanel.java
/trunk/user/src/com/google/gwt/user/client/ui/DockLayoutPanel.java
/trunk/user/src/com/google/gwt/user/client/ui/HasHTML.java
/trunk/user/src/com/google/gwt/user/client/ui/HasText.java
/trunk/user/src/com/google/gwt/user/client/ui/LayoutPanel.java
/trunk/user/src/com/google/gwt/user/client/ui/MenuBar.java
/trunk/user/src/com/google/gwt/user/client/ui/StackLayoutPanel.java
/trunk/user/src/com/google/gwt/user/client/ui/TabLayoutPanel.java
/trunk/user/test/com/google/gwt/uibinder/test/client/WidgetBasedUi.ui.xml
===
--- /trunk/user/src/com/google/gwt/user/client/ui/CustomButton.java Wed
Nov 4 10:50:50 2009
+++ /trunk/user/src/com/google/gwt/user/client/ui/CustomButton.java Tue
Dec 1 15:21:10 2009
@@ -20,6 +20,7 @@
import com.google.gwt.dom.client.NativeEvent;
import com.google.gwt.event.dom.client.ClickEvent;
import com.google.gwt.event.dom.client.ClickHandler;
+import com.google.gwt.resources.client.ImageResource;
import com.google.gwt.user.client.DOM;
import com.google.gwt.user.client.Element;
import com.google.gwt.user.client.Event;
@@ -99,6 +100,38 @@
* /table
* /p
*
+ * h3Use in UiBinder Templates/h3
+ *
+ * When working with CustomButton subclasses in
+ * {...@link com.google.gwt.uibinder.client.UiBinder UiBinder} templates, you
+ * can set text and assign ImageResources for their various faces via
+ * child elements:
+ * p
+ * dl
+ * dtlt;g:upFace
+ * dtlt;g:downFace
+ * dtlt;g:upHoveringFace
+ * dtlt;g:downHoveringFace
+ * dtlt;g:upDisabledFace
+ * dtlt;g:downDisabledFace
+ * /dl
+ *
+ * Each face element can take an optional codeimage/code attribute
+ * and an html body. For example:pre
+ * lt;ui:image field='downButton'/ lt;!-- define an {...@link
ImageResource} --
+ *
+ * lt;g:PushButton ui:field='pushButton' enabled='true'
+ * lt;g:upFace
+ * lt;bclick melt;/b
+ * lt;/gwt:upFace
+ * lt;g:upHoveringFace
+ * lt;bClick ME!lt;/b
+ * lt;/gwt:upHoveringFace
+ *
+ * lt;g:downFace image='{downButton}'/
+ * lt;g:downHoveringFace image='{downButton}'/
+ * lt;/g:PushButton
+ * /pre
*/
public abstract class CustomButton extends ButtonBase {
/**
===
--- /trunk/user/src/com/google/gwt/user/client/ui/DialogBox.javaWed Nov
4
09:18:51 2009
+++ /trunk/user/src/com/google/gwt/user/client/ui/DialogBox.javaTue Dec
1
15:21:10 2009
@@ -79,6 +79,26 @@
* h3Example/h3
* {...@example com.google.gwt.examples.DialogBoxExample}
* /p
+ *
+ * h3Use in UiBinder Templates/h3
+ * p
+ * DialogBox elements in
+ * {...@link com.google.gwt.uibinder.client.UiBinder UiBinder} templates can
+ * have one widget child and one lt;g:caption child. (Note the lower case
+ * c, meant to signal that the caption is not a runtime object, and so
cannot
+ * have a codeui:field/code attribute.) The body of the
+ * caption can be html.
+ * p
+ * For example: pre
+ * lt;g:DialogBox autoHide=true modal=true
+ * lt;g:captionlt;bCaption textlt;/blt;/g:caption
+ * lt;g:HTMLPanel
+ * Body text
+ * lt;g:Button ui:field='cancelButton'Cancellt;/g:Button
+ * lt;g:Button ui:field='okButton'Okaylt;/g:Button
+ * lt;/g:HTMLPanel
+ * lt;/g:DialogBox
+ * /pre
*/
@SuppressWarnings(deprecation)
public class DialogBox extends DecoratedPopupPanel implements HasHTML,
===
--- /trunk/user/src/com/google/gwt/user/client/ui/DisclosurePanel.java Wed
Oct 28 15:52:50 2009
+++ /trunk/user/src/com/google/gwt/user/client/ui/DisclosurePanel.java Tue
Dec 1 15:21:10 2009
@@ -37,11 +37,15 @@
* A widget that consists of a header and a content panel that discloses
the
* content when a user clicks on the header.
*
- * h3CSS Style Rules/h3 ul class=css li.gwt-DisclosurePanel { the
- * panel's primary style }/li li.gwt-DisclosurePanel-open { dependent
style
- * set when panel is open }/li li.gwt-DisclosurePanel-closed {
dependent
- * style set when panel is closed }/li
- *
+ * h3CSS Style Rules/h3
+ * dl class=css
+ * dt.gwt-DisclosurePanel
+ * ddthe panel's primary style
+ * dt.gwt-DisclosurePanel-open
+ * dd dependent style set when panel is open
+ * dt.gwt-DisclosurePanel-closed
+ * dd dependent style set when panel is closed
+ * /dl
* p
* img class='gallery' src='DisclosurePanel.png'/
* /p
@@ -51,6 +55,29 @@
* selector:br/
* .gwt-DisclosurePanel-open .header { ... }
* /p
+ * h3Use in UiBinder Templates/h3
+ * p
+ * DisclosurePanel elements in
+ * {...@link
[gwt-contrib] [google-web-toolkit] r7224 committed - tr...@7222 was merged into this branch...
Revision: 7224
Author: jlaba...@google.com
Date: Tue Dec 1 15:25:46 2009
Log: tr...@7222 was merged into this branch
Increase stack size of JUnit tests.
svn merge --ignore-ancestry -c7222
https://google-web-toolkit.googlecode.com/svn/trunk/ .
Patch by: jlabanca
http://code.google.com/p/google-web-toolkit/source/detail?r=7224
Modified:
/releases/2.0/branch-info.txt
/releases/2.0/common.ant.xml
===
--- /releases/2.0/branch-info.txt Tue Dec 1 14:05:14 2009
+++ /releases/2.0/branch-info.txt Tue Dec 1 15:25:46 2009
@@ -1125,3 +1125,7 @@
Javadoc fixes.
svn merge --ignore-ancestry -c7219 \
https://google-web-toolkit.googlecode.com/svn/trunk/ .
+
+tr...@7222 was merged into this branch
+ Increase stack size of JUnit tests.
+svn merge --ignore-ancestry -c7222
https://google-web-toolkit.googlecode.com/svn/trunk/ .
===
--- /releases/2.0/common.ant.xmlThu Nov 12 12:45:28 2009
+++ /releases/2.0/common.ant.xmlTue Dec 1 15:25:46 2009
@@ -187,6 +187,7 @@
junit dir=@{test.out} fork=yes printsummary=yes
failureproperty=junit.failure tempdir=@{test.out}
jvmarg line=-Xmx768m /
+jvmarg line=-Xss512k /
jvmarg
value=-demma.coverage.out.fi...@{test.emma.coverage}/coverage.emma /
jvmarg value=-Demma.coverage.out.merge=true /
sysproperty key=gwt.args value=@{test.args} /
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: Flow analysis framework definition and solver.
On Tue, Dec 1, 2009 at 5:59 PM, Mike Aizatsky mike.aizat...@gmail.com wrote: Well, it would be sitting in svn and not being tested in any way except that it compiles. If you want to commit the pieces somewhere, why don't we make an svn branch? I don't think svn branch will help much. It will only add headaches. What do you say if I would merge all LGTM'ed changes together into single git branch on my workstation? This would at least help me reduce the number of branches to maintain to 3: dev branch, under review branch, LGTM'ed branch. I can also actively export that branch to github if you need. Sounds good. Git is optional; please do if it's easy, but don't worry if it's not. I can patch in multiple patches just fine. For using this framework to walk the callgraph, I understand that the implementation is simple, but simple things often don't perform well. An easily O(n^3) graph traversal is okay if n is only the size of one method, but is problematic if we are talking about a whole program. I don't see where you get O(n^3). Solver algorithm complexity is O(e * l) where e is number of edges, and l is lattice height. For a simple boolean lattice l = 2, so this should be quite efficient from algorithmic point of view. I said n^3 because frequently the information is a set that is proportional to the size of the program. For example, we'd like to analyze clinits that have definitely been called. Then the lattice height is the number of classes in the program, which is proportional to n. When you multiply it all out you get n^3 or n^4, depending on how big you assume the call graphs are. Lex -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: Increase Java stack size for JUnit tests
LGTM http://gwt-code-reviews.appspot.com/115806 -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: Comment on UiBinder in google-web-toolkit
Comment by vincent.case: I found these UiBinder use cases very helpful in understanding the APIs. However, I am unable to determine if UIBinder addresses the gwt 1.7 issues I have with formatting my app layout using CSS. Specifically, * HTML generated by gwt layout widgets is not transparent/explicit, obscuring the application/intrepretation of css to the layout * HTML generated by gwt layout widgets is table based, foregoing the possiblity of many css layout techniques Is one of the intentions of UiBinder to facilitate the use of CSS for app Layout by: * Allowing definition of an explicit HTML structue in the UIBinder xml to which css can be applied * Allowing app structure to be defined without use of the table based gwt widgets Thanks for your feedback. For more information: http://code.google.com/p/google-web-toolkit/wiki/UiBinder -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] GWT RC2: TabPanelLayout -- no supporting CSS?
All, I found myself needing band-aids (read: bleeding edge) while trying out TabLayoutPanel. 1) The javadocs and code for TabLayoutPanel suggest that the gwt- TabLayoutPanel(*) css selectors exist: http://code.google.com/p/google-web-toolkit/source/browse/releases/2.0/user/src/com/google/gwt/user/client/ui/TabLayoutPanel.java 2) And, poking around the trunk shows this tidy example: http://code.google.com/p/google-web-toolkit/source/browse/releases/2.0/user/javadoc/com/google/gwt/examples/TabLayoutPanelExample.java 3) When that example is implemented, there is no CSS on the TabLayoutPanel: http://tablayoutpanel.latest.emcode-dev.appspot.com/ While there is no CSS to dress it up, the layout and events are mostly correct on Safari 4.0.3 (Mac). But on FF 3.5.5 (Mac) only one tab shows (the third) sitting above the contents of the first tab. Yikes, not really cross-browser. 4) Of course, it seems that the main problem is that the new gwt- TabLayoutPanel(*) selectors don't yet exist, in here: http://code.google.com/p/google-web-toolkit/source/browse/trunk/user/src/com/google/gwt/user/theme/standard/public/gwt/standard/standard.css or any other of the themes/css files. Is there someone sitting on a patch for gwt-TabLayoutPanel(*) selectors, or is the problem deeper? I came across a couple of TODOs and hints about css floats maybe not doing the trick under the TabLayoutPanel implementation. Any help on this? In the meantime, is there sample UIBinder xml to use the old TabPanel instead? -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: Comment on UiBinder in google-web-toolkit
Comment by j...@google.com: @vincent.case: It's not clear precisely what you're referring to when you reference the gwt layout widgets. Are you referring to the new *LayoutPanel structures or the existing panels such as DockPanel, Horizontal/VerticalPanel and such? The existing panels derived from CellPanel are all based on tables, which we know to be problematic under some circumstances. The newer *LayoutPanel classes do not use tables, are much more predictable in their behavior, and fully support standards-mode doctypes, unlike the older table-based panels. If you want to use common CSS layout techniques involving tricks like float:left, explicit large margins, and so forth, there's nothing stopping you from using regular widgets in FlowPanels and HTMLPanels and applying whatever CSS trickery you like. UiBinder actually makes this much easier by making it simple to use HTMLPanel and mix arbitrary HTML and widgets. For more information: http://code.google.com/p/google-web-toolkit/wiki/UiBinder -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: Make UiBinder handle custom subclasses of DialogBox
Ping. This is fairly urgent. http://gwt-code-reviews.appspot.com/115803 -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] [google-web-toolkit] r7228 committed - Fixing TabLayoutPanel tab stacking (float - cssFloat)....
Revision: 7228
Author: j...@google.com
Date: Tue Dec 1 22:01:22 2009
Log: Fixing TabLayoutPanel tab stacking (float - cssFloat).
Review: jlabanca (tbr)
http://code.google.com/p/google-web-toolkit/source/detail?r=7228
Modified:
/trunk/user/src/com/google/gwt/user/client/ui/TabLayoutPanel.java
===
--- /trunk/user/src/com/google/gwt/user/client/ui/TabLayoutPanel.java Tue
Dec 1 15:21:10 2009
+++ /trunk/user/src/com/google/gwt/user/client/ui/TabLayoutPanel.java Tue
Dec 1 22:01:22 2009
@@ -108,7 +108,7 @@
// heights, the shorter ones will top-align, rather than
bottom-align,
// which is what we would want. display:inline-block fixes this, but
// needs lots of cross-browser hacks to work properly.
- getElement().getStyle().setProperty(float, left);
+ getElement().getStyle().setProperty(cssFloat, left);
}
public HandlerRegistration addClickHandler(ClickHandler handler) {
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] TBR: float - cssFloat in TabLayoutPanel
http://code.google.com/p/google-web-toolkit/source/detail?r=7228 This was a mistake on my part. Some browsers (e.g., Firefox) won't accept elem.style['float'], but rather require elem.style['cssFloat']. -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] GWT RC2: TabPanelLayout -- no supporting CSS?
Joel,
Is there something special that I need to do in my ui.xml in order to get
these CSS rules applied to my TabLayoutPanel?
!DOCTYPE ui:UiBinder SYSTEM
http://google-web-toolkit.googlecode.com/files/xhtml.ent;
ui:UiBinder
xmlns:ui='urn:ui:com.google.gwt.uibinder'
xmlns:g='urn:import:com.google.gwt.user.client.ui'
... ui style ... src? type? empty? do I add {style.*} styles to the XML
below?
g:TabLayoutPanel ui:field=tabLayoutPanel barHeight=20
g:tabg:headerFirst Tab/g:headerg:HTMLfirst tab
content/g:HTML/g:tab
g:tabg:headerSecond Tab/g:headerg:HTMLsecond tab
content/g:HTML/g:tab
/g:TabLayoutPanel
/ui:UiBinder
You'll notice my sample app which has no default CSS rules applied:
http://tablayoutpanel.latest.emcode-dev.appspot.com/
Stuart
On Wed, Dec 2, 2009 at 12:49 AM, Joel Webber j...@google.com wrote:
The following CSS rules should work fine with the TabLayoutPanel as checked
in:
.gwt-TabLayoutPanel { }
.gwt-TabLayoutPanelTabs { }
.gwt-TabLayoutPanelTab { }
.gwt-TabLayoutPanelTab .gwt-TabLayoutPanelTabInner { }
.gwt-TabLayoutPanelTab-selected { }
.gwt-TabLayoutPanelTab-selected .gwt-TabLayoutPanelTabInner { }
While we haven't added rules to default.css, et al, these rules should be
sufficient for most standard CSS tricks. There is indeed an issue that's
causing the tabs to stack up on Firefox, for which I will be committing a
patch momentarily (TabLayoutPanel.java:111 should be setting cssFloat
rather than just float).
If you run into other problems with the structures that are there, please
let me know.
Thanks,
joel.
On Tue, Dec 1, 2009 at 11:12 PM, Stuart Moffatt
stuartmoff...@gmail.comwrote:
All,
I found myself needing band-aids (read: bleeding edge) while trying
out TabLayoutPanel.
1) The javadocs and code for TabLayoutPanel suggest that the gwt-
TabLayoutPanel(*) css selectors exist:
http://code.google.com/p/google-web-toolkit/source/browse/releases/2.0/user/src/com/google/gwt/user/client/ui/TabLayoutPanel.java
2) And, poking around the trunk shows this tidy example:
http://code.google.com/p/google-web-toolkit/source/browse/releases/2.0/user/javadoc/com/google/gwt/examples/TabLayoutPanelExample.java
3) When that example is implemented, there is no CSS on the
TabLayoutPanel:
http://tablayoutpanel.latest.emcode-dev.appspot.com/
While there is no CSS to dress it up, the layout and events are mostly
correct on Safari 4.0.3 (Mac). But on FF 3.5.5 (Mac) only one tab
shows (the third) sitting above the contents of the first tab. Yikes,
not really cross-browser.
4) Of course, it seems that the main problem is that the new gwt-
TabLayoutPanel(*) selectors don't yet exist, in here:
http://code.google.com/p/google-web-toolkit/source/browse/trunk/user/src/com/google/gwt/user/theme/standard/public/gwt/standard/standard.css
or any other of the themes/css files.
Is there someone sitting on a patch for gwt-TabLayoutPanel(*)
selectors, or is the problem deeper? I came across a couple of TODOs
and hints about css floats maybe not doing the trick under the
TabLayoutPanel implementation. Any help on this?
In the meantime, is there sample UIBinder xml to use the old TabPanel
instead?
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] [google-web-toolkit] r7229 committed - Merging /trunk r7228 into this branch.
Revision: 7229
Author: j...@google.com
Date: Tue Dec 1 22:03:38 2009
Log: Merging /trunk r7228 into this branch.
http://code.google.com/p/google-web-toolkit/source/detail?r=7229
Modified:
/releases/2.0/branch-info.txt
/releases/2.0/user/src/com/google/gwt/user/client/ui/TabLayoutPanel.java
===
--- /releases/2.0/branch-info.txt Tue Dec 1 21:26:37 2009
+++ /releases/2.0/branch-info.txt Tue Dec 1 22:03:38 2009
@@ -1148,3 +1148,7 @@
Also fixes mail icon showing up in front of the about dialog.
svn merge --ignore-ancestry -c7226
https://google-web-toolkit.googlecode.com/svn/trunk/ .
+tr...@7228 was merged into this branch
+ Fixing TabLayoutPanel tab stacking (float - cssFloat).
+svn merge --ignore-ancestry -c7228
https://google-web-toolkit.googlecode.com/svn/trunk/ .
+
===
---
/releases/2.0/user/src/com/google/gwt/user/client/ui/TabLayoutPanel.java
Tue Dec 1 21:26:37 2009
+++
/releases/2.0/user/src/com/google/gwt/user/client/ui/TabLayoutPanel.java
Tue Dec 1 22:03:38 2009
@@ -108,7 +108,7 @@
// heights, the shorter ones will top-align, rather than
bottom-align,
// which is what we would want. display:inline-block fixes this, but
// needs lots of cross-browser hacks to work properly.
- getElement().getStyle().setProperty(float, left);
+ getElement().getStyle().setProperty(cssFloat, left);
}
public HandlerRegistration addClickHandler(ClickHandler handler) {
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] question about GWT RichTextArea
Dear John, I would like to thank you for your response. We were working with GWT 1.7 and now we have to upgrade to 2.0. Thanks, Nicolas 2009/11/28 John LaBanca jlaba...@google.com Try this: richTextArea.getFormatter().setJustification(Justification.FULL); The RichTextArea uses execCommand() to modify the currently selected contents of the editable area. Some of the inputs to execCommand() do not match similar CSS style names exactly. Thanks, John LaBanca jlaba...@google.com On Fri, Nov 27, 2009 at 8:58 AM, Nicolas Job 955...@gmail.com wrote: Dear contributors, I'm using the RichTextArea component from Google Web Toolkit and I met a problem with justifing text inside the text area. What I want is to justify my text like the CSS property text-align:justify; do it. Someone could help me ? is that feature planified in this editor ? Many thanks, Nicolas Job -- -- - ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ° ° ° ° ° ° ° ° '((( ° ° \ °|/ ° \ \/ ° \/ |/ ` \| \ / _ _ - _ ~ - /_\ ~-_ - ____ __ - -- http://groups.google.com/group/Google-Web-Toolkit-Contributors -- http://groups.google.com/group/Google-Web-Toolkit-Contributors -- -- - ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ° ° ° ° ° ° ° ° '((( ° ° \ °|/ ° \ \/ ° \/ |/ ` \| \ / _ _ - _ ~ - /_\ ~-_ - ____ __ - -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
