Is there a wish/bounty list of tasks for GLib?

Platform
1

I’m a very passionate open source programmer with plenty of time (I’ve did e.g.: 300 commits to Midnight Commander fork NeoMC but changed the repo to a private one because I’ll be selling it) and I’m quite fascinated by GLib structures, so I thought to invest some significant time into uplifting GLib.

I’m thinking about adding a Heap and/or a Fibonacci data structures (with the immediate use case of priority queue). Would I get my hands wet or is the chance of accepting such extension too low?

Or maybe there are some planned/wished features for GLib and I could take some from there and implement it instead?

2

We only add new API to GLib if at least three GLib-based projects (libraries or applications) are already using something very similar, and are willing to switch to the new API. This typically happens via copy-paste code, and iteration over the API until all the possible issues are well understood.

GLib is very close to the bottom of the stack, and it has strong API/ABI compatibility rules. Adding new API, and new data structures, is extremely expensive in terms of maintenance effort.

3

OK, but I’m hoping for a list for planned extensions (ie. ones that actually are used by the three projects). As I said, I have a plenty of time and could provide a very tested code so the maintenance cost would be very low. Besides, wouldn’t be a priority queue super cool feature? I know the answer is no, but I just have to ask.

4

It’s not exactly what you asked for, but some GNOME components use the Help Wanted label to identify issues where help from a passionate open source programmer would be very welcome.

1 Like
5

tl;dr: No feature is super cool in GLib if it’s not widely useful. :slight_smile: In my experience so far, the thing about fancy data structures is that typically they’re needed in specific situations where performance or certain behaviour is needed, and in those situations a generic implementation of the data structure often doesn’t do exactly what you need. So you end up implementing your own version of the data structure anyway. That’s why GLib doesn’t have many fancy data structures, but lots of the boring and simple ones (for which a generic version is often widely applicable).

Mostly, if someone has gone to the trouble of working out that three projects share an implementation of something which should be upstreamed to GLib, the upstreaming has already been done, because at that point there’s a good incentive to go ahead and finish it.

The to-do list for GLib is just its issue list, which you’re welcome to take a look at and pick some tasks off if you want. Generally, though, the most useful contributions come when people are scratching their own itch and fixing or implementing something which they need for their project — then they know exactly what the use cases and correct API are. It’s harder to get that right when picking up an issue which is 5 years old, wasn’t described well in the first place, and the original reporter has disappeared.

2 Likes
6

tl;dr: No feature is super cool in GLib if it’s not widely useful. :slight_smile: In my experience so far, the thing about fancy data structures is that typically they’re needed in specific situations where performance or certain behaviour is needed, and in those situations a generic implementation of the data structure often doesn’t do exactly what you need. So you end up implementing your own version of the data structure anyway.

I think that the genericness teached by GLib → to pass around gpointers as the stored data (giving up static typing of C) → would be sufficient so that what you’ve described wouldn’t have to happen.

That’s why GLib doesn’t have many fancy data structures, but lots of the boring and simple ones (for which a generic version is often widely applicable).

I think that there are some fancy data structures in GLib – eg.: GSequence/…Iter. IT’s backend data structure is sophisticated and the property of “always valid iterators, even after moving the element, event to another GSequence” is quite remarkable. I have a hook into such subject – to provide a sophisticated-backend data structure yet simple to use and with uncommon, treasure properties – and I would be glad if I could add another such thing to GLib. This is my pet subject currently. I hope that I’ll succeed with doing this.

Mostly, if someone has gone to the trouble of working out that three projects share an implementation of something which should be upstreamed to GLib, the upstreaming has already been done, because at that point there’s a good incentive to go ahead and finish it.

I don’t fully understand what you’ve wrote here. What do you mean by “the upstreaming has alredy been done”?

Generally, though, the most useful contributions come when people are scratching their own itch and fixing or implementing something which they need for their project — then they know exactly what the use cases and correct API are.

I hope that I’ll be able to come up with an use case in my MC fork (which is based on GLib like the original proj) ↔ ie. to come up with a feature for my own project, being inspired by such issue (I’m adding tons of features to the fork, quite often coming up with them such way).

I’ll take a look at the issues.

7

It’s not exactly what you asked for, but some GNOME components use the Help Wanted label to identify issues where help from a passionate open source programmer would be very welcome

It seems to me that there aren’t GLib issues with such label there?

8

It seems to me that there aren’t GLib issues with such label there?

Indeed, I don’t see any either. Like I said, it’s not exactly what you asked for :slight_smile:

9

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