[gwt-contrib] Re: auto-deploy GWT on maven repo ?
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]> wrote: > If this is done, please make sure that the conventions adhere to the > gwt-mavenplugin's repo layout. This allows you to use themaven-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 a GWT_HOME environment > variable. > > I use this in my build process which allows Chronoscope to build clean > on an empty computer with only Java andMaveninstalled and no other > prerequisites or reliance on absolute file system paths. This allows > us to startup a VMWare instant with an OS of our choice, and have it > build and test out of the box with virtually no configuration needed. > > -Ray > > On Thu, Nov 20, 2008 at 2:09 PM, nicolas.deloof > > <[EMAIL PROTECTED]> wrote: > > > I was considering only releases, as google-maven-repository has a > > rsync to publish onmavencentral > > 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 things like nightlies, or just full releases? > > >> On Wed, Nov 19, 2008 at 11:12 AM, nicolas.deloof > >> <[EMAIL PROTECTED]>wrote: > > >> > Hi, > > >> > As amavendevelopper, I have contributed the central repository with > >> > gwt artifacts. I now GWT team doesn't want to usemavenas build > >> > system, and I'm fine with this. I'm not here to try changing your > >> > choice. > > >> > I just would like the build script to support deploying the GWT > >> > artifacts to amavenrepo (there is one dedicated to google projects > >> > athttp://code.google.com/p/google-maven-repository/). I did this > >> > manually myself for 1.5.x versions, but a more automated deployment > >> > would be nice. > > >> > What's your opinion ? --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: Use LazyPanel in showcase
LGTM http://codereview.appspot.com/9656 --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: RR : Pluggable CompilePerms workers
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 actually passes a corresponding set of result files into the PWF. This prevents having to do the temp-file-then-copy trick with CompilePerms. I still want to go back at some point and implement the "generic file-backed serializable thing" concept which would make this even cleaner. - Fixed a few bugs. - We ended up going with Lex's ThreadPoolExecutor stuff. Mainly because he was physically here, and I think both of the TPE-based implementations suck. :) Tomorrow we need to check the build machine for a successful 1.6 build, and then merge up to trunk so you can merge in SOYC. Scott --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: RR : Pluggable CompilePerms workers
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 little simplification helps. Instead of each task being a manager that itself reads from a queue of permutations to work on, each task is itself a permutation. There is a separate list of workers that are not currently in use. Advantages are: there is no more explicit use of synchronized, no more wait and notify calls, and no more need to use the interrupted flag on Java threads. Let's get this all merged together, now. Lex --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~--- PermutationWorkerFactory.java Description: Binary data diffFromBobs.patch Description: Binary data
[gwt-contrib] [google-web-toolkit commit] r4144 - branches/1_6_datepicker/user/src/com/google/gwt/user/datepicker/client
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 order to allow subclasses to completely override showDate() if
they want, making refreshAll protected.
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/DatePicker.java
(original)
+++
branches/1_6_datepicker/user/src/com/google/gwt/user/datepicker/client/DatePicker.java
Thu Nov 20 14:50:49 2008
@@ -292,12 +292,13 @@
}
/**
- * Gets the currently shown date.
+ * Returns the first shown date.
*
- * @return the current date shown
+ * @return the first date.
*/
- public Date getDateShown() {
-return getModel().getCurrentMonth();
+ // Final because the view should always control the value of the first
date.
+ public final Date getFirstDate() {
+return view.getFirstDate();
}
/**
@@ -320,6 +321,16 @@
}
/**
+ * Returns the last shown date.
+ *
+ * @return the last date.
+ */
+ // Final because the view should always control the value of the last
date.
+ public final Date getLastDate() {
+return view.getLastDate();
+ }
+
+ /**
* Gets the [EMAIL PROTECTED] DatePicker}'s value.
*
* @return the value
@@ -441,11 +452,13 @@
}
/**
- * Shows the given date.
+ * Shows the given date, use [EMAIL PROTECTED] #getFirstDate()} and
+ * [EMAIL PROTECTED] #getLastDate()} to access the exact date range the date
picker
chose
+ * to display.
*
* @param date the date to show
*/
- public final void showDate(Date date) {
+ public void showDate(Date date) {
getModel().setCurrentMonth(date);
refreshAll();
}
@@ -478,6 +491,17 @@
}
/**
+ * Refreshes all components of this date picker.
+ */
+ protected final void refreshAll() {
+highlighted = null;
+getModel().refresh();
+getView().refresh();
+getMonthSelector().refresh();
+ShowRangeEvent.fire(this, getFirstDate(), getLastDate());
+ }
+
+ /**
* Sets up the date picker.
*/
protected void setup() {
@@ -497,18 +521,6 @@
*/
final StandardCss css() {
return css;
- }
-
- /**
- * Refreshes all components of this date picker.
- */
- final void refreshAll() {
-highlighted = null;
-getModel().refresh();
-getView().refresh();
-getMonthSelector().refresh();
-ShowRangeEvent.fire(this, getView().getFirstDate(),
-getView().getLastDate());
}
/**
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---
[gwt-contrib] [google-web-toolkit commit] r4143 - releases/1.6
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-info.txt(original) +++ releases/1.6/branch-info.txtThu Nov 20 14:23:18 2008 @@ -6,18 +6,13 @@ /releases/1.6/ was created (r3732) as a straight copy from /trunk/@r3683 Merges: -/trunk revisions c3688,c3703,c3700,c3704,c3707,c3715,c3717,c3724,3725 were merged (r3739) into this branch +/trunk revisions c3688,c3703,c3700,c3704,c3707,c3715,c3717,c3724,c3725 were merged (r3739) into this branch /releases/1.5/@r3630:3863 was merged (r3864) into this branch /releases/1.6/@r3739:3876 was merged (r3877) into trunk /releases/1.6/@r3878:3944 was merged (r3945) into trunk, skipping c3878 /releases/1.6/@r3944:4025 was merged (r4032) into trunk /branches/[EMAIL PROTECTED]:4088 was merged (r4092) into this branch /releases/1.5/@r3863:4093 was merged (r4134) into this branch +/releases/1.6/@r4025:4130 was merged (r4142) into trunk, superceding trunk:c4118 > The next merge into trunk will be 4025:HEAD; however there will be great conflict between trunk:c4118 and this branch's c4120. Highly suggested that the next merge to trunk "roll-back" c4118 in trunk before merging in 1.6. - -In trunk: - svn merge -c-4118 https://google-web-toolkit.googlecode.com/svn/trunk . - svn merge -r4025: https://google-web-toolkit.googlecode.com/svn/releases/1.6 . - -<--- +---> The next merge into trunk will be 4130: --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: auto-deploy GWT on maven repo ?
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 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 a GWT_HOME environment > variable. > > I use this in my build process which allows Chronoscope to build clean > on an empty computer with only Java and Maven installed and no other > prerequisites or reliance on absolute file system paths. This allows > us to startup a VMWare instant with an OS of our choice, and have it > build and test out of the box with virtually no configuration needed. > > -Ray > --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: auto-deploy GWT on maven repo ?
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 handling infrastructure, meaning that other Maven enabled products like JetBrain's TeamCity continuous integration server, or some IDEs, won't deal coherently with the outputs of the tests. -Ray On Thu, Nov 20, 2008 at 2:15 PM, Ray Cromwell <[EMAIL PROTECTED]> wrote: > 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 a GWT_HOME environment > variable. > > I use this in my build process which allows Chronoscope to build clean > on an empty computer with only Java and Maven installed and no other > prerequisites or reliance on absolute file system paths. This allows > us to startup a VMWare instant with an OS of our choice, and have it > build and test out of the box with virtually no configuration needed. > > -Ray > > On Thu, Nov 20, 2008 at 2:09 PM, nicolas.deloof > <[EMAIL PROTECTED]> wrote: >> >> 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 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, and I'm fine with this. I'm not here to try changing your >>> > choice. >>> >>> > I just would like the build script to support deploying the GWT >>> > artifacts to a maven repo (there is one dedicated to google projects >>> > athttp://code.google.com/p/google-maven-repository/). I did this >>> > manually myself for 1.5.x versions, but a more automated deployment >>> > would be nice. >>> >>> > What's your opinion ? >> >> >> > --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: auto-deploy GWT on maven repo ?
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 a GWT_HOME environment variable. I use this in my build process which allows Chronoscope to build clean on an empty computer with only Java and Maven installed and no other prerequisites or reliance on absolute file system paths. This allows us to startup a VMWare instant with an OS of our choice, and have it build and test out of the box with virtually no configuration needed. -Ray On Thu, Nov 20, 2008 at 2:09 PM, nicolas.deloof <[EMAIL PROTECTED]> wrote: > > 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 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, and I'm fine with this. I'm not here to try changing your >> > choice. >> >> > I just would like the build script to support deploying the GWT >> > artifacts to a maven repo (there is one dedicated to google projects >> > athttp://code.google.com/p/google-maven-repository/). I did this >> > manually myself for 1.5.x versions, but a more automated deployment >> > would be nice. >> >> > What's your opinion ? > > > --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] [google-web-toolkit] [EMAIL PROTECTED] commented on revision r4138.
[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 at http://code.google.com/p/google-web-toolkit/source/detail?r=4138 -- You received this message because you starred this review, or because your project has directed all notifications to a mailing list that you subscribe to. You may adjust your review notification preferences at: http://code.google.com/hosting/settings --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: auto-deploy GWT on maven repo ?
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 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, and I'm fine with this. I'm not here to try changing your > > choice. > > > I just would like the build script to support deploying the GWT > > artifacts to a maven repo (there is one dedicated to google projects > > athttp://code.google.com/p/google-maven-repository/). I did this > > manually myself for 1.5.x versions, but a more automated deployment > > would be nice. > > > What's your opinion ? --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] [google-web-toolkit commit] r4141 - branches/1_6_datepicker/user/src/com/google/gwt/user/datepicker/client
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_datepicker/user/src/com/google/gwt/user/datepicker/client/DatePicker.java
==
---
branches/1_6_datepicker/user/src/com/google/gwt/user/datepicker/client/DatePicker.java
(original)
+++
branches/1_6_datepicker/user/src/com/google/gwt/user/datepicker/client/DatePicker.java
Thu Nov 20 14:08:19 2008
@@ -427,10 +427,10 @@
* @param fireEvents should events be fired.
*/
public final void setValue(Date newValue, boolean fireEvents) {
-Date oldSelected = value;
+Date oldValue = value;
-if (oldSelected != null) {
- removeGlobalStyleFromDate(oldSelected, css().dayIsValue());
+if (oldValue != null) {
+ removeGlobalStyleFromDate(oldValue, css().dayIsValue());
}
value = CalendarUtil.copyDate(newValue);
@@ -504,6 +504,7 @@
*/
final void refreshAll() {
highlighted = null;
+getModel().refresh();
getView().refresh();
getMonthSelector().refresh();
ShowRangeEvent.fire(this, getView().getFirstDate(),
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---
[gwt-contrib] Re: RR (Incubator): Fix for CssResourceGenerator ImageResource Method lookups
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 -~--~~~~--~~--~--~---
[gwt-contrib] Re: RR (Incubator): Fix for CssResourceGenerator ImageResource Method lookups
LGTM -- Bob Vawter Google Web Toolkit Team --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] [google-web-toolkit commit] r4140 - branches/1_6_datepicker/user/src/com/google/gwt/user/datepicker/client
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/user/src/com/google/gwt/user/datepicker/client/DatePicker.java
==
---
branches/1_6_datepicker/user/src/com/google/gwt/user/datepicker/client/DatePicker.java
(original)
+++
branches/1_6_datepicker/user/src/com/google/gwt/user/datepicker/client/DatePicker.java
Thu Nov 20 14:04:16 2008
@@ -28,7 +28,6 @@
import com.google.gwt.user.client.ui.Composite;
import com.google.gwt.user.client.ui.FlowPanel;
import com.google.gwt.user.client.ui.HasValue;
-import com.google.gwt.user.client.ui.Widget;
import java.util.Date;
import java.util.HashMap;
@@ -236,7 +235,7 @@
public void addGlobalStyleToDate(Date date, String styleName) {
styler.setStyleName(date, styleName, true);
if (isDateVisible(date)) {
- view.addStyleToDate(date, styleName);
+ getView().addStyleToDate(date, styleName);
}
}
@@ -257,8 +256,8 @@
*/
public HandlerRegistration addShowRangeHandlerAndFire(
ShowRangeHandler handler) {
-ShowRangeEvent event = new ShowRangeEvent(view.getFirstDate(),
-view.getLastDate()) {
+ShowRangeEvent event = new ShowRangeEvent(getView().getFirstDate(),
+getView().getLastDate()) {
};
handler.onShowRange(event);
return addShowRangeHandler(handler);
@@ -272,7 +271,7 @@
* @param styleName style name
*/
public final void addStyleToVisibleDate(Date visibleDate, String
styleName) {
-view.addStyleToDate(visibleDate, styleName);
+getView().addStyleToDate(visibleDate, styleName);
}
/**
@@ -336,7 +335,7 @@
* @return is the date currently shown
*/
public boolean isDateVisible(Date date) {
-return view.isDateVisible(date);
+return getView().isDateVisible(date);
}
/**
@@ -347,7 +346,7 @@
*/
public boolean isVisibleDateEnabled(Date date) {
assert isDateVisible(date) : date + " is not visible";
-return view.isDateEnabled(date);
+return getView().isDateEnabled(date);
}
/**
@@ -359,7 +358,7 @@
public void removeGlobalStyleFromDate(Date date, String styleName) {
styler.setStyleName(date, styleName, false);
if (isDateVisible(date)) {
- view.removeStyleFromDate(date, styleName);
+ getView().removeStyleFromDate(date, styleName);
}
}
@@ -374,7 +373,7 @@
while (dates.hasNext()) {
Date date = dates.next();
assert (isDateVisible(date)) : date + " should be visible";
- view.removeStyleFromDate(date, styleName);
+ getView().removeStyleFromDate(date, styleName);
}
}
@@ -465,7 +464,7 @@
*
* @return the month selector
*/
- protected final Widget getMonthSelector() {
+ protected final MonthSelector getMonthSelector() {
return monthSelector;
}
@@ -505,8 +504,8 @@
*/
final void refreshAll() {
highlighted = null;
-view.refresh();
-monthSelector.refresh();
+getView().refresh();
+getMonthSelector().refresh();
ShowRangeEvent.fire(this, getView().getFirstDate(),
getView().getLastDate());
}
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---
[gwt-contrib] [google-web-toolkit commit] r4139 - branches/1_6_datepicker/user/src/com/google/gwt/user/datepicker/client
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" blurb.
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/DatePicker.java
(original)
+++
branches/1_6_datepicker/user/src/com/google/gwt/user/datepicker/client/DatePicker.java
Thu Nov 20 13:55:58 2008
@@ -202,20 +202,20 @@
}
/**
- * Constructor for use by subType()s.
+ * Creates a new date picker.
*
* @param monthSelector the month selector
- * @param calendarView the view view
- * @param model the view model
+ * @param view the view
+ * @param model the model
*/
- protected DatePicker(MonthSelector monthSelector, CalendarView
calendarView,
+ protected DatePicker(MonthSelector monthSelector, CalendarView view,
CalendarModel model) {
this.model = model;
this.monthSelector = monthSelector;
monthSelector.setDatePicker(this);
-this.view = calendarView;
+this.view = view;
view.setDatePicker(this);
view.setup();
@@ -415,10 +415,10 @@
/**
* Sets the [EMAIL PROTECTED] DatePicker}'s value.
*
- * @param date the new value
+ * @param newValue the new value
*/
- public final void setValue(Date date) {
-setValue(date, true);
+ public final void setValue(Date newValue) {
+setValue(newValue, true);
}
/**
@@ -472,7 +472,7 @@
/**
* Gets the [EMAIL PROTECTED] CalendarView} associated with this date
picker.
*
- * @return view view
+ * @return the view
*/
protected final CalendarView getView() {
return view;
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---
[gwt-contrib] [google-web-toolkit] [EMAIL PROTECTED] commented on revision r4138.
[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 getView() throughout, especially since it's protected. Sometimes you do, sometimes you don't. Otherwise should make the method final. Both getView() and getMonthSelector() are final actually, and yep, I have that on my list, trying to keep the review burden down for individual commits. This one was for finals and renaming only. Respond to these comments at http://code.google.com/p/google-web-toolkit/source/detail?r=4138 -- You received this message because you starred this review, or because your project has directed all notifications to a mailing list that you subscribe to. You may adjust your review notification preferences at: http://code.google.com/hosting/settings --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] [google-web-toolkit] [EMAIL PROTECTED] commented on revision r4138.
[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) === Line 209:* @param model the view model --- Typos here, need to delete "view" from both lines Line 377: view.removeStyleFromDate(date, styleName); --- should be calling getView() throughout, especially since it's protected. Sometimes you do, sometimes you don't. Otherwise should make the method final. Line 509: monthSelector.refresh(); --- Ditto getMonthSelector() instead of monthSelector Respond to these comments at http://code.google.com/p/google-web-toolkit/source/detail?r=4138 -- You received this message because you starred this review, or because your project has directed all notifications to a mailing list that you subscribe to. You may adjust your review notification preferences at: http://code.google.com/hosting/settings --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] [google-web-toolkit commit] r4138 - branches/1_6_datepicker/user/src/com/google/gwt/user/datepicker/client
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/google/gwt/user/datepicker/client/DatePicker.java
==
---
branches/1_6_datepicker/user/src/com/google/gwt/user/datepicker/client/DatePicker.java
(original)
+++
branches/1_6_datepicker/user/src/com/google/gwt/user/datepicker/client/DatePicker.java
Thu Nov 20 13:27:49 2008
@@ -185,16 +185,16 @@
}
}
- private DateStyler styler = new DateStyler();
- private Date highlightedDate;
- private MonthSelector monthSelector;
- private CalendarView calendar;
- private CalendarModel model;
+ private final DateStyler styler = new DateStyler();
+ private final MonthSelector monthSelector;
+ private final CalendarView view;
+ private final CalendarModel model;
private Date value;
+ private Date highlighted;
private StandardCss css = StandardCss.DEFAULT;
/**
- * Constructor.
+ * Create a new date picker.
*/
public DatePicker() {
this(new DefaultMonthSelector(), new DefaultCalendarView(),
@@ -205,20 +205,23 @@
* Constructor for use by subType()s.
*
* @param monthSelector the month selector
- * @param calendarView the calendar view
- * @param model the calendar model
+ * @param calendarView the view view
+ * @param model the view model
*/
protected DatePicker(MonthSelector monthSelector, CalendarView
calendarView,
CalendarModel model) {
-this.setModel(model);
+
+this.model = model;
this.monthSelector = monthSelector;
monthSelector.setDatePicker(this);
-this.calendar = calendarView;
-calendar.setDatePicker(this);
-calendar.setup();
+this.view = calendarView;
+view.setDatePicker(this);
+
+view.setup();
monthSelector.setup();
this.setup();
+
showDate(new Date());
addGlobalStyleToDate(new Date(), css().dayIsToday());
}
@@ -233,7 +236,7 @@
public void addGlobalStyleToDate(Date date, String styleName) {
styler.setStyleName(date, styleName, true);
if (isDateVisible(date)) {
- calendar.addStyleToDate(date, styleName);
+ view.addStyleToDate(date, styleName);
}
}
@@ -247,15 +250,15 @@
/**
* Adds a show range handler and immediately activate the handler on the
- * current calendar view.
+ * current view.
*
* @param handler the handler
* @return the handler registration
*/
public HandlerRegistration addShowRangeHandlerAndFire(
ShowRangeHandler handler) {
-ShowRangeEvent event = new ShowRangeEvent(calendar.getFirstDate(),
-calendar.getLastDate()) {
+ShowRangeEvent event = new ShowRangeEvent(view.getFirstDate(),
+view.getLastDate()) {
};
handler.onShowRange(event);
return addShowRangeHandler(handler);
@@ -269,7 +272,7 @@
* @param styleName style name
*/
public final void addStyleToVisibleDate(Date visibleDate, String
styleName) {
-calendar.addStyleToDate(visibleDate, styleName);
+view.addStyleToDate(visibleDate, styleName);
}
/**
@@ -281,7 +284,7 @@
*/
public final void addStyleToVisibleDates(Iterable visibleDates,
String styleName) {
-getCalendarView().addStyleToDates(visibleDates, styleName);
+getView().addStyleToDates(visibleDates, styleName);
}
public HandlerRegistration addValueChangeHandler(
@@ -314,7 +317,7 @@
* @return the highlighted date
*/
public final Date getHighlightedDate() {
-return highlightedDate;
+return highlighted;
}
/**
@@ -333,7 +336,7 @@
* @return is the date currently shown
*/
public boolean isDateVisible(Date date) {
-return calendar.isDateVisible(date);
+return view.isDateVisible(date);
}
/**
@@ -344,7 +347,7 @@
*/
public boolean isVisibleDateEnabled(Date date) {
assert isDateVisible(date) : date + " is not visible";
-return calendar.isDateEnabled(date);
+return view.isDateEnabled(date);
}
/**
@@ -356,7 +359,7 @@
public void removeGlobalStyleFromDate(Date date, String styleName) {
styler.setStyleName(date, styleName, false);
if (isDateVisible(date)) {
- calendar.removeStyleFromDate(date, styleName);
+ view.removeStyleFromDate(date, styleName);
}
}
@@ -371,7 +374,7 @@
while (dates.hasNext()) {
Date date = dates.next();
assert (isDateVisible(date)) : date + " should be visible";
- calendar.removeStyleFromDate(date, styleName);
+ view.removeStyleFromDate(date, styleName);
}
}
@@ -385,7 +388,7 @@
public final void setEnabledOnVisibleDate(Date date, boolean enabled) {
assert isDateVisible(date) : date
[gwt-contrib] Comment on TableOfContents in google-web-toolkit
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 -~--~~~~--~~--~--~---
[gwt-contrib] Fwd: [gwt-contrib] [google-web-toolkit commit] r4137 - releases/1.6/user/javadoc/com/google/gwt/examples
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: [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/LazyPanelExample.java
==
--- (empty file)
+++ releases/1.6/user/javadoc/com/google/gwt/examples/LazyPanelExample.java
Thu Nov 20 13:14:33 2008
@@ -0,0 +1,54 @@
+/*
+ * Copyright 2008 Google Inc.
+ *
+ * Licensed under the Apache License, Version 2.0 (the "License"); you may
not
+ * use this file except in compliance with the License. You may obtain a
copy of
+ * the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
WITHOUT
+ * WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the
+ * License for the specific language governing permissions and limitations
under
+ * the License.
+ */
+package com.google.gwt.examples;
+
+import com.google.gwt.core.client.EntryPoint;
+import com.google.gwt.event.dom.client.ClickEvent;
+import com.google.gwt.event.dom.client.ClickHandler;
+import com.google.gwt.user.client.ui.Label;
+import com.google.gwt.user.client.ui.LazyPanel;
+import com.google.gwt.user.client.ui.PushButton;
+import com.google.gwt.user.client.ui.RootPanel;
+import com.google.gwt.user.client.ui.Widget;
+
+public class LazyPanelExample implements EntryPoint {
+
+ /**
+ * A friendly little LazyPanel.
+ */
+ static class HelloLazy extends LazyPanel {
+@Override
+protected Widget createWidget() {
+ return new Label("Well hello there!");
+}
+ }
+
+ public void onModuleLoad() {
+final Widget lazy = new HelloLazy();
+lazy.setVisible(false);
+
+PushButton b = new PushButton("Click me");
+b.addClickHandler(new ClickHandler() {
+ public void onClick(ClickEvent event) {
+lazy.setVisible(true);
+ }
+});
+
+RootPanel root = RootPanel.get();
+root.add(b);
+root.add(lazy);
+ }
+}
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---
[gwt-contrib] [google-web-toolkit commit] r4137 - releases/1.6/user/javadoc/com/google/gwt/examples
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/LazyPanelExample.java
==
--- (empty file)
+++ releases/1.6/user/javadoc/com/google/gwt/examples/LazyPanelExample.java
Thu Nov 20 13:14:33 2008
@@ -0,0 +1,54 @@
+/*
+ * Copyright 2008 Google Inc.
+ *
+ * Licensed under the Apache License, Version 2.0 (the "License"); you may
not
+ * use this file except in compliance with the License. You may obtain a
copy of
+ * the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
WITHOUT
+ * WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the
+ * License for the specific language governing permissions and limitations
under
+ * the License.
+ */
+package com.google.gwt.examples;
+
+import com.google.gwt.core.client.EntryPoint;
+import com.google.gwt.event.dom.client.ClickEvent;
+import com.google.gwt.event.dom.client.ClickHandler;
+import com.google.gwt.user.client.ui.Label;
+import com.google.gwt.user.client.ui.LazyPanel;
+import com.google.gwt.user.client.ui.PushButton;
+import com.google.gwt.user.client.ui.RootPanel;
+import com.google.gwt.user.client.ui.Widget;
+
+public class LazyPanelExample implements EntryPoint {
+
+ /**
+ * A friendly little LazyPanel.
+ */
+ static class HelloLazy extends LazyPanel {
+@Override
+protected Widget createWidget() {
+ return new Label("Well hello there!");
+}
+ }
+
+ public void onModuleLoad() {
+final Widget lazy = new HelloLazy();
+lazy.setVisible(false);
+
+PushButton b = new PushButton("Click me");
+b.addClickHandler(new ClickHandler() {
+ public void onClick(ClickEvent event) {
+lazy.setVisible(true);
+ }
+});
+
+RootPanel root = RootPanel.get();
+root.add(b);
+root.add(lazy);
+ }
+}
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---
[gwt-contrib] Re: auto-deploy GWT on maven repo ?
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, and I'm fine with this. I'm not here to try changing your > choice. > > I just would like the build script to support deploying the GWT > artifacts to a maven repo (there is one dedicated to google projects > at http://code.google.com/p/google-maven-repository/). I did this > manually myself for 1.5.x versions, but a more automated deployment > would be nice. > > What's your opinion ? > > > > --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: RR : Pluggable CompilePerms workers
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 ahead and start working, without waiting for the last JVM to start. -Lex --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] [google-web-toolkit commit] r4136 - releases/1.6
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 == --- releases/1.6/branch-info.txt(original) +++ releases/1.6/branch-info.txtThu Nov 20 12:46:28 2008 @@ -12,7 +12,7 @@ /releases/1.6/@r3878:3944 was merged (r3945) into trunk, skipping c3878 /releases/1.6/@r3944:4025 was merged (r4032) into trunk /branches/[EMAIL PROTECTED]:4088 was merged (r4092) into this branch -/releases/1.5/@r3863:4093 was merged (r) into this branch +/releases/1.5/@r3863:4093 was merged (r4134) into this branch ---> The next merge into trunk will be 4025:HEAD; however there will be great conflict between trunk:c4118 and this branch's c4120. Highly suggested that the next merge to trunk "roll-back" c4118 in trunk before merging in 1.6. --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] [google-web-toolkit commit] r4135 - in branches/1_6_datepicker/user/src/com/google/gwt/user: datepicker/client theme/standard...
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_6_datepicker/user/src/com/google/gwt/user/theme/standard/public/gwt/standard/standard.css
Log:
Using value rather then selected terminology.
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/DatePicker.java
(original)
+++
branches/1_6_datepicker/user/src/com/google/gwt/user/datepicker/client/DatePicker.java
Thu Nov 20 12:45:19 2008
@@ -80,16 +80,16 @@
return day("Highlighted");
}
-public String dayIsSelected() {
- return day("Selected");
+public String dayIsToday() {
+ return day("Today");
}
-public String dayIsSelectedAndHighlighted() {
- return dayIsSelected() + "AndHighlighted";
+public String dayIsValue() {
+ return day("Value");
}
-public String dayIsToday() {
- return day("Today");
+public String dayIsValueAndHighlighted() {
+ return dayIsValue() + "AndHighlighted";
}
public String dayIsWeekend() {
@@ -190,7 +190,7 @@
private MonthSelector monthSelector;
private CalendarView calendar;
private CalendarModel model;
- private Date selectedDate;
+ private Date value;
private StandardCss css = StandardCss.DEFAULT;
/**
@@ -202,7 +202,7 @@
}
/**
- * Constructor for use by subgetType()s.
+ * Constructor for use by subType()s.
*
* @param monthSelector the month selector
* @param calendarView the calendar view
@@ -318,12 +318,12 @@
}
/**
- * Gets the selected date, if any.
+ * Gets the [EMAIL PROTECTED] DatePicker}'s value.
*
- * @return the selected date
+ * @return the value
*/
public final Date getValue() {
-return selectedDate;
+return value;
}
/**
@@ -376,13 +376,6 @@
}
/**
- * Selects the current highlighted date.
- */
- public final void selectHighlightedDate() {
-setValue(getHighlightedDate());
- }
-
- /**
* Sets a visible date to be enabled or disabled. This is only set until
the
* next time the DatePicker is refreshed.
*
@@ -417,32 +410,32 @@
}
/**
- * Sets the selected date.
+ * Sets the [EMAIL PROTECTED] DatePicker}'s value.
*
- * @param date the new selected date
+ * @param date the new value
*/
public final void setValue(Date date) {
setValue(date, true);
}
/**
- * Sets the selected date.
+ * Sets the [EMAIL PROTECTED] DatePicker}'s value.
*
- * @param newSelected the new selected date
+ * @param newValue the new value for this date picker
* @param fireEvents should events be fired.
*/
- public final void setValue(Date newSelected, boolean fireEvents) {
-Date oldSelected = selectedDate;
+ public final void setValue(Date newValue, boolean fireEvents) {
+Date oldSelected = value;
if (oldSelected != null) {
- removeGlobalStyleFromDate(oldSelected, css().dayIsSelected());
+ removeGlobalStyleFromDate(oldSelected, css().dayIsValue());
}
-selectedDate = CalendarUtil.copyDate(newSelected);
-if (selectedDate != null) {
- addGlobalStyleToDate(selectedDate, css().dayIsSelected());
+value = CalendarUtil.copyDate(newValue);
+if (value != null) {
+ addGlobalStyleToDate(value, css().dayIsValue());
}
-ValueChangeEvent.fire(this, newSelected);
+ValueChangeEvent.fire(this, newValue);
}
/**
Modified:
branches/1_6_datepicker/user/src/com/google/gwt/user/datepicker/client/DefaultCalendarView.java
==
---
branches/1_6_datepicker/user/src/com/google/gwt/user/datepicker/client/DefaultCalendarView.java
(original)
+++
branches/1_6_datepicker/user/src/com/google/gwt/user/datepicker/client/DefaultCalendarView.java
Thu Nov 20 12:45:19 2008
@@ -113,7 +113,7 @@
accum += " " + css().dayIsHighlighted();
if (isHighlighted() && isSelected()) {
-accum += " " + css().dayIsSelectedAndHighlighted();
+accum += " " + css().dayIsValueAndHighlighted();
}
}
if (!isEnabled()) {
Modified:
branches/1_6_datepicker/user/src/com/google/gwt/user/theme/standard/public/gwt/standard/standard.css
==
---
branches/1_6_datepicker/user/src/com/google/gwt/user/theme/standard/public/gwt/standard/standard.css
(original)
+++
branches/1_6_datepicker/user/src/com/google/gwt/user/theme/standard/public/gwt/standard/standard.
[gwt-contrib] TBR Code review: update 1.6 branch-info.txt
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:14:57 2008 New Revision: 4071 Modified: branches/1_6_clean_events/branch-info.txt Log: update branchinfo.txt w/previous up-integrate change number Modified: branches/1_6_clean_events/branch-info.txt == --- branches/1_6_clean_events/branch-info.txt (original) +++ branches/1_6_clean_events/branch-info.txt Thu Nov 13 17:14:57 2008 @@ -6,6 +6,6 @@ /branches/1_6_clean_events was created from /releases/[EMAIL PROTECTED] Merges: -/releases/[EMAIL PROTECTED]:3957 was merged () into this branch +/releases/[EMAIL PROTECTED]:3957 was merged (3963) into this branch -> The next merge into this branch will be r3957: --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] [google-web-toolkit commit] r4134 - in releases/1.6: . reference/dispatch reference/dispatch/client reference/dispatch/public
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/reference/dispatch/Dispatch.gwt.xml releases/1.6/reference/dispatch/client/ - copied from r4093, /releases/1.5/reference/dispatch/client/ releases/1.6/reference/dispatch/client/Dispatch.java - copied unchanged from r4093, /releases/1.5/reference/dispatch/client/Dispatch.java releases/1.6/reference/dispatch/client/Subject.java - copied unchanged from r4093, /releases/1.5/reference/dispatch/client/Subject.java releases/1.6/reference/dispatch/public/ - copied from r4093, /releases/1.5/reference/dispatch/public/ releases/1.6/reference/dispatch/public/Dispatch.html - copied unchanged from r4093, /releases/1.5/reference/dispatch/public/Dispatch.html Modified: releases/1.6/branch-info.txt Log: Integrate reference/dispatch from 1.5 Modified: releases/1.6/branch-info.txt == --- releases/1.6/branch-info.txt(original) +++ releases/1.6/branch-info.txtThu Nov 20 12:44:31 2008 @@ -12,6 +12,7 @@ /releases/1.6/@r3878:3944 was merged (r3945) into trunk, skipping c3878 /releases/1.6/@r3944:4025 was merged (r4032) into trunk /branches/[EMAIL PROTECTED]:4088 was merged (r4092) into this branch +/releases/1.5/@r3863:4093 was merged (r) into this branch ---> The next merge into trunk will be 4025:HEAD; however there will be great conflict between trunk:c4118 and this branch's c4120. Highly suggested that the next merge to trunk "roll-back" c4118 in trunk before merging in 1.6. --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] [google-web-toolkit commit] r4133 - in releases/1.6/user: src/com/google/gwt/user/client/ui test/com/google/gwt/user test/com...
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/DisclosurePanel.java
releases/1.6/user/src/com/google/gwt/user/client/ui/TabPanel.java
releases/1.6/user/test/com/google/gwt/user/UISuite.java
releases/1.6/user/test/com/google/gwt/user/client/ui/CompositeTest.java
Log:
Hello, LazyPanel
Modified:
releases/1.6/user/src/com/google/gwt/user/client/ui/DisclosurePanel.java
==
---
releases/1.6/user/src/com/google/gwt/user/client/ui/DisclosurePanel.java
(original)
+++
releases/1.6/user/src/com/google/gwt/user/client/ui/DisclosurePanel.java
Thu Nov 20 12:42:23 2008
@@ -89,6 +89,10 @@
run(ANIMATION_DURATION);
} else {
panel.contentWrapper.setVisible(panel.isOpen);
+if (panel.isOpen) {
+ // Special treatment on the visible case to ensure LazyPanel
works
+ panel.getContent().setVisible(true);
+}
}
}
@@ -107,7 +111,9 @@
super.onStart();
if (opening) {
curPanel.contentWrapper.setVisible(true);
- }
+// Special treatment on the visible case to ensure LazyPanel works
+curPanel.getContent().setVisible(true);
+ }
}
@Override
Added: releases/1.6/user/src/com/google/gwt/user/client/ui/LazyPanel.java
==
--- (empty file)
+++ releases/1.6/user/src/com/google/gwt/user/client/ui/LazyPanel.java Thu
Nov 20 12:42:23 2008
@@ -0,0 +1,68 @@
+/*
+ * Copyright 2008 Google Inc.
+ *
+ * Licensed under the Apache License, Version 2.0 (the "License"); you may
not
+ * use this file except in compliance with the License. You may obtain a
copy of
+ * the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
WITHOUT
+ * WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the
+ * License for the specific language governing permissions and limitations
under
+ * the License.
+ */
+
+package com.google.gwt.user.client.ui;
+
+/**
+ * Convenience class to help lazy loading. The bulk of a LazyPanel is not
+ * instantiated until [EMAIL PROTECTED] #setVisible}(true) or [EMAIL
PROTECTED] #ensureWidget} is
+ * called.
+ *
+ * Example
+ * [EMAIL PROTECTED] com.google.gwt.examples.LazyPanelExample}
+ */
+public abstract class LazyPanel extends SimplePanel {
+
+ public LazyPanel() {
+ }
+
+ /**
+ * Create the widget contained within the [EMAIL PROTECTED] LazyPanel}.
+ *
+ * @return the lazy widget
+ */
+ protected abstract Widget createWidget();
+
+ /**
+ * Ensures that the widget has been created by calling [EMAIL PROTECTED]
#createWidget}
+ * if [EMAIL PROTECTED] #getWidget} returns null. Typically it
is not
+ * necessary to call this directly, as it is called as a side effect of a
+ * setVisible(true) call.
+ */
+ public void ensureWidget() {
+Widget widget = getWidget();
+if (widget == null) {
+ widget = createWidget();
+ setWidget(widget);
+}
+ }
+
+ @Override
+ /**
+ * Sets whether this object is visible. If visible is
+ * true, creates the sole child widget if necessary by
calling
+ * [EMAIL PROTECTED] #ensureWidget}.
+ *
+ * @param visible true to show the object,
false
+ * to hide it
+ */
+ public void setVisible(boolean visible) {
+if (visible) {
+ ensureWidget();
+}
+super.setVisible(visible);
+ }
+}
Modified: releases/1.6/user/src/com/google/gwt/user/client/ui/TabPanel.java
==
--- releases/1.6/user/src/com/google/gwt/user/client/ui/TabPanel.java
(original)
+++ releases/1.6/user/src/com/google/gwt/user/client/ui/TabPanel.java Thu
Nov 20 12:42:23 2008
@@ -42,9 +42,12 @@
* [EMAIL PROTECTED] com.google.gwt.user.client.ui.HasWidgets}.
*
*
- * CSS Style Rules .gwt-TabPanel { the tab
panel
- * itself } .gwt-TabPanelBottom { the bottom section of the tab
panel
- * (the deck containing the widget) }
+ * CSS Style Rules
+ *
+ * .gwt-TabPanel { the tab panel itself }
+ * .gwt-TabPanelBottom { the bottom section of the tab panel
+ * (the deck containing the widget) }
+ *
*
*
* Example
Modified: releases/1.6/user/test/com/google/gwt/user/UISuite.java
==
--- releases/1.6/user/test/com/google/gwt/user/UISuite.java (original)
+++ releases/1.6/user/test/com/google/gwt/user/UISuite.java Thu Nov 20
12:42:23 2008
@@ -47,6 +47,7 @@
[gwt-contrib] Re: RR: Code Review, copies LazyPanel to 1.6 from incubator
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 >> that. >> > > Sorry, somehow managed to lose the "if necessary" stanza the first time I > read it. Yes, that is perfectly clear. > >> >> >>> >>> *setVisible:* >>> I wonder if we should actually reverse the order, and call >>> super.setVisible() first? >> >> >> I can't really see why. I can imagine it being better to create the new >> widget before making it visible--my normal habit to avoid flicker, though >> that shouldn't be an issue here. >> > > Only potential problem is that if the new widget needs to calculate > height/width information, those will be wrong if it is currently wrapped in > a display none block. On the other hand, given that this is a new API, it > seems equality valid to just not allow that sort of code. > > Also, I assume you still know that you don't have a a LazyPanel example in > this review? > -- "There are only 10 types of people in the world: Those who understand binary, and those who don't" --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: UISuite test omissions: feature or bug?
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 < [EMAIL PROTECTED]> wrote: > 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 > one perhaps-more-important thing that I dropped the ball on: > There appear to be several GWTTestCase classes in UISuite's package space, > which are not actually in UISuite's enumeration of test classes to add to > the suite (and thus aren't being exercised). Feature or bug? > > The classes are: > > PasswordTextBoxTest > RandomTest > TextBoxTest > > > I can't see any particular reason the tests shouldn't be run, I think they > actually pass; should they be included? > > And having gone that far, let me reprise the patch I sent Joel. Note that > the change provoked some legit latent faults in various tests, and also > provoked some not-yet-explained test failures in DOMSuite and I think > TreeTest, so there's still some work to do if we think the package-add > function is useful. Regardless, we should decide how to handle the three > orphan tests above. > > > > > > > > --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: RR: Code Review, copies LazyPanel to 1.6 from incubator
> > 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, that is perfectly clear. > > >> >> *setVisible:* >> I wonder if we should actually reverse the order, and call >> super.setVisible() first? > > > I can't really see why. I can imagine it being better to create the new > widget before making it visible--my normal habit to avoid flicker, though > that shouldn't be an issue here. > Only potential problem is that if the new widget needs to calculate height/width information, those will be wrong if it is currently wrapped in a display none block. On the other hand, given that this is a new API, it seems equality valid to just not allow that sort of code. Also, I assume you still know that you don't have a a LazyPanel example in this review? --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] [google-web-toolkit] [EMAIL PROTECTED] commented on revision r4132.
[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 DatePickerComponent, as all user code should either be extending month selector or calendar view. Respond to these comments at http://code.google.com/p/google-web-toolkit/source/detail?r=4132 -- You received this message because you starred this review, or because your project has directed all notifications to a mailing list that you subscribe to. You may adjust your review notification preferences at: http://code.google.com/hosting/settings --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] [google-web-toolkit] [EMAIL PROTECTED] commented on revision r4132.
[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)
===
Line 54: public StandardCss(String widgetName, String baseName) {
---
Why still public?
Line 145: protected String wrap(String style) {
---
protected?
Line 528: private void setModel(CalendarModel model) {
---
should just inline this method and make model final
File:
/branches/1_6_datepicker/user/src/com/google/gwt/user/datepicker/client/DatePickerComponent.java
(r4132)
===
Line 26: abstract class DatePickerComponent extends Composite {
---
You just explained to me that MonthSelector being public makes sense
because it inherits functionality from here. Doesn't this class need to be
public?
Respond to these comments at
http://code.google.com/p/google-web-toolkit/source/detail?r=4132
--
You received this message because you starred this review, or because
your project has directed all notifications to a mailing list that you
subscribe to.
You may adjust your review notification preferences at:
http://code.google.com/hosting/settings
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---
[gwt-contrib] Re: Proposal: Add "Constants" and "Message" resources to ImmutableResourceBundle
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 type.
>
> In the simplest case, you could define a new resource type that just
> returns an instance of a Messages or Constants.
>
> @ResourceGenerator(MessageResourceGenerator.class)
> interface MessageResource extends ResourcePrototype {
> public T get();
>
> }
But how do I get all the annotation magic from the i18n Message or
Constant generation?
Once I have time I'll dig into all of this.
> On Thu, Nov 20, 2008 at 2:38 PM, dflorey <[EMAIL PROTECTED]> wrote:
> > BTW: Does ImmutableResourceBundle i18n work for ImageResources?
>
> It should. If it doesn't, that's a bug.
>
> --
> Bob Vawter
> Google Web Toolkit Team
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---
[gwt-contrib] RR (Incubator): Fix for CssResourceGenerator ImageResource Method lookups
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 trunk: src/com/google/gwt/libideas/resources/rg/CssResourceGenerator.java -Jaime --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~--- CssResourceGenerator_fix.patch Description: Binary data
[gwt-contrib] Re: Proposal: Add "Constants" and "Message" resources to ImmutableResourceBundle
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 resource type that just
returns an instance of a Messages or Constants.
@ResourceGenerator(MessageResourceGenerator.class)
interface MessageResource extends ResourcePrototype {
public T get();
}
On Thu, Nov 20, 2008 at 2:38 PM, dflorey <[EMAIL PROTECTED]> wrote:
> BTW: Does ImmutableResourceBundle i18n work for ImageResources?
It should. If it doesn't, that's a bug.
--
Bob Vawter
Google Web Toolkit Team
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---
[gwt-contrib] Re: RR : Pluggable CompilePerms workers
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 down, but maybe there's nothing better. 2. Check how Scala deals with finding the Java VM to run. I think it's the same way as is used here. Things for you to do, Bob, by my notes: 1. When starting a permutation daemon, give it a cookie to send back on the socket it uses to connect to the worker manager. That way, the manager knows it is talking to a daemon it itself spawned, and not some attacker. 2. When reading stdout and stderr from a spawned thread, make two reader threads instead of just one. This improves the hypothetical case where stdout has a lot of output but stderr has nothing, or vice versa. 3. (maybe) Add a system property for the arguments to pass to Java when starting it. This would be an escape hatch in case copying the current JVM's arguments does not work in some weird context. Also, there's a debate around the office about calling System.gc(). It can speed things up in theory, but it can decrease performance heavily in some contexts. So, it's a bit of a landmine at the best of times. Maybe we should avoid using it until we have a better evidence that it improves things. -Lex --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] [google-web-toolkit commit] r4132 - branches/1_6_datepicker/user/src/com/google/gwt/user/datepicker/client
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
branches/1_6_datepicker/user/src/com/google/gwt/user/datepicker/client/DatePickerComponent.java
Log:
Removing all public mentions of any css class. Removing Css interface and
StandardCssImpl altogether. As of now, StandardCss is only being used as a
convenience class for internal usage.
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/DatePicker.java
(original)
+++
branches/1_6_datepicker/user/src/com/google/gwt/user/datepicker/client/DatePicker.java
Thu Nov 20 11:38:45 2008
@@ -42,14 +42,18 @@
HasHighlightHandlers, HasShowRangeHandlers, HasValue
{
/**
- * Convenience class to group css handling code.
+ * Convenience class to group css style names.
*/
- static class StandardCss extends StandardCssImpl implements
DatePicker.Css {
+ static class StandardCss {
-static DatePicker.Css DEFAULT = new
StandardCss("gwt-DatePicker", "datePicker");
+static StandardCss DEFAULT = new
StandardCss("gwt-DatePicker", "datePicker");
-public StandardCss(String widgetName, String baseStyleName) {
- super(widgetName, baseStyleName);
+private String baseName;
+private String widgetName;
+
+public StandardCss(String widgetName, String baseName) {
+ this.widgetName = widgetName;
+ this.baseName = baseName;
}
public String datePicker() {
@@ -100,6 +104,14 @@
return wrap("DaysLabel");
}
+public String getBaseStyleName() {
+ return baseName;
+}
+
+public String getWidgetStyleName() {
+ return widgetName;
+}
+
public String month() {
return wrap("Month");
}
@@ -123,6 +135,16 @@
public String weekendLabel() {
return wrap("WeekendLabel");
}
+
+/**
+ * Prepends the base name to the given style.
+ *
+ * @param style style name
+ * @return style name
+ */
+protected String wrap(String style) {
+ return baseName + style;
+}
}
private class DateStyler {
@@ -163,171 +185,20 @@
}
}
- /**
- * Styles defined by the date picker widget that can be used by its
- * components.
- */
- protected interface Css {
-/**
- * Widget style name.
- *
- * @return the widget's style name
- */
-String datePicker();
-
-/**
- * Day style.
- *
- * @return the style
- */
-String day();
-
-/**
- * Disabled day style.
- *
- * @return the style
- */
-String dayIsDisabled();
-
-/**
- * Filler day style.
- *
- * @return the style
- */
-String dayIsFiller();
-
-/**
- * Highlighted day style.
- *
- * @return the style
- */
-String dayIsHighlighted();
-
-/**
- * Selected day style.
- *
- * @return the style
- */
-String dayIsSelected();
-
-/**
- * Selected and highlighted day style.
- *
- * @return the style
- */
-String dayIsSelectedAndHighlighted();
-
-/**
- * Today's day style.
- *
- * @return style
- */
-String dayIsToday();
-
-/**
- * Weekend day style.
- *
- * @return the style
- */
-String dayIsWeekend();
-
-/**
- * Days container style.
- *
- * @return the style
- */
-String days();
-
-/**
- * Label for months style.
- *
- * @return the style
- */
-String month();
-
-/**
- * Month selector style.
- *
- * @return the style
- */
-String monthSelector();
-
-/**
- * The navigation next button style.
- *
- * @return the style
- */
-String nextButton();
-
-/**
- * The navigation previous button style.
- *
- * @return the getType()
- */
-String previousButton();
-
-/**
- * Label for weekdays style.
- *
- * @return the style
- */
-String weekdayLabel();
-
-/**
- * Label for weekends style.
- *
- * @return the style
- */
-String weekendLabel();
- }
-
- /**
- *
- * Creates a [EMAIL PROTECTED] DatePicker.Css} instance with the given style
name.
Note, this does
- * not change the base name used for auxiliary styles. So, for instance,
- * create("myDatePicker") would replace the default "gwt-DatePicker" with
- * "myDatePicker" but would not effect the style "monthSelector".
- *
- * @param styleName widget's style name.
- * @return the created css
- */
- public static DatePicker.Css createCss(String styleName) {
-return new StandardCss(styleNa
[gwt-contrib] Re: Proposal: Add "Constants" and "Message" resources to ImmutableResourceBundle
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 -~--~~~~--~~--~--~---
[gwt-contrib] Re: Proposal: Add "Constants" and "Message" resources to ImmutableResourceBundle
StringResource interface could be just toString() --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Proposal: Add "Constants" and "Message" resources to ImmutableResourceBundle
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 would be available in the ImmutableResourceBundle.
Ok, this is only imagination based on the user perspective, but this
is how it could look like:
/**
* All resources used by tree table
*/
@DefaultLocale("en_US")
public interface TreeTableResources extends ImmutableResourceBundle {
/**
* The css file.
*/
@Resource("com/google/gwt/gen2/widgetbase/public/TreeTable.css")
Css css();
@Resource("treeClosed.gif")
ImageResource treeClosed();
@Resource("treeOpen.gif")
ImageResource treeOpen();
@Resource("filename")
StringResource hello();
@Resource("filename")
@DefaultText("You have {0} widgets")
@PluralText({"one", "You have one widget")
StringResource widgetCount(@PluralCount int count);
}
A StringBundleBuilder needs to collect all the defined StringResources
and grab the content from a propertyfile to generate the appropriate
class.
No idea if this is possible to implement as I've never touched the
generator part of gwt, but from a users perspective this would be
cool.
We could simple pass an instance of this ImmutableResourceBundle to a
widget to completely customize its appearance.
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---
[gwt-contrib] Re: [google-web-toolkit] [EMAIL PROTECTED] commented on revision r4098.
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 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 in the case of C, a good compiler will use branch prediction to > arrange it such that the common case (either inferred from the style, > profile-directed compilation, or programmer annotations) is untaken > branches, which on a modern processor is just as fast as the or. > > load a into accum > bnz trueLabel > load b into accum > bnz trueLabel > load c into accum > trueLabel: > return accum > > compared to > > load a into accum > load b into temp > or temp > load c into temp > or temp > return accum > > In either case, the loads are going to dominate execution time and untaken > branches are no more expensive than the or. The first version will be much > faster when the first or second is true, and equally fast when all are false > (ignoring the fact that the first version has an instruction that can be put > into the load's delay slot while the second one will stall for the first > load to finish before starting the second). > > However, in JS, evaluating the expression is done in complicated code with > lots of branches already. I am not sure that it is any slower at all to > evaluate a || b than a | b, even if the values are known to be false. > > Finally, I think it requires a demonstrable improvement to justify ignoring > the typical programming idiom, and if that is found it should be documented > there, such as "IE is 5 times faster to use | rather than || here, [EMAIL > PROTECTED] > OrBenchmark}". > > > -- > John A. Tamplin > Software Engineer (GWT), Google > > > > -- "There are only 10 types of people in the world: Those who understand binary, and those who don't" --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: [google-web-toolkit] [EMAIL PROTECTED] commented on revision r4098.
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 in the case of C, a good compiler will use branch prediction to arrange it such that the common case (either inferred from the style, profile-directed compilation, or programmer annotations) is untaken branches, which on a modern processor is just as fast as the or. load a into accum bnz trueLabel load b into accum bnz trueLabel load c into accum trueLabel: return accum compared to load a into accum load b into temp or temp load c into temp or temp return accum In either case, the loads are going to dominate execution time and untaken branches are no more expensive than the or. The first version will be much faster when the first or second is true, and equally fast when all are false (ignoring the fact that the first version has an instruction that can be put into the load's delay slot while the second one will stall for the first load to finish before starting the second). However, in JS, evaluating the expression is done in complicated code with lots of branches already. I am not sure that it is any slower at all to evaluate a || b than a | b, even if the values are known to be false. Finally, I think it requires a demonstrable improvement to justify ignoring the typical programming idiom, and if that is found it should be documented there, such as "IE is 5 times faster to use | rather than || here, [EMAIL PROTECTED] OrBenchmark}". -- John A. Tamplin Software Engineer (GWT), Google --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] [google-web-toolkit commit] r4131 - branches/1_6_datepicker/user/src/com/google/gwt/event/dom/client
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
==
---
branches/1_6_datepicker/user/src/com/google/gwt/event/dom/client/KeyEvent.java
(original)
+++
branches/1_6_datepicker/user/src/com/google/gwt/event/dom/client/KeyEvent.java
Thu Nov 20 09:38:00 2008
@@ -42,8 +42,8 @@
* @return whether this event have any modifier key down
*/
public boolean isAnyModifierKeyDown() {
-return isControlKeyDown() | isShiftKeyDown() | isMetaKeyDown()
-| isAltKeyDown();
+return isControlKeyDown() || isShiftKeyDown() || isMetaKeyDown()
+|| isAltKeyDown();
}
/**
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---
[gwt-contrib] Re: RR: Code Review, copies LazyPanel to 1.6 from incubator
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/gwt/user/client/ui/LazyPanel.java M user/src/com/google/gwt/user/client/ui/TabPanel.java On Wed, Nov 19, 2008 at 2:26 PM, Emily Crutcher <[EMAIL PROTECTED]> wrote: > *LazyPanelTest: > *I like your MyLazyPanel, seems like a good model to use for testing this. > > I think we should add tests that ensure that the create is triggered when > called in a TabPanel,StackPanel, (soon) DisclosurePanel, and ensureWidget(). Done, including the change to DisclosurePanel. But I'm testing the more fundamental DeckPanel rather than TabPanel. > > > *LazyPanel: > *We should probably decide as a group if we want to document no-arg > constructors or not. It's kinda odd to document just some of them. Seems like that's already decided by the fact that the style nazi tool doesn't require them. > > > *setVisible* javadoc: >childe --> child 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. > > > *setVisible:* > I wonder if we should actually reverse the order, and call > super.setVisible() first? I can't really see why. I can imagine it being better to create the new widget before making it visible--my normal habit to avoid flicker, though that shouldn't be an issue here. > > > > > On Wed, Nov 19, 2008 at 11:50 AM, Ray Ryan <[EMAIL PROTECTED]> wrote: > >> Here's the bulk of the work introducing LazyPanel. I'll send a follow up >> patch that reworks ShowCase to use it soon. >> You'll note that the javadoc references an example that doesn't exist yet. >> It's written, but I'll send a separate patch when it's been tested. >> >> Issues: >> >> 1. I don't like the fact that it's a panel, inheriting a useless list and >> extra API, and find myself wishing for, say, LazyComposite instead. Is there >> any particular reason it wasn't written that way originally? >> >> 2. I chatted with jlabanca, and we think it would be a good idea to tweak >> DisclosurePanel so that it calls setVisible(true) on its wrapped children >> before exposing them, to make it LazyPanel friendly the same way that >> DeckPanel and StackPanel already are. >> >> rjrjr >> >> > > > -- > "There are only 10 types of people in the world: Those who understand > binary, and those who don't" > --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~--- hello-lazy-panel-1.6-r4130.patch Description: Binary data
[gwt-contrib] Re: [google-web-toolkit] [EMAIL PROTECTED] commented on revision r4098.
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-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 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 true in JS? I would expect the interpreter to >> have so many branches in expression evaluation that you don't pay any more >> here, and the early-out case would be significantly faster. >> >> -- >> John A. Tamplin >> Software Engineer (GWT), Google >> >> >> >> >> > -- "There are only 10 types of people in the world: Those who understand binary, and those who don't" --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: Proposal: Extracting gwt-incubator-servlet.jar
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, >>>GWT.create, or reflection >> >> >> I think this should be "reachable code", in that code hiding behind a >> GWT.isClient() should be allowed. >> > > No, because on some JVMs even the attempt to load a class that has native > methods but no matching shared library (ie, JSNI) will thow an exception. I > think the only safe way to make that work is with super-source overlaying > the client-compatible version. > > > -- > John A. Tamplin > Software Engineer (GWT), Google > > > > -- "There are only 10 types of people in the world: Those who understand binary, and those who don't" --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: Proposal: Extracting gwt-incubator-servlet.jar
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() should be allowed. > No, because on some JVMs even the attempt to load a class that has native methods but no matching shared library (ie, JSNI) will thow an exception. I think the only safe way to make that work is with super-source overlaying the client-compatible version. -- John A. Tamplin Software Engineer (GWT), Google --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] UISuite test omissions: feature or bug?
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 one perhaps-more-important thing that I dropped the ball on: There appear to be several GWTTestCase classes in UISuite's package space, which are not actually in UISuite's enumeration of test classes to add to the suite (and thus aren't being exercised). Feature or bug? The classes are: PasswordTextBoxTest RandomTest TextBoxTest I can't see any particular reason the tests shouldn't be run, I think they actually pass; should they be included? And having gone that far, let me reprise the patch I sent Joel. Note that the change provoked some legit latent faults in various tests, and also provoked some not-yet-explained test failures in DOMSuite and I think TreeTest, so there's still some work to do if we think the package-add function is useful. Regardless, we should decide how to handle the three orphan tests above. --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~--- testclassfinder-r3861-3.patch Description: Binary data
[gwt-contrib] Re: Proposal: Extracting gwt-incubator-servlet.jar
> >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://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: RR: Adding PopupPanel.showBelow
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 > 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 considered for the future (if, for > example, someone submitted a patch...)? If so, which issue tracker > does it belong in? > > > On Thu, Nov 20, 2008 at 11:24 AM, Emily Crutcher <[EMAIL PROTECTED]> wrote: > > > >> 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 the widget as a > >> lot of toolkits do. Having an API method that easily allowed one to > >> do this now would be quite helpful. > > > > > > Yep, that is what the current version does, it tries to show the popup > below > > the ui object, but if it is too near the bottom of the screen, reverses > > itself. > > > >> > >> >> > > > > > > -- "There are only 10 types of people in the world: Those who understand binary, and those who don't" --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: RR: Adding PopupPanel.showBelow
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 considered for the future (if, for example, someone submitted a patch...)? If so, which issue tracker does it belong in? On Thu, Nov 20, 2008 at 11:24 AM, Emily Crutcher <[EMAIL PROTECTED]> wrote: > >> 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 the widget as a >> lot of toolkits do. Having an API method that easily allowed one to >> do this now would be quite helpful. > > > Yep, that is what the current version does, it tries to show the popup below > the ui object, but if it is too near the bottom of the screen, reverses > itself. > >> >> >> > --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: Code review on date picker branch to date
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 btw. the DatePicker API and CalendarView >> is odd. Can CalendarView be reduced to a smaller set of "primitive" calls at >> all? E.g., it doesn't really need the setDatesEnabled convenience wrapper, >> DatePicker can be in charge of that kind thing. >> > > Sure, we can get rid of the convinience methods. > So what is the actual date returned in such a case? The first day of the > month(s) displayed? Or can a Date be filled with null day info? Sounds like > another excellent javadoc opportunity. > > Yep. Also, I think it does make sense to extend this API down to the > calendar model level, as that would probably help mitigate the confusion. > > > >> >> Anyway, can such a CalendarView really be implemented? CalendarModel seems >> very locked down to a single month. >> >>> The calendar view specifies a month at a time, the calendar view can > increment the month to help it fill in its date views. > > > >> That might not be possible--the compiler may find itself unable to tell >> whether to use the Date or the Date... version. >> > > Yep, and if we actually implement ".." efficiently in our compiler, no > reason to do this either! > >> >>> >> February is visible. The 10th is disabled. The user moves the picker to >> March, and back to February. What is the state of Feb. 10? >> > > It is no longer disabled. That's why the API has the assertion actually, as > all the api calls that include "visible dates" specifically are reset when > the date picker refreshes. > So, again, if I use this api, I am responsible for monitoring the picker and re-applying my setDisabled calls. This strikes me as kind of half hearted support, and surprising behavior. If someone can make this kind of thing happen with a slightly customized CalendarView, I think we should delete this method. > > >> Custom CalendarView seems okay, but MonthSelector is an empty class, and >> its default implementation is final. So I have protected API that says "your >> month selector here," and no way to actually provide one without copying and >> pasting our code. That seems inconsistent. >> >>> > > So you think we should include an extendable month selector as well? We > actually even have a googler working on one, so we can see how far he has > gotten or create one ourselves if he hasn't gotten far enough. > More that we should get MonthSelector out of the protected constructor. > > > >> CalendarUtil.java Some of the methods in this public class are not public, seemingly arbitrarily. Is there a real reason we don't want people to call isWeekend or hasTime? Why is resetTime private? >>> We were trying to expose only the methods we were absolutely certain >>> other people would want, mostely because we used them ourselves, rather then >>> exposing all of them. >>> >> >> If we have methods we aren't using, why are they there? >> > > We are using them for calendar model, we just don't know if anyone else > would need to use them. > So we do use them ourselves, then... Basically, I think we should either make the whole thing package protected, or else expose every method we use and make sure it is unit tested. And if time does not permit the test coverage, it should not be public. > >>> >> > > > --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: RR: Adding PopupPanel.showBelow
> 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 the widget as a > lot of toolkits do. Having an API method that easily allowed one to > do this now would be quite helpful. Yep, that is what the current version does, it tries to show the popup below the ui object, but if it is too near the bottom of the screen, reverses itself. > > > > -- "There are only 10 types of people in the world: Those who understand binary, and those who don't" --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: Code review on date picker branch to date
> > > 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 compiler implements the ".." sytax efficiently, no reason for the clutter. > > -- > John A. Tamplin > Software Engineer (GWT), Google > > > > -- "There are only 10 types of people in the world: Those who understand binary, and those who don't" --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] [google-web-toolkit commit] r4130 - releases/1.6/dev/core/src/com/google/gwt/dev
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 for pluggable CompilePerms workers.
Patch by: scottb
Review by: bobv
Modified: releases/1.6/dev/core/src/com/google/gwt/dev/Link.java
==
--- releases/1.6/dev/core/src/com/google/gwt/dev/Link.java (original)
+++ releases/1.6/dev/core/src/com/google/gwt/dev/Link.java Thu Nov 20
08:18:54 2008
@@ -107,6 +107,16 @@
return doLink(logger, linkerContext, precompilation, jsFiles);
}
+ public static void link(TreeLogger logger, ModuleDef module,
+ Precompilation precompilation, File[] jsFiles, File outDir, File
extrasDir)
+ throws UnableToCompleteException {
+StandardLinkerContext linkerContext = new StandardLinkerContext(logger,
+module, precompilation.getUnifiedAst().getOptions());
+ArtifactSet artifacts = doLink(logger, linkerContext, precompilation,
+jsFiles);
+doProduceOutput(logger, artifacts, linkerContext, module, outDir,
extrasDir);
+ }
+
public static void main(String[] args) {
/*
* NOTE: main always exits with a call to System.exit to terminate any
@@ -147,6 +157,48 @@
return linkerContext.invokeLink(logger);
}
+ private static void doProduceOutput(TreeLogger logger, ArtifactSet
artifacts,
+ StandardLinkerContext linkerContext, ModuleDef module, File outDir,
+ File extraDir) throws UnableToCompleteException {
+boolean warnOnExtra = false;
+File moduleExtraDir;
+if (extraDir == null) {
+ /*
+ * Legacy behavior for backwards compatibility; if the extra
directory is
+ * not specified, make it a sibling to the deploy directory, with
-aux.
+ */
+ String deployDir = module.getDeployTo();
+ deployDir = deployDir.substring(0, deployDir.length() - 1) + "-aux";
+ moduleExtraDir = new File(outDir, deployDir);
+
+ /*
+ * Only warn when we create a new legacy extra dir.
+ */
+ warnOnExtra = !moduleExtraDir.exists();
+} else {
+ moduleExtraDir = new File(extraDir, module.getDeployTo());
+}
+
+File moduleOutDir = new File(outDir, module.getDeployTo());
+Util.recursiveDelete(moduleOutDir, true);
+Util.recursiveDelete(moduleExtraDir, true);
+linkerContext.produceOutputDirectory(logger, artifacts, moduleOutDir,
+moduleExtraDir);
+
+/*
+ * Warn on legacy extra directory, but only if: 1) It didn't exist
before.
+ * 2) We just created it.
+ */
+if (warnOnExtra && moduleExtraDir.exists()) {
+ logger.log(
+ TreeLogger.WARN,
+ "Non-public artificats were produced in '"
+ + moduleExtraDir.getAbsolutePath()
+ + "' within the public output folder; use -extra to specify
an alternate location");
+}
+logger.log(TreeLogger.INFO, "Link succeeded");
+ }
+
private static void finishPermuation(TreeLogger logger, Permutation perm,
File jsFile, StandardLinkerContext linkerContext)
throws UnableToCompleteException {
@@ -174,16 +226,6 @@
private ModuleDef module;
- /**
- * This is the output directory for private files.
- */
- private File moduleExtraDir;
-
- /**
- * This is the output directory for public files.
- */
- private File moduleOutDir;
-
private final LinkOptionsImpl options;
public Link(LinkOptions options) {
@@ -191,7 +233,8 @@
}
public boolean run(TreeLogger logger) throws UnableToCompleteException {
-init(logger);
+module = ModuleDefLoader.loadFromClassPath(logger,
options.getModuleName());
+
File precompilationFile = new File(options.getCompilerWorkDir(),
Precompile.PRECOMPILATION_FILENAME);
if (!precompilationFile.exists()) {
@@ -229,45 +272,9 @@
module, precompilation.getUnifiedAst().getOptions());
ArtifactSet artifacts = doLink(branch, linkerContext, precompilation,
jsFiles);
-if (artifacts != null) {
- boolean preexistingExtraDir = moduleExtraDir.exists();
- linkerContext.produceOutputDirectory(branch, artifacts, moduleOutDir,
- moduleExtraDir);
-
- /*
- * Warn on legacy extra directory, but only if: 1) It didn't exist
before.
- * 2) We just created it.
- */
- if (!preexistingExtraDir && moduleExtraDir.exists()
- && options.getExtraDir() == null) {
-branch.log(TreeLogger.WARN, "Non-deployed artificats are in '"
-+ moduleExtraDir.getPath()
-+ "', within the deployable output directory '"
-+ options.getOutDir().getPath()
-+ "'; use -extra to relocate the auxilliary files");
- }
- branch.log(TreeLogger.INFO, "Link succeed
[gwt-contrib] Re: Code review on date picker branch to date
> > 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 smaller set of "primitive" calls at > all? E.g., it doesn't really need the setDatesEnabled convenience wrapper, > DatePicker can be in charge of that kind thing. > Sure, we can get rid of the convinience methods. So what is the actual date returned in such a case? The first day of the month(s) displayed? Or can a Date be filled with null day info? Sounds like another excellent javadoc opportunity. Yep. Also, I think it does make sense to extend this API down to the calendar model level, as that would probably help mitigate the confusion. > > Anyway, can such a CalendarView really be implemented? CalendarModel seems > very locked down to a single month. > >> The calendar view specifies a month at a time, the calendar view can increment the month to help it fill in its date views. > That might not be possible--the compiler may find itself unable to tell > whether to use the Date or the Date... version. > Yep, and if we actually implement ".." efficiently in our compiler, no reason to do this either! > >> > February is visible. The 10th is disabled. The user moves the picker to > March, and back to February. What is the state of Feb. 10? > It is no longer disabled. That's why the API has the assertion actually, as all the api calls that include "visible dates" specifically are reset when the date picker refreshes. > Custom CalendarView seems okay, but MonthSelector is an empty class, and > its default implementation is final. So I have protected API that says "your > month selector here," and no way to actually provide one without copying and > pasting our code. That seems inconsistent. > >> So you think we should include an extendable month selector as well? We actually even have a googler working on one, so we can see how far he has gotten or create one ourselves if he hasn't gotten far enough. > >>> CalendarUtil.java >>> >>> Some of the methods in this public class are not public, seemingly >>> arbitrarily. Is there a real reason we don't want people to call isWeekend >>> or hasTime? Why is resetTime private? >>> >>> >> We were trying to expose only the methods we were absolutely certain other >> people would want, mostely because we used them ourselves, rather then >> exposing all of them. >> > > If we have methods we aren't using, why are they there? > We are using them for calendar model, we just don't know if anyone else would need to use them. > >> > --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] [google-web-toolkit commit] r4129 - in releases/1.6/dev/core/src/com/google/gwt/dev: . jjs
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/UnifiedAst.java
Log:
Remove UnifiedAST memory calculation and clean up instance-creation aspects
of UnifiedAST.
This patch is in preparation for pluggable CompilePerms workers.
Patch by: scottb
Review by: bobv
Modified:
releases/1.6/dev/core/src/com/google/gwt/dev/PermutationCompiler.java
==
--- releases/1.6/dev/core/src/com/google/gwt/dev/PermutationCompiler.java
(original)
+++ releases/1.6/dev/core/src/com/google/gwt/dev/PermutationCompiler.java
Thu Nov 20 08:17:10 2008
@@ -19,9 +19,8 @@
import com.google.gwt.core.ext.UnableToCompleteException;
import com.google.gwt.dev.cfg.BindingProperty;
import com.google.gwt.dev.cfg.StaticPropertyOracle;
-import com.google.gwt.dev.jjs.UnifiedAst;
import com.google.gwt.dev.jjs.JavaToJavaScriptCompiler;
-import com.google.gwt.dev.jjs.ast.JProgram;
+import com.google.gwt.dev.jjs.UnifiedAst;
import com.google.gwt.dev.util.PerfLogger;
import java.util.concurrent.BlockingQueue;
@@ -191,14 +190,6 @@
});
}
- if (!hasEnoughMemory()) {
-/*
- * Not enough memory to run, but if there are multiple threads, we
can
- * try again with fewer threads.
- */
-tryToExitNonFinalThread(outOfMemoryRetryAction);
- }
-
boolean definitelyFinalThread = (threadCount.get() == 1);
try {
String result = currentTask.call();
@@ -247,26 +238,6 @@
}
/**
- * Returns true if there is enough estimated memory to run
- * another permutation, or if this is the last live worker thread and
we
- * have no choice.
- */
-private boolean hasEnoughMemory() {
- if (threadCount.get() == 1) {
-// I'm the last thread, so I have to at least try.
-return true;
- }
-
- if (astMemoryUsage >= getPotentialFreeMemory()) {
-return true;
- }
-
- // Best effort memory reclaim.
- System.gc();
- return astMemoryUsage < getPotentialFreeMemory();
-}
-
-/**
* Exits this thread if and only if it's not the last running thread,
* performing the specified action before terminating.
*
@@ -294,21 +265,6 @@
private static final Result FINISHED_RESULT = new Result(null, -1) {
};
- private static long getPotentialFreeMemory() {
-long used = Runtime.getRuntime().totalMemory()
-- Runtime.getRuntime().freeMemory();
-assert (used > 0);
-long potentialFree = Runtime.getRuntime().maxMemory() - used;
-assert (potentialFree >= 0);
-return potentialFree;
- }
-
- /**
- * Holds an estimate of how many bytes of memory a new concurrent
compilation
- * will consume.
- */
- protected final long astMemoryUsage;
-
/**
* A queue of results being sent from worker threads to the main thread.
*/
@@ -329,7 +285,6 @@
public PermutationCompiler(TreeLogger logger, UnifiedAst unifiedAst,
Permutation[] perms, int[] permsToRun) {
this.logger = logger;
-this.astMemoryUsage = unifiedAst.getAstMemoryUsage();
for (int permToRun : permsToRun) {
tasks.add(new PermutationTask(logger, unifiedAst, perms[permToRun],
permToRun));
@@ -387,52 +342,10 @@
result = Math.min(Runtime.getRuntime().availableProcessors(), result);
/*
- * Allow user-defined override as an escape valve.
+ * User-defined value caps.
*/
-result = Math.min(result, Integer.getInteger("gwt.jjs.maxThreads",
result));
-
-if (result == 1) {
- return 1;
-}
-
-// More than one thread would definitely be faster at this point.
-
-if (JProgram.isTracingEnabled()) {
- logger.log(TreeLogger.INFO,
- "Parallel compilation disabled due to gwt.jjs.traceMethods being
enabled");
- return 1;
-}
-
-int desiredThreads = result;
-
-/*
- * Need to do some memory estimation to figure out how many concurrent
- * threads we can safely run.
- */
-long potentialFreeMemory = getPotentialFreeMemory();
-int extraMemUsageThreads = (int) (potentialFreeMemory /
astMemoryUsage);
-logger.log(TreeLogger.TRACE,
-"Extra threads constrained by estimated memory usage: "
-+ extraMemUsageThreads + " = " + potentialFreeMemory + " / "
-+ astMemoryUsage);
-int memUsageThreads = extraMemUsageThreads + 1;
-
-if (memUsageThreads < desiredThreads) {
- long currentMaxMemory = Runtime.getRuntime().maxMemory();
- // Convert to megabytes.
- currentMaxMemory /= 1024 * 1024;
-
- long suggestedMaxMemory = currentMaxMemory * 2;
-
- logger.log(TreeLogger.WARN, de
[gwt-contrib] Re: Proposal: Extracting gwt-incubator-servlet.jar
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 > data and send just portions to the server. None the less, it might be a > good idea for us to separate these classes in general if we think they are > likely to be used with RPC. Obviously Request and SerializableResponse fall > into this category because we made them Serializable. Personally I think code that uses neither JSNI or reflection should be in a shared directory (though perhaps some things would still go in client or server if they only made sense there). I would like to see more rigorous separation of code so that shared code can only see other shared code and referencing server/client code there would be a compile-time error. I set my home app up that way and I found it makes things much easier. For example, I was originally lazy and had a model as an inner class of a widget, and that model was used in server code. When debugID support was added, suddenly my server broke because accessing that model class wound up doing clinit on the widget, which wound up calling GWT.create. Here is the model I have been using: server - code that needs any server-only resource, such as servlets or reflection shared - code that does not contain or reference any class that contains JSNI, GWT.create, or reflection client - code that needs JSNI, GWT.create, or is only useful in the client rebind - generators and other code that needs access to TypeOracle linker - linkers When compiling the server-side code, it can only see server and shared. Client side code can see client and shared. -- John A. Tamplin Software Engineer (GWT), Google --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: Code review on date picker branch to date
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 not distinguishable overloads, so you would have to reverse the order of the arguments to keep the single-arg version. -- John A. Tamplin Software Engineer (GWT), Google --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: Proposal: Extracting gwt-incubator-servlet.jar
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 idea for us to separate these classes in general if we think they are likely to be used with RPC. Obviously Request and SerializableResponse fall into this category because we made them Serializable. Thanks, John LaBanca [EMAIL PROTECTED] On Thu, Nov 20, 2008 at 4:43 AM, dflorey <[EMAIL PROTECTED]> wrote: > > 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 fixed but isn't in an official eclipse release yet. > The > > bug shows up in our RPC generator when you try to pass a Request or > Response > > object over RPC. We'll combine TableModelHelper back into TableModel > once > > the next Eclipse version is officially released and people have time to > > switch to it. > > > > GWT issue: > http://code.google.com/p/google-web-toolkit/issues/detail?id=2731 > > > > Eclipse issue:https://bugs.eclipse.org/bugs/show_bug.cgi?id=243820 > > > > Thanks, > > John LaBanca > > [EMAIL PROTECTED] > > > > On Wed, Nov 19, 2008 at 11:22 AM, dflorey <[EMAIL PROTECTED]> > wrote: > > > > > While I've been moving TableModelHelper to shared I was wondering why > > > this class is needed. > > > From my point of view it is only a container for all rpc relevant > > > classes. > > > I'm a big fan of not producing too many classes but I'd prefer to make > > > the nested classes top level classes. > > > Eclipse fails to organize imports with these nested classes, but that > > > is just one reasone behind it. > > > What do you think? > > > I'll move them to top level in my branch to see what happens... > > > > > On 19 Nov., 17:00, Emily Crutcher <[EMAIL PROTECTED]> wrote: > > > > Thanks! > > > > > > On Wed, Nov 19, 2008 at 10:39 AM, dflorey <[EMAIL PROTECTED]> > > > wrote: > > > > > > > I've just seen that there are already server and shared packages in > > > > > the logging lib. > > > > > So we need a shared package for the tables containing: > > > > > Request, Reponse, SerializableResponse, ColumnSortInfo, > > > > > ColumnSortInfoList (and maybe some others I've missed). > > > > > I'll create an ant task in my branch to see if I manage to strip > down > > > > > a gwt-incubator-servlet.jar > > > > > > > On 19 Nov., 15:28, Emily Crutcher <[EMAIL PROTECTED]> wrote: > > > > > > That sounds like a great idea. Could you create a list of > classes > > > you > > > > > think > > > > > > should be either > > > > > > a) moved to the new gwt-incubator-servlet.jar > > > > > > b) copied to the new gwt-incubator-servlet.jar > > > > > > > > and send it out to the group? > > > > > > > > On Wed, Nov 19, 2008 at 5:49 AM, dflorey < > [EMAIL PROTECTED]> > > > > > wrote: > > > > > > > > > Hi, > > > > > > > some of the incubator classes are required on the server side > > > > > > > (especially the table request & response, sort info classes > etc.) > > > > > > > I've read somewhere that these classes should be placed in a > > > "shared" > > > > > > > package. > > > > > > > No clue if it causes trouble to move the serializable classes > to > > > such > > > > > > > a package (as they are right now in the TableModelHelper class > > > because > > > > > > > of eclise compiler issues) but if possible I'd vote for > extracting > > > > > > > these classes into a gwt-incubator-servlet.jar. > > > > > > > > -- > > > > > > "There are only 10 types of people in the world: Those who > understand > > > > > > binary, and those who don't" > > > > > > -- > > > > "There are only 10 types of people in the world: Those who understand > > > > binary, and those who don't" > > > --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: Code review on date picker branch to date
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 option >> to the plural versions seems like a terrific idea. I don't think it matters >> if we use calendar/getCalendar, but we should probably pick only one for >> consistancy! >> > > You can still call the varargs version with a single value, as in > addStyleToVisibleDates(styleName, date), and the extra cost should be > minimal. I think the extra weight of additional API surface area is more > costly. > 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. > > -- > John A. Tamplin > Software Engineer (GWT), Google > > > > > -- "There are only 10 types of people in the world: Those who understand binary, and those who don't" --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: RR: Adding PopupPanel.showBelow
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 > saying that it, by default shows below. Then, if we do decide to eventually > introduce orientations we 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 the widget as a lot of toolkits do. Having an API method that easily allowed one to do this now would be quite helpful. --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: Code review on date picker branch to date
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 expect here. >> > Yep, so long term may have been a bit of an exaggeration! --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: Code review on date picker branch to date
"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 PROTECTED]> wrote:
>
>>
>> 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.
>> Proposal: Add ChangeListener support and add a "Date getValue()"
>> method.
>>
>> On 20 Nov., 04:26, 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? Or, should
>> > getCalendarView perhaps go away, or become protected or package--is it
>> > really useful/safe for clients to talk to it directly?
>> >
>> > ElementMapper.java
>> >
>> > We need ElementMapperTest
>> >
>> > The param type MappedType should be a single letter, perhaps U
>> >
>> > What's going on Iterator#remove? This class claims to work on UIObjects,
>> but
>> > here you are casting to Widget and asserting that parent is an
>> HTMLTable.
>> >
>> > CalendarModel.java
>> >
>> > We need CalendarModelTest
>> >
>> > So this class has the notion of the current date shared by the various
>> > moving parts, and it does formatting, yes? Could punch up its javadoc to
>> > that effect.
>> >
>> > What is that no-op refresh() method there for?
>> >
>> > DatePicker.java
>> >
>> > 1. It's confusing that there is a CalendarView named calendar, and a
>> > CalendarModel named model. I'd expect the view to be named view, and the
>> > model to be named calendar.
>> >
>> > 2. It seems like many fields here could be final.
>> >
>> > 3. The Css interface is protected, but I though we were going to make it
>> > private, or at least package protected. It is also featured in a ton of
>> > public methods and constructors. That's no good.
>> >
>> > If it does wind up staying visible, having a public static setDefaultCss
>> > method is a bad idea. Allowing it to be overridden per instance is
>> plenty.
>> >
>> > 4. getDateShown() is implemented as getModel().getCurrentMonth(). Isn't
>> that
>> > a bug? If not, shouldn't the method be called getMonthShown()?
>> >
>> > 5. It seems like these methods:
>> >
>> > public final void addStyleToVisibleDate(Date visibleDate, String
>> > styleName) {
>> > calendar.addStyleToDate(visibleDate, styleName);
>> > }
>> >
>> > public final void addStyleToVisibleDates(Iterable visibleDates,
>> > String styleName) {
>> > getCalendarView().addStyleToDates(visibleDates, styleName);
>> > }
>> >
>> > could instead be
>> >
>> > public final void addStyleToVisibleDates(String styleName, Date...
>> > visibleDates) {
>> > addStyleToVisibleDates(styleName, Arrays.asList(visibleDates));
>> > }
>> >
>> > public final void addStyleToVisibleDates(String styleName,
>> Iterable
>> > visibleDates) {
>> > getCalendarView().addStyleToDates(visibleDates, styleName);
>> > }
>> >
>> > Even if not, why is one using calendar and the other using
>> > getCalendarView()?
>> >
>> > And note that the remove method is not parallel to these--there is only
>> one.
>> >
>> > 6. getHighlightedDate() javadoc should explain diff between selected and
>> > highlighted. class doc should probably do the same.
>> >
>> > 7. getGlobalStyleOfDate() What is a global style? Is this a GWT wide
>> > concept? If not, needs explicating.
>> >
>> > 8. showDate() Need to explain how this differs from setValue(), and link
>> > between the two methods.
>> >
>> > 9. What is the package private setModel(CalendarModel) needed for?
>> >
>> > 10. Some methods are final, and some aren't. It seems very arbitrary.
>> And we
>> > should be documenting final methods to explain why.
>> >
>> > 11. This seems harsh (the assert, I mean):
>> >
>> > public final void setEnabledOnVisibleDate(Date date, boolean enabled)
>> {
>> >
>> > assert isDateVisible(date) : date
>> >
>> > + " cannot be enabled or disabled as it is not visible";
>> >
>> > getCalendarView().setDateEnabled(date, enabled);
>> >
>> > }
>> >
>> > What happens if they disable a date, the user scrolls it away, and then
>> > scrolls it back? Do they have to listen for these scroll events and then
>> > reapply the disables? Is this a method people actually asked for, can we
>> get
>> > rid of it?
>> >
>> > 12. setAllowableDates says it is "not yet implemented for the default
>> case".
>> > Why is it here, then?
>> >
>> > DateBox.java
>> >
>> > 1. Constitutent fields (box, picker, popup) should be final
>> >
>> > DefaultMonthSelector.java
>> >
>>
[gwt-contrib] Re: Code review on date picker branch to date
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 are redundant with
>> CalendarView methods be stricken, given DatePicker#getCalendarView? Or,
>> should getCalendarView perhaps go away, or become protected or package--is
>> it really useful/safe for clients to talk to it directly?
>>
>
> getCalendarView is already protected, so I'm not sure what you are
> suggesting here?
>
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 smaller set of "primitive" calls at
all? E.g., it doesn't really need the setDatesEnabled convenience wrapper,
DatePicker can be in charge of that kind thing.
>
>
>>
>> ElementMapper.java
>>
>> We need ElementMapperTest
>>
> Yep, that's part of the "basic unit test task" on tracker.
>
>
>>
>> The param type MappedType should be a single letter, perhaps U
>>
>
> Yep. All the classes still are using the old style XType syntax rather then
> the single letter syntax.
>
>>
>> What's going on Iterator#remove? This class claims to work on UIObjects,
>> but here you are casting to Widget and asserting that parent is an
>> HTMLTable.
>>
>
> My bad. I converted over to UIObject as we are not using any specific
> "widget" like information when I moved it, should have waited until after
> the initial commit like the other changes.
>
>>
>> CalendarModel.java
>>
>> We need CalendarModelTest
>>
>
> Yep.
>
>
>> So this class has the notion of the current date shared by the various
>> moving parts, and it does formatting, yes? Could punch up its javadoc to
>> that effect.
>>
>
> Yep.
>
>
>> What is that no-op refresh() method there for?
>>
>
> So subclasses of calendar model have the ability to refresh.
>
>
>>
>> DatePicker.java
>>
>> 1. It's confusing that there is a CalendarView named calendar, and a
>> CalendarModel named model. I'd expect the view to be named view, and the
>> model to be named calendar.
>>
>
> how about just view and model?
>
k
>
>
>
>
>>
>> 2. It seems like many fields here could be final.
>>
>
> Yep.
>
>
>>
>> 3. The Css interface is protected, but I though we were going to make it
>> private, or at least package protected. It is also featured in a ton of
>> public methods and constructors. That's no good.
>>
>
> Yep, that's in the current tracker schedule as well. Now, I'm not entirely
> sure how we are going to get rid of it, but I figure we can knock our heads
> together and figure something out.
>
>
>>
>> If it does wind up staying visible, having a public static setDefaultCss
>> method is a bad idea. Allowing it to be overridden per instance is plenty.
>>
>
> I'm 99% certain that whatever solution we come up with in the general case
> will NOT have this method.
>
>
>>
>> 4. getDateShown() is implemented as getModel().getCurrentMonth(). Isn't
>> that a bug? If not, shouldn't the method be called getMonthShown()?
>>
>
> In the default implementation, the current month field in the calendar
> model is the date shown, so it is correct for the default case.
>
> We've tried to implement the API so it would be tolerant of a calendar view
> that showed multiple months at once, which is why the date picker methods
> are getDateShown() and showDate() rather then getMonthShown() and
> showMonth()
>
So what is the actual date returned in such a case? The first day of the
month(s) displayed? Or can a Date be filled with null day info? Sounds like
another excellent javadoc opportunity.
Anyway, can such a CalendarView really be implemented? CalendarModel seems
very locked down to a single month.
>
>
>
>
>> 5. It seems like these methods:
>>
>> public final void addStyleToVisibleDate(Date visibleDate, String
>> styleName) {
>> calendar.addStyleToDate(visibleDate, styleName);
>> }
>>
>> public final void addStyleToVisibleDates(Iterable visibleDates,
>> String styleName) {
>> getCalendarView().addStyleToDates(visibleDates, styleName);
>> }
>>
>> could instead be
>>
>> public final void addStyleToVisibleDates(String styleName, Date...
>> visibleDates) {
>> addStyleToVisibleDates(styleName, Arrays.asList(visibleDates));
>> }
>>
>> public final void addStyleToVisibleDates(String
>> styleName, Iterable visibleDates) {
>> getCalendarView().addStyleToDates(visibleDates, styleName);
>> }
>>
>> Even if not, why is one using calendar and the other using
>> getCalendarView()?
>>
>
> 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
[gwt-contrib] Re: Code review on date picker branch to date
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 matters if > we use calendar/getCalendar, but we should probably pick only one for > consistancy! > You can still call the varargs version with a single value, as in addStyleToVisibleDates(styleName, date), and the extra cost should be minimal. I think the extra weight of additional API surface area is more costly. -- John A. Tamplin Software Engineer (GWT), Google --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: Code review on date picker branch to date
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.
> 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.
> Proposal: Add ChangeListener support and add a "Date getValue()"
> method.
>
> On 20 Nov., 04:26, 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? Or, should
> > getCalendarView perhaps go away, or become protected or package--is it
> > really useful/safe for clients to talk to it directly?
> >
> > ElementMapper.java
> >
> > We need ElementMapperTest
> >
> > The param type MappedType should be a single letter, perhaps U
> >
> > What's going on Iterator#remove? This class claims to work on UIObjects,
> but
> > here you are casting to Widget and asserting that parent is an HTMLTable.
> >
> > CalendarModel.java
> >
> > We need CalendarModelTest
> >
> > So this class has the notion of the current date shared by the various
> > moving parts, and it does formatting, yes? Could punch up its javadoc to
> > that effect.
> >
> > What is that no-op refresh() method there for?
> >
> > DatePicker.java
> >
> > 1. It's confusing that there is a CalendarView named calendar, and a
> > CalendarModel named model. I'd expect the view to be named view, and the
> > model to be named calendar.
> >
> > 2. It seems like many fields here could be final.
> >
> > 3. The Css interface is protected, but I though we were going to make it
> > private, or at least package protected. It is also featured in a ton of
> > public methods and constructors. That's no good.
> >
> > If it does wind up staying visible, having a public static setDefaultCss
> > method is a bad idea. Allowing it to be overridden per instance is
> plenty.
> >
> > 4. getDateShown() is implemented as getModel().getCurrentMonth(). Isn't
> that
> > a bug? If not, shouldn't the method be called getMonthShown()?
> >
> > 5. It seems like these methods:
> >
> > public final void addStyleToVisibleDate(Date visibleDate, String
> > styleName) {
> > calendar.addStyleToDate(visibleDate, styleName);
> > }
> >
> > public final void addStyleToVisibleDates(Iterable visibleDates,
> > String styleName) {
> > getCalendarView().addStyleToDates(visibleDates, styleName);
> > }
> >
> > could instead be
> >
> > public final void addStyleToVisibleDates(String styleName, Date...
> > visibleDates) {
> > addStyleToVisibleDates(styleName, Arrays.asList(visibleDates));
> > }
> >
> > public final void addStyleToVisibleDates(String styleName,
> Iterable
> > visibleDates) {
> > getCalendarView().addStyleToDates(visibleDates, styleName);
> > }
> >
> > Even if not, why is one using calendar and the other using
> > getCalendarView()?
> >
> > And note that the remove method is not parallel to these--there is only
> one.
> >
> > 6. getHighlightedDate() javadoc should explain diff between selected and
> > highlighted. class doc should probably do the same.
> >
> > 7. getGlobalStyleOfDate() What is a global style? Is this a GWT wide
> > concept? If not, needs explicating.
> >
> > 8. showDate() Need to explain how this differs from setValue(), and link
> > between the two methods.
> >
> > 9. What is the package private setModel(CalendarModel) needed for?
> >
> > 10. Some methods are final, and some aren't. It seems very arbitrary. And
> we
> > should be documenting final methods to explain why.
> >
> > 11. This seems harsh (the assert, I mean):
> >
> > public final void setEnabledOnVisibleDate(Date date, boolean enabled) {
> >
> > assert isDateVisible(date) : date
> >
> > + " cannot be enabled or disabled as it is not visible";
> >
> > getCalendarView().setDateEnabled(date, enabled);
> >
> > }
> >
> > What happens if they disable a date, the user scrolls it away, and then
> > scrolls it back? Do they have to listen for these scroll events and then
> > reapply the disables? Is this a method people actually asked for, can we
> get
> > rid of it?
> >
> > 12. setAllowableDates says it is "not yet implemented for the default
> case".
> > Why is it here, then?
> >
> > DateBox.java
> >
> > 1. Constitutent fields (box, picker, popup) should be final
> >
> > DefaultMonthSelector.java
> >
> > JavaDoc says that it is "not part of the public API". If it's a public
> class
> > and can be used as an arg to a protected constructor, it's public, let's
> be
> > honest here. Perhaps you meant "not extensible"? As for "please feel to
> copy
> > it
[gwt-contrib] Re: Code review on date picker branch to date
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? Or,
> should getCalendarView perhaps go away, or become protected or package--is
> it really useful/safe for clients to talk to it directly?
>
getCalendarView is already protected, so I'm not sure what you are
suggesting here?
>
> ElementMapper.java
>
> We need ElementMapperTest
>
Yep, that's part of the "basic unit test task" on tracker.
>
> The param type MappedType should be a single letter, perhaps U
>
Yep. All the classes still are using the old style XType syntax rather then
the single letter syntax.
>
> What's going on Iterator#remove? This class claims to work on UIObjects,
> but here you are casting to Widget and asserting that parent is an
> HTMLTable.
>
My bad. I converted over to UIObject as we are not using any specific
"widget" like information when I moved it, should have waited until after
the initial commit like the other changes.
>
> CalendarModel.java
>
> We need CalendarModelTest
>
Yep.
> So this class has the notion of the current date shared by the various
> moving parts, and it does formatting, yes? Could punch up its javadoc to
> that effect.
>
Yep.
> What is that no-op refresh() method there for?
>
So subclasses of calendar model have the ability to refresh.
>
> DatePicker.java
>
> 1. It's confusing that there is a CalendarView named calendar, and a
> CalendarModel named model. I'd expect the view to be named view, and the
> model to be named calendar.
>
how about just view and model?
>
> 2. It seems like many fields here could be final.
>
Yep.
>
> 3. The Css interface is protected, but I though we were going to make it
> private, or at least package protected. It is also featured in a ton of
> public methods and constructors. That's no good.
>
Yep, that's in the current tracker schedule as well. Now, I'm not entirely
sure how we are going to get rid of it, but I figure we can knock our heads
together and figure something out.
>
> If it does wind up staying visible, having a public static setDefaultCss
> method is a bad idea. Allowing it to be overridden per instance is plenty.
>
I'm 99% certain that whatever solution we come up with in the general case
will NOT have this method.
>
> 4. getDateShown() is implemented as getModel().getCurrentMonth(). Isn't
> that a bug? If not, shouldn't the method be called getMonthShown()?
>
In the default implementation, the current month field in the calendar model
is the date shown, so it is correct for the default case.
We've tried to implement the API so it would be tolerant of a calendar view
that showed multiple months at once, which is why the date picker methods
are getDateShown() and showDate() rather then getMonthShown() and
showMonth()
> 5. It seems like these methods:
>
> public final void addStyleToVisibleDate(Date visibleDate, String
> styleName) {
> calendar.addStyleToDate(visibleDate, styleName);
> }
>
> public final void addStyleToVisibleDates(Iterable visibleDates,
> String styleName) {
> getCalendarView().addStyleToDates(visibleDates, styleName);
> }
>
> could instead be
>
> public final void addStyleToVisibleDates(String styleName, Date...
> visibleDates) {
> addStyleToVisibleDates(styleName, Arrays.asList(visibleDates));
> }
>
> public final void addStyleToVisibleDates(String styleName, Iterable
> visibleDates) {
> getCalendarView().addStyleToDates(visibleDates, styleName);
> }
>
> Even if not, why is one using calendar and the other using
> getCalendarView()?
>
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 matters if
we use calendar/getCalendar, but we should probably pick only one for
consistancy!
> And note that the remove method is not parallel to these--there is only
> one.
>
While no one has requested the plural version of remove, I think you are
right and we should add it anyway.
>
> 6. getHighlightedDate() javadoc should explain diff between selected and
> highlighted. class doc should probably do the same.
>
Yep.
>
> 7. getGlobalStyleOfDate() What is a global style? Is this a GWT wide
> concept? If not, needs explicating.
>
Will add more explination then.
>
> 8. showDate() Need to explain how this differs from setValue(), and link
> between the two methods.
>
Yep, can add more javadoc.
>
> 9. What is the package private setModel(CalendarModel) needed for?
>
It looks like it can be made private. Will do so.
>
> 10. Some methods are final, and some aren't. It seems very arbitrary. And
> we should be documenting final methods to explain why.
>
Will add javadoc to explain
[gwt-contrib] Re: [google-web-toolkit] [EMAIL PROTECTED] commented on revision r4098.
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 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 true in JS? I would expect the interpreter to > have so many branches in expression evaluation that you don't pay any more > here, and the early-out case would be significantly faster. > > -- > John A. Tamplin > Software Engineer (GWT), Google > > > > > --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: [google-web-toolkit] [EMAIL PROTECTED] commented on revision r4098.
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 true in JS? I would expect the interpreter to have so many branches in expression evaluation that you don't pay any more here, and the early-out case would be significantly faster. -- John A. Tamplin Software Engineer (GWT), Google --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] [google-web-toolkit] [EMAIL PROTECTED] commented on revision r4098.
[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 branches, which is faster. Respond to these comments at http://code.google.com/p/google-web-toolkit/source/detail?r=4098 -- You received this message because you starred this review, or because your project has directed all notifications to a mailing list that you subscribe to. You may adjust your review notification preferences at: http://code.google.com/hosting/settings --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: Linker artifacts in WAR
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
SERVING=www -dir CONTEXT=... etc. By default if nothing but -out is
supplied (or if no "master output format" option is supplied), everything
defaults as it does now. If -war dir is supplied, that creates a different
set of defaults for all these categories, but can still be overridden by
doing something like -war war -dir EXTRA=myCustomExtra.
I think it might be useful to have some form of variable substitution on
these, so you could include the module name at different places in the path
as appropriate. So, for backwards compatibility EXTRA's default could be
{outDir}/{moduleDeployTo}-aux.
--
John A. Tamplin
Software Engineer (GWT), Google
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---
[gwt-contrib] When to use Serializbale / IsSerializable
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 used in SerializableResponse as long as it will not extend the IsSerializable interface. When using Serializable instead the same problem will arise with classes implementing IsSerializable. Any ideas? --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] [google-web-toolkit] t.broyer commented on revision r4122.
[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 isXXXKeyDown() aren't supposed to have any side effect, are they? so if, say, isControlKeyDown() is true, then "any modifier key" is down; no need to check that any other modifier key is down too. (this question applies to both this rev and the previous one) Respond to these comments at http://code.google.com/p/google-web-toolkit/source/detail?r=4122 -- You received this message because you starred this review, or because your project has directed all notifications to a mailing list that you subscribe to. You may adjust your review notification preferences at: http://code.google.com/hosting/settings --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: Proposal: Extracting gwt-incubator-servlet.jar
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 fixed but isn't in an official eclipse release yet. The > bug shows up in our RPC generator when you try to pass a Request or Response > object over RPC. We'll combine TableModelHelper back into TableModel once > the next Eclipse version is officially released and people have time to > switch to it. > > GWT issue:http://code.google.com/p/google-web-toolkit/issues/detail?id=2731 > > Eclipse issue:https://bugs.eclipse.org/bugs/show_bug.cgi?id=243820 > > Thanks, > John LaBanca > [EMAIL PROTECTED] > > On Wed, Nov 19, 2008 at 11:22 AM, dflorey <[EMAIL PROTECTED]> wrote: > > > While I've been moving TableModelHelper to shared I was wondering why > > this class is needed. > > From my point of view it is only a container for all rpc relevant > > classes. > > I'm a big fan of not producing too many classes but I'd prefer to make > > the nested classes top level classes. > > Eclipse fails to organize imports with these nested classes, but that > > is just one reasone behind it. > > What do you think? > > I'll move them to top level in my branch to see what happens... > > > On 19 Nov., 17:00, Emily Crutcher <[EMAIL PROTECTED]> wrote: > > > Thanks! > > > > On Wed, Nov 19, 2008 at 10:39 AM, dflorey <[EMAIL PROTECTED]> > > wrote: > > > > > I've just seen that there are already server and shared packages in > > > > the logging lib. > > > > So we need a shared package for the tables containing: > > > > Request, Reponse, SerializableResponse, ColumnSortInfo, > > > > ColumnSortInfoList (and maybe some others I've missed). > > > > I'll create an ant task in my branch to see if I manage to strip down > > > > a gwt-incubator-servlet.jar > > > > > On 19 Nov., 15:28, Emily Crutcher <[EMAIL PROTECTED]> wrote: > > > > > That sounds like a great idea. Could you create a list of classes > > you > > > > think > > > > > should be either > > > > > a) moved to the new gwt-incubator-servlet.jar > > > > > b) copied to the new gwt-incubator-servlet.jar > > > > > > and send it out to the group? > > > > > > On Wed, Nov 19, 2008 at 5:49 AM, dflorey <[EMAIL PROTECTED]> > > > > wrote: > > > > > > > Hi, > > > > > > some of the incubator classes are required on the server side > > > > > > (especially the table request & response, sort info classes etc.) > > > > > > I've read somewhere that these classes should be placed in a > > "shared" > > > > > > package. > > > > > > No clue if it causes trouble to move the serializable classes to > > such > > > > > > a package (as they are right now in the TableModelHelper class > > because > > > > > > of eclise compiler issues) but if possible I'd vote for extracting > > > > > > these classes into a gwt-incubator-servlet.jar. > > > > > > -- > > > > > "There are only 10 types of people in the world: Those who understand > > > > > binary, and those who don't" > > > > -- > > > "There are only 10 types of people in the world: Those who understand > > > binary, and those who don't" --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: Code review on date picker branch to date
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.
Proposal: Add ChangeListener support and add a "Date getValue()"
method.
On 20 Nov., 04:26, 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? Or, should
> getCalendarView perhaps go away, or become protected or package--is it
> really useful/safe for clients to talk to it directly?
>
> ElementMapper.java
>
> We need ElementMapperTest
>
> The param type MappedType should be a single letter, perhaps U
>
> What's going on Iterator#remove? This class claims to work on UIObjects, but
> here you are casting to Widget and asserting that parent is an HTMLTable.
>
> CalendarModel.java
>
> We need CalendarModelTest
>
> So this class has the notion of the current date shared by the various
> moving parts, and it does formatting, yes? Could punch up its javadoc to
> that effect.
>
> What is that no-op refresh() method there for?
>
> DatePicker.java
>
> 1. It's confusing that there is a CalendarView named calendar, and a
> CalendarModel named model. I'd expect the view to be named view, and the
> model to be named calendar.
>
> 2. It seems like many fields here could be final.
>
> 3. The Css interface is protected, but I though we were going to make it
> private, or at least package protected. It is also featured in a ton of
> public methods and constructors. That's no good.
>
> If it does wind up staying visible, having a public static setDefaultCss
> method is a bad idea. Allowing it to be overridden per instance is plenty.
>
> 4. getDateShown() is implemented as getModel().getCurrentMonth(). Isn't that
> a bug? If not, shouldn't the method be called getMonthShown()?
>
> 5. It seems like these methods:
>
> public final void addStyleToVisibleDate(Date visibleDate, String
> styleName) {
> calendar.addStyleToDate(visibleDate, styleName);
> }
>
> public final void addStyleToVisibleDates(Iterable visibleDates,
> String styleName) {
> getCalendarView().addStyleToDates(visibleDates, styleName);
> }
>
> could instead be
>
> public final void addStyleToVisibleDates(String styleName, Date...
> visibleDates) {
> addStyleToVisibleDates(styleName, Arrays.asList(visibleDates));
> }
>
> public final void addStyleToVisibleDates(String styleName, Iterable
> visibleDates) {
> getCalendarView().addStyleToDates(visibleDates, styleName);
> }
>
> Even if not, why is one using calendar and the other using
> getCalendarView()?
>
> And note that the remove method is not parallel to these--there is only one.
>
> 6. getHighlightedDate() javadoc should explain diff between selected and
> highlighted. class doc should probably do the same.
>
> 7. getGlobalStyleOfDate() What is a global style? Is this a GWT wide
> concept? If not, needs explicating.
>
> 8. showDate() Need to explain how this differs from setValue(), and link
> between the two methods.
>
> 9. What is the package private setModel(CalendarModel) needed for?
>
> 10. Some methods are final, and some aren't. It seems very arbitrary. And we
> should be documenting final methods to explain why.
>
> 11. This seems harsh (the assert, I mean):
>
> public final void setEnabledOnVisibleDate(Date date, boolean enabled) {
>
> assert isDateVisible(date) : date
>
> + " cannot be enabled or disabled as it is not visible";
>
> getCalendarView().setDateEnabled(date, enabled);
>
> }
>
> What happens if they disable a date, the user scrolls it away, and then
> scrolls it back? Do they have to listen for these scroll events and then
> reapply the disables? Is this a method people actually asked for, can we get
> rid of it?
>
> 12. setAllowableDates says it is "not yet implemented for the default case".
> Why is it here, then?
>
> DateBox.java
>
> 1. Constitutent fields (box, picker, popup) should be final
>
> DefaultMonthSelector.java
>
> JavaDoc says that it is "not part of the public API". If it's a public class
> and can be used as an arg to a protected constructor, it's public, let's be
> honest here. Perhaps you meant "not extensible"? As for "please feel to copy
> it...", that's a pretty severe mixed message.
>
> I don't really see what we're gaining by encouraging people to copy it and
> then claiming that it's not public and subject to change. If they copy it,
> we will break them. We're providing a protected constructor that accepts
> this. That's public api. We need to make up our minds--providing your own
> CalendarView and MonthSelector is supported, or it isn't.
>
> MonthSelector.java
>
> More of the same. This class contributes b
