There's a super-simple patch to make GtkSpell work with Gtk3 which was submitted to RedHat [1] in February. Perhaps someone could commit it here and make a new tarball...
So concerning the signal: I had the problem that I had another control for setting the spellcheck language, and if the user would then modify if from the menu, the two would get out of sync.
If you find it necessary I'll fix up all the coding style related stuff.
Concerning compiling: compiles fine without warnings, the only problem is that gtk-doc does not recognize the annotation tags. The fix is mentioned here http://live.gnome.org/GObjectIntrospection/Annotations (all the way down), but as soon as I add the mentioned include, I get all sorts parser errors, I guess because it's a sgml file and not an xml. Maybe the docs should be ported to XML?
Um, I'm the original poster, not the maintainer... but I'm a Gtk-quartz maintainer, so I've gotten sensitized to the coding standards (meaning I've been whacked often with a rolled up copy ;-) ). It's up to Daniel Atallah, the current project owner here, to decide whether you should fix up the coding style to match Gnome's (and whether he should, too ;-) ).
I don't know if he's still monitoring this, having closed it; if he doesn't respond in a few days you should open a new ticket and attach a set of patches... but I'd break up the 77403c20 commit to separate making the GtkspellSpell GObject, the introspection annotations, the new signal, and any other added features that I missed (a separate patch for each) -- and leaving out any gratuitous reformatting. (If you were submitting this to Gtk we'd want a separate bug report for each of those patches.)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I really need to apologize for being extremely unavailable.
Unfortunately, my time for side projects has been practically non-existent the past few months.
There hasn't been a release of the currently committed 3.0.0 changes (and that probably is a good thing because it makes it possible to do this sort of thing without a further version bump).
The GObject-ification is something that I've really been wanting to do, so I'm really happy to see a patch that does that.
As far as the coding style goes - this is old code and very little of it is actually mine. I certainly agree that isn't the most consistent. I'm not necessarily a huge fan of the gnome style, but I think that consistency is more important than anything else (within reason) where coding style is concerned. I'd be happy if new stuff were to be consistent, but I don't think it is a strict prerequisite to accepting a patch.
Now for some comments about the actual changes:
Good job removing the deprecated functions - I should have already done that.
I'm not super happy about the function name changes, but if that is what's needed to make this work, it isn't the end of the world.
The ability to tell when a language is changed is a good thing - I opened a ticket for that a while ago [1]
I wonder if some variation of this (without the API changes) could be adapted to the GTK2 branch - started down this path a while ago and didn't have time to finish. If so, I would rather this be done like that (and then the API changes be made to the 3.0.0 branch).
Do you think that is reasonably doable?
I do agree with John's sentiment of separate patches / commits for separate features, but I don't think it needs to be a separate ticket (this is such a low activity project that it isn't really necessary).
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The usual pattern for broadly applicable major changes is to do them on the development branch ("default" in Hg) and then backport them to stable branches.
GSignals are part of GObject, so you'd need to backport the GObjectification as well. You could just call the object GtkSpell in Gtk2, there's not much point in using GObject-Introspection there. That would let you keep mostly the same API, you'd just make gtkspell_new_attach() a convenience function that calls gtkspell_new() (itself a convenience function for g_object_new (GTKSPELL_TYPE) ).
As for coding style, I'm not fond of parts of it either, but ISTM if a project is named "gtkfoo" or "gnomefoo" it ought to follow the Gnome style.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I could also give the gtk2 version a shot, i.e. apply b0c5359e32242b263c637ec6266a0dd4ee349c71 to the gtk2 branch with some changes (gtkspell_spell -> gtkspell, gtkspell_new_attach as a convenience function).
Feedback welcome.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
You went a bit further than just fixing it up for gobject-introspection. What's your use-case for the LANGUAGE_CHANGED signal?
There are a lot of coding style errors (but there are in the original, too): http://git.gnome.org/browse/gtk+/plain/docs/CODING-STYLE
Other than that, it looks fine... but I haven't tried to build it, nor do I have a good gtk3 test bed for it.
So concerning the signal: I had the problem that I had another control for setting the spellcheck language, and if the user would then modify if from the menu, the two would get out of sync.
If you find it necessary I'll fix up all the coding style related stuff.
Concerning compiling: compiles fine without warnings, the only problem is that gtk-doc does not recognize the annotation tags. The fix is mentioned here http://live.gnome.org/GObjectIntrospection/Annotations (all the way down), but as soon as I add the mentioned include, I get all sorts parser errors, I guess because it's a sgml file and not an xml. Maybe the docs should be ported to XML?
Usage: works as expected afaict, using it through PyGi atm. Feedback from here is also positive: https://bugzilla.redhat.com/show_bug.cgi?id=675504#c10
Um, I'm the original poster, not the maintainer... but I'm a Gtk-quartz maintainer, so I've gotten sensitized to the coding standards (meaning I've been whacked often with a rolled up copy ;-) ). It's up to Daniel Atallah, the current project owner here, to decide whether you should fix up the coding style to match Gnome's (and whether he should, too ;-) ).
I don't know if he's still monitoring this, having closed it; if he doesn't respond in a few days you should open a new ticket and attach a set of patches... but I'd break up the 77403c20 commit to separate making the GtkspellSpell GObject, the introspection annotations, the new signal, and any other added features that I missed (a separate patch for each) -- and leaving out any gratuitous reformatting. (If you were submitting this to Gtk we'd want a separate bug report for each of those patches.)
Uhm ok, thanks for the review in the meantime!
I really need to apologize for being extremely unavailable.
Unfortunately, my time for side projects has been practically non-existent the past few months.
There hasn't been a release of the currently committed 3.0.0 changes (and that probably is a good thing because it makes it possible to do this sort of thing without a further version bump).
The GObject-ification is something that I've really been wanting to do, so I'm really happy to see a patch that does that.
As far as the coding style goes - this is old code and very little of it is actually mine. I certainly agree that isn't the most consistent. I'm not necessarily a huge fan of the gnome style, but I think that consistency is more important than anything else (within reason) where coding style is concerned. I'd be happy if new stuff were to be consistent, but I don't think it is a strict prerequisite to accepting a patch.
Now for some comments about the actual changes:
Good job removing the deprecated functions - I should have already done that.
I'm not super happy about the function name changes, but if that is what's needed to make this work, it isn't the end of the world.
The ability to tell when a language is changed is a good thing - I opened a ticket for that a while ago [1]
I wonder if some variation of this (without the API changes) could be adapted to the GTK2 branch - started down this path a while ago and didn't have time to finish. If so, I would rather this be done like that (and then the API changes be made to the 3.0.0 branch).
Do you think that is reasonably doable?
[1] https://sourceforge.net/tracker/?func=detail&aid=3015525&group_id=7896&atid=357896
I do agree with John's sentiment of separate patches / commits for separate features, but I don't think it needs to be a separate ticket (this is such a low activity project that it isn't really necessary).
The usual pattern for broadly applicable major changes is to do them on the development branch ("default" in Hg) and then backport them to stable branches.
GSignals are part of GObject, so you'd need to backport the GObjectification as well. You could just call the object GtkSpell in Gtk2, there's not much point in using GObject-Introspection there. That would let you keep mostly the same API, you'd just make gtkspell_new_attach() a convenience function that calls gtkspell_new() (itself a convenience function for g_object_new (GTKSPELL_TYPE) ).
As for coding style, I'm not fond of parts of it either, but ISTM if a project is named "gtkfoo" or "gnomefoo" it ought to follow the Gnome style.
Ok, so i splitted up the changes into small patches, work is in the new branch "changes", here
https://github.com/manisandro/gtkspell3/tree/changes
I could also give the gtk2 version a shot, i.e. apply b0c5359e32242b263c637ec6266a0dd4ee349c71 to the gtk2 branch with some changes (gtkspell_spell -> gtkspell, gtkspell_new_attach as a convenience function).
Feedback welcome.
Any news on this?
I guess I was waiting for the gtk2 branch changes.
I think it makes more sense to make those in the gtk2 branch, merge them up to the gtk3 branch and make the additional cleanup changes there.
Trying to backport part of another set of changes is a recipe for merge nightmare.