Connect client gwt with server external.... help
hi, I write because I am developing a connection that allows communication between me gwt gwt client and an external server and I've already failed RPC requests and HTTP communication and works well when working on the same project. But now I want to implement the project on a local client and can connect to the server developed in another project. I've done everything but I get this to work. I hope I can count on your help. Thank you very much. -- You received this message because you are subscribed to the Google Groups Google Web Toolkit group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit+unsubscr...@googlegroups.com. To post to this group, send email to google-web-toolkit@googlegroups.com. Visit this group at http://groups.google.com/group/google-web-toolkit. For more options, visit https://groups.google.com/d/optout.
Re: Connect client gwt with server external.... help
Did you enable CORS? On 29 October 2014 00:56, carlos espitia cmaur...@gmail.com wrote: hi, I write because I am developing a connection that allows communication between me gwt gwt client and an external server and I've already failed RPC requests and HTTP communication and works well when working on the same project. But now I want to implement the project on a local client and can connect to the server developed in another project. I've done everything but I get this to work. I hope I can count on your help. Thank you very much. -- You received this message because you are subscribed to the Google Groups Google Web Toolkit group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit+unsubscr...@googlegroups.com. To post to this group, send email to google-web-toolkit@googlegroups.com. Visit this group at http://groups.google.com/group/google-web-toolkit. For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups Google Web Toolkit group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit+unsubscr...@googlegroups.com. To post to this group, send email to google-web-toolkit@googlegroups.com. Visit this group at http://groups.google.com/group/google-web-toolkit. For more options, visit https://groups.google.com/d/optout.
Re: Image and ImageElement
Because the API I am using has a loader class that gives me an ImageElement, not an Image. I have similar queries on that API's board ( MGWT, BTW ), trying to figure out why the API gives me a seemingly useless ImageElement. I think the loader is meant to make things more friendly for mobile devices, which is why I was using it. That said, until I figure out this loader, I am just calling Image directly with the URL in question. On Wednesday, October 29, 2014 12:15:58 AM UTC-4, Donald Mteka wrote: The wrap methods expect an element that is already attached to the dom. In your case, why not create the Image widget directly? On Oct 28, 2014 8:14 PM, Tony B tbald...@wmsvision.com javascript: wrote: Tried that - got assert error on assert Document.get().getBody().isOrHasChild(element); at start of wrap method ( see my other post here https://groups.google.com/forum/?fromgroups#!topic/google-web-toolkit/CACHoELySTI for a post on this topic ). The wrap method not working is part of the reason why I am so confused as it is the most logical solution. On Tuesday, October 28, 2014 1:03:25 PM UTC-4, Jens wrote: Image.wrap(ImageElement) -- J. -- You received this message because you are subscribed to the Google Groups Google Web Toolkit group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit+unsubscr...@googlegroups.com. To post to this group, send email to google-web-toolkit@googlegroups.com. Visit this group at http://groups.google.com/group/google-web-toolkit. For more options, visit https://groups.google.com/d/optout.
Can not see GWT webpage
Hello, I made a GWT client using Eclipse and I have been able to test and see on my Chrome. However, today Chrome shows me a page saying Download the GWT Developer Plugin For Chrome. https://lh4.googleusercontent.com/-ZHKoYCiZ5Yc/VFEjc90TFOI/AWk/M93-LAPholA/s1600/plugin.1.png What happened? When I click on the blue area. It opens a page like this: https://lh3.googleusercontent.com/-p2NkILsILsE/VFEjms0rrgI/AWs/kvNY3ftZakE/s1600/plugin.png in which I cannot see how to download the plugin. Those textfields and buttons are not enabled. Do I do anything wrong? How to I see my web page on Chrome? Thanks, Larry -- You received this message because you are subscribed to the Google Groups Google Web Toolkit group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit+unsubscr...@googlegroups.com. To post to this group, send email to google-web-toolkit@googlegroups.com. Visit this group at http://groups.google.com/group/google-web-toolkit. For more options, visit https://groups.google.com/d/optout.
GWT 2.7.0 RC1 available
Hi all, I just build the GWT 2.7.0 RC1 and pushed it to maven central. The complete SDK is also available from here http://goo.gl/npqEUR. Please start testing and let us know if you run into any trouble. You can either reply to this thread on gwt-contrib https://groups.google.com/forum/#!forum/google-web-toolkit-contributors or file a bug https://code.google.com/p/google-web-toolkit/issues/entry. We are planing to release this as GWT 2.7.0 if we do not here about any serious issues within the next two weeks. The release notes http://www.gwtproject.org/release-notes.html#Release_Notes_2_7_0_RC1 for RC1 will be made available shortly after this notice, in the mean time you can take a look at the review for the release notes https://gwt-review.googlesource.com/#/c/10031/. Daniel, on behalf of the GWT team -- You received this message because you are subscribed to the Google Groups Google Web Toolkit group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit+unsubscr...@googlegroups.com. To post to this group, send email to google-web-toolkit@googlegroups.com. Visit this group at http://groups.google.com/group/google-web-toolkit. For more options, visit https://groups.google.com/d/optout.
[gwt-contrib] RichTextToolbar Widget in GWT?
Hi, Do we have built In RichTextToolbar widget in GWT? -- You received this message because you are subscribed to the Google Groups GWT Contributors group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/b2132e01-4634-4a1a-9147-2d6c1b235d31%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[gwt-contrib] Cell widgets and GSS
Now that GSS will be shipped in GWT 2.7 as an experimental feature, I'm
wondering if we shouldn't provide GSS files for all existing CssResource
interfaces present in GWT. The idea is to keep the associated .css files
and use them by default but also to provide GSS files in order that people
can use GSS to style their widgets.
Let take the cell widgets (CelTable, CellList...) as example. If you want
to override default style, you do something like:
public interface TableResources extends CellTable.Resources {
interface Style extends CellTable.Style {
}
@Override
@Source({ CellTable.Style.DEFAULT_CSS, css/table.css})
Style cellTableStyle();
}
In this case, it's impossible to use GSS because you cannot mix .css and
.gss files on the same resource. So the only mean to use GSS is to first
convert manually the default css file to gss and include it in your
application or start from scratch.
So I would like that GWT provides these gss files that user can use in
their @Source annotations in order to override the default style.
What do you guys think ?
Julien
--
You received this message because you are subscribed to the Google Groups GWT
Contributors group.
To unsubscribe from this group and stop receiving emails from it, send an email
to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/google-web-toolkit-contributors/CABb_3%3D6To8pLn%3D0EmgLRQdByrx_m0-CURafkr7FhZRMwxGXbqg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
Re: [gwt-contrib] GWT 2.7 JsInterop Handle static JavaScript Functions
@Ray Cromwell thank you for your answer. One last question regarding the
creation of JSInterop objects.
Is it @JsType(prototype=SomeJsObject) or
@JsType(prototype=$wnd.SomeJsObject) ?
Consider an interface
@JsType
interface Test {
void do();
}
How do I instantiate such an interface? The only way I see is be using a
static inner class on the interface which contains a static JSNI method
that returns a new instance. This seems to be a little bit complicated. Is
this the correct way to do?
Am Dienstag, 28. Oktober 2014 19:37:15 UTC+1 schrieb Ray Cromwell:
@JsType(prototype=Window) means that x instanceof Window will return
false if the underlying object isn't a Window. That is, the GWT compiler
generates a JS instanceof operator with the specified prototype.
Otherwise, @JsType interfaces are treated like JavaScriptObject overlay
types as far as castability/instanceof is concerned.
isNative is just documentation for now, but says that the underlying
prototype is a browser built-in as opposed to a hand written user supplied
JS prototype. Native prototypes have restrictions that pure-JS ones don't.
@JsType(prototype=...) will also trigger an annotation processor in the
future that generates a stub _Prototype for extending, e.g.
@JsType(prototype=HTMLDivElement)
interface HTMLDivElement extends HTMLElement { ... }
will generate a
@PrototypeOfJsType(HTMLDivElement.class)
class HtmlDivElement_Prototype extends HTMLElement_Prototype { ... }
This makes it possible to subclass JS objects, e.g.
class MyDivElement extends HTMLDivElement_Prototype { ... }
On Tue Oct 28 2014 at 9:17:55 AM confile michael@googlemail.com
javascript: wrote:
Okay great. But what is the difference between the following?
*@JsType(prototype=Window**)* and *@JsType *
Also could you please explain when to use isNative = true?
Am Dienstag, 28. Oktober 2014 17:06:47 UTC+1 schrieb Ray Cromwell:
GWT.create() doesn't work to create Js interfaces. It's part of the
GWT deferred binding system and can only be bound to concrete Java
subtypes. (GWT.create uses the 'new' operator)
JsInterop is going to move towards Java8 syntax for the use case you
describe, e.g
@JsType
interface Window {
static Window get() { return js(window); }
}
On Tue, Oct 28, 2014 at 8:33 AM, confile
michael@googlemail.com wrote:
What is the difference in using the following?
@JsType(prototype=Window) and @JsType
It does not become very clear from the documentation.
Here is the interface I implemented:
@JsType(prototype=Window)
public interface MyWindow {
public static abstract class Statics {
public static native MyWindow create() /*-{
var w = $wnd;
return w;
}-*/;
}
void alert(String msg);
}
When I want to use the interface I have to do: MyWindow w =
MyWindow.Statics.create();
I also would expect that the following should work too: MyWindow w =
GWT.create(MyWindow.class);
The compiler throws an error in the later case:
[ERROR] Line 46: Rebind result 'test.client.MyWindow' must be a class
Unification traversed 735 fields and methods and 538 types. 7
are
considered part of the current module and 7 had all of their fields
and
methods traversed.
[ERROR] Compiler returned false
Two questions:
1. When do I use or do I not use the prototype and isNative attribute
of
@JsType?
2. Do I use the correct way to instantiate a JSInterop Interface?
Am Sonntag, 5. Oktober 2014 08:32:26 UTC+2 schrieb Ray Cromwell:
Using default methods in Java8 is exactly how we plan to allow
specifying method bodies without using JSOs. We are also going to
introduce a new annotation, @JsFinal to declare these methods final
(which you can't do on interfaces) to make it a compile time error
for
subclasses to override them.
Why? One of the reasons why JSOs are efficient is that they are not
polymorphic, and essentially turn into static method calls, e.g.
getState() is rewritten as getState(SwitchElement this$static) /*-{
return this$static.bootstrapSwitch(state); }-*/; which is
inlineable by the compiler.
Polymorphic methods are not inlineable and if there is a concrete
implementor, it forces the compiler to insert a trampoline, e.g
.
@JsType
interface JsArrayT {
default T get(int x) { return js(this[$0], x); }
}
If we didn't have @JsFinal, and someone did class Blah implements
JsArray { ... }, it would slow down every single JsArray call in the
entire program, because the compiler has to emit code like this:
jsArray.get ? jsArray.get(i) : this[i];
That is, it has to check to see if the method is implemented and call
it, otherwise fall back to the default.
This is why the full JsInterop will require Java8, because
Re: [gwt-contrib] GWT 2.7 JsInterop Handle static JavaScript Functions
Consider an interface
@JsType
interface Test {
void do();
}
How do I instantiate such an interface?
For now you need to use a JSNI factory method. May it be in a static inner
class or a dedicated factory class for all your JsTypes.
With GWT 3.0 (and Java8 support) you can use a static factory method on the
interface which uses GWT.jsni() or GWT.js() or whatever name that special
GWT method will have. So in GWT 3.0 it will probably look like:
@JsType
interface Test {
static Test create() { return GWT.js(new Test()); }
void do();
}
-- J.
--
You received this message because you are subscribed to the Google Groups GWT
Contributors group.
To unsubscribe from this group and stop receiving emails from it, send an email
to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/google-web-toolkit-contributors/dddf3130-f84a-4003-984f-74d781a8da60%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: [gwt-contrib] GWT 2.7 JsInterop Handle static JavaScript Functions
thank oyu Jens. What about my first question:
Is it @JsType(prototype=SomeJsObject) or
@JsType(prototype=$wnd.SomeJsObject) ?
Best
Michael
Am Mittwoch, 29. Oktober 2014 14:45:33 UTC+1 schrieb Jens:
Consider an interface
@JsType
interface Test {
void do();
}
How do I instantiate such an interface?
For now you need to use a JSNI factory method. May it be in a static inner
class or a dedicated factory class for all your JsTypes.
With GWT 3.0 (and Java8 support) you can use a static factory method on
the interface which uses GWT.jsni() or GWT.js() or whatever name that
special GWT method will have. So in GWT 3.0 it will probably look like:
@JsType
interface Test {
static Test create() { return GWT.js(new Test()); }
void do();
}
-- J.
--
You received this message because you are subscribed to the Google Groups GWT
Contributors group.
To unsubscribe from this group and stop receiving emails from it, send an email
to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/google-web-toolkit-contributors/a8612613-de28-4413-926f-ed97086436fa%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: [gwt-contrib] GWT 2.7 JsInterop Handle static JavaScript Functions
Whether you use $wnd.SomeJsObject or SomeJsObject depends on the following:
1) whether you want 'instanceof' to only work on objects that come
from the host page
2) whether or not you're going to extend/subtype JS objects
In most cases, you want $wnd.SomeJsObject, however there are cases
where you don't
1) if you loaded some hand written JS into 'window' instead of $wnd
2) if you are referring to inbuilt native JS objects like Window or
HTMLDivElement
If you do the following
@JsType(prototype=$wnd.Window)
interface Window {
...
}
Window w = someIframe.window();
Then w instanceof Window = false. Why? Because the GWT compiler will
emit w instanceof $wnd.Window, but your checking for Window objects
from ANY location.
So you see, a prefix of $wnd leads to an ABSOLUTE instanceof operator.
If you don't specify $wnd, then the instanceof check is relative. So
for example, it will just check if your constructor is 'Window', no
matter which context where it came from.
In general, native DOM elements == no $wnd prefix, JS libraries loaded
in host page == $wnd prefix
On Wed, Oct 29, 2014 at 7:04 AM, confile
michael.gorsk...@googlemail.com wrote:
thank oyu Jens. What about my first question:
Is it @JsType(prototype=SomeJsObject) or
@JsType(prototype=$wnd.SomeJsObject) ?
Best
Michael
Am Mittwoch, 29. Oktober 2014 14:45:33 UTC+1 schrieb Jens:
Consider an interface
@JsType
interface Test {
void do();
}
How do I instantiate such an interface?
For now you need to use a JSNI factory method. May it be in a static inner
class or a dedicated factory class for all your JsTypes.
With GWT 3.0 (and Java8 support) you can use a static factory method on
the interface which uses GWT.jsni() or GWT.js() or whatever name that
special GWT method will have. So in GWT 3.0 it will probably look like:
@JsType
interface Test {
static Test create() { return GWT.js(new Test()); }
void do();
}
-- J.
--
You received this message because you are subscribed to the Google Groups
GWT Contributors group.
To unsubscribe from this group and stop receiving emails from it, send an
email to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/google-web-toolkit-contributors/a8612613-de28-4413-926f-ed97086436fa%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups GWT
Contributors group.
To unsubscribe from this group and stop receiving emails from it, send an email
to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/google-web-toolkit-contributors/CAPVRV7fuBJCLq7kpyxjDxTqvPQ_ST-h%3DULprM%3D9K0UVO56FsEA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
Re: [gwt-contrib] Blocking RC1: Fold gwt-codeserver into gwt-dev
On Tuesday, October 28, 2014 9:09:47 PM UTC+1, Brian Slesinsky wrote: Yes, merging the jars should be fine as a short-term fix. Just though that it could break some plugins out there that would expect to find a gwt-codeserver 2.7.0 in Maven Central. For the gwt-maven-plugin, we release a new version for each new version of GWT, so we can adapt. It's a different story for the gwt-gradle-plugin though (it already has to handle the case where gwt-codeserver doesn't exist for pre-2.5 versions of GWT, it'll have to be updated to support GWT 2.7): https://github.com/steffenschaefer/gwt-gradle-plugin/blob/4ecc5b8c022ceaf16b600c4ebaabcf703bd54fd7/gwt-gradle-plugin/src/main/java/de/richsource/gradle/plugins/gwt/GwtBasePlugin.java#L142-L145 Or maybe, for 2.7 we could deploy a dummy gwt-codeserver JAR? (I hate such hacks, but it would give some time for tools out there to adapt; note that for gwt-gradle-plugin, there's a workaround: just declare your GWT dependencies explicitly rather than letting the plugin do it automagically for you) Codeserver should be built as a separate library to enforce that there are no circular dependencies. (We already have one for DevMode -superDevMode but that should be fixed by splitting out DevMode; it doesn't belong in the same library as the compiler.) Long term, we will also want to split gwt-user into multiple jars. It seems like we should either give plugins a way to set up the classpath properly without hard-coding exactly which jars to use, or else plan on building the traditional all-in-one jars when creating the distribution. This is going to be tricky. We want to externalize dependencies to make it easier to handle conflicts with other libs (e.g. using a newer version of Guava) so the all-in-one jar won't work. It's already an issue for some projects (e.g. Gerrit) that don't use the embedded Jetty and don't use GWTTestCase (so they have absolutely no direct dependency on the version of Jetty we bundle) but want to use a newer version of Jetty (through the extension point in DevMode; the same that's used by GAE to plug its own server). BTW, for this use-case, having SuperDevMode being embeddable in a webapp rather than running side-by-side would probably help (Gerrit maintainers would rather have a single process running; maybe they're wrong striving for that) We could use all-in-one jars in the SDK to make classpath management easier, but then IDE plugins would have to do things differently for projects that use the SDK vs. projects that use manage dependencies (Maven, Gradle, Ivy, etc.) Well, they already have to do things differently, so maybe it's a false issue, but still, we probably want to ask IDE plugin maintainers before making a choice. For managed dependencies builds (and some others; e.g. Gerrit with Buck), we'd rather want many small libs so you can cherry-pick only the ones you need, and leave out transitive dependencies that you don't need (e.g. no dependency on HtmlUnit if you don't use GWTTestCase; it could even be optional if you only run your tests in real browsers through Selenium/WebDriver, or with PhantomJS). IDE and build-tools plugins could then quite easily resolve transitive dependencies of the JARs they need (this is what I recently added to the gwt-maven-plugin, which previously assumed GWT JARs had no external dependencies). I believe all builds would benefit from smaller JARs, even if creating your Ant build.xml (for example) and then maintaining it when updating GWT would be harder than it is today (but if you decide to manage your dependencies manually, you know what you sign up for, and the added flexibility of small JARs with external dependencies is probably a good thing in the long run) I don't have an answer for the IDE plugins (when using a downloaded SDK ZIP), but for other tools I think smaller JARs are better, and those tools are built around generating a classpath out of a description of transitive dependencies. For humans (managing dependencies manually), we could probably generate a dependency graph quite easily (the hard part would be to make it straightforward for the people who will update the docs at each release), to help them pick the required and appropriate dependencies for their build. On Tue Oct 28 2014 at 12:03:25 PM 'Daniel Kurka' via GWT Contributors google-web-toolkit-contributors@googlegroups.com wrote: I think moving sources right now is too risky and too much work we should just merge the jars in dist. On Tue, Oct 28, 2014 at 8:02 PM, Thomas Broyer t.bro...@gmail.com wrote: Fine for me. Do you intend to move the sources or just merge the JARs during dist-dev/dist? -- You received this message because you are subscribed to the Google Groups GWT Contributors group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com . To view
Re: [gwt-contrib] Blocking RC1: Fold gwt-codeserver into gwt-dev
It looks like the gwt-codeserver jar will still exist, but the same classes will also be in gwt-dev.jar. So it's ugly but should be backward compatible? - Brian -- You received this message because you are subscribed to the Google Groups GWT Contributors group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/CA%2B%2BRBT9RgArmAq5W2PQJSQvzhp-9HKPTtAX7ypQVRZBGPU159g%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
[gwt-contrib] Certain gwtar files seem to be way too large in GWT 2.7
The increased *.gwtar file size results in a gwt-user.jar which is 80MB in size, up from 29MB. This really hurts when using the SNAPSHOT build of GWT through Maven/Gradle. I guess there is something wrong in the build script and stuff gets repackaged multiple times. GWT 2.7.1: jens-mba:gwt-user-2.7.0-beta1 Jens$ ls -laRh | grep .gwtar -rw-r--r--@ 1 Jens staff 50M 18 Okt 09:16 Activity.gwtar -rw-r--r--@ 1 Jens staff 5,6M 18 Okt 09:16 Core.gwtar -rw-r--r--@ 1 Jens staff 56M 18 Okt 09:16 Debug.gwtar -rw-r--r--@ 1 Jens staff 172K 18 Okt 09:16 JSON.gwtar -rw-r--r--@ 1 Jens staff 57M 18 Okt 09:16 Logging.gwtar -rw-r--r--@ 1 Jens staff 6,0M 18 Okt 09:16 Place.gwtar -rw-r--r--@ 1 Jens staff 42K 18 Okt 09:16 RegExp.gwtar -rw-r--r--@ 1 Jens staff 57M 18 Okt 09:16 User.gwtar -rw-r--r--@ 1 Jens staff 480K 18 Okt 09:16 XML.gwtar -rw-r--r--@ 1 Jens staff 794K 18 Okt 09:16 AutoBean.gwtar -rw-r--r--@ 1 Jens staff 195K 18 Okt 09:16 Event.gwtar -rw-r--r--@ 1 Jens staff 58M 18 Okt 09:16 RequestFactory.gwtar GWT 2.6.1: jens-mba:gwt-user-2.6.1 Jens$ ls -laRh | grep .gwtar -rw-r--r--@ 1 Jens staff 78K 7 Mai 13:59 Activity.gwtar -rw-r--r--@ 1 Jens staff 6,0M 7 Mai 13:59 Core.gwtar -rw-r--r--@ 1 Jens staff 21K 7 Mai 13:59 Debug.gwtar -rw-r--r--@ 1 Jens staff 167K 7 Mai 13:59 JSON.gwtar -rw-r--r--@ 1 Jens staff 299K 7 Mai 13:59 Logging.gwtar -rw-r--r--@ 1 Jens staff 140K 7 Mai 13:59 Place.gwtar -rw-r--r--@ 1 Jens staff 39K 7 Mai 13:59 RegExp.gwtar -rw-r--r--@ 1 Jens staff 551K 7 Mai 13:59 RPC.gwtar -rw-r--r--@ 1 Jens staff 51M 7 Mai 13:59 User.gwtar -rw-r--r--@ 1 Jens staff 443K 7 Mai 13:59 XML.gwtar -rw-r--r--@ 1 Jens staff 753K 7 Mai 13:59 AutoBean.gwtar -rw-r--r--@ 1 Jens staff 189K 7 Mai 13:59 Event.gwtar -rw-r--r--@ 1 Jens staff 1,4M 7 Mai 13:59 RequestFactory.gwtar -- J. -- You received this message because you are subscribed to the Google Groups GWT Contributors group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/eab5ea1c-591b-45df-8b38-fad4b2384329%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[gwt-contrib] Re: Certain gwtar files seem to be way too large in GWT 2.7
I think the problem is that GWT module dependencies have changed due to library compilation constraints (no circular module deps) and the build file has not been updated to reflect that. Would it make sense to have one *.gwtar file per GWT module that is not marked as type=fieldset ? -- J. -- You received this message because you are subscribed to the Google Groups GWT Contributors group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/ad05e8d4-6bf8-4223-bd8a-f24939791ee0%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [gwt-contrib] GWT 2.7 JsInterop Handle static JavaScript Functions
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 michael.gorsk...@googlemail.com
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 Cromwell:
Whether you use $wnd.SomeJsObject or SomeJsObject depends on the
following:
1) whether you want 'instanceof' to only work on objects that come
from the host page
2) whether or not you're going to extend/subtype JS objects
In most cases, you want $wnd.SomeJsObject, however there are cases
where you don't
1) if you loaded some hand written JS into 'window' instead of $wnd
2) if you are referring to inbuilt native JS objects like Window or
HTMLDivElement
If you do the following
@JsType(prototype=$wnd.Window)
interface Window {
...
}
Window w = someIframe.window();
Then w instanceof Window = false. Why? Because the GWT compiler will
emit w instanceof $wnd.Window, but your checking for Window objects
from ANY location.
So you see, a prefix of $wnd leads to an ABSOLUTE instanceof operator.
If you don't specify $wnd, then the instanceof check is relative. So
for example, it will just check if your constructor is 'Window', no
matter which context where it came from.
In general, native DOM elements == no $wnd prefix, JS libraries loaded
in host page == $wnd prefix
On Wed, Oct 29, 2014 at 7:04 AM, confile
michael@googlemail.com wrote:
thank oyu Jens. What about my first question:
Is it @JsType(prototype=SomeJsObject) or
@JsType(prototype=$wnd.SomeJsObject) ?
Best
Michael
Am Mittwoch, 29. Oktober 2014 14:45:33 UTC+1 schrieb Jens:
Consider an interface
@JsType
interface Test {
void do();
}
How do I instantiate such an interface?
For now you need to use a JSNI factory method. May it be in a static
inner
class or a dedicated factory class for all your JsTypes.
With GWT 3.0 (and Java8 support) you can use a static factory method
on
the interface which uses GWT.jsni() or GWT.js() or whatever name that
special GWT method will have. So in GWT 3.0 it will probably look
like:
@JsType
interface Test {
static Test create() { return GWT.js(new Test()); }
void do();
}
-- J.
--
You received this message because you are subscribed to the Google
Groups
GWT Contributors group.
To unsubscribe from this group and stop receiving emails from it, send
an
email to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/google-web-toolkit-
contributors/a8612613-de28-4413-926f-ed97086436fa%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups
GWT Contributors group.
To unsubscribe from this group and stop receiving emails from it, send an
email to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/google-web-toolkit-contributors/89359bef-175d-4a96-9362-787fed32888d%40googlegroups.com
https://groups.google.com/d/msgid/google-web-toolkit-contributors/89359bef-175d-4a96-9362-787fed32888d%40googlegroups.com?utm_medium=emailutm_source=footer
.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups GWT
Contributors group.
To unsubscribe from this group and stop receiving emails from it, send an email
to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/google-web-toolkit-contributors/CAN%3DyUA0g4PrEkz_mm1D1jHiEDxFqt6gYok%3D%3DwjehREsML2ZNyA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
Re: [gwt-contrib] Cell widgets and GSS
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 julien.dram...@gmail.com
wrote:
Now that GSS will be shipped in GWT 2.7 as an experimental feature, I'm
wondering if we shouldn't provide GSS files for all existing CssResource
interfaces present in GWT. The idea is to keep the associated .css files
and use them by default but also to provide GSS files in order that people
can use GSS to style their widgets.
Let take the cell widgets (CelTable, CellList...) as example. If you want
to override default style, you do something like:
public interface TableResources extends CellTable.Resources {
interface Style extends CellTable.Style {
}
@Override
@Source({ CellTable.Style.DEFAULT_CSS, css/table.css})
Style cellTableStyle();
}
In this case, it's impossible to use GSS because you cannot mix .css and
.gss files on the same resource. So the only mean to use GSS is to first
convert manually the default css file to gss and include it in your
application or start from scratch.
So I would like that GWT provides these gss files that user can use in
their @Source annotations in order to override the default style.
What do you guys think ?
Julien
--
You received this message because you are subscribed to the Google Groups
GWT Contributors group.
To unsubscribe from this group and stop receiving emails from it, send an
email to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/google-web-toolkit-contributors/CABb_3%3D6To8pLn%3D0EmgLRQdByrx_m0-CURafkr7FhZRMwxGXbqg%40mail.gmail.com
https://groups.google.com/d/msgid/google-web-toolkit-contributors/CABb_3%3D6To8pLn%3D0EmgLRQdByrx_m0-CURafkr7FhZRMwxGXbqg%40mail.gmail.com?utm_medium=emailutm_source=footer
.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups GWT
Contributors group.
To unsubscribe from this group and stop receiving emails from it, send an email
to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/google-web-toolkit-contributors/CAN%3DyUA3wT52nZHx-9BZ3PcgjXAXMaPQZLdD4gJcnb%2BJpAsOxhw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
Re: [gwt-contrib] Re: Certain gwtar files seem to be way too large in GWT 2.7
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. They are not used within Google and we do not want to maintain them going foward. So I suggest we deprecate them with GWT 2.7 and disable them and remote them going forward. -Daniel On Wed, Oct 29, 2014 at 6:12 PM, Jens jens.nehlme...@gmail.com wrote: I think the problem is that GWT module dependencies have changed due to library compilation constraints (no circular module deps) and the build file has not been updated to reflect that. Would it make sense to have one *.gwtar file per GWT module that is not marked as type=fieldset ? -- J. -- You received this message because you are subscribed to the Google Groups GWT Contributors group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/ad05e8d4-6bf8-4223-bd8a-f24939791ee0%40googlegroups.com https://groups.google.com/d/msgid/google-web-toolkit-contributors/ad05e8d4-6bf8-4223-bd8a-f24939791ee0%40googlegroups.com?utm_medium=emailutm_source=footer . For more options, visit https://groups.google.com/d/optout. -- Google Germany GmbH *Dienerstr. 12* *80331 München* Registergericht und -nummer: Hamburg, HRB 86891 Sitz der Gesellschaft: Hamburg Geschäftsführer: Graham Law, Katherine Stephens -- You received this message because you are subscribed to the Google Groups GWT Contributors group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/CALLujip7WPpMssr5PvM_tGk4dERWZFXUDRvdwmWqKES%2B%3DBSp2Q%40mail.gmail.com https://groups.google.com/d/msgid/google-web-toolkit-contributors/CALLujip7WPpMssr5PvM_tGk4dERWZFXUDRvdwmWqKES%2B%3DBSp2Q%40mail.gmail.com?utm_medium=emailutm_source=footer . For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups GWT Contributors group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/CAN%3DyUA05VLF0sxZ4%2BvFhvFb4MmS3Z9rR7ZM9H6WQ6XiVNnUUqQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
[gwt-contrib] GWT 2.7.0-RC1 is available
Hi all, I just build the GWT 2.7.0 RC1 and pushed it to maven central. The complete SDK is also available from here http://goo.gl/npqEUR. Please start testing and let us know if you run into any trouble. You can either reply to this thread on gwt-contrib https://groups.google.com/forum/#!forum/google-web-toolkit-contributors or file a bug https://code.google.com/p/google-web-toolkit/issues/entry. We are planing to release this as GWT 2.7.0 if we do not here about any serious issues within the next two weeks. The release notes http://www.gwtproject.org/release-notes.html#Release_Notes_2_7_0_RC1 for RC1 will be made available shortly after this notice, in the mean time you can take a look at the review for the release notes https://gwt-review.googlesource.com/#/c/10031/. Daniel, on behalf of the GWT team -- You received this message because you are subscribed to the Google Groups GWT Contributors group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/CALLujioAdKOHQv1nx4%2BSN7Ajj0paortL2ANDzuf_7YAwKzxzOQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: [gwt-contrib] GWT 2.7.0-RC1 is available
When running DevMode (the Swing UI) with gwt-2.7.0-rc1 installed from Maven central, without gwt-codeserver on my classpath, I get: Caused by: java.lang.NoClassDefFoundError: com/google/gwt/dev/util/arg/JsInteropMode at com.google.gwt.dev.codeserver.Options.init(Options.java:79) at com.google.gwt.dev.codeserver.CodeServer.main(CodeServer.java:45) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) Adding the gwt-codeserver jar makes it work, but IIRC we were attempting to make a no gwt-codeserver yet classpath setup work. (I'm not weighing in one way or the other, just reporting results.) - Stephen -- You received this message because you are subscribed to the Google Groups GWT Contributors group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/20141029225313.3555fec5%40sh9. For more options, visit https://groups.google.com/d/optout.
[gwt-contrib] Re: GWT 2.7.0-RC1 is available
I grabbed the RC and switched to use it from my IntelliJ project. When starting my run configuration using SDM, all seems well until the compiler dies (see below). What can I do to provide more information to help track this down? (Sorry, I cannot make the code available...) // Lots and lots of: // Resolving ... //Found type '' // Resolving method ... Finding entry point classes Assimilating generated source Generated source files... com.google.gwt.lang. com_00046ao_00046foo_00046MyGwtModule_00045DEV__EntryMethodHolder Adding '1' new generated units Compiling... Compilation completed in 0.00 seconds Added 1 units to cache since last cleanup. Removing invalidated units Wrote 1 units to persistent cache. [ERROR] Unexpected internal compiler error java.lang.AssertionError at com.google.gwt.dev.jjs.impl.UnifyAst.instantiate(UnifyAst.java:1407) at com.google.gwt.dev.jjs.impl.UnifyAst.instantiate(UnifyAst.java:1414) at com.google.gwt.dev.jjs.impl.UnifyAst.instantiate(UnifyAst.java:1414) at com.google.gwt.dev.jjs.impl.UnifyAst.fullFlowIntoType(UnifyAst.java:1186 ) at com.google.gwt.dev.jjs.impl.UnifyAst.assimilateSourceUnit(UnifyAst.java: 1020) at com.google.gwt.dev.jjs.impl.UnifyAst.internalFindType(UnifyAst.java:1595 ) at com.google.gwt.dev.jjs.impl.UnifyAst.translate(UnifyAst.java:1653) at com.google.gwt.dev.jjs.impl.UnifyAst.translate(UnifyAst.java:1733) at com.google.gwt.dev.jjs.impl.UnifyAst.translate(UnifyAst.java:1747) at com.google.gwt.dev.jjs.impl.UnifyAst.flowInto(UnifyAst.java:1226) at com.google.gwt.dev.jjs.impl.UnifyAst.fullFlowIntoType(UnifyAst.java:1191 ) at com.google.gwt.dev.jjs.impl.UnifyAst.assimilateSourceUnit(UnifyAst.java: 1020) at com.google.gwt.dev.jjs.impl.UnifyAst.internalFindType(UnifyAst.java:1595 ) at com.google.gwt.dev.jjs.impl.UnifyAst.translate(UnifyAst.java:1653) at com.google.gwt.dev.jjs.impl.UnifyAst.translate(UnifyAst.java:1733) at com.google.gwt.dev.jjs.impl.UnifyAst.translate(UnifyAst.java:1747) at com.google.gwt.dev.jjs.impl.UnifyAst.flowInto(UnifyAst.java:1226) at com.google.gwt.dev.jjs.impl.UnifyAst.fullFlowIntoType(UnifyAst.java:1191 ) at com.google.gwt.dev.jjs.impl.UnifyAst.assimilateSourceUnit(UnifyAst.java: 1020) at com.google.gwt.dev.jjs.impl.UnifyAst.internalFindType(UnifyAst.java:1595 ) at com.google.gwt.dev.jjs.impl.UnifyAst.translate(UnifyAst.java:1653) at com.google.gwt.dev.jjs.impl.UnifyAst.translate(UnifyAst.java:1645) at com.google.gwt.dev.jjs.impl.UnifyAst.resolveType(UnifyAst.java:1552) at com.google.gwt.dev.jjs.impl.UnifyAst.assimilateSourceUnit(UnifyAst.java: 1010) at com.google.gwt.dev.jjs.impl.UnifyAst.internalFindType(UnifyAst.java:1595 ) at com.google.gwt.dev.jjs.impl.UnifyAst.translate(UnifyAst.java:1653) at com.google.gwt.dev.jjs.impl.UnifyAst.translate(UnifyAst.java:1733) at com.google.gwt.dev.jjs.impl.UnifyAst.translate(UnifyAst.java:1747) at com.google.gwt.dev.jjs.impl.UnifyAst.flowInto(UnifyAst.java:1206) at com.google.gwt.dev.jjs.impl.UnifyAst.fullFlowIntoType(UnifyAst.java:1188 ) at com.google.gwt.dev.jjs.impl.UnifyAst.assimilateSourceUnit(UnifyAst.java: 1020) at com.google.gwt.dev.jjs.impl.UnifyAst.internalFindType(UnifyAst.java:1595 ) at com.google.gwt.dev.jjs.impl.UnifyAst.translate(UnifyAst.java:1653) at com.google.gwt.dev.jjs.impl.UnifyAst.translate(UnifyAst.java:1645) at com.google.gwt.dev.jjs.impl.UnifyAst.resolveType(UnifyAst.java:1552) at com.google.gwt.dev.jjs.impl.UnifyAst.assimilateSourceUnit(UnifyAst.java: 1010) at com.google.gwt.dev.jjs.impl.UnifyAst.internalFindType(UnifyAst.java:1595 ) at com.google.gwt.dev.jjs.impl.UnifyAst.translate(UnifyAst.java:1653) at com.google.gwt.dev.jjs.impl.UnifyAst.translate(UnifyAst.java:1645) at com.google.gwt.dev.jjs.impl.UnifyAst.resolveType(UnifyAst.java:1552) at com.google.gwt.dev.jjs.impl.UnifyAst.assimilateSourceUnit(UnifyAst.java: 1010) at com.google.gwt.dev.jjs.impl.UnifyAst.internalFindType(UnifyAst.java:1595 ) at com.google.gwt.dev.jjs.impl.UnifyAst.translate(UnifyAst.java:1653) at com.google.gwt.dev.jjs.impl.UnifyAst.translate(UnifyAst.java:1645) at com.google.gwt.dev.jjs.impl.UnifyAst.resolveType(UnifyAst.java:1552) at com.google.gwt.dev.jjs.impl.UnifyAst.assimilateSourceUnit(UnifyAst.java: 1010) at com.google.gwt.dev.jjs.impl.UnifyAst.internalFindType(UnifyAst.java:1595 ) at com.google.gwt.dev.jjs.impl.UnifyAst.translate(UnifyAst.java:1653) at com.google.gwt.dev.jjs.impl.UnifyAst.translate(UnifyAst.java:1645) at com.google.gwt.dev.jjs.impl.UnifyAst.resolveType(UnifyAst.java:1552) at com.google.gwt.dev.jjs.impl.UnifyAst.assimilateSourceUnit(UnifyAst.java: 1010) at com.google.gwt.dev.jjs.impl.UnifyAst.internalFindType(UnifyAst.java:1595 ) at com.google.gwt.dev.jjs.impl.UnifyAst.translate(UnifyAst.java:1653) at com.google.gwt.dev.jjs.impl.UnifyAst.translate(UnifyAst.java:1645) at
