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
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
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
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
LGTM
http://gwt-code-reviews.appspot.com/143805
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
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
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
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
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
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
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
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
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
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
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
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.
The new patch set looks great. Thanks, Pete.
http://gwt-code-reviews.appspot.com/136805
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
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
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
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
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
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
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
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
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
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
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
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
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
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
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
@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
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
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
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
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
36 matches
Mail list logo
