Re: [gwt-contrib] New Google Groups apparent with GWT ?
I believe it is, though I think they may have taken Gmail's Javascript rich-text editor (the one from the Closure library). I'm pretty happy with it, too. On 10:55 am, stuckagain david.no...@gmail.com wrote: Hi, I'm writing this message using the new Groups... and what do I see... it is now written in GWT! Looking sweet! Although I see a bit a lag when typing (in IE8) David -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: Fix some timeout typos, and increase delay on RequestFactoryTest. (issue1163801)
Ready for review now? On 2:32 pm, Ray Ryan rj...@google.com wrote: http://gwt-code-reviews.appspot.com/1163801/show -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: Fixing Internet Explorer specific memory leaks (circular references, etc)
Paul, First off, I'd like to applaud your diligent efforts to track down these leaks. It's often very hard in practice, especially with the paucity of good tools and no access to the browser's source. That Microsoft leak detector is definitely the right one to be using -- Drip (which I wrote ages ago) was always kind of a hack without access to internal data structures, and I no longer trust it at all. One caveat about the MS tool, though -- IIRC it has two modes, one of which reports potential leaks, and which I've found to be extremely misleading on GWT output. I'd double-check to make sure you're using the strict check. Based on the result that your app *actually* stopped leaking (and the fact that it was leaking in the first place), I'm guessing this isn't the problem, but I thought I'd mention it for completeness. As far as getting a GWT app to leak is concerned, you are correct that it was carefully designed such that you should never have to remove the event handlers explicitly. We're quite certain the theory is sound, and we've confirmed it on apps up to the complexity of Wave and AdWords. But you *did* see leaks in your app, so how could that happen? The most obvious cases I've seen are: - Using libraries that wrap external Javascript libraries - Either because said library isn't careful enough or because there's some strange interaction making things worse. - Writing JSNI methods that hook events by hand in Javascript, but not cleaning up after them. - Overriding Widget.onDetach() without calling super.onDetach() (onUnload() was meant to serve this purpose without the added danger, and we couldn't make onDetach() final, unfortunately). This stops the widgets from calling setEventListener(null), which breaks the reference cycle. I just posted a wiki page I've been sitting on for a few months with some (hopefully) more useful information and background: http://code.google.com/p/google-web-toolkit/wiki/UnderstandingMemoryLeaks If you uncover any leads in your quest (or a simple repro), I'd love to hear about it. This problem has been my personal Moby Dick for years now, and since I can't eliminate old versions of IE, I'd really like to see it laid to rest! Cheers, joel. Le 7 novembre 2010 03:10, Paul McLachlan pmclach...@gmail.com a écrit : I’d like to chronicle my experiences fixing a memory leak in our enterprise GWT application when running on Internet Explorer. A few facts getting started: 1. Using a click-recording tool, QA could get our application to leak hundreds of megabytes of memory in Internet Explorer. 2. No leak measured using Java memory analysis tools in hosted mode. 3. Non-trivial application - we have over 100K SLOC just for GWT (ie, not counting server side or any non .java files) Reproducibility was handled by QA, but the first problem was working out what was going on. We didn't see these kinds of problems with Firefox this strongly implies some kind of Internet Explorer circular reference strangeness between DOM elements and javascript. We spent some time playing with Drip and sIEve, but we were advised not to use these tools (misleading output) and didn't have wonderful success with them in any case. A bit more googling found a javascript memory leak analyzer from Microsoft at: http://blogs.msdn.com/b/gpde/archive/2009/08/03/javascript-memory-leak-detector-v2.aspx . That's actually the v2 and most google hits send you to a (now removed v1), so it's a little difficult to find. In any case, the results of using Microsoft's javascript memory leak detector are basically unintelligible in a regular production mode GWT compile. I had more luck when compiling with -style PRETTY (obviously), and I also turned on -draftCompile. I think I remember that -draftCompile did less inlining, which made the generated javascript closer to our Java code. This was important because the output of the tool is basically a series of leaks, like: DIV leaked due to onclick from stack XYZ where XYZ is a javascript stack trace of where the onclick event handler was set. By clicking back up the stack you can generally get a reasonable idea of which widget in your application is causing the problem. At this point, I didn't actually trust the tool - so from a methodology perspective my first step was to validate the tools output. I commented out code and otherwise configured our application down to a bare-bones login, display a couple of things, logout script that I could run in a loop. Having done so, I could demonstrate that: a) that operational loop actually leaked in IE b) the tool reported about 15 elements as being leaked Then, I proceeded to ... try to fix those leaks. First attempt was to click the ClickListener (or ClickHandler or KeyPressHandler or whatever). I mean, calling Handler.remove(), or removeClickListener() during onDetach(). My theory was that my ClickHandler was a Java inner class and it somehow just
Re: [gwt-contrib] protected com.google.gwt.user.client.ui.Widget.addHandler(H, TypeH)
The point of that method being protected is that under normal circumstances you don't want to be able to add handlers to a widget that's not capable of firing them in the first place. So a widget subclass creates addFooHandler(), then uses this method internally. Are you saying you want to add a custom event handler to a widget, then force that widget to fire the event from external code? Sounds like it wants to be a subclass. Le 9 novembre 2010 01:56, cokol eplisc...@googlemail.com a écrit : why is com.google.gwt.user.client.ui.Widget.addHandler(H, TypeH) protected? in case I want to fire a custom event on a widget so that the widget is not aware of custom event handler, it makes it difficult to manage. thanks -- http://groups.google.com/group/Google-Web-Toolkit-Contributors -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Fwd: [gwt-contrib] Re: Comment on WhyWidgetIsAClass in google-web-toolkit
[+rjrjr] I haven't put much thought into widget interfaces recently (I've been busy wrestling low-level stuff on other fronts), but clearly Ray and others have been thinking about this problem (based upon the appearance of IsWidget, which seems to have worked out well). Thoughts? -- Message transféré -- De : codesite-nore...@google.com Date : 4 novembre 2010 10:56 Objet : [gwt-contrib] Re: Comment on WhyWidgetIsAClass in google-web-toolkit À : Google-Web-Toolkit-Contributors@googlegroups.com Comment by stephen.haberman: Hurray for structural typing. :-) That being said, I think you're coupling benefits of a concrete base class with cannot use interfaces for widgets--to me, they're separate concerns because you can: * Enforce a concrete class internally within the widget impls by immediately doing asWidget() whenever a widget comes into the API * Allow external clients to /think/ you support widget interfaces, by providing IsWidget method overloads where ever you take widgets. Note that this is already being done in GWT 2.1's Panel.add(IsWidget widget). What makes this really useful is if Panel itself had an interface: https://github.com/stephenh/gwt-mpv/blob/master/user/src/main/java/org/gwtmpv/widgets/IsPanel.java Then presenter/etc. code can add fake widgets to fake panels, be thoroughly unit tested, but at GWT time they all turn into real/Widget-extending widgets. Also, union types become needed less if you just have per-widget interfaces--e.g. IsTextBox. IsTextBox inherently defines the union of its HasValueString/etc. characteristic interfaces (/plus/ the the TextBox-specific methods that are not in a characteristic interface and so could never be accessed before), so client code just uses IsTextBox. (Unless the code really does need to be generic across widgets that don't share a IsXxx interface.) For more information: http://code.google.com/p/google-web-toolkit/wiki/WhyWidgetIsAClass -- http://groups.google.com/group/Google-Web-Toolkit-Contributors -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] factory methods
Specific examples might be helpful here. I can see how this might be useful
in some specific cases, but wrapping every new in a template method sounds
like a horribly contorting way to have to write all one's code.
Le 13 octobre 2010 05:19, cokol eplisc...@googlemail.com a écrit :
many other developers, including me, would appreciate if you'd use
protected factory methods in non-final classes (even if the class is
not abstract), like:
a no-go:
void func() {
A = new A();
A.doSomething();
}
instead, a better pattern:
---
protected A createA() {
return new A();
}
void func() {
A = createA();
A.doSomething();
}
-
because in some situations the integration of GWT into existing
environment becomes a little nightmare, and it would be great pay more
attention to DI
thank you!!
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] panel does not fire attach events (issue981801)
Hmm... I didn't even realize AttachEvent had been added. John Ray, you
might want to take a look at this -- in the original design this super
invocation wouldn't have mattered, because widget's onLoad() was empty
(onAttach/Detach() weren't really meant to overridden outside of Panel and
Composite -- onLoad/Unload() were the methods to override). But now it
appears that Widget.onLoad() has actual code in it. Could this not be moved
to onAttach?
Le 11 octobre 2010 14:05, stephen.haber...@gmail.com a écrit :
Reviewers: ,
Description:
Panel's onLoad does not call super.onLoad. This is a simple fix that
just adds the missing onLoad call.
I have another patch set which fires the attach event in
onAttach/onDetach, given these are more stable methods that user's are
less prone overriding them.
Please review this at http://gwt-code-reviews.appspot.com/981801/show
Affected files:
user/src/com/google/gwt/user/client/ui/Panel.java
user/test/com/google/gwt/user/client/ui/WidgetOnLoadTest.java
Index: user/test/com/google/gwt/user/client/ui/WidgetOnLoadTest.java
===
--- user/test/com/google/gwt/user/client/ui/WidgetOnLoadTest.java
(revision 8929)
+++ user/test/com/google/gwt/user/client/ui/WidgetOnLoadTest.java
(working copy)
@@ -121,9 +121,12 @@
}
TestPanel tp = new TestPanel();
+TestAttachHandler tpa = new TestAttachHandler();
+tp.addAttachHandler(tpa);
+
TestWidget tw = new TestWidget();
-TestAttachHandler ta = new TestAttachHandler();
-tw.addAttachHandler(ta);
+TestAttachHandler twa = new TestAttachHandler();
+tw.addAttachHandler(twa);
tp.add(tw);
RootPanel.get().add(tp);
@@ -134,9 +137,9 @@
assertTrue(tp.onAttachOrder tp.onLoadOrder);
assertTrue(tp.onDetachOrder tp.onUnloadOrder);
assertTrue(tw.onAttachOrder tw.onLoadOrder);
-assertTrue(tw.onLoadOrder ta.delegateAttachOrder);
+assertTrue(tw.onLoadOrder twa.delegateAttachOrder);
assertTrue(tw.onDetachOrder tw.onUnloadOrder);
-assertTrue(tw.onUnloadOrder ta.delegateDetachOrder);
+assertTrue(tw.onUnloadOrder twa.delegateDetachOrder);
// Also trivial. Ensure that the panel's onAttach/onDetach is called
before
// its child's onAttach/onDetach.
@@ -150,6 +153,9 @@
// detached/unloaded.
assertTrue(tp.onUnloadOrder tw.onUnloadOrder);
+assertTrue(tp.onLoadOrder tpa.delegateAttachOrder);
+assertTrue(tp.onUnloadOrder tpa.delegateDetachOrder);
+
// Make sure each widget/panel's elements are actually still attached
to the
// DOM during onLoad/onUnload.
assertTrue(tp.domAttachedOnLoad);
Index: user/src/com/google/gwt/user/client/ui/Panel.java
===
--- user/src/com/google/gwt/user/client/ui/Panel.java (revision 8929)
+++ user/src/com/google/gwt/user/client/ui/Panel.java (working copy)
@@ -183,6 +183,7 @@
*/
@Override
protected void onLoad() {
+super.onLoad();
}
/**
@@ -193,6 +194,7 @@
*/
@Override
protected void onUnload() {
+super.onUnload();
}
/**
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] 2 questions about TabBar internals
Thanks for pointing these out, Jay. If you could put together a quick patch, we'd be glad to commit it. Le 6 octobre 2010 16:52, jay jay.gin...@gmail.com a écrit : While debugging my code I ran across two things within the TabBar class that I seemed strange... (Line numbers are from svn 8960.) 1. com.google.gwt.user.client.ui.TabBar.ClickDelegatePanel#onBrowserEvent -- There's a comment on line 149: // No need for call to super., and yet there *is* a call to super.onBrowserEvent. I assume the comment should be deleted? 2. com.google.gwt.user.client.ui.TabBar#TabBar -- Line 201 is first.setHeight(100%); and guess what's on line 206? The same thing! I'm guessing one of these is not necessary. Thanks, jay -- http://groups.google.com/group/Google-Web-Toolkit-Contributors -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] Why is getOffsetWidth/getOffsetHeight returning 0 even after onLoad is called for LayoutPanel children?
getOffsetWidth/Height() always read the current state of the widget's
backing element, which won't be updated until the layout panels are done
laying themselves out. All the layout panels have the potential to be
animated, and defer actually laying things out until the end of the current
event (in this case, the current event is likely the module startup). This
is pretty important for optimization, because layout can be expensive, and
you don't want to do any layout work until the app's done fiddling with its
structure. That's why you're seeing the correct value in a DeferredCommand
-- it's guaranteed to run after the current event.
If you really need to force layout earlier, you can call
LayoutPanel.forceLayout(). But be careful with this, because you can end up
forcing more layouts than you mean to (in the example you show, it would be
fine, but if you were to take a similar structure and nest it within another
that *also* called forceLayout(), you would end up doing extra work).
Hope that helps,
joel.
Le 27 septembre 2010 11:20, Damon Lundin damon.lun...@gmail.com a écrit :
I posted this over on the normal group but hopefully I can get some
useful responses here. I am attempting to use the new GWT
LayoutPanels and unfortunately they are causing me some grief. We are
using the layout panels (RootLayoutPanel, DockLayoutPanel,
LayoutPanel, etc) to arrange the overall layout of the panel. Then,
the children of one of these panels needs to know how big it is so
that it can size one of its children properly to cause a scroll bar to
appear. As far as I can tell, the only way to do this is by calling
getOffsetWidth and getOffsetHeight. I know that these methods will
return 0 if the widget is not attached but I am finding that in even
putting the calls in onLoad, these methods are still returning 0.
Clearly I don't understand when GWT and/or the browser figures out
what the sizes of these layout panels are.
Below is a simplification of my problem. The widget added to the
RootLayoutPanel cannot determine its size when it is attached to the
DOM. I made sure the widget had something in it and to prove that it
ends up with a size, I added the call to the deferred command to
display the size again.
If you simply replace RootLayoutPanel with RootPanel then it will
output the full window width. What am I doing wrong here?
final FlowPanel testWidget = new FlowPanel() {
protected void onLoad() {
int width = getOffsetWidth();
Window.alert(width= + width); // Outputs 0
}
};
testWidget.add(new Label(Something));
RootLayoutPanel.get().add(testWidget);
Window.alert(width= + width); // Outputs 0
DeferredCommand.add(new Command() {
public void execute() {
int width = testWidget.getElement().getOffsetWidth();
Window.alert(width= + width); // Outputs non-zero
}
}
The value of 0 comes from FF 3.6. IE6 has almost the same problem
except that in the cases where FF returns 0, IE6 is returning 60
(presumably the default size of the label). In both cases, it returns
the full Window width in the DeferredCommand.
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] Re: Let MenuItem implement HasEnabled (issue846801)
Sorry about that. Will look at it this afternoon (US/EST). Le 20 septembre 2010 04:45, johan.rydb...@gmail.com a écrit : Ping! On 2010/09/07 16:49:52, rjrjr wrote: Please! On Tue, Sep 7, 2010 at 8:01 AM, Joel Webber mailto:j...@google.com wrote: @rjrjr: I notice you own the bug -- do you have time to look at this, or would you like me to take it off your hands? Le 6 septembre 2010 04:48, mailto:johan.rydb...@gmail.com a écrit : Reviewers: , Description: Let MenuItem implement HasEnabled and update MenuBar to use this information when selecting items. The themes are also updated with a gwt-MenuItem-disabled rule. This is an attempt to fix http://code.google.com/p/google-web-toolkit/issues/detail?id=1649 Please review this at http://gwt-code-reviews.appspot.com/846801/show Affected files: user/src/com/google/gwt/user/client/ui/MenuBar.java user/src/com/google/gwt/user/client/ui/MenuItem.java user/src/com/google/gwt/user/theme/chrome/public/gwt/chrome/chrome.css user/src/com/google/gwt/user/theme/chrome/public/gwt/chrome/chrome_rtl.css user/src/com/google/gwt/user/theme/dark/public/gwt/dark/dark.css user/src/com/google/gwt/user/theme/dark/public/gwt/dark/dark_rtl.css user/src/com/google/gwt/user/theme/standard/public/gwt/standard/standard.css user/src/com/google/gwt/user/theme/standard/public/gwt/standard/standard_rtl.css -- http://groups.google.com/group/Google-Web-Toolkit-Contributors http://gwt-code-reviews.appspot.com/846801/show -- http://groups.google.com/group/Google-Web-Toolkit-Contributors -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] Re: How to detect HTML5 support?
Daniel, Which HTML5 features are you thinking of emulating on older browsers? It seems to me that the only ones realistically emulatable are a few of the input types -- most of the stuff like canvas, audio/video, et al would be impossible without direct browser support. It might be kind of possible to support a few of the things like local storage, but it would have to depend on an ugly combination of flash/gears. Is this the kind of thing you're thinking of? Cheers, joel. Le 14 septembre 2010 07:00, dflorey daniel.flo...@gmail.com a écrit : Thanks for your reply. Yes, I know that html5 support is a mess. I guess I'll split up my stuff into separate projects supporting a single feature/property like webDB (requires native webDB / gears detection property), css3 transforms etc. Thanks for the link, very impressive! Daniel On Sep 14, 11:24 am, Thomas Broyer t.bro...@gmail.com wrote: On Sep 13, 6:04 pm, dflorey daniel.flo...@gmail.com wrote: I'm working on a HTML5 widget library that will emulate html5 when it is not supported by the browser (html5 form elements etc.) I don't know what is the best approach to take advantage of deferred binding to use the native/emulated classes. Is it better to extend the user agent to be able to detect Chrome7/ Safari etc. (CSS3 transforms) or is it better to introduce a new property? If you want to do it right, you'll actually have to add a bunch of properties, because there's nothing like HTML5 support. Even if you only talk about form additions, some browsers support a few new input type values but not all, some say they support a given type but don't provide any specific UI and/or validation (e.g. input type=date in WebKit), some browsers support validation (Chrome 7 is said to support validation on html5test.com, but it won't abort submission if a constrained input field –such as type=date or type=email– contains an invalid value). And this is only about new input types and form validation! BTW, have you looked athttps://code.google.com/p/gwt-ns/? -- http://groups.google.com/group/Google-Web-Toolkit-Contributors -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] GWT Compiler or widget.gwt.xml file optimisation for 2.1 ?
This is slightly off-topic, but I'm curious -- would having a formal nightly build actually be acceptable for use within your locked-down environment? And would the same go for offline dev-mode plugin installers? Le 12 septembre 2010 08:43, David david.no...@gmail.com a écrit : Eric, No I'm not using the draftCompile option, I will see if it improves even more. And yes, after removing the incubator from my project the whole project compile process only took 1/3rd of the time (7 minutes instead of 22 minutes). I guess the main reason is probably because we had to import both gen2 and widgetideas in. I am not able/allowed to get the trunk downloaded due to corporate policies. That's why in the past I asked if the GWT team did not want to consider daily builds/dev builds. So I will have to wait until 2.1 is out. And when it is, I guess I will again have to ask for non installers for the IE/Firefox/Chrome plugins that do not mandate an internet connection :-S. So maybe for the poor corporate developers in very secure environments that fight to get GWT accepted: think about us! ;-) David On Fri, Sep 10, 2010 at 8:48 PM, Eric Ayers zun...@google.com wrote: Hi David, Are you using the -draftCompile option? The reason I ask is that using this option cuts out the optimization steps to make the compile run faster. The end result i that running the JDT compiler takes dominates the compile time when using it. Everything on the sourcepath is compiled at least once to build the TypeOracle. Every class that is actually used is run through the JDT compile library twice. So, removing even unreferenced files from the source path should have a significant impact. We are considering all kinds of performance improvements, but keeping modules small and independent and referencing the smallest number needed is going to always give the best compilation performance. In the future, if you need one widget from a module that is full of unreferenced code, you could define a custom one that includes just the paths you need to minimize compile time. If you like, run your build with a tip of trunk GWT and add -Dgwt.speedtracerlog=/tmp/speedtracer.html both with and without the incubator dependencies and I can tell more about why your compile time improved so dramatically. -Eric. On Fri, Sep 10, 2010 at 11:02 AM, stuckagain david.no...@gmail.com wrote: Hi, I managed to finally factor our the incubator widgets from my medium sized application and now that I have no dependencies left I saw the compile time decrease with 66%. Which is an amazing. We were only using 2 widgets yet this library had such a huge impact. Are there any plans to improve on this in the future ? David -- http://groups.google.com/group/Google-Web-Toolkit-Contributors -- Eric Z. Ayers Google Web Toolkit, Atlanta, GA USA -- http://groups.google.com/group/Google-Web-Toolkit-Contributors -- http://groups.google.com/group/Google-Web-Toolkit-Contributors -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] PopupPanel rolldown animation is only accesable with incubator!?
@jlabanca: Sounds like a bit of an anachronism in the code. Is this
something we can clean up now (and do you need a hand getting it done if
so)?
Le 13 septembre 2010 03:50, stuckagain david.no...@gmail.com a écrit :
Hi,
While factoring out a dependency on GWT incubator I stumbled upon the
way the animation type is selected in the PopupPanel.
This is what the javadoc says:
/**
* Sets the animation used to animate this popup. Used by gwt-
incubator to
* allow DropDownPanel to override the default popup animation. Not
protected
* because the exact API may change in gwt 1.6.
*
* @param animation the animation to use for this popup
*/
void setAnimation(ResizeAnimation animation) {
resizeAnimation = animation;
}
So basically I will have to put my code in the same package if I want
to re-enable the rolldown animation instead of the centered one for
PopupPanel...
David
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] Wrong error message...
Whoops, looks like I missed a rename :) Thanks for the heads-up. Le 13 septembre 2010 11:03, dflorey daniel.flo...@gmail.com a écrit : ...in ResizeComposite:25 java.lang.AssertionError: LayoutComposite requires that its wrapped widget implement HasLayout should be java.lang.AssertionError: LayoutComposite requires that its wrapped widget implements RequiresResize -- http://groups.google.com/group/Google-Web-Toolkit-Contributors -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: Deletes the bikeshed. (issue816801)
Don't worry, I'm sure it will come back next time we need to do something big that needs time to settle. This ended up being a much, much better pattern than the incubator, which just became a dumping ground with version-skew hell... Le 10 septembre 2010 03:28, edwin...@gmail.com a écrit : Amen, nevertheless Bikeshed is still a good example for those who has strong willing to know and use the GWT, at least for me. On 2010/08/31 02:36:17, jlabanca wrote: Bikeshed will always have a special place in my heart. I remember not that long ago the first time I committed a Cell based widget to bikeshed, and all those hours we spent together tweaking the Expenses sample. But alas, the Expenses sample has grown up and moved out to trunk, and the Scaffold app has moved into Roo. Bikeshed is a beast from an ancient time, with no place in the modern world. You will be missed bikeshed. By most. http://gwt-code-reviews.appspot.com/816801/show -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] GWT Compiler or widget.gwt.xml file optimisation for 2.1 ?
Wait, are you saying that your compile time went down *by* 2/3 (meaning to 1/3 of its original duration)? And this is a result of pulling the incubator off of the classpath (and hoisting out a couple of widgets)? That would seem to be a pretty big difference! @Eric: This might be interesting fodder for compiler optimizations. Le 10 septembre 2010 11:02, stuckagain david.no...@gmail.com a écrit : Hi, I managed to finally factor our the incubator widgets from my medium sized application and now that I have no dependencies left I saw the compile time decrease with 66%. Which is an amazing. We were only using 2 widgets yet this library had such a huge impact. Are there any plans to improve on this in the future ? David -- http://groups.google.com/group/Google-Web-Toolkit-Contributors -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] [conference]
Allez Nicolas! Le 9 septembre 2010 09:18, nicolas de loof nicolas.del...@gmail.com a écrit : For info, I'll speak at JugSummerCamp http://www.jugsummercamp.org/ conference tomorrow on GWT 2. Long live GWT :D Nicolas -- http://groups.google.com/group/Google-Web-Toolkit-Contributors -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] Let MenuItem implement HasEnabled (issue846801)
@rjrjr: I notice you own the bug -- do you have time to look at this, or would you like me to take it off your hands? Le 6 septembre 2010 04:48, johan.rydb...@gmail.com a écrit : Reviewers: , Description: Let MenuItem implement HasEnabled and update MenuBar to use this information when selecting items. The themes are also updated with a gwt-MenuItem-disabled rule. This is an attempt to fix http://code.google.com/p/google-web-toolkit/issues/detail?id=1649 Please review this at http://gwt-code-reviews.appspot.com/846801/show Affected files: user/src/com/google/gwt/user/client/ui/MenuBar.java user/src/com/google/gwt/user/client/ui/MenuItem.java user/src/com/google/gwt/user/theme/chrome/public/gwt/chrome/chrome.css user/src/com/google/gwt/user/theme/chrome/public/gwt/chrome/chrome_rtl.css user/src/com/google/gwt/user/theme/dark/public/gwt/dark/dark.css user/src/com/google/gwt/user/theme/dark/public/gwt/dark/dark_rtl.css user/src/com/google/gwt/user/theme/standard/public/gwt/standard/standard.css user/src/com/google/gwt/user/theme/standard/public/gwt/standard/standard_rtl.css -- http://groups.google.com/group/Google-Web-Toolkit-Contributors -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: Memory Leak IE7 GWT 2.0.4
Sorry I didn't follow up earlier (this should have showed up in my
inbox, but didn't for some reason...).
@chrisr:
It is at least remotely possible that this could have leaked in 1.5.4,
but I'm not aware of any memory-leak fixes as recently as that. The
architecture that guards against leaks is sound, and hasn't changed
significantly since 1.0. There were a couple of bug fixes for little
pieces of Javascript that were triggering leaks (notably in the
RequestBuilder code, which this doesn't exercise), but that was some
time ago. As for the dev mode leak, I've asked one of my team members
who's working on optimizing dev mode to take a look at that.
@Marcos:
I wish I could do more to help with memory leaks in SmartGWT, but
that's way beyond the knowledge of anyone on our team. SmartGWT's a
wrapper around a huge Javascript library that, from your earlier post,
appears to require destroy() calls on widgets as part of its memory-
leak strategy (IIUC). That strategy's rife with problems and very hard
for users to get right in practice (I've tried it in other frameworks,
and always found myself squashing leaks ad infinitum). Do the SmartGWT
tools not provide some mechanism for tracing and finding leaks?
On Aug 30, 9:10 am, chrisr chris.robert.rowl...@gmail.com wrote:
This may be a valid solution, however its not an ideal one, as this
application is already significantly large, and its not going to be
easy to refactor all of the existing code to work this way. It will
be easy to keep this in mind while going forward, however.
As I said above, I was trying to reproduce the way a lot of the code
I'm working with has been written. Also, while I thought this was
reproducing the situation we are seeing in our live app (using GWT
1.5.4) it turns out this only produces the memory leak in development
mode using the most recent GWT. I will have to see if this produces a
leak when compiled using 1.5.4. If not then I'll probably need to
find a new simple case that reproduces the leak we're seeing.
On Aug 28, 11:48 am, Michael W mwang_2...@yahoo.com wrote:
I doubt following code causing the memory leak.
In reloadRight method, you create and assign new DecoratedTabPanel()
to tabPanel every time.
protected void reloadRight(){
++rightPanelCount;
rPanel.clear();
tabPanel = new DecoratedTabPanel();
You may reuse existing tabPanel instead of create new one.
On Aug 27, 4:21 pm, chrisr chris.robert.rowl...@gmail.com wrote:
Hi Joel, i appreciate your help.
I was running in development mode and it appears that this memory
bloat goes away when not using development mode.
We have been developing our application using older GWT (1.5.4 I
belive) so I'm used to using the old hosted mode. I didn't realize
the in browser development mode might have this side effect.
The goal of this was to reproduce a memory leak that we have in our
application (when compiled, of course) using as simple a case as
possible, in the newest version of GWT, if possible. I erroneously
thought this was accomplishing that.
Does the fact that this growth occurs in development mode suggest
anything about why I might see similar growth in a compiled GWT 1.5.4
application?
On Aug 27, 12:52 pm, Joel Webber j...@google.com wrote:
Hmm... I've tried to reproduce this on IE7 and IE8 (both quirks
standards), to no avail. I doubt it's anything in the outer HTML file,
but just in case, here's what I used:
!DOCTYPE HTML
html
head
titleHello/title
script type=text/javascript language=javascript src=hello/
hello.nocache.js/script
/head
body
div id='container'/div
/body
/html
The initial calls to getSomeText() were causing a huge number of slow-
script warnings on IE, so I was only able to run through a few
iterations. I then dropped the count by a factor of 10 to get the SSWs
under control, and the memory usage appears quite stable after a
couple of hundred clicks. (~30MB). Can you think of anything else that
might be different in your setup?
On 27 août, 08:20, chrisr chris.robert.rowl...@gmail.com wrote:
Sorry for posting this twice. If a moderator wants to/can remove the
duplicate go ahead.
On Aug 25, 2:56 pm, chrisr chris.robert.rowl...@gmail.com wrote:
I created a simple application in an attempt to reproduce a memory
leak issue in our decently large GWT application.
This test application basically contains a split panel with a button
on the left, and a tab panel full of large blocks of text on the
right.
Clicking the reload button fires the reloadRight method, and does a
panel.clear() to remove the old tab panel and a panel.add() to add
a
new tab panel to the right panel. Doing this repeatedly causes
memory
Re: Memory Leak IE7 GWT 2.0.4
Hmm... I've tried to reproduce this on IE7 and IE8 (both quirks
standards), to no avail. I doubt it's anything in the outer HTML file,
but just in case, here's what I used:
!DOCTYPE HTML
html
head
titleHello/title
script type=text/javascript language=javascript src=hello/
hello.nocache.js/script
/head
body
div id='container'/div
/body
/html
The initial calls to getSomeText() were causing a huge number of slow-
script warnings on IE, so I was only able to run through a few
iterations. I then dropped the count by a factor of 10 to get the SSWs
under control, and the memory usage appears quite stable after a
couple of hundred clicks. (~30MB). Can you think of anything else that
might be different in your setup?
On 27 août, 08:20, chrisr chris.robert.rowl...@gmail.com wrote:
Sorry for posting this twice. If a moderator wants to/can remove the
duplicate go ahead.
On Aug 25, 2:56 pm, chrisr chris.robert.rowl...@gmail.com wrote:
I created a simple application in an attempt to reproduce a memory
leak issue in our decently large GWT application.
This test application basically contains a split panel with a button
on the left, and a tab panel full of large blocks of text on the
right.
Clicking the reload button fires the reloadRight method, and does a
panel.clear() to remove the old tab panel and a panel.add() to add a
new tab panel to the right panel. Doing this repeatedly causes memory
consumption to increase without bounds.
For example, on the initial load IE7 uses around 35 MB. 125 clicks
later its using nearly 1.5GB.
Is this example doing something in a fundamentally incorrect way?
How can I keep memory usage from exploding like this?
/* Example Below */
package com.example.myproject.client;
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.Button;
import com.google.gwt.user.client.ui.DecoratedTabPanel;
import com.google.gwt.user.client.ui.DecoratorPanel;
import com.google.gwt.user.client.ui.HTML;
import com.google.gwt.user.client.ui.HTMLPanel;
import com.google.gwt.user.client.ui.HorizontalSplitPanel;
import com.google.gwt.user.client.ui.RootPanel;
/**
* Entry point classes define codeonModuleLoad()/code.
*/
public class TestApplication01 implements EntryPoint {
/**
* This is the entry point method.
*/
public void onModuleLoad() {
RootPanel.get(container).add( new MainPanel() );
}
private class MainPanel extends DecoratorPanel{
private HorizontalSplitPanel hsp;
private HTMLPanel lPanel;
private HTMLPanel rPanel;
private DecoratedTabPanel tabPanel;
int rightPanelCount = 0;
public MainPanel(){
hsp = new HorizontalSplitPanel();
hsp.setSplitPosition(25%);
hsp.setSize(800px, 400px);
lPanel = new HTMLPanel(div
id=\reloadButton\/);
rPanel = new HTMLPanel(div
id=\right-panel-contents\/);
Button reloadButton = new ReloadButton(this);
reloadButton.setVisible(true);
lPanel.add( reloadButton, reloadButton );
hsp.setLeftWidget(lPanel);
hsp.setRightWidget(rPanel);
this.add( hsp );
reloadRight();
}
char[] chars = new char[] {' ',' ',' ', ' ', ' ',
'a','b','c','d','e','f','g','h','i','j','k','l','m',
'n','o','p','q','r','s','t','u','v','w','x','y','z' };
private String getSomeText(int length){
StringBuffer sb = new StringBuffer(length);
for ( int i=0; ilength; ++i ){
sb.append( chars[ (int)Math.round(Math.random()*(chars.length-1)) ]);
if ( i0 i % 60 == 0 )
sb.append(br);
}
return sb.toString();
}
protected void reloadRight(){
++rightPanelCount;
rPanel.clear();
tabPanel = new DecoratedTabPanel();
tabPanel.setWidth(400px);
tabPanel.setAnimationEnabled(true);
String text = Load count = +rightPanelCount;
tabPanel.add( new HTML(text+br+getSomeText((int)
(Math.random()*500)+50)), Tab One);
tabPanel.add( new HTML(text+br+getSomeText((int)
Re: [gwt-contrib] IE6/7/8 huge speed problems when adding Stylenames on the fly.
[+some people who have looked at this problem in the past]
Le 19 août 2010 09:36, stuckagain david.no...@gmail.com a écrit :
Hi,
I found out that using something like addStylename() in an onmouseover
can have really catastrophic effects on performance in IE (6/7 and 8).
In fact IE8 seems to be worse than the older versions. In my
applications the browser locks up for many seconds even minutes
running at 100% CPU. DynaTrace reveals that the browser is busy doing
layout calculations.
For example we were doing a style change when moving the mouse over a
big table. In some situations this would block the browser for many
seconds (sometimes minutes, depending on the complexity of the UI).
If I just directly set the style attribute changes directly in the
code it takes almost no CPU with the same complex UI. The problem here
is that I loose a lot of flexibility in my UI to use CSS to do the
styling (what if I want to change more than just the color for
example).
I know there is something like CssResource, but as I understand it, it
will not solve the issue in this case since I still need to use an
addStyleName.
Would there be a way, or wouldn't it be an great Idea, that GWT would
have support in CssResource to copy style attributes from the
CssResouce directly in the styles of the element that I am
targetting ? That way I would not need a addStylename/addClassname but
I still have the flexibility to write down these changes in a CSS
file.
Or did I overlook such a feature ?
As I understood, the declarative UI mechanism in GWT is doing such
things, but in our apps we can not use this.
We haven't built anything like this, but we've definitely seen this problem
before. It doesn't seem unreasonable to be able to extract the text of a
CSSResource rule's properties (a bit unfortunate, since it only affects IE
and would be slower everywhere else -- maybe it would be better to provide a
more abstract mechanism that could do the right thing everywhere). There
is also some complexity added by the fact that the fastest way to apply such
a style would be Element.style = '{css string}'. But the only efficient
way to do this would be to set the whole thing at once (meaning you couldn't
easily mix them).
If I recall correctly (Kelly, Jaime, John please check me on this), the
speed problems on this case in IE tended to be a combination of layout and
style matching. Layout can be mitigated a bit if you separate the table
from the rest of the page by putting it in a position:absolute container
(putting it in a layout panel does this), but that may not help enough
and/or fit your design.
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] HTML5 tags in com.google.gwt.dom.DOM.gwt.xml module
Le 15 août 2010 10:40, Cristiano cristiano.costant...@gmail.com a écrit : Hello all, I need to work with new HTML5 elements: video and SVG's tags. Now I'm doing some experiment and I'm working out this HTML5 support by myself on a modified src of GWT: I'm adding some new Element subclasses for some example element (video,svg,g,image) and extending the com.google.gwt.dom.client.Document.java and com.google.gwt.user.client.DOM.java classes by adding in a straightforward way all the SVG and video element creation methods I need for my tests. I want to ask you if is there anyone else who is doing the same on an official branch of GWT or into the incubator, so not to do a duplicate work. Jaime and Philip have started looking at this, but I don't believe they've committed anything yet (and I doubt they'd mind a little help). There are also a couple of projects out there that have begun this as well (see below). Maybe it's time to start a concerted effort to clean up all our HTML5 libraries and wrappers? http://code.google.com/p/gwt-mobile-webkit/ http://code.google.com/p/gwt-html5-media -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] This is a bug in JSORestrictionsChecker
Bob Lex, I just ran into an interesting error message while experimenting with some JSO stuff that you might be able to shed some light on. First, here's the error: InternalCompilerException: Already seen an implementing JSO subtype (DocumentImpl) for interface (Node) while examining newly-added type (ElementImpl). This is a bug in JSORestrictionsChecker. The structure that triggered this is the following: interface Node interface Element extends Node interface Document extends Node class NodeImpl extends JSO implements Node class ElementImpl extends NodeImpl implements Element class DocumentImpl extends NodeImpl implements Document At first glance, this would appear to anger the SingleJSO gods. However, because NodeImpl contains implementations of all Node methods, there is no actual ambiguity as to which method implementation to bind to. The this is a bug wording in the error also raised my eyebrows a bit :) If I'm correct about the lack of actual ambiguity here, it would seem that the restrictions checker is just being a bit too aggressive. Do either of you have any sense for how difficult it would be to fix this (and the associated code in the compiler itself that generates the method dispatch code)? I'm perfectly willing to dig into it myself, but thought you might be able to provide a bit of context. Thanks, joel. -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: This is a bug in JSORestrictionsChecker
Le 11 août 2010 15:11, BobV b...@google.com a écrit : At first glance, this would appear to anger the SingleJSO gods. However, because NodeImpl contains implementations of all Node methods, there is no actual ambiguity as to which method implementation to bind to. The this is a bug wording in the error also raised my eyebrows a bit :) Is NodeImpl abstract? Tried both with and without. But there is only one JSO implementation of each method in the Node interface, so there can be no ambiguity in which one to call. -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] Re: Make GWT template javascript suitable for XHTML
The best way would be to upload a patch to http:// gwt-code-reviews.appspot.com/ . That makes it much easier to understand the diffs. Le 1 août 2010 11:07, Henri hfman...@gmail.com a écrit : I updated function computeScriptBase() in IFrameTemplate.js to work with DOM javascript functions instead of document.write, which seems to work, and would like you to look at it. How can I send this file to you? On Jul 23, 3:17 pm, Joel Webber j...@google.com wrote: We've tried to get rid of the document.write() tricks before, but with no success. There's always some squirrely case that crops on (especially on IE) that's forced us to put them back in. There are also a couple of specific corner cases that rely on document.write(), which would need to be preserved: 1. computeScriptBase() uses it to find the current script element, so it can compute the base url from which it was loaded. 2. It's used to determine when script injection (i.e., script tags referenced in the .gwt.xml file) is done. The above two cases are probably impossible to solve without document.write(), though I'm certainly open to ideas. Assuming that's correct, it would mean you'd have to remove automatic script base detection and disable script injection. As much as I'd like to do that, we can't do so without breaking many existing apps. If you really must have XHTML support (something I've never found any actual utility in personally), then probably the better approach would be to design a different linker for it that explicitly removes the above features. Le 22 juillet 2010 05:28, Henri hfman...@gmail.com a écrit : Hello, Currently the template javascript files IFrameTemplate.js, SingleScriptTemplate.js, and XSTemplate.js in com/google/gwt/core/ linker and HostedModeTemplate.js in com/google/gwt/core/ext/linker/ impl use document.write to manipulate the HTML page. This is not allowed in XHTML. I changed IFrameTemplate.js so it now uses equivalent DOM statements instead and that is working. XHTML documents are useful since one can use embedded SVG and MathML. If you are interested I can send the modified IFrameTemplate.js to you to check out if I did it the right way. Then we can update the other template javascript files. Hope to hear from you! Kind regards, Henri Manson -- http://groups.google.com/group/Google-Web-Toolkit-Contributors -- http://groups.google.com/group/Google-Web-Toolkit-Contributors -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] Phasing in a new, unified linker
[+matt, who's one of the few people I know outside of Google creating custom linkers] I'm 100% on board with this as well. These things weren't all that carefully designed for extension from the beginning, so it's going to be difficult to make significant changes to them without breaking existing linker extensions. Having one true linker, except for fundamentally different cases (like Chrome and Firefox extensions) would be hugely convenient. Le 26 juillet 2010 12:37, Scott Blum sco...@google.com a écrit : SGTM as far as process. Is the new linker designed to curtail extension, or to sanely encourage it? The existing primary linkers ended up getting extended in brittle ways. On Mon, Jul 26, 2010 at 12:06 PM, Lex Spoon sp...@google.com wrote: Joel, Miguel, GWTers, I am trying to phase in a new linker as the default GWT linker, and I could use some feedback on how that is accomplished. My first thought was to modify the cross-site linker in place, as was started by this patch: http://gwt-code-reviews.appspot.com/674802/show After further thought, though, the changes in that patch are simply not backward compatible. The most fundamental problem is that there are currently linkers extending the XSLinker class, and any major change to XSLinker will break these other ones. Additionally, the cross-site linker has $wnd==window, but that's no longer true in the unified linker. Both of these problems won't affect most apps, but an indeterminate few will be broken by simply committing the above patch. Here's an alternate phase-in plan that avoids the above two problems: 1. Make a new linker class and new linker name, so as not to disturb any code inheriting from our existing linkers. Commit the above patch under the new names. Anyone who can live without dev mode support can use it immediately. 2. Add development mode support to the new linker. 3. Redirect the std linker to the new one. We could add a deprecated iframe name for the iframe linker for anyone who desperately needs it. Note that people using the std linker must already be using $wnd in the necessary places. 4. Deprecate the iframe and xs linkers, and after a year or two remove them. Users of the cross-site linker will need to make sure they use $wnd in the right places before they change over. A benefit of this approach is that most apps use the std linker and will simply pick up the improvements without needing any changes. Updating people currently on the cross-site linker is trickier, but I don't see any way to get around the $wnd/window problem. Their code simply needs to be updated. -Lex -- http://groups.google.com/group/Google-Web-Toolkit-Contributors -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] Make GWT template javascript suitable for XHTML
We've tried to get rid of the document.write() tricks before, but with no success. There's always some squirrely case that crops on (especially on IE) that's forced us to put them back in. There are also a couple of specific corner cases that rely on document.write(), which would need to be preserved: 1. computeScriptBase() uses it to find the current script element, so it can compute the base url from which it was loaded. 2. It's used to determine when script injection (i.e., script tags referenced in the .gwt.xml file) is done. The above two cases are probably impossible to solve without document.write(), though I'm certainly open to ideas. Assuming that's correct, it would mean you'd have to remove automatic script base detection and disable script injection. As much as I'd like to do that, we can't do so without breaking many existing apps. If you really must have XHTML support (something I've never found any actual utility in personally), then probably the better approach would be to design a different linker for it that explicitly removes the above features. Le 22 juillet 2010 05:28, Henri hfman...@gmail.com a écrit : Hello, Currently the template javascript files IFrameTemplate.js, SingleScriptTemplate.js, and XSTemplate.js in com/google/gwt/core/ linker and HostedModeTemplate.js in com/google/gwt/core/ext/linker/ impl use document.write to manipulate the HTML page. This is not allowed in XHTML. I changed IFrameTemplate.js so it now uses equivalent DOM statements instead and that is working. XHTML documents are useful since one can use embedded SVG and MathML. If you are interested I can send the modified IFrameTemplate.js to you to check out if I did it the right way. Then we can update the other template javascript files. Hope to hear from you! Kind regards, Henri Manson -- http://groups.google.com/group/Google-Web-Toolkit-Contributors -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] Re: IE9 Preview 3 issues
Thanks, Brendan. I entered issue 5125 to capture the general IE9 support issue. I agree that it seems likely we'll be able to shift to an IE9 that derives from the standard browser base classes. Nothing would make me happier :) Le 24 juin 2010 15:08, Brendan Kenny bcke...@gmail.com a écrit : I haven't verified this on another machine, but it appears that the new IE9 Preview (when in full IE9 standards mode) no longer accepts markup in document.createElement(), which is DomImplTrident's approach to creating several elements (like buttons). I've filed an issue here: http://code.google.com/p/google-web-toolkit/issues/detail?id=5058 It seems like any GWT project that uses buttons or input elements (among others) will trigger the error and stop running. To see it in action, visit showcase with the console open, or run the following in the console: var b = document.createElement(BUTTON type='button'/BUTTON); The good thing (for the web) is that this seems to be the correct behavior wrt standards. For GWT, IE9's DOM impl might get to be a lot closer to DomImplStandard. Microsoft also doesn't include normal navigation in the preview, so regular users won't be using it as their browser and run into this problem too soon, but this change does appear to be coming. Le 24 juin 2010 15:19, Brendan Kenny bcke...@gmail.com a écrit : Also--and I haven't completely figured this out yet--something seems to be going on with support for IE's ancient filters. I'm not aware of any use of filters in GWT outside of maybe a PNG transparency fix (for IE6? not sure), but I'm sure there are third party module authors that use them to add HTML5/CSS3-style features. element.filters is throwing an error and element.style.filter is being ignored (again, just checked on my machine). This must be partly a bug (it's just wrong that checking !document.body.filters would fail), but it might be a sign that filters are going away. I use filters for IE in a module for cross-browser CSS3-like transformations, and I believe that this will leave me without a way to support them in IE9, so I'll definitely be keeping up with this. -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] UiBinder tweaks for GWT Designer
Konstantin,
I've not gone over these proposals in great detail, but it does seem like a
reasonable idea to build design time hooks into UiBinder-generated code.
One very important caveat would be that it must be possible for the compiler
to strip them out completely in production mode (this seems likely, but we'd
have to be very careful to make sure it happens in practice).
I'm going to have to defer to Ray on the architectural details (I haven't
touched this generator in a while), and I suspect he'd want to make sure the
proposed mechanisms would be generally useful for other kinds of design
tools. He's on vacation this week, so I doubt he'll be able to look into it
until next week at the earliest.
@rjrjr: Please do have a look at this when you have a moment, and if you'd
like me to look at anything in particular, I'd be happy to.
Cheers,
joel.
Le 23 juin 2010 06:40, Konstantin.Scheglov konstantin.scheg...@gmail.com a
écrit :
To support UiBinder in GWT Designer we need to have several changes
in UiBinder generators, writer and parsers.
I will describe below these changes as they are done now.
In real patch I will group as much implementation details as
possible into single class like DesignTimeUtils or GWTDesignerSupport.
It will check for GWT Designer presence and do something only in this
case.
So, main question is following. Will GWT team accept patch with such
changes?
This would allow us avoid creating internal patches for 2.0 and each
future version of GWT.
1. Declare in binder implementation interface and field with it.
Something like this:
public static interface WBPObjectHandler {void handle(String
path, Object object);}
public WBPObjectHandler wbpObjectHandler;
In method createAndBindUi() directly after creating each Widget
instance (but before applying setX() methods) wbpObjectHandler is
used to notify GWT Designer about new widget and its path in XML. GWT
Designer bind Widget instance to model (using path) and also asks
default values for all properties using getX() methods.
Path in XML is / separated string of indexes.
For example in
ui:UiBinder
ui:style/
g:FlowPanel styleName={style.panel}
g:Button text=New Button/
/g:FlowPanel
/ui:UiBinder
0/1 is FlowPanel
0/1/0 is Button
2. Declare in binder implementation Map with values of attributes.
public final java.util.Map wbpAttributes = new
java.util.HashMap();
and fill it, here is example if code generated for ui.xml above
if (wbpObjectHandler != null) wbpObjectHandler.handle(0/1/0,
f_Button2);
f_Button2.setText(New Button);
wbpAttributes.put(0/1/0 text, New Button);
f_FlowPanel1.add(f_Button2);
if (wbpObjectHandler != null) wbpObjectHandler.handle(0/1,
f_FlowPanel1);
f_FlowPanel1.setStyleName( + style.panel() + );
GWT Designer needs to know attribute values to show them to user in
properties table. Not all properties have getter, so we can not get
these values for existing Widget object.
3. In special parsers for panels, remember also values of attributes
for artificial elements. For example Cell in CellPanelParser (and
Dock in DockPanel).
// Parse horizontal and vertical alignment attributes.
if (cellElem.hasAttribute(HALIGN_ATTR)) {
String value = cellElem.consumeAttribute(HALIGN_ATTR,
hAlignConstantType);
writer.addStatement(%1$s.setCellHorizontalAlignment(%2$s,
%3$s);,
fieldName, childFieldName, value);
//XXX Instantiations
writer.addStatement(wbpAttributes.put(\%s\, %s);,
widgetElem.getPath() + Cell. + HALIGN_ATTR, value);
//XXX Instantiations
}
4. To allow quick updates of design canvas as user changes properties,
without reloading GWT context each time, we should:
4.1. Generate Binder implementation class with new name each time, so
be able to define each time new class in same ClassLoader. Right now
we just add current time to the name of class.
//XXX Instantiations
// generate class with new name each time, to allow refresh in
same ClassLoader
implName += _wbp + System.currentTimeMillis();
//XXX Instantiations
4.2. To parse/render UI.XML file content without saving, i.e. from
memory/editor, generate should try to read document from memory.
Something like this:
private Document getW3cDoc(MortalLogger logger, String templatePath)
throws UnableToCompleteException {
//XXX Instantiations
{
String content = System.getProperty(wbp.gwt.UiBinder +
templatePath);
if (content != null) {
Document doc = null;
try {
doc = new
W3cDomHelper(logger.getTreeLogger()).documentFor(content);
} catch (SAXParseException e) {
logger.die(Error parsing XML (line + e.getLineNumber() +
):
+ e.getMessage() + + content, e);
} catch (Throwable e) {
logger.die(Error parsing XML + content, e);
}
return doc;
[gwt-contrib] Re: UiBinder. Parser for TextAlignConstant (issue612803)
@rjrjr: What say ye? Have you considered doing something like this before, and perhaps found a way to generalize it such that we don't have to create a separate attribute parser for every enum? Le 22 juin 2010 07:14, konstantin.scheg...@gmail.com a écrit : Reviewers: jgw, Description: It uses friendly names. I will post patch with adding support for names like this for horizontal/vertical alignments (in addition, not replace to keep compatibility with existing code) later. Please review this at http://gwt-code-reviews.appspot.com/612803/show Affected files: user/src/com/google/gwt/uibinder/attributeparsers/AttributeParsers.java user/src/com/google/gwt/uibinder/attributeparsers/TextAlignConstantParser.java user/test/com/google/gwt/uibinder/UiBinderJreSuite.java user/test/com/google/gwt/uibinder/attributeparsers/TextAlignConstantParser_Test.java user/test/com/google/gwt/uibinder/test/UiJavaResources.java -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] Re: UiBinder. Code style for constant parsers.
Le 22 juin 2010 07:03, Konstantin.Scheglov konstantin.scheg...@gmail.com a écrit : Pretty much everything we've done so far has been limited to automatically exposing the Java-level APIs in all their ugliness. The h/v alignment values are implemented somewhat manually, but for things like enums I really like the idea that they can be exposed completely automatically. On the other hand, it would be nice to have prettier names. Perhaps we could find some sort of convention for exposing prettier names for [pseudo-]enums. What about a shortName() method on the enum itself? Hm... Yes, I think that it is possible to create some generic parser for enum-like constants. However because they are not real enums, following things come to mind: 1. During registration in AttributeParsers we will need to pass list of values; 2. To check for shortName() using reflection; 3. To test that each such constant parser instance works correctly, I would write special ui.xml file. Also one more thing worries me. Do you think that it is OK to add into GWT classes on this level information which is used only by some presentation of GWT? I mean that parsing ui.xml files is part of UiBinder, so it should be problem of UiBinder how to parse it. It *does* seem a little odd to have to add a UiBinder-specific short name to every enum (or enum-alike) used as a widget property (especially if they somehow end up in the compiled output). On the other hand, it would also kind of suck to have to put them in a completely separate place, which most widget authors would simply forget to do. On second thought, maybe we can actually get away with just convention. Most enums (e.g., Style.Unit) have names that are upper-case by convention, but we could allow UiBinder to specify them in a case-insensitive manner without ambiguity. That would leave only a handful of special cases (like the TextAlignmentParser patch you just sent). @rjrjr, konstantin: How does that sound to you both? -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] Re: Improving event handling, as initiated in 1.6
Just to let everyone know, I've finally gotten around to picking up this task again, and have updated the linked wave with my proposals. Please feel free to chime in; I could use the feedback. Le 11 juin 2010 11:13, Thomas Broyer t.bro...@gmail.com a écrit : On Thu, Jun 10, 2010 at 11:59 PM, Dan ddum...@gmail.com wrote: I don't suppose you could bump the wave Thomas? I seem to not have access to do anything but add blank replies... I've added you to the wave. Don't know what happened as you're a member of GWT-Contrib, which has full access to the wave... -- http://groups.google.com/group/Google-Web-Toolkit-Contributors -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] Any ETA for 2.1?
We're also working to get the new widgets libraries stabilized well before that, though we don't have hard dates. One thing to look for would be the removal of the Note: This class is new and its interface subject to change. warnings in the javadoc. Or just ask here :) Le 21 juin 2010 14:29, Chris Ramsdale cramsd...@google.com a écrit : While this shouldn't be taken as a binding set of dates, we are looking to wrap up a 2.1 RC in late Q3, with GA release in early Q4. On Mon, Jun 21, 2010 at 12:30 PM, Thomas Broyer t.bro...@gmail.comwrote: Hi Googlers^H^H G-men! Do you have any ETA for 2.1 M2 (or RC1?), and/or 2.1 GA? We're looking at RequestFactory, ActivityManager and data presentation widgets for a new project, but they're far from complete now (particularly RequestFactory, and ActivityManager isn't plugged with the History). So we'd like to know when do you think they'll be usable enough so we can start use them, or if we should rather plan on using something else (GWT-RPC, our already-existing-though-not- perfect PlaceManager, etc.) -- http://groups.google.com/group/Google-Web-Toolkit-Contributors -- http://groups.google.com/group/Google-Web-Toolkit-Contributors -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] mail patch
Thanks, Stephen. @Dan: Is this still applicable, or has it been fixed already? Le 9 juin 2010 13:21, Stephen Haberman step...@exigencecorp.com a écrit : Hi, I was playing with the Mail example this morning and saw a stack trace casting the Message class to Comparable for the TreeMap inside of the MailSelectionModel.toString(). Seemed to happen most reliably when clicking select all on this page. A simple fix is attached. Thanks, Stephen -- http://groups.google.com/group/Google-Web-Toolkit-Contributors -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] UiBinder. Code style for constant parsers.
Le 19 juin 2010 10:34, Konstantin.Scheglov konstantin.scheg...@gmail.com a
écrit :
Why existing horizontal/vertical alignment parsers use so unfriendly
names for alignments? ALIGN_RIGHT looks not very good in XML. Why
not just right? This would be more natural for people with HTML
background.
I ask because I have already TextAlignConstantParser and not sure
which style to use - same as in existing parsers, or more friendly.
Right now it looks so:
private static final String PREFIX =
com.google.gwt.user.client.ui.TextBoxBase.ALIGN_;
private static final HashMapString, String values = new
HashMapString, String();
static {
values.put(left, PREFIX + LEFT);
values.put(center, PREFIX + CENTER);
values.put(right, PREFIX + RIGHT);
values.put(justify, PREFIX + JUSTIFY);
}
Pretty much everything we've done so far has been limited to automatically
exposing the Java-level APIs in all their ugliness. The h/v alignment values
are implemented somewhat manually, but for things like enums I really like
the idea that they can be exposed completely automatically.
On the other hand, it would be nice to have prettier names. Perhaps we could
find some sort of convention for exposing prettier names for [pseudo-]enums.
What about a shortName() method on the enum itself?
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] DockPanelParser and width/height attributes
That certainly looks like a leftover implementation detail that could be
cleaned up. If you don't mind putting together a patch I'd be happy to
commit it.
Le 18 juin 2010 08:23, Konstantin.Scheglov konstantin.scheg...@gmail.com a
écrit :
Is there reason to have separate handling for width/height
attributes?
As I can see, CellPanelParser.parseCellAttributes() already handles
these attributes and generates same statements.
// And they can optionally have a width.
if (child.hasAttribute(width)) {
writer.addStatement(%1$s.setCellWidth(%2$s, \%3$s\);,
fieldName, childFieldName,
child.consumeRawAttribute(width));
}
// And they can optionally have a height.
if (child.hasAttribute(height)) {
writer.addStatement(%1$s.setCellHeight(%2$s, \%3$s\);,
fieldName, childFieldName,
child.consumeRawAttribute(height));
}
// Parse the CellPanel-specific attributes on the Dock element.
CellPanelParser.parseCellAttributes(child, fieldName,
childFieldName, writer);
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] Re: DockPanelParser and width/height attributes
I'll have a look this afternoon. w.r.t. the other patch, I'm running all the
tests right now. Thanks for both of these!
Le 18 juin 2010 11:08, Konstantin.Scheglov konstantin.scheg...@gmail.com a
écrit :
I've added patch for review.
http://gwt-code-reviews.appspot.com/633802/show
BTW, I've added also other patch yesterday and would like to add more
of them in future (TextAlignConstant parser, AbsolutePanel support,
etc). What is procedure for asking review? Sorry if I'm too
impatient. ;-)
On Jun 18, 5:26 pm, Joel Webber j...@google.com wrote:
That certainly looks like a leftover implementation detail that could be
cleaned up. If you don't mind putting together a patch I'd be happy to
commit it.
Le 18 juin 2010 08:23, Konstantin.Scheglov
konstantin.scheg...@gmail.com a
écrit :
Is there reason to have separate handling for width/height
attributes?
As I can see, CellPanelParser.parseCellAttributes() already handles
these attributes and generates same statements.
// And they can optionally have a width.
if (child.hasAttribute(width)) {
writer.addStatement(%1$s.setCellWidth(%2$s, \%3$s\);,
fieldName, childFieldName,
child.consumeRawAttribute(width));
}
// And they can optionally have a height.
if (child.hasAttribute(height)) {
writer.addStatement(%1$s.setCellHeight(%2$s, \%3$s\);,
fieldName, childFieldName,
child.consumeRawAttribute(height));
}
// Parse the CellPanel-specific attributes on the Dock element.
CellPanelParser.parseCellAttributes(child, fieldName,
childFieldName, writer);
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] FileUpload.setEnabled(false) causing invalid access of stack red zone 0x141055ff8 rip=0x101098a05
Even if that were a stupid thing to do, it shouldn't be crashing like that :) I suspect that most browsers would either silently fail or throw an exception under those circumstances, but that should be pretty harmless. What browser/platform are you seeing this on? At a glance, the bug looks like something to do with the plugin's marshalling code. Le 4 juin 2010 13:47, Aaron Steele eightyste...@gmail.com a écrit : I'm seeing something fairly funky occur if I disable a FormUpload widget in a FormPanel.onSubmit() handler (here's the code: http://pastebin.com/SSSqGtB1). Basically the Dev server and browser crashes with the following console message: Invalid access of stack red zone 0x141055ff8 rip=0x101098a05 Running it with log=SPAM prints the following output over and over and over again until the crash: Invoke native method @com.google.gwt.dom.client.Element::setPropertyBoolean(Ljava/lang/String;Z) - this=JavaScript object(12) - arg[0]=string: 'disabled' - arg[1]=bool: true - return void Invoke native method @com.google.gwt.dom.client.Element::setPropertyBoolean(Ljava/lang/String;Z) - this=JavaScript object(7) - arg[0]=string: 'disabled' - arg[1]=bool: true - return void What's the expected behavior if a FormUpload is disabled in the FormPanel.onSubmit() handler (if disabling a FormUpload is kind of a stupid thing to do, uh, FHMP)? -- http://groups.google.com/group/Google-Web-Toolkit-Contributors -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] Tabless
That's all basically correct. The VerticalPanel alignment methods are a little funky to reimplement in FlowPanel -- someone would have to sit down and actually try all the cases to make sure they work (I'm fairly sure text-alignment: will do it, but I'd need to confirm). Le 3 juin 2010 12:11, Ray Ryan rj...@google.com a écrit : So that'd mean deprecating DockPanel, SplitPanel, TabPanel and VerticalPanel. Any others? We shouldn't deprecate RootPanel, right? The deprecation language will probably need to point out that the new panels aren't just drop in replacements — that they require standards mode, and are most easily used under a RootLayoutPanel. Is that accurate? Anything else to say? For VerticalPanel, we'd tell them to use FlowPanel instead, but what could we tell them about its alignment methods? Is there generic advice to offer for doing that kind of thing in a FlowPanel? On Wed, May 26, 2010 at 8:41 AM, Joel Webber j...@google.com wrote: Well... HorizontalPanel is still useful in some instances, and we have no way of providing the same behavior in a general way because CSS layout is a bloody mess. I'd be ok with deprecating the others (StackPanel, TabPanel, VerticalPanel, and DockPanel) though. Le 26 mai 2010 11:36, Ray Ryan rj...@google.com a écrit : Joel, can we @Deprecate all the redundant non-flow panels yet? It's getting harder and harder for people to discover the right thing to do. On Wed, May 26, 2010 at 7:15 AM, Joel Webber j...@google.com wrote: The FlowPanel (just a simple div that leaves its children's styles unmodified) already allows you to do this. For the vertical case, this tends to happen naturally with block-level children. The horizontal case is trickier, however. Using float:left captures some, but definitely not all cases (vertical alignment is quite hard). inline-block isn't supported on all browsers (and has behavior quirks even on modern browsers). Basically, there's no simple answer that actually works across browsers, so we haven't yet tried to offer a widget that does this automatically. Your best bet is to actually just use a FlowPanel and style its children using the kinds of tricks described in the linked Wikipedia article. Maybe one day we'll get hbox/vbox/flexbox across browsers, but until then horizontal alignment is extremely difficult to generalize. Cheers, joel. Le 25 mai 2010 06:39, Ivo ivom...@gmail.com a écrit : The next GWT Developments, will have alternatives to the VerticalPanel and HorizontalPanel, using no table tags?? http://en.wikipedia.org/wiki/Tableless_web_design For instance, the HorizontalPanel could have a alternative named HorizontalFlowPanel, that instead of generate this code: table tr td cell1 /td td cell2 /td /tr /table Generate that: div style=float:left cell1 /div div style=float:left cell2 /div This alternative is lighter for the browser, and for the developer when we needs to know what code are GWT generating. You have some development in this area? -- http://groups.google.com/group/Google-Web-Toolkit-Contributors -- http://groups.google.com/group/Google-Web-Toolkit-Contributors -- http://groups.google.com/group/Google-Web-Toolkit-Contributors -- http://groups.google.com/group/Google-Web-Toolkit-Contributors -- http://groups.google.com/group/Google-Web-Toolkit-Contributors -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] Tabless
I'm fine with leaving h/v undeprecated for the time being. It is worth pointing out that the vertical alignment *within* cells of a vertical panel isn't usually useful, because as John says, it tightly wraps its content vertically. Getting a vertical panel to stretch out vertically such that there is any freedom of vertical movement for its children is both unusual and hard to achieve. Le 3 juin 2010 12:56, Ray Ryan rj...@google.com a écrit : No argument. And since we've never, ever managed to actually delete a deprecated class so far as I know, the issue may not come up for a while… On Thu, Jun 3, 2010 at 9:53 AM, Amir Kashani amirkash...@gmail.comwrote: While I think deprecating these widgets is definitely the right move, I don't think the normal policy of removing them after one release will work (is this still the actual policy?). Breaking an application's dependence on these widgets and switching to the new equivalents is a particular daunting task for a large application as it has to happen all at once. That is, either the entire app becomes standards compliant or none of it. That could be a awful lot of tables CSS to fix. - Amir On Wed, May 26, 2010 at 8:36 AM, Ray Ryan rj...@google.com wrote: Joel, can we @Deprecate all the redundant non-flow panels yet? It's getting harder and harder for people to discover the right thing to do. On Wed, May 26, 2010 at 7:15 AM, Joel Webber j...@google.com wrote: The FlowPanel (just a simple div that leaves its children's styles unmodified) already allows you to do this. For the vertical case, this tends to happen naturally with block-level children. The horizontal case is trickier, however. Using float:left captures some, but definitely not all cases (vertical alignment is quite hard). inline-block isn't supported on all browsers (and has behavior quirks even on modern browsers). Basically, there's no simple answer that actually works across browsers, so we haven't yet tried to offer a widget that does this automatically. Your best bet is to actually just use a FlowPanel and style its children using the kinds of tricks described in the linked Wikipedia article. Maybe one day we'll get hbox/vbox/flexbox across browsers, but until then horizontal alignment is extremely difficult to generalize. Cheers, joel. Le 25 mai 2010 06:39, Ivo ivom...@gmail.com a écrit : The next GWT Developments, will have alternatives to the VerticalPanel and HorizontalPanel, using no table tags?? http://en.wikipedia.org/wiki/Tableless_web_design For instance, the HorizontalPanel could have a alternative named HorizontalFlowPanel, that instead of generate this code: table tr td cell1 /td td cell2 /td /tr /table Generate that: div style=float:left cell1 /div div style=float:left cell2 /div This alternative is lighter for the browser, and for the developer when we needs to know what code are GWT generating. You have some development in this area? -- http://groups.google.com/group/Google-Web-Toolkit-Contributors -- http://groups.google.com/group/Google-Web-Toolkit-Contributors -- http://groups.google.com/group/Google-Web-Toolkit-Contributors -- http://groups.google.com/group/Google-Web-Toolkit-Contributors -- http://groups.google.com/group/Google-Web-Toolkit-Contributors -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: RR : Rework ImageResourceGenerator to address several issues (issue335802)
Crap, sorry. I/O ate my brain. Reviewing now. Le 2 juin 2010 10:04, b...@google.com a écrit : Ping. http://gwt-code-reviews.appspot.com/335802/show -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] Tabless
The FlowPanel (just a simple div that leaves its children's styles unmodified) already allows you to do this. For the vertical case, this tends to happen naturally with block-level children. The horizontal case is trickier, however. Using float:left captures some, but definitely not all cases (vertical alignment is quite hard). inline-block isn't supported on all browsers (and has behavior quirks even on modern browsers). Basically, there's no simple answer that actually works across browsers, so we haven't yet tried to offer a widget that does this automatically. Your best bet is to actually just use a FlowPanel and style its children using the kinds of tricks described in the linked Wikipedia article. Maybe one day we'll get hbox/vbox/flexbox across browsers, but until then horizontal alignment is extremely difficult to generalize. Cheers, joel. Le 25 mai 2010 06:39, Ivo ivom...@gmail.com a écrit : The next GWT Developments, will have alternatives to the VerticalPanel and HorizontalPanel, using no table tags?? http://en.wikipedia.org/wiki/Tableless_web_design For instance, the HorizontalPanel could have a alternative named HorizontalFlowPanel, that instead of generate this code: table tr td cell1 /td td cell2 /td /tr /table Generate that: div style=float:left cell1 /div div style=float:left cell2 /div This alternative is lighter for the browser, and for the developer when we needs to know what code are GWT generating. You have some development in this area? -- http://groups.google.com/group/Google-Web-Toolkit-Contributors -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] Tabless
Well... HorizontalPanel is still useful in some instances, and we have no way of providing the same behavior in a general way because CSS layout is a bloody mess. I'd be ok with deprecating the others (StackPanel, TabPanel, VerticalPanel, and DockPanel) though. Le 26 mai 2010 11:36, Ray Ryan rj...@google.com a écrit : Joel, can we @Deprecate all the redundant non-flow panels yet? It's getting harder and harder for people to discover the right thing to do. On Wed, May 26, 2010 at 7:15 AM, Joel Webber j...@google.com wrote: The FlowPanel (just a simple div that leaves its children's styles unmodified) already allows you to do this. For the vertical case, this tends to happen naturally with block-level children. The horizontal case is trickier, however. Using float:left captures some, but definitely not all cases (vertical alignment is quite hard). inline-block isn't supported on all browsers (and has behavior quirks even on modern browsers). Basically, there's no simple answer that actually works across browsers, so we haven't yet tried to offer a widget that does this automatically. Your best bet is to actually just use a FlowPanel and style its children using the kinds of tricks described in the linked Wikipedia article. Maybe one day we'll get hbox/vbox/flexbox across browsers, but until then horizontal alignment is extremely difficult to generalize. Cheers, joel. Le 25 mai 2010 06:39, Ivo ivom...@gmail.com a écrit : The next GWT Developments, will have alternatives to the VerticalPanel and HorizontalPanel, using no table tags?? http://en.wikipedia.org/wiki/Tableless_web_design For instance, the HorizontalPanel could have a alternative named HorizontalFlowPanel, that instead of generate this code: table tr td cell1 /td td cell2 /td /tr /table Generate that: div style=float:left cell1 /div div style=float:left cell2 /div This alternative is lighter for the browser, and for the developer when we needs to know what code are GWT generating. You have some development in this area? -- http://groups.google.com/group/Google-Web-Toolkit-Contributors -- http://groups.google.com/group/Google-Web-Toolkit-Contributors -- http://groups.google.com/group/Google-Web-Toolkit-Contributors -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: Adds a mobile-friendly drag-scroll implementation. (issue530801)
We should definitely consider how we're going to bring gesture/touch events into the existing event framework. I went ahead and wrote this the simple way because it will only ever need to work on mobile webkit browsers, which all safely support addEventListener() and don't leak memory. Le 14 mai 2010 15:07, cromwell...@gmail.com a écrit : Joel, I think post I/O perhaps we should add touch events support to dispatchEvent() rather than call addEventListener directly, so you'd be able to invoke sinkEvents(Event.TOUCH_EVENTS);. I did this for my apps and have working code. http://gwt-code-reviews.appspot.com/530801/diff/1/9 File /bikeshed/src/com/google/gwt/mobile/client/TouchHandler.java (right): http://gwt-code-reviews.appspot.com/530801/diff/1/9#newcode57 /bikeshed/src/com/google/gwt/mobile/client/TouchHandler.java:57: }, capture); Memory leak? http://gwt-code-reviews.appspot.com/530801/show -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] Setting DocType or Standards mode within generated cache.html files
Erin, The DOCTYPE of the script HTML won't affect the behavior of the outer page. You should only have to put a simple !DOCTYPE html in the outer page -- that's it. If you're still having troubles with LayoutPanel after that, ping me. Cheers, joel. Le 13 mai 2010 15:04, Erin sparkle...@gmail.com a écrit : I am trying to use the TabLayoutPanel, but having issues within IE. Using Debug bar, I can see that the frame created from the generated files has document mode of IE5 Quirks. There is no DocType set within the generated cache.html. I have tried just adding the DocType definition to the page that my jJavascript reference to the module is on, but though the frame containing the main page is IE7Standards, the frame containing the module is still Quirks. Is there a setting that can be made in the java code or the module definition(gwt.xml) that can set the DocType on the frames created to hold the gwt module generated code. I would appreciate any assistance. Thanks, Erin -- http://groups.google.com/group/Google-Web-Toolkit-Contributors -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] Re: use ParameterizedType at GWT#create method (issue429801)
I'm not the right one to review this, but I just wanted you to (a) apologize for your email getting caught by the spam filter (which I just fixed), and (b) let you know that we're all pretty slammed getting ready for I/O, so it might be a while before anyone has time to take a look. This looks like a fairly complex change, so it would be very helpful if you could post some sort of (at least rough) design document. Le 1 mai 2010 03:50, takeshi.ko...@gmail.com a écrit : Hi All This patch is my first contribution. I don't know whom to ask for this review. Please teach it to me? http://gwt-code-reviews.appspot.com/429801/show -- http://groups.google.com/group/Google-Web-Toolkit-Contributors -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] History misses token set by Window.Location.replace()
I've added comments to the bug so they don't get lost. The short form of the story is that I'm not sure it's possible to make this work in the general case because of various cross-browser issues (I'm always happy to be proven wrong, though!) Le 6 mai 2010 18:58, jarrod jarrod.carl...@gmail.com a écrit : In my module's entry point, I check the current History token, and if it is blank, I set it to a default value. This allows my normal MVP mechanisms to show the default view on startup. I set the default value using Window.Location.replace() so as not to create an entry in the browser's history stack. Unfortunately, History misses this new token and returns the blank one from before I replaced the URL. This looks like a defect to me. Anyone? I filed an issue with code samples... http://code.google.com/p/google-web-toolkit/issues/detail?id=4919 -- http://groups.google.com/group/Google-Web-Toolkit-Contributors -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] Re: Selection/Cursor for RichTextArea implementation
You can always just put it up in a little code.google.com (or github, as you see fit) project. That usually makes it easier for others to try it out. Le 30 avril 2010 14:03, kozura koz...@gmail.com a écrit : Ok, understood, just didn't want it to get lost in the mix. Maybe for now I'll just attach the library as-is to the issue, and worry about making it GWT-compliant later. Thanks, jk On Apr 30, 11:57 am, John LaBanca jlaba...@google.com wrote: External contributions are always welcome, but we've all been heads down for the last couple of weeks getting ready for Google I/O. We promise to be more attentive and look at your proposal once I/O is over. Thanks, John LaBanca jlaba...@google.com -- http://groups.google.com/group/Google-Web-Toolkit-Contributors -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] RootLayoutPanel
Kerr, Can you show me roughly the code needed to get into this state? It sounds like it could be a problem, but I'm having a slightly hard time imagining the precise code that got you here. Cheers, joel. Le 15 avril 2010 12:34, kerrr kerr.rai...@gmail.com a écrit : Hi, I've been playing around with RootLayoutPanel and have some questions about how it works. I had a UI layed out by placing widgets in lements on a page using RootLayout.get(foo).add(widget). This was fine. I wanted to try adding a LayoutPanel on top to achieve a LightBox style effect. This was all goign well untill I wanted to gt rid of the LayoutPanel. I couldn't work out how to do it. I removed the LayoutPanel from the RootLayoutPanel but none of the underlying ui could be clicked. Eventually I discovered that I needed to remove the RootLayoutPanel from the RootPanel. This works but leaves the singleton RootLayoutPanel detached and calling RootLayoutPanel.get() again simply returns the detached RootLayoutPanel. Trying to add anything to it throws an exception. You can work around this my reattaching the RootLayoutPanel yourself, but this seems a bit ugly. So here are my thoughts on an improvement. Please let me know if there is any reason why this would cause a problem. 1. Have RootLayoutPanel detach itself automatically from its parent if all it's children are removed. 2. Defer attaching the RootLayoutPanel to RootPanel untill a child is added to it. I'm planning on implementing my own replacement RootLayoutPanel to see how it works, but please let me know if there is anything I should consider when doing this. Cheers Kerr -- http://groups.google.com/group/Google-Web-Toolkit-Contributors -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] Text Area enhancement
Allahbaksh, That seems like it would be useful, though looking at the code I'm a little wary as to whether it works in all circumstances (font-size changes, etc). The first step would be to convert it to Java (usually pretty straightforward) and test it under all the circumstances you can think of -- change the font-size, resize the element, try it on all browsers, and so forth. Cheers, joel. Le 19 avril 2010 03:02, Allahbaksh Asadullah a.allahba...@gmail.com a écrit : Hi, I want to get the coordinates of the Cursor position in TextArea so that I can show the popup appropriately. Please find the similar implementation of http://enobrev.info/cursor/. I am not sure whether a new method to get the coordinates of the cursor is really helpful to other but I think it would grea. Warm Regards, Allahbaksh -- http://groups.google.com/group/Google-Web-Toolkit-Contributors -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] TabLayoutPanel: Distinguish between user- and code-initiated SelectionEvents
[I just commented directly on the linked issue] On Thu, Apr 8, 2010 at 11:17 PM, jarrod jarrod.carl...@gmail.com wrote: I would really like to see a way to distinguish between SelectionEvents (and BeforeSelectionEvents) in TabLayoutPanel based on whether the event occurred in response to a user action (e.g. clicking a tab) or a programmatic call (e.g. TabLayoutPanel#selectTab). I have created an issue for this request: http://code.google.com/p/google-web-toolkit/issues/detail?id=4834 Any thoughts on a possible work around? Will sub-classing TabLayoutPanel mean I need to also sub-class the TabLayoutPanelParser for use with UiBinder? -- http://groups.google.com/group/Google-Web-Toolkit-Contributors To unsubscribe, reply using remove me as the subject. -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] Re: RFC: Web worker proposal and proof of concept
Brendan, At a quick glance, this looks pretty much like I would have expected a good workers library to look like. Is there any way I *could* convince you to make a wave of it? It's a pretty big description, and would probably diverge badly on a mailing list (@everyone: If anyone who frequents this list doesn't yet have a wave account, don't hesitate to ping me so I can get you invites). If I understand correctly, it looks like you've made this work without patching GWT proper. Assuming that's correct, are there any changes that would have made it simpler or more efficient? Cheers, joel. On Thu, Apr 8, 2010 at 9:41 PM, Brendan Kenny bcke...@gmail.com wrote: Gah, well, it should have been a wave. Aside from the assorted grammatical problems, the library is https://code.google.com/p/gwt-ns/ and the all important goal of To patching of GWT should of course be NO patching. Also, I'm not sure if the workflow of the current implementation is entirely clear. 1) A class extends the WorkerEntryPoint and does what it needs to do, dealing with messages from its parent as they arrive. If it fulfills the requirements listed above under Valid Worker Modules, it can be instantiated and used as a web worker. 2) The parent project instantiates a worker from a worker module as listed under To Use a Worker. The object created can only give messages, receive them, and be terminated. 3) Developers compile *only* the parent project. The invoked generator and linkers handle the rest. On Apr 8, 8:05 pm, Brendan Kenny bcke...@gmail.com wrote: This might be a bit unusual. I have a fairly reasonable proposal for supporting web workers in GWT proper, and a working proof of concept that shouldn't come anywhere near the core toolkit. Everyone seems busy with what looks like 2.1 and the upcoming I/O, so I'm not expecting miracles, but I would appreciate any wider perspective and maybe some Compiler insight to make the implementation less of a complete hack. A few months ago I put together a module to get workers working nicely with the GWT compiling/linking process. It was originally just on a bit of a lark, but it's proven so easy to use (thanks to GWT, not me) that I've ended up developing a few projects with it, two examples of which I've posted over with the code (http://code.google.com/p/gwt- ns/). I finally have some time to come back to the module and finish some lingering issues, but thought I might try and get some other perspectives first. If there's a GWT 2.1 web worker skunkworks project already in progress, please let me know now =) To give credit where its due: several files came from the Speedtracer worker overlay code and one or two files came from GALGWT. I've preserved copyright notices everywhere, and everything else is also Apache 2.0 licensed. I also finally got around to watching 2008's GWT Extreme! and found out my compilation scheme is very similar to what Ray Cromwell was up to two years ago (which probably happens a lot). He called it the Generator+Linker+Generator+Linker pattern, though in this case it's more Generator+Linker(+Generator+Linker)*. Anyway, like Ray Ryan, I wish this were a wave, but I'll stick to the board for now. I tried to keep it short, but it got rather long, so if there is interest I can make it look a bit more like an actual design document in a wave and hook it up to the water cooler. === Motivation === Web workers, as currently specifiedhttp:// www.whatwg.org/specs/web-workers/current-work/ have two primary requirements. They are separate Javascript files, loaded in a worker constructor that 1. Doesn't access the DOM 2. Don't share state or context with other execution contexts (e.g. their parent script). Once a worker is loaded and running, the worker and its parent can pass messages to each other, usually in JSON form. At least for transitional worker support, I'm suggesting a third condition 3. No single code execution will throw a slow script warning, even when run *normally* in an older/slower browser. This does necessarily limit functionality, e.g. ruling out the usual worker examples of blocking I/O and long running calculations. The first isn't really welcome in the GWT world, anyways, and really any synchronous operation is a bad fit for GWT/Javascript. This condition can also just be considered transitional; I'll go with it for now and just assert that another level of deferred binding could give allow more flexibility on this point. Accepting these three conditions, a true worker object becomes functionally equivalent to a simple isolated object with only post and receive message methods in its exposed interface (an Actor, if you're into that sort of thing). In practice, the only difference is that some newer platforms will execute the native worker off the main thread. In exchange for some loss of flexibility, instead of
Re: [gwt-contrib] Re: Comment on EnumOptimizations in google-web-toolkit
[+cromwell: What's the current state of the enum optimizations? I seem to recall they were partially done, but forgot where the doc is] On Mon, Apr 12, 2010 at 11:28 AM, codesite-nore...@google.com wrote: Comment by piotr.swigon: Joel, I would like to ask if anything has changed regarding enums implementation in GWT 2.0.X ? We're having a discussion in gwt-google-apis if we should start using enums instead of string-enum pattern, and some information about current state would be highly appreciated. For more information: http://code.google.com/p/google-web-toolkit/wiki/EnumOptimizations -- http://groups.google.com/group/Google-Web-Toolkit-Contributors To unsubscribe, reply using remove me as the subject. -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: A question!
[+gwt group] Konark, I actually don't see an attached screenshot (perhaps you forgot the attachment -- I do that all the time). I would normally recommend just looking at the Showcase source (it's part of the GWT distribution, and you can find it online here: http://code.google.com/p/google-web-toolkit/source/browse/#svn/trunk/samples/showcase). If you have questions about specifics, please feel free to ask them here on the group, and I may be able to help as well. Cheers, joel. On Wed, Apr 7, 2010 at 2:40 PM, Konark Shah sha...@plu.edu wrote: Hello Sir, I am a student of Pacific Lutheran University ,Tacoma ,WA. I am currently working on my final year (Computer Sci) project which is a website, being development with GWT. My team and I are stuck at one part in the project which might be a piece of cake for skilled developers like you. All we are trying to do is figure out how to create a bar similar to the one in your GWT Showcase application. It will make more sense if you check the screenshot attached with this email. It will be a huge favor on us if you can give us some idea how to create a link-bar like that. We are aware that there is Tab bar and tab-panel widget available however, they are not matching our GUI design. We look forward for your email. Konark Shah Student Pacific Lutheran University, Tacoma WA -- You received this message because you are subscribed to the Google Groups Google Web Toolkit group. To post to this group, send email to google-web-tool...@googlegroups.com. To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
Re: [gwt-contrib] DockLayoutPanel addLayoutCompleteHandler
I was hoping that because most people (not using the Maps API) wouldn't need
this, it wouldn't be necessary to provide a special case for layout
complete outside of the existing animation callbacks. Does it not work to
put the Map in a RequiresResize container and call its layout method when
onResize() is called?
On Thu, Mar 18, 2010 at 2:42 AM, jd jdpatter...@gmail.com wrote:
Hi, I use DockLayoutPanel with Google maps and there is a known issue
where any component inside a DockLayoutPanel that depends on the size
of its container must be initialized like this:
root.animate(0, new AnimationCallback()
{
public void onLayout(Layer layer, double progress)
{
}
public void onAnimationComplete()
{
// init internal widget
}
}
I was thinking it might be more obvious to include a handler after the
layout is complete?
addLayoutCompleteHandler()?
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
To unsubscribe from this group, send email to
google-web-toolkit-contributors+unsubscribegooglegroups.com or reply to
this email with the words REMOVE ME as the subject.
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] Re: LayoutImplIE6 and onResize()
John, Sorry for the slow response -- I've had a browser window open for several days to respond, but I keep getting pulled off onto other things. It sounds like this is indeed an ordering bug. It's hard to be sure precisely when IE's going to call onresize() (onmove() and onresize() are obscure non-standard events that aren't documented all that well). But what you're saying makes perfect sense, and I'll try to find a way to get the ordering straight. Would you mind entering an issue (or pointing me to it if you already have) that captures this? It may take me a little while to get a test case together and work out a solution. Please let me know anything you discover that might help. Thanks, joel. On Wed, Mar 31, 2010 at 5:51 AM, jd jdpatter...@gmail.com wrote: Does anyone think this is a bug? Or is it expected behaviour? On Mar 23, 10:40 pm, jd jdpatter...@gmail.com wrote: Something else related to this problem: when a DockLayoutPanel is animated to resize its children, onResize() is called *before* the resize but my child component was expecting to examine its new size. The JavaDoc for onResize says This method must be called whenever the implementor's size has been modified. Has been modified signifies that it should be called *after* the resize has occurred which would definitely be more useful and expected. Currently, onResize is not called at the end of the animation because the animations onComplete() calls Layout.layout() and not Layout.layout(0, callback). i.e. if the callback was passed then onResize() should also get called at the end of the animation. John On Mar 20, 12:31 pm, jd jdpatter...@gmail.com wrote: Hi, I am experiencing a problem using a DockLayoutPanel with IE6 where a child widgets RequiresResize.onResize() is fired before the LayoutImplIE6 has updated the widgets width and height with new values. I have a child widget that needs to know when it is resized so it can resize a nested MapWidget. I must do this because setting the maps height to 100% does not work inside a DockLayoutPanel child in IE7 because the element is positioned absolutely using top, bottom, left, right. Using this same absolute positioning for the child map does work in IE7 but obviously not in IE6. My current solution is to implement RequiresResize and explicitly resize the map to the dimensions of the container. This works well in all browsers except IE6 because the container element has not yet been resized by LayoutImplIE6 It looks like this is due to the RootLayoutPanel registering its window resize handler before the LayoutImplIE6 registers its handler. I could work around this problem by either making the map a direct child of the DockLayoutPanel which means that the browser specific resize problems are handled by the Layout. Alternatively, I could use another nested LayoutPanel or implement browser specific resize logic myself. But it seems that onResize() is designed for situations like this? Thanks, John -- http://groups.google.com/group/Google-Web-Toolkit-Contributors To unsubscribe, reply using remove me as the subject. -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] TabLayoutPanel suggestion: Add tab-position property
On Wed, Mar 24, 2010 at 1:01 PM, dflorey daniel.flo...@gmail.com wrote: I've been missing that one as well. I can provide patches if desired. -- On Wed, Mar 24, 2010 at 11:40 AM, dflorey daniel.flo...@gmail.com wrote: I just needed a TabLayoutPanel with Tabs on the bottom instead of tabs on the top. I copied the TabLayoutPanal and changed the orientation. I'd like to suggest to add this feature as an option in another cstr. It requires just 3 lines of code ;-) [sorry for the slow response -- swamped lately] Would you mind entering issues for these and pointing me at them? I know it sounds kind of pedantic for little changes, but we're trying to manage our workflow more carefully these days. Patches always speed things up, of course :) Cheers, joel. -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] Re: IE9 preview support ?
I just installed the preview the other day as well, and most things seem to be working ok (the UA script should detect it as IE8 for the time being). As others point out on this thread, the DOMContentLoaded thing is expected (because they added addEventListener()) but likely harmless. I haven't had time to look into it too deeply yet, but I'm really hoping that they're far enough along in standards implementation that we can switch away from the DOMImplTrident base and consider IE9 a standard browser. We'll see how that goes in practice soon... On Sun, Mar 21, 2010 at 9:24 PM, Brendan Kenny bcke...@gmail.com wrote: I get the same DOMContentLoaded error, but that's as expected. Check out the addEventListener event registration section in the release notes: http://ie.microsoft.com/testdrive/info/ReleaseNotes/Default.html#WPKI My applications all work as well--even while throwing that error-- which is weird. I wouldn't think the bootstrap script would work if the event is detected as implemented but never fires, but there it is. I'm a big fan of Microsoft's choice of chrome for the preview...no one will be using this as their default browser and complaining accordingly. On Mar 21, 2:32 pm, Matt Mastracci matt...@mastracci.com wrote: I'm seeing the same thing in our application. I haven't had time to dig into it, but I'm seeing 'unknown event DOMContentLoaded' in the developer tools console. The GWT Showcase example works, however. Maybe some sort of doctype issue? On 2010-03-20, at 4:53 AM, nicolas.deloof wrote: Hi, I tried my GWT 2.0 webapp with the recent test build of IE9 and it doesn't display. I wonder IE9 is not recognized as IE, event whit IE8 mode set. The browser may use a unsuported user-agent ID, is there allready any test done on this new browser ? roadmap to support its better support for standards ? Cheers, Nicolas -- http://groups.google.com/group/Google-Web-Toolkit-Contributors To unsubscribe from this group, send email to google-web-toolkit-contributors+unsubscribegooglegroups.com or reply to this email with the words REMOVE ME as the subject. -- http://groups.google.com/group/Google-Web-Toolkit-Contributors To unsubscribe from this group, send email to google-web-toolkit-contributors+unsubscribegooglegroups.com or reply to this email with the words REMOVE ME as the subject. -- http://groups.google.com/group/Google-Web-Toolkit-Contributors To unsubscribe from this group, send email to google-web-toolkit-contributors+unsubscribegooglegroups.com or reply to this email with the words REMOVE ME as the subject.
Re: [gwt-contrib] Proposal for including easyXDM as a new cross-domain Transport/RPC
[+matt]
I can't speak to any experience with either of these libraries, but this
also sounds like the work Matt's been doing here:
http://code.google.com/p/gwt-rpc-plus/
http://code.google.com/p/gwt-rpc-plus/Can anyone speak to the relationship
between these libraries? I'd love to see a standard way of dealing with XDM
make it into the GWT core.
On Sun, Mar 21, 2010 at 10:59 AM, Sean Kinsey okin...@gmail.com wrote:
I've seen many questions on the net on how to enable cross-domain
requests with GWT, and most of the solutions I've seen mentioned has
been less efficient than what I know the easyXDM library can offer.
For those who has never heard of it, easyXDM is a library that
conveniently abstracts away all the hassle of hash/fragments,
window.name and postMessage, and that exposes a simple and reliable
Socket that allows strings to be passed between two documents (no
reloads, so both documents can keep state).
Whatever kind of transport being used internally (based on what the
browser offers etc) the stack will provide _reliability_, queuing (and
fragmenting if necessary) and security.
Whats interesting with the library is that it also contains an Rpc
class, that allows you to invoke methods, with complex arguments
(JSON), and with or without return values.
From the consumers calling an RPC method is as easy as doing
//set up rpc object, only a few simple lines
var rpc = new easyXDM.Rpc(...
rpc.nameOfMethod(arg1, arg2, arg3, function
methodToHandleResponse(response){
...
});
Why don't you give it a try?
The library has several easy to follow examples at http://easyxdm.net/;
the Rpc sample can be found at
http://consumer.easyxdm.net/current/example/methods.html
Regards
Sean Kinsey
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
To unsubscribe from this group, send email to
google-web-toolkit-contributors+unsubscribegooglegroups.com or reply to
this email with the words REMOVE ME as the subject.
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
To unsubscribe from this group, send email to
google-web-toolkit-contributors+unsubscribegooglegroups.com or reply to this
email with the words REMOVE ME as the subject.
Re: [gwt-contrib] Re: Array implementation for Lightweight Collections. Pure Java implementation only. (issue232801)
I think we're talking about two different things here. Rodrigo's (valid)
point is that implementing immutability sanely early on is a good idea. And
this implementation is pretty much analogous to the one you describe from
Cocoa.
The question at hand is whether it makes sense to get an immutable
collection from a mutable one, with no copies. There are two ways to do
this:
1. Create an immutable view of a mutable list, but with no guarantees that
the list won't be mutated by the original owner later.
2. Freeze a mutable list into an immutable view of said list, making the
former runtime immutable.
(1) solves the problem of a class giving access to one of its internal
collections without having to guard against external mutation. (2) can be
used to replicate the builder pattern.
I don't have a strong opinion about (2) myself, but (1) is pretty damned
important, because it's the source of innumerable stupid defensive copies in
JRE code. The provider of such an interface would just have to be very clear
about whether the immutable list might be modified later (because it's a
view on a mutable one).
On Mon, Mar 22, 2010 at 5:23 PM, Ray Ryan rj...@google.com wrote:
I think you're missing my point. An object is immutable if there exists no
api to mutate it. That should be enough.
Let me put it another way. It's lame that the JRE achieves immutability by
turning mutate methods into runtime errors. It will be equally lame of us to
do the same, especially since we can't enforce it at production time. It
would be much better to provide an api such that there is not even possible
to compile the mutate call (without cheating with casts, but then you know
you're being bad).
The Cocoa approach to this is to have interfaces like NSArray be immutable,
and then have NSMutableArray extend NSArray. If we're going to roll our own
collection classes, it seems to me we could do the same: e.g.
LiteImmutableList and List extends LiteImmutableList.
rjrjr
On Mon, Mar 22, 2010 at 2:12 PM, Rodrigo Chandia rchan...@google.comwrote:
I like the *concept* of immutability being introduced early in the
development. The initial implementation may be limiting for some use cases,
but I believe it is a useful concept to expand on. If specific needs require
simultaneous mutable and immutable access we can provide implementations to
address that problem (copy on write semantics, for example).
2010/3/22 Ray Ryan rj...@google.com
I guess I'm overstating my opposition. It's not really dangerous, but it
just doesn't seem useful. Just by existing I think it'll promote confusion
and perhaps bad habits. Why bother?
I think the 90% use case is for something like the following (writing in
JRE terms here):
private final ListString magicValues;
{
ListString buildValues = new ArrayListString();
buildValues.add(able);
buildValues.add(baker);
buildValues.add(charlie);
magicValues = Collections.unmodifiableList(buildValues);
}
Ta da: it's a read only structure and no copy was made. In our world, we
could do better:
private final ImmutableLiteListString magicValues;
{
LiteListString buildValues = new LiteListString();
buildValues.add(able);
buildValues.add(baker);
buildValues.add(charlie);
magicValues = buildValues.immutableView(); // more equivalent of
cast()
}
The user never thinks in terms of freezing, just cutting off access. No
extra dev mode mechanism to maintain, and basically the same idiom already
in use in Java.
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
To unsubscribe from this group, send email to
google-web-toolkit-contributors+unsubscribegooglegroups.com or reply to
this email with the words REMOVE ME as the subject.
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
To unsubscribe from this group, send email to
google-web-toolkit-contributors+unsubscribegooglegroups.com or reply to this
email with the words REMOVE ME as the subject.
Re: [gwt-contrib] ClientBundle produce memory leaks in IE6
I am able to reproduce this leak as well, and can confirm that it only happens on IE6 (not 7+). If I use a standard image url rather than a ClientBundle, the leak goes away. Interestingly, though, it doesn't appear to be a standard circular-ref leak, because Microsoft's own leak detector doesn't flag it, and the memory is recouped when you navigate away from the page (IE7+ will try to clean up some kinds of leaks when you leave the page, but IE6 makes no such attempt). This implicates the ClippedImageImplIE6 code, which has been a nasty thorn in our side for some time. I've tried without success to replicate the leak in a simple Javascript snippet, but that likely means I just haven't stepped on whatever particular set of problems is causing it. @Adrien: Would you mind entering an issue for this so we can track it? I'm likely to use this as another opportunity to push for removing that god-awful code (see issues 1765, 3236, 3573, and 3588). Thanks, joel. On Fri, Mar 19, 2010 at 10:50 AM, AdrienA aubry.adr...@gmail.com wrote: Hello, I find out a problem with the using of ClientBundle wich produce memory leaks in IE6. To proove that, I have realised a very simple application (you can find the source code at this address : http://google-web-toolkit-contributors.googlegroups.com/web/SampleCode-memoryLeakFromClientBundleOnIE6.zip ) In this application, there is just one popup which contains 1000 times the same image creating by a ClientBundle. I open and close several times this popup and I observe the memory leaks in IE6 (with the soft Process Explorer for example). The result is alarming : http://www.googleonlinestorage.com/pictures/3077dd392df167271d24f526e41b637e.gif Is the problem already known? Maybe there is something to do ? Thank you, Adrien AUBRY -- http://groups.google.com/group/Google-Web-Toolkit-Contributors To unsubscribe from this group, send email to google-web-toolkit-contributors+unsubscribegooglegroups.com or reply to this email with the words REMOVE ME as the subject. -- http://groups.google.com/group/Google-Web-Toolkit-Contributors To unsubscribe from this group, send email to google-web-toolkit-contributors+unsubscribegooglegroups.com or reply to this email with the words REMOVE ME as the subject.
Re: [gwt-contrib] GWT's JsonpRequest conflicts browser caching
That's definitely a valid point, and I understand how it would defeat caching. However, I believe using a hash for the callback name would make it impossible to properly deal with two requests to the same URL, because there would be no way to distinguish which AsyncCallback should get which response. This could lead to very difficult-to-debug errors. It's not immediately obvious to me that there's a way to deal with this correctly in the general case (though ideas are of course welcome). It might be worth considering to allow the user to name the callback explicitly, but it would have to come with dire warnings about making multiple overlapping requests with the same callback name. Thoughts? On Fri, Mar 12, 2010 at 3:48 PM, Frank frank.man...@yahoo.com wrote: I had a look at JsonpRequest and JsonpRequestBuilder provided by GWT 2.0 for cross domain HTTP requests. Very nice, worked right away. However, there is one serious flaw... Like many other JSONP implementations, GWT's JsonRequest generates a unique callback name for each single jsonp request containing a serial number (e.g., __gwt_jsonp__.I1.onSuccess, __gwt_jsonp__.I2.onSuccess, and so on). This callback name is appended to the URI of the GET request, e.g., http://service.whatsoever.com/book/12345678?callback=__gwt_jsonp__.I37.onSuccess . A response header such as Cache-Control: public, max-age=... telling the browser to cache the resource, will not have any effect because the URI was skewed. Getting one and the same resource (e.g., /book/ 12345678) with many different URIs makes browser caching through Cache- Control impossible. My proposal for GWT's JsonRequest is to provide an alternative strategy for generating callback names. If you use a hash value of the URI rather than a serial number, browser caching through Cache-Control would work. -- http://groups.google.com/group/Google-Web-Toolkit-Contributors -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] Multiple inheritance in Widget hierarchy
John,
The background behind that weird type hierarchy is that it stems from a time
before overlay types existed. Originally c.g.g.user.client.Element was a
simple opaque handle that had to be passed to the DOM.*() methods to get
anything done (same for Event). After the compiler got overlay type support
we added c.g.g.dom.client.Element as a superclass to user.Element, and
refactored all the DOM.*() methods to use the new dom.* node/element
hierarchy.
Unfortunately we couldn't banish user.Element altogether without breaking
everyone, so we ended up with a number of warts like
setElement(user.Element). It's been on our TODO list for some time to
deprecate user.Element and remove all references to it, but no one's found
the time yet. As you've probably discovered, we just end up using JSO.cast()
to work around this where necessary, but of course that won't work in real
Java.
If I understand what you're doing correctly, it sounds like clearing this up
would simplify your life. But it might take a while, because we have to go
through a fair amount of work to get there.
@kathrin amit: How did you guys deal with this in the HtmlUnit testing
stuff? Sounds like it would have come up there.
Cheers,
joel.
On Thu, Mar 18, 2010 at 12:45 AM, jd jdpatter...@gmail.com wrote:
Hi,
I am reposting this question here as the user list got no reply and I
guess it is more a dev question:
I am experimenting with compiling GWT code with a standard JDK so I
can use the same code to generate HTML on both the client and the
server. So far it seem to be working OK but will only be practical if
I can also get UIBinder and i18n working.
My goal is to create HTML pages that can be crawled and indexed and
also allow GWT code to add, load and modify the page. Others have
recommended building two parallel sites - an html one and a GT one
which seems a bit redundant.
My experiement has put a real w3c Node inside every GWT Node and
replace native methods with ones that manipulate the w3c node. Then
finally I take the full w3c node from any element and convert it into
html.
I found that the object hierarchy needed to be changed to be valid
Java. An example of the issue is with the Anchor widget:
public Anchor() {
setElement(Document.get().createAnchorElement());
setStyleName(gwt-Anchor);
}
com.google.gwt.dom.client.AnchorElement extends
com.google.gwt.dom.client.AnchorElement but setElement expects a
com.google.gwt.user.client.Element so AnchorElement must extend both
classes which is impossible.
I have modified AnchorElement and friends to extends
com.google.gwt.user.client.Element instead which seems to have
worked.
My question is: Is this impossible inheritance hierarchy intentional
to stop this kind of messing about?
Cheers,
John
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] Re: Avira and HTML/CryptedGen (again)
This is Avira, isn't it? Ddi you ever hear anything back from them about this? It seems like it really ought to be fixed on their end, though I applaud your spelunking for a workaround :) On Tue, Mar 16, 2010 at 3:08 PM, Matt Mastracci matt...@mastracci.comwrote: On Mar 16, 12:42 pm, Matt Mastracci matt...@mastracci.com wrote: Holy cow -- how do they think that is an acceptable measure? Surely they could at least change the warning to say potentially dangerous JS or something rather than declaring it a virus. This probably will likely affect a significant number GWT applications that use RPC. Avira seems to check files ending in .js* and .html* for this pattern. I verified that the scanner intercepts these patterns in HTTP traffic and detects them in IE cache files. There might be some negative patterns as well: Avira doesn't block my message in the Google Groups web interface, but it does block it when viewing the raw message source. Even better: it turns out that if you put the string google anywhere in the file matching CryptedGen, it no longer matches the heuristic. I imagine that it would pick up the string from the class metadata for those not using -XdisableClassMetadata. So this is a virus: for eval .fromcharcode .charcodeat math.min 0,0,0,0,0,0 And this is not: google for eval .fromcharcode .charcodeat math.min 0,0,0,0,0,0 The easiest solution for us seems to be putting the string Google Web Toolkit in a comment in our header. Matt. -- http://groups.google.com/group/Google-Web-Toolkit-Contributors -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] Support runAsync with the cross-site linker.
That's great news, and will really help with efforts to make our linkers more sane. Out of curiosity, what's the strategy for loading fragments into the enclosing namespace (and yes, that's the sound of me being too lazy to dig into the patch)? On Mon, Mar 15, 2010 at 6:17 PM, sp...@google.com wrote: Reviewers: cromwellian, Description: Support runAsync with the cross-site linker. Please review this at http://gwt-code-reviews.appspot.com/213801 Affected files: M dev/core/src/com/google/gwt/core/ext/linker/impl/SelectionScriptLinker.java M dev/core/src/com/google/gwt/core/linker/IFrameLinker.java M dev/core/src/com/google/gwt/core/linker/XSLinker.java M dev/core/src/com/google/gwt/core/linker/XSTemplate.js M dev/core/src/com/google/gwt/dev/jjs/JavaToJavaScriptCompiler.java M dev/core/src/com/google/gwt/dev/jjs/impl/FragmentLoaderCreator.java A dev/core/src/com/google/gwt/dev/jjs/impl/HandleCrossIslandReferences.java M dev/core/src/com/google/gwt/dev/jjs/impl/JsFunctionClusterer.java M dev/core/src/com/google/gwt/dev/js/JsToStringGenerationVisitor.java A dev/core/test/com/google/gwt/dev/js/JavaScriptStringTest.java M user/src/com/google/gwt/core/CompilerParameters.gwt.xml M user/src/com/google/gwt/core/Core.gwt.xml A user/src/com/google/gwt/core/XSLinker.gwt.xml user/src/com/google/gwt/core/client/impl/AsyncFragmentLoader.java A user/src/com/google/gwt/core/client/impl/CrossSiteLoadingStrategy.java M user/src/com/google/gwt/core/client/impl/XhrLoadingStrategy.java M user/test/com/google/gwt/core/client/impl/AsyncFragmentLoaderTest.java M user/test/com/google/gwt/core/client/impl/XhrLoadingStrategyTest.java A user/test/com/google/gwt/dev/jjs/CompilerSuiteCrossSite.gwt.xml A user/test/com/google/gwt/dev/jjs/CrossSiteRunAsyncFailure.gwt.xml A user/test/com/google/gwt/dev/jjs/CrossSiteRunAsyncMetrics.gwt.xml A user/test/com/google/gwt/dev/jjs/CrossSiteRunAsyncSuite.java M user/test/com/google/gwt/dev/jjs/RunAsyncFailure.gwt.xml M user/test/com/google/gwt/dev/jjs/RunAsyncMetricsIntegrationTest.gwt.xml user/test/com/google/gwt/dev/jjs/public/empty-gwt-stats.js A user/test/com/google/gwt/dev/jjs/test/CrossSiteRunAsyncFailureTest.java A user/test/com/google/gwt/dev/jjs/test/CrossSiteRunAsyncMetricsTest.java A user/test/com/google/gwt/dev/jjs/test/CrossSiteRunAsyncTest.java M user/test/com/google/gwt/dev/jjs/test/RunAsyncFailureTest.java A user/test/com/google/gwt/user/client/runasync/CrossSiteLoadingStrategyForRunAsyncFailureTest.java D user/test/com/google/gwt/user/server/runasync/RunAsyncFailureIFrameLinker.java -- http://groups.google.com/group/Google-Web-Toolkit-Contributors -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: Generated widget markup
First of all, there have always been widgets that have used tables, and
those that don't. When we started designing them, tables were pretty much
the only way to get sane layout behavior, especially before anything like
standards mode was widely supported. But it's always been possible to
avoid them -- they're not baked deeply into the system.
We have definitely been moving away from tables for most layout structure
and newer widgets, and will continue to do so. And as Chris points out, the
2.0 layout widgets avoid tables altogether (and are much more stable in
their behavior than the old table-based widgets).
However, when you say that semantically correct markup is a MUST BE, it's
important to be clear about your actual goals, rather than making such a
statement a priori. These DOM structures are never serialized into static
content, for example. And it's also a fair question to ask what the
semantics of a stack of divs are, as opposed to a table -- they're both
semantically meaningless.
We will continue to do what works best in practice, not conform to an
arbitrary standard that has no effect on functionality. Fortunately, this
will likely lead us to an outcome where we *do* use the elements that you're
proposing are appropriate, but if there are cases where a table works better
in practice, then that's what we'll use.
On Fri, Mar 12, 2010 at 10:32 AM, Chris Lercher cl_for_mail...@gmx.netwrote:
I think, the new GWT 2.0 Layout Panel address pretty much that -
they're designed for standards mode, and you can make do without
Tables (VerticalPanel etc). You can still use them for data tables, in
which case they're semantically correct.
On Mar 12, 2:19 pm, mmoossen mmoos...@gmail.com wrote:
Dear all!
i was surprised, even disappointed, when i realized how GWT (ab)uses
html tables.
For instance the vertical panel and the tree widget ARE html tables.
why it is so??
should not it be much better just to use a list of DIVs (or even a UL)
for the vertical panel and nested ULs for the tree??
i mean, in the days of HTML5, CSS3, ria, and so on... semantically
correct markup is a MUST BE.
well, perhaps there is a really good reason behind it...
so i would be really happy if somebody could help me to understand the
idea...
or has somebody already written semantic widgets and wants to share
them ;)
thanks
Michael
PS: i was just thinking that a tree item could have been composed by a
vertical panel, so if i implement the vertical panel as an UL i would
get automagically a nested ULs tree, but it is not :(
but i think that is what i will do now :)
PS2: i think code likehttp://
code.google.com/p/google-web-toolkit/source/browse/trunk/user/...
DOM.setStyleAttribute(getElement(), zoom, 1);
should also better go in a TreeImplIE class as inhttp://
code.google.com/p/google-web-toolkit/source/browse/trunk/user/...
/**
* IE specific implementation class for {...@link TreeItem}.
*/
public static class TreeItemImplIE6 extends TreeItemImpl {
@Override
void convertToFullNode(TreeItem item) {
super.convertToFullNode(item);
DOM.setStyleAttribute(item.getElement(), marginBottom, 0px);
}
}
--
You received this message because you are subscribed to the Google Groups
Google Web Toolkit group.
To post to this group, send email to google-web-tool...@googlegroups.com.
To unsubscribe from this group, send email to
google-web-toolkit+unsubscr...@googlegroups.comgoogle-web-toolkit%2bunsubscr...@googlegroups.com
.
For more options, visit this group at
http://groups.google.com/group/google-web-toolkit?hl=en.
--
You received this message because you are subscribed to the Google Groups
Google Web Toolkit group.
To post to this group, send email to google-web-tool...@googlegroups.com.
To unsubscribe from this group, send email to
google-web-toolkit+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/google-web-toolkit?hl=en.
Re: [gwt-contrib] 3 PopupPanel related bugs
Thanks, George. I'll put these on our schedule to look at as soon as we can. On Fri, Mar 5, 2010 at 9:41 AM, ggeorg georgopoulos.georg...@gmail.comwrote: Hi, please have a look at: - http://code.google.com/p/google-web-toolkit/issues/detail?id=4720can=4 - http://code.google.com/p/google-web-toolkit/issues/detail?id=4664can=4 - http://code.google.com/p/google-web-toolkit/issues/detail?id=4662can=4 the patch for the last one is not valid. Thanks, George. -- http://groups.google.com/group/Google-Web-Toolkit-Contributors -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] Updates the IFRame and XS selection script templates to support
@Ian: I know, it's nasty. These things have gotten a bit out of hand, and we
have a big, fat TODO to come back and clean this up (as well as to bring
together various other linkers under a more coherent umbrella). But we
probably won't be able to get around to it for at least another quarter,
unfortunately.
On Mon, Mar 8, 2010 at 12:37 PM, Ian Petersen ispet...@gmail.com wrote:
Just idle curiosity here, but why did you have to make the same change
twice? I know you're modifying selection scripts, and maybe that
means you need to violate DRY for some reason, but it strikes me as a
potential refactoring.
Ian
On Mon, Mar 8, 2010 at 9:23 AM, sp...@google.com wrote:
Reviewers: jgw,
Description:
Updates the IFRame and XS selection script templates to support
inlined selection scripts. There are two changes involved:
1. There is a baseUrl meta property that can be used to override
the choice of base URL.
2. Meta tags can be made to apply to only module MODULENAME by putting
MODULENAME:: at the beginning of the name attribute of the meta tag.
Review by: j...@google.com
Please review this at http://gwt-code-reviews.appspot.com/159810
Affected files:
M dev/core/src/com/google/gwt/core/linker/IFrameTemplate.js
M dev/core/src/com/google/gwt/core/linker/XSTemplate.js
Index: dev/core/src/com/google/gwt/core/linker/IFrameTemplate.js
===
--- dev/core/src/com/google/gwt/core/linker/IFrameTemplate.js (revision
7685)
+++ dev/core/src/com/google/gwt/core/linker/IFrameTemplate.js (working
copy)
@@ -120,6 +120,10 @@
,markerId = __gwt_marker___MODULE_NAME__
,markerScript;
+if (base = metaProps['baseUrl']) {
+ return;
+}
+
$doc.write('script id=' + markerId + '/script');
markerScript = $doc.getElementById(markerId);
@@ -189,6 +193,12 @@
var meta = metas[i], name = meta.getAttribute('name'), content;
if (name) {
+name = name.replace('__MODULE_NAME__::', '');
+if (name.indexOf('::') = 0) {
+ // It's for a different module
+ continue;
+ }
+
if (name == 'gwt:property') {
content = meta.getAttribute('content');
if (content) {
@@ -347,6 +357,7 @@
// --- STRAIGHT-LINE CODE ---
// do it early for compile/browse rebasing
+ processMetas();
computeScriptBase();
var strongName;
@@ -361,7 +372,6 @@
strongName = ;
}
- processMetas();
// --- WINDOW ONLOAD HOOK ---
Index: dev/core/src/com/google/gwt/core/linker/XSTemplate.js
===
--- dev/core/src/com/google/gwt/core/linker/XSTemplate.js (revision
7685)
+++ dev/core/src/com/google/gwt/core/linker/XSTemplate.js (working
copy)
@@ -104,6 +104,10 @@
,markerId = __gwt_marker___MODULE_NAME__
,markerScript;
+if (base = metaProps['baseUrl']) {
+ return;
+}
+
$doc.write('script id=' + markerId + '/script');
markerScript = $doc.getElementById(markerId);
@@ -173,7 +177,13 @@
var meta = metas[i], name = meta.getAttribute('name'), content;
if (name) {
-if (name == 'gwt:property') {
+name = name.replace('__MODULE_NAME__::', '');
+if (name.indexOf('::') = 0) {
+ // It's for a different module
+ continue;
+}
+
+ if (name == 'gwt:property') {
content = meta.getAttribute('content');
if (content) {
var value, eq = content.indexOf('=');
@@ -287,8 +297,8 @@
}
// do it early for compile/browse rebasing
+ processMetas();
computeScriptBase();
- processMetas();
// --- WINDOW ONLOAD HOOK ---
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] UIObject methods return type improvement.
We could argue the merits of method chaining (I'll let the compiler guys speak to whether or not this is better, worse, or indifferent for code generation) -- but the bigger problem is that we'd have to change the style of code throughout the system to make it useful, but any attempt to do so would break existing subclasses that override these methods. On Tue, Mar 2, 2010 at 7:19 PM, Qcho qch...@gmail.com wrote: Hi, I am currently working on a project using GWT. Maybe is a good suggestion to change the return value of functions such as addStyleDependentName or addStyleName from void to the UI modified itself, so you can do things like this: DockLayoutPanel appPanel = new DockLayoutPanel(Unit.EM); appPanel.addNorth(new HTML(hh1).addStyleName(header), 4); appPanel.addNorth(new HTML(hh2).addStyleName(subHeader), 10); appPanel.addSouth(new HTML(foot).addStyleName(footer), 4); appPanel.addWest(new HTML(nav).addStyleName(navigation), 10); this code wont compile since the chaining of addStyleName returns void and not the Widget element. Simple example provided. -- http://groups.google.com/group/Google-Web-Toolkit-Contributors -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: GWT 2.0 is unusable in IE7
I can assure you that this is not a general problem -- we've built plenty of applications (including the Mail sample) which work fine using a structure very much like the one you describe. If it's only happening on IE, there's a very good probability that you're running using a quirks-mode doctype (i.e., no !doctype html). If that fixes the problem, would you please update issue 4532 to reflect that? On Fri, Feb 26, 2010 at 9:45 AM, nagin naginkoth...@gmail.com wrote: I am developing Web application using GWT 2.0. I am using Layout panel which is added to RootLayout panel. In IE 7 when we open dialog box, popup panel, menu item or date picker or any thing that pop ups , then all widgets on the screen except popup disappears . when these pop ups are closed then everything reappears. This is very irritating to user and make application unusable . I had open issue #4532 a month back, but nobody from GWT team have attended or accepted and looked into it yet . It is very surprising that such critical issue is not been attended to. I hope that GWT team will look into it and try to resolve this earliest. thanks Nagin -- You received this message because you are subscribed to the Google Groups Google Web Toolkit group. To post to this group, send email to google-web-tool...@googlegroups.com. To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
Re: [gwt-contrib] Re: JSON.parse vs. eval
What Thomas said. But yes, if we could make a good safe-eval JSON parser
available, that would be great. The old json library is both unsafe
(because it uses eval()) and ugly (because it was written long before
overlay types).
On Sat, Feb 20, 2010 at 10:22 AM, Thomas Broyer t.bro...@gmail.com wrote:
On Feb 16, 2:32 pm, mozSte ste.biopa...@gmail.com wrote:
Hi all,
I'm a newbie, so excuse me if this was posted/solved already.
I have a quick suggestion on the implementation of a safeEval (or
safer, anyway) parsing to the JSONUtils class.
public static native T extends JavaScriptObject T
safeEval(String json) /*-{
if(JSON)
{
return JSON.parse(json);
}
else
{
return eval('('+json+')');
}
}-*/;
object JSON is present as native JSON parser in all modern browsers,
so with this code you'll likely get more secure and also faster code.
Do you see any drawback in using this code?
It evals the if each time you call safeEval; and the fallback to
eval isn't safe at all (I'd at least add a check using the regexp
from RFC 4627).
Is it already present in
some other GWT module?
I wrote a JSON module at work (we might open source it someday) that
uses deferred binding to use native parsing when we're sure it is
available (IE8), eval() when we're sure it isn't (IE6 and Opera) and
runtime detection otherwise (Firefox and Safari/Chrome), when the
check is done once only!
I proposed a patch to GWT but unfortunately it has some problems so I
(temporarily) withdrawn it: http://gwt-code-reviews.appspot.com/86803/show
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] Feature Request: VisibilityEvent
Wow, I had completely forgotten about onpropertychange() -- like onresize(), there's some interesting and useful stuff floating around in IE, even if it is nonstandard. If you can get something like this wired up across browsers, that would be really useful. I would be particularly interested in seeing how this might be generalized -- if, e.g., we could get a standard interface to something like onpropertychange() (note how it explicitly *includes* style changes in the MSDN doc), we could use it for a lot of things. On Mon, Feb 15, 2010 at 1:30 PM, Jarrod Carlson jarrod.carl...@gmail.comwrote: Yes, there are some serious hurdles to being able to support this kind of feature. I haven't tried it yet, but I suggested the feature because I understand both Mozilla and WebKit support a DOMAttrModified sort of native event: http://www.w3.org/TR/DOM-Level-2-Events/events.html#Events-eventgroupings-mutationevents I also understand IE has some limited support for a proprietary alternative (onpropertychange). It sounds like it might be possible to get some sort of support working, although I have no doubt that some additional voodoo would be required to level the support across browsers. On Mon, Feb 15, 2010 at 10:46 AM, Joel Webber j...@google.com wrote: I'm not sure if it's possible to do this correctly in the general case. You can currently override setVisible(), but that only works if it's called explicitly. Most importantly, there's no way I know of to get the DOM to tell you when an element becomes visible/hidden; to synthesize this would require that all changes to visibility of a parent walk the entire child hierarchy to inform all of its children of the change. Even worse, it can happen for random reasons like a change to the Style object or CSS class name. If we can find a way to get the DOM to inform us of this kind of change, I'm all for it though. On Sat, Feb 13, 2010 at 11:30 PM, jarrod jarrod.carl...@gmail.comwrote: One feature I would like to see added to GWT is a DOM or logical event to notify handlers of a Widget's visibility changes. In the spirit of keeping things loosely coupled, say for instance I have a TabLayoutPanel which contains several Widgets. Those Widgets do not necessarily know that they are contained within a TabLayoutPanel that might show or hide them at will. Thus it would be quite helpful if a Widget could (especially through UiBinder) be notified when it becomes visible to the user. Any thoughts? -- http://groups.google.com/group/Google-Web-Toolkit-Contributors -- http://groups.google.com/group/Google-Web-Toolkit-Contributors -- ~jj -- http://groups.google.com/group/Google-Web-Toolkit-Contributors -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] Size improvements with latest trunk
That's great news. I'm particularly happy given that (IIRC) Ray confirmed that these have no negative impact on parse time (please tell me I'm remembering this correctly!). On Tue, Feb 16, 2010 at 8:21 PM, Ray Cromwell cromwell...@gmail.com wrote: Awesome, thanks a lot for the data and debugging. I guess that brings the gain since 1.7 to 28% now. :) -Ray On Tue, Feb 16, 2010 at 5:16 PM, Matt Mastracci matt...@mastracci.com wrote: I ran a few different compiles with our codebase to test some of the improvements in trunk for Ray. I've only measured the post-gzip/zip size improvements below - the numbers for the website sizes are an average of the size for gzip -9 over all of the browser permutations: GWT 2.0.0: dotspots.com (initial fragment, gzipped): 73299 dotspots.com/popup (initial fragment, gzipped): 89715 Publisher script (initial fragment, gzipped): 54424 Chrome extension (final zipped size): 83790 Firefox extension (final zipped size): 103257 GWT trunk (as of r7589): dotspots.com (initial fragment, gzipped): 73983 dotspots.com/popup (initial fragment, gzipped): 89260 publisher script (initial fragment, gzipped): 55307 Chrome extension (final zipped size): 84771 Firefox extension (final zipped size): 103707 GWT trunk (as of r7589), with compiler.stackMode = strip: dotspots.com (initial fragment, gzipped): 69185 dotspots.com/popup (initial fragment, gzipped): 83768 publisher script (initial fragment, gzipped): 52040 Chrome extension (final zipped size): 80980 Firefox extension (final zipped size): 0 GWT trunk (as of r7589), with compiler.stackMode = strip + Compact Integer Seed Functions patch: dotspots.com (initial fragment, gzipped): 67937 dotspots.com/popup (initial fragment, gzipped): 82242 publisher script (initial fragment, gzipped): 51089 Chrome extension (final zipped size): 80058 Firefox extension (final zipped size): 98661 Overall improvements (from 2.0.0 to trunk+stack strip+patch): dotspots.com (initial fragment, gzipped): 7.3% dotspots.com/popup (initial fragment, gzipped): 8.3% publisher script (initial fragment, gzipped): 6.1% (xpi/crx omitted, since there's a large constant factor) In other words: WOOHOO! Matt. -- http://groups.google.com/group/Google-Web-Toolkit-Contributors -- http://groups.google.com/group/Google-Web-Toolkit-Contributors -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] GWT 2.0.2 still broken when there is no history.
[+jlabanca: can you take a look at this?] On Mon, Feb 15, 2010 at 9:06 AM, stuckagain david.no...@gmail.com wrote: People, Somehow testings needs to be a bit enhanced. GWT 2.0.2 which is supposed to fix issue 4585 does not seem to work correctly. Although the original stack is no longer produced when showing the popup, I now get the stack when closing down the PopupPanel. Can this bug be re-opened ? http://code.google.com/p/google-web-toolkit/issues/detail?id=4584 2010/02/15 14:59:20 SEVERE Unknown:Uncaught Exception java.lang.NullPointerException at com.google.gwt.user.client.ui.PopupPanel.setState(PopupPanel.java: 1397) at com.google.gwt.user.client.ui.PopupPanel.onUnload(PopupPanel.java: 1025) at com.google.gwt.user.client.ui.Widget.onDetach(Widget.java:329) at com.google.gwt.user.client.ui.Widget.setParent(Widget.java:402) at com.google.gwt.user.client.ui.Panel.orphan(Panel.java:210) at com.google.gwt.user.client.ui.ComplexPanel.remove(ComplexPanel.java: 63) at com.google.gwt.user.client.ui.AbsolutePanel.remove(AbsolutePanel.java: 159) at com.google.gwt.user.client.ui.PopupPanel $ResizeAnimation.onInstantaneousRun(PopupPanel.java:314) at com.google.gwt.user.client.ui.PopupPanel $ResizeAnimation.setState(PopupPanel.java:208) at com.google.gwt.user.client.ui.PopupPanel.setState(PopupPanel.java: 1374) at com.google.gwt.user.client.ui.PopupPanel.hide(PopupPanel.java:585) at com.google.gwt.user.client.ui.PopupPanel.hide(PopupPanel.java:571) -- http://groups.google.com/group/Google-Web-Toolkit-Contributors -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] Feature Request: VisibilityEvent
I'm not sure if it's possible to do this correctly in the general case. You can currently override setVisible(), but that only works if it's called explicitly. Most importantly, there's no way I know of to get the DOM to tell you when an element becomes visible/hidden; to synthesize this would require that all changes to visibility of a parent walk the entire child hierarchy to inform all of its children of the change. Even worse, it can happen for random reasons like a change to the Style object or CSS class name. If we can find a way to get the DOM to inform us of this kind of change, I'm all for it though. On Sat, Feb 13, 2010 at 11:30 PM, jarrod jarrod.carl...@gmail.com wrote: One feature I would like to see added to GWT is a DOM or logical event to notify handlers of a Widget's visibility changes. In the spirit of keeping things loosely coupled, say for instance I have a TabLayoutPanel which contains several Widgets. Those Widgets do not necessarily know that they are contained within a TabLayoutPanel that might show or hide them at will. Thus it would be quite helpful if a Widget could (especially through UiBinder) be notified when it becomes visible to the user. Any thoughts? -- http://groups.google.com/group/Google-Web-Toolkit-Contributors -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] Patch for RichTextEditor
Sebastian,
Sorry it's taken so long for anyone to respond. This sounds like useful
functionality, and I would suggest creating an issue (
http://code.google.com/p/google-web-toolkit/issues/) and a patch for public
discussion (http://gwt-code-reviews.appspot.com/). That way it will be
easier for people to try out your patch and refine it.
Cheers,
joel.
On Fri, Jan 22, 2010 at 9:55 AM, Sebastian use...@laliluna.de wrote:
Hello,
I was missing the ability to format a block with h1 - h6 tags. I
researched the topic and build a patch which allows to insert block
tags. It makes use of the FormatBlock command.
I would like to ask, if you are interested in the patch and discuss
the coding decision I took.
1)
I couldn't find any guidance on testing. I have tested with Safari 4,
Firefox 3.5, IE 6, IE 8 and IE 8 in IE 7 mode.
2)
Currently only the tags h1 to h6, pre, address and p work
stable across browsers. To limit the choice of tags, I have created an
enum to limit the possible values.
public static enum BlockTag {
H1, H2, H3, H4, H5, H6, PRE, ADDRESS, P;
final String OPEN = ;
final String CLOSE = ;
public String toTag() {
return OPEN+name()+CLOSE;
}
}
The advantage is that you cannot provide the wrong tags. The
disadvantage is that you cannot provide tags which are for example
supported in newer browser versions.
The rest of the tag is just a new method in RichTextAreaImplStd.
public void formatBlock(RichTextArea.BlockTag blockTag) {
execCommand(FormatBlock, blockTag.toTag());
}
Shall I leave it that way or turn it into a String parameter?
3)
Should I create a bug tracking entry for this?
If somebody is interested, here are some links, I found interesting
while exploring the topic.
http://discerning.com/topics/software/ttw.html
http://help.dottoro.com/ljcvtcaw.php
http://www.quirksmode.org/dom/execCommand.html
Best Regards
Sebastian Hennebrueder
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] StackPanelLayout and applying additional style when hovering header.
Thanks, Marko. I'll take a look at it today. On Tue, Feb 9, 2010 at 4:07 AM, Marko Vuksanovic markovuksano...@gmail.comwrote: I thought it would be nice if it was possible to have hovering effect on StackPanelLayout header so I created an issue for that (issue nuber is 4561, or direct link http://code.google.com/p/google-web-toolkit/issues/detail?can=2q=4561colspec=ID%20Type%20Status%20Priority%20Milestone%20Owner%20Summaryid=4561 ) and submitted a patch. It would be nice if somebody from the gwt team had a look at this... /Marko -- http://groups.google.com/group/Google-Web-Toolkit-Contributors -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: Exceptions in Event Handlers(inner classes) are not shown by Dev Mode Panel in Eclipse!
This may be a problem with SmartGWT. I'm not familiar with the details of
how they deal with wrapping events from the native SmartClient widgets, but
if they fail to properly punt exceptions to the UncaughtExceptionHandler,
dev mode will eat the exceptions.
On Thu, Feb 4, 2010 at 12:58 PM, J-Pro jpro@gmail.com wrote:
Good afternoon, dear GWT group members!
I've noticed that if I create an event handler, for example
ButtonItem btnSubmit = new ButtonItem();
btnSubmit.addClickHandler(new
com.smartgwt.client.widgets.form.fields.events.ClickHandler()
{
@Override
public void
onClick(com.smartgwt.client.widgets.form.fields.events.ClickEvent
event)
{
int i = 5/0;
}
});
I can't see the problem in the Development Mode Panel in the Eclipse.
The last record there is Module has been loaded. The application
itself behaves just as if nothing happened. You can try it by
yourself.
But if only I put int i = 5/0; after ButtonItem declaration, i.e.
not in inner class, the exception will be described in Development
Mode Panel.
Having this, it's very hard to catch errors... Can you advise anything
to me? Or is it a bug?
I use Eclipse 3.5 SR1, Google Plugin 1.2.0, GWT Toolkit SDK 2.0.1,
smartgwt 2.0, latest Firefox and Windows 7 x64 Ultimate.
Thank you very much in advance!
--
You received this message because you are subscribed to the Google Groups
Google Web Toolkit group.
To post to this group, send email to google-web-tool...@googlegroups.com.
To unsubscribe from this group, send email to
google-web-toolkit+unsubscr...@googlegroups.comgoogle-web-toolkit%2bunsubscr...@googlegroups.com
.
For more options, visit this group at
http://groups.google.com/group/google-web-toolkit?hl=en.
--
You received this message because you are subscribed to the Google Groups
Google Web Toolkit group.
To post to this group, send email to google-web-tool...@googlegroups.com.
To unsubscribe from this group, send email to
google-web-toolkit+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/google-web-toolkit?hl=en.
[gwt-contrib] Re: GWT 2.0.1: is the history support iframe now mandatory ?
I just clarified the issue a bit and assigned it. Thanks for catching this. On Feb 5, 6:00 am, Konstantin.Scheglov konstantin.scheg...@gmail.com wrote: I've added this issue yesterday, found during running tests for GWT Designer. http://code.google.com/p/google-web-toolkit/issues/detail?id=4584 On Feb 4, 6:36 pm, Joel Webber j...@google.com wrote: It shouldn't be -- if you kick off History's static initializer, it will GWT.create(HistoryImpl.class), and thus attempt to find the iframe, but I believe it's been this way for a long time. Are you sure you're not referencing History somewhere? On Thu, Feb 4, 2010 at 10:34 AM, stuckagain david.no...@gmail.com wrote: Hi, I rebuild my apps with 2.0.1 and noticed that they no longer start. In DevMode is see an error about the History Support that fails to initialize. My apps do not support history, so I did not include the IFrame... has this become mandatory or is this a little oops ? David -- http://groups.google.com/group/Google-Web-Toolkit-Contributors -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: GWT 2.0.1: is the history support iframe now mandatory ?
I just clarified the issue a bit and assigned it. Thanks for catching this. On Feb 5, 6:00 am, Konstantin.Scheglov konstantin.scheg...@gmail.com wrote: I've added this issue yesterday, found during running tests for GWT Designer. http://code.google.com/p/google-web-toolkit/issues/detail?id=4584 On Feb 4, 6:36 pm, Joel Webber j...@google.com wrote: It shouldn't be -- if you kick off History's static initializer, it will GWT.create(HistoryImpl.class), and thus attempt to find the iframe, but I believe it's been this way for a long time. Are you sure you're not referencing History somewhere? On Thu, Feb 4, 2010 at 10:34 AM, stuckagain david.no...@gmail.com wrote: Hi, I rebuild my apps with 2.0.1 and noticed that they no longer start. In DevMode is see an error about the History Support that fails to initialize. My apps do not support history, so I did not include the IFrame... has this become mandatory or is this a little oops ? David -- http://groups.google.com/group/Google-Web-Toolkit-Contributors -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: html5 + gwt ... or gears?
Karl-Heinz, We are planning on adding built-in support for the HTML5 AppCache, but have not done so yet. I believe there are some projects already in existence working to do this, such as gwt-mobile-webkit ( http://code.google.com/p/gwt-mobile-webkit/). I haven't used this project personally, but it looks like they're working on AppCache support at present. Cheers, joel. On Fri, Feb 5, 2010 at 4:08 AM, Karl-Heinz Troyer k...@troyer.co.at wrote: *hi gwt dev team! * it seems gears does not come forward. are there any plans to do the same with html5? and when? how can i provide an offline app with html5 and gwt? gears is even not supported on chrome for mac. our app has to run on some platforms where i can request html5 compatibility, but not gears thanks in advance, -- regards / mit freundlichen grüssen [image: chance123] http://info.chance123.net http://info.chance123.net *ing. karl-heinz troyer* troyer information systems gmbh alte hohenzeller strasse 2 / a-4910 ried im innkreis / austria skype callto:tis_charly / tel +43 676 9330080 / infohttp://firmena-z.wko.at/udbsql/FirmaInfo5.asp?id=24893cs=180510421428329713813852045665 a worldwide success story http://info.chance123.net -- http://groups.google.com/group/Google-Web-Toolkit-Contributorskht-email3.png
Re: [gwt-contrib] GWT 2.0.1: is the history support iframe now mandatory ?
It shouldn't be -- if you kick off History's static initializer, it will GWT.create(HistoryImpl.class), and thus attempt to find the iframe, but I believe it's been this way for a long time. Are you sure you're not referencing History somewhere? On Thu, Feb 4, 2010 at 10:34 AM, stuckagain david.no...@gmail.com wrote: Hi, I rebuild my apps with 2.0.1 and noticed that they no longer start. In DevMode is see an error about the History Support that fails to initialize. My apps do not support history, so I did not include the IFrame... has this become mandatory or is this a little oops ? David -- http://groups.google.com/group/Google-Web-Toolkit-Contributors -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] Re: GWT Incubator Status Update and Schedule
To be clear, we do recognize the importance of starting to support HTML5 constructs that don't work on all browsers, though we need to find a clear way to indicate to developers that a particular library or widget won't work in some cases. None of us have ever worked through all the nuances of how this should be done yet, and probably won't have time to do so until at least Q2. That said, if you want to start the discussion, I'm all ears! On Thu, Jan 28, 2010 at 10:44 AM, Ray Ryan rj...@google.com wrote: As you'll see in the first note in this thread, Incubator is closing down. Having your work in its own project is exactly the right thing to do. If it becomes an appropriate addition for GWT proper, we'll eagerly help you integrate it. In the meantime, the community can use it and shape it without waiting for the GWT team to get in the mix. rjrjr On Thu, Jan 28, 2010 at 4:56 AM, Mark Renouf mark.ren...@gmail.comwrote: I've developed gwt-html5-media, which implements all the common functionality described in the Media Element section of the HTML5 spec, including the specific functionality for Video and Audio tags, including all of the events and settings. I could use some help testing and improving it and perhaps some advice on how to better handle usage of the large number of new native events available (currently side-steps the main GWT sinkEvents code instead using it's own, since it exhausts the available number of free bitfield definitions there). http://code.google.com/p/gwt-html5-media/ Would something like this be welcome in incubator or simply as a side project for eventual inclusion into GWT? I'd like to see the HTML5 support rounded out so this plus the Canvas support would me a major step forward. I know there is also another pure-canvas implementation for GWT within the SpeedTracer project. I'm not sure if VML fallback is worth the complexity if the only browser supporting it does not support any other HTML5 features anyhow... but that's a point for debate elsewhere I suppose ;-) On Jan 12, 1:04 pm, John LaBanca jlaba...@google.com wrote: Incubator Users - The Google Web Toolkit Incubator project began as a proving grounds for new widgets to be vetted before joining the ranks of the GWT trunk. We've seen some success stories over the last year with EventHandlers, ClientBundle, and DatePicker, but for many of the widgets and libraries, Incubator has become an elephant graveyard. In order to address this issue, we will start graduating some of the libraries to GWT trunk, move some into separate projects, and discontinue development on others. Ultimately, we will wind down the incubator project completely. The schedule below shows the fate of each subproject in incubator. It's a tentative schedule, meaning that it could change as priorities shift. GWT 2.1 - *PagingScrollTable and FastTree* We are working on a new set of data backed widgets for GWT 2.1 that will include APIs for trees and tables. We will build upon the lessons learned with these incubator widgets, but the API for the new data backed widgets will evolve significantly from the current APIs. When the data backed widgets are added to GWT trunk, we will stop development on the PagingScrollTable and FastTree. - *Locale Selection* Selecting the locale on the server requires one less round trip to the server on startup and is needed for effective use of runtime locales selection. This library will be included in GWT 2.1. GWT 2.2 - *CollapsiblePanel* This widget will probably become a subclass of DockingLayoutPanel, similar to SplitLayoutPanel. - *SliderBar and ProgressBar* Both of these widgets currently require the use of a global timer, which has performance implications. If we can implement these without a resize timer, we will include them in GWT 2.2. If we cannot, we will discontinue development on them. - *Logging* The logging API may make it into GWT 2.1 if time permits. - *Form Validation* We will take a closer look at the form validation API in GWT 2.2.. Separate Project: - *SoundResource* SoundResource is a promising API for including sound in an application, but it makes sense to wait for HTML 5 features to become widely adopted before including it. We would like to move SoundResource into the gwt-voices project:http://code.google.com/p/gwt-voices/. - *Graphics* The graphics library provides a single, platform independent API that works on top of Canvas and VML. The library is not ready for GWT trunk, but this project is worth pursuing. - *HtmlDecorators* We will continue to work on this project to arbitrarily add decorations to widgets. As always, please feel free to reply with comments or suggestions. Thanks, John LaBanca on
Re: [gwt-contrib] Re: GWT Incubator Status Update and Schedule
[+fred, just to make sure he sees this] On Mon, Feb 1, 2010 at 11:26 AM, dflorey daniel.flo...@gmail.com wrote: See: http://groups.google.com/group/google-web-toolkit-contributors/browse_thread/thread/4f5fb0cbd007fa25/e6a70c6a26a444cd?lnk=gstq=compatibility+animations#e6a70c6a26a444cd On 1 Feb., 17:23, dflorey daniel.flo...@gmail.com wrote: What about Fred Sauer's gwt voices project? AFAK it has an elegant approach how to provide flash based fallback if certain capabilities are not supported by the browser itself. On 1 Feb., 14:25, Joel Webber j...@google.com wrote: To be clear, we do recognize the importance of starting to support HTML5 constructs that don't work on all browsers, though we need to find a clear way to indicate to developers that a particular library or widget won't work in some cases. None of us have ever worked through all the nuances of how this should be done yet, and probably won't have time to do so until at least Q2. That said, if you want to start the discussion, I'm all ears! On Thu, Jan 28, 2010 at 10:44 AM, Ray Ryan rj...@google.com wrote: As you'll see in the first note in this thread, Incubator is closing down. Having your work in its own project is exactly the right thing to do. If it becomes an appropriate addition for GWT proper, we'll eagerly help you integrate it. In the meantime, the community can use it and shape it without waiting for the GWT team to get in the mix. rjrjr On Thu, Jan 28, 2010 at 4:56 AM, Mark Renouf mark.ren...@gmail.com wrote: I've developed gwt-html5-media, which implements all the common functionality described in the Media Element section of the HTML5 spec, including the specific functionality for Video and Audio tags, including all of the events and settings. I could use some help testing and improving it and perhaps some advice on how to better handle usage of the large number of new native events available (currently side-steps the main GWT sinkEvents code instead using it's own, since it exhausts the available number of free bitfield definitions there). http://code.google.com/p/gwt-html5-media/ Would something like this be welcome in incubator or simply as a side project for eventual inclusion into GWT? I'd like to see the HTML5 support rounded out so this plus the Canvas support would me a major step forward. I know there is also another pure-canvas implementation for GWT within the SpeedTracer project. I'm not sure if VML fallback is worth the complexity if the only browser supporting it does not support any other HTML5 features anyhow... but that's a point for debate elsewhere I suppose ;-) On Jan 12, 1:04 pm, John LaBanca jlaba...@google.com wrote: Incubator Users - The Google Web Toolkit Incubator project began as a proving grounds for new widgets to be vetted before joining the ranks of the GWT trunk. We've seen some success stories over the last year with EventHandlers, ClientBundle, and DatePicker, but for many of the widgets and libraries, Incubator has become an elephant graveyard. In order to address this issue, we will start graduating some of the libraries to GWT trunk, move some into separate projects, and discontinue development on others. Ultimately, we will wind down the incubator project completely. The schedule below shows the fate of each subproject in incubator. It's a tentative schedule, meaning that it could change as priorities shift. GWT 2.1 - *PagingScrollTable and FastTree* We are working on a new set of data backed widgets for GWT 2.1 that will include APIs for trees and tables. We will build upon the lessons learned with these incubator widgets, but the API for the new data backed widgets will evolve significantly from the current APIs. When the data backed widgets are added to GWT trunk, we will stop development on the PagingScrollTable and FastTree. - *Locale Selection* Selecting the locale on the server requires one less round trip to the server on startup and is needed for effective use of runtime locales selection. This library will be included in GWT 2.1. GWT 2.2 - *CollapsiblePanel* This widget will probably become a subclass of DockingLayoutPanel, similar to SplitLayoutPanel. - *SliderBar and ProgressBar* Both of these widgets currently require the use of a global timer, which has performance implications. If we can implement these without a resize timer, we will include them in GWT 2.2. If we cannot, we will discontinue development on them. - *Logging* The logging API may make it into GWT 2.1 if time permits
Re: [gwt-contrib] Re: Changing JsArrayT extends JavaScriptObject to JsArrayT
Correct me if I'm wrong, but isn't the closure collections library more like JRE-ish collections than simple JSO wrappers? My impression of most JS code was that if it needed a string map or simple array, people tended to just use raw objects, knowing that there are certain strange behaviors they have to avoid. That said, if there's a way to make them play nice together, I'm all for it. On Tue, Jan 26, 2010 at 7:46 AM, Stefan Haustein haust...@google.comwrote: Collections are very, very amenable to bikeshedding, so I want to have a pretty well thought-out plan so as to avoid endless what if threads, if at all possible. Of course, if the design is bad, people will hopefully say so and we'll do something different. But I just don't want to start with so little that it doesn't have enough intertia to achieve escape velocity. Bruce, for collections in general, maybe we should also consider using / linking / emulating closure collections. With stuff like Bach on the horizon, we may otherwise end up with too many collection frameworks, creating a situation similar to strings in C++. For simple arrays, I think it may make sense to re-visit the original idea of extending the scope of JsArrayT extends JsObject to JsArrayT extends Object. Stefan -- http://groups.google.com/group/Google-Web-Toolkit-Contributors -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: gwt-phys2d: 2D physics engine for GWT
[+gwt-contrib] That's pretty impressive. Have you tried it on any larger scene graphs? I'd love to see how it scales. It looks quite smooth on Chrome already. On Fri, Jan 22, 2010 at 3:05 AM, Neil Halelamien ne...@caltech.edu wrote: I quasi-ported the Phys2d Java physics library to run with GWT and gwt- g2d (for HTML5 canvas rendering). You can see the result (and download the library source) here: http://edgeofvision.com/2010/01/22/initial-release-of-gwt-phys2d-javascriptgwt-physics-engine/ http://gwt-phys2d.appspot.com If anybody's interested in actually using this and/or contributing, I'd be happy to clean things up and create a Google Code project for it. It was pretty much just a self-education project though, so I probably won't be doing too much more with it myself. I imagine it might be handy for a GWT game programming project out there, though. -- Neil -- You received this message because you are subscribed to the Google Groups Google Web Toolkit group. To post to this group, send email to google-web-tool...@googlegroups.com. To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.comgoogle-web-toolkit%2bunsubscr...@googlegroups.com . For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en. -- You received this message because you are subscribed to the Google Groups Google Web Toolkit group. To post to this group, send email to google-web-tool...@googlegroups.com. To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
[gwt-contrib] Re: gwt-phys2d: 2D physics engine for GWT
[+gwt-contrib] That's pretty impressive. Have you tried it on any larger scene graphs? I'd love to see how it scales. It looks quite smooth on Chrome already. On Fri, Jan 22, 2010 at 3:05 AM, Neil Halelamien ne...@caltech.edu wrote: I quasi-ported the Phys2d Java physics library to run with GWT and gwt- g2d (for HTML5 canvas rendering). You can see the result (and download the library source) here: http://edgeofvision.com/2010/01/22/initial-release-of-gwt-phys2d-javascriptgwt-physics-engine/ http://gwt-phys2d.appspot.com If anybody's interested in actually using this and/or contributing, I'd be happy to clean things up and create a Google Code project for it. It was pretty much just a self-education project though, so I probably won't be doing too much more with it myself. I imagine it might be handy for a GWT game programming project out there, though. -- Neil -- You received this message because you are subscribed to the Google Groups Google Web Toolkit group. To post to this group, send email to google-web-tool...@googlegroups.com. To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.comgoogle-web-toolkit%2bunsubscr...@googlegroups.com . For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en. -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: SuggestBox loses focus when hovering over suggestions
Sure thing. Looking now. On Fri, Jan 22, 2010 at 11:17 AM, John LaBanca jlaba...@google.com wrote: ping - can you get to this today? It should go into GWT 2.0.1 Thanks, John LaBanca jlaba...@google.com On Wed, Jan 20, 2010 at 2:32 PM, jlaba...@google.com wrote: Reviewers: jgw, Description: The SuggestBox loses focus when the mouse hovers over the list of suggestions because MenuBar steals keyboard focus on hover. This is particularly annoying if a user leaves the cursor just beneath the text box. As soon as the suggestions are shown, the text box loses focus. In fact, there are other cases where this can be annoying, such as just having a MenuBar and TextBox in the same app: http://code.google.com/p/google-web-toolkit/issues/detail?id=3884 Fix: This patch adds an option to MenuBar to disable focus on hover, which fixes the problem at the expense of losing keyboard focus. SuggestBox now uses the new option. Testing: === Manually verified that this works for MenuBar and SuggestBox. Please review this at http://gwt-code-reviews.appspot.com/132816 Affected files: user/src/com/google/gwt/user/client/ui/MenuBar.java user/src/com/google/gwt/user/client/ui/SuggestBox.java -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] LayoutPanel Button in Mozilla
Agreed that this is a really irritating bug in Firefox. Have you tried
w/h:100% just on the button itself? This is required for table and
iframe on all browsers, though it's not baked into the Layout code by
default, because it mis-lays-out slightly (pushes borders and margin off the
edge).
On Wed, Jan 20, 2010 at 7:58 AM, ggeorg georgopoulos.georg...@gmail.comwrote:
Hi,
is there a workaround for :
public void onModuleLoad() {
LayoutPanel panel = new LayoutPanel();
panel.add(new Button(Hello!));
RootLayoutPanel.get().add(panel);
}
left: 0px; right: 0px; together do not work in Firefox 3.5.6 (top:
0px; bottom: 0px; work).
There is also the same problem with TextBox in both Firefox and IE8.
With TextBox even vertical alignment does not work.
What I found so far is
http://www.quirksmode.org/css/tests/mozie_button.html,
but -moz-box-sizing: content-box; does not help. Maybe there is
something else. Button.setWidth(100%) works perfect, but it fails
for div elements with margin and border.
Thanks,
George.
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] Re: More on TabLayoutPanel styles
Good point as well, thanks. I've updated issue 4259 to capture this. On Tue, Jan 19, 2010 at 2:08 PM, dflorey daniel.flo...@gmail.com wrote: One more issue: Using LazyPanel does not work in the new TabLayoutPanel. I guess the setVisible() method is no longer called on this widget (is it called on one of the parent panels?) On Jan 19, 5:07 pm, Joel Webber j...@google.com wrote: On Mon, Jan 18, 2010 at 6:17 AM, dflorey daniel.flo...@gmail.com wrote: Hi, I've been trying to usw the new TabLayoutPanel for different layouts. Here are my findings: 1. The .gwt-TabLayoutPanelTabs style gets applied to the wrapper element with width set to 16000 px. This makes it impossible to create a border around the tab bar. As a workaround I had to apply a style to wrapper element like this: ((Element) tabPanel.getElement().getChild(1)).setClassName(.gwt- TabLayoutPanel-wrapper); This is very ugly and will fail as soon as the TabLayoutPanel impl changes. Please consider applying the .gwt-TabLayoutPanelTabs style to the appropriate wrapper element. This is a good point. I'll need to add another wrapper element around the tabs to make this work, but I don't think that will cause any problems. There *is* a wrapper created by the Layout class, but it's unsafe to apply arbitrary styles to it (in particular, decorations such as border, margin, and padding will confuse it -- it's actually there to work around measurement problems with such decorations). I've added a comment to issue 4429 (default TLP styles) to capture this. 2. The setStyle(Primary)Name methods will not change the substyles. When using different TabLayoutPanels with different styles in the same application you'll have to overwrite each css property as you'll inherit all styles by default. It would be much better to change all substyles as it has been the case with the old gwt widgets Actually, I can't think of any cases off the top of my head where we've automatically updated sub-styles like this. For example, the old StackPanel only modifies the top-most class name. The problem is that there are cases where we'd be forced to walk arbitrarily large numbers of children every time the style name is changed. We decided it was best to avoid this, and require the (admittedly somewhat uglier, and imperfect) use of descendent selectors. The right long-term approach is probably closer to what you suggest below. or - even better - to pass a ClientBundle defining all styles as an optional argument to the cstr of the TabLayoutPanel. A default style factory could provide default styles if no ClientBundle is provided. Replacing the default style factory using deferred binding could make the default styles themable. I've used this approach in my own app and it works fine. Essentially, yes. Though it's a fairly complex design problem in the general case to do so in a way that ensures there's no unnecessary overhead, and supports all the common use cases. This is definitely a Q1 goal, and we'll make a point to share design docs as soon as we have a rough idea of what it should look like. -- http://groups.google.com/group/Google-Web-Toolkit-Contributors -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: GWT Incubator Status Update and Schedule
To be clear, the inclusion of more core widgets and libraries won't impose any size overhead on projects that don't use them. If you *do* use them, you can always use code-splitting to divide your app into logical components that are demand-loaded. On Wed, Jan 13, 2010 at 10:25 AM, Deanna Bonds deanna.bo...@gmail.comwrote: Happy to see these getting promoted to GWT. Can you make sure they use code splitting so there isn't an extra overhead with them being included? On Jan 12, 4:19 pm, Gabriel Guerrero gabrieldavidguerr...@gmail.com wrote: +1 For at least doing another release compatible with gwt 2, I use the FastTree and the PagingScrollTable, and it will be nice to have a version of those widgets that support the new layout system, for what I saw in the trunk the seem to be already compatible with the new layout, although I have not tested them Cheers Gabriel On Jan 12, 6:05 pm, John LaBanca jlaba...@google.com wrote: Incubator Users - The Google Web Toolkit Incubator project began as a proving grounds for new widgets to be vetted before joining the ranks of the GWT trunk. We've seen some success stories over the last year with EventHandlers, ClientBundle, and DatePicker, but for many of the widgets and libraries, Incubator has become an elephant graveyard. In order to address this issue, we will start graduating some of the libraries to GWT trunk, move some into separate projects, and discontinue development on others. Ultimately, we will wind down the incubator project completely. The schedule below shows the fate of each subproject in incubator. It's a tentative schedule, meaning that it could change as priorities shift. GWT 2.1 - *PagingScrollTable and FastTree* We are working on a new set of data backed widgets for GWT 2.1 that will include APIs for trees and tables. We will build upon the lessons learned with these incubator widgets, but the API for the new data backed widgets will evolve significantly from the current APIs. When the data backed widgets are added to GWT trunk, we will stop development on the PagingScrollTable and FastTree. - *Locale Selection* Selecting the locale on the server requires one less round trip to the server on startup and is needed for effective use of runtime locales selection. This library will be included in GWT 2.1. GWT 2.2 - *CollapsiblePanel* This widget will probably become a subclass of DockingLayoutPanel, similar to SplitLayoutPanel. - *SliderBar and ProgressBar* Both of these widgets currently require the use of a global timer, which has performance implications. If we can implement these without a resize timer, we will include them in GWT 2.2. If we cannot, we will discontinue development on them. - *Logging* The logging API may make it into GWT 2.1 if time permits. - *Form Validation* We will take a closer look at the form validation API in GWT 2.2.. Separate Project: - *SoundResource* SoundResource is a promising API for including sound in an application, but it makes sense to wait for HTML 5 features to become widely adopted before including it. We would like to move SoundResource into the gwt-voices project:http://code.google.com/p/gwt-voices/. - *Graphics* The graphics library provides a single, platform independent API that works on top of Canvas and VML. The library is not ready for GWT trunk, but this project is worth pursuing. - *HtmlDecorators* We will continue to work on this project to arbitrarily add decorations to widgets. As always, please feel free to reply with comments or suggestions. Thanks, John LaBanca on behalf of the GWT team -- You received this message because you are subscribed to the Google Groups Google Web Toolkit group. To post to this group, send email to google-web-tool...@googlegroups.com. To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.comgoogle-web-toolkit%2bunsubscr...@googlegroups.com . For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en. -- You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To post to this group, send email to google-web-tool...@googlegroups.com. To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
Re: [gwt-contrib] Re: AutoHide PopupPanel on History Events
Say I have a GWT-powered eBook reader. That would be really cool :) Ok, fair enough. Let's just leave it as is then. LGTM. On Wed, Jan 13, 2010 at 3:55 PM, Isaac Truett itru...@gmail.com wrote: I like it except for one scenario: Say I have a GWT-powered eBook reader. I hide some navigation controls in the corner; mouse over and they pop up. I want them to disappear if you click outside the popup, so auto-hide=true. But If you click next page I want to set a history token (for the next page) and I want the controls to stay visible so that you don't have to mouse back over the trigger in the corner in order to flip the page again, or flip back. If auto-hide-on-click implied auto-hide-on-history then you would have to jump through some more hoops (keep track of the popup state and re-show after history change if it was visible before). On Wed, Jan 13, 2010 at 3:43 PM, j...@google.com wrote: An idea: What if we just considered auto-hide on history to be equivalent to auto-hide? I definitely see that we can't hide *all* popups on history events, but ones mark auto-hide seem like fair game. What do you think? http://gwt-code-reviews.appspot.com/132804 -- http://groups.google.com/group/Google-Web-Toolkit-Contributors -- http://groups.google.com/group/Google-Web-Toolkit-Contributors -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] All the content of RichTextEditor is deleted in FF first time you push a key
If you're not explicitly selecting the RTA's text (using formatter.selectAll(), and it's becoming selected by default, please do file a bug for this. It's likely a mozilla bug, but there's probably something we can do to forcibly work around it. Do post a snippet that reproduces the exact behavior if possible -- these things often happen for subtle reasons that are hard to reproduce without a very specific order of operations. Thanks, joel. On Fri, Jan 8, 2010 at 2:08 PM, Manuel Carrasco Moñino man...@apache.orgwrote: Hello, When a RichTextEditor is added to a page and then you set the HTML content, it is displayed fine, then when you focus the editor and write any letter with your keyboard, all the content is erased. If you push undo (ctrl-z) the content is displayed again. The problem seems to be that when you add content to the editor, the first time, this content goes selected, so when you introduce any text it is override. Do you think it is a bug?, is it possible to unselect the text after adding it to the editor. Thanks Manolo -- http://groups.google.com/group/Google-Web-Toolkit-Contributors -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] All the content of RichTextEditor is deleted in FF first time you push a key
[-gwtc] He's not likely to know about google3 :) On Fri, Jan 8, 2010 at 2:38 PM, John LaBanca jlaba...@google.com wrote: Are you using RichTextArea that is part of GWT, or another widget called RichTextEditor (in google3?). Thanks, John LaBanca jlaba...@google.com On Fri, Jan 8, 2010 at 2:26 PM, Joel Webber j...@google.com wrote: If you're not explicitly selecting the RTA's text (using formatter.selectAll(), and it's becoming selected by default, please do file a bug for this. It's likely a mozilla bug, but there's probably something we can do to forcibly work around it. Do post a snippet that reproduces the exact behavior if possible -- these things often happen for subtle reasons that are hard to reproduce without a very specific order of operations. Thanks, joel. On Fri, Jan 8, 2010 at 2:08 PM, Manuel Carrasco Moñino man...@apache.org wrote: Hello, When a RichTextEditor is added to a page and then you set the HTML content, it is displayed fine, then when you focus the editor and write any letter with your keyboard, all the content is erased. If you push undo (ctrl-z) the content is displayed again. The problem seems to be that when you add content to the editor, the first time, this content goes selected, so when you introduce any text it is override. Do you think it is a bug?, is it possible to unselect the text after adding it to the editor. Thanks Manolo -- http://groups.google.com/group/Google-Web-Toolkit-Contributors -- http://groups.google.com/group/Google-Web-Toolkit-Contributors -- http://groups.google.com/group/Google-Web-Toolkit-Contributors -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] All the content of RichTextEditor is deleted in FF first time you push a key
Ok, I'm a complete idiot. Please ignore stupid chatter between me and John about our internal repository. There is nothing in GWT (internally or externally) called RichTextEditor, so I just assumed RichTextArea was being referred to on this thread. On Fri, Jan 8, 2010 at 2:45 PM, Joel Webber j...@google.com wrote: [-gwtc] He's not likely to know about google3 :) On Fri, Jan 8, 2010 at 2:38 PM, John LaBanca jlaba...@google.com wrote: Are you using RichTextArea that is part of GWT, or another widget called RichTextEditor (in google3?). Thanks, John LaBanca jlaba...@google.com On Fri, Jan 8, 2010 at 2:26 PM, Joel Webber j...@google.com wrote: If you're not explicitly selecting the RTA's text (using formatter.selectAll(), and it's becoming selected by default, please do file a bug for this. It's likely a mozilla bug, but there's probably something we can do to forcibly work around it. Do post a snippet that reproduces the exact behavior if possible -- these things often happen for subtle reasons that are hard to reproduce without a very specific order of operations. Thanks, joel. On Fri, Jan 8, 2010 at 2:08 PM, Manuel Carrasco Moñino man...@apache.org wrote: Hello, When a RichTextEditor is added to a page and then you set the HTML content, it is displayed fine, then when you focus the editor and write any letter with your keyboard, all the content is erased. If you push undo (ctrl-z) the content is displayed again. The problem seems to be that when you add content to the editor, the first time, this content goes selected, so when you introduce any text it is override. Do you think it is a bug?, is it possible to unselect the text after adding it to the editor. Thanks Manolo -- http://groups.google.com/group/Google-Web-Toolkit-Contributors -- http://groups.google.com/group/Google-Web-Toolkit-Contributors -- http://groups.google.com/group/Google-Web-Toolkit-Contributors -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] Re: [google-web-toolkit] r7364 committed - Adds the module name to the generated ID of FormPanel's iframe to ensu...
createUniqueId() guarantees a unique id for the document, but makes no guarantees about uniqueness within the global namespace ($wnd). I think it would be a worthwhile addition to create such a method in the future, though. On Thu, Jan 7, 2010 at 4:12 AM, Thomas Broyer t.bro...@gmail.com wrote: On Jan 7, 12:23 am, John Tamplin j...@google.com wrote: What about the case of multiple instances of the same module? How about simply using Document.get().createUniqueId() ? -- http://groups.google.com/group/Google-Web-Toolkit-Contributors -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] Re: [google-web-toolkit] r7364 committed - Adds the module name to the generated ID of FormPanel's iframe to ensu...
On Thu, Jan 7, 2010 at 9:57 AM, John LaBanca jlaba...@google.com wrote: createUniqueId() guarantees a unique id for the document, but makes no guarantees about uniqueness within the global namespace ($wnd). I think it would be a worthwhile addition to create such a method in the future, though. And to that point, we are generating a unique name for the hidden iframe, not a unique ID. I'm not sure what effect it would have to have names that are not unique in the global namespace. I'm an idiot, sorry. This is for the 'name' attribute of a form panel, not a global variable. I'm not precisely sure to what extent name and id overlap in their namespaces, but IIRC there are some subtle interactions. This code should work fine, but Thomas' idea to use doc.uid would probably be fine as well. -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] Tab-selected style missing in JavaDoc for TabLayoutPanel
Whoops, thanks. Added, and will commit momentarily. On Wed, Jan 6, 2010 at 5:47 AM, dflorey daniel.flo...@gmail.com wrote: reminder -- http://groups.google.com/group/Google-Web-Toolkit-Contributors -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] Re: History support broken on chrome
Daniel, I'm seeing Showcase work fine on both Chrome/Mac and Chrome/Windows. For http://www.floreysoft.com/ I'm seeing different behaviors on each: Windows: Everything seems to work fine, except for some strange shuffle when backing into the first history state, which keeps me from going forward out of this position. Mac: History items seem to be created correctly, and change when you click back/forward, but the app itself often fails to respond to them altogether. Is there anything unusual going on in your app's history event handler? Perhaps something like calling History.newItem() in response to a history event? Cheers, joel. On Wed, Jan 6, 2010 at 4:53 AM, dflorey daniel.flo...@gmail.com wrote: Works fine in IE too On Jan 6, 10:51 am, dflorey daniel.flo...@gmail.com wrote: For the some reason the history support is not working properly on chrome. I've just added the history example to the main tab panel and it is working fine on firefox but works on chrome only for the first back. You can double check here:http://www.floreysoft.net -- http://groups.google.com/group/Google-Web-Toolkit-Contributors -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] History support for StackLayoutPanel
Are addSelectionHandler(), addBeforeSelectionHandler(), selectTab(int), and selectTab(Widget) not sufficient for this? On Wed, Jan 6, 2010 at 4:05 AM, dflorey daniel.flo...@gmail.com wrote: Hi, it would be very convenient if StackLayoutPanel would support SelectionHandler and a setItem(int index) method to implement history support. -- http://groups.google.com/group/Google-Web-Toolkit-Contributors -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
