Hi, On Sun, 2008-01-27 at 17:42 -0600, Klaus Weidner wrote: > On Sun, Jan 27, 2008 at 02:17:04PM -0500, Michael Stone wrote: > > While I can't say how your efforts will wind up being used, I very much > > want to thank you for stepping up to work on these issues and for > > submitting such clear patches. > > You're welcome, I'm happy if I can contribute something to such a cool > project :-) > > > Keep up the hard work, and let everyone know if you'd like help > > packaging your changes (to ease testing) or in working with the upstream > > maintainers of Read and Evince. > > I've bundled up the activity and library and put them on my web server, in > case anyone wants to test them: > > http://www.pocketworkstation.org/xo/ > > The activity is a normal .xo bundle. For the shared library, extract it > from the '/' directory: > > tar xvzf libevince-*.tar.gz > > Yes, I'd like help who to contact and how best to submit changes for the > upstream code.
In general, having the proposed patches attached to an existing ticket in trac is the best way. This puts the patches in context, help with tracking and will probably reach the maintainer faster. See http://wiki.laptop.org/go/Sugar_Patches . That said, I think it makes sense to post the patches to the mailing list if some discussion needs to happen. In this concrete case, we still miss a decision about how we want to express this new functionality in the UI. We have had already some discussion in this list about the different approaches we can take, but before we can accept an implementation, Eben should specify clearly how he thinks it should be implemented. > If I understand it right, the evince library currently used is > temporarily forked, and I'm not sure which parts of it are ready to be > upstreamed. I can separate out the scrolling-backwards-in-noncontinuous-mode > fix which I've reproduced in the desktop evince, so that could be submitted > separately to the original evince project. Yes, I haven't looked in detail at your patches, but if it was possible to add this feature to Read without modifying evince, it would be much better. We don't want to maintain this fork of evince forever, so we try to maintain the differences to a minimum because at some point we'll need to merge with upstream. Have you already considered handling the key binding in ReadActivity._key_press_event_cb() instead? Thanks, Tomeu _______________________________________________ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel