methods.
I added style injection via Gen2CssInjector. (and added the images and
css to com.google/gwt/gen2/widgetbase/public)
The patch is in the attached file.
Thanks,
Uwe
On Fri, Feb 27, 2009 at 5:13 PM, Emily Crutcher e...@google.com wrote:
The changes look great. Thank you for doing
The changes look great. Thank you for doing this. Any chance you could you
create a gen2 version of SliderBar and deprecate the widgetideas version
instead on modifying the widgetideas version in place?
We are slowly retiring the old widgetideas package in favor of the gen2
package hierarchy, so
Thanks for the fast turn around, committed as r4898
2009/2/27 jlaba...@google.com
LGTM
http://gwt-code-reviews.appspot.com/7804
--
There are only 10 types of people in the world: Those who understand
binary, and those who don't
--~--~-~--~~~---~--~~
Committed at r4885
On Tue, Feb 24, 2009 at 6:16 PM, Ray Ryan rj...@google.com wrote:
LGTM
Nah, just rename and submit.
On Tue, Feb 24, 2009 at 3:13 PM, Emily Crutcher e...@google.com wrote:
Hmm Any reasons I can think of dissolve under the argument of that
what I'd look for. Do you
:
AbstractSuggestionBoxT extends Suggestion
SuggestionBox extends AbstractSuggestionBoxSuggestion
rjrjr
On Mon, Feb 23, 2009 at 7:15 PM, Emily Crutcher e...@google.com wrote:
On Mon, Feb 23, 2009 at 7:04 PM, Isaac Truett itru...@gmail.com wrote:
The API documentation has this to say on the subject
and impractical to me. And my job title
used to be Senior Pedant.
On Tue, Feb 24, 2009 at 7:44 AM, Emily Crutcher e...@google.com wrote:
It could work, though I found when I used this technique with
DatePicker (DatePicker extends AbstractDatePickerMonthSelector,
CalandarView), there was some
Thanks for the quick turn around!
commited at r4853
2009/2/24 rj...@google.com
LGTM
http://gwt-code-reviews.appspot.com/7801
--
There are only 10 types of people in the world: Those who understand
binary, and those who don't
--~--~-~--~~~---~--~~
On Mon, Feb 23, 2009 at 7:04 PM, Isaac Truett itru...@gmail.com wrote:
The API documentation has this to say on the subject:
[...] To send back a DTO with each suggestion, extend the Suggestion
interface and define a getter method that has a return value of the
DTO's type. Define a class
LGTM, thanks for the terrific turn around time!
On Mon, Feb 9, 2009 at 9:43 AM, Jaime Yap jaime...@google.com wrote:
Super simple fix. Had the order of operators swapped in one of the
constructor overloads for Color.
Affected files:
src/com/google/gwt/widgetideas/graphics/client/Color.java
branch to check the -XdisableClassMetadata flag.
@ecc, this reduces showcase by about 10%. I would suspect that in an
RPC-heavy application, this flag combined with enabling obfuscated
idents in RPC payloads, should produce similar savings.
WOOT!
--
Bob Vawter
Google Web Toolkit
Do you have any numbers of how much this shrinks compiled output, as this
seems like a terrific change! Thanks for doing it :-).
Cheers,
Emily
On Fri, Feb 6, 2009 at 1:21 PM, BobV b...@google.com wrote:
On Thu, Feb 5, 2009 at 12:28 AM, BobV b...@google.com
Only the current gwt-incubator trunk is validated to work against the
release jar. We'll be releasing a new gwt-incubator jar soon, but I'm still
working on getting all the demos to build and display correctly.
On Thu, Feb 5, 2009 at 12:24 PM, Scott Blum sco...@google.com wrote:
Hi stuckagain,
Can you create a test case that is reproducible and add an issue to the
issue tracker? After you do that, feel free to e-mail me the issue id and
I'll take a look.
The strange thing about your problem is that the load listeners are actually
just adapted load handlers now, so getting different
offer any
solutions:
Emily Crutcher
wrote here:
http://groups.google.com/group/Google-Web-Toolkit-Contributors/browse_thread/thread/a63a973ee627dded
I noticed a few styling issues:
- Firefox puts a box around the selected tree item (see attached
image). Can it be removed
On Wed, Feb 4, 2009 at 10:02 AM, nw...@google.com wrote:
looks great, thanks for doing this. I have one minor question/comment.
http://gwt-code-reviews.appspot.com/2801/diff/1/7
File src/com/google/gwt/gen2/widgetbase/public/FastTree.css (right):
Here is the change:
http://code.google.com/p/google-web-toolkit-incubator/source/detail?r=1466
--
There are only 10 types of people in the world: Those who understand
binary, and those who don't
--~--~-~--~~~---~--~~
Committed as r1467
On Mon, Feb 2, 2009 at 6:08 PM, Emily Crutcher e...@google.com wrote:
Yep, thanks for the review!
On Mon, Feb 2, 2009 at 5:46 PM, itru...@gmail.com wrote:
LGTM, with the removal of stray debug code from DropDownPanel.
http://gwt-code-reviews.appspot.com/2402/diff/1
} -x...@{jvm.stack} /
...
*and then each use can set its own limits, like so:*
gwt.junit jvm.heap=1G jvm.stack=256K ... /
*
On Tue, Feb 3, 2009 at 11:53 AM, Emily Crutcher e...@google.com wrote:
Here is the change:
http://code.google.com/p/google-web-toolkit-incubator/source/detail?r
seen more than one stack change required recently.
On Tue, Feb 3, 2009 at 12:33 PM, Emily Crutcher e...@google.com wrote:
For the heap, I think that would be a good change. The stack though in
general, is not something programs should have to mess with.
On Tue, Feb 3, 2009 at 11:59 AM
One warning for you, the performance characteristics of having a grid be
attached or detached can be very different for Firefox and IE. If you are
trying to use this technique in your own code, you might want to double
check the effect on both browsers.
In terms of gwt-incubator, we are
LGTM
On Thu, Jan 15, 2009 at 10:36 PM, fabb...@google.com wrote:
Reviewers: ecc,
Description:
Small tweak to set the env property first, so that user-preference
properties in build.properties can refer to environment variables, and
to remove the check on gwt.home, because it's going to be
...@google.com wrote:
Log.i()? Yuck.
On Thu, Jan 15, 2009 at 12:54 PM, Emily Crutcher e...@google.com
wrote:
In some ways, android is now a sister project of gwt. For our static
logging, we use methods like
Log.info(String message, String category) the same method in android is
Log.i
() and Log.i(). Is the extra verbosity worth it?
On Fri, Jan 16, 2009 at 11:30 AM, Emily Crutcher e...@google.com wrote:
Both actually, though if we don't change the method names, changing the
order of the parameters without breaking everyone currently using logging
would be almost
How about WrappedClickListener instead then? I want a prefix rather then a
suffix because we don't want these classes to show up prominently when you
do a type search in an ide.
On Fri, Jan 16, 2009 at 2:57 PM, jlaba...@google.com wrote:
Everything looks good except the names. If we are
The reasons we narrow the type is to allow the following:
1. the ability to have users deprecate their listeners cleanly
2. the ability to create an internal gwt reporting system that gives
users feedback on where/what their handlers are used
3. the ability to, in a later release,
, Jan 15, 2009 at 3:10 PM, Emily Crutcher e...@google.com wrote:
Yep, that's a requirement, the only question, in my mind, is how to name
the modules.
On Thu, Jan 15, 2009 at 2:09 PM, Ray Cromwell cromwell...@gmail.comwrote:
Being able to pick out only base events is crucial for me
Thanks, committed as r4448.
On Wed, Jan 14, 2009 at 10:27 AM, John LaBanca jlaba...@google.com wrote:
LGTM
One nit:
You set bottom = (int) (progress * offsetHeight), but you could just use
bottom = top + height or even just bottom = height.
Thanks,
John LaBanca
jlaba...@google.com
The general idea of decoupling the handler manager from the actual events
seems like a great goal, and I think we are on the right track, a couple of
problems with the current implementation...
---
Removing getHandlers() unforutnately makes firing most logical events
this and used a method off of a EventDispatchUtil class.
But we don't actually recycle events anywhere, do we? This is one of the
open issues left from the review process as the event stuff was merged in to
the 1.6 branch last year--why do we have this complicated mechanism that we
Daniel,
You have some good points and what you are describing is almost exactly
the date box we initially had in gwt-incubator. We ran into a few
significant problems that made us change to the current design:
1. DateTimeFormat represents a very sophisticated API, it was difficult
1. DateTimeFormat represents a very sophisticated API, it was
difficult
for users to replace the formatting/parsing of dates because, to do so
they
needed to understand the internals of the date time format class.
Try extending DateTimeFormat rather then using the predefined
not decouple DateBox and DateBox.Format it is just adding
unnecessary complexity IMO.
On Jan 13, 7:10 pm, dflorey daniel.flo...@gmail.com wrote:
I know this is nitpicking, but some comments inline
On Jan 13, 6:53 pm, Emily Crutcher e...@google.com wrote:
Daniel,
You have some good
LGTM
On Fri, Jan 9, 2009 at 11:53 AM, jlaba...@google.com wrote:
Reviewers: ecc,
Description:
The keyCode is a read only attribute in all browsers except IE. This
patch deprecates the setKeyCode method so we can remove it in a future
release.
Here is the associated issue:
By the way, now that gwt-incubator is sourced against 1.6, if you can
retarget your DropDownDatePicker for 1.6 and the com.google.gwt.gen2.picker
package I'd love to review it.
On Fri, Dec 5, 2008 at 1:08 AM, Emily Crutcher e...@google.com wrote:
Also, the code should be reviewed before
+1 from me.
On Thu, Jan 8, 2009 at 4:52 PM, John LaBanca jlaba...@google.com wrote:
Contributors -
Description:
=
I proposed that we deprecate DOM#eventSetKeyCode() and TextBoxBase#setKey()
because they only work in IE and the same functionality would be difficult
to simulate on
In the library code we constantly use *Impl to denote a class that users
should not look at, but here we we have *Impl annotations that is part of a
public API. Could we modify the name slightly so we can keep the *Impl
convention consistant throughout the gwt code base?
On Wed, Jan 7, 2009 at
the *Impl type is an annotation, interface, or
class.
On Wed, Jan 7, 2009 at 12:26 PM, Bruce Johnson br...@google.com wrote:
@Emily: Does the fact that it's an annotation not make it completely clear?
We don't use *Impl on interfaces anywhere (do we?)
On Wed, Jan 7, 2009 at 11:46 AM, Emily
, I believe that the simplicity and code savings
of having a simplified HandlerManager (i.e. one that just uses JRE classes
or simple native maps) would be worth it. IMHO, anyway.
On Mon, Dec 1, 2008 at 11:36 AM, Emily Crutcher e...@google.com wrote:
Joel,
Thank you so much for looking
Can we automatically include all shared and client (excluding impl)
packages instead of manually listing them out? It seems like that may be
less of a maintenance headache at least for the user package organization.
On Mon, Jan 5, 2009 at 11:34 AM, Freeland Abbott gwt.team.fabb...@gmail.com
will be called with fireEvent=false.
Once this is fixed I'd like to implement a TimeBox similar to DateBox
but using a more usefull TimePicker (seehttp://
code.google.com/p/google-web-toolkit-incubator/issues/detail?i...
)
Cheers,
Daniel
On 30 Dez. 2008, 18:33, Emily Crutcher e
Dear Daniel,
I hope you are having a great holiday. I've added a gen2 version of
TimePicker and DatePickerPicker in a new com.google.gwt.gen2.picker package.
It now depends upon the gwt 1.6 date picker and event system. If you could
review my changes and make any more you deem appropriate,
itru...@gmail.com
wrote:
Whatever happened to this change? I noticed issue #2739 requesting
hideSuggestions() and this patch would seem to satisfy that request.
Is there any chance of this patch or something similar making 1.6?
On Tue, Apr 29, 2008 at 4:25 PM, Emily Crutcher e
LGTM.
On Mon, Dec 22, 2008 at 3:17 PM, jlaba...@google.com wrote:
Here is the bug:
http://code.google.com/p/google-web-toolkit/issues/detail?id=504
http://gwt-code-reviews.appspot.com/1803
--
There are only 10 types of people in the world: Those who understand
binary, and those who
This seems like the right model of behavior. I wonder if we could figure out
a way to tweak the API exposing the behavior though when you get back from
vacation? As a user, I think I might get confused by the interactions of
setAlwaysAutoHide(), setAutoHidePartner,
LGTM
On Mon, Dec 22, 2008 at 11:41 AM, jlaba...@google.com wrote:
Reviewers: ecc,
Description:
The dateBoxFormatError style name is applied to a DateBox with an
invalid date entry. This patch adds style definitions to the dark and
chrome style themes. Style definitions were already added
Good point, added as issue 3234.
On Fri, Dec 19, 2008 at 3:40 AM, Andy Moorley andy.moor...@gmail.comwrote:
Hi there
Been struggling a bit with some of the effects of the GWT style sheets
in an attempt to get round IE6 alpha transparancy.
In the top of standard.css
make sense!
Cheers,
Emily
On Mon, Dec 29, 2008 at 6:41 PM, Ray Cromwell cromwell...@gmail.com wrote:
Is the /releases/1.6 going to be the branch that becomes 1.6? There
are two other 1.6 branches in /branches as well.
-Ray
On Mon, Dec 29, 2008 at 1:28 PM, Emily Crutcher e
And yep, for the gwt code base, the releases/1.6 will become the 1.6
release.
Cheers,
Emily
On Mon, Dec 29, 2008 at 9:15 PM, Emily Crutcher e...@google.com wrote:
I think you might be thinking about GWT rather then gwt-incubator.
gwt-incubator releases only has two sub
John, as I just got a vacation message from Ray, could you finish the review
of this patch? The only unreviewed part is adding the abandon method as per
Ray's request.
Thanks!
Emily
http://gwt-code-reviews.appspot.com/1201
On Fri, Dec 19, 2008 at 1:20 AM, Emily Crutcher e
, Emily Crutcher e...@google.com wrote:
Isaac,
Could you review this patch? It re-jiggers the ant tasks to make
build-demos a bit more efficient, because after I moved the other demos
in,
the task was taking a while.
At some point, we might think about making the build/build
LGTM, though I think you mean to add I18n to the single issue module. Also,
did you check how the samples looked now that you removed the spacing?
Thanks,
Emily
On Fri, Dec 19, 2008 at 1:18 PM, John LaBanca jlaba...@google.com wrote:
ping
Please review this when you
(yet). I don't see any problem
with deleting compiled-demos for now. Looks good with the addition of
the initial delete?
On Wed, Dec 17, 2008 at 9:03 PM, Emily Crutcher e...@google.com wrote:
That is absolutely awesome! Here are the gen2 widgets using your patch
posted on app engine.
http
On Thu, Dec 18, 2008 at 6:42 PM, rj...@google.com wrote:
Seems like we're missing a method from the Format interface?
http://gwt-code-reviews.appspot.com/1201/diff/12/14
File user/src/com/google/gwt/user/datepicker/client/DateBox.java
(right):
),
that would also be a very big help, because it would avoid a whole bunch of
manually editing and clicking on urls.
On Wed, Dec 17, 2008 at 11:01 AM, Isaac Truett itru...@gmail.com wrote:
+1. Let me know if I can assist with the transition.
On Wed, Dec 17, 2008 at 10:25 AM, Emily Crutcher e
For gwt-incubator users who are using svn tip from gwt-1.6 or gwt-trunk, we
currently are in a confusing situation of having two different, almost
identical event systems: one in gwt-incubator itself and one in gwt. In
many cases, both are currently in use. Additionally, we have tons of
We have introduced a new interface into DateBox called Format and providing
a DefaultFormat class. You can see the code
herehttp://gwt-code-reviews.appspot.com/1201.
this interface has the following advantages:
- As the date parsing is now completely replaceable, our default parser
can be
cal state.
You can add an abandon() method to the format lifecycle, to tell it to
clean up its crap. To make sure my formatter doesn't interfere with someone
else's styling, change the CSS class name for errors to reflect that the
formatter owns it, not the DateBox, e.g.
#removeStyleDependentName here, right?
rjrjr
On Thu, Dec 18, 2008 at 11:15 AM, Emily Crutcher e...@google.com wrote:
When a default format instance receives a format or parse request, how
does it know whether it needs to remove its error style name from that date
box other then getting the current
That is absolutely awesome! Here are the gen2 widgets using your patch
posted on app engine.
http://collectionofdemos.appspot.com/demo/index.html
When the build.demos target is invoked, is there any reason we should not
clear the entire directory first? That would save us from including old
demos
that we might want to make is to filter out the -aux
dirs from compiled-demo when building the zip. They're harmless but
extraneous.
On Tue, Dec 16, 2008 at 10:01 AM, Emily Crutcher e...@google.com wrote:
Isaac,
Could you review these small extra changes to the gwt-incubator
build
Daniel,
Could you review this change? Focus Panel no longer sinks Focus,
Key, or Mouse events by default. Therefore, adding a sink events call to
SliderBar itself. Code:
http://code.google.com/p/google-web-toolkit-incubator/source/detail?r=1322
Thanks,
Emily
to dist, as we want the sanity
check that building the demos provides when we do a full distribution.
On Mon, Dec 15, 2008 at 5:21 PM, Isaac Truett itru...@gmail.com wrote:
Thanks. Committed as r1319.
On Mon, Dec 15, 2008 at 5:14 PM, Emily Crutcher e...@google.com wrote:
LGTM.
On Mon
Should we, in general, be adding padding to RadioButtons and CheckBoxes, as
won't other users have the same problems?
On Tue, Dec 16, 2008 at 11:40 AM, jlaba...@google.com wrote:
Reviewers: ecc,
Description:
Description:
This patch addresses a bunch of Tree alignment issues:
The reasons I would prefer to use the gwt-incubator.jar is because that
gives us a quick sanity check that the gwt-incubator jar is actually
including everything needed to run the demos!
+ project.src and project.bin can be overridden, if desired (super
could be overridden if it used a
, 2008 at 10:24 AM, Emily Crutcher e...@google.com wrote:
Amit, could you review this change?
Adding gwt-externals directory to gwt-incubator trunk in order to support
the use of gwt's build-tools directory.
Change at:
http://code.google.com/p/google-web-toolkit-incubator/source/detail?r=1302
Thanks! Updated comment to reflect new handler names rather then the old
listener ones.
Committed at r4305.
On Thu, Dec 11, 2008 at 10:22 AM, John LaBanca [EMAIL PROTECTED] wrote:
I'm getting server errors, so here is your review:
// Only fire the mouseEnter event if it's coming from
Cool, looking forward to seeing the new patch!
Per our conversation, onPreviewNativeEvent will be exposed, but will
only contain minimal code by default. The bulk of the code will be in a
new method previewNativeEvent()
Why expose onPreviewNativeEvent at all?
--
There are only 10 types
Amit, could you review this change?
Adding gwt-externals directory to gwt-incubator trunk in order to support
the use of gwt's build-tools directory.
Change at:
http://code.google.com/p/google-web-toolkit-incubator/source/detail?r=1302
Thanks,
Emily
--
There are only 10 types
On Tue, Dec 9, 2008 at 12:42 AM, John LaBanca [EMAIL PROTECTED] wrote:
Internet Explorer now works the same as Firefox. That is, with real zoom,
absolute positions do not change even though the widget appears further from
the left or top. I was going to put that info in the review request,
Committed as 4274.
On Mon, Dec 8, 2008 at 8:25 PM, Amit Manjhi [EMAIL PROTECTED] wrote:
LGTM
On Mon, Dec 8, 2008 at 6:40 PM, [EMAIL PROTECTED] wrote:
Reviewers: amitmanjhi,
Description:
Amit,
This patch changes the gwt build.xml file to use value rather then
location when defining
Why is this a problem for NamedFrames but not Frames?
Other then that, LGTM.
On Tue, Dec 9, 2008 at 3:10 PM, [EMAIL PROTECTED] wrote:
Reviewers: ecc,
Description:
Description:
The iframe created in a NamedFrame does not have a src, so
it throws a mixed content warning in IE6
In gwt-incubator, we want to be able to tag widgets/libaries
alpha/beta/releaseCandidate. However, this implies an extra level of
support for releaseCandidate libraries/widgets. Specifically, between each
incubator drop, if we had to break the API, which we will occasionally need
to do, we want
Ah, I see, the normal add(String) already sets word-wrap to false.
In that case LGTM.
On Tue, Dec 9, 2008 at 6:05 PM, [EMAIL PROTECTED] wrote:
insertTab(String text, boolean asHTML, int beforeIndex) already disabled
wordWrap, and we want insertTab() and setTabText() to be consistent.
It is definitely something that we would consider. Of course, the first step
would be to get some good alternative month selectors into the
gwt-incubator...
On Wed, Dec 3, 2008 at 9:28 PM, Arthur Kalmenson [EMAIL PROTECTED]wrote:
Hi John,
Thank you for the reply. Are there any plans in the
setTransientEnabledOnVisibleDates seems a bit awkward. What if we removed
the VisibleDates from the name instead? So we'd have:
setTransientEnabled
addTransientStyleToDates
etc.
Why do we want people to be able to remove date styles that do not exist
without getting an assertion
Also, you might want to turn your javadoc warnings on in your IDE, as I
notice that there are a lot of missing javadoc tags.
On Thu, Dec 4, 2008 at 10:01 AM, Emily Crutcher [EMAIL PROTECTED] wrote:
setTransientEnabledOnVisibleDates seems a bit awkward. What if we
removed the VisibleDates
that in tonight.
On Thu, Dec 4, 2008 at 9:39 AM, Emily Crutcher [EMAIL PROTECTED] wrote:
It is definitely something that we would consider. Of course, the first
step
would be to get some good alternative month selectors into the
gwt-incubator...
On Wed, Dec 3, 2008 at 9:28 PM, Arthur
Could you create a in issue for this problem here:
http://code.google.com/p/google-web-toolkit-incubator/issues/entry
Thanks!
Emily
On Wed, Dec 3, 2008 at 8:56 AM, Revv [EMAIL PROTECTED] wrote:
PROBLEM DESCRIPTION: In IE, even simple shape(meaning very short path
string) drawn with
Does anyone volunteer to support the ProgressBar widget in gwt-incubator?
Thanks!
Emily
--
There are only 10 types of people in the world: Those who understand
binary, and those who don't
--~--~-~--~~~---~--~~
it to the incubator. I'll see if I can fit that in tonight.
On Thu, Dec 4, 2008 at 9:39 AM, Emily Crutcher [EMAIL PROTECTED] wrote:
It is definitely something that we would consider. Of course, the
first
step
would be to get some good alternative month selectors into the
gwt-incubator
Also, the code should be reviewed before committing. I'll be happy to be
your reviewer once we land the 1.6 datepicker + release the 1.5 final
gwt-incubator drop. As until then, we cannot add 1.6 specific code to
gwt-incubator.
On Fri, Dec 5, 2008 at 1:05 AM, Emily Crutcher [EMAIL PROTECTED
By the way, if anyone has any problems with the new structure, , please file
a bug under gwt-incubator's bug tracker. If the instructions are not clear
on the incubator wiki(
http://code.google.com/p/google-web-toolkit-incubator/wiki/WorkingWithEclipse),
please add a comment under the wiki.
What about deprecating the old DOM.addEventPreview and creating an
DOM.addPreviewHandler instead, where the PreviewEvent extends DomEvent and
has some specialized methods to stop the event from going down the GWT
preview event chain.
On Wed, Dec 3, 2008 at 2:00 PM, Isaac Truett [EMAIL
3, 2008 at 4:19 PM, Isaac Truett [EMAIL PROTECTED] wrote:
Sounds good. I don't do a lot with event preview, but it seems
reasonable that it should follow the new event model.
On Wed, Dec 3, 2008 at 2:14 PM, Emily Crutcher [EMAIL PROTECTED] wrote:
What about deprecating the old
HasValue implementation and
developers will be accustomed to seeing and handling them.
I think Ian's idea of a read-only interface is interesting, but not
really on topic. Perhaps it deserves its own thread?
On Mon, Dec 1, 2008 at 5:50 PM, Emily Crutcher [EMAIL PROTECTED] wrote:
As many
IllegalArgumentException on setValue(null)
3. HasValue's javadoc should be tweaked accordingly
Yes?
rjrjr
On Tue, Dec 2, 2008 at 6:12 AM, Emily Crutcher [EMAIL PROTECTED] wrote:
This seems like the right philosophy to me, and your point about date
pickers having an optional range is a very
Code review request:
http://code.google.com/p/google-web-toolkit-incubator/source/detail?r=1250
Copying gen2-DropDownPanel over the widgetideas-DropDownPanel rather then
patching the widgetideas version, as this way we only maintain one version
of DropDownPanel, which is going to be depricated
John,
Could you review this change? Unfortunately, HasValue from incubator
directly conflicts with HasValue from gwt-trunk. Therefore creating a nasty
path-dependency problem, the current solution is to remove HasValue from
gwt-incubator:
be a
nightmare. IMHO, development on widgetideas code should be closed once a
gen2 replacement is available.
Thanks,
John LaBanca
[EMAIL PROTECTED]
On Tue, Dec 2, 2008 at 11:48 AM, Emily Crutcher [EMAIL PROTECTED] wrote:
Code review request:
http://code.google.com/p/google-web-toolkit
Fired 36 handlers for 5000 widgets using handlerMapForJava 312
millseconds, 312 millseconds, 312 millseconds created a random string with
3 handlers using handlerMapForJava 141 millseconds, 188 millseconds,
188 millseconds
-- Forwarded message --
From: Emily Crutcher [EMAIL
As many of you know, we have started down the path of making our form
widgets implement HasValue. A question that has come up is: Should widgets
be able to chose what values the widget accepts (i.e. setValue(null) for a
text box or a bounded integer range for a select box) without throwing
runtime
I'd prefer to leave the interface as is for now, and see if there is an
actual problem here. I suspect we'll find ourselves in a world where most
widgets deal with null, but string-based ones do not, and everyone will be
just fine.
Unfortunately, it is not very easy to change the contract
On Thu, Nov 20, 2008 at 10:32 AM, Ray Ryan [EMAIL PROTECTED] wrote:
Long term? 1.6, yes?
On Thu, Nov 20, 2008 at 10:07 AM, Emily Crutcher [EMAIL PROTECTED] wrote:
DateBox should implement the HasValue interface long term, which using the
new terminology, does basically what you expect here
On Thu, Nov 20, 2008 at 10:23 AM, John Tamplin [EMAIL PROTECTED] wrote:
On Thu, Nov 20, 2008 at 10:04 AM, Emily Crutcher [EMAIL PROTECTED] wrote:
For efficiency and code clearity I would still be inclined to support
the singleton version as well, but adding the Date... version as an option
Sorry, could have sworn that was public. Btw., DatePicker is littered with
direct uses of the calendar field. If getCalendarView() is protected, we
should always call it.
Still, the amount of duplication btw. the DatePicker API and CalendarView
is odd. Can CalendarView be reduced to a
Actually as Ray points out, foo(Bar) and foo(Bar...) are not
distinguishable overloads, so you would have to reverse the order of the
arguments to keep the single-arg version.
One is plural, one is not, so they would hopefully not overlap at all. The
bigger point though, is if the the
would have two methods:
Showing a popup above the widget is very useful for cases when the
popup shown below the widget will scroll the screen. In those cases
it would be nice to be able to detect that the popup is going to show
off the bottom of the screen and instead show it above the
, 2008 at 11:24 AM, Emily Crutcher [EMAIL PROTECTED] wrote:
would have two methods:
Showing a popup above the widget is very useful for cases when the
popup shown below the widget will scroll the screen. In those cases
it would be nice to be able to detect that the popup is going
shared - code that does not contain or reference any class that contains
JSNI,
GWT.create, or reflection
I think this should be reachable code, in that code hiding behind a
GWT.isClient() should be allowed.
--~--~-~--~~~---~--~~
If the class is never loaded, how is it unsafe?
On Thu, Nov 20, 2008 at 12:00 PM, John Tamplin [EMAIL PROTECTED] wrote:
On Thu, Nov 20, 2008 at 11:50 AM, Emily Crutcher [EMAIL PROTECTED] wrote:
shared - code that does not contain or reference any class that
contains JSNI
1 - 100 of 192 matches
Mail list logo
