Progress of Asset / Plugin manager

classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|

Progress of Asset / Plugin manager

Developers mailing list
I think Jehan did some work on this in the past. Is there some progress on
this? Or maybe some Windows binary to test it out? ;-)
_______________________________________________
gimp-developer-list mailing list
List address:    [hidden email]
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list
Reply | Threaded
Open this post in threaded view
|

Re: Progress of Asset / Plugin manager

Developers mailing list
Hi,

If in the past means 2/3 months ago, then yes. That's work-in-progress
which I am resuming these days and I hope we should be able to have
something in a few months.

Jehan


On Fri, Dec 14, 2018 at 6:37 PM Michal Vašut via gimp-developer-list <
[hidden email]> wrote:

> I think Jehan did some work on this in the past. Is there some progress on
> this? Or maybe some Windows binary to test it out? ;-)
> _______________________________________________
> gimp-developer-list mailing list
> List address:    [hidden email]
> List membership:
> https://mail.gnome.org/mailman/listinfo/gimp-developer-list
> List archives:   https://mail.gnome.org/archives/gimp-developer-list
>


--
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:    [hidden email]
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list
Reply | Threaded
Open this post in threaded view
|

Re: Progress of Asset / Plugin manager

Developers mailing list
Hi Jehan, thanks for answer. Do you have the code in some public repository
to take a peek?

On Fri, Dec 14, 2018, 11:49 PM Jehan Pagès <[hidden email]
wrote:

> Hi,
>
> If in the past means 2/3 months ago, then yes. That's work-in-progress
> which I am resuming these days and I hope we should be able to have
> something in a few months.
>
> Jehan
>
>
> On Fri, Dec 14, 2018 at 6:37 PM Michal Vašut via gimp-developer-list <
> [hidden email]> wrote:
>
>> I think Jehan did some work on this in the past. Is there some progress on
>> this? Or maybe some Windows binary to test it out? ;-)
>> _______________________________________________
>> gimp-developer-list mailing list
>> List address:    [hidden email]
>> List membership:
>> https://mail.gnome.org/mailman/listinfo/gimp-developer-list
>> List archives:   https://mail.gnome.org/archives/gimp-developer-list
>>
>
>
> --
> 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:    [hidden email]
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list
Reply | Threaded
Open this post in threaded view
|

Re: Progress of Asset / Plugin manager

Developers mailing list
On Sat, Dec 15, 2018 at 11:03 AM Michal Vašut <[hidden email]>
wrote:

> Hi Jehan, thanks for answer. Do you have the code in some public
> repository to take a peek?
>

Well yeah, code is in master (for some times now). There is no
search/installation part yet, but the core code: basically what is an
extension (the metadata format to describe the contents (both with
Human-text description and for automatic consumption), the loading of
extensions, enabling/disabling them, etc.
Please read:
https://girinstud.io/news/2018/07/crowdfunding-for-extension-management-in-gimp-and-other-improvements/
And you can refer to commits done after this too.

Note that it won't work on Windows yet (as I saw that's the OS you are
interested in), because the library used for metadata parsing is not ported
to Windows yet (on my TODO list).

Jehan


> On Fri, Dec 14, 2018, 11:49 PM Jehan Pagès <[hidden email]
> wrote:
>
>> Hi,
>>
>> If in the past means 2/3 months ago, then yes. That's work-in-progress
>> which I am resuming these days and I hope we should be able to have
>> something in a few months.
>>
>> Jehan
>>
>>
>> On Fri, Dec 14, 2018 at 6:37 PM Michal Vašut via gimp-developer-list <
>> [hidden email]> wrote:
>>
>>> I think Jehan did some work on this in the past. Is there some progress
>>> on
>>> this? Or maybe some Windows binary to test it out? ;-)
>>> _______________________________________________
>>> gimp-developer-list mailing list
>>> List address:    [hidden email]
>>> List membership:
>>> https://mail.gnome.org/mailman/listinfo/gimp-developer-list
>>> List archives:   https://mail.gnome.org/archives/gimp-developer-list
>>>
>>
>>
>> --
>> 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:    [hidden email]
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list
Reply | Threaded
Open this post in threaded view
|

Re: Progress of Asset / Plugin manager

Developers mailing list
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 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).

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

---

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
* 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.

>
_______________________________________________
gimp-developer-list mailing list
List address:    [hidden email]
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list
Reply | Threaded
Open this post in threaded view
|

Re: Progress of Asset / Plugin manager

Developers mailing list
Hi!

On Tue, Dec 18, 2018 at 9:05 PM Michal Vašut <[hidden email]> 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
_______________________________________________
gimp-developer-list mailing list
List address:    [hidden email]
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list
Reply | Threaded
Open this post in threaded view
|

Re: Progress of Asset / Plugin manager

Developers mailing list
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)

On Tue, Dec 18, 2018, 22:00 Jehan Pagès <[hidden email] wrote:

> Hi!
>
> On Tue, Dec 18, 2018 at 9:05 PM Michal Vašut <[hidden email]>
> 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
>
_______________________________________________
gimp-developer-list mailing list
List address:    [hidden email]
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list
Reply | Threaded
Open this post in threaded view
|

Re: Progress of Asset / Plugin manager

Developers mailing list
Hi!

On Wed, Dec 19, 2018 at 1:16 AM Michal Vašut <[hidden email]> 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 <[hidden email] wrote:

>
>> Hi!
>>
>> On Tue, Dec 18, 2018 at 9:05 PM Michal Vašut <[hidden email]>
>> 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:    [hidden email]
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list
Reply | Threaded
Open this post in threaded view
|

Re: Progress of Asset / Plugin manager

Developers mailing list
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 <[hidden email] wrote:

> Hi!
>
> On Wed, Dec 19, 2018 at 1:16 AM Michal Vašut <[hidden email]>
> 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 <[hidden email] wrote:
>>
>>> Hi!
>>>
>>> On Tue, Dec 18, 2018 at 9:05 PM Michal Vašut <[hidden email]>
>>> 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:    [hidden email]
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list
Reply | Threaded
Open this post in threaded view
|

Re: Progress of Asset / Plugin manager

Developers mailing list
Happy 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?

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?

Thanks for answer.

Michal

On Wed, Dec 19, 2018, 15:40 Michal Vašut <[hidden email] 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 <[hidden email] wrote:
>
>> Hi!
>>
>> On Wed, Dec 19, 2018 at 1:16 AM Michal Vašut <[hidden email]>
>> 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 <[hidden email]
>>> wrote:
>>>
>>>> Hi!
>>>>
>>>> On Tue, Dec 18, 2018 at 9:05 PM Michal Vašut <[hidden email]>
>>>> 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:    [hidden email]
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list
Reply | Threaded
Open this post in threaded view
|

Re: Progress of Asset / Plugin manager

Developers mailing list
Hi!

On Wed, Jan 2, 2019 at 1:57 AM Michal Vašut <[hidden email]> 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 <[hidden email] 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 <[hidden email]
>> wrote:
>>
>>> Hi!
>>>
>>> On Wed, Dec 19, 2018 at 1:16 AM Michal Vašut <[hidden email]>
>>> 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 <[hidden email]
>>>> wrote:
>>>>
>>>>> Hi!
>>>>>
>>>>> On Tue, Dec 18, 2018 at 9:05 PM Michal Vašut <[hidden email]>
>>>>> 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:    [hidden email]
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list