Also, has anyone seen the call for widgets on the contrib list? If
more widgets get into the core API, where does that leave the commons?
The one thing that doesn't seem to fit in the core are browser
specific widgets, and server-side integration.
Rob
The call for widgets actually incorporates some of the bits that we
were planning to have in commons, which I feel was one of the
ultimate goals of commons anyway. (Commons members get your CLAs into
Google!)
If we manage to help get all the things that were requested in Joel's
message to the Contrib list, that pretty much grabs up what we had
planned for commons core. This would leave commons with things that
may be less appropriate for GWT proper. These would be things like
server side integration, and widgets that necessarily cannot support
all platforms.
And perhaps a staging area for things that we would like to see
rolled onto GWT in the future.
-jason
I agree. I am also wondering if there is value in having a perpetual
"alpha library".
Let me explain what I mean. First, it looks like there is interest on
adding a lot of these widgets, and your effects library, to the GWT
core.
The problem I have is that I don't see this happening in short order.
The delay is good for a stable GWT, but it isn't helping anyone get
their work done. Just yesterday I sent off my unfinished color picker
code to someone that really needed a color picker for his project. He
didn't care that it wasn't documented, or that it was incomplete. He
just needed some code to get his work done.
I think what I am proposing is a distribution that is filled with code
that comes from ideas on the contrib list. Ideas like the data driven
widgets on the contrib list has lost some steam. But what if you were
to build a prototype and make it available to everyone. I think that
the feedback from the community would be extremely helpful, and would
answer the question, "should it belong in the GWT core?"
I have wanted to do something like this for a while now, and still
plan to do so when my other obligations lighten up. I just wanted to
throw it out there in case there was other interest in this by the
commons group.
With regard to the original issue, I have one question... Does the
call for widgets on the contrib list change the mandate of this group?
I think that we weren't really expecting any overlap with the GWT
core, but now it seems that there might be.
Rob
Rob
a happy new year to you all.
btw rob, congratulations to adam and yourself on the book.
---
ive manage to read a couple of threads on both groups with interest.
to answer a few posts in one:
> I was just wondering if something was in the works that isn't being published (I
am hopeful that the answer is yes).
im just back from vacation, so nothing has been done from my end since
my last post. at that time i merged my effects framework with jasons.
> Also, has anyone seen the call for widgets on the contrib list? If
more widgets get into the core API, where does that leave the commons?
sometime ago i posted a message requesting what the scope boundaries
are for gwt core. i felt that several components we were building in
commons were candidates to be promoted into core. some of those were
jre based, and from what i have read[1], sandy has already started
that. adding basic java.text support has been one of my motivations, so
i am glad to see this initiative have some momentum. it would be good
to have andre and george contrib their calendar work to that cause.
however, i believe there are many things that do belong in the commons
library that are misplaced in gwt proper. infact, sometimes i wonder if
things like gwt-rpc is better demoted to commons for consistency. one
key differentiator is that commons is not limited by the same set of
principles. those different principles has helped me establish the
boundaries, however, sharing and agreeing those boundaries is another
issue.
> Does the call for widgets on the contrib list change the mandate of this group?
i read joels post and also the post on data-bound controls. like
konstantin i was a delphi guy in a former life and loved the vcl, its
simplicity and its serialisation. infact, i got so disheartened with
gwt's widget library 6 months ago that i almost implemented delphi's
vcl library in gwt.
anyway, i feel that gwt proper needs a very light-weight widget
library. imho, if the user needs high-fidelity widgets or themed
widgets, then they use third party.
rgds ash
http://www.gworks.com.au
I've minor changes but I think it is irrelevant. In my opinion,
gwt-commons needs a project leader and/or decision group that will
point priorities and accept/deny contributions. As in gwt-contrib,
member will have to show work to be able to change source and
contribute. I include my self in this last group since I'm pretty new
to GWT and this group. Without orientation we will all work in
different branches, duplicate efforts and won't help each other.
Regards,
Freller
I completely agree. I think that this entire manage by committee
thing isn't working. It is great to get input from everyone, but only
one or two people should be making the decisions. ...And if the
general group doesn't like the decisions being made, then they will go
elsewhere or oust the group leader.
I would also like to add that I have been waiting for someone to step
up and do this. Ash in particular seems to have strong convictions
for this project (and some amount of free time), but hasn't yet
attempted to step up and run the show.
Thoughts?
Rob
I am open to any suggestion that will get things moving forward. I'm
not picky... dictator or committee is fine by me.
> Maybe we should make a list of features we want in the first release
Again, I am not so picky here, but "something" is better than nothing.
Even a release with a single widget that a few people might need
would be a worthwhile release.
Rob
> Thoughts?
well there is certainly a lot to chew on here...
Andre wrote:
> gwt-commons needs a project leader and/or decision group
indeed leadership is required.
Rob wrote:
> I completely agree. I think that this entire manage by committee
> thing isn't working. It is great to get input from everyone, but only
a distracted committee attempting to drive consensus during the festive
season was doomed.
> one or two people should be making the decisions. ...And if the
and Joe wrote:
> I think there is a Project Management Committee who get binding votes to
> questions that are proposed. And everyone else can voice their opinion, of
> course, but their votes are non-binding.
ok, we all seem to be gravitating towards a _small_ group empowered
with decision making. input and contribution is always desired.
Rob wrote:
> I would also like to add that I have been waiting for someone to step
> up and do this. Ash in particular seems to have strong convictions
> for this project (and some amount of free time), but hasn't yet
> attempted to step up and run the show.
its true, i have strong convictions and a vision for this but i am all
too aware of what i can achieve alone. i didnt just want to create a
better gems framework on my 3rd attempt. i wanted to challenge some of
my misconceptions and ideas and unify with some of yours.
ive used the gems framework on a few commercial projects now. its gone
well for me. i have evolved from just reusing widgets to patterns and
even principles across projects. the stuff in my private commons branch
is all code that we used. in fact we have more to contribute from our
recent developments.
so why have i not stepped up to the plate?
because i have observed that even with my own contributions i have no
time to author end-user documentation. i have not had time to engineer
test-cases and test-suites. i did my best to make time to develop the
various demos and update gwt-petstore but even that was pushing my
concurrent responsibilities.
my goal was to create a seamless, consistent and integrated framework
and associated toolkits to boost the productivity in gwt development.
achieving those goals across the various libraries/contributions is a
non-trivial exercise and requires intimacy with each of the problem
domains, and also self-motivation. admittedly i had no affinity to some
of the contributions b/c i had not experienced those requirements in my
gwt travels. but i know there are _real_ users of gwt-wl, rocket, etc.
hence, i felt the need for several parties to step up to the plate, not
just me.
i still strongly believe that it is in the best interest of the gwt
community to have a stable and active gwt-commons. i strongly believe
that the gwt-commons core should have a key set of user-experience
patterns and that the widget set, controllers and runtime features that
ships with it are integrated, consistent and seamless to in order to
realise those patterns effectively.
your thougts?
rgds ash
http://www,gworks.com.au