Author: fabb...@google.com
Date: Thu Dec 11 22:59:31 2008
New Revision: 4330
Modified:
trunk/user/test/com/google/gwt/user/client/ui/CheckBoxTest.java
Log:
Removing a build-breaking test that was merged in my cherrypick at
r4314 or 1.6's c4298... the test isn't valid without code that wasn't
This broke incubator for non-committers, as it was tied to
https://google-web-toolkit.googlecode.com/svn/trunk/build-tools (https, not
http). Should be fixed by r1306.
Mmmm, copy/paste errors,rjrjr
On Fri, Dec 12, 2008 at 10:24 AM, Emily Crutcher wrote:
> Amit, could you review this change?
>
>
Author: sco...@google.com
Date: Thu Dec 11 21:02:41 2008
New Revision: 4325
Modified:
releases/1.6/user/src/com/google/gwt/junit/JUnitShell.java
Log:
Removing unnecessary code.
Modified: releases/1.6/user/src/com/google/gwt/junit/JUnitShell.java
=
Author: sco...@google.com
Date: Thu Dec 11 18:59:42 2008
New Revision: 4315
Modified:
releases/1.6/dev/core/src/com/google/gwt/core/ext/linker/impl/SelectionScriptLinker.java
Log:
Better error message when a module needs to be recompiled.
was: This module needs to be (re)compiled, plea
Author: fabb...@google.com
Date: Thu Dec 11 20:27:06 2008
New Revision: 4322
Modified:
releases/1.6/branch-info.txt
Log:
Bookkeeping of 3 cherrypick merges and one reverse merge. If need be, I
volunteer to sort out the next one since there's now at least 4
fragments...
Modified: releases
Author: sco...@google.com
Date: Thu Dec 11 21:02:21 2008
New Revision: 4324
Modified:
releases/1.6/eclipse/reference/code-museum/DefaultMuseum.launch (props
changed)
releases/1.6/eclipse/samples/DynaTable2/DynaTable2Legacy
compile.launch (contents, props changed)
releases/1.6/
Author: sco...@google.com
Date: Thu Dec 11 19:04:45 2008
New Revision: 4318
Modified:
releases/1.6/dev/core/src/com/google/gwt/dev/GWTShell.java
releases/1.6/dev/core/src/com/google/gwt/dev/HostedMode.java
releases/1.6/dev/core/src/com/google/gwt/dev/HostedModeBase.java
Log:
Sort & f
Author: fabb...@google.com
Date: Thu Dec 11 20:20:13 2008
New Revision: 4321
Modified:
releases/1.6/user/src/com/google/gwt/user/client/ui/ListenerWrapper.java
Log:
Reverse-merging a fix for tree open events from ListenerWrapper
Modified:
releases/1.6/user/src/com/google/gwt/user/client/
Author: sco...@google.com
Date: Thu Dec 11 21:03:53 2008
New Revision: 4326
Modified:
releases/1.6/dev/core/src/com/google/gwt/dev/HostedModeBase.java
releases/1.6/dev/core/src/com/google/gwt/dev/util/arg/ArgHandlerLogLevel.java
Log:
Fixes default log level for JUnit.
Modified: releas
Author: sco...@google.com
Date: Thu Dec 11 21:01:47 2008
New Revision: 4323
Modified:
releases/1.6/eclipse/reference/code-museum/DefaultMuseum.launch
releases/1.6/eclipse/samples/DynaTable2/DynaTable2 compile.launch
releases/1.6/eclipse/samples/DynaTable2/DynaTable2 hosted.launch
Author: sco...@google.com
Date: Thu Dec 11 19:14:09 2008
New Revision: 4319
Modified:
releases/1.6/dev/core/src/com/google/gwt/dev/HostedMode.java
Log:
Lock down HostedMode's public API for now.
Modified: releases/1.6/dev/core/src/com/google/gwt/dev/HostedMode.java
=
Comment by sco...@google.com:
Yeah, that's the downside, the heavy implementation-dependency on GWT. It
would have to be rewritten to !GWT. Amit would be the only person who
could realistically estimate how much effort that would be... I'm guessing
probably a week?
For more information:
Author: sco...@google.com
Date: Thu Dec 11 18:59:59 2008
New Revision: 4316
Modified:
releases/1.6/dev/core/src/com/google/gwt/dev/cfg/ModuleDef.java
Log:
Fixed a bug computing module creation time. Min vs. Max, doh.
Review by: bobv
Modified: releases/1.6/dev/core/src/com/google/gwt/dev/
Author: sco...@google.com
Date: Thu Dec 11 19:02:11 2008
New Revision: 4317
Modified:
releases/1.6/dev/core/src/com/google/gwt/dev/GWTShell.java
releases/1.6/dev/core/src/com/google/gwt/dev/HostedMode.java
releases/1.6/dev/core/src/com/google/gwt/dev/HostedModeBase.java
Log:
Makes ho
Author: fabb...@google.com
Date: Thu Dec 11 20:02:30 2008
New Revision: 4320
Modified:
trunk/tools/api-checker/config/gwt15_16userApi.conf
trunk/tools/api-checker/src/com/google/gwt/tools/apichecker/ApiContainer.java
trunk/tools/api-checker/src/com/google/gwt/tools/apichecker/ApiPa
(Moving conversation to contrib).
The question is can we remove a very public interface from our API without
deprecating it first, even if we java doc that it is going away?
For instance, a user might be storing a set of clickable gwt widgets in a
List. That code would not produce any deprecati
On Thu, Dec 11, 2008 at 9:50 PM, wrote:
> Umm, that's a pretty big dependency - it has to run the GWT compiler and
> use its internal data structures... What if we wanted to get good use of
> the tool we already have without rewriting it?
>
I think long term we want to replace TypeOracle data s
Comment by zun...@google.com:
@Scott - isn't it a pretty large dependency to depend on the GWT compiler
and its internal data structures (TypeOracle). How much of an effort would
it be to re-write the tool without using TypeOracle and would we get the
same functionality?
IMHO, it is alrea
Comment by zun...@google.com:
Umm, that's a pretty big dependency - it has to run the GWT compiler and
use its internal data structures... What if we wanted to get good use of
the tool we already have without rewriting it?
For more information:
http://code.google.com/p/google-web-toolkit/w
Author: sco...@google.com
Date: Thu Dec 11 17:55:55 2008
New Revision: 4313
Modified:
wiki/WAR_Design_1_6.wiki
Log:
Updating open issues and tasks.
Modified: wiki/WAR_Design_1_6.wiki
==
--- wiki/WAR_Design_1_6.wiki
Author: fabb...@google.com
Date: Thu Dec 11 18:30:55 2008
New Revision: 4314
Added:
trunk/reference/code-museum/src/com/google/gwt/museum/client/defaultmuseum/Issue3186.java
- copied unchanged from r4299,
/releases/1.6/reference/code-museum/src/com/google/gwt/museum/client/defaultm
Comment by sco...@google.com:
I kinda feel like ApiChecker should be cut loose from GWT. Its
relationship to GWT is really that of a third-party tool. The only
problem, really, is its dependency on TypeOracle; but that's an
implementation detail. I think if we were starting from fresh, w
LGTM
--
Bob Vawter
Google Web Toolkit Team
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---
SelectionScriptLinker: nicer error message that makes it more clear what's
going on.
was: This module needs to be (re)compiled, please run a compile or use the
Compile/Browse button in hosted mode
now: GWT module 'your.ModuleName' needs to be (re)compiled, please run a
compile or use the Compil
On Fri, Dec 12, 2008 at 10:57 AM, Scott Blum wrote:
> There might be a simpler variant to what you propose but in a similar
> spirit. Instead of injecting code into static initializers, could we just
> use an ASM visitor to gather the information that we'd get later through
> reflection, without
There might be a simpler variant to what you propose but in a similar
spirit. Instead of injecting code into static initializers, could we just
use an ASM visitor to gather the information that we'd get later through
reflection, without actually having to load the target class?
On Thu, Dec 11, 20
For what it's worth RayR (damn it, I used to love the fact that my
name was rare on lists. Curse Google for hiring Ray's :) ), I think
you were still right to be somewhat cautious here, due to the fact
that stuff introduced into core becomes legacy and hard to change
without breakage. There might
On Thu, Dec 11, 2008 at 6:12 PM, Sam Gross wrote:
> In which branch is OOPHM development taking place? I see trunk/dev/oophm,
> but this project seems to cause compile errors for the gwt-user project,
> since the version of GWTShell in trunk/dev/oophm is missing some expected
> methods.
>
The m
Amit, could you review this change?
Adding gwt-externals directory to gwt-incubator trunk in order to support
the use of gwt's build-tools directory.
Change at:
http://code.google.com/p/google-web-toolkit-incubator/source/detail?r=1302
Thanks,
Emily
--
"There are only 10 types
Well put, RayC, thanks. MVC is exactly the intended point of HasValue.
(Freeland, John, it's HasValue, that's not being debated, fret ye not.)
And you guys are right, I think, that we're wrong to paralyze ourselves with
fears of future confusion with our still-vague-but-crystallizing-nicely
notions
Hi John and Bob,
In which branch is OOPHM development taking place? I see trunk/dev/oophm,
but this project seems to cause compile errors for the gwt-user project,
since the version of GWTShell in trunk/dev/oophm is missing some expected
methods.
What are the key things that need to be done befor
Hi, this patch records some information that makes the final report
much easier to read. The internal fragment numbers are really
obscure, so the less they show up in the reports, the better.
It looks generally good but I think there should be a few small modifications.
First, it looks like it
Author: amitman...@google.com
Date: Thu Dec 11 15:08:00 2008
New Revision: 4312
Modified:
wiki/SharingCodeAmongGwtProjects.wiki
Log:
Edited wiki page through web user interface.
Modified: wiki/SharingCodeAmongGwtProjects.wiki
=
Author: amitman...@google.com
Date: Thu Dec 11 14:58:35 2008
New Revision: 4311
Modified:
wiki/SharingCodeAmongGwtProjects.wiki
Log:
Edited wiki page through web user interface.
Modified: wiki/SharingCodeAmongGwtProjects.wiki
=
Author: amitman...@google.com
Date: Thu Dec 11 14:52:18 2008
New Revision: 4310
Modified:
wiki/SharingCodeAmongGwtProjects.wiki
Log:
Edited wiki page through web user interface.
Modified: wiki/SharingCodeAmongGwtProjects.wiki
=
Author: amitman...@google.com
Date: Thu Dec 11 14:50:38 2008
New Revision: 4309
Modified:
wiki/SharingCodeAmongGwtProjects.wiki
Log:
Edited wiki page through web user interface.
Modified: wiki/SharingCodeAmongGwtProjects.wiki
=
Author: amitman...@google.com
Date: Thu Dec 11 14:48:58 2008
New Revision: 4308
Added:
wiki/SharingCodeAmongGwtProjects.wiki
Log:
Created wiki page through web user interface.
Added: wiki/SharingCodeAmongGwtProjects.wiki
==
I'm going through all the JUnit test sequences that Scott and I came up with
right now. We really have to land these two patches together -- if we don't,
then all the Event.trigger() methods are only going to cause everyone to run
headlong into the same problem I did. I'll be sending an updated pat
You detect this case by checking if you've received a null
PrintWriter. If so, you've already run, and should just return the
appropriate new statement.
rjrjr
On Fri, Dec 12, 2008 at 4:42 AM, John LaBanca wrote:
> Do you get any specific error in web mode? The generator runs at compile
> time,
On Thu, Dec 11, 2008 at 5:12 PM, BobV wrote:
> My original solution to the ClassCircularityError was to implement
> an ASM visitor that added or modified a class's static initializer to
> call over to CCL.injectJsni(). This ensured that the Class was
> fully-reified before any attempt at dispId
This is a follow-up from the previous commit at 4304.
The problem basically boils down to the fact that in the OOPHM code
branch, the assignment of dispatch ids is now driven by reflection so
that we may pre-assign numeric ids for Java methods and fields before
rewritten JSNI code is injected i
IMHO, the concept of a Widget having a value is that it has only one
value. The "value" can certainly be an object with multiple fields, or
with conversion helper functions (String->Boolean), but it's one value
with a normalized internal representation.
For example, consider an USPostalAddressWid
On Thu, Dec 11, 2008 at 8:38 AM, Marek Gregor wrote:
> Reason why we do not want to use GWT interfaces (Constants,
> ConstantsWithLookup, Message) is that we do not want to make
> dependency on GWT (gwt-servlet.jar or gwt.user.jar) for every module
> where localization is used.
>
It would be poss
We use GWT as web client technology for enterprise J2EE system (EJB,
JAAS, ...) which is also capable to offer swing client GUI via java-
web-start.
Our aim is to make development simple (because of the size of
project)- to use the same code for the same thing in all parts of the
code. But nowada
At the risk of seeming to hand-wave that problem away, I would say
that any Widget seeking to implement HasValue twice is not a candidate
for HasValue at all. HasValue is, by definition, for Widgets with a
single distinct value. The value of a CheckBox is either a String or a
Boolean (we've seen a
On Thu, Dec 11, 2008 at 2:20 PM, Freeland Abbott wrote:
> To be fair, my friend was extending TextBox---which came to implement
> HasValue, and thus acquired the colliding String getValue()---when he should
> have extended Composite (which doesn't) instead; that was my suggested
> resolution for
Ah. We have a disconnect:
> However, the "old" HasValue is not parameterized, and implies something has
> *string* value, period. As applied to CheckBox, that's confusing-to-wrong.
I'm not familiar with the old HasValue. The code I was referring to
was originally committed to gwt-incubator as r
Author: fabb...@google.com
Date: Thu Dec 11 11:04:37 2008
New Revision: 4307
Modified:
trunk/distro-source/windows/build.xml
Log:
Windows should have , not , though Ant 1.7 doesn't
care. (Ant 1.6 does.)
Modified: trunk/distro-source/windows/build.xml
==
To be fair, my friend was extending TextBox---which came to implement
HasValue, and thus acquired the colliding String getValue()---when he should
have extended Composite (which doesn't) instead; that was my suggested
resolution for him. He grumbled ("but it 'is-a' TextBox, that should be
extends"
The HasValue interface's usefulness is entirely separable from any
framework or library which might or might not be built on top of it.
TelephoneTextBox is a great example of that. You could wrap a single
TextBox in a composite that implements HasValue and
another composite (TelephoneChooser?) tha
All as described; I got a LGTM from Amit on it, and thought I committed
it... but it looks like I dropped the ball.
Sorry, submitted trunk @4307. As noted, 1.6 is non-problemmatic.
On Thu, Dec 11, 2008 at 11:59 AM, Scott Blum wrote:
> Because newer versions of Ant (1.7?) allow it, and our bui
No, Scott's right, I should svn merge rather than commiting a
metadata-unrelated patch. Both achieve the desired effect; one establishes
the metadata trail.
Showing the patch of what's being done for review is separate, and generally
not habitual; but then, we don't generally cherrypick merges eit
On Thu, Dec 11, 2008 at 1:33 PM, Bruce Johnson wrote:
> @Scott: Blame me. I asked Freeland to take this approach because we are
> still urgently trying to stabilize the trunk. We'll knowingly suffer the
> cost of a yuckier merge, but we definitely can't take any chance of
> additional breakages.
@Scott: Blame me. I asked Freeland to take this approach because we are
still urgently trying to stabilize the trunk. We'll knowingly suffer the
cost of a yuckier merge, but we definitely can't take any chance of
additional breakages.
On Thu, Dec 11, 2008 at 11:42 AM, Scott Blum wrote:
> Freelan
Do you get any specific error in web mode? The generator runs at compile
time, so if it works in hosted mode, it should work in web mode. The main
difference is that in hosted mode it should only run once, whereas in
compiled mode it runs once per permutation. Your generator looks straight
forwa
Any ideas why this is not working in compiled mode?
I'm aware that my approach may be violating the generator approach but
it would be interesting to know why it fails.
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--
Is this for 1.6, or trunk? Also: need patch file?
On Thu, Dec 11, 2008 at 9:48 AM, Eric Ayers <[EMAIL PROTECTED]> wrote:
> Hi Scott,
>
> John observed that the messages coming out of Browser ManagerServer
> draw too much attention to the bad status value returned when the
> browser exits. In fac
Because newer versions of Ant (1.7?) allow it, and our build system only
officially supports 1.7+.
On Thu, Dec 11, 2008 at 11:57 AM, John LaBanca <[EMAIL PROTECTED]> wrote:
> I didn't see it in the 1.6 branch. The line in question references soyc,
> which is only in trunk as far as I know:
> pr
I didn't see it in the 1.6 branch. The line in question references soyc,
which is only in trunk as far as I know:
This line was recently committed. It just uses tarfileset instead of
zipfileset, which causes build errors. I'm not sure why this hasn't
affected anyone else yet.
Thanks,
John LaB
Wait, this sounds like something already committed. Was it something
committed to trunk that should have been 1.6, or vice versa?
On Thu, Dec 11, 2008 at 11:42 AM, John LaBanca <[EMAIL PROTECTED]> wrote:
> Freeland -
>
> Please do a code review on this patch that fixes the windows distro build
>
Freeland -
Please do a code review on this patch that fixes the windows distro build
file.
Description:
=
does not support the , at least on my machine. This looks
like a typo,
Fix:
===
Changed to , which is consistent with the rest of
the file.
Testing:
==
Building using "ant" n
LGTM, but I'm not happy with this whole thing. There's gotta be a better
way.
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---
Author: [EMAIL PROTECTED]
Date: Thu Dec 11 07:41:33 2008
New Revision: 4306
Modified:
releases/1.6/user/src/com/google/gwt/user/client/ui/Widget.java
Log:
Changed the comment to use new handler names.
Modified: releases/1.6/user/src/com/google/gwt/user/client/ui/Widget.java
Freeland: I would strongly prefer that you literally svn merge c4298 and
c4299 from 1.6 into trunk. This will reduce the likelihood of later
conflicts. Also, please record they've already been merged in
1.6/branch-info.txt.
(in trunk)
svn merge -c4298 https://google-web-toolkit.googlecode.com/sv
This review replaces:
http://gwt-code-reviews.appspot.com/805/show
http://gwt-code-reviews.appspot.com/606
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---
Reviewers: ecc,
Description:
The new NativePreviewEvent and NativePreviewHandler replaces the old
EventPreview system. Instead of firing only one EventPreview at the top
of the stack, we now fire all NativePreventHandlers. The PopupPanel,
DialogBox, MenuBar, and code museum code has been update
Cool, looking forward to seeing the new patch!
Per our conversation, onPreviewNativeEvent will be exposed, but will
> only contain minimal code by default. The bulk of the code will be in a
> new method previewNativeEvent()
>
Why expose onPreviewNativeEvent at all?
--
"There are only 10 typ
Emily -
I replied to all your comments. I'll send out a new patch for review
soon that addresses all of your issues.
- John
http://gwt-code-reviews.appspot.com/805/diff/1/5
File user/src/com/google/gwt/event/shared/GwtEvent.java (right):
http://gwt-code-reviews.appspot.com/805/diff/1/5#newco
Author: [EMAIL PROTECTED]
Date: Thu Dec 11 07:38:37 2008
New Revision: 4305
Modified:
releases/1.6/user/src/com/google/gwt/user/client/ui/ListenerWrapper.java
releases/1.6/user/src/com/google/gwt/user/client/ui/Widget.java
Log:
Commiting fix for 3186, Mouse enter/leave events need to sup
Thanks! Updated comment to reflect new handler names rather then the old
listener ones.
Committed at r4305.
On Thu, Dec 11, 2008 at 10:22 AM, John LaBanca <[EMAIL PROTECTED]> wrote:
> I'm getting server errors, so here is your review:
>
> // Only fire the mouseEnter event if it's coming from ou
I'm getting server errors, so here is your review:
// Only fire the mouseEnter event if it's coming from outside this
mouseEnter should be mouseOver since we are firing a MouseOverEvent
// Only fire the mouseLeave event if it's actually leaving this
mouseLeave should be mouseOut since we are fir
Reviewers: jlabanca,
Description:
GWT issue:
http://code.google.com/p/google-web-toolkit/issues/detail?id=3189&q=owner:ecc%20started
Please review this at http://gwt-code-reviews.appspot.com/810
Affected files:
user/src/com/google/gwt/user/client/ui/ListenerWrapper.java
user/src/com/googl
Hi Scott,
John observed that the messages coming out of Browser ManagerServer
draw too much attention to the bad status value returned when the
browser exits. In fact, non-zero exits are the normal way all the
browsers we test return, so there is no use alarming them.
Note: Even if we do decide
It would be really nice if we could do this, and once we have out of process
hosted mode we will be able to. If you look at your class path rules, notice
you have "gwt-dev-windows" hard-coded in your classpath dependencies.
Cheers,
Emily
On Thu, Dec 11, 20
LGTM. Should we freeze new commits to 1.6 until the rest of this shakes
out?
On Thu, Dec 11, 2008 at 12:30 AM, Freeland Abbott <
[EMAIL PROTECTED]> wrote:
> This is going to make our next 1.6 -> trunk merge mildly unpleasant, but we
> need the 1.6 fixes at c4298 and c4299 'cause we're seeing the
Thanks Bob and Freeland. I should have mentioned that the current about.txt
is just a placeholder and I was planning to work with Emily to fix it up
later. I will remember to update the copyright and include the licensing
info. I also forgot to activate checkstyle for gwt-incubator. Will fix those
No longer use mysterious gwt-resources directory, and instead tie straight
to the needed GWT_TOOLS entries.
rjrjr
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---
incubator-
Author: [EMAIL PROTECTED]
Date: Wed Dec 10 23:50:53 2008
New Revision: 4304
Modified:
trunk/dev/core/src/com/google/gwt/dev/shell/CompilingClassLoader.java
trunk/user/test/com/google/gwt/dev/jjs/test/JsoTest.java
Log:
Fix a ClassCircularityError caused by a supertype having a JSNI refere
78 matches
Mail list logo
