Bug#722451: Adoption
Well, I just added the changes that I needed in Knoppix. They are small
compared to the frequent upstream work on the Ubuntu launchpad. On the
other hand, my version is probably better tested because of inclusion in
Knoppix (with around 8000-20000 downloads per day), compared to the
upstream compiz version that Ubuntu seems to maintain last but not least
as a testcase for their own unity desktop. The main development work is
done on launchpad, whereas I just pull the sources once or twice a year
when there is a major upgrade, and include them in Knoppix since compiz
is one of the main features there. Adopting the upstream launchpad
version with its frequent changes from bzr, may cause you more work, but
would be closer to the original authors of the software. It would also
in my interest because if you are maintaining compiz in Debian
officially, I can stop creating a fork of the upstream compiz version.
If you choose my version, we have a packaging chain like this:
launchpad-based development from upstream authors -> Knoppers testing
distribution -> Debians official packaging
But what changes do you do that imply a "Knoppix step" instead of
maintaining directly in Debian? Why couldn't your work be done directly
in Debian? I ask because:
1. I think we want in Debian a Compiz more similar as you do than this
from Ubuntu, given they try to make it work for Unity, not us.
2. Do you do code patches? Important code patches?
Why couldn't the string be: upstream -> Debian (with you as
co-maintainer and your release). It matches to Debian philosophy:
stability, safety; it gives a cleaner package without Unity integration,
etc. Why would we need, between upstream and Debian, a step in Knoppix
instead of applying directly your work in Debian? Again, due to Unity
integration and not priority for a11y, I don't think Debian has interest
to use upstream release if you patch it in the direction we hope.
Should be OK, too, then I will function as a proxy. It's your decision,
of course. Just tell me the final result, so that I won't accidentially
switch back to the official Debian package while the official Debian
package just uses Knoppix packages as upstream, so we have a loop which
is likely not being synchronized with upstream development again. ;-)
Well I really think we could use directly your work, which is a kind of
filter with upstream, directly in Debian instead of creating a
knoppix-"step".
and it's excellent given the
few time before freeze and the complexity of the package. So I think
I'll put in Debian what you do for Knoppix, it seems relevant.
True, there are time constraints, and once the packages are in Debian
before feature freeze, you can probably still change the upstream source
later, so adopting the packages that work for Debian-based Knoppix right
now is probably the quickest way to do it.
You may want to recheck if my preference for using file-based settings
in $HOME/.config/compiz-1/compizconfig/* instead of using gsettings, is
suitable for Debian. I think a file-based configuration has less hidden
dependencies to gnome, though, while in Ubuntu, they keep everything
inside the gnome configuration scheme by default so it's configurable
with the central configuration GUI instead of needing its own "compiz
configuration settings manager" (ccsm). If not, change the "backend =
ini" parameter in /etc/compizconfig/config back to gsettings
accordingly.
Ok I'll check. I hope to use ccsm yes, but shipped typically in
settings. I'll think of this.
I just uploaded the 0.9.12.0 compiz version based on
https://launchpad.net/compiz/+milestone/0.9.12.0, which features two
IMHO important accessibility patches (that I also attached here). They
fix the erraneous transparency on first usage of the ezoom and annotate
plugin (mouse curser and writing on screen were almost invisible unless
you activated the "magnify" plugin temporarily). I already suggested the
patches on the compiz bugtracker:
https://bugs.launchpad.net/compiz/+bug/1362005
https://bugs.launchpad.net/compiz/+bug/1362009
They have not been reviewed that, though.
But are these changes packaged in
http://debian-knoppix.alioth.debian.org/packages/compiz
Yes, they are included in my packages and well tested in Knoppix 7.4.1
and 7.4.2. I had sent the patches to upstream, but they have not looked
at them yet.
? What's the status of your patch above (in launchpad) in
debian-knoppix (uploaded? waiting for acceptation on launchpad
before shipping in debian-knoppix, etc)?
Waiting to be reviewed. But due to the technical context, these changes
should be considered harmless, i.e. compiz wll not crash just because I
changed the color settings before drawing, which is already done in
other stable plugins, too.
Nevertheless, if you plan to adopt compiz in Debian again, I'd suggest
using the upstream sources on https://launchpad.net/compiz rather than
my modified version on
http://debian-knoppix.alioth.debian.org/packages/compiz and coordinate
with the project maintainers, which is just what Jean-Philippe Mengual
suggested.
But given details you gave, it's useless. It seems much more
relevant to use your package, put them in Debian, and work you and
us in order to stay synchronoous with Canonical. I don't think 2
"branches" should exist, I would prefer Debian + knoppix merge sfnce
the base is similar.
It was mainly two packages and tools that don't exist in Debian which
caused the original debian/* recipes to fail outside of Ubuntu. If you
have some time now or later, you way want to check comparing a fresh bzr
checkout of compiz 0.9.12.0 from launchpad to my source. Unfortunately,
being lazy, I did not create a patch for all of my changes except the
two plugin fixes I mentioned, but changed the source files directly in
about 4 places. Also time constraints for a quick release. :-/
Oh! You mean that all your patches are not applied at each deb package
generation? They're hardcoded? If yes, after packaging, I think it worth
to compare both upstream and your files to apply patches more properly.
Running a diff between upstream compiz 0.9.12.0 and my source should not
be very large.
So it worth try to make the package clean in changes it brings in the code.
Once compiz is officially back in Debian, I will happily use
that version rather than my forked version. I do need at least the ezoom
patch included in Knoppix, though, since ezoom (Super+Mousewheel) is an
important accessibility feature for users with low vision and is also
practival for presentations where the mousepointer should be visible.
Just to be sure: can we take your package, ship the patch, upload in
Debian?
Yes, of course, it's open source and I know my packages are working in
Debian testing and unstable. :-)
Or do you prefer to wait some Canonical's feedback?
Waiting for them could take a few weeks, they work in bursts on compiz
and sometimes longer pauses in between, following the Ubuntu release
cycle. I think they would be happy if Debian adopts their work, I
already had a few email conversations with them.
I really
would like to merge Debian and you, so that your maintainance work
is automatically shipped in Debian. It'll improve Debian+knoppix
a11y, and will represent less work for me with low dev skills.
Sure, no problem. :-)
But we should keep a switch to the main development source in mind for
later, and start an email exchange with upstream so they may find a way
to provide additional build configurations for original Debian
additionally to their current Ubuntu-only builds, and save both of us
some work.
True.
Last question: does Compiz magnify know to "follow the focus" now?
The "ezoom" plugin has an optional setting to zoom and scale to newly
appearing windows, menus and popups (through their initial focus event).
So, if a dialog appears outside of the currently visible magnified area,
ezoom will reposition the visible range and scale to that new window, so
you don't miss it. In standard operation, it just follows the mouse. I
attached two screenshots of the corresponding settings in ccsm.
What you probably have in mind and what is often asked for, is the
possibility to follow the "text cursor", for example if typing in
LibreOffice. The problem seems to be getting the coordinates of the
"text cursor" from the X server. This has not been done in compiz or
ezoom yet. Do you know any other magnification software that can follow
the "text cursor", which I could use as a template in order to improve
ezoom?
I believe gnome-mag with Orca did that in 2.x releases. Ok so it's
something to do.
Regards,
Regards
-Klaus
--
Jean-Philippe MENGUAL
accelibreinfo, votre partenaire en informatique adaptée aux déficients visuels
Mail: texou@accelibreinfo.eu
Site Web: http://www.accelibreinfo.eu
Reply to: