It bears repeating that for milestone builds like this, there are still many known problems, and it is use-at-your-own-risk. It *definitely* isn't ready for production use. For example, this milestone build is missing release notes, and it doesn't include the developer guide documentation. Please expect that it will require some trial and error getting everything to work.
What's new in Milestone 2? Here are some highlights:
- There is a new DOM API package. Using the new ability to subclass JavaScriptObject, GWT 1.5 M2 includes bindings for nearly the entire W3C HTML DOM spec. See the javadoc for the package com.google.gwt.dom.client for details. The widgets will be retrofitted to use the new DOM classes in the upcoming release candidate.
- Some widgets now have animation effects. Popups, trees, etc. have subtle animation effects to provide visual cues when hidden and shown.
- The addition of a "Showcase" sample. This sample combines features from several other samples and demonstrates the new, nicer-looking GWT default stylesheet and widget animations. Note that the default style is still in flux and is likely to change.
- Keyboard support has been added where previously absent in UI classes, including in menus and tab panels.
- ARIA support for enhanced accessibility is now present in most widgets, including menus, trees, tabs, and button variants.
- Bi-di. Widgets and panels have built-in support for bi-directional layout.
- "long" emulation. The Java language defines "long" types to be 64-bit signed integers, whereas JavaScript only supports 64-bit floating point numbers, which cannot accurately represent the same whole-number range as a true "long" type. GWT 1.5 M2 transparently emulates long types properly to more faithfully maintain Java semantics in web mode.
- There is a single Mac OS X distribution that works on both Leopard (10.5) and Tiger (10.4).
Now, some known bugs and caveats:
- Change from Milestone 1: No more "std/" directory in the compiler output. The GWT compiler output directory structure has been reverted to match its behavior in GWT 1.4. If auxiliary linker output is generated, additional files are placed in a sibling subdirectory whose name is "<module>-aux/". In most existing projects, this output directory won't be created, so the behavior should match GWT 1.4.
- The DOM structure for some widgets has changed to accommodate new CSS styling options. See the CSS rules used in GWT-default.css and Showcase.css (both in the Showcase project) for examples of how to use the new styles.
- Not all widgets work perfectly in standards mode. There are several minor known layout bugs that still need to be fixed for the release candidate.
- "long" and JSNI. The new long emulation support adds a new prohibition against the accidental use of "long" types within JSNI code. If you experience this error, the hosted mode tree logger will provide a "More Info" link that you can double-click for details on how to resolve the issue.
Thanks for posting these milestones for testing, especially the
Java1.5 support is well appreciated!
Not really issues, but from M1 to M2 for my project:
- The compiler (and shell) now runs out of heap space with the Java
default, during rebind to particular browsers
- The size of the browser-specific cache files has jumped 15%, from
~185k to ~210k. There was little change from 1.4.60 to M1
I just switched our project over. Initial impressions are very good.
Nice work with integrating animation into it as well. I like the new
showcase example as well, but I wonder if the stack panel wouldn't
work better as a slide than that weird fade thing it does?
Output files are about the same size as Milestone 1, however compile
time has increased a bit. Our project which used to take about 45
seconds to build now takes 1m20. Not sure if that's specifically
something to do with our project or whether it will be a general
thing? I'm sure you've crammed all sorts of goodness into it, but
anything you can do to tune that compile time would be awesome!
overall very good!
Rusty
On Apr 8, 12:28 pm, "Ian Bambury" <ianbamb...@gmail.com> wrote:
Just one other thing I noticed, it also breaks the LightBox widget
from gwt-widgets, which is one I rely on fairly heavily. Basically
only about half of the screen is greyed out by the PNG image they use.
I might have to look into that one a bit more, as it was working fine
under M1.
Rusty
On Apr 8, 2:32 pm, rusty <rustysh...@gmail.com> wrote:
> I just switched our project over. Initial impressions are very good.
> Nice work with integrating animation into it as well. I like the new
> showcase example as well, but I wonder if the stack panel wouldn't
> work better as a slide than that weird fade thing it does?
> Output files are about the same size as Milestone 1, however compile
> time has increased a bit. Our project which used to take about 45
> seconds to build now takes 1m20. Not sure if that's specifically
> something to do with our project or whether it will be a general
> thing? I'm sure you've crammed all sorts of goodness into it, but
> anything you can do to tune that compile time would be awesome!
> overall very good!
> Rusty
> On Apr 8, 12:28 pm, "Ian Bambury" <ianbamb...@gmail.com> wrote:
Sorry for the triple post but it seems to be related to GWT not
stretching the background popup panel past 640 wide? The height gets
stretched fine but the width stops after 640.
Any ideas? It's just a simple call to PopupPanel.setSize(width,
height)?
So you call PopupPanel.setSize(900, 600) and you get a PopupPanel that
is a 640x900?
On Apr 8, 3:12 pm, rusty <rustysh...@gmail.com> wrote:
> Just one other thing I noticed, it also breaks the LightBox widget
> from gwt-widgets, which is one I rely on fairly heavily. Basically
> only about half of the screen is greyed out by the PNG image they use.
> I might have to look into that one a bit more, as it was working fine
> under M1.
> Rusty
> On Apr 8, 2:32 pm, rusty <rustysh...@gmail.com> wrote:
> > Excellent work, go GWT team!
> > I just switched our project over. Initial impressions are very good.
> > Nice work with integrating animation into it as well. I like the new
> > showcase example as well, but I wonder if the stack panel wouldn't
> > work better as a slide than that weird fade thing it does?
> > Output files are about the same size as Milestone 1, however compile
> > time has increased a bit. Our project which used to take about 45
> > seconds to build now takes 1m20. Not sure if that's specifically
> > something to do with our project or whether it will be a general
> > thing? I'm sure you've crammed all sorts of goodness into it, but
> > anything you can do to tune that compile time would be awesome!
> Sorry for the triple post but it seems to be related to GWT not
> stretching the background popup panel past 640 wide? The height gets
> stretched fine but the width stops after 640.
> Any ideas? It's just a simple call to PopupPanel.setSize(width,
> height)?
> So you call PopupPanel.setSize(900, 600) and you get a PopupPanel that
> is a 640x900?
> On Apr 8, 3:12 pm, rusty <rustysh...@gmail.com> wrote:
> > Just one other thing I noticed, it also breaks the LightBox widget
> > from gwt-widgets, which is one I rely on fairly heavily. Basically
> > only about half of the screen is greyed out by the PNG image they use.
> > I might have to look into that one a bit more, as it was working fine
> > under M1.
> > Rusty
> > On Apr 8, 2:32 pm, rusty <rustysh...@gmail.com> wrote:
> > > Excellent work, go GWT team!
> > > I just switched our project over. Initial impressions are very good.
> > > Nice work with integrating animation into it as well. I like the new
> > > showcase example as well, but I wonder if the stack panel wouldn't
> > > work better as a slide than that weird fade thing it does?
> > > Output files are about the same size as Milestone 1, however compile
> > > time has increased a bit. Our project which used to take about 45
> > > seconds to build now takes 1m20. Not sure if that's specifically
> > > something to do with our project or whether it will be a general
> > > thing? I'm sure you've crammed all sorts of goodness into it, but
> > > anything you can do to tune that compile time would be awesome!
Rusty, I can think of no good reason that a popup would be limited in size like that. One possibility is that it might be related to standards vs. quirks fixes, but that's just a guess. I'm checkout out gwt-widgets right now to see what's going on.
On Tue, Apr 8, 2008 at 3:17 AM, rusty <rustysh...@gmail.com> wrote:
> Sorry for the triple post but it seems to be related to GWT not > stretching the background popup panel past 640 wide? The height gets > stretched fine but the width stops after 640.
> Any ideas? It's just a simple call to PopupPanel.setSize(width, > height)?
> So you call PopupPanel.setSize(900, 600) and you get a PopupPanel that > is a 640x900?
> On Apr 8, 3:12 pm, rusty <rustysh...@gmail.com> wrote: > > Just one other thing I noticed, it also breaks the LightBox widget > > from gwt-widgets, which is one I rely on fairly heavily. Basically > > only about half of the screen is greyed out by the PNG image they use. > > I might have to look into that one a bit more, as it was working fine > > under M1.
> > Rusty
> > On Apr 8, 2:32 pm, rusty <rustysh...@gmail.com> wrote:
> > > Excellent work, go GWT team!
> > > I just switched our project over. Initial impressions are very good. > > > Nice work with integrating animation into it as well. I like the new > > > showcase example as well, but I wonder if the stack panel wouldn't > > > work better as a slide than that weird fade thing it does?
> > > Output files are about the same size as Milestone 1, however compile > > > time has increased a bit. Our project which used to take about 45 > > > seconds to build now takes 1m20. Not sure if that's specifically > > > something to do with our project or whether it will be a general > > > thing? I'm sure you've crammed all sorts of goodness into it, but > > > anything you can do to tune that compile time would be awesome!
I just checked out the gwt-widget source, and set up a quick sample app that looks like this (not sure if this is the intended use pattern, but it looked like it):
PopupPanel pp = new PopupPanel();
pp.add(new Button("w00t!"));
LightBox lb = new LightBox(pp);
lb.show();
This seems to do more or less the right thing on IE6, FF3, and Safari3, and Opera9. The gray area overflowed the client boundaries a little bit on IE and Safari, but that was about it. Could you show me an example that is pegging the popup size?
On Tue, Apr 8, 2008 at 8:24 AM, Joel Webber <j...@google.com> wrote: > Rusty, > I can think of no good reason that a popup would be limited in size like > that. One possibility is that it might be related to standards vs. quirks > fixes, but that's just a guess. I'm checkout out gwt-widgets right now to > see what's going on.
> Thanks for the heads-up, > joel.
> On Tue, Apr 8, 2008 at 3:17 AM, rusty <rustysh...@gmail.com> wrote:
> > Sorry for the triple post but it seems to be related to GWT not > > stretching the background popup panel past 640 wide? The height gets > > stretched fine but the width stops after 640.
> > Any ideas? It's just a simple call to PopupPanel.setSize(width, > > height)?
> > So you call PopupPanel.setSize(900, 600) and you get a PopupPanel that > > is a 640x900?
> > On Apr 8, 3:12 pm, rusty <rustysh...@gmail.com> wrote: > > > Just one other thing I noticed, it also breaks the LightBox widget > > > from gwt-widgets, which is one I rely on fairly heavily. Basically > > > only about half of the screen is greyed out by the PNG image they use. > > > I might have to look into that one a bit more, as it was working fine > > > under M1.
> > > > I just switched our project over. Initial impressions are very good. > > > > Nice work with integrating animation into it as well. I like the new > > > > showcase example as well, but I wonder if the stack panel wouldn't > > > > work better as a slide than that weird fade thing it does?
> > > > Output files are about the same size as Milestone 1, however compile > > > > time has increased a bit. Our project which used to take about 45 > > > > seconds to build now takes 1m20. Not sure if that's specifically > > > > something to do with our project or whether it will be a general > > > > thing? I'm sure you've crammed all sorts of goodness into it, but > > > > anything you can do to tune that compile time would be awesome!
On Tue, Apr 8, 2008 at 1:32 AM, rusty <rustysh...@gmail.com> wrote:
> Excellent work, go GWT team!
> Output files are about the same size as Milestone 1, however compile > time has increased a bit. Our project which used to take about 45 > seconds to build now takes 1m20. Not sure if that's specifically > something to do with our project or whether it will be a general > thing? I'm sure you've crammed all sorts of goodness into it, but > anything you can do to tune that compile time would be awesome!
Rusty (and others),
Can you ensure that you're not getting a lot of warnings output to the console, for example, about deprecated metadata usage like gwt.typeArgs? We've seen several other people encounter slowness due to large amounts of logging. For example, running with -logLevel DEBUG can have a huge impact on the amount of time it takes to compile, launch hosted mode, and refresh.
On Tue, Apr 8, 2008 at 12:12 AM, rusty <rustysh...@gmail.com> wrote:
> Just one other thing I noticed, it also breaks the LightBox widget > from gwt-widgets, which is one I rely on fairly heavily. Basically > only about half of the screen is greyed out by the PNG image they use. > I might have to look into that one a bit more, as it was working fine > under M1.
> Rusty
> On Apr 8, 2:32 pm, rusty <rustysh...@gmail.com> wrote: > > Excellent work, go GWT team!
> > I just switched our project over. Initial impressions are very good. > > Nice work with integrating animation into it as well. I like the new > > showcase example as well, but I wonder if the stack panel wouldn't > > work better as a slide than that weird fade thing it does?
> > Output files are about the same size as Milestone 1, however compile > > time has increased a bit. Our project which used to take about 45 > > seconds to build now takes 1m20. Not sure if that's specifically > > something to do with our project or whether it will be a general > > thing? I'm sure you've crammed all sorts of goodness into it, but > > anything you can do to tune that compile time would be awesome!
How do I generate cross site version of the application using
Milestone 2.
The set-linker tag isn't supported anymore, I was able to figure out a
new add-linker tag, but it does not produce any output.
Any clues anyone ?
On Apr 8, 6:54 pm, "Toby Reyelts" <to...@google.com> wrote:
> On Tue, Apr 8, 2008 at 1:32 AM, rusty <rustysh...@gmail.com> wrote:
> > Excellent work, go GWT team!
> > Output files are about the same size as Milestone 1, however compile
> > time has increased a bit. Our project which used to take about 45
> > seconds to build now takes 1m20. Not sure if that's specifically
> > something to do with our project or whether it will be a general
> > thing? I'm sure you've crammed all sorts of goodness into it, but
> > anything you can do to tune that compile time would be awesome!
> Rusty (and others),
> Can you ensure that you're not getting a lot of warnings output to the
> console, for example, about deprecated metadata usage like gwt.typeArgs?
> We've seen several other people encounter slowness due to large amounts of
> logging. For example, running with -logLevel DEBUG can have a huge impact on
> the amount of time it takes to compile, launch hosted mode, and refresh.
Having not followed GWT's release schedule before, is there any idea
when the final release is scheduled for? A month? Three months?
About how many milestones do you have before a final release?
Thanks for all your hard work!
On Apr 7, 11:23 pm, "Bruce Johnson" <br...@google.com> wrote:
> If you haven't already, please take a look at the notes for Milestone 1
> (linked below) for some background information on changes coming in GWT 1.5:
> It bears repeating that for milestone builds like this, there are still many
> known problems, and it is use-at-your-own-risk. It *definitely* isn't ready
> for production use. For example, this milestone build is missing release
> notes, and it doesn't include the developer guide documentation.
> Please expect that it will require some trial and error getting everything
> to work.
> What's new in Milestone 2? Here are some highlights:
> - There is a new DOM API package. Using the new ability to subclass
> JavaScriptObject, GWT 1.5 M2 includes bindings for nearly the entire W3C
> HTML DOM spec. See the javadoc for the package com.google.gwt.dom.client for
> details. The widgets will be retrofitted to use the new DOM classes in the
> upcoming release candidate.
> - Some widgets now have animation effects. Popups, trees, etc. have subtle
> animation effects to provide visual cues when hidden and shown.
> - The addition of a "Showcase" sample. This sample combines features from
> several other samples and demonstrates the new, nicer-looking GWT default
> stylesheet and widget animations. Note that the default style is still in
> flux and is likely to change.
> - Keyboard support has been added where previously absent in UI classes,
> including in menus and tab panels.
> - ARIA support for enhanced accessibility is now present in most widgets,
> including menus, trees, tabs, and button variants.
> - Bi-di. Widgets and panels have built-in support for bi-directional layout.
> - "long" emulation. The Java language defines "long" types to be 64-bit
> signed integers, whereas JavaScript only supports 64-bit floating point
> numbers, which cannot accurately represent the same whole-number range as a
> true "long" type. GWT 1.5 M2 transparently emulates long types properly to
> more faithfully maintain Java semantics in web mode.
> - There is a single Mac OS X distribution that works on both Leopard (10.5)
> and Tiger (10.4).
> Now, some known bugs and caveats:
> - Change from Milestone 1: No more "std/" directory in the compiler output.
> The GWT compiler output directory structure has been reverted to match its
> behavior in GWT 1.4. If auxiliary linker output is generated, additional
> files are placed in a sibling subdirectory whose name is "<module>-aux/". In
> most existing projects, this output directory won't be created, so the
> behavior should match GWT 1.4.
> - The DOM structure for some widgets has changed to accommodate new CSS
> styling options. See the CSS rules used in GWT-default.css and Showcase.css
> (both in the Showcase project) for examples of how to use the new styles.
> - Not all widgets work perfectly in standards mode. There are several minor
> known layout bugs that still need to be fixed for the release candidate.
> - "long" and JSNI. The new long emulation support adds a new prohibition
> against the accidental use of "long" types within JSNI code. If you
> experience this error, the hosted mode tree logger will provide a "More
> Info" link that you can double-click for details on how to resolve the
> issue.
Any way compillation step could parallelized to reduce the time it
takes? It's a real pain watching compiler taking only 1 cpu/core time
on my 4 core dev box and more than a minute to build a gwt
project...and what if my box had 8 cores? Or maybe somehow structure
the compilation to exclude classes/packages that haven't changed in
the java source?
On Apr 8, 9:54 am, "Toby Reyelts" <to...@google.com> wrote:
> On Tue, Apr 8, 2008 at 1:32 AM, rusty <rustysh...@gmail.com> wrote:
> > Excellent work, go GWT team!
> > Output files are about the same size as Milestone 1, however compile
> > time has increased a bit. Our project which used to take about 45
> > seconds to build now takes 1m20. Not sure if that's specifically
> > something to do with our project or whether it will be a general
> > thing? I'm sure you've crammed all sorts of goodness into it, but
> > anything you can do to tune that compile time would be awesome!
> Rusty (and others),
> Can you ensure that you're not getting a lot of warnings output to the
> console, for example, about deprecated metadata usage like gwt.typeArgs?
> We've seen several other people encounter slowness due to large amounts of
> logging. For example, running with -logLevel DEBUG can have a huge impact on
> the amount of time it takes to compile, launch hosted mode, and refresh.
I am trying to migrate from GWT 1.5 M1 to the M2. During the
compilation step, I have the following kinds of errors :
[GWTCompiler] [ERROR] Errors in 'jar:file:/home/sebastien/workspace/
prism/lib/main/gwtext/gwtext.jar!/com/gwtext/client/util/
DateUtil.java'
[GWTCompiler] [ERROR] Line 116: Referencing method
'com.gwtext.client.util.DateUtil.getTime': return type 'long' is not
safe to access in JSNI code
[GWTCompiler] [ERROR] Line 132: Parameter 1 of method
'com.gwtext.client.util.DateUtil.create': type 'long' may not be
passed out of JSNI code
...
It seems the GWT-EXT library (0.9.3) uses 'long' type. Is it mean that
JSNI code using the 'long' type cannot be used with 1.5M2 version ?
As there is a big gap between gwtext 0.9.3 and gwt 2.x (API
changes ...), both migrations are a huge work for me ...
regards,
Seb
On 8 avr, 05:23, "Bruce Johnson" <br...@google.com> wrote:
> If you haven't already, please take a look at the notes for Milestone 1
> (linked below) for some background information on changes coming in GWT 1.5:
> It bears repeating that for milestone builds like this, there are still many
> known problems, and it is use-at-your-own-risk. It *definitely* isn't ready
> for production use. For example, this milestone build is missing release
> notes, and it doesn't include the developer guide documentation.
> Please expect that it will require some trial and error getting everything
> to work.
> What's new in Milestone 2? Here are some highlights:
> - There is a new DOM API package. Using the new ability to subclass
> JavaScriptObject, GWT 1.5 M2 includes bindings for nearly the entire W3C
> HTML DOM spec. See the javadoc for the package com.google.gwt.dom.client for
> details. The widgets will be retrofitted to use the new DOM classes in the
> upcoming release candidate.
> - Some widgets now have animation effects. Popups, trees, etc. have subtle
> animation effects to provide visual cues when hidden and shown.
> - The addition of a "Showcase" sample. This sample combines features from
> several other samples and demonstrates the new, nicer-looking GWT default
> stylesheet and widget animations. Note that the default style is still in
> flux and is likely to change.
> - Keyboard support has been added where previously absent in UI classes,
> including in menus and tab panels.
> - ARIA support for enhanced accessibility is now present in most widgets,
> including menus, trees, tabs, and button variants.
> - Bi-di. Widgets and panels have built-in support for bi-directional layout.
> - "long" emulation. The Java language defines "long" types to be 64-bit
> signed integers, whereas JavaScript only supports 64-bit floating point
> numbers, which cannot accurately represent the same whole-number range as a
> true "long" type. GWT 1.5 M2 transparently emulates long types properly to
> more faithfully maintain Java semantics in web mode.
> - There is a single Mac OS X distribution that works on both Leopard (10.5)
> and Tiger (10.4).
> Now, some known bugs and caveats:
> - Change from Milestone 1: No more "std/" directory in the compiler output.
> The GWT compiler output directory structure has been reverted to match its
> behavior in GWT 1.4. If auxiliary linker output is generated, additional
> files are placed in a sibling subdirectory whose name is "<module>-aux/". In
> most existing projects, this output directory won't be created, so the
> behavior should match GWT 1.4.
> - The DOM structure for some widgets has changed to accommodate new CSS
> styling options. See the CSS rules used in GWT-default.css and Showcase.css
> (both in the Showcase project) for examples of how to use the new styles.
> - Not all widgets work perfectly in standards mode. There are several minor
> known layout bugs that still need to be fixed for the release candidate.
> - "long" and JSNI. The new long emulation support adds a new prohibition
> against the accidental use of "long" types within JSNI code. If you
> experience this error, the hosted mode tree logger will provide a "More
> Info" link that you can double-click for details on how to resolve the
> issue.
We had a face-to-face meeting today to nail down this issue, and here is what we came up with (rationale in italics): 1. All longs in Java code will be emulated *Existing Java code expects longs to just work, and some of that code can't readily be changed (in libraries or shared server code). If the user cares about performance and a double was suitable before, they can change it to use doubles instead.* 2. long parameters to a JSNI method will result in an error instructing you to use either double or Long. Also, the compiler will continue its current behavior, which is to pass an emulated long object to JSNI, if a to-be-specified annotation is present on the long parameter. This would be used for generated RPC serializers and internal uses, but would also be available to users if they need it (but only documented where the details are explained). *Code that used to work correctly in GWT 1.4 can just change the type to double and it will work exactly as it did before (other than the conversion from the emulated long to double added by the implicit cast). JSNI code that just passes around a token can use Long equally well, and code that really needs access to the emulated long can use the low-visibility annotation to enable it. Developers converting apps from 1.4 to 1.5 will already have lots of warnings to deal with, and a warning about passing long might get lost in the pile of warnings, while the code may no longer work correctly at all. Better to force the developer to choose which use case they want up front and get known behavior than to risk silently bad behavior discovered at runtime.* 3. Since a large portion of the code we are worried about long performance on deals with timestamps, we would provide a GWT-specific way to get timestamps and deltas in a double. *For example, animation code typically does long math on timestamps, which will be significantly slower in 1.5.*
On Tue, Apr 8, 2008 at 11:39 AM, Sebastien <chassa...@gmail.com> wrote:
> Hi,
> I am trying to migrate from GWT 1.5 M1 to the M2. During the > compilation step, I have the following kinds of errors : > [GWTCompiler] [ERROR] Errors in 'jar:file:/home/sebastien/workspace/ > prism/lib/main/gwtext/gwtext.jar!/com/gwtext/client/util/ > DateUtil.java' > [GWTCompiler] [ERROR] Line 116: Referencing method > 'com.gwtext.client.util.DateUtil.getTime': return type 'long' is not > safe to access in JSNI code > [GWTCompiler] [ERROR] Line 132: Parameter 1 of method > 'com.gwtext.client.util.DateUtil.create': type 'long' may not be > passed out of JSNI code > ... > It seems the GWT-EXT library (0.9.3) uses 'long' type. Is it mean that > JSNI code using the 'long' type cannot be used with 1.5M2 version ?
> As there is a big gap between gwtext 0.9.3 and gwt 2.x (API > changes ...), both migrations are a huge work for me ...
> regards, > Seb
> On 8 avr, 05:23, "Bruce Johnson" <br...@google.com> wrote: > > Hi again everybody, > > GWT 1.5 Milestone 2 (build 0.0.2415) is now available:
> > If you haven't already, please take a look at the notes for Milestone 1 > > (linked below) for some background information on changes coming in GWT > 1.5:
> > It bears repeating that for milestone builds like this, there are still > many > > known problems, and it is use-at-your-own-risk. It *definitely* isn't > ready > > for production use. For example, this milestone build is missing release > > notes, and it doesn't include the developer guide documentation. > > Please expect that it will require some trial and error getting > everything > > to work.
> > What's new in Milestone 2? Here are some highlights:
> > - There is a new DOM API package. Using the new ability to subclass > > JavaScriptObject, GWT 1.5 M2 includes bindings for nearly the entire W3C > > HTML DOM spec. See the javadoc for the package com.google.gwt.dom.client > for > > details. The widgets will be retrofitted to use the new DOM classes in > the > > upcoming release candidate.
> > - Some widgets now have animation effects. Popups, trees, etc. have > subtle > > animation effects to provide visual cues when hidden and shown.
> > - The addition of a "Showcase" sample. This sample combines features > from > > several other samples and demonstrates the new, nicer-looking GWT > default > > stylesheet and widget animations. Note that the default style is still > in > > flux and is likely to change.
> > - Keyboard support has been added where previously absent in UI classes, > > including in menus and tab panels.
> > - ARIA support for enhanced accessibility is now present in most > widgets, > > including menus, trees, tabs, and button variants.
> > - Bi-di. Widgets and panels have built-in support for bi-directional > layout.
> > - "long" emulation. The Java language defines "long" types to be 64-bit > > signed integers, whereas JavaScript only supports 64-bit floating point > > numbers, which cannot accurately represent the same whole-number range > as a > > true "long" type. GWT 1.5 M2 transparently emulates long types properly > to > > more faithfully maintain Java semantics in web mode.
> > - There is a single Mac OS X distribution that works on both Leopard > (10.5) > > and Tiger (10.4).
> > Now, some known bugs and caveats:
> > - Change from Milestone 1: No more "std/" directory in the compiler > output. > > The GWT compiler output directory structure has been reverted to match > its > > behavior in GWT 1.4. If auxiliary linker output is generated, additional > > files are placed in a sibling subdirectory whose name is > "<module>-aux/". In > > most existing projects, this output directory won't be created, so the > > behavior should match GWT 1.4.
> > - The DOM structure for some widgets has changed to accommodate new CSS > > styling options. See the CSS rules used in GWT-default.css and > Showcase.css > > (both in the Showcase project) for examples of how to use the new > styles.
> > - Not all widgets work perfectly in standards mode. There are several > minor > > known layout bugs that still need to be fixed for the release candidate.
> > - "long" and JSNI. The new long emulation support adds a new prohibition > > against the accidental use of "long" types within JSNI code. If you > > experience this error, the hosted mode tree logger will provide a "More > > Info" link that you can double-click for details on how to resolve the > > issue.
> We had a face-to-face meeting today to nail down this issue, and here is
> what we came up with (rationale in italics):
> 1. All longs in Java code will be emulated
> *Existing Java code expects longs to just work, and some of that code
> can't readily be changed (in libraries or shared server code). If the
> user
> cares about performance and a double was suitable before, they can change
> it
> to use doubles instead.*
> 2. long parameters to a JSNI method will result in an error
> instructing you to use either double or Long. Also, the compiler will
> continue its current behavior, which is to pass an emulated long object
> to
> JSNI, if a to-be-specified annotation is present on the long parameter.
> This would be used for generated RPC serializers and internal uses, but
> would also be available to users if they need it (but only documented
> where
> the details are explained).
> *Code that used to work correctly in GWT 1.4 can just change the type
> to double and it will work exactly as it did before (other than the
> conversion from the emulated long to double added by the implicit cast).
> JSNI code that just passes around a token can use Long equally well, and
> code that really needs access to the emulated long can use the
> low-visibility annotation to enable it. Developers converting apps from
> 1.4 to 1.5 will already have lots of warnings to deal with, and a
> warning about passing long might get lost in the pile of warnings, while
> the
> code may no longer work correctly at all. Better to force the developer
> to
> choose which use case they want up front and get known behavior than to
> risk
> silently bad behavior discovered at runtime.*
> 3. Since a large portion of the code we are worried about long
> performance on deals with timestamps, we would provide a GWT-specific way
> to
> get timestamps and deltas in a double.
> *For example, animation code typically does long math on timestamps,
> which will be significantly slower in 1.5.*
> On Tue, Apr 8, 2008 at 11:39 AM, Sebastien <chassa...@gmail.com> wrote:
> > Hi,
> > I am trying to migrate from GWT 1.5 M1 to the M2. During the
> > compilation step, I have the following kinds of errors :
> > [GWTCompiler] [ERROR] Errors in 'jar:file:/home/sebastien/workspace/
> > prism/lib/main/gwtext/gwtext.jar!/com/gwtext/client/util/
> > DateUtil.java'
> > [GWTCompiler] [ERROR] Line 116: Referencing method
> > 'com.gwtext.client.util.DateUtil.getTime': return type 'long' is not
> > safe to access in JSNI code
> > [GWTCompiler] [ERROR] Line 132: Parameter 1 of method
> > 'com.gwtext.client.util.DateUtil.create': type 'long' may not be
> > passed out of JSNI code
> > ...
> > It seems the GWT-EXT library (0.9.3) uses 'long' type. Is it mean that
> > JSNI code using the 'long' type cannot be used with 1.5M2 version ?
> > As there is a big gap between gwtext 0.9.3 and gwt 2.x (API
> > changes ...), both migrations are a huge work for me ...
> > regards,
> > Seb
> > On 8 avr, 05:23, "Bruce Johnson" <br...@google.com> wrote:
> > > Hi again everybody,
> > > GWT 1.5 Milestone 2 (build 0.0.2415) is now available:
> > > If you haven't already, please take a look at the notes for Milestone 1
> > > (linked below) for some background information on changes coming in GWT
> > 1.5:
> > > It bears repeating that for milestone builds like this, there are still
> > many
> > > known problems, and it is use-at-your-own-risk. It *definitely* isn't
> > ready
> > > for production use. For example, this milestone build is missing release
> > > notes, and it doesn't include the developer guide documentation.
> > > Please expect that it will require some trial and error getting
> > everything
> > > to work.
> > > What's new in Milestone 2? Here are some highlights:
> > > - There is a new DOM API package. Using the new ability to subclass
> > > JavaScriptObject, GWT 1.5 M2 includes bindings for nearly the entire W3C
> > > HTML DOM spec. See the javadoc for the package com.google.gwt.dom.client
> > for
> > > details. The widgets will be retrofitted to use the new DOM classes in
> > the
> > > upcoming release candidate.
> > > - Some widgets now have animation effects. Popups, trees, etc. have
> > subtle
> > > animation effects to provide visual cues when hidden and shown.
> > > - The addition of a "Showcase" sample. This sample combines features
> > from
> > > several other samples and demonstrates the new, nicer-looking GWT
> > default
> > > stylesheet and widget animations. Note that the default style is still
> > in
> > > flux and is likely to change.
> > > - Keyboard support has been added where previously absent in UI classes,
> > > including in menus and tab panels.
> > > - ARIA support for enhanced accessibility is now present in most
> > widgets,
> > > including menus, trees, tabs, and button variants.
> > > - Bi-di. Widgets and panels have built-in support for bi-directional
> > layout.
> > > - "long" emulation. The Java language defines "long" types to be 64-bit
> > > signed integers, whereas JavaScript only supports 64-bit floating point
> > > numbers, which cannot accurately represent the same whole-number range
> > as a
> > > true "long" type. GWT 1.5 M2 transparently emulates long types properly
> > to
> > > more faithfully maintain Java semantics in web mode.
> > > - There is a single Mac OS X distribution that works on both Leopard
> > (10.5)
> > > and Tiger (10.4).
> > > Now, some known bugs and caveats:
> > > - Change from Milestone 1: No more "std/" directory in the compiler
> > output.
> > > The GWT compiler output directory structure has been reverted to match
> > its
> > > behavior in GWT 1.4. If auxiliary linker output is generated, additional
> > > files are placed in a sibling subdirectory whose name is
> > "<module>-aux/". In
> > > most existing projects, this output directory won't be created, so the
> > > behavior should match GWT 1.4.
> > > - The DOM structure for some widgets has changed to accommodate new CSS
> > > styling options. See the CSS rules used in GWT-default.css and
> > Showcase.css
> > > (both in the Showcase project) for examples of how to use the new
> > styles.
> > > - Not all widgets work perfectly in standards mode. There are several
> > minor
> > > known layout bugs that still need to be fixed for the release candidate.
> > > - "long" and JSNI. The new long emulation support adds a new prohibition
> > > against the accidental use of "long" types within JSNI code. If you
> > > experience this error, the hosted mode tree logger will provide a "More
> > > Info" link that you can double-click for details on how to resolve the
> > > issue.
On Tue, Apr 8, 2008 at 11:39 AM, Sebastien <chassa...@gmail.com> wrote:
> Hi,
> I am trying to migrate from GWT 1.5 M1 to the M2. During the > compilation step, I have the following kinds of errors : > [GWTCompiler] [ERROR] Errors in 'jar:file:/home/sebastien/workspace/ > prism/lib/main/gwtext/gwtext.jar!/com/gwtext/client/util/ > DateUtil.java' > [GWTCompiler] [ERROR] Line 116: Referencing method > 'com.gwtext.client.util.DateUtil.getTime': return type 'long' is not > safe to access in JSNI code > [GWTCompiler] [ERROR] Line 132: Parameter 1 of method > 'com.gwtext.client.util.DateUtil.create': type 'long' may not be > passed out of JSNI code > ... > It seems the GWT-EXT library (0.9.3) uses 'long' type. Is it mean that > JSNI code using the 'long' type cannot be used with 1.5M2 version ?
> As there is a big gap between gwtext 0.9.3 and gwt 2.x (API > changes ...), both migrations are a huge work for me ...
> regards, > Seb
> On 8 avr, 05:23, "Bruce Johnson" <br...@google.com> wrote: > > Hi again everybody, > > GWT 1.5 Milestone 2 (build 0.0.2415) is now available:
> > If you haven't already, please take a look at the notes for Milestone 1 > > (linked below) for some background information on changes coming in GWT > 1.5:
> > It bears repeating that for milestone builds like this, there are still > many > > known problems, and it is use-at-your-own-risk. It *definitely* isn't > ready > > for production use. For example, this milestone build is missing release > > notes, and it doesn't include the developer guide documentation. > > Please expect that it will require some trial and error getting > everything > > to work.
> > What's new in Milestone 2? Here are some highlights:
> > - There is a new DOM API package. Using the new ability to subclass > > JavaScriptObject, GWT 1.5 M2 includes bindings for nearly the entire W3C > > HTML DOM spec. See the javadoc for the package com.google.gwt.dom.client > for > > details. The widgets will be retrofitted to use the new DOM classes in > the > > upcoming release candidate.
> > - Some widgets now have animation effects. Popups, trees, etc. have > subtle > > animation effects to provide visual cues when hidden and shown.
> > - The addition of a "Showcase" sample. This sample combines features > from > > several other samples and demonstrates the new, nicer-looking GWT > default > > stylesheet and widget animations. Note that the default style is still > in > > flux and is likely to change.
> > - Keyboard support has been added where previously absent in UI classes, > > including in menus and tab panels.
> > - ARIA support for enhanced accessibility is now present in most > widgets, > > including menus, trees, tabs, and button variants.
> > - Bi-di. Widgets and panels have built-in support for bi-directional > layout.
> > - "long" emulation. The Java language defines "long" types to be 64-bit > > signed integers, whereas JavaScript only supports 64-bit floating point > > numbers, which cannot accurately represent the same whole-number range > as a > > true "long" type. GWT 1.5 M2 transparently emulates long types properly > to > > more faithfully maintain Java semantics in web mode.
> > - There is a single Mac OS X distribution that works on both Leopard > (10.5) > > and Tiger (10.4).
> > Now, some known bugs and caveats:
> > - Change from Milestone 1: No more "std/" directory in the compiler > output. > > The GWT compiler output directory structure has been reverted to match > its > > behavior in GWT 1.4. If auxiliary linker output is generated, additional > > files are placed in a sibling subdirectory whose name is > "<module>-aux/". In > > most existing projects, this output directory won't be created, so the > > behavior should match GWT 1.4.
> > - The DOM structure for some widgets has changed to accommodate new CSS > > styling options. See the CSS rules used in GWT-default.css and > Showcase.css > > (both in the Showcase project) for examples of how to use the new > styles.
> > - Not all widgets work perfectly in standards mode. There are several > minor > > known layout bugs that still need to be fixed for the release candidate.
> > - "long" and JSNI. The new long emulation support adds a new prohibition > > against the accidental use of "long" types within JSNI code. If you > > experience this error, the hosted mode tree logger will provide a "More > > Info" link that you can double-click for details on how to resolve the > > issue.
Thanks for the new release. Here are my 2c from the first look:
- Menu animation looks funny. It should not be part of the default
behavior. I think menus looked good without the animation. Is there a
flag to turn off the animations?
- Disclosure panel animation was much required and the panel now looks
complete with that effect.
- Tree animation looks great! Wish you had added lines in the tree.
Many users have asked for that. It gives the tree a rigid look.
- popup and dialog animations: Correct me if I am wrong, but I guess
the window rectangle zooms out from the center of the screen(correct
me if i am wrong here). It would be nice if these rectangle could zoom
out of a specified widget(example the button that is clicked).
Moreover it would be nice if you could provide a example that will
fade the background when a "Dialog" is displayed.
- Request: Can you implement animation for stackpanel tabs??
- Request: Double click to expand 100% for the horizontal and vertical
splitpanel?
@Joel - I'm using a pre-built version, so maybe there's something
different in the source. I might try switching to the GlassPanel in
the incubator anyway, as that seems to be more supported (I haven't
seen an update to the gwt-widgets library in a long time)
@Toby - I saw all the warnings on my first compile, but I have fixed
them all, it made a slight difference to the build time, but the ones
I reported were for the fixed version already. Also I've noticed that
the compiler is inspecting classes that I don't even use (out of third
party GWT library files) - is this expected behaviour? I noticed this
initially when GWT was complaining about components of the gwt-widget
library, so I just removed these files from the jar.
Rusty
On Apr 8, 10:54 pm, "Toby Reyelts" <to...@google.com> wrote:
> On Tue, Apr 8, 2008 at 1:32 AM, rusty <rustysh...@gmail.com> wrote:
> > Excellent work, go GWT team!
> > Output files are about the same size as Milestone 1, however compile
> > time has increased a bit. Our project which used to take about 45
> > seconds to build now takes 1m20. Not sure if that's specifically
> > something to do with our project or whether it will be a general
> > thing? I'm sure you've crammed all sorts of goodness into it, but
> > anything you can do to tune that compile time would be awesome!
> Rusty (and others),
> Can you ensure that you're not getting a lot of warnings output to the
> console, for example, about deprecated metadata usage like gwt.typeArgs?
> We've seen several other people encounter slowness due to large amounts of
> logging. For example, running with -logLevel DEBUG can have a huge impact on
> the amount of time it takes to compile, launch hosted mode, and refresh.
@Joel: I've switched to GlassPanel and all is well now. Seems like
it's a better implementation anyway. I also figured out my width
problem. It's that in this milestone the Dialog Box & PopupPanel is
much more configurable (which is good) on of the style names used in
it clashed with our existing CSS though (which had a width of 660px).
This is our fault though, because we had a blanket div.content which
picked up .gwt-DialogBox .middleCenter .content as well. So put that
one down to my stupidity and don't worry about looking into it.
@Toby I forgot to mention I'm running the debugger at WARN level with
output OBF, and no warnings appear. Upping it to ERROR doesn't seem to
make any difference to the compile times. My theory is that the
compiler is now looking through every single class in all of my
inherited modules even if I don't actually use those classes? Or
perhaps it has always done that, but it now does something extra as
well? I'm guessing this because when I was getting warnings, it was in
classes I wasn't even using anywhere.
Rusty
On Apr 9, 8:25 am, rusty <rustysh...@gmail.com> wrote:
> @Joel - I'm using a pre-built version, so maybe there's something
> different in the source. I might try switching to the GlassPanel in
> the incubator anyway, as that seems to be more supported (I haven't
> seen an update to the gwt-widgets library in a long time)
> @Toby - I saw all the warnings on my first compile, but I have fixed
> them all, it made a slight difference to the build time, but the ones
> I reported were for the fixed version already. Also I've noticed that
> the compiler is inspecting classes that I don't even use (out of third
> party GWT library files) - is this expected behaviour? I noticed this
> initially when GWT was complaining about components of the gwt-widget
> library, so I just removed these files from the jar.
> > On Tue, Apr 8, 2008 at 1:32 AM, rusty <rustysh...@gmail.com> wrote:
> > > Excellent work, go GWT team!
> > > Output files are about the same size as Milestone 1, however compile
> > > time has increased a bit. Our project which used to take about 45
> > > seconds to build now takes 1m20. Not sure if that's specifically
> > > something to do with our project or whether it will be a general
> > > thing? I'm sure you've crammed all sorts of goodness into it, but
> > > anything you can do to tune that compile time would be awesome!
> > Rusty (and others),
> > Can you ensure that you're not getting a lot of warnings output to the
> > console, for example, about deprecated metadata usage like gwt.typeArgs?
> > We've seen several other people encounter slowness due to large amounts of
> > logging. For example, running with -logLevel DEBUG can have a huge impact on
> > the amount of time it takes to compile, launch hosted mode, and refresh.
> On Tue, Apr 8, 2008 at 11:39 AM, Sebastien <chassa...@gmail.com> wrote:
> > Hi,
> > I am trying to migrate from GWT 1.5 M1 to the M2. During the
> > compilation step, I have the following kinds of errors :
> > [GWTCompiler] [ERROR] Errors in 'jar:file:/home/sebastien/workspace/
> > prism/lib/main/gwtext/gwtext.jar!/com/gwtext/client/util/
> > DateUtil.java'
> > [GWTCompiler] [ERROR] Line 116: Referencing method
> > 'com.gwtext.client.util.DateUtil.getTime': return type 'long' is not
> > safe to access in JSNI code
> > [GWTCompiler] [ERROR] Line 132: Parameter 1 of method
> > 'com.gwtext.client.util.DateUtil.create': type 'long' may not be
> > passed out of JSNI code
> > ...
> > It seems the GWT-EXT library (0.9.3) uses 'long' type. Is it mean that
> > JSNI code using the 'long' type cannot be used with 1.5M2 version ?
> > As there is a big gap between gwtext 0.9.3 and gwt 2.x (API
> > changes ...), both migrations are a huge work for me ...
> > regards,
> > Seb
> > On 8 avr, 05:23, "Bruce Johnson" <br...@google.com> wrote:
> > > Hi again everybody,
> > > GWT 1.5 Milestone 2 (build 0.0.2415) is now available:
> > > If you haven't already, please take a look at the notes for Milestone 1
> > > (linked below) for some background information on changes coming in GWT
> > 1.5:
> > > It bears repeating that for milestone builds like this, there are still
> > many
> > > known problems, and it is use-at-your-own-risk. It *definitely* isn't
> > ready
> > > for production use. For example, this milestone build is missing release
> > > notes, and it doesn't include the developer guide documentation.
> > > Please expect that it will require some trial and error getting
> > everything
> > > to work.
> > > What's new in Milestone 2? Here are some highlights:
> > > - There is a new DOM API package. Using the new ability to subclass
> > > JavaScriptObject, GWT 1.5 M2 includes bindings for nearly the entire W3C
> > > HTML DOM spec. See the javadoc for the package com.google.gwt.dom.client
> > for
> > > details. The widgets will be retrofitted to use the new DOM classes in
> > the
> > > upcoming release candidate.
> > > - Some widgets now have animation effects. Popups, trees, etc. have
> > subtle
> > > animation effects to provide visual cues when hidden and shown.
> > > - The addition of a "Showcase" sample. This sample combines features
> > from
> > > several other samples and demonstrates the new, nicer-looking GWT
> > default
> > > stylesheet and widget animations. Note that the default style is still
> > in
> > > flux and is likely to change.
> > > - Keyboard support has been added where previously absent in UI classes,
> > > including in menus and tab panels.
> > > - ARIA support for enhanced accessibility is now present in most
> > widgets,
> > > including menus, trees, tabs, and button variants.
> > > - Bi-di. Widgets and panels have built-in support for bi-directional
> > layout.
> > > - "long" emulation. The Java language defines "long" types to be 64-bit
> > > signed integers, whereas JavaScript only supports 64-bit floating point
> > > numbers, which cannot accurately represent the same whole-number range
> > as a
> > > true "long" type. GWT 1.5 M2 transparently emulates long types properly
> > to
> > > more faithfully maintain Java semantics in web mode.
> > > - There is a single Mac OS X distribution that works on both Leopard
> > (10.5)
> > > and Tiger (10.4).
> > > Now, some known bugs and caveats:
> > > - Change from Milestone 1: No more "std/" directory in the compiler
> > output.
> > > The GWT compiler output directory structure has been reverted to match
> > its
> > > behavior in GWT 1.4. If auxiliary linker output is generated, additional
> > > files are placed in a sibling subdirectory whose name is
> > "<module>-aux/". In
> > > most existing projects, this output directory won't be created, so the
> > > behavior should match GWT 1.4.
> > > - The DOM structure for some widgets has changed to accommodate new CSS
> > > styling options. See the CSS rules used in GWT-default.css and
> > Showcase.css
> > > (both in the Showcase project) for examples of how to use the new
> > styles.
> > > - Not all widgets work perfectly in standards mode. There are several
> > minor
> > > known layout bugs that still need to be fixed for the release candidate.
> > > - "long" and JSNI. The new long emulation support adds a new prohibition
> > > against the accidental use of "long" types within JSNI code. If you
> > > experience this error, the hosted mode tree logger will provide a "More
> > > Info" link that you can double-click for details on how to resolve the
> > > issue.
I vote for reverting PopupPanel 3x3 table implementation.
What's the reason of this change? (rounded corners are possible with
1.4 PopupPanel implementation...)
I'll let JohnL answer this in more detail, but my understanding is that only limited styling is possible without the 9-box structure. I believe things like adding drop-shadows and borders (other than a simple, solid color), while still retaining the ability to resize, are nigh impossible without table cells. Would that all browsers actually implemented the full CSS border image styles like WebKit does... If this structure's breaking your code in a way that's difficult to work around, please let us know exactly how it is doing so. I'm not entirely averse to reverting it if it causes hard-to-fix problems -- but we're trying to walk a fine line here. If we leave the structure the way it was, lots of styles become difficult and/or impossible. We've heard over and over again that people want all the beautiful styling that they see in some other libraries, and we're trying to provide it without breaking everyone.
On Wed, Apr 9, 2008 at 8:27 AM, Andrej <ahars...@gmail.com> wrote:
> Hi,
> I vote for reverting PopupPanel 3x3 table implementation. > What's the reason of this change? (rounded corners are possible with > 1.4 PopupPanel implementation...)
I suggest to create DecoratorPopupPanel (or similar name) with 3x3
table rendering, and
revert PopupPanel from 1.4.
There are many situations where we don't need to style PopupPanel at
all
for example it is just single TextBox container.
I will try to publish example of our application using Desktop window
manager.
thanks.
Andrej
On Apr 9, 2:39 pm, "Joel Webber" <j...@google.com> wrote:
> I'll let JohnL answer this in more detail, but my understanding is that only
> limited styling is possible without the 9-box structure. I believe things
> like adding drop-shadows and borders (other than a simple, solid color),
> while still retaining the ability to resize, are nigh impossible without
> table cells. Would that all browsers actually implemented the full CSS
> border image styles like WebKit does...
> If this structure's breaking your code in a way that's difficult to work
> around, please let us know exactly how it is doing so. I'm not entirely
> averse to reverting it if it causes hard-to-fix problems -- but we're trying
> to walk a fine line here. If we leave the structure the way it was, lots of
> styles become difficult and/or impossible. We've heard over and over again
> that people want all the beautiful styling that they see in some other
> libraries, and we're trying to provide it without breaking everyone.
> joel.
> On Wed, Apr 9, 2008 at 8:27 AM, Andrej <ahars...@gmail.com> wrote:
> > Hi,
> > I vote for reverting PopupPanel 3x3 table implementation.
> > What's the reason of this change? (rounded corners are possible with
> > 1.4 PopupPanel implementation...)
