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

2022-10-18 Thread 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

2022-10-18 Thread 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 u

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

2022-10-17 Thread Jehan Pagès via gimp-developer-list
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 and hopefully last answer
on this topic. I'm just tired and don't want to paste the same email twice
(or more).

Actually sending private emails, you kind of made a counter-argument
against mailing lists where it is indeed quite common that people feel they
can just continue discussions in private. But there is a reason why it's
public: anyone can join in, help and contribute to the discussion. No need
to involve a single person only (forbidding others to help by going
private). In GIMP, we work in full transparency, with public
infrastructure. We don't want private discussions, and unfortunately as you
showed, this is often what some people believe they can afford to do with
emails. So you both shot your opinion in the foot by telling me that
mailing lists are better while deciding not to use these to tell me this. 🤣

So yes, bottom line: mailing lists will be gone. It's not a private
decision from anyone in GIMP team (I got notified today myself of the
end-of-month deadline), though clearly nobody fought against it either.
It's not really something we can or want to control so there is really no
need to give counter-arguments here. If you really wish to do so, you are
welcome to ask the GNOME Infrastructure team. If they back down from their
decision, we'll happily comply and keep the mailing lists.

Jehan
GIMP team


On Mon, Oct 17, 2022 at 10:00 PM Jehan Pagès 
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
>
> 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 ab

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

2022-10-17 Thread 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

2022-10-17 Thread 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

2022-09-14 Thread 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

2022-08-15 Thread 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 thought

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

2022-07-26 Thread 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&

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

2022-07-26 Thread 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

2022-07-26 Thread 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?

2021-10-06 Thread 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

2021-09-18 Thread 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

2021-08-25 Thread 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

2021-08-24 Thread 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]

2021-08-03 Thread Jehan Pagès via gimp-developer-list
Hi!

On Tue, Aug 3, 2021 at 5:49 AM ShiroYuki Mot 
wrote:

> Dear Jehan Pagès, Thanks for your reply even though you are busy.
>
> We, the beginners of Python writer feel it is so difficult.
> I didn't know the devel-docs/GIMP3-plug-in-porting-guide/ folder.
> (Windows users got only executables...)
> Reasons for feeling difficult are that gi module firstly needed and
> plug-ins dialog/registration definitions changed.
> I said this situation is a "new stage".
> There doesn't exist the explanation of a 'new' generation of using GObject.
> So many beginner level users (like me) will be confused.
> Many GIMP Python/script-fu users are writing code by
> imitating/copying-pasting, not at the developer level...
> And there are not many samples...
>
> The new API itself is not so difficult, I think so. This is because the
> documents are carefully supported. ;)
>
> 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.
>>
>
> Sure! ;)
>
>  And one more Question.
> foggify.py is stored in the same named sub directory.
> If we write a private script, is it better to be stored in a named sub
> diretory at users 'plug-ins' directory?
>

In GIMP 3, it is mandatory to have all plug-ins in an identically named
folder as the main script. This is to avoid making a mess in the root
plug-ins/ directory, and mixing files between plug-ins (which results in
DLL hell on Windows especially, for instance).

Jehan


>
>
> 2021年8月3日(火) 2:29 Jehan Pagès :
>
>> Hi!
>>
>> On Mon, Aug 2, 2021 at 3:15 PM ShiroYuki Mot <
>> shiroyuki.mot.m...@gmail.com> 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. 😛
>>
>>

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

2021-08-02 Thread 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 improvement

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

2021-08-02 Thread 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

2021-07-31 Thread 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 qui

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

2021-07-16 Thread 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

2021-06-18 Thread 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

2021-06-15 Thread 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

2021-06-05 Thread 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

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

2021-06-03 Thread 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 

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

2021-06-03 Thread 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

2021-05-19 Thread 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

2021-05-07 Thread 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().
  - gimp_progress_

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

2021-02-12 Thread 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

2021-02-12 Thread 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

2021-02-07 Thread 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&utf8=%E2%9C%93&state=opened&author_username=ellestone
>
> Here are bugs that I opened before the migration to gitlab:
>
> https://gitlab.gnome.org/GNOME/gimp/-/issues?scope=all&utf8=%E2%9C%93&state=opened&author_username=bugzilla-migration&search=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
scratchin

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

2021-02-07 Thread 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:
> whe

Re: [Gimp-developer] meson build with pdbgen

2021-01-14 Thread 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&utf8=%E2%9C%93&state=opened&label_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

2020-12-02 Thread 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)

2020-10-20 Thread 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

2020-10-09 Thread 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

2020-09-04 Thread 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&M 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&M 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&M 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&M 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)

2020-06-09 Thread 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)

2020-05-26 Thread 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)

2020-05-21 Thread 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&t=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

2020-01-08 Thread 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

2020-01-08 Thread 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

2020-01-07 Thread 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

2019-12-22 Thread 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

2019-12-12 Thread 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
>&

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

2019-11-30 Thread 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&list=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 ?

2019-08-16 Thread 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

2019-04-05 Thread 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

2019-03-30 Thread 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

2019-03-25 Thread 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

2019-01-23 Thread 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
>>> <https://www.dropbox.com/s/r1qfmk4r2oc3off/spyro_plus.py?dl=0>
>>>
>>> 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
>>>>> <https://www.dropbox.com/s/r1qfmk4r2oc3off/spyro_plus.py?dl=0> .
>>>>>
>>>>> 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
>>>>> <https://www.dropbox.com/s/6ae238njoafnqe7/example.png?dl=0>.
>>>>> * 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 

Re: [Gimp-developer] Spyrogimp plugin rewrite

2019-01-23 Thread 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
>> <https://www.dropbox.com/s/r1qfmk4r2oc3off/spyro_plus.py?dl=0>
>>
>> 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
>>>> <https://www.dropbox.com/s/r1qfmk4r2oc3off/spyro_plus.py?dl=0> .
>>>>
>>>> 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
>>>> <https://www.dropbox.com/s/6ae238njoafnqe7/example.png?dl=0>.
>>>> * 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 

Re: [Gimp-developer] AI algorithms in GIMP

2019-01-19 Thread 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

2019-01-02 Thread 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
>>>>>>  
>>>

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

2018-12-19 Thread 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
>>> som

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

2018-12-18 Thread 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

2018-12-15 Thread 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

2018-12-14 Thread 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

2018-11-18 Thread 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
> <https://www.dropbox.com/s/r1qfmk4r2oc3off/spyro_plus.py?dl=0>
>
> 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
>>> <https://www.dropbox.com/s/r1qfmk4r2oc3off/spyro_plus.py?dl=0> .
>>>
>>> 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
>>> <https://www.dropbox.com/s/6ae238njoafnqe7/example.png?dl=0>.
>>> * 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 

Re: [Gimp-developer] Spyrogimp plugin rewrite

2018-11-14 Thread 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
> <https://www.dropbox.com/s/r1qfmk4r2oc3off/spyro_plus.py?dl=0> .
>
> 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
> <https://www.dropbox.com/s/6ae238njoafnqe7/example.png?dl=0>.
> * 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

Re: [Gimp-developer] Spyrogimp plugin rewrite

2018-11-04 Thread Jehan Pagès via gimp-developer-list
Hi Elad,

I've had my mind elsewhere so haven't reviewed yet, but noticed a new GEGL
operation named "spyrograph" was added with your authorship. Does it do
everything your new plug-in does?

I guess it is probably not worth including the new plug-in if it makes it
to GEGL as a new operation instead. :-)

Jehan

On Sun, Oct 21, 2018 at 11:49 PM Elad Shahar  wrote:

> Hi Jehan,
>
> For authorship, you can use the name and email as used on this mailing
> list.
>
> On Sat, Oct 20, 2018 at 12:15 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
>>> <https://www.dropbox.com/s/r1qfmk4r2oc3off/spyro_plus.py?dl=0> .
>>>
>>
>> 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
>>> <https://www.dropbox.com/s/6ae238njoafnqe7/example.png?dl=0>.
>>> * 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
>>>>>
>>>>&

Re: [Gimp-developer] Spyrogimp plugin rewrite

2018-10-20 Thread 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
> <https://www.dropbox.com/s/r1qfmk4r2oc3off/spyro_plus.py?dl=0> .
>

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
> <https://www.dropbox.com/s/6ae238njoafnqe7/example.png?dl=0>.
> * 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 b

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

2018-09-17 Thread 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

2018-09-16 Thread 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


Re: [Gimp-developer] Spyrogimp plugin rewrite

2018-09-16 Thread Jehan Pagès via gimp-developer-list
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
___
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

2018-08-17 Thread 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

2018-08-03 Thread 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

2018-07-24 Thread 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


Re: [Gimp-developer] GIMP branched: new stable branch gimp-2-10

2018-05-22 Thread Jehan Pagès
On Tue, May 22, 2018 at 5:33 PM, Elle Stone 
wrote:

> On 05/22/2018 11:09 AM, Jehan Pagès wrote:
>
>> Gtk4 doesn't have a Mac backend AFAIK and I'm not sure it's widely tested
>>>
>> on Windows
>>
>
> Hmm, this page seems to indicate GTK+4 does/will have support for MacOs:
> https://www.phoronix.com/scan.php?page=news_item&px=GTK-3.91-Released
>
> quoting: "GTK+ 3.91 brings initial Meson build system support, GTK4 native
> support for macOS, and nearly two dozen bug fixes."
>
>
Maybe. As I said, I was only extrapolating from a single discussion on some
"social network".
In any case, the macOS backend may be there, but in a poor state
apparently, since I believe that a discussion between several contributors
of GTK+ (one of them being still a very regular contributor, and another
being the maintainer!) is definitely more trustworthy than whatever press.
:-)

Yet once again, do not take my word for it.

Jehan



> Best,
> Elle
>
> ___
> 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 branched: new stable branch gimp-2-10

2018-05-22 Thread Jehan Pagès
Hi!

On Tue, May 22, 2018 at 5:00 PM, Kristian Rietveld 
wrote:

>
> > On 22 May 2018, at 16:01, Jehan Pagès 
> wrote:
> >
> > There is another issue which was raised these days by GTK+ developers who
> > discussed GIMP port: apparently GTK+3.99 (to become GTK+4) has currently
> no
> > macOS backend! Basically that means we'd lose GIMP on macOS. And worse,
> > they have (nearly or none at all?) no developers working on this, so it's
> > not even sure when or if it will come.
>
> The macOS backend been fully removed in 3.99??
>

I have no idea. Has it been removed? Is it still here but just completely
broken and waiting to be fixed?
Or simply so untested that none really knows?

For information, I am referring to this discussion:
https://twitter.com/acruiz/status/998552715654463489
As you can see, the first message is:

> Gtk4 doesn't have a Mac backend AFAIK and I'm not sure it's widely tested
on Windows
(by Alberto Ruiz)


>
> > Actually even GTK+3 macOS port is bad but at least there is something.
> The
> > Windows backend on GTK+3 is bad too (still according to GTK+ devs) but is
> > more tested than Windows backend.
>
> I worked on the GTK+3 macOS port in the early beginning of GTK+3. I don’t
> know how much work went into it after that, I did get the impression that
> it got commits and maintenance regularly.
>
> I wasn’t really looking forward to the GTK+3 port because of this and the
> fact that the entire backend appears to have been removed doesn’t really
> make it better :(  On the other hand, it should probably be much easier to
> port GTK+3/4 to macOS compared to GTK+2.
>
>
Don't take my word for it. I was just relaying what I understood from the
Twitter thread above, which may itself not be perfectly informed.
It seems clear that the macOS backend is not that maintained though, seeing
how various GTK+ devs are clearly stating this as a fact, but I actually
guess they would not just remove years of code just on a whim (I hope so).

Jehan



>
> regards,
>
> -kris.
>
>
>
>


-- 
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 branched: new stable branch gimp-2-10

2018-05-22 Thread Jehan Pagès
Hi!

On Tue, May 22, 2018 at 1:33 PM, Simon Budig  wrote:

> Elle Stone (ellest...@ninedegreesbelow.com) wrote:
> > On 05/21/2018 11:13 AM, Jehan Pagès wrote:
> > > Just to be clear, the toolkit update here is not*just*  a necessary
> evil.
> > > It will also be totally awesome, even feature-wise!
> >
> > 
> >
> > > Simply to get there, we have to pass through an "unstable" phase,
> that's
> > > all there is to it.
> >
> > Apparently GTK+3.22 is considered "long term stable" (that is, supported
> for
> > three years? starting from when?) and is the last minor release in the
> GTK+3
> > series: https://blog.gtk.org/2016/09/01/versioning-and-long-term-
> stability-promise-in-gtk/
>
> Just to clarify, the "unstable" phase happens because we're migrating
> the toolkit, not because the toolkit we're migrating to is unstable...
>
> > Will the port from GTK+3 to GTK+4 be as difficult as the port from GTK+2
> to
> > GTK+3? Looking at various NEWS postings in the 3.93/.92/etc releases
> leading
> > up to GTK+4 (http://ftp.acc.umu.se/pub/gnome/sources/gtk+/), it looks
> like a
> > fair amount of stuff will change.
>
> I guess we'll see.


There is another issue which was raised these days by GTK+ developers who
discussed GIMP port: apparently GTK+3.99 (to become GTK+4) has currently no
macOS backend! Basically that means we'd lose GIMP on macOS. And worse,
they have (nearly or none at all?) no developers working on this, so it's
not even sure when or if it will come.

Actually even GTK+3 macOS port is bad but at least there is something. The
Windows backend on GTK+3 is bad too (still according to GTK+ devs) but is
more tested than Windows backend.

So yeah thinking about porting to GTK+4 is far too early. And anyway we
have already far enough to do. Deciding to port to a moving target (i.e.
unstable API) would be just masochistic.



> The major concern I have is related to our own ABI
> compatibility. Is there a way to decouple our ABI version from the GTK
> version? This is what forced us to stick with gtk2 for that long
> timeframe, and that sucked...
>
>
I think that is definitely a good point, and I am in favor of creating as
much high level "semantic" API as possible (when it makes sense). This
would create some boiler plate intermediate code, but is definitely worth
it on the long run IMO.

Jehan



> Bye,
> Simon
>
> --
>   si...@budig.de  http://simon.budig.de/
> ___
> 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 branched: new stable branch gimp-2-10

2018-05-21 Thread Jehan Pagès
Hi!,

On Mon, May 21, 2018 at 3:32 PM, Elle Stone 
wrote:

> Hi All,
>
> On 05/20/2018 05:23 PM, Elle Stone wrote:
>
>> On 05/20/2018 04:31 PM, Michael Natterer wrote:
>>
>>> On Sun, 2018-05-20 at 21:27 +0200, Carmelo DrRaw wrote:
>>>
 What is the recommended branch for nightly development snapshots?

 Should one provide snapshots for both master and gimp-2-10?

>>>
>>> That depends on what you want or what these snapshots are for:
>>>
>>> gimp-2-10 is where 2.10.x releases are made from.
>>>
>>> master is bleeding edge.
>>>
>>
>>
> Is current git master more or less stable for actual use? For context, I
>> started using GIMP-2.9 back in 2013 and from my point of view it was
>> already sufficiently stable. I don't mind the occasional crash (well,
>> assuming the crash doesn't destroy XCF files that aren't actually open for
>> editing).
>>
>
> Regarding which branch to use for editing (as opposed to which branch(es)
> to provide for users to choose from), over on the gimp-gui mailing list
> Jehan had this to say about the new gimp git master branch, post-merging
> with the gtk+3 branch:
>
> A note: are you actually planning on working with master? Even though
>> for the last few years, master was absolutely production-usable, this is
>> not the case with new master with GTK+3.
>>
>> A lot of stuff is broken on the GTK+3 port. As I write this, I am
>> working on the icon themes for instance which are completely broken.
>> This is not production-ready. If you want a moving target while still
>> stay usable, build "gimp-2-10" branch (which is old master). I predict
>> it will still stay quite active, much more than what the "gimp-2-8"
>> branch used to be since we will continue to backport features when
>> possible/not too hard.
>>
> I had asked on the gimp-gui mailing list about some issues with the
> GTK+3/"new git" branch GTK+3 user interface. Even apart from other stuff
> that might be broken, the current git GIMP master GTK+3 interface is not
> very nice to use, at least not as it appears on my computer. The thread is
> here, if anyone is interested:
>
> https://mail.gnome.org/archives/gimp-gui-list/2018-May/thread.html
> and click on the thread "gimp git master branch user interface".
>
> Personally I've decided to hold off switching to the "new git/GTK+3"
> branch and stick with the 2.10 branch, at least until the user interface
> issues are resolved.
>
> I guess changing toolkits is a necessary evil (eg QT4 to QT5, GTK+2 to
> GTK+3 with GTK+4 already in the wings . . . ). But it uses up a lot of
> developer time and energy, and the benefits of changing toolkits to the
> actual purposes for which we use editing software seem to me to be a bit
> iffy.
>

Just to be clear, the toolkit update here is not *just* a necessary evil.
It will also be totally awesome, even feature-wise! Without doing much, the
differences are already dramatically awesome IMO, like the simple fact that
input devices (read: graphics tablet) don't have to be activated manually,
nor plugged before running GIMP (hotplug support), etc.
Then we'll be able to add touch support (zoom, pan, rotation of canvas with
fingers).
And much more. This is very exciting.
In any case, the benefits are definitely not "iffy".

Simply to get there, we have to pass through an "unstable" phase, that's
all there is to it. The old master (which became 2.10) has had this phase
too, I can definitely tell so. When I started contributed, back in 2012, it
was absolutely unusable for daily use as well (though you say you were
already using the master build daily back in 2013, but maybe you are less
demanding as us :P). Not only unstable, but also slow as hell. Absolutely
impossible to use for painting.
This is just how software development works.
:-)

Jehan


> For a very insightful developer perspective on a comparable change in
> toolkits, when Krita went from QT4 to QT5, see this link:
>
> https://valdyas.org/fading/software/krita-3-0/
>
> Best,
> Elle
>
> On 20 May 2018, at 21:17, Michael Natterer  wrote:
>
> Hi everybody,
>
> We just branched:
>
> Stable GIMP 2.10.x lives on the new gimp-2-10 branch now.
>
> The gtk3-port branch has been merged to master, we're
> back to normal development in master again.
>
 ___
> 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

Re: [Gimp-developer] Master branch string freeze until Sunday 20th of May

2018-05-18 Thread Jehan Pagès
Hi!

On Fri, May 18, 2018 at 2:40 PM, ramir...@gmx.fr  wrote:

> On 05/18/2018 04:57 AM, Jehan Pagès wrote:
>
>>
>>
>> On Fri, May 18, 2018 at 4:53 AM, Jehan Pagès > <mailto:jehan.marmott...@gmail.com>> wrote:
>>
>> Hi,
>>
>> On Thu, May 17, 2018 at 10:35 AM, ramir...@gmx.fr
>> <mailto:ramir...@gmx.fr> mailto:ramir...@gmx.fr>>
>>
>> wrote:
>>
>> On 05/17/2018 12:42 AM, Jehan Pagès wrote:
>>
>> Hello everyone!
>>
>> We are going to release GIMP 2.10.2 with many bug fixes and
>> even a few new
>> features on the (hopeful) date of 2018/05/20.
>>
>> Hi
>> Any hope to get documentation about Gimp-2.10 new .xcf format?
>> This one is obsolete
>> https://git.gnome.org/browse/gimp/tree/devel-docs/xcf.txt
>> <https://git.gnome.org/browse/gimp/tree/devel-docs/xcf.txt>
>>
>>
>> Indeed, the XCF doc has not been much updated these last year.
>>
>> I have just now updated a bit the docs for:
>> - zlib compression (which is now a possible internal tile
>> compression);
>> - new layer modes;
>> - update in the header with the "precision" field.
>>
>> See the recent log commits:
>> https://git.gnome.org/browse/gimp/log/devel-docs/xcf.txt
>> <https://git.gnome.org/browse/gimp/log/devel-docs/xcf.txt>
>>
>> There is at least one more update relative to group mask. I will do
>> this tomorrow.
>> There are also some changes relative to endianness, but I'll have to
>> dig deeper (it looks like it was only a bug which would have touched
>> some development XCF format only).
>>
>> I will complete the docs with these 2 more information tomorrow. Now
>> I'll go to bed!
>>
>>
>> Digikam / Kimageformats  can't display new .xcf thumnails
>> created with Gimp-2.10. It seems developers need this
>> documentation to solve bug.
>> https://bugs.kde.org/show_bug.cgi?id=360821
>> <https://bugs.kde.org/show_bug.cgi?id=360821>
>>
>>
>> Give them this link:
>> https://git.gnome.org/browse/gimp/log/devel-docs/xcf.txt
>> <https://git.gnome.org/browse/gimp/log/devel-docs/xcf.txt>
>>
>>
>> P.S.: actually I gave the link on the bugtracker myself! :-)
>>
>>
>>  From the contents of recent commits, they will be able to easily
>> find the differences. That is enough to start until I complete the
>> docs.
>> It's not that much change, format-wise (though it may be quite some
>> work, because of the many new layer modes). :-)
>> Thanks for reminding us.
>>
>
> Great! Thanks for all these useful informations and all your work on Gimp.
> :)


I did more updates to the docs. For the record, I *think* the docs is now
up-to-date with all new changes in the XCF format.
If anyone thinks some stuff are still wrong in the docs, please feel free
to open bug reports (rather than emails which I may miss) explaining the
parts where things are still unclear or not right when compared to actual
XCF files.

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] Master branch string freeze until Sunday 20th of May

2018-05-17 Thread Jehan Pagès
On Fri, May 18, 2018 at 4:53 AM, Jehan Pagès 
wrote:

> Hi,
>
> On Thu, May 17, 2018 at 10:35 AM, ramir...@gmx.fr  wrote:
>
>> On 05/17/2018 12:42 AM, Jehan Pagès wrote:
>>
>>> Hello everyone!
>>>
>>> We are going to release GIMP 2.10.2 with many bug fixes and even a few
>>> new
>>> features on the (hopeful) date of 2018/05/20.
>>>
>>> Hi
>> Any hope to get documentation about Gimp-2.10 new .xcf format?
>> This one is obsolete https://git.gnome.org/browse/g
>> imp/tree/devel-docs/xcf.txt
>
>
> Indeed, the XCF doc has not been much updated these last year.
>
> I have just now updated a bit the docs for:
> - zlib compression (which is now a possible internal tile compression);
> - new layer modes;
> - update in the header with the "precision" field.
>
> See the recent log commits:
> https://git.gnome.org/browse/gimp/log/devel-docs/xcf.txt
>
> There is at least one more update relative to group mask. I will do this
> tomorrow.
> There are also some changes relative to endianness, but I'll have to dig
> deeper (it looks like it was only a bug which would have touched some
> development XCF format only).
>
> I will complete the docs with these 2 more information tomorrow. Now I'll
> go to bed!
>
>
>> Digikam / Kimageformats  can't display new .xcf thumnails created with
>> Gimp-2.10. It seems developers need this documentation to solve bug.
>> https://bugs.kde.org/show_bug.cgi?id=360821
>>
>
> Give them this link: https://git.gnome.org/browse/gimp/log/devel-docs/
> xcf.txt
>

P.S.: actually I gave the link on the bugtracker myself! :-)


> From the contents of recent commits, they will be able to easily find the
> differences. That is enough to start until I complete the docs.
> It's not that much change, format-wise (though it may be quite some work,
> because of the many new layer modes). :-)
> Thanks for reminding us.
>
> Jehan
>
>
>> Thanks
>> ___
>> 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] Master branch string freeze until Sunday 20th of May

2018-05-17 Thread Jehan Pagès
Hi,

On Thu, May 17, 2018 at 10:35 AM, ramir...@gmx.fr  wrote:

> On 05/17/2018 12:42 AM, Jehan Pagès wrote:
>
>> Hello everyone!
>>
>> We are going to release GIMP 2.10.2 with many bug fixes and even a few new
>> features on the (hopeful) date of 2018/05/20.
>>
>> Hi
> Any hope to get documentation about Gimp-2.10 new .xcf format?
> This one is obsolete https://git.gnome.org/browse/g
> imp/tree/devel-docs/xcf.txt


Indeed, the XCF doc has not been much updated these last year.

I have just now updated a bit the docs for:
- zlib compression (which is now a possible internal tile compression);
- new layer modes;
- update in the header with the "precision" field.

See the recent log commits:
https://git.gnome.org/browse/gimp/log/devel-docs/xcf.txt

There is at least one more update relative to group mask. I will do this
tomorrow.
There are also some changes relative to endianness, but I'll have to dig
deeper (it looks like it was only a bug which would have touched some
development XCF format only).

I will complete the docs with these 2 more information tomorrow. Now I'll
go to bed!


> Digikam / Kimageformats  can't display new .xcf thumnails created with
> Gimp-2.10. It seems developers need this documentation to solve bug.
> https://bugs.kde.org/show_bug.cgi?id=360821
>

Give them this link:
https://git.gnome.org/browse/gimp/log/devel-docs/xcf.txt
From the contents of recent commits, they will be able to easily find the
differences. That is enough to start until I complete the docs.
It's not that much change, format-wise (though it may be quite some work,
because of the many new layer modes). :-)
Thanks for reminding us.

Jehan


> Thanks
> ___
> 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] Master branch string freeze until Sunday 20th of May

2018-05-16 Thread Jehan Pagès
Hello everyone!

We are going to release GIMP 2.10.2 with many bug fixes and even a few new
features on the (hopeful) date of 2018/05/20.

Therefore I am announcing a string freeze on the master branch until this
date.

This means that we ask all developers to not add or modify any string on
master until the release of GIMP 2.10.2 is effective. If you have a pending
patch with string changes, please do not push it and wait a few days. You
will be able to push it after we announced the release.

Announcement on the gnome-i18n mailing list:
https://mail.gnome.org/archives/gnome-i18n/2018-May/msg00031.html

Thank you everyone!

Jehan
GIMP

-- 
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] libmypaint version for building GIMP-2.10.0

2018-04-27 Thread Jehan Pagès
Hi!

On Fri, Apr 27, 2018 at 7:18 PM, Carmelo DrRaw 
wrote:

> Dear all,
>
> I am currently stuck with what seems to be a version dependency conflict
> between GIMP and libmypaint-1.3.0.
>
> GIMP requires GEGL >= v0.4.0, however libmypaint still requires GEGL
> v0.3.x:
>
> checking for GEGL... no
> configure: error: Package requirements (gegl-0.3 >= 0.3) were not met:
>
> No package 'gegl-0.3' found
>
>
> This happens because GEGL v0.4.x only provides gegl-0.4.pc
>
>
Which is normal, since it is GEGL 0.4, not 0.3. ;-)

And yes, you are right. The GEGL dependency in libmypaint is GEGL v0.3, and
I am not sure that will change soon, since libmypaint developers are mostly
working on libmypaint v2 now. You can still ask them if they would make a
libmypaint v1 with updated GEGL dep.

BUT for the time being, it is not much a problem because (1) GEGL v0.3 and
v0.4 can be installed next to each other (hence the different namespace)
and (2) you don't have to build libmypaint with GEGL. libmypaint-gegl is
not used by GIMP in any way to this day.
So just build libmypaint with --disable-gegl and don't care about
installing GEGL v0.3.


> I am using the latest official release of libmypaint:
> https://github.com/mypaint/libmypaint/releases/download/
> v1.3.0/libmypaint-1.3.0.tar.xz  libmypaint/releases/download/v1.3.0/libmypaint-1.3.0.tar.xz>
>
>
libmypaint version is right. This is the GEGL version whose version you did
not correctly installed.

Jehan


> Should I use a specific commit instead?
>
> Thanks a lot!
> ___
> 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.pc.in still contains reference to gegl-0.3

2018-04-27 Thread Jehan Pagès
Hi!

On Fri, Apr 27, 2018 at 8:55 PM, Jean-Luc Coulon (f5ibh) <
jean.luc.cou...@gmail.com> wrote:

> Hi,
>
> The git repository file gimp.pc.in still contains reference to gegl-0.3.
>


Thanks for noticing this! I fixed this just now.

Jehan


> This prevents some software using gimtool to be built against new version
> of gimp/gegl.
> This is the cas of gmic for instance.
>
> Regards
>
> Jean-Luc
> ___
> 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] Build Error

2018-04-04 Thread Jehan Pagès
Hi,

On Wed, Apr 4, 2018 at 11:43 AM, Darshan kadu  wrote:

> Hello,
>
> I am building the GIMP, But I am getting this error https://pastebin.ca/
> 4010673
>
> I have updated the gegl and babl.
>
> What can be the reason?
> Is it because of dependency issues or the error is in the latest GIMP code?
>
>

Also update babl and GEGL from master too before GIMP.

Jehan



> Regards,
> Darshan
>



-- 
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] GSoC project query

2018-03-29 Thread Jehan Pagès
Hi!

For the record, our would-be intern had a job proposal, and therefore had
to cancel his GSoC proposition. He even asked me if that is OK, and
obviously I told him to do what's best for him!

Anyway this was quite interesting to see a bit the possibilities for GSoC.
Maybe next year, we'll try "for real", telling people beforehand we wish to
participate, etc. If once again I am the only available mentor, I might
once more integrate into another project, like GNU.

Also for anyone disappointed, I would like to reassure you: if there is one
thing that should be learned from past GSoC participation of GIMP, it is
that GSoC is far from the best way to improve a software. Personally I am
mostly interested in it because it is nice to help some students discover
real development world and mentor them. And maybe these students will even
stay regular contributors *afterwards*! If we can get a few cool patches in
the process, this is cool. But this event should not be considered as a
cheap way to get code. Any project which relies mostly on this to improve
will mostly get hardly maintainable code.

When I see how some people seem to see GSoC as a miraculous event which we
should absolutely join, I am a bit dubious on how you envision this event.
Whatever your job is, picture yourself when you were student. Now imagine
that you suddenly dropped your student self into your current position
which you are in after years of hard work and learning the job though
actual real-life projects, successes and failures. Do you really believe
that your student self would have just revolutionnized your current job in
just a few months? I hope you don't say yes, because that would be a bit
sad if you don't believe you evolved since you were students! ;p

In the end, whatever the regular developers do in the same time as any
intern is 100 times more important, and I remind that some of us (including
myself) are even trying to make a living from GIMP development through
crowdfunding with quite weak success for now. Just a small reminder so that
people know they can crowdfund us (in case of my own project, all links in
my signature) which will be more efficient for any of the goals you
proposed in this thread or others than what GSoC could bring us (even if
still a cool event, but for helping good students mostly, as I said, not
for magically cheap, fast and quality code).

Have fun everyone!

Jehan


On Tue, Mar 6, 2018 at 7:50 PM, Joseph Bupe  wrote:

> I would be happy to see free-angled guides implemented. These can be handy
> in many situations for graphics designing.
>
> Something started a couple of years back
> https://bugzilla.gnome.org/show_bug.cgi?id=344109
>
> On 6 March 2018 at 17:21, C R  wrote:
> > Is it possible to task the student(s) with getting more GEGL integration?
> > GIMP really needs that to speed up image processing and previews.
> >
> > I mean like REALLY REALLY needs that more than just about any new toys
> > they can dream up. :)
> >
> > My 2p.
> > -C
> >
> > On Mon, Mar 5, 2018 at 11:32 PM, Alexandre Prokoudine
> >  wrote:
> > > On Tue, Mar 6, 2018 at 2:04 AM, Kevin Cozens wrote:
> > >
> > >> Having read the above I had the idea that it could be worth having a
> > student
> > >> work on one or more of the previous GSoC projects
> > >
> > > Google is usually extremely unhappy with this.
> > >
> > > Alex
>


-- 
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 at Apple Developer Program

2018-03-27 Thread Jehan Pagès
Hi!

On Tue, Mar 27, 2018 at 9:21 AM, Kristian Rietveld 
wrote:

>
> > On 27 Mar 2018, at 03:25, Jehan Pagès 
> wrote:
> >
> > But right now, we are discussing paying to distribute a version of GIMP
> > which is barely kept alive. This is a bit doing things in the wrong order
> > IMO.
>
> In fact, I think this is the main point. Even in the case we do decide to
> pay for an account, we need to incorporate this into our build system. And
> I consider it more important to first get regular 2.10 builds off the
> ground than to produce signed binaries.
>
> [I am near having a script that completely automates the build and DMG
> creation. I wanted to have 2.10 DMGs available already, but unfortunately
> due to some family related events early this year I had to stall his work
> for a while. It is my intention to pick it up again now].
>
>
I just wanted to add that Kris is the person who makes things happen in
GIMP for macOS. As far as I am concerned, as said earlier, he is therefore
the one who should call the shots regarding such macOS build questions,
rather than a vote (unless he wants to decide through a vote himself)
because in the end, he is the one who has to make the grunt work here (as a
volunteer, I remind).

Jehan


>
> I voted “I don’t care”, because manually enabling the binary is in my
> opinion a minor nuisance to some of the other issues that need fixing. Also
> I don’t need this feature myself, but if the community wants to see this
> fixed I can look into it.
>
>
> regards,
>
> -kris.
>
>


-- 
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 at Apple Developer Program

2018-03-26 Thread Jehan Pagès
Hi!

On Mon, Mar 26, 2018 at 6:08 PM, Ofnuts  wrote:

> On 03/26/18 00:45, alexandre.prokoud...@gmail.com wrote:
>
>> I've invited you to fill out the following form:
>> Participation at Apple Developer Program
>>
>> To fill it out, visit:
>> https://docs.google.com/forms/d/e/1FAIpQLSdRepYcE1dLD0342FaV
>> GenU0Nr519SyK-MYzdGylmNXYq5rUQ/viewform?c=0&
>> amp;w=1&usp=mail_form_link
>>
>> Hi.
>>
>> We'd like to know opinions of all developers and contributors of
>> GIMP, but not everyone is on IRC. Please vote :)
>>
>> P.S. Collecting emails in this form is disabled. It's safe to vote.
>>
>> Alex
>>
>
> Did we try to get in touch with Apple developer relations and see if they
> would give us a rebate or even complete waive the fee? That would be good
> PR for them...
>
>
For the record, I did try to get in touch with Apple some time ago (may
have been a year ago, or more, or less, I don't remember), and I didn't get
any answer.
Or maybe I had an answer to a first email who told me to send an email to
another address, but I didn't get an answer from this second contact. Or
something like that, I can't remember exactly.

Bottom line: they don't care, and they didn't answer.

I feel that anyone who believes that Apple would even care about us is
misled. What are we compared to Apple? Nothing. Seriously what is the PR
for them here?
Now I'm happy to be wrong. Maybe I wrote to the wrong contacts (I don't
know anyone from the "inside", and simply tried to get through the official
contact media). Maybe they would sponsor. Maybe they would even donate more
as João believes possible. I don't believe so, but I may just be
pessimistic.

As for answering, I think I will just vote "I don't care".

But really for me, this is hiding the real issue: we have barely no macOS
developers. We have mostly a single dev caring for macOS, but his time is
very limited (which is not a problem, everyone has one's priority and he
does already a lot). For instance, 10 days ago, I made some changes to
macOS code, hoping for a macOS developer or one of third party packagers to
test the change. Nothing happened until today, just before the release (as
expected, things needed to be fixed).
So it looks a bit funny to me to be discussing how to better package for an
OS when we have nearly none to improve things for this said OS.

What I would love is for people who wants GIMP on macOS to actually *care*
for their OS (not "care" by *saying* "I care" but by actual action, i.e.
the real meaning of "caring"). If we had a few developers fixing regularly
GIMP for macOS, improving things, etc. then these people would want to get
a proper signed package for this platform, I'd be happy for us to have an
official account, even if I completely agree with Mitch that it is really
garbage that we have to pay for real good and clean Free Software; this is
shameful from this company. Yet if we have actual people giving of their
time, and really showing their care, I'd still say It would make sense.

But right now, we are discussing paying to distribute a version of GIMP
which is barely kept alive. This is a bit doing things in the wrong order
IMO.

Jehan

P.S.: most of what I said can be said for the Windows build too. Well
actually we seem to have slightly more love for this build, yet barely.
Only GIMP on GNU/Linux (and *BSD seems to have people watching closely too)
is actually very well maintained with a huge flow of fixes and improvements.



> ___
> 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] GSoC project query

2018-03-05 Thread Jehan Pagès
Hi!

On Mon, Mar 5, 2018 at 11:09 PM, Elle Stone
 wrote:
> On 03/05/2018 03:54 PM, Jehan Pagès wrote:
>>
>> Now we have to decide of a good project for GIMP/Darshan since GSoC
>> needs us to decide this first. Note that, as already said previously,
>> I am more in favor of feasible and more concrete projects for GIMP,
>> even though maybe less fancy looking that what we used to have for
>> GSoC. Something which will definitely end up in GIMP in the end.:-)
>
>
> Some suggestions focused on painting and color management:
>
> * Better LCH support including high bit depth LCH palettes (to replace
> current 8-bit sRGB palettes) and gradients, plus for the color pickers
> outlines showing LCH vs the user-selected RGB color space at any given
> Lightness value, and showing complements/color harmonies.
>
> * Improved soft proofing to compensate for deficiencies in LCMS soft
> proofing.
>
> * Improved painting assets in general, including brushes and brush dynamics,
> building on Americo's work on improving painting assets, and addressing a
> bunch of painting-related bug reports.

This is typically the kind of projects which are both "easy"
technically, but actually difficult to do right. Because it is not
only about stacking up various brushes which look cool and have as
many as possible in GIMP (especially in current situation where brush
management is so shitty that it is not a good idea to have too many).

We are discussing the topic with Aryeom and Americo and this is quite
harder than I thought it would be (I am the one who originally
proposed Americo to work on it).

So I definitely don't want to give this to a student. We will stick to
working with the artists who use them.

> * High bit depth brushes - Cinepaint supported 16-bit brushes, but it would
> probably be more efficient for GIMP to go straight to 32f brushes.

Interesting. Since everything is 32-bit internally already, will it
contribute to make painting faster as well?

> * An HDR viewer and improved HDR editing capabilities.
>
> * OCIO color management
>
> * Improved support for AnyRGB and AnyTRC.
>
> * Adding JCH and CIECAM02 support, following the lead set by RawTherapee's
> extensive and incredibly useful (for artistic purposes as well as
> compensating for viewing conditions) CIECAM02 support.

If you want to contribute ideas, you can add them to the wiki:
https://wiki.gimp.org/wiki/Hacking:GSoC/2018/Ideas
Please if you do so, if you could add some explanatory links too, that
would be awesome, because I would not be able to implement several of
your propositions without some serious reading myself.

Remember that this is for a student. The main reason why GIMP stopped
doing GSoC is because we were giving the students very awesome
projects, and even though the final results were very cool
proof-of-concepts (so the students did do very good work), they were
not finished (either extremely buggy, with bad standard code, or so
slow that it was unusable on real data, etc.) and they had been a dead
weight to the GIMP project for years (even nowadays, some older
student projects are still making issues).

Well that is from a time where I barely started contributing myself,
so I am just telling what I gathered, and basically I want to try and
take into account the "elder's" experience (old farts! ;p) to really
get something good out of such a project. That may mean less ambitious
ideas (which does not mean they are not just as important for GIMP!).
:-)

Jehan

> Best,
> Elle
>
> ___
> 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] GSoC project query

2018-03-05 Thread Jehan Pagès
Hi!

On Sun, Mar 4, 2018 at 2:01 PM, Jehan Pagès  wrote:
> Hi!
>
> On Sun, Mar 4, 2018 at 1:28 PM, Alexandre Prokoudine
>  wrote:
>> On Sun, Mar 4, 2018 at 1:37 PM, Darshan  kadu wrote:
>>> Hello,
>>>
>>> I am Darshan Kadu Intern at FSF working on GNU GIMP as the task of the
>>> internship.
>>>
>>> I would like to contribute to the GNU GIMP as part of GSoC also, as GNU is
>>> participating too.
>>>
>>> But I don't see the page giving any description of the project.
>>> So does that means I cant contribute to GIMP for GSoC?
>>> If yes how to proceed further?
>>
>> Hi Darshan,
>>
>> We are not participating at GSoC as a standalone organisation, and we
>> haven't discussed doing it under any umbrella project with any
>> umbrella project.
>
> As Prokoudine said, we have not any plan doing this yet, but I would
> not be against. You should ask people at GNU if they would accept to
> give us a slot. They are the only one who would be able to tell you if
> it is ok.

For the record, GNU accepted our request, and invited me as a mentor.
So I am now subscribed as a GSoC mentor for GNU.
This does not gives us automatically a slot. I assume in the end, the
choice will depend on how many slots are given to GNU. We'll see.

Since there is a slight overlap in the schedule of the current FSF
internship and GSoC, I asked the FSF contacts if that would be a
problem. Since having Darshan as a GSoC student would be beneficial to
both GIMP (longer contribution from Darshan) and Darshan himself, they
said that would not be a problem to wrap up the FSF internship earlier
if our project got accepted for GSoC.

Now we have to decide of a good project for GIMP/Darshan since GSoC
needs us to decide this first. Note that, as already said previously,
I am more in favor of feasible and more concrete projects for GIMP,
even though maybe less fancy looking that what we used to have for
GSoC. Something which will definitely end up in GIMP in the end. :-)

Jehan

>> P.S. We are GIMP, not GNU GIMP :)
>
> Indeed. The first 'G' already means "GNU". You were basically
> repeating: GNU GNU Image Manipulation Program. ;p
>
> 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



-- 
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] GSoC project query

2018-03-04 Thread Jehan Pagès
Hi!

On Sun, Mar 4, 2018 at 1:28 PM, Alexandre Prokoudine
 wrote:
> On Sun, Mar 4, 2018 at 1:37 PM, Darshan  kadu wrote:
>> Hello,
>>
>> I am Darshan Kadu Intern at FSF working on GNU GIMP as the task of the
>> internship.
>>
>> I would like to contribute to the GNU GIMP as part of GSoC also, as GNU is
>> participating too.
>>
>> But I don't see the page giving any description of the project.
>> So does that means I cant contribute to GIMP for GSoC?
>> If yes how to proceed further?
>
> Hi Darshan,
>
> We are not participating at GSoC as a standalone organisation, and we
> haven't discussed doing it under any umbrella project with any
> umbrella project.

As Prokoudine said, we have not any plan doing this yet, but I would
not be against. You should ask people at GNU if they would accept to
give us a slot. They are the only one who would be able to tell you if
it is ok.

> P.S. We are GIMP, not GNU GIMP :)

Indeed. The first 'G' already means "GNU". You were basically
repeating: GNU GNU Image Manipulation Program. ;p

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] FSF spring internship applicant looking for a GNU project

2018-02-13 Thread Jehan Pagès
Hi Darshan,

On Tue, Feb 13, 2018 at 5:42 PM, Darshan  kadu  wrote:
> Thank you for offering me the project.
>
> Can you just tell me the time at which you will be active on IRC?

I just left IRC because I need to head out. I'll try to be there
tomorrow most of the day, from afternoon to evening (CET).
Unless you want to make some kind of "appointment" at a specific time
to discuss.
Regards,

Jehan

> I have some questions regarding the project!
>
> --Darshan



-- 
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] Trouble building Gimp from GIT repo

2018-02-11 Thread Jehan Pagès
Hello,

On Mon, Feb 12, 2018 at 1:03 AM, Steven P. Ulrick  wrote:
>
>
> On 02/11/2018 10:03 AM, Kevin Cozens wrote:
>>
>> On 2018-02-11 05:48 AM, Steven P. Ulrick wrote:
>>>
>>> I also have libmypaint installed from GIT. It's "libmypaint-2.0.pc" file
>>> says the following:
>>>
>>> Version: 2.0.0
>>>
>>> "rpm -qa | grep -i mypaint" says the following:
>>
>> [snip]
>>>
>>> My custom installs of BABL and GEGL are both accepted versions, and they
>>> ARE detected by GIMP.
>>
>>
>> I ran across the same problem with mypaint. After you clone the mypaint
>> repo you need to checkout the 1.3 branch and built it. GIMP won't let you
>> use the 2.0 version.
>>
>
> Hello, Kevin
> Are you referring to libmypaint?  I know that I was unclear in my original
> email. I just built and installed libmypaint-1.3.0 and GIMP is happy with
> that...  But, libmypaint does not appear to have the brushes that are
> contained in mypaint.
> This is the only error I am getting right now:
>   - Error: missing dependency mypaint-brushes-1.0

It is better to read the INSTALL file when you are building a software. :-)
Or in the case of GIMP, If you build from git repository, then read
INSTALL.in instead. Everything is explained.

As you note yourself, libmypaint do not contain MyPaint brushes, which
is a problem. This is why mypaint-brushes is a separate package. It is
available in https://github.com/Jehan/mypaint-brushes
Install the branch v1.3.x and make sure that your PKG_CONFIG_PATH is
well set (once again, everything is explained in details in
INSTALL.in).

> I have the appropriate RPM installed, and the brushes are located at
> "/usr/share/mypaint/brushes" but GIMP does not see them...

Yes these are installed with MyPaint, but this is a problem because:

(1) it makes MyPaint a defacto dependency to GIMP since we use
libmypaint (which is useless without brushes).
(2) there is no way to know where the brushes are but guessing. This
is what we were doing previously trying various common places (/usr,
/usr/local, etc.). But this is not an acceptable solution. We need to
know where each of our dependencies are actually installed with
certainty.

This is why we have a separate package which hopefully will be used
also soon by every project using libmypaint out there (instead of
duplicating these data everywhere! For instance, I read that it is
what OpenToonz is doing: they just ship MyPaint brushes which is not a
good idea).

Jehan

> Thank you,
> Steven P. Ulrick
> ___
> 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] FSF spring internship applicant looking for a GNU project

2018-02-09 Thread Jehan Pagès
Hello Darshan,

On Thu, Feb 8, 2018 at 6:41 PM, Darshan  kadu  wrote:
> Hello everyone,
>
> I am Darshan Kadu, a 4th-year student at VNIT, Nagpur, India,
> I am an FSF internship applicant for the spring.  I do have experience in
> C, C++. Previously, I have worked with Blende in GSoC'17. I would like to
> contribute to the GIMP during the internship.

That's interesting. How does the FSF internship work exactly? Does it
require GIMP to assign any mentor too or are you mentored solely
within the FSF?

> I am ready to work for 30-40 hrs/week.
>
> I have attached my resume.

The mailing list drops every attachment, so we didn't receive it.

> Can you suggest me any project or series of task to work on?

Well there are many topics of interest. What are you the most
interested by? There are lower level work on graphics algorithm and
stuff, in which case, that would be rather work on GEGL. If you want
to work on GIMP itself, I wrote for instance a few quick ideas the
other day (when we considered participating to gsoc with GNOME, though
I'm not sure this will happen):
https://wiki.gimp.org/wiki/Hacking:GSoC/2018/Ideas

Someone else (right now on a discussion in IRC; I think he said he
sent an answer too but I don't see it) was interested in someone
working on our API using GObject Introspection to allow more language
support. Why not.

These ideas are obviously not exhaustive. If you have yourself other
topics which interest you, we can discuss.
Only thing is that we prefer small yet solid work which can be merged
at the end of your internship rather than an awesome yet very
complicated feature "on-paper", which only ends as a demo in the end
and is never finished by anyone.
We have had some mitigated gsoc experience and some code from gsoc
students are still rotting around after several years.

Anyway yes, we are interested. :-)
We can continue discussing here, you can also drop on IRC (#gimp at
irc.gimp.org), and we can also discuss privately if needed be.

Jehan

> Thank you.
> Darshan
> ___
> 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] Why is the 0.44 version of poppler required?

2018-02-09 Thread Jehan Pagès
Hello,

On Wed, Feb 7, 2018 at 6:03 PM, Kevin Cozens  wrote:
> Greetings.
>
> The subject line of this message is the short version of this email.

A bit of git log searching gives the response to this:

commit b249a998aaa57fc85975dc5dd14088f125a82930
Author: Michael Natterer 
Date:   Mon Nov 7 16:00:52 2016 +0100

Bug 763214 - Wrong rendering of shadings in PDF imports...

...(in libpoppler -> requires a more recent version)

Require libpoppler >= 0.44.0 which contains a fix for this bug.

> The git master version of GIMP requires the 0.44 version of poppler. That
> version is not available for the 18.3 (latest) version of Linux Mint. I

Note that git *master* is not supposed to follow whatever is in the
stable distributions. We may have some advance, which is normal for a
development version. If ever we limited ourselves to what is in any
distribution *currently*, then *that* would be the start for problems.

In any case, as a general rule, it is better to have state-of-the art
versions of everything since they are supposed to get better (but for
exception and regression bugs).

> modified the configure.ac file to require the 0.41 version of poppler. I ran
> distclean and a full build of GIMP and had no compile errors. I have not
> seen any problems running GIMP with this older version of poppler.

Yeah as the git message says, that's not a change of API or anything.
So it would work. But then you may encounter bugs in rendering of
shadings. Or not. We don't take the chance. :-)

Jehan

> --
> Cheers!
>
> Kevin.
>
> http://www.ve3syb.ca/   |"Nerds make the shiny things that distract
> Owner of Elecraft K2 #2172  | the mouth-breathers, and that's why we're
> | powerful!"
> #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] GEGL errors during 'make' process

2018-02-03 Thread Jehan Pagès
Hi!

On Sun, Feb 4, 2018 at 1:37 AM, Americo Gobbo  wrote:
> Hi Jehan,
>
> On 03/02/2018 22:23, Jehan Pagès wrote:
>>
>> Well I'm lost.
>
> ;-) me too!
>>
>> Are you sure you did a build from a fresh start? No
>> files at all from a previous build?
>> You can run `git clean -dfx` to erase every file from the repository
>> which are not in git (be careful not to run it carelessly and erase
>> important personal files!).
>
> So, I have the attention to apply 'git clean -xdf' first.
> I don't have personal files only the remote files of git clone updated.
>
>> Other than this, I really have no idea with only this.
>> But if you still have the error, please run `make V=1`. This will make
>> the build verbose and tell exactly which command was run. But first,
>> you should make sure you did a fresh build, really from scratch.
>
> this is the output, final parte of 'make V=1':
>
> mv -f .deps/gegl-path-spiro.Tpo .deps/gegl-path-spiro.Po
> /bin/bash ../libtool  --tag=CC   --mode=link gcc -pthread
> -I/opt/gimp-default-master/include/gio-unix-2.0/
> -I/opt/gimp-default-master/include/glib-2.0
> -I/opt/gimp-default-master/lib/glib-2.0/include -I/usr/include/json-glib-1.0
> -I/opt/gimp-default-master/include/babl-0.1
> -I/opt/gimp-default-master/include/libpng16
> -I/opt/gimp-default-master/include
> -I/opt/gimp-default-master/include/glib-2.0
> -I/opt/gimp-default-master/lib/glib-2.0/include  -std=gnu99 -fPIC -mmmx
> -msse -ftree-vectorize -ffast-math -Wall -Wdeclaration-after-statement
> -Wmissing-prototypes -Wmissing-declarations -Winit-self -Wpointer-arith
> -Wold-style-definition  ../gegl/libgegl-0.3.la
> -L/opt/gimp-default-master/lib -Wl,--export-dynamic -lgmodule-2.0 -pthread
> -ljson-glib-1.0 -lgio-2.0 -lgobject-2.0 -lgthread-2.0 -pthread -lglib-2.0
> -L/opt/gimp-default-master/lib -lbabl-0.1 -L/opt/gimp-default-master/lib
> -lpng16 -lspiro -lm -L/opt/gimp-default-master/lib -lgexiv2 -lgobject-2.0
> -lglib-2.0 -o gegl gegl.o gegl-options.o gegl-path-smooth.o
> gegl-path-spiro.o
> libtool:   error: cannot find the library '/usr/local/lib/libexiv2.la' or
> unhandled argument '/usr/local/lib/libexiv2.la'
> Makefile:571: recipe for target 'gegl' failed
> make[2]: *** [gegl] Error 1
> make[2]: Leaving directory '/home/jag/devel/gimp-default-master-/gegl/bin'
> Makefile:634: recipe for target 'all-recursive' failed
> make[1]: *** [all-recursive] Error 1
> make[1]: Leaving directory '/home/jag/devel/gimp-default-master-/gegl'
> Makefile:541: recipe for target 'all' failed
> make: *** [all] Error 2

Well there is nothing in the command line itself which relates to
libexiv2. It looks like there is something wrong in the libtool script
wrapper generated by the build system. Delete the file "libtool" which
you will find in the root of the git repository. Then run the
configure script again (this will create again the libtool wrapper),
then make and let's see what happens.

Jehan

> ===
> ciao
> americo
>
>

-- 
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] GEGL errors during 'make' process

2018-02-03 Thread Jehan Pagès
On Sun, Feb 4, 2018 at 1:14 AM, Americo Gobbo  wrote:
> Hi Jehan,
>
> On 03/02/2018 22:06, Jehan Pagès wrote:
>>
>> Hi!
>>
>> On Sun, Feb 4, 2018 at 12:59 AM, Americo Gobbo 
>> wrote:
>>>
>>> Hi Jehan,
>>> I have used the git repository to build.
>>> config.log is of my traditional environment to gegl
>>> config-new.log is of a ex-novo environment to gegl to test if was making
>>> something wrong in the traditional env.
>>
>> Both seem fine. pkg-config does not seem to detect any exiv2 in
>> /usr/local/.
>> Are the build still broken and outputting the same errors?
>>
>> Jehan
>
> This is final of my 'make' messages:
>
>   CCLD gegl
> libtool:   error: cannot find the library '/usr/local/lib/libexiv2.la' or
> unhandled argument '/usr/local/lib/libexiv2.la'
> Makefile:571: recipe for target 'gegl' failed
> make[2]: *** [gegl] Error 1
> make[2]: Leaving directory '/home/jag/devel/gimp-default-master-/gegl/bin'
> Makefile:634: recipe for target 'all-recursive' failed
> make[1]: *** [all-recursive] Error 1
> make[1]: Leaving directory '/home/jag/devel/gimp-default-master-/gegl'
> Makefile:541: recipe for target 'all' failed
> make: *** [all] Error 2
> ---
>
> In fact the archives are installed in another directory
>
> '/usr/lib/x86_64-linux-gnu/' instead that '/usr/local/lib/'

Well I'm lost. Are you sure you did a build from a fresh start? No
files at all from a previous build?
You can run `git clean -dfx` to erase every file from the repository
which are not in git (be careful not to run it carelessly and erase
important personal files!).

Other than this, I really have no idea with only this.
But if you still have the error, please run `make V=1`. This will make
the build verbose and tell exactly which command was run. But first,
you should make sure you did a fresh build, really from scratch.

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] GEGL errors during 'make' process

2018-02-03 Thread Jehan Pagès
Hi!

On Sun, Feb 4, 2018 at 12:59 AM, Americo Gobbo  wrote:
> Hi Jehan,
> I have used the git repository to build.
> config.log is of my traditional environment to gegl
> config-new.log is of a ex-novo environment to gegl to test if was making
> something wrong in the traditional env.

Both seem fine. pkg-config does not seem to detect any exiv2 in /usr/local/.
Are the build still broken and outputting the same errors?

Jehan

> ciao
> americo
>
>
>
> On 03/02/2018 21:38, Jehan Pagès wrote:
>>
>> Were you building inside the git repository or in a separate
>> directory? In the second case, make sure the build directory is empty.
>> Could you send us the contents of "config.log"? Since gexiv2 and exiv2
>> are looked up with pkg-config, it will allow us to see what was
>> detected too.
>>
>> Since you can't attach a file, just copy-paste its contents somewhere,
>> for instance athttps://paste.gnome.org/
>> Thanks!
>
>



-- 
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] GEGL errors during 'make' process

2018-02-03 Thread Jehan Pagès
Hi Americo!

On Sat, Feb 3, 2018 at 2:45 PM, Americo Gobbo  wrote:
> Hi Tobias,

 Hi All,
 I have upgrade my system to ubuntu gnome 16.04.3 and I have tried again
 compile GEGL. The 'autogen.sh' is finished OK, without problems.
 The 'make' process have these errors messages:

 gcc: error: /usr/local/lib/libexiv2.so: No such file or directory
 Makefile:571: recipe for target 'gegl' failed
 make[2]: *** [gegl] Error 1
 make[2]: Leaving directory
 '/home/jag/devel/gimp-default-master/gegl/bin'
 Makefile:634: recipe for target 'all-recursive' failed
 make[1]: *** [all-recursive] Error 1
 make[1]: Leaving directory '/home/jag/devel/gimp-default-master/gegl'
 Makefile:541: recipe for target 'all' failed
 make: *** [all] Error 2

 Someone can give some suggestion?
>>>
>>> Is that a fresh git clone or did you compile in the directory before?
>
> I have a made a fresh git clone of 'gegl' and it results the same error...
> is a bit odd :-)

Were you building inside the git repository or in a separate
directory? In the second case, make sure the build directory is empty.
Could you send us the contents of "config.log"? Since gexiv2 and exiv2
are looked up with pkg-config, it will allow us to see what was
detected too.

Since you can't attach a file, just copy-paste its contents somewhere,
for instance at https://paste.gnome.org/
Thanks!

Jehan

> Perhaps, the problem is on my environment setup script?
>
> PREFIX=/opt/gimp-default-master
> export PATH=$PREFIX/bin:$PATH
> export LD_LIBRARY_PATH=$PREFIX/lib:$LD_LIBRARY_PATH
> export XDG_DATA_DIRS=$PREFIX/share:$XDG_DATA_DIRS
> export ACLOCAL_FLAGS="-I $PREFIX/share/aclocal"
> export PKG_CONFIG_PATH=$PREFIX/lib/pkgconfig:$PKG_CONFIG_PATH
> export GIO_EXTRA_MODULES=/usr/lib/x86_64-linux-gnu/gio/modules
> export SRC_DIR=$HOME/devel/gimp-default-master/gimp-2.9/build
> export CFLAGS='-std=gnu99 -fPIC'
> export LESS="-F -X -R"
>
> ___
> 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-git pull today fails to build - Mac

2018-02-03 Thread Jehan Pagès
Hi!

On Fri, Feb 2, 2018 at 5:50 PM, Partha Bagchi  wrote:
> On Fri, Feb 2, 2018 at 5:36 AM, Michael Natterer  wrote:
>
>> Hi Partha,
>>
>> you might need the right CPPFLAGS and LDFLAGS in tools/Makefile.am,
>> it doesn't look like they are there.
>>
>> Can you try that so it builds and then send a patch please?
>>
>> Thanks, Mitch
>> ...
>>
>
> Hi Mitch,
>
> I think the LDFLAGS is fine. However, we need to patch 2 files I believe:
> tools/Makefile.am and app/widgets/Makefile.am

Highly possible. The code was untested on macOS for lack of developer
availability.

> I've created a patch (attached), though I'm not sure if it's in the right
> format? :(

The mailing list doesn't accept attachment. Just make a git-formatted
patch please (git format-patch origin/master).

> Where should I upload it?

https://bugzilla.gnome.org/enter_bug.cgi?product=GIMP

Jehan

> Thanks,
> Partha
> ___
> 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

On Fri, Feb 2, 2018 at 5:50 PM, Partha Bagchi  wrote:
> On Fri, Feb 2, 2018 at 5:36 AM, Michael Natterer  wrote:
>
>> Hi Partha,
>>
>> you might need the right CPPFLAGS and LDFLAGS in tools/Makefile.am,
>> it doesn't look like they are there.
>>
>> Can you try that so it builds and then send a patch please?
>>
>> Thanks, Mitch
>> ...
>>
>
> Hi Mitch,
>
> I think the LDFLAGS is fine. However, we need to patch 2 files I believe:
> tools/Makefile.am and app/widgets/Makefile.am
>
> I've created a patch (attached), though I'm not sure if it's in the right
> format? :(
>
> Where should I upload it?
>
> Thanks,
> Partha
> ___
> 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] Compiling GIMP-2.9 with the new mypaint requirements

2018-01-03 Thread Jehan Pagès
Hi!

On Tue, Jan 2, 2018 at 7:00 PM, Akkana Peck  wrote:
>> > On 01/02/2018 07:38 AM, Elle Stone wrote:
>> > > When configuring GIMP-2.9, it doesn't find the mypaint brushes.
>
> Tobias Ellinghaus writes:
>> You probably have to add
>>
>> /home/elle/code-install/gimpdefault/install/share/pkgconfig/
>
> I hit a bunch of snags trying to follow this, getting the right
> branch and not knowing that libmypaint's autogen doesn't run
> configure automatically..

Yeah autogen.sh does not have to run configure and MyPaint people
removed this behavior from the autotools setup I initially did. Since
I expect this repository to be taken care of later on by the MyPaint
team, I did the autogen.sh the way they like it, i.e. not running
configure. :-)

Jehan

P.S.: also I don't really like that the autogen.sh run configure
myself. It can sometimes be a bother when you want to do VPATH builds
but the autogen script often wants to be run from within the source
root. Anyway…

-- 
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] Compiling GIMP-2.9 with the new mypaint requirements

2018-01-03 Thread Jehan Pagès
Hi!

On Tue, Jan 2, 2018 at 9:54 PM, Kevin Cozens  wrote:
> On 2018-01-02 11:51 AM, Alexandre Prokoudine wrote:
>>
>> OK, so I'm being Mr. Silly, switched to the 1.3 branch, it worked.
>
>
> Switching to the 1.3 branch, and the previous tip about adding
> share/pkconfig to the paths used by pkgconfig allowed GIMP to find the
> mypaint-brushes files that I installed for use by GIMP.
>
> The configure checks in GIMP don't like the 2.x version you get if you just
> checkout and install the files from git master.

Yep that's on purpose. MyPaint/libmypaint development evolved their
brush format with incompatible changes. There are new parameters (some
of which can currently crash GIMP, which is still to be fixed on
libmypaint side) and some parameters are the same but actually behave
differently.

The library has been versionned already (current libmypaint master is
version 2 though there has been no release yet) and we needed to also
have brushes versionned as well for the above reasons. We also needed
brushes as a separate package (otherwise MyPaint is a dependency of
GIMP!) and finally we needed to make sure of the installation path
(otherwise we have to "guess" and in many cases, the MyPaint tool was
just useless with no brushes available).

For all these reasons, I took the MyPaint current brushes. And I made
a branch to freeze the brushes before all the changes happened. But
the master branch still needs to follow MyPaint master development.
:-)

Jehan

> --
> Cheers!
>
> Kevin.
>
> http://www.ve3syb.ca/   |"Nerds make the shiny things that distract
> Owner of Elecraft K2 #2172  | the mouth-breathers, and that's why we're
> | powerful!"
> #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] Compiling GIMP-2.9 with the new mypaint requirements

2018-01-02 Thread Jehan Pagès
Hi!

On Tue, Jan 2, 2018 at 2:25 PM, Tobias Ellinghaus  wrote:
> Am Dienstag, 2. Januar 2018, 14:05:58 CET schrieb Elle Stone:
>> On 01/02/2018 07:38 AM, Elle Stone wrote:
>> > When configuring GIMP-2.9, it doesn't find the mypaint brushes.
>> >
>> > 6. So I tried also install the mypaint brushes in /usr/local, but GIMP
>> > still can't find the brushes.
>> >
>> > 7. In case it's relevant.  I have libmypaint-1.3.0 installed from Gentoo
>> > portage:
>> > equery list '*mypaint*'
>> >
>> >   * Searching for *mypaint* ...
>> >
>> > [IP-] [  ] media-libs/libmypaint-1.3.0:0/0
>>
>> Installing the brushes in "/usr" allowed GIMP to find the brushes. But
>> it seems like GIMP should have found the brushes when they were
>> installed in the prefix.
>
> You probably have to add
>
> /home/elle/code-install/gimpdefault/install/share/pkgconfig/

Indeed!
I'm not sure why everyone was only adding a lib/pkgconfig/ but
share/pkgconfig/ is also to be added in any custom prefix in
PKG_CONFIG_PATH!
Why it worked inside /usr is because this is already in the defaults
path of pkg-config for the /usr/ or /usr/local/ prefixes but you have
to take care of it for any custom prefix.

Also why can it be in share/ or in lib/? The logic is quite simple: if
this is a library, the pc file goes in lib/pkgconfig/, if this is a
data package, it goes in share/pkgconfig/.
Have fun!

Jehan

> to your PKG_CONFIG_PATH. libmypaint installs to lib/pkgconfig and the brushes
> are in share/pkgconfig. Both are valid locations, but this adds one new path
> you have to deal with when installing dependencies for GIMP separately.
>
>> Best,
>> Elle
>
> Tobias
> ___
> 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] proliferation of messages

2017-12-05 Thread Jehan Pagès
Hi!

On Tue, Dec 5, 2017 at 8:55 AM, Marco Ciampa via gimp-developer-list
 wrote:
> Hello devs,
> sorry for the trivial question.
>
> Is there any special linguistic reason behind the choice to have so many
> nearly the same messages like this:
>
> in /app/actions/layers-actions.c:45
>
> "Layer Color Tag: Set to "
>
> and the corresponding color:
>
> /app/actions/layers-actions.c:458
>
> msgid ""
>
> ?

No linguistic reason, no. Just I haven't thought better.
We still need to have a longer message in the tooltip so that we can
have a better understand of the action because the name is just a
color (which is pretty not descriptive), and even more because there
are several similar actions (set layer color tag, set channel color
tag…). And the similarity of the message helps to associate them as
similar actions, especially in some out-of-menu context (i.e. the
action search) where just reading "Red" would be a pretty
non-descriptive information on an action.

But it's true that ideally we could/should factorize the strings to
not repeat the same text base.

> Why not just a
>
> Layer Color Tag: Set to %s"
>
> ?

This would indeed be better, indeed.
Now there is a technical difficulty. These strings are not in a
printf-style gettext call. They are in an initialization array for
action entries with a given non-printf format. We could theoretically
change the struct GimpEnumActionEntry to allow for some
printf-formatted string, and consequently change as well the function
gimp_action_group_add_enum_actions().
Of course if we did this, we should do the same to other
Gimp*ActionEntry (and association add_*_actions() functions) to be
consistent.

Basically I feel that would be a lot of boring work for limited
advantage IMO. :-/

Jehan

>
> --
>
>
> Marco Ciampa
>
> I know a joke about UDP, but you might not get it.
>
> 
>
>  GNU/Linux User #78271
>  FSFE fellow #364
>
> 
>
> ___
> 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
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] Cage transform and Warp transform

2017-11-28 Thread Jehan Pagès
Hi!

On Tue, Nov 28, 2017 at 11:45 PM, Tobias Ellinghaus  wrote:
> Am Dienstag, 28. November 2017, 23:30:57 CET schrieb Jehan Pagès:
>> Hi!
>>
>> On Tue, Nov 28, 2017 at 11:25 PM, Tobias Ellinghaus  wrote:
>> > Am Dienstag, 28. November 2017, 17:55:16 CET schrieb Jehan Pagès:
>> >
>> > [...]
>> >
>> >> The command is:
>> >> $ gimp-2.9 --gtk-g-fatal-warnings
>> >
>> > Actually, it's --g-fatal-warnings, without the "gtk-".
>>
>> Both exist and work. Run a `gimp-2.9 --help-all` to see them. :-)
>> I believe they are synonyms though clearly using the version without
>> "gtk-" in it is 4-letters faster, hence more efficient (I don't know
>> why I always use the option with gtk- though).
>>
>> But yeah, both exist. ;-)
>
> Interesting. Do you know where the longer version is coming from? I grepped
> the sources of gimp, gtk, glib and nowhere was "gtk-g-fatal-warnings" found.

I believe --g-fatal-warnings is generated by glib whereas
--gtk-g-fatal-warnings is generated by GTK+. Probably even just a
wrapper of the former.
Though I may be wrong. I don't think I ever searched this specifically.

> TIL GTK uses magic. :-)

Yeah if you can't grep it, it may just be some CLI option generation.
I am not sure. :-)

Jehan

>> Jehan
>>
>> > [...]
>> >
>> >> Jehan
>> >
>> > Tobias
>> > ___
>> > 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
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] Cage transform and Warp transform

2017-11-28 Thread Jehan Pagès
Hi!

On Tue, Nov 28, 2017 at 11:25 PM, Tobias Ellinghaus  wrote:
> Am Dienstag, 28. November 2017, 17:55:16 CET schrieb Jehan Pagès:
>
> [...]
>
>> The command is:
>> $ gimp-2.9 --gtk-g-fatal-warnings
>
> Actually, it's --g-fatal-warnings, without the "gtk-".

Both exist and work. Run a `gimp-2.9 --help-all` to see them. :-)
I believe they are synonyms though clearly using the version without
"gtk-" in it is 4-letters faster, hence more efficient (I don't know
why I always use the option with gtk- though).

But yeah, both exist. ;-)

Jehan

> [...]
>
>> Jehan
>
> Tobias
> ___
> 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
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] Cage transform and Warp transform

2017-11-28 Thread Jehan Pagès
Hi!

On Tue, Nov 28, 2017 at 5:32 PM, Elle Stone
 wrote:
> On 11/28/2017 10:32 AM, Jehan Pagès wrote:
>>
>> Hi!
>>
>> On Tue, Nov 28, 2017 at 3:54 PM, Elle Stone
>>  wrote:
>
>
>>> I wanted to somewhat reshape some curved lines in a drawing, and tried
>>> the
>>> Cage transform, which I remember using a long time ago. After selecting
>>> the
>>> points, it took a long time for the cage transform to calculate the cage.
>>> But when trying to move a point on the cage, nothing happened. During all
>>> of
>>> this calculating plus "nothing happened", these lines were printed over
>>> and
>>> over to the terminal:
>>>
>>> (gimp-2.9:30657): GEGL-CRITICAL **: gegl_buffer_get: assertion
>>> 'GEGL_IS_BUFFER (buffer)' failed
>>>
>>> Is there a bug?
>>
>>
>> Well if it doesn't work and if there is a GEGL-critical, yes there is
>> definitely a bug. ;-)
>> You should run gimp with --gtk-g-fatal-warnings to force it to crash
>> when it gets a warning. Doing this inside gdb will get you a
>> stacktrace which led to this warning so that you can copy-paste it in
>> a bug report. :-)
>
>
> Hi Jehan,
>
> What is the actual command to type to get GIMP to run with
> --gtk-g-fatal-warnings? I kept getting terminal output that indicated that
> GIMP couldn't find the file "--gtk-g-fatal-warnings".

The command is:
$ gimp-2.9 --gtk-g-fatal-warnings

GIMP will crash as soon as it gets any warning.

To run this into gdb, you run first:
$ gdb gimp-2.9
Then inside gdb prompt:
(gdb) run --gtk-g-fatal-warnings

> Though in this case it really doesn't matter as I haven't been able to
> produce the same terminal output as before. Sorry for the noise!
>
> I still think I'm not doing something correctly with Cage transform. But as
> Warp worked perfectly for the task at hand, I'm very glad that the cage
> transform didn't work as expected, because otherwise I wouldn't have tried
> the Warp tool.

Well maybe you are not using cage transform tool correctly. Yet even
though no critical warnings are meant to happen! That is a definite
bug.
Also even if you were not using it correctly, then it would mean there
may be a design flaw. Cage tool should not be that complicated to
operate.

>>>
>>> Jehan, is there any possibility that this warp transform could be made to
>>> work symmetrically, perhaps via the symmetric painting dialog? Or maybe
>>> it
>>> already does, but somehow I did something wrong?
>>
>>
>> No. The symmetries work for paint tools (children of GimpPaintTool
>> class), but the warp transform is not a paint tool (I mean, not in our
>> code; it is derived directly from GimpDrawTool, which is lower level
>> class).
>> Of course, in theory, that could be changed. But this is not how it is
>> implemented currently.
>
>
> Thanks! for letting me know. I had a feeling the Warp tool wasn't code-wise
> related to the Paint tools, but wanted to ask to make sure. Whhether it can
> work symmetrically or not, it's a wonderful way to transform portions of an
> image.

Yep. Warp is cool indeed. :-)

Jehan

> Best,
> Elle



-- 
ZeMarmot open animation film
http://film.zemarmot.net
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] Cage transform and Warp transform

2017-11-28 Thread Jehan Pagès
Hi!

On Tue, Nov 28, 2017 at 3:54 PM, Elle Stone
 wrote:
> Hi All,
>
> I wanted to somewhat reshape some curved lines in a drawing, and tried the
> Cage transform, which I remember using a long time ago. After selecting the
> points, it took a long time for the cage transform to calculate the cage.
> But when trying to move a point on the cage, nothing happened. During all of
> this calculating plus "nothing happened", these lines were printed over and
> over to the terminal:
>
> (gimp-2.9:30657): GEGL-CRITICAL **: gegl_buffer_get: assertion
> 'GEGL_IS_BUFFER (buffer)' failed
>
> Is there a bug? Or maybe I did something wrong? I reread through the on-line
> documentation (https://docs.gimp.org/2.9/en/gimp-tool-cage.html), but maybe
> I misunderstood what it says.

Well if it doesn't work and if there is a GEGL-critical, yes there is
definitely a bug. ;-)
You should run gimp with --gtk-g-fatal-warnings to force it to crash
when it gets a warning. Doing this inside gdb will get you a
stacktrace which led to this warning so that you can copy-paste it in
a bug report. :-)

> So I switched to the Warp transform, which worked very smoothly, quickly,
> responsively. It's like using a paint brush to warp the lines. The only
> catch was that after moving all the lines to where you want them, then you
> have to hit Return to actually apply the transform, which makes sense, but
> it took me a couple tries to figure this out.
>
> Whoever programmed the warp transform, thank you!! This is such a nice way
> to gently reshape curved lines!
>
> Jehan, is there any possibility that this warp transform could be made to
> work symmetrically, perhaps via the symmetric painting dialog? Or maybe it
> already does, but somehow I did something wrong?

No. The symmetries work for paint tools (children of GimpPaintTool
class), but the warp transform is not a paint tool (I mean, not in our
code; it is derived directly from GimpDrawTool, which is lower level
class).
Of course, in theory, that could be changed. But this is not how it is
implemented currently.

> Anyway, I made the transformed lines symmetric by duplicating the warped
> layer, flipping it around the horizontal axis, and applying a mask to hide
> the untranformed half of the image, which worked out just fine.

Cool. That's old style how it would have been done with paint tools as
well. I guess this still has to be done for other tools until someone
make symmetries even more generic.

Jehan

> Best,
> Elle
> ___
> 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
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


  1   2   3   4   >