What to do with the gobjectification branch
mark at kingant.net
Sat Jan 19 02:11:14 EST 2013
- We should not try merging into or out of the current gobjectification branch
- We shouldn't worry about gobjectification for 3.0.0
- If there is still interest in gobjectification after 3.0.0 is
released, then we should:
- Change one struct at a time (preferably directly in main. Or, if
it's done in a separate branch, it should be done in a short amount of
time (a few days) and merged into main as soon as possible.)
- Get things working and merged and happy. Make sure people like
the way its done. Make sure everyone is on board with the switch.
- Then move onto the next struct, and continue doing them one at a time.
I think using GObjects makes sense for a lot of our structs. I think
it's a good idea. I think our code would probably benefit from using
these conventions. And I would definitely like to get rid of the
signals system we built and use glib signals. But I feel like the
change will take a lot of developer hours, and we don't seem to have a
lot of developer hours.
I'd rather we focus on finishing 3.0.0 and get that out the door, wait
at least a few months, THEN maybe start working on the next.major
I worry that having this hanging over our heads causes us to hesitate.
"Should I avoid making large changes because it's going to be hard to
merge into the gobjectification branch?" Etc. And that's why I think
we should not try merging into or out of the current gobjectification
branch. And when the time comes to switch to GObjects I think it
definitely makes sense to use the code in that branch as a starting
On Thu, Jan 17, 2013 at 3:29 PM, Jorge Villaseñor <salinasv at gmail.com> wrote:
> What do you think we should do about the issue with glib-mkenums?
> a) ship our own patched version of glib-mkenums and compile using it until
> glib fixes the issue?
> b) add a hardcoded enums.h and enums.c?
I'm not familiar with this problem. If everyone decides to postpone
gobjectification for now then we can wait to decide this later.
Otherwise, I don't know, either option sounds acceptable to me. (b)
seems maybe a little better.
More information about the Devel