Future of touch support
215 views
Skip to first unread message
Carsten Kraus
Apr 25, 2012, 1:19:34 PM4/25/12
to closure-lib...@googlegroups.com
Hi list,
I recently posted on an older thread[1] about touch support in the lib, but unfortunately did not get any response.
Maybe that was because its an older thread.
So, I'd like to ask again: what are the plans on fixing BrowserEvent for touch devices? Will Andrew Matties fixes[2] make it into the library and, if not, will there be alternatives[3]?
I would really appreciate a response on the google-internal status on the topic, even if the reply is that there will be no touch-support in the near future.
For the latter case, it would then be great if we could kick-off a community-driven effort to fix the situation.
Btw I tried to apply Andrews 3rd patchset[2] and, while BrowserEvent then at least had values for screenX/screenY, the patch failed to fix Dragger for me(applied against rev 1780).
@Andrew, do you have an idea, what could be the problem there?
Thanks,
Carsten
Andrew Mattie
Apr 25, 2012, 3:28:09 PM4/25/12
to closure-lib...@googlegroups.com
Yeah, I'd definitely like to see my patches be reviewed and ingested, but I also suspect the maintainers are quite busy and so I'm trying not to bug too much. Forking the library to more quickly move outside contributions through would be more trouble than it's worth in my opinion.
Perhaps a good intermediate solution would be to designate certain members from the community with a title like "initial reviewer." Those members could then be tasked with the initial review of reported bugs and suggested patches to ensure they meet Closure's style practices, have appropriate test coverage, etc. Once the initial reviewer deals with the bug or blesses the patch, a Googler w/ ingest privileges could assign it out for another look and then bring it into the repo. It'd take a commitment on Google's part to actually do the latter reviews lest the initial reviewers feel like they're wasting their time, but it wouldn't be as much work as it is now where Nathan and co. have to spend time reviewing everything that comes through. Just an idea.
Anyway, I just updated the touch / event / dragger patch for compatibility w/ r1780.
Andrew
Andrew
Erik Charlebois
Apr 25, 2012, 5:45:05 PM4/25/12
to closure-lib...@googlegroups.com
I'd also like to know the state of touch support. I've been updating the good.ui components as I go [1] and have some more advanced components I'd consider contributing (e.g. an iOS-style UIScrollView clone with pinch zoom support).
Erik Charlebois
Johannes Nel
Apr 25, 2012, 11:10:30 PM4/25/12
to closure-lib...@googlegroups.com
forking in svn is an issue, i see people trying to get their git branches working so maybe someone...
should get the a community github going?
we also have have to fork around the current bug in webkit where touching the dom jumps
--
j:pn
\\no comment
j:pn
\\no comment
Sarah Allen
Apr 25, 2012, 10:13:13 PM4/25/12
to closure-lib...@googlegroups.com
+1 to github branch of touch event changes so we can all test it easily until the Google folks decide to integrate it. I haven't used svn-git bridge stuff in a while, but it worked pretty well a few years ago and github is nice for reviewing changes and accepting pull requests.
Carsten Kraus
Apr 26, 2012, 7:31:12 AM4/26/12
to closure-lib...@googlegroups.com
Andrew's idea of an initial reviewer sounds nice, but I fear the real problem with community contributions is not the limited time that googlers are allowed to spend with the open source project.
I may be wrong, but I think, that the project will rather only allow for 'smaller' contributions anyway. Patches to critical packages like goog.events/goog.ui will always have a super hard time trying to get in, I guess.
If I remeber correctly there have been quite some discussions on some flawed/not-so-well-designed parts in Component/Container years ago and driven by prominent members like bolinfest, but today these parts still didnt change much.
And that's pretty easy to understand, since so many important projects seem to rely on them inside google. However, that leaves us open-source-users in a bad situation at times.
So, bottom line, imho the idea of community review helpers will not really bring us further that much.
Now, what do we do? Maintaining forks? Can we bring up the commitment & resources to maintain sth big as this?
Another idea: why dont we put up feature-focused community packages on github/bitbucket or wherever? 'goog.mobile.*' someone? : )
Thoughts?
We're talking javascript, so we could even patch prototypes/mixin members of library classes at runtime(maybe even at compile time?!), if we need to.
Not scalable till eternity, but could potentially help quite some use cases..
@Andrew, thanks a lot for your 4th patchset!! Works great now(for ex 'Drag' demo), your really saved my current project with this.
Fwiw, I commited to a plovr fork that has the library at rev 1780 and Andrews patch ingested: http://bitbucket.org/carkraus/plovr
@Erik: UIScrollView-like component sounds absolutely incredible! Please please please consider sharing! : )
Rhys Brett-Bowen
Apr 27, 2012, 2:10:32 AM4/27/12
to Closure Library Discuss
Think a community edition is a brilliant idea and something we need to
hop on. We've got the initial meetup scheduled for early June and
believe this will be a big topic. There are so many things happening
in the world of javascript, mobile and HTML5 that the library will
fall behind if there isn't a bells'n'whistles version.
I've got some ideas that I would like to see in the library - perhaps
it'd be good to organize a google hangout before the initial meet with
people who are interested to discuss what we think would be a good
idea for a wider community fork.
> >https://github.com/wishabi/closure-library/commit/6a7166f922f7ee98695...
> > [2]http://codereview.appspot.com/5150047/
> > [3]
> >https://groups.google.com/d/msg/closure-library-discuss/0MO-sSKN2YA/s...
hop on. We've got the initial meetup scheduled for early June and
believe this will be a big topic. There are so many things happening
in the world of javascript, mobile and HTML5 that the library will
fall behind if there isn't a bells'n'whistles version.
I've got some ideas that I would like to see in the library - perhaps
it'd be good to organize a google hangout before the initial meet with
people who are interested to discuss what we think would be a good
idea for a wider community fork.
>
> > --
> > Erik Charlebois
>
> > On Wednesday, 25 April, 2012 at 3:28 PM, Andrew Mattie wrote:
>
> > Yeah, I'd definitely like to see my patches be reviewed and ingested, but
> > I also suspect the maintainers are quite busy and so I'm trying not to bug
> > too much. Forking the library to more quickly move outside contributions
> > through would be more trouble than it's worth in my opinion.
>
> > Perhaps a good intermediate solution would be to designate certain members
> > from the community with a title like "initial reviewer." Those members
> > could then be tasked with the initial review of reported bugs and suggested
> > patches to ensure they meet Closure's style practices, have appropriate
> > test coverage, etc. Once the initial reviewer deals with the bug or blesses
> > the patch, a Googler w/ ingest privileges could assign it out for another
> > look and then bring it into the repo. It'd take a commitment on Google's
> > part to actually do the latter reviews lest the initial reviewers feel like
> > they're wasting their time, but it wouldn't be as much work as it is now
> > where Nathan and co. have to spend time reviewing everything that comes
> > through. Just an idea.
>
> > Anyway, I just updated the touch / event / dragger patch for compatibility
> > w/ r1780.
>
> > Andrew
>
> > --
> > Erik Charlebois
>
> > On Wednesday, 25 April, 2012 at 3:28 PM, Andrew Mattie wrote:
>
> > Yeah, I'd definitely like to see my patches be reviewed and ingested, but
> > I also suspect the maintainers are quite busy and so I'm trying not to bug
> > too much. Forking the library to more quickly move outside contributions
> > through would be more trouble than it's worth in my opinion.
>
> > Perhaps a good intermediate solution would be to designate certain members
> > from the community with a title like "initial reviewer." Those members
> > could then be tasked with the initial review of reported bugs and suggested
> > patches to ensure they meet Closure's style practices, have appropriate
> > test coverage, etc. Once the initial reviewer deals with the bug or blesses
> > the patch, a Googler w/ ingest privileges could assign it out for another
> > look and then bring it into the repo. It'd take a commitment on Google's
> > part to actually do the latter reviews lest the initial reviewers feel like
> > they're wasting their time, but it wouldn't be as much work as it is now
> > where Nathan and co. have to spend time reviewing everything that comes
> > through. Just an idea.
>
> > Anyway, I just updated the touch / event / dragger patch for compatibility
> > w/ r1780.
>
> > Andrew
>
> > On Wed, Apr 25, 2012 at 10:19 AM, Carsten Kraus <carsten.kr...@gmail.com>wrote:
>
> > Hi list,
>
> > I recently posted on an older thread[1] about touch support in the lib,
> > but unfortunately did not get any response.
> > Maybe that was because its an older thread.
>
> > So, I'd like to ask again: what are the plans on fixing BrowserEvent for
> > touch devices? Will Andrew Matties fixes[2] make it into the library and,
> > if not, will there be alternatives[3]?
> > I would really appreciate a response on the google-internal status on the
> > topic, even if the reply is that there will be no touch-support in the near
> > future.
>
> > For the latter case, it would then be great if we could kick-off a
> > community-driven effort to fix the situation.
>
> > Btw I tried to apply Andrews 3rd patchset[2] and, while BrowserEvent then
> > at least had values for screenX/screenY, the patch failed to fix Dragger
> > for me(applied against rev 1780).
> > @Andrew, do you have an idea, what could be the problem there?
>
> > Thanks,
> > Carsten
>
> > [1]
> >https://groups.google.com/d/msg/closure-library-discuss/-0qExt9ndgY/C...
>
> > Hi list,
>
> > I recently posted on an older thread[1] about touch support in the lib,
> > but unfortunately did not get any response.
> > Maybe that was because its an older thread.
>
> > So, I'd like to ask again: what are the plans on fixing BrowserEvent for
> > touch devices? Will Andrew Matties fixes[2] make it into the library and,
> > if not, will there be alternatives[3]?
> > I would really appreciate a response on the google-internal status on the
> > topic, even if the reply is that there will be no touch-support in the near
> > future.
>
> > For the latter case, it would then be great if we could kick-off a
> > community-driven effort to fix the situation.
>
> > Btw I tried to apply Andrews 3rd patchset[2] and, while BrowserEvent then
> > at least had values for screenX/screenY, the patch failed to fix Dragger
> > for me(applied against rev 1780).
> > @Andrew, do you have an idea, what could be the problem there?
>
> > Thanks,
> > Carsten
>
> > [1]
> > [2]http://codereview.appspot.com/5150047/
> > [3]
> >https://groups.google.com/d/msg/closure-library-discuss/0MO-sSKN2YA/s...
Chris Wilson
Apr 27, 2012, 5:16:47 AM4/27/12
to Closure Library Discuss
Hi all,
On Thu, 26 Apr 2012, Rhys Brett-Bowen wrote:
> Think a community edition is a brilliant idea and something we need to
> hop on. We've got the initial meetup scheduled for early June and
> believe this will be a big topic. There are so many things happening
> in the world of javascript, mobile and HTML5 that the library will
> fall behind if there isn't a bells'n'whistles version.
>
> I've got some ideas that I would like to see in the library - perhaps
> it'd be good to organize a google hangout before the initial meet with
> people who are interested to discuss what we think would be a good
> idea for a wider community fork.
I strongly agree with the idea of a community-maintained fork of Closure.
While its development happens "in secret" inside Google, it feels like a
one-way street like Apple's Darwin, which eventually killed Darwin out of
frustration with Apple's approach; and Sun/Oracle's approach to Open
Office, which eventually resulted in the Libre Office fork.
It feels to me as though Google's distribution of Closure is designed to
meet their needs, not the community's. That makes perfect business sense
for them, and no sense for the community, except those members who are
exactly like Google, and I doubt there are many.
I would really like to be able to fork, patch and submit pull requests for
Closure on github or bitbucket. Google would probably not want to use that
version, but they would be free to extract whatever they want as patches
to put into their official branch. I think git-svn should make it quite
easy to do that. Likewise we should review updates from Google and pull
them if possible.
I think from the discussions I've seen on this list that we have enough
members and skills to maintain a community fork. So I propose a few rules
as a starting point for discussion:
* We elect some committers to the fork based on proven code quality
(majority vote for or against each one independently, minimum 100 votes
to pass)
* We have patch review meetings once a month (preferably in public on the
list/IRC)
* Anyone who wants their pull request submitted must persuade at least one
committer, otherwise it gets refused/dropped (without prejudice)
* New committers may apply on the mailing list at any time, and be elected
by majority vote as before.
* Any rule changes/additions to be proposed on the mailing list and agreed
by majority vote as before.
We could also consider a patch triage process like Django has: if you want
your patch reviewed by a committer, you have to review/triage three
other proposed patches (that you didn't write).
Thoughts?
Cheers, Chris.
--
_____ __ _
\ __/ / ,__(_)_ | Chris Wilson <chri...@qwirx.com> Cambs UK |
/ (_/ ,\/ _/ /_ \ | Security/C/C++/Java/Ruby/Perl/SQL Developer |
\__/_/_/_//_/___/ | We are GNU : free your mind & your software |
On Thu, 26 Apr 2012, Rhys Brett-Bowen wrote:
> Think a community edition is a brilliant idea and something we need to
> hop on. We've got the initial meetup scheduled for early June and
> believe this will be a big topic. There are so many things happening
> in the world of javascript, mobile and HTML5 that the library will
> fall behind if there isn't a bells'n'whistles version.
>
> I've got some ideas that I would like to see in the library - perhaps
> it'd be good to organize a google hangout before the initial meet with
> people who are interested to discuss what we think would be a good
> idea for a wider community fork.
While its development happens "in secret" inside Google, it feels like a
one-way street like Apple's Darwin, which eventually killed Darwin out of
frustration with Apple's approach; and Sun/Oracle's approach to Open
Office, which eventually resulted in the Libre Office fork.
It feels to me as though Google's distribution of Closure is designed to
meet their needs, not the community's. That makes perfect business sense
for them, and no sense for the community, except those members who are
exactly like Google, and I doubt there are many.
I would really like to be able to fork, patch and submit pull requests for
Closure on github or bitbucket. Google would probably not want to use that
version, but they would be free to extract whatever they want as patches
to put into their official branch. I think git-svn should make it quite
easy to do that. Likewise we should review updates from Google and pull
them if possible.
I think from the discussions I've seen on this list that we have enough
members and skills to maintain a community fork. So I propose a few rules
as a starting point for discussion:
* We elect some committers to the fork based on proven code quality
(majority vote for or against each one independently, minimum 100 votes
to pass)
* We have patch review meetings once a month (preferably in public on the
list/IRC)
* Anyone who wants their pull request submitted must persuade at least one
committer, otherwise it gets refused/dropped (without prejudice)
* New committers may apply on the mailing list at any time, and be elected
by majority vote as before.
* Any rule changes/additions to be proposed on the mailing list and agreed
by majority vote as before.
We could also consider a patch triage process like Django has: if you want
your patch reviewed by a committer, you have to review/triage three
other proposed patches (that you didn't write).
Thoughts?
Cheers, Chris.
--
_____ __ _
\ __/ / ,__(_)_ | Chris Wilson <chri...@qwirx.com> Cambs UK |
/ (_/ ,\/ _/ /_ \ | Security/C/C++/Java/Ruby/Perl/SQL Developer |
\__/_/_/_//_/___/ | We are GNU : free your mind & your software |
Reply all
Reply to author
Forward
0 new messages