On Mon, Oct 14, 2013 at 10:53 AM, Matti Tahvonen ma...@vaadin.com wrote:
IMHO the right way to fix the sub pixel issues would be to just start
using double as return value. For average GWT users this causes little or
no changes at all, for widget developers compilation errors are easy to
fix.
On Tue, Oct 15, 2013 at 11:13 AM, Matthew Dempsky mdemp...@google.comwrote:
I've been thinking about how we'd cope with this in Google's code base,
and I think we could handle a change-return-type-to-double change
reasonably gracefully. I'd probably tackle it as (glossing over some
On Tue, Oct 15, 2013 at 8:18 AM, John A. Tamplin j...@jaet.org wrote:
You could make this completely foolproof by introducing an extra step -
add a new wrapper type GwtInt which behaves just like Integer except it
isn't autoboxed. Then have toInt32(GwtInt), and fix all the compile errors
to
On Tue, Oct 15, 2013 at 11:51 AM, Matthew Dempsky mdemp...@google.comwrote:
On Tue, Oct 15, 2013 at 8:18 AM, John A. Tamplin j...@jaet.org wrote:
You could make this completely foolproof by introducing an extra step -
add a new wrapper type GwtInt which behaves just like Integer except it
On Tue, Oct 15, 2013 at 8:54 AM, John A. Tamplin j...@jaet.org wrote:
No, because you can use foolproof automated refactoring tools.
Ah, our internal automated refactoring tools have improved significantly
within the last year (e.g., Louis Wasserman's Scalable, Example-Based
Refactorings with
Hi,
IMHO the right way to fix the sub pixel issues would be to just start using
double as return value. For average GWT users this causes little or no
changes at all, for widget developers compilation errors are easy to fix.
Also the breaking change highlights potential sub pixel related
Perhaps we can just avoid the trouble and introduce sub-pixel APIs only
with the new Elemental(*) - not from old APIs (including 3.0 release). In
the mean-time we can improve the internals of current widgets to better
utilize subpixel values like the Daniel's patch.
* I'm planning to write a doc
