Re: GWT issue tracker spring cleaning
Hi Ed, thank you Ed for the feedback. We really like to see patches on issues that you care about. If you want to work on something we will happily review your work. As Thomas pointed out: If you want to propose a bigger patch please get in contact with gwt contributors to make sure you are heading in the right direction and your work will make it into gwt master. Some patches seem to be quite controversial and I want to make sure that we do not waste your time. -Daniel Am Freitag, 31. Mai 2013 10:24:34 UTC+2 schrieb Thomas Broyer: > > > > On Thursday, May 30, 2013 8:36:23 PM UTC+2, Ed wrote: >> >> BTW: Note: some issues that are marked as Stale, I am planning to pick up >> and submit a patch, but that will not be soon, seen my agenda. So I hope >> the issue will still be considered then (or is considered dead by then when >> no activity happens in X weeks);) >> > > As with most OSS projects, patches are welcome whether there's an issue > open for them or not (opening an issue then allows for better tracking, > particularly when writing the release notes). > Before working on a patch though (particularly a big one), unless you're > ready to maintain a personal/private fork, you'd probably better come > discuss on the gwt-contrib: if it's something that would be rejected, no > need to start working on a patch and it'll save you time (that you could > then dedicate to some other patch :-P ) > > Think of "assumed stale" as "nobody seems to really care" (historically, > "assumed stale" also meant "we think it might have been fixed, please test > with the latest version", but it's not that different actually: we want to > close the issue and send a "signal" to anyone who cares about it; if he > says it's fixed, we can change the status to Fixed, if he says he no longer > care, or doesn't respond, we'll leave it as is, or maybe change the status > to NotPlanned; if he says he still wants it, then we'll probably leave it > closed and "ask" for a patch; when the patch comes –or the contributor says > he's about to start working on it– we can change the issue status). > > BTW, there's a "glossary" at > https://code.google.com/p/google-web-toolkit/wiki/BugTriageProcess but it > might need an update, and it doesn't talk about AssumedStale. > Maybe we should move it to gwtproject.org, patches welcome ;-) > (if you want to propose enhancements to that wiki page, feel free to come > discuss it at gwt-contrib –I'm not sure comments on the wiki will notify > anyone, so better use gwt-contrib–) > -- You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit+unsubscr...@googlegroups.com. To post to this group, send email to google-web-toolkit@googlegroups.com. Visit this group at http://groups.google.com/group/google-web-toolkit?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
Browser compatibility issue
Hi all, I'm using gwt-2.5.1 and the following widgets have distinct behaviours: 1. CellTable in Chrome, IE and Mozilla, it appear in fact filling all browser width but in Safary it doesent. 2. menuBar (or SimplePanel) a menu bar is added to the following SimplePanel in Safary and Chrome it appear filling all browser width but in IE and Mozilla it doesent. Is this a know problem? Many thanks, Luis Costa -- You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit+unsubscr...@googlegroups.com. To post to this group, send email to google-web-toolkit@googlegroups.com. Visit this group at http://groups.google.com/group/google-web-toolkit?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
Re: change in children not saved in GWT 2.5.1 after implement OSIV
Same problem, Still haven't found any good solution, Em sexta-feira, 31 de maio de 2013 11h50min21s UTC-3, Yan escreveu: > > Hi there, > > I have a Parent object containing a list of Children objects. Both are > EntityProxy. My RequestFactory API is to persist the Parent along with > Children collection. My JPA layer is EclipseLink (JPA 1.0), with entity > manager cache ENABLED. > > In UI, I change some property on children (without changing parent). When > the backend API is called, I expect to see that the Parent's children > objects will have the updates. > > In GWT 2.4.0, I do see that because GWT 2.4.0 sends the list of children > to server regardless. In GWT 2.5.1, I see only the delta is sent across > the wire (this is correct), but in the backend, I do not see the children > collection with updates, that is incorrect. > > I did implement one-entitymanager-per-request pattern based on a solution > someone offered on this group. I verified that only one instance of child > is created by JPA during the request. I also verified that GWT client is > correctly sending the delta to GWT server and setter methods are called on > JPA entity to set the correct value (after JPA loads children from > database). Afterwards, the setter is not called and no child object ever > created again. > > However, when the code reaches the API (as seen in debugger), I do not see > the children objects has the updates. > > Why is this? GWT runtime is somehow loading the object from somewhere > else? > > Thanks, > Yan > -- You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit+unsubscr...@googlegroups.com. To post to this group, send email to google-web-toolkit@googlegroups.com. Visit this group at http://groups.google.com/group/google-web-toolkit?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
Re: change in children not saved in GWT 2.5.1 after implement OSIV
I'm having the same issue. Tried to edit the proxy with the same request context as the parent proxy, but no solution. Also tried to create new child proxies and set to the parent, also without sucess; -- You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit+unsubscr...@googlegroups.com. To post to this group, send email to google-web-toolkit@googlegroups.com. Visit this group at http://groups.google.com/group/google-web-toolkit?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
Re: SimplePager last page issue
These methods are private in 2.5.1, so this fix does not work there.
The behavior to only set enabled/disabled on next/last seems broken. I have
rangeLimited(false) and always have exact row count, and the enablement on
my next/last paging controls can never be updated.
On Tuesday, October 16, 2012 10:18:46 AM UTC-4, Juan Pablo Gardella wrote:
>
> Hi,
>
> See
> http://code.google.com/p/google-web-toolkit/source/browse/trunk/user/src/com/google/gwt/user/cellview/client/SimplePager.javathese
> methods are defined in a super class.
>
> Juan
>
> 2012/10/16 dafintrash >
>
>> Your tip could use some clarification as the SimplePager class doesn't
>> have the following methods: setPrevPageButtonsDisabled,
>> setNextPageButtonsDisabled, setFastForwardDisabled.
>>
>>
>> On Monday, August 27, 2012 4:11:25 AM UTC+3, Juan Pablo Gardella wrote:
>>>
>>> Hi,
>>>
>>> There is a bug with SimplePager that enable go to next page in the last
>>> page (an must be disabled). Well, after some debugging if I change the
>>> method onRangeOrRowCountChanged() in this way works well.
>>>
>>> @Override
>>> protected void onRangeOrRowCountChanged() {
>>> HasRows display = getDisplay();
>>> label.setText(createText());
>>>
>>> // Update the prev and first buttons.
>>> setPrevPageButtonsDisabled(!**hasPreviousPage());
>>>
>>> // Update the next and last buttons.
>>> //if (isRangeLimited() || !display.isRowCountExact()) {
>>> if (isRangeLimited() || *display.isRowCountExact()*) {
>>> setNextPageButtonsDisabled(!**hasNextPage());
>>> setFastForwardDisabled(!**hasNextPages(**getFastForwardPages()));
>>> }
>>> }
>>>
>>> As see, I remove "!" in display.isRowCountExact() and works. Hope helps
>>> someone.
>>>
>>> Juan
>>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Google Web Toolkit" group.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msg/google-web-toolkit/-/pnTXCInn1bwJ.
>> To post to this group, send email to
>> google-we...@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 unsubscribe from this group and stop receiving emails from it, send an email
to google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
SimplePager next/last not being disabled appropriately
Using GWT 2.5.1, SimplePager.java has this method:
@Override
protected void onRangeOrRowCountChanged() {
HasRows display = getDisplay();
label.setText(createText());
// Update the prev and first buttons.
setPrevPageButtonsDisabled(!hasPreviousPage());
// Update the next and last buttons.
if (isRangeLimited() || !display.isRowCountExact()) {
setNextPageButtonsDisabled(!hasNextPage());
setFastForwardDisabled(!hasNextPages(getFastForwardPages()));
}
}
Why are the next/last buttons enabled/disabled only if range is limited or
if the row count isn't exact? I have a pager set to range limited false,
and my data provider specifies that the row count is exact when I update
the row count. With this setup, the next/last paging buttons will NEVER be
updated!
Am I just using this wrong, or is it a bug?
I worked around the issue by subclassing SimplePager to allow me into that
block at the bottom of onRangeOrRowCountChanged():
@Override
protected void onRangeOrRowCountChanged() {
boolean rangeLimited = isRangeLimited();
super.setRangeLimited(true);
super.onRangeOrRowCountChanged();
super.setRangeLimited(rangeLimited);
}
--
You received this message because you are subscribed to the Google Groups
"Google Web Toolkit" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
