Author: [EMAIL PROTECTED]
Date: Tue Oct 7 15:35:36 2008
New Revision: 3726
Modified:
changes/jat/oophm-branch/dev/core/src/com/google/gwt/dev/util/log/SwingLoggerPanel.java
Log:
Don't display stubbed-out filtering controls.
Modified:
changes/jat/oophm-branch/dev/core/src/com/google/gw
Hi Arthur,
On Tue, Oct 7, 2008 at 1:51 PM, Arthur Kalmenson <[EMAIL PROTECTED]> wrote:
>> I don't mean to nitpick, but it's actually the editor that puts back
>> the previous value, not the converter. The converter just throws a
>> ConversionException if the String couldn't be converted. It's u
Hi Miguel,
This patch addresses issue 183, a typo in a method name:
http://code.google.com/p/gwt-google-apis/issues/detail?id=183
I renamed the method in the library class and updated the test.
M test/com/google/gwt/gears/client/localserver/LocalServerTest.java
M
src/com/google/gwt/gears/clien
Will review.
On Tue, Oct 7, 2008 at 12:22 PM, Lex Spoon <[EMAIL PROTECTED]> wrote:
> Okay, here is a patch that gives the bootstrap entry method an
> enclosing class. It went together simply; I simply updated all
> references to JProgram.entryMethods. The one non-trivial part was
> GenerateJava
> When I designed the library, I thought of bound widgets as views on
> fields in a bean. If the bean changes, the widget is updated and if
> the widget changes, the bean is updated. If you created a "detached"
> editor that didn't automatically update the bean, what would you want
> to happen i
On Tue, Oct 7, 2008 at 12:53 PM, Emily Crutcher <[EMAIL PROTECTED]> wrote:
>
>>
>>
> It would typically be the case that you would want to sink, however
> this is not always true, so we want users to have the option of whether to
> sink or not.
>
addDomHandlerAndSink()?
>
>
>
It would typically be the case that you would want to sink, however this
is not always true, so we want users to have the option of whether to sink
or not.
>>>
>>> addDomHandlerAndSink()?
>>>
>>
If we are depending upon javadoc, what about just calling it
addDomHandler(DomHa
Author: [EMAIL PROTECTED]
Date: Tue Oct 7 09:17:27 2008
New Revision: 3725
Added:
trunk/reference/code-museum/src/com/google/gwt/museum/client/defaultmuseum/Issue2855.java
(contents, props changed)
Modified:
trunk/reference/code-museum/src/com/google/gwt/museum/client/defaultmus
Okay, here is a patch that gives the bootstrap entry method an
enclosing class. It went together simply; I simply updated all
references to JProgram.entryMethods. The one non-trivial part was
GenerateJavaScriptAST, which used to pick up entry methods by looking
at the first (or last?) thing that
Thanks for keeping us honest, Ray! Alex and I will add a test for this
behavior to DialogBoxTest and reply back on this thread with the code
review.
On Tue, Oct 7, 2008 at 11:26 AM, Ray Ryan <[EMAIL PROTECTED]> wrote:
> Shouldn't there be a change to PopupTest to go along with this?
>
> On 10/7/0
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
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 to
>>> sink? If so, then it makes more sense for the names to be uni
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 to
>> sink? If so, then it makes more sense for the names to be uniform, perhaps
>> even left as is.
>>
>
> It would typically be the case that you
On Tue, Oct 7, 2008 at 10:56 AM, Arthur Kalmenson <[EMAIL PROTECTED]> wrote:
> Yes, I'm looking to avoid updating the bean automatically. I want to
> specify when the bean should be updated.
I see. I hadn't thought of that use case. As it stands, no, you
can't do that. BoundFieldImpl has a nes
Shouldn't there be a change to PopupTest to go along with this?
On 10/7/08, Alex Rudnick <[EMAIL PROTECTED]> wrote:
>
> Hey Rajeev :)
>
> Thanks for the quick review!
>
> Responses inline.
>
> On Mon, Oct 6, 2008 at 7:08 PM, Rajeev Dayal <[EMAIL PROTECTED]> wrote:
>> DialogBox.java
>> 199: Spelli
Hey Rajeev :)
Thanks for the quick review!
Responses inline.
On Mon, Oct 6, 2008 at 7:08 PM, Rajeev Dayal <[EMAIL PROTECTED]> wrote:
> DialogBox.java
> 199: Spelling: sceen --> screen
OK
> 243: @Overrides on an a method that implements an interface only works in
> Java 1.6. While GWT on the th
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 fo
> I'm not sure what you mean. Are you looking to avoid updating the
> bean until sometime after the editor has changed?
Yes, I'm looking to avoid updating the bean automatically. I want to
specify when the bean should be updated.
It'll also be interesting to see what the performance implication
Author: [EMAIL PROTECTED]
Date: Tue Oct 7 07:54:14 2008
New Revision: 3724
Modified:
trunk/user/src/com/google/gwt/user/client/ui/DialogBox.java
trunk/user/src/com/google/gwt/user/client/ui/PopupPanel.java
Log:
Let users drag DialogBoxes off the screen in any direction, but only as
lo
>
> Would it be typical to addHandler() for a DOM event and *not* want to sink?
> If so, then it makes more sense for the names to be uniform, perhaps even
> left as is.
>
It would typically be the case that you would want to sink, however this is
not always true, so we want users to have the opti
LGTM
On Mon, Oct 6, 2008 at 10:16 AM, Eric Ayers <[EMAIL PROTECTED]> wrote:
> (Forgot to CC: Miguel)
>
> On Fri, Sep 26, 2008 at 5:42 PM, Eric Ayers <[EMAIL PROTECTED]> wrote:
>
>> Hello Miguel,
>>
>> I would like for you to review the attached patch.
>>
>> I used the wrong constructor in a nati
LGTM
On Fri, Sep 26, 2008 at 4:33 PM, Eric Ayers <[EMAIL PROTECTED]> wrote:
> Hello Miguel,
>
> Could you please review the attached patch? I've already committed it as
> r857. This was brought to my attention from a gwt-maps developer that
> attended Google Developer Day in Madrid (Alberto Núñe
If there are really two different kinds of things (that is, (1) logical
handlers and (2) dom handlers), why not change the names to reflect that?
Would it be typical to addHandler() for a DOM event and *not* want to sink?
If so, then it makes more sense for the names to be uniform, perhaps even
lef
On Tue, Oct 7, 2008 at 9:28 AM, Arthur Kalmenson <[EMAIL PROTECTED]> wrote:
> - Is it possible to run the binding on demand instead of automatically
> with the attached listeners? Say I want to only run the binding after
> the user pressed the submit button, is that possible?
I'm not sure what yo
Hello Ian,
I had a coworker take a look at the data binding framework. It looks
really good so far, but we had a couple of questions:
- Is it possible to run the binding on demand instead of automatically
with the attached listeners? Say I want to only run the binding after
the user pressed the
Hello Miguel,
Here is another patch I'd like for you to review. It addresses issue 189 in
the issue tracker:
http://code.google.com/p/gwt-google-apis/issues/detail?id=189
The problem was very easy to solve, but I went ahead and added some more
unit testing and eliminated some warnings from a
26 matches
Mail list logo
