Ok, no problem... Yeah, the best way is to do without asking, but that is problem when you don't have skill :-D <=> that was also reason why I was asking in the first place - Gimp (its C code) is quiet hardcore and therefore there is so few devs capable (and willing) to contribute. Ok, thanks for making it little bit more clearer and have a nice Xmas holidays. Michal On Wed, Dec 19, 2018, 13:12 Jehan Pagès <jehan.marmottard@xxxxxxxxx wrote: > Hi! > > On Wed, Dec 19, 2018 at 1:16 AM Michal Vašut <michal.vasut@xxxxxxxxx> > wrote: > >> Uff, I have feeling (from your text) like I've been pierced by thousands >> of swords. I've meant no offense nor asked from you to do anything. I've >> only asked the reason why and from your response I've found the reason is >> historical. That's all I've wanted to hear and I fully understand that >> transition to some modern technology is pretty resource expensive or >> impossible (in my work me and team, we are maintaining and improving 20+ >> years old legacy monster code written in Delphi, so be ensured that I quiet >> know what you are talking about) >> > > Yes sorry. My answer was definitely a bit annoyed, I should not have > written it this way. > It's just that we get this question once every few months (maybe more, I > don't follow all discussions/ML much) and regular requests to change to > this or that language (whatever is the current fashion, javascript, python, > rust…). It's just a bit annoying. Also the time I wrote this answer (10PM) > probably did not help. > > But in any case, I should not have written away any frustration to you. > So, sorry again for this. > As you say, yeah the shorter answer is "it's historical". > Let's keep it at it and pretend I have not written the previous answer. ;-) > Thanks! > > Jehan > > P.S.: this said, I really meant it when I say I am all for genius > contributions proving us wrong. For this or other topics, the best option > is often to just propose a patch. Of course it's a risk and is high work > (like really really; I would expect this to take many many many months full > time to port every single bit), but that's also what I do when I want to > contribute to some other software. I don't wait for approval, I do and hope > for the best. :-) > > On Tue, Dec 18, 2018, 22:00 Jehan Pagès <jehan.marmottard@xxxxxxxxx wrote: >> >>> Hi! >>> >>> On Tue, Dec 18, 2018 at 9:05 PM Michal Vašut <michal.vasut@xxxxxxxxx> >>> 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 >>> >> > > -- > ZeMarmot open animation film > http://film.zemarmot.net > Liberapay: https://liberapay.com/ZeMarmot/ > Patreon: https://patreon.com/zemarmot > Tipeee: https://www.tipeee.com/zemarmot > _______________________________________________ gimp-developer-list mailing list List address: gimp-developer-list@xxxxxxxxx List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://mail.gnome.org/archives/gimp-developer-list
