Re: Can we use multiple mvp using single Entry point.
This may or may not be relevant for your particular use-case, but have a look at slotted https://code.google.com/p/slotted/. For us, it picks up where Activities and Places leaves off. -- 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: Emulation for java.io
Hi Thomas, Side note: I love that you're so active on this forum. Keep up the great work. Refactoring, of course, is ideal when possible. However, refactoring is not always an option. Who among us hasn't had to rely on code that we don't control or own? The pieces of code we would like to use client-side fall into that category. The performance issue you mentioned, for us a least, would be a welcome change over the long-term headache of maintaining wrappers/parallel classes/parallel hierarchies/etc. Proposal: Can we just hire Thomas Broyer, the man himself, to code up a super-source drop in replacement for java.io? That way: GWT remains unsullied, we're headache-free, and Thomas buys something nice for his SO. -- 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/groups/opt_out.
Emulation for java.io
The only related issuehttps://code.google.com/p/google-web-toolkit/issues/detail?id=604I could find about this was originally slated to be included as far back as GWT *1*.*4*, but still hasn't made it in. (https://code.google.com/p/google-web-toolkit/issues/detail?id=604) *What would it take for GWT to emulate InputStream/OutputStream/ByteArrayInputStream/ByteArrayOutputStream, etc?* Naturally, FileInputStream/FileOuputStream are out of the question, but having much of the rest of java.io available client-side would be very useful. It would also help for certain cases where duplicate code must be maintained for the client-side, as well as the server-side, just to avoid such emulation issues. Nobody likes having to maintain duplicate code. -- 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/groups/opt_out.
Re: Protocol Buffers for GWT: Issue 2649
Our team is revisiting this issue again in hopes that some lateral (i.e. non-reflection) workarounds could be added to GWT 2.6.1 or GWT 3.0. In particular, the original problem with protobuf-generated Java classes is that Reflection isn't emulated in GWT. I admit that emulating reflection is of dubious value, at best. *However*, it turns out this can be side-stepped by compiling with the LITE_RUNTIME flag, which excludes reflection code, solving 80% of the problem. The next problem has to do with very common classes/methods that are not emulated by GWT, but *reasonably* could be. These include parts of java.io.* (Issue 604https://code.google.com/p/google-web-toolkit/issues/detail?id=604), String.format (Issue 3945https://code.google.com/p/google-web-toolkit/issues/detail?id=3945), and a few others (try compiling the attached .proto file into Java). Adding emulation for these would be very beneficial far beyond just protocol buffers. What would it take to get these side-issues included in 2.6.1/3.0 ? -- 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/groups/opt_out. GWTCompatibilityTest1.proto Description: Binary data
Re: Activities and Places, how to deal with nested views ?
Also check out Slotted to see if it fits your needs. https://code.google.com/p/slotted/ -- 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/groups/opt_out.
Re: Overuse of AssumedStale Issue Tag
Hi David and Ed and Jim, Thanks for chiming in. I'm glad I'm not alone. I completely agree that bugs should come first, period. That goes without saying. My previous question about weighing by stars was intended to be specific to enhancements and feature requests. You're right, bugs should never be weighed by stars. I think GWT is going through some growing pains right now, and I feel this is exactly the kind of discussion that needs to happen. All the better that Daniel K. and Thomas B. are chiming in as well. David, I saw your recent commenthttp://code.google.com/p/google-web-toolkit/issues/detail?id=1328#c11in issue 1328 http://code.google.com/p/google-web-toolkit/issues/detail?id=1328#c11, and you made some very good points. In particular, you reminded me that many GWT users (probably the vast majority) are working in the corporate sector and need GWT to be a professional-grade tool. I can also relate to your point about having to come up with a workaround, and then not being able to contribute it back. I'll probably post back here with your full comment. Thomas, thanks for your in-depth response. That was very thorough. I intended my questions to be more general though (I was just citing the top open issues as an example). After bugs, which come first, does the Steering Committee have some set protocol for triaging issues (questions 1 3, above)? And a follow-up question: Making GWT more maintainable makes perfect sense, so I understand the need to modularize GWT by externalizing several components. *But*, does that also imply that the Steering Committee as a whole would be effectively washing its hands of any responsibility to externalized components? By the way, I do want to give props to Daniel and Thomas for entering the discussion so quickly. It's a nice change from the AppEngine forum where we often feel left in the dark. -- 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?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
Re: Overuse of AssumedStale Issue Tag
Posting David's comment (in blue) from Issue 1328https://code.google.com/p/google-web-toolkit/issues/detail?id=1328#c11 : #8 [Issue marked as AssumedStale] #9 (*David*) Hey, why make this stale? When you are using IFrames in applications you really need more events than GWT is offering. #10 (*Thomas*) ... and yet, in almost 6 years: * only 9 people starred the issue * no one provided a patch * the issue hasn't been updated for years... If you provide a patch, we'll gladly review it and update the issue status accordingly. #11 (*David*) - The only bugs that reach 100+ votes are probably critical bugs. - This particular bug was accepted, it would have taken a few hours to implement. - In the mean time I obviously already used JSNI to work around the issue, as most people probably did. I am not allowed to contribute this by my employer. - But it is a maintenance problem in bigger projects because we need JSNI tricks to be able to extend existing GWT widgets (the widget designs are very restrictive). So we rather just replace them completely. - In fact people who needed more advanced widgets went for GXT or some other widget set and as a consequence it is normal that these kinds of bugs don't get a lot of exposure. I have been exposed to about 10 large GWT projects at multiple companies and none of them are using the core GWT widgets due to a lack of features. -- 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?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
Overuse of AssumedStale Issue Tag
Recently, I have been getting several email updates about GWT issues that I had starred. The majority of these have been because the issue was tagged as AssumedStale. I fully understand the need for such a tag, but I think it has been overused in a few cases to the point of abuse. Specifically: I noticed that some issues tagged as Accepted (or at least Planned), are now listed as AssumedStale. I think that's taking it a bit too far. My interpretation here is that the aforementioned Accepted issues are no longer going to make into GWT. Have I misunderstood the situation? If not, is anyone else concerned about this? -- 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?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
Re: Overuse of AssumedStale Issue Tag
Hi Daniel, Thanks for taking the time to respond. I watched your IO video. Great job btw, and congrats on your new position at Google. I completely understand the need to clean out the issue tracker. It has certainly been neglected over the years. My primary concern over all else is for Accepted issues in general. Presumably these were issues that other Google engineers felt were important enough to mark for inclusion into GWT. I understand now that GWT has the Steering Committee guiding it, certain priorities may have changed. That's fine, I accept that! However, as GWT continues to evolve, three questions come to mind: 1) Other than age, is there any other criteria for marking an Accepted/Planned issue as stale? 2) Moving forward, can we assume that any *newly* Accepted issues will be tackled in a reasonable time frame (i.e. not still floating around in 2016)? 3) How much weight does the Steering Committee give to heavily starred issues (i.e. the kind that are too large for individuals to tackle)? The top three open issues are: java.util.Calendar emulationhttp://code.google.com/p/google-web-toolkit/issues/detail?id=603(483 stars) WebSockets for RequestFactoryhttp://code.google.com/p/google-web-toolkit/issues/detail?id=267(218 stars) GWT-compatible Protocol Buffer Compilerhttp://code.google.com/p/google-web-toolkit/issues/detail?id=2649(164 stars) -- start with this one! Again, thanks for taking the time to respond. -- 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?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
Re: How to override gwt styles in uibinder?
Hi Thomas, In your post above you mention @external .gwt-*;. You also use the same trick in thishttp://stackoverflow.com/questions/8182917/how-to-override-default-css-in-modern-gwt-applications StackOverflow question. But, I have never been able to make that work. Instead I have to have @external for every gwt type that I need to override, which is quite a hassle. (Note: in your post above you don't have the leading period. I have tried it both ways just to be sure.) When I try to use @external .gwt-*; I get errors of this flavor: [ERROR] Line 69: The annotation @CssResource.ClassName is disallowed for this location [ERROR] Line 70: Syntax error on token *, delete this token The generated lines in question look like this: @ClassName(gwt-*) String gwt*(); Am I doing something wrong? -- 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?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
Re: Slotted - A Slot/Nesting Extension to Activities and Places
Fantastic. Thank you! -- 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?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
Re: Slotted - A Slot/Nesting Extension to Activities and Places
Great, thank you! v2 sounds like exactly what we need. Do you have any estimate about when you might release v2? -- 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?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
Re: Slotted - A Slot/Nesting Extension to Activities and Places
Hello, Slotted looks very promising. I have a question regarding bookmarking and URLs. Does Slotted have a built-in way of representing nested activities/places? Specifically, I would like to be able to include in the bookmark the current state of all nested activities. I was going to implement this myself, but if Slotted can help here I'll just use that instead. Also, how well does Slotted lend itself to code-splitting? Thanks. -- 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?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
Re: Replacing classes during custom serialization
This is slightly OT but... Thomas, do you think it would be possible to use a custom serialization approach server-side to translate protocol buffers on the fly to/from parallel GWT classes? Our situation is this: We have lots of protocol buffer definitions that we pass around between AppEngine, Android, iOS, and WP8. Since GWT doesn't have PB support yet, we maintain parallel classes specifically for GWT and already perform a lot of switch on type and translation on the server. It's ugly but we have it working. I feel as though custom serialization might be able to offer a slightly cleaner approach for switching between GWT and PB types. Your thoughts? -- 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?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
Re: Protocol Buffers for GWT: Issue 2649
Hi Goktug and Thomas, Thank you for your responses. Thomas, I recognize your name immediately. Goktug, I see that you are also a member of the GWT team. Obviously, you are both in a position to know how this feature would best be implemented. If you say that it is better for Protocol Buffer support to be external to GWT (rather than directly baked into GWT), then I can accept that at face value. In either case, we need a solution that we know will be actively maintained by Google. Currently, we are developing an educational platform (Android client, iOS client, and GWT web client, hosted on AppEngine) using grants from the National Science Foundation, and *from Google itself*. We were contacted by Sprint and may partner with them for a large scale (mobile client) deployment of our platform to classrooms here in the United States. As new features and bugfixes are added to the protobufhttp://code.google.com/p/protobuf/project, we need to know that Protocol Buffer support for GWT will stay current, for the sake of the teachers and parents that will depend on our web client. We use Protocol Buffers directly in Android, iOS, and AppEngine. But currently, we are stuck maintaining a parallel set of GWT-compatible classes that are translated from Protocol Buffers in AppEngine before being sent to the GWT web client, and vice versa. This is quite cumbersome and will only get worse as we continue development. Naturally, the ideal situation is that the GWT web client can handle the exact same Protocol Buffers that the mobile clients already send and receive. No manual translation in the middle. Thomas, I really like your suggestion about using TypedArrays (in browsers that support them) for binary serialization/deserialization, which makes perfect sense since we are dealing with Protocol Buffers. If requiring our users to have only up-to-date modern browsers is the tradeoff, then that is a *small* price to pay. We'll take it. Thank you again for your responses. -- You received this message because you are subscribed to the Google Groups Google Web Toolkit group. To view this discussion on the web visit https://groups.google.com/d/msg/google-web-toolkit/-/dzmtR7MOvW8J. To post to this group, send email to google-web-toolkit@googlegroups.com. To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
Re: Protocol Buffers for GWT: Issue 2649
Hi Andrea, Thanks for the interest, and for your thoughtful post! Given our particular requirements, the reason we ruled out protostuff and protobuf-gwt is that we need something officially supported by Google. I saw from the GWT Wishlist that we are not the only ones waiting for baked-in Protocol Buffer support in GWT. My hope is that the Protobuf Team would pick up where the GWT Team left off. *Or, perhaps Vaadin and Sencha can make this happen now that they are part of the steering committee.* Our project spans both mobile and web. We have native Android clients, native iOS clients, and GWT web clients, all serviced by AppEngine. Protocol Buffers fit our needs perfectly!... except for the glaring lack of official support in GWT. -- You received this message because you are subscribed to the Google Groups Google Web Toolkit group. To view this discussion on the web visit https://groups.google.com/d/msg/google-web-toolkit/-/TLrs8fTM9p4J. To post to this group, send email to google-web-toolkit@googlegroups.com. To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
Protocol Buffers for GWT: Issue 2649
For those of you still waiting for Issue 2649http://code.google.com/p/google-web-toolkit/issues/detail?id=2649 to be completed, I opened a parallel feature request on the Protocol Buffers issue tracker (Issue 431http://code.google.com/p/protobuf/issues/detail?id=431). Be sure to star both issues. Hopefully, the missing feature will be completed soon - it has been 4+ years since the original request. -- You received this message because you are subscribed to the Google Groups Google Web Toolkit group. To view this discussion on the web visit https://groups.google.com/d/msg/google-web-toolkit/-/HVLSlmtgJjEJ. To post to this group, send email to google-web-toolkit@googlegroups.com. To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
Re: Wishlist - What GWT developers want for Christmas
Hello Joonas, Thanks for your work on the report and for posting the wishlist. While I agree with the previous post that the majority of the 2,600 wishlist items are duplicates, there are several other valid items buried in the middle or near bottom of the list, which were not covered in the report. At the moment, these are not getting much attention because most voters stop looking after the first 50 or so items. For example, I found comments from a number of members about bugs that don't get fixed (e.g. some are even 2-3 years old), and patches that don't get accepted. I also saw some very important comments about how GWT needs to be better marketed/publicized in order to attract more developers. I suspect that issues like these would get much more up-voting if they were more visible. Perhaps a member of the community (me, for example) could volunteer to remove duplicates, or perhaps the list could be randomized every time it's viewed. Anything to make sure *all* the important issues get attention. On a separate note, I think even more members might log in and vote if not for the Access-to-Contacts requirement. Thanks again. -- You received this message because you are subscribed to the Google Groups Google Web Toolkit group. To view this discussion on the web visit https://groups.google.com/d/msg/google-web-toolkit/-/cs6_jnGWLbIJ. To post to this group, send email to google-web-toolkit@googlegroups.com. To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
Re: History.newItem() not working in IE
Just after posting this message I found the solution! It seems that IE cant find the iframe if it is not the first element of the page. The problem was the script file (LfwMapKeys.js) being included in the HEAD section of the html. I moved it to the BODY section, just after the iframe declaration and now the history in IE is working fine. On 22/08/2011 20:49, Cerávolo wrote: Hi. When I call History.newItem() in my application, the URL on the address bar doesn't get updated with the new history token, and neither the history is created on the browser (if I click back, it get out of my application). This is only happenning in Internet Explorer (tested with IE 8). In FF it works properly. Debugging, I found that the calling of HistoryImplIE6.findHistoryFrame() is returning NULL, so the History control is not initialized by GWT. Am I missing something? Below is the host hmlt file: !DOCTYPE HTML PUBLIC -//W3C//DTD HTML 4.01 Transitional//EN meta http-equiv=content-type content=text/html; charset=UTF-8 html head script type=text/javascript language=javascript src=lfwshowcase/LfwMapKeys.js/script titleLFW Showcase/title link rel=stylesheet href=LfwShowcase.css /head body iframe id=__gwt_historyFrame style=width:0;height:0;border:0/ iframe script var isomorphicDir = lfwshowcase/sc/; /script script type=text/javascript language=javascript src=lfwshowcase/lfwshowcase.nocache.js/script /body /html -- You received this message because you are subscribed to the Google Groups Google Web Toolkit group. To post to this group, send email to google-web-toolkit@googlegroups.com. To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
