[gwt-contrib] Re: Introducing CustomScrollPanel, a subclass of ScrollPanel that lets users define their own scroll... (issue1427804)
I'm not sure if this is the right forum for this - if not let me know. the demo looks awesome, but the semi-transparent scrollbars have really bad artifacting on chrome for windows - it seems like it is due to this http://code.google.com/p/chromium/issues/detail?id=24524 If the chrome bug doesn't get fixed, perhaps the semi-transparency should be disabled on windows chrome? On Apr 20, 2:38 pm, jlaba...@google.com wrote: Reviewers: rchandia, Description: Introducing CustomScrollPanel, a subclass of ScrollPanel that lets users define their own scrollbars. By default, we use NativeVerticalScrollbar and NativeHorizontalScrollbar, but in the future we might introduce thin scrollbars for mobile devices. The scrollbars are semi-transparent until the user hovers them, at which time they transition to 100% opacity (on browsers that do not support CSS transitions, they immediately become opaque). In RTL, the vertical scrollbar appears on the left side (many browsers get this wrong natively). CustomScrollPanel looks and acts almost exactly like a normal scrollable div, with one important exception. The scrollbars in a CustomScrollPanel are overlaid on top of the content instead of adjacent to it, so when scrollbars appear, the content does not require relayout. This can be useful for layout when aligning items directly above and/or below the CustomScrollPanel, because the content will always flow to the end of the panel. CustomScrollPanel is a pre-requisite for a CellTable with fixed headers/footers and scrollable content area. It allows the header/footer tables to be the same width as the content table regardless of whether or not scrollbars appear. If we tried to a regular ScrollPanel, we would need active layout to adjust the width of the header/footer tables to account for the appearance of scrollbars. In terms of implementation details, the content is actually in a scrollable div, but the scrollbars of the div are hidden behind the outer viewport. So, all of the normal scrolling mechanisms (click and drag text, mousewheel, page up/down) work normally. We use the ResizeLayoutPanel implementation to detect when the content is resize, and show/hide scrollbars accordingly. You can view a demo here:http://cscroll.jlabanca-testing.appspot.com/ Please review this athttp://gwt-code-reviews.appspot.com/1427804/ Affected files: M user/src/com/google/gwt/user/ResizeLayoutPanel.gwt.xml A user/src/com/google/gwt/user/Scroll.gwt.xml D user/src/com/google/gwt/user/ScrollPanel.gwt.xml M user/src/com/google/gwt/user/User.gwt.xml A user/src/com/google/gwt/user/client/ui/AbstractNativeScrollbar.java M user/src/com/google/gwt/user/client/ui/AttachDetachException.java A user/src/com/google/gwt/user/client/ui/CustomScrollPanel.css A user/src/com/google/gwt/user/client/ui/CustomScrollPanel.java A user/src/com/google/gwt/user/client/ui/HorizontalScrollbar.java A user/src/com/google/gwt/user/client/ui/NativeHorizontalScrollbar.css A user/src/com/google/gwt/user/client/ui/NativeHorizontalScrollbar.java A user/src/com/google/gwt/user/client/ui/NativeHorizontalScrollbar.ui.xml A user/src/com/google/gwt/user/client/ui/NativeHorizontalScrollbarTransparent.css A user/src/com/google/gwt/user/client/ui/NativeVerticalScrollbar.css A user/src/com/google/gwt/user/client/ui/NativeVerticalScrollbar.java A user/src/com/google/gwt/user/client/ui/NativeVerticalScrollbar.ui.xml A user/src/com/google/gwt/user/client/ui/NativeVerticalScrollbarTransparent.css M user/src/com/google/gwt/user/client/ui/ResizeLayoutPanel.java A user/src/com/google/gwt/user/client/ui/ScrollImpl.java M user/src/com/google/gwt/user/client/ui/ScrollPanel.java A user/src/com/google/gwt/user/client/ui/VerticalScrollbar.java M user/test/com/google/gwt/user/UISuite.java A user/test/com/google/gwt/user/client/ui/CustomScrollPanelTest.java A user/test/com/google/gwt/user/client/ui/NativeHorizontalScrollbarTest.java A user/test/com/google/gwt/user/client/ui/NativeScrollbarTestBase.java A user/test/com/google/gwt/user/client/ui/NativeVerticalScrollbarTest.java M user/test/com/google/gwt/user/client/ui/ScrollPanelTest.java -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: Feedback Requested: Preview of new GWT Style Theme
I would support just using border-radius for rounded corners and living with square corners in IE 6-8. (Same with using box-shadow for shadows, e.g.: in DialogBox) I think it still needs to look 'good' on IE6-8, but it doesn't need to look exactly the same, and i think missing rounded corners is an acceptable difference. If you are going to take that approach, I think you should also break a bit of backwards compatibility with the new theme by changing the DOM structure of some of the existing widgets. Using border-radius and still having superfluous 3x3 tables all over the place seems like a decision that will be regretted down the road. Internally, we have an internal implementation for buttons and tabs that, via deferred binding, uses border-radius on HTML5 browsers, and images for rounded corners on IE6-8. That is not the easiest thing to implement (and we didn't try to make it generically theme-able), but would be my 'ideal' solution for the widgets where that is possible. That being said, there are much higher things on my wishlist than that :) On Feb 17, 9:08 am, John LaBanca jlaba...@google.com wrote: Chrome, Safari, and Firefox support rounded corners natively in CSS. How do you guys feel about using CSS rules to create rounded corners on modern browser that support it, but not IE? It would mean degraded styles in IE, but thats better than degraded styles across the board. Thanks, John LaBanca jlaba...@google.com On Thu, Feb 17, 2011 at 7:33 AM, Jeff Schwartz jefftschwa...@gmail.comwrote: It is an improvement over previous attempts but can I make a suggestion? Why not use a top graphic artist? Developers are great at layout but... well you know where I'm going with this. Notice josht in the cc list. Yes, GWT finally has a graphic designer on the team. Unfortunately, he's constrained by the fact that he cannot change the DOM structure of existing widgets, which limits what he can do. Jeff On Wed, Feb 16, 2011 at 1:12 PM, John LaBanca jlaba...@google.com wrote: The GWT team is happy to (pre)announce that we will introduce a new, more modern CSS style theme in GWT 2.3 called Clean. The new theme makes existing widgets look cleaner (more business-like) than the standard theme, and replaces the thick light blue borders with thin gray borders. We worked under the constraint that we would not modify the DOM structure of the existing widgets because we didn't want to break existing apps, so this new theme is purely a CSS overhaul. You can preview the new Clean style theme at the link below: http://gwt-showcase-clean.appspot.com/ Please let us know what you like and dislike about the new theme, and if you are interested in switching your app to it. Once we release the theme, it becomes very difficult to change it without affecting existing apps, so early feedback is helpful. Thanks, John LaBanca jlaba...@google.com -- 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. -- *Jeff Schwartz* http://jefftschwartz.appspot.com/ -- 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.
Re: Feedback Requested: Preview of new GWT Style Theme
Another nice aspect of border-radius over the emulation approach, is that it lets you avoid aliasing artifacts when changing the page size via full-page zoom. For example, if you look at the basic popup on the showcase, and change the page zoom size in your browser, you can see occasional single-pixel 'cracks', and the rounded corner ends up being pixelated. On Feb 17, 11:37 am, Chi H c...@chi.ca wrote: I would support just using border-radius for rounded corners and living with square corners in IE 6-8. (Same with using box-shadow for shadows, e.g.: in DialogBox) I think it still needs to look 'good' on IE6-8, but it doesn't need to look exactly the same, and i think missing rounded corners is an acceptable difference. If you are going to take that approach, I think you should also break a bit of backwards compatibility with the new theme by changing the DOM structure of some of the existing widgets. Using border-radius and still having superfluous 3x3 tables all over the place seems like a decision that will be regretted down the road. Internally, we have an internal implementation for buttons and tabs that, via deferred binding, uses border-radius on HTML5 browsers, and images for rounded corners on IE6-8. That is not the easiest thing to implement (and we didn't try to make it generically theme-able), but would be my 'ideal' solution for the widgets where that is possible. That being said, there are much higher things on my wishlist than that :) On Feb 17, 9:08 am, John LaBanca jlaba...@google.com wrote: Chrome, Safari, and Firefox support rounded corners natively in CSS. How do you guys feel about using CSS rules to create rounded corners on modern browser that support it, but not IE? It would mean degraded styles in IE, but thats better than degraded styles across the board. Thanks, John LaBanca jlaba...@google.com On Thu, Feb 17, 2011 at 7:33 AM, Jeff Schwartz jefftschwa...@gmail.comwrote: It is an improvement over previous attempts but can I make a suggestion? Why not use a top graphic artist? Developers are great at layout but... well you know where I'm going with this. Notice josht in the cc list. Yes, GWT finally has a graphic designer on the team. Unfortunately, he's constrained by the fact that he cannot change the DOM structure of existing widgets, which limits what he can do. Jeff On Wed, Feb 16, 2011 at 1:12 PM, John LaBanca jlaba...@google.com wrote: The GWT team is happy to (pre)announce that we will introduce a new, more modern CSS style theme in GWT 2.3 called Clean. The new theme makes existing widgets look cleaner (more business-like) than the standard theme, and replaces the thick light blue borders with thin gray borders. We worked under the constraint that we would not modify the DOM structure of the existing widgets because we didn't want to break existing apps, so this new theme is purely a CSS overhaul. You can preview the new Clean style theme at the link below: http://gwt-showcase-clean.appspot.com/ Please let us know what you like and dislike about the new theme, and if you are interested in switching your app to it. Once we release the theme, it becomes very difficult to change it without affecting existing apps, so early feedback is helpful. Thanks, John LaBanca jlaba...@google.com -- 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. -- *Jeff Schwartz* http://jefftschwartz.appspot.com/ -- 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.
Re: Feedback Requested: Preview of new GWT Style Theme
This looks great! Some of my suggestions: - Light sources - from a design perspective, what direction is the light source? The styling of most widgets (including textbox, menu bar, stack panel, and buttons) implies that the light source is coming from the top part of the screen.However, the text-shadow in the CellTable headers, and the shadow in the pop up DialogBox implies that the light source is coming from the upper-left corner of the screen.It is a very subtle thing, but this should be made consistent (I prefer top light sources myself). - I'm not a fan of the text-shadow in the header of CellTable. With such a small font size, I think the effect comes across more as blurriness than a shadow. I think it should just be removed - DatePicker - the day of week labels (S/M/T/W/T/F/S) should be a bit stronger, and the days which are not part of the currently selected month should have a stronger 'greyed out' look, e.g.: by using a darker background. Generally, i think YUI 2's date picker looks really good - http://developer.yahoo.com/yui/examples/calendar/quickstart.html - SuggestBox - can we use non-rounded corners in the suggest pop- up? Or, at the very least, changing it so that only the bottom two corners are rounded. - SplitLayoutPanel - I think it would look better if the splitter has a defined border. I like the look of the splitter used in android's documentation - e.g.: on http://developer.android.com/reference/packages.html and I think copying that would be an improvement - TabLayoutPanel - the dark blue background for the tabs looks very out of place, since it is so strong and isn't widely used in other widgets. Perhaps a simple grey would be better? All that being said, we will be adopting the new theme regardless of whether or not you accept these suggestions, it is already a huge improvement. We appreciate the GWT team's hard work and their willingness to hear feedback! --- Chi Hoang On Feb 16, 11:12 am, John LaBanca jlaba...@google.com wrote: The GWT team is happy to (pre)announce that we will introduce a new, more modern CSS style theme in GWT 2.3 called Clean. The new theme makes existing widgets look cleaner (more business-like) than the standard theme, and replaces the thick light blue borders with thin gray borders. We worked under the constraint that we would not modify the DOM structure of the existing widgets because we didn't want to break existing apps, so this new theme is purely a CSS overhaul. You can preview the new Clean style theme at the link below:http://gwt-showcase-clean.appspot.com/ Please let us know what you like and dislike about the new theme, and if you are interested in switching your app to it. Once we release the theme, it becomes very difficult to change it without affecting existing apps, so early feedback is helpful. Thanks, John LaBanca jlaba...@google.com -- 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: Making GWT look good...
On the topic of the widget set. * One thing we do internally is use deferred binding on some of our custom widgets to deal with different browsers having different levels of functionality. For example, in our custom styled button widget, we use CSS3 properties (e.g.: border-radius) to render buttons on CSS3 browsers, and the CSS2 sliding doors technique (which use images for rounded corners) to render identical looking buttons on less capable browsers. One advantage of using border-radius on the browsers which support it is that you avoid aliasing when zooming in on the page. This has been very successful for us, it should be something to consider for new widgets where appropriate. * Performance is important. Sluggish sites are not fun to use. I love how the GWT team is already so focused on performance, please do not lose sight of it while you are in the process of making it look good. On the topic of the scaffolding app: * Pagination is the standard solution to the 'large number of entities' problem. However, there is a usability cost to pagination. It would be really nice to get rid of the pagination and just use a scrollbar. If you used the approach of SlickGrid (http:// wiki.github.com/mleibman/SlickGrid/), where you only rendered what was visible on the screen, you can render large numbers entities without the need for pagination. * Alternatively, you can just provide developers with the choice between using a scrollbar and with using pagination. This is what we have done internally - in practice, 80% of our crud pages are 'low cardinality' (e.g.: 300 entities) - and we show low cardinality pages by displaying all elements inside a standard ScrollPanel. For extra usability points, if you have a table, the headers should stay on screen as you scroll the data down. * Assuming we stick with pagination, why are there only 8 entities on a page? That wastes a lot of screen real estate, there is a big blank below. Ideally, the list would fill all available space on the page. That would be more difficult, but either way, but 8 is far too low if it is going to be set to a static number. * When you click 'create employee' the 4 input fields for employee creation appear below the search list. That works well enough if there are only 4 input fields, and 8 items on a page, as is in the demo. However, we had CRUD screens with 50 input fields. We also want to put a lot more than 8 items on a page. So, the input fields would need to be on their own page, replacing or overlaying the 8 entities in the list. This is one of those things where there is no one-size-fits all solution, but our experience is that a large number of input fields is more common than a small number. One last 'wishlist' point: * We've actually developed our own GWT-based CRUD infrastructure recently - versioning/duditing is one of the biggest reasons we ended up creating our own infrastructure instead of reusing an existing one. When an entity is created, it is created as 'v1'. When it is edited, we just create 'v2', mark it as current, and leave 'v1' alone. When the entity is deleted, we just mark it as deleted. Because of this, in addition to just CRUD screens, we also have an audit trail screen that lets users see all previous versions of an entity, when each change was made, and who made each change. And users can then select an older version of the entity and 'revert' back to that version. * Undo/redo fall nicely out of versioning as well - undoing an edit is just reverting back to the prior version * We haven't yet implemented it ourselves, but 'future dated changes' (changes that only take effect on a date in the future) and 'approved changes' (changes that must be approved by another user before they take effect) fall nicely into that pattern as well * I know we aren't the only company to have to deal with this, if GWT's built-in infrastructure had this, and did it really well, I believe it would be a huge win in the enterprise market. * Even if GWT's built in infrastructure didn't have this built in, this type of thing shows how important it is for the framework to be easily extendable, so that developers can add this to the framework if needed. --- Chi Hoang On Aug 9, 7:26 am, Chris Ramsdale cramsd...@google.com wrote: Thanks for all of the great feedback (and please, keep it coming). With these suggestions and some internal guidance, we're going to move on to fleshing out mocks. Once I have something tangible, I'll share it here. -- Chris On Fri, Aug 6, 2010 at 8:01 PM, martino martino.piccin...@gmail.com wrote: While I appreciate the richness of widgets and behaviours offered by framework like SmartGWT or GXT, I don't particularly like their windowish look and feel, also I don't think it's a particularly good idea promoting GWT powerfulness or web application in general by mimicking desktop application widgets aspect (how many useless web desktops simulating a windows
Re: Table Row Gaps
It sounds like this - https://developer.mozilla.org/en/Images,_Tables,_and_Mysterious_Gaps is what you're experience, On May 20, 11:14 pm, Craigo craig...@gmail.com wrote: When creating a Grid, FlexTable, VerticalPanel, or any other type of table, I couldn't get rid of the gaps in the rows. The gaps would only appear in Chrome and FF, but not in IE6. They were very small gaps (about 3 pixels high). Nothing seemed to work, setCellPadding, setCellSpacing, css with padding, margin, border-collapse, ... Finally figured out changing the doctype solved it. The default was: !doctype html When I changed it to: !DOCTYPE html PUBLIC -//W3C//DTD XHTML 1.0 Transitional//EN http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd; The row gaps disappeared! If there is a better way, please post. Thanks. -- 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-tool...@googlegroups.com. To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com. For more options, visit this group athttp://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-tool...@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: Texbox width greater than others
I've run into this problem before, it is a 'quirk' of the CSS
standards mode. Take a look at the following HTML:
!DOCTYPE html
html
body
input type='text' style='width: 300px;'br
select style='width: 300px;'/selectbr
button style='width: 300px;'nbsp;/buttonbr
div style='width: 300px; background-color: red;'nbsp;/div
input type='text' style='width: 300px; box-sizing: border-box; -moz-
box-sizing: border-box; -ms-box-sizing: border-box;-webkit-box-sizing:
border-box;'
/body
/html
In standards mode, the text box is wider than the other widgets. If
you try quirks mode (by removing the first doctype line), all widgets
are the same width. I bet the new project you tried is in quirks
mode, which would explain why you get identical widths.
In standards mode, the text box defaults to using the content box
model, so when you specify the width of the textbox, you are actually
specifying the width of the inner area, not including the padding or
border. If you force the text box to use the border box model (which
is what I did in the last row of that sample HTML), you'll see that
all the widgets line up again. Unfortunately, the box-sizing
parameter is not available in IE6 and IE7.
Other than reverting to quirks mode, the only solution i found was to
use deferred binding to create an alternative setWidth function which
will
1) In IE6/7, set the Width to width-4
void setWidth(TextBox textBox, int width) {
textBox.setWidth((width-4)+px); //4 being the default padding/
border widths of a textbox, you may need to change it if you overrode
it in your stylesheet
}
2) In all other browsers, set the width to the requested width, and
apply the border box model
void setWidth(TextBox textBox, int widtb) {
textBox.addStyleName(borderBoxModel); //this is the name of a css
class which sets the box-model properties
textBox.setWidth(width+px);
}
On Apr 11, 11:59 pm, Sagar Samag samag.sa...@gmail.com wrote:
Thank you, Kozura,
My problem got resolved. I copied the code to a new GWT Project and it is
working fine there without any change! But in the old project the same
strange behavior continues. I checked CSS files. They are identical. I could
not understand why this was happening.
Sagar
--
From: kozura koz...@gmail.com
Sent: Monday, April 12, 2010 10:37 AM
To: Google Web Toolkit google-web-toolkit@googlegroups.com
Subject: Re: Texbox width greater than others
Probably need to do panel.setCellWidth(text, 200px) since
VerticalPanel is doing implemented with a table. If lined up
formatting is key you might find other panel widgets like Grid to be
easier.
On Apr 11, 10:23 pm, Sagar Samag samag.sa...@gmail.com wrote:
Am I missing something? I have very simple code to display a TextBox, a
Dropdown and a Button. Why is the width of the Textbox greater than
others? I checked in IE6, IE8 and Mozilla.
TextBox text = new TextBox();
ListBox list = new ListBox();
Button button = new Button(Click me!);
text.setWidth(200px);
list.setWidth(200px);
button.setWidth(200px);
VerticalPanel panel = new VerticalPanel();
panel.add(text);
panel.add(list);
panel.add(button);
RootPanel.get().add(panel);
I am in the middle of code that needs abstraction over the widget. I need
to display different widgets without knowing what they are. Different
widths of controls are screwing my plans.
Can someone help me on this?
Thanks and Regards
Sagar Samag
--
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-tool...@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-tool...@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: Servlet Session
RemoteServiceServlet has a getThreadLocalRequest() method which returns a HttpServletRequest. With the HttpServletRequest, you can call the standard getSession() method On Mar 22, 5:18 am, guest23 dav2...@gmail.com wrote: Hi there, gwt rpc is a nice feature! Is it possible to get a HTTP Session inside RemoteServiceServlet? User does login over normal Servlet. I store the login token in session. Thanks for help! -- 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-tool...@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: Announcing GWT 2.0.1
Great job! One question - one of the bugs listed as being fixed was 'Standard.css missing new layout styles'. I'm having trouble finding these new layout styles. My expectation was that standard.css would be updated with the new styles. Standard.css on the 2.0.1 can be seen here: http://code.google.com/p/google-web-toolkit/source/browse/tags/2.0.1/user/src/com/google/gwt/user/theme/standard/public/gwt/standard/standard.css It looks identical to standard.css on 2.0.0, which can be seen here: http://code.google.com/p/google-web-toolkit/source/browse/tags/2.0.0/user/src/com/google/gwt/user/theme/standard/public/gwt/standard/standard.css However, standard.css on the trunk DOES seem to be updated with new styles: http://code.google.com/p/google-web-toolkit/source/browse/trunk/user/src/com/google/gwt/user/theme/standard/public/gwt/standard/standard.css Was this missed, or am i misunderstanding what this bug is referring to? --- Chi On Feb 2, 7:01 pm, Miguel Méndez mmen...@google.com wrote: The GWT 2.0.1 point release is now available for download. It contains fixes for bugs found in the 2.0.0 release. Potentially breaking changes and fixes - Fixed a bug in how code generators collect method arguments from generated source, which impacted the Messages interfaces generated for UiBinder template files. In GWT 2.0, such argument names were incorrectly changed to ARGn. Most GWT applications will be unaffected, but external systems relying on these names may need to be updated. - The development mode server will, by default, only bind to localhost which will break cross-machine debugging. You can get the old behavior by specifying -bindAddress 0.0.0.0. Please see issue (#4322http://code.google.com/p/google-web-toolkit/issues/detail?id=4322) for more details. For webAppCreator-generated ant files, you can pass this with ant -Dgwt.args=-bindAddress 0.0.0.0 devmode. - The CurrencyList/CurrencyData APIs are now public - if you were relying upon these classes in their non-public location, you should only need to update your imports. Noteworthy Fixed Issues - UiBinder Image class with resource attribute, removes styles on that image (#4415http://code.google.com/p/google-web-toolkit/issues/detail?id=4415 ) - Widgets lose focus if its placed on FocusPanel (Opera, Safari) (#1471http://code.google.com/p/google-web-toolkit/issues/detail?id=1471 ) - Standard.css missing new layout styles (#4429http://code.google.com/p/google-web-toolkit/issues/detail?id=4429 ) - Remove method in SplitLayoutPanel is broken (#4217http://code.google.com/p/google-web-toolkit/issues/detail?id=4217 ) - Splitter constructor hard codes the background color of the splitter to white (#4335http://code.google.com/p/google-web-toolkit/issues/detail?id=4335 ) - Image should provide method to set alternative text (#4335http://code.google.com/p/google-web-toolkit/issues/detail?id=4335 ) - CssResource cannot parse unescaped '-', '_' in class selectors and unknown at-rules (#3946http://code.google.com/p/google-web-toolkit/issues/detail?id=3946 ) - Focusable implementation breaks ScrollPanels in Safari (#1313http://code.google.com/p/google-web-toolkit/issues/detail?id=1313 ) - RequestBuilder restricted to GET and POST (#3388http://code.google.com/p/google-web-toolkit/issues/detail?id=3388 ) - HTMLTable.Cell.getElement() calls getCellFormatter().getElement() with row and column swapped RequestBuilder restricted to GET and POST (#3757http://code.google.com/p/google-web-toolkit/issues/detail?id=3757 ) - MenuBar steals focus when hovered (#3884http://code.google.com/p/google-web-toolkit/issues/detail?id=3884 ) - TabLayoutPanel tabs don't line up properly on IE (#4447http://code.google.com/p/google-web-toolkit/issues/detail?id=4447 ) - webAppCreator produces ant build files which support the gwt.args property for passing additional flags to the gwtc and devmode rules, such as ant -Dgwt.args=-style PRETTY gwtc. See the GWT issue tracker for the complete list of bug fixes and enhancementshttp://code.google.com/p/google-web-toolkit/issues/list?can=1q=statu... in this release. -- Miguel on behalf of the GWT Team -- 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-tool...@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: Announcing GWT 2.0.1
This seems to have the same problem as the styles The trunk version of com.google.gwt.user.client.ui.Image has getAltText() and setAltText() methods, but those methods are not in the 2.0.0 or the 2.0.1 versions. On Feb 3, 3:58 pm, Thad thad.humphr...@gmail.com wrote: Where and how has this been done? How can I use it? The only reference I see to alt is in com.google.gwt.dom.client.ImageElement, getAlt() and setAlt(), and the code is the same as in 2.0.0. On Feb 2, 9:01 pm, Miguel Méndez mmen...@google.com wrote: The GWT 2.0.1 point release is now available for download. It contains fixes for bugs found in the 2.0.0 release. ... - Image should provide method to set alternative text (#4335http://code.google.com/p/google-web-toolkit/issues/detail?id=4335 ) ... -- 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-tool...@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] Re: now.. afetr GWT 2.0?
- Another vote for data binding + validation - Rich datagrid component, similar to the PagingScrollTable in the incubator - Inbuilt support for server push (comet) - We should be able to exclude methods from GWT compilation using an annotation (e.g.: @GwtIncompatible). This would make it easier to share classes between the server side and the client side. Right now, if we want to add a method that uses classes which are not GWT- compatible, it has to be put into a separate class, even if the method is only ever called by server side code. - Get an early start on Java 7 support (i know it is a moving target, especially the closures part, but there was a long wait for Java 5 support in GWT 1.5, and it would be nice if there was a much shorter wait for Java 7 support) On Dec 16, 10:01 am, Bruce Johnson br...@google.com wrote: Working on a draft one. What do folks here think is important? On Wed, Dec 16, 2009 at 7:42 AM, tfreitas tfrei...@gmail.com wrote: What about roadmap? -- http://groups.google.com/group/Google-Web-Toolkit-Contributors -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Announcing: The gwt-rpc-annotation library
Announcing the gwt-rpc-annotation library -
http://code.google.com/p/gwt-rpc-annotation/
This library simplifies the development of GWT-RPC services through
the use of a JSR-269 annotation processor.
It is currently being used extensively at Solium Capital - http://www.solium.com
- and we are happy to contribute it back to the community.
Normally, when implementing a GWT-RPC service, three files must be
maintained
A) A class to implement the service
B) An interface for the service which defines all the exposed methods
C) An asynchronous interface, which is used when the service is
called from the client side
With this annotation processor, you simply need to implement the class
which implements the service. You can then use an annotation
to mark a method as something which should be exposed, and the
annotation processor will automatically generate both interfaces for
you.
In other words, all you have to do is write a method and annotate it
like follows:
@GwtRpcServlet
public class FooServiceImpl extends RemoteServiceServlet implements
FooService {
@GwtRpcMethod
public String foo() {
return bar;
}
}
And the annotation processor will automatically generate the interface
classes for you:
public interface FooService extends RemoteService {
String foo() {
}
public interface FooServiceAsync {
void foo(AsyncCallbackString async);
}
To use this library:
- Annotate methods to be exposed with the @GwtRpcMethod annotation
- Servlets which contain methods to be exposed need be annotated with
the @GwtRpcServlet annotation.
- This annotation has an optional remoteServiceRelativePath
argument - if specified, it will put the value in the
@RemoteServiceRelativePath annotation in the generated interface
A sample is provided in the sample directory.
Java 6 is required, as JSR-269 was only introduced in Java 6.
The generation of these classes can be configured by creating a custom
implementation of the GwtRpcAnnotationConfig. This custom
implementation is passed to the annotation processor via the
gwtRpcAnnotation.config parameter.
By implementing this class, you can:
- Control the package name of the generated interfaces
- Add standard exceptions to all exposed GWT-RPC methods. GWT-RPC
requires that all exceptions thrown by a method are declared in the
interface. We use this to add in exceptions that aren't necessarily
thrown by the method itself, but are instead thrown by generic code in
RemoteServiceServlet.onAfterRequestDeserialized which implements some
cross-cutting-concerns
- Add any additional common code to all interfaces, for example if
you want a common static variable in all your interfaces.
Enjoy!
--
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-tool...@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=.
Re: ListBox performance problem,with many items
First of all, a listbox with 8000 typically is unlikely to be user
friendly, perhaps you should be using a SuggestBox instead?
However, if you really do want a listbox, you're on the right track in
that using HTML is the only way to get reasonable performance with a
large number of elements in IE.
The reason your second example is still slow is because of all the
string concatenation overhead - you should be using a stringbuilder
here.
I put together a quick test using StringBuilder:
StringBuilder htmlSelect = new StringBuilder();
htmlSelect.append(select);
for (int i = 0; i 8000; i++) {
htmlSelect.append(option).append(i).append(/option);
}
htmlSelect.append(/select);
HTML html = new HTML(htmlSelect.toString());
RootPanel.get().add(html);
On my eee netbook running IE6:
- your first example, using ListBox directly takes 70 seconds for the
8000 elements
- your second example, using HTML but with +=, takes 24 seconds for
8000 elements
- my example, using HTML with StringBuilder, takes 0.6 seconds
Unfortunately, by using HTML instead of ListBox, you lose all the nice
methods available in ListBox.
I don't think ListBox.wrap() will work if you are creating the listbox
this way, but if you use a HtmlPanel and get the native Select
element, I believe you can do something like this:
public class MyListBox extends Composite {
private final SelectElement _select;
public MyListBox() {
String id = HTMLPanel.createUniqueId();
StringBuilder htmlSelect = new StringBuilder();
htmlSelect.append(select id=').append(id).append(');
for (int i = 0; i 8000; i++) {
htmlSelect.append(option).append(i).append(/option);
}
htmlSelect.append(/select);
HTMLPanel htmlPanel = new HTMLPanel(htmlSelect.toString());
_select = SelectElement.as(htmlPanel.getElementById(id));
initWidget(htmlPanel);
}
public String getValue(int index) {
return _select.getOptions().getItem(index).getValue();
}
public int getSelectedIndex() {
return _select.getSelectedIndex();
}
//etc...
}
Anyone know of any downfalls to this approach?
On Jul 30, 8:59 am, Enea eneager...@gmail.com wrote:
Hi.
I'm populating ListBoxwith 8000 items.
ListBoxlb=newListBox();
for(int i=0;i8000;i++)
lb1.addItem(+i);
RootPanel.get().add(lb1);
In my real project I have to add items from a big list of cities, but
anyway.
That takes 5 seconds on my developer machine, in hosted mode.
In IE is a wasting 15-20 seconds :(
Trying making some test, it result that with Safari is working very
good...slower than a second.
I have to develop for IE...unfortunately.
So, i've tried that:
String HtmlSelect=select;
for(int i=0;i8000;i++)
HtmlSelect+=option+i+/option;
HtmlSelect+=/select;
HTML html=new HTML(HtmlSelect);
RootPanel.get().add(html);
But that give me slower result...
this is the same issue
ofhttp://code.google.com/p/google-web-toolkit/issues/detail?id=49
any faster solution?
Thanks in advance!
--~--~-~--~~~---~--~~
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: Use a FormPanel without submitting to a URL?
Yes, if you are not submiting a form, you won't really need a FormPanel at all, you can just put a TextBox/ListBox/CheckBox/etc objects into a panel of your choosing. Then, you can create a Button or link or anything which reads from the input objects using TextBox.getText()/ ListBox.getSelectedIndex() / CheckBox.isChecked() / etc If you want to send that data through a server, you can just do a RPC call from that point, or alternatively you can use the data entirely on the client side. On Jan 6, 2:27 pm, hortitude hortitude.eyeb...@gmail.com wrote: Is it possible to use a FormPanel with a submit button, but instead of having the values sent to a server, simply process the result within my GWT app? Here's what I am doing: I have a Form that is generated dynamically (the user can add rows to the form through the UI). I want to be able to look at those values within my application. I figured a FormPanel would be the easiest -- as I could easily take advantage of it gathering data from each of the elements and creating name/value pairs for the data. Can anyone help? Thanks! --~--~-~--~~~---~--~~ 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: How do I make a pretty, easy to use button without making custom images for each one?
I've had great success using the 'sliding doors' technique for buttons. Just google for the phrase - here is a good example of the css needed - http://www.jorkas.com/lab/css/rounded_button/index.html I basically just created my own 'MyButton' class which extends InlineHTML and populates it with the html needed for the button, e.g.: a href=\#\ onclick=\javascript: return false\ class=\myButton \span + buttonLabelHtml + /span/a Then, I can instantiate with whatever label i want when I need a button, add clickListeners, etc. On Jan 2, 4:00 am, dduck anders.johansen.a...@gmail.com wrote: Hi, I would like to make abuttonthat looks like this: (|| text ||) ...where ( is a rounded left-end of thebutton, ) is a rounded right- end of thebutton, || is a background and text can be specified e.g. at creation. Thus, all buttons of this type would share the same style, but not the same text on the face of it. Examples: (|| OK ||) (|| My very longbuttontext ||) How would I go about this, without having to generate each individualbuttonas an image in my drawing program? Anders --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
