GWT Incubator Status Update and Schedule
John LaBanca
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.
Thanks,
John LaBanca
on behalf of the GWT team
Arthur Kalmenson
This is really great news.
> 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.
Is this essentially data binding? Since you've put Form Validation at
GWT 2.2, I guess you'd have to have data binding implemented before
then?
> 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.
If the performance issues are not sorted out, would it be possible to
just spit it off into a different project instead of discontinuing it?
Some people may be willing to accept a performance penalty to use
these widgets.
> 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.
Will you be building on what was done in Speed Tracer for Canvas integration?
Thanks again for the update.
All the best,
--
Arthur Kalmenson
> --
> http://groups.google.com/group/Google-Web-Toolkit-Contributors
>
John LaBanca
Hello John,
This is really great news.
Is this essentially data binding? Since you've put Form Validation at
> 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.
GWT 2.2, I guess you'd have to have data binding implemented before
then?
If the performance issues are not sorted out, would it be possible to
> 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.
just spit it off into a different project instead of discontinuing it?
Some people may be willing to accept a performance penalty to use
these widgets.
> GraphicsWill you be building on what was done in Speed Tracer for Canvas integration?
> 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.
jay
Please use this forum generously--ask questions about APIs and bounce
ideas around publicly so that we have ample opportunity to chime in
(and fewer excuses if the delivered solution doesn't work for us).
Thanks!!!!!
jay
On Jan 12, 10:04 am, 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*
dflorey
I've added some ideas of simple annotation based table creation to my
treetable branch:
http://code.google.com/p/google-web-toolkit-incubator/wiki/TreeTable
John LaBanca
Thanks,
John LaBanca
jlab...@google.com
monkeyboy
I'm glad to see that PagingScrollTable will make it to the GWT trunk.
Even now it is a useful widget but I can't wait to see the final
version. I would like to ask a few questions. I am sorry to hear that
the incubator will be shut down. I was wandering what (if anything)
will replace it. With the incubator I as a developer had access to
some tools and widgets that had a great chance to end up in the GWT
trunk so I knew that they had a bigger chance to be supported and I
dared to include them in my projects (eg. PagingScrollTable). I was
burnt a few times with third party gwt libraries found on Google code
for which the developer lost interest after a few months and I was
left with a buggy library without support.
If the incubator is shut down how will we developers be able to find
the new widgets and tools that are being "incubated" by Google
developers? It is a bit hard to find them browsing trough Google code.
I suggest that You put a couple of links in the Tools and Libraries
section of gwt (http://code.google.com/webtoolkit/tools.html). It
would be very helpful.
Regards.
Ray Ryan
Regards.
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
monkeyboy
release. That way developers would know if they should become involved
in the nontrivial (but not too hard) task of compiling GWT from
source. I take the last comment back if such a list exists. I could
not find it.
Regards.
On Jan 20, 4:26 pm, Ray Ryan <rj...@google.com> wrote:
John LaBanca
Thanks,
John LaBanca
jlab...@google.com
monkeyboy
you are shutting down the incubator. What I am suggesting is that
developers should have a place where they can see what new features
(libraries,...) are being developed and not to stumble upon this new
features by chance (like I stumbled upon the doc for
DataBackedWidgetsDesign for example). You mentioned that you send
emails when you start a new project. What do I need to do to receive
such an email?
I think you guys at Google develop great libraries that are perhaps
underused because they are hard to find. Let's take Gin for example
(http://code.google.com/p/google-gin/). I think that more people would
use it if you had a link to Gin from the GWT Tools and Libraries page.
Regards.
On Jan 20, 5:29 pm, John LaBanca <jlaba...@google.com> wrote:
> Libraries and widgets that we want to incubate will be moved into separate
> projects. Instead of downloading one incubator jar, you'll be able to (have
> to) download each project individually. Like Ray said, we're going to
> commit most new features directly to trunk, but we may still want to
> incubate some features if they are highly experimental. We often setup a
> design doc and send out an email when we start a new project, such as the
> data backed widgets, so the community can be involved. I'm sure we'll keep
> doing that.
>
> The advantage of separate projects is that each project can move along at
> its own pace. The incubator currently has some very stable features, some
> highly experimental ones, and some deprecated code, and it isn't obvious
> which is which (well, except the deprecated stuff). With individual
> projects, it should be more obvious what the state of the project is.
>
> Thanks,
> John LaBanca
David
It would be nice that the GWT team would release some development
builds once in a while. That would be very usefull at the point where
new things are added to the trunk. This way you can get a lot more
input from the community, since it makes it much easier to use a more
experimental version of GWT. Compiling from the sources means that we
need direct access to the internet, but not all companies allow that.
As long as we have some indication of what is mostly stable and what
not, we can choose at what point we whish to start using a development
build.
David
> --
> http://groups.google.com/group/Google-Web-Toolkit-Contributors
>
Arthur Kalmenson
--
Arthur Kalmenson
Bruce Johnson
we'd like to do for sure. Not sure about exactly when, but it's good
to know there would be an audience to justify looking into it a bit.
Chris
We build infrequently from trunk and we currently guess what might be
a good version to grab our internal snapshot from. Having a developer
snapshot would help us when we are looking to grab the "latest"
version for our internal use.
Chris....
On Jan 21, 12:07 pm, Bruce Johnson <br...@google.com> wrote:
> Nightly or perhaps less frequent "stable snapshot" builds is something
> we'd like to do for sure. Not sure about exactly when, but it's good
> to know there would be an audience to justify looking into it a bit.
>
> On Thursday, January 21, 2010, Arthur Kalmenson <arthur.k...@gmail.com> wrote:
> > Hmm, a nightly build sounds like a cool idea, I wouldn't mind seeing that as well.
> > --
> > Arthur Kalmenson
>
> > On Thu, Jan 21, 2010 at 3:28 AM, David <david.no...@gmail.com> wrote:
>
> > Hi,
>
> > It would be nice that the GWT team would release some development
> > builds once in a while. That would be very usefull at the point where
> > new things are added to the trunk. This way you can get a lot more
> > input from the community, since it makes it much easier to use a more
> > experimental version of GWT. Compiling from the sources means that we
> > need direct access to the internet, but not all companies allow that.
>
> > As long as we have some indication of what is mostly stable and what
> > not, we can choose at what point we whish to start using a development
> > build.
>
> > David
>
Fushion
of both worlds.
Developer snapshots provide the best way for hardcore developers to
sync their communication on the development progress.
Nightly builds are easy to setup and provide users an easy way to see
if a particular bug is resolved without having to wait several days/
weeks for a developer snapshot to appear.
bond
Any plans for touch interfaces?
Ability to replace mouse events with touch events or new DomImpl with
touch events.
Mark Renouf
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*
Ray Ryan
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.
Joel Webber
dflorey
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
>
dflorey
Joel Webber
Fred Sauer
--
Fred Sauer
Developer Advocate
Google Inc.1600 Amphitheatre Parkway
Mountain View, CA 94043
fre...@google.com
stuckagain
I only realized now that we are depending on the ProgressBar in
incubator... so if I read this right it might get scrapped from GWT :-
S.
David
On Jan 12, 7: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*
John LaBanca
I only realized now that we are depending on the ProgressBar in incubator... so if I read this right it might get scrapped from GWT :-