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, 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.
sorry, I've readded the branch (I wanted to implement what you suggested but then realized the problem with gtkspell_detch).
As for the problems: at this point I am wondering, is there any real benefit of having the gobjectization in the gtkspell2 branch? Obviously the main reason is mantainability resp having the gtkspell3 branch diverge as little as possible from the gtkspell2 one, but compatibility with the deprecated functions prevents us from having a clean gobject in the gtkspell2 version.
As far as I can judge the addition of new deprecated functions is really the cleanest solution which also allows the gtkspell2 and gtkspell3 branches to share nearly all of the code (basically everything except deprecated.c).
I've added another branch, changes2, for the GtkspellSpell variant.
So... I'd really hate to see this stalled. The reason I started working on this is because I need gtkspell3 for an application, and want to avoid shipping a non-official/non-upstream version. So, if you have other suggestions for the gtkspell2 branch, I'm willing to work on those, since ultimately I'd really like to see gtkspell3 materialize.
Looks stalled. :-(
Daniel, Sandro's changes to GtkSpell3 are necessary for gobject-introspection bindings. If you don't want to backport them to GtkSpell2 because it changes the API, that's fine, gi isn't used much by Gtk2 users. But please do commit Sandro's Gtk3 changes and do a release. GRAMPS (http://www.gramps-project.org) is converting to Gtk3 and they're right now as a workaround using Sanro's Github repo.
I would just like to indicate that moving from current gtkspell to the gtkspell3 branch of Sandro is in python a 5 line patch:
As an application developer my main concern would be API stability. We aim for release spring 2013, so up to end 2012 we can easily change API, after that, we need if constructs if API would change.
So, at this point the question is what next. I've again got some time to work on my original project, and really would like to see this resolved somehow. Unfortunately, it does not look as if the maintainer is still active. If the maintainer is still reading this and simply does not have time to deal with the work required, I would be happy to help co-maintain. Otherwise, an interesting option would be to attempt to make gtkspell an official gnome project, like gtksourceview. Thoughts?
It came up on gtk-devel-list back in January . I suspect that the Gtk/GLib maintainers would prefer to move the functionality into GtkTextView, perhaps with the actual spell-checking code in gio somewhere.
There were also several discussions back in late 2005/early 2006 about it (you can find them if you google "gtk-devel-list" gtkspell -- include the quotes). One concern then was the enchant dependency.
Anyway, the only way to find out would be to bring it up there.
Sandro, I'd be happy to take you up on your offer to help maintain the project; I've added you to the SF.
I simply haven't had any time to spend on this, and don't see the situation improving soon.
Ok, I'll have a look soon, thanks!
Daniel, I'd need to know the following before I can move forward:
- Do you want Gtk2 Gobject-ification, or keep Gtk2 as is and make gtkspell3 a new repository?
- Would you like me to handle the release? If so, I'd also need access rights to the sourceforge project page.
I thought that you'd make Sandro an admin for the project. You should.
I thought I had already given Sandro admin for this project, but I guess not. That has been corrected now.
We have to be careful about not breaking backward compatibility for the gtk2 branch.
Ideally it'd get GObjectified too, but perhaps that's a lower priority than finalizing the gtk3 branch and getting it out and available to the people who need it.
If you feel up to doing the release, that would be great.
It may not be realistic given my unresponsiveness, but perhaps it'd be best if I can review what you're about to release before it actually goes out?
Now is the opportunity to make API changes for the gtk3 branch and it'd be good to make sure that we get it right before it is released.
There is a thread on the mailing list (https://sourceforge.net/mailarchive/forum.php?thread_name=20120726145723.GA4194%40aragorn.home&forum_name=gtkspell-devel) that has some thoughts about the API.
Please also remember to update all the translations from the translationproject page (http://translationproject.org/domain/gtkspell.html).
So, I've been playing around with the package in the past few days, and would like to hear some opinions on the following points:
- Do we want gtkspell2 and gtkspell3 as separate packages, or one gtkspell package with both variants (which will probably appear in the distros as gtkspell-gtk2 and gtkspell-gtk3). From my experiments, the second variant is doable, and possibly a lower burden to maintain. Furthermore, one could also offer --disable-gtk2 / --disable-gtk3 options. Clearly, the unified package would include a series of compatibility functions for backwards compatibility with the current gtkspell2 API.
- Namespace, class name: as was discussed on gtkspell-devel, I have now changed the namespace it to GtkSpell (aka gtk_spell_**), but in my opinion gtk_spell_inline_checker is too long. I would rather propose simply gtk_spell_checker, since realistically I guess future extentions would hardly go beyond including an assistant/dialog, which may then well be called gtk_spell_dialog or gtk_spell_assistant.
Frankly, I don't see any good reason to combine them. Gtkspell for Gtk2 is very stable, and there isn't any further development for Gtk2. The current release is fine, so leave it and just work on Gtk3.
For Gtk3, the namespace and function name changes are fine; compared to migrating everything else to Gtk3 it's minor, and the namespace change is needed for GI.
I like the idea of keeping the option to compile a Gtk2 version of the GObjectified gtkspell3 as long as it's not going to be significantly more work. I would envision binary packaging to work like you mention. I guess I don't necessarily see the need for backward compatibility with the gtkspell2 API/ABI at all.
Your namespace proposal sounds fine to me.
Here we go: https://github.com/manisandro/gtkspell
By default, only the gtk3 variant gets built. If --enable-gtk2 is provided, also a gtk2 variant is built. The autotools scripts are pretty much rewritten. It should be installable cleanly side-by-side with the existing gtkspell binaries in the distros (even the gtkspell3-gtk2 package).
Daniel, if you prefer to have patches against the current gtkspell2 code, I can do so. Furthermore, I guess we need a new gtkspell3 repo. I actually have never used mercurial, so maybe you want to take care of that? Or we could switch to using git.
Hmm... I don't see any commits except the initial import and one that changes the Readme and copyright stuff - am I missing something?
I'd prefer we stay with mercurial.
The sourceforge instructions for creating a new repo are here:
I don't think we need a new repo for this though - the default branch of the current repo is intended to be the gtkspell3 code (there is a gtkspell2 branch as well).
Ok, so I've revived the changes branch from my gtkspell3 repo and created a series of patches against master, see
Daniel, one you're ok with the changes, are you going to apply the patches?
I feel a little bit like a broken record, but my first reaction is that I really don't like the formatting changes, I kinda hate the GTK+ formatting :(
It's also hard to tell what actually changed in e.g. https://github.com/manisandro/gtkspell3/commit/f17d2bb11fc6d26ed79a827bcb6afeb5c474492c because there are a bunch of formatting changes at the same time.
From a functionality perspective, I'm concerned with the change in behavior in the GtkSpellChecker object's normal lifecycle compared to the previous GtkSpell usage - specifically, I think it's a problem that it's necessary to clean it up manually. I think it makes more sense for the GtkSpell to be destroyed automatically if the GtkTextView that contains it is destroyed (otherwise I think this is going to cause leaks because people aren't going to expect it to work like this).
Apart from that, I think it looks good - I'm glad to see that you updated the examples too.
Formatting changes: I'm also not a great fan of the GTK+ formatting, but I guess since the module is intended for the gnome world, it might as well comply with their rules. Also, if we don't take this opportunity to uniformize the coding style within the gtkspell codebase, I guess it will never happen.
The GObject commit is indeed quite large. I've recreated the patches and tried to make it less invasive, moving out many formatting changes to the corresponding patch. I guess the question then is whether I want to write the new methods on purpose with the "wrong" coding style just to spare a few lines in the patch - in my opinion it is not worth it.
Finally, I've now attached gtk_spell_checker_free instead of gtk_spell_checker_detach to the destroy signal of the textview, and updated the README accordingly.
Log in to post a comment.