On Mon, Dec 8, 2014 at 1:00 PM, confile
wrote:
> I use GWT-PhoneGap on an iPhone5 and Super Dev Mode. SDM works file. I use
> the Safari console for logging.
>
>
The problem is you shouldn't be seeing obfuscated method names in GWT 2.7
SDM as incremental compiler uses pretty names. You should see
The stack traces that are logged as escaped exceptions (with missing
causes) and the ones that are logged by Logger (without inheriting
c.g.gwt.logging) will be deobfuscated by Chrome dev tools (if haven't
already fixed in Dev channel).
Being said that, I don't understand why you are not seeing pre
GWT already not conforms to java from numerical perspective. You can easily
leak, for example, non-Integer types disguised as 'int' in the type system.
This causes all sorts of surprises for people who ends up hitting them but
quite luckily most people/apps doesn't care about it. The proposal mostl
Somebody previously experimented with it:
https://github.com/Legioth/devmodejs
On Mon, Nov 24, 2014 at 9:49 AM, 'Ray Cromwell' via GWT Contributors <
google-web-toolkit-contributors@googlegroups.com> wrote:
> If you mean replacing the DevMode plugin with pure JS in Chrome Dev
> Tools, I don't th
The one of the problems is the boxing makes the support of method
overloading, var args, etc. more complicated and much slower in JsInterop.
Making it optional is not going to help with those.
I think with the experiment we will have a very good data on the impact of
this change, after that we can
Resurrecting this.
I talked with Roberto and then Ray yesterday and we think that this is a
good idea and this will both improve performance and simplify
jsinterop/compiler.
The general idea is to make the boxed types work similar to String so all
instance methods will be staticified and instance
We originally started with the idea that when we encounter a non-JsType
that is a Single-Abstract-Method class (SAM), we will automatically threat
it as a javascript function for interoperability purposes.
For that to work well, we need to make it work in a predictable way. Which
means;
1. Behav
We met with Ray today. We are planning to have it for GWT 3.0 but there are
parts that needs to be fleshed out more before that (e.g. handling of array
literals inside object literals).
On Wed Nov 12 2014 at 4:52:40 PM Cristian Rinaldi
wrote:
> @Goktug
> some progress in this proposal?
>
> Thank
I'm glad you solved it.
For future references, in general it is good idea to keep the strict
enabled - though some libraries that are not in your control might cause
compilation problems that you cannot fix without changing the lib.
On Sun, Nov 9, 2014 at 11:16 PM, Erik Kuefler wrote:
> Cool, di
Here is an early draft for adding support for JavaScript object literals in
GWT JsInterop:
http://goo.gl/K2Aygn
TL;DR;
@JsType(literal=true)
class MapOptions {
public double zoom;
public int mapTypeId;
public LatLon center;
}
MapOptions options = new MapOptions() {{
zoom = 8;
mapTy
Without a repro case and debugging the best suggestion we have is to enable
"strict" mode in your compilation. This might show some additional
compilation errors but it's your best shot.
When you are looking at the errors, you will probably see some errors in
"client.pages.AddParametersView.MyUiBin
It is compiler magic. The compiler understands from PrototypeOfJsType and
assumes any methods in the class are native, hence ignores the method body.
On Wed, Nov 5, 2014 at 4:08 AM, Cristian Rinaldi
wrote:
> @goktug I like this option, it is expressive and concise.
>
> But I have a question,
> T
Sorry guys. When I said next release, I meant next major release (2.8 or
3.0).
On Tue, Nov 4, 2014 at 8:04 AM, Cristian Rinaldi
wrote:
> @confile
>
> @goktug said "However we don't have an ETA for this and 2.7 is already
> at RC1 so you need to wait for the next release."
> This may mean:
>
Method overloading is supposed to be ok if there is no prototype is given,
however in your case prototype is provided hence even if we fix it, it will
not work for your case.
There two ways to cover your use case here. One is making var-args work (if
it is not already working) so that you can do s
ive methods,
>> *then* we can just drop it's class setup from the output".
>>
>> Otherwise, for every single one of these you'll get massive bloat, and a
>> SDM compile of Elemental 2.0 would have a thousand stubbed out classes in
>> it.
>>
>&g
get massive bloat, and a
> SDM compile of Elemental 2.0 would have a thousand stubbed out classes in
> it.
>
>
> On Sat Nov 01 2014 at 10:07:21 AM 'Goktug Gokdogan' via GWT Contributors <
> google-web-toolkit-contributors@googlegroups.com> wrote:
>
>> (I
On Sat, Nov 1, 2014 at 8:25 AM, Stephen Haberman wrote:
>
> > I will try to summarize my thought process and different options that
> > I have played with so that you could get a better understanding where
> > I'm coming from and I hope it will provide good documentation for
> > future.
>
> Thank
be not difficult to
> modify it and return proxies of classes implementing native methods ant
> throwing sensible messages to the user telling what methods are used, etc.
>
> Coming back to JsInterop, I agree that native methods is an easy solution,
> probably not so difficult t
There is going to be a JsMethod to provide custom names to the method so
that you can name the method as abc() and map it to xyx() in the js.
But before that I didn't understand why it doesn't work out of the box. You
are not overloading based on return type; one of the methods has an
argument and
(I will read & respond to comments after the weekend)
On Sat, Nov 1, 2014 at 9:52 AM, Goktug Gokdogan wrote:
> There is also a third option.
>
> User writes:
>
> @JsType(prototype = "Object")interface JsObject {
>
> class prototype extends Prototype_JsObject {}
>
> interface Static {
> S
There is also a third option.
User writes:
@JsType(prototype = "Object")interface JsObject {
class prototype extends Prototype_JsObject {}
interface Static {
String[] keys(JsObject obj);
JsObject defineProperties(JsObject obj, JsObject props);
}
static Static getStatic() {
I finally had some time to think about JsInterop and how to abstract
browser APIs.
I will try to summarize my thought process and different options that I
have played with so that you could get a better understanding where I'm
coming from and I hope it will provide good documentation for future.
to provide the .gss files for people using GSS and want to
> override some style class of cell widgets. We have this case at Arcbees
> where css guys want to use their existing mixins to style CellTable.
>
>
>
> On Wed Oct 29 2014 at 6:49:46 PM 'Goktug Gokdogan' v
SGTM.
On Wed, Oct 29, 2014 at 12:58 PM, 'Daniel Kurka' via GWT Contributors <
google-web-toolkit-contributors@googlegroups.com> wrote:
> Jens and I talked offline.
>
> Since gwttars are only relevant for the prod compile and do not impact SDM
> compile times, we don't really need them anymore. Th
The original idea to make the GSS default was to ship .gss files next to
.css files and let the generator automatically use the file with the gss
extension.
We can probably ship the gss files but I think it is optional at this point.
On Wed, Oct 29, 2014 at 5:50 AM, Julien Dramaix
wrote:
> Now t
Just FYI, we were planning to drop the $wnd and isNative last time we
discussed about it..
On Wed, Oct 29, 2014 at 10:01 AM, confile
wrote:
> Thank you Ray. This is a good explanation. It should be added to the docs.
>
> Best
> Michael
>
> Am Mittwoch, 29. Oktober 2014 16:44:42 UTC+1 schrieb Ray
Today finally I had some free time to think about the rest of the issues
(extending, constructors, static functions etc). I'm going to make another
attempt to make those pieces work better and less boilerplatey. Will update
the thread if I find something that is worth sharing.
On Tue, Oct 28, 2014
If it is feasible yes. I'm not sure if we can do a designer release at this
point.
We can put back the removed method and mark it deprecated.
On Tue, Oct 28, 2014 at 1:58 PM, Roberto Lublinerman
wrote:
> I suspect that the designer needs to be recompiled; do you want to provide
> the old api so
On Tue, Oct 28, 2014 at 8:05 AM, 'Daniel Kurka' via GWT Contributors <
google-web-toolkit-contributors@googlegroups.com> wrote:
> Hi all,
>
> the smoke testing for the release showed up a couple of problems, some of
> them need to be fixed before we put RC1 out others can wait until the final
> re
On Sat, Oct 25, 2014 at 2:27 AM, Julien Dramaix
wrote:
> For the time being, you have to use the converter externally, see
> https://github.com/jDramaix/gss.gwt/wiki/Migration-guide#the-converter
> (Now the support of GSS is included in GWT, you don't need any other
> dependencies than gwt-user.j
com.google.gwt.widget.* was deprecated and removed in the 2.7 release.
You can get a copy of the files here:
https://code.google.com/p/google-web-toolkit/source/browse/trunk/user/src/com/google/gwt/widget/client?r=9884
On Thu, Oct 23, 2014 at 7:57 AM, Stefan Lecho wrote:
> It seems that the com.
IIRC, there was a bug in compiler where is you call GWT.create on JSO (e.g.
when you inject it via GIN), it will generate a new MyJso call (which
shouldn't work normally as the constructor is protected.)
On Tue, Oct 21, 2014 at 4:06 AM, Jan Thewes wrote:
> Ok thx. This is what I assumed.
> Will
herits from my gwtxml:
>
>
>>
>>
>>
>>
>>
>>
>>
>>
>>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>
> On Sun, Oct 19, 2014 at 3:03 PM, 'Gok
Does adding inherit to c.g.gwt.uibinder.UiBinder fix the issue?
We broke many cyclic dependencies around c.g.gwt.user.User. In this
process, I dropped many unneeded dependencies to User from smaller modules.
As most developers directly depend on User that doesn't have any affect.
However if they w
Is there any fundamental reason why we don't support script tags for
Cross-Site-IFrame?
On Sat, Oct 18, 2014 at 2:54 PM, Jens wrote:
>Invoking Linker Cross-Site-Iframe
>>
>> [ERROR] The Cross-Site-Iframe linker does not support
ll change in a future
> + * release), so overriding them will require returning an
> Element
> + * object too.
> */
> +@Deprecated
> public class Element extends com.google.gwt.dom.client.Element {
>
> Emphasis mine, apologies to Matthew if it feels like I am twist
I think the other (probably bigger) problem is method overloads that has
Element as the parameter type instead of return type (as that is no such
thing like co-variant parameter types).
That means for whole story to work, every third-party library needs to do
the same that we did in the SDK; provi
This is a giant change for us and we don't have a simple way to handle that
even with the tooling that we have. Let's discuss this after the release
cut.
On Wed, Oct 8, 2014 at 9:46 PM, Colin Alworth wrote:
> On Wednesday, October 8, 2014 5:16:18 PM UTC-5, Thomas Broyer wrote:
>>
>>
>>
>> On Wed
On Thu, Oct 9, 2014 at 7:04 AM, Thomas Broyer wrote:
>
>
> On Thursday, October 9, 2014 3:25:37 PM UTC+2, Daniel Kurka wrote:
>>
>> We are making steady progress towards GWT 2.7. At this point we are not
>> accepting any new patches, but we still have a list of issues that we would
>> like to inc
There are a few things we need to do. I will talk with Andrei and see if we
can make it.
On Wed, Oct 8, 2014 at 7:54 AM, wrote:
> Hi,
>
> thank you all for your hard work. We have been using GWT and SDM with
> great success in a big financial software company :).
> There is one major feature tha
We are not really making a release for JsInterop for 2.7 and it is not
meant to be used in production and missing a lot of stuff.
The released stuff is just something that people can play with and give
some feedback.
On Wed, Oct 8, 2014 at 10:31 AM, confile
wrote:
> @Ray Cromwell will the @Entry
generator, we
>>> will be able to reintroduce this automatic in-memory conversion if we
>>> want still to support the old syntax.
>>>
>>> Now I think we have to mark the current syntax of CssResource as
>>> deprecated in favor of GSS. In order to able to
der to ease the conversion of existing CssResource to
> GSS, we could maybe during the compilation convert every .css file with the
> converter and write the result on disk (in the "extra" directory) if the
> -extra flag is set.
>
> Julien
>
> On Mon, Oct 6, 2014 at 11:
We worked on a migration plan a few weeks back. I don't think we need to
mix css and gss together inside the same app.
At this point, the libraries have multiple reasonable options on
compatibility:
1- Provide both css and gss file for the resource (recommended).
The library will work fine regard
It might be related to the bug[1] that mdempsky@ filed to Firefox earlier.
The Firefox's VM was causing an incorrect polymorphic dispatch sometimes.
[1] https://bugzilla.mozilla.org/show_bug.cgi?id=872796
On Fri, Oct 3, 2014 at 11:52 AM, Stephen Haberman <
stephen.haber...@gmail.com> wrote:
> He
ck anyway.
>
> Are you suggesting that the comment should point out that IE9 probably
> shouldn't be bound in that way (though it works, and may not work if
> differently bound)?
>
> Thanks for any clarification,
> Colin
>
> On Thu, Oct 2, 2014 at 11:05 AM, 'G
There are still 80+ references to IE6 in the code base. Still looking for
more patches...
On Sat, Jul 12, 2014 at 6:15 AM, Jens wrote:
> Michael, you should track https://gwt-review.googlesource.com/#/c/5304/
> so you don't do the same work again.
>
> -- J.
>
> --
> You received this message bec
On Thu, Oct 2, 2014 at 12:41 AM, Manuel Carrasco Moñino
wrote:
> Hi,
>
> There are a bunch of Elemental patches which fix some issues, some of them
> manifested when running its test suite which was not enabled, and the
> others to use elemental json as a replacement of the controversial
> org.j
Reverting the binding sounds good to me. Please add a comment to the
binding; it might probably be bound to something else but not tested.
On Wed, Oct 1, 2014 at 9:39 PM, Colin Alworth wrote:
> It looks like changes to a few rebind rules are generating some new
> logspam when any GWT app compile
; On Tuesday, September 30, 2014 11:57:56 AM UTC-7, John Stalcup wrote:
>>
>> Yeah I kind of agree.
>>
>> If DevMode support is removed in Chrome soon after the 2.7 release, we'll
>> be wishing we'd made DevMode launches default to turning superDevMod
Thinking about it, we should probably make superDevMode opt-out instead of
opt-in and make it work out of the box for existing users instead of asking
them to add the -superDevMode.
So what do you think about making superDevMode the default for dev-mode in
2.7 release?
PS: BTW, if you haven't alr
1.7 was mostly required for GSS and that is no longer planned for 2.7
release so we can probably fix this breakage (recently introduced) instead
of a warning.
On Tue, Sep 30, 2014 at 10:50 AM, Brandon Donnelson wrote:
> Just a thought, the folks that forget to update Java 1.6 to Java 1.7 in
> t
Did you enable jsinterop?
If you did, take a look at the generated javascript and see if it makes
sense.
On Tue, Sep 30, 2014 at 3:55 AM, Michael Vogt wrote:
> Hello.
>
> Should it be possible right now to use JsInterop to use the facebook
> Javascript sdk?
>
> The call I want to use is FB.XFB
I have a patch that will introduce a preconditions helper class to be used
internally by the SDK. It will be very similar to the one in Guava with
some modifications.
My goals with this class are:
1- Ability to provide different levels of checking (e.g. development vs
production) without worrying
On Wed, Aug 27, 2014 at 2:52 PM, Colin Alworth wrote:
> As I'm sure everyone is aware, IE11 is making the navigator.useragent
> property significantly more useless than it already was, by having IE11
> identify as 'Trident' rather than 'MSIE', and adding 'iPhone', 'Webkit',
> 'Android' and a few
We don't have any plans for this in 2.7. It should be fine to use the one
from Speedtracer though.
On Sat, Aug 23, 2014 at 3:24 PM, confile
wrote:
> It would be great if the Web Workers code from google Speedtracer would be
> included into GWT 2.7
>
> Here is the link to the code:
> https://cod
On Fri, Aug 22, 2014 at 10:00 AM, Cristian Rinaldi
wrote:
> I followed with JsInterop and implement a basic version of Promise (not
> full implemented).
> The code is here:
>1)
>
> https://github.com/workingflows/gwt-jscore/tree/master/src/main/java/com/workingflows/js/jscore/client/api/pro
On Thu, Aug 21, 2014 at 5:29 AM, Cristian Rinaldi
wrote:
> Thanks +Goktug Gokdogan for response.
>
> APT is very good option and java 8 support for GWT 3.0 would be a amazing
> thing.
> You have a planning for Elemental 2.0 or initial documentation to share,
> to how you plan address the desing?
nterface NodeList extends Iterable {
> T item(int x);
> int length();
>
>default Iterator iterator() {
> return NodeListIterator(this);
>}
> }
>
>
> for (T x : nodeList) { ... }
>
> Are we ballsy enough to say GWT 3.0 = Java8 source level enforced for
>
On Wed, Aug 20, 2014 at 6:17 AM, Cristian Rinaldi
wrote:
> Community:
> I'm playing with JsInterop , and I have two questions:
>
> 1) Are you planning to try the static methods of JS objects, such as
> Object, Promise, etc.?
>
There will be some static helpers provided from the SDK. I
*[to: +google-web-toolkit-contributors]*
(I originally didn't think this thoroughly and considered it as the
specifics of the implementation but actually it is not.)
On Tue, Aug 19, 2014 at 7:00 PM, Thomas Broyer wrote:
> Could we use the public gwt-contrib rather than the private
> gwt-mainta
Thanks for the info.
We didn't do much change in gecko for IE11; mostly skipping workarounds
specific to gecko. In general when we refactor stuff we try to provide less
specific permutations.
I think best of course of action here is to do the same here and hopefully
we will eventually converge. Tha
(Responded for the parts that I know the answer for)
On Fri, Aug 1, 2014 at 8:07 AM, Manuel Carrasco Moñino
wrote:
>
> Hi all
>
> There is a patch [1] from Thomas in gerrit for spliting elemental
> apparently in 3 libraries:
> - elemental-collections
> - elemental-json
> - elemental
>
> 1.- Wha
On Fri, Jul 25, 2014 at 3:12 PM, Jens wrote:
> This is not intended and actually a bug in deferred binding. I'll send a
>> patch. IE10+ & FF should still be using CollectorModernNoSourceMap.
>>
>
> Ok cool. Is there a good reason why IE 11 and FF should not use
> CollectorModern yet?
>
>
No good
On Fri, Jul 25, 2014 at 10:15 AM, Jens wrote:
> Hi,
>
> for some time our app has produced useless stack traces in FF, IE10+11 in
> case of null pointer exceptions thrown by the browser (TypeError: var is
> null). After some debugging I have seen that our app uses CollectorLegacy
> for these brow
Here is quick proposal that describes a way to access GWT binding and
configuration properties via System.getProperty:
https://docs.google.com/document/d/1LEP0H-6z__Mog0QTt-NAFpllcOGu7X5gr7KR32BIT4Y/edit?usp=sharing
IIRC, Brian suggested something similar to this earlier and has been
discussed mul
On Mon, Jul 14, 2014 at 5:02 PM, Colin Alworth wrote:
> Sorry for the delay in getting back to you (and to my reviews, got at
> least one up to date now), finally catching up after a few days off.
>
> I guess I was looking for "We want to use Object.create in Core" in your
> initial email. If we
I don't think it is a good idea to depend on UmbrellaException from Core.
The simple alternative is to use a custom UncaughtExceptionHandler to
un-stack UmbrellaException and send as separate log entries.
On Fri, Jul 11, 2014 at 6:16 AM, Jens wrote:
> Hi,
>
> In an app we have an UncaughtExcept
At the end of last year, Daniel started to remove IE6/7 specific code from
the SDK and make simplifications based on that; especially for the deferred
bindings. We had some progress on it (see some examples [1]) though there
are still work to do and looking at our plans it doesn't look like we will
On Mon, Jul 7, 2014 at 7:50 AM, Stephen Haberman wrote:
>
> > The point was more about Orkut announcement doesn't change anything
> > and cannot effect the decision from our perspective; as long as the
> > system is running we need to take care of it.
>
> Right, sorry...I thought that the annouce
On Sun, Jul 6, 2014 at 8:05 PM, Stephen Haberman wrote:
>
> > Even Orkut closing the doors, it doesn't mean their code is going away
> > anytime soon :)
>
> You're killing me, Goktug. The backwards compatibility knife had
> already pierced my heart, and this just shimmied it around a bit. :-)
>
>
On Fri, Jul 4, 2014 at 1:58 PM, Thomas Broyer wrote:
> Hi Googlers,
>
> AFAIK, PotentialElement and Renderable were an experiment contributed by
> the team at Orkut. Now that Orkut is closing its doors, what will happen of
> that feature?
>
Even Orkut closing the doors, it doesn't mean their cod
Actually you could see in the demo how I created the HTMLElement.
On Tue, Jul 1, 2014 at 7:28 PM, 'Daniel Kurka' via GWT Contributors <
google-web-toolkit-contributors@googlegroups.com> wrote:
> This was only done in demo code. You will need to rebuild that item from
> scratch.
>
> -Daniel
>
>
>
On Mon, Jun 30, 2014 at 8:46 PM, Colin Alworth wrote:
> Sounds great, but is there a reason that we're now starting at IE9+ and
> not IE10+, thus giving us typed arrays, web workers, web sockets, etc? I
> only ask because the kind of case where you are giving up User (and Widget,
> RPC, Timer, an
We are planning to drop support for IE8 if the application doesn't inherit
c.g.gwt.useragent.UserAgent and hence not have browser permutations.
Nearly all of today's apps inherit User so they will not be affected by
this change. In the future more apps will only inherit Core however they
shouldn't
I don't want to dive into this discussion but for anyone reading this
thread in the future;
Most of the "rebind" packages in GWT are not designed as a public APIs or
built with extensibility in mind; *they are not meant to be extended nor
being maintained across different versions. Things have disa
I looked at the issue tracker.
To give you some background; UiBinder code base is quite complex, has so
many features that it is really hard to maintain. And usually touching one
place can easily break other places, so we usually try to prevent it to
grow organically by all different request flowi
- Manolo
>
>
> On Tue, May 13, 2014 at 9:23 PM, 'Goktug Gokdogan' via GWT Contributors <
> google-web-toolkit-contributors@googlegroups.com> wrote:
>
>> SGTM
>>
>>
>> On Tue, May 13, 2014 at 4:26 AM, Julien Dramaix > > wrote:
>>
>
Just for clarification: HttpThrowableReporter is still not deleted in 2.7;
I'm waiting on what to be decided on the policy.
-- Forwarded message --
From:
Date: Tue, May 13, 2014 at 7:27 PM
Subject: Abridged summary of gwt-steer...@googlegroups.com - 1 update in 1
topic
To: Abridge
> revamp, we could fixe all these problems.
>
> I propose that Manolo (thanks again for the good job) fixes the behavior
> of the menu according to the Goktug second option and then merge his
> patches in order that we can deploy this version in production. This
> version improves a l
On Sat, May 10, 2014 at 8:02 AM, Manuel Carrasco Moñino
wrote:
>
>
>
> On Sat, May 10, 2014 at 2:33 AM, 'Goktug Gokdogan' via GWT Contributors <
> google-web-toolkit-contributors@googlegroups.com> wrote:
>
>> Pretty cool. Thanks for all the work. Also spe
Pretty cool. Thanks for all the work. Also special kudos for fixing the
styling for download page, it is much more elegant now!
Footer:
- We are now missing the extra space in the bottom of the pages (the one
before the footer)
- The area for the footer is larger and the text is closer to the bo
Looks better; thanks for the work.
Some suggestions:
- Removes the versions submenu from Downloads as it is already included as
a link from Downloads page.
- Move GWT surveys under resources
- Perhaps we can group Making GWT Better, Life of an Issue, Steering
Committee under a submenu
- Releas
On Tue, Apr 22, 2014 at 2:28 PM, 'John Stalcup ' via
GWT Contributors wrote:
> If you're depending directly on anything (in this case DOM) then that
> thing needs to be separately compilable. Which means it's .gwt.xml file
> needs to *not* be marked with type=fileset at the top.
>
> If you look a
201 - 284 of 284 matches
Mail list logo
