GWT Issue/ Bug/ Feature Tracking - Suggestion
aglaforge
toes in google?
Being that it's very simple to create a project on the google project
hosting, we use that to track issues. I just went and created a
project gwt-issues where we could all post to (along w/ real code
snippets and files).
Honestly, I don't have any intention of moderating it and there is no
code associated with this particular project, but I would strong
encourage google to please take control of this project and actively
manage it.
At least this would provide developers a temporary outlet to organize
open issues.
The URL to submit issues:
http://code.google.com/p/gwt-issues/issues/list
Kind Regards,
Anthony L.
ash
you have touched on a core issue that enables us all to observe a
number of related tension points.
>The URL to submit issues:
why stop there?
cause: there are people in this group that want to report defects with
complete test-cases (see Mat Gessel's largely unrecognised, yet
fantastic contributions).
effect: MG publishes a executable test script on his site and then
posts a codified test-case to this group. (should all MVP volunteers
suffer such pain?). then us old time gwt'ers poll the gwt group
regularly for posts by MG with included test-cases.
preferred-effect: give MG commit rights to a community branch of a
gwt-commons::gwt-user library subsystem
cause: there are people in this group that make hacks into the runtime
library b/c they _need_ to fix problems or need to develop new features
in order for their deployed solutions to run effectively for their
clients.
effect: there are now many widget libraries and/or framework extensions
(including yours, robs, mine etc - http://www.gwtpowered.org/#Widgets).
whilst we all have different motivations, we mostly share common goals,
and we all suffer port issues for each gwt release. our consumers rely
on us to have resolved dependency issues, and for things to just work!
preferred-effect: there is a great pool of talent in this group, yet
our only effective collaboration is this forum. imho, this represents a
resource that is uncoordinated, self-driven, and its lack of
orchestration least benefits the overall gwt community.
i believe we should form a team. that team should be committers to a
gwt-commons project. that project may spawn several sub-projects, but
all are coordinated and managed releases. one sub-project should be the
gwt runtime where the team can make fixes or key enhancements to
gwt-user library. this gwt-user library is what all gwt-commons
projects should have a dependency on. the google gwt-user library team
can run diff reports and we can enter into concrete discussions with
the google team on modifications/enhancements with sample code, _real_
projects and/or test-cases that exercise these requirements. this team
should be able to collaborate with the gwt team to know when upcomming
gwt release's with compiler or emulation subsystem updates will cause a
forced gwt and gwt-commons sycnhronised release.
finally there are those that have either 1. identified an issue and
want some sort of response, or 2. currently lack the experience or have
no bandwith to develop gwt extensions for new features.
effect: post to this group raising an issue or feature request and hope
that it gets picked up in someones roadmap.
preferred-effect: know googles roadmap for gwt-user and be very clear
about the concerns/scope that the gwt team intends on addressing. eg.
is the google gwt team planning on developing a complete rich set of
widgets (eg. Coolbar, CTab, etc). is there going to be a gwt gui
builder etc. know what the gwt-commons project roadmap is and be very
clear about the concerns/scope their sub-projects intend on addressing.
once the community is clear about scope boundaries, the issues and
enhancements can be discussed with people that care and plan to address
it within a known time window. how many more GWT OSX posts do we need
to see in order to realise that this concern is not a priority on
anyones roadmap. yet, clearly there are people in this group that are
self-motivated to resolve this issue but nothing has been done -
another example of not harnessing the talent in this group.
anthony,
just as you created http://code.google.com/p/gwt-issues/issues/list to
address a community issue, i created
http://code.google.com/p/gems-gwt-user/ some time ago address the
issues i discussed above. however, what i have discovered is that an
issues list, or codebase is not enough. what is needed is an
orchestrated team that shares the same goals and whose scope boundaries
are coordinated with the gwt team.
best wishes ash
http://www.gworks.com.au/
Scott Blum
Let's face it, we haven't been doing a good job of managing issues,
particularly in the area of public visibility. I totally understand
and respect your desire to underscore how important this problem is to
everyone.
So what are we doing? We're are (big surprise!) migrating our issue
tracking to Google Code project hosting in the very near future. This
will give you all the ability to report issues more directly, and we
are hoping it will resolve many of these visibility/transparency
issues.
You may know that at Google we're not in the habit of pre-announcing
things that aren't done, but since you guessed, I figured I might as
well let the cat out of the bag. We expect to make the transition in
the next couple weeks, and we will keep you posted here.
Best,
Scott
ijuma
Regards,
Ismael
Konstantin Scheglov
Thank you, Scott.
claude
> You may know that at Google we're not in the habit of pre-announcing
While I generally agree with this strategy - it is one of the hallmarks
of making a good first impression - not all aspects of a project's
evolution qualify as announcements. Things of interest to the
community, I think, include:
1) Aspects or features that are understood by the GWT team to be
desirable but not within the scope of the project due to resource
restrictions or time constraints. This is a perfect place to encourage
community projects since the GWT team would implicitly support such
efforts without having to commit to them.
2) A general roadmap, though this doesn't have to be very explicit - it
could just be a wish list in order of priority - with no timeline
commitments. Some things of potential strategic value may be ommited or
simply declared as 'secret way of dealing with X'. A casual post that
says something like, we are working on a few things, including A, B, C
in the near future is not an announcement in my opinion but
communicates intention to the community, which can then plan accordinly
and engage in project that are synbiotic rather than uncoordinated.
3) Real open source, with a meritocracy of committers. This is a touch
problem but Sun's community licence approach and transparency in J2EE
and Java 6.x seems to be working well, while allowing them to retain
the necessary IP protection they need from a business standpoint.
Arguments for or against asside, a similar model would help expedite
bug fixes if nothing else.
To be fair, I'm still personally pleased with the quality of design and
releases in GWT, though perhaps less so with architectural
documentation, but the main point of this thread that I think deserves
emphasizing is that the community consists of some pretty savvy
individuals that are motivated to help and they should be leveraged to
maximum effect. If I were part of the GWT team, I'd be working very
hard to get that brain trust working on my problems instead of
dissipating energy into the ether.
ijuma
my opinion a lot better than leaving the community in the dark while it
struggles with certain issues. In the end, the community keeps wasting
time debating the issues and trying to convince the GWT team to do
something that the team is already in the process of doing. This may be
good in terms of media buzz when an annoucement is finally made, but
it's definitely bad for the people who are actually using the product
and trying to encourage change.
The third point, however, I am not sure. Sure, I like the idea of a
meritocracy of committers, but the Sun example is bad in my view. Sun
itself has decided that they should license their work under a real
open-source license and are in the process of doing this, therefore
admitting that the current approach should be improved.
Having said that, I think things should be done in small steps. And the
GWT team is moving in the right direction from what I can see. Sure, it
still seems like when it comes to plans, they won't say anything until
several people ask the same question repeateadly. But, maybe once they
migrate their issues to the public tracker, this situation will
improve. By the way, does anyone knows what is being worked on for the
next release? ;)
claude
but rather as an example of a system that can protect the IP if that's
a concern. Nothing is ever perfect, so I'm not pushing for a completely
open source project if that's not what the GWT team have in mind. There
are certainly benefits to keep the design 'in the family' so to speak.
I'd just like to encourate the team to leverage the talent on their
periphery is all.
Perhaps some features can be tested via an open source development
process that folds valid desings into the core, as approved by the GWT
team at Google. Maybe somthing like 'Friends of GWT' would be
sufficient to accomplish these goals.
A clear example is support for Drag and Drop, whcih was listed as a
requested feature on the first day and has remain unimplemeneted on the
todo list. I'm not saying it needs to be (I've already written my own)
but I'd be willing to refine it, open it up, align it with a more
standard Swing and/or SWT model and then propose it for eview as an
addition to GWT, in order to aleviate the work on Google's side if I
knew there was even a remote chance that it would not just end out
outside the framework, only to be reinvented ad nauseum.
My goal is merely to stimulate a dialog not to criticize. As I've said
before, the GWT team is doing an admirable job. Nothing is ever
perfect. I'd just like to jump in an help more effectively meet common
goals for the framework, perhaps as an extended team member (as I'm
sure others would be willing to do). Maybe we need to send our resumes
to Google ;-).
ash
> A clear example is support for Drag and Drop, whcih was listed as a
> requested feature on the first day and has remain unimplemeneted on the
> todo list. I'm not saying it needs to be (I've already written my own)
> but I'd be willing to refine it, open it up, align it with a more
claude a window manager. now i find myself doing drag and _dock_. how
many implementations of the same concept do we need before we realise
that we share the same goals yet unless that implementation gets folded
into a common distribution, the effort was simply not worth it.
> standard Swing and/or SWT model and then propose it for eview as an
> addition to GWT, in order to aleviate the work on Google's side if I
claude,
lately i been rethinking the widget component library. ive spent a lot
of time investigating josson's work on http://j2s.sourceforge.net/
which essentially lets you build a swt application and render it in
javascript. then there is bob's work on http://swingwt.sourceforge.net/
that lets you remap swing api to an alternate implementation (in his
case swt). finally there is chris's work on
http://swtswing.sourceforge.net/main/index.html that lets you go in the
reverse direction.
with two well established widget frameworks already available in the
java realm and with two open source projects that have abstracted both
of those frameworks and provided alternative implementations, can't it
be argued that we could avoid re-building all the widgets and
drag/drop, drag/dock already available in the desktop world and have
them ported to gwt?
but then again you could be a cynical bugger like me that has never
enjoyed java gui development since their delphi days and prefers to
port a different component model. perhaps im the only one that wants
gwt development to be as simple as client/server development a decade
ago.
rgds ash
claude
so easily. The key difference is rendering, where a native platform
supports a full graphics context, JavaScript does not. There's no
sufficiently fast way of drawing arbitrary shapes in the browser at the
moment, so we are left with building things on top of DOM objects.
The other key difference is a mixed metaphor, I think. Web apps are not
desktop apps and so idioms like flowing columns should probably be
retained while attempts at conforming to desktop idioms are often
counter-productive and end up looking boxy or constrained. I for one,
really dont want to re-invent Windows 3.0 for the browser. Think that's
the wrong way to go. A windowing system is good, but not one that tries
to be too desktop-ish if it's at the exclusion of recognizing that you
are still running in a browser. We still have to shape this generation
of applications, I suspect.
I agreee with all your other points WRT duplication of projects and
unnecessary re-invention though.
ash
claude wrote:
> I'm not sure Swing, SWT and other non-browser framework can be ported
> so easily. The key difference is rendering, where a native platform
> supports a full graphics context, JavaScript does not. There's no
> sufficiently fast way of drawing arbitrary shapes in the browser at the
> moment, so we are left with building things on top of DOM objects.
same level of fidelity could not be acheived until i discovered jossons
work. he has currently ported 80% of swt and whilst there are currently
some annoying differences, it is very close (see
https://svn.sourceforge.net/svnroot/j2s/trunk/sources/net.sf.j2s.java.org.eclipse.swt/src/org/eclipse/swt/).
> The other key difference is a mixed metaphor, I think. Web apps are not
> desktop apps and so idioms like flowing columns should probably be
good point! i do however feel that there are two sterotypical kinds of
rich internet apps (ria); 1. enterprise ria and 2. public ria.
the key difference in my mind is that the enterprise ria is domain rich
and is rendered more along the lines of a traditional desktop
application. in contrast, the public ria is domain simplified and
strikes a balance between broshureware and desktop.
> retained while attempts at conforming to desktop idioms are often
> counter-productive and end up looking boxy or constrained. I for one,
> really dont want to re-invent Windows 3.0 for the browser. Think that's
i think ajaxos (http://www.ajax13.com/en/ajaxos/) and bindows
(http://bindows.net/) has done it.
> the wrong way to go. A windowing system is good, but not one that tries
> to be too desktop-ish if it's at the exclusion of recognizing that you
perhaps your seeing and developing a public ria or a different
stereotype of application. the two gwt applications that ive been
involved with fit the enterprise ria stereotype which may well be
clouding my views. however, i am interested in whether you have used
the google portal (see. http://www.google.com/ig) and its gadgets. now
when we consider the classic "drag and dock" desktop concept and the
gadget portal, there is little difference in my mind. I feel that there
is a real convergence, and the realisation is differentiated by the ria
stereotype.
> are still running in a browser. We still have to shape this generation
> of applications, I suspect.
i agree. there is so much that is similar to the past but with
differences. there are new constraints and a higher expectation on
user-experience.
> I agreee with all your other points WRT duplication of projects and
> unnecessary re-invention though.
good luck with your application at google :-)
rgds ash
claude
ash wrote:
> good point! i do however feel that there are two sterotypical kinds of
> rich internet apps (ria); 1. enterprise ria and 2. public ria.
> the key difference in my mind is that the enterprise ria is domain rich
> and is rendered more along the lines of a traditional desktop
In an enterprise environment, there is typically more control over the
technology deployment scenario, so I would be more inclined to use
Swing, a more mature and capable technology. Most of the problems that
GWT adresses have to do with low-bandwidth, ubiquitous deployment at
the consumer level. I'm not saying this can't be applied in-house, but
the arguments are not as compelling.
> the google portal (see. http://www.google.com/ig) and its gadgets. now
> when we consider the classic "drag and dock" desktop concept and the
> gadget portal, there is little difference in my mind. I feel that there
> is a real convergence, and the realisation is differentiated by the ria
> stereotype.
This re-enforces my point. You'll notice that Google's Gadgets,
pageflakes.com, netvibes.com, etc all use a columnar format, consistent
with the web idiom, while adding windows for hosting content. This is
more like a rich portal interface than a desktop application. One key
difference is a limited use of the z-axis in web apps, no window tiling
or cascade functions.
The browser environment needs to co-exist with a real desktop and
unless you can drag across the browser-desktop boundary, there is no
real integration and thus too much user-confusion if they become too
much alike. I"m not saying this is a good thing, but it is a fact of
life.