how to make a clickable image cell?
I want to make a column of clickable image inside a celltable, if user click the image, a new tab page is created. the problem is how to make such a clickable image cell column? -- 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/-/VprB67tD7VYJ. 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: how to make a clickable image cell?
Should be possible with ActionCell or ButtonCell. The image could be easily
added via render method. look at examples on gwt showcase like
thishttp://gwt.google.com/samples/Showcase/Showcase.html#!CwCellList
.
An image could be added to every kind of cell i think (from example):
String imageHtml = AbstractImagePrototype.create(image).getHTML();
...
@Override
public void render(Context context, ContactInfo value, SafeHtmlBuilder sb) {
// Value can be null, so do a null check..
if (value == null) {
return;
}
// Add the contact image.
sb.appendHtmlConstant(trtd rowspan='3');
sb.appendHtmlConstant(imageHtml);
sb.appendHtmlConstant(/td);
...
On Thursday, 19 April 2012 09:45:40 UTC+2, tong123123 wrote:
I want to make a column of clickable image inside a celltable, if user
click the image, a new tab page is created.
the problem is how to make such a clickable image cell column?
--
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/-/rHzpUQ2lUOQJ.
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: how to make a clickable image cell?
On Thursday, April 19, 2012 9:45:40 AM UTC+2, tong123123 wrote: I want to make a column of clickable image inside a celltable, if user click the image, a new tab page is created. the problem is how to make such a clickable image cell column? How about https://www.google.fr/search?q=clickable+ImageCell ? -- 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/-/sGcIFb4U9XIJ. 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: Call for action: Time to rethink a road-map and more frequent updates for GWT.
+1 On Wednesday, April 18, 2012 4:48:52 AM UTC+8, emurmur wrote: I'm one of the fence sitters. I have been using Flex/Flash, which has been fantastic, but has no future on the mobile web. I think there are only two mature tools that would allow me to create similarly rich applications; GWT and Closure Tools. Google has decided that Javascript won't cut it for their own future products, even though they are heavily invested in Closure Tools. I agree completely. It is important to understand that they have also decided NOT to move everything to GWT. This makes some sense, given that the owner of Java is suing them. I think this is in no way a reflection on GWT as a tool and technology. So Google has decided to move forward with a third initiative designed, in part, to replace GWT and Closure Tools at Google. So, I look at that and I am worried about long-term support for GWT. I think that is a reasonable concern. This concern is mitigated by the fact that GWT is a fully open-source project. Flex/Flash on mobile browsers _was_ fully supported and look how that turned out. So, corporate support is no guarantee; open source is actually a safer bet. However, I would feel a lot better if I had an official roadmap for GWT. That being said, Ray's comments on what is coming are heartening. The biggest worry I have for GWT, if Google stops directly supporting it, is the debug environment. The plugin seems to need a lot of maintenance because the browsers are moving so fast. The upcoming support for source-maps mitigates this; I would feel better if I did not have to rely on a plugin. I've been working with Dart quite a bit and it is really promising. However, integration with other Javascript environments is problematic. For instance, Dart integration with PhoneGap does not exist and appears to be very challenging (some have tried and decided to pass on it). This is a non-starter for me. I want to use the mobile web, but I also want the flexibility of providing an app if my customers want one. For now, Dart can't do that. This may also be a problem when trying to integrate a Dart app into Windows 8 Metro. GWT is far superior in this regard; it has a nice architecture for integrating with Javascript and many useful implementations, including a couple for PhoneGap. I'm hoping Javascript integration will be addressed in the future, but Dart is still in alpha and the team is working on core features at least until the language gets to 1.0. Also, because Dart is so young, the tooling cannot compare to Java tooling. This will improve, but Java has many years head start. The Dart team is amazing and I am sure they are creating something very important; I just wish they were 2 more years along. My window for fence sitting is closing fast. I will have to make a decision. GWT and Dart are the only real contenders. As of now, I think GWT is the best choice, but I would sleep better at night if I had a roadmap under my pillow. On Apr 13, 7:34 am, Blake McBride blake1...@gmail.com wrote: I strongly disagree with this. First of all browser technology and HTML are in constant flux. If GWT is not updated, it will very soon become out-of-date (bugs in new browsers) and unusable (reliably usable over a broad base of browsers and platforms). Secondly, building apps with GWT is a full time job. Having to understand and maintain GWT makes two full time jobs. Building GWT apps could easily be a multi-million dollar effort - and so could maintaining GWT. This is a huge, huge risk! Another issue I've seen this many times before. When Windows became popular, many developer tools appeared. Many were quite good. IMO, the worst development environment by far was Microsoft's MFC. Virtually all of the other tools either sold out or got dropped. Management often chose MFC over other tool because they were non-technical and the old IBM adage applied to Microsoft no one ever lost their job by selecting Microsoft ruled. In the end, the industry largely settled on the absolute lowest common denominator. Innovation in that area, for all practical purposes, is dead. Now we have ASP, JSP, and other popular mashups out there. I am utterly shocked how poor they are (although to their credit, they are trying to solve practical problems given an environment that was clearly not meant to support what they are attempting!). These environments are among the worst I've ever seen. It's one kludgy work around after another with three totally different environments attempting to interact. GWT goes a very long way to solve this very significant problem. However, GWT is a total waste of time if you risk your entire company on it and it gets dropped. In terms of financial risk, very unfortunately, tool popularity and support
Error when trying to create HTML in GWT2.4
Hi I'm trying to create HTML page and I get an error : Unhandled event Loop exception. I need help to fix this problem. Thks -- 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.
Re: Error when trying to create HTML in GWT2.4
On Thu, Apr 19, 2012 at 23:02, SCK guyedj...@gmail.com wrote: Hi I'm trying to create HTML page and I get an error : Unhandled event Loop exception. I need help to fix this problem. Thks How about a minimal code snippet to reproduce the problem? -- 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.
Re: Error when trying to create HTML in GWT2.4
There is an issue for it on the issue tracker: http://code.google.com/p/google-web-toolkit/issues/detail?id=6338 I also had this problem but with the most recent Eclipse (Indigo Service Release 2) and GWT Plugin (2.5.2.v201203300216-rel-r37) I don't have that issue anymore (OS X). Maybe time to update your tools? -- J. Am Donnerstag, 19. April 2012 17:02:31 UTC+2 schrieb SCK: Hi I'm trying to create HTML page and I get an error : Unhandled event Loop exception. I need help to fix this problem. Thks -- 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/-/W3l6wQI9xM0J. 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: RequestFactory/Editor AutoBean has been frozen error
Hello all, I tried to reply to the message below in its own thread (here: http://groups.google.com/group/google-web-toolkit/browse_thread/thread/4309e1e60f2cb8d8?pli=1 ), but I was getting an error at every attempt, so I decided to open a new topic with the same title. It seems this useful workaround doesn't work anymore. I get a ClassCastException when I try it. My RequestContext implementation is casted to AbstractRequestContext$State. I can't find a way to access the state of a RequestContext in order to attribute the new one to the old AutoBean. The attribute is private. It almost seems somebody wanted to prevent this hack from being possible... Is there any alternative now, besides manually copying each property of each proxy? Thank you for any help, Tiago. On Feb 22 2011, 9:41 pm, Scott Olcott scottolc...@gmail.com wrote: Thomas, You are correct in understanding my issue. I tried calling AutoBean.clone(), but is fails with a Cannot clone wrapped bean error. I was however able to resubmit the proxy successfully using the following: AutoBeanTest autoBean = AutoBeanUtils.getAutoBean(test); autoBean.setFrozen(false); requestContext = requestFactory.testRequest(); autoBean.setTag(requestContext, requestContext); driver.edit(test, requestContext); calling autoBean.setTag(requestContext, requestContext) is needed to avoid a Attempting to edit an EntityProxy previously edited by another RequestContext error. I know it's a hack but it's the only thing I can get to work other than copying the proxy into a new proxy property by property. -- Tiago Rinck Caveden -- 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.
Re: UIBinder
Sure, I'll try to do that tonight On Wednesday, 18 April 2012 18:55:13 UTC+2, Thomas Broyer wrote: On Wednesday, April 18, 2012 6:36:44 PM UTC+2, Thomas Lefort wrote: One word of advice as I spent a couple of hours on this. DO NOT name (ui:field) your widgets template. This causes great disturbances when generating the code! it looks like a field named template is used internally. Would you mind filing a bug? IIRC UiBinder takes great care not to introduce possibly-conflicting fields, so it's likely something that a) can be fixed, b) is likely to be considered as a should be fixed. -- 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/-/gk_GEVo3QgAJ. 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.
Avoiding DTOs in RPC
I want to avoid having to use DTOs for transferring my Users with RPC. Basically I have a number of rpc calls for my users, and based on the configuration and the user rights, etc... there is a number of fields I want to hide. My approach has been to create DTOs for each case. I was now thinking of using the JPA relationships and lazy loading instead. For instance I store additional information (bio, etc...) in an Additional object, with a onetoone relationship and lazy loading. So I guess based on the call I just need to load the field or not, instead of filling up a dedicated DTO each time I send a User with holes. Does that make sense? any one has cons on this idea? will RPC send empty fields or will it be more clever and just not add the fields that are null? Thanks, Thomas -- 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/-/iLFbBNp8rLAJ. 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: Avoiding DTOs in RPC
On Thursday, April 19, 2012 5:46:07 PM UTC+2, Thomas Lefort wrote: I want to avoid having to use DTOs for transferring my Users with RPC. Basically I have a number of rpc calls for my users, and based on the configuration and the user rights, etc... there is a number of fields I want to hide. My approach has been to create DTOs for each case. I was now thinking of using the JPA relationships and lazy loading instead. For instance I store additional information (bio, etc...) in an Additional object, with a onetoone relationship and lazy loading. So I guess based on the call I just need to load the field or not, instead of filling up a dedicated DTO each time I send a User with holes. Does that make sense? any one has cons on this idea? will RPC send empty fields or will it be more clever and just not add the fields that are null? I don't know JPA very well, but I think lazy-loading will get in your way here. What you need is to conditionally load the Additional object, and in the case you don't, you want the field to be 'null'. AFAIK, this is pretty easy with JPA. That being said, maybe detaching your object from the session would be enough to have a 'null' in the field, and more importantly have the getter not throw any exception but return simply return the null; but that doesn't really change the fact that you'd better ask JPA to load the Additional object if you need it (so it could use a JOIN instead of 2 SELECTs for instance) than use lazy-loading (and calling the getter as a trigger to load the Additional object) -- 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/-/chqJD0S9QZMJ. 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: Recruiting
I've had the same problem. Put a post in gwt jobs group, but little response. Difficult to find good developers and gwt, in particular. Mike On Wednesday, April 18, 2012 1:17:52 AM UTC-7, Thomas Lefort wrote: Hi Thanks. I did try (this is what I called the dedicated group) and got a couple of answers, with very good CVs indeed. However, I was expecting a fair amount more. My (quick) deduction was that there are not so many GWT developers out there - which is not great news for a company. Hence my question. Although not the intention, I got some more CVs through this post. So I guess the GWT Employment group does not have such a wide audience. On 17 April 2012 23:20, Thad thad.humphr...@gmail.com wrote: You might want to look at the google-web-toolkit-employment group. (https://groups.google.com/forum/?fromgroups#!topic/google-web-toolkit/N9NaadyNOk4) On Sunday, April 15, 2012 6:08:41 AM UTC-4, Thomas Lefort wrote: I am looking into recruiting - or at least a bit of freelancing first, ideally someone around Madrid but not necessarily. I tried the dedicated group and also a few other websites (free). I got a couple of good CVs with the group but only two and not in Spain. With the websites, nothing at all. I am trying pay for job boards now. I am wondering if anybody else experienced any difficulty recruiting GWT savvy people. I was naively hoping given the crisis recruiting would be easy but it doesn't appear to be the case. There appears to be shortage of highly skill computer engineers. Anybody else experienced difficulties recruiting gwt profiles, or even Java web engineers in general? -- 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/-/I03pg9fDjLkJ. 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. -- 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/-/EPwUNplM0SoJ. 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: Resolution Dependent ImageBundles
Shouldn't the image size remain constant with screen resolution? Otherwise there would be a similar need on desktops. Are you specifying image size in pixels? Could you use percent? Mike On Tuesday, April 17, 2012 2:21:41 AM UTC-7, Evan Ruff wrote: Hey guys, /div So I#39;m designing an application to be used on tablets and phones. With the introduction of the new iPad, my images are getting BIG. Real big. HUGE. They#39;re so big at this point, that it#39;s really unwieldy to download the ginormous ImageBundle; further, when scaled down in the browser, the images aren#39;t presentable anymore on smaller devices./div /div I was wondering if anyone had started developing a resolution dependent WBRImageBundle, where I could define screen densities and have corresponding packages, much like the Android concepts. If not, I believe that this would be a useful extension to the framework as things like PhoneGap, MobileObjects and mgwt are really starting to push GWT successfully on to the mobile devices. Could someone who has some familiarity with the ImageBundle source point me in the direction of the Linker for that class?/div /div Thanks,/div /div E/div -- 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/-/qC_ly69jPu0J. 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: Avoiding DTOs in RPC
I think GWT-RPC will skip null fields when building the payload. But I would better ask if your JPA entity is serializable so you can share it between GWT and your server. JPA entities will be enhanced by the JPA provider and lazy fields can typically only be accessed while your persistence session is active. If you close your session and then send your data to GWT, during serialization the getter for the lazy field will be called and it will result in an exception (enhanced JPA class trys to load the lazy data upon getter call, but database session is closed already). Maybe you also see SerializationExceptions because your JPA entities are enhanced and may contain additional code / class references that are not serializable. How to solve this depends on your JPA provider: I think OpenJPA lets you detach an entity which gives you back the original POJO (maybe lazy fields will be null then, documentation may help to find out). For Hibernate you can use something like Gilead (only supports Hibernate) which does pretty much what you want (Lazy fields will become null). EclipseLink does static or dynamic weaving to enhance the JPA entities and I haven't found a way to make them serializable for GWT-RPC. So I wouldn't choose EclipseLink if you want to avoid DTO's ;-) -- J. -- 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/-/mMM7kkD1XasJ. 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: Avoiding DTOs in RPC
Additional thoughts below: My approach has been to create DTOs for each case. I was now thinking of using the JPA relationships and lazy loading instead I would recommend to go the lazy loading route in this case. I think having a unique DTO will make things easier to maintain instead of creating specific DTOs for each case. If you are using GWT-RPC and you are in this case populating the DTO's yourself, you can check the user's role for example and based on that, lazy or eagerly fetch what you need. If you are using hibernate, this can be accomplished in a few different ways. Your default configurations are typically lazy there. In the UI, you will always receive the same DTO. There you should at that point either know the user's role or check based on the response you received. The fields that do not apply to the user based on role should then be null and you should check for that. On Thu, Apr 19, 2012 at 12:05 PM, Thomas Broyer t.bro...@gmail.com wrote: On Thursday, April 19, 2012 5:46:07 PM UTC+2, Thomas Lefort wrote: I want to avoid having to use DTOs for transferring my Users with RPC. Basically I have a number of rpc calls for my users, and based on the configuration and the user rights, etc... there is a number of fields I want to hide. My approach has been to create DTOs for each case. I was now thinking of using the JPA relationships and lazy loading instead. For instance I store additional information (bio, etc...) in an Additional object, with a onetoone relationship and lazy loading. So I guess based on the call I just need to load the field or not, instead of filling up a dedicated DTO each time I send a User with holes. Does that make sense? any one has cons on this idea? will RPC send empty fields or will it be more clever and just not add the fields that are null? I don't know JPA very well, but I think lazy-loading will get in your way here. What you need is to conditionally load the Additional object, and in the case you don't, you want the field to be 'null'. AFAIK, this is pretty easy with JPA. That being said, maybe detaching your object from the session would be enough to have a 'null' in the field, and more importantly have the getter not throw any exception but return simply return the null; but that doesn't really change the fact that you'd better ask JPA to load the Additional object if you need it (so it could use a JOIN instead of 2 SELECTs for instance) than use lazy-loading (and calling the getter as a trigger to load the Additional object) -- 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/-/chqJD0S9QZMJ. 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. -- Alfredo Quiroga-Villamil AOL/Yahoo/Gmail/MSN IM: lawwton -- 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.
Re: Resolution Dependent ImageBundles
Shouldn't the image size remain constant with screen resolution? Otherwise there would be a similar need on desktops. Are you specifying image size in pixels? Could you use percent? Apples HiDPI devices double every pixel so that the appearance of the web application remains the same as on low DPI devices. For CSS thats not a problem but images won't be sharp anymore on these devices. So web apps have to provide a double sized image and then set its size to 50%. -- J. -- 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/-/bZhFFpw5qmMJ. 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: Resolution Dependent ImageBundles
Am, This is essentially what I want to do, but with a more refined, reusable approach. One thing that I've found is very helpful with the Android framework, is it has some built in failover type stuff. So if I have an hdpi asset, but no corresponding asset in the ldpi directory, it will just use the hdpi one. It would be interesting to scale down the asset in the generator using some of the better JavaFX tools as well. As of now, I'm investigating this approach. Thanks! E On Tuesday, April 17, 2012 5:49:25 AM UTC-4, Jens wrote: What about a custom property for deferred binding in a .gwt.xml file and a small javascript that fills its value based on window.devicePixelRatio. Older iOS devices have a ratio of 1 while the retina devices have a ratio of 2 because each pixel is doubled. So you could define your own ratio ranges and map them to property values like ldpi, mdpi, hdpi. You could then create a Factory for your bundles and use deferred binding to swap factories between devices based on their pixel density. I dont think you can directly swap out ClientBundles as they are generated by GWT. -- J. Am Dienstag, 17. April 2012 11:21:41 UTC+2 schrieb Evan Ruff: Hey guys, So I'm designing an application to be used on tablets and phones. With the introduction of the new iPad, my images are getting BIG. Real big. HUGE. They're so big at this point, that it's really unwieldy to download the ginormous ImageBundle; further, when scaled down in the browser, the images aren't presentable anymore on smaller devices. I was wondering if anyone had started developing a resolution dependent ImageBundle, where I could define screen densities and have corresponding packages, much like the Android concepts. If not, I believe that this would be a useful extension to the framework as things like PhoneGap, MobileObjects and mgwt are really starting to push GWT successfully on to the mobile devices. Could someone who has some familiarity with the ImageBundle source point me in the direction of the Linker for that class? Thanks, E On Tuesday, April 17, 2012 5:49:25 AM UTC-4, Jens wrote: What about a custom property for deferred binding in a .gwt.xml file and a small javascript that fills its value based on window.devicePixelRatio. Older iOS devices have a ratio of 1 while the retina devices have a ratio of 2 because each pixel is doubled. So you could define your own ratio ranges and map them to property values like ldpi, mdpi, hdpi. You could then create a Factory for your bundles and use deferred binding to swap factories between devices based on their pixel density. I dont think you can directly swap out ClientBundles as they are generated by GWT. -- J. Am Dienstag, 17. April 2012 11:21:41 UTC+2 schrieb Evan Ruff: Hey guys, So I'm designing an application to be used on tablets and phones. With the introduction of the new iPad, my images are getting BIG. Real big. HUGE. They're so big at this point, that it's really unwieldy to download the ginormous ImageBundle; further, when scaled down in the browser, the images aren't presentable anymore on smaller devices. I was wondering if anyone had started developing a resolution dependent ImageBundle, where I could define screen densities and have corresponding packages, much like the Android concepts. If not, I believe that this would be a useful extension to the framework as things like PhoneGap, MobileObjects and mgwt are really starting to push GWT successfully on to the mobile devices. Could someone who has some familiarity with the ImageBundle source point me in the direction of the Linker for that class? Thanks, E -- 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/-/CHb1ZjFAOw4J. 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: Resolution Dependent ImageBundles
Joe, SVG would be awesome if my sources were vectors. By the time the images have gotten to me, they're bitmaps. Does GWT support SVG in client bundles? Thanks, E On Tuesday, April 17, 2012 10:21:31 PM UTC-4, Joseph Lust wrote: Note quite what you're looking for, but why not use SVG for many of these graphics? In most cases the result will be smaller than a png and you will no longer need to worry about resolution creep. This is what we used for our ipad app. Joe -- 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/-/qgrBZP5_ODUJ. 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: Resolution Dependent ImageBundles
You could wrap them up as a TextResource in your ClientBundle and inject them into the page, but Android 1-3's Browser doesn't support SVG, nor do IE versions prior to 9. On Thursday, April 19, 2012 12:38:54 PM UTC-5, Evan Ruff wrote: Joe, SVG would be awesome if my sources were vectors. By the time the images have gotten to me, they're bitmaps. Does GWT support SVG in client bundles? Thanks, E On Tuesday, April 17, 2012 10:21:31 PM UTC-4, Joseph Lust wrote: Note quite what you're looking for, but why not use SVG for many of these graphics? In most cases the result will be smaller than a png and you will no longer need to worry about resolution creep. This is what we used for our ipad app. Joe -- 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/-/UGykNimw700J. 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: Resolution Dependent ImageBundles
Colin, This seems to be similar to Jens suggestion. I just read over the Appearance Pattern information and it seems like it would be quite a lot of code for every Widget in the application. Are you suggesting that the ImageBundle itself have an appearance abstraction, or that each Widget have a HDPIAppearance, LDPIAppearance, etc? Thanks, E On Tuesday, April 17, 2012 4:40:35 PM UTC-4, Colin Alworth wrote: It could be possible to wrap your ClientBundles in an appearance implementation, and use replace-with declarations on that, to check for dpi when the app starts up. Check out the notes on the appearance concept at http://code.google.com/p/google-web-toolkit/wiki/CellBackedWIdgets#Appearance_Pattern -Colin On Tuesday, April 17, 2012 4:49:25 AM UTC-5, Jens wrote: What about a custom property for deferred binding in a .gwt.xml file and a small javascript that fills its value based on window.devicePixelRatio. Older iOS devices have a ratio of 1 while the retina devices have a ratio of 2 because each pixel is doubled. So you could define your own ratio ranges and map them to property values like ldpi, mdpi, hdpi. You could then create a Factory for your bundles and use deferred binding to swap factories between devices based on their pixel density. I dont think you can directly swap out ClientBundles as they are generated by GWT. -- J. Am Dienstag, 17. April 2012 11:21:41 UTC+2 schrieb Evan Ruff: Hey guys, So I'm designing an application to be used on tablets and phones. With the introduction of the new iPad, my images are getting BIG. Real big. HUGE. They're so big at this point, that it's really unwieldy to download the ginormous ImageBundle; further, when scaled down in the browser, the images aren't presentable anymore on smaller devices. I was wondering if anyone had started developing a resolution dependent ImageBundle, where I could define screen densities and have corresponding packages, much like the Android concepts. If not, I believe that this would be a useful extension to the framework as things like PhoneGap, MobileObjects and mgwt are really starting to push GWT successfully on to the mobile devices. Could someone who has some familiarity with the ImageBundle source point me in the direction of the Linker for that class? Thanks, E -- 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/-/AcInZOQMjREJ. 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: Resolution Dependent ImageBundles
I think it'd be a little too specialized for ClientBundle itself to support such a thing - that said, a custom *ClientBundleGenerator subclass could be used in conjunction with file naming conventions to work this out. The basic idea would need to be that each file has one of several suffixes, and that there is some bootstrap property (akin to user.agent and locale) to decide which suffix to have built in to that ClientBundle impl. Or, take the approach of allowing standard resources as well as DPI specific resources, and define a new ImageResource type with a matching ResourceGenerator. Use the ImageResourceGenerator's locale specific wiring as a guide for picking out a dpi-specific file -- or if you aren't using the i18n features, use this locale _as_ your dpi. But yes, my suggestion had been to create appearances - this would go beyond just images then, and allow you to have the rest of the control that android has, with defining new layouts, etc - phone vs tablet vs desktop probably need more than just different images, but in some cases, not a lot more. On Thursday, April 19, 2012 12:45:48 PM UTC-5, Evan Ruff wrote: Colin, This seems to be similar to Jens suggestion. I just read over the Appearance Pattern information and it seems like it would be quite a lot of code for every Widget in the application. Are you suggesting that the ImageBundle itself have an appearance abstraction, or that each Widget have a HDPIAppearance, LDPIAppearance, etc? Thanks, E On Tuesday, April 17, 2012 4:40:35 PM UTC-4, Colin Alworth wrote: It could be possible to wrap your ClientBundles in an appearance implementation, and use replace-with declarations on that, to check for dpi when the app starts up. Check out the notes on the appearance concept at http://code.google.com/p/google-web-toolkit/wiki/CellBackedWIdgets#Appearance_Pattern -Colin On Tuesday, April 17, 2012 4:49:25 AM UTC-5, Jens wrote: What about a custom property for deferred binding in a .gwt.xml file and a small javascript that fills its value based on window.devicePixelRatio. Older iOS devices have a ratio of 1 while the retina devices have a ratio of 2 because each pixel is doubled. So you could define your own ratio ranges and map them to property values like ldpi, mdpi, hdpi. You could then create a Factory for your bundles and use deferred binding to swap factories between devices based on their pixel density. I dont think you can directly swap out ClientBundles as they are generated by GWT. -- J. Am Dienstag, 17. April 2012 11:21:41 UTC+2 schrieb Evan Ruff: Hey guys, So I'm designing an application to be used on tablets and phones. With the introduction of the new iPad, my images are getting BIG. Real big. HUGE. They're so big at this point, that it's really unwieldy to download the ginormous ImageBundle; further, when scaled down in the browser, the images aren't presentable anymore on smaller devices. I was wondering if anyone had started developing a resolution dependent ImageBundle, where I could define screen densities and have corresponding packages, much like the Android concepts. If not, I believe that this would be a useful extension to the framework as things like PhoneGap, MobileObjects and mgwt are really starting to push GWT successfully on to the mobile devices. Could someone who has some familiarity with the ImageBundle source point me in the direction of the Linker for that class? Thanks, E -- 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/-/TUCQhjWww-AJ. 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: Call for action: Time to rethink a road-map and more frequent updates for GWT.
Here is my own personal opinion about what is going on. Initially Google was totally dedicated to GWT. It is a great platform loved by Google and many others. Oracle is suing Google over Java. Google doesn't know where this is going to end and is, quite frankly, sick of the idea that Oracle could possibly sue them over use of a largely public platform. Google doesn't ever want to be in a position to have another company bully them - especially given the very significant time and money Google put in to, in effect, promoting Java. Given the possibly crazy settlement amount, it is cheaper and less hassle over the long haul if Google just invents in its own stuff and doesn't depend on anything such as Java. Given this, Google has roughly decided to drop GWT over the long haul and move to some other solution such as Dart. However, there are two issues. First, Google doesn't know how the suit will unfold, nor how the public will react to both the suit and diminished support of GWT. Secondly, Google doesn't know when Dart will be able to totally replace GWT. These two issues cause Google to be silent. They don't want to prematurely kill GWT, especially since they aren't totally sure about its future anyway. They also can't give a roadmap since that would largely be a lie. The only thing they can do is remain silent. Look for an announcement about GWT when Dart is ready for prime time. You can thank Oracle for all of this! (On another note, IMO, Oracle suing over Java use may go a long way towards killing Java over the long haul. Nobody wants to live with a possible threat like this from one of the largest companies in the world.) Blake McBride On Thu, Apr 19, 2012 at 7:12 AM, July julyg...@gmail.com wrote: +1 On Wednesday, April 18, 2012 4:48:52 AM UTC+8, emurmur wrote: I'm one of the fence sitters. I have been using Flex/Flash, which has been fantastic, but has no future on the mobile web. I think there are only two mature tools that would allow me to create similarly rich applications; GWT and Closure Tools. Google has decided that Javascript won't cut it for their own future products, even though they are heavily invested in Closure Tools. I agree completely. It is important to understand that they have also decided NOT to move everything to GWT. This makes some sense, given that the owner of Java is suing them. I think this is in no way a reflection on GWT as a tool and technology. So Google has decided to move forward with a third initiative designed, in part, to replace GWT and Closure Tools at Google. So, I look at that and I am worried about long-term support for GWT. I think that is a reasonable concern. This concern is mitigated by the fact that GWT is a fully open-source project. Flex/Flash on mobile browsers _was_ fully supported and look how that turned out. So, corporate support is no guarantee; open source is actually a safer bet. However, I would feel a lot better if I had an official roadmap for GWT. That being said, Ray's comments on what is coming are heartening. The biggest worry I have for GWT, if Google stops directly supporting it, is the debug environment. The plugin seems to need a lot of maintenance because the browsers are moving so fast. The upcoming support for source-maps mitigates this; I would feel better if I did not have to rely on a plugin. I've been working with Dart quite a bit and it is really promising. However, integration with other Javascript environments is problematic. For instance, Dart integration with PhoneGap does not exist and appears to be very challenging (some have tried and decided to pass on it). This is a non-starter for me. I want to use the mobile web, but I also want the flexibility of providing an app if my customers want one. For now, Dart can't do that. This may also be a problem when trying to integrate a Dart app into Windows 8 Metro. GWT is far superior in this regard; it has a nice architecture for integrating with Javascript and many useful implementations, including a couple for PhoneGap. I'm hoping Javascript integration will be addressed in the future, but Dart is still in alpha and the team is working on core features at least until the language gets to 1.0. Also, because Dart is so young, the tooling cannot compare to Java tooling. This will improve, but Java has many years head start. The Dart team is amazing and I am sure they are creating something very important; I just wish they were 2 more years along. My window for fence sitting is closing fast. I will have to make a decision. GWT and Dart are the only real contenders. As of now, I think GWT is the best choice, but I would sleep better at night if I had a roadmap under my pillow. On Apr 13, 7:34 am, Blake McBride blake1...@gmail.com wrote: I strongly disagree with this. First of all browser technology and HTML are in constant flux. If GWT is not updated, it will very
Re: How to track native browser scroll up-down movement
I got to know about the scrollbar event but could not achieve the result as desired. Can anyone help me with css ? On Wed, Apr 18, 2012 at 3:54 AM, Aidan O'Kelly aida...@gmail.com wrote: I have not used this, but: http://google-web-toolkit.googlecode.com/svn/javadoc/latest/com/google/gwt/user/client/Window.html#addWindowScrollHandler(com.google.gwt.user.client.Window.ScrollHandler) Should help you track the users scrolling. On Tue, Apr 17, 2012 at 11:08 PM, Deepak Singh deepaksingh...@gmail.comwrote: I want to use plain html only because in my whole project i have not used LayoutPanels, its only plain html with uibinders. I believe the work can be achieved with a bit of css only. The first question is how to track the scroll movement by user? And the 2nd question is what could be the best css to applied for each div ? Thanks in advance Deepak On Wed, Apr 18, 2012 at 2:48 AM, Thad thad.humphr...@gmail.com wrote: I would rewrite this as SplitLayoutPanel. g:north would be topDiv and a SimpleLayoutPanel. g:west would be leftDiv and a SimpleLayoutPanel. g:center would be rightDiv and a ScrollPanel or CustomScrollPanel. It's a pain in the neck to get in place, but it does work. On Monday, April 16, 2012 4:45:01 PM UTC-4, Deepak Singh wrote: Hi, I have the following scenario, Html: div div style=width:100% ui:field=topDiv/div div style=width:40% ui:field=leftDiv/div div style=width:60% ui:field=rightDiv/div /div Now, this uibinder is rendered at a particular position in html. Browser scrolls up and down and this uibinder scrolls up and down as usual. Now, I need to achieve two things, As the scrollbar moves, when the 'topDiv' reaches the top postion of browser, it should not scroll any more and make its position fixed. When scrollbar scrolls up, 'topDiv' should also scroll down and reach its original position. At the same time, 'leftDiv' should always remain fixed and should never scroll up or down ever. And, 'rightDiv' should always scroll up and down with scrollbar as required natively. So the question is, how do i track the movement of scroll bar up and down ? What should be the proper css applied to each div ? Thanks Deepak Singh -- 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/-/Y_Hx2bQDLBEJ. 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. -- Deepak Singh -- 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. -- 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. -- Deepak Singh -- 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.
Re: Avoiding DTOs in RPC
In a project of mine I successfully use THE SAME classes both as hibernate model and as GWT client model class using simple GWT RPC for client-server comunication: A couple of things I remember are: 1) I needed to put my DAO model classes in gwt client package because I work directly with this in GWT client mode (they need to be translated to javscript). 2) use lazy=true in collection attribute definitions. If not, the getCollection() will return a Collection implementation not supported by GWT RPC. 3) (obvius) be careful your pojos will support RPC valid types. careful while using other framework that enrich your model POJOS like hibernate does for collection attributes. I don't know if this will be of use for you... On Thu, 19 Apr 2012 08:46:07 -0700 (PDT) Thomas Lefort lefortho...@gmail.com wrote: I want to avoid having to use DTOs for transferring my Users with RPC. Basically I have a number of rpc calls for my users, and based on the configuration and the user rights, etc... there is a number of fields I want to hide. My approach has been to create DTOs for each case. I was now thinking of using the JPA relationships and lazy loading instead. For instance I store additional information (bio, etc...) in an Additional object, with a onetoone relationship and lazy loading. So I guess based on the call I just need to load the field or not, instead of filling up a dedicated DTO each time I send a User with holes. Does that make sense? any one has cons on this idea? will RPC send empty fields or will it be more clever and just not add the fields that are null? Thanks, Thomas -- 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/-/iLFbBNp8rLAJ. 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. -- Sebastian Gurin sgu...@softpoint.org -- 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.
Re: Call for action: Time to rethink a road-map and more frequent updates for GWT.
I have an additional comment. Although I see Google dropping GWT when Dart becomes ready for prime time, I believe GWT will live on as a community project. Additionally, given Google's internal use of GWT, Google is likely to at least minimally support GWT (for its own needs at least) for a considerable time. GWT is such a valuable tool and has achieved sufficient level of maturity that I think it'll not disappear. Lacking an unexpected statement of real commitment, perhaps we should start considering how best to provide community support of GWT. Blake McBride On Thu, Apr 19, 2012 at 1:17 PM, Blake McBride blake1...@gmail.com wrote: Here is my own personal opinion about what is going on. Initially Google was totally dedicated to GWT. It is a great platform loved by Google and many others. Oracle is suing Google over Java. Google doesn't know where this is going to end and is, quite frankly, sick of the idea that Oracle could possibly sue them over use of a largely public platform. Google doesn't ever want to be in a position to have another company bully them - especially given the very significant time and money Google put in to, in effect, promoting Java. Given the possibly crazy settlement amount, it is cheaper and less hassle over the long haul if Google just invents in its own stuff and doesn't depend on anything such as Java. Given this, Google has roughly decided to drop GWT over the long haul and move to some other solution such as Dart. However, there are two issues. First, Google doesn't know how the suit will unfold, nor how the public will react to both the suit and diminished support of GWT. Secondly, Google doesn't know when Dart will be able to totally replace GWT. These two issues cause Google to be silent. They don't want to prematurely kill GWT, especially since they aren't totally sure about its future anyway. They also can't give a roadmap since that would largely be a lie. The only thing they can do is remain silent. Look for an announcement about GWT when Dart is ready for prime time. You can thank Oracle for all of this! (On another note, IMO, Oracle suing over Java use may go a long way towards killing Java over the long haul. Nobody wants to live with a possible threat like this from one of the largest companies in the world.) Blake McBride On Thu, Apr 19, 2012 at 7:12 AM, July julyg...@gmail.com wrote: +1 On Wednesday, April 18, 2012 4:48:52 AM UTC+8, emurmur wrote: I'm one of the fence sitters. I have been using Flex/Flash, which has been fantastic, but has no future on the mobile web. I think there are only two mature tools that would allow me to create similarly rich applications; GWT and Closure Tools. Google has decided that Javascript won't cut it for their own future products, even though they are heavily invested in Closure Tools. I agree completely. It is important to understand that they have also decided NOT to move everything to GWT. This makes some sense, given that the owner of Java is suing them. I think this is in no way a reflection on GWT as a tool and technology. So Google has decided to move forward with a third initiative designed, in part, to replace GWT and Closure Tools at Google. So, I look at that and I am worried about long-term support for GWT. I think that is a reasonable concern. This concern is mitigated by the fact that GWT is a fully open-source project. Flex/Flash on mobile browsers _was_ fully supported and look how that turned out. So, corporate support is no guarantee; open source is actually a safer bet. However, I would feel a lot better if I had an official roadmap for GWT. That being said, Ray's comments on what is coming are heartening. The biggest worry I have for GWT, if Google stops directly supporting it, is the debug environment. The plugin seems to need a lot of maintenance because the browsers are moving so fast. The upcoming support for source-maps mitigates this; I would feel better if I did not have to rely on a plugin. I've been working with Dart quite a bit and it is really promising. However, integration with other Javascript environments is problematic. For instance, Dart integration with PhoneGap does not exist and appears to be very challenging (some have tried and decided to pass on it). This is a non-starter for me. I want to use the mobile web, but I also want the flexibility of providing an app if my customers want one. For now, Dart can't do that. This may also be a problem when trying to integrate a Dart app into Windows 8 Metro. GWT is far superior in this regard; it has a nice architecture for integrating with Javascript and many useful implementations, including a couple for PhoneGap. I'm hoping Javascript integration will be addressed in the future, but Dart is still in alpha and the team is working on core features at least until the language gets to 1.0. Also, because Dart is so
Re: Call for action: Time to rethink a road-map and more frequent updates for GWT.
Obviously something is happening. One of the first thing you do as a team lead of a project that is going to disappear is to remove the developer relations people and reassign team members, which both have been happening in the GWT team. David Chandler, GWT developer relations left the team (https://turbomanage.wordpress.com/) to work on Android and some GWT developers are now working on Dart as per GWT team lead Bruce Johnson ( http://googlewebtoolkit.blogspot.com/2011/11/gwt-and-dart.html) speculation 1. I think the GWT team is creating a Dart equivalent to GWT then will retire GWT. However talking about this would scare lots of people off so until they have something big to show and a concrete roadmap they keep silent. If GWT was dropped we would hear about but and I think we are in a transition phase. 2. Since Dart is close to Java in many ways, they could offer Dart on App Engine thus providing a complete solution, UI and backend all on Dart, which would be really cool. That would be a replacement for Java on Android which would break the java-lawsuit-leach Oracle has on Google. /speculation But it's too silent out there... The community needs to be more vocal about requesting some information and the GWT team needs to be more proactive engaging with us. On Monday, April 2, 2012 10:19:16 AM UTC-5, Joshua Kappon wrote: With the rise of the new developers.google.com, and with Google trying to rally up developers using Google technologies and products, and the rise of Dart and unclear future of GWT, I think it's about time that Google will rethink the all We don't and won't have a road map, and there are no release dates for new GWT versions and embrace the GWT developers community. What do you guys think? (if you agree, +1 this) Best, Josh -- 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/-/SLJ-Yc4OLWwJ. 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: Call for action: Time to rethink a road-map and more frequent updates for GWT.
Interesting idea, but the issue is that Oracle is suing Google over its use of Dalvik in Android - the basis of the case is that Dalvik breaks the licensing terms of a JDK. Although I totally agree that this may well spread FUD in the long term which will cost Oracle more that it makes out of the suit, the fact is I suspect that the main reason is still that GWT is moving to the maintenance part of its lifecycle On 4/19/2012 11:17 AM, Blake McBride wrote: Here is my own personal opinion about what is going on. Initially Google was totally dedicated to GWT. It is a great platform loved by Google and many others. Oracle is suing Google over Java. Google doesn't know where this is going to end and is, quite frankly, sick of the idea that Oracle could possibly sue them over use of a largely public platform. Google doesn't ever want to be in a position to have another company bully them - especially given the very significant time and money Google put in to, in effect, promoting Java. Given the possibly crazy settlement amount, it is cheaper and less hassle over the long haul if Google just invents in its own stuff and doesn't depend on anything such as Java. Given this, Google has roughly decided to drop GWT over the long haul and move to some other solution such as Dart. However, there are two issues. First, Google doesn't know how the suit will unfold, nor how the public will react to both the suit and diminished support of GWT. Secondly, Google doesn't know when Dart will be able to totally replace GWT. These two issues cause Google to be silent. They don't want to prematurely kill GWT, especially since they aren't totally sure about its future anyway. They also can't give a roadmap since that would largely be a lie. The only thing they can do is remain silent. Look for an announcement about GWT when Dart is ready for prime time. You can thank Oracle for all of this! (On another note, IMO, Oracle suing over Java use may go a long way towards killing Java over the long haul. Nobody wants to live with a possible threat like this from one of the largest companies in the world.) Blake McBride On Thu, Apr 19, 2012 at 7:12 AM, July julyg...@gmail.com mailto:julyg...@gmail.com wrote: +1 On Wednesday, April 18, 2012 4:48:52 AM UTC+8, emurmur wrote: I'm one of the fence sitters. I have been using Flex/Flash, which has been fantastic, but has no future on the mobile web. I think there are only two mature tools that would allow me to create similarly rich applications; GWT and Closure Tools. Google has decided that Javascript won't cut it for their own future products, even though they are heavily invested in Closure Tools. I agree completely. It is important to understand that they have also decided NOT to move everything to GWT. This makes some sense, given that the owner of Java is suing them. I think this is in no way a reflection on GWT as a tool and technology. So Google has decided to move forward with a third initiative designed, in part, to replace GWT and Closure Tools at Google. So, I look at that and I am worried about long-term support for GWT. I think that is a reasonable concern. This concern is mitigated by the fact that GWT is a fully open-source project. Flex/Flash on mobile browsers _was_ fully supported and look how that turned out. So, corporate support is no guarantee; open source is actually a safer bet. However, I would feel a lot better if I had an official roadmap for GWT. That being said, Ray's comments on what is coming are heartening. The biggest worry I have for GWT, if Google stops directly supporting it, is the debug environment. The plugin seems to need a lot of maintenance because the browsers are moving so fast. The upcoming support for source-maps mitigates this; I would feel better if I did not have to rely on a plugin. I've been working with Dart quite a bit and it is really promising. However, integration with other Javascript environments is problematic. For instance, Dart integration with PhoneGap does not exist and appears to be very challenging (some have tried and decided to pass on it). This is a non-starter for me. I want to use the mobile web, but I also want the flexibility of providing an app if my customers want one. For now, Dart can't do that. This may also be a problem when trying to integrate a Dart app into Windows 8 Metro. GWT is far superior in this regard; it has a nice architecture for integrating with Javascript and
Re: Call for action: Time to rethink a road-map and more frequent updates for GWT.
GWT 2.5 was supposed to be released in first quarter of 2012 which already passed. Anybody knows why it was not released yet? On Fri, Apr 20, 2012 at 12:45 AM, Alan Chaney a...@mechnicality.com wrote: Interesting idea, but the issue is that Oracle is suing Google over its use of Dalvik in Android - the basis of the case is that Dalvik breaks the licensing terms of a JDK. Although I totally agree that this may well spread FUD in the long term which will cost Oracle more that it makes out of the suit, the fact is I suspect that the main reason is still that GWT is moving to the maintenance part of its lifecycle On 4/19/2012 11:17 AM, Blake McBride wrote: Here is my own personal opinion about what is going on. Initially Google was totally dedicated to GWT. It is a great platform loved by Google and many others. Oracle is suing Google over Java. Google doesn't know where this is going to end and is, quite frankly, sick of the idea that Oracle could possibly sue them over use of a largely public platform. Google doesn't ever want to be in a position to have another company bully them - especially given the very significant time and money Google put in to, in effect, promoting Java. Given the possibly crazy settlement amount, it is cheaper and less hassle over the long haul if Google just invents in its own stuff and doesn't depend on anything such as Java. Given this, Google has roughly decided to drop GWT over the long haul and move to some other solution such as Dart. However, there are two issues. First, Google doesn't know how the suit will unfold, nor how the public will react to both the suit and diminished support of GWT. Secondly, Google doesn't know when Dart will be able to totally replace GWT. These two issues cause Google to be silent. They don't want to prematurely kill GWT, especially since they aren't totally sure about its future anyway. They also can't give a roadmap since that would largely be a lie. The only thing they can do is remain silent. Look for an announcement about GWT when Dart is ready for prime time. You can thank Oracle for all of this! (On another note, IMO, Oracle suing over Java use may go a long way towards killing Java over the long haul. Nobody wants to live with a possible threat like this from one of the largest companies in the world.) Blake McBride On Thu, Apr 19, 2012 at 7:12 AM, July julyg...@gmail.com wrote: +1 On Wednesday, April 18, 2012 4:48:52 AM UTC+8, emurmur wrote: I'm one of the fence sitters. I have been using Flex/Flash, which has been fantastic, but has no future on the mobile web. I think there are only two mature tools that would allow me to create similarly rich applications; GWT and Closure Tools. Google has decided that Javascript won't cut it for their own future products, even though they are heavily invested in Closure Tools. I agree completely. It is important to understand that they have also decided NOT to move everything to GWT. This makes some sense, given that the owner of Java is suing them. I think this is in no way a reflection on GWT as a tool and technology. So Google has decided to move forward with a third initiative designed, in part, to replace GWT and Closure Tools at Google. So, I look at that and I am worried about long-term support for GWT. I think that is a reasonable concern. This concern is mitigated by the fact that GWT is a fully open-source project. Flex/Flash on mobile browsers _was_ fully supported and look how that turned out. So, corporate support is no guarantee; open source is actually a safer bet. However, I would feel a lot better if I had an official roadmap for GWT. That being said, Ray's comments on what is coming are heartening. The biggest worry I have for GWT, if Google stops directly supporting it, is the debug environment. The plugin seems to need a lot of maintenance because the browsers are moving so fast. The upcoming support for source-maps mitigates this; I would feel better if I did not have to rely on a plugin. I've been working with Dart quite a bit and it is really promising. However, integration with other Javascript environments is problematic. For instance, Dart integration with PhoneGap does not exist and appears to be very challenging (some have tried and decided to pass on it). This is a non-starter for me. I want to use the mobile web, but I also want the flexibility of providing an app if my customers want one. For now, Dart can't do that. This may also be a problem when trying to integrate a Dart app into Windows 8 Metro. GWT is far superior in this regard; it has a nice architecture for integrating with Javascript and many useful implementations, including a couple for PhoneGap. I'm hoping Javascript integration will be addressed in the future, but Dart is still in alpha and the team is working on core features at least until the language gets to
logging jobs run by executor service
Hello gwt users, I can see my usual stderr messages from my default gwt classes. However, if I use the Executor Service to run the jobs, the stderr messages seems to get lost in limbo. I am using standard java logging classes. Is this a limitation of gwt/tomcat, or simply my misconfigurations? my logging.properties is simply: # The following creates two handlers handlers = java.util.logging.ConsoleHandler, java.util.logging.FileHandler # Set the level for the root logger .level = INFO # Set the level for ConsoleHandler java.util.logging.ConsoleHandler.level = INFO # Set the logging level for FileHandler java.util.logging.FileHandler.level = INFO # Set the formatter for ConsoleHandler java.util.logging.ConsoleHandler.formatter = java.util.logging.SimpleFormatter Thank you very much for your help. -- 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/-/JzTspUInM3EJ. 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.
[gwt-contrib] Add text-align support to Style (issue1686803)
Reviewers: ,
Description:
http://code.google.com/p/google-web-toolkit/issues/detail?id=6493
Please review this at http://gwt-code-reviews.appspot.com/1686803/
Affected files:
user/src/com/google/gwt/dom/client/Style.java
Index: user/src/com/google/gwt/dom/client/Style.java
===
--- user/src/com/google/gwt/dom/client/Style.java (revision 10954)
+++ user/src/com/google/gwt/dom/client/Style.java (working copy)
@@ -574,6 +574,38 @@
}
/**
+ * Enum for the text-align property.
+ */
+ public enum TextAlign implements HasCssName {
+CENTER {
+ @Override
+ public String getCssName() {
+return TEXT_ALIGN_CENTER;
+ }
+},
+JUSTIFY {
+ @Override
+ public String getCssName() {
+return TEXT_ALIGN_JUSTIFY;
+ }
+},
+LEFT {
+ @Override
+ public String getCssName() {
+return TEXT_ALIGN_LEFT;
+ }
+},
+RIGHT {
+ @Override
+ public String getCssName() {
+return TEXT_ALIGN_RIGHT;
+ }
+};
+@Override
+public abstract String getCssName();
+ }
+
+ /**
* Enum for the text-decoration property.
*/
public enum TextDecoration implements HasCssName {
@@ -792,6 +824,7 @@
private static final String STYLE_BACKGROUND_COLOR = backgroundColor;
private static final String STYLE_VERTICAL_ALIGN = verticalAlign;
private static final String STYLE_TABLE_LAYOUT = tableLayout;
+ private static final String STYLE_TEXT_ALIGN = textAlign;
private static final String STYLE_OUTLINE_WIDTH = outlineWidth;
private static final String STYLE_OUTLINE_STYLE = outlineStyle;
private static final String STYLE_OUTLINE_COLOR = outlineColor;
@@ -800,6 +833,11 @@
private static final String TABLE_LAYOUT_AUTO = auto;
private static final String TABLE_LAYOUT_FIXED = fixed;
+ private static final String TEXT_ALIGN_CENTER = center;
+ private static final String TEXT_ALIGN_JUSTIFY = justify;
+ private static final String TEXT_ALIGN_LEFT = left;
+ private static final String TEXT_ALIGN_RIGHT = right;
+
private static final String TEXT_DECORATION_LINE_THROUGH
= line-through;
private static final String TEXT_DECORATION_OVERLINE = overline;
private static final String TEXT_DECORATION_UNDERLINE = underline;
@@ -1097,6 +1135,13 @@
}
/**
+ * Clear the 'text-align' css property.
+ */
+ public final void clearTextAlign() {
+clearProperty(STYLE_TEXT_ALIGN);
+ }
+
+ /**
* Clears the text-decoration CSS property.
*/
public final void clearTextDecoration() {
@@ -1371,6 +1416,13 @@
}
/**
+ * Get the 'text-align' css property.
+ */
+ public final String getTextAlign() {
+return getProperty(STYLE_TEXT_ALIGN);
+ }
+
+ /**
* Gets the text-decoration CSS property.
*/
public final String getTextDecoration() {
@@ -1697,6 +1749,13 @@
}
/**
+ * Set the 'text-align' CSS property.
+ */
+ public final void setTextAlign(TextAlign value) {
+setProperty(STYLE_TEXT_ALIGN, value.getCssName());
+ }
+
+ /**
* Sets the text-decoration CSS property.
*/
public final void setTextDecoration(TextDecoration value) {
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] DockLayoutPanel.getWidgetSize(Widget) (issue1687803)
Reviewers: ,
Description:
http://code.google.com/p/google-web-toolkit/issues/detail?id=4613
Please review this at http://gwt-code-reviews.appspot.com/1687803/
Affected files:
user/src/com/google/gwt/user/client/ui/DockLayoutPanel.java
Index: user/src/com/google/gwt/user/client/ui/DockLayoutPanel.java
===
--- user/src/com/google/gwt/user/client/ui/DockLayoutPanel.java (revision
10954)
+++ user/src/com/google/gwt/user/client/ui/DockLayoutPanel.java (working
copy)
@@ -293,6 +293,21 @@
}
/**
+ * Gets the layout size of the given child widget.
+ *
+ * @param child the widget to be queried
+ * @return the widget's layout size, or codenull/code if it is not a
+ * child of this panel
+ */
+ public Double getWidgetSize(Widget child) {
+assertIsChild(child);
+if (child.getParent() != this) {
+ return null;
+}
+return ((LayoutData) child.getLayoutData()).size;
+ }
+
+ /**
* Adds a widget to the east edge of the dock, inserting it before an
existing
* widget.
*
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Incorrect doc for Style.Position (issue1688803)
Reviewers: ,
Description:
The java doc for the Position enum in Style states that the enum is for
the display CSS property when it is actually for the position CSS
property.
Please review this at http://gwt-code-reviews.appspot.com/1688803/
Affected files:
user/src/com/google/gwt/dom/client/Style.java
Index: user/src/com/google/gwt/dom/client/Style.java
===
--- user/src/com/google/gwt/dom/client/Style.java (revision 10954)
+++ user/src/com/google/gwt/dom/client/Style.java (working copy)
@@ -522,7 +522,7 @@
}
/**
- * Enum for the display property.
+ * Enum for the position property.
*/
public enum Position implements HasCssName {
STATIC {
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] SplitLayoutPanel should use ScheduledCommand instead of Command (issue1689803)
Reviewers: ,
Description:
The class uses ScheduledCommand in all but 1 place, the import can be
removed all together if we construct a ScheduledCommand instead of a
Command.
Please review this at http://gwt-code-reviews.appspot.com/1689803/
Affected files:
user/src/com/google/gwt/user/client/ui/SplitLayoutPanel.java
Index: user/src/com/google/gwt/user/client/ui/SplitLayoutPanel.java
===
--- user/src/com/google/gwt/user/client/ui/SplitLayoutPanel.java (revision
10954)
+++ user/src/com/google/gwt/user/client/ui/SplitLayoutPanel.java (working
copy)
@@ -22,7 +22,6 @@
import com.google.gwt.dom.client.Element;
import com.google.gwt.dom.client.Style.Position;
import com.google.gwt.dom.client.Style.Unit;
-import com.google.gwt.user.client.Command;
import com.google.gwt.user.client.Event;
import com.google.gwt.user.client.Window;
@@ -252,7 +251,7 @@
// Defer actually updating the layout, so that if we receive many
// mouse events before layout/paint occurs, we'll only update once.
if (layoutCommand == null) {
-layoutCommand = new Command() {
+layoutCommand = new ScheduledCommand() {
@Override
public void execute() {
layoutCommand = null;
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
