GtkSourceView 2 API frozen
September 11th, 2007 — pborWith yesterday night release of GtkSourceView 1.90.5 (which will likely become 2.0 next week) we consider the API frozen and in the future releases only API additions will happen.
Honestly we hoped to have more early adopters so that we could have more feedback on the API changes, but I can understand how painful it is to track a library that it is a bit of a moving target :)
Anyway, now it’s a good time to start porting your app to GtkSourceView 2 and an even better time to bind it to your favourite language (Python bindings are already available). Why? Because you get a way more accurate syntax highlighting and because you get support for style schemes.
I will not go into the details of the API changes (most of it should be straightforward), my advice is just to be careful with the memory management of the LanguageManager and StyleSchemeManager: unless you want to do advanced stuff like a style scheme editor or use two separate highlighting contexts in the same app, you should probably stick to the singletons provided by GtkSourceView itself.
That said, I should also point out that there are a few feature regressions with respect to GtkSourceView 1 and anyone getting ready to port his app should be aware of that:
- Printing support was dropped: GtkSourceView 1 depended on gnome-print which is now deprecated, this days printing should be done with gtk itself.
- GtkSourceMarkers were dropped: they were pretty much the only API that is not exercised by gedit and we didn’t feel comfortable enough with the API to set it in stone.
We are more than willing to reintroduce these features back in 2.2 (though printing is a bit of a gray area since bits of it really belong to gtk itself), but we need feedback from the apps using the library to get the API right!
September 11th, 2007 at 9:26 am
Mono bindings are available too: http://anonsvn.mono-project.com/viewcvs/trunk/gtksourceview2-sharp/
Thanks for the work on GtkSourceView 2; I’m looking forward to getting the new features into MonoDevelop!
September 11th, 2007 at 9:42 am
Good work!! But, I’m still missing something. Do you know if code folding is going to be introduced on 2.2?
September 11th, 2007 at 9:50 am
Folding is one of the big features on the map (along with a completion framework and indenters support) but it’s far from trivial, especially figuring out *where* to fold (we already have a patch for the folding display itself). Not sure if we can make it for 2.2… obviously help is appreciated :)
September 11th, 2007 at 11:42 am
I’m so happy to read about all this new possibilities of GtkSourceView and gEdit. Great work at all and will help me a lot porting SweeTS ( http://typo3.area42.de ) to gEdit/GtkSourceView.
September 11th, 2007 at 1:16 pm
Is there some list of API changes somewhere, or a porting guide?
September 11th, 2007 at 1:55 pm
Murray: there is http://live.gnome.org/GtkSourceView/PortingGuide but it’s not finished nor comprehensive, that’s why I didn’t link it. I’ll try to add more content as time permits.
However apart from the major issues listed there, the other api changes are mostly cleanups that should be easy to spot by just going through the gcc errors: e.g. renaming the ‘tabs-width’ property to ‘tab-width’ or renaming the ‘margin’ property to ‘right-margin-position’.
September 11th, 2007 at 7:09 pm
Does the new syntax-with-a-syntax support cover things like XML docs in C#?
///
September 11th, 2007 at 7:10 pm
That didn’t print right:
/// <see
/// cref=”string” /<
September 11th, 2007 at 7:25 pm
Brian: Yes, it can highlight stuff like that, for instance we highlight gtk-doc inside C comments. That said, currently csharp.lang doesn’t take advantage of that… patches are welcome! :-)
September 13th, 2007 at 7:59 am
I am currently maintaining a project called gnusim8085 which uses GtkSourceView as editor component. It is a 8085 simulator and we use GtkSourceMarker to mark debug points in the editor.
Also for this simulator we had developed a .lang file for 8085 syntax highlighting. It was submitted in a bug on GNOME bugzilla. Looks like it will never get included in GtkSourceView now. I will be glad if it gets included in GtkSourceView2.
http://bugzilla.gnome.org/show_bug.cgi?id=412587
You can try the simulator yourself if you wish. http://www.sourceforge.net/projects/gnusim8085
September 13th, 2007 at 12:39 pm
In Glom, we currently have this code (simplified and translated to C), to get python syntax highlighting:
GtkSourceLanguage* language = gtk_source_languages_manager_get_language_from_mime_type(“application/x-python”);
GtkSourceBuffer* buffer = gtk_source_buffer_new(language);
gtk_source_buffer_set_highlght(buffer, TRUE);
gtk_text_view_set_buffer (text_view, buffer);
Not what get_language_from_mime_type() is gone, how should we say that we want Python sytntax highlighting?
September 13th, 2007 at 12:52 pm
Onkar: what to do with assembler highlighting is being a bit debated internally because usually there is no mime type for assembler and because there are many assembler variants, but hopefully for the next version you’ll get both the lang file and the markers api back so that your app can benefit from gsv2. Anyway note that the api allows an app to specify a cutsom path where to look for lang files.
Murray: since you already know which language highlighting you want you can simply use gtk_source_language_manager_get_language() and use the id of the language you want, in this case simply ‘python’
October 9th, 2007 at 6:01 pm
I am using gtksourceview (and gtksourceviewmm) in a debugger application, and I depend on source markers to show breakpoints, the line at the program counter and so on, as you can see here:
http://www.zero-bugs.com/images/zero-2.png
What are my options, to stick with gtksourceview-1.0 until the markers make it into the 2.2 API? Do you have any better recommendations?
Thank you!
October 9th, 2007 at 8:45 pm
Cristian: yes, I guess you can either stick to version 1.0 and wait for 2.2 to come out with gnome 2,22 or you can try to reimplement them locally for now (it’s not that much code, though you would probably need some hacks to draw markers in the left margin…)
Oh wait, I have a better idea: you can submit a patch to make markers happen sooner than later! :-)
October 9th, 2007 at 11:52 pm
“Oh wait, I have a better idea: you can submit a patch to make markers happen sooner than later! :-)”
My understanding was that it is not a matter of implementation as much as it is about the API not being completely flushed out as of this time (WRT markers)…
October 10th, 2007 at 8:14 am
Yeah, we want to revise the API a bit and since once released the API is set in stone we decided to punt it for 2.0.
That said with the word “patch” I meant that help is very much welcome both in figuring out the best API and in the implementation.