gwt issues marked as "patcheswelcome" don't show up under open issues

51 views
Skip to first unread message

Jeff Larsen

unread,
Oct 6, 2011, 2:12:28 PM10/6/11
to google-web-tool...@googlegroups.com
All the issues marked patcheswelcome are reasonably hidden from view because they do not show up as open anymore. 

Eric Clayberg (Google)

unread,
Oct 6, 2011, 3:02:58 PM10/6/11
to google-web-tool...@googlegroups.com
At least for the moment, that is intentional. 

As you probably know, the GWT issue tracker has not had a lot of love lately, and we would like to fix that. We are undertaking a multi-week project to triage as many of the open issues as we can. We would like to close stale, invalid, fixed & duplicate issues, assign owners as appropriate, or mark issues as "PatchesWelcome" if it is something that we think is a reasonable idea but not something we (the GWT development team) are going to commit to. By treating "PatchesWelcome" as a closed state, we are, in essence, making a positive indication that, while we are happy to look at a patch, we are not going to address this ourselves (similar to "NotPlanned").

We are willing to be convinced otherwise, if folks think it is a bad idea.

Jeff Larsen

unread,
Oct 6, 2011, 3:24:00 PM10/6/11
to google-web-tool...@googlegroups.com
Is there a way to add patcheswelcome to the dropdown of the issue tracker? I think people will not find these issues and know to work on them. 

If I went to the issue tracker hoping to work on something where I would be able to help out the gwt community, I would start looking at open issues. I would not look at closed issues, closed issues would indicate to me that they are either not going to be done, and that is by design, or those issues are fixed. I would probably never know these issues existed. 

These issues seem like they are still open, just that they aren't issues that the gwt team will devote time to implement. 

Eric Clayberg (Google)

unread,
Oct 6, 2011, 5:01:02 PM10/6/11
to google-web-tool...@googlegroups.com
You make some good points, so we have reverted it back to "open".

David

unread,
Oct 7, 2011, 7:56:27 AM10/7/11
to google-web-tool...@googlegroups.com
This issue is marked now as PatchesWelcome:

http://code.google.com/p/google-web-toolkit/issues/detail?id=6401

So if I understand you correct:
Resizing columns in the CellTables will not be implemented unless we
find a way to do it ourselfs ...
A lot of people are waiting on this rather obvious feature (from the
perspective of the user at least)

I see some others related to the CellTable that would make it a decent
component (like horizontal scrolling) also marked as PatchesWelcome.

So after making us wait years for a fast replacement for the incubator
tables, the cell table has become abandonware as well ?

I'm really starting to regret chosing GWT for development. The only
thing where there are many commits is the compiler optimisations and
code splitting stuff ... in my opinion that is a waste of time since
the browsers are getting faster every day anyway.

David

> --
> http://groups.google.com/group/Google-Web-Toolkit-Contributors

Jeff Larsen

unread,
Oct 7, 2011, 9:20:26 AM10/7/11
to google-web-tool...@googlegroups.com
Switch to datagrid, that allows for horizontal scrolling. 

I've got a local version of drag resizing for columns working locally for the most part. I was waiting to pull a patch in until I figured out how to get the sizes of all the columns first. The only way I could get drag resizing of columns to work was to explicitly set a column size, and I was hoping to inspect the columns for their size on the initial load of data and use that for the explicit size.

I'd highly recommend dumping celltable for datagrid. It should be a mostly drop in replacement. 

James Horsley

unread,
Oct 7, 2011, 8:22:30 AM10/7/11
to google-web-tool...@googlegroups.com
Aren't tasks like CellTable column resizing something that the GWT community are much more likely to have expertise in to implement locally and hopefuly contribute back (it is open source after all) compared with compiler optimizations and code splitting? I've been very happy with the speed improvements to dev mode, compilation, etc. although of course am happy to have those along with the widget fixes/improvements if the GWT team have bandwidth :)


Eric Clayberg (Google)

unread,
Oct 7, 2011, 10:07:26 AM10/7/11
to google-web-tool...@googlegroups.com
Exactly right. Keep in mind that we (Google) have over 1000 current projects using GWT, and GWT is used for some of our largest, most important projects. If you are building large, complex GWT apps, things like compiler optimizations and code splitting are critical. Conversely, there are hundreds, if not thousands, of widget enhancements that could (and should) be made. We can't possibly do them all nor are we necessarily the best folks to implement them just as you suggest. GWT is open source so that the community can contribute patches and improve the toolkit in ways that have either not thought of or don't have the time for. 

Marking something as "PatchesWelcome" means that we do think it is a good idea, but it ls likely not something we are going to do ourselves any time soon. We will, however, happily accept, review, and integrate high quality patches that implement this behavior. Issue 6401 is a perfect example of something that could be implemented by the community (and probably fairly quickly).

Jeff Larsen

unread,
Oct 7, 2011, 10:20:03 AM10/7/11
to google-web-tool...@googlegroups.com
I got my own (slightly buggy version) done in a weekend. 

If you're not interested in waiting for me to submit either a patch or my own grid component project, you can look at DialogBox for some tips on how to hand the dragging events. 

The components to build this are all there, they just need to be put together. 
Reply all
Reply to author
Forward
0 new messages