Hi! On Wed, Jan 2, 2019 at 1:57 AM Michal Vašut <michal.vasut@xxxxxxxxx> wrote: > Happy new year, > > Happy and fun new year! I have 2 questions about plugin manager and since there is already thread, > I will use it. > > 1. Will the manager support binary extensions? ... Well scripts will run > anywhere (I think), but binary (compiled) extensions are platform specific > and there are some devs, that only creates extensions in their platform and > don't care about others. Wouldn't that (platform support) be somehow marked > in metadata? > Yes, but in order to distribute them, we will have to set up build servers (for various platforms) because our upstream repository server won't just distribute third-party built binaries without any security nor review. Though we will be able to add some exceptions for some plug-ins with safe sources, such as G'Mic, created by a well known public research facility. > 2. Will the manager support dealing with dependencies (like if the > extension requires some library I will download it or if no one uses this > library I will remove it) or every extension will have to contain every > library it needs? > It will support dependency to GIMP versions (for instance if it requires an API released in a given GIMP version) and to other extensions (an extension can depend on another extension). I have not planned any other kind of dependency so far. Jehan > Thanks for answer. > > Michal > > On Wed, Dec 19, 2018, 15:40 Michal Vašut <michal.vasut@xxxxxxxxx wrote: > >> 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 >>> >> -- 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
