I've managed to convince myself that it would be a trivial amount of work to
introduce a GwtEventPreview interface into the events package and that the
change would be a good one. In specific we would have:
public interface GwtEventPreview {
boolean onGwtEventPreview(GwtEvent event);
}
Author: [EMAIL PROTECTED]
Date: Tue Nov 11 07:07:46 2008
New Revision: 4013
Modified:
releases/1.6/dev/core/src/com/google/gwt/dev/GWTCompiler.java
releases/1.6/dev/core/src/com/google/gwt/dev/GWTShell.java
releases/1.6/dev/core/src/com/google/gwt/dev/Link.java
Log:
Fix build by
Author: [EMAIL PROTECTED]
Date: Tue Nov 11 07:11:09 2008
New Revision: 4014
Modified:
releases/1.6/user/build.xml
Log:
Leverage -workDir to allow parallelized testing without clobbering.
Patch by: fabbott
Modified: releases/1.6/user/build.xml
The naming was mimicking the EventPreview interface we have for the
underlying native events. Don't mind changing it, but it seems like
the consistency is nice.
I think the testing should be fairly trivial as we have three use cases.
1. no event preview set on a handler manager.
2. an
That's a great find, Ray.
In terms of ideal product direction, I'd rather consider a flag like that
(at least, one that's documented) as the last resort. Extra options tend to
lead to option-shock, and we don't want people to have to think about things
like that too much.
Instead, I think we
On Tue, Nov 11, 2008 at 10:38 AM, Isaac Truett [EMAIL PROTECTED] wrote:
We've been kicking around the idea of an unsafe but fast compile for
exactly this reason.
I always thought the compile was unsafe already.
Only for things that are truly unaffordable, like null checks on every
object
On Tue, Nov 11, 2008 at 10:50 AM, John LaBanca [EMAIL PROTECTED] wrote:
Do I remember correctly that you have looked at script-loading gymnastics
in the HTML host pages before?
No, I looked into style sheet loading gymnastics while working on the
Showcase so we could load style sheets
Lex is going to take a look at this, it was part of the runAsync changes.
On Tue, Nov 11, 2008 at 1:47 AM, Cameron Braid [EMAIL PROTECTED] wrote:
hosted.html expects the querystring to contain only the module strongName
where as it curently contains strongName + .cache.html
IFrameTemplate.js
None that I can see. Kelly, I think you pushed for this clampdown. Still
want it?
rjrjr
On Tue, Nov 11, 2008 at 9:41 AM, Ray Cromwell [EMAIL PROTECTED] wrote:
I would prefer HandlerManager not be so finalized. I had a real use
case for creating a version of fireEvent that dealt with DOM-like
Can you think of any other relevant use cases?
4. Uncaught exception in onGwtEventPreview().
On Tue, Nov 11, 2008 at 10:25 AM, Emily Crutcher [EMAIL PROTECTED] wrote:
The naming was mimicking the EventPreview interface we have for the
underlying native events. Don't mind changing it, but
I'm curious what things you're referring to here. Generally, I think we're
pretty open to more checks in hosted mode. As an example, hosted mode always
runs with assertions enabled.
More assertions are exactly what I've been hoping for. The one case
that's stuck with me was issue 2365. As I
Author: [EMAIL PROTECTED]
Date: Tue Nov 11 10:43:20 2008
New Revision: 4017
Modified:
branches/1_6_clean_events/user/src/com/google/gwt/event/dom/client/DomEvent.java
Log:
Fix NPE in DomEvent#fireNativeEvent, reviewed by ecc
Modified:
On Tue, Nov 11, 2008 at 11:34 AM, BobV [EMAIL PROTECTED] wrote:
Here's a strawman proposal for handling different types of
EmittedArtifacts in the Linker API and how that would interact with a
WAR output format.
Cool.
First, it's great to have a list of the categories of output. There
seem
The only proposal I have in mind right now is that we stop messing with
stuff and get the branch merged.
rjrjr
On Tue, Nov 11, 2008 at 8:28 AM, Emily Crutcher [EMAIL PROTECTED] wrote:
Do you have a proposal in mind? Everything we tightened down we had good
reason to do so.
On Tue, Nov 11,
On Tue, Nov 11, 2008 at 2:02 PM, Lex Spoon [EMAIL PROTECTED] wrote:
One big question: why a separate packer step? My naive understanding
is that the point of a linker is to decide where the various bits of
compiler output will go on disk. Is there a reason to discontinue
that? It sounds
Author: [EMAIL PROTECTED]
Date: Tue Nov 11 07:53:27 2008
New Revision: 4016
Modified:
trunk/dev/core/src/com/google/gwt/core/linker/IFrameLinker.java
Log:
When creating a script tag to load code for runAsync,
create the tag in the same DOM element that the tag
will be attached to.
I'm not sure if the event preview mechanism would completely solve all
the problems, but it appears to offer essentially an override
capability to fireEvent. If you recall our earlier discussions, the
use case goes something like this:
1) a virtual widget system exists which implements widgets
BTW, I'm also curious as to the performance implications. A subtype of
HandlerManager with override fireEvent() could theoretically be
type-tightened and staticified, even inlined, because the field inside
the calling widgets can typically be declared with a concrete leaf
type (MyHandlerManager
Bob
Something tells me the packer proposal might be very useful. To
package GWT apps for offline Android execution, Android demands that
various artifacts be placed in precise directories on disk before
being packaged into an APK. Maybe Thomas can comment about how this
would impact his
Is there any objection to changing the checkIndex() method in
AbstractList to an assert? I suppose one might want JRE behavior in HM
even if assertions are disabled, but perhaps we could just check
!GWT.isScript() and use if vs assert. I noticed that if you hammer on
ArrayList, a very large
I'm working on a srawman proposal for this; expect a copy later today.
--
Bob Vawter
Google Web Toolkit Team
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---
On Tue, Nov 11, 2008 at 2:30 PM, Ray Cromwell [EMAIL PROTECTED] wrote:
I'm not sure if the event preview mechanism would completely solve all
the problems, but it appears to offer essentially an override
capability to fireEvent. If you recall our earlier discussions, the
use case goes
If you did not have an event preview defined, then it is only a null check,
which are cheap.
If you did have one defined you would have had to have two implementations
of fireEvent and your inherited version had better call our fireEvent
somewhere or else your add/remove handler code will break
Our JRE isn't run in hosted mode, so that shouldn't be an issue.
Let's use the pattern of calling checkIndex within an assert, and having
checkIndex always return true if it doesn't throw.
On Tue, Nov 11, 2008 at 2:47 PM, Ray Cromwell [EMAIL PROTECTED] wrote:
Is there any objection to changing
Maybe John can comment on issue #2365 in particular.
On Tue, Nov 11, 2008 at 10:51 AM, Isaac Truett [EMAIL PROTECTED] wrote:
I'm curious what things you're referring to here. Generally, I think
we're
pretty open to more checks in hosted mode. As an example, hosted mode
always
runs with
How about we start a convention for -Xunsafe:yyy flags, like
-Xunsafe:disableArrayIndexChecks
-Xunsafe:disableClassCastChecks
-Xunsafe:disableDefensiveCollections
then we'd want a roll-up flag like
-Xunsafe:all
Of course, we'd want to not document these.
@Ray: The compiler guys are slammed
We've been kicking around the idea of an unsafe but fast compile for
exactly this reason.
OTOH, there are a couple of things we could do to make the type checks
faster even in the short term:
1) Do actual null tracking so as to omit the null check part in many cases.
2) Get away from using
What is clear is that this is a use case that needs to be addressed before
1.6 ships. However, I think it will actually be a lot easier to talk about
after the initial patch lands in 1.6/trunk and is therefore more visible to
all our users.
Cheers,
Emily
On Tue, Nov
Reviewers: zundel, dglibicki,
Description:
Fix bug with date in DataTable
private native void setValueDate(int rowIndex, int columnIndex, int
value) /*-{
-this.setValue(rowIndex, columnIndex, new Date(value));
+this.setValue(rowIndex, columnIndex, new $wnd.Date(value));
}-*/;
Author: [EMAIL PROTECTED]
Date: Tue Nov 11 12:41:10 2008
New Revision: 4018
Added:
branches/1_6_clean_events/user/src/com/google/gwt/event/dom/client/KeyCodes.java
(contents, props changed)
- copied, changed from r4000,
Actually, we also should get some good feedback from the first gwt 1.6
milestone. That will also help us calibrate how important this feature is
to folks, and we can always introduce something like it after the milestone
if it seems to be very much missed.
On Tue, Nov 11, 2008 at 11:36 AM, Ray
On Tue, Nov 11, 2008 at 3:02 PM, Bruce Johnson [EMAIL PROTECTED] wrote:
How about we start a convention for -Xunsafe:yyy flags, like
-Xunsafe:disableArrayIndexChecks
-Xunsafe:disableClassCastChecks
-Xunsafe:disableDefensiveCollections
then we'd want a roll-up flag like
-Xunsafe:all
Ray,
This commit tries to get us out of figuring out how we want to use
enums by giving us api breathing room to introduce them (or not) later.
In specific, we now use getNativeKeyCode and getNativeButton, remove any
mention of integers from KeyCodeEvent and MouseEvent, plus remove the
Author: [EMAIL PROTECTED]
Date: Tue Nov 11 12:58:45 2008
New Revision: 4019
Modified:
branches/1_6_clean_events/user/src/com/google/gwt/user/client/ui/Widget.java
Log:
Making ensureHandlers package protected as it is not part of the public API.
Modified:
I would prefer HandlerManager not be so finalized. I had a real use
case for creating a version of fireEvent that dealt with DOM-like
event bubbling for non-DOM events, the effect of freezing
HandlerManager overrides would deny me the ability of creating a
EventBubblingHandlerManager. Is there a
It's fine with me if the trivial amount of time it will take to add includes
time for test coverage.
On naming, how about GwtEventPreviewer and setEventPreviewer.
rjrjr
On Tue, Nov 11, 2008 at 6:37 AM, Emily Crutcher [EMAIL PROTECTED] wrote:
I've managed to convince myself that it would be a
Author: [EMAIL PROTECTED]
Date: Tue Nov 11 13:16:04 2008
New Revision: 4020
Added:
branches/1_6_clean_events/user/src/com/google/gwt/user/client/ListenerWrapper.java
(contents, props changed)
- copied, changed from r4018,
Author: [EMAIL PROTECTED]
Date: Tue Nov 11 07:29:02 2008
New Revision: 4015
Modified:
trunk/dev/core/src/com/google/gwt/dev/GWTCompiler.java
trunk/dev/core/src/com/google/gwt/dev/jjs/impl/CodeSplitter.java
trunk/dev/core/src/com/google/gwt/dev/jjs/impl/ControlFlowAnalyzer.java
[google-web-toolkit] ray.ryan commented on revision r4018.
Details are at
http://code.google.com/p/google-web-toolkit/source/detail?r=4018
Score: Positive
General Comment:
LGTM
Just one tiny nit, do with it what you will.
Line-by-line comments:
File:
Comment by cristescu.sorinel:
Is it going to be faster that the old one or not? that's the big
question ... 'cause I waste lots of time with starting/debugging in hosted
mode ... brrr ...
Thanks,
Sorinel Cristescu
For more information:
[google-web-toolkit] [EMAIL PROTECTED] commented on branch
/branches/1_6_clean_events.
Details are at
http://code.google.com/p/google-web-toolkit/source/branch?spec=issue3083branch=%2Fbranches%2F1_6_clean_events
General Comment:
BeforeSelectionEvent (but it has questions relevant to all
[google-web-toolkit] [EMAIL PROTECTED] commented on branch
/branches/1_6_clean_events.
Details are at
http://code.google.com/p/google-web-toolkit/source/branch?spec=issue3083branch=%2Fbranches%2F1_6_clean_events
General Comment:
Another comment on GwtEvent.
[google-web-toolkit] EmilyCrutcher commented on revision r4018.
Details are at
http://code.google.com/p/google-web-toolkit/source/detail?r=4018
General Comment:
Our import formatter automatically does that as the gwt style guidelines
say no x.* imports. Now, for static imports we may wish to
Is this really part of the handler update? If this can wait, let's wait. We
need to wrap up the changes to handlers ASAP.
On Tue, Nov 11, 2008 at 9:37 AM, Emily Crutcher [EMAIL PROTECTED] wrote:
I've managed to convince myself that it would be a trivial amount of work
to introduce a
Author: [EMAIL PROTECTED]
Date: Tue Nov 11 14:06:28 2008
New Revision: 4021
Modified:
branches/1_6_clean_events/reference/code-museum/src/com/google/gwt/museum/client/defaultmuseum/VisualsForDisclosurePanelEvents.java
LGTM
Thanks,
John LaBanca
[EMAIL PROTECTED]
On Mon, Nov 10, 2008 at 9:31 PM, Isaac Truett [EMAIL PROTECTED] wrote:
John,
I wanted to run this one-liner by you before committing. I'm seeing
the JSE below in hosted mode when the body of my PagingScrollTable is
empty and has 0 height. The
1. Its more API clutter
Yep, the question is it useful api clutter.
2. Can't users just add listeners directly to their widgets that they put
into the tabs?
Not necessarily, the tabs maybe added via some sort of injection dependency.
For instance, extra functionality, including tabs, are often
We've been kicking around the idea of an unsafe but fast compile for
exactly this reason.
I always thought the compile was unsafe already. Hasn't the GWT
philosophy been to perform type safety/bounds/null checks only in
hosted mode, if at all? Are there many such checks currently left in
Seems to be a good idea! I guess it is hard to find an approach that
will cover all the contract checking code snippets in the gwt
widgets.
Do you have an idea in mind how to handle this? Annotations?
On 11 Nov., 08:14, Ray Cromwell [EMAIL PROTECTED] wrote:
Heads up guys,
I just profiled my
And as Emily and I just chatted offline, if we're loosening things up I'd
rather see us allow folks to provide their own HandlerManager implementation
(or wrapper around ours) than just try to predict the one or two hooks
they'll find useful.
rjrjr
On Tue, Nov 11, 2008 at 7:59 AM, Emily Crutcher
Yes lgtm to cameron's change, sorry I ignored email for a while.
On Nov 10, 2008 6:08 PM, Lex Spoon [EMAIL PROTECTED] wrote:
On Mon, Nov 10, 2008 at 2:33 PM, Kelly Norton [EMAIL PROTECTED] wrote:
For iframe loading, Came...
Can I consider that an LGTM?
However, I am wondering how this is
BTW: does this feature send an email directly to the committer who committed
the revision?
On Tue, Nov 11, 2008 at 10:38 PM, [EMAIL PROTECTED] wrote:
[google-web-toolkit] [EMAIL PROTECTED] commented on revision r4004.
Details are at
[google-web-toolkit] [EMAIL PROTECTED] commented on branch
/branches/1_6_clean_events.
Details are at
http://code.google.com/p/google-web-toolkit/source/branch?spec=issue3083branch=%2Fbranches%2F1_6_clean_events
General Comment:
HandlerManager:
[google-web-toolkit] [EMAIL PROTECTED] commented on branch
/branches/1_6_clean_events.
Details are at
http://code.google.com/p/google-web-toolkit/source/branch?spec=issue3083branch=%2Fbranches%2F1_6_clean_events
General Comment:
JsHandlerRegistry:
[google-web-toolkit] [EMAIL PROTECTED] commented on branch
/branches/1_6_clean_events.
Details are at
http://code.google.com/p/google-web-toolkit/source/branch?spec=issue3083branch=%2Fbranches%2F1_6_clean_events
General Comment:
CloseEvent:
55 matches
Mail list logo
