[gwt-contrib] Re: GWT 2.0.1 breaks incubator 2.0 ... is a new release emminent ?
ok this was my fault, I didnt upgrade correctly. works fine in 2.0.1, except for message Line 30: Referencing deprecated class 'com.google.gwt.user.client.impl.DocumentRootImpl' and the same in line 38. thanks for the great job! On 10 Feb., 12:44, David david.no...@gmail.com wrote: I didn't get the chance to test it out, due to corporate red tape :-( David On Tue, Feb 9, 2010 at 3:51 PM, John LaBanca jlaba...@google.com wrote: I'll take a look and make sure we can use the incubator jar with GWT 2.0. Thanks, John LaBanca jlaba...@google.com On Tue, Feb 9, 2010 at 8:35 AM, newnoise tommmuel...@googlemail.com wrote: acutally i get the errors in the version downloaded today also. On 8 Feb., 16:09, John LaBanca jlaba...@google.com wrote: Wow, 2010 already. Fixed. Thanks, John LaBanca jlaba...@google.com On Sat, Feb 6, 2010 at 8:52 AM, jim n northrup.ja...@gmail.com wrote: can you name it 2010x please? On Feb 4, 8:19 am, Ray Ryan rj...@google.com wrote: And the jar is posted. All better? On Thu, Feb 4, 2010 at 7:15 AM, Ray Ryan rj...@google.com wrote: Sorry, we'll get a 2.0.1 incubator jar up today. On Thu, Feb 4, 2010 at 7:04 AM, stuckagain david.no...@gmail.com wrote: Hi, The changes to CurrencyData and CurrencyList as described in the release note of GWT 2.0.1 has impact on the current GWT incubator CurrencyWidget. Is there a new release planned ? It seems to be fixed in the trunk of incubator. This is the compilation error. [ERROR] Errors in 'jar:file:/W:/rlsCOTS/gwtincubator/JAVA/lib/gwt- incubator.jar!/com/google/gwt/widgetideas/client/CurrencyWidget.java' [java] [ERROR] Line 46: The import com.google.gwt.i18n.client.impl.CurrencyData cannot be resolved [java] [ERROR] Line 47: The import com.google.gwt.i18n.client.impl.CurrencyList cannot be resolved [java] [ERROR] Line 107: CurrencyData cannot be resolved to a type [java] [ERROR] Line 122: CurrencyData cannot be resolved to a type [java] [ERROR] Line 122: CurrencyList cannot be resolved [java] [ERROR] Line 123: CurrencyData cannot be resolved to a type [java] [ERROR] Line 124: CurrencyData cannot be resolved to a type [java] [ERROR] Line 181: CurrencyData cannot be resolved to a type David -- http://groups.google.com/group/Google-Web-Toolkit-Contributors -- I wish this were a Wave -- I wish this were a Wave -- http://groups.google.com/group/Google-Web-Toolkit-Contributors -- http://groups.google.com/group/Google-Web-Toolkit-Contributors -- http://groups.google.com/group/Google-Web-Toolkit-Contributors -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Upgrade for get/setInnerText in DOMImplSafari.
Reviewers: jgw, jaimeyap,
Description:
Upgrade WebKit's DOM library to use textContent instead of falling back
to the slow versions of setInnerText and getInnerText.
Please review this at http://gwt-code-reviews.appspot.com/143803
Affected files:
M user/src/com/google/gwt/dom/client/DOMImplSafari.java
Index: user/src/com/google/gwt/dom/client/DOMImplSafari.java
diff --git
a/google3/third_party/java/gwt/source/svn/trunk/user/src/com/google/gwt/dom/client/DOMImplSafari.java
b/google3/third_party/java/gwt/source/svn/trunk/user/src/com/google/gwt/dom/client/DOMImplSafari.java
index
c6a5d2cd0a813b9767b8de0495762f826f12a7d7..24ec4e331c3abc08c4d7b3ddffbe1839cf21a528
100644
---
a/google3/third_party/java/gwt/source/svn/trunk/user/src/com/google/gwt/dom/client/DOMImplSafari.java
+++
b/google3/third_party/java/gwt/source/svn/trunk/user/src/com/google/gwt/dom/client/DOMImplSafari.java
@@ -168,6 +168,18 @@ class DOMImplSafari extends DOMImplStandard {
return top;
}-*/;
+ /*
+ * textContent is used over innerText for two reasons:
+ * 1 - It is consistent with DOMImplMozilla. textContent
+ * does not convert br's to new lines in WebKit.
+ * 2 - textContent is faster on retreival because WebKit
+ * does not recalculate styles as it does for innerText.
+ */
+ @Override
+ public native String getInnerText(Element node) /*-{
+return node.textContent;
+ }-*/;
+
@Override
public int getScrollLeft(Document doc) {
// Safari always applies document scrolling to the body element, even
in
@@ -215,9 +227,9 @@ class DOMImplSafari extends DOMImplStandard {
* elements, because their descendent elements are only one level deep.
*/
@Override
- public native void selectClear(SelectElement select) /*-{
-select.innerText = '';
- }-*/;
+ public void selectClear(SelectElement select) {
+select.setInnerText();
+ }
@Override
public native int selectGetLength(SelectElement select) /*-{
@@ -234,6 +246,14 @@ class DOMImplSafari extends DOMImplStandard {
select.removeChild(select.children[index]);
}-*/;
+ /*
+ * See getInnerText for why textContent is used instead of innerText.
+ */
+ @Override
+ public native void setInnerText(Element elem, String text) /*-{
+elem.textContent = text || '';
+ }-*/;
+
@Override
public void setScrollLeft(Document doc, int left) {
// Safari always applies document scrolling to the body element, even
in
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Use cellIndex and sectionRowIndex in HTMLTable::getCellForEvent
Reviewers: ,
Please review this at http://gwt-code-reviews.appspot.com/143805
Affected files:
M user/src/com/google/gwt/user/client/impl/DOMImplStandard.java
M user/src/com/google/gwt/user/client/ui/HTMLTable.java
Index: user/src/com/google/gwt/user/client/impl/DOMImplStandard.java
diff --git a/user/src/com/google/gwt/user/client/impl/DOMImplStandard.java
b/user/src/com/google/gwt/user/client/impl/DOMImplStandard.java
index
414e4c381e23b3179ccc0e03f1cdf5b6095307b1..61a6ea9522b2a7c723ca94597fa0a451fdceb6d6
100644
--- a/user/src/com/google/gwt/user/client/impl/DOMImplStandard.java
+++ b/user/src/com/google/gwt/user/client/impl/DOMImplStandard.java
@@ -71,13 +71,12 @@ abstract class DOMImplStandard extends DOMImpl {
public native Element getChild(Element elem, int index) /*-{
var count = 0, child = elem.firstChild;
while (child) {
- var next = child.nextSibling;
if (child.nodeType == 1) {
if (index == count)
return child;
++count;
}
- child = next;
+ child = child.nextSibling;
}
return null;
Index: user/src/com/google/gwt/user/client/ui/HTMLTable.java
diff --git a/user/src/com/google/gwt/user/client/ui/HTMLTable.java
b/user/src/com/google/gwt/user/client/ui/HTMLTable.java
index
54095a266bf7bde524c9173a0af787fb0cd37669..8278ca0ed6ed79436de5348abc959ff6eb9a7caa
100644
--- a/user/src/com/google/gwt/user/client/ui/HTMLTable.java
+++ b/user/src/com/google/gwt/user/client/ui/HTMLTable.java
@@ -16,6 +16,8 @@
package com.google.gwt.user.client.ui;
import com.google.gwt.dom.client.Document;
+import com.google.gwt.dom.client.TableCellElement;
+import com.google.gwt.dom.client.TableRowElement;
import com.google.gwt.event.dom.client.ClickEvent;
import com.google.gwt.event.dom.client.ClickHandler;
import com.google.gwt.event.dom.client.HasClickHandlers;
@@ -791,11 +793,8 @@ public abstract class HTMLTable extends Panel
implements SourcesTableEvents,
return null;
}
-Element tr = DOM.getParent(td);
-Element body = DOM.getParent(tr);
-int row = DOM.getChildIndex(body, tr);
-int column = DOM.getChildIndex(tr, td);
-
+int row =
TableRowElement.as(td.getParentElement()).getSectionRowIndex();
+int column = TableCellElement.as(td).getCellIndex();
return new Cell(row, column);
}
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: Use cellIndex and sectionRowIndex in HTMLTable::getCellForEvent
I ran through the whole process of getting this checked in, only to realize that there are a number of subtle api-checker failures that are exceedingly hard to get rid of. I'd rather we attack the user.Element - dom.Element transition in a single, coherent pass over the widget library (which will probably need a design doc to get it right). For now, I've surgically extracted the core optimization from this patch here: http://gwt-code-reviews.appspot.com/143805 http://gwt-code-reviews.appspot.com/125806 -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: Use cellIndex and sectionRowIndex in HTMLTable::getCellForEvent
LGTM http://gwt-code-reviews.appspot.com/143805 -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: Upgrade for get/setInnerText in DOMImplSafari.
On 2010/02/11 11:00:17, knorton wrote: LGTM http://gwt-code-reviews.appspot.com/141808 -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: MenuBar highlight style is not always removed when it loses focus
On 2010/02/10 20:54:50, jlabanca wrote: LGTM. http://gwt-code-reviews.appspot.com/141804 -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: Trivial fix for issue 3956 (REGRESSION: r5292 broke Opera support for History)
On 2010/02/10 19:50:26, jlabanca wrote: LGTM Committed at r7553. http://gwt-code-reviews.appspot.com/126812 -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] RR : Add ExternalCssResource
Reviewers: Ray Ryan, jgw, Message: Comments on the utility of this feature requested. Description: This patch adds a new CssResource type that externalizes the processed CSS instead of adding it to the compiled JavaScript. It allows the developer to trade additional round-trips and certain CssResource features for reduced JS size or parse time. If a regular, inline, CssResource uses only static features, a simpler code-generation path will be used, although this should have no user-visible effects. Features missing from ExternalCssResource: - @sprite - @if (Java expression), however the deferred-binding property version still works - The value() function This has been sitting in a git branch of mine since before the 2.0 release cycle started. I'm not entirely sure that externalizing CSS has actual value unless you're in a runtime environment that has very slow JS evaluation. Please review this at http://gwt-code-reviews.appspot.com/141809 Affected files: A user/src/com/google/gwt/resources/client/ExternalCssResource.java A user/src/com/google/gwt/resources/client/impl/ExternalCssResourcePrototype.java A user/src/com/google/gwt/resources/css/CheckStaticCssVisitor.java M user/src/com/google/gwt/resources/css/CssGenerationVisitor.java M user/src/com/google/gwt/resources/css/ast/CollapsedNode.java M user/src/com/google/gwt/resources/css/ast/CssDef.java M user/src/com/google/gwt/resources/css/ast/CssEval.java M user/src/com/google/gwt/resources/css/ast/CssExternalSelectors.java M user/src/com/google/gwt/resources/css/ast/CssIf.java M user/src/com/google/gwt/resources/css/ast/CssMediaRule.java M user/src/com/google/gwt/resources/css/ast/CssNoFlip.java M user/src/com/google/gwt/resources/css/ast/CssNode.java M user/src/com/google/gwt/resources/css/ast/CssPageRule.java M user/src/com/google/gwt/resources/css/ast/CssProperty.java M user/src/com/google/gwt/resources/css/ast/CssRule.java M user/src/com/google/gwt/resources/css/ast/CssSelector.java M user/src/com/google/gwt/resources/css/ast/CssSprite.java M user/src/com/google/gwt/resources/css/ast/CssStylesheet.java A user/src/com/google/gwt/resources/css/ast/CssSubstitution.java M user/src/com/google/gwt/resources/css/ast/CssUnknownAtRule.java M user/src/com/google/gwt/resources/css/ast/CssUrl.java M user/src/com/google/gwt/resources/rg/CssResourceGenerator.java M user/test/com/google/gwt/resources/client/CSSResourceTest.java A user/test/com/google/gwt/resources/client/external.css -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] Re: Add the ability to change the default HandlerManager of a Widget
But what if you have the case where you're setting the HandlerManager specifically because you want to stop listening to all the events from the previous HandlerManager. The idea of a stack of HandlerManagers makes some sense if you want to have different HandlerManagers handling events for different parts of a system. I understand the idea of making your own HandlerManager, but from a design perspective, doesn't it make sense to just have a singleton HandlerManager? Are there performance implications of having everything go through one HandlerManager? All the best, -- Arthur Kalmenson On Wed, Feb 10, 2010 at 11:34 AM, Isaac Truett itru...@gmail.com wrote: The argument seems to revolve around changing HandlerManagers resulting in the loss of registered handlers. Is it possible that the HandlerManager and the set of registered handlers aren't really the same thing and need to be separated? Would everyone be happy if you could call setHandlerManager() and the new manager would still service the same set of handlers that existed previously? On Wed, Feb 10, 2010 at 10:59 AM, Ray Ryan rj...@google.com wrote: I forgot about that nuance of your proposal. I like. @jat: the stack idea is nifty, but expanding the scope of the patch even worse than I am. And JL's proposal would let one implement that. On Wed, Feb 10, 2010 at 7:56 AM, John LaBanca jlaba...@google.com wrote: I still think my proposal solves this for both cases. We add a protected createHandlerManager, which is more restrictive because it is only called once per widget. We also make getHandlerManager() protected, which allows users to replace the HandlerManager if they really want to by overriding getHandlerManager to return one of many. It would be up to the developer to add a setHandlerManager() method in their own widgets that would change the return value of getHandlerManager(), so its intentionally more difficult and therefore forces the developer to think about it a little more. Thanks, John LaBanca jlaba...@google.com On Wed, Feb 10, 2010 at 10:44 AM, Sven Brunken sven.brun...@googlemail.com wrote: On 10 Feb., 16:28, Ray Ryan rj...@google.com wrote: Sven, you're arguing both sides here. You want things to be more customizable in general, but with your specific patch you're trying to be as restrictive as you can to achieve your personal goal. Both patches have the same restriction, once a handlermanager is set or the default one created, there is no way back to change it. I am also ok with a setHandlerManager without restrictions. But than people will have the problem that they will loose handlerregistrations, if they dont know what they are doing (and yes, there are these people). I wanted to make this patch as much fool proof as possible. It should be customaziable, but in a way, that you cannot brake it. I dont think that you really need to change the handlermanager during runtime after you set the first one. You also cannot change the element of a widget once you set the first one. I'm assuming that if we provide an unrestricted setHandlerManager we would also provide a getHandlerManager. It doesn't seem like rocket science to expect someone to check for an existing one if before clobbering it. I'm also assuming that these methods are protected, not part of every widget's public api. Yes sure, protected. They should not be public. I also would argue against providing both createHM and setHM. Redundant API is confusing API, another unfortunate trait of our widget set. Lazy creation can happen in the default implementation of getHM. A custom widget author could override that method to maintain laziness, or call setHM from their constructor to keep ours from ever seeing the light of day. I dont want to add boths. There is no need for it. One approach is more than sufficient. With both ways you would be able to change the default handlermanager (which is the goal in the end). On Tue, Feb 9, 2010 at 9:11 AM, Sven Brunken sven.brun...@googlemail.comwrote: The danger is that if you add handlers, and than later in your code call setHandlerManager with a new HandlerManager. If we dont check for a prior existing HandlerManager, all old HandlerRegistration's will be lost. If you dont know what happened, you will search forever why your old handlers are not working. You wont have the problem with a createHandlerManager method. On 9 Feb., 17:55, Ray Ryan rj...@google.com wrote: If you're right that swapping HMs midstream is a bad idea, I think you need a better argument than it's a bad idea. What's the actual danger? If I'm making my own HM I'm already pretty savvy. Why tie my hands? But yes, if you win that point, I agree with the change to replace setHM(HM) with HM createHM() -- http://groups.google.com/group/Google-Web-Toolkit-Contributors -- I wish
Re: [gwt-contrib] Re: Add the ability to change the default HandlerManager of a Widget
I think that violates the spirit, if not the letter, of the addHandler() contract. I add a handler and I get back a HandlerRegistration. I can use that registration to remove the handler later, if I choose to do so. If I expose that registration to other code, then the other code can also remove the handler. But if I guard my registration jealously, I expect that nobody else will have the ability to remove my handler. It seems to me that canceling all of the old handlers when the manager changes is a recipe for hard to find bugs, especially if changing HandlerManagers is not a common use case. You're going to have handlers suddenly stop receiving events and not be able to find an explicit removal. On Thu, Feb 11, 2010 at 11:36 AM, Arthur Kalmenson arthur.k...@gmail.com wrote: But what if you have the case where you're setting the HandlerManager specifically because you want to stop listening to all the events from the previous HandlerManager. The idea of a stack of HandlerManagers makes some sense if you want to have different HandlerManagers handling events for different parts of a system. I understand the idea of making your own HandlerManager, but from a design perspective, doesn't it make sense to just have a singleton HandlerManager? Are there performance implications of having everything go through one HandlerManager? All the best, -- Arthur Kalmenson On Wed, Feb 10, 2010 at 11:34 AM, Isaac Truett itru...@gmail.com wrote: The argument seems to revolve around changing HandlerManagers resulting in the loss of registered handlers. Is it possible that the HandlerManager and the set of registered handlers aren't really the same thing and need to be separated? Would everyone be happy if you could call setHandlerManager() and the new manager would still service the same set of handlers that existed previously? On Wed, Feb 10, 2010 at 10:59 AM, Ray Ryan rj...@google.com wrote: I forgot about that nuance of your proposal. I like. @jat: the stack idea is nifty, but expanding the scope of the patch even worse than I am. And JL's proposal would let one implement that. On Wed, Feb 10, 2010 at 7:56 AM, John LaBanca jlaba...@google.com wrote: I still think my proposal solves this for both cases. We add a protected createHandlerManager, which is more restrictive because it is only called once per widget. We also make getHandlerManager() protected, which allows users to replace the HandlerManager if they really want to by overriding getHandlerManager to return one of many. It would be up to the developer to add a setHandlerManager() method in their own widgets that would change the return value of getHandlerManager(), so its intentionally more difficult and therefore forces the developer to think about it a little more. Thanks, John LaBanca jlaba...@google.com On Wed, Feb 10, 2010 at 10:44 AM, Sven Brunken sven.brun...@googlemail.com wrote: On 10 Feb., 16:28, Ray Ryan rj...@google.com wrote: Sven, you're arguing both sides here. You want things to be more customizable in general, but with your specific patch you're trying to be as restrictive as you can to achieve your personal goal. Both patches have the same restriction, once a handlermanager is set or the default one created, there is no way back to change it. I am also ok with a setHandlerManager without restrictions. But than people will have the problem that they will loose handlerregistrations, if they dont know what they are doing (and yes, there are these people). I wanted to make this patch as much fool proof as possible. It should be customaziable, but in a way, that you cannot brake it. I dont think that you really need to change the handlermanager during runtime after you set the first one. You also cannot change the element of a widget once you set the first one. I'm assuming that if we provide an unrestricted setHandlerManager we would also provide a getHandlerManager. It doesn't seem like rocket science to expect someone to check for an existing one if before clobbering it. I'm also assuming that these methods are protected, not part of every widget's public api. Yes sure, protected. They should not be public. I also would argue against providing both createHM and setHM. Redundant API is confusing API, another unfortunate trait of our widget set. Lazy creation can happen in the default implementation of getHM. A custom widget author could override that method to maintain laziness, or call setHM from their constructor to keep ours from ever seeing the light of day. I dont want to add boths. There is no need for it. One approach is more than sufficient. With both ways you would be able to change the default handlermanager (which is the goal in the end). On Tue, Feb 9, 2010 at 9:11 AM, Sven Brunken sven.brun...@googlemail.comwrote: The danger is that if you add handlers, and than later in your code call
[gwt-contrib] Re: RR : Add ExternalCssResource
My knee jerk is that it seems redundant with RunAsync. That plus the fact that it has to be a slightly different feature set than normal make me wonder if it's worth it. http://gwt-code-reviews.appspot.com/141809 -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] Re: Add the ability to change the default HandlerManager of a Widget
This conversation keeps getting complicated by discussions of policy. I'm
just trying to make it possible for widgets we haven't thought of yet to
define policies of their own.
E.g., to temporarily switch between modes that change the set of events they
source, copying some handlers or not if that's appropriate (perhaps in mode
B I simply am not a source of the events that would happen in mode A.
Perhaps I am. Let me choose). E.g., to implement an HM stack. E.g., to try
out a singleton HM (I wouldn't, but why should I stop you from trying it
out).
I think JohnL has hit the sweet spot with:
/**
* Called by default implementation of {...@link #getHM}
* to lazily instantiate the HM for this widget.
*/
protected HM createHM();
/**
* All access to the widget's HM must be made through this method.
* It is an error to cache the object returned. The default implementation
* returns the result of {...@link #createHM} the first time it is called.
*/
protected HM getHM();
If I override getHM(), I have the option to call the normal createHM() to
get whatever HM the widget normally uses. Or not. If I override createHM() I
can provide a custom implementation, or wrap the normal one, without having
to re-implement the lazy instantiation mechanism.
Am I trying to provide flexibility that no one is asking for?
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] Re: Add the ability to change the default HandlerManager of a Widget
Am I trying to provide flexibility that no one is asking for?
In my opinion, this is providing flexibility that is not necessary and
is not a net positive change to the API. I'm not convinced that it's
the right thing to do. However if you were to provide that
flexibility, I would agree that get/createHM() is probably a better
way to go about it than setHM(). But I think that introducing
volatility to the HandlerManager exposes a flaw in the relationship
between Widgets, HandlerManagers, and Handlers.
On Thu, Feb 11, 2010 at 1:05 PM, Ray Ryan rj...@google.com wrote:
This conversation keeps getting complicated by discussions of policy. I'm
just trying to make it possible for widgets we haven't thought of yet to
define policies of their own.
E.g., to temporarily switch between modes that change the set of events they
source, copying some handlers or not if that's appropriate (perhaps in mode
B I simply am not a source of the events that would happen in mode A.
Perhaps I am. Let me choose). E.g., to implement an HM stack. E.g., to try
out a singleton HM (I wouldn't, but why should I stop you from trying it
out).
I think JohnL has hit the sweet spot with:
/**
* Called by default implementation of {...@link #getHM}
* to lazily instantiate the HM for this widget.
*/
protected HM createHM();
/**
* All access to the widget's HM must be made through this method.
* It is an error to cache the object returned. The default implementation
* returns the result of {...@link #createHM} the first time it is called.
*/
protected HM getHM();
If I override getHM(), I have the option to call the normal createHM() to
get whatever HM the widget normally uses. Or not. If I override createHM() I
can provide a custom implementation, or wrap the normal one, without having
to re-implement the lazy instantiation mechanism.
Am I trying to provide flexibility that no one is asking for?
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] Re: Add the ability to change the default HandlerManager of a Widget
I don't get that. If I (widget) have nothing to say to you for a while (am
not going to be generating the kinds of events that you are registered for),
why do you care if my mechanism for achieving that involves putting my usual
HM on ice? So long as I don't cause an error if you de-register in the
meantime, what's the problem?
On Thu, Feb 11, 2010 at 10:23 AM, Isaac Truett itru...@gmail.com wrote:
Am I trying to provide flexibility that no one is asking for?
In my opinion, this is providing flexibility that is not necessary and
is not a net positive change to the API. I'm not convinced that it's
the right thing to do. However if you were to provide that
flexibility, I would agree that get/createHM() is probably a better
way to go about it than setHM(). But I think that introducing
volatility to the HandlerManager exposes a flaw in the relationship
between Widgets, HandlerManagers, and Handlers.
On Thu, Feb 11, 2010 at 1:05 PM, Ray Ryan rj...@google.com wrote:
This conversation keeps getting complicated by discussions of policy. I'm
just trying to make it possible for widgets we haven't thought of yet to
define policies of their own.
E.g., to temporarily switch between modes that change the set of events
they
source, copying some handlers or not if that's appropriate (perhaps in
mode
B I simply am not a source of the events that would happen in mode A.
Perhaps I am. Let me choose). E.g., to implement an HM stack. E.g., to
try
out a singleton HM (I wouldn't, but why should I stop you from trying it
out).
I think JohnL has hit the sweet spot with:
/**
* Called by default implementation of {...@link #getHM}
* to lazily instantiate the HM for this widget.
*/
protected HM createHM();
/**
* All access to the widget's HM must be made through this method.
* It is an error to cache the object returned. The default
implementation
* returns the result of {...@link #createHM} the first time it is called.
*/
protected HM getHM();
If I override getHM(), I have the option to call the normal createHM() to
get whatever HM the widget normally uses. Or not. If I override
createHM() I
can provide a custom implementation, or wrap the normal one, without
having
to re-implement the lazy instantiation mechanism.
Am I trying to provide flexibility that no one is asking for?
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
--
I wish this were a Wave
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] Re: Add the ability to change the default HandlerManager of a Widget
I don't get why it would be necessary. What would you be able to do by
putting an HM on ice that you can't do with the existing API? Why
complicate things? Where's the use case that requires this new API?
Is this just a philosophical argument over narrowly defined, tightly
controlled APIs vs. more abundant, unrestricted APIs?
On Thu, Feb 11, 2010 at 1:34 PM, Ray Ryan rj...@google.com wrote:
I don't get that. If I (widget) have nothing to say to you for a while (am
not going to be generating the kinds of events that you are registered for),
why do you care if my mechanism for achieving that involves putting my usual
HM on ice? So long as I don't cause an error if you de-register in the
meantime, what's the problem?
On Thu, Feb 11, 2010 at 10:23 AM, Isaac Truett itru...@gmail.com wrote:
Am I trying to provide flexibility that no one is asking for?
In my opinion, this is providing flexibility that is not necessary and
is not a net positive change to the API. I'm not convinced that it's
the right thing to do. However if you were to provide that
flexibility, I would agree that get/createHM() is probably a better
way to go about it than setHM(). But I think that introducing
volatility to the HandlerManager exposes a flaw in the relationship
between Widgets, HandlerManagers, and Handlers.
On Thu, Feb 11, 2010 at 1:05 PM, Ray Ryan rj...@google.com wrote:
This conversation keeps getting complicated by discussions of policy.
I'm
just trying to make it possible for widgets we haven't thought of yet to
define policies of their own.
E.g., to temporarily switch between modes that change the set of events
they
source, copying some handlers or not if that's appropriate (perhaps in
mode
B I simply am not a source of the events that would happen in mode A.
Perhaps I am. Let me choose). E.g., to implement an HM stack. E.g., to
try
out a singleton HM (I wouldn't, but why should I stop you from trying it
out).
I think JohnL has hit the sweet spot with:
/**
* Called by default implementation of {...@link #getHM}
* to lazily instantiate the HM for this widget.
*/
protected HM createHM();
/**
* All access to the widget's HM must be made through this method.
* It is an error to cache the object returned. The default
implementation
* returns the result of {...@link #createHM} the first time it is called.
*/
protected HM getHM();
If I override getHM(), I have the option to call the normal createHM()
to
get whatever HM the widget normally uses. Or not. If I override
createHM() I
can provide a custom implementation, or wrap the normal one, without
having
to re-implement the lazy instantiation mechanism.
Am I trying to provide flexibility that no one is asking for?
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
--
I wish this were a Wave
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: Make HandlerManager survive exceptions
The new patch set looks great. Thanks, Pete. http://gwt-code-reviews.appspot.com/136805 -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: Make HandlerManager survive exceptions
One more tweak, though: http://gwt-code-reviews.appspot.com/136805/diff/5001/5002 File user/src/com/google/gwt/event/shared/HandlerManager.java (right): http://gwt-code-reviews.appspot.com/136805/diff/5001/5002#newcode71 Line 71: causes.add(e); Seems like this and the identical call below should be refactored into a single method http://gwt-code-reviews.appspot.com/136805 -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] Re: Add the ability to change the default HandlerManager of a Widget
Your point being that I could just implement a custom handler manager that
can do any of these things, and so should keep Widgets that much simpler,
yes? I don't have a good answer to that.
On Thu, Feb 11, 2010 at 10:54 AM, Isaac Truett itru...@gmail.com wrote:
I don't get why it would be necessary. What would you be able to do by
putting an HM on ice that you can't do with the existing API? Why
complicate things? Where's the use case that requires this new API?
Is this just a philosophical argument over narrowly defined, tightly
controlled APIs vs. more abundant, unrestricted APIs?
On Thu, Feb 11, 2010 at 1:34 PM, Ray Ryan rj...@google.com wrote:
I don't get that. If I (widget) have nothing to say to you for a while
(am
not going to be generating the kinds of events that you are registered
for),
why do you care if my mechanism for achieving that involves putting my
usual
HM on ice? So long as I don't cause an error if you de-register in the
meantime, what's the problem?
On Thu, Feb 11, 2010 at 10:23 AM, Isaac Truett itru...@gmail.com
wrote:
Am I trying to provide flexibility that no one is asking for?
In my opinion, this is providing flexibility that is not necessary and
is not a net positive change to the API. I'm not convinced that it's
the right thing to do. However if you were to provide that
flexibility, I would agree that get/createHM() is probably a better
way to go about it than setHM(). But I think that introducing
volatility to the HandlerManager exposes a flaw in the relationship
between Widgets, HandlerManagers, and Handlers.
On Thu, Feb 11, 2010 at 1:05 PM, Ray Ryan rj...@google.com wrote:
This conversation keeps getting complicated by discussions of policy.
I'm
just trying to make it possible for widgets we haven't thought of yet
to
define policies of their own.
E.g., to temporarily switch between modes that change the set of
events
they
source, copying some handlers or not if that's appropriate (perhaps in
mode
B I simply am not a source of the events that would happen in mode A.
Perhaps I am. Let me choose). E.g., to implement an HM stack. E.g., to
try
out a singleton HM (I wouldn't, but why should I stop you from trying
it
out).
I think JohnL has hit the sweet spot with:
/**
* Called by default implementation of {...@link #getHM}
* to lazily instantiate the HM for this widget.
*/
protected HM createHM();
/**
* All access to the widget's HM must be made through this method.
* It is an error to cache the object returned. The default
implementation
* returns the result of {...@link #createHM} the first time it is
called.
*/
protected HM getHM();
If I override getHM(), I have the option to call the normal createHM()
to
get whatever HM the widget normally uses. Or not. If I override
createHM() I
can provide a custom implementation, or wrap the normal one, without
having
to re-implement the lazy instantiation mechanism.
Am I trying to provide flexibility that no one is asking for?
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
--
I wish this were a Wave
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
--
I wish this were a Wave
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: Make HandlerManager survive exceptions
Oh, course, nevermind, LGTM On Thu, Feb 11, 2010 at 12:01 PM, Pete Hopkins phopk...@google.com wrote: On Thu, Feb 11, 2010 at 2:58 PM, rj...@google.com wrote: One more tweak, though: http://gwt-code-reviews.appspot.com/136805/diff/5001/5002 File user/src/com/google/gwt/event/shared/HandlerManager.java (right): http://gwt-code-reviews.appspot.com/136805/diff/5001/5002#newcode71 Line 71: causes.add(e); Seems like this and the identical call below should be refactored into a single method That's tricky to do because the causes variable needs to get initialized from the common code. I don't think causes can be made a member variable because that method needs to be reentrant. The alternative would be passing in causes and then returning it from the helper method (so that the helper could initialize it), or doing away with the optimization of only creating causes when it's needed. -- Pete -- I wish this were a Wave -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] Re: Add the ability to change the default HandlerManager of a Widget
I was actually thinking it would involve overriding onBrowserEvent().
Maybe I need to have another look at how HandlerManager fits into
things. I thought of it more as a dispatcher directing traffic than
the actual source of event firing. But yes, essentially, it looks like
all of the tools are there already to turn off one type of event and
turn on another. The handlers for the off event don't fire because
their event simply doesn't happen. Then you don't have to worry about
which HM is active when a handler is added, making sure they get
removed properly, etc. Simpler, as you said.
On Thu, Feb 11, 2010 at 3:30 PM, Ray Ryan rj...@google.com wrote:
Your point being that I could just implement a custom handler manager that
can do any of these things, and so should keep Widgets that much simpler,
yes? I don't have a good answer to that.
On Thu, Feb 11, 2010 at 10:54 AM, Isaac Truett itru...@gmail.com wrote:
I don't get why it would be necessary. What would you be able to do by
putting an HM on ice that you can't do with the existing API? Why
complicate things? Where's the use case that requires this new API?
Is this just a philosophical argument over narrowly defined, tightly
controlled APIs vs. more abundant, unrestricted APIs?
On Thu, Feb 11, 2010 at 1:34 PM, Ray Ryan rj...@google.com wrote:
I don't get that. If I (widget) have nothing to say to you for a while
(am
not going to be generating the kinds of events that you are registered
for),
why do you care if my mechanism for achieving that involves putting my
usual
HM on ice? So long as I don't cause an error if you de-register in the
meantime, what's the problem?
On Thu, Feb 11, 2010 at 10:23 AM, Isaac Truett itru...@gmail.com
wrote:
Am I trying to provide flexibility that no one is asking for?
In my opinion, this is providing flexibility that is not necessary and
is not a net positive change to the API. I'm not convinced that it's
the right thing to do. However if you were to provide that
flexibility, I would agree that get/createHM() is probably a better
way to go about it than setHM(). But I think that introducing
volatility to the HandlerManager exposes a flaw in the relationship
between Widgets, HandlerManagers, and Handlers.
On Thu, Feb 11, 2010 at 1:05 PM, Ray Ryan rj...@google.com wrote:
This conversation keeps getting complicated by discussions of policy.
I'm
just trying to make it possible for widgets we haven't thought of yet
to
define policies of their own.
E.g., to temporarily switch between modes that change the set of
events
they
source, copying some handlers or not if that's appropriate (perhaps
in
mode
B I simply am not a source of the events that would happen in mode A.
Perhaps I am. Let me choose). E.g., to implement an HM stack. E.g.,
to
try
out a singleton HM (I wouldn't, but why should I stop you from trying
it
out).
I think JohnL has hit the sweet spot with:
/**
* Called by default implementation of {...@link #getHM}
* to lazily instantiate the HM for this widget.
*/
protected HM createHM();
/**
* All access to the widget's HM must be made through this method.
* It is an error to cache the object returned. The default
implementation
* returns the result of {...@link #createHM} the first time it is
called.
*/
protected HM getHM();
If I override getHM(), I have the option to call the normal
createHM()
to
get whatever HM the widget normally uses. Or not. If I override
createHM() I
can provide a custom implementation, or wrap the normal one, without
having
to re-implement the lazy instantiation mechanism.
Am I trying to provide flexibility that no one is asking for?
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
--
I wish this were a Wave
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
--
I wish this were a Wave
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] Re: Add the ability to change the default HandlerManager of a Widget
If you need to swap out two different complex event handling modes of
a widget (where say, a half dozen different events are being
monitored), I think it is too complex to remove all the old handlers
and add new ones every time, I also think overriding onBrowserEvent is
kind of tedious and limited, since every time you need to change the
set being nullified or altered, you need to edit the method.
Consider a paint program with a paint widget, where, depending on
which tool is selected (clone, crop, airbrush, etc) a different set of
event handlers will be active. On some, you may care about drag, or
keyboard, or mouse wheel, or others, you don't.
You could of course write an object that absorbs all the events and
re-routes/broadcasts them as needed, but then all you've done is
simply re-invent HandlerManager and called it 'EventRouter' or some
subject.
Ray * Ray = Ray ^2
:)
On Thu, Feb 11, 2010 at 12:43 PM, Isaac Truett itru...@gmail.com wrote:
I was actually thinking it would involve overriding onBrowserEvent().
Maybe I need to have another look at how HandlerManager fits into
things. I thought of it more as a dispatcher directing traffic than
the actual source of event firing. But yes, essentially, it looks like
all of the tools are there already to turn off one type of event and
turn on another. The handlers for the off event don't fire because
their event simply doesn't happen. Then you don't have to worry about
which HM is active when a handler is added, making sure they get
removed properly, etc. Simpler, as you said.
On Thu, Feb 11, 2010 at 3:30 PM, Ray Ryan rj...@google.com wrote:
Your point being that I could just implement a custom handler manager that
can do any of these things, and so should keep Widgets that much simpler,
yes? I don't have a good answer to that.
On Thu, Feb 11, 2010 at 10:54 AM, Isaac Truett itru...@gmail.com wrote:
I don't get why it would be necessary. What would you be able to do by
putting an HM on ice that you can't do with the existing API? Why
complicate things? Where's the use case that requires this new API?
Is this just a philosophical argument over narrowly defined, tightly
controlled APIs vs. more abundant, unrestricted APIs?
On Thu, Feb 11, 2010 at 1:34 PM, Ray Ryan rj...@google.com wrote:
I don't get that. If I (widget) have nothing to say to you for a while
(am
not going to be generating the kinds of events that you are registered
for),
why do you care if my mechanism for achieving that involves putting my
usual
HM on ice? So long as I don't cause an error if you de-register in the
meantime, what's the problem?
On Thu, Feb 11, 2010 at 10:23 AM, Isaac Truett itru...@gmail.com
wrote:
Am I trying to provide flexibility that no one is asking for?
In my opinion, this is providing flexibility that is not necessary and
is not a net positive change to the API. I'm not convinced that it's
the right thing to do. However if you were to provide that
flexibility, I would agree that get/createHM() is probably a better
way to go about it than setHM(). But I think that introducing
volatility to the HandlerManager exposes a flaw in the relationship
between Widgets, HandlerManagers, and Handlers.
On Thu, Feb 11, 2010 at 1:05 PM, Ray Ryan rj...@google.com wrote:
This conversation keeps getting complicated by discussions of policy.
I'm
just trying to make it possible for widgets we haven't thought of yet
to
define policies of their own.
E.g., to temporarily switch between modes that change the set of
events
they
source, copying some handlers or not if that's appropriate (perhaps
in
mode
B I simply am not a source of the events that would happen in mode A.
Perhaps I am. Let me choose). E.g., to implement an HM stack. E.g.,
to
try
out a singleton HM (I wouldn't, but why should I stop you from trying
it
out).
I think JohnL has hit the sweet spot with:
/**
* Called by default implementation of {...@link #getHM}
* to lazily instantiate the HM for this widget.
*/
protected HM createHM();
/**
* All access to the widget's HM must be made through this method.
* It is an error to cache the object returned. The default
implementation
* returns the result of {...@link #createHM} the first time it is
called.
*/
protected HM getHM();
If I override getHM(), I have the option to call the normal
createHM()
to
get whatever HM the widget normally uses. Or not. If I override
createHM() I
can provide a custom implementation, or wrap the normal one, without
having
to re-implement the lazy instantiation mechanism.
Am I trying to provide flexibility that no one is asking for?
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
--
I wish this were a Wave
--
Re: [gwt-contrib] Re: Add the ability to change the default HandlerManager of a Widget
But I could still override createHM to be a wrapper that is backed by two separate instances, for example. I'm running out of rationalizations for providing both methods. And if getHM is missed it could be added later. 180 degrees, rjrjr On Feb 11, 2010 1:00 PM, Ray Cromwell cromwell...@gmail.com wrote: If you need to swap out two different complex event handling modes of a widget (where say, a half dozen different events are being monitored), I think it is too complex to remove all the old handlers and add new ones every time, I also think overriding onBrowserEvent is kind of tedious and limited, since every time you need to change the set being nullified or altered, you need to edit the method. Consider a paint program with a paint widget, where, depending on which tool is selected (clone, crop, airbrush, etc) a different set of event handlers will be active. On some, you may care about drag, or keyboard, or mouse wheel, or others, you don't. You could of course write an object that absorbs all the events and re-routes/broadcasts them as needed, but then all you've done is simply re-invent HandlerManager and called it 'EventRouter' or some subject. Ray * Ray = Ray ^2 :) On Thu, Feb 11, 2010 at 12:43 PM, Isaac Truett itru...@gmail.com wrote: I was actually thinking... -- http://groups.google.com/group/Google-Web-Toolkit-Contributors -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] sharded linking
Reviewers: cromwellian, Description: Allow linkers to be shardable, so as to speed up compiles that use multiple computers. See ongoing discussion here: http://groups.google.com/group/google-web-toolkit-contributors/browse_thread/thread/748d55e44fb79cdf/0df742bb9aafea6b?lnk=raot Please review this at http://gwt-code-reviews.appspot.com/141811 Affected files: dev/core/src/com/google/gwt/core/ext/Linker.java dev/core/src/com/google/gwt/core/ext/linker/Artifact.java dev/core/src/com/google/gwt/core/ext/linker/BinaryEmittedArtifact.java dev/core/src/com/google/gwt/core/ext/linker/CompilationResult.java dev/core/src/com/google/gwt/core/ext/linker/Shardable.java dev/core/src/com/google/gwt/core/ext/linker/Transferable.java dev/core/src/com/google/gwt/core/ext/linker/impl/BinaryOnlyArtifactWrapper.java dev/core/src/com/google/gwt/core/ext/linker/impl/HostedModeLinker.java dev/core/src/com/google/gwt/core/ext/linker/impl/JarEntryEmittedArtifact.java dev/core/src/com/google/gwt/core/ext/linker/impl/SelectionInformation.java dev/core/src/com/google/gwt/core/ext/linker/impl/SelectionScriptLinker.java dev/core/src/com/google/gwt/core/ext/linker/impl/StandardLinkerContext.java dev/core/src/com/google/gwt/core/linker/IFrameLinker.java dev/core/src/com/google/gwt/core/linker/SingleScriptLinker.java dev/core/src/com/google/gwt/core/linker/SoycReportLinker.java dev/core/src/com/google/gwt/core/linker/SymbolMapsLinker.java dev/core/src/com/google/gwt/core/linker/XSLinker.java dev/core/src/com/google/gwt/dev/CompilePerms.java dev/core/src/com/google/gwt/dev/CompilePermsServer.java dev/core/src/com/google/gwt/dev/Compiler.java dev/core/src/com/google/gwt/dev/DevMode.java dev/core/src/com/google/gwt/dev/DevModeBase.java dev/core/src/com/google/gwt/dev/GWTCompiler.java dev/core/src/com/google/gwt/dev/Link.java dev/core/src/com/google/gwt/dev/PermutationWorker.java dev/core/src/com/google/gwt/dev/Precompile.java dev/core/src/com/google/gwt/dev/ThreadedPermutationWorkerFactory.java dev/core/src/com/google/gwt/dev/jjs/JavaToJavaScriptCompiler.java dev/core/src/com/google/gwt/dev/jjs/JavaToJavaScriptCompiler.java.orig dev/core/src/com/google/gwt/dev/shell/GWTShellServlet.java dev/core/src/com/google/gwt/dev/util/NullOutputFileSet.java dev/core/src/com/google/gwt/dev/util/OutputFileSet.java dev/core/src/com/google/gwt/dev/util/OutputFileSetOnDirectory.java dev/core/src/com/google/gwt/dev/util/OutputFileSetOnJar.java dev/core/src/com/google/gwt/dev/util/Util.java dev/core/src/com/google/gwt/dev/util/arg/ArgHandlerDisableGeneratingOnShards.java dev/core/src/com/google/gwt/dev/util/arg/ArgHandlerShardPrecompile.java dev/core/test/com/google/gwt/dev/cfg/ModuleDefTest.java user/src/com/google/gwt/rpc/linker/ClientOracleLinker.java user/src/com/google/gwt/rpc/rebind/RpcProxyCreator.java user/src/com/google/gwt/user/RemoteService.gwt.xml user/src/com/google/gwt/user/linker/rpc/RpcLogArtifact.java user/src/com/google/gwt/user/linker/rpc/RpcLogLinker.java user/src/com/google/gwt/user/linker/rpc/RpcPolicyFileArtifact.java user/src/com/google/gwt/user/linker/rpc/RpcPolicyManifestLinker.java user/src/com/google/gwt/user/rebind/rpc/ProxyCreator.java user/src/com/google/gwt/user/rebind/rpc/SerializableTypeOracleBuilder.java user/test/com/google/gwt/core/ext/FinalLinkNotificationsTest.gwt.xml user/test/com/google/gwt/core/ext/LinkerSuite.java user/test/com/google/gwt/core/ext/LinkerTest.gwt.xml -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] Re: Add the ability to change the default HandlerManager of a Widget
Does anyone object to adding createHandlerManager now, and then adding getHandlerManager if it is needed later? Thanks, John LaBanca jlaba...@google.com On Thu, Feb 11, 2010 at 4:09 PM, Ray Ryan rj...@google.com wrote: But I could still override createHM to be a wrapper that is backed by two separate instances, for example. I'm running out of rationalizations for providing both methods. And if getHM is missed it could be added later. 180 degrees, rjrjr On Feb 11, 2010 1:00 PM, Ray Cromwell cromwell...@gmail.com wrote: If you need to swap out two different complex event handling modes of a widget (where say, a half dozen different events are being monitored), I think it is too complex to remove all the old handlers and add new ones every time, I also think overriding onBrowserEvent is kind of tedious and limited, since every time you need to change the set being nullified or altered, you need to edit the method. Consider a paint program with a paint widget, where, depending on which tool is selected (clone, crop, airbrush, etc) a different set of event handlers will be active. On some, you may care about drag, or keyboard, or mouse wheel, or others, you don't. You could of course write an object that absorbs all the events and re-routes/broadcasts them as needed, but then all you've done is simply re-invent HandlerManager and called it 'EventRouter' or some subject. Ray * Ray = Ray ^2 :) On Thu, Feb 11, 2010 at 12:43 PM, Isaac Truett itru...@gmail.com wrote: I was actually thinking... -- 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] Re: RFC: sharded linking
On Wed, Feb 10, 2010 at 10:58 AM, John Tamplin j...@google.com wrote: On Wed, Feb 10, 2010 at 10:45 AM, Lex Spoon sp...@google.com wrote: Is copying source code so inconvenient that it would be worth having a slower build? I would have thought any of the following would work to move source code from one machine to another: 1. rsync 2. jar + scp 3. svn up on the slave machines Do any of those seem practical for your situation, Alex? Overall, it's easy to provide an extra build staging as an option, but we support a number of build stagings already What does make it difficult is that you can't have a pool of worker machines that can build any project that are asked of them without copying the sources to the worker for each request. For a large project, this can get problematic especially when you have to send the transitive dependencies. You assume the answer here, John. The question is, just why is copying source code problematic to begin with? Can anyone put their finger on it? One concern is that the copying might take too long. However, is there any project where it would take more than a few seconds? A few seconds seems like not a big deal for any build large enough to bother with parallel building. Another possible concern is the need to do some extra build configuration. It doesn't take much *build time* to copy the dependencies, but it takes *developer time* to set it up. Here I agree that it is some amount of extra work. However, it doesn't seem like much. You have to know what your dependencies are, and you have already worked out how to copy precompilation.ser, so how much more work is it to also send over the source code? Overall, I see that it worries people to send source code to the CompilePerms nodes. Yet, it seems entirely normal to me. When you do a distributed build, all the remote workers must have their inputs copied over to them over the network. Besides, what is gained by having the user have to arrange this copying themselves rather than the current method of sending it as part of the compile process? For example, distributed C/C++ compilers send the preprocessed source to the worker nodes, so they don't have to have the source or the same include files, we currently send the AST which is a representation of the source, etc. Compared to the status quo, we gain much faster builds. Compared to automatically copying, we have a fully specced out proposal. :) If we try to automatically copy dependencies, how would we we know exactly what to copy? Lex -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] PopupPanel.setVisible does not affect glass
Reviewers: jgw,
Description:
PopupPanel.setVisible is supposed to update the visibility of the glass
element, but it is using PopupImpl variation of setVisible (a no-op in
all but IE) instead of UIObjects.
Fix:
We now use the standard UIObject.setVisible to set the visibility of the
glass element.
Testing:
===
I tested this manually on Chrome, FF, and IE. Added a unit test and
verified it passed on FF, Chrome, IE, Safari, Opera.
Please review this at http://gwt-code-reviews.appspot.com/143809
Affected files:
user/src/com/google/gwt/user/client/ui/PopupPanel.java
user/test/com/google/gwt/user/client/ui/PopupTest.java
Index: user/test/com/google/gwt/user/client/ui/PopupTest.java
===
--- user/test/com/google/gwt/user/client/ui/PopupTest.java (revision 7555)
+++ user/test/com/google/gwt/user/client/ui/PopupTest.java (working copy)
@@ -377,6 +377,25 @@
popup.hide();
}
+ public void testSetVisibleWithGlass() {
+PopupPanel popup = createPopupPanel();
+popup.setGlassEnabled(true);
+popup.show();
+
+assertTrue(popup.isVisible());
+assertTrue(UIObject.isVisible(popup.getGlassElement()));
+
+popup.setVisible(false);
+assertFalse(popup.isVisible());
+assertFalse(UIObject.isVisible(popup.getGlassElement()));
+
+popup.setVisible(true);
+assertTrue(popup.isVisible());
+assertTrue(UIObject.isVisible(popup.getGlassElement()));
+
+popup.hide();
+ }
+
/**
* Test the showing a popup while it is hiding will not result in an
illegal
* state.
Index: user/src/com/google/gwt/user/client/ui/PopupPanel.java
===
--- user/src/com/google/gwt/user/client/ui/PopupPanel.java (revision 7555)
+++ user/src/com/google/gwt/user/client/ui/PopupPanel.java (working copy)
@@ -924,7 +924,7 @@
// as well.
impl.setVisible(getElement(), visible);
if (glass != null) {
- impl.setVisible(glass, visible);
+ UIObject.setVisible(glass, visible);
}
}
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] Re: RFC: sharded linking
On Thu, Feb 11, 2010 at 5:33 PM, Lex Spoon sp...@google.com wrote: Besides, what is gained by having the user have to arrange this copying themselves rather than the current method of sending it as part of the compile process? For example, distributed C/C++ compilers send the preprocessed source to the worker nodes, so they don't have to have the source or the same include files, we currently send the AST which is a representation of the source, etc. Compared to the status quo, we gain much faster builds. Compared to automatically copying, we have a fully specced out proposal. :) If we try to automatically copy dependencies, how would we we know exactly what to copy? That is exactly my point -- the C++ example sends the preprocessed source to the worker nodes, so they don't have to have the dependencies or the right include path or whatever. The analogy here would be for GWT to send all of the collected source, either in its native form or as is currently done in a parsed AST form, to the worker nodes. -- John A. Tamplin Software Engineer (GWT), Google -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] Re: RFC: sharded linking
On Wed, Feb 10, 2010 at 11:25 AM, James Northrup northrup.ja...@gmail.comwrote: the usecases being described as a point of deliberation, defining dependancies, repository access, and bundling automation, are well solved items in the maven stable. how hard can it be to define a multiproject descriptor, assign channels of build-stage progression, and have a top-level project build coordinated by one maven instance publish artifacts to sucessive build-channels served elsewhere by daemons which trigger maven sub-builds? That's a nice idea. Has anyone heard of a project using Maven to support distributed builds? The little bit of web searching I did turned up did not look good. People were saying it would be logical to build that way, but that Maven has a fundamental showstopper: the local repositories are not thread safe. Perhaps that has changed by now? Maven aside, there are other options. Hudson and Pulse should work well. Lex -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] Re: Add the ability to change the default HandlerManager of a Widget
I agree, you could do it that way. I'm trying to think of a case where it wouldn't be good enough, I guess in theory, you could have a widget that can't be subclassed/overridden where set/get methods could allow you to override or inject HM dependencies, whereas the create technique isn't as DI friendly. -Ray On Thu, Feb 11, 2010 at 1:09 PM, Ray Ryan rj...@google.com wrote: But I could still override createHM to be a wrapper that is backed by two separate instances, for example. I'm running out of rationalizations for providing both methods. And if getHM is missed it could be added later. 180 degrees, rjrjr On Feb 11, 2010 1:00 PM, Ray Cromwell cromwell...@gmail.com wrote: If you need to swap out two different complex event handling modes of a widget (where say, a half dozen different events are being monitored), I think it is too complex to remove all the old handlers and add new ones every time, I also think overriding onBrowserEvent is kind of tedious and limited, since every time you need to change the set being nullified or altered, you need to edit the method. Consider a paint program with a paint widget, where, depending on which tool is selected (clone, crop, airbrush, etc) a different set of event handlers will be active. On some, you may care about drag, or keyboard, or mouse wheel, or others, you don't. You could of course write an object that absorbs all the events and re-routes/broadcasts them as needed, but then all you've done is simply re-invent HandlerManager and called it 'EventRouter' or some subject. Ray * Ray = Ray ^2 :) On Thu, Feb 11, 2010 at 12:43 PM, Isaac Truett itru...@gmail.com wrote: I was actually thinking... -- 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] RFC: sharded linking
I have a few comments, but first I wanted to raise the point that I'm not sure why we're having this argument about maximally sharded Precompiles at all. For one thing, it's already implemented, and optional, via -XshardPrecompile. I can't think of any reason to muck with this, or why it would have any relevance to sharded linking. Can we just table that part for now, or is there something I'm missing? Okay, so now on to sharded linking itself. Here's what I love: - Love the overall goals: do more work in parallel and eliminate serialization overhead. - Love the idea of simulated sharding because it enforces consistency. - Love that the linkers all run in the same order. Here's what I don't love: - I'm not sure why development mode wouldn't run a sharded link first. Wouldn't it make sense if development mode works just like production compile, it just runs a single development mode permutation shard link before running the final link? - I dislike the whole transition period followed by having to forcibly update all linkers, unless there's a really compelling reason to do so. Maybe I'm missing some use cases, but I don't see what problems result from having some linkers run early and others run late. As Lex noted, all the linkers are largely independent of each other and mostly won't step on each other's toes. - It seems unnecessary to have to annotate Artifacts to say which ones are transferable, because I thought we already mandated that all Artifacts have to be transferable. I have in mind a different proposal that I believe addresses the same goals, but in a less-disruptive fashion. Please feel free to poke holes in it: 1) Linker was made an abstract class specifically so that it could be extended later. I propose simply adding a new method linkSharded() with the same semantics as link(). Linkers that don't override this method would simply do nothing on the shards and possibly lose out on the opportunity to shard work. Linkers that can effectively do some work on shards would override this method to do so. (We might also have a relinkSharded() for development mode.) 2) Instead of trying to do automatic thinning, we just let the linkers themselves do the thinning. For example, one of the most serialization-expensive things we do is serialize/deserialze symbolMaps. To avoid this, we update SymbolMapsLinker to do most of its work during sharding, and update IFrameLinker (et al) to remove the CompilationResult during the sharded link so it never gets sent across to the final link. The pros to this idea are (I think) that you don't break anyone... instead you opt-in to the optimization. If you don't do anything, it should still work, but maybe slower than it could. The cons are... well maybe it's too simplistic and I'm missing some of the corner cases, or ways this could break down. Thoughts? Scott -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] Re: Add the ability to change the default HandlerManager of a Widget
@John - No objection here. @Ray squared - The idea of overriding HandlerManager still intrigues me. I've never found myself wanting to do it and I don't recall seeing it in practice elsewhere. I'm curious. If either of you knows of a project where I could find an example, would you mind passing along a link? On Thu, Feb 11, 2010 at 4:52 PM, John LaBanca jlaba...@google.com wrote: Does anyone object to adding createHandlerManager now, and then adding getHandlerManager if it is needed later? Thanks, John LaBanca jlaba...@google.com On Thu, Feb 11, 2010 at 4:09 PM, Ray Ryan rj...@google.com wrote: But I could still override createHM to be a wrapper that is backed by two separate instances, for example. I'm running out of rationalizations for providing both methods. And if getHM is missed it could be added later. 180 degrees, rjrjr On Feb 11, 2010 1:00 PM, Ray Cromwell cromwell...@gmail.com wrote: If you need to swap out two different complex event handling modes of a widget (where say, a half dozen different events are being monitored), I think it is too complex to remove all the old handlers and add new ones every time, I also think overriding onBrowserEvent is kind of tedious and limited, since every time you need to change the set being nullified or altered, you need to edit the method. Consider a paint program with a paint widget, where, depending on which tool is selected (clone, crop, airbrush, etc) a different set of event handlers will be active. On some, you may care about drag, or keyboard, or mouse wheel, or others, you don't. You could of course write an object that absorbs all the events and re-routes/broadcasts them as needed, but then all you've done is simply re-invent HandlerManager and called it 'EventRouter' or some subject. Ray * Ray = Ray ^2 :) On Thu, Feb 11, 2010 at 12:43 PM, Isaac Truett itru...@gmail.com wrote: I was actually thinking... -- http://groups.google.com/group/Google-Web-Toolkit-Contributors -- http://groups.google.com/group/Google-Web-Toolkit-Contributors -- http://groups.google.com/group/Google-Web-Toolkit-Contributors -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: RFC: sharded linking
On Feb 11, 6:43 pm, Scott Blum sco...@google.com wrote: I have a few comments, but first I wanted to raise the point that I'm not sure why we're having this argument about maximally sharded Precompiles at all. For one thing, it's already implemented, and optional, via -XshardPrecompile. I can't think of any reason to muck with this, or why it would have any relevance to sharded linking. Can we just table that part for now, or is there something I'm missing? Okay, so now on to sharded linking itself. Here's what I love: - Love the overall goals: do more work in parallel and eliminate serialization overhead. - Love the idea of simulated sharding because it enforces consistency. - Love that the linkers all run in the same order. Here's what I don't love: - I'm not sure why development mode wouldn't run a sharded link first. Wouldn't it make sense if development mode works just like production compile, it just runs a single development mode permutation shard link before running the final link? - I dislike the whole transition period followed by having to forcibly update all linkers, unless there's a really compelling reason to do so. Maybe I'm missing some use cases, but I don't see what problems result from having some linkers run early and others run late. As Lex noted, all the linkers are largely independent of each other and mostly won't step on each other's toes. - It seems unnecessary to have to annotate Artifacts to say which ones are transferable, because I thought we already mandated that all Artifacts have to be transferable. I have in mind a different proposal that I believe addresses the same goals, but in a less-disruptive fashion. Please feel free to poke holes in it: 1) Linker was made an abstract class specifically so that it could be extended later. I propose simply adding a new method linkSharded() with the same semantics as link(). Linkers that don't override this method would simply do nothing on the shards and possibly lose out on the opportunity to shard work. Linkers that can effectively do some work on shards would override this method to do so. (We might also have a relinkSharded() for development mode.) 2) Instead of trying to do automatic thinning, we just let the linkers themselves do the thinning. For example, one of the most serialization-expensive things we do is serialize/deserialze symbolMaps. To avoid this, we update SymbolMapsLinker to do most of its work during sharding, and update IFrameLinker (et al) to remove the CompilationResult during the sharded link so it never gets sent across to the final link. The pros to this idea are (I think) that you don't break anyone... instead you opt-in to the optimization. If you don't do anything, it should still work, but maybe slower than it could. The cons are... well maybe it's too simplistic and I'm missing some of the corner cases, or ways this could break down. Thoughts? Scott If this is indeed the direction to go in (and I'm a big fan of the goals as well), it's probably also worth making a more formal definition for won't step on each other's toes. As a use case, I'm working on a PRE linker that (currently) removes CompilationResults, alters them based on information collected from across all permutations, and then emits new ones. Obviously this isn't ideal--its expensive and CompilationResults were written to be (mostly) immutable--but it's also perfectly acceptable within the current design of the artifactSet/linker chain. The primary linker only cares about the set of compilation results it receives, and if an earlier linker altered them, it need never know. It seems (and I could definitely be misinterpreting here) that in both the simulated sharding procedure and Scott's alternate proposal, there will be sections of primary and post linkers running before a non- shardable pre linker. If that's true, then neither will be able to fully honor the ordering of linkers when shardable and non-shardable linkers are mixed. But, then again, when I started on this one I think I could find only one other PRE linker in existence, so now would be the time to change. Continuing to think out loud, it seems that the way to alter my linker is probably either to statically derive what all permutations will need in every shard (as opposed to just having each triggered generator emit an artifact and collecting them at the end), or keeping that the same and creating a custom primary linker, which I was hoping not to do as it would tend to limit adoption. If that's the largest price to pay, though, the trade off would seem worth it. -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: Add the ability to change the default HandlerManager of a Widget
I'd say that if you wanted to implement a HandlerManager stack, it
would probably be best to do that internal to the HandlerManager,
rather than forcing a Widget to know how events are handled.
Assuming that is possible given the current Widget implementations
(others more expert than I would know this, probably), the only API I
would want is createHandlerManager(). I could then manage how that
more complex HandlerManager is dealt with.
While we're on the subject... if you're providing this factory method,
I would rather see a well-documented interface to implement rather
than a semi-documented implementation of which I would probably be
overriding every method.
just my .02
On Feb 11, 11:05 am, Ray Ryan rj...@google.com wrote:
This conversation keeps getting complicated by discussions of policy. I'm
just trying to make it possible for widgets we haven't thought of yet to
define policies of their own.
E.g., to temporarily switch between modes that change the set of events they
source, copying some handlers or not if that's appropriate (perhaps in mode
B I simply am not a source of the events that would happen in mode A.
Perhaps I am. Let me choose). E.g., to implement an HM stack. E.g., to try
out a singleton HM (I wouldn't, but why should I stop you from trying it
out).
I think JohnL has hit the sweet spot with:
/**
* Called by default implementation of {...@link #getHM}
* to lazily instantiate the HM for this widget.
*/
protected HM createHM();
/**
* All access to the widget's HM must be made through this method.
* It is an error to cache the object returned. The default implementation
* returns the result of {...@link #createHM} the first time it is called.
*/
protected HM getHM();
If I override getHM(), I have the option to call the normal createHM() to
get whatever HM the widget normally uses. Or not. If I override createHM() I
can provide a custom implementation, or wrap the normal one, without having
to re-implement the lazy instantiation mechanism.
Am I trying to provide flexibility that no one is asking for?
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] Re: Add the ability to change the default HandlerManager of a Widget
Alright, lets go with createHandlerManager() for now. Thanks for all the
feedback.
@sven -
Would you like to update the patch by reverting the getHandlerManager()
method back to a package protected method? If you don't get to it for a few
days, I'll can do it for you.
Thanks,
John LaBanca
jlaba...@google.com
On Thu, Feb 11, 2010 at 9:39 PM, Nathan Wells nwwe...@gmail.com wrote:
I'd say that if you wanted to implement a HandlerManager stack, it
would probably be best to do that internal to the HandlerManager,
rather than forcing a Widget to know how events are handled.
Assuming that is possible given the current Widget implementations
(others more expert than I would know this, probably), the only API I
would want is createHandlerManager(). I could then manage how that
more complex HandlerManager is dealt with.
While we're on the subject... if you're providing this factory method,
I would rather see a well-documented interface to implement rather
than a semi-documented implementation of which I would probably be
overriding every method.
just my .02
On Feb 11, 11:05 am, Ray Ryan rj...@google.com wrote:
This conversation keeps getting complicated by discussions of policy. I'm
just trying to make it possible for widgets we haven't thought of yet to
define policies of their own.
E.g., to temporarily switch between modes that change the set of events
they
source, copying some handlers or not if that's appropriate (perhaps in
mode
B I simply am not a source of the events that would happen in mode A.
Perhaps I am. Let me choose). E.g., to implement an HM stack. E.g., to
try
out a singleton HM (I wouldn't, but why should I stop you from trying it
out).
I think JohnL has hit the sweet spot with:
/**
* Called by default implementation of {...@link #getHM}
* to lazily instantiate the HM for this widget.
*/
protected HM createHM();
/**
* All access to the widget's HM must be made through this method.
* It is an error to cache the object returned. The default
implementation
* returns the result of {...@link #createHM} the first time it is called.
*/
protected HM getHM();
If I override getHM(), I have the option to call the normal createHM() to
get whatever HM the widget normally uses. Or not. If I override
createHM() I
can provide a custom implementation, or wrap the normal one, without
having
to re-implement the lazy instantiation mechanism.
Am I trying to provide flexibility that no one is asking for?
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] Re: Add the ability to change the default HandlerManager of a Widget
Thinking outload...
What about allowing ctors to take a HM. The other ctors use the default
implementation. If you dont care for a HM then use the ctors without HM in
the parameter list. That way you dont pollute the widget method list with
gets/creates and sets which prolly dont make sense once the thing is built.
On Fri, Feb 12, 2010 at 2:22 PM, John LaBanca jlaba...@google.com wrote:
Alright, lets go with createHandlerManager() for now. Thanks for all the
feedback.
@sven -
Would you like to update the patch by reverting the getHandlerManager()
method back to a package protected method? If you don't get to it for a few
days, I'll can do it for you.
Thanks,
John LaBanca
jlaba...@google.com
On Thu, Feb 11, 2010 at 9:39 PM, Nathan Wells nwwe...@gmail.com wrote:
I'd say that if you wanted to implement a HandlerManager stack, it
would probably be best to do that internal to the HandlerManager,
rather than forcing a Widget to know how events are handled.
Assuming that is possible given the current Widget implementations
(others more expert than I would know this, probably), the only API I
would want is createHandlerManager(). I could then manage how that
more complex HandlerManager is dealt with.
While we're on the subject... if you're providing this factory method,
I would rather see a well-documented interface to implement rather
than a semi-documented implementation of which I would probably be
overriding every method.
just my .02
On Feb 11, 11:05 am, Ray Ryan rj...@google.com wrote:
This conversation keeps getting complicated by discussions of policy.
I'm
just trying to make it possible for widgets we haven't thought of yet to
define policies of their own.
E.g., to temporarily switch between modes that change the set of events
they
source, copying some handlers or not if that's appropriate (perhaps in
mode
B I simply am not a source of the events that would happen in mode A.
Perhaps I am. Let me choose). E.g., to implement an HM stack. E.g., to
try
out a singleton HM (I wouldn't, but why should I stop you from trying it
out).
I think JohnL has hit the sweet spot with:
/**
* Called by default implementation of {...@link #getHM}
* to lazily instantiate the HM for this widget.
*/
protected HM createHM();
/**
* All access to the widget's HM must be made through this method.
* It is an error to cache the object returned. The default
implementation
* returns the result of {...@link #createHM} the first time it is called.
*/
protected HM getHM();
If I override getHM(), I have the option to call the normal createHM()
to
get whatever HM the widget normally uses. Or not. If I override
createHM() I
can provide a custom implementation, or wrap the normal one, without
having
to re-implement the lazy instantiation mechanism.
Am I trying to provide flexibility that no one is asking for?
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
--
mP
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
