Re: [Gimp-developer] [Gimp-user] Discontinuation of mailing lists and moving to Discourse

[Jehan Pagès via gimp-developer-list]

Hi!

On Tue, Oct 18, 2022 at 3:25 AM Ken Moffat  wrote:

> On Mon, Oct 17, 2022 at 10:00:24PM +0200, Jehan Pagès via
> gimp-developer-list wrote:
> > Hi!
> >
> > On Mon, Oct 17, 2022 at 9:48 PM Rick Strong  wrote:
> >
> > > So if I want to ask a question about using GIMP, or respond to a
> question,
> > > how do I do it?
> > >
> >
> > Well basically same as you always did, except that now it will be on one
> of
> > the Discourse instances, such as the pixls.us one or the GNOME one.
> Instead
> > of being subscribed to a mailing list, it's on Discourse (which is
> > basically a modern-time forum, as I see it), on which you'd have a
> > login/account. :-)
> >
> > Jehan
> >
>
> As a linux user, this feels like a retrograde step (there are ways
> of running mailing lists without python2, such as sympa, although
> they tend to work sub-optimally).  But it is outside my, and your,
> control so thanks for the forewarning.
>
> I guess that if I have any questions in the future I'll use
> https://discuss.pixls.us in the hope that I might get indications of
> how to do something (I'm logged in there on one of my machines, I
> get mails every week or so with topics since I last visited - most
> of which seem to be about non-interesting *to me* software).
>
> This might be my last post here, so I'll say thanks to the people
> who have helped me on -user over the years, and to the devs who have
> made 2.10 what it is - yes, I'd like to use 2.99 but I also want
> script-fu and g'mic plugins so I guess I'll be staying on 2.10 for a
> while.
>

Script-fu is still available in 2.99 and nowadays we get a very active
contributor for it. So it's even improving. :-)

As for G'MIC, it is available for GIMP 2.99 too, though maybe not on all
platforms, and it probably "breaks" at nearly every dev release (as we
progressively change the API here and there). So there is indeed often a
short span of time where it's non-available. Of course, not advising you to
use 2.99 either as it's still marked as "unstable" releases (so to be used
carefully), but just saying that these 2 points are not hugely broken and
there is no doubt to me that they will will be available with GIMP 3.0 (and
no API break for a long time then!). :-)

Jehan


> ĸen
> --
> Greater love hath no woman for the premiership than to lay down the
> life of her bosom friend in an attempt to save her own skin.
>  -- Andrew Rawnsley
>


-- 
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@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list

Re: [Gimp-developer] [Gimp-user] Discontinuation of mailing lists and moving to Discourse

[Jehan Pagès via gimp-developer-list]

Hi!

On Tue, Oct 18, 2022 at 4:43 AM Rick Strong  wrote:

> Gee, Jehan I'm really sorry I was so involved in getting photographs ready
> for print tomorrow morning that I overlooked the possibility that YOU might
> also be stressed out. I’m going blind in one eye, had a heart attack in
> August and I’ve been going for over 12 hours now, but that’s no excuse. You
> have my sympathy. [image: Crying face]
>

Hey no problem don't worry. Neither your email nor the one from the other
person were rude or anything. I was just annoyed by the fact they were sent
privately and it's true I'm quite tired these days.
Anyway thanks for understanding and sorry to read about your health issues.
I hope these will get better soon! 

Jehan


> Rick
>
>
> -Original Message-
> From: Jehan Pagès via gimp-user-list
> Sent: Monday, October 17, 2022 8:29 PM
> To: gimp-web-list ; GIMP User List ; gimp-gui-l...@gnome.org ; GIMP Docs
> ; gimp-developer ; gegl-developer-list
> Subject: Re: [Gimp-user] Discontinuation of mailing lists and moving to
> Discourse
>
> Hi everyone!
>
> I received 2 off-list emails. Please do not send me off-list emails. I am
> exhausted  and cannot do private support in addition to public support,
> code development, news writing, website making and everything else in GIMP.
> 
>
> This is even more true as I don't really see anything private/sensitive in
> the 2 emails I received. Really no need to make them private, except for
> making me work double (whereas as public emails, someone else could have
> answered). I generally advise contributors to preserve themselves from
> overworking by not answering to private messages.
>
> Anyway, regarding unhappiness about the new platform, I will mainly answer
> that there is not much we can do. We are heavily relying on GNOME
> Infrastructure (which we thank for this) and they have their own reasons
> (one of them is that mailing lists are apparently one of the elements in
> their stack which prevent them from dropping Python 2; we can relate!). Cf.
> the link in my original email.
>
> Now we could always try to fight against the current and persuade GNOME
> infrastructure team, but we made a small opinion tour among the current
> core team and nobody really had particular love or use of our mailing
> lists. Also we realize it's very low volume these days (barely a few
> threads per month, counting all mailing lists together). Myself I barely
> look at mailing lists every once in a while and make a random answer
> sometimes. And there were several mailing lists I was not even subscribed
> to (I did for the sake of this announcement). So that's probably why none
> from the core team is really trying to fight this change.
>
> There is one more thing to take into consideration: more infrastructure
> means more work. I said it above, I am exhausted by this all. I was only
> managing one of the mailing lists so far (the gimp-gui one, the most
> recent) and still had to regularly handle spams. I am personally thankful
> that this work goes to GNOME admins now. Moreover I would not try to find
> alternative mailing list providers either. Now, same as hundreds of
> third-party forums discuss GIMP out there, people are welcome to create
> third-party mailing lists to discuss GIMP if that's really what you are
> into. I won't be such a person; and apparently it looks like nobody else
> from the core team is so far.
>
> One last thing: I am aware that Discourse is not perfect. I also spent some
> time today to try and understand how to efficiently transform it into a
> mailing list equivalent.
>
> For questions about only receiving emails for the "gimp" tag, I think that
> you should not try to use the "Enable mailing list mode" option. Instead
> just go to the "gimp" tag page (https://discourse.gnome.org/tag/gimp),
> click the bell icon on the top-right and set to "Watching" mode. This way,
> you will be notified of absolutely all messages for this tag. Then in your
> "Emails" preferences, set "Email me when I am quoted, replied to, my
> @username is mentioned, or when there is new activity in my watched
> categories, tags or topics" to "always". This should transform every
> notification into emails, in other words you will receive an email for
> every message added in the "gimp" tag. You can even directly reply to a
> notification email from your mail client without going to Discourse.
> At least, so far it worked for me (I tried today, and I only received
> emails for the 2 messages which came in with the "gimp" tag, no other
> emails). So it's probably the right setting.
>
> Anyway please understand that it's really not about comparing the Discourse
> and mailing list technologies. GIMP is not a discussion platform, we only
> provide these channels on the side because it's a cool community tool, but
> we cannot spend all our time managing these. This is why we need to go with
> the flow of what GNOME is proposing (as long as it's not completely wrong;
> e.g. 

Re: [Gimp-developer] [Gimp-user] Discontinuation of mailing lists and moving to Discourse

[Jehan Pagès via gimp-developer-list]

Hi everyone!

I received 2 off-list emails. Please do not send me off-list emails. I am
exhausted  and cannot do private support in addition to public support,
code development, news writing, website making and everything else in GIMP.


This is even more true as I don't really see anything private/sensitive in
the 2 emails I received. Really no need to make them private, except for
making me work double (whereas as public emails, someone else could have
answered). I generally advise contributors to preserve themselves from
overworking by not answering to private messages.

Anyway, regarding unhappiness about the new platform, I will mainly answer
that there is not much we can do. We are heavily relying on GNOME
Infrastructure (which we thank for this) and they have their own reasons
(one of them is that mailing lists are apparently one of the elements in
their stack which prevent them from dropping Python 2; we can relate!). Cf.
the link in my original email.

Now we could always try to fight against the current and persuade GNOME
infrastructure team, but we made a small opinion tour among the current
core team and nobody really had particular love or use of our mailing
lists. Also we realize it's very low volume these days (barely a few
threads per month, counting all mailing lists together). Myself I barely
look at mailing lists every once in a while and make a random answer
sometimes. And there were several mailing lists I was not even subscribed
to (I did for the sake of this announcement). So that's probably why none
from the core team is really trying to fight this change.

There is one more thing to take into consideration: more infrastructure
means more work. I said it above, I am exhausted by this all. I was only
managing one of the mailing lists so far (the gimp-gui one, the most
recent) and still had to regularly handle spams. I am personally thankful
that this work goes to GNOME admins now. Moreover I would not try to find
alternative mailing list providers either. Now, same as hundreds of
third-party forums discuss GIMP out there, people are welcome to create
third-party mailing lists to discuss GIMP if that's really what you are
into. I won't be such a person; and apparently it looks like nobody else
from the core team is so far.

One last thing: I am aware that Discourse is not perfect. I also spent some
time today to try and understand how to efficiently transform it into a
mailing list equivalent.

For questions about only receiving emails for the "gimp" tag, I think that
you should not try to use the "Enable mailing list mode" option. Instead
just go to the "gimp" tag page (https://discourse.gnome.org/tag/gimp),
click the bell icon on the top-right and set to "Watching" mode. This way,
you will be notified of absolutely all messages for this tag. Then in your
"Emails" preferences, set "Email me when I am quoted, replied to, my
@username is mentioned, or when there is new activity in my watched
categories, tags or topics" to "always". This should transform every
notification into emails, in other words you will receive an email for
every message added in the "gimp" tag. You can even directly reply to a
notification email from your mail client without going to Discourse.
At least, so far it worked for me (I tried today, and I only received
emails for the 2 messages which came in with the "gimp" tag, no other
emails). So it's probably the right setting.

Anyway please understand that it's really not about comparing the Discourse
and mailing list technologies. GIMP is not a discussion platform, we only
provide these channels on the side because it's a cool community tool, but
we cannot spend all our time managing these. This is why we need to go with
the flow of what GNOME is proposing (as long as it's not completely wrong;
e.g. if they had proposed to go for some walled garden proprietary network
for the main discussion channels, I would have questioned the choice). I am
not into gamification, infinite scrolls or such things either. Us accepting
this platform is not about us wanting these. It's really about having a
limited core team and nobody highly interested into maintaining complicated
infrastructure for a different system than what GNOME does. That's about it.

Also for the 2 people who sent private emails, forgive me for not answering
directly and privately to you. It's not against you, I just hope you will
understand I am trying to preserve my mental sanity here. Someone was even
apparently "shocked" that I used a gmail account. The reason is actually
exactly the same (avoiding private emails): historically I wanted to avoid
spreading my main email address too much (even though I now realize it was
a vain wish, I was young back then! ) so I created this account as a
trash email, maybe 15 years ago, and that's the address I historically used
to subscribe to mailing lists. I am still receiving uncountable numbers of
emails daily.
And now you'll understand why I am doing a single 

Re: [Gimp-developer] [Gimp-user] Discontinuation of mailing lists and moving to Discourse

[Jehan Pagès via gimp-developer-list]

Hi!

On Mon, Oct 17, 2022 at 9:48 PM Rick Strong  wrote:

> So if I want to ask a question about using GIMP, or respond to a question,
> how do I do it?
>

Well basically same as you always did, except that now it will be on one of
the Discourse instances, such as the pixls.us one or the GNOME one. Instead
of being subscribed to a mailing list, it's on Discourse (which is
basically a modern-time forum, as I see it), on which you'd have a
login/account. :-)

Jehan

Rick
>
> -Original Message-
> From: Jehan Pagès via gimp-user-list
> Sent: Monday, October 17, 2022 12:38 PM
> To: gimp-web-list ; gimp-developer ; GIMP User List ;
> gimp-gui-l...@gnome.org ; gegl-developer-list ; GIMP Docs
> Subject: [Gimp-user] Discontinuation of mailing lists and moving to
> Discourse
>
> Hello everyone!
>
> The GNOME Foundation has been moving all its discussions to a Discourse
> forum, progressively:
>
> https://mail.gnome.org/archives/desktop-devel-list/2022-September/msg00018.html
>
> We were informed today that they are on the last stage of this migration
> and that all the mailing lists will be fully retired by the end of October.
> This implies also all of GIMP and GEGL mailing lists.
>
> Instead, people wishing to discuss about GIMP are expected to use GNOME's
> Discourse instance. In particular 2 tags were created for us:
>
> * "gimp" tag for GIMP-related discussions:
> https://discourse.gnome.org/tag/gimp
> * "gegl" tag for GEGL-related discussions:
> https://discourse.gnome.org/tag/gegl
>
> We don't have as many tags as we used to have mailing lists, just these 2,
> but since all our lists are quite low volume these days, I didn't think it
> was worth asking, at least for now. GNOME admins confirmed that it would
> not be a problem to add new tags in the future if we ever decided we needed
> more (e.g. having a "gimp-dev" tag or whatnot).
>
> By the way, noteworthy information: GIMP has had already an official
> presence on pixls.us Discourse: https://discuss.pixls.us/gimp/
> We discussed among the team if it was worth having presence on both
> pixls.us
> and GNOME discourse and we came to the conclusion that the audience is
> different, therefore it is interesting to stay on both communities. For
> discussion with existing GNOME contributors, translators and various GNOME
> users for instance, they might be already on the GNOME Discourse. On the
> other hand, pixls.us is a much more specialized forum/community on
> Photography in particular, and is also probably more platform-independent
> too.
>
> Last but not least, as I expect that some people might prefer interacting
> by email, I tried to look up what are the possibilities. This thread
> "Interacting with Discourse via email" is of interest:
> https://discourse.gnome.org/t/interacting-with-discourse-via-email/46
>
> It didn't have the ability to create new threads easily, especially tagged
> with the "gimp" keyword. Discourse has a way to create a topic on a
> specific category but we couldn't find for tags, for instance you can send
> an email to community @ discourse.gnome.org (note that it doesn't work for
> every category, e.g. it didn't work for infrastructure; I haven't tested
> others). With Andrea Veri, GNOME Infrastructure admin, we came up with a
> special email hook: any email with "[GIMP]" in the subject will be tagged
> "gimp".
> Nevertheless you need to have level 1 trust level for this to work. We
> aren't sure exactly what it means other than having participated enough
> (whatever "enough" is) to the Discourse first. 路
>
> See:
>
> https://discourse.gnome.org/t/gimp-how-to-send-emails-to-discourse-tagged-for-gimp-forum/11535
>
> So I guess, let's continue discussing there everyone! 珞
>
> Jehan
> GIMP maintainer
>
> --
> 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-user-list mailing list
> List address:gimp-user-l...@gnome.org
> List membership: https://mail.gnome.org/mailman/listinfo/gimp-user-list
> List archives:   https://mail.gnome.org/archives/gimp-user-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:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list

[Gimp-developer] Discontinuation of mailing lists and moving to Discourse

[Jehan Pagès via gimp-developer-list]

Hello everyone!

The GNOME Foundation has been moving all its discussions to a Discourse
forum, progressively:
https://mail.gnome.org/archives/desktop-devel-list/2022-September/msg00018.html

We were informed today that they are on the last stage of this migration
and that all the mailing lists will be fully retired by the end of October.
This implies also all of GIMP and GEGL mailing lists.

Instead, people wishing to discuss about GIMP are expected to use GNOME's
Discourse instance. In particular 2 tags were created for us:

* "gimp" tag for GIMP-related discussions:
https://discourse.gnome.org/tag/gimp
* "gegl" tag for GEGL-related discussions:
https://discourse.gnome.org/tag/gegl

We don't have as many tags as we used to have mailing lists, just these 2,
but since all our lists are quite low volume these days, I didn't think it
was worth asking, at least for now. GNOME admins confirmed that it would
not be a problem to add new tags in the future if we ever decided we needed
more (e.g. having a "gimp-dev" tag or whatnot).

By the way, noteworthy information: GIMP has had already an official
presence on pixls.us Discourse: https://discuss.pixls.us/gimp/
We discussed among the team if it was worth having presence on both pixls.us
and GNOME discourse and we came to the conclusion that the audience is
different, therefore it is interesting to stay on both communities. For
discussion with existing GNOME contributors, translators and various GNOME
users for instance, they might be already on the GNOME Discourse. On the
other hand, pixls.us is a much more specialized forum/community on
Photography in particular, and is also probably more platform-independent
too.

Last but not least, as I expect that some people might prefer interacting
by email, I tried to look up what are the possibilities. This thread
"Interacting with Discourse via email" is of interest:
https://discourse.gnome.org/t/interacting-with-discourse-via-email/46

It didn't have the ability to create new threads easily, especially tagged
with the "gimp" keyword. Discourse has a way to create a topic on a
specific category but we couldn't find for tags, for instance you can send
an email to community @ discourse.gnome.org (note that it doesn't work for
every category, e.g. it didn't work for infrastructure; I haven't tested
others). With Andrea Veri, GNOME Infrastructure admin, we came up with a
special email hook: any email with "[GIMP]" in the subject will be tagged
"gimp".
Nevertheless you need to have level 1 trust level for this to work. We
aren't sure exactly what it means other than having participated enough
(whatever "enough" is) to the Discourse first. 路

See:
https://discourse.gnome.org/t/gimp-how-to-send-emails-to-discourse-tagged-for-gimp-forum/11535

So I guess, let's continue discussing there everyone! 珞

Jehan
GIMP maintainer

-- 
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@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list

Re: [Gimp-developer] Encoder for HEIC/HEIF

[Jehan Pagès via gimp-developer-list]

Hello,

On Wed, Sep 14, 2022 at 9:53 PM Marek Simka <195...@vut.cz> wrote:

> Hello,
>
> as a PhD student I research videos and images for virtual reality.
> May I ask what kind of implementation/library GIMP uses to encode images
> into HEIC format? Is this libheif (with libx265 encoder)?
>

Yes we use libheif. We have no specific prefered encoder for HEIC. So
whatever is made available through the local libheif install, I'd say.

Jehan


> Thank you for your answer
> Marek Simka
> ___
> gimp-developer-list mailing list
> List address:gimp-developer-list@gnome.org
> 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:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list

Re: [Gimp-developer] PF_ENUM, SF_ENUM, dynamically defined enums for plugins

[Jehan Pagès via gimp-developer-list]

Hi all!

On Mon, Aug 15, 2022 at 12:25 AM Ofnuts via gimp-developer-list <
gimp-developer-list@gnome.org> wrote:

> I'm not convinced this needs to be an enum. The basic problem it to
> show  a list of strings, and return the index of the selected one.  The
> contents of the list can be quite dynamic. As far as I can tell, in 2.10
> they aren't cached in pluginrc. In 3.0, the query/init methods of the
> plugin suggest that things can be dynamic and a list of URLs/devices
> could be created during registration (this could also change if the user
> changes the UI language, and only the plugin would know how to retrieve
> the translations...).  How the returned integer is used is left to the
> imagination of the author.
>

I discussed the topic of enum-type arguments in the MR opened by Lloyd:
https://gitlab.gnome.org/GNOME/gimp/-/merge_requests/709

Feel free to read the discussion, though I'll also try to re-explain it
here.

As a first disclaimer, I will discuss this with C code because I am
personally not interested into script-fu-only specifics, neither into any
language-specifics. This includes C itself (i.e. I don't care about
solutions which work only on C either), but C is our base language, which
is why it's our generic language here.
We used to have many bindings in many languages, most of them (but
script-fu) are now dead (development-wise) because they focused on logic
specific to the language (which is great and for sure has a lot of
advantages, don't get me wrong, but also means a lot more continuous
maintenance).

>
> So, IMHO, this is more like a variant of regular integer, instead of
> showing a slider you display  a list of labels.
>

This is actually the current state of things currently in GIMP 2.99/3.0.

When we want a list of options (a.k.a. enum-like type) as argument, we
declare it as an int argument. And we list the values in the docs string:

  GIMP_PROC_ARG_INT (procedure, "preset",
 _("Source _type"),
 _("WebP encoder preset (Default=0, Picture=1,
Photo=2, Drawing=3, "
   "Icon=4, Text=5)"),
 0, 5, WEBP_PRESET_DEFAULT,
 G_PARAM_READWRITE);

On API/plug-in/script programmer side, it's ugly because it means that
people rely on meaningless integers and always have to refer to docs to
re-read existing code. Also it means if we forget to update the docs, the
possible values might be incomplete. Worse, for some procedure, the number
of options is so huge, we currently don't list them in the string docs.
This is the case of "pixel-format" in plug-ins/common/file-raw-data.c which
has 19 possible values. So I didn't even bother writing the docs, though
it's also because I was planning for better system to declare list of
options.

On GUI side though, we don't have such a problem because we have the API to
easily map int values to individual string items:

  /* Create the combobox containing the presets */
  store = gimp_int_store_new ("Default", WEBP_PRESET_DEFAULT,
  "Picture", WEBP_PRESET_PICTURE,
  "Photo",   WEBP_PRESET_PHOTO,
  "Drawing", WEBP_PRESET_DRAWING,
  "Icon",WEBP_PRESET_ICON,
  "Text",WEBP_PRESET_TEXT,
  NULL);
  gimp_procedure_dialog_get_int_combo (GIMP_PROCEDURE_DIALOG (dialog),
   "preset", GIMP_INT_STORE (store));

So my initial idea was to move this "store" list (but it will have to be
another type, not depending on GTK) into the declaration part of plug-ins.
This way, at least the problem of documenting the values and even managing
errors (non-supported values) is no more.
Then we would not have to maintain a huge docs for the arg (but smaller doc
strings for each values) and we can generate better docs for such
arguments. Though we would still have to deal with integer on caller side.
It would be better with semantic values.

An alternative could be to use string arguments (also associated to a
limited given list of allowed values on callee side), this would bring
semantic, using for instance "picture" as arg rather than whatever int
value is WEBP_PRESET_PICTURE.

In any case, the best would be to have real enum types declared and usable
on caller side too, hence using the same type on both side, and that brings
some semantic to the API. It seemed to me that it was not possible to
generate enum types dynamically, but Lloyd seems to think it is thanks to
GTypeModule. So let's see how it goes. :-)

Jehan


> On 08/08/2022 14:42, Lloyd Konneker via gimp-developer-list wrote:
> > This is a continuation of a thread on this list:
> >
> https://mail.gnome.org/archives/gimp-developer-list/2022-July/msg00016.html
> .
> > The thread diverged to a discussion about future PF_OPTION implementation
> > in GIMP 3.
> >
> > Here are my preliminary 

Re: [Gimp-developer] How to distribute translated/translatable python plugins in 2.99

[Jehan Pagès via gimp-developer-list]

Hi,

On Tue, Jul 26, 2022 at 10:50 PM Ofnuts via gimp-developer-list <
gimp-developer-list@gnome.org> wrote:

> Thanks. Eventually made it to work.
>
> > I am planning to make tutorials for all the GIMP 3.0 API for plug-in
> > creation, and more generally extension creation. This will include
> > localization.
> > We are currently also in the process of reviving
> > https://developer.gimp.org/ (which is very outdated right now).
>
> Since I just finished migrating my first V2 plugin to V3 I think I can
> help there, with firsthand experience.  Recently retired, so plenty of
> time. PM me you needs (En or FR). This will  give you more time to
> finish GimpUi.ProcedureDialog which is still missing a replacement for
> PF_OPTION, which is a major impairment for my migration efforts(*).


I just checked old 2.10 plug-ins. I see PF_OPTION is a Python API thingy.
Apparently it was to make combo boxes from properties?

We can already do this in the 3.0 API using int properties. A bunch of
plug-ins already use this. For instance look at the PNG plug-in:
https://gitlab.gnome.org/GNOME/gimp/-/blob/cac7ed93a0debedf1c60c2e71dc9a038b3ffb454/plug-ins/common/file-png.c#L2280-2291

Now I am still planning to improve this, I think I explain this in some
report somewhere but I can't find it right now (or maybe I forgot to write
this down). Basically the idea is to move the int_store part from GUI into
the procedure definition (the query_procedure() method) as a complement of
the int argument:
https://gitlab.gnome.org/GNOME/gimp/-/blob/cac7ed93a0debedf1c60c2e71dc9a038b3ffb454/plug-ins/common/file-png.c#L274-279

Because right now, for people using the API in scripts, we have to list the
whole values in the argument description (i.e.:
https://gitlab.gnome.org/GNOME/gimp/-/blob/cac7ed93a0debedf1c60c2e71dc9a038b3ffb454/plug-ins/file-jpeg/jpeg.c#L234-237
) but this is very annoying, both for translation, keeping it up-to-data,
but also when the values list is very long (for instance, recently I was
updating the file-raw-data plug-in and one of the int arguments is such a
list of options and it's veryyy long.

If we can move this store list into the properties, it could make
everything easier.


> Some
> preference for the Wiki on Gitlab, though,


The wiki on Gitlab was considered but it is a hassle to use because of
access permissions. Apparently you need to have Developer permissions to be
allowed to write on the Gitlab wiki too. It means we can't easily give
access to more people.

unless markdown can be used
> for developer.gimp.org/


Yes, this is the goal. The full data has already been ported to Markdown
(and using the Hugo framework) to facilitate contributions.


>
> > That's actually one of the things I still have to review and make
> > decisions or changes about. Look at my little checkbox at the bottom
> > of this comment:
> > https://gitlab.gnome.org/GNOME/gimp/-/issues/8124#note_1493804
> > The one box still unchecked says "Menu paths" which I believe is what
> > you are asking about.
>
> This is comment bait, and I won't resist...
>

Comment answered there too.

Jehan


>
> (*) usage stats in my Python plugins:
>
>1 PF_GRADIENT
>1 PF_TEXT
>2 PF_LAYER
>2 PF_PALETTE
>3 PF_FONT
>6 PF_COLOR
>   12 PF_INT
>   13 PF_DIRNAME
>   19 PF_TOGGLE
>   30 PF_STRING
>   37 PF_FLOAT
>   38 PF_DRAWABLE
>   48 PF_VECTORS
>   52 PF_SLIDER
>   82 PF_SPINNER
>  109 PF_IMAGE
>  153 PF_OPTION
>
>
>
> On 26/07/2022 16:48, Jehan Pagès wrote:
> > Hi!
> >
> > On Mon, Jul 25, 2022 at 11:38 PM Ofnuts via gimp-developer-list
> >  wrote:
> >
> > What is necessary to distribute a translation-enabled python
> > plugin for
> > 2.99?
> >
> > I assume that the plugin distribution should be self-sufficient
> since
> > it cannot assume that translations will be available in some general
> > repository.
> >
> > What should the plugin directory look like (it seems it needs a
> > "locale"
> > subdirectory)?
> >
> > Indeed.
> >
> > But adding and "fr.po" file there with some msgid/msgstr
> > doesn't seem enough.
> >
> >
> > It must be "compiled" too. `.po` files are source for `.mo` (or
> > `.gmo`) files.
> > Also it must be in subdirectories (standard translation
> > organizations). So if your plug-in is called "my-plug-in", then the
> > .mo file for French would likely be in
> locale/fr/LC_MESSAGES/my-plug-in.mo
> >
> > Are there examples available (outside of Gimp's
> > source code since these use the general repo).
> >
> >
> > Anyway that's a lot of work being done right now. We can't give ETA,
> > but it will happen. :-)
> >
> >
> > And do menu locations need to be translated as well?
> >
> >
> > That's actually one of the things I still have to review and make
> > decisions or changes about. Look at my little checkbox at the bottom
> > of this comment:
> > 

Re: [Gimp-developer] macOS third-party plugins

[Jehan Pagès via gimp-developer-list]

Hi!

On Wed, Jul 20, 2022 at 8:30 PM Jacob Boerema via gimp-developer-list <
gimp-developer-list@gnome.org> wrote:

> On 20 Jul 2022 at 8:51, Piotr Fusik wrote:
>
> > I found no macOS plugin SDK. Is there one?
>
> I am not aware of anything macOS specific in our plug-in API or any macOS
> specific documentation. We would welcome improvements.
>

Indeed there is no difference for plug-in creation depending on the
platform.

Now maybe the fact that the macOS DMG is signed means all the plug-in
binaries must be signed too to be run. I have no idea, but I guess it makes
sense in the security context of signature of binaries.

As Jacob says, if anyone has more information, we welcome contributors for
documenting OS-specific differences too, especially as we are currently in
the process of reviving our developer website where such information would
be definitely welcome. :-)

Jehan


> The number of macOS GIMP developers traditionally has been very low. Not
> sure if our current maintainer Lukas Oberhuber reads this list. You may
> have
> more luck contacting him on our IRC channel.
>
> --
> Jacob Boerema
>
> ___
> gimp-developer-list mailing list
> List address:gimp-developer-list@gnome.org
> 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:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list

Re: [Gimp-developer] How to distribute translated/translatable python plugins in 2.99

[Jehan Pagès via gimp-developer-list]

Hi!

On Mon, Jul 25, 2022 at 11:38 PM Ofnuts via gimp-developer-list <
gimp-developer-list@gnome.org> wrote:

> What is necessary to distribute a translation-enabled python plugin for
> 2.99?
>
> I assume that the plugin distribution should be self-sufficient  since
> it cannot assume that translations will be available in some general
> repository.
>
> What should the plugin directory look like (it seems it needs a "locale"
> subdirectory)?


Indeed.

But adding and "fr.po" file there with some msgid/msgstr
> doesn't seem enough.


It must be "compiled" too. `.po` files are source for `.mo` (or `.gmo`)
files.
Also it must be in subdirectories (standard translation organizations). So
if your plug-in is called "my-plug-in", then the .mo file for French would
likely be in locale/fr/LC_MESSAGES/my-plug-in.mo


> Are there examples available (outside of Gimp's
> source code since these use the general repo).
>

I am planning to make tutorials for all the GIMP 3.0 API for plug-in
creation, and more generally extension creation. This will include
localization.
We are currently also in the process of reviving https://developer.gimp.org/
(which is very outdated right now).

Anyway that's a lot of work being done right now. We can't give ETA, but it
will happen. :-)


> And do menu locations need to be translated as well?
>

That's actually one of the things I still have to review and make decisions
or changes about. Look at my little checkbox at the bottom of this comment:
https://gitlab.gnome.org/GNOME/gimp/-/issues/8124#note_1493804
The one box still unchecked says "Menu paths" which I believe is what you
are asking about.

Again, it's on my TODO, but I can't give an ETA. My hope is that I can make
time to finish this one for the next dev release. We'll see.

Jehan

>
> --
>
> Ofnuts
>
>
>
>
> ___
> gimp-developer-list mailing list
> List address:gimp-developer-list@gnome.org
> 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:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list

Re: [Gimp-developer] Need help for the macOS package?

[Jehan Pagès via gimp-developer-list]

Hi!

On Wed, Oct 6, 2021 at 10:17 PM Ludovic Rousseau via gimp-developer-list <
gimp-developer-list@gnome.org> wrote:

> Hello,
>
> After Jehan asked for help on
>
> https://linuxfr.org/news/sortie-de-gimp-2-10-28-et-nouvelles-autour-du-projet


I sent you a response there too, just a bit ago.  

>
> I plan to (try to) work the macOS package.
>

Sure. We now have someone new very recently who has been working on
compiling the dev code (finally!) for macOS. It's still a work-in-progress
but promising. Of course, the more we are, the better, so it should not
prevent you from helping too. This would be a great milestone, I don't
think I saw 2 active macOS code contributors at a time for the last 9 years
I have been around. 


> I have never compiled GIMP myself.
> I forked and cloned
> https://gitlab.gnome.org/Infrastructure/gimp-macos-build and
> https://gitlab.gnome.org/GNOME/gimp
> My first step will be to rebuild GIMP locally.
>

Sure.


> I already use jhbuild to build/package Grisbi for macOS. So this is
> not a new technology to me.
> But I guess that building GIMP will bring new challenges :-)
>

Yes definitely. Current contributor is trying to figure out a few issues
already, for instance: https://gitlab.gnome.org/GNOME/gimp/-/issues/7319

>
> I may even try to create a Universal Binary with both Intel and ARM
> CPUs support.
>

Definitely M1 support would be awesome too.


> I see the macOS binary is signed by "Developer ID Application: GNOME
> Foundation (T25BQ8HSJF)". I guess someone here has access to the
> private key.
>
Yes sure. But that's detail. Signing is already all set-up. Now what we
need to look at is to build and run (without crashing) GIMP dev code.
That's the next big thing. Signing is useless without this. 

Anyway as said on LinuxFr, discussing on #gimp IRC channel at irc.gimp.org
is probably the best (now soon going to bed and tomorrow might not be too
available during the day, but in the evening or next days, sure; you might
also be able to talk to lukaso, the other macOS contributor, on IRC too if
around).

Jehan


> Regards,
>
> --
>  Dr. Ludovic Rousseau
> ___
> gimp-developer-list mailing list
> List address:gimp-developer-list@gnome.org
> 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:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list

Re: [Gimp-developer] Looking for gexiv2 maintainer

[Jehan Pagès via gimp-developer-list]

Hi Jens!

Didn't see this email until today.

On Sun, Aug 29, 2021 at 2:30 AM Jens Georg  wrote:

> Hello,
>
> I am going to give up gexiv2 maintainership, for multiple reasons.
>

Ouch!


> One of them is that I have too many projects, the other one is I don't
> want to work with Exiv2 upstream anymore.
>
> I will do a final 0.14 release for GNOME 41 and than I'll stop caring.
> Sorry about that, but I have to let that go, for my onw personal
> sanity.
>

It's hard, but I understand. You should never give up sanity (or anything
which makes your life nice to live) for a program.

I hope we'll find a nice new maintainer for GExiv2 and I wish you a good
continuation. Thanks for all the past work! And obviously you'd be welcome
if you want to be back (as far as I can say on GIMP behalf at least).

As for Shlomi Fish, one is indeed a nice and useful person going around in
the community for quite a long time. So it's a good start! 

Jehan


> ___
> desktop-devel-list mailing list
> desktop-devel-l...@gnome.org
> https://mail.gnome.org/mailman/listinfo/desktop-devel-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:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list

Re: [Gimp-developer] About The Python Script writing

[Jehan Pagès via gimp-developer-list]

Hi,

On Wed, Aug 25, 2021 at 1:52 AM Ofnuts via gimp-developer-list <
gimp-developer-list@gnome.org> wrote:

> Wouldn't it be more natural to write the migration program in Python
> itself (plus this needs Python2->Python3 migration)? Why add a
>

It's a third-party tool, not an official one. We don't have our say to what
people enjoying GIMP want to use it with? 

This being said, someone could create a similar tool in Python or whatever
you want.

dependency on yet another language? Is there a decent C# runtime on Linux?
>

That's a good question. I have no idea.
In any case, if it were to be contributed as an official tool in the end,
your worry would be most valid as cross-platform code matters a lot. As
long as it's just a third-party tool, everyone may use whatever they want.

Jehan


>
> On 24/08/2021 17:31, ShiroYuki Mot via gimp-developer-list wrote:
> > I wrote the Script File Migration Program.
> > It was used by MS Visual Studio C#.
> > The target is to migrate the simple and basic scripts to the new API 3 in
> > GIMP 2.99 (GIMP 3).
> > Yes, Scheme and Python, both.
> > It is still Draft level yet.
> > Scheme file was almost done, but, Python file is not complete yet.
> > (No workable Python code has been generated yet. Need manual editings.)
> >
> > Holding Items for Python. Can it be run on L
> > 1. class - Parameters (__gproperties__ = {)
> > 2. class - def do_create_procedure - procedure.add_argument_from_property
> > 3. pdb calling conversion ... not set out. Maybe, I know how to write.
> >4. old procedure arguments migration
> >
> > On Python,
> > The formatted/migration-based  sources are created from the official
> > 'foggify.py' .
> > The qualified phrases using "<>" replace by a value obtained from
> the
> > old code.
> >
> > Here is Questions.
> > 1. Can write PF_COLOR/PF_SPINNER/etc. block like a 'str/float' style in
> > '__gproperties__ = {' at class ?
> > 2. Is the Class name the Camel-style except "_" ?
> > ex. python-fu-shiro-migration-test-210 > ShiroMigrationTest210
> > 3. Can the procedure definition name include "_"?
> > (4th arg at 'procedure = Gimp.ImageProcedure.new' of 'def
> > do_create_procedure(self, name)')
> > ex. def shiromigrationtest210 > ? def shiro_migration_test_210 OK?
> >
> >
> >
> > Initially, the development language was VB.net.
> > As a possibility in the future, if I publish the source code (or
> > project/solution) and expect other people to participate, I thought that
> C#
> > was more versatile, so I wrote it by C#, which I am not used to.
> >
> >
> >
> > We, the beginner level GIMP scripting users, are referring to the
> Procedure
> > Browser.
> > So, I think there are many cases that there are a lot of pdb.xxx calling
> > sentences in the file.
> > In this case, I feel that visibility deteriorates because there are the
> new
> > multiple lines per the old syntax line by the migration.
> >
> > Maybe, it is better that using not pdb calling but Gimp command (Gimp
> class
> > ?).
> > But currently there does not exist the comparison table/list for these.
> > I think it would be very useful if that will be provided.
> >
> >
> > .zip Inf.
> > FileName : GIMPscriptMigSupport_API2to3.v.0.8.1.15.zip
> > FileDate : 2021/08/24 23:09:04 ( or * Downloaded Date * )
> > FileSize : 193099(189KB)
> > MD5 : 318f7a7002a44550188d630c9cd48cfa
> >SHA1 : 2e6390231b13f39b4d20f81e70003641cbadf499
> >
> > FileName : API_Inf/RemovedFunctions_Replacement_GIMP3.txt   <- in zip
> > FileName : GIMPscriptMigSupport_API2to3.exe   <- in zip
> > FileName : GIMPscriptMigSupport_API2to3.exe.config   <- in zip
> > FileName : Ref_Inf/GIMP_Enums.txt   <- in zip
> > FileName : Ref_Inf/Py3_Import.txt   <- in zip
> > FileName : Ref_Inf/Py3_Registration.txt   <- in zip
> >
> >   GIMPscriptMigSupport_API2to3.v.0.8.1.15.zip
> > <
> https://drive.google.com/file/d/1lV3W73fYz8B31uyckk9yXWBLmau3TLrz/view?usp=drive_web
> >
> > ___
> > gimp-developer-list mailing list
> > List address:gimp-developer-list@gnome.org
> > List membership:
> https://mail.gnome.org/mailman/listinfo/gimp-developer-list
> > List archives:   https://mail.gnome.org/archives/gimp-developer-list
>
>
> ___
> gimp-developer-list mailing list
> List address:gimp-developer-list@gnome.org
> 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:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list

Re: [Gimp-developer] About The Python Script writing

[Jehan Pagès via gimp-developer-list]

Hi!

On Tue, Aug 24, 2021 at 5:31 PM ShiroYuki Mot 
wrote:

> I wrote the Script File Migration Program.
> It was used by MS Visual Studio C#.
> The target is to migrate the simple and basic scripts to the new API 3 in
> GIMP 2.99 (GIMP 3).
> Yes, Scheme and Python, both.
> It is still Draft level yet.
> Scheme file was almost done, but, Python file is not complete yet.
> (No workable Python code has been generated yet. Need manual editings.)
>
> Holding Items for Python.
> 1. class - Parameters (__gproperties__ = {)
> 2. class - def do_create_procedure - procedure.add_argument_from_property
> 3. pdb calling conversion ... not set out. Maybe, I know how to write.
>   4. old procedure arguments migration
>
> On Python,
> The formatted/migration-based  sources are created from the official
> 'foggify.py' .
> The qualified phrases using "<>" replace by a value obtained from
> the old code.
>
> Here is Questions.
> 1. Can write PF_COLOR/PF_SPINNER/etc. block like a 'str/float' style in
> '__gproperties__ = {' at class ?
>

Actually creating procedure parameter in Python plug-ins is a bit of a
mess, because of various issues in pygobject.
Adding properties to the class is indeed not mandatory, we should be able
to just create a GParamSpec and use it in gimp_procedure_add_argument().

So we **should** be able to just write:

paramspec = GObject.param_spec_rgb("color",
>  "Color",
> "Color", true, red,
>
> GObject.ParamFlags.READWRITE)
> procedure.add_argument(paramspec)
>

Except it doesn't work because of a bug in pygobject:
https://gitlab.gnome.org/GNOME/pygobject/-/issues/227#note_570031

This is why I created gimp_procedure_add_argument_from_property() to grab
the GParamSpec out of a created class' property.

Now the question is: how do you create a property to a GObject class in
Python? Well it turns out documentation lists 3 ways to create a GObject
property:
https://python-gtk-3-tutorial.readthedocs.io/en/latest/objects.html#create-new-properties

I used the __gproperties__ one because it felt a bit more centralized and
easy to detect (also it's apparently the only syntax allowing to set
min/max values), but it turned out that I never managed to make a Gimp.RGB
property using this syntax. This is the reason why in Foggify plug-in, all
but the "color" property use the __gproperties__ syntax whereas "color" is
defined like this:

color = GObject.Property(type =Gimp.RGB, default=_color,
>  nick =_("Fog _color"),
>  blurb=_("Fog color"))
>

It looks like a limitation of this __gproperties__ syntax, but maybe I
missed something in how this syntax works.
And this is all why it's such a mess. Of course, maybe a best way might be
to define all properties with GObject.Property() syntax, then we don't have
discrepancy in code style (but then we also lose the min/max ability).



> 2. Is the Class name the Camel-style except "_" ?
>ex. python-fu-shiro-migration-test-210 > ShiroMigrationTest210
>

Yes we use CamelCasing for class names in our Python code, I guess it's
just usage in Python (https://www.python.org/dev/peps/pep-0008/#class-names
).
Now we have coding style for within GIMP core code, but we don't mind what
third-party software developers want to use. We are really not into coding
style wars, only keeping consistency within a single codebase.

3. Can the procedure definition name include "_"?
>(4th arg at 'procedure = Gimp.ImageProcedure.new' of 'def
> do_create_procedure(self, name)')
>ex. def shiromigrationtest210 > ? def shiro_migration_test_210 OK?
>

Sure. Python doesn't forbid underscores in function names. Actually it even
advises using it in the same coding style document (
https://www.python.org/dev/peps/pep-0008/#function-and-variable-names). You
can see this is also the convention we are using in our Python code in
GIMP's codebase.

>
> Initially, the development language was VB.net.
> As a possibility in the future, if I publish the source code (or
> project/solution) and expect other people to participate, I thought that C#
> was more versatile, so I wrote it by C#, which I am not used to.
>

To be fair, I don't think I'd be a big fan of either VB or C#. This being
said, same as coding style, you are free to do and use whatever you want,
and I won't be the one to tell you it's wrong. If you make a great tool for
migrating third-party plug-ins into GIMP 3 API, we will even happily make a
mention of it on gimp.org when we are closing the release date! 

>
>
> We, the beginner level GIMP scripting users, are referring to the
> Procedure Browser.
> So, I think there are many cases that there are a lot of pdb.xxx calling
> sentences in the file.
> In this case, I feel that visibility deteriorates because there are the
> new multiple lines per the old syntax line by the migration.
>
> Maybe, it is better that using not pdb calling but Gimp command (Gimp
> class 

Re: [Gimp-developer] [At GIMP 3 era, The Python Script writing style]

[Jehan Pagès via gimp-developer-list]

Hi!

On Mon, Aug 2, 2021 at 3:15 PM ShiroYuki Mot 
wrote:

> Dear Jehan Pagès, Thanks for reply.
>
> Mostly yes. There will probably be some more changes so you will have to
>> change more from time to time until GIMP 3 release (when it will be
>> finalized).
>>
>
>  Basically, the current scripting style is on a new stage, isn't it?
>

I don't really understand what you mean by "new stage". 

We can learn the basic writing from this.
>
> Not really. This is on my TODO list to write proper docs. We have some
>> starts in the devel-docs/GIMP3-plug-in-porting-guide/ folder in the
>> repository, but nothing yet which you can really call a proper
>> "documentation".
>>
>
>  Maybe, because of the difference from GIMP 2.10 scripting, many people
> will need the guide to write/rewrite.
> I think that the porting will be not so easy...
>

Most plug-ins can be actually ported in less than 30 min (let's say 2 or 3
hours for someone who does this for the first time by just following a
tutorial; nothing insurmountable). I say it by experience from having
ported a huge portion of core plug-ins.


> I feel that the hurdle is higher than before when it was possible to
> replace api name/enumeration name.
> Even now, there is a lot of talk that old plug-ins don't work
>

Our API has been stable for a long long time. Actually the cases of broken
plug-ins which we can see here and there are plug-ins which have been
basically abandoned/unmaintained for years and years. In such case, first
there were deprecation warning triggering popups then much later, functions
were removed. So we are talking plug-ins which have not been updated for
like 10 or 15 years!


> , but with GIMP 3, many more/most will be wiped out.
>

Sure. We did a choice of going with a cleaner API. Sometimes I wonder if
that was not a mistake and we should have tried compatibility as much as
possible. On the other hand, we would have lost so much. In any case, it's
too late now. We are not going to redo everything.

Also as said, porting is actually very quick. Some people already started
(there are a bunch of plug-ins with a GIMP 2.99.x version; even G'MIC can
work on 2.99.x). The base logics of our plug-in stayed quite similar. So
it's nothing too hard.

And once again, same as the v2 API has been around for more than 15 years,
I expect the v3 API to stay for quite some time. We are not planning to
break API all the time. 


>
>> It's never premature to write docs. Sure there will be changes, and sure
>> it means some of the docs will be wrong and need to be changed before
>> release. But better start early and fix as we go than write dozens of pages
>> of documentation at the last minute.
>>
>> This is actually a good way to contribute to GIMP with other than code.
>> The few random files we have in devel-docs/GIMP3-plug-in-porting-guide/
>> were written by several people already. If you port your own plug-ins and
>> want to write documentation, do not hesitate. Right now it's a mess because
>> everyone wrote a bit of what they wanted, but with time and more people
>> giving time into it, the documentation will organize itself. 
>>
>
>  Let's port! Thanks.
>
Cool! 

Jehan

>
> PS;
> I tried writing template from GIMP 2.99.6 Foggify.py. So, attached.
> (Maybe, including many wrong points. UTF-8 CrLf)
>
>
> 2021年8月2日(月) 19:08 Jehan Pagès :
>
>> Hi!
>>
>> On Mon, Aug 2, 2021 at 9:38 AM ShiroYuki Mot via gimp-developer-list <
>> gimp-developer-list@gnome.org> wrote:
>>
>>> It is the Question (same as
>>> https://gitlab.gnome.org/GNOME/gimp/-/issues/7114)
>>> Please teach me.
>>>
>>> At the next coming 2.99.8, the Python script will avoid the crash. (See
>>> #7106 (closed))
>>> (https://gitlab.gnome.org/GNOME/gimp/-/issues/7106)
>>> So, One question I have. It is not the issue!.
>>>
>>> Can I rewrite my own Python scripts by referring to the foggify.py
>>> (official one) writing style bundled with GIMP 2.99.8?
>>>
>>
>> Mostly yes. There will probably be some more changes so you will have to
>> change more from time to time until GIMP 3 release (when it will be
>> finalized).
>>
>> Because of I think that the scripting is so far from GIMP 2.10 era... (Too
>>> high hardles / So difficult)
>>>
>>
>> It's actually simpler in many ways, but yeah it changed (though bases
>> concepts still are the same). That's a fact. Also the Python binding used
>> to have some of the new features already (like dialog generation) which
>> makes the improvements less visible for people who were already making
>> Python plug-ins.
>>
>> Are there any points to be aware of?
>>> Or does the documentation exist for GIMP 3 scripting?
>>>
>>
>> Not really. This is on my TODO list to write proper docs. We have some
>> starts in the devel-docs/GIMP3-plug-in-porting-guide/ folder in the
>> repository, but nothing yet which you can really call a proper
>> "documentation".
>>
>> Is it premature? (Is it better to wait for a while? Will some change
>>> come?)
>>>
>>
>> It's never premature 

Re: [Gimp-developer] [At GIMP 3 era, The Python Script writing style]

[Jehan Pagès via gimp-developer-list]

Hi!

On Mon, Aug 2, 2021 at 9:38 AM ShiroYuki Mot via gimp-developer-list <
gimp-developer-list@gnome.org> wrote:

> It is the Question (same as
> https://gitlab.gnome.org/GNOME/gimp/-/issues/7114)
> Please teach me.
>
> At the next coming 2.99.8, the Python script will avoid the crash. (See
> #7106 (closed))
> (https://gitlab.gnome.org/GNOME/gimp/-/issues/7106)
> So, One question I have. It is not the issue!.
>
> Can I rewrite my own Python scripts by referring to the foggify.py
> (official one) writing style bundled with GIMP 2.99.8?
>

Mostly yes. There will probably be some more changes so you will have to
change more from time to time until GIMP 3 release (when it will be
finalized).

Because of I think that the scripting is so far from GIMP 2.10 era... (Too
> high hardles / So difficult)
>

It's actually simpler in many ways, but yeah it changed (though bases
concepts still are the same). That's a fact. Also the Python binding used
to have some of the new features already (like dialog generation) which
makes the improvements less visible for people who were already making
Python plug-ins.

Are there any points to be aware of?
> Or does the documentation exist for GIMP 3 scripting?
>

Not really. This is on my TODO list to write proper docs. We have some
starts in the devel-docs/GIMP3-plug-in-porting-guide/ folder in the
repository, but nothing yet which you can really call a proper
"documentation".

Is it premature? (Is it better to wait for a while? Will some change come?)
>

It's never premature to write docs. Sure there will be changes, and sure it
means some of the docs will be wrong and need to be changed before release.
But better start early and fix as we go than write dozens of pages of
documentation at the last minute.

This is actually a good way to contribute to GIMP with other than code. The
few random files we have in devel-docs/GIMP3-plug-in-porting-guide/ were
written by several people already. If you port your own plug-ins and want
to write documentation, do not hesitate. Right now it's a mess because
everyone wrote a bit of what they wanted, but with time and more people
giving time into it, the documentation will organize itself. 

Jehan

___
> gimp-developer-list mailing list
> List address:gimp-developer-list@gnome.org
> 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:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list

Re: [Gimp-developer] Mime type application/x-xcf in /etc/mime.types vs image/x-xcf in gimp.desktop

[Jehan Pagès via gimp-developer-list]

Hi,

On Sat, Jul 31, 2021 at 2:10 AM Joel Hockey  wrote:

> Thanks Jehan,
>
> Debian will change this after their current release freeze.
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=991158
>
> They have requested if gimp could register the mime type with iana?
>

Sure why not.

Charles offered help if needed: ple...@debian.org
>

Definitely yes. I have started to fill the form (
https://www.iana.org/form/media-types), but they ask for a lot of
information I'm not sure of (even looking at the RFC they link as
references). So I would appreciate some feedback. Charles' email has been
added in recipients of this thread.

Attached is my first try at filling the form. Would anyone mind review and
tell me if I misunderstood anything? I left a lot of notes here and there
for reviewers because there were many stuff I was not sure of.
Thanks!

Jehan


> On Sat, Jul 17, 2021 at 6:54 AM Jehan Pagès 
> wrote:
>
>> Hi!
>>
>> On Fri, Jul 16, 2021 at 9:49 PM Joel Hockey via gimp-developer-list <
>> gimp-developer-list@gnome.org> wrote:
>>
>>> When I use GIMP in Chrome OS Linux environment, it does not automatically
>>> associate *.xcf files with GIMP since there is a mismatch between the
>>> /usr/share/applications/gimp.desktop file which registers to handle mime
>>> types including image/x-xcf and the system /etc/mime.types file which
>>> associates extension xcf with mime type application/x-xcf.
>>>
>>> I'm one of the developers on Chrome OS.  I believe most linux desktops
>>> are
>>> using the xdg shared-mime-info database rather than /etc/mime.types, but
>>> we
>>> haven't yet implemented that.
>>>
>>> https://gitlab.freedesktop.org/xdg/shared-mime-info/-/blob/47ca1dc530d356336ffe1b7a45dc5dc8f0e528ca/data/freedesktop.org.xml.in#L5568
>>>
>>> I am planning to request debian media-types package to update their
>>> /etc/mime.types to use image/x-xcf rather than application/x-xcf which
>>> will
>>> fix things for me if they are happy to change.
>>>
>>
>> Indeed I think that  image/x-xcf is the right one. I didn't even know of
>> the application/x-xcf !
>>
>> Does anyone know the history why these are different, or would there be
>>> any
>>> issue if /etc/mime.types did change?
>>>
>>
>> Sorry I don't. If you find the source of this duplicate, please do not
>> hesitate to come and tell us later. 
>>
>> Jehan
>>
>>
>>> Thanks,
>>> Joel
>>> ___
>>> gimp-developer-list mailing list
>>> List address:gimp-developer-list@gnome.org
>>> 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
# Your Full Name

Jehan Pagès

# Type Name

image

# Subtype Name

Standard Tree (no prefix)
xcf

**Note**: I wonder if XCF should actually be considered *vendor* tree
(even if there is no vendor per-se and no organism behind).
Our XCF format is clearly tied to GIMP and will evolve with it. Wouldn't it
be somehow the definition of a vendor format?

# Required Parameters

**Note**: no idea how to fill these. They give RFC 2046 §1, and RFC 6838
§4.3 as references but these sections discuss format and such, but not
really what these parameters are (I have not read the full RFCs).

# Optional Parameters

**Note**: same as above.

# Encoding Considerations

binary

# Security Considerations

No active content or action of any kind is contained in an XCF file.

XCF files may contain any possible metadata (Exif, XMP, IPTC, and a
generic comment), which are usually found in all common image formats.
This may reveal very sensitive information on author's name, address,
position, movements, owned material…

Compression is used to store image tile data. The 2 possible compression
formats so far are RLE and zlib compression. Image data can be enormous
once uncompressed, especially for work images, which can contains dozens
of layers. Since the format compresses the data per tile blocks of width
and height of up to 64 pixels, the reading software will uncompress
progressively, hence with the opportunity to quit at any time. This
should be enough to avoid any memory-consuming attacks.

The XCF format is an image work format, which may contain source images,
references and sensitive metadata. It is up to the users to handle its
data and metadata with copyright and privacy concerns, according to
local laws.

**Note**: I tried to fill in with some text I felt relevant after
reading RFC 6838 §4.6, but I'm not sure if maybe they are looking for
specific.

# Data Interoperability Considerations

XCF is a living format which 

Re: [Gimp-developer] Mime type application/x-xcf in /etc/mime.types vs image/x-xcf in gimp.desktop

[Jehan Pagès via gimp-developer-list]

Hi!

On Fri, Jul 16, 2021 at 9:49 PM Joel Hockey via gimp-developer-list <
gimp-developer-list@gnome.org> wrote:

> When I use GIMP in Chrome OS Linux environment, it does not automatically
> associate *.xcf files with GIMP since there is a mismatch between the
> /usr/share/applications/gimp.desktop file which registers to handle mime
> types including image/x-xcf and the system /etc/mime.types file which
> associates extension xcf with mime type application/x-xcf.
>
> I'm one of the developers on Chrome OS.  I believe most linux desktops are
> using the xdg shared-mime-info database rather than /etc/mime.types, but we
> haven't yet implemented that.
>
> https://gitlab.freedesktop.org/xdg/shared-mime-info/-/blob/47ca1dc530d356336ffe1b7a45dc5dc8f0e528ca/data/freedesktop.org.xml.in#L5568
>
> I am planning to request debian media-types package to update their
> /etc/mime.types to use image/x-xcf rather than application/x-xcf which will
> fix things for me if they are happy to change.
>

Indeed I think that  image/x-xcf is the right one. I didn't even know of
the application/x-xcf !

Does anyone know the history why these are different, or would there be any
> issue if /etc/mime.types did change?
>

Sorry I don't. If you find the source of this duplicate, please do not
hesitate to come and tell us later. 

Jehan


> Thanks,
> Joel
> ___
> gimp-developer-list mailing list
> List address:gimp-developer-list@gnome.org
> 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:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list

Re: [Gimp-developer] Notice to documentation contributors: plans to update the gimp-help repository

[Jehan Pagès via gimp-developer-list]

Hi all!

On Tue, Jun 15, 2021 at 7:47 PM Jehan Pagès 
wrote:

> Hi all!
>
> On Mon, Jun 7, 2021 at 11:13 AM Marco Ciampa via gimp-developer-list <
> gimp-developer-list@gnome.org> wrote:
>
>> On Sun, Jun 06, 2021 at 01:38:21PM -0400, Jacob Boerema via
>> gimp-developer-list wrote:
>> > On 5 Jun 2021 at 23:57, Jehan Pagès via gimp-developer-list wrote:
>> >
>> > > Damned Lies broke on POT generation for this module though, because of
>> > > missing dependencies (cf.
>> > > https://gitlab.gnome.org/Infrastructure/damned-lies/-/issues/236)
>> but I
>> > > guess it should be fixed soon.
>> >
>> > It seems that they are having some trouble adding that dependency.
>> >
>> > They are suggesting using itstool as a possible better way to extract
>> > translation strings from XML files than using xml2po. We should
>> investigate
>> > this.
>> >
>>
>> As I already wrote in the issue page:
>>
>> https://gitlab.gnome.org/Infrastructure/damned-lies/-/issues/236
>>
>> Why don't you install the distro package instead?
>> It probably has a name like this:
>>
>> python3-libxml2 (or at least it is that in Debian-Fedora-CentOS-Ubuntu...)
>>
>> yum install python3-libxml2
>>
>> or
>>
>> apt install python3-libxml2
>>
>>
> Now Damned Lies has been updated appropriately and the master branch is
> properly processed again.
> Thanks to all who helped!
>
> So I proceeded with the branching which was planned. As of today,
> `gimp-help-2-10` is the branch to continue working on GIMP 2.10 series
> documentation. `master` is now dedicated to GIMP 2.99/3.0 so we can start
> documenting new unreleased features.
> I opened a bug report to Damned Lies to ask for this new branch to also be
> followed by the translation infrastructure:
> https://gitlab.gnome.org/Infrastructure/damned-lies/-/issues/239
>

Thanks to Claude Paroz for taking care of this last point!
Now the gimp-help module on Damned Lies follow both the `master` and
`gimp-help-2-10` branches: https://l10n.gnome.org/module/gimp-help/

Documentation is now fully ready to diverge. It also means anyone wanting
to help contribute on documentation for future GIMP 3 is very welcome to
start opening new sections/pages for the new features coming with GIMP 3,
even when they are still unfinished. To get a quick idea on these, the 3
development versions already released are a good start:

https://www.gimp.org/news/2020/11/06/gimp-2-99-2-released/
https://www.gimp.org/news/2020/12/25/gimp-2-99-4-released/
https://www.gimp.org/news/2021/05/08/gimp-2-99-6-released/

To go further, the NEWS file is obviously a bit more complete:
https://gitlab.gnome.org/GNOME/gimp/-/blob/master/NEWS

And finally do not hesitate to ask us directly and discuss with us when you
don't understand something. The current mailing list is obviously a good
discussion point though the IRC channel may be a bit easier to catch people
(#gimp on GIMPnet).

It might also be a good starting point to discuss how to better synchronize
development and documentation. There is this whole help ID business (we can
assign an help ID to various parts of the GUI and when these have focus and
one hit F1 for instance, or when hitting the Help button on some dialog, it
brings you to the corresponding manual page/section) also which I think
would be worth being disentangled. How should devs choose the IDs? How
should documenters be made aware of new IDs? I think some process and more
communication would definitely be worth it.

Jehan


> Last point: it has been 10 days since I proposed for Jacob to be
> co-maintainer on gimp-help repo. We got agreement from Mitch and Marco and
> none speaking against, so I proceeded with this. Jacob is now considered a
> new co-maintainer of gimp-help!
> Welcome Jacob to your new role on this repository (or as you said yourself
> on IRC: maybe you are doomed now! ).
>
> Jehan
>
>
>> --
>>
>> Saluton,
>> Marco Ciampa
>> ___
>> gimp-developer-list mailing list
>> List address:gimp-developer-list@gnome.org
>> 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:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list

Re: [Gimp-developer] Notice to documentation contributors: plans to update the gimp-help repository

[Jehan Pagès via gimp-developer-list]

Hi all!

On Mon, Jun 7, 2021 at 11:13 AM Marco Ciampa via gimp-developer-list <
gimp-developer-list@gnome.org> wrote:

> On Sun, Jun 06, 2021 at 01:38:21PM -0400, Jacob Boerema via
> gimp-developer-list wrote:
> > On 5 Jun 2021 at 23:57, Jehan Pagès via gimp-developer-list wrote:
> >
> > > Damned Lies broke on POT generation for this module though, because of
> > > missing dependencies (cf.
> > > https://gitlab.gnome.org/Infrastructure/damned-lies/-/issues/236) but
> I
> > > guess it should be fixed soon.
> >
> > It seems that they are having some trouble adding that dependency.
> >
> > They are suggesting using itstool as a possible better way to extract
> > translation strings from XML files than using xml2po. We should
> investigate
> > this.
> >
>
> As I already wrote in the issue page:
>
> https://gitlab.gnome.org/Infrastructure/damned-lies/-/issues/236
>
> Why don't you install the distro package instead?
> It probably has a name like this:
>
> python3-libxml2 (or at least it is that in Debian-Fedora-CentOS-Ubuntu...)
>
> yum install python3-libxml2
>
> or
>
> apt install python3-libxml2
>
>
Now Damned Lies has been updated appropriately and the master branch is
properly processed again.
Thanks to all who helped!

So I proceeded with the branching which was planned. As of today,
`gimp-help-2-10` is the branch to continue working on GIMP 2.10 series
documentation. `master` is now dedicated to GIMP 2.99/3.0 so we can start
documenting new unreleased features.
I opened a bug report to Damned Lies to ask for this new branch to also be
followed by the translation infrastructure:
https://gitlab.gnome.org/Infrastructure/damned-lies/-/issues/239

Last point: it has been 10 days since I proposed for Jacob to be
co-maintainer on gimp-help repo. We got agreement from Mitch and Marco and
none speaking against, so I proceeded with this. Jacob is now considered a
new co-maintainer of gimp-help!
Welcome Jacob to your new role on this repository (or as you said yourself
on IRC: maybe you are doomed now! ).

Jehan


> --
>
> Saluton,
> Marco Ciampa
> ___
> gimp-developer-list mailing list
> List address:gimp-developer-list@gnome.org
> 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:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list

Re: [Gimp-developer] Notice to documentation contributors: plans to update the gimp-help repository

[Jehan Pagès via gimp-developer-list]

Hi all!

On Thu, Jun 3, 2021 at 10:39 PM Marco Ciampa via gimp-developer-list <
gimp-developer-list@gnome.org> wrote:

> On Thu, May 20, 2021 at 03:46:13AM +0200, Jehan Pagès wrote:
> > Hello all!
>
> Sorry for the late reply...
>
> > Some efforts is being made to improve a bit the documentation process:
> >
> > 1. A Python 3 port is being worked on right now by Jacob Boerema (see
> > https://gitlab.gnome.org/GNOME/gimp-help/-/merge_requests/50). He nearly
> > finished. I don't think anyone is against this since Python 2 is EOL, but
> > if anyone has any comment, please feel free. Also Jacob has some issues
> > with the `xml_helper.py` script so we wondered if this one was actually
> > being used by anyone actually contributing to the documentation (because
> if
> > not, and it is not considered useful anymore, maybe some time can be
> saved
> > by dropping this script).
> > In any case, feel free to test the associated branch and make any remark.
>
> It's ok for me.
>

For the record, we merged the Python 3 port today. So gimp-help is now at
least a bit less outdated! 藍

Damned Lies broke on POT generation for this module though, because of
missing dependencies (cf.
https://gitlab.gnome.org/Infrastructure/damned-lies/-/issues/236) but I
guess it should be fixed soon.

By the way, I would like to propose for Jacob Boerema to be promoted as
co-maintainer on the gimp-help repository, since I believe he is now the
one who knows the best its technical logics, scripts and alike among still
active contributors (actually even considering activity on gimp-help in the
last 10 years, he did the most in the last few weeks). For the record,
Jacob has been a very active GIMP contributor for a year now, and he is
doing excellent technical work.
I believe the gimp-help repository can only benefit from having someone
technical-side among its co-maintainers.

Thus is there any of the current maintainers against adding Jacob as a new
co-maintainer? I'll take an absence of answer as being OK with it, but if
you read and are in favor, I will appreciate even a short answer. 
If none is against it, I propose we add him on the maintainers list in a
week or so.

By the way, if anyone wants to update some data in the list, please tell me
(if you don't want to be considered a maintainer anymore for instance
because you went to do something else and have no time anymore for
gimp-help; or if you just want to update your email address, etc.). At
least one person in the current list has an email address which doesn't
work anymore.
For current info, see:
https://gitlab.gnome.org/GNOME/gimp-help/-/blob/master/gimp-help.doap



> > 2. We are considering branching the tree (to `gimp-help-2-10`) so that
> the
> > `master` branch will be used for preparing the documentation specific to
> > GIMP 3, whereas any work specific to the 2.10.x series can continue on
> the
> > new branch.
>
> Ok I'll finish updating the Italian translation presumably tomorrow.
>

Cool. Maybe we'll hold off the branching a day or 2 to first resolve the
Damned Lies issues and if we find any more little details to fix before
branching.

>
> > We feel like these 3 plans could be done in about 2 weeks (so let's say
> the
> > weekend of June 5/6), but if anyone feels like this is wrong, or that
> > things should be done differently, please tell us before we merge the
> > Python 3 port and branch the `master` tree, please.
>
> It's ok for me.
>
> > Róman Joost, Ulf-D. Ehlert, Marco Ciampa, Julien Hardelin, Michael
> Natterer
> > and Michael Schumacher (all in BCC) in particular, you are the
> > co-maintainers of this repository (if the `MAINTAINERS` and .doap files
> are
> > still up-to-date), so we'd appreciate your input in particular. Any other
> > contributor is welcome to give an opinion too of course. We don't want to
> > do any mistake. 
> >
> > The third plan we have (not within a 2-week schedule, but hopefully at
> > least before GIMP 3 release) is that we wonder if a better process for
> > releases of the documentation (on the website in particular) could not be
> > done. Maybe we are wrong, but it feels like the release/update into the
> > wild could be improved, couldn't it?
> > What we are thinking are things like tagging the tree leading to
> automatic
> > (or at least easier) build then publication of the documentation online,
> > probably through the Continuous Integration pipelines (we have been
> > improving GIMP release the same way lately, by generating source tarballs
> > automatically, and these days, we are doing the same with the Windows
> > installer).
>
> I would appreciate (=volunteer to translate) a multilanguage site...
>
> > So same here, if anyone has any opinion or wishes on how the
> documentation
> > process should be improved, we welcome the ideas and propositions.
>
> I have one for the future... I'll explain after the branch...
>

Cool. Let's discuss this when the time comes then! 

Jehan


> > Thanks all!
>
> Thank YOU!
>
> --
>
> 

Re: [Gimp-developer] Notice to documentation contributors: plans to update the gimp-help repository

[Jehan Pagès via gimp-developer-list]

Hi João,

On Thu, Jun 3, 2021 at 6:55 PM Joao S. O. Bueno  wrote:

> Just so that this does not feel like no one is reading:
> although there is a long time I do not fidle with the docs,
> all things listed seem quite reasonable.
>

Thanks! I was not really thinking none was reading so I didn't mind too
much the absence of responses (especially as here I don't think there is
anything controversial, but who knows…), but I still needed to make the
announcement, just to (1) make sure we are not missing anything with our
change and (2) because we don't want anyone to be left out of important
decisions.

Anyway thanks for the answer! 

Jehan

P.S.: Marco, sorry, I realize you were in the main recipient list of my
previous email. You were supposed to be in BCC, along with other
maintainers of the gimp-help repository. Anyway, not that your email is not
known here , but I know many people don't like to be direct recipients of
emails.


> On Thu, 3 Jun 2021 at 13:36, Jehan Pagès via gimp-developer-list <
> gimp-developer-list@gnome.org> wrote:
>
>> Hi all, developers, documenters and co-maintainers of the gimp-help
>> repository,
>>
>> This is just a small reminder for our plan to merge the Python 3 port (by
>> Jacob Boerema) and do the gimp-help-2-10/master branching this week-end,
>> i.e. in 2 or 3 days unless outstanding issues appear. If anyone has a
>> reluctance, this is the time to make it heard.
>>
>> Otherwise, my next and last message on the topic will likely be once we
>> have done the merge and branching!
>> Have fun and thanks everyone! 
>>
>> Jehan
>>
>> On Thu, May 20, 2021 at 3:46 AM Jehan Pagès 
>> wrote:
>>
>> > Hello all!
>> >
>> > Some efforts is being made to improve a bit the documentation process:
>> >
>> > 1. A Python 3 port is being worked on right now by Jacob Boerema (see
>> > https://gitlab.gnome.org/GNOME/gimp-help/-/merge_requests/50). He
>> nearly
>> > finished. I don't think anyone is against this since Python 2 is EOL,
>> but
>> > if anyone has any comment, please feel free. Also Jacob has some issues
>> > with the `xml_helper.py` script so we wondered if this one was actually
>> > being used by anyone actually contributing to the documentation
>> (because if
>> > not, and it is not considered useful anymore, maybe some time can be
>> saved
>> > by dropping this script).
>> > In any case, feel free to test the associated branch and make any
>> remark.
>> >
>> > 2. We are considering branching the tree (to `gimp-help-2-10`) so that
>> the
>> > `master` branch will be used for preparing the documentation specific to
>> > GIMP 3, whereas any work specific to the 2.10.x series can continue on
>> the
>> > new branch.
>> >
>> > We feel like these 3 plans could be done in about 2 weeks (so let's say
>> > the weekend of June 5/6), but if anyone feels like this is wrong, or
>> that
>> > things should be done differently, please tell us before we merge the
>> > Python 3 port and branch the `master` tree, please.
>> >
>> > Róman Joost, Ulf-D. Ehlert, Marco Ciampa, Julien Hardelin, Michael
>> > Natterer and Michael Schumacher (all in BCC) in particular, you are the
>> > co-maintainers of this repository (if the `MAINTAINERS` and .doap files
>> are
>> > still up-to-date), so we'd appreciate your input in particular. Any
>> other
>> > contributor is welcome to give an opinion too of course. We don't want
>> to
>> > do any mistake. 
>> >
>> > The third plan we have (not within a 2-week schedule, but hopefully at
>> > least before GIMP 3 release) is that we wonder if a better process for
>> > releases of the documentation (on the website in particular) could not
>> be
>> > done. Maybe we are wrong, but it feels like the release/update into the
>> > wild could be improved, couldn't it?
>> > What we are thinking are things like tagging the tree leading to
>> automatic
>> > (or at least easier) build then publication of the documentation online,
>> > probably through the Continuous Integration pipelines (we have been
>> > improving GIMP release the same way lately, by generating source
>> tarballs
>> > automatically, and these days, we are doing the same with the Windows
>> > installer).
>> >
>> > So same here, if anyone has any opinion or wishes on how the
>> documentation
>> > process should be improved, we welcome the ideas and propositions.
>> >
>> >

Re: [Gimp-developer] Notice to documentation contributors: plans to update the gimp-help repository

[Jehan Pagès via gimp-developer-list]

Hi all, developers, documenters and co-maintainers of the gimp-help
repository,

This is just a small reminder for our plan to merge the Python 3 port (by
Jacob Boerema) and do the gimp-help-2-10/master branching this week-end,
i.e. in 2 or 3 days unless outstanding issues appear. If anyone has a
reluctance, this is the time to make it heard.

Otherwise, my next and last message on the topic will likely be once we
have done the merge and branching!
Have fun and thanks everyone! 

Jehan

On Thu, May 20, 2021 at 3:46 AM Jehan Pagès 
wrote:

> Hello all!
>
> Some efforts is being made to improve a bit the documentation process:
>
> 1. A Python 3 port is being worked on right now by Jacob Boerema (see
> https://gitlab.gnome.org/GNOME/gimp-help/-/merge_requests/50). He nearly
> finished. I don't think anyone is against this since Python 2 is EOL, but
> if anyone has any comment, please feel free. Also Jacob has some issues
> with the `xml_helper.py` script so we wondered if this one was actually
> being used by anyone actually contributing to the documentation (because if
> not, and it is not considered useful anymore, maybe some time can be saved
> by dropping this script).
> In any case, feel free to test the associated branch and make any remark.
>
> 2. We are considering branching the tree (to `gimp-help-2-10`) so that the
> `master` branch will be used for preparing the documentation specific to
> GIMP 3, whereas any work specific to the 2.10.x series can continue on the
> new branch.
>
> We feel like these 3 plans could be done in about 2 weeks (so let's say
> the weekend of June 5/6), but if anyone feels like this is wrong, or that
> things should be done differently, please tell us before we merge the
> Python 3 port and branch the `master` tree, please.
>
> Róman Joost, Ulf-D. Ehlert, Marco Ciampa, Julien Hardelin, Michael
> Natterer and Michael Schumacher (all in BCC) in particular, you are the
> co-maintainers of this repository (if the `MAINTAINERS` and .doap files are
> still up-to-date), so we'd appreciate your input in particular. Any other
> contributor is welcome to give an opinion too of course. We don't want to
> do any mistake. 
>
> The third plan we have (not within a 2-week schedule, but hopefully at
> least before GIMP 3 release) is that we wonder if a better process for
> releases of the documentation (on the website in particular) could not be
> done. Maybe we are wrong, but it feels like the release/update into the
> wild could be improved, couldn't it?
> What we are thinking are things like tagging the tree leading to automatic
> (or at least easier) build then publication of the documentation online,
> probably through the Continuous Integration pipelines (we have been
> improving GIMP release the same way lately, by generating source tarballs
> automatically, and these days, we are doing the same with the Windows
> installer).
>
> So same here, if anyone has any opinion or wishes on how the documentation
> process should be improved, we welcome the ideas and propositions.
>
> Thanks all!
>
> Jehan, on behalf of the GIMP team
>
> --
> 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@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list

[Gimp-developer] Notice to documentation contributors: plans to update the gimp-help repository

[Jehan Pagès via gimp-developer-list]

Hello all!

Some efforts is being made to improve a bit the documentation process:

1. A Python 3 port is being worked on right now by Jacob Boerema (see
https://gitlab.gnome.org/GNOME/gimp-help/-/merge_requests/50). He nearly
finished. I don't think anyone is against this since Python 2 is EOL, but
if anyone has any comment, please feel free. Also Jacob has some issues
with the `xml_helper.py` script so we wondered if this one was actually
being used by anyone actually contributing to the documentation (because if
not, and it is not considered useful anymore, maybe some time can be saved
by dropping this script).
In any case, feel free to test the associated branch and make any remark.

2. We are considering branching the tree (to `gimp-help-2-10`) so that the
`master` branch will be used for preparing the documentation specific to
GIMP 3, whereas any work specific to the 2.10.x series can continue on the
new branch.

We feel like these 3 plans could be done in about 2 weeks (so let's say the
weekend of June 5/6), but if anyone feels like this is wrong, or that
things should be done differently, please tell us before we merge the
Python 3 port and branch the `master` tree, please.

Róman Joost, Ulf-D. Ehlert, Marco Ciampa, Julien Hardelin, Michael Natterer
and Michael Schumacher (all in BCC) in particular, you are the
co-maintainers of this repository (if the `MAINTAINERS` and .doap files are
still up-to-date), so we'd appreciate your input in particular. Any other
contributor is welcome to give an opinion too of course. We don't want to
do any mistake. 

The third plan we have (not within a 2-week schedule, but hopefully at
least before GIMP 3 release) is that we wonder if a better process for
releases of the documentation (on the website in particular) could not be
done. Maybe we are wrong, but it feels like the release/update into the
wild could be improved, couldn't it?
What we are thinking are things like tagging the tree leading to automatic
(or at least easier) build then publication of the documentation online,
probably through the Continuous Integration pipelines (we have been
improving GIMP release the same way lately, by generating source tarballs
automatically, and these days, we are doing the same with the Windows
installer).

So same here, if anyone has any opinion or wishes on how the documentation
process should be improved, we welcome the ideas and propositions.

Thanks all!

Jehan, on behalf of the GIMP team

-- 
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@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list

[Gimp-developer] ANNOUNCE: GIMP 2.99.6 released

[Jehan Pagès via gimp-developer-list]

Hello everyone!

We have not been very good with announcing releases on the mailing list
lately, so let's fix this! In particular, we have never announced here any
of the development releases of the 2.99 series (the unstable versions meant
to become GIMP 3 later on) even though this is actually the third one!

* GIMP 2.99.2 (2020-11-06):
https://www.gimp.org/news/2020/11/06/gimp-2-99-2-released/
* GIMP 2.99.4 (2020-12-25):
https://www.gimp.org/news/2020/12/25/gimp-2-99-4-released/
* GIMP 2.99.6 (today):
https://www.gimp.org/news/2021/05/08/gimp-2-99-6-released/

Note about the release dates: some people may have noticed that versions
are tagged earlier in the git repository, because we now wait for at least
the Windows installer or macOS DMG before announcing a new version, and for
mirrors to sync up. In GIMP 2.99.6 case, we are even 11 days late, but such
is life! It is nicer not to announce something most people cannot test.
Though our flatpak (Linux) package is always timely distributed a few hours
after version tagging.

For a list of the changes, with nice text and screenshots, please refer to
the relevant news link above, on our website. For a more complete list of
changes since GIMP 2.99.6, please see the "Changes" section below.

Happy GIMPing,

Jehan and the GIMP team!

Download


  GIMP 2.99.6 is available from:

  https://download.gimp.org/mirror/pub/gimp/v2.99/

  and from the mirrors listed at:

  https://www.gimp.org/downloads/devel/#mirrors

  The sha256 and sha512 checksums of the tarball are:

8d264b28445a3df2b940f30ee0b89b469255e975e8563b889fd57fb2f58f66a0
 gimp-2.99.6.tar.bz2

51ada696693ac51624ba222d1fff54d39bdc72a06de54f7c244b89740b77f7205aab44f1cec90785ca4196cab32f817e7390b4287a30f5024606163f24222961
 gimp-2.99.6.tar.bz2

Overview of Changes from GIMP 2.99.4 to GIMP 2.99.6
===

Core:

  - Various fixes for Wayland support.
  - Canvas Size dialog now displays a template selector to simply
resize the canvas to a known template. When the image's and
template's pixel density don't match, a choice will be proposed to
set the image's PPI to the template's one or to scale the template's
pixel size with the image's pixel density.
  - Off-canvas guides are now allowed. Guides are not deleted anymore
when dropped off-canvas, but when dropped off-viewport.
  - Pinch gesture is now possible on canvas for zooming in/out (works on
Wayland, not on X11; untested yet on *BSD, macOS, Windows and
others).
  - GimpAction core class now stores a reason for explaining being
disabled. This can be used later for giving better hints on why some
effects or plug-ins are not usable in some situations. We already
had this feature, but by tweaking the action's tooltip, which
prevented this to have proper styling on GUIs and disrupted action
search (as the reason text was searched, hence may return actions it
should not).
  - Copy|Cut-Paste could already operate on multiple layers, by merging
the result into a single layer. It will still do this when a
selection exists, yet will paste layers as-is otherwise. This makes
an alternative way to move layers, which is sometimes easier than
drag'n dropping (especially between separate images).

Tools:

  - Paint Select tool got various improvements:
* apply a threshold on the image mask before triggering the
  automatic expansion to simplify mask handling in the gegl
  paint-select operation.
* enable viewport-based local selection.
  - GEGL Operation tool is now moved into Filters > Generic menu because
it behaves more like a generic filter conceptually. As other
filters, the GEGL Operation action is now only active when there are
opened images.

API:

  - The generate "Metadata" frame layout in a GimpSaveProcedureDialog
has been improved to always show the same number of columns to avoid
ugly layout with options on 3 columns, then 2 columns on the next
line (for instance).
  - The "Reset" button in GimpProcedureDialog shows a down arrow to show
this is actually a button menu.
  - "Save|Load Defaults" in GimpProcedureDialog are renamed as "Save
Settings" and "Load Saved Settings". The term "defaults" was not
very clear and could be confused with "factory defaults". Moreover
tooltips were added and the "Load Defaults" button is now only
sensitive if "Save Defaults" buttion has been hit at least once.
  - Annotations improved.
  - Drop g_object_notify() in favor of g_object_notify_by_pspec() in
various implementations to avoid a slight performance hit because of
a global lock.
  - New function gimp_parasite_get_data() replacing gimp_parasite_data()
and gimp_parasite_data_size() in a GObject Introspection friendly
way.
  - gimp_procedure_dialog_new() now allows a NULL title if a menu label
was set on the GimpProcedure with gimp_procedure_set_menu_label().
  - 

Re: [Gimp-developer] creating a mac dmg for 2.99

[Jehan Pagès via gimp-developer-list]

Hi!

On Sat, Feb 6, 2021 at 11:39 PM Aleph Mage  wrote:

> Hello all,
>
> I’m interested in compiling the dev branch code and becoming the hosting
> developer for the eventual 3.0 release of the Gimp for Mac.
>
>
> I need to understand the steps for creating this as they have been in the
> past. What pitfalls should I look out for?
>
> Please advise / point in the right direction
>

The build scripts are readable at these 2 repositories:
https://gitlab.gnome.org/Infrastructure/gimp-macos-build
https://gitlab.gnome.org/samm-git/gtk-osx/

Builds happen automatically on Circle-CI servers (with public logs for
everyone to review). The process is explained in the gimp-macos-build
repository.

Current maintainers for the macOS build are Oleksii Samorukov (who created
the process but lacks time lately) and more recently Des McGuinness.

So I would suggest to first have a look at the scripts. Then you are
welcome to propose some patches to work on a build for the dev version too,
which would indeed be very nice. I'm not 100% sure, but I don't think that
Des has had the time to look into it as he focused on getting the stable
version up to speed first. Anyway more devs the merrier.

Something which can be done is to set up a branch for you and we will let
you merge test commits on this branch for you to get acquainted with the
build system and have automatic CI builds (while not merging tests into the
main branch). If you are interested, please tell me (on a report or on IRC
for instance).

Jehan


> Thank you.
> ___
> gimp-developer-list mailing list
> List address:gimp-developer-list@gnome.org
> 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:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list

Re: [Gimp-developer] Translating Gimp into arabic

[Jehan Pagès via gimp-developer-list]

Hi!

On Thu, Feb 4, 2021 at 5:52 PM Ofnuts via gimp-developer-list <
gimp-developer-list@gnome.org> wrote:

> Gimp already has Arabic translations. Do you have something specific in
> mind?
>

It's true there is Arabic translation, but according to the stats, far from
complete (68% on stable branch and 47% on dev branch). Anyway we always
welcome more contributors. 

On 03/02/2021 09:41, Abdullah OLABI wrote:
> > I would like please to talk to someone in your organisation about
> > translating Gimp into Arabic language.
>

Basically translations are handled by the GNOME localization teams and you
have to contact directly your locale team to participate. For Arabic in
particular, here are the contact information:
https://l10n.gnome.org/teams/ar/

Have a good morning/day/evening, and hoping to see your new translations
soon! 

Jehan


> With kind regards
> >
> > Abdullah Olabi
> >
> > ___
> > gimp-developer-list mailing list
> > List address:gimp-developer-list@gnome.org
> > List membership:
> > https://mail.gnome.org/mailman/listinfo/gimp-developer-list
> > List archives: https://mail.gnome.org/archives/gimp-developer-list
>
>
> ___
> gimp-developer-list mailing list
> List address:gimp-developer-list@gnome.org
> 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:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list

Re: [Gimp-developer] GIMP-2.10 and GIMP2.99 are still sRGB-only image editors

[Jehan Pagès via gimp-developer-list]

Hi!

On Fri, Feb 5, 2021 at 1:00 AM Elle Stone 
wrote:

> A misconception I keep seeing on various forums needs to be corrected:
>
> GIMP-2.10 does *NOT* produce correct editing results in color spaces
> other than sRGB. Neither does GIMP-2.99.
>
> Editing in AdobeRGB, ProPhotoRGB, Rec2020, etc WILL produce *wrong*
> results for many operations, and unless you are thoroughly conversant
> with the underlying code, or else have a way to compare results with a
> properly color-managed editing application, you don't have any way to
> know what's right and what's wrong. It's best to stick with editing only
> in GIMP's built-in sRGB color spaces.
>
> The same is true if you are using GIMP-2.99: Some things that don't work
> in GIMP-2.10, do work in GIMP-2.99. Other things that actually do work
> in GIMP-2.10, don't work in GIMP-2.99.
>
> About two years ago major changes were made in babl and additional
> changes were made in GIMP-2.99, messing up stuff that still works in
> GIMP-2.10. For awhile progress was being made in GIMP-2.99 on extending
> the arena of "what actually works", some of which progress is from bug
> reports I filed and in some cases helped to fix - it seems nobody else
> was testing the new code to see what actually did work.
>
> I was able to write code that fixed some of the bugs I reported for
> GIMP-2.99 color management. But once I reached the point where further
> coding requirements exceeded my coding ability, progress simply stopped,
> with everyone else saying "some day" proper color management for GIMP
> would be a priority. I began to feel like the best way to make sure a
> bug would never get fixed, was to have the dreaded "Concepts: Color
> Science" tag attached to it.
>
> Since autumm of 2013 I've been participating in GIMP development, mostly
> in the area of color management (editing in color spaces other than
> sRGB) and color science (making sure GIMP code produces correct results
> for things like layer blend modes, Curves and Levels, AutoStretch,
> Luminance, and so on; and adding code for things like LCh color pickers
> and blend modes).
>
> Participating in GIMP development used to be challenging and enjoyable.
> But over the last couple of years my interest in and patience with the
> slow pace of progress regarding GIMP color management have dwindled to
> the point of disappearing altogether.
>
> If someone else feels like helping with GIMP color management and color
> science, here's a list of still-open bug reports that I reported after
> the migration to gitlab, most of which have to do with color
> management/color science:
>
>
> https://gitlab.gnome.org/GNOME/gimp/-/issues?scope=all=%E2%9C%93=opened_username=ellestone
>
> Here are bugs that I opened before the migration to gitlab:
>
> https://gitlab.gnome.org/GNOME/gimp/-/issues?scope=all=%E2%9C%93=opened_username=bugzilla-migration=ellestone
>
> The most important color management bugs still open from before the
> migration to gitlab are these:
>
> * Replace hard-coded sRGB parameters to allow editing in other RGB
> working spaces (opened 6 years ago):
> https://gitlab.gnome.org/GNOME/gimp/-/issues/594 - in some ways this bug
> is obsolete as current GIMP color management issues are less about
> actual hard-coded values and more about a lack of any way to convey the
> required "not sRGB" color space information to various sections of code
> that need this information.
>
> * Decomposed to LAB images have the wrong ICC profile assigned (opened 4
> years ago): https://gitlab.gnome.org/GNOME/gimp/-/issues/883
>
> * Address various limitations of LCMS soft proofing (opened 4 years
> ago): https://gitlab.gnome.org/GNOME/gimp/-/issues/976
> the
> and hoping very much that GIMP will find new developers that them a lot
> of energy and some interest and expertise in color management and color
> science.
> * Support for high bit depth RGB (and LCH?) color palettes for painting
> (opened 2 years ago): https://gitlab.gnome.org/GNOME/gimp/-/issues/1328
>
> Similar searchs in https://gitlab.gnome.org/GNOME/gegl/ and
> https://gitlab.gnome.org/GNOME/babl/ will turn up a few additional color
> management issues.
>
> Best of luck to all,
>

So it feels like you are saying goodbye.
If so I hope it's only a temporary one and you'd be back if we get more
active on the color management side. We will, we definitely will, because
it's a major part of what GIMP 3 is supposed to be about anyway.

I personally have a high theoretical interest on this topic, but not a
practical one unfortunately (because we work in sRGB), which is why it is
both high in priority for me (because we need it for GIMP 3) and low
(compared to what we actually do day to day with GIMP). I have always been
hoping that Mitch and Ell would be back soon as they are much better suited
than me to decide on these topics anyway IMO. These are actually very
intimidating topics. I do understand them (or so I believe), when
scratching the head very hard, but I feel much 

Re: [Gimp-developer] Discuss backward compatibility for multilayer changes to v3 PDB API

[Jehan Pagès via gimp-developer-list]

Hi!

On Sun, Feb 7, 2021 at 5:59 PM Lloyd Konneker via gimp-developer-list <
gimp-developer-list@gnome.org> wrote:

> The v3 PDB API has changes for multilayer capability.
> For example this signature change: gimp-edit-copy(drawable) =>
> gimp-edit-copy(drawableArray).
> This breaks some scripts in the GIMP repository and some third party
> plugins.
>
> To provide backward compatibility means allow existing scripts to work for
> a defined period.
> (say from 2.99 until 3.1).
>

Just for the record, there are no such versions: 2.99 and 3.1. Or to be
accurate, these are dev versions, they don't "count". Whatever is in 2.99
and whatever will be in 3.1 doesn't matter but for testing. We don't mind
too much broken stuff in these (we obviously prefer non-broken stuff, but
this won't stop us from releasing something for people to test the rest,
i.e. what is not broken).

As for API in particular, it means that API compatibility is a non-existent
concept there. We are heavily testing. The API may end up broken even
between 2 micro releases (like 2.99.4 to 2.99.6). This is what these
versions are for. What matters is only that we get the right API for GIMP
3.0.

That allows users time to adjust their scripts.
>

It had been decided long ago that the API could break for our GIMP 3.0
release. I mean, the multi-layer related functions you give are only the
tip of the iceberg. There are so many more changed functions, and in
particular all the base API for plug-ins are changed anyway. Now the old
base API don't even exist anymore. So anyway all plug-ins will have to be
updated. It's not even an "if" anymore, and it's not even related to
multi-layer selection (even without this, all plug-ins will have to be
updated).

I mean, it's already too late. We have not just started or anything. This
work on base API changes started more than 2 years ago (after we released
GIMP 2.10.0) and reverting this (losing 2+ years of work by several people
and using probably just as much to bring compatibility back) is not an
option as far as I'm concerned!


> If we don't provide backward compatibility, it is a logistics problem:
> third party script authors must prepare an updated copy of their scripts,
> and change over immediately when they change from 2.10 to 3.0.
>

Which is also why we have started to talk about this long before, made news
about this on GIMP website and we started to release dev versions. The
current dev API is unstable (as already said), but it's still close to what
will be released as stable. So plug-in developers are very welcome to start
porting. Whatever will change between now and finale stable GIMP 3.0 likely
won't be as much as what already changed between 2.10 and current dev
version.

We also plan to document the main changes, with porting docs, tutorial and
whatnot.
And also we hope to have the new extension platform by the time we release
GIMP 3, to help people port their plug-ins and upload them.

In the end, the change won't be so complicated. It may look scary, but in
the end, I don't think even the most complicated plug-ins will need much
more than 30 min to be ported. Ok maybe 1hour if rlly you made a
hugely complicated plug-in, I don't know. Talking from experience of having
participated to port many of our core plug-ins.


> Some scripts in GIMP 2.99 are broken now since the API was changed but
> scripts were not updated.
> If we provide backward compatibility,
> the GIMP developers can fix the scripts in the repository at their leisure.
>

Are you talking about third-party scripts or the ones we provide? If the
core ones, of course we should port them before release. But not providing
a compatibility layer again. As said, GIMP 3 is our chance to improve our
API, 25 years of cruft, 25 years of evolution, new features, new usages, so
many things different. The goal is not to continue with double the mess.
Like if we talk about multi-layer related API, what? Do we want to propose
every layer API in double now? Both multi and single layer? Then do the
same when we finally make vectors and channels multi-selectable?

I'm not saying what you say is wrong. Of course, in an ideal setup, we try
to never break any past API. But in this ideal setup, we are more than a
handful of contributors. Right now, trying to do what you propose would be
like releasing GIMP 3.0 in 5 years. I don't think anyone wants this.

So yeah this is why we just decided long ago that API breakage was allowed
as it was a major version update. We don't do useless API breakage, but for
stuff like multi-layer selection, this just makes sense. It will be a new
ability of GIMP 3. Nobody wants our API not to be able to access this
feature. And we don't want to maintain double the functions.


> Because the name has stayed the same but the signature changed,
> to provide backward compatibility could be considered
> a problem of overloaded functions.
>
> One backward compatible solution is to implement overloading in scriptfu:
> 

Re: [Gimp-developer] meson build with pdbgen

[Jehan Pagès via gimp-developer-list]

Hi,

On Mon, Dec 28, 2020 at 2:11 PM Lloyd Konneker via gimp-developer-list <
gimp-developer-list@gnome.org> wrote:

> Is there a build option for the meson build similar to the --with-pdbgen
> for the automake AM build?
>
> I am hacking at PDB procedures.  The meson build doesn't seem to generate
> code using the PDBGEN tool (from the source in the pdb/groups directory.)
> There is no mention of "pdb" in the meson_options.txt file.
>

Yes. It's one of the many issues we currently have with the meson build.
See: https://gitlab.gnome.org/GNOME/gimp/-/issues/4201


> If not, I will open an issue.  Without the option, the meson build cannot
> entirely replace the automake build.
>

Which is why the meson build is absolutely not replacing the autotools one
so far. We still officially ask people to use autotools (in the context of
a final build, like packaging; developers who want to contribute are
obviously welcome to use meson so that they can contribute to fix the
build).

It is far from being the only issue:
https://gitlab.gnome.org/GNOME/gimp/-/issues?scope=all=%E2%9C%93=opened_name[]=Build%3Ameson

Patches welcome.

Jehan

___
> gimp-developer-list mailing list
> List address:gimp-developer-list@gnome.org
> 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:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list

Re: [Gimp-developer] Touchpad gestures for zooming

[Jehan Pagès via gimp-developer-list]

Hi!

On Wed, Dec 2, 2020 at 10:37 AM Alexandre Prokoudine via
gimp-developer-list  wrote:

> On Wed, Dec 2, 2020 at 1:55 AM Povilas Kanapickas wrote:
> >
> > Hello,
> >
> > I would like to implement touchpad gesture support in GIMP. Perhaps the
> > most useful use case is the ability to do pinch gesture to zoom the
> > currently opened image in and out. I would like to focus on just this
> > use case initially.
> >
> > Is this something the team sees as an useful feature?
>
> Hello!
>
> Yes, Jehan Pages experimented with that a few years back but switched
> to other tasks. So that would be a very much welcome feature :)
>

Indeed I focus on more important tasks to us right now so I think none is
working on it. And obviously we would really welcome the feature! 

Jehan


> Alex
> ___
> gimp-developer-list mailing list
> List address:gimp-developer-list@gnome.org
> 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:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list

Re: [Gimp-developer] where can I see this string in action (translation related)

[Jehan Pagès via gimp-developer-list]

Hi!

On Thu, Oct 15, 2020 at 12:37 PM Cristian Secară  wrote:

> Where or how can I see this string in action:
>
> #: ../libgimp/gimpexport.c:444
> #, c-format
> msgid "%s plug-in needs to crop the layers to the image bounds"
>
> ?
>

If not mistaken, these are labels shown on an intermediate export dialog
(back from a day where export had a 3-dialog workflow: choose path, then
this dialog, then the format options dialog; now it has a 2-dialog
workflow). This intermediate dialog is not shown anymore (now the export
code automatically does what it says here, which is not a problem as it
doesn't actually modify the image but a copy of it), but the code is still
there in our codebase lurking (this change is before my time, so before
2012, I don't know when exactly).

Someday we might want to do something about it (anyway I have big plans for
the export process, though I'm not sure when I'll get there). In the
meantime, I'd suggest to just translate to what it seems to mean, it won't
matter much anyway as none will see it. So don't bother too much.

Jehan

P.S.: there is actually an environment variable you can set to force the
intermediate dialog to appear. I can look it up if ever you really want to
see the strings on GUI.


>
> --
> Cristian Secară
> https://www.secarica.ro
> ___
> gimp-developer-list mailing list
> List address:gimp-developer-list@gnome.org
> 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:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list

Re: [Gimp-developer] Offering help

[Jehan Pagès via gimp-developer-list]

Hello!

So you are a Windows developer, Vrok? If so, awesome, it's really needed!

On Fri, Oct 9, 2020 at 12:39 PM Alexandre Prokoudine via
gimp-developer-list  wrote:

> Hello Vrok!
>
> Our onboarding procedure could do with some improvement indeed :)
>
> I guess the first step would be building GIMP from source code. We
> typically do it n Linux with Mingw, but I know there's some work going
> on to try doing this with MSYS2. At least that's my impression from
> quick glances on our IRC channel.
>

Actually Wormnest (our current Windows dev boss!) says he builds from MSYS2
from Windows. The ones who cross-build from Linux are the Linux devs (like
myself!) who can't bother to set up a full development environment on
Windows. 

So yeah it should work with both methods.
Though building GIMP 2.10 natively from Windows is apparently a real pain
(because autotools are very slow natively on Windows), but master branch
with meson should be much easier. At least that's what I hear.


> As for actual development, we usually recommend accomplishing a simple
> task that really excites you, something you want to see fixed in GIMP.
> If all else fails, there's a 'Newcomers' label for issues that are
> simple enough to get started contributing:
>
> https://gitlab.gnome.org/GNOME/gimp/-/issues?label_name%5B%5D=4.+Newcomers


Yes, the best is really if you find yourself issues you had with GIMP and
try to fix them. All current long-term GIMP developers started like this.
We encountered a bug and dealt with it. It can be something very basic. It
is much more enjoyable when you actually work for yourself than just for
the sake of it. 

Also I would suggest to come and discuss on IRC (#gimp on irc.gimp.org).
This makes things more enjoyable for you than just dropping patches (at
least I think, personally).

Jehan


>
> Please don't hesitate asking questions :)
>
> Alex
>
> On Fri, Oct 9, 2020 at 1:26 PM Tan Vrok Fei via gimp-developer-list
>  wrote:
> >
> > Hello,
> >
> > I’m Vrok, and I would like to help out with developing and introducing
> new features to GIMP. However, I don’t know where to start.
> >
> > Any guidance on where to begin is welcome. Thank you.
> >
> > Regards,
> > Vrok
> >
> > Sent from Mail for
> Windows 10
> >
> > ___
> > gimp-developer-list mailing list
> > List address:gimp-developer-list@gnome.org
> > List membership:
> https://mail.gnome.org/mailman/listinfo/gimp-developer-list
> > List archives:   https://mail.gnome.org/archives/gimp-developer-list
> ___
> gimp-developer-list mailing list
> List address:gimp-developer-list@gnome.org
> 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:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list

Re: [Gimp-developer] VPAT request

[Jehan Pagès via gimp-developer-list]

Hello Peter,

On Fri, Sep 4, 2020 at 5:18 PM Godswill Peter via gimp-developer-list <
gimp-developer-list@gnome.org> wrote:

> Good afternoon;
>
> My name is Godswill Peter and I work for the Texas A University
> Engineering and Experiment Station as a student assistant, I hope this
> email finds you well. I am emailing you to request the VPAT for your
> software (GIMP 2.10.20 (Latest) version), as it is required that all
> software we use here at Texas A University has their own VPAT. Please get
> back to me as soon as possible.
>

Alexandre sent you the VPAT earlier. I hope you got it well.

May I ask about your usage of GIMP in Texas A University? This is
interesting to know some use cases in universities (courses? Projects? Just
installed by default on computers for students to use? Something else?).

Thanks!

Jehan
GIMP team


> Cheers,
>
> Godswill Peter
>
> Student Assistant
>
> Texas A University Engineering and Experiment Station
>
> Suite 102
> ___
> gimp-developer-list mailing list
> List address:gimp-developer-list@gnome.org
> 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:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list

Re: [Gimp-developer] missing strings for translation (GIMP 2.10.x)

[Jehan Pagès via gimp-developer-list]

Hi!

On Wed, Jun 3, 2020 at 6:12 PM Cristian Secară  wrote:

> I cannot find these strings for translation:
>
> 1. Go to Preferences -> Toolbox -> (checkbox) Show GIMP _logo
> (drag-and-drop target) -> (tooltip) Show the GIMP mascot at the top of the
> toolbox.

The tooltip is missing for translation.
>

Indeed. Added.


> 2. Go to Preferences -> Input devices -> click on Configure extended input
> devices... -> Core Pointer
> "Core Pointer" is missing for translation.
>

Unless mistaken, we don't have this string in GIMP itself. As this is part
of the list of devices, I think it is returned by one of the other layers
of the system. I have not investigated much to see which layer it is, but
this is this one which should return localized strings if adequate.


> Also the "X tilt" and "Y tilt" are missing, which are parameters for "%s
> Curve" (this one is ok).
>
> ?
>

Indeed. They were actually translatable/translated, but only when shown
alone (in the "Axes" list). I have made these to be also translated when
used in the  "%s Curve" and "The axis '%s' has no curve" context.

Thanks for noticing.
If I may, next time though, I'd suggest to open a bug report:
https://gitlab.gnome.org/GNOME/gimp/-/issues

Otherwise your reports might end up forgotten if we don't process them
immediately (for this one, we got lucky).
Thanks again.

Jehan

P.S.: commit:

commit 4c081730255d33418a7402413d3b9a4ae4bcda0f (HEAD -> gimp-2-10,
origin/gimp-2-10)
Author: Jehan 
Date:   Tue Jun 9 10:58:28 2020 +0200

app: make a tooltip translatable and translate device axis strings.

Thanks to Cristian Secară on the developer mailing list to notice them.

(cherry picked from commit 5302beb9471e67d3c4e124d7c20c93ddb5efd9f1)

 app/config/gimprc-blurbs.h | 2 +-
 app/widgets/gimpdeviceinfoeditor.c | 4 ++--
 2 files changed, 3 insertions(+), 3 deletions(-)



> Cristi
>
> --
> Cristian Secară
> https://www.secarica.ro
> ___
> gimp-developer-list mailing list
> List address:gimp-developer-list@gnome.org
> 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:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list

Re: [Gimp-developer] feature request: forget about the goat (somewhat translation related)

[Jehan Pagès via gimp-developer-list]

Hi!

On Sat, May 23, 2020 at 6:43 PM Cristian Secară  wrote:

> În data de Fri, 22 May 2020 01:51:43 +0200, Jehan Pagès a scris:
>
> > [...]
> > Basically in the future, this plug-in will be a looot more
> > interesting, self-explanatory and better labelled.
>
> Hopefully ...
>
> > [...]
> > Are you asking this as one of the translators of GIMP?
>
> Yes (for Romanian)
>
> > Now I agree that the plug-in is not self-explanatory enough in GIMP
> > 2.10.x and I understand that people will wonder what this filter is
> > exactly. [...] This is passed, it has been like this
> > for 2 years already, nobody ever complains of it (and if they don't
> > get it, a simple web search or asking on a forum like in your link
> > and they can get their answer), [...]
>
> What relevant answer can one get by searching (without quotes) "gimp
> promener une chèvre" ? Or "gimp esercizio per capre" ? Or "gimp
> Потренировать козу" ? Or "gimp ejercitar una cabra" ? And so on. At most
> they will only find references to the corresponding msgstr source code for
> their language.
>

Yes, as you say, it's a joke with the GEGL mascot being a goat. The name is
indeed not very relevant. This plug-in being now in a "development > Goat
exercises" subsection and the new dialog clearly saying that it is a
demo/exercise plug-in for plug-in developer is the relevant part. In the
future version, there should not be any ambiguosity anymore of what these
are, even with the funny name.

Now it's not saying that you are still right that the ambiguosity
definitely remains on GIMP 2.10.x, but then it's only about time management
(and the limits of this time), and this is the only reason why I won't even
look at it in GIMP 2.10, but also why I would still accept patches if
someones wishes to do so.


> > Yet if anyone were to propose some patch to goat invasion, possibly
> > to make it work the same on GIMP 2.10.x as it does now on master
> > (it's not just a simple cherry-pick as we changed the API, but it
> > should not be too hard anyway), I would gladly accept the patch.
>
> Not sure I understand what you mean, but I only complained about the name
> (menu name and its tooltip), not what it actually do (by the way, I don't
> know what this plug-in actually does, except that it's something about a
> work out in conjunction with a goat, but still I didn't understand if the
> work out (the exercise) is done by the owner of the goat, or by the goat
> itself :)
>

Ahah well, I guess both the goat and its friend (rather than owner!) are
doing the workout! ;-)

Joke aside, if I recall, it's just a color invert effect. Not much interest
other than showing how to make plug-ins and how to call GEGL operations
from GIMP plug-in code.

Jehan



> Cristi
>
> --
> Cristian Secară
> https://www.secarica.ro
> ___
> gimp-developer-list mailing list
> List address:gimp-developer-list@gnome.org
> 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:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list

Re: [Gimp-developer] feature request: forget about the goat (somewhat translation related)

[Jehan Pagès via gimp-developer-list]

Hi,

On Sun, May 17, 2020 at 10:44 PM Cristian Secară  wrote:

> Is it possible to change the goat menu item & tooltip to something more
> valuable ?
>

On the master code (future GIMP 3), I made quite some change to the Goat
exercise.

First of all, there are now several goat exercises, one for each binding
which we tested, i.e. so far a C one, a Python, Javascript, Lua and
probably soon a Vala one. Also they are in a menu section called
"Development".

And most importantly, when they run, they don't directly run a GEGL
operation, they first open a dialog with a header label explaining that the
plug-in is a demo demonstrating how to make plug-ins. Under the header
text, there is a text box displaying their own code, and at the top there
are 3 bouttons: Cancel, Source and OK. "OK" runs the filter operation and
"Source" sends to the last version of the plug-in source online (in the
repository).

Basically in the future, this plug-in will be a looot more interesting,
self-explanatory and better labelled.

Right now it makes no sense when translating in any language, except if
> leaving the goat untranslated and put the whole story / pun explanation [1]
> in the tooltip, which doesn't make much sense either.
>

Are you asking this as one of the translators of GIMP?

Including for GIMP 2.10.x...
>

Now I agree that the plug-in is not self-explanatory enough in GIMP 2.10.x
and I understand that people will wonder what this filter is exactly.
Personally I know I don't really want to spend much more time in the
gimp-2-10 series. This is passed, it has been like this for 2 years
already, nobody ever complains of it (and if they don't get it, a simple
web search or asking on a forum like in your link and they can get their
answer), so I think my time much better used to make it better for the
future GIMP 3.

Yet if anyone were to propose some patch to goat invasion, possibly to make
it work the same on GIMP 2.10.x as it does now on master (it's not just a
simple cherry-pick as we changed the API, but it should not be too hard
anyway), I would gladly accept the patch.

Jehan


> Thank you,
> Cristi
>
> [1] http://gimpchat.com/viewtopic.php?f=8=16635
>
> --
> Cristian Secară
> https://www.secarica.ro
> ___
> gimp-developer-list mailing list
> List address:gimp-developer-list@gnome.org
> 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:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list

Re: [Gimp-developer] New asset / extension manager

[Jehan Pagès via gimp-developer-list]

Hi!

On Wed, Jan 8, 2020 at 5:16 PM Michal Vašut  wrote:

> Hey dude, calm down. Where have I written about "throwing your family,
> friends and life under the bus" or "black magic instant coding" ? Why are
> you angry (offended)?
>

I was clearly annoyed, if not indeed a bit offended by the answer (what and
how you said it was not very pleasant, if you read it with a neutral mind,
you should see it), though I was still calm and thought I stayed diplomatic
in my answer. Sorry if this part didn't get through, always hard by writing.

So yeah, no problem, don't worry. I am not angry or anything here. :-)


> Of course I don't know what you're doing. (only what you expose on Gitlab
> or blog)
>
> By priority I meant that Gimp team is pushing new features (that don't
> look like prerequisites for that manager) and that one that I'm looking for
> the most looks freezed (at least from outside). So I assume it's only your
> priority (not priority of the whole team).
>

Yeah we have some team roadmap of things we generically think should go in
this or that version. And there are global dev efforts in these direction
(like GTK+3, non-destructive editing and such). But mostly development is
driven by individual priorities, objectives or even sometimes just "where
they have most fun", on a finer level.

In that case I understand that creating something new (besides bugfixing,
> infrastructure maintenance,...) takes some time. I'm developer myself,
> trust me, I know well how it works.
>
> ✌
>

☮ ;-)

Jehan

️
>
>
>
>
> On Wed, Jan 8, 2020, 11:01 Jehan Pagès  wrote:
>
>> Hi,
>>
>> On Wed, Jan 8, 2020 at 7:10 AM Michal Vašut 
>> wrote:
>>
>>> Ok, so it's not priority...
>>>
>>
>> I re-read my email. Nowhere do I say such thing. I consider this project
>> to be one of my main priorities (I'd say it's easy in the top 10 of the
>> GIMP-related things I want to see happening as soon as possible). Hence I
>> talk about it in posts, I started implementing it and so on. We have been
>> discussing this stuff for years and years. Priority does not mean "black
>> magic instant coding".
>> Not giving deadlines does not mean not priority either.
>>
>> Unless by priority you mean throwing my family, friends and life under
>> the bus to get it done yesterday, because yeah I don't have any of these
>> and won't ever have.
>>
>> It's a pity, I think it would be much more useful and beneficial for Gimp
>>> that other things you guys do. But, it's your choice how you spend your
>>> free time...
>>>
>>
>> How do you know what else I do? I don't think you can decide that this
>> project is more important than any other things I've been doing, sorry. :-)
>>
>> Anyway, thanks for answer a have a successful 2020.
>>>
>>
>> Same for you, have a happy 2020!
>>
>> Jehan
>>
>>
>>> On Tue, Jan 7, 2020, 11:25 Jehan Pagès 
>>> wrote:
>>>
 Hi,

 On Sun, Jan 5, 2020 at 11:37 PM Michal Vašut 
 wrote:

> Hello Jehan, I know you've made some work on new extension manager -
> you've presented some GUI prototypes in the past and I also read about 
> some
> huge backend refactoring, fixes and added support for JS and Lua for
> extension scripting. How far is it? Or better, how close to be released?
> It's without doubt huge task, and I understand how difficult is to work
> with such old codebase and don't mess up something else, so I don't want 
> to
> put any pressure on you. Only thing I want to know is some rough estimate
> when it will be done.1st half of 2020? Second half? Next year?
>

 I'm sorry, we don't do dates. We don't do rough estimates either.

 Things will be done when it's ready, that's it. I haven't taken the
 time to work on this particular feature the last few months as I was doing
 other stuff. I will continue implementing the feature. I can't tell when
 this will happen and when this will be finished. I don't know either.

 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@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list

Re: [Gimp-developer] New asset / extension manager

[Jehan Pagès via gimp-developer-list]

Hi,

On Wed, Jan 8, 2020 at 7:10 AM Michal Vašut  wrote:

> Ok, so it's not priority...
>

I re-read my email. Nowhere do I say such thing. I consider this project to
be one of my main priorities (I'd say it's easy in the top 10 of the
GIMP-related things I want to see happening as soon as possible). Hence I
talk about it in posts, I started implementing it and so on. We have been
discussing this stuff for years and years. Priority does not mean "black
magic instant coding".
Not giving deadlines does not mean not priority either.

Unless by priority you mean throwing my family, friends and life under the
bus to get it done yesterday, because yeah I don't have any of these and
won't ever have.

It's a pity, I think it would be much more useful and beneficial for Gimp
> that other things you guys do. But, it's your choice how you spend your
> free time...
>

How do you know what else I do? I don't think you can decide that this
project is more important than any other things I've been doing, sorry. :-)

Anyway, thanks for answer a have a successful 2020.
>

Same for you, have a happy 2020!

Jehan


> On Tue, Jan 7, 2020, 11:25 Jehan Pagès  wrote:
>
>> Hi,
>>
>> On Sun, Jan 5, 2020 at 11:37 PM Michal Vašut 
>> wrote:
>>
>>> Hello Jehan, I know you've made some work on new extension manager -
>>> you've presented some GUI prototypes in the past and I also read about some
>>> huge backend refactoring, fixes and added support for JS and Lua for
>>> extension scripting. How far is it? Or better, how close to be released?
>>> It's without doubt huge task, and I understand how difficult is to work
>>> with such old codebase and don't mess up something else, so I don't want to
>>> put any pressure on you. Only thing I want to know is some rough estimate
>>> when it will be done.1st half of 2020? Second half? Next year?
>>>
>>
>> I'm sorry, we don't do dates. We don't do rough estimates either.
>>
>> Things will be done when it's ready, that's it. I haven't taken the time
>> to work on this particular feature the last few months as I was doing other
>> stuff. I will continue implementing the feature. I can't tell when this
>> will happen and when this will be finished. I don't know either.
>>
>> 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@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list

Re: [Gimp-developer] New asset / extension manager

[Jehan Pagès via gimp-developer-list]

Hi,

On Sun, Jan 5, 2020 at 11:37 PM Michal Vašut  wrote:

> Hello Jehan, I know you've made some work on new extension manager -
> you've presented some GUI prototypes in the past and I also read about some
> huge backend refactoring, fixes and added support for JS and Lua for
> extension scripting. How far is it? Or better, how close to be released?
> It's without doubt huge task, and I understand how difficult is to work
> with such old codebase and don't mess up something else, so I don't want to
> put any pressure on you. Only thing I want to know is some rough estimate
> when it will be done.1st half of 2020? Second half? Next year?
>

I'm sorry, we don't do dates. We don't do rough estimates either.

Things will be done when it's ready, that's it. I haven't taken the time to
work on this particular feature the last few months as I was doing other
stuff. I will continue implementing the feature. I can't tell when this
will happen and when this will be finished. I don't know either.

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:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list

Re: [Gimp-developer] Python2.7 reaches end of life

[Jehan Pagès via gimp-developer-list]

Hi all!

> Since Python 2.7 reaches end of life (in a week), what is the roadmap  of
switching to Python3?

We are already using Python3 on master, as Elad said. Don't expect anything
to happen for the GIMP 2.10.x branch (which will continue to use Python 2,
even though deprecated, and so be it). Not because we don't want it, but
because we don't have the people to work on this. Also we can't just
invalidate all existing Python 2 plug-ins.

> As far as I understand, Jehan is coordinating it.

Just to make things clear, I coordinate as far as I was the only one
working on Python 3 port, and I am the one who initially ported libgimp* to
GObject Introspection. But I am happy if anyone decides to go all the way
out and take some responsibilities. ;-)

> I also understand that mitch created new methods for plugins for UI, and
I am not sure whether I am supposed to use them or not.

You are welcome to use any existing API. Or propose improvements and
patches if you feel it's not quite right yet. Until GIMP 3 is released,
even can change. I would even say that everything *should* change now if it
has to (after release, it will be too late as we will have to keep
compatibility for years to come).

> Personally, I am a bit stuck on creating UI for the plugins.

There is also the possibility to just create GUI the GTK+ way, manually by
calls to Gtk.* functions, widgets creation and whatnot. This is what C
plug-ins do. No reason we don't do it for Python ones too until we get
proper GUI generation.

Alternatively, you may already start porting partially the plug-ins,
without the GUI part for now and we can work on adding the GUI later, on a
second step. Iterative port is better than no port at all.

In any case, thanks for helping Elad. This is useful. I will look at your
patches and review at some point. Don't worry. :-)

Helmut, if you wish to join the fun, we'd be happy! :-)

Jehan


On Sun, Dec 22, 2019 at 6:38 PM Elad Shahar via gimp-developer-list <
gimp-developer-list@gnome.org> wrote:

> Helmut,
>
>  I also opened an issue to talk about porting. Not sure whether an issue,
> or this list is more appropriate.
> https://gitlab.gnome.org/GNOME/gimp/issues/4368
>
> I started porting histogram_export.py , so just avoid that one.
>
> Personally, I am a bit stuck on creating UI for the plugins. There is no
> automatic UI for plugins, like
> there was before.  I also understand that mitch created new methods
> for plugins for UI, and I am not sure whether I am supposed to use them or
> not.
>
>
> On Sun, Dec 22, 2019 at 7:18 PM Elad Shahar  wrote:
>
> > The master branch supports Python3.
> >
> > As far as I understand, Jehan is coordinating it. I volunteered to help a
> > bit.
> > The latest plugin I ported is here, and still waiting for it be reviewed.
> > https://gitlab.gnome.org/GNOME/gimp/issues/4369
> >
> > Elad
> >
> >
> > On Sun, Dec 22, 2019 at 1:54 PM Helmut Jarausch via gimp-developer-list <
> > gimp-developer-list@gnome.org> wrote:
> >
> >> Since Python 2.7 reaches end of life (in a week), what is the roadmap
> >> of switching to Python3?
> >> Is there a Gimp version which supports Python3 already?
> >> Is there a 'repository' where plugins are stored which have been
> >> converted to Python3.
> >> Is there some coordination if I like to help in converting plugins?
> >>
> >> Merry Christmas and a Happy New Year,
> >> Helmut
> >> ___
> >> gimp-developer-list mailing list
> >> List address:gimp-developer-list@gnome.org
> >> List membership:
> >> https://mail.gnome.org/mailman/listinfo/gimp-developer-list
> >> List archives:   https://mail.gnome.org/archives/gimp-developer-list
> >>
> >
> ___
> gimp-developer-list mailing list
> List address:gimp-developer-list@gnome.org
> 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:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list

Re: [Gimp-developer] Participation to GameDev room at FOSDEM

[Jehan Pagès via gimp-developer-list]

Hi!

On Mon, Dec 2, 2019 at 10:12 PM StraToN54 .  wrote:

> Hi Jehan & Alexandre,
>
> Thanks for your answer.
>
No prob.

> I'm sorry there's no funding for coming to FOSDEM. We're all doing this
> pro bono, and FOSDEM doesn't provide any funding either for devrooms.
>
No problem. I thought so. I just had to ask at least, because we are simply
not in a financial situation where we can afford it. Hopefully some day! :-)

> If indeed nobody comes to FOSDEM apart for this devroom, then I totally
> understand if you guys do not wish to spend a trip for so little time.
> Maybe another time, I'm sure we'll have many occasions! :)
>
> Also if you guys come to Rennes, I expect to come to the next occurrence
> of GrafikLabor which I couldn't attend this year. I guess some of you guys
> would be there too?
>
I have never been but we might go some day. Not sure if this will happen
the coming year though. So far LGM is the only public event we really try
to be at every year (unless some thing were to occur, but personally I
managed for the last 6 years).

See you hopefully at one of these events!

Jehan


> All the best,
> Julian Murgia - Godot Engine
>
>
> Le 01/12/2019 à 00:56, Jehan Pagès a écrit :
>
> Hi Julian (and other Godot devs)!
>
> On Sat, Nov 30, 2019 at 11:01 PM Alexandre Prokoudine via
> gimp-developer-list  wrote:
>
>> Hello Julian!
>>
>> It took a while to ask everyone, sorry about that :)
>>
>> Unfortunately, none of us is going to be at FOSDEM in 2020.
>>
>
> After Alexandre told me why he was asking if we go to FOSDEM though, I'd
> like to note that, even though we were not planning to be there, I'm not
> against coming for the weekend if there is any funding (accomodation + trip
> Paris-Brussel).
>
> On Mon, Nov 25, 2019 at 4:14 PM Julian Murgia 
> wrote:
> > Thus, we are calling for participations aimed at Free Softwares projects,
> > involved closely or less closely in game development. These
> participations
> > would consist in technical-oriented presentations during the GameDev
> room:
> > game developers, game engine developers, tools developers are very
> welcome.
>
> Though when I read what you are looking for (technical talks for game
> creation), it's close but not exactly our expertise. On our side, we make
> animation films (https://film.zemarmot.net/
> https://www.instagram.com/zemarmot/ to get an idea, we did this too:
> https://framatube.org/videos/watch/9c9de5e8-0a1e-484a-b099-e80766180a6d
> ), also 2D rather than 3D mostly.
>
> Also is it *developers* oriented? Because I'm not sure what would interest
> you which targets developers. Now maybe we could talk about animating or
> something if it's not only for developers?
>
> I don't know, reading your email and your CFP, I am just a bit unclear if
> we can be a fit there since it seems a lot about talking about one's
> experience about making games. And well… we don't have any (except for
> minor hacks for fun years ago, maybe, but I would not call this experience!
> Ahah) so not sure that's what you are looking for. 
>
> Or maybe we could just do some round table to discuss what people are
> looking for in a 2D image creation tool for game making.
>
> Apart from this, yeah we love hearing that you like using GIMP for game
> creation and we'd love to talk about your usage. And indeed discuss about
> how we can make things nicer both for you and us.
>
> > GIMP is one mandatory tool in game developers toolbox. We'd also be happy
> > to discuss your plans and your needs for GIMP development, and discuss
> > assets workflow and integration into game and game engines.
>
> I have been working on better extension management in GIMP, and when I
> read about asset workflow/integration, I wonder if this cannot go within
> the same plans. Well this would need to be discussed to know exactly what
> you are looking for, I guess!
>
> However, we are up for a meeting in late May during Libre Graphics
>> Meeting, in Rennes, France:
>>
>
> Indeed we should be in LGM, as every year, so this can be a good
> opportunity to meet as well.
>
> As for FOSDEM, I am not against, but as said above, we need
> trip/accomodation paid for at least, and discussing also what kind of talks
> you want (we would not want to be a disappointment or look like a mismatch).
>
> That's it. Have a good weekend and tell us what you think.
> Have fun!
>
> Jehan
> GIMP / ZeMarmot / LILA non-profit
>
>
>>
>> https://libregraphicsmeeting.org/2020/en/index.html
>>
>> How does it sound for you?
>>
>> Alex
>>
>> On Mon, Nov 25, 2019 at 4:14 PM Julian Murgia 
>> wrote:
>> >
>> >  Hello,
>> >
>> > First of all I'm sorry if this was not the right place to send this
>> email,
>> > even though I believe it is addressed mostly to GIMP developers.
>> >
>> > I am a member of Godot Engine's organization team for FOSDEM. We have
>> been
>> > granted with a "Game Developers" room at FOSDEM, taking place in
>> Brussels,
>> > Belgium, on February 1st and 2nd 2020.
>> > Even though we proposed 

Re: [Gimp-developer] Participation to GameDev room at FOSDEM

[Jehan Pagès via gimp-developer-list]

Hi Julian (and other Godot devs)!

On Sat, Nov 30, 2019 at 11:01 PM Alexandre Prokoudine via
gimp-developer-list  wrote:

> Hello Julian!
>
> It took a while to ask everyone, sorry about that :)
>
> Unfortunately, none of us is going to be at FOSDEM in 2020.
>

After Alexandre told me why he was asking if we go to FOSDEM though, I'd
like to note that, even though we were not planning to be there, I'm not
against coming for the weekend if there is any funding (accomodation + trip
Paris-Brussel).

On Mon, Nov 25, 2019 at 4:14 PM Julian Murgia 
wrote:
> Thus, we are calling for participations aimed at Free Softwares projects,
> involved closely or less closely in game development. These participations
> would consist in technical-oriented presentations during the GameDev room:
> game developers, game engine developers, tools developers are very
welcome.

Though when I read what you are looking for (technical talks for game
creation), it's close but not exactly our expertise. On our side, we make
animation films (https://film.zemarmot.net/
https://www.instagram.com/zemarmot/ to get an idea, we did this too:
https://framatube.org/videos/watch/9c9de5e8-0a1e-484a-b099-e80766180a6d ),
also 2D rather than 3D mostly.

Also is it *developers* oriented? Because I'm not sure what would interest
you which targets developers. Now maybe we could talk about animating or
something if it's not only for developers?

I don't know, reading your email and your CFP, I am just a bit unclear if
we can be a fit there since it seems a lot about talking about one's
experience about making games. And well… we don't have any (except for
minor hacks for fun years ago, maybe, but I would not call this experience!
Ahah) so not sure that's what you are looking for. 

Or maybe we could just do some round table to discuss what people are
looking for in a 2D image creation tool for game making.

Apart from this, yeah we love hearing that you like using GIMP for game
creation and we'd love to talk about your usage. And indeed discuss about
how we can make things nicer both for you and us.

> GIMP is one mandatory tool in game developers toolbox. We'd also be happy
> to discuss your plans and your needs for GIMP development, and discuss
> assets workflow and integration into game and game engines.

I have been working on better extension management in GIMP, and when I read
about asset workflow/integration, I wonder if this cannot go within the
same plans. Well this would need to be discussed to know exactly what you
are looking for, I guess!

However, we are up for a meeting in late May during Libre Graphics
> Meeting, in Rennes, France:
>

Indeed we should be in LGM, as every year, so this can be a good
opportunity to meet as well.

As for FOSDEM, I am not against, but as said above, we need
trip/accomodation paid for at least, and discussing also what kind of talks
you want (we would not want to be a disappointment or look like a mismatch).

That's it. Have a good weekend and tell us what you think.
Have fun!

Jehan
GIMP / ZeMarmot / LILA non-profit


>
> https://libregraphicsmeeting.org/2020/en/index.html
>
> How does it sound for you?
>
> Alex
>
> On Mon, Nov 25, 2019 at 4:14 PM Julian Murgia 
> wrote:
> >
> >  Hello,
> >
> > First of all I'm sorry if this was not the right place to send this
> email,
> > even though I believe it is addressed mostly to GIMP developers.
> >
> > I am a member of Godot Engine's organization team for FOSDEM. We have
> been
> > granted with a "Game Developers" room at FOSDEM, taking place in
> Brussels,
> > Belgium, on February 1st and 2nd 2020.
> > Even though we proposed this developers room, it will be about "*Free and
> > Open Source Game Development"* at large and not focused on Godot Engine.
> >
> > Thus, we are calling for participations aimed at Free Softwares projects,
> > involved closely or less closely in game development. These
> participations
> > would consist in technical-oriented presentations during the GameDev
> room:
> > game developers, game engine developers, tools developers are very
> welcome.
> >
> > GIMP is the most used image processing Free Software for almost all
> usages.
> > Our lead developer Juan Linietsky presented a nice tutorial for creating
> > graphics and textures using GIMP last year during our Godot Engine annual
> > convention (
> >
> https://www.youtube.com/watch?v=wrGLIt322jM=PLeG_dAglpVo5XPsWqBiXXg6wvee11yDeS
> ).
> > GIMP is one mandatory tool in game developers toolbox. We'd also be happy
> > to discuss your plans and your needs for GIMP development, and discuss
> > assets workflow and integration into game and game engines.
> >
> > You'll find some details on our past news post:
> > https://godotengine.org/article/cfp-game-development-room-fosdem-2020.
> If
> > you wish, you can of course respond to this mail for more precisions
> before
> > applying on FOSDEM's Pentabarf.
> >
> > Waiting for your reply,
> >
> > Best regards,
> > Julian Murgia - Godot Engine
> > 

Re: [Gimp-developer] Doing without pygtk ?

[Jehan Pagès via gimp-developer-list]

Hi!

On Sun, Aug 4, 2019 at 10:32 PM Ken Moffat via gimp-developer-list <
gimp-developer-list@gnome.org> wrote:

> On Sun, Aug 04, 2019 at 08:18:26PM +0100, Ken Moffat via
> gimp-developer-list wrote:
> > Everyone knows that python2 is reaching end of life, but until now
> > pygtk-2 (which seems to be unmaintained) has continued to build.
> > But now pango is under more-active maintenance, and using harfbuzz
> > (which is a good thing).  Unfortunately, as part of the changes in
> > pango-1.44 to move to hb, a _lot_ of things from pango headers have
> > moved into private headers which do not get installed.
> >
> > At the risk of offending people who want to use python2 with gimp:
> > is it practical to build gimp-2.10 without pygtk-2 ?
>
>
Is it a question because it is actually going to be impossible to have
pygtk in some distributions in a close future?
If so, which distribution, and for when?


>
> Builds fine with --disable-python.  Whether all users will find it
> usable is a different matter ;-)
>

Yeah Python has always been an option but it is also a very important
feature of GIMP. People will not be happy if their scripts suddenly stop
working.

This being said, we already dropped pygtk in the master branch (future Gimp
3), which now uses GObject Introspection for Python support (both 2 and 3)
and much more (we tested with success already JavaScript and Lua too, and
someone is working on Vala if not mistaken).

Now when will GIMP 3 be released? Nobody can say. We'd really like GIMP
2.10 to keep Python 2 support for as long as possible.

Jehan


>
> ĸen
> --
> One pill makes you larger, And one pill makes you small.
> And the ones that mother gives you, Don't do anything at all.
> Go ask Alice, When she's ten feet tall.
>-- Jefferson Airplane, White Rabbit
> ___
> gimp-developer-list mailing list
> List address:gimp-developer-list@gnome.org
> 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:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list

Re: [Gimp-developer] Forwarding bugfix release request we received on GNOME board list

[Jehan Pagès via gimp-developer-list]

Hi Philip!

On Thu, Apr 4, 2019 at 11:53 PM  wrote:

> Hi Jehan,
>
> Thanks. I'm glad to hear you have been in contact with this contributor.
>
> Just to avoid any confusion, I have no comments on the GIMP release
> schedule and no wish to interfere :-) I just wanted to make sure that the
> contributor's message got to the right person, since it's better that they
> discuss a possible release with you and not the GNOME board.
>

Of course. No problem there. ;-)
Have fun and a good upcoming week-end!

Jehan


> Thanks,
> Philip
>
> On Sat, Mar 30, 2019, 17:57 Jehan Pagès, 
> wrote:
>
>> Hello Philip,
>>
>> We are in contact with this person (since this team does indeed the
>> Marathi translation, and I even helped them to get started as there was no
>> active Marathi coordinator so their initial contributions were stuck) and
>> were even aware of this specific request for a release (dating from January
>> as your email shows).
>>
>> Back in January, I told Dr. Snehalata Shirude that we were hoping to do a
>> release soon, which unfortunately didn't happen in the end for various
>> reasons. We are still planning a release very very soon, though I cannot
>> say an exact date (same as I couldn't back then).
>>
>> In any case, I am sorry to tell we cannot answer to requests for release.
>> It's done when it's done. Such is the saying. :-)
>>
>> I am the first to hope we could have even more releases (though I don't
>> think we are too bad with 5 release since last April). Yet things are so
>> that we don't have the resources, neither have we the intention to speed up
>> things just because a university (or anyone/anything) uses GIMP, even
>> though it is very cool. I'm sure you understand as I doubt that GNOME would
>> speed up its release as well if it were to receive the same request, right?
>> :-)
>>
>> Still thanks for relaying.
>> Have a good Sunday!
>>
>> Jehan
>>
>>
>> On Wed, Mar 27, 2019 at 7:06 PM philip.chimento--- via
>> gimp-developer-list  wrote:
>>
>>> Hi GIMP developers!
>>>
>>> On the GNOME board list we received a request from a university that is
>>> using GIMP to teach a course. They would appreciate a bugfix release with
>>> updated Marathi translations that, as far as I could tell from looking at
>>> the commit log, have already been contributed by the requester and
>>> committed.
>>>
>>> I don't know what your release schedule is, and I would not presume to
>>> interfere in it, but I would just like to make you aware of the request.
>>>
>>> Best regards,
>>> Philip Chimento
>>> GNOME Board of Directors
>>>
>>> -- Forwarded message -
>>> From: Snehalata Shirude 
>>> Date: Thu, Jan 10, 2019 at 10:50 PM
>>> Subject: Invitation ...
>>> To: 
>>> [...]
>>> Further it is very kind request to you to please release the GIMP with
>>> new
>>> translations of Marathi before start of our course. This will allow
>>> participants of the course to download the GIMP and use it for practice
>>> in
>>> Marathi on their machines easily.
>>> [...]
>>> ___
>>> gimp-developer-list mailing list
>>> List address:gimp-developer-list@gnome.org
>>> 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:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list

Re: [Gimp-developer] Forwarding bugfix release request we received on GNOME board list

[Jehan Pagès via gimp-developer-list]

Hello Philip,

We are in contact with this person (since this team does indeed the Marathi
translation, and I even helped them to get started as there was no active
Marathi coordinator so their initial contributions were stuck) and were
even aware of this specific request for a release (dating from January as
your email shows).

Back in January, I told Dr. Snehalata Shirude that we were hoping to do a
release soon, which unfortunately didn't happen in the end for various
reasons. We are still planning a release very very soon, though I cannot
say an exact date (same as I couldn't back then).

In any case, I am sorry to tell we cannot answer to requests for release.
It's done when it's done. Such is the saying. :-)

I am the first to hope we could have even more releases (though I don't
think we are too bad with 5 release since last April). Yet things are so
that we don't have the resources, neither have we the intention to speed up
things just because a university (or anyone/anything) uses GIMP, even
though it is very cool. I'm sure you understand as I doubt that GNOME would
speed up its release as well if it were to receive the same request, right?
:-)

Still thanks for relaying.
Have a good Sunday!

Jehan


On Wed, Mar 27, 2019 at 7:06 PM philip.chimento--- via gimp-developer-list <
gimp-developer-list@gnome.org> wrote:

> Hi GIMP developers!
>
> On the GNOME board list we received a request from a university that is
> using GIMP to teach a course. They would appreciate a bugfix release with
> updated Marathi translations that, as far as I could tell from looking at
> the commit log, have already been contributed by the requester and
> committed.
>
> I don't know what your release schedule is, and I would not presume to
> interfere in it, but I would just like to make you aware of the request.
>
> Best regards,
> Philip Chimento
> GNOME Board of Directors
>
> -- Forwarded message -
> From: Snehalata Shirude 
> Date: Thu, Jan 10, 2019 at 10:50 PM
> Subject: Invitation ...
> To: 
> [...]
> Further it is very kind request to you to please release the GIMP with new
> translations of Marathi before start of our course. This will allow
> participants of the course to download the GIMP and use it for practice in
> Marathi on their machines easily.
> [...]
> ___
> gimp-developer-list mailing list
> List address:gimp-developer-list@gnome.org
> 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:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list

Re: [Gimp-developer] Questions about the split view feature

[Jehan Pagès via gimp-developer-list]

Hi!

On Sat, Mar 23, 2019 at 10:48 AM wwp  wrote:

> Hello,
>
> the split view in Gimp 2.10 is an awesome feature!
>
> Here are my questions:
> - I couldn't find a way to have the split view turned on by default, in
> any place. Is that possible?
>

I guess it may makes sense to save this option so that the checkbox stays
checked if we left it checked last we used a filter. On the other hand, I
could imagine it to be annoying sometimes, especially if you fail to notice
it to be on (in case of subtle changes). :-/


> - The split view handle is only visible when the guides are visible. You
> probably see me coming, because, when the guides are unvisible, turn on
> the split view and.. and nothing :-). Shouldn't turning the split view
> on, make the guides visibles? Or just the split view guide (make it a
> non-discardable guide)?
>

I understand the issue. This is annoying sometimes when I turn on a feature
with guides and they are invisible. Unfortunately making them always
visible is definitely not an option. Guides are very practical feature but
they are also in the way. Many often, you absolutely need to make them
disappear. This is just as true for generic guides, as for mirror guides,
or here split view guides. In the later case, the guide is just right in
the border between with and without the effect you are comparing. Sometimes
you want to do so the most seamlessly possible. And a line just at the
separation points is making the comparison difficult.

If you have a lot of need to switch guide visibility on/off, I'd suggest
you change the shortcut to some direct key. I know this is what does the
artist I work with, because guide visibility is quite a frequently used
switch.

Jehan



> Regards,
>
> --
> wwp
> ___
> gimp-developer-list mailing list
> List address:gimp-developer-list@gnome.org
> 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:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list

Re: [Gimp-developer] Spyrogimp plugin rewrite

[Jehan Pagès via gimp-developer-list]

P.S.: As you can guess, I never took the time to actually look into
re-implementing the clone as an available tool in your plug-in. That was a
cool feature, but I don't think if I will make the time to add it (as I
don't need it other than it's cool :P). So feel free to just add it back if
ever you manage to fix the issue previously raised. :-)

On Thu, Jan 24, 2019 at 1:23 AM Jehan Pagès 
wrote:

> Hi Elad,
>
> Sorry for the delay before inclusion. I must admit I completely forgot
> (just while doing something else tonight, I suddenly remembered this
> proposal for an updated Spyrogimp!).
>
> So I took some time tonight to review again, then finally pushed your
> plug-in.
> I just did some trailing whitespace cleaning, and also simply renamed it
> to "plug-in-spyrogimp", basically dropping the "Plus" part. I understand
> that the "plus" was about saying it is another more advanced plug-in, but I
> prefer to think of it as just a new version of the same plug-in (even
> though a total rewrite), so that we can later on just drop the old version
> (maybe when moving to GIMP 3?). When this happens, if there is only one
> plug-in and it is named "plus", it makes not much sense. I guess. :-)
>
> Anyway here is the commit for the initial code you provided, as-is:
> https://gitlab.gnome.org/GNOME/gimp/commit/a702c6a3270485e1320521c89499e1b3270477d4
> And here my commit with the slight changes:
> https://gitlab.gnome.org/GNOME/gimp/commit/e91028df2f9669fe2d98f05a969692695a62003f
>
> I hope you will stay around for any fixes which might be needed later on.
> :-)
> Do you have a GNOME gitlab account?
>
> Jehan
>
> On Sun, Nov 18, 2018 at 9:24 PM Jehan Pagès 
> wrote:
>
>> Hi!
>>
>> On Sun, Nov 18, 2018 at 8:58 PM Elad Shahar  wrote:
>>
>>> Hi Jehan,
>>>
>>> Thanks for the review!
>>> The new version is here
>>> 
>>>
>>> Here is what I have done:
>>>
>>> * The problem with the background color happens only in some themes,
>>> when using a notebook where the tabs are set to be invisible. That was what
>>> I was using.
>>> I did not manage to make the odd background color go away, so I just
>>> changed the UI to use a notebook with the tabs visible.  So this should be
>>> solved.
>>>
>>> * As for the clone issue, I did not manage to fix the issue, so I just
>>> removed "Clone" from the list of tools.
>>>
>>
>> Sad! The clone source seemed like a cool feature. I'll see if I can fix
>> this myself then. :-)
>>
>> Jehan
>>
>>
>>> Thanks!
>>> Elad
>>>
>>> On Wed, Nov 14, 2018 at 6:54 PM Jehan Pagès 
>>> wrote:
>>>
 Hi!

 On Sun, Oct 14, 2018 at 12:47 AM Elad Shahar 
 wrote:

> Hi Jehan,
>
> Thanks for your feedback!
> The new version is here
>  .
>
> Here is what I have done:
>
> * I made "Esc" close the dialog (and cancel the pattern).
> * The issue with the broken icon was part of a larger issue that made
> the plugin look different than other plugins. This was resolved by using
> gimpui.py
> * I added a non-interactive API.
> * I made the dialog less tall, by grouping parameters in notebook tabs.
>
> In addition:
>
> * Using the "selection" shape now draws multiple shapes - if several
> paths were generated from the selection-to-path conversion.
> * Several new multi-sided shapes were added as fixed rings, with
> additional options.
>   These produce drawings similar to many guilloche patterns. Examples
> for the new shapes are here
> .
> * I added "long-gradient" support, that spreads across the entire
> pattern.
>   This was available in the previous spyrogimp.scm, and produces nice
> results which are difficult to obtain when trying to tune the gradient 
> from
> tool settings.
> * Improved the speed of incremental drawing by using gobject.idle_add
> instead of timeouts.
>
> I'd be glad to fix any other issues.
>

 So I finally reviewed.

 * The background color of self.pattern_notebook is always white, which
 is especially a problem with darker themes. Is it only for me? Don't you
 have this issue too? I had a look and am unsure where this comes from
 though (maybe it's a problem in the theme, but I have no idea).

 * I had once a warning about broken undo when setting "Clone" (then I
 had a warning about no clone source, but this one is normal) then canceling
 with Esc.

 Apart from these, it looks good here. :-)

 Jehan


> If the plugin is indeed updated in the repository, could I write
> documentation for the manual?
>
> Thanks!
> Elad
>
> On Sun, Sep 16, 2018 at 10:34 PM Jehan Pagès <
> jehan.marmott...@gmail.com> wrote:
>
>> Hi Elad,
>>
>> On Sat, Sep 15, 

Re: [Gimp-developer] Spyrogimp plugin rewrite

[Jehan Pagès via gimp-developer-list]

Hi Elad,

Sorry for the delay before inclusion. I must admit I completely forgot
(just while doing something else tonight, I suddenly remembered this
proposal for an updated Spyrogimp!).

So I took some time tonight to review again, then finally pushed your
plug-in.
I just did some trailing whitespace cleaning, and also simply renamed it to
"plug-in-spyrogimp", basically dropping the "Plus" part. I understand that
the "plus" was about saying it is another more advanced plug-in, but I
prefer to think of it as just a new version of the same plug-in (even
though a total rewrite), so that we can later on just drop the old version
(maybe when moving to GIMP 3?). When this happens, if there is only one
plug-in and it is named "plus", it makes not much sense. I guess. :-)

Anyway here is the commit for the initial code you provided, as-is:
https://gitlab.gnome.org/GNOME/gimp/commit/a702c6a3270485e1320521c89499e1b3270477d4
And here my commit with the slight changes:
https://gitlab.gnome.org/GNOME/gimp/commit/e91028df2f9669fe2d98f05a969692695a62003f

I hope you will stay around for any fixes which might be needed later on.
:-)
Do you have a GNOME gitlab account?

Jehan

On Sun, Nov 18, 2018 at 9:24 PM Jehan Pagès 
wrote:

> Hi!
>
> On Sun, Nov 18, 2018 at 8:58 PM Elad Shahar  wrote:
>
>> Hi Jehan,
>>
>> Thanks for the review!
>> The new version is here
>> 
>>
>> Here is what I have done:
>>
>> * The problem with the background color happens only in some themes, when
>> using a notebook where the tabs are set to be invisible. That was what I
>> was using.
>> I did not manage to make the odd background color go away, so I just
>> changed the UI to use a notebook with the tabs visible.  So this should be
>> solved.
>>
>> * As for the clone issue, I did not manage to fix the issue, so I just
>> removed "Clone" from the list of tools.
>>
>
> Sad! The clone source seemed like a cool feature. I'll see if I can fix
> this myself then. :-)
>
> Jehan
>
>
>> Thanks!
>> Elad
>>
>> On Wed, Nov 14, 2018 at 6:54 PM Jehan Pagès 
>> wrote:
>>
>>> Hi!
>>>
>>> On Sun, Oct 14, 2018 at 12:47 AM Elad Shahar 
>>> wrote:
>>>
 Hi Jehan,

 Thanks for your feedback!
 The new version is here
  .

 Here is what I have done:

 * I made "Esc" close the dialog (and cancel the pattern).
 * The issue with the broken icon was part of a larger issue that made
 the plugin look different than other plugins. This was resolved by using
 gimpui.py
 * I added a non-interactive API.
 * I made the dialog less tall, by grouping parameters in notebook tabs.

 In addition:

 * Using the "selection" shape now draws multiple shapes - if several
 paths were generated from the selection-to-path conversion.
 * Several new multi-sided shapes were added as fixed rings, with
 additional options.
   These produce drawings similar to many guilloche patterns. Examples
 for the new shapes are here
 .
 * I added "long-gradient" support, that spreads across the entire
 pattern.
   This was available in the previous spyrogimp.scm, and produces nice
 results which are difficult to obtain when trying to tune the gradient from
 tool settings.
 * Improved the speed of incremental drawing by using gobject.idle_add
 instead of timeouts.

 I'd be glad to fix any other issues.

>>>
>>> So I finally reviewed.
>>>
>>> * The background color of self.pattern_notebook is always white, which
>>> is especially a problem with darker themes. Is it only for me? Don't you
>>> have this issue too? I had a look and am unsure where this comes from
>>> though (maybe it's a problem in the theme, but I have no idea).
>>>
>>> * I had once a warning about broken undo when setting "Clone" (then I
>>> had a warning about no clone source, but this one is normal) then canceling
>>> with Esc.
>>>
>>> Apart from these, it looks good here. :-)
>>>
>>> Jehan
>>>
>>>
 If the plugin is indeed updated in the repository, could I write
 documentation for the manual?

 Thanks!
 Elad

 On Sun, Sep 16, 2018 at 10:34 PM Jehan Pagès <
 jehan.marmott...@gmail.com> wrote:

> Hi Elad,
>
> On Sat, Sep 15, 2018 at 4:14 PM Elad Shahar via gimp-developer-list <
> gimp-developer-list@gnome.org> wrote:
>
>> Hi,
>>
>> Long ago, I have written a Spyrogimp plugin in scheme. The plugin is
>> currently included in gimp (under Filters -> Render -> Spyrogimp).
>> Now I
>> have done a rewrite in python which I hope is a big improvement:
>>
>> * It provides immediate feedback, by incremental drawing to a
>> temporary
>> layer.
>> * Supports using more tools to draw the pattern (e.g. stroke).
>> * You can use a 

Re: [Gimp-developer] AI algorithms in GIMP

[Jehan Pagès via gimp-developer-list]

Hi!

On Thu, Jan 17, 2019 at 12:14 PM Maitraya Bhattacharyya via
gimp-developer-list  wrote:

> Dear devs,
>
> I have recently joined the mailing list because I wanted to contribute my
> two pennies to GIMP development (since I use it for my work). I had a look
> at the proposed plan for GIMP and wondered if people would be interested in
> including some popular AI algorithms for several image processing tasks.
>

We are definitely interested by any AI algorithms. At least I am.

I would be interested in writing implementations of some of these
> algorithms into gimp if someone can commit to writing a frontend/GUI for
> it.
>

The hard point here is "if someone can commit to […]". It's a bit hard to
commit without knowing much (unless you are paid, then you have no choice
;p). Usually it's the other way around: you propose something. It doesn't
have to be with a great GUI or whatever. Then if we like what we see, we
will definitely add our own 2 cents to the pool. This is usually how most
features are done around here, when someone contributes a patch with a very
cool idea, then we review and often fix/change what we think is needed
(sometimes just a bit, sometimes deeply).

I often wrote crap GUI myself and others came to the rescue with ideas and
code. :-)


> It would be great if we can make a list of these algorithms to implement
> and rank them according to priority.
>

I would suggest to *not do that*. :-)
Basically we are not a company, we don't sell GIMP and don't have huge
plans for the next decade. Well "officially", we do have a roadmap and
such, but if you follow GIMP development, you'd see it is more flexible and
experimental than some rigid plan.
Making a huge list with big plans for the future "might" be just the way to
spend a lot of time and kill your project in the end.

Instead I would propose **you** just select **one** such algorithm which
you find is great and even irrefusable since it would be so fucking awesome
and useful! Then you implement and propose it and we will be so amazed that
we just have to include it and do a proper GUI for it. That sounds like the
best plan.

From there, you can go on with more awesome ideas. :-)
You may even be able to start doing more organized work with a list of
algorithms after, etc. But for a first patch, I would suggest you just take
the lead.


> As for my background, I am a theoretical physicist making simulations for
> HPCs (in C/C++) and interpreting their data (in Python). I have a

reasonable workstation to train neural nets, if necessary. Be warned that I
>

There is only a single very important part about AI algorithms which need
training: we will want the code to train, the data, etc. everything as free
software/Open Data and properly documented.
I have worked with trained algorithms in Free Software where the trained
data is just dropped as-is, and once the original author disappears, this
is unmaintainable. In particular it cannot be improved or fixed or nothing,
because we don't have the code to re-generate the neural networks (or
alike). This can only be a recipe for failure long-term.

So AI in GIMP? Yeah definitely! But it has to be reproducible generated
data, with the whole training infrastructure available and properly
documented and the input data under Libre license as well.


> have never written a GUI software in my life and I don't know the GIMP
> codebase at all. I envision these to be standalone scripts which can be
> called in from the GIMP interface.
>

Cool. Depending on the idea, it may be interesting to rather implement it
directly as a GEGL operation (GEGL is our graphics engine). Maybe you don't
even need to make a GUI then. Just make a GEGL op, and when it is done, run
it with examples to show us how good it is, and we might just get into the
game to make it a proper GUI.


> Please let me know what you think.
>

And here you are! I hope we will see soon a lot of baby robots in our code.
;-)

Jehan



> Cheerio,
> Maitraya.
>
> Senior Research Fellow
> Center for Excellence in Space Sciences India
> Indian Institute of Science Education and Research Kolkata
> ___
> gimp-developer-list mailing list
> List address:gimp-developer-list@gnome.org
> 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:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list

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

[Jehan Pagès via gimp-developer-list]

Hi!

On Wed, Jan 2, 2019 at 1:57 AM Michal Vašut  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 
>> 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 > wrote:
>>
>>> Hi!
>>>
>>> On Wed, Dec 19, 2018 at 1:16 AM Michal Vašut 
>>> 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 >>> wrote:

> Hi!
>
> On Tue, Dec 18, 2018 at 9:05 PM Michal Vašut 
> wrote:
>
>> Cool, thanks for info. I've checked the page on your blog and have
>> some notes to metadata that would be included:
>>
>> 
>>   org.gimp.GIMP
>>  
>>
>> 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

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

[Jehan Pagès via gimp-developer-list]

Hi!

On Wed, Dec 19, 2018 at 1:16 AM Michal Vašut  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 
>> Hi!
>>
>> On Tue, Dec 18, 2018 at 9:05 PM Michal Vašut 
>> wrote:
>>
>>> Cool, thanks for info. I've checked the page on your blog and have some
>>> notes to metadata that would be included:
>>>
>>> 
>>>   org.gimp.GIMP
>>>  
>>>
>>> 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 `` 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 

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

[Jehan Pagès via gimp-developer-list]

Hi!

On Tue, Dec 18, 2018 at 9:05 PM Michal Vašut  wrote:

> Cool, thanks for info. I've checked the page on your blog and have some
> notes to metadata that would be included:
>
> 
>   org.gimp.GIMP
>  
>
> 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 `` 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:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list

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

[Jehan Pagès via gimp-developer-list]

On Sat, Dec 15, 2018 at 11:03 AM Michal Vašut 
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  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 <
>> gimp-developer-list@gnome.org> 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:gimp-developer-list@gnome.org
>>> 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:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list

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

[Jehan Pagès via gimp-developer-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 <
gimp-developer-list@gnome.org> 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:gimp-developer-list@gnome.org
> 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:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list

Re: [Gimp-developer] Spyrogimp plugin rewrite

[Jehan Pagès via gimp-developer-list]

Hi!

On Sun, Nov 18, 2018 at 8:58 PM Elad Shahar  wrote:

> Hi Jehan,
>
> Thanks for the review!
> The new version is here
> 
>
> Here is what I have done:
>
> * The problem with the background color happens only in some themes, when
> using a notebook where the tabs are set to be invisible. That was what I
> was using.
> I did not manage to make the odd background color go away, so I just
> changed the UI to use a notebook with the tabs visible.  So this should be
> solved.
>
> * As for the clone issue, I did not manage to fix the issue, so I just
> removed "Clone" from the list of tools.
>

Sad! The clone source seemed like a cool feature. I'll see if I can fix
this myself then. :-)

Jehan


> Thanks!
> Elad
>
> On Wed, Nov 14, 2018 at 6:54 PM Jehan Pagès 
> wrote:
>
>> Hi!
>>
>> On Sun, Oct 14, 2018 at 12:47 AM Elad Shahar  wrote:
>>
>>> Hi Jehan,
>>>
>>> Thanks for your feedback!
>>> The new version is here
>>>  .
>>>
>>> Here is what I have done:
>>>
>>> * I made "Esc" close the dialog (and cancel the pattern).
>>> * The issue with the broken icon was part of a larger issue that made
>>> the plugin look different than other plugins. This was resolved by using
>>> gimpui.py
>>> * I added a non-interactive API.
>>> * I made the dialog less tall, by grouping parameters in notebook tabs.
>>>
>>> In addition:
>>>
>>> * Using the "selection" shape now draws multiple shapes - if several
>>> paths were generated from the selection-to-path conversion.
>>> * Several new multi-sided shapes were added as fixed rings, with
>>> additional options.
>>>   These produce drawings similar to many guilloche patterns. Examples
>>> for the new shapes are here
>>> .
>>> * I added "long-gradient" support, that spreads across the entire
>>> pattern.
>>>   This was available in the previous spyrogimp.scm, and produces nice
>>> results which are difficult to obtain when trying to tune the gradient from
>>> tool settings.
>>> * Improved the speed of incremental drawing by using gobject.idle_add
>>> instead of timeouts.
>>>
>>> I'd be glad to fix any other issues.
>>>
>>
>> So I finally reviewed.
>>
>> * The background color of self.pattern_notebook is always white, which is
>> especially a problem with darker themes. Is it only for me? Don't you have
>> this issue too? I had a look and am unsure where this comes from though
>> (maybe it's a problem in the theme, but I have no idea).
>>
>> * I had once a warning about broken undo when setting "Clone" (then I had
>> a warning about no clone source, but this one is normal) then canceling
>> with Esc.
>>
>> Apart from these, it looks good here. :-)
>>
>> Jehan
>>
>>
>>> If the plugin is indeed updated in the repository, could I write
>>> documentation for the manual?
>>>
>>> Thanks!
>>> Elad
>>>
>>> On Sun, Sep 16, 2018 at 10:34 PM Jehan Pagès 
>>> wrote:
>>>
 Hi Elad,

 On Sat, Sep 15, 2018 at 4:14 PM Elad Shahar via gimp-developer-list <
 gimp-developer-list@gnome.org> wrote:

> Hi,
>
> Long ago, I have written a Spyrogimp plugin in scheme. The plugin is
> currently included in gimp (under Filters -> Render -> Spyrogimp). Now
> I
> have done a rewrite in python which I hope is a big improvement:
>
> * It provides immediate feedback, by incremental drawing to a temporary
> layer.
> * Supports using more tools to draw the pattern (e.g. stroke).
> * You can use a non-rectangular selection to serve as the shape of the
> "fixed ring". This is done by converting the selection to a path. If
> the
> path has more than one stroke, then a pattern is drawn only for one of
> them. ( I might improve that in the near future).
> * There is an additional way to specify the pattern, that is compatible
> with the notation in the toy kit Spirograph manuals.
> * Lots of tooltips
>
> If you want to try it, you can download it here:
> https://www.dropbox.com/s/r2t5o4n4kyvtkmi/spyro.py?dl=0


 That's a cool update, and we could replace the old spyro by the new one
 (or on 2.10 at least deprecate the old one and hide it from menus but leave
 it alongside for the PDB API).
 I wonder if this could not be a GEGL operation also by the way, rather
 than a plug-in.

 Feedback is welcome.
>

 * Would be nice that hitting "Esc" close the dialog (and cancel the
 pattern).
 * On my desktop (GNOME on Fedora 28), the dialog shows a broken icon.
 * The dialog is much too high. On my screen, part of it is out of
 screen (the buttons in particular) so I need to use the Super key + left
 mouse click trick to move the window. It would be nice to rearrange the
 buttons differently or hide a scrollbar.
 * Your new plug-in doesn't provide a non-interactive API as 

Re: [Gimp-developer] Spyrogimp plugin rewrite

[Jehan Pagès via gimp-developer-list]

Hi!

On Sun, Oct 14, 2018 at 12:47 AM Elad Shahar  wrote:

> Hi Jehan,
>
> Thanks for your feedback!
> The new version is here
>  .
>
> Here is what I have done:
>
> * I made "Esc" close the dialog (and cancel the pattern).
> * The issue with the broken icon was part of a larger issue that made the
> plugin look different than other plugins. This was resolved by using
> gimpui.py
> * I added a non-interactive API.
> * I made the dialog less tall, by grouping parameters in notebook tabs.
>
> In addition:
>
> * Using the "selection" shape now draws multiple shapes - if several paths
> were generated from the selection-to-path conversion.
> * Several new multi-sided shapes were added as fixed rings, with
> additional options.
>   These produce drawings similar to many guilloche patterns. Examples for
> the new shapes are here
> .
> * I added "long-gradient" support, that spreads across the entire pattern.
>   This was available in the previous spyrogimp.scm, and produces nice
> results which are difficult to obtain when trying to tune the gradient from
> tool settings.
> * Improved the speed of incremental drawing by using gobject.idle_add
> instead of timeouts.
>
> I'd be glad to fix any other issues.
>

So I finally reviewed.

* The background color of self.pattern_notebook is always white, which is
especially a problem with darker themes. Is it only for me? Don't you have
this issue too? I had a look and am unsure where this comes from though
(maybe it's a problem in the theme, but I have no idea).

* I had once a warning about broken undo when setting "Clone" (then I had a
warning about no clone source, but this one is normal) then canceling with
Esc.

Apart from these, it looks good here. :-)

Jehan


> If the plugin is indeed updated in the repository, could I write
> documentation for the manual?
>
> Thanks!
> Elad
>
> On Sun, Sep 16, 2018 at 10:34 PM Jehan Pagès 
> wrote:
>
>> Hi Elad,
>>
>> On Sat, Sep 15, 2018 at 4:14 PM Elad Shahar via gimp-developer-list <
>> gimp-developer-list@gnome.org> wrote:
>>
>>> Hi,
>>>
>>> Long ago, I have written a Spyrogimp plugin in scheme. The plugin is
>>> currently included in gimp (under Filters -> Render -> Spyrogimp). Now I
>>> have done a rewrite in python which I hope is a big improvement:
>>>
>>> * It provides immediate feedback, by incremental drawing to a temporary
>>> layer.
>>> * Supports using more tools to draw the pattern (e.g. stroke).
>>> * You can use a non-rectangular selection to serve as the shape of the
>>> "fixed ring". This is done by converting the selection to a path. If the
>>> path has more than one stroke, then a pattern is drawn only for one of
>>> them. ( I might improve that in the near future).
>>> * There is an additional way to specify the pattern, that is compatible
>>> with the notation in the toy kit Spirograph manuals.
>>> * Lots of tooltips
>>>
>>> If you want to try it, you can download it here:
>>> https://www.dropbox.com/s/r2t5o4n4kyvtkmi/spyro.py?dl=0
>>
>>
>> That's a cool update, and we could replace the old spyro by the new one
>> (or on 2.10 at least deprecate the old one and hide it from menus but leave
>> it alongside for the PDB API).
>> I wonder if this could not be a GEGL operation also by the way, rather
>> than a plug-in.
>>
>> Feedback is welcome.
>>>
>>
>> * Would be nice that hitting "Esc" close the dialog (and cancel the
>> pattern).
>> * On my desktop (GNOME on Fedora 28), the dialog shows a broken icon.
>> * The dialog is much too high. On my screen, part of it is out of screen
>> (the buttons in particular) so I need to use the Super key + left mouse
>> click trick to move the window. It would be nice to rearrange the buttons
>> differently or hide a scrollbar.
>> * Your new plug-in doesn't provide a non-interactive API as the old one
>> used to. I think this would be quite needed to be able to replace the old
>> plug-in correctly.
>>
>> Apart from these, that is a really cool plug-in. I would update the
>> repository with this new plug-in once these few points are fixed. :-)
>> If you answer by email, make sure to name me so that I don't miss the
>> email (I have filters allowing me to see when I am named so that I don't
>> miss mailing list emails targeted at me).
>> Thanks!
>>
>> Jehan
>>
>>
>>>
>>> Elad
>>> ___
>>> gimp-developer-list mailing list
>>> List address:gimp-developer-list@gnome.org
>>> 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: 

Re: [Gimp-developer] Spyrogimp plugin rewrite

[Jehan Pagès via gimp-developer-list]

Hi!

On Sun, Oct 14, 2018 at 12:47 AM Elad Shahar  wrote:

> Hi Jehan,
>
> Thanks for your feedback!
> The new version is here
>  .
>

For the record, I saw the email and will review (and merge if no problems)
your code. I have had not much time this week, but hopefully it will be
better next week.
For git authorship, do you confirm I should use the name and email as used
on this mailing list?

As for the GEGL operation discussion, I definitely see how cool it would be.
But if you say it would remove some features, of course we could discuss
how to make the best out of both worlds. I don't know enough about this
plug-in yet to be 100% relevant though. :-)

Here is what I have done:
>
> * I made "Esc" close the dialog (and cancel the pattern).
> * The issue with the broken icon was part of a larger issue that made the
> plugin look different than other plugins. This was resolved by using
> gimpui.py
> * I added a non-interactive API.
> * I made the dialog less tall, by grouping parameters in notebook tabs.
>
> In addition:
>
> * Using the "selection" shape now draws multiple shapes - if several paths
> were generated from the selection-to-path conversion.
> * Several new multi-sided shapes were added as fixed rings, with
> additional options.
>   These produce drawings similar to many guilloche patterns. Examples for
> the new shapes are here
> .
> * I added "long-gradient" support, that spreads across the entire pattern.
>   This was available in the previous spyrogimp.scm, and produces nice
> results which are difficult to obtain when trying to tune the gradient from
> tool settings.
> * Improved the speed of incremental drawing by using gobject.idle_add
> instead of timeouts.
>
> I'd be glad to fix any other issues.
>
> If the plugin is indeed updated in the repository, could I write
> documentation for the manual?
>

You are more than welcome to contribute to the manual too. The source is
there: https://gitlab.gnome.org/GNOME/gimp-help

Same as we welcome patches for GIMP, we also do welcome patches for the
manual. :-)

Jehan


> Thanks!
> Elad
>
> On Sun, Sep 16, 2018 at 10:34 PM Jehan Pagès 
> wrote:
>
>> Hi Elad,
>>
>> On Sat, Sep 15, 2018 at 4:14 PM Elad Shahar via gimp-developer-list <
>> gimp-developer-list@gnome.org> wrote:
>>
>>> Hi,
>>>
>>> Long ago, I have written a Spyrogimp plugin in scheme. The plugin is
>>> currently included in gimp (under Filters -> Render -> Spyrogimp). Now I
>>> have done a rewrite in python which I hope is a big improvement:
>>>
>>> * It provides immediate feedback, by incremental drawing to a temporary
>>> layer.
>>> * Supports using more tools to draw the pattern (e.g. stroke).
>>> * You can use a non-rectangular selection to serve as the shape of the
>>> "fixed ring". This is done by converting the selection to a path. If the
>>> path has more than one stroke, then a pattern is drawn only for one of
>>> them. ( I might improve that in the near future).
>>> * There is an additional way to specify the pattern, that is compatible
>>> with the notation in the toy kit Spirograph manuals.
>>> * Lots of tooltips
>>>
>>> If you want to try it, you can download it here:
>>> https://www.dropbox.com/s/r2t5o4n4kyvtkmi/spyro.py?dl=0
>>
>>
>> That's a cool update, and we could replace the old spyro by the new one
>> (or on 2.10 at least deprecate the old one and hide it from menus but leave
>> it alongside for the PDB API).
>> I wonder if this could not be a GEGL operation also by the way, rather
>> than a plug-in.
>>
>> Feedback is welcome.
>>>
>>
>> * Would be nice that hitting "Esc" close the dialog (and cancel the
>> pattern).
>> * On my desktop (GNOME on Fedora 28), the dialog shows a broken icon.
>> * The dialog is much too high. On my screen, part of it is out of screen
>> (the buttons in particular) so I need to use the Super key + left mouse
>> click trick to move the window. It would be nice to rearrange the buttons
>> differently or hide a scrollbar.
>> * Your new plug-in doesn't provide a non-interactive API as the old one
>> used to. I think this would be quite needed to be able to replace the old
>> plug-in correctly.
>>
>> Apart from these, that is a really cool plug-in. I would update the
>> repository with this new plug-in once these few points are fixed. :-)
>> If you answer by email, make sure to name me so that I don't miss the
>> email (I have filters allowing me to see when I am named so that I don't
>> miss mailing list emails targeted at me).
>> Thanks!
>>
>> Jehan
>>
>>
>>>
>>> Elad
>>> ___
>>> gimp-developer-list mailing list
>>> List address:gimp-developer-list@gnome.org
>>> 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
>> 

Re: [Gimp-developer] GIMP 2.10.x AppImage packages

[Jehan Pagès via gimp-developer-list]

On Mon, Sep 17, 2018 at 8:54 AM Carmelo DrRaw 
wrote:

> Hi Jehan,
>
> On 16 Sep 2018, at 21:55, Jehan Pagès  wrote:
>
> Hi!
>
>
>>
>>
> Also at some point, we should resume discussing making your package
> upstream. It's hard to make time to discuss this, but this is probably
> needed. Moreover lately the maintainer of the Snap package approached us to
> make it upstream as well. So I thought this is the opportunity to discuss
> about AppImage as well.
>
>
> Would it be ok to continue the discussion in the corresponding GitHub
> issue?
> https://github.com/aferrero2707/gimp-appimage/issues/9
>

Of course. I wrote a comment there actually immediately after my previous
email. ;-)

Jehan


> Andrea
>
>
> Jehan
>
>
>> > --
>> > Ell
>>
>> ___
>> gimp-developer-list mailing list
>> List address:gimp-developer-list@gnome.org
>> 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:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list

Re: [Gimp-developer] GIMP 2.10.x AppImage packages

[Jehan Pagès via gimp-developer-list]

Hi!

On Mon, Sep 10, 2018 at 7:03 PM Carmelo DrRaw via gimp-developer-list <
gimp-developer-list@gnome.org> wrote:

> Hi!
>
> > On 10 Sep 2018, at 18:28, Ell  wrote:
> >
> >
> >> A note to the developers: the current 2.10.x branch requires a quite
> >> recent version of Glib, but only due to the use of a single function
> >> in app/gui/splash.c, and only for diagnostics purposes. To circumvent
> >> the problem and be able to use the older Glib version available on
> >> CentOS 7, I am applying the following patch:
> >>
> https://github.com/aferrero2707/gimp-appimage/blob/master/gimp-glib-splash.patch
> >> <
> https://github.com/aferrero2707/gimp-appimage/blob/master/gimp-glib-splash.patch
> >
> >> Is that OK?
> >
> > This has already been fixed in the gimp-2-10 branch (master requires a
> > newer GLib version).  See commit
> > 499a8962b326823bdf12936960798f802c79f283.
> >
>
> Excellent! The new Glib requirement is one of the reasons preventing me to
> provide an AppImage for the master branch… I need to go through the
> compilation of Glib from sources, and see if there are no showstoppers on
> CentOS 7.
>

Also at some point, we should resume discussing making your package
upstream. It's hard to make time to discuss this, but this is probably
needed. Moreover lately the maintainer of the Snap package approached us to
make it upstream as well. So I thought this is the opportunity to discuss
about AppImage as well.

Jehan


> > --
> > Ell
>
> ___
> gimp-developer-list mailing list
> List address:gimp-developer-list@gnome.org
> 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:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list

[Gimp-developer] Packagers: core plug-ins will be installed in subdirs in GIMP 2.10.6

[Jehan Pagès via gimp-developer-list]

Hi all!

That's a message mostly for packagers (it doesn't matter for other people):
the core plug-ins will now be installed in sub-directories. I.e. the
plug-in `file-webp.exe` (on Windows) will be installed under
`plug-ins/file-webp/file-webp.exe`.

The `make install` step takes care of everything, but this info may matter
for update process (depending on how you do it), as you might want to
delete `plug-ins/file-webp.exe` (and other plug-ins directly under
`plug-ins/` in previous versions of GIMP).

This is one more step towards getting fully rid of DLL hell.

This doesn't change anything for third-party plug-ins which can still be
installed directly under the user config's `plug-ins/` directory though we
advise against it. We advise to install user plug-ins under subdirectories
as well.

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:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list

Re: [Gimp-developer] configure: Eeeeeeeeeeeeeeeeeeeeek! Missing dep: appstream-glib >= 0.7.7

[Jehan Pagès via gimp-developer-list]

Hi!

On Thu, Aug 2, 2018 at 8:04 PM, Kevin Cozens  wrote:

> On 2018-07-24 06:04 AM, Jehan Pagès via gimp-developer-list wrote:
>
>> On Sat, Jul 14, 2018 at 3:40 AM, Liam R E Quin  wrote:
>>
> [snip]
>
>> For the record, I just checked current code and actual minimum dep
>> (relatively to the functions I use from this lib) would be 0.6.7.
>>
> [snip]
>
>> Also this is development code. It is expected to get bumpy.
>>
>
> The addition of appstream-glib has been the biggest bump to date. When
> dependencies get bumped I just download, compile, and install the new
> version of the dependency. That hasn't worked with appsteram-glib.
>
> This new dependency wants some support for RPM packages on a system that
> doesn't use RPM for package management. It also needed another dependency
> that I needed to compile but that needed yet another package. At that point
> I gave up trying to satisfy the need for appstream-glib.
>

RPM libs and tools are available on most (if not all) distributions that I
know of, even when based on other package systems (like .deb packages). :-)
This being said, in appstream-glib, RPM support is an option. I'm not sure
what it is used for, but I doubt we use anything related to this in GIMP.
You should not try to make featureful builds of dependencies at the first
attempt.


> What is appstream-glib and how is it going to be used in GIMP?
>

This is a lib to process the AppStream metadata format. This is used for
the new extension management system. I don't think that anyone will be ok
to have builds without this feature, when it will be released, considering
how important it will be, hence that's not an option. :-)

Note that I use the future because even though current dev code use this
already, this will show its importance in more code to come. But it still
has to be non-optional dep because we are no going to make our lives more
difficult just for the sake of it.

I remind (just in case!) that master code is for development. It is
certainly not advised for daily use, in particular. And we are not going to
develop with outdated versions of libraries for instance (unless you want
to see features be released with completely outdated code). So yes, we use
recent versions (while still being reasonnable, hence the famous "at least
available in Debian Testing" rule). A developer is expected to run such a
modern OS for developer, not a LTS or other old distributions for "stable"
systems.

Then there is the question of Windows or macOS. We hope we can help these
libraries to become cross-platform soon (same as we helped libmypaint to be
easily cross-compiled, as well as GExiv2, and many others… wasn't there
libheif also recently?). That's what we do all the time. And hopefully this
will happen again.
Now I am not saying it is impossible that we ever get back and use
something else if it turns out really too complicated a task. But we need
to at least try and go this way first. I currently see no reasons why it
would turn out impossible to improve the library to be more cross-platform,
as we did it for many others. That's what development is for.

Jehan



> --
> Cheers!
>
> Kevin.
>
> http://www.ve3syb.ca/   | "Nerds make the shiny things that
> https://www.patreon.com/KevinCozens | distract the mouth-breathers, and
> | that's why we're powerful"
> Owner of Elecraft K2 #2172  |
> #include  | --Chris Hardwick
> ___
> gimp-developer-list mailing list
> List address:gimp-developer-list@gnome.org
> 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:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list

Re: [Gimp-developer] configure: Eeeeeeeeeeeeeeeeeeeeek! Missing dep: appstream-glib >= 0.7.7

[Jehan Pagès via gimp-developer-list]

Hi!

On Sat, Jul 14, 2018 at 3:40 AM, Liam R E Quin  wrote:

> On Wed, 2018-07-11 at 14:59 +0100, richard brown via gimp-developer-
> list wrote:
> > "configure: Ek! Missing dep: appstream-glib >=
> > 0.7.7"
>
> On my system i edited configure to require 0.7.6 (which i have) and it
> worked.
>

For the record, I just checked current code and actual minimum dep
(relatively to the functions I use from this lib) would be 0.6.7.
I could set a lower value, but really the development is barely started on
this feature, I will use more API soon so it may go back up soon anyway,
and I'm not sure if it is worth just going back and forth on dependency
versions.

Note that I originally chose this version 0.7.7 by looking at Debian
Testing, which is our base for deciding whether a version can a requirement
in the development GIMP.
Also this is development code. It is expected to get bumpy. We even
realized this dependency has problems to build on Windows, but it's ok. We
are confident that this will improve. This is not the first time (and won't
be the last) that we improve projects by using them, and in particular that
we make them going cross-platform. :-)

Jehan


>
> > Ah, but I have appstream-glib >0.7.7 installed; built it from source
> > and installed it into the prefix I use for gimp.
>
> Check there's a .pc file in $PREFIX/usr/lib/pkgconfig/ and also that
> the directory containing it is in your PKG_PATH.
> >
>
> If so, check config.log to see what went wrong...
>
> Liam (slave ankh)
>
>
> --
> Liam Quin - web slave for https://www.fromoldbooks.org/
> with fabulous vintage art and fascinating texts to read.
> Click here to have the slave beaten.
> ___
> gimp-developer-list mailing list
> List address:gimp-developer-list@gnome.org
> 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:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list