[Github-comments] [geany/geany] Gi signals (#1038)

Colomban Wendling notifications at xxxxx
Mon Jun 20 21:30:55 UTC 2016


> @@ -3813,3 +3813,14 @@ void document_grab_focus(GeanyDocument *doc)
>  
>  	gtk_widget_grab_focus(GTK_WIDGET(doc->editor->sci));
>  }
> +
> +static void        *copy_(void *src) { return src; }
> +static void         free_(void *doc) { }
> +
> +/** Gets the GType of GeanyDocument
> + *
> + * @return the GeanyDocument type */

If you just want your peasy to use public API, make it so.  But you need stuff exposed that is only useful for GIR (and even, just because GIR tools are kind of broken).  So you add it, makes sense.

And no, I'm not saying the GIRonly part should be unstable and we can break it everytime we get bored.  But you yourself admitted we probably want to change these GTypes later on, so as there is zero benefit for anything but GIR, why shoot ourselves in the foot and give it more exposure than it requires?  If we change from what the type is derived, it'll basically be both and ABI *and* API break, because yes, it being boxed matters at least for signal marshallers and other GValue packers, so we can't simply pretend nothing changed.  Well, we can, and it'd be fine after a rebuild in 99% of the probable use cases, but it still wouldn't be technically correct.  So yes, I propose to lower the annoyance for everyone by making it only affect GIR, in the hope that less code will depend on it, and also that GIR being automated it'd adapt more easily.  We'll still have to break API and ABI if we change it, but hopefully it'll only actually require a rebuild and no actual code changes.
Exposing it *to people that don't benefit from it* only makes it more likely they will use it thinking it's useful (i.e. as to put one of those in a `GtkTreeModel`?) and suffer later.  And as the type is somewhat a lie anyway (it doesn't follow normal GBoxed semantic, so it's no use to properly copy/free it), it at best is useless, and at worse make people think they can hold a copy/ref of their own.

And well.  Let's be honest, your requirements for GIR change very often as you progress towards an usable thing.  I get it, but it's also true that it can make us wonder whether this won't change in a few months because another issue arose and this one will be outdated and irrelevant.  So yeah, compartimenting also makes sense.

And now I think about it yes, until the GIR gets actually used by something that does work (i.e. Peasy), I'm fine considering experimental and unstable.  It actually does change very often with your patches, which is good here, but doesn't provide so much stability (although recently I believe it only got extended).
An example going against your rant about it staying "stable" was the change you wanted to introduce renaming `document_new()`: it would have *changed* GIR in an *incompatible* manner, yet you didn't make a big deal out of it.

So.  Yes please, unless you convince me there's a valid use case for non-GIR to have those, please mark them GIR only.

---
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany/pull/1038/files/eb3a1a6edf796e71bcd688a1f0e689416856ff25#r67770431
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.geany.org/pipermail/github-comments/attachments/20160620/8de35e99/attachment.html>


More information about the Github-comments mailing list