Author: [EMAIL PROTECTED]
Date: Mon Oct 6 00:08:26 2008
New Revision: 3713
Modified:
changes/jat/oophm-branch/dev/core/src/com/google/gwt/dev/util/log/SwingLoggerPanel.java
changes/jat/oophm-branch/dev/core/src/com/google/gwt/dev/util/log/SwingTreeLogger.java
Log:
Added find
Good enough to commit it for me? :)
On Sat, Oct 4, 2008 at 10:33 AM, Emily Crutcher [EMAIL PROTECTED] wrote:
LGTM
On Fri, Oct 3, 2008 at 9:16 PM, Isaac Truett [EMAIL PROTECTED] wrote:
Oops. My *other* datepicker, right.
Here's the new patch with gen2 datepicker and implementing HasValue
This a nice optimization, and one certainly worth keeping in mind. As
part of this transition, I'll be creating some more benchmarks on
performance, and might try it then to see if it makes any practical
difference.
Thanks!
Emily
On Mon, Oct 6, 2008 at 5:54 AM, Thomas
Does this mean that all the GWT core widgets will implement the
HasValue interface?
On Oct 4, 10:33 am, Emily Crutcher [EMAIL PROTECTED] wrote:
LGTM
On Fri, Oct 3, 2008 at 9:16 PM, Isaac Truett [EMAIL PROTECTED] wrote:
Oops. My *other* datepicker, right.
Here's the new patch with gen2
Thank you!
Committed as r1093.
On Mon, Oct 6, 2008 at 9:36 AM, Emily Crutcher [EMAIL PROTECTED] wrote:
As you've proven your ability (several times now) to produce tight good
code, I've added you as a gwt-incubator committer, so you should be able to
commit it yourself
On Mon, Oct 6,
+1 here, as I've recently had to use the violator pattern to flip
those bits.
-jason
On Oct 6, 2008, at 9:44 AM, John LaBanca wrote:
Contributors -
I propose adding the following accessors and getters to PopupPanel:
public boolean isAutoHideEnabled()
public boolean isModal()
public void
va 1.5 features that are now available
This is pretty straight forward. I would use typed lists in
AbstractValidationController, make Subject a generic interface (for
the value returned), and other minor changes.
Yes.
Use interfaces instead of abstract classes
A lot
@Emily
In my case, I needed to create a modal non-autohiding DropDown Panel.
however, the problem is that DropDown calls the PopupPanel constructor
that creates a non-modal auto-hiding PopupPanel.
Currently the only way to flip those bits subsequent to instantiation
but prior to display is
This seems like a pretty persuasive use case.
On Mon, Oct 6, 2008 at 12:47 PM, Ray Ryan [EMAIL PROTECTED] wrote:
+1
For one thing, it lets UI templates set their values without requiring
custom parsers. Something like four different people have inspected the code
for problems at this point
Author: [EMAIL PROTECTED]
Date: Mon Oct 6 10:22:53 2008
New Revision: 3715
Modified:
trunk/user/src/com/google/gwt/dom/client/DOMImplMozilla.java
Log:
Restoring removed innerContent change now that build is green.
Modified: trunk/user/src/com/google/gwt/dom/client/DOMImplMozilla.java
@Emily -
Looking at the code, I don't think there are any edge cases. We don't do
any special setup/teardown if the bits are set, we just check them in
onEventPreview. Also, I think its a valid use case to change them. For
example, if somebody offers a user defined option to enable autoHide.
Scott,
- Could briefly summarize the motivation for the
suite()/JJSOptimizerTestDecator design?
This way the module will be compiled only once. Unfortunately
JavaToJavaScriptCompiler doesn't have any easily extract compiling
pass and I didn't want to seriously refactor it.
-
Freeland,
How's this?
On Fri, Oct 3, 2008 at 6:43 PM, Freeland Abbott
[EMAIL PROTECTED] wrote:
The format for gwt.svnrev is [EMAIL PROTECTED], and if a real answer can't
be determined it's set to [EMAIL PROTECTED], so I'd rather keep that pattern
consistent instead of the 0 here.
As a bigger
Author: [EMAIL PROTECTED]
Date: Mon Oct 6 11:48:14 2008
New Revision: 3716
Modified:
changes/spoon/runAsync/dev/core/src/com/google/gwt/dev/jjs/impl/Pruner.java
Log:
Run visitors over the set of all declared types, not over the whole
JProgram.
Visiting a JProgram ends up visiting entry
The specific use case I was thinking of is related to an efficiency patch I
was toying with that solves the occasionally-slow popup dragging case.
However, Ray + Jason's use cases are much more compelling then mine anyway,
especially since mine isn't implemented yet :-).
On Mon, Oct 6, 2008 at
LGTM, with a minor tweak to the comment to be clearer why it's not a big
deal.
Submitted at r3717.
On Mon, Oct 6, 2008 at 1:46 PM, Mike Aizatsky [EMAIL PROTECTED]wrote:
Freeland,
How's this?
On Fri, Oct 3, 2008 at 6:43 PM, Freeland Abbott
[EMAIL PROTECTED] wrote:
The format for
Author: [EMAIL PROTECTED]
Date: Mon Oct 6 07:54:16 2008
New Revision: 3714
Modified:
releases/1.5/branch-info.txt
releases/1.5/dev/core/src/com/google/gwt/dev/jdt/WebModeCompilerFrontEnd.java
Log:
Merging trunk c3708 into releases/1.5.
Modified: releases/1.5/branch-info.txt
Hey Rajeev :)
Would you take a look at this patch, implementing Joel's suggestion
for keeping DialogBox on the screen?
Instead of trying to decide whether a PopupPanel is being positioned
off the edge, we check whether the user is dragging it off the screen,
and ignore the drag if the pointer
On Mon, Oct 6, 2008 at 1:32 PM, Mike Aizatsky [EMAIL PROTECTED]wrote:
- Could briefly summarize the motivation for the
suite()/JJSOptimizerTestDecator design?
This way the module will be compiled only once. Unfortunately
JavaToJavaScriptCompiler doesn't have any easily extract compiling
Scott,
- Could briefly summarize the motivation for the
suite()/JJSOptimizerTestDecator design?
This way the module will be compiled only once. Unfortunately
JavaToJavaScriptCompiler doesn't have any easily extract compiling
pass and I didn't want to seriously refactor it.
I'm not sure
On Mon, Oct 6, 2008 at 4:27 PM, Mike Aizatsky [EMAIL PROTECTED]wrote:
Scott,
- Could briefly summarize the motivation for the
suite()/JJSOptimizerTestDecator design?
This way the module will be compiled only once. Unfortunately
JavaToJavaScriptCompiler doesn't have any easily
Gotcha. But if you don't compile multiple times, how do you prevent
optimizations that occur in one test method from impacting ones that occur
in another test method?
I can't. I do this by limiting the scope optimization should work on
(see MethodInlineTest)...
By the way, I've already got
Here is the current doc on it, to give context:
/**
* Adds a native event handler to the widget and sinks the corresponding
* native event.
*
* @param HandlerType the type of handler to add
* @param key the event key
* @param handler the handler
* @return [EMAIL PROTECTED]
Author: [EMAIL PROTECTED]
Date: Mon Oct 6 15:12:24 2008
New Revision: 3721
Modified:
changes/spoon/runAsync/dev/core/src/com/google/gwt/dev/jjs/impl/FragmentLoaderCreator.java
changes/spoon/runAsync/user/src/com/google/gwt/core/client/AsyncFragmentLoader.java
Log:
Signal
Author: [EMAIL PROTECTED]
Date: Mon Oct 6 15:18:16 2008
New Revision: 3722
Added:
changes/bobv/clientbundle-3721/
- copied from r3721, /trunk/
Log:
Create a change branch for integrating ClientBundle into the trunk.
--~--~-~--~~~---~--~~
Author: [EMAIL PROTECTED]
Date: Mon Oct 6 13:52:32 2008
New Revision: 3719
Modified:
changes/jat/oophm-branch/plugins/xpcom/Makefile.mac
Log:
Mac port of recent changes.
Modified: changes/jat/oophm-branch/plugins/xpcom/Makefile.mac
On Mon, Oct 6, 2008 at 4:20 PM, Scott Blum [EMAIL PROTECTED] wrote:
How do you clean up dead refs in the entry method, which isn't part of any
class?
Good catch. It sounds like there is a more fundamental problem.
The runAsync entry methods actually are included in a class. Thus, in
some
Hey Alex,
Thanks for putting this fix together. Comments below:
DialogBox.java
199: Spelling: sceen -- screen
243: @Overrides on an a method that implements an interface only works in
Java 1.6. While GWT on the the trunk currently support JDK 1.6, the code
base still compiles under GWT 1.5. If
Author: [EMAIL PROTECTED]
Date: Mon Oct 6 11:49:45 2008
New Revision: 3717
Modified:
trunk/build-tools/ant-gwt/src/com/google/gwt/ant/taskdefs/SvnInfo.java
Log:
Fix SvnInfo to handle a non-svn workspace: can't deduce the version
available, but it won't stop the build either.
Patch by:
Hey Emily,
Is there a use case when a ValidatorController will hold different
types of Subjects and Validators or can I assume that
ValidatorController is generic and the generic type will be the same
in Validators and Subjects?
Regards,
Arthur Kalmenson
On Oct 6, 12:20 pm, Emily Crutcher
That seems like a reasonable approach.. it was always a bit weird to have a
method with no containing class. I'd look
at com.google.gwt.lang.ClassLiteralHolder as a template for this idea. In
fact, you might be able to get rid of JProgram.entryMethods in favor of an
entry class.
On Mon, Oct 6,
Author: [EMAIL PROTECTED]
Date: Mon Oct 6 17:10:48 2008
New Revision: 3723
Modified:
changes/jat/oophm-branch/dev/core/src/com/google/gwt/dev/GWTShell.java
Log:
Correct the launch URL in the case of a pre-existing query parameter.
Modified:
32 matches
Mail list logo
