http://code.google.com/p/google-web-toolkit/issues/detail?id=3056
On Wed, Oct 29, 2008 at 3:13 PM, Ray Ryan [EMAIL PROTECTED] wrote:
There's no good reason beyond sometimes you want divs. This is a long
standing complaint, and I believe the forgotten plan was to either offer new
analogs
On Tue, Oct 28, 2008 at 11:32 AM, John Tamplin [EMAIL PROTECTED] wrote:
On Tue, Oct 28, 2008 at 2:28 PM, Emily Crutcher [EMAIL PROTECTED] wrote:
I would be more in favor of forbidding them everywhere then allowing them
in only 1% of the cases, as knowing it is always the case that generics
If we're going to differ from the community, the onus is on us have a very
good reason to do so. I don't think we have one, and thus my preference for
the single letter names.
That said, Freeland's E, E, E case is not contrived, and it seems foolish
to be so rigid as to forbid using something
On Mon, Oct 27, 2008 at 1:26 PM, John Tamplin [EMAIL PROTECTED] wrote:
On Mon, Oct 27, 2008 at 4:22 PM, Ray Ryan [EMAIL PROTECTED] wrote:
** KeyGenerator.java:191
Shouldn't you be recursively checking all superclasses? Hmm. Actually,
since these things are interfaces, why check super at all
** KeyGenerator.java:191
Shouldn't you be recursively checking all superclasses? Hmm. Actually,
since these things are interfaces, why check super at all?
** CommonInterfaceAnnotations.java:22
Nit: need p to break up 'graphs in javadoc
On Fri, Oct 24, 2008 at 1:50 PM, John Tamplin [EMAIL
in the
unrelated issue 1047 you have three, one of whom had a viable workaround. I
saw nothing to indicate that the default behavior had to change. An option
would be sufficient.
Where's the overwhelming call for a breaking change?
On Thu, Oct 16, 2008 at 1:15 PM, Ray Ryan [EMAIL PROTECTED
LGTM
On Mon, Oct 27, 2008 at 2:47 PM, John Tamplin [EMAIL PROTECTED] wrote:
Ok, here is a revised patch which recursively follows the inheritance
chains, and the test improved to check for that.
--
John A. Tamplin
Software Engineer (GWT), Google
for this issue
Fred Sauer
[EMAIL PROTECTED]
On Thu, Oct 16, 2008 at 7:39 PM, Ray Ryan [EMAIL PROTECTED] wrote:
I've just uploaded the files for 1.5.3 RC, which you'll find here:
http://code.google.com/p/google-web-toolkit/downloads/list?can=1q=1.5.3
(Please don't be put off by the deprecated tags
Hi, all.
We have just deprecated GWT 1.5.2, and replaced it with GWT 1.5.3.
This new release has a small handful of patches, mainly aimed at
fixing RPC problems with Android. You can download the update from the
usual location:
http://code.google.com/webtoolkit/download.html
You may find that
is a great idea but is doing so with a breaking change
really necessary?
On Wed, Oct 15, 2008 at 5:51 PM, Ray Ryan [EMAIL PROTECTED] wrote:
This
addresses http://code.google.com/p/google-web-toolkit/issues/detail?id=2330
The SuggestBox will no longer select its first item by default. In case
think a more conservative
approach is desirable.
On Thu, Oct 16, 2008 at 12:45 PM, Ray Ryan [EMAIL PROTECTED] wrote:
But if you compare the suggest box to its peers on actual web pages
(especially including our own), you'll find they don't do this auto
select thing. I think the current
I've just uploaded the files for 1.5.3 RC, which you'll find here:
http://code.google.com/p/google-web-toolkit/downloads/list?can=1q=1.5.3
(Please don't be put off by the deprecated tags, that's just to keep them
from showing up on the main download page. As soon as we have the group's
no smoke
Hey, Alex.
This patch cleans up a couple of spots where we were unnecessarily declaring
extends HasHTML, HasText (silly, since HasHTML itself extends HasText). It's
intended for the 1.6 branch.
M src/com/google/gwt/user/client/ui/DialogBox.java
M
This addresses
http://code.google.com/p/google-web-toolkit/issues/detail?id=2330
The SuggestBox will no longer select its first item by default. In case
there are existing apps that prefer this behavior, a boolean property
(selectsFirstItem) is added to turn it back on.
rjrjr
We all seem to be talking about data binding and validation a lot, and some
of us are even implementing code about it. We on the GWT team hear the need
and feel it ourselves.
We have some notions of how we'd like to tackle this in a way that blends
seamlessly with the rest of GWT, and are looking
It might be good for the javadoc on the setter methods to mention that they
have no immediate effect if called while the dialog is showing. In fact,
should we encourage people to hide the dialog before using the new setters?
It looks like we have no test coverage for the panel's behavior in its
On Tue, Oct 7, 2008 at 11:36 AM, Emily Crutcher [EMAIL PROTECTED] wrote:
On Tue, Oct 7, 2008 at 11:30 AM, Ray Ryan [EMAIL PROTECTED] wrote:
On Tue, Oct 7, 2008 at 10:51 AM, Emily Crutcher [EMAIL PROTECTED] wrote:
Would it be typical to addHandler() for a DOM event and *not* want
, Oct 3, 2008 at 12:07 PM, Ray Ryan [EMAIL PROTECTED] wrote:
I'm with Isaac. I think the case for teaching our Widgets to implement
HasDataT is really clear cut (especially if they also accept DataChange
listeners). The DataManager is a bit harder to justify, and anyway
trivial
for folks
701 - 718 of 718 matches
Mail list logo
