Re: [Gimp-developer] Progress of Asset / Plugin manager

[Jehan Pagès <jehan marmottard gmail com>]

Hi!

On Tue, Dec 18, 2018 at 9:05 PM Michal Vašut <michal vasut gmail com> wrote:

> Cool, thanks for info. I've checked the page on your blog and have some
> notes to metadata that would be included:
>
> <requires>
>   <id version="2.10" compare="ge">org.gimp.GIMP</id>
>  </requires>
>
> I assume that "ge" value of "compare" attribute means "greater or equal".
> That's the possible way to do it. Here is another way how other systems
> deals with the same problem:
> https://madewithlove.be/tilde-and-caret-constraints/
> And here some related tester: https://semver.npmjs.com

I am not going to change the appdata format. If you absolutely wish to go
this way, you can contribute to the format specification (they are hosted
at freedesktop), though to be fair, I doubt they are going to change it (it
has been used for years now, and is widely spread on Linux distributions:
basically all software management is based on this nowadays), nor do I see
much need (as you say yourself even!).

I don't say one way is better than other, it's just to prevent you
> reinventing the wheel (in case you are not aware of this way).

Well the whole point is to not reinvent any wheel, which is why I am not
going to change anything here.


> 2nd thing, I'm missing Tags section in metadata, it's not necessary, but
> nice to have - great sorting / grouping ability.

That's what the `<keywords>` tag is for, I believe.

---
> BTW I've also checked the code in repo (for the 1st time) and realized
> that it's written in C. Just out of curiosity, why is that? Historical
> reasons? Performance reasons? IMHO it brings huge complexity

For the same reason I am not going to change the appdata format: when you
contribute to a software, you don't try to change all its basics. And GIMP
is indeed written in C. This has been so for 23 years now. I don't see why
it is complex by the way. I have programmed in a lot of languages (many
script languages as well, I even maintain some software mostly made in
Python, etc.) and I find C just fine.


> * in code itself - only emulation of OOP through GObject creates lot of
> code
> * for developers - the graphical math, theorises algorithms are difficult
> on its own, now here is C code that is in this age quiet hardcore to use
> with its non-OOP / structured paradigm ( most of devs code in OOP languages
> these days). Well I can definitely read and understand what's going on in
> the Gimp code, but it would take quiet long time to write something useful.
>
> >
I am not interested in discussing a port of GIMP to some language X, if not
for the first reason that the work required to do such port would just
block us for years (and you would not see GIMP 3 for like 10 years?!
Neither the extension manager as well of course, since we'd have no time to
implement it anymore, nor any of the cool new features we are bringing in
nowadays).

Now I am happy to be wrong, and if someone were to port the GUI part of
GIMP into some well maintained and interesting/powerful/simple language,
making any graphics change easier, without any regression or feature loss,
if this person contributes us a working patch tomorrow, I test it, it just
works and keeps all the "promises", then I'd be the first to consider the
patch for inclusion (though I would not be the only one to decide). But
other than this, please don't ask us to do some work which we find not
useful. I have a lot of things where I want to see GIMP improve (see my
signature; we are making an animation film, as a professional studio, and
my main worry is not the language of GIMP but what it can do and how, and
if it is stable/fast) and spending years to change our base language is
certainly not one of these.
Sorry. :-)

Jehan

-- 
ZeMarmot open animation film
http://film.zemarmot.net
Liberapay: https://liberapay.com/ZeMarmot/
Patreon: https://patreon.com/zemarmot
Tipeee: https://www.tipeee.com/zemarmot