[gwt-contrib] [google-web-toolkit commit] r3713 - changes/jat/oophm-branch/dev/core/src/com/google/gwt/dev/util/log
Author: [EMAIL PROTECTED]
Date: Mon Oct 6 00:08:26 2008
New Revision: 3713
Modified:
changes/jat/oophm-branch/dev/core/src/com/google/gwt/dev/util/log/SwingLoggerPanel.java
changes/jat/oophm-branch/dev/core/src/com/google/gwt/dev/util/log/SwingTreeLogger.java
Log:
Added find functionality to Swing tree logger.
Modified:
changes/jat/oophm-branch/dev/core/src/com/google/gwt/dev/util/log/SwingLoggerPanel.java
==
---
changes/jat/oophm-branch/dev/core/src/com/google/gwt/dev/util/log/SwingLoggerPanel.java
(original)
+++
changes/jat/oophm-branch/dev/core/src/com/google/gwt/dev/util/log/SwingLoggerPanel.java
Mon Oct 6 00:08:26 2008
@@ -23,16 +23,21 @@
import java.awt.Color;
import java.awt.Component;
import java.awt.Dimension;
+import java.awt.FlowLayout;
import java.awt.HeadlessException;
+import java.awt.Point;
import java.awt.datatransfer.Clipboard;
import java.awt.datatransfer.StringSelection;
import java.awt.event.ActionEvent;
import java.awt.event.ActionListener;
import java.awt.event.InputEvent;
import java.awt.event.KeyEvent;
+import java.util.ArrayList;
import java.util.Enumeration;
import javax.swing.AbstractAction;
+import javax.swing.BorderFactory;
+import javax.swing.ImageIcon;
import javax.swing.JButton;
import javax.swing.JComboBox;
import javax.swing.JComponent;
@@ -45,6 +50,8 @@
import javax.swing.JTextField;
import javax.swing.JTree;
import javax.swing.KeyStroke;
+import javax.swing.Popup;
+import javax.swing.PopupFactory;
import javax.swing.event.TreeSelectionEvent;
import javax.swing.event.TreeSelectionListener;
import javax.swing.tree.DefaultMutableTreeNode;
@@ -59,6 +66,135 @@
*/
public class SwingLoggerPanel extends JPanel implements
TreeSelectionListener {
+ private class FindBox extends JPanel {
+
+private JTextField searchField;
+private JLabel searchStatus;
+
+private Popup findPopup;
+
+private String lastSearch;
+private int matchNumber;
+private ArrayListDefaultMutableTreeNode matches;
+
+public FindBox() {
+ super(new BorderLayout());
+ JPanel top = new JPanel(new FlowLayout());
+ searchField = new JTextField(20);
+ top.add(searchField);
+ JButton nextButton = new JButton(+);
+ top.add(nextButton);
+ nextButton.addActionListener(new ActionListener() {
+public void actionPerformed(ActionEvent e) {
+ nextMatch();
+}
+ });
+ JButton prevButton = new JButton(-);
+ top.add(prevButton);
+ prevButton.addActionListener(new ActionListener() {
+public void actionPerformed(ActionEvent e) {
+ prevMatch();
+}
+ });
+ JButton closeButton = new JButton(closeIcon);
+ closeButton.setBorderPainted(false);
+ closeButton.setPreferredSize(new Dimension(closeIcon.getIconWidth(),
+ closeIcon.getIconHeight()));
+ closeButton.setToolTipText(Close this search box);
+ top.add(closeButton);
+ KeyStroke key = KeyStroke.getKeyStroke(KeyEvent.VK_ESCAPE, 0);
+ getInputMap(WHEN_IN_FOCUSED_WINDOW).put(key, find-cancel);
+ key = KeyStroke.getKeyStroke(KeyEvent.VK_ENTER, 0);
+ getInputMap(WHEN_IN_FOCUSED_WINDOW).put(key, find-search);
+ getActionMap().put(find-search, new AbstractAction() {
+public void actionPerformed(ActionEvent e) {
+ lastSearch = searchField.getText();
+ matches = doFind(lastSearch);
+ matchNumber = 0;
+ updateSearchResult();
+}
+ });
+ AbstractAction closeFindBox = new AbstractAction() {
+public void actionPerformed(ActionEvent e) {
+ hideFindBox();
+}
+ };
+ getActionMap().put(find-cancel, closeFindBox);
+ closeButton.addActionListener(new ActionListener() {
+public void actionPerformed(ActionEvent e) {
+ hideFindBox();
+}
+ });
+ add(top, BorderLayout.NORTH);
+ searchStatus = new JLabel(Type search text and press Enter);
+ searchStatus.setBorder(BorderFactory.createEmptyBorder(0, 2, 2, 0));
+ add(searchStatus, BorderLayout.SOUTH);
+}
+
+public void hideBox() {
+ if (findPopup != null) {
+findPopup.hide();
+findPopup = null;
+ }
+}
+
+public void nextMatch() {
+ if (matches != null matches.size() 0) {
+matchNumber = (matchNumber + 1) % matches.size();
+updateSearchResult();
+ }
+}
+
+public void prevMatch() {
+ if (matches != null) {
+int n = matches.size();
+if (n 0) {
+ matchNumber = (matchNumber + n - 1) % n;
+ updateSearchResult();
+}
+ }
+}
+
+public void showBox() {
+ Point loggerOrigin = details.getLocationOnScreen();
+ Dimension dim = details.getSize();
+ if (findPopup != null) {
+findPopup.hide();
+ }
+ // have to
[gwt-contrib] Re: Incubator review request: HasValue
Good enough to commit it for me? :) On Sat, Oct 4, 2008 at 10:33 AM, Emily Crutcher [EMAIL PROTECTED] wrote: LGTM On Fri, Oct 3, 2008 at 9:16 PM, Isaac Truett [EMAIL PROTECTED] wrote: Oops. My *other* datepicker, right. Here's the new patch with gen2 datepicker and implementing HasValue on DropDownListBox instead of CustomListBox. Thanks, Isaac On Fri, Oct 3, 2008 at 6:21 PM, Emily Crutcher [EMAIL PROTECTED] wrote: I like the feel of it, can you patch against the gen2 datepicker though? Also, I think we might want to move the HasValue interface from CustomListBox to DropDownListBox, as we plan to eventually have a MultiSelectListBox and therefore, we might want to keep our options open. On Fri, Oct 3, 2008 at 5:43 PM, Isaac Truett [EMAIL PROTECTED] wrote: I originally proposed a HasValue interface in this threadhttp://groups.google.com/group/Google-Web-Toolkit-Contributors/browse_thread/thread/b696e7319fc6bea. Although the discussion largely focused on data binding, HasValue is not an attempt at a data binding library. The HasValue concept is more about providing a common API for many Widgets and other Objects that have a distinct logical value. This is conceptually the same as HasText, but parameterized to allow for data types other than String. The attached patch to the Incubator trunk includes the HasValue interface and implements this interface in DropDownListBox and DatePicker. -- 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: RR: 1.6 Event handler proposal
This a nice optimization, and one certainly worth keeping in mind. As
part of this transition, I'll be creating some more benchmarks on
performance, and might try it then to see if it makes any practical
difference.
Thanks!
Emily
On Mon, Oct 6, 2008 at 5:54 AM, Thomas Broyer [EMAIL PROTECTED] wrote:
On 22 sep, 22:02, Emily Crutcher [EMAIL PROTECTED] wrote:
A more complete implementation of the event handlers has been added to
the gwt-incubator
gen2.event package
http://code.google.com/p/google-web-toolkit-incubator/source/browse/#
Implementation-detail note: why is DomEvent using getTypeInt()? Why
not using getType()? It would save some string-to-int translation
code (see issue 2927), and given that the value is only used as a key
within DomEvent.WrappedKeyMap, I can't see a drawback (on the
contrary: adding support for other dom events –e.g. drag'n'drop, cut/
copy/paste, text selection, etc.– could then be done without the need
to rewrite/overwrite this string-to-int mapping). Of course, the
string-to-int mapping is still necessary for sinkEvents
(addHandlerAndSink) to work, but it would be done at registration-time
only, and not for every fired event!
This means however, that DomEvent.Key has to keep track of both the
int *and* the string event type (shouldn't this be somehow optimized
by the JSStringInterner?), and that DomEvent-derived classes thus have
to be kept synchronized with the getTypeInt()/sinkEvents() code (not
a big deal, this is an almost-never-changing code).
...but there are some events that have different names (mousewheel/
DOMMouseScroll). DomEvent.Key could have a register() abstract method
(with register(String name) helper method), or variations along this
line (e.g. constructor accepting an additional String eventName and
calling register(eventName), for the common case, and ScrollEvent
defining its own instance initializer code to call register() once
more with the second name):
public abstract static class KeyEventType extends DomEvent,
HandlerType extends EventHandler
extends AbstractEvent.KeyEventType, HandlerType {
int nativeEventType;
/**
* Creates a [EMAIL PROTECTED] Key}. Each event should have a singleton
key.
*/
public Key(int nativeEventType) {
this.nativeEventType = nativeEventType;
register();
}
protected final void register(String eventName) {
registered.put(eventName, this);
}
protected abstract void register();
...
public static final KeyScrollEvent, ScrollHandler KEY = new new
KeyScrollEvent, ScrollHandler(
Event.ONSCROLL) {
protected void register() {
register(mousewheel);
register(DOMMouseScroll);
}
@Override
protected void fire(ScrollHandler handler, ScrollEvent event) {
handler.onScroll(event);
}
@Override
public ScrollEvent wrap(Event nativeEvent) {
return new ScrollEvent(nativeEvent);
}
};
--
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: Incubator review request: HasValue
Does this mean that all the GWT core widgets will implement the HasValue interface? On Oct 4, 10:33 am, Emily Crutcher [EMAIL PROTECTED] wrote: LGTM On Fri, Oct 3, 2008 at 9:16 PM, Isaac Truett [EMAIL PROTECTED] wrote: Oops. My *other* datepicker, right. Here's the new patch with gen2 datepicker and implementing HasValue on DropDownListBox instead of CustomListBox. Thanks, Isaac On Fri, Oct 3, 2008 at 6:21 PM, Emily Crutcher [EMAIL PROTECTED] wrote: I like the feel of it, can you patch against the gen2 datepicker though? Also, I think we might want to move the HasValue interface from CustomListBox to DropDownListBox, as we plan to eventually have a MultiSelectListBox and therefore, we might want to keep our options open. On Fri, Oct 3, 2008 at 5:43 PM, Isaac Truett [EMAIL PROTECTED] wrote: I originally proposed a HasValue interface in this threadhttp://groups.google.com/group/Google-Web-Toolkit-Contributors/browse Although the discussion largely focused on data binding, HasValue is not an attempt at a data binding library. The HasValue concept is more about providing a common API for many Widgets and other Objects that have a distinct logical value. This is conceptually the same as HasText, but parameterized to allow for data types other than String. The attached patch to the Incubator trunk includes the HasValue interface and implements this interface in DropDownListBox and DatePicker. -- 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: Incubator review request: HasValue
Thank you! Committed as r1093. On Mon, Oct 6, 2008 at 9:36 AM, Emily Crutcher [EMAIL PROTECTED] wrote: As you've proven your ability (several times now) to produce tight good code, I've added you as a gwt-incubator committer, so you should be able to commit it yourself On Mon, Oct 6, 2008 at 9:07 AM, Isaac Truett [EMAIL PROTECTED] wrote: Good enough to commit it for me? :) On Sat, Oct 4, 2008 at 10:33 AM, Emily Crutcher [EMAIL PROTECTED] wrote: LGTM On Fri, Oct 3, 2008 at 9:16 PM, Isaac Truett [EMAIL PROTECTED] wrote: Oops. My *other* datepicker, right. Here's the new patch with gen2 datepicker and implementing HasValue on DropDownListBox instead of CustomListBox. Thanks, Isaac On Fri, Oct 3, 2008 at 6:21 PM, Emily Crutcher [EMAIL PROTECTED] wrote: I like the feel of it, can you patch against the gen2 datepicker though? Also, I think we might want to move the HasValue interface from CustomListBox to DropDownListBox, as we plan to eventually have a MultiSelectListBox and therefore, we might want to keep our options open. On Fri, Oct 3, 2008 at 5:43 PM, Isaac Truett [EMAIL PROTECTED]wrote: I originally proposed a HasValue interface in this threadhttp://groups.google.com/group/Google-Web-Toolkit-Contributors/browse_thread/thread/b696e7319fc6bea. Although the discussion largely focused on data binding, HasValue is not an attempt at a data binding library. The HasValue concept is more about providing a common API for many Widgets and other Objects that have a distinct logical value. This is conceptually the same as HasText, but parameterized to allow for data types other than String. The attached patch to the Incubator trunk includes the HasValue interface and implements this interface in DropDownListBox and DatePicker. -- 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 -- 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: Proposed API Addition - PopupPanel.get/setModal() and PopupPanel.get/setAutoHide()
+1 here, as I've recently had to use the violator pattern to flip those bits. -jason On Oct 6, 2008, at 9:44 AM, John LaBanca wrote: Contributors - I propose adding the following accessors and getters to PopupPanel: public boolean isAutoHideEnabled() public boolean isModal() public void setAutoHideEnabled(boolean autoHide) public void setModal(boolean modal) Currently, autoHide and modal are private members of PopupPanel, so subclasses cannot change these values. From a cursory glance, it looks like PopupPanel checks these variables as needed, so implementing these methods would not require any special handling in case the PopupPanel is currently open. Here is the relevant issue: http://code.google.com/p/google-web-toolkit/issues/detail?id=2855 This seems like a valuable addition to the API, but I wanted to see if anyone has an obvious reason why we shouldn't add these methods. Thanks, John LaBanca [EMAIL PROTECTED] --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: RR: updates and design changes to incubator validation
va 1.5 features that are now available This is pretty straight forward. I would use typed lists in AbstractValidationController, make Subject a generic interface (for the value returned), and other minor changes. Yes. Use interfaces instead of abstract classes A lot of the main validation classes are abstract classes. Some examples are ErrorHandler, AbstractValidationController and Validator. This creates a lot of problems for unit testing these classes because you can't really mock them out, you have to instantiate them, etc. Therefore, I think it's better to make these classes interfaces and make an abstract concrete implementation that includes the current code. To me, this depends upon how well you can factor them into characteristic interfaces. What we want to avoid is an interface with a bundle of functionality where we locked out of adding more features. Some of the system might be able to be be mapped into the event handlers framework or something similar (i.e. a set of validation events consumed by validation handlers) this pattern gives the the advantages of interfaces, but can still be enhanced over time. Write test cases The validation library is currently missing unit tests, I'd like to add extensive tests. I wanted to use EasyMock (http:// www.easymock.org/) for testing some of the stuff that doesn't involve GWT.create() calls. EasyMock is under the MIT license, is it acceptable to use and include? Let me check with legal on this one. GWT code certainly runs with easy mock, however I don't know if we can bundle it with the gwt-incubator code. Remove static methods There are a number of static methods scattered around in classes like the DefaultTextBoxSubject, RegExValidator and ValidatorController. Static methods really make testing hard, and global states are in general bad. Is there a specific reason for these static methods? This is completely true of server side code, and therefore as validation is a shared system, we would definitely want to go over it with a fine-toothed comb. GWT Client side web applications, in general, are less subject to this rule, because 1. They are, by nature, single threaded 2. They are, by nature, single user 3. They run on JavaScript, so are,by nature, slow 4. They need to include the fewest lines of code possible, which means we must be very careful that the compiler can trace through when code is actually needed, in other words a lot of the injection-dependency systems which are perfect for server code end up creating really bad GWT apps. Annotation based validation What do you think about annotation based validation? It could look something like this: @NotEmptyValidator TextBox firstName = new TextBox(); @NumberRangeValidator(low = 18, high = 100) TextBox age = new TextBox(); I like the general principle, the devil, of course, will be in the details! Let me know what you think. Thank you. Regards, Arthur Kalmenson -- 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: Proposed API Addition - PopupPanel.get/setModal() and PopupPanel.get/setAutoHide()
@Emily In my case, I needed to create a modal non-autohiding DropDown Panel. however, the problem is that DropDown calls the PopupPanel constructor that creates a non-modal auto-hiding PopupPanel. Currently the only way to flip those bits subsequent to instantiation but prior to display is to use the violator pattern to set the private field values. I suppose that toggling those bits after the panel is displayed is pretty meaningless, and as such could maybe throw IllegalStateExcpetion. -jason On Oct 6, 2008, at 10:44 AM, Emily Crutcher wrote: +1 to public boolean isAutoHideEnabled() public boolean isModal() Why do we want to change whether auto hide/modality is enabled on an existing popup panel? It seems like if we do this we would need to check for edge cases that currently don't come up. On Mon, Oct 6, 2008 at 12:09 PM, Alex Rudnick [EMAIL PROTECTED] wrote: +1, sounds like a good idea. On Mon, Oct 6, 2008 at 11:54 AM, Jason Essington [EMAIL PROTECTED] wrote: +1 here, as I've recently had to use the violator pattern to flip those bits. -jason -- Alex Rudnick swe, gwt, atl -- 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: Proposed API Addition - PopupPanel.get/setModal() and PopupPanel.get/setAutoHide()
This seems like a pretty persuasive use case. On Mon, Oct 6, 2008 at 12:47 PM, Ray Ryan [EMAIL PROTECTED] wrote: +1 For one thing, it lets UI templates set their values without requiring custom parsers. Something like four different people have inspected the code for problems at this point and found none. rjrjr On Mon, Oct 6, 2008 at 12:44 PM, Emily Crutcher [EMAIL PROTECTED] wrote: +1 to public boolean isAutoHideEnabled() public boolean isModal() Why do we want to change whether auto hide/modality is enabled on an existing popup panel? It seems like if we do this we would need to check for edge cases that currently don't come up. On Mon, Oct 6, 2008 at 12:09 PM, Alex Rudnick [EMAIL PROTECTED] wrote: +1, sounds like a good idea. On Mon, Oct 6, 2008 at 11:54 AM, Jason Essington [EMAIL PROTECTED] wrote: +1 here, as I've recently had to use the violator pattern to flip those bits. -jason -- Alex Rudnick swe, gwt, atl -- 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] [google-web-toolkit commit] r3715 - trunk/user/src/com/google/gwt/dom/client
Author: [EMAIL PROTECTED]
Date: Mon Oct 6 10:22:53 2008
New Revision: 3715
Modified:
trunk/user/src/com/google/gwt/dom/client/DOMImplMozilla.java
Log:
Restoring removed innerContent change now that build is green.
Modified: trunk/user/src/com/google/gwt/dom/client/DOMImplMozilla.java
==
--- trunk/user/src/com/google/gwt/dom/client/DOMImplMozilla.java
(original)
+++ trunk/user/src/com/google/gwt/dom/client/DOMImplMozilla.javaMon Oct
6
10:22:53 2008
@@ -65,7 +65,7 @@
var style = $wnd.getComputedStyle($doc.documentElement, '');
return parseInt(style.marginLeft) + parseInt(style.borderLeftWidth);
}-*/;
-
+
@Override
public native int getBodyOffsetTop() /*-{
var style = $wnd.getComputedStyle($doc.documentElement, '');
@@ -73,10 +73,20 @@
}-*/;
@Override
+ public native String getInnerText(Element elem) /*-{
+return elem.textContent;
+ }-*/;
+
+ @Override
public native boolean isOrHasChild(Element parent, Element child) /*-{
// For more information about compareDocumentPosition, see:
// http://www.quirksmode.org/blog/archives/2006/01/contains_for_mo.html
return (parent === child) || !!(parent.compareDocumentPosition(child)
16);
+ }-*/;
+
+ @Override
+ public native void setInnerText(Element elem, String text) /*-{
+elem.textContent = text || '';
}-*/;
@Override
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---
[gwt-contrib] Re: Proposed API Addition - PopupPanel.get/setModal() and PopupPanel.get/setAutoHide()
@Emily - Looking at the code, I don't think there are any edge cases. We don't do any special setup/teardown if the bits are set, we just check them in onEventPreview. Also, I think its a valid use case to change them. For example, if somebody offers a user defined option to enable autoHide. Thanks, John LaBanca [EMAIL PROTECTED] On Mon, Oct 6, 2008 at 1:15 PM, Ray Ryan [EMAIL PROTECTED] wrote: John, when you do this it would be a good idea to add a test that toggles the bits a couple of times and sees that thing still works, so that we don't break it later. rjrjr On Mon, Oct 6, 2008 at 1:14 PM, Emily Crutcher [EMAIL PROTECTED] wrote: This seems like a pretty persuasive use case. On Mon, Oct 6, 2008 at 12:47 PM, Ray Ryan [EMAIL PROTECTED] wrote: +1 For one thing, it lets UI templates set their values without requiring custom parsers. Something like four different people have inspected the code for problems at this point and found none. rjrjr On Mon, Oct 6, 2008 at 12:44 PM, Emily Crutcher [EMAIL PROTECTED] wrote: +1 to public boolean isAutoHideEnabled() public boolean isModal() Why do we want to change whether auto hide/modality is enabled on an existing popup panel? It seems like if we do this we would need to check for edge cases that currently don't come up. On Mon, Oct 6, 2008 at 12:09 PM, Alex Rudnick [EMAIL PROTECTED] wrote: +1, sounds like a good idea. On Mon, Oct 6, 2008 at 11:54 AM, Jason Essington [EMAIL PROTECTED] wrote: +1 here, as I've recently had to use the violator pattern to flip those bits. -jason -- Alex Rudnick swe, gwt, atl -- 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] Small Test Framework For JJS Optimizers
Scott, - Could briefly summarize the motivation for the suite()/JJSOptimizerTestDecator design? This way the module will be compiled only once. Unfortunately JavaToJavaScriptCompiler doesn't have any easily extract compiling pass and I didn't want to seriously refactor it. - JJSOptimizerTestCase.staticJprogram strikes me as scary.. is this necessary? How else would you pass values from static context? - Textual comparison seems like a great first step, but a bit brittle going forward. I'd worry that changes in the compiler totally unrelated to an optimization pass would tend to unnecessarily break tests. That's a valid point and I saw this in the fast. I don't know a solution for this. Writing manual tree-based checks is even more fragile. However I do believe this is better than nothing. - Noticed many issues with things like sort order, formatting, spelling. Have you looked at the GWT eclipse setup? Opened everything in Eclipse and reformatted/reorder. See the attached patch. - Very high-level: We should talk about doing something more invasive to make testing lighter weight. There's really no reason to have to setup a GWT module to do a test... with some refactoring we could make it as easy as providing some input source and some output source. There still be a compilation step, right? Are you sure it will be easy to set up all binding, intrinsic stuff, etc. without the module? On Mon, Oct 6, 2008 at 7:49 AM, Scott Blum [EMAIL PROTECTED] wrote: Hi Mike, I'm really glad you broke ground on this. I took a look, but wanted to ask a question or two and give some high-level feedback before I dig in too much. - Could briefly summarize the motivation for the suite()/JJSOptimizerTestDecator design? - JJSOptimizerTestCase.staticJprogram strikes me as scary.. is this necessary? - Textual comparison seems like a great first step, but a bit brittle going forward. I'd worry that changes in the compiler totally unrelated to an optimization pass would tend to unnecessarily break tests. - Noticed many issues with things like sort order, formatting, spelling. Have you looked at the GWT eclipse setup? - Very high-level: We should talk about doing something more invasive to make testing lighter weight. There's really no reason to have to setup a GWT module to do a test... with some refactoring we could make it as easy as providing some input source and some output source. -- Regards, Mike --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: Patch: Build File Fix
Freeland, How's this? On Fri, Oct 3, 2008 at 6:43 PM, Freeland Abbott [EMAIL PROTECTED] wrote: The format for gwt.svnrev is [EMAIL PROTECTED], and if a real answer can't be determined it's set to [EMAIL PROTECTED], so I'd rather keep that pattern consistent instead of the 0 here. As a bigger change, though, I'd actually suggest pushing the test for .svn into SvnInfo.java; that already handles error conditions like the svn or svnversion binaries not being available, so it's a reasonable fit to check for workspace configuration there, and it makes the build file itself cleaner. General concept is fine, of course, but can we make those changes? On Fri, Oct 3, 2008 at 8:28 PM, Scott Blum [EMAIL PROTECTED] wrote: Freeland, it's all you. :) On Fri, Oct 3, 2008 at 8:23 PM, Mike Aizatsky [EMAIL PROTECTED] wrote: Hi! I've fixed build file to support working in non-svn workdir (e.g. git :). Can you please get this in? -- Regards, Mike -- Regards, Mike --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~--- ant_fix.patch Description: Binary data
[gwt-contrib] [google-web-toolkit commit] r3716 - changes/spoon/runAsync/dev/core/src/com/google/gwt/dev/jjs/impl
Author: [EMAIL PROTECTED]
Date: Mon Oct 6 11:48:14 2008
New Revision: 3716
Modified:
changes/spoon/runAsync/dev/core/src/com/google/gwt/dev/jjs/impl/Pruner.java
Log:
Run visitors over the set of all declared types, not over the whole
JProgram.
Visiting a JProgram ends up visiting entry methods twice, which breaks
an assumption of CleanUpRefsVisitor.
Modified:
changes/spoon/runAsync/dev/core/src/com/google/gwt/dev/jjs/impl/Pruner.java
==
---
changes/spoon/runAsync/dev/core/src/com/google/gwt/dev/jjs/impl/Pruner.java
(original)
+++
changes/spoon/runAsync/dev/core/src/com/google/gwt/dev/jjs/impl/Pruner.java
Mon Oct 6 11:48:14 2008
@@ -468,7 +468,7 @@
PruneVisitor pruner = new PruneVisitor(
livenessAnalyzer.getReferencedTypes(),
livenessAnalyzer.getLiveFieldsAndMethods());
- pruner.accept(program);
+ pruner.accept(program.getDeclaredTypes());
if (!pruner.didChange()) {
break;
}
@@ -476,7 +476,7 @@
CleanupRefsVisitor cleaner = new CleanupRefsVisitor(
livenessAnalyzer.getLiveFieldsAndMethods(),
pruner.getMethodToOriginalParamsMap());
- cleaner.accept(program);
+ cleaner.accept(program.getDeclaredTypes());
madeChanges = true;
}
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---
[gwt-contrib] Re: Proposed API Addition - PopupPanel.get/setModal() and PopupPanel.get/setAutoHide()
The specific use case I was thinking of is related to an efficiency patch I was toying with that solves the occasionally-slow popup dragging case. However, Ray + Jason's use cases are much more compelling then mine anyway, especially since mine isn't implemented yet :-). On Mon, Oct 6, 2008 at 1:22 PM, John LaBanca [EMAIL PROTECTED] wrote: @Emily - Looking at the code, I don't think there are any edge cases. We don't do any special setup/teardown if the bits are set, we just check them in onEventPreview. Also, I think its a valid use case to change them. For example, if somebody offers a user defined option to enable autoHide. Thanks, John LaBanca [EMAIL PROTECTED] On Mon, Oct 6, 2008 at 1:15 PM, Ray Ryan [EMAIL PROTECTED] wrote: John, when you do this it would be a good idea to add a test that toggles the bits a couple of times and sees that thing still works, so that we don't break it later. rjrjr On Mon, Oct 6, 2008 at 1:14 PM, Emily Crutcher [EMAIL PROTECTED] wrote: This seems like a pretty persuasive use case. On Mon, Oct 6, 2008 at 12:47 PM, Ray Ryan [EMAIL PROTECTED] wrote: +1 For one thing, it lets UI templates set their values without requiring custom parsers. Something like four different people have inspected the code for problems at this point and found none. rjrjr On Mon, Oct 6, 2008 at 12:44 PM, Emily Crutcher [EMAIL PROTECTED] wrote: +1 to public boolean isAutoHideEnabled() public boolean isModal() Why do we want to change whether auto hide/modality is enabled on an existing popup panel? It seems like if we do this we would need to check for edge cases that currently don't come up. On Mon, Oct 6, 2008 at 12:09 PM, Alex Rudnick [EMAIL PROTECTED] wrote: +1, sounds like a good idea. On Mon, Oct 6, 2008 at 11:54 AM, Jason Essington [EMAIL PROTECTED] wrote: +1 here, as I've recently had to use the violator pattern to flip those bits. -jason -- Alex Rudnick swe, gwt, atl -- 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 -- 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: Patch: Build File Fix
LGTM, with a minor tweak to the comment to be clearer why it's not a big deal. Submitted at r3717. On Mon, Oct 6, 2008 at 1:46 PM, Mike Aizatsky [EMAIL PROTECTED]wrote: Freeland, How's this? On Fri, Oct 3, 2008 at 6:43 PM, Freeland Abbott [EMAIL PROTECTED] wrote: The format for gwt.svnrev is [EMAIL PROTECTED], and if a real answer can't be determined it's set to [EMAIL PROTECTED], so I'd rather keep that pattern consistent instead of the 0 here. As a bigger change, though, I'd actually suggest pushing the test for .svn into SvnInfo.java; that already handles error conditions like the svn or svnversion binaries not being available, so it's a reasonable fit to check for workspace configuration there, and it makes the build file itself cleaner. General concept is fine, of course, but can we make those changes? On Fri, Oct 3, 2008 at 8:28 PM, Scott Blum [EMAIL PROTECTED] wrote: Freeland, it's all you. :) On Fri, Oct 3, 2008 at 8:23 PM, Mike Aizatsky [EMAIL PROTECTED] wrote: Hi! I've fixed build file to support working in non-svn workdir (e.g. git :). Can you please get this in? -- Regards, Mike -- Regards, Mike --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] [google-web-toolkit commit] r3714 - in releases/1.5: . dev/core/src/com/google/gwt/dev/jdt
Author: [EMAIL PROTECTED]
Date: Mon Oct 6 07:54:16 2008
New Revision: 3714
Modified:
releases/1.5/branch-info.txt
releases/1.5/dev/core/src/com/google/gwt/dev/jdt/WebModeCompilerFrontEnd.java
Log:
Merging trunk c3708 into releases/1.5.
Modified: releases/1.5/branch-info.txt
==
--- releases/1.5/branch-info.txt(original)
+++ releases/1.5/branch-info.txtMon Oct 6 07:54:16 2008
@@ -32,7 +32,8 @@
/releases/1.5/@r3550:3556 was merged (r3591) into /trunk/, skipping c3550
/releases/1.5/@r3556:3587 was merged (r3593) into /trunk/
/releases/1.5/@r3587:3629 was merged (r3630) into /trunk/
The next merge into trunk will be 3630:
+/trunk c3708 was merged (r3714) into this branch.
+--- The next merge into trunk will be 3630:, skipping r3714
Changes in this branch (excluding changes to this file itself):
- Fixed random JUnit timeouts occurring on module transition. (r2941)
Modified:
releases/1.5/dev/core/src/com/google/gwt/dev/jdt/WebModeCompilerFrontEnd.java
==
---
releases/1.5/dev/core/src/com/google/gwt/dev/jdt/WebModeCompilerFrontEnd.java
(original)
+++
releases/1.5/dev/core/src/com/google/gwt/dev/jdt/WebModeCompilerFrontEnd.java
Mon Oct 6 07:54:16 2008
@@ -165,9 +165,7 @@
continue;
}
// Look for a noArg ctor.
- MethodBinding noArgCtor =
type.getExactMethod(init.toCharArray(),
- TypeBinding.NO_PARAMETERS, cud.scope);
-
+ MethodBinding noArgCtor =
type.getExactConstructor(TypeBinding.NO_PARAMETERS);
if (noArgCtor == null) {
FindDeferredBindingSitesVisitor.reportRebindProblem(site,
Rebind result ' + typeName
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---
[gwt-contrib] Re: RR: make PopupPanels stay on the screen, even in RTL situations
Hey Rajeev :)
Would you take a look at this patch, implementing Joel's suggestion
for keeping DialogBox on the screen?
Instead of trying to decide whether a PopupPanel is being positioned
off the edge, we check whether the user is dragging it off the screen,
and ignore the drag if the pointer has left the visible window area.
We use a WindowResizeListener to make sure we always know how wide the
window is.
Also, in the PopupPanel class, we remove the check that prevents
placing a popup offscreen -- if a developer wants to programmatically
put it off screen, that's OK.
Seems to work right in RTL and LTR modes on all major browsers.
Thanks!
--
Alex Rudnick
swe, gwt, atl
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---
Index: user/src/com/google/gwt/user/client/ui/DialogBox.java
===
--- user/src/com/google/gwt/user/client/ui/DialogBox.java (revision 3717)
+++ user/src/com/google/gwt/user/client/ui/DialogBox.java (working copy)
@@ -15,9 +15,12 @@
*/
package com.google.gwt.user.client.ui;
+import com.google.gwt.dom.client.Document;
import com.google.gwt.user.client.DOM;
import com.google.gwt.user.client.Element;
import com.google.gwt.user.client.Event;
+import com.google.gwt.user.client.Window;
+import com.google.gwt.user.client.WindowResizeListener;
/**
* A form of popup that has a caption area at the top and can be dragged by the
@@ -69,6 +72,10 @@
private boolean dragging;
private int dragStartX, dragStartY;
private MouseListenerCollection mouseListeners = new MouseListenerCollection();
+ private WindowResizeListener resizeListener;
+ private int windowWidth;
+ private int clientLeft;
+ private int clientTop;
/**
* Creates an empty dialog box. It should not be shown until its child widget
@@ -114,6 +121,10 @@
// Set the style name
setStyleName(DEFAULT_STYLENAME);
sinkEvents(Event.MOUSEEVENTS);
+
+windowWidth = Window.getClientWidth();
+clientLeft = Document.get().getBodyOffsetLeft();
+clientTop = Document.get().getBodyOffsetTop();
}
public String getHTML() {
@@ -125,6 +136,12 @@
}
@Override
+ public void hide() {
+Window.removeWindowResizeListener(resizeListener);
+super.hide();
+ }
+
+ @Override
public void onBrowserEvent(Event event) {
super.onBrowserEvent(event);
@@ -178,6 +195,14 @@
if (dragging) {
int absX = x + getAbsoluteLeft();
int absY = y + getAbsoluteTop();
+
+ // if the mouse is off the sceen to the left, right, or top, don't
+ // move the dialog box. This would let users lose dialog boxes, which
+ // would be bad for modal popups.
+ if (absX clientLeft || absX = windowWidth || absY clientTop) {
+return;
+ }
+
setPopupPosition(absX - dragStartX, absY - dragStartY);
}
}
@@ -212,6 +237,20 @@
}
@Override
+ public void show() {
+if (resizeListener == null) {
+ resizeListener = new WindowResizeListener() {
+@Override
+public void onWindowResized(int width, int height) {
+ windowWidth = width;
+}
+ };
+}
+Window.addWindowResizeListener(resizeListener);
+super.show();
+ }
+
+ @Override
protected void doAttachChildren() {
super.doAttachChildren();
Index: user/src/com/google/gwt/user/client/ui/PopupPanel.java
===
--- user/src/com/google/gwt/user/client/ui/PopupPanel.java (revision 3717)
+++ user/src/com/google/gwt/user/client/ui/PopupPanel.java (working copy)
@@ -573,17 +573,6 @@
* @param top the top position, in pixels
*/
public void setPopupPosition(int left, int top) {
-// Keep the popup within the browser's client area, so that they can't get
-// 'lost' and become impossible to interact with. Note that we don't attempt
-// to keep popups pegged to the bottom and right edges, as they will then
-// cause scrollbars to appear, so the user can't lose them.
-if (left 0) {
- left = 0;
-}
-if (top 0) {
- top = 0;
-}
-
// Save the position of the popup
leftPosition = left;
topPosition = top;
[gwt-contrib] Re: [Code Review] Small Test Framework For JJS Optimizers
On Mon, Oct 6, 2008 at 1:32 PM, Mike Aizatsky [EMAIL PROTECTED]wrote: - Could briefly summarize the motivation for the suite()/JJSOptimizerTestDecator design? This way the module will be compiled only once. Unfortunately JavaToJavaScriptCompiler doesn't have any easily extract compiling pass and I didn't want to seriously refactor it. I'm not sure I totally understand. Are you suggesting that if you don't use a suite and simply run the test class as a unit test, stuff happens multiple times that shouldn't? - JJSOptimizerTestCase.staticJprogram strikes me as scary.. is this necessary? How else would you pass values from static context? Why do we need to pass in values from a static context exactly? - Textual comparison seems like a great first step, but a bit brittle going forward. I'd worry that changes in the compiler totally unrelated to an optimization pass would tend to unnecessarily break tests. That's a valid point and I saw this in the fast. I don't know a solution for this. Writing manual tree-based checks is even more fragile. However I do believe this is better than nothing. I know. But I would like to think of a way forward. Maybe we could take a before and after string snapshot of the program, and validate only the sections of the code that are different. - Very high-level: We should talk about doing something more invasive to make testing lighter weight. There's really no reason to have to setup a GWT module to do a test... with some refactoring we could make it as easy as providing some input source and some output source. There still be a compilation step, right? Are you sure it will be easy to set up all binding, intrinsic stuff, etc. without the module? We should be able to get by without deferred binding, so it's really just providing the core JRE classes. Typically in other parts of the system, we just create reusable mock compilation units for things like Object, String; and write other test classes with minimal dependencies. --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: [Code Review] Small Test Framework For JJS Optimizers
Scott, - Could briefly summarize the motivation for the suite()/JJSOptimizerTestDecator design? This way the module will be compiled only once. Unfortunately JavaToJavaScriptCompiler doesn't have any easily extract compiling pass and I didn't want to seriously refactor it. I'm not sure I totally understand. Are you suggesting that if you don't use a suite and simply run the test class as a unit test, stuff happens multiple times that shouldn't? If you perform program compilation in setUp method - you'll compile all your code for every test. And this becomes really costly for 50 tests. So, the natural solution is to move compilation into some static context. But since our JavaToJavaScriptCompiler doesn't have any methods like compile() - the only way to plug into it seems to override optimize method and run your code there. This could be done either overriding runBare method in Test, which leads to compiling multiple times, or by using decorators. - JJSOptimizerTestCase.staticJprogram strikes me as scary.. is this necessary? How else would you pass values from static context? Why do we need to pass in values from a static context exactly? Because our tests need JProgram instance. If we're compiling only once - that's static context. - Textual comparison seems like a great first step, but a bit brittle going forward. I'd worry that changes in the compiler totally unrelated to an optimization pass would tend to unnecessarily break tests. That's a valid point and I saw this in the fast. I don't know a solution for this. Writing manual tree-based checks is even more fragile. However I do believe this is better than nothing. I know. But I would like to think of a way forward. Maybe we could take a before and after string snapshot of the program, and validate only the sections of the code that are different. You mean storing diffs instead of expected data? -- Regards, Mike --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: [Code Review] Small Test Framework For JJS Optimizers
On Mon, Oct 6, 2008 at 4:27 PM, Mike Aizatsky [EMAIL PROTECTED]wrote: Scott, - Could briefly summarize the motivation for the suite()/JJSOptimizerTestDecator design? This way the module will be compiled only once. Unfortunately JavaToJavaScriptCompiler doesn't have any easily extract compiling pass and I didn't want to seriously refactor it. I'm not sure I totally understand. Are you suggesting that if you don't use a suite and simply run the test class as a unit test, stuff happens multiple times that shouldn't? If you perform program compilation in setUp method - you'll compile all your code for every test. And this becomes really costly for 50 tests. So, the natural solution is to move compilation into some static context. Gotcha. But if you don't compile multiple times, how do you prevent optimizations that occur in one test method from impacting ones that occur in another test method? By the way, I've already got a big patch out that Bob is reviewing that is a huge refactor to JavaToJavaScriptCompiler, and we can continue to refactor further to support this use case in the best way possible. I can't think of a fundamental reason that compiles should be slow for small test cases. - Textual comparison seems like a great first step, but a bit brittle going forward. I'd worry that changes in the compiler totally unrelated to an optimization pass would tend to unnecessarily break tests. That's a valid point and I saw this in the fast. I don't know a solution for this. Writing manual tree-based checks is even more fragile. However I do believe this is better than nothing. I know. But I would like to think of a way forward. Maybe we could take a before and after string snapshot of the program, and validate only the sections of the code that are different. You mean storing diffs instead of expected data? Something like that. Scott --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: [Code Review] Small Test Framework For JJS Optimizers
Gotcha. But if you don't compile multiple times, how do you prevent optimizations that occur in one test method from impacting ones that occur in another test method? I can't. I do this by limiting the scope optimization should work on (see MethodInlineTest)... By the way, I've already got a big patch out that Bob is reviewing that is a huge refactor to JavaToJavaScriptCompiler, and we can continue to refactor further to support this use case in the best way possible. I can't think of a fundamental reason that compiles should be slow for small test cases. I'll be happy to take a look at JTJSC and tests as soon as you finish the refactoring. You mean storing diffs instead of expected data? Something like that. As a second thought, I don't feel that will help much. If you change a compiler, in a way, that changes interesting code - you'll be in the same position. And it's much more difficult to look at diffs than at expected text. Probably we could limit expected test scope? Say to a specified method(s)? - Textual comparison seems like a great first step, but a bit brittle going forward. I'd worry that changes in the compiler totally unrelated to an optimization pass would tend to unnecessarily break tests. That's a valid point and I saw this in the fast. I don't know a solution for this. Writing manual tree-based checks is even more fragile. However I do believe this is better than nothing. I know. But I would like to think of a way forward. Maybe we could take a before and after string snapshot of the program, and validate only the sections of the code that are different. Scott -- Regards, Mike --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: A rose by any other name (what to call addHandlersAndSink)
Here is the current doc on it, to give context:
/**
* Adds a native event handler to the widget and sinks the corresponding
* native event.
*
* @param HandlerType the type of handler to add
* @param key the event key
* @param handler the handler
* @return [EMAIL PROTECTED] HandlerRegistration} used to remove the handler
*/
protected HandlerType extends EventHandler HandlerRegistration
addHandlerAndSink(
DomEvent.Key?, HandlerType key, final HandlerType handler) {
sinkEvents(key.getNativeEventType());
return addHandler(key, handler);
}
On Mon, Oct 6, 2008 at 5:35 PM, Emily Crutcher [EMAIL PROTECTED] wrote:
The purpose of the new method addHandlersAndSink is to allow users to add
a DOM handler and sink the necessary event in one easy step.
The reason we, the GWT team, care about this is because traditionally, with
the two call separated everyone, including us, will tend to sink the events
in the constructor rather then when a handler is actually added. This can
degrade performance significantly for small widgets, so we'd like to
encourage our developers to do the fast/efficient thing instead.
addHandlersAndSink has the advantage that when you autocomplete to find
your widget methods, it appears directly under addHandlers. However, it
sounds somewhat awkward, so a better name might be in order, hence this
post...
--
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] [google-web-toolkit commit] r3721 - in changes/spoon/runAsync: dev/core/src/com/google/gwt/dev/jjs/impl user/src/com/google/g...
Author: [EMAIL PROTECTED]
Date: Mon Oct 6 15:12:24 2008
New Revision: 3721
Modified:
changes/spoon/runAsync/dev/core/src/com/google/gwt/dev/jjs/impl/FragmentLoaderCreator.java
changes/spoon/runAsync/user/src/com/google/gwt/core/client/AsyncFragmentLoader.java
Log:
Signal AsyncFragmentLoader once a fragment finishes downloading.
This sets the stage for fragmentation strategies where the order
fragments arrive needs to be controlled.
Modified:
changes/spoon/runAsync/dev/core/src/com/google/gwt/dev/jjs/impl/FragmentLoaderCreator.java
==
---
changes/spoon/runAsync/dev/core/src/com/google/gwt/dev/jjs/impl/FragmentLoaderCreator.java
(original)
+++
changes/spoon/runAsync/dev/core/src/com/google/gwt/dev/jjs/impl/FragmentLoaderCreator.java
Mon Oct 6 15:12:24 2008
@@ -120,15 +120,15 @@
private void generateOnLoadMethod(PrintWriter srcWriter) {
srcWriter.println(public static void onLoad() {);
-srcWriter.println(loaded = true;);
-srcWriter.println(instance = new + getLoaderSimpleName() + (););
srcWriter.println(ASYNC_FRAGMENT_LOADER
+ .logEventProgress(\download
+ entryNumber + \, \end\););
-srcWriter.println(ASYNC_FRAGMENT_LOADER
-+ .logEventProgress(\runCallbacks + entryNumber + \,
\begin\););
+srcWriter.println(loaded = true;);
+srcWriter.println(instance = new + getLoaderSimpleName() + (););
+srcWriter.println(ASYNC_FRAGMENT_LOADER + .fragmentHasLoaded(
++ entryNumber + ););
+
srcWriter.println(instance.runCallbacks(););
-srcWriter.println(ASYNC_FRAGMENT_LOADER
-+ .logEventProgress(\runCallbacks + entryNumber + \,
\end\););
+
srcWriter.println(});
}
@@ -167,7 +167,7 @@
}
private void generateRunCallbacksMethod(PrintWriter srcWriter) {
-srcWriter.println(protected void runCallbacks() {);
+srcWriter.println(public void runCallbacks() {);
// TODO(spoon): this runs the callbacks in reverse order
// TODO(spoon): this runs the callbacks immediately; deferred would be
// better
@@ -265,9 +265,9 @@
/**
* Create a stand-in superclass of the actual loader. This is used to
keep the
* liveness analyzer from thinking the real coderunCallbacks()/code
- * method is available until codeonLoad/code has been called an the
real
- * load instantiated. A little work on TypeTightener could prevent the
for
- * this class.
+ * method is available until codeonLoad/code has been called and the
+ * real loader instantiated. A little work on TypeTightener could
prevent the
+ * need for this class.
*/
private void writeLoaderSuperclass(TreeLogger logger, GeneratorContext
ctx)
throws UnableToCompleteException {
@@ -282,7 +282,7 @@
printWriter.println(package + getPackage() + ;);
printWriter.println(public class + getLoaderSuperclassSimpleName()
+ {);
-printWriter.println(protected void runCallbacks() { });
+printWriter.println(public void runCallbacks() { });
printWriter.println(});
printWriter.close();
Modified:
changes/spoon/runAsync/user/src/com/google/gwt/core/client/AsyncFragmentLoader.java
==
---
changes/spoon/runAsync/user/src/com/google/gwt/core/client/AsyncFragmentLoader.java
(original)
+++
changes/spoon/runAsync/user/src/com/google/gwt/core/client/AsyncFragmentLoader.java
Mon Oct 6 15:12:24 2008
@@ -19,9 +19,20 @@
import com.google.gwt.user.client.Element;
/**
- *
+ * Low-level support to download an extra fragment of code. This should
not be
+ * invoked directly by user code.
*/
public class AsyncFragmentLoader {
+ /**
+ * Inform the loader that the code for an entry point has now finished
+ * loading.
+ *
+ * @param entry The entry whose code fragment is now loaded.
+ */
+ public static void fragmentHasLoaded(int entry) {
+// There is nothing to do with the current fragmentation strategy
+ }
+
/**
* Loads the specified fragment asynchronously.
*
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---
[gwt-contrib] [google-web-toolkit commit] r3722 - changes/bobv/clientbundle-3721
Author: [EMAIL PROTECTED] Date: Mon Oct 6 15:18:16 2008 New Revision: 3722 Added: changes/bobv/clientbundle-3721/ - copied from r3721, /trunk/ Log: Create a change branch for integrating ClientBundle into the trunk. --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] [google-web-toolkit commit] r3719 - changes/jat/oophm-branch/plugins/xpcom
Author: [EMAIL PROTECTED] Date: Mon Oct 6 13:52:32 2008 New Revision: 3719 Modified: changes/jat/oophm-branch/plugins/xpcom/Makefile.mac Log: Mac port of recent changes. Modified: changes/jat/oophm-branch/plugins/xpcom/Makefile.mac == --- changes/jat/oophm-branch/plugins/xpcom/Makefile.mac (original) +++ changes/jat/oophm-branch/plugins/xpcom/Makefile.mac Mon Oct 6 13:52:32 2008 @@ -1,5 +1,5 @@ #XUL_SDK_PATH=/Users/sgross/Downloads/xulrunner-1.8-sdk/xulrunner-sdk -XUL_SDK_PATH=/Users/sgross/Downloads/xulrunner-sdk +XUL_SDK_PATH=../../..//xulrunner-sdk GECKO_SDK_PATH=$(XUL_SDK_PATH)/sdk INC=-I. -I../common -I$(GECKO_SDK_PATH)/include -I$(XUL_SDK_PATH)/include/caps -I$(XUL_SDK_PATH)/include/dom -I$(XUL_SDK_PATH)/include/js -I$(XUL_SDK_PATH)/include/necko -I$(XUL_SDK_PATH)/include/string -I$(XUL_SDK_PATH)/include/widget -I$(XUL_SDK_PATH)/include/xpcom -I$(XUL_SDK_PATH)/include/xpconnect -I$(XUL_SDK_PATH)/include RUN_PATH_FLAG=-executable_path @@ -15,15 +15,15 @@ COMMON= ../common/libcommon$(FLAG32BIT).a -ALL: oophm.xpi +ALL: oophm-xpcom.xpi -OBJS= ExternalWrapper.o ModuleOOPHM.o FFSessionHandler.o JavaObject.o JSRunner.o +OBJS= ExternalWrapper.o ModuleOOPHM.o FFSessionHandler.o JavaObject.o JSRunner.o XpcomDebug.o -SRCS= ExternalWrapper.cpp ModuleOOPHM.cpp FFSessionHandler.cpp JavaObject.cpp JSRunner.cpp +SRCS= ExternalWrapper.cpp ModuleOOPHM.cpp FFSessionHandler.cpp JavaObject.cpp JSRunner.cpp XpcomDebug.cpp -oophm.xpi: arch extension $(INSTDIR)/liboophm.dylib \ +oophm-xpcom.xpi: arch extension $(INSTDIR)/liboophm.dylib \ extension/components/IOOPHM.xpt extension/install.rdf - -rm -f oophm.xpi + -rm -f oophm-xpcom.xpi cd extension; zip -r -D -9 -o ../$@ * -x '*/.svn/*' -x 'META-INF/*' extension: prebuilt/extension @@ -42,7 +42,14 @@ cp $ $@ extension/components/IOOPHM.xpt: IOOPHM.xpt + -mkdir -p extension/components cp $ $@ + +extension/install.rdf: install-template.rdf version + sed s/GWT_OOPHM_VERSION/`cat version`/ install-template.rdf $@ + +version: computeversion $(HDRS) $(SRCS) $(COMMON) + ./computeversion $@ IOOPHM.h: IOOPHM.idl $(XPIDL) -m header $(XPIDL_FLAGS) $ --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: [google-web-toolkit commit] r3716 - changes/spoon/runAsync/dev/core/src/com/google/gwt/dev/jjs/impl
On Mon, Oct 6, 2008 at 4:20 PM, Scott Blum [EMAIL PROTECTED] wrote: How do you clean up dead refs in the entry method, which isn't part of any class? Good catch. It sounds like there is a more fundamental problem. The runAsync entry methods actually are included in a class. Thus, in some circumstances I saw these methods get cleaned twice and thus ending up with invalid method calls. Since the normal entry method is not part of a class, there's no simple solution for Pruner to do its cleaning up. To make the story consistent, what would you think of attaching the existing entry method to some class? The other arrangement looks awkward, because the runAsync entry methods are the result of generator runs. They're plain old static methods. -Lex --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: RR: make PopupPanels stay on the screen, even in RTL situations
Hey Alex, Thanks for putting this fix together. Comments below: DialogBox.java 199: Spelling: sceen -- screen 243: @Overrides on an a method that implements an interface only works in Java 1.6. While GWT on the the trunk currently support JDK 1.6, the code base still compiles under GWT 1.5. If this change goes in, then GWT will no longer be able to compile under JDK 1.5. Let's get rid of the annotation. 245: Do you need to recompute clientLeft and clientTop on window resize? Can these change based on a window resize? General: I did some testing and it looks good. Dragging in IE6 in RTL mode is still somewhat odd with the jumpiness, but workable. I wonder if we could improve RTL dragging in general in IE6/IE7. It might be worth filing a bug for. If I had to suspect something, it might be the use of CSS expressions and a hidden IFRAME to prevent scrollbar shine-through. This isn't needed in IE7, as they've fixed this at the rendering level, so it might be worth exploring at least an improvement for IE7 at some point. After addressing the above nits, feel free to hit the commit switch. Rajeev On Mon, Oct 6, 2008 at 4:03 PM, Alex Rudnick [EMAIL PROTECTED] wrote: Hey Rajeev :) Would you take a look at this patch, implementing Joel's suggestion for keeping DialogBox on the screen? Instead of trying to decide whether a PopupPanel is being positioned off the edge, we check whether the user is dragging it off the screen, and ignore the drag if the pointer has left the visible window area. We use a WindowResizeListener to make sure we always know how wide the window is. Also, in the PopupPanel class, we remove the check that prevents placing a popup offscreen -- if a developer wants to programmatically put it off screen, that's OK. Seems to work right in RTL and LTR modes on all major browsers. Thanks! -- Alex Rudnick swe, gwt, atl --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] [google-web-toolkit commit] r3717 - trunk/build-tools/ant-gwt/src/com/google/gwt/ant/taskdefs
Author: [EMAIL PROTECTED]
Date: Mon Oct 6 11:49:45 2008
New Revision: 3717
Modified:
trunk/build-tools/ant-gwt/src/com/google/gwt/ant/taskdefs/SvnInfo.java
Log:
Fix SvnInfo to handle a non-svn workspace: can't deduce the version
available, but it won't stop the build either.
Patch by: [EMAIL PROTECTED]
Review by: fabbott
Modified:
trunk/build-tools/ant-gwt/src/com/google/gwt/ant/taskdefs/SvnInfo.java
==
--- trunk/build-tools/ant-gwt/src/com/google/gwt/ant/taskdefs/SvnInfo.java
(original)
+++ trunk/build-tools/ant-gwt/src/com/google/gwt/ant/taskdefs/SvnInfo.java
Mon Oct 6 11:49:45 2008
@@ -57,9 +57,20 @@
if (!workDirFile.isDirectory()) {
throw new BuildException(workdir + is not a directory);
}
+
+String branch;
+String revision;
+
+File svnDirFile = new File(workdir, .svn);
+if (!svnDirFile.exists()) {
+ // This is not svn workdir. We can't guess the version...
+ branch = unknown;
+ revision = unknown;
+} else {
+ branch = getSvnBranch(workDirFile);
+ revision = getSvnVersion(workDirFile);
+}
-String branch = getSvnBranch(workDirFile);
-String revision = getSvnVersion(workDirFile);
getProject().setNewProperty(outprop, branch + @ + revision);
if (fileprop != null) {
getProject().setNewProperty(fileprop, branch + -
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---
[gwt-contrib] Re: RR: updates and design changes to incubator validation
Hey Emily, Is there a use case when a ValidatorController will hold different types of Subjects and Validators or can I assume that ValidatorController is generic and the generic type will be the same in Validators and Subjects? Regards, Arthur Kalmenson On Oct 6, 12:20 pm, Emily Crutcher [EMAIL PROTECTED] wrote: va 1.5 features that are now available This is pretty straight forward. I would use typed lists in AbstractValidationController, make Subject a generic interface (for the value returned), and other minor changes. Yes. Use interfaces instead of abstract classes A lot of the main validation classes are abstract classes. Some examples are ErrorHandler, AbstractValidationController and Validator. This creates a lot of problems for unit testing these classes because you can't really mock them out, you have to instantiate them, etc. Therefore, I think it's better to make these classes interfaces and make an abstract concrete implementation that includes the current code. To me, this depends upon how well you can factor them into characteristic interfaces. What we want to avoid is an interface with a bundle of functionality where we locked out of adding more features. Some of the system might be able to be be mapped into the event handlers framework or something similar (i.e. a set of validation events consumed by validation handlers) this pattern gives the the advantages of interfaces, but can still be enhanced over time. Write test cases The validation library is currently missing unit tests, I'd like to add extensive tests. I wanted to use EasyMock (http:// www.easymock.org/) for testing some of the stuff that doesn't involve GWT.create() calls. EasyMock is under the MIT license, is it acceptable to use and include? Let me check with legal on this one. GWT code certainly runs with easy mock, however I don't know if we can bundle it with the gwt-incubator code. Remove static methods There are a number of static methods scattered around in classes like the DefaultTextBoxSubject, RegExValidator and ValidatorController. Static methods really make testing hard, and global states are in general bad. Is there a specific reason for these static methods? This is completely true of server side code, and therefore as validation is a shared system, we would definitely want to go over it with a fine-toothed comb. GWT Client side web applications, in general, are less subject to this rule, because 1. They are, by nature, single threaded 2. They are, by nature, single user 3. They run on JavaScript, so are,by nature, slow 4. They need to include the fewest lines of code possible, which means we must be very careful that the compiler can trace through when code is actually needed, in other words a lot of the injection-dependency systems which are perfect for server code end up creating really bad GWT apps. Annotation based validation What do you think about annotation based validation? It could look something like this: @NotEmptyValidator TextBox firstName = new TextBox(); @NumberRangeValidator(low = 18, high = 100) TextBox age = new TextBox(); I like the general principle, the devil, of course, will be in the details! Let me know what you think. Thank you. Regards, Arthur Kalmenson -- 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 commit] r3716 - changes/spoon/runAsync/dev/core/src/com/google/gwt/dev/jjs/impl
That seems like a reasonable approach.. it was always a bit weird to have a method with no containing class. I'd look at com.google.gwt.lang.ClassLiteralHolder as a template for this idea. In fact, you might be able to get rid of JProgram.entryMethods in favor of an entry class. On Mon, Oct 6, 2008 at 6:53 PM, Lex Spoon [EMAIL PROTECTED] wrote: On Mon, Oct 6, 2008 at 4:20 PM, Scott Blum [EMAIL PROTECTED] wrote: How do you clean up dead refs in the entry method, which isn't part of any class? Good catch. It sounds like there is a more fundamental problem. The runAsync entry methods actually are included in a class. Thus, in some circumstances I saw these methods get cleaned twice and thus ending up with invalid method calls. Since the normal entry method is not part of a class, there's no simple solution for Pruner to do its cleaning up. To make the story consistent, what would you think of attaching the existing entry method to some class? The other arrangement looks awkward, because the runAsync entry methods are the result of generator runs. They're plain old static methods. -Lex --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] [google-web-toolkit commit] r3723 - changes/jat/oophm-branch/dev/core/src/com/google/gwt/dev
Author: [EMAIL PROTECTED]
Date: Mon Oct 6 17:10:48 2008
New Revision: 3723
Modified:
changes/jat/oophm-branch/dev/core/src/com/google/gwt/dev/GWTShell.java
Log:
Correct the launch URL in the case of a pre-existing query parameter.
Modified:
changes/jat/oophm-branch/dev/core/src/com/google/gwt/dev/GWTShell.java
==
--- changes/jat/oophm-branch/dev/core/src/com/google/gwt/dev/GWTShell.java
(original)
+++ changes/jat/oophm-branch/dev/core/src/com/google/gwt/dev/GWTShell.java
Mon Oct 6 17:10:48 2008
@@ -502,7 +502,13 @@
* TODO(jat): properly support launching arbitrary browsers; waiting on
* Freeland's work with BrowserScanner and the trunk merge to get it.
*/
-url += ?gwt.hosted= + listener.getEndpointIdentifier();
+String separator;
+if (url.contains(?)) {
+ separator = ;
+} else {
+ separator = ?;
+}
+url += separator + gwt.hosted= + listener.getEndpointIdentifier();
TreeLogger branch = getTopLogger().branch(TreeLogger.INFO,
Launching firefox with + url, null);
try {
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---
