Kind of bundling of GtkSourceView for gnome-latex and probably gedit too

Applications
,
1

In my opinion, libraries like GtkSourceView, Amtk or Tepl are more suitable to be bundled with the application when packaging it. Because it’s not something like the libc, they are much more higher-level, so quickly re-compiling a few programs is manageable, while re-compiling all libc-dependent projects is not desired in case of applying a security fix.

When developing GtkSourceView I have known several apps that bundle a copy of a subset of GtkSourceView, in fact. Even from a big contributor to GtkSourceView itself (for the syntax highlighting engine) with medit.

I contributed a lot to GtkSourceView in the past, and I’ve now restarted again development of gnome-latex and related projects. (I have the intention to come back to gedit development too, once some work in the libraries are done). As part of this work, I’ve started the development of a different version of GtkSourceView, with the API version 300. “3” is for GTK 3, and 300 is distant enough from other GtkSourceView versions.

Tepl’s and gnome-latex’s main branches have switched to GtkSourceView 300. But the code of GSV 300 itself remains in its own repository, located here: Sign in · GitLab

So it’s some kind of bundling, but distribution packagers can have the choice, since GtkSourceView 300 tarballs will be released separately from the other dependent projects.

Some things still need to be set up:

I’m sure we will find a solution. But at the beginning it will be more work for packagers.

As for the reason to create GSV 300, you can read this article: https://informatique-libre.be/swilmet/articles/gtksourceview-300.pdf

I know that some of the GNOME community will not be pleased by this change, but I prefer to announce it openly, instead of developing a product and then open-sourcing it with lots of bundling all over the place. Also, if it means that gedit is developed again, your reaction could also be “oh, well, that’s how it is”, and move on :wink:

2

Why can’t you submit bugfixes to gtksourceview? Then everyone using gtksourceview will benefit from your bugfixes instead of just your projects.

It is not a good naming convention to name your fork of gtksourceview “gtksourceview 300”. That is just going to cause confusion.

2 Likes
3

This is wholly unacceptable.

You are not the owner of the GtkSourceView project and never were simply because you contributed to it at some point. Nor am I the owner of the project. It’s part of the GNOME project and we need to treat it that way. We are simply stewards for moments in time.

When you stepped away from the project, a vacuum was left that needed to be filled. As the largest contributor beyond you at the time, I naturally filled that role given the importance of GtkSourceView to Builder and the GNOME ecosystem at large which will outlive each of us.

You’ve slandered me multiple times by making patently incorrect claims about things I’ve said or felt towards you that gave the false impression of hostility. It was unfair to me and I never received an apology for your unacceptable behavior. You don’t get to treat people like that and then not apologize. I deserve better treatment from you and I’m not wrong in asking for that to heal.

Then the GtkSourceView project didn’t evolve in a direction that I like, with different development priorities.

That’s completely fine. We have different timelines with products and when things need to ship.

Correctness first: quality, having as few bugs as possible. It means devoting more time to existing features, and developing fewer new features. It also means to test well the solution (unit tests, and interactive mini test programs).

This comes off a bit slandering too. I spent a great deal of time tracking down correctness bugs introduced by you and this somehow implies that I as the current maintainer don’t care about correctness. If you had been around to co-maintain GtkSourceView, it would (and still would) provide me a great deal of help by having a peer to code-review my and others work.

I’m not impervious to correctness bugs either and having peer review is most appreciated.

Don’t prioritize performances. Fix performance issues when it’s really a problem

Yes, it was a problem. I know that because I wrote the profiler to prove it which we now use throughout the stack (including in GLib, Pango, GTK, and GtkSourceView) to identify performance problems. We’re trying to ship a product-line that shows what GTK is capable of and that means caring about performance of the text editing stack including making sure things like scrolling are fast.

It means devoting more time to existing features, and developing fewer new features.

I just can’t win with you. Previously you complained that Builder had all these features that weren’t pushed upstream and that somehow meant that Builder was a bad actor in the ecosystem. Now I’ve done the work to land them upstream in a clean and maintainable manner and I’m somehow wrong for that too?

Where to upload tarballs: in the usual place under Index of /sources/gtksourceview/ ?

Absolutely not.

I object strongly and loudly. You are no longer the maintainer of GtkSourceView and therefore that directory is not yours to place tarballs into.

You need to choose a different name for your fork because it is exactly that at this point, a fork.

7 Likes
4

Christian, I know you have reason to be frustrated, but it would help if you tone things down here. Thanks.

Please don’t upload tarballs here. The problem is that trying to reuse the gtksourceview name for two different projects is very confusing. To avoid irritating other developers and confusing downstreams, just change the name. There’s a lot of precedent for doing this, e.g. emacs vs. xemacs, or ffmpeg vs. libav. Possible names: swsourceview for Sébastien Wilmet, gtksourcewidget, gtktextview, some combination of the above, or even gtksourceview-fork if you’re bad at naming things like I am. :wink: We still have people confused between RPM 4 (the real RPM) and RPM 5 (the fork), 15 years later, and gtksourceview 300 will be no different, so let’s avoid creating new trouble.

I am confident that both original gtksourceview and Sebastien’s gtksourceview 300 will be able to coexist just fine as long as we iron out the naming. Names are hard, but fortunately not an impossible problem. :slight_smile:

5

It is every packager’s choice if they want something bundled alongside their app or not. I am assuming you are a packager yourself. If so, feel free to bundle it with your app. Others will do whatever they want.

I agree with @jbicha, @chergert and @mcatanzaro about renaming GtkSourceView 300 to something else because it will cause confusion if not renamed.

6

After reading your article, I agree with @jbicha also on the fact that you could have and should have submitted the bug fixes directly to the official GtkSourceView.

7

Thanks for your replies, I’ll rename the project to gsv-for-tepl or tepl-gsv, something like that.

I wanted to add, the more a library is high-level, the more it is specific to just a few applications. Even though, as library developers we try hard to make things as re-usable as possible.

And in GNOME, there is also the libgd (a copy-lib), or Clutter being bundled with Mutter. The “tepl-gsv” is something in-between :wink:

3 Likes
8

An update, I’ve finished normally to rename the project to tepl-gsv: Sign in · GitLab

And updated the reverse-deps (Tepl and gnome-latex, mainly).

No release yet, but it’s in a releasable state (for the alpha/beta).

For the packaging, distributions can choose whatever model is more suitable. I suppose that with DEB or RPM (for example) it’s possible to take the different tarballs and put them in the same package, in a way that it doesn’t impact other programs. With Flatpak such bundling is a first-class citizen, that’s all I know. I also know that Debian is strongly against any bundling, but that’s fine, it will work either way.

If you have any more feedback, don’t hesitate.

9

Christian, with regards to the development priorities that - in my opinion - are different, here are more thoughts, with some hope that it will soften a little my wording in the small article that I wrote.

On my side, I now prefer to be satisfied by the statu quo (i.e. existing features), just do some improvements on it when working on a part of the source code.

On your side / the projects you work on, and I don’t mean that it’s bad per se, it’s just different: one of your project was, as you’ve said, to show what GTK is capable of. Performance is indeed one thing, but there is also all the work for adding animations or effects more generally. With GTK 3 it’s something quite hard to do, it uses low-level APIs of GTK and it uses more GDK. But, on the good side, it has had I think an influence on the development of GTK 4, to see some use-cases, to make it much easier (with some hope) to implement animations etc. A whole set of things that were hard to do in GTK 3 are now easy to do in GTK 4.

I’ve read some time ago also this blog post: Provided "as is", without warranty of any kind
which I found interesting, and is related to the philosophy that I follow now.

10

I’m sorry I’m not a developer on GSV so maybe I missed something but also I don’t really understand this, all I can see explained there is some patches to fix failing tests. This seems like not enough reason to fork a project, I hope these changes can get merged eventually and there will be no need for a fork.

11

Btw Christian fixed the offending test-case fyi

12

Why did I create tepl-gsv? Well, because I can. Exactly like Linux Mint can fork some GNOME components (or MATE for another example). I’ve also given other examples above with libgd (a project can choose to take an older copy), or Clutter/Mutter.

You cannot force somebody to either contribute to the “official” GtkSourceView project, or not contributing to the gnome-latex / gedit text stack at all. It’s not as simple.

Yet another example is Xamarin Studio. In the past they used GtkSourceView, and then they developed their own text widget.

All these projects have their own reasons to exist.

I’m talking here in more general terms.

13

Yes that’s true you can do whatever you want but that isn’t actually a justification for forking. Think about this from an outsider’s perspective, there needs to be some technical reason for doing so, some thing that sets the fork apart that would not be possible with the upstream project. I don’t think anyone is going to choose to use a fork just “because it exists”, like you say it has to have its own reason.

I hope that reason is for full technical reasons and not because of personal disputes around the maintenance of some unit tests, I have seen way too many projects flounder, fork and become fragmented because of petty and unprofessional issues that could have been avoided. That behavior just makes the project and open source look bad in general.

14

Another update: I will give it some thoughts.

In any case, if something depends on Tepl-gsv, it’s also possible to switch to GtkSourceView 4. The reverse is not necessarily true.

15

I think it is very reasonable to use a personal fork as a git submodule for some projects, if upstream is too slow and you want to test certain patches before they get merged, or something like that. Though this only makes sense in the context of something like a nightly Flatpak build.

16

The situation has been resolved, sorry for the noise. I’m again a co-maintainer of GtkSourceView after a discussion with Christian.

4 Likes
17

In my experience non-technical issues are the most difficult ones. I’d like to show my respect for all parties involved solving this issue.

18

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.