Re: Feedback Requested: Preview of new GWT Style Theme

[Chi H]

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  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  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 
> > wrote:
>
> > > 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  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

[Chi H]

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  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 wrote:
>
> > 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  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

[Chi H]

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  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...

[Chi H]

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  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  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 desktop inside your browse

Re: Table Row Gaps

[Chi H]

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  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:
> 
>
> When I changed it to:
>  "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

[Chi H]

I've run into this problem before, it is a 'quirk' of the CSS
standards mode.  Take a look at the following 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"  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" 
> Sent: Monday, April 12, 2010 10:37 AM
> To: "Google Web Toolkit" 
> 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"  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

[Chi H]

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  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

[Chi H]

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  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  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
> > (#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.

Re: Announcing GWT 2.0.1

[Chi H]

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  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
> (#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 
> (#4415
>    )
>    - Widgets lose focus if its placed on FocusPanel (Opera, Safari)
> (#1471
>    )
>    - Standard.css missing new layout styles
> (#4429
>    )
>    - Remove method in SplitLayoutPanel is broken
> (#4217
>    )
>    - Splitter constructor hard codes the background color of the splitter to
>    white 
> (#4335
>    )
>    - Image should provide method to set alternative text
> (#4335
>    )
>    - CssResource cannot parse unescaped '-', '_' in class selectors and
>    unknown at-rules
> (#3946
>    )
>    - Focusable implementation breaks ScrollPanels in Safari
> (#1313
>    )
>    - RequestBuilder restricted to GET and POST
> (#3388
>    )
>    - HTMLTable.Cell.getElement() calls getCellFormatter().getElement() with
>    row and column swapped RequestBuilder restricted to GET and POST
> (#3757
>    )
>    - MenuBar steals focus when hovered
> (#3884
>    )
>    - TabLayoutPanel tabs don't line up properly on IE
> (#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
> enhancements
> 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.

Announcing: The gwt-rpc-annotation library

[Chi H]

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(AsyncCallback 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

[Chi H]

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("");
for (int i = 0; i < 8000; i++) {
htmlSelect.append("").append(i).append("");
}
htmlSelect.append("");

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("");
for (int i = 0; i < 8000; i++) {
htmlSelect.append("").append(i).append("");
}
htmlSelect.append("");

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  wrote:
> Hi.
>
> I'm populating  ListBoxwith 8000 items.
>
> ListBoxlb=newListBox();
> for(int i=0;i<8000;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="";
> for(int i=0;i<8000;i++)
> HtmlSelect+=""+i+"";
>
> HtmlSelect+="";
> 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?

[Chi H]

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  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?

[Chi H]

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.:
"" + buttonLabelHtml + ""

Then, I can instantiate with whatever label i want when I need a
button, add clickListeners, etc.



On Jan 2, 4:00 am, dduck  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
-~--~~~~--~~--~--~---