Re: [gwt-contrib] Nextgen GWT/JS Interop (Public) (google-web-toolkit-contributors@googlegroups.com)

It might be nice to be able to say that anything defined in a .d.ts can be imported into GWT. This will make it easier to work with JavaScript programmers since they don't have to write any Java code. So perhaps it's worth making sure that generating the Java interfaces from .d.ts files will work?

Re: [gwt-contrib] Nextgen GWT/JS Interop (Public) (google-web-toolkit-contributors@googlegroups.com)

Yep, insuring a clear interface between different world is always valuable and even mandatory in my opinion.. Typescript .d.ts files have already made the job, so why not using this syntax. As a early adopter of gwt in 2006, i could also say that I'm an early adopter of typescript on real projects

Re: [gwt-contrib] Nextgen GWT/JS Interop (Public) (google-web-toolkit-contributors@googlegroups.com)

As cool as I think TS is, there are far more lines of code out there in Js, some even with JsDoc type assertions, so I think the latter would be more useful as a first pass. JsDoc is comments so it works with existing JS. We could explore importing libraries defined in TS, Dart, haXe, et al via som

[gwt-contrib] Google team meeting notes for August 7 (and earlier)

I haven't been sending out emails for our meetings. Let's catch up: August 7th: - John got a "hello world" app running using separate compilation. We talked a bit about how it might get pulled back into GWT. - Brian: Firefox architecture changes may break the Development Mode plugin by the end of

Re: [gwt-contrib] Nextgen GWT/JS Interop (Public) (google-web-toolkit-contributors@googlegroups.com)

I desagree with this assertion ; the goal is not to interop with ts, haxe, coffee, ..., but only with js. Moreover the future of js is ecmascript 6, so ts is a good candidate to express properly an interface; this is not the case IMO of a jsdoc like solution which is verbose and not so precise a

Re: [gwt-contrib] Nextgen GWT/JS Interop (Public) (google-web-toolkit-contributors@googlegroups.com)

I think that's a good point; someone went through the trouble of creating these definition files so it would be nice to be able to use them, even without using TypeScript at all. (On the other hand, how many of those libraries would you say are relevant for GWT? I don't see us using backbone.) For

Re: [gwt-contrib] Nextgen GWT/JS Interop (Public) (google-web-toolkit-contributors@googlegroups.com)

First of all, as long d.ts works, end user should not care if the compiler directly understands it or there is a converter in between. Even the starting point is d.ts or type annotations, in order to have good IDE support you still need a java representation so that your code will compile and auto

[gwt-contrib] Re: Google team meeting notes for August 7 (and earlier)

> > > - Brian: Firefox architecture changes may break the Development Mode > plugin by the end of the year. (The ContextStack service went away [1] and > word is that they will be making more architectural changes [2]. This isn't > the end of Development Mode because we still have Chrome, but w

[gwt-contrib] Could someone review patch for IE10 permutation and MSPointerEvents support, please?

On behalf of author, I'm looking for reviewers for https://gwt-review.googlesource.com/#/c/2421/ Despite the commit message this changeset is ready to be reviewed. :) Any comments / +1's would be appreciated Related issue: Issue 8063: Add basic support for IE 10

[gwt-contrib] Re: Google team meeting notes for August 7 (and earlier)

Our plan is to make Super Dev Mode compile faster. Plan B is to use an extended release of Firefox for a while. (I believe Firefox 24 is the next one.) Despite appearances, I'm not actually a C++ programmer and I'm not plugged into the Firefox community enough to know how realistic it is that i