[Geany-devel] geany-plugins depends on GIO
elextr at xxxxx
Thu Nov 18 00:03:37 UTC 2010
2010/11/18 Enrico Tröger <enrico.troeger at uvena.de>:
> On Thu, 18 Nov 2010 09:55:35 +1100, Lex wrote:
>>2010/11/18 Enrico Tröger <enrico.troeger at uvena.de>:
>>> On Wed, 17 Nov 2010 19:52:40 +1100, Lex wrote:
>>> I don't want to go too deep into this discussion, just my cents:
>>> To keep it shorter, I'm 100% agree with Colomban's statements.
>>>>As Geany is getting more and more functionality in plugins there
>>>>needs to be more thought in general about the need to lock Geany
>>>>versions and plugin versions.
>>> Yes. But not at all costs.
>>>>If they are locked together then users can't upgrade Geany until
>>>>their plugins support the new version and can't upgrade plugins
>>>>without upgrading Geany.
>>>>As I said in another post, as Geany is used for more than C
>>>>development it is becoming less acceptable to assume that all users
>>>>can re-compile Geany or plugins so any system needs to work at
>>>>runtime as well as at compile time.
>>> As already said, most users probably use distribution packages and/or
>>> Windows binaries. I think we can ignore (don't get me wrong here :D)
>>> Windows users as there updating Geany is really simply: download
>>> installers, execute them, done.
>>Assuming that Geany and all plugins have been updated, that means that
>>plugin devs have to update the plugins every time Geany updates and at
>>the same time. Effectively Geany and geany-plugins and any plugins
>>not in geany-plugins have to be the same package since they have to
>>remain in lockstep.
> The last releases indeed broke ABI compatiblity each time (IIRC). But
> it's not meant to be the normal case. At some point the plugin API
> should be stable enough to not break ABI every now and then.
You are more optimistic than me :-)
> we reach this point, I don't see any required lockstep here.
>>> The distribution packages users also can easily upgrade provided that
>>> the package maintainers do their job, out of our responsibility.
>>But they can't package anything unless we provide them with updated
>>everything, so giving Geany and plugin devs more work. Or you get the
> We are talking about releases, right?
> Some time ago, we said that at least for now we try to keep Geany and
> Geany-Plugins releases together as long as it's possible. That's not
> strictly a technical requirement, more or less just for users' and
> developers' convenience.
> Again, AFAIK there is no technical requirement.
>>problems that have currently happened with Debian where some plugins
>>were not updated in time to make the release so they didn't get in the
>>package :-( Thats not Debians fault.
> Side note, the geany-plugins 0.19 package entered Debian Squeeze last
> weekend because of the heavy efforts of its Debian maintainer. Doesn't
> relate to the discussion but is worth mentioning anyway :).
Yes it is.
> Thanks Evgeni!
And partly I'm trying to reduce the amount of work required.
>>> And then, there are those users who compile from source. I think it
>>> doesn't matter for which languages they use Geany, either the compile
>>> Geany from source or they do not. If they do, they can do it again if
>>> anything is incompatible, especially for SVN version users.
>>Agree, I'm not worried about people like you and me who can compile
>>things, we don't count :-)
> Bah, always hearing the same: you don't count!
An editor is an end-user program (even if the end users are
developers) so only the users matter :-) (and I did say WE :-)
>>> Don't get me wrong, I'm not against making compiling Geany
>>> +Plugins even more easy for users. But at some point I think code
>>> maintainability (is this a real word? :D) is also important.
>>Maintainability is indeed a word and an important one, and by
>>decoupling plugins and Geany you reduce maintenance since things don't
> I don't see any strict coupling you are talking about. Except the above
> mentioned release policy but this isn't that strict.
But it is effectively forced because any change to the ABI prevents
plugins from working, so they have to be updated. And an ABI change
might only be a bugfix. Requiring the whole ABI stability is a pretty
>>>>So there needs to be thought about how to allow any version of Geany
>>>>and any version of a plugin to continue to work as long as the
>>>>functions that they *use* have not been changed. This means that a
>>>>single API/ABI number for the whole interface is not enough, it needs
>>>>to be per function. Then smart plugin developers can make their
>>>>plugins adapt themselves at runtime to the features available from
>>> This leads to tons of #ifdefs or even worse,
>>Only if a plugin dev decides to use the facility, otherwise the plugin
>>just says, "oh, wrong version of the function, sorry I can't run." If
> This already happens, partly on compile-time, partly on runtime at
> loading the plugin. Even though Geany says: "oh, plugin can't be
> loaded, sorry'.
Yes, but at the level of the whole interface, I'm not suggesting any
wildly new technology, just reduce the level of granularity. I only
suggested an implementation to show that it exists, could be
implemented lots of ways.
>> if you really want to have
>>> per-function checks at runtime, if conditions in the code.
>>> I think this makes maintenance of such code much harder and so it
>>> easier tends to break which makes users even more sad.
>>There are lots of requests by plugin devs for access to more of Geany,
>>that changes the API/ABI version and that should make all other
>>plugins fail until they are updated (but doesn't always, which is
> This already happens, at least for API/ABI changes.
> For API additons, it doesn't matter.
> Get my GPG key from http://www.uvena.de/pub.asc
> Geany-devel mailing list
> Geany-devel at uvena.de
More information about the Devel