Work at SourceForge, help us to make it a better place! We have an immediate need for a Support Technician in our San Francisco or Denver office.
There's a super-simple patch to make GtkSpell work with Gtk3 which was submitted to RedHat  in February. Perhaps someone could commit it here and make a new tarball...
Ok, I'll work on that, will report back as soon as I'm done - hope by next week.
Ok, here we go: https://github.com/manisandro/gtkspell2 (branch changes). I'll recreate the gtkspell3 patches once the gtkspell2 changes are accepted into master.
Sandro, thanks for the patches.
I've reviewed and here are some notes, comments and questions:
There must be no API removals or ABI changes in the gtkspell2 branch - people who previously compiled against 2.0.16 need to be able to run with (and compile against) 2.0.17 (or 2.1.0 - whatever this gets named). This means that https://github.com/manisandro/gtkspell2/commit/0cfcbf3dd92e3d262db2ee9b9e77d8cb7b2e736f will need to wait for the gtkspell3 branch.
What is the deal with the removal of "docs/tmpl"?
I'm not sure about the reformatting commit.
It's certainly good it is done separately than the rest (although there appear to also be some formatting changes in d46cb5f662efda560ddeda686bd4da243839f1bd), but I'm not really convinced that it's really worthwhile to change all the existing code just for formatting reasons.
Was this done manually or did you use a utility to apply the formatting?
The rest of this seems reasonable and safe to include in gtkspell2 - I still need to compile and do a little testing though.
- The gtkspell_attach function exists again and is valid, so as far as that function is concerned there is no problem.
- For the gtkspell_init on the other hand, there is a problem: the GObject system forces me to create a gtkspell_init function and to call it that way. While the old deprecated gtkspell_init has a different signature, this does not help since C does not support function overloading... Hence from what I can see, an API break is unavoidable, but at least the user gets a compilation error (because of the signature mismatch), and therefore the case where gtkspell_init gets called twice (once because of the GObject init, once because of the call in the user code) is avoided.
From what I can tell they were simply the autogenerated files which were added to version control. Additionally, I got some compilation warnings (i.e.
"../gtkspell/gtkspell.h:21: warning: Documentation in template ./tmpl/gtkspell.sgml:114 for GTKSPELL_ERROR being overridden by inline comments.", and similar for GtkSpellError and GtkSpell). For that reason, I think it is best to simply let gtk-doc autogenerate them always.
Refromatting: it was done with a combination of regular expressions. There are indeed some formatting changes in d46cb5f662efda560ddeda686bd4da243839f1bd, essentially because I copied the functions from the gtkspell3 branch and did the GtkspellSpell -> GtkSpell renaming
Hmm... This is a problem. Unless there is a way to avoid the API and ABI breakage, it isn't going to be possible to include this in the gtkspell2 branch.
I think it should be possible to keep the function in deprecated.c as it is now and to simply define GTKSPELL_DISABLE_DEPRECATED at the top of gtkspell.c before gtkspell.h is included to avoid a naming conflict. The new function is static in gtkspell.c and not part of any exposed API.
I'm not familiar with the origins of the docs/tmpl files, as long as the doc generation still works and looks the same without them, I'm fine killing them.
Ok, done and working. (For some odd reason, the GitHub web interface is out of sync at the moment (but git clone works fine), the latest changes were performed around Tue Feb 7 00:10:00 CET 2012).
We're getting closer.
There still is an issue with gtkspell_attach.
Previously the signature was "void gtkspell_attach(GtkTextView)" now it is "gboolean gtkspell_attach (GtkSpell,GtkTextView*)"
I think the easy fix (which fits in with the minimalist approach of getting gtkspell2 gobjectified) is to eliminate the new "gtkspell_attach" and "gtkspell_new" public functions and to restore the deprecated "gtkspell_attach" function.
Uh, this is starting to get a little ugly. The next problem ist that gtkspell_detach does not delete the object anymore as previously. I'd actually suggest a radically new approach:
- GObjectify the gtkspell class as gtkspell_spell (as in the GTK3 version)
- Introduce GtkSpell as a dummy struct containing a GtkspellSpell (or typedef GtkspellSpell as Gtkspell?)
- Create wrapper functions which use the old API and perform the respective actions consistently with the old API
If you take that approach - emulate gtkspell2 on top of gtkspell3 then there is not much point waiting with the release.
As I understand it applications can be easily adapted for gtkspell3 and non-adapted applications would fail to build with the new headers.
I don't understand what you mean, hramrach.
gtkspell3 depends on GTK+ 3 - nobody is proposing that gtkspell2 be a wrapper / emulation layer for gtkspell3 because that isn't an option.
What is being discussed is how to implement gobjectification for gtkspell2 without breaking existing applications that use gtkspell2.
I don't see myself moving to GTK+3 any time soon for a variety of reasons.
I'd rather not introduce a completely new public API for gtkspell2 and have yet another set of deprecated functions to provide backward compatibility. :(
I can't look at the issue that you mentioned with gtkspell_detach because the changes branch isn't on the github repo anymore.