If what you are hinking about is ths "gwt-dev--libs.zip"
that is in maven repo, I've created this bundle for the Mojo project
gwt-maven-plugin (1.0 final release curently beeing voted), so YES,
this one should also be created and deployed.
On 20 nov, 23:15, "Ray Cromwell" <[EMAIL PROTECTED]> wr
LGTM
http://codereview.appspot.com/9656
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---
w00t, we committed this as r4145! We did make a few changes to it:
- Passing serialized ASTs around is gimpy, we just pass the UnifiedAst; it
can handle memory management internally. This actually allows the main
process to reuse the original Ast.
- We flipped things around such that the caller
I checked about java.home, and as far as I can tell the patch is doing
the right things.
I messed around with the threading logic, and did manage to come up
with something I think is a little easier to reason about. It's not a
huge advantage, but I get paranoid about concurrency bugs, so every
li
Author: [EMAIL PROTECTED]
Date: Thu Nov 20 14:50:49 2008
New Revision: 4144
Modified:
branches/1_6_datepicker/user/src/com/google/gwt/user/datepicker/client/DatePicker.java
Log:
removing getShownDate() and exposing the calendar view's getFirstDate() and
getLastDate() instead.
Also, in or
Author: [EMAIL PROTECTED]
Date: Thu Nov 20 14:23:18 2008
New Revision: 4143
Modified:
releases/1.6/branch-info.txt
Log:
Recording 1.6 -> trunk merge.
Modified: releases/1.6/branch-info.txt
==
--- releases/1.6/branch
Funny you should mention this.. we had a crazy plan once to embed the native
libs into gwt-dev.jar, and at startup install them into the temp directory
and then load them, with delete on exit.
On Thu, Nov 20, 2008 at 5:15 PM, Ray Cromwell <[EMAIL PROTECTED]> wrote:
> If this is done, please make
BTW, while we're discussing maven, fixing the long standing hosted
mode classloader issue (Issue #1032) that blocks the maven JUnit test
runner from working would be nice. :) The gwt-maven plugin works
around this with a custom test runner, but it exists outside of
maven's reporting and error hand
If this is done, please make sure that the conventions adhere to the
gwt-maven plugin's repo layout. This allows you to use the
maven-dependency plugin to download the platform specific JNI
libraries separately and unpack them, so that one doesn't have to
"install" the GWT distribution and set up
[google-web-toolkit] [EMAIL PROTECTED] commented on revision r4138.
Details are at
http://code.google.com/p/google-web-toolkit/source/detail?r=4138
Score: Positive
General Comment:
These were fixed in subsequent commits, issues with the fixes should be put
there.
Respond to these comments a
I was considering only releases, as google-maven-repository has a
rsync to publish on maven central
But maybe you'd like to have a custom snapshot / milestones repository
(the way Springframework does for example).
Nicolas
On 20 nov, 21:59, Scott Blum <[EMAIL PROTECTED]> wrote:
> Do you mean for
Author: [EMAIL PROTECTED]
Date: Thu Nov 20 14:08:19 2008
New Revision: 4141
Modified:
branches/1_6_datepicker/user/src/com/google/gwt/user/datepicker/client/DatePicker.java
Log:
Adding getModel().refresh() to refreshAll() method and renaming bad
oldSelected var
Modified:
branches/1_6_
committed at r.1214
2008/11/20 BobV <[EMAIL PROTECTED]>
> LGTM
>
> --
> Bob Vawter
> Google Web Toolkit Team
>
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---
LGTM
--
Bob Vawter
Google Web Toolkit Team
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---
Author: [EMAIL PROTECTED]
Date: Thu Nov 20 14:04:16 2008
New Revision: 4140
Modified:
branches/1_6_datepicker/user/src/com/google/gwt/user/datepicker/client/DatePicker.java
Log:
Constantly use getView and getMonthSelector rather then the private fields.
Modified:
branches/1_6_datepicker
Author: [EMAIL PROTECTED]
Date: Thu Nov 20 13:55:58 2008
New Revision: 4139
Modified:
branches/1_6_datepicker/user/src/com/google/gwt/user/datepicker/client/DatePicker.java
Log:
Fixing up javadoc params + param names. Also changed constructor doc to the
vacuous "create new date picker" b
[google-web-toolkit] [EMAIL PROTECTED] commented on revision r4138.
Details are at
http://code.google.com/p/google-web-toolkit/source/detail?r=4138
Score: Neutral
General Comment:
Typos here, need to delete "view" from both lines
hee hee, eclipse auto-renaming can be fun!
should be calling g
[google-web-toolkit] [EMAIL PROTECTED] commented on revision r4138.
Details are at
http://code.google.com/p/google-web-toolkit/source/detail?r=4138
Score: Negative
Line-by-line comments:
File:
/branches/1_6_datepicker/user/src/com/google/gwt/user/datepicker/client/DatePicker.java
(r4138
Author: [EMAIL PROTECTED]
Date: Thu Nov 20 13:27:49 2008
New Revision: 4138
Modified:
branches/1_6_datepicker/user/src/com/google/gwt/user/datepicker/client/DatePicker.java
Log:
Finalized variables, renamed them to use short versions.
Modified:
branches/1_6_datepicker/user/src/com/googl
Comment by HMEDNA:
hi to le monde
For more information:
http://code.google.com/p/google-web-toolkit/wiki/TableOfContents
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---
John, just submitted this TBR you to fix the 1.6 build.
-- Forwarded message --
From: <[EMAIL PROTECTED]>
Date: Thu, Nov 20, 2008 at 4:15 PM
Subject: [gwt-contrib] [google-web-toolkit commit] r4137 -
releases/1.6/user/javadoc/com/google/gwt/examples
To: [EMAIL PROTECTED]
Author:
Author: [EMAIL PROTECTED]
Date: Thu Nov 20 13:14:33 2008
New Revision: 4137
Added:
releases/1.6/user/javadoc/com/google/gwt/examples/LazyPanelExample.java
Log:
Untested LazyPanelExample--needed to fix 1.6 build. TBR jlabanca
Added:
releases/1.6/user/javadoc/com/google/gwt/examples/LazyPan
Do you mean for things like nightlies, or just full releases?
On Wed, Nov 19, 2008 at 11:12 AM, nicolas.deloof
<[EMAIL PROTECTED]>wrote:
>
> Hi,
>
> As a maven developper, I have contributed the central repository with
> gwt artifacts. I now GWT team doesn't want to use maven as build
> system, a
On Thu, Nov 20, 2008 at 2:44 PM, Lex Spoon <[EMAIL PROTECTED]> wrote:
> Things for you to do, Bob, by my notes:
Also:
4. Call accept() within the worker thread, not in the main thread that
creates all the workers. That should speed things up a little,
allowing the first JVM that starts to go ah
Author: [EMAIL PROTECTED]
Date: Thu Nov 20 12:46:28 2008
New Revision: 4136
Modified:
releases/1.6/branch-info.txt
Log:
Adds rev number to last 1.5 merge line, TBR jat
Modified: releases/1.6/branch-info.txt
==
--- r
Author: [EMAIL PROTECTED]
Date: Thu Nov 20 12:45:19 2008
New Revision: 4135
Modified:
branches/1_6_datepicker/user/src/com/google/gwt/user/datepicker/client/DatePicker.java
branches/1_6_datepicker/user/src/com/google/gwt/user/datepicker/client/DefaultCalendarView.java
branches/1
John, I just put this in TBR you.
rjrjr
-- Forwarded message --
From: <[EMAIL PROTECTED]>
Date: Thu, Nov 13, 2008 at 8:15 PM
Subject: [gwt-contrib] [google-web-toolkit commit] r4071 -
branches/1_6_clean_events
To: [EMAIL PROTECTED]
Author: [EMAIL PROTECTED]
Date: Thu Nov 13 17:1
Author: [EMAIL PROTECTED]
Date: Thu Nov 20 12:44:31 2008
New Revision: 4134
Added:
releases/1.6/reference/dispatch/
- copied from r4093, /releases/1.5/reference/dispatch/
releases/1.6/reference/dispatch/Dispatch.gwt.xml
- copied unchanged from r4093,
/releases/1.5/referenc
Author: [EMAIL PROTECTED]
Date: Thu Nov 20 12:42:23 2008
New Revision: 4133
Added:
releases/1.6/user/src/com/google/gwt/user/client/ui/LazyPanel.java
releases/1.6/user/test/com/google/gwt/user/client/ui/LazyPanelTest.java
Modified:
releases/1.6/user/src/com/google/gwt/user/client/ui/D
LGTM.
On Thu, Nov 20, 2008 at 3:39 PM, Emily Crutcher <[EMAIL PROTECTED]> wrote:
>
>>
>> Fixed
>>
>>>
>>>It does not create the widget each time, so can we reword the javadoc
>>> a little bit?
>>
>>
>> "creates
>> the sole child widget if necessary" I'm not sure how to make it clearer than
>>
I can't look at the patch proper right now, but the orphans should certainly
be woken up.
Re: the unexplained failures, might you be running some tests twice, and
might they be leaving static artifacts around and stomping themselves?
rjrjr
On Thu, Nov 20, 2008 at 11:47 AM, Freeland Abbott <
[EMA
>
> Fixed
>
>>
>>It does not create the widget each time, so can we reword the javadoc a
>> little bit?
>
>
> "creates
> the sole child widget if necessary" I'm not sure how to make it clearer than
> that.
>
Sorry, somehow managed to lose the "if necessary" stanza the first time I
read it. Yes
[google-web-toolkit] [EMAIL PROTECTED] commented on revision r4132.
Details are at
http://code.google.com/p/google-web-toolkit/source/detail?r=4132
General Comment:
I'm make model final with a commit that makes as many vars final as
possible.
No one should ever need to extend DatePickerCompo
[google-web-toolkit] [EMAIL PROTECTED] commented on revision r4132.
Details are at
http://code.google.com/p/google-web-toolkit/source/detail?r=4132
Score: Negative
Line-by-line comments:
File:
/branches/1_6_datepicker/user/src/com/google/gwt/user/datepicker/client/DatePicker.java
(r4132
On 20 Nov., 20:48, BobV <[EMAIL PROTECTED]> wrote:
> Adding new resource types is done by defining a new interface that
> derives from ResourcePrototype and annotating that new resource with
> an @ResourceGeneratorType annotation. Take a look at TextResource as
> an example of a simple resource
Bob could you review this tiny patch. It contains a fix for
CssResourceGenerator ImageResource Method lookups. It wasn't
checking supertypes.
Bruce already exposed everything we would need, since ImageBundle pretty
much does the same thing.
Patch taken against trunk.
Files affected in Incubator t
Adding new resource types is done by defining a new interface that
derives from ResourcePrototype and annotating that new resource with
an @ResourceGeneratorType annotation. Take a look at TextResource as
an example of a simple resource type.
In the simplest case, you could define a new reso
Thanks, Bob.
List, Bob and I looked at this together. In general it looks great.
Things I want to do:
1. Ponder the overall strategy for starting up worker threads and
communicating with them. It looks odd to me to use the interrupted
thread state to communicate whether workers should shut do
Author: [EMAIL PROTECTED]
Date: Thu Nov 20 11:38:45 2008
New Revision: 4132
Removed:
branches/1_6_datepicker/user/src/com/google/gwt/user/datepicker/client/StandardCssImpl.java
Modified:
branches/1_6_datepicker/user/src/com/google/gwt/user/datepicker/client/DatePicker.java
branc
BTW: Does ImmutableResourceBundle i18n work for ImageResources?
On 20 Nov., 20:35, dflorey <[EMAIL PROTECTED]> wrote:
> StringResource interface could be just toString()
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~
StringResource interface could be just toString()
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---
It would be cool if someone (bobv) could implement the following ;-)
ImmutableResourceBundle right now offers all that is needed to bundle
the required resources for a widget - except localized constants and
messages.
It would be perfect it the functionality currently provided in the
i18n module
Darn it, I hate when inconvenient facts get in the way of a nice theory! As
I did the benchmark and you are right, there is no advantage of "|" over
"||".
On Thu, Nov 20, 2008 at 12:49 PM, John Tamplin <[EMAIL PROTECTED]> wrote:
> On Thu, Nov 20, 2008 at 12:33 PM, Emily Crutcher <[EMAIL PROTECT
On Thu, Nov 20, 2008 at 12:33 PM, Emily Crutcher <[EMAIL PROTECTED]> wrote:
> Don't quite understand why eliminating three branches is worth the comment
> "compiler-as-it-happened-to-behave-last-time-I-checked", but happy to take
> it out.
Have you actually tested it on a JS interpreter?
Even
Author: [EMAIL PROTECTED]
Date: Thu Nov 20 09:38:00 2008
New Revision: 4131
Modified:
branches/1_6_datepicker/user/src/com/google/gwt/event/dom/client/KeyEvent.java
Log:
Using "||" rather then "|"
Modified:
branches/1_6_datepicker/user/src/com/google/gwt/event/dom/client/KeyEvent.java
=
Updated patch attached.
M user/test/com/google/gwt/user/UISuite.java
M user/test/com/google/gwt/user/client/ui/CompositeTest.java
A user/test/com/google/gwt/user/client/ui/LazyPanelTest.java
M user/src/com/google/gwt/user/client/ui/DisclosurePanel.java
A user/src/com/google
Don't quite understand why eliminating three branches is worth the comment
"compiler-as-it-happened-to-behave-last-time-I-checked", but happy to take
it out.
On Thu, Nov 20, 2008 at 10:01 AM, Ray Ryan <[EMAIL PROTECTED]> wrote:
> I'm not comfortable in general with such reflexive micro-optimiz
If the class is never loaded, how is it unsafe?
On Thu, Nov 20, 2008 at 12:00 PM, John Tamplin <[EMAIL PROTECTED]> wrote:
> On Thu, Nov 20, 2008 at 11:50 AM, Emily Crutcher <[EMAIL PROTECTED]> wrote:
>
>> shared - code that does not contain or reference any class that
>>> contains JSNI,
>>>
On Thu, Nov 20, 2008 at 11:50 AM, Emily Crutcher <[EMAIL PROTECTED]> wrote:
>shared - code that does not contain or reference any class that contains
>> JSNI,
>>GWT.create, or reflection
>
>
> I think this should be "reachable code", in that code hiding behind a
> GWT.isClient(
Joel's near-reemergence reminded me of a few low-priority patches I'd sent
his way just before he became more interested in his new daughter than in
us; mostly they're low-priority convenience (to let you add "all tests in
this package" rather than enumerating them individually), but it uncovered
o
>
>shared - code that does not contain or reference any class that contains
> JSNI,
>GWT.create, or reflection
I think this should be "reachable code", in that code hiding behind a
GWT.isClient() should be allowed.
--~--~-~--~~~---~--~~
http://
It seems like that would be a good patch. It would belong on the gwt issue
tracker.
On Thu, Nov 20, 2008 at 11:30 AM, Isaac Truett <[EMAIL PROTECTED]> wrote:
>
> It certainly doesn't need to be a blocker on this change, but
> separating that popup/popdown logic so that we have our first two
> O
It certainly doesn't need to be a blocker on this change, but
separating that popup/popdown logic so that we have our first two
Orientation options would be handy (for writing a Windows-style
"Start" menu, for example, that should always pop up and never down).
Is this something that would be cons
On Thu, Nov 20, 2008 at 11:21 AM, Emily Crutcher <[EMAIL PROTECTED]> wrote:
>
>
>> Sorry, could have sworn that was public. Btw., DatePicker is littered with
>> direct uses of the calendar field. If getCalendarView() is protected, we
>> should always call it.
>>
>> Still, the amount of duplication
> would have two methods:
>
> Showing a popup above the widget is very useful for cases when the
> popup shown below the widget will scroll the screen. In those cases
> it would be nice to be able to detect that the popup is going to show
> off the bottom of the screen and instead show it above
>
>
> Actually as Ray points out, foo(Bar) and foo(Bar...) are not
> distinguishable overloads, so you would have to reverse the order of the
> arguments to keep the single-arg version.
>
>
One is plural, one is not, so they would hopefully not overlap at all. The
bigger point though, is if the the
Author: [EMAIL PROTECTED]
Date: Thu Nov 20 08:18:54 2008
New Revision: 4130
Modified:
releases/1.6/dev/core/src/com/google/gwt/dev/Link.java
Log:
Add an additional static method to Link to automatically package the linked
resources into the output directories.
This patch is in preparation
>
> Sorry, could have sworn that was public. Btw., DatePicker is littered with
> direct uses of the calendar field. If getCalendarView() is protected, we
> should always call it.
>
> Still, the amount of duplication btw. the DatePicker API and CalendarView
> is odd. Can CalendarView be reduced to a
Author: [EMAIL PROTECTED]
Date: Thu Nov 20 08:17:10 2008
New Revision: 4129
Modified:
releases/1.6/dev/core/src/com/google/gwt/dev/PermutationCompiler.java
releases/1.6/dev/core/src/com/google/gwt/dev/jjs/JavaToJavaScriptCompiler.java
releases/1.6/dev/core/src/com/google/gwt/dev/jjs
On Thu, Nov 20, 2008 at 11:03 AM, John LaBanca <[EMAIL PROTECTED]> wrote:
> That's a good idea. In general, we don't separate client code into a
> shared directory because users can decide what they want to send over RPC.
> For example, a user may not send the Request object, she may take out the
On Thu, Nov 20, 2008 at 10:55 AM, Emily Crutcher <[EMAIL PROTECTED]> wrote:
> Well, we can always add the single-arg one back in, so if the compiler
> actually generates reasonably efficent code for this, I think you're
> probably right.
>
Actually as Ray points out, foo(Bar) and foo(Bar...) are
That's a good idea. In general, we don't separate client code into a shared
directory because users can decide what they want to send over RPC. For
example, a user may not send the Request object, she may take out the data
and send just portions to the server. None the less, it might be a good
i
On Thu, Nov 20, 2008 at 10:23 AM, John Tamplin <[EMAIL PROTECTED]> wrote:
> On Thu, Nov 20, 2008 at 10:04 AM, Emily Crutcher <[EMAIL PROTECTED]> wrote:
>
>> For efficiency and code clearity I would still be inclined to support
>> the singleton version as well, but adding the Date... version as an
On Nov 19, 10:37 am, Emily Crutcher <[EMAIL PROTECTED]> wrote:
> We were not planning on it, because the show below case is by far the most
> useful. However, we should also not box ourselves into corners, so what if
> we renamed the method to showRelativeTo(UIObject object), with the javadoc
>
On Thu, Nov 20, 2008 at 10:32 AM, Ray Ryan <[EMAIL PROTECTED]> wrote:
> "Long term"? 1.6, yes?
>
> On Thu, Nov 20, 2008 at 10:07 AM, Emily Crutcher <[EMAIL PROTECTED]> wrote:
>
>> DateBox should implement the HasValue interface long term, which using the
>> new terminology, does basically what you
"Long term"? 1.6, yes?
On Thu, Nov 20, 2008 at 10:07 AM, Emily Crutcher <[EMAIL PROTECTED]> wrote:
> DateBox should implement the HasValue interface long term, which using the
> new terminology, does basically what you expect here.
>
>
>
> On Thu, Nov 20, 2008 at 4:41 AM, dflorey <[EMAIL PROTECTE
On Thu, Nov 20, 2008 at 10:04 AM, Emily Crutcher <[EMAIL PROTECTED]> wrote:
>
>
> On Wed, Nov 19, 2008 at 10:26 PM, Ray Ryan <[EMAIL PROTECTED]> wrote:
>
>> General comments
>>
>> It seems like there is a lot of overlap between DatePicker and
>> CalendarView. Should the methods in DatePicker that
On Thu, Nov 20, 2008 at 10:04 AM, Emily Crutcher <[EMAIL PROTECTED]> wrote:
> For efficiency and code clearity I would still be inclined to support the
> singleton version as well, but adding the Date... version as an option to
> the plural versions seems like a terrific idea. I don't think it mat
DateBox should implement the HasValue interface long term, which using the
new terminology, does basically what you expect here.
On Thu, Nov 20, 2008 at 4:41 AM, dflorey <[EMAIL PROTECTED]> wrote:
>
> Comment on DateBox:
> Would be cool if there would be a way to get the value of the DateBox.
>
On Wed, Nov 19, 2008 at 10:26 PM, Ray Ryan <[EMAIL PROTECTED]> wrote:
> General comments
>
> It seems like there is a lot of overlap between DatePicker and
> CalendarView. Should the methods in DatePicker that are redundant with
> CalendarView methods be stricken, given DatePicker#getCalendarView?
I'm not comfortable in general with such reflexive micro-optimizations,
especially those that involve second guessing the
compiler-as-it-happened-to-behave-last-time-I-checked.
On Thu, Nov 20, 2008 at 9:20 AM, John Tamplin <[EMAIL PROTECTED]> wrote:
> On Thu, Nov 20, 2008 at 9:09 AM, <[EMAIL PROT
On Thu, Nov 20, 2008 at 9:09 AM, <[EMAIL PROTECTED]> wrote:
> In cases where you expect the conditional to return false most of the time,
> using | instead of || avoids branches, which is faster.
>
That can be true in native code if the compiler's branch prediction is
wrong, but is it actually tr
[google-web-toolkit] [EMAIL PROTECTED] commented on revision r4098.
Details are at
http://code.google.com/p/google-web-toolkit/source/detail?r=4098
Score: Neutral
General Comment:
In cases where you expect the conditional to return false most of the time,
using | instead of || avoids branche
I think perhaps we should support extensible categories of output files (for
example I think it might be useful to split out things expected by the build
system from other non-runtime output, since the build system output can't
change names or formats while human-readable files could). Maybe -dir
I don't know if it's the only place where this question comes up, but
right now the SerializableResponse from the table model requires its
wrapped row values to implement the IsSerializable interface.
So every row value object that implement Serializable (and as such can
be serialized) cannot be u
[google-web-toolkit] t.broyer commented on revision r4122.
Details are at
http://code.google.com/p/google-web-toolkit/source/detail?r=4122
Score: Neutral
General Comment:
What's the rationale for calling all four isXXXKeyDown() (i.e. using
bitwise OR instead of logical OR)?
Those isXXXKeyDow
I'd like to put the classes wrapped into TableModelHelper into the new
"shared" package as they are required both on client and server side.
On 19 Nov., 19:20, John LaBanca <[EMAIL PROTECTED]> wrote:
> TableModelHelper is a temporary class that works around an eclipse compiler
> bug that has been
Comment on DateBox:
Would be cool if there would be a way to get the value of the DateBox.
Right now I struggle to find a way to listen to value changes and get
the value afterwards.
I tried to listen to DatePicker and TextBox changes, but it's very
complicated to find the proper value there.
Prop
78 matches
Mail list logo
