Created attachment 38369 [details]
new files

Created attachment 38370 [details] [review]
glue

Forgot to mention that we will have to move the gnomecanvas stuff somewhere
else, probably libgail-gnome.

ok, gnomecanvas stuff should probably go to gnome-canvas itself. 
We also have to change the libgail-util soname.
Longer-term we may want to evaluate the libgail-util usefulness and move the
useful stuff into gtk. The same goes for the module itself, if moving the a11y
implementation to gtk does not affect performance.

Created attachment 39077 [details] [review]
move gail canvas bits to libgnomecanvas

A minimal patch which moves the canvas a11y bits into gnome-canvas, without
renaming or reorganizing anything. 

I don't know if this actually works.

one thing which I don't see, which I expected, were calls to
atk_registry_set_factory_type (registry, GNOME_TYPE_CANVAS_WIDGET,
GAIL_TYPE_CANVAS_WIDGET_FACTORY);  etc., so that the atk_registry (not to be
confused with the at-spi-registry ;-) ), knows what factory to use in order to
create appropriate AtkObjects for specific GObject subtypes.

This also is the area where any possible conflicts between the old libgail and
the new implementation would get resolved - the latest call to
atk_registry_set_factory_type() replaces any prior registrations for that type.

- bill

Ah, thats probably because some files were missing from the patch.

Created attachment 39081 [details] [review]
new version

Punting some big, unfinished features from 2.8

What's the status of this right now?  Is there anything I can do to help with it?

The libgnomecanvas a11y support has been moved from gail to libgnomecanvas, in bug 363103. That was the only thing blocking this bug, so I guess it could move forward now?

* Do we want to preserve the svn history on import?
* What about the PO files in gail; create another domain for them, or merge them into the main domain? There are about 100 strings in gail currently.

I don't think preserving svn history is super-important, the old module will not just go away. But if you can do it without bending over too far, it would be nice.

The po files, I'd just merge. Might be worth to look over the strings and see if they are worthwhile at the same time.

Created attachment 100719 [details]
updated patch: glue and new files (.diff.gz due to size)

Didn't find an easy way to import the svn history, so this is just the latest version from gail svn.

Remaining:
- import the po files
- import the tests
- gailwidget.h is installed in $includedir/gail-1.0/gail. I guess we should make that $includedir/gtk-2.0/gail ?

About the po files: the only translatable strings in gail are in gailimage, where they're used to get some sort of 'name' for images with storage_type GTK_IMAGE_STOCK. They seem to be exactly the same strings as the stock item's label, except they're in lowercase and without mnemonics. I think it'd be better to remove them and just use the stock item's label, processed like we do in gtktoolbar.c. That should be a follow-up bug though.

Sounds right. 

>  gailwidget.h is installed in $includedir/gail-1.0/gail. I guess we should
> make that $includedir/gtk-2.0/gail ?

I'd just leave it there for the initial merge. A lot of the stuff in there is probably up for cleanup as we proceed to integrate the gail bits more closely.

The patch looks good to me in general. 

Li, do you want to review it, or should we just go ahead and do the merge ?

This probably also has some consequences for the ongoing maintenance of the standalone and (the merged) gail, so just say if now is a good time for you to do the merge.

The patch is OK for me if there is no change in the code (*.c/*.h). Please do the merge. And thanks for your work :)

I think the work left for standalone gail is previous releases' branches, right? I will still work on it.

And I'd like to go on maintaining gail in the future. Can I commit patches for gail directly after the merge?

Yes, I'd appreciate if you (or other people who know the gail code) would keep maintaining it after the move to GTK+. 

(In reply to comment #18)
> The patch is OK for me if there is no change in the code (*.c/*.h).
It's straight from gail svn, with only the include of gdkx.h fixed, and the i18n code in gailimage.c #if 0'd (see comment 14; I'm going to fix that up in a follow-up bug).

Please refer to Bug #122549, I think we created these strings because we want the name of the gailimage is translated. So instead of returning the stock_id (like gtktoolbar.c), maybe we can return the stock label.

Anyway, this patch is OK for me.

Should we commit the patch?

yes, I was waiting for Christian or you to do that.

I was waiting for 'accept_commit-now' state :)

I'll commit the patch today.

The last attachment is not a patch, so bugzilla doesn't think it can be committed...

But anyway: accept-commit-now !

        * configure.in:
        * docs/reference/Makefile.am:
        * docs/reference/libgail-util/*:
        * gail-uninstalled.pc.in:
        * gail.pc.in:
        * modules/Makefile.am:
        * modules/other/Makefile.am:
        * modules/other/gail/*:
        * modules/other/gail/libgail-util/*:
        * po/POTFILES.skip: Integrate gail into gtk+. Bug #169488.

Way cool guys!  Does this mean the old gail module is now in maintenance mode for GNOME 2.20 and prior?

I'll have to live on for at least 2.22, since we don't plan to do a gtk release before next guadec.

I tried gtk+ trunk and found two problems:
1. libgailutil.so's version is changed, because it is now using gtk_binary_age. This means all applications built before cannot start. Is this breaking binary compatibility?

2. libgail.so now doesn't link to gtk and gdk libraries anymore, which could be a problem for python applications. I will paste a patch.

Created attachment 101305 [details] [review]
patch to add gtk and gdk libraries to DEPS

I filed new bugs for the things from comment 29, bug 504643 and 504645.

Can we install gail.pc? libgnomecanvas is depending on gail now.

I filed bug 505859 for that. In future, please open a new bug instead of adding comments to closed bugs :)