[gwt-contrib] Re: Proposal: Simplification of ScrollTable
Copy from #190 I like the idea of providing additional default/simple implementations to make constructing a very basic PagingScrollTable easier. Of course, this should be done (if at all possible) without reducing the current flexibility of PST. To address specifics: 1. Consolidating the PST genealogy. This hasn't really bothered me. I haven't personally found a use for ScrollTable, since I'm very much attached to the model-driven PST. AbstractScrollTable just seems like an inheritance artifact, which I find acceptable (although I know that at least one element in the GWT team would dissent). But if consolidation would make things easier/safer/tighter or any other way better, it's worth considering. 2. Adding a title and tooltip to the ColumnDefinitions. This seems reasonable as an option for streamlined PST construction. Caveat retaining flexibility. 3. Provide a default data table. I like this option as well. User's can always pass in their own data table to retain more control over it. 4. Provide simple client side table model taking a list or array. Doesn't this already exist as IterableTableModel? 5. Annotations for column definitions. I'm not a huge fan of this idea, but I can see how some might prefer it. As long as other ColumnDefinition schemes aren't neglected, this seems like an interesting avenue to explore. --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: Flurry of Data binding threads
Hello Rahul, Here's some of the projects: gwt-data-binding: http://code.google.com/p/gwt-data-binding/ gwt-validation: http://code.google.com/p/gwt-validation/ I'm working on visibility logic as we speak, I'll make a post when I get the chance. I am also wondering what the status of the GWT teams solution is. Regards, -- Arthur Kalmenson On Thu, Nov 13, 2008 at 8:41 PM, rahul [EMAIL PROTECTED] wrote: Hello Emily, *Metadata Systems, comprising Models and Controllers* xforms, Ian's databinding system, Arthur's validation system, gwt team's upcoming proposal for data management: Do you have links to the above resources please, where we could find more details/sources? Also, you mentioned GWT team's upcoming proposal for data management - is it available online yet? Thanks, Rahul --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: a patch for legacy argument support
On Mon, Nov 17, 2008 at 1:15 AM, John Tamplin [EMAIL PROTECTED] wrote: Shouldn't Link.java:157 refer to Link? Yes; fixed, and thanks. Won't this mean if you just run the precompile step it will automatically create one if not specified? I think it should fail if you run the steps separately without supplying -workDir, and you only get a default if you run GwtCompiler. As written, yes. I'm okay with either specification... change attached. I don't like the race condition in ensureWorkDir -- I know Java doesn't support the equivalent of mkdtemp, but I think rather than creating a unique file and trying to reuse that name for a directory I would rather just atomically create a random directory and try another if it fails -- basically implementing mkdtemp ourselves. Well, if we're going to do that, let's put it into Utility, so we have a general-purpose mkdtemp equivalent... attached. And, in that case, do we want such spontaneous workDirs to be (best-effort) cleaned up at shutdown, via File.deleteOnExit()? I wouldn't delete a manually-specified workDir, even in GWTCompiler, but an implicit one might keep the accumulated trash down... Which is a big enough change I probably shouldn't rely on your prior LGTM. --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~--- flagupdates-1.6-r4033-2.patch Description: Binary data
[gwt-contrib] Re: Flurry of Data binding threads
On Mon, Nov 17, 2008 at 6:11 AM, Arthur Kalmenson [EMAIL PROTECTED]wrote: Hello Rahul, Here's some of the projects: gwt-data-binding: http://code.google.com/p/gwt-data-binding/ gwt-validation http://code.google.com/p/gwt-data-binding/gwt-validation: http://code.google.com/p/gwt-validation/ I'm working on visibility logic as we speak, I'll make a post when I get the chance. I am also wondering what the status of the GWT teams solution is. Hi, all. Our plan is to start looking in earnest at data binding and validation issues in Q1, and it will be a from-scratch type of effort--though we'll certainly be eagerly looking through the two projects Arthur links to for guidance an inspiration. Nearer term, the declarative ui work that we've been talking up for quite a while now ( http://code.google.com/p/google-web-toolkit-incubator/wiki/UiBinder) should hit the incubator in a matter of weeks. rjrjr Regards, -- Arthur Kalmenson On Thu, Nov 13, 2008 at 8:41 PM, rahul [EMAIL PROTECTED] wrote: Hello Emily, *Metadata Systems, comprising Models and Controllers* xforms, Ian's databinding system, Arthur's validation system, gwt team's upcoming proposal for data management: Do you have links to the above resources please, where we could find more details/sources? Also, you mentioned GWT team's upcoming proposal for data management - is it available online yet? Thanks, Rahul --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: a patch for legacy argument support
Yeah, I'd misunderstood the deleteOnExit() doc to imply recursive deletion, but they're hanging around. Also a small bug, I'd failed to shift my random number (so I got 5 repeated digits, and a random space of 36 vice 36^5). Both fixes attached... It turns out that a try/finally to do the cleanup interacts poorly with System.exit (which seems to really exit, right then, and so skip my finally block)... thus the code duplication in GWTCompiler.main(). On Mon, Nov 17, 2008 at 11:24 AM, John Tamplin [EMAIL PROTECTED] wrote: On Mon, Nov 17, 2008 at 11:15 AM, Freeland Abbott [EMAIL PROTECTED] wrote: Well, if we're going to do that, let's put it into Utility, so we have a general-purpose mkdtemp equivalent... attached. And, in that case, do we want such spontaneous workDirs to be (best-effort) cleaned up at shutdown, via File.deleteOnExit()? I wouldn't delete a manually-specified workDir, even in GWTCompiler, but an implicit one might keep the accumulated trash down... Right, I forgot to mention the cleanup in the earlier email. I think an automatically generated one should be cleaned up, but I don't think deleteOnExit will do it if it has files in it, since delete on a directory with files will fail. In this case, we don't need the on-exit hook, since we know it has to come back trhough GwtCompiler.main anyway. Which is a big enough change I probably shouldn't rely on your prior LGTM. I'll look at it closer shortly, but we really need Scott to look at it since he made the original changes. -- John A. Tamplin Software Engineer (GWT), Google --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~--- flagupdates-1.6-r4033-3.patch Description: Binary data
[gwt-contrib] History list problem in IE6 - Do I really need to patch GWT's jar
I am using GWT 1.5 and want to manage history. Whenever I call
History.newItem(token), Mozilla displays the window title in history
list But Internet Explorer shows
http://localhost:/com.TestEntry/8DF40326B05334ADE3B6DCA8E9DD3DA2
in the list i.e. URL of my page instead of showing window title. When
I drilled, I noticed an issue in HistoryImplIE6's newItemImpl method.
It was written as below:
protected native void newItemImpl(Element historyFrame, String
historyToken, boolean forceAdd) /*-{
historyToken = historyToken || ;
if (forceAdd || ($wnd.__gwt_historyToken != historyToken)) {
var doc = historyFrame.contentWindow.document;
doc.open();
doc.write('htmlbody onload=if(parent.__gwt_onHistoryLoad)
parent.__gwt_onHistoryLoad(__gwt_historyToken.innerText)div
id=__gwt_historyToken' + historyToken + '/div/body/html');
doc.close();
}
}-*/;
It adds an IFrame without specifying title tag.
If IFrame does not have title then it will display the complete URL in
history list. For a solution, I applied a patch in this class where I
took the window title and put it into head tag as below:
protected native void newItemImpl(Element historyFrame, String
historyToken, boolean forceAdd) /*-{
historyToken = historyToken || ;
if (forceAdd || ($wnd.__gwt_historyToken != historyToken)) {
var doc = historyFrame.contentWindow.document;
doc.open();
var windowTitle = $wnd.document.title;
doc.write('htmlheadtitle'+windowTitle+'/title/
headbody onload=if(parent.__gwt_onHistoryLoad)
parent.__gwt_onHistoryLoad(__gwt_historyToken.innerText)div
id=__gwt_historyToken' + historyToken + '/div/body/html');
doc.close();
}
}-*/;
and now IE is also showing window title in History list.
Now my question is: is it a bug of GWT ? And is there any other
alternate for this so that I need not to make a patch in GWT's jar.
Any help or suggestion in this regard will be highly appreciated.
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---
[gwt-contrib] Review of handler map speed test.
Kelly, Could you review this visual benchmark I was using to compute the pros/cons of the different handler maps? Of particular interest is the SimpleJsHandlerMap, to see if there is anything, well, simple we we can do to make it faster. http://code.google.com/p/google-web-toolkit/source/detail?r=4089 -- 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] r4089 - in branches/1_6_clean_events/reference/code-museum/src/com/google/gwt: event event/shared...
Author: [EMAIL PROTECTED]
Date: Mon Nov 17 11:49:13 2008
New Revision: 4089
Added:
branches/1_6_clean_events/reference/code-museum/src/com/google/gwt/event/
branches/1_6_clean_events/reference/code-museum/src/com/google/gwt/event/shared/
branches/1_6_clean_events/reference/code-museum/src/com/google/gwt/event/shared/GwtEventUtil.java
branches/1_6_clean_events/reference/code-museum/src/com/google/gwt/museum/client/defaultmuseum/SpeedOfHandlerMap.java
Log:
Adding the speed test for different types of handler maps. Will be
recommitted to 1.6 release branch after review.
Added:
branches/1_6_clean_events/reference/code-museum/src/com/google/gwt/event/shared/GwtEventUtil.java
==
--- (empty file)
+++
branches/1_6_clean_events/reference/code-museum/src/com/google/gwt/event/shared/GwtEventUtil.java
Mon Nov 17 11:49:13 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.event.shared;
+
+import com.google.gwt.event.shared.GwtEvent.Type;
+
+/**
+ * Utility class to help with managing events.
+ */
+public class GwtEventUtil {
+
+ /**
+ * Fire the event on the given handler.
+ *
+ * @param event the event to dispatch
+ * @param handler the handler to dispatch it to
+ * @param H the event's handler type
+ *
+ */
+ public static H extends EventHandler void dispatch(GwtEventH event,
+ H handler) {
+event.dispatch(handler);
+ }
+
+ /**
+ * Gets the event's type.
+ *
+ * @param H handler type
+ *
+ * @param event the event
+ * @return the associated type
+ */
+ public static H extends EventHandler TypeH getType(GwtEventH
event) {
+return event.getAssociatedType();
+ }
+
+ private GwtEventUtil() {
+// Utility class, should not have instances.
+ }
+}
Added:
branches/1_6_clean_events/reference/code-museum/src/com/google/gwt/museum/client/defaultmuseum/SpeedOfHandlerMap.java
==
--- (empty file)
+++
branches/1_6_clean_events/reference/code-museum/src/com/google/gwt/museum/client/defaultmuseum/SpeedOfHandlerMap.java
Mon Nov 17 11:49:13 2008
@@ -0,0 +1,708 @@
+/*
+ * 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.museum.client.defaultmuseum;
+
+import com.google.gwt.core.client.Duration;
+import com.google.gwt.core.client.GWT;
+import com.google.gwt.core.client.JavaScriptObject;
+import com.google.gwt.event.dom.client.ClickEvent;
+import com.google.gwt.event.dom.client.ClickHandler;
+import com.google.gwt.event.dom.client.HandlesAllMouseEvents;
+import com.google.gwt.event.dom.client.KeyDownEvent;
+import com.google.gwt.event.dom.client.KeyPressEvent;
+import com.google.gwt.event.dom.client.KeyUpEvent;
+import com.google.gwt.event.dom.client.MouseDownEvent;
+import com.google.gwt.event.dom.client.MouseMoveEvent;
+import com.google.gwt.event.dom.client.MouseOutEvent;
+import com.google.gwt.event.dom.client.MouseOverEvent;
+import com.google.gwt.event.dom.client.MouseUpEvent;
+import com.google.gwt.event.dom.client.MouseWheelEvent;
+import com.google.gwt.event.shared.EventHandler;
+import com.google.gwt.event.shared.GwtEvent;
+import com.google.gwt.event.shared.GwtEventUtil;
+import com.google.gwt.event.shared.GwtEvent.Type;
+import com.google.gwt.museum.client.common.AbstractIssue;
+import com.google.gwt.user.client.ui.Button;
+import com.google.gwt.user.client.ui.Composite;
+import com.google.gwt.user.client.ui.FlexTable;
+import com.google.gwt.user.client.ui.HTML;
+import com.google.gwt.user.client.ui.HorizontalPanel;
+import com.google.gwt.user.client.ui.ListBox;
+import com.google.gwt.user.client.ui.Panel;
+import com.google.gwt.user.client.ui.TextBox;
+import com.google.gwt.user.client.ui.VerticalPanel;
[gwt-contrib] RR: Adding .project to gwt-incubator root directory
Several months ago we had the discussion of whether it was worth polluting the root directory of gwt-incubator with eclipse specific project files in order to make sub-eclipse and/or other subversion plugins to work correctly with the gwt-incubator source. At the time, there was a lot of discussion about that potential change, so we pended the issue and I tried running with an experimental eclipse config for a while. My conclusion after running with the alternative eclipse config, is that subversion is an extremely useful tool when doing the creation/refactoring work that is common when growing new libraries. Therefore, would any of you (particularly the non-eclipse users) object to having a checked in .project, .classpath, and .checkstyle files in the root directory of the gwt-incubator project? Thanks, Emily -- 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 .project to gwt-incubator root directory
No objections :) Fred Sauer [EMAIL PROTECTED] On Mon, Nov 17, 2008 at 1:18 PM, Emily Crutcher [EMAIL PROTECTED] wrote: Several months ago we had the discussion of whether it was worth polluting the root directory of gwt-incubator with eclipse specific project files in order to make sub-eclipse and/or other subversion plugins to work correctly with the gwt-incubator source. At the time, there was a lot of discussion about that potential change, so we pended the issue and I tried running with an experimental eclipse config for a while. My conclusion after running with the alternative eclipse config, is that subversion is an extremely useful tool when doing the creation/refactoring work that is common when growing new libraries. Therefore, would any of you (particularly the non-eclipse users) object to having a checked in .project, .classpath, and .checkstyle files in the root directory of the gwt-incubator project? Thanks, Emily -- 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 .project to gwt-incubator root directory
On Mon, Nov 17, 2008 at 3:18 PM, Emily Crutcher [EMAIL PROTECTED] wrote: Several months ago we had the discussion of whether it was worth polluting the root directory of gwt-incubator with eclipse specific project files in order to make sub-eclipse and/or other subversion plugins to work correctly with the gwt-incubator source. At the time, there was a lot of discussion about that potential change, so we pended the issue and I tried running with an experimental eclipse config for a while. My conclusion after running with the alternative eclipse config, is that subversion is an extremely useful tool when doing the creation/refactoring work that is common when growing new libraries. Therefore, would any of you (particularly the non-eclipse users) object to having a checked in .project, .classpath, and .checkstyle files in the root directory of the gwt-incubator project? Do any other tools also use .project, for example? If so, you can't have that file used for that tool or it may get trashed on subsequent update. Having the files in an eclipse directory seems much cleaner, and the main trunk of GWT works this way. Also, other IDEs like VisualStudio can work with project files in a subdirectory, which is how the OOPHM build works. What exactly is the reason we can't do the same here? Even if it is an issue, why would we not leave the files in an eclipse subdirectory and have interested users simply copy them to their trunk directory so we don't trash any other similarly named files there? -- John A. Tamplin Software Engineer (GWT), Google --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: RR: Adding .project to gwt-incubator root directory
What exactly is the reason we can't do the same here? subclipse won't handle linked resources. Even if it is an issue, why would we not leave the files in an eclipse subdirectory and have interested users simply copy them to their trunk directory so we don't trash any other similarly named files there? Drift. -- Bob Vawter Google Web Toolkit Team --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Event handlers committed to 1.6, event listeners deprecated
With r4092, the new event handlers have been committed to the 1.6 branch. rjrjr --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] [google-web-toolkit commit] r4093 - releases/1.6
Author: [EMAIL PROTECTED] Date: Mon Nov 17 21:06:07 2008 New Revision: 4093 Modified: releases/1.6/branch-info.txt Log: branch-info.txt updated with event handler merge change #. TBR scottb Modified: releases/1.6/branch-info.txt == --- releases/1.6/branch-info.txt(original) +++ releases/1.6/branch-info.txtMon Nov 17 21:06:07 2008 @@ -11,6 +11,6 @@ /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 (r) into trunk -/branches/[EMAIL PROTECTED]:4088 was merged (r) into this branch +/branches/[EMAIL PROTECTED]:4088 was merged (r4092) into this branch --- The next merge into trunk will be 4025:HEAD --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] RR 1.6 (tbr): branch-info.txt updated
Scott, I updated 1.6 branch-info.txt with the event listener change number, figuring you could TBR it. http://code.google.com/p/google-web-toolkit/source/detail?r=4093 rjrjr --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] RR: Merging releases/1.5 into releases/1.6 to pick up reference/dispatch
This is step two of three of committing your event dispatch benchmark. Step one was checking the 1.5 version into releases/1.5/reference/dispatch. Now I'm merging that into releases/1.6. The third and final step will be a patch updating 1.6/reference/dispatch with your event handler changes. I'm not sure how one gets a merge reviewed, as svn diff doesn't show the A + adds. But, FWIW... I performed the merge thus: svn merge -r 3863:4093 http://google-web-toolkit.googlecode.com/svn/releases/1.5 and saw only the correct files picked up: 21:28:50 svn st A + reference/dispatch A + reference/dispatch/client A + reference/dispatch/client/Dispatch.java A + reference/dispatch/client/Subject.java A + reference/dispatch/public A + reference/dispatch/public/Dispatch.html A + reference/dispatch/Dispatch.gwt.xml M branch-info.txt and have updated the branch-info.txt: 21:24:03 svn diff Index: branch-info.txt === --- branch-info.txt (revision 4093) +++ branch-info.txt (working copy) @@ -12,5 +12,6 @@ /releases/1.6/@r3878:3944 was merged (r3945) into trunk, skipping c3878 /releases/1.6/@r3944:4025 was merged (r) 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 --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
