Re: [Gimp-developer] Introduction of new unique brush tool

[Joao S. O. Bueno via gimp-developer-list]

I had not tried it - but this feature has been a demand by some users.

If we could talk into making this kind of mask a toggle for existing tools,
instead of a whole new tool, I guess it could be really interesting.

On Tue, Feb 15, 2022 at 1:54 PM sigetch via gimp-developer-list <
gimp-developer-list@gnome.org> wrote:

> Hi all,
>
> Long time no see.
> Recently, I implemented a funny tool named "Bucket-fill brush" in my
> gimp-painter fork.
> It's kind of a brush tool, but every brush dab is clipped by the
> bucket-fill selection mask under the cursor position too. This tool is
> convenient for painting illustrations with line art.
>
> You can see how it works in my painting workflow from following video
> in YouTube.
> https://www.youtube.com/watch?v=RTZWXifLpRE
>
> If you're interested in this brush, please check my repository for
> implementation.
> https://github.com/seagetch/gimp-painter
>
> It is very simple and straightforward implementation to clip brush
> mask with bucket-fill boundary.
> You can find /app/tools/gimpbucketfillbrushtool.cpp and
> /app/core/gimpimage-contiguous-region.c which implements this brush.
>
> Thanks,
> --
> sige...@gmail.com
> ___
> 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

[Gimp-developer] Adjustments on dynamics

[Joao S. O. Bueno via gimp-developer-list]

Hi folks -

This is just to let it in written here that last Monday me, Ayreom, Jehan
and Americo
had a meeting concerning the current behavior of dynamics (both up to 2.10
and on 2.99) -
and asserted some incorrect behaviors -

These included but are not limited to the "spacings"
dynamic output, which is mostly not usefull at all since the dynamics curve
has its lower value corresponding to the current "spacing" setting on the
tool options. A most useful functionality would be to be able, for example,
to have the minimum corresponding to spacing "1%" and maximum corresponding
to the tool options setting.  In that way it would be possible to set the
curve so that spacing would vary from 3% to 15% - which can enforce some
visuals on brushes intending to imitate natural painting. Americo is the
authority on this - but I fully agree, and it should be easily verifiable,
that the current behavior yields no visually intesting results.

Another broken dynamics is the "aspect ratio X direction": it just yields
maximum aspect ratio (20:1 or 1:20) disregarding any intermediate values -

I had to leave the meeting early, and I think the three of them had
asserted more behaviors that are currently of no use but as a toy.

Before I left, though, one of Jehan's sugestions was that we should find a
way to implement a version number to the dynamics files, so that as these
things get fixed, GIMP can auto-convert old, bad behaviors to a new, fixed
scale (if possible at all, after the fix is in effect)..

I think most of the issues discussed have proper issues open on gitlab -
but I proposed sending this in written form to get more engagement to these
(and certainly other)  relatively small fixes that are in need.

Best regards,

   joao
___
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] Making enabling dynamics a checkbox (Issue #4333)

[Joao S. O. Bueno via gimp-developer-list]

Maybe, instead of a redundant control to the already cluttered tool options,
we could step back and try to get an easier way to find and select a desired
dynamics (including the "Dynamics Off"). meanwhile, maybe just
making it special so that it shows first on the dynamics list would
be a nicer workaround than adding still another control there.

On Wed, 29 Dec 2021 at 12:42, Asalle via gimp-developer-list <
gimp-developer-list@gnome.org> wrote:

> Hi all,
>
> I'm fairly new to gimp, so any advice is welcome. I'm attempting to
> implement this feature request:
> https://gitlab.gnome.org/GNOME/gimp/-/issues/4333#note_1211607.
> In short: instead of changing from e. g. "Basic dynamics" to "Dynamics Off"
> and vice versa, there should be just a checkbox that allows to turn the
> dynamics off and on.
>
> So far I've implemented the checkbox and a "use-dynamics" property in
> PaintOptions. But I'm not sure how to actually enable it when drawing. I'm
> also not sure if I'm on the right path, so if you could nudge me in the
> right direction, I would appreciate it!
>
> Here is my patch:
>
> https://gitlab.gnome.org/Asalle/gimp/-/commit/1928d1edd71286ce7b185fbf24eda91aa5b504b3
> .
>
>
> --
> Best regards,
> Asa
> ___
> 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

Re: [Gimp-developer] Hello Developers

[Joao S. O. Bueno via gimp-developer-list]

If the plug-in is indeed the "Error Level Analyst" plug-in, it is a Python
plug-in, and should work fine with GIMP 2.10.
Please add some more information on the environment you are running GIMP
(Linux/Windows/ Mac), GIMP version, and
the error message - as the list blocks attachments, if you answer me in
private, I should get the attachment.

Since it is showing in the menu, it maybe that a fix for the plug-in is
needed - or possibly
jsut some small adjustment in your environment.


On Sat, 11 Dec 2021 at 08:31, David Johnson via gimp-developer-list <
gimp-developer-list@gnome.org> wrote:

> I am David Johnson,
>
> I have a serious dilemma and could us some help.  I am far too old to
> follow links all over the internet. I am using Gimp in preparation fo Court
> and have found myself stuck.  Can someone from the Dev Team assist me in
> installing “Error Level Analyst’ Plugin.  I have it showing in the images
> menu but I continue get the following messages.
>
> I would be willing to donate to your org in exchange for help getting this
> plugin installed and working!
> This is an open request and I ask that someone please respond.
>
> David
> lambwebdes...@gmail.com
>
>
>
> ___
> 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

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

[Joao S. O. Bueno via gimp-developer-list]

No progress -
But I've been talking to Americo over the last 2-3 weeks to start some
movement on that direction.

I had some work done in 2018, but it was a Python 2 plug-in with
requirements for a server-side API -
maybe I will revisit some of that

I did not even know about this extension format in the ChangeLog you
pointed. It certainly will be useful.

On Sat, 4 Dec 2021 at 12:31, Michal Vašut via gimp-developer-list <
gimp-developer-list@gnome.org> wrote:

> Huh, just found some info on gitlab, but not sure, how old it is (those
> commit messages are not very descriptive):
>
> - New extension format support (.gex a.k.a. GIMP Extension) which is
> an archive containing various supported data. So far, it can
> package: brushes, MyPaint brushes, dynamics, patterns, gradients,
> palettes, tool presets, plug-ins, splash images and themes.
>   - New extension manager allowing to enable, disable or uninstall
> installed extensions, with a dialog available in `Edit > Manage
> Extensions`.
>
> https://gitlab.gnome.org/GNOME/gimp/-/blob/master/NEWS#L540
>
>
> I will dig in...
>
>
>
> On Sat, Dec 4, 2021, 15:56 Michal Vašut  wrote:
>
> > Any progress here? (not pushing, just asking)
> >
> > On Wed, Jan 8, 2020, 21:51 Ofnuts  wrote:
> >
> >> On 1/8/20 11:00 AM, Jehan Pagès via gimp-developer-list wrote:
> >> > 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.
> >> >
> >> And you haven't even got a bus right now :)
> >>
> >> ___
> >> 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
>
___
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

[Joao S. O. Bueno via gimp-developer-list]

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.

On Thu, 3 Jun 2021 at 13:36, Jehan Pagès via gimp-developer-list <
gimp-developer-list@gnome.org> wrote:

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

[Joao S. O. Bueno via gimp-developer-list]

Having read things to this point, a first short remark on
the feature you mentioned of allowing a pattern rotation/scaling before
filling up an area:

That'd be great. I remember we used to have this as a feature request a
long time ago
(10+ years), and it was dismissed at some point. That was well before we
had
on-canvas controls.

But I think it would be great to have that for the fill  tool, and maybe as
a post-adjustment when
dragging the pattern directly to the image.

As for the various instances you mention of "expanding a selection
containing a pattern",
the current way of doing this with GIMP would be to have initially a layer
with a small (GIMP) selection on it,
do the proofs there, then recreating a larger selection with the rectangle
tool, and re-filling the pattern.


Another thing on the top of my mind is the current behavior for a pattern
being used in a
palette-constrained GIMP image GIMP will transform the colors in the
pattern to near colors
on the image -  a behavior of replacing near-colors, and carefully add new
colors could
be implemented with the current plug-in system.

Best regards, and a nice LGM for however is there!

   js
 ><-

On Tue, 28 May 2019 at 08:41, Sven Görsmann via gimp-developer-list <
gimp-developer-list@gnome.org> wrote:

> Simon Budig  schrieb am Di., 28. Mai 2019 13:24:
>
> > Hi all.
> >
> > Some of you will have noticed the Mail from Thomas Völker from the end
> > of last February. He was looking for some Developers for paid Gimp
> > development.
> >
> > [putting on my business head]
> >
> > I co-own and work for a small company doing embedded linux / customer
> > specific application development.
> >
> > After discussing this in the GIMP IRC channel I was ready to dip my toes
> > into the somewhat murky water of doing paid development for my hobby pet
> > project. So I went ahead and visited the company in question. It was a
> > nice and productive meeting with interesting questions and I'd like to
> > ask for your thoughts and input on the problems I'm about to explain.
> > I'll split up this mail, so that different problems can be discussed in
> > separate sub-threads.
> >
> > If you're interested in doing paid development work on some of these
> > problems please feel free to speak to me.
> >
> > If you're interested in the problems, have input on working with
> > printing in the textile industry please feel free to speak to me.
> >
> > I am currently in Saarbrücken and would welcome discussions about these
> > topics at LGM.
> >
> >
> > The Problem:
> >
> > The Company is based in Germany and is manufacturing carpets, printing
> > them with various customer specific designs.
> >
> > Due to changes in their software toolchain (product upgrades with very
> > unwelcome additional restrictions) they are looking for free
> > alternatives and one part of a new toolchain could be GIMP.
> >
> > During the two days of my (paid) visit there we tried to assess what
> > features they need and looked for ways to fit GIMP into their needs.
> >
> > I was very clear about that we need to be very careful about feature
> > additions and how they fit into our future roadmap. That having said I
> > really do believe that there are areas which would be useful for GIMP,
> > other things are maybe a bit more tricky to incorporate in a sane manner
> > into the GIMPs UI.
> >
> > As for the background: the company in question manufactures long
> > (dozends of meters) 4m wide runs of carpet, which then get printed on
> > with customer specific designs in three different production lines. One
> > of these lines uses a four color CMYK process, but the focus of this
> > project are the two other lines using machines to print 24 and 32
> > individually mixed colors.
> >
> > Since rooms wider than 4m are not uncommon site specific carpets need to
> > get prepared in a way that multiple runs of carpet can be placed next to
> > each other and the pattern globally match perfectly. This is one of the
> > main concerns and I have the impression that the current tools in GIMP
> > are not that great to deal with this kind of design constraints.
> > Adressing these might expand our audience further into the realm of the
> > textile industry, but I also believe that it might be helpful for people
> > working with textures. To develop tools that make it more easy to work
> > with this kind of constraints is probably the most tricky and
> > questionable part of the project.
> >
> > Lets first look at the in my opinion quite simple and uncontroversial
> > things for the GIMP.
> >
> > The two printing lines in question print with 24 resp. 32 customer
> > specific colors. Each carpet project has its own color palette and while
> > there is a predefined set of color recipes readily available it is not
> > uncommon that specific projects get their own customer specific
> > colors.
> >
> > That is the basic situation. I'll send some follow up mails for the
> > following sub-topics:
> >
> > - Better 

Re: [Gimp-developer] We need a missing feature.

[Joao S. O. Bueno via gimp-developer-list]

It is possible to move otherwise unrelated layers if they are set as
"linked" -
To mark a layer as "linked", one should click just to the right of the
"eye" icon
on the layers dialog - a chain Icon shows up.

All layers marked with the chain Icon will move (or be transformed) as a
"temporary" group,
regardless of which actual layer group they belong too.

https://pasteboard.co/I7oGHLh.png

On Wed, 27 Mar 2019 at 15:12, Maxime Martyr via gimp-developer-list <
gimp-developer-list@gnome.org> wrote:

> Greetings Gimp developers!
>
> I am trying to convince friends that open-source software Gimp can replace
> proprietary software Adobe Photoshop.
>
> They like Gimp but they say it misses a feature which make it unsatisfying
> to replace Photoshop.
>
> They say Gimp doesn't allow them to move several layers at once and that
> really annoys them to have to move each layer one by one.
>
> So I searched if the feature that they need exists and I found that it is
> possible to create groups of layers to move several layers at once as a
> group.
>
> They answered that they knew this feature already but they need to move
> several layers from different groups at once so they need to move several
> layers at once not independently from groups.
>
> Then I told them that I was going to ask to Gimp developers if they could
> add this feature and so here I am.
>
> Dear Gimp developers, could you please add the possibility to move several
> layers at once independently from groups?
>
> Sent with [ProtonMail](https://protonmail.com) Secure Email.
> ___
> 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

Re: [Gimp-developer] Editing last stroke / modification through gimp plugins

[Joao S. O. Bueno via gimp-developer-list]

No - the current PDB API  + some extras in the Python bindings cannot "see"
what the user
is doing with any tool. Nor is anything related to the undo history exposed
for plug-ins.

Your described work around sounds like the only thing possible.

You might want to try "pyautogui"  module to check for mouse-click/movements
timing, as it might be more performant than checking for differences in the
image.

Regards,

   joao


On Wed, 27 Mar 2019 at 15:12, Paul Jewell via gimp-developer-list <
gimp-developer-list@gnome.org> wrote:

> Hey all. I have been writing small plugins using the python engine for
> quite a while, it is very nice and I appreciate the great batch
> functionality available.
>
> I am interested in writing some functionality that deals with working with
> the last brushstroke. Ideally, I would be able to enable my plugin and it
> applies to all brush strokes (individually) until I turn it off, but I
> would also settle for just running it with a hotkey after making a stroke.
> I know these states must be stored somewhere because they are in the undo
> history. So far the only equivalent I have been able to come up with is to
> run a background thread that iterated over the canvas repeatedly to check
> if there are any deltas, and wait until no more are found, but obviously
> this is inefficient and inaccurate. Is there a better way available
> currently?
>
> I am usually using python-fu style but I have also used the scheme engine
> for a few projects.
>
> Thanks for your help.
> ___
> 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

Re: [Gimp-developer] Gtk4

[Joao S. O. Bueno via gimp-developer-list]

So, from the post entitled "GTK 4.0 is not GTK 4", we read, with all
letters:
"""In this way, “Gtk 4.0” is not “Gtk 4”. “Gtk 4.0” is the first raw
version of what will eventually grow into “Gtk 4”, sometime around Gtk 4.6
(18 months later)."""
So, it is actually not ready "a couple of weeks" from now.


On Wed, 13 Feb 2019 at 10:00, Alexandre Prokoudine via gimp-developer-list <
gimp-developer-list@gnome.org> wrote:

> On Wed, Feb 13, 2019 at 2:46 PM Elle Stone wrote:
>
> > Will the port from GTK3 to GTK4 be as onerous as the port from GTK2 to
> GTK3?
>
> https://blog.gtk.org/2019/02/08/report-from-the-gtk-hackfest-in-brussels/
> appears to outline a number of changes that will absolutely affect
> GIMP. E.g. I'm unsure if the proposed constraint -based layout system
> will replace the old boxes or be available next to it. But if it will,
> updating the UI will take quite a while.
>
> 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
>
___
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 Drop Shadow filter not working

[Joao S. O. Bueno via gimp-developer-list]

The GEGLized drop shadow filter is a big regressin in 2.10 -
nonetheless it works, in a destructive way (while the legacy
dropshadow works in a
non destructive way, and even allows adjusting the effect by
displacing the created
shadow layer).

So - it actually only works in a whole layer, is there are no active
selections -
if you are seeing nothing (and have space in the layer), maybe the problem is
that you have an active selection. The legacy drop shadow works
in a similar way, by changing the active layer, if there is an
active selection. The existing GEGL filter have no equivalent mode
to the one that would create a shadow for the selection itself in the
old filter.


On Fri, 4 Jan 2019 at 14:36, Marco Ciampa via gimp-developer-list
 wrote:
>
> On Fri, Jan 04, 2019 at 03:09:21PM +0300, Alexandre Prokoudine via 
> gimp-developer-list wrote:
> > https://i.imgur.com/TciFDZy.png
>
> Sorry, no:
>
> https://imgur.com/a/8OepPGF
>
> what system/gimp-version are you using?
>
> Mine is Ubuntu 18.04 with dev 2.10 branch gimp ...
>
> --
>
>
> 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
___
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-web] Alexandre Prokoudine attacks on GIMP critics around the Web

[Joao S. O. Bueno via gimp-developer-list]

Now when reading you people, I can understand why
is it that Guido stepped down from being the Python head.
And why the GIMP dev team really have an option of being more recluse -

I should tell you that I'd be in the same category of Prokoudine -
mention GIMP as "us", although my code contribution have
been negligible over the years. believe it or not, there is more
 work to be done on a project like this than writing
the lines of code. Acknowledging  the sheer amount of
work that it takes for refactoring
or adding some of the features on the project as it is now,
 based only on the work of very few volunteers is part
of what makes the project progress.

I have friends that poke me with the same insistence you
were taking on that reddit thread about new features,
release, or GIMP releases - and, believe it:
it does really piss one off, if one only knows what is involved.

In my case, the persons were calling me that I should
 "talk the GIMP team to get the 2.10 version on Ubuntu (18.04 version) ,
 and somehow implying it was GIMP teams fault that it
would not run out of the box there. Snap packages, or 3rd
 party repositories were not enough for them.
Explaining it is not GIMP volunteers
responsibility which version is included or not in Ubuntu
was as impossible to them as it seems to be to explain
you that there can't be date-mandated releases in
GIMP project.

If you can't see in how many levels saying
 "Ubuntu has been having scheduled releases for years,
 are you saying that GIMP is some complicated than a whole operating system?"
is incorrect, it is really hard to think of ways of explaining
 it you'd find polite. (I wrote on that comparison bellow -
 it is really so out of scale, I don't feel like I
could express 30% of the differences)

So humans are faulty in communicating in a way that makes
everyone happy, and I am sorry if the way Prokoudine
 put his statements made you feel as bad
as bringing this mail thread here. But really, there
is a reason why the answers
on "why is not feature X included already" or "why will
it take so long", "why there is no Windows/Mac/Linux
Distro Du Jour ready to install from the site" is answered
with some impatience by _us_.

The fact is that all these things demand work.
 Hard work. And all things in GIMP are made by
volunteers. Including not only development, but also
documenting, making the news posts to the web sites,
translating, _and_ talking to users that reach the
eam and managing their expectations.

Ultimately, when it is stated that the project can't
 make scheduled releases by one that _do_ _participate_
of the project core community, and there is
still insistence in the point, it is really complicated
 to go forward on the discussion
without crossing the line - and I myself often do cross it
 - and I excuse Alexandre if he did cross it, although
 my reading on that thread is that it was still ok - since
the posts he was replying too were in no means
reasonable.

It is true that adding new tools, or filters, or themes can make part
of intermediate, short releases, and that is what the team
has agreed upon: these are being made during the micro version
of the 2.10.x series, and there is a much shorter cicle for these releases
than for minor version, or, as is the case, major version changes.
The fact is that the changes that took place from 2.8 to 2.10, and the ones that
are getting in place from 2.10 to 3.0 simply CAN NOT be partial! You either
have the whole software ported to the new underlying technology, or you
have a mess that can barely function. One can't have GTK 2.x code in
one part of the 2000+ C source files, and GTK 3.x code on other part
of those.
Now, does the above paragraph sounds "impolite"? I'd guess so. Still,
it deals only with facts.

And finally, let's move to your very unreasonable statement trying to compare
GIMP with Ubuntu project above, and let's try to put in perspective
why these are not reasonable.

So, Ubuntu is a project that encompass 10.000+ software
 packages. As an outsider to the project, it is easy to
estimate they feature a couple hundred (had to google some -
and only could get some numbers for 2008, there seems to be 50 core
contributors, and 340 packagers  at the time)
More over, the work they do on the packages is made on top of the work
made on the Debian project - so, for a lot of those packages,
the work is mostly done - and I am quite sure it works the
other way around: Debian packages that are based on whatever
packaging job is done on Ubuntu, and more than a handful of
people who makes some packages for both systems)
Some of the authors of those 1+ packages certainly contribute
downstream and do the packaging to Debian/Ubuntu.
But what they have to do to ensure new releases each 6 months of
Ubuntu, is mostly to ensure those packages work together, picking
a version as new as possible when the date is due. And that is already
a lot of work. Sure, there are projects that are ubuntu specific, and 

Re: [Gimp-developer] Participation at Apple Developer Program

[Joao S. O. Bueno]

I voted yes -

But I also think we could ask Apple for a direct sponsorship for the
project  (obviously, not limited to this amount - maybe 100 times as
much is a reasonable value,
given the value made available gratis for all Mac OS users.)

Do we create another pool on that? Or can we figure out someone to
volunteer and contact them?

On 26 March 2018 at 13:08, 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/1FAIpQLSdRepYcE1dLD0342FaVGenU0Nr519SyK-MYzdGylmNXYq5rUQ/viewform?c=0w=1usp=mail_form_link
>>
>> Hi.
>>
>> Wed 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. Its 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...
>
> ___
> 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

Re: [Gimp-developer] Fwd: selection of a colour using python filters

[Joao S. O. Bueno]

Moin  -

There is no current effort or intent to improve on the color selection
for Python or Script-fu plug-ins.
There are few developers on GIMP and they are focusing on other points
of the codebase -

You can open a feature-request on http://bugzilla.gnome.org -  be sure
to specify exactly what you think
would be nice for this color picker, and then try to get someone to
provide a patch.

It will help if you follow continue this e-mail thread detailing a
little bit more what features you miss, and why it is important for
you before opening the feature request - so that we can make some more
suggestions to you.


regards,

  js
 -><-

On 23 May 2017 at 13:22, diego nassetti  wrote:
> Forwarded conversation
> Subject: selection of a colour using python filters
> 
>
> From: diego nassetti 
> Date: Mon, May 22, 2017 at 6:30 PM
> To: gimp-developer-list-requ...@gnome.org
>
>
> Hi,
> I noticed that using filters written in python, when there is to select a
> colour (parameter PF_COLOR), the interface panel appearing when clicking
> over the default colour shown by the filter is very limited with respect to
> the possibilities available in the standard color picking interface (and
> even in the interface of a filter written in script-fu).
> Is there any plan to improve it?
> Thanks a lot.
> (PS: I'm using Gimp 2.8.20)
> Diego
>
>
> --
> From: diego nassetti 
> Date: Tue, May 23, 2017 at 8:05 AM
> To: gimp-developer-list-requ...@gnome.org
>
>
> Hi,
> to complete my request I attach examples of:
> - what I get trying to select a colour from a python filter
> - what I get when changing BG colour (which I called standard color picking)
> Would it be possible in a next release to have the std panel also when
> using a python filter?
> 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
___
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] Please migrate to GitHub/CMake

[Joao S. O. Bueno]

On 8 May 2017 at 09:47, gregory grey  wrote:

I can get why are you trying to poke Alexandre on that - you are on an absolute
"shoot the messenger" weird thing there.


> In my experience "ain't broke" is a standard mantra of organizations
> stuck in the past.
>
> It's a tent-pole phrase that does not explain anything, and justifies
> whatever practices you want it to justify.
>
> I say waiting 3 weeks for build under some platform is broken as hell,
> given you shoot for mutiplatform-ity.

So, as a recap - the initial "no." is not the only answer here -
Pippin did expand it
to a manageable way to try todo something about it, if someone is
really willing to.

The original "no" reply from Alexandre is the absolute to be expected
answer if you
jut read this thread subject. "Can you please change ([thesetwof core
technologies your project
depend on just because they don't have enough bling-ding (github) ] ,
and then demand on the
human-resource-starved, volunteer only project, thatthe change is made
or at least
started immediately. Sorry, 'no' is among the most polite answer one could get
with such a request.




>
> @Alexandre - what exactly is your point here? I did not build Gimp
> from source, ever.
>
> I'm confident there is nothing in your Makefiles that is beyond human
> understanding.
>
>  Again, since you said explicitly you are not making infra decisions,
> can I talk to the one/s who do? on the

You are already, and you did get answers regarding more practical aspects of
a possible cmake move, and a not-so-possible github move. Alexanre was
just first
to answer - with an answer that correctly roughly mirrored the
collective short answer the
he and the other collaborators for this project would like to be given.


>
> For sake of absolutely sane and productive discussion. If you want of course.
Do you realise this is a volunteer-maintained project and people
involved here will
be more happy doing codding and other tasks than "having a productive discussion
on whether it would be theoretically better to change to cmake"?
You've got a full
reply on that - that is: get one to have at least a proof-of-concept
build that migrates and
simplifies the current process.  The existing contributors won't stop
what they are doing
now because an e-mail not-so-politely  labeled  "Please migrate to
GitHub/Cmake"  came
along.

Try the same e-mail with "I've managed to build GIMP with cmake and could drop
these 1 lines of configuraton files - it already works on Linux
and Windows, Mac pending, here is the branch:... "

As for github, it is really irrelevant - the needed functionality from
the code management aspect
is provided by the (free software) git, regardless of the host of the
accepted main tree - what people disregard to see is that despite all
its popularity, github is just a normal privately owned commercial
player - that can change its use-terms, conduct, or go bankrupt any
time. (All of which did happen to previous
"point of reference" host for free software projects "Source Forge").
We have our servers setup and
independently running - and keeping control of the URLs where the
project is hosted mean we
can change that if need arises.
Moreover, anyone can use git functionality to create their forks on
github, and make something useful
with that - to the point of having patches using that side code-review
tools ready to be looked at and reviewed by current GIMP-commiters,
and if accepted, all it takes one command on the shell to
send that patch in a way it can be officially used in GIMP - in
contrast with one of the developers
"pressing a button" on github (wow, so much gain for a fancy prison).


Now, send more e-mails with personal offenses if you need - or try to
get GIMP to build with
cmake and showing it is indeed more maintainable.  :-)

best regards,

   joao
>
___
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-GEGL

[Joao S. O. Bueno]

Hi Diego -  the main problem right now is that GEGL Python bindings
are only possible from Python3 (with pygobject)  - and GIMP-Python is
stuck in Python2 + old GTK+ bindings.

But your e-mail gave me an idea - not that I am currently with time to
hack with it - but maybe use a module thta use a shameless hack to
call GEGL functions, even if it requires  making remote procedure
calls to a Python3 plug-in that can use GEGL directly.

On 2 March 2017 at 11:07, diego nassetti  wrote:
> Hi,
>
> will it be possible (and -if yes- when) to have a "pdb" interface for
> calling GEGL functions from inside a (scheme or python) filter?
> If not as pdb, is it planned to create a single interface call like the one
> existing for calling G'MIC (a string with all required parameters)?
>
> Many thanks
>
> Diego
> ___
> 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

Re: [Gimp-developer] An idea / feature for future releases of GIMP

[Joao S. O. Bueno]

Kindly provided to you by the Wilber Time Machine.

On 16 December 2016 at 00:27, Alexandre Prokoudine
 wrote:
> Already available since 2.9.2 :)
>
> 16 дек. 2016 г. 1:19 пользователь "M. Hammoud" 
> написал:
>
>> Hi.
>> New users spend a lot of time looking for an effect / filter / brush / tool
>> / pattern in the multiple menu tabs, each with a long list of submenus,
>> each with a lot of sub-sub-items.
>> It would be great, if one could simply type in a box what they are looking
>> for, such as for example "Gaussian Blur" and gimp would look for this or
>> suggest closest potential results.
>>
>> Regards,
>> *M. M. HAMMOUD, **MSc, MCITP, PMP, PSM, Prince2, SSBB, CPD*
>>
>> *https://linkedin.com/in/marchammoud/
>> *
>> ___
>> 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
___
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] State of Libre Graphics Union 2016 - call for Slides

[Joao S. O. Bueno]

On 23 March 2016 at 10:56, Alexandre Prokoudine
 wrote:
> On Sun, Mar 20, 2016 at 9:40 PM, C R wrote:
>> I'm doing the video for the Inkscape project. I can toss one together for
>> GIMP as well (mentioned in previous emails)
>> Is there still interest in this, or would someone rather do slides?
>>
>> Note that a video creates much more of an impact and allows us to show off
>> GIMP's new eyecandy.
>>
>> If interested please provide a complete list of features to highlight.
>
> What timeframe exactly are we talking about? Everything since last LGM?
Yes.
Actually one could talk about stuff since the last stable release -
that is too much -
but not everyone will have in mind the changes already done in GIMP
since 2.8 was out.
So maybe, one slide to talk about the greatest changes (color depth,
GEGL plug-ins, etc... ) and the others
to emphasize changes since the last LGM.


>
> 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
___
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] State of Libre Graphics Union 2016 - call for Slides

[Joao S. O. Bueno]

Dear Folks at GIMP -

The first presentation event in this years LGM program is ‘state of
Libre Graphics’. A common update for many of the projects across our
Libre Graphics community. This frees up room in the schedule for deeper
topics or fresh projects; while still giving us a chance to know what
has been going on in various ongoing libre graphics related efforts; not
only software projects, but also our various curation, publication and
umbrella projects.

More information on this presentation here - inclding the slides or video name
conventions and formating -

http://libregraphicsmeeting.org/2016/state-of-libre-graphics-union-2016/


The slides should be sent to me at this e-mail (gwid...@gmail.com ) up
to Friday the 8th of April -


Regards,

   js
  -><-
___
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] Future of Python v2 scripts

[Joao S. O. Bueno]

While it is is feasible to have Python3 as the system default install,
it is not practical to remove Python2 from the system. Even if it is
not installed by default (which I doubt very much) it will be
reachable via the default packaging system (and therefore available as
a GIMP dependency).

Anyway, even if we switched today to Python3 for GIMP, it would only
be available as of GIMP 2.10 - so GIMP 2.8 would still use Python2
scripts.

On 26 November 2015 at 06:46,   wrote:
> On 25 November 2015 at 16:21, Ofnuts  wrote:
>> The latest Ubuntu (15;10) has dropped support for Python V2 (Python V2 is
>> still available via a PPA). Are there any plans to support V3 in Gimp,
>
> I think they were talking about this, but it was not ready in time.
> 15.10 still has python2 as the default. They are now talking about
> making the change in 16.04 instead, but of course who knows if it will
> actually happen.
>
> https://wiki.ubuntu.com/Python
>
> You're absolutely correct that Gimp should be ready for this. No doubt
> many other distributions will also make this change.
>
> John
> ___
> 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

Re: [Gimp-developer] Future of Python v2 scripts

[Joao S. O. Bueno]

Therte is aproblem in migrating -  because converting scripts to
Python3 nto that much of a hasle, but current PyGIMP uses PyGTK - and
_that_ is a problem -  because we should them move the Python
itnerface to gobject introspection - and it would imply to move the
GIMP parts to use gobjetc introspection as possible as well. The
problem is that GIMP's C source does not export aythign as gobject
introspection.

But anyway - as a long time pythonista, I can say it is an error on
the Ubuntu team not to include Python2 in the main distribution (even
if manually installable) -  like a BIG ERROR - and GIMP scripts will
be a lesser problem.

Anyway, we should draw a "python3 plug-ins " architecture on GIMP -
I've  sent a couple of emails trying to gather ideas for that in the
past., It is just time to take one more look and try again. I will try
to send news on that over the next few days.

It is probably possible to build the interface with gobject
introspection and talk to the PDB using CTYPES - which will allow to
reqrite all of PyGIMP in pure Python, as we should have done a while
ago.



On 25 November 2015 at 20:43, Jehan Pagès  wrote:
> Hi,
>
> On Wed, Nov 25, 2015 at 5:21 PM, Ofnuts  wrote:
>> The latest Ubuntu (15;10) has dropped support for Python V2 (Python V2 is
>> still available via a PPA). Are there any plans to support V3 in Gimp,
>> possibly alongside V2? Maybe as a minimum look at the script's shebang to
>> determine if it is compatible with the supported Python version?
>
> I would think we are all for it (at least I am). We'd just need some
> nice contributor (you?!) to make use of Python 3 scripts possible. :-)
>
> 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
___
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] Fade length setting for paint dynamics

[Joao S. O. Bueno]

Sttting it programatically is likely a missing feature - it shouldbe
available as gimp-context-fade-set-length  -- and yes, it has nothing
to do with percents

On 2 October 2015 at 09:51, Ofnuts  wrote:
> I see that some changes have occured in that area in 2.8.14... However:
>
>  * I can't figure out the "percent" setting. Percent of what? From what
>I tried, it is not a percent of the total path length, not a percent
>of the stroke length, and not a percent of some image dimension.
>  * is there a way to set it programmatically? searching "fade",
>"context" or "dynamics" in the procedure browser doesn't show
>anything (not does looking at dir(gimp) in Python).
>
>
>
> ___
> 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

Re: [Gimp-developer] rollApp GIMP usage

[Joao S. O. Bueno]

On 27 May 2015 at 09:00, Boudewijn Rempt b...@valdyas.org wrote:
 Only if they'd distribute gimp, which they, arguably aren't doing.

EEek!  Time to go AGPL 3.0   :-)
___
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] Sourceforge downloads

[Joao S. O. Bueno]

On 27 May 2015 at 09:49, Jehan Pagès jehan.marmott...@gmail.com wrote:
 It also appears that the account the project page belongs to is
 sf-editor1, and a lot of well known projects are listed on the user page:
 http://sourceforge.net/u/sf-editor1/

As I openned the profile for that page to check the list projects it said
GIMP for Windows: last upodated 4 minutes ago - and the downlaod file thre nw
feature today's date.

Maybe due to our contacts they have just changed the kind and nature
of the malware
shipped with the installer.

  js
 --
___
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] Sourceforge downloads

[Joao S. O. Bueno]

On 26 May 2015 at 12:08, Jernej Simončič jer...@ena.si wrote:
 On Tuesday, May 26, 2015, 8:40:08, Ofnuts wrote:

 Should this site be closed down entirely (assuming it is still under the
 control of someone related to Gimp development)? There are still plenty
 of links pointing to it, and it would be better for them to be invalid
 instead of pointing to this crap?

 SourceForge has taken the gimp-win project control away from me
 (apparently due to inactivity, although they haven't done anything
 like that with a few other inactive projects I'm a member of), and so
 far they haven't responded to the message I sent them to cease the
 distribution of the installer.

Eek!

That is quite a nasty scenario- we have the former project host to
have apropriated itself
of being the target of download links to actively distribute malware with
GIMP brand.

I think that if some (not many) communication attempts go unresponded this is an
issue where we should tap on  Gnome Foundation and check whether there
are legal resources we can lay hand on to get them to stop it


   js
  --


 --
  Jernej Simončič  http://eternallybored.org/ 

 To err is human, but it feels terrific.
-- Mae West's Observation

 ___
 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

Re: [Gimp-developer] GIMP useability - choosing linear vs perceptually uniform RGB

[Joao S. O. Bueno]

Hi Elle -

Seeing your e-mail give the same kind of and what can I do about it
feeling I have when talking to Americo (he should also be reading
this mailing  list by now).

There are obvious lots of improvements that _could_ be done so that
GIMP would be a killer application.
What you do on the high-depth, color management field, Americo is
doing on the painting tools/dynamics/presets
area.

The problem is: currently there is not enough colaborator time to put
these suggestions together. There are barely collaborator resources
to read in full what you and Americo write (though the later have been
writing mostly to me in private due to language barriers) .

So, I hope that with the previous e-mail you could get to a good
summary of what would be needed for GIMP not only to be vaibale, but
to surpass current photoshop U.I. when dealing with these issues . I hope so.

Now help us think on the next steps. For example get that e-mail
worked into a feasible specification: If you can, refine it, then
maybe try to get someone with UI expertise that could fine tune that
your suggestions into specifications that could be really great -  now
we don't have Peter helping the project anymore.
(could be someone from your area, to whom you could get face to face
meetings) - (I'd rather have another switch along the layer modes than
to duplicate all layer modes in the UI, for example) -

And then...help use having more people who could help with development. :-)

At least I can see the suggested features as great. And I can't think
of a way to even begin takling them without an enormous amount of
weekly hours to dedicate to it (or Americo's issues for the matter)

Best regards,

   js
 --

On 29 April 2015 at 08:55, Elle Stone ellest...@ninedegreesbelow.com wrote:
 On 04/19/2015 06:44 AM, Elle Stone wrote:

 The single biggest useability issue with GIMP 2.9 is the mechanism for
 allowing the user to switch between linear and perceptually uniform RGB.


 On 04/19/2015 03:40 PM, Liam R. E. Quin wrote:
 In the meantime in my own workflow the lack of repeat last filter
 used is a much bigger usability issue than anything to do with gamma
 or clipping. So phrases like everyone and the biggest usability
 problen don't carry as much weight as specific use cases, I think.

 I will guess that most current GIMP users, just like most current PhotoShop
 users, don't have any notion of whether any given RGB operation should be
 done on linear vs perceptually uniform RGB. They rely on what they see on
 the screen, and they are used to seeing wrong results.

 Anyone who understands and intends to take advantage of high bit depth
 linear gamma image editing needs *control* over whether an operation is done
 using linear or perceptually uniform RGB:

 * The user shouldn't have to guess whether the RGB values have been
 linearized or not.

 * The user shouldn't be forced to rely on the developer's decisions from
 afar regarding whether any given RGB operation should be done using linear
 or perceptually uniform RGB.

 * The GIMP UI should provide easy user choice for all RGB editing
 operations, with good default settings. For example the default for gaussian
 blur should be linear RGB and the default for adding RGB noise should be
 perceptually uniform RGB. But the user needs the ability to *easily* make
 the other choice.

 Back when I used PhotoShop for linear gamma image editing I encountered
 three useability issues, which apparently still exist in the latest version
 of PhotoShop:

 1. PhotoShop couldn't display a true linear gamma image without causing
 posterization in the shadows, at least until the image was zoomed in to
 nearly 100%.

 2. PhotoShop Curves and Levels provided far too few tonal steps in the
 shadows to allow good control over edits made in linear gamma color spaces.

 3. Switching between linear gamma and perceptually uniform RGB required
 doing an ICC profile conversion.

 GIMP 2.9 from git used to have (but doesn't any longer have) the first two
 problems (well, there seems to be some kind of problem with Curves/Levels
 shadow adjustments, but it's not related to having too few tonal steps).

 The babl flips are a brilliant solution to the third problem. But the
 current User Interface for switching between linear gamma and perceptually
 uniform RGB is a useability nightmare.

 Currently the only way a use could know how to get an operation to operate
 on linear vs perceptually uniform RGB is if someone supplied a table that
 includes all operations, with a column for how to get linear RGB and another
 column for how to get perceptually uniform RGB. For examples of how very
 inconsistent the current UI is, see this table:
 http://ninedegreesbelow.com/photography/users-guide-to-high-bit-depth-gimp.html#linear-or-perceptual-table.
 The table explains how to get selected operations to work on linear RGB.


 Best,
 Elle
 ___
 gimp-developer-list mailing list
 List 

Re: [Gimp-developer] GIMP at Libre Graphics Meeting 2015 - Toronto, Canada, April 29 to May 2

[Joao S. O. Bueno]

Any tentative time set for the GIMP B.o.F. already?
So that those of us who could not make it this year can follow on irc.

On 28 April 2015 at 03:08, Michael Schumacher schum...@gmx.de wrote:
 Hi all,

 as in most years, some of us are at the Libre Graphics Meeting.

 If you are in the area around Toronto, Canada, and can easily get there,
 then consider to use this opportunity to meet us and many more people there:

 http://libregraphicsmeeting.org/2015/participants/


 LGM is part meeting other people, and part talks - the schedule is
 available here: http://libregraphicsmeeting.org/2015/program/



 --
 Regards,
 Michael
 GPG: 96A8 B38A 728A 577D 724D 60E5 F855 53EC B36D 4CDD
 ___
 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

Re: [Gimp-developer] Gimp in private schools and educational institutions

[Joao S. O. Bueno]

On 15 April 2015 at 05:40, Simon Budig si...@budig.de wrote:
 Gez (lis...@ohweb.com.ar) wrote:
 [...] optional patch
 that provides and easy way to remove the name GIMP from the UI,
 replacing it for a different one?

 Now, seriously. What do devs think about this idea? If somebody provided
 a good patch for building GIMP easily with a different name as an
 option, would you accept that patch?

 No. It would only play into the hands we already have with fake
 packagers who sell Gimp without mentioning the Gimp brand name and
 without mentioning that Gimp is available for free as well.


Indeed -
Mr. Bagot -
I think the best approach you have is write the Software name in full
in all possible instances
(e-mails, documents, letters, etc...) - just write GNU Image
Manipulation Program - and leave
the acronym as if it did not exist in all written documents.

In my experience, name connotations are a matter os perception, and
many times it just hit
us in certain contexts - and may not bother our neighbors at all. For
example, it was only when phrasing this
paragraph I stopped to think about the sound of your last name would
have in my native language, and the possible
linked connotations - but just because I forced myself to think into
it in this context. Just as I don expect a full
400 million Spanish speakers to think of me as a good person.


Best regards,

   js
 --


 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
___
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 I can't repeat this command?

[Joao S. O. Bueno]

Hi Marco  -

What I like to do in cases like this is to enable
preferences-inbterface-Dynamic Keyboard shortcuts ,  (actually I
keep this always on), and assign a temporary shortcut to the action at
hand (in this case, shrink selection). ot having the overhead of going
through the keyboard shortcut efitor for doing things like this
really makes a difference. Try it.

On 22 March 2015 at 07:17, Marco Ciampa ciam...@libero.it wrote:
 On Sun, Mar 22, 2015 at 10:55:35AM +0100, Ofnuts wrote:
 Redo is used to replay what you just removed with Undo, in other
 words it undoes the undo, so it is enabled only if you just did an
 undo.

 Oh my... thanks for clarifying me this very silly question!

 Very sorry for the noise!

 --


 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
___
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] Selections to shapes

[Joao S. O. Bueno]

Try using Select-To Path --
Everything you describe is already possible.

Although, maybe, selection-To path could have more usability if it
would change to the Path Tool, with the new path as active, so that
its nodes are displayed at once. Currently, one has to manually go to
the Paths dockable, set the path as visible, select the Path Tool and
click on the path (4 separate actions) before being able to see the
handles.


   js
  --


On 20 March 2015 at 06:01, Joseph Bupe joseph.b...@gmail.com wrote:
 Hi,

 It would be nice to have controls for tweaking rectangle and ellipse
 selections into different shapes for designing pixel-based graphics with
 easy. Currently, the rectangle selections can only be tweaked into a
 rounded-corners shape. This should be extended further to allow shaping
 selections into different forms based on the type of the starting selection.

 Such design shapes can then be filled with colour, stroked, beveled,
 embossed etc.

 Regards.

 Joseph
 ___
 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

Re: [Gimp-developer] Huge performance improvement idea

[Joao S. O. Bueno]

On 20 March 2015 at 13:43, Chandana Bandara cbsoftw...@gmail.com wrote:
 Greetings from Chandana,

Hi Chandana -
welcome to this group.

Thank you for your suggestions.
In fact the workflow you suggest could be made explicitly possible in
the future as we move GIMP to
a non-destructive editing paradgim using GEGL

That will take a lot of time, however - as there is a huge lot of work
for such fundamental changes.

However, the good news is that the underlying image processing in GIMP
- GEGL - was conceived
to allow preview renderings - that would behave just like you suggest
(working on the
zoomed out part of an image as if it were a smaller image, for
example) - and just this week
Pippin sent an e-mail detailing how the final pieces are being put in
place so that this starts working.

So - it is not so simple, or explicit for the final users as you have
it in your e-mail, but it is basically the same idea -
just search the list developer list archives for a message from Øyvind
Kolås on March the 18th to see the details.

  js
 --



 I have an idea that can make a huge impact on performance increase on GIMP
 image manipulations. This idea occurred to me when I was working on a large
 banner which I had to do some experiments (Colour changes, layer movements,
 Font changes, etc...)

 The problem was, it took so long time to do even a small change in the
 image. I do not have huge memory. What I thought was, what if I can
 1. Get a copy of the current image (with all layer details)
 2. Resize it to a smaller version
 3. Do all the modifications I do in the small version
 4. Apply all changes I did in the smaller version to the larger version

 This way, computer resources required are much less than what needed in the
 original image. We need to implement a way so that GIMP will remember all
 the modifications we do in the small image and from a single click GIMP
 should be able to do it to the larger image. Another good version of this
 idea would be to

 1. Create a small image
 2. Do whatever we want in to the small image
 3. From a single click, GIMP create scaled up image and apply all the
 things we did to the small image to the large image

 Please take this idea into consideration.

 Thank you,
 Chandana Bandara
 Coolbit Software Solutions (Pvt) Ltd
 www.coolbitsoftware.com

 Web applications | Web designing | Web hosting | Product/Commercial
 photography
 ___
 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

Re: [Gimp-developer] Cage Transform Tool's transformations

[Joao S. O. Bueno]

On 17 March 2015 at 18:20, Elle Stone ellest...@ninedegreesbelow.com wrote:
 On 03/17/2015 02:51 PM, Joseph Bupe wrote:

 Ok Alex, the progress bar in the link below is what I am referring to. It
 appears between every tweak on the Cage transform tool.

 Link: http://s4.postimg.org/qqlkwjx4t/snapshort.png

 I just feel it's too disruptive because I have to halt and wait for the
 progress bar to run every single tweak.


 Everything works faster on a smaller image.

 Unlike simpler edits like Curves, currently the transform tools don't save a
 record as a recallable transform.

 Let's say you open a smaller version of the image and make the cage
 transform. Could the transform steps be recorded and then replayed on the
 full-size image? Or would coding something like this be just as complicated
 as making the transform faster in the first place?

Pippin wrote a great answer on the way that will be fixed, and some
other improvements
that can be done GIMP side in the future.

As for the present, a workaround find by  my colleague Americo Gobbo,
is to turn off the visibility
os the layer to be caged.
So: duplicate layer, hide layer, draw cage based on the duplicate,
turn visibility back on, apply cage.

  js
 --



 --
 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
___
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] Useability enhancement request: unified/expanded file export dialog

[Joao S. O. Bueno]

On 11 March 2015 at 18:05, Ofnuts ofn...@gmx.com wrote:
 On 11/03/15 14:26, Elle Stone wrote:


 3. Scaling upon export:

 When exporting an image for display on the web, the image usually needs to
 be resized, and sometimes you might want to make some additional edits at
 the reduced size before the final export. But not always. It would be
 convenient to have the option to scale the image as part of the file export
 dialog, leaving the GIMP XCF file at the original size.


 For current Gimp there is the Save for Web plug-in that lets you
 crop/scale the image. However it's not uncommon to do a little bit of
 sharpening after a downscale, or maybe add some watermark... Better take the
 habit to use ImageDuplicate. This creates an untitled image to there is
 little risk to overwrite the original image with a scaled down version(*).

 (*) in the belt-cum-suspenders series, shouldn't Gimp issue a warning when
 saving an image if it detects that the image has been scaled down/cropped?
 This is another case of potential accidental loss of data. **ducks for
 cover**

IMO, the medium term solution for all export-workflow problems is to have
an in-gimp way to manipulate a set of transformations to be applied to an image
on export.

Thinking on an UI for this now is up to us - so, why not bring the idea
to the list?

Currently, actually most export plug-ins do perform a
image-duplicate, image-flatten (or merge visible layers) and save
the resulting layer. Indexed formats do a image-duplicate,
image-flatten, image-convert-to-indexed sequence.

Having this in an UI would allow one to have several presets like:
image duplicate, image-resize(max-width: N, preserve-aspect: True),
image-sharpen, image-flatten, image-convert-to-precision(8bpp),
gimp-pause-for-review, export-to-desired-file-format  )

That would allow presets for example, that could at once save for the
various icon-sizes needed for
icons in mobile projects bound to a single keystroke. (and having  a
mark as clean node available for these presets
could also give an option to the I do only jpeg exports shouters)
___
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 with Python plugin exporting to raw file (using Gimp 2.9)

[Joao S. O. Bueno]

On 21 February 2015 at 10:35, Partha Bagchi parth...@gmail.com wrote:
 Hi João,

 What's your timeframe for modifying pygimp to use introspection? I
 have not yet built glib and friends with introspection because it's a
 pain and it's finicky. :)

No idea on timeframes . Introspection as it is now, since GIMP
itself does not make use of it,
is mostly needed for the UI parts of Pygimp.  (i.e. changing from
traditional pygtk
to gobject introspection gtk)  - but I jsut remebered the major blocker there:
GUI building with gobject introspection is known not to work well with
GTK2 - we'd
need to change pygimp to gtk3.

That would not be a problem for Linux systems (hey, Pygimp used
TCL based Tk widgets when it first debut), it should be a nono for
packagers for Mac OS X and Windows.

Can someone who works on the installers  give me some feedback on that?




 Thanks,
 Partha


 On Fri, Feb 20, 2015 at 11:54 PM, Joao S. O. Bueno gwid...@gmail.com wrote:
 Hi  -
 I've actually comitted the above method - but beware it is subject to
 some changes.

 I've added the precision read-only property to gimp-images, and the
 get_data method
 to drawables (layers and channels) -
 get_data returns a Python array.array object - it even features
 conveninent methods
 to write itself to a file (https://docs.python.org/2/library/array.html) -
 For now, it  takes an optional string argument representing a BABL pixel 
 format
 (http://gegl.org/babl/BablFishPath.html) and will return an array of
 the apropriate data type.
 The default is RGBA float - but I think it would be better to change
 it to default to the
 drawable native data type- still allowing an explicit format to be passed.


 I will probably keep it the return type an array, but possibly
 subclass it to an object that can
 take in 2D indexes to ease pixel access, as  currently existing python
 pixel_region object allows
 (thus: data[100, 50] will be as valid as data[50 * drawable.width +
 100] to get to a single pixels.

 On the short term roadmap there is a set_data  - (or maybe blit )?

 And at the point in time it is possible to use gobject introspection along
 pygimp (it can't be done in a straightforward way), make
 drawable.get_buffer directly available and returning a Gegl buffer
 wrapped in a convenient Python object.

 On 21 February 2015 at 00:49, Joao S. O. Bueno gwid...@gmail.com wrote:
 Getting there... no need to poke me for now -

 GIMP 2.9.1 Python Console
 Python 2.7.5 (default, Nov  3 2014, 14:26:24)
 [GCC 4.8.3 20140911 (Red Hat 4.8.3-7)]
 img = gimp.image_list()[0]
 a = img.layers[0].get_data()
 len(a)
 1228800
 a[0:300]
 array('f', [0.0003035269910469651, 0.0003035269910469651,
 0.0003035269910469651, 0.6235294342041016, 0.0003035269910469651,
 0.0003035269910469651, 0.0003035269910469651, 0.6235294342041016,
 0.0003035269910469651,...]

 On 20 February 2015 at 09:50, Joao S. O. Bueno gwid...@gmail.com wrote:
 Hi Alek_

 it turns out that the Python bindings for GIMP had not been updated to
 deal with higher precision images as of yet.

 Don't despair - since you had built GIMP master, this is as good time
 as any to get it going. :-)

 You can get to know the image precision (and even set it) thorugh the
 PDB, though, with a call to:

 pdb.gimp_image_get_precision

 Now - for the actual business: I think there are two ways to go - one
 short term, with
 a get and set buffer method on Python drawables that will just
 copy the inner image data
 and make it available in a Python array. That would suffice for most
 needs like yours, I guess.

 The other, longer term and proper way, is to write calls to get the
 proper GEGL Buffer objects
 in Python, using GEGL Python bindings - that will allow the use of any
 of GEGL's operations
 on GIMP Image data and commit it back - but it will also require the
 python-gegl package.

 Those bindings are currently living in my personal repo, and  could
 work for you right now, as they do allow access to the buffer data -
 but you have to build GEGL with the extra --enable-introspection
 switich to get then going.
 (http://github.com/jsbueno/python-gegl )

 But -- let's focus in enabling one to get the high-depth pixel
 contents from GIMP without need for those for now.
 Feel free to poke me again in 24 hours if there are no news on this 
 subject.

   js
  --


 On 19 February 2015 at 23:06, Alek _ specta...@outlook.com wrote:



 I'm using Gimp 2.9 experimental build, which I downloaded from
 partha.com, to specifically have edit ability with 16-bit per channel
 images.  I originally posted in gimpforums.com and was told I should try 
 here.



 I'm trying to write a Python plugin to export an image as a raw file
 (just data, no header).  The current option to export as raw image data
 (File - Export as - Raw image data) seems to only support writing out 
 as 8-bit even when the image precision
  is greater than 8-bit.  So I wanted to write a plugin so I could export
  my 16-bit per channel image to a raw file

Re: [Gimp-developer] Need help with Python plugin exporting to raw file (using Gimp 2.9)

[Joao S. O. Bueno]

On 21 February 2015 at 16:46, Alek _ specta...@outlook.com wrote:
 Where did you commit the changes?  I looked at
 https://github.com/jsbueno/python-gegl and it says the last commit was
 Jun 6, 2014.


Yes - it works nicely for what it does - enabling access to gegloperators,
but tehre are new features needed (and bit-rot to avoid)

 I did find a way to get my values.  I found out that
  if I enable precision (pdb.gimp_plugin_enable_precision), the pixel
 array from srcTile[x,y] will contain the higher precision data.  I just
 need to concatenate the high/low bytes together through bit shifting.
 The comments for gimp_plugin_enable_precision says Switches this
 plug-in to using the real bit depth of drawables but I don't understand
  what that means.  Is this a compatibility thing, to make sure older
 stuff that always assumed 8-bit will still work?
 So you're supposed to
 enable precision if you want to access to the new higher bit depth?
Yes - I did not know this call, but it certainly is there for this reason  -
The commits from yesterday on pygimp however, will make it more straightforward,

The old way (tiles nad pixel regions) will be kept, if it is kept,
just for compatibility reasons.


 Date: Sat, 21 Feb 2015 02:54:51 -0200
 Subject: Re: [Gimp-developer] Need help with Python plugin exporting to raw 
 file (using Gimp 2.9)
 From: gwid...@gmail.com
 To: specta...@outlook.com
 CC: gimp-developer-list@gnome.org

 Hi  -
 I've actually comitted the above method - but beware it is subject to
 some changes.

 I've added the precision read-only property to gimp-images, and the
 get_data method
 to drawables (layers and channels) -
 get_data returns a Python array.array object - it even features
 conveninent methods
 to write itself to a file (https://docs.python.org/2/library/array.html) -
 For now, it  takes an optional string argument representing a BABL pixel 
 format
 (http://gegl.org/babl/BablFishPath.html) and will return an array of
 the apropriate data type.
 The default is RGBA float - but I think it would be better to change
 it to default to the
 drawable native data type- still allowing an explicit format to be passed.


 I will probably keep it the return type an array, but possibly
 subclass it to an object that can
 take in 2D indexes to ease pixel access, as  currently existing python
 pixel_region object allows
 (thus: data[100, 50] will be as valid as data[50 * drawable.width +
 100] to get to a single pixels.

 On the short term roadmap there is a set_data  - (or maybe blit )?

 And at the point in time it is possible to use gobject introspection along
 pygimp (it can't be done in a straightforward way), make
 drawable.get_buffer directly available and returning a Gegl buffer
 wrapped in a convenient Python object.

 On 21 February 2015 at 00:49, Joao S. O. Bueno gwid...@gmail.com wrote:
  Getting there... no need to poke me for now -
 
  GIMP 2.9.1 Python Console
  Python 2.7.5 (default, Nov  3 2014, 14:26:24)
  [GCC 4.8.3 20140911 (Red Hat 4.8.3-7)]
  img = gimp.image_list()[0]
  a = img.layers[0].get_data()
  len(a)
  1228800
  a[0:300]
  array('f', [0.0003035269910469651, 0.0003035269910469651,
  0.0003035269910469651, 0.6235294342041016, 0.0003035269910469651,
  0.0003035269910469651, 0.0003035269910469651, 0.6235294342041016,
  0.0003035269910469651,...]
 
  On 20 February 2015 at 09:50, Joao S. O. Bueno gwid...@gmail.com wrote:
  Hi Alek_
 
  it turns out that the Python bindings for GIMP had not been updated to
  deal with higher precision images as of yet.
 
  Don't despair - since you had built GIMP master, this is as good time
  as any to get it going. :-)
 
  You can get to know the image precision (and even set it) thorugh the
  PDB, though, with a call to:
 
  pdb.gimp_image_get_precision
 
  Now - for the actual business: I think there are two ways to go - one
  short term, with
  a get and set buffer method on Python drawables that will just
  copy the inner image data
  and make it available in a Python array. That would suffice for most
  needs like yours, I guess.
 
  The other, longer term and proper way, is to write calls to get the
  proper GEGL Buffer objects
  in Python, using GEGL Python bindings - that will allow the use of any
  of GEGL's operations
  on GIMP Image data and commit it back - but it will also require the
  python-gegl package.
 
  Those bindings are currently living in my personal repo, and  could
  work for you right now, as they do allow access to the buffer data -
  but you have to build GEGL with the extra --enable-introspection
  switich to get then going.
  (http://github.com/jsbueno/python-gegl )
 
  But -- let's focus in enabling one to get the high-depth pixel
  contents from GIMP without need for those for now.
  Feel free to poke me again in 24 hours if there are no news on this 
  subject.
 
js
   --
 
 
  On 19 February 2015 at 23:06, Alek _ specta...@outlook.com wrote:
 
 
 
  I'm using Gimp 2.9 experimental build, which I

Re: [Gimp-developer] Need help with Python plugin exporting to raw file (using Gimp 2.9)

[Joao S. O. Bueno]

Hi Alek_

it turns out that the Python bindings for GIMP had not been updated to
deal with higher precision images as of yet.

Don't despair - since you had built GIMP master, this is as good time
as any to get it going. :-)

You can get to know the image precision (and even set it) thorugh the
PDB, though, with a call to:

pdb.gimp_image_get_precision

Now - for the actual business: I think there are two ways to go - one
short term, with
a get and set buffer method on Python drawables that will just
copy the inner image data
and make it available in a Python array. That would suffice for most
needs like yours, I guess.

The other, longer term and proper way, is to write calls to get the
proper GEGL Buffer objects
in Python, using GEGL Python bindings - that will allow the use of any
of GEGL's operations
on GIMP Image data and commit it back - but it will also require the
python-gegl package.

Those bindings are currently living in my personal repo, and  could
work for you right now, as they do allow access to the buffer data -
but you have to build GEGL with the extra --enable-introspection
switich to get then going.
(http://github.com/jsbueno/python-gegl )

But -- let's focus in enabling one to get the high-depth pixel
contents from GIMP without need for those for now.
Feel free to poke me again in 24 hours if there are no news on this subject.

  js
 --


On 19 February 2015 at 23:06, Alek _ specta...@outlook.com wrote:



 I'm using Gimp 2.9 experimental build, which I downloaded from
 partha.com, to specifically have edit ability with 16-bit per channel
 images.  I originally posted in gimpforums.com and was told I should try here.



 I'm trying to write a Python plugin to export an image as a raw file
 (just data, no header).  The current option to export as raw image data
 (File - Export as - Raw image data) seems to only support writing out as 
 8-bit even when the image precision
  is greater than 8-bit.  So I wanted to write a plugin so I could export
  my 16-bit per channel image to a raw file with the 16-bit data
 preserved.

 My image is a 16-bit grayscale 3x3 image with a checkerboard pattern of 
 alternating white and black pixels.



 I used the sample script 'test-discolour-layer-v4.py' from 
 http://registry.gimp.org/node/28124
  as a guide on how to iterate through every pixel.  I have some
 questions and ran into some problems.  What I have so far can be seen here 
 (http://pastebin.com/U49VZYVT).  It just iterates through the pixels and 
 outputs values to the
 error console.



 1. How do I query for the precision?  That is, I want to know if the
 current image is 8-bit gamma integer, or 16-bit linear integer, or
 something else.  I looked at the image object's attributes and didn't
 find anything.



 2. When I get the pixel value from srcTile[x,y], the value is always
 8-bit.  With the white pixels, the value should be 65535 but I got 255.  How 
 do I get the
 proper value?  When I use the Color Picker tool with info window, it says 
 65535 for white.  How do I get that value?



 3. My code creates a new layer from visible and then queries the pixels from 
 that.  In my image, all values returned are 255 even for the black pixels.  
 When I put my checkboard pattern on the Background layer and query that 
 layer, I get correct values (though in 8-bit).  For any other layer other 
 than Background, the values are always 255.  I don't know what I'm doing 
 wrong.


 Can someone help me or point me in the right direction?

 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
___
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 with Python plugin exporting to raw file (using Gimp 2.9)

[Joao S. O. Bueno]

Hi  -
I've actually comitted the above method - but beware it is subject to
some changes.

I've added the precision read-only property to gimp-images, and the
get_data method
to drawables (layers and channels) -
get_data returns a Python array.array object - it even features
conveninent methods
to write itself to a file (https://docs.python.org/2/library/array.html) -
For now, it  takes an optional string argument representing a BABL pixel format
(http://gegl.org/babl/BablFishPath.html) and will return an array of
the apropriate data type.
The default is RGBA float - but I think it would be better to change
it to default to the
drawable native data type- still allowing an explicit format to be passed.


I will probably keep it the return type an array, but possibly
subclass it to an object that can
take in 2D indexes to ease pixel access, as  currently existing python
pixel_region object allows
(thus: data[100, 50] will be as valid as data[50 * drawable.width +
100] to get to a single pixels.

On the short term roadmap there is a set_data  - (or maybe blit )?

And at the point in time it is possible to use gobject introspection along
pygimp (it can't be done in a straightforward way), make
drawable.get_buffer directly available and returning a Gegl buffer
wrapped in a convenient Python object.

On 21 February 2015 at 00:49, Joao S. O. Bueno gwid...@gmail.com wrote:
 Getting there... no need to poke me for now -

 GIMP 2.9.1 Python Console
 Python 2.7.5 (default, Nov  3 2014, 14:26:24)
 [GCC 4.8.3 20140911 (Red Hat 4.8.3-7)]
 img = gimp.image_list()[0]
 a = img.layers[0].get_data()
 len(a)
 1228800
 a[0:300]
 array('f', [0.0003035269910469651, 0.0003035269910469651,
 0.0003035269910469651, 0.6235294342041016, 0.0003035269910469651,
 0.0003035269910469651, 0.0003035269910469651, 0.6235294342041016,
 0.0003035269910469651,...]

 On 20 February 2015 at 09:50, Joao S. O. Bueno gwid...@gmail.com wrote:
 Hi Alek_

 it turns out that the Python bindings for GIMP had not been updated to
 deal with higher precision images as of yet.

 Don't despair - since you had built GIMP master, this is as good time
 as any to get it going. :-)

 You can get to know the image precision (and even set it) thorugh the
 PDB, though, with a call to:

 pdb.gimp_image_get_precision

 Now - for the actual business: I think there are two ways to go - one
 short term, with
 a get and set buffer method on Python drawables that will just
 copy the inner image data
 and make it available in a Python array. That would suffice for most
 needs like yours, I guess.

 The other, longer term and proper way, is to write calls to get the
 proper GEGL Buffer objects
 in Python, using GEGL Python bindings - that will allow the use of any
 of GEGL's operations
 on GIMP Image data and commit it back - but it will also require the
 python-gegl package.

 Those bindings are currently living in my personal repo, and  could
 work for you right now, as they do allow access to the buffer data -
 but you have to build GEGL with the extra --enable-introspection
 switich to get then going.
 (http://github.com/jsbueno/python-gegl )

 But -- let's focus in enabling one to get the high-depth pixel
 contents from GIMP without need for those for now.
 Feel free to poke me again in 24 hours if there are no news on this subject.

   js
  --


 On 19 February 2015 at 23:06, Alek _ specta...@outlook.com wrote:



 I'm using Gimp 2.9 experimental build, which I downloaded from
 partha.com, to specifically have edit ability with 16-bit per channel
 images.  I originally posted in gimpforums.com and was told I should try 
 here.



 I'm trying to write a Python plugin to export an image as a raw file
 (just data, no header).  The current option to export as raw image data
 (File - Export as - Raw image data) seems to only support writing out as 
 8-bit even when the image precision
  is greater than 8-bit.  So I wanted to write a plugin so I could export
  my 16-bit per channel image to a raw file with the 16-bit data
 preserved.

 My image is a 16-bit grayscale 3x3 image with a checkerboard pattern of 
 alternating white and black pixels.



 I used the sample script 'test-discolour-layer-v4.py' from 
 http://registry.gimp.org/node/28124
  as a guide on how to iterate through every pixel.  I have some
 questions and ran into some problems.  What I have so far can be seen here 
 (http://pastebin.com/U49VZYVT).  It just iterates through the pixels and 
 outputs values to the
 error console.



 1. How do I query for the precision?  That is, I want to know if the
 current image is 8-bit gamma integer, or 16-bit linear integer, or
 something else.  I looked at the image object's attributes and didn't
 find anything.



 2. When I get the pixel value from srcTile[x,y], the value is always
 8-bit.  With the white pixels, the value should be 65535 but I got 255.  
 How do I get the
 proper value?  When I use the Color Picker tool with info window, it says 
 65535 for white.  How

Re: [Gimp-developer] Need help with Python plugin exporting to raw file (using Gimp 2.9)

[Joao S. O. Bueno]

Getting there... no need to poke me for now -

GIMP 2.9.1 Python Console
Python 2.7.5 (default, Nov  3 2014, 14:26:24)
[GCC 4.8.3 20140911 (Red Hat 4.8.3-7)]
 img = gimp.image_list()[0]
 a = img.layers[0].get_data()
 len(a)
1228800
 a[0:300]
array('f', [0.0003035269910469651, 0.0003035269910469651,
0.0003035269910469651, 0.6235294342041016, 0.0003035269910469651,
0.0003035269910469651, 0.0003035269910469651, 0.6235294342041016,
0.0003035269910469651,...]

On 20 February 2015 at 09:50, Joao S. O. Bueno gwid...@gmail.com wrote:
 Hi Alek_

 it turns out that the Python bindings for GIMP had not been updated to
 deal with higher precision images as of yet.

 Don't despair - since you had built GIMP master, this is as good time
 as any to get it going. :-)

 You can get to know the image precision (and even set it) thorugh the
 PDB, though, with a call to:

 pdb.gimp_image_get_precision

 Now - for the actual business: I think there are two ways to go - one
 short term, with
 a get and set buffer method on Python drawables that will just
 copy the inner image data
 and make it available in a Python array. That would suffice for most
 needs like yours, I guess.

 The other, longer term and proper way, is to write calls to get the
 proper GEGL Buffer objects
 in Python, using GEGL Python bindings - that will allow the use of any
 of GEGL's operations
 on GIMP Image data and commit it back - but it will also require the
 python-gegl package.

 Those bindings are currently living in my personal repo, and  could
 work for you right now, as they do allow access to the buffer data -
 but you have to build GEGL with the extra --enable-introspection
 switich to get then going.
 (http://github.com/jsbueno/python-gegl )

 But -- let's focus in enabling one to get the high-depth pixel
 contents from GIMP without need for those for now.
 Feel free to poke me again in 24 hours if there are no news on this subject.

   js
  --


 On 19 February 2015 at 23:06, Alek _ specta...@outlook.com wrote:



 I'm using Gimp 2.9 experimental build, which I downloaded from
 partha.com, to specifically have edit ability with 16-bit per channel
 images.  I originally posted in gimpforums.com and was told I should try 
 here.



 I'm trying to write a Python plugin to export an image as a raw file
 (just data, no header).  The current option to export as raw image data
 (File - Export as - Raw image data) seems to only support writing out as 
 8-bit even when the image precision
  is greater than 8-bit.  So I wanted to write a plugin so I could export
  my 16-bit per channel image to a raw file with the 16-bit data
 preserved.

 My image is a 16-bit grayscale 3x3 image with a checkerboard pattern of 
 alternating white and black pixels.



 I used the sample script 'test-discolour-layer-v4.py' from 
 http://registry.gimp.org/node/28124
  as a guide on how to iterate through every pixel.  I have some
 questions and ran into some problems.  What I have so far can be seen here 
 (http://pastebin.com/U49VZYVT).  It just iterates through the pixels and 
 outputs values to the
 error console.



 1. How do I query for the precision?  That is, I want to know if the
 current image is 8-bit gamma integer, or 16-bit linear integer, or
 something else.  I looked at the image object's attributes and didn't
 find anything.



 2. When I get the pixel value from srcTile[x,y], the value is always
 8-bit.  With the white pixels, the value should be 65535 but I got 255.  How 
 do I get the
 proper value?  When I use the Color Picker tool with info window, it says 
 65535 for white.  How do I get that value?



 3. My code creates a new layer from visible and then queries the pixels from 
 that.  In my image, all values returned are 255 even for the black pixels.  
 When I put my checkboard pattern on the Background layer and query that 
 layer, I get correct values (though in 8-bit).  For any other layer other 
 than Background, the values are always 255.  I don't know what I'm doing 
 wrong.


 Can someone help me or point me in the right direction?

 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
___
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

[Joao S. O. Bueno]

Hi there -

As I've replied online to Alex - i am willing to mentor this year -
and we are still looking for more people to step up.

  js
 --




On 6 February 2015 at 13:19, Alexandre Prokoudine
alexandre.prokoud...@gmail.com wrote:
 Hello,

 Google Summer of Code 2015 is launching next week. I can do
 administration, and Michael Schumacher can be the backup admin. The
 usual question is: who's available and willing to mentor a student?

 For reference, preliminary discussions with prospective students can
 start anytime now, if we decide to  submit an application to
 participate at GSoC, the coding period is May 25 - August 21, and
 you'd have to be available another week after that for final
 evaluation.

 Full timeline:

 https://www.google-melange.com/gsoc/events/google/gsoc2015

 So, who's in? :)

 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
___
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] Drop shadow - a question from an user - developer-version 2.9

[Joao S. O. Bueno]

On 9 February 2015 at 09:15, Alexandre Prokoudine
alexandre.prokoud...@gmail.com wrote:
 On Mon, Feb 9, 2015 at 2:10 PM, Joao S. O. Bueno wrote:

 In this particular case, I am in favor of restoring the extra-layer
 creation behavior, or at least have a checkbox
 to imply it. The uses I myself make of drop shadow always require a
 separate layer.

Yes, I've just tested it and it is definitely working here. Apart from
not allowing a separate layer,
the live-preview is a major enhancement. (but the default values could
not be worse)

Maybe you are stuck to an old binary version of the operator from an old build?

  js
 --


 Joao,

 Does this GEGL op do anything for you at all? Because it does
 absolutely nothing for me (duly noted in
 http://wiki.gimp.org/wiki/Hacking:Porting_filters_to_GEGL/UI_review),
 seperate layer or no separate layer.

 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
___
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] Drop shadow - a question from an user - developer-version 2.9

[Joao S. O. Bueno]

Although the filter is intended to work that way, I consider it to be a bug.

As you know, GIMP 2.9 is still under heavy development, an done of the
pending things is to find-put a way
to have the classic plug-ins installed back again on a running GIMP
- that way, any regressions such as this could
be work-arounded by installing the previous script.

In this particular case, I am in favor of restoring the extra-layer
creation behavior, or at least have a checkbox
to imply it. The uses I myself make of drop shadow always require a
separate layer.

 (For developers: I know that breaks the a single gegl-op paradigm
for such a plug-in - since it would have to fiddle with the image
layer stack - that means that some plug-ins can't simply become an op
with automated GUI, but have to be actually coded and call GEGL and
gimplib/pdb to manipulate the image)

For now, if you can find the drop-shadow.scm file from any gimp2.8
(or less) install and put it in yours scripts dir, it will work.


  js
 --


On 8 February 2015 at 10:26, Axel und Doris ad-emmer...@t-online.de wrote:
 Hello

 OnIRC-Channel they told me, it ist better to ask the developer directly or
 write in the bug-report. So, I hope this is the right place now for my
 question.

 I took a first look of the new development version 2.9. on my win7 system.
 Great work!
 My question: The new Filter “Drop Shadow” creates no extra layer. Is this a
 bug or a new feature?

 It would be very importend for our work to get the shadow on an extra layer,
 because we need it for extra manipulations.
 It will be nice, if we have the choice to merge down the layers or not.


 Thanks for your time to get it fixed.
 do-se (this is my nick in the gimp-world)



 ___
 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

Re: [Gimp-developer] [Gimp-user] Translation of Gimp

[Joao S. O. Bueno]

Alexandre:

Maybe he is referring to Portugal's portuguese
https://l10n.gnome.org/languages/pt/gnome-gimp/ui/

Or, more likely,  to the development version - which is actually how I
started years ago.

Pedro -

Hi -

I use to be the maintainer of the Brazilian Portuguese translation for GIMP.

I had not made any work in the post 2.8 series - so if you are using
GIMP from master you will see
missing work.

You are, of course, welcome to help.

The official channel for translations, which include a o workflow for
revisions is to sign in
the  https://l10n.gnome.org/ and the pt_BR translators list - after
taht you will be able to check out
incomplete pot files  from that site, and lock them, so there is no
effort duplication.

Feel free to write me directly on this e-mail address if you have any
doubts, and, please do so if you have translation suggestions that
would involve the change of terms currently in use.


Regards,

  js
 --


On 13 January 2015 at 13:52, Alexandre Prokoudine
alexandre.prokoud...@gmail.com wrote:
 On Tue, Jan 13, 2015 at 6:45 PM, Jehan Pagès wrote:
 Hi,

 On Tue, Jan 13, 2015 at 12:02 PM, Pedro Albuquerque
 palbuquerqu...@gmail.com wrote:
 Hi,

 I started using Gimp some time ago and first thing I noticed is that the
 translation to Portuguese-Pt, besides not being complete, is outdated.

 ???

 https://l10n.gnome.org/languages/pt_BR/gnome-gimp/ui/

 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
___
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] Brush size relative to canvas size

[Joao S. O. Bueno]

It is obvious that the current way of changing brush size is nearly unusable.

I have doubts however if your proposal would be the best way to have a
better UI, or if it is just a work around for the current behavior.

Above all, just because Richard steped up with a proposed UI behavior
for th e proposed feature does not mean, in any way, it would be
easy to implement -  there would need to be hacks all way down to
how Units are implemented inside GIMP, and that could affect all code
using units - just to star with.

Nonetheless it is way past the time we should have a decent way to
deal with brush size - if Peter is around, it would be nice to hear f
he could come up with some proposal on this.
(I've tried suggesting alternatives in the past, but got either
feedback, or feedback contrary to my suggestions)

  js
 --



On 20 October 2014 09:39, Johann jo.y.v...@gmail.com wrote:


  From: jo.y.v...@gmail.com
  Date: Sat, 18 Oct 2014 14:30:24 +0200
  To: gimp-developer-list@gnome.org
  Subject: [Gimp-developer] Brush size relative to canvas size
 
  Hi guys,
 
  some suggestions how to improve brushes:
  Brush size relative to canvas size
 
  would be handy to have a dynamic brush size, like: if i zoom in, the 
  brush size adapts to the canvas size and shrinks relative to the zoom 
  factor. Vice-versa, if i zoom out, the brush size grows relative to the 
  zoom factor.
 

 I imagine this could be 'easy' to implement simply by adding a new unit of 
 measure for brush sizes: screen pixels (as contrasted to image pixels). 
  This might not be a useful feature to have for all measurements, but for 
 brush sizes it could indeed be a plus.

 For comparison, when you make adjustments in Inkscape the Alt modifier 
 allows you to adjust things in terms of screen pixels (using the current 
 zoom level), and it's a handy thing to have available.

 -- Stratadrake
 strata_ran...@hotmail.com
 
 Numbers may not lie, but neither do they tell the whole truth.



 nice, if this feature looks relative easy to implement!
 I, and thats me, would suggest a check-button or something persistent to 
 activate this feature, rather some modifier keys (maybe as a complementary 
 function) - just to make things handier
 As a digital painter, i search always for new solutions to improve my work - 
 a consistent brush size would help to speed up things, coupled with presets.

 ___
 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

Re: [Gimp-developer] Gimp Gui redesign

[Joao S. O. Bueno]

Hi Ricardo -

This is the correct forum --
just let me give you some advice so that you can start to adjust your
expectatives, and avoid frustration both to you and to developers:

GIMP is a huge project, with a history going back almost 2 decades,
has millions of lines of code, and is maintained by _few_ volunteers -
in their spare time.

That means any changes that are all set to go, and agreeded upon take
months or years to be completed. Sometimes even featrues that appear
simple to people outside the code.

That said, for _some_ of things in the UI there was a careful planing
and thinking on them.
Some of them just where finished up in a way this is what I could
come up with along the years - and still, there are some UI features
reviewed and backed by UI experts in the queue to get implemented.

Moreover, any new UI feature should be tought and approved by the
people thinking the UI and UX aspects of the project, regardless of
what proponents and developers both think about it.

I think you can perceive that a proposal for a complete overhaul of
the UI, - as suggested by your
Gimp Gui redesign e-mail title will hardly be welcome all at once -
even if most of the suggestions are actually great improvements on the
current program.

Therefore, please, keep in mind that in this forum there are people
who put several years of their lifes in making the program be what it
is today - most of times believing what we have today is the right way
to do it. And sometimes it just is. :-)  (mostly not, we are well
aware of a lot of pitfalls in the UI). There are also people
passionate about UI aspects - jsut quietly waiting for discussion to
begin ...

That said, again, this is a good forum as any to present your ideas. Welcome.


   js
  --

On 22 September 2014 19:14, Ricardo Patiño dragoncross...@gmail.com wrote:
 I really don't know hot to contact anyone at gimp a just need help I did
 something and i would like to show it to the people who are in charge or
 who work with the GUI. Just to see what the think about it!. Thanks!!! I
 will really appreciate any help wt it. This is only a preview..i have
 more

   ATT Ricardo
 ___
 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

Re: [Gimp-developer] Query about Brushes and names

[Joao S. O. Bueno]

On 10 September 2014 08:09, Andrew Francis u10...@yahoo.co.uk wrote:
 Dear Sir or Madam,
 I do hope my query doesn't automatically go out to all developers - I don't 
 want to pester everyone with it!  My apologies if I have done so.


 I just have a query about GIMP and if it is possible to change names of 
 brushes - the boxes that I would have expected to take input for names don't 
 let me do so which is why I'm addressing this to developers directly.

So - indeed, it is an UI issue -GIMP currently  don't distinguish
between resources, including brushes, which are marked as read only
(either in the file system, or just marked as from a folder made
read-only in the preferences).  So, brush names for new brushes should
be changeable - but to change the name of brushes that ship with GIMP
you have to move then to a user writable location, and make the proper
changes in the Brush folders page in the preferences.



 I notice also that there is a filter option and wondered how a person might 
 tag brushes with filterable options?

Maybe you are mistaking the brush name for brush tags?
Please take a look at the documentation and  check if that is the case:

http://docs.gimp.org/en/gimp-tagging.html


 I attached an image with a couple of screenshots added in case I am not being 
 clear - I don't know the names for the 'bits' and am just starting as a gimp 
 user.


The mail list does not accept attached files - if I had not addressed
your issues correctly, please post your image somewhere on the web and
send us the link.

Also, you can try e-mailing the user list instead of here - there
should be more people willing to help with day-to-day using issues
than here.


 Thanking you in advance for any advice you may be able to offer me,

 Andrew Francis
 
___
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] ANNOUNCE: GIMP 2.8.14 released

[Joao S. O. Bueno]

Yaii! Now we are getting up to speed!


On 26 August 2014 14:50, Michael Natterer mi...@gimp.org wrote:
 Hi,

 GIMP 2.8.14 has been released. This is a bugfix release
 in the stable 2.8 series, no new features were added.

 Yesterday's 2.8.12 release had broken library versioning,
 please don't distribute any binaries of 2.8.12!

 For a complete list of changes since 2.8.12 please see the Changes
 section below. Also see the release notes of the 2.8 series at
 http://www.gimp.org/release-notes/gimp-2.8.html

 Happy GIMPing,
 --Mitch


 Download
 

   GIMP 2.8.14 is available from:

   http://download.gimp.org/pub/gimp/v2.8/

   and from the mirrors listed at:

   http://www.gimp.org/downloads/#mirrors

   Please use the torrent, it distributes
   the download bandwidth across all mirrors:

   http://download.gimp.org/pub/gimp/v2.8/gimp-2.8.14.tar.bz2.torrent

   The checksum of the tarball is:

   233c948203383fa078434cc3f8f925cb  gimp-2.8.14.tar.bz2


 Overview of Changes from GIMP 2.8.12 to GIMP 2.8.14
 ===

 General:

  - Fix libtool versioning (forgot to bump gimp_interface_age)


 ___
 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

Re: [Gimp-developer] ANNOUNCE: GIMP User Manual 2.8.2 released

[Joao S. O. Bueno]

caros  --

saiu a nova versão do manual do GIMP - 2.8.2, com a tradução completa
para PortuguÊs  - o maual é ao mesmo tempo um livro e a ajuda online
do GIMP, com textos sore cada item da interface quando se aperta F1 -

Instalem, testem e divulguem!

:-)

abraços,

   js
  --


-- Forwarded message --
From: Roman Joost romanof...@gimp.org
Date: 13 August 2014 23:30
Subject: [Gimp-developer] ANNOUNCE: GIMP User Manual 2.8.2 released
To: GIMP Docs gimp-docs-l...@gnome.org, Gimp Developer
gimp-developer-list@gnome.org, GIMP User gimp-user-l...@gnome.org


Hi,

A new version of the user manual for GIMP 2.8 has been released!

You can find the release on download server:

  http://download.gimp.org/pub/gimp/help/gimp-help-2.8.2.tar.bz2
  (md5: a591c8974b2f4f584d0a769d52ed6c5b, 152MB)


We have included:

* complete translation of Brazilian Portuguese

* many bug fixes


For easy installation, we suggest that you wait until an installer for this
release has been packaged for your platform. Find more releases and information
about our goals and how you can help at http://docs.gimp.org as well as
the wiki page under: http://wiki.gimp.org/wiki/Documentation:Main.

Happy GIMPing!
--
Roman Joost
www: http://www.romanofski.de
email: romanof...@gimp.org
___
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

Re: [Gimp-developer] User of Software

[Joao S. O. Bueno]

On 14 July 2014 07:15, Lythgoe Sharon sharon.l.lyth...@wwl.nhs.uk wrote:
 Hi



 I work in an NHS organisation and we would like to download and use your
 software as it's been recommended to us.  However I've looked through
 the licence agreement on the gimp website and although it appears to be
 covered, our IT specialist have said that there are sometimes parts of
 the system which use code from other suppliers which is not covered by
 the same licensing agreement.  Could you assure me that it is ok for us
 to use this software for free?

yes, it is.
Tell your specialist to read the acompaining COPYING file, which contains
the license for use and redistribution of the Software, the GPL v.3 -
Most of the text deals with redistributing the program - as for running,
the license simply states that:

This License explicitly affirms your unlimited
permission to run the unmodified Program.




 Many thanks for your help,



 Sharon



 Sharon Lythgoe
 IMT Training Manager

 IT Training Department



 t.  01942 82 2020

 e.   sharon.l.lyth...@wwl.nhs.uk mailto:sharon.l.lyth...@wwl.nhs.uk

 w.   www.wwl.nhs.uk http://www.wwl.nhs.uk/

 Wrightington, Wigan and Leigh NHS Foundation Trust
 Suite 5. Buckingham Row
 Brick Kiln Lane
 Wigan WN1 1XX

 your hospitals, your health, our priority



   http://www.facebook.com/WWLNHS   http://twitter.com/wwlnhs




 ___
 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

Re: [Gimp-developer] Compile gimp plugins with lazarus

[Joao S. O. Bueno]

Exactly  - I don't think this could work, unless lazarus has a way to place
calls to native code functions in dynamic libraries. If so, one could
make use of
libgimp and create a plug-in just like the C plug-ins.

Otherwise, no deal.

  js
 --

On 8 July 2014 14:51, scl scl.gp...@gmail.com wrote:
 Hi,


 On  8.7.2014 at 5:31 PM Paco Garcia wrote:

 Hi, is there any way to develop gimp plugins with lazarus ide?


 as Lazarus is a Pascal IDE programming GIMP plug-ins with
 Lazarus would require Pascal bindings to GIMP or its
 Procedural Database (PDB). I don't know of any.

 Kind regards,

 Sven


 ___
 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

Re: [Gimp-developer] Blend Tool UI

[Joao S. O. Bueno]

On 25 June 2014 01:59, Michael Henning dra...@darkrefraction.com wrote:
 Joao: You might have misunderstood me. I'm referring to the blend
 tool, not the gradient editor.

Yes . I indeed was thinking about the gradient editor - just later I
realized it was the
actual application of the gradient on Canvas.

My comment about the shapped ones however is valid - I think they
should stay, even if terhe
is no possible action for the time being. The shaped blends do require
control as well, and it would be nice
if we could be work ont hat for the future. If you look there, there
is an open bug
about the offset parameter not being used in the shapped fills (and
the ending point is actually ignored).
Maybe, adding some control there, the 3 shaped... fills could be
made into a single one.

https://bugzilla.gnome.org/show_bug.cgi?id=505755

  js
 --


 scl: Just the ones whose name starts with 'Shaped'.

 Ofnuts: Yes, FiltersRender is probably a better place than the bucket
 tool, if we do move the shapebursts.

 Alexandre: I'm hoping to also hook up the live preview to update along
 with any modifications of the gradient that happen in the gradient
 editor. It isn't quite the same as on-canvas editing of color stops,
 but if you're doing that sort of work, it should become it a lot
 nicer.

 peter:
 On Tue, Jun 24, 2014 at 7:49 AM, peter sikking pe...@mmiworks.net wrote:
 Michael Henning wrote:
 * I'd like to make the blend tool generally more interactive. By
 this, I mean that after the user has created a gradient, they will be
 presented with handles that they can use to modify the endpoints of
 the gradient before committing their changes.

 good plan. combine it with updating the colours of the
 endpoints to make it truly adjustable to get it _right_

 hint: please do not make the endpoint handles small;
 think generous (more tens of pixels than single digits) and
 also show where the exact endpoint is in the centre of the handle
 (say, with a cross to aim).

 I had been imagining selection handles that are simply filled circles.
 In my early prototype, they look like this:
 http://i.imgur.com/t4g1zOE.png

 I think they are big enough, but they don't really show the exact
 location of the endpoint. I guess I'll need to experiment with this
 more.

 I have a feeling that If I make them circle outlines with crosshairs
 in them, they'll look cluttered. Having just crosshairs won't make it
 obvious that you can drag the points. Maybe drawing circles most of
 the time, and then hiding the circles and switching to crosshairs
 while dragging the points, would be good? (The idea is to show the
 precise handles when they're needed during dragging, and then switch
 to handles that invite grabbing for the remainder of the time.)

 * I'd also like to add a live preview to the blend tool so users can
 preview the gradient and experiment with different options, before
 committing their changes.

 yes, vital for making the previous point work.

 please make commit an implicit thing (moving on to another
 tool, starting another gradient) combined with explicit
 (e.g. return) as a backup. see handling of committing
 selections in the rectangular selection tool.

 Agreed. I wasn't planning to make starting another gradient commit the
 first, but now that I think about it, that does make more sense.

 * I'm also planning to add undo support within the tool.

 I hope you mean: step-by-step undo while not committed,
 after a commit undo the whole committed gradient.

 Yes, that's exactly the plan.

 again: vital, to make other points above _really_ work.
 both for the interactive part and as a form of non-committing

 * The general consensus within the dev team seems to be that the
 shapebursts (all of the gradient types currently marked shaped)
 should be moved out of the blend tool. They would likely be moved into
 either a menu item, or (maybe?) within the fill tool.

 as far as my thoughts go: there will be more working
 with (vector) shapes in the future, and modifying those
 shapes with a gradient fill (by the gradient tool)
 could be the way to handle that.

 Hmm, you might have misunderstood what I meant by shapebursts. The
 shapebursts are special gradients that mimic the shape of your
 selection (currently labeled Shaped (angular), Shaped (spherical),
 and Shaped (dimpled)). Anyway, at this point I'm really conflicted
 as to what should be done with them. I'm not sure whether they belong
 in the blend tool or not right now.

 Anyway, thanks for the input.

   -- drawoc
 ___
 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: 

Re: [Gimp-developer] How to call gimp_export_image() from Pythonplugin

[Joao S. O. Bueno]

On 21 June 2014 18:02, Ed . ej...@hotmail.com wrote:
 GIO is a file access library and part of GLib. -
 http://wiki.gimp.org/index.php/Hacking:Porting_file_plugins_to_GEGL_and_GIO#Porting_to_GIO

 GIR is (GObject Introspection Repository) -
 http://blogs.gnome.org/johan/2008/06/01/introduction-to-gobject-introspection/

 GIR is something that GIMP will fully support when someone gets around to it
 - currently I've volunteered to be that guy.

So - that is GIR, not GIO.

How far had you got?



 Ed


 -Original Message- From: Joao S. O. Bueno
 Sent: Friday, June 20, 2014 11:59 PM
 To: Vladimir Rutsky
 Cc: Ed . ; gimp-developer

 Subject: Re: [Gimp-developer] How to call gimp_export_image() from
 Pythonplugin

 What is GIO?


 It stands for Gobject Introspection Oforgot

 It is a framework to,in a more or less automated form,  expose C functions
 and
 gobject based classes to various languages - including Python.

 The Python bindings for gtk+3.0 , ofr example, are GIO based -
 in this way, one does not have to re-especify every function or class
 one wants to expose to other languages in  a manually written C
 (or other configuration) file.


 Pygimp today has C modules which have to create Python objects that mimic
 GIMP objects, and all manipulations of these objects are wrapped by
 methods exposed
 to Python which in turn call one of the libgimp functions.

 With GIO, all libgimp functions could be called directly, and what we
 would need is an order of magnitude simpler implementation of the
 objects, directly in Python.

 I am working on such a layer for GEGL, for example -
 http://github.com/jsbueno/python-gegl

   js

___
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] Blend Tool UI

[Joao S. O. Bueno]

On 23 June 2014 00:31, Michael Henning dra...@darkrefraction.com wrote:
 I'd like to make some incremental improvements to the blend tool. On
 IRC, Alexandre suggested to get the UI team involved, so I'm looking
 for feedback/advice from the UI team.

 Here are my general plans:

  * I'd like to make the blend tool generally more interactive. By
 this, I mean that after the user has created a gradient, they will be
 presented with handles that they can use to modify the endpoints of
 the gradient before committing their changes.

I don't quite nderstand what you mean by commiting changes - as of
now, gradients as all GIMP assts are all updated in realtime - You
move a handle, that is the valid value for that gradient right now,
for all purposes: that is, you make a move, you commit it.

Having undo and redo steps on possible on the gradient window would be great,


  * I'd also like to add a live preview to the blend tool so users can
 preview the gradient and experiment with different options, before
 committing their changes.

You mean a radial and square previews, beyond the existing linear preview?


  * I'm also planning to add undo support within the tool.

Yes - that would be great! I guess you mean within the gradient editor dialog,
not for the blending tool itself.


  * The general consensus within the dev team seems to be that the
 shapebursts (all of the gradient types currently marked shaped)
 should be moved out of the blend tool. They would likely be moved into
 either a menu item, or (maybe?) within the fill tool.

Not sure. One thing they lack is more control: the offset shuldbe vaid
for them -
otherwise, when using these in a workflow, I think of different
shaopes for the blending tool, not
anything else.
The fact that they currently take no advantage on the point one click,
to the point one drag is more
motive to improve on that, within the blending tool, than to turn then
into dumb menu entries, I think.

However,a shape fill tool, which could not only fill an area with a
gradient, but also with a pattern
(a selection copied from somewhere else) would be great. Then,
gradient shapes could be aggregated there, and GIMP would finally
match the feature which was present in 1986's Deluxe Paint .

But again: I don't think moving it out of the blending shape options,
just for ding so, is a nice idea.


 js
--




 Any thoughts?

-- drawoc
 ___
 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

[Gimp-developer] (no subject)

[Joao S. O. Bueno]

I've worked on implementing this on top of GIMP master -

The near 300 line gimp_export_image  is big because it has to handle all
possible exporting-plug-in capabilities. The most shortening cut there is that
if you do the tests yourself, you already know your file format
capabilites, while
the function has to take care of all possible capabilities against all possible
image states.

Moreover, the C function is unaware of Layer Groups - which are relevant
as an export capability, and I think the feature to detect/export based on
the ...CAN_HANDLE_MASKS  capability is currently broken anyway.
That is for GIMP 2.8. If this function call remains undeprecated in GIMP 2.10,
it will also have to take care of image precision, which it currently ignores.

Anyway, now one can use
gimp.export_image (...) and gimp.export_dialog from Python in GIMP master.

I will leave to others to judge whether this should be backported to
2.8. As I see it,
it is less useful than recreating what would be its job in the
Python-plugin side, since
it is broken anyway (regarding layer groups and masks).

  js
 --

On 19 June 2014 21:42, Joao S. O. Bueno gwid...@gmail.com wrote:
 On 19 June 2014 20:38, Ed . ej...@hotmail.com wrote:
 My understanding is that libgimp is for C plugins. Many libgimp functions
 are in fact calls to PDB functions - see libgimp/gimppainttools_pdb.c for
 example. The distinction between high and low level is not the one used
 to determine what is in the PDB and what is not - despite what you say,
 there are gimp-drawable-set-pixel and gimp-drawable-get-pixel procs in the
 PDB.

 It seems you are knowledgeable in writing interface code for Python. Why not
 add gimp_export_image to the available python functions?

 Because it is not there.

 One problem with the current implementation of Pygimp is exactly that it uses
 C to wrap around calls do libgimp.
 The problem with this approach is that one loses all the dynamic aspects from
 Python for these objects:
 The GIMP Python objects,as exposed in pygimp are native objects - as such
 they can not be modified by pure Python code.

 For writing Python plug-ins one does either use the objects ofered in Pygimp,
 with the functions enabled there in C code that requires a ton of
 boiler-plate for eachmethod made available,
 or use the Python PDB module, which allows one to call GIMP via the PDB.


 So, if it is not clear yet, the gimp_file_export function just is
 _not_ there.
 It can be made available by a C patch in pygimp - but that is adding
 functionality to a stable series.
 Or it could be made available through the PDB - which would also make
 it work from script-fu,
 and whatever other bindings happen to work. That is also adding new
 functionality.

 The correct thing to do is to add it both ways - as an export method
 for image objects,
 and as a PDB call - in the 2.9 branch.

 Now, talking about new features, you where the one experiencing with
 GIMP and GIO - that, on the contrary of this simple call, is something
 that matters: I'd very much like to rewrite GIMP Python using
 GIO - (so this kind of stuff would be a non issue in the future:
 everything available in C is ready without
 needing explicit wrappers with boiler plate code) - how far did you
 get with the GIO stuff?




 -Original Message- From: Vladimir Rutsky
 Sent: Thursday, June 19, 2014 11:52 PM
 To: Ed .
 Cc: gimp-developer

 Subject: Re: [Gimp-developer] How to call gimp_export_image() from
 Pythonplugin

 On 19.06.2014 22:09, Ed . wrote:

 It is not a PDB function, but a libgimp (C) function. Since pygimp can do
 gimpui stuff (also C functions), there is no conceptual reason why pygimp
 shouldn't also handle gimpexport (which is where gimp_export_image lives).


 Which functions in GIMP goes to PDB, and which stays only in libgimp?

 As I understand, libgimp should contain _all_ functionality, that may be
 needed for external C plugins. So it's low-level library.

 PDB functions are designed to be called from scripts for automation and
 easer writing custom plugins in Scheme/Python/Perl scripts.
 So there mostly should be high-level functions, since there is no
 point in calling low-level operations, like set_pixel(), due to
 performance overhead of PDB.

 gimp_export_image() is high-level function: it does several operations
 on image as whole and optionally asks user for some input.
 If gimp_export_image() would be available though PDB, it could be called
 from any fu-script, that can call PDB functions, and there would be no
 need to export it specifically in Python, Perl, Ruby, C#...

 Correct me if I'm wrong, since I'm new to PDB and GIMP development.


 I thought that in Python it was straightforward to access C functions?
 This is simply a function that returns an integer, albeit one that uses the
 GIMP UI - which pygimp already can initialise.


 Best way to use C functions from Python is to write wrapper module in C
 that will export methods as Python functions/classes

Re: [Gimp-developer] How to call gimp_export_image() from Pythonplugin

[Joao S. O. Bueno]

 What is GIO?

It stands for Gobject Introspection Oforgot

It is a framework to,in a more or less automated form,  expose C functions and
gobject based classes to various languages - including Python.

The Python bindings for gtk+3.0 , ofr example, are GIO based -
in this way, one does not have to re-especify every function or class
one wants to expose to other languages in  a manually written C
(or other configuration) file.


Pygimp today has C modules which have to create Python objects that mimic
GIMP objects, and all manipulations of these objects are wrapped by
methods exposed
to Python which in turn call one of the libgimp functions.

With GIO, all libgimp functions could be called directly, and what we
would need is an order of magnitude simpler implementation of the
objects, directly in Python.

I am working on such a layer for GEGL, for example -
http://github.com/jsbueno/python-gegl

   js
 --

On 20 June 2014 19:13, Vladimir Rutsky rutsky.vladi...@gmail.com wrote:
 On 20.06.2014 04:42, Joao S. O. Bueno wrote:

 On 19 June 2014 20:38, Ed . ej...@hotmail.com wrote:

 My understanding is that libgimp is for C plugins. Many libgimp functions
 are in fact calls to PDB functions - see libgimp/gimppainttools_pdb.c for
 example. The distinction between high and low level is not the one
 used
 to determine what is in the PDB and what is not - despite what you say,
 there are gimp-drawable-set-pixel and gimp-drawable-get-pixel procs in
 the
 PDB.

 It seems you are knowledgeable in writing interface code for Python. Why
 not
 add gimp_export_image to the available python functions?

 Because it is not there.

 One problem with the current implementation of Pygimp is exactly that it
 uses
 C to wrap around calls do libgimp.
 The problem with this approach is that one loses all the dynamic aspects
 from
 Python for these objects:
 The GIMP Python objects,as exposed in pygimp are native objects - as
 such
 they can not be modified by pure Python code.

 For writing Python plug-ins one does either use the objects ofered in
 Pygimp,
 with the functions enabled there in C code that requires a ton of
 boiler-plate for eachmethod made available,
 or use the Python PDB module, which allows one to call GIMP via the PDB.


 So, if it is not clear yet, the gimp_file_export function just is
 _not_ there.
 It can be made available by a C patch in pygimp - but that is adding
 functionality to a stable series.
 Or it could be made available through the PDB - which would also make
 it work from script-fu,
 and whatever other bindings happen to work. That is also adding new
 functionality.

 The correct thing to do is to add it both ways - as an export method
 for image objects,
 and as a PDB call - in the 2.9 branch.

 Now, talking about new features, you where the one experiencing with
 GIMP and GIO - that, on the contrary of this simple call, is something
 that matters: I'd very much like to rewrite GIMP Python using
 GIO - (so this kind of stuff would be a non issue in the future:
 everything available in C is ready without
 needing explicit wrappers with boiler plate code) - how far did you
 get with the GIO stuff?


 What is GIO?
 I heard about https://developer.gnome.org/gio/, but from it's description I
 don't get how it can be related to GIMP and it's plugins?


 --
 Vladimir Rutsky






 -Original Message- From: Vladimir Rutsky
 Sent: Thursday, June 19, 2014 11:52 PM
 To: Ed .
 Cc: gimp-developer

 Subject: Re: [Gimp-developer] How to call gimp_export_image() from
 Pythonplugin

 On 19.06.2014 22:09, Ed . wrote:

 It is not a PDB function, but a libgimp (C) function. Since pygimp can
 do
 gimpui stuff (also C functions), there is no conceptual reason why
 pygimp
 shouldn't also handle gimpexport (which is where gimp_export_image
 lives).


 Which functions in GIMP goes to PDB, and which stays only in libgimp?

 As I understand, libgimp should contain _all_ functionality, that may be
 needed for external C plugins. So it's low-level library.

 PDB functions are designed to be called from scripts for automation and
 easer writing custom plugins in Scheme/Python/Perl scripts.
 So there mostly should be high-level functions, since there is no
 point in calling low-level operations, like set_pixel(), due to
 performance overhead of PDB.

 gimp_export_image() is high-level function: it does several operations
 on image as whole and optionally asks user for some input.
 If gimp_export_image() would be available though PDB, it could be called
 from any fu-script, that can call PDB functions, and there would be no
 need to export it specifically in Python, Perl, Ruby, C#...

 Correct me if I'm wrong, since I'm new to PDB and GIMP development.

 I thought that in Python it was straightforward to access C functions?
 This is simply a function that returns an integer, albeit one that uses
 the
 GIMP UI - which pygimp already can initialise.


 Best way to use C functions from Python is to write wrapper module

Re: [Gimp-developer] How to call gimp_export_image() from Pythonplugin

[Joao S. O. Bueno]

This is a missing feature in the 2.8 release. New features are usually not added
in stable release cycle, which is the case of gimp 2.8  - and gimp-python is
bound to it.

If it was something without which one would die - but  the
functionality can be obtained by 5 lines
of code, as already answered in the first e-mail.

I will deal shortly  with the other bug reported here - regarding the
parent atribute of layers, which
is being retrieved as Layer, not LayerGroup.
I might add the export method to GIMP Image objects - but that is a
new feature , I am  not sure if it should be backported to 2.8 .




On 19 June 2014 15:09, Ed . ej...@hotmail.com wrote:
 It is not a PDB function, but a libgimp (C) function. Since pygimp can do
 gimpui stuff (also C functions), there is no conceptual reason why pygimp
 shouldn't also handle gimpexport (which is where gimp_export_image lives).

 I thought that in Python it was straightforward to access C functions? This
 is simply a function that returns an integer, albeit one that uses the GIMP
 UI - which pygimp already can initialise.


 -Original Message- From: Vladimir Rutsky
 Sent: Thursday, June 19, 2014 6:24 PM
 To: João Sebastião de Oliveira Bueno
 Cc: Ed . ; gimp-developer

 Subject: Re: [Gimp-developer] How to call gimp_export_image() from
 Pythonplugin

 On Wed, Jun 18, 2014 at 9:52 PM, Joao S. O. Bueno gwid...@gmail.com wrote:

 IS it available throught the PDB?
 Most GIMP - Python functions are done via PDB, except pixel-region
 manipulation stuff.
 If it is not in the PDB, it is not availabl in GIMP 2.8 - the current
 GIMP Python structure has to
 special cases a lot of things to work aside from the PDB, and doing so
 is not minor stuff
 done inside a release cycle.

 Making the 3-4 above calls are straightforward - I see no reason to
 violate the principle of no new features inside a release to add this.
 In GIMP 2.10, the export feature will also have to deal with precision
 management, and besides this export function, a class of PDB calls
 dealing with precision needs
 to be added as well.


 Joao, Ed,

 so gimp_export_image() should be exported to Python though PDB (to all
 plugins) or by writing custom export code as done for some functions
 to export it only to Python?

 --
 Vladimir Rutsky

 ___
 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

Re: [Gimp-developer] pin references

[Joao S. O. Bueno]

On 9 June 2014 15:06, Johann jo.y.v...@gmail.com wrote:
 Hi,
 please add the ability to:
 -pin reference pictures outside the image boundaries

 Outside because for now i have to insert reference images inside my canvas, 
 covering parts of my work. Ive to move the refs around while im painting and 
 this annoys me a bit. I think having two screens isnt a standard for everyone.
 Not all my refs are digital, but a lot of these, yes.

GIMP can do that since pré 1.0 -
It can't to that in the new single window mode  - but allyou have to
tdo is to use the regular
multple Window interface, and open your reference picture as another
image - then use the
facilities of your Window manager to deal with it as you prefer.



 have a nice day!
 jo
 ___
 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

Re: [Gimp-developer] How to call gimp_export_image() from Pythonplugin

[Joao S. O. Bueno]

On 19 June 2014 20:38, Ed . ej...@hotmail.com wrote:
 My understanding is that libgimp is for C plugins. Many libgimp functions
 are in fact calls to PDB functions - see libgimp/gimppainttools_pdb.c for
 example. The distinction between high and low level is not the one used
 to determine what is in the PDB and what is not - despite what you say,
 there are gimp-drawable-set-pixel and gimp-drawable-get-pixel procs in the
 PDB.

 It seems you are knowledgeable in writing interface code for Python. Why not
 add gimp_export_image to the available python functions?

Because it is not there.

One problem with the current implementation of Pygimp is exactly that it uses
C to wrap around calls do libgimp.
The problem with this approach is that one loses all the dynamic aspects from
Python for these objects:
The GIMP Python objects,as exposed in pygimp are native objects - as such
they can not be modified by pure Python code.

For writing Python plug-ins one does either use the objects ofered in Pygimp,
with the functions enabled there in C code that requires a ton of
boiler-plate for eachmethod made available,
or use the Python PDB module, which allows one to call GIMP via the PDB.


So, if it is not clear yet, the gimp_file_export function just is
_not_ there.
It can be made available by a C patch in pygimp - but that is adding
functionality to a stable series.
Or it could be made available through the PDB - which would also make
it work from script-fu,
and whatever other bindings happen to work. That is also adding new
functionality.

The correct thing to do is to add it both ways - as an export method
for image objects,
and as a PDB call - in the 2.9 branch.

Now, talking about new features, you where the one experiencing with
GIMP and GIO - that, on the contrary of this simple call, is something
that matters: I'd very much like to rewrite GIMP Python using
GIO - (so this kind of stuff would be a non issue in the future:
everything available in C is ready without
needing explicit wrappers with boiler plate code) - how far did you
get with the GIO stuff?




 -Original Message- From: Vladimir Rutsky
 Sent: Thursday, June 19, 2014 11:52 PM
 To: Ed .
 Cc: gimp-developer

 Subject: Re: [Gimp-developer] How to call gimp_export_image() from
 Pythonplugin

 On 19.06.2014 22:09, Ed . wrote:

 It is not a PDB function, but a libgimp (C) function. Since pygimp can do
 gimpui stuff (also C functions), there is no conceptual reason why pygimp
 shouldn't also handle gimpexport (which is where gimp_export_image lives).


 Which functions in GIMP goes to PDB, and which stays only in libgimp?

 As I understand, libgimp should contain _all_ functionality, that may be
 needed for external C plugins. So it's low-level library.

 PDB functions are designed to be called from scripts for automation and
 easer writing custom plugins in Scheme/Python/Perl scripts.
 So there mostly should be high-level functions, since there is no
 point in calling low-level operations, like set_pixel(), due to
 performance overhead of PDB.

 gimp_export_image() is high-level function: it does several operations
 on image as whole and optionally asks user for some input.
 If gimp_export_image() would be available though PDB, it could be called
 from any fu-script, that can call PDB functions, and there would be no
 need to export it specifically in Python, Perl, Ruby, C#...

 Correct me if I'm wrong, since I'm new to PDB and GIMP development.


 I thought that in Python it was straightforward to access C functions?
 This is simply a function that returns an integer, albeit one that uses the
 GIMP UI - which pygimp already can initialise.


 Best way to use C functions from Python is to write wrapper module in C
 that will export methods as Python functions/classes (just as
 GIMP-Python does).
 Also you can load shared object and call C-function directly using
 libffi library (presented as ctypes module in Python), but this
 error-prone and really hackish way.

 ___
 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

Re: [Gimp-developer] Python-fu GIMP Layer parent property error

[Joao S. O. Bueno]

Issue fixed in master and 2.8 branch.  (It will be generally
available as of gimp 2.8.12)

Thanks for spotting that.

  js
 --

On 19 June 2014 00:31, Joao S. O. Bueno gwid...@gmail.com wrote:
 yes - this is a bug - and it can be open in the bugtracker.

 On 18 June 2014 22:41, Seldom Needy needthist...@gmail.com wrote:
 As stated at http://www.gimp.org/bugs/ I'm supposed to mention issues
 here before throwing them into the tracker so here goes.

 Working on a plugin that does some layer manipulation and kept
 encountering the error:
 AttributeError: 'gimp.Layer' object has no attribute 'layers'
 when trying to access the layer structure in a tree-like fashion to
 find sibling layers in the same grouplayer/layergroup. After being
 puzzled, I found the issue, which seems to essentially be that the
 parent attribute of a layer automatically upcasts to gimp.Layer,
 rather than yielding a gimp.GroupLayer, as I think should be expected.

 The behavior can be reproduced as follows from Python console in GIMP 2.8.8:
 image = gimp.image_list()[0]
 image.layers[0].layers[0].parent.layers # again with the result:
 AttributeError: 'gimp.Layer' object has no attribute 'layers'

 Assuming an image's layer-structure is similar to:
 [root image]
 +GROUPLAYER ZERO
 ++LAYER ZERO OF ZERO
 +GROUPLAYER ONE
 ++LAYER ZERO OF ONE
 ++LAYER ONE OF ONE
 +LAYER BACKGROUND

 From the console we have a hint as to why this is.
 image.layers[0]
 gimp.GroupLayer GROUPLAYER ZERO
 image.layers[0].layers[0].parent # should return the same layer as above 
 but gives
 gimp.Layer GROUPLAYER ZERO

 I haven't seen this on the bugtracker nor was I able to find
 discussion about it on the listserv archive. I assume it is a
 platform-independent bug. Can anyone confirm that? I develop on
 Windows XP at present.

 Workarounds for this bug exist I'm not in love with them (inelegant).
 Regardless, a sketch of what might work without using globals:

 def get_all_layers(parent):
 - list. recursively get all layers from either an image, or a 
 GroupLayer
 Proceeds depth-first.
 
 container=[]
 for layer in parent.layers:
 container.append(layer)
 if hasattr(layer,layers):
 container.extend( get_all_layers(layer) )
 return container

 def get_parent(child):
 if hasattr(child,parent):
 for layer in get_all_layers(child.image):
 if layer.name==child.parent.name: return layer
 #^ layer will have the proper data-type of
 gimp.GroupLayer, so return it.
 #^.. We do this because child.parent yields a gimp.Layer,
 which is undesired.
 else:
 return child.image # if we're already top-level, parent must
 just be the image.

 Cheers
 - Seldom
 ___
 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

Re: [Gimp-developer] How to call gimp_export_image() from Python plugin

[Joao S. O. Bueno]

On 18 June 2014 07:43, Vladimir Rutsky rutsky.vladi...@gmail.com wrote:
 On Wed, Jun 18, 2014 at 7:32 AM, Joao S. O. Bueno gwid...@gmail.com wrote:
 From Python, in GIMP 2.8, you have to make calls to whatever is
 available via the PDB, but
 for some calls that have been shortened as methods of Image, Layer and
 other objects (but internally,
 most things happen through the PDB anyway).


 So, you have to call either pdb.gimp_file_save  and specify the file
 format via the file-name extension,
 or call pdb.file_bmp_save. For both cases you have to passin a
 drawable to be saved, meaning that if you
 want to save an existingimage, you hvae to preceed these calls with
 the equivalent of these two lines:

 saving_image = pdb.gimp_image_duplicate(img)
 saving_drawable = pdb.gimp_image_merge_visible_layers(saving_image)

 then you have a drawable to save, with all the visible image contents,
 but without messing
 with the image the user sees. After saving, call
 pdb.gimp_image_delete(saving_image) - to recover
 the resources used by the temporary image,

   js
  --

 Thank for your reply, but this doesn't solves my problem.

 merge_visible_layers() doesn't behave as gimp_export_image(): it only
 merges image layers to single layer.
 I need not only to merge them, but also to convert to proper image
 format suitable for me (e.g. convert to RGB from GRAY or RGBA) and
 probably some other convertions.

so, just do the needed conversions through further PDB calls.
as you can see, gimp_export_image is not available to plug-ins as of
gimp 2.8 series.
(yes, it should be, and yes you can open a  bug report requesting that
so that we don't  forget about it,
but this is an API change, so it will just be there for GIMP 2.10 anyway).


   js
 --


 And gimp_export_image() designed specifically for my task.

 According to it's sources
 (https://git.gnome.org/browse/gimp/tree/libgimp/gimpexport.c) there
 are quite a lot of steps and not so trivial logic that should be done
 to obtain result image, and I don't want to reimplement this
 functionality, I want to call gimp_export_image().





 On 17 June 2014 19:43, Vladimir Rutsky rutsky.vladi...@gmail.com wrote:
 Hello!

 I'm trying to write export plugin for custom image format in Python.

 Looking at plugins implemented in C, e.g. gimp/plug-ins/file-bmp/bmp.c, and
 docs (http://developer.gimp.org/api/2.0/libgimp/libgimp-gimpexport.html)
 I see, that best and recommended way to convert user image to single layer
 image with proper capabilities is by using gimp_export_image() function.

 How gimp_export_image() can be called from Python?

 I can't find it exported Python modules and looks like it's not accessible
 via PDB either.

 If it's not available, can you advice proper alternative? Should I report
 missing gimp_export_image() function in bug tracker?


 Thanks in advance,

 Vladimir Rutsky

 ___
 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


 --
 Vladimir Rutsky
___
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 call gimp_export_image() from Pythonplugin

[Joao S. O. Bueno]

IS it available throught the PDB?
Most GIMP - Python functions are done via PDB, except pixel-region
manipulation stuff.
If it is not in the PDB, it is not availabl in GIMP 2.8 - the current
GIMP Python structure has to
special cases a lot of things to work aside from the PDB, and doing so
is not minor stuff
done inside a release cycle.

Making the 3-4 above calls are straightforward - I see no reason to
violate the principle of no new features inside a release to add this.
In GIMP 2.10, the export feature will also have to deal with precision
management, and besides this export function, a class of PDB calls
dealing with precision needs
to be added as well.

On 18 June 2014 14:21, Ed . ej...@hotmail.com wrote:
 Just to clarify, JS - you say gimp_export_image is not available to
 plug-ins as of gimp 2.8 series - I take it you mean to Python plug-ins?
 Because it works fine in Gimp-Perl plug-ins.

 I'd claim that the lack of gimp_export_image in pygimp is a bug, not a
 feature to be added, so it should be possible to add in 2.8. Vladimir, it
 ought to be as simple as adding to pygimp gimpexport, in the same way as
 there is gimpui. See
 http://developer.gimp.org/api/2.0/libgimp/libgimp-gimpexport.html

 Ed J
 Gimp-Perl guy

 -Original Message- From: Vladimir Rutsky
 Sent: Wednesday, June 18, 2014 1:27 PM
 To: gwid...@gmail.com
 Cc: gimp-developer
 Subject: Re: [Gimp-developer] How to call gimp_export_image() from
 Pythonplugin


 On Wed, Jun 18, 2014 at 3:19 PM, Joao S. O. Bueno gwid...@gmail.com wrote:

 On 18 June 2014 07:43, Vladimir Rutsky rutsky.vladi...@gmail.com wrote:

 On Wed, Jun 18, 2014 at 7:32 AM, Joao S. O. Bueno gwid...@gmail.com
 wrote:

 From Python, in GIMP 2.8, you have to make calls to whatever is
 available via the PDB, but
 for some calls that have been shortened as methods of Image, Layer and
 other objects (but internally,
 most things happen through the PDB anyway).


 So, you have to call either pdb.gimp_file_save  and specify the file
 format via the file-name extension,
 or call pdb.file_bmp_save. For both cases you have to passin a
 drawable to be saved, meaning that if you
 want to save an existingimage, you hvae to preceed these calls with
 the equivalent of these two lines:

 saving_image = pdb.gimp_image_duplicate(img)
 saving_drawable = pdb.gimp_image_merge_visible_layers(saving_image)

 then you have a drawable to save, with all the visible image contents,
 but without messing
 with the image the user sees. After saving, call
 pdb.gimp_image_delete(saving_image) - to recover
 the resources used by the temporary image,

   js
  --


 Thank for your reply, but this doesn't solves my problem.

 merge_visible_layers() doesn't behave as gimp_export_image(): it only
 merges image layers to single layer.
 I need not only to merge them, but also to convert to proper image
 format suitable for me (e.g. convert to RGB from GRAY or RGBA) and
 probably some other convertions.


 so, just do the needed conversions through further PDB calls.
 as you can see, gimp_export_image is not available to plug-ins as of
 gimp 2.8 series.
 (yes, it should be, and yes you can open a  bug report requesting that
 so that we don't  forget about it,
 but this is an API change, so it will just be there for GIMP 2.10 anyway).


 Ok, thank you for clarification. I filed bug:
 https://bugzilla.gnome.org/show_bug.cgi?id=731843

 Why it can be released sooner? I'm not familiar with GIMP development
 process, but I think exporting additional function doesn't break
 backward compatibility of API.
 If I'll submit patches for this issue, when I can expect to see it in
 some official release of GIMP (in case patches will be accepted)?


 --
 Vladimir Rutsky





js
  --


 And gimp_export_image() designed specifically for my task.

 According to it's sources
 (https://git.gnome.org/browse/gimp/tree/libgimp/gimpexport.c) there
 are quite a lot of steps and not so trivial logic that should be done
 to obtain result image, and I don't want to reimplement this
 functionality, I want to call gimp_export_image().





 On 17 June 2014 19:43, Vladimir Rutsky rutsky.vladi...@gmail.com
 wrote:

 Hello!

 I'm trying to write export plugin for custom image format in Python.

 Looking at plugins implemented in C, e.g. gimp/plug-ins/file-bmp/bmp.c,
 and
 docs
 (http://developer.gimp.org/api/2.0/libgimp/libgimp-gimpexport.html)
 I see, that best and recommended way to convert user image to single
 layer
 image with proper capabilities is by using gimp_export_image()
 function.

 How gimp_export_image() can be called from Python?

 I can't find it exported Python modules and looks like it's not
 accessible
 via PDB either.

 If it's not available, can you advice proper alternative? Should I
 report
 missing gimp_export_image() function in bug tracker?


 Thanks in advance,

 Vladimir Rutsky

 ___
 gimp-developer-list mailing list
 List address:gimp-developer-list

Re: [Gimp-developer] Python-fu GIMP Layer parent property error

[Joao S. O. Bueno]

yes - this is a bug - and it can be open in the bugtracker.

On 18 June 2014 22:41, Seldom Needy needthist...@gmail.com wrote:
 As stated at http://www.gimp.org/bugs/ I'm supposed to mention issues
 here before throwing them into the tracker so here goes.

 Working on a plugin that does some layer manipulation and kept
 encountering the error:
 AttributeError: 'gimp.Layer' object has no attribute 'layers'
 when trying to access the layer structure in a tree-like fashion to
 find sibling layers in the same grouplayer/layergroup. After being
 puzzled, I found the issue, which seems to essentially be that the
 parent attribute of a layer automatically upcasts to gimp.Layer,
 rather than yielding a gimp.GroupLayer, as I think should be expected.

 The behavior can be reproduced as follows from Python console in GIMP 2.8.8:
 image = gimp.image_list()[0]
 image.layers[0].layers[0].parent.layers # again with the result:
 AttributeError: 'gimp.Layer' object has no attribute 'layers'

 Assuming an image's layer-structure is similar to:
 [root image]
 +GROUPLAYER ZERO
 ++LAYER ZERO OF ZERO
 +GROUPLAYER ONE
 ++LAYER ZERO OF ONE
 ++LAYER ONE OF ONE
 +LAYER BACKGROUND

 From the console we have a hint as to why this is.
 image.layers[0]
 gimp.GroupLayer GROUPLAYER ZERO
 image.layers[0].layers[0].parent # should return the same layer as above 
 but gives
 gimp.Layer GROUPLAYER ZERO

 I haven't seen this on the bugtracker nor was I able to find
 discussion about it on the listserv archive. I assume it is a
 platform-independent bug. Can anyone confirm that? I develop on
 Windows XP at present.

 Workarounds for this bug exist I'm not in love with them (inelegant).
 Regardless, a sketch of what might work without using globals:

 def get_all_layers(parent):
 - list. recursively get all layers from either an image, or a 
 GroupLayer
 Proceeds depth-first.
 
 container=[]
 for layer in parent.layers:
 container.append(layer)
 if hasattr(layer,layers):
 container.extend( get_all_layers(layer) )
 return container

 def get_parent(child):
 if hasattr(child,parent):
 for layer in get_all_layers(child.image):
 if layer.name==child.parent.name: return layer
 #^ layer will have the proper data-type of
 gimp.GroupLayer, so return it.
 #^.. We do this because child.parent yields a gimp.Layer,
 which is undesired.
 else:
 return child.image # if we're already top-level, parent must
 just be the image.

 Cheers
 - Seldom
 ___
 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

Re: [Gimp-developer] How to call gimp_export_image() from Python plugin

[Joao S. O. Bueno]

From Python, in GIMP 2.8, you have to make calls to whatever is
available via the PDB, but
for some calls that have been shortened as methods of Image, Layer and
other objects (but internally,
most things happen through the PDB anyway).


So, you have to call either pdb.gimp_file_save  and specify the file
format via the file-name extension,
or call pdb.file_bmp_save. For both cases you have to passin a
drawable to be saved, meaning that if you
want to save an existingimage, you hvae to preceed these calls with
the equivalent of these two lines:

saving_image = pdb.gimp_image_duplicate(img)
saving_drawable = pdb.gimp_image_merge_visible_layers(saving_image)

then you have a drawable to save, with all the visible image contents,
but without messing
with the image the user sees. After saving, call
pdb.gimp_image_delete(saving_image) - to recover
the resources used by the temporary image,

  js
 --




On 17 June 2014 19:43, Vladimir Rutsky rutsky.vladi...@gmail.com wrote:
 Hello!

 I'm trying to write export plugin for custom image format in Python.

 Looking at plugins implemented in C, e.g. gimp/plug-ins/file-bmp/bmp.c, and
 docs (http://developer.gimp.org/api/2.0/libgimp/libgimp-gimpexport.html)
 I see, that best and recommended way to convert user image to single layer
 image with proper capabilities is by using gimp_export_image() function.

 How gimp_export_image() can be called from Python?

 I can't find it exported Python modules and looks like it's not accessible
 via PDB either.

 If it's not available, can you advice proper alternative? Should I report
 missing gimp_export_image() function in bug tracker?


 Thanks in advance,

 Vladimir Rutsky

 ___
 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

Re: [Gimp-developer] Emails for contributors?

[Joao S. O. Bueno]

On 1 May 2014 23:09, Jehan Pagès jehan.marmott...@gmail.com wrote:
 Hi,

 Haven't we discussed gimp.org emails for contributors during LGM?
 I remember that the last day, someone asked about this and the
 conclusions was that it was a good idea.
 I wouldn't mind one either. :-)


The same for me.

  js
 --



 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
___
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] [FEATURE] - Blend mode Truncate

[Joao S. O. Bueno]

Ok, I think if we keep posting new small wanted (and being hacked on)
features here, maybe we can get the thing going.

So, I propose adding a fourth repeat mode for the Blending tool:

The default behavior when blending with repeat None is to stretch the last
color on the gradient (and for linear blending, also the first one) to
infinity, past the point the user dragged the blending endpoint to.

Sometimes, it might be desirable just to stop filing in new colors
at the point the user stopped dragging the blending tool.

Currently, if one wants to perform just that, for example,
drawing a gradient circle without overwritting all the layer
with the last gradient color, there are two options:
1) create a selection previous to using the blending tool
delimitng the wanted area
2) modifying the gradient to be used so that its last segment
is a fully transparent color. And this has to be done to all gradients one
intends to use.

Besides having to create a selection, method 1 still requires the user
to visually match the starting point of the blending with the center of
the desired select circle or square. And if one wants to delimit a
linear or bi-linear
blending, pre-selecting the affected area is not only hard, but non obvious,
requiring the use of quickmask and the blend tool (witha  solid color gradient)
itself.


Note that some of the intended uses for Square of Circular shapped gradients
may not even be possible to achieve due to the constrainst above.

By introducing a truncate blending mode to gradients, drawing a gradient
square or circle in GIMP is straightforward (it will also fulfill the demand of
some users for easy ways to draw basic shapes while we don't
have a proper shape tool).

Maybe this should have even been the proper behavior for Repeat None -
but since it can't be changed now, introducing this as a new repeating mode
can bring new ways to use the blending tool and GIMP itself.

-
Comments on this idea anyone?

  js
 --
___
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] - Blend mode Truncate

[Joao S. O. Bueno]

On 23 April 2014 21:35, Gez lis...@ohweb.com.ar wrote:
 El 2014-04-23 18:10, Joao S. O. Bueno escribió:


 Maybe this should have even been the proper behavior for Repeat None -
 but since it can't be changed now, introducing this as a new repeating
 mode
 can bring new ways to use the blending tool and GIMP itself.

 -
 Comments on this idea anyone?


 I like the idea, but I don't think that making it the default behavior for
 Repeat None is a good idea. People are used to the current behavior, that
 extends the last color.
 But as an extra option, it would be really useful.

Please note I don propose changing the behavior of repeat None - I just
consider that maybe it should have been the default in the begining,
but not changing it now.

 ___
 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

Re: [Gimp-developer] [FEAT-REQUEST] A way to quickly know layer dimensions in Gimp

[Joao S. O. Bueno]

https://bugzilla.gnome.org/show_bug.cgi?id=728493 - feature
implemented and comited
as new status bar codes. (%x and %y)

On 20 April 2014 23:15, Joao S. O. Bueno gwid...@gmail.com wrote:
 I think the only reason this has never been implemented is that it has
 been in the long term goal
 the feature of making layers auto-expand as required upon any
 operations outside its boundaries.

 This unbounded layers feature has been on the wish list since
 forever I guess - and it would make
 the display of the current layer size less useful - but even them it
 would not be at all useless.

 I think having status codes for the title and status bar to be one of
 the most appropriate ways
 to display this. Maybe also add layer information to the
 Imageinformation window (a layer tab) could
 be done as a more visible way to do it, as adding a status code for it
 would make it still be too
 hidden away for most users.


   js
  --

 On 19 April 2014 03:45, Liam R E Quin l...@holoweb.net wrote:
 On Sat, 2014-04-19 at 17:56 +1200, Jehan Pagès wrote:

  I add a feature request to display layer dimensions somewhere in the
  main window or the layers one. May be display only the current layer
  sizes, but would be great to see all layer dimesions at a glance.
  Could be an option in user preferences?'

 You can right-click on the layer in the layers dialogue and choose Layer
 Boundary Size, just under the second separator in that menu, although I
 don't know the difference between layer size and layer boundary size,
 and it's not terribly convenient.


 --
 Liam Quin - XML Activity Lead, W3C, http://www.w3.org/People/Quin/
 Pictures from old books: http://fromoldbooks.org/
 Ankh: irc.sorcery.net irc.gnome.org freenode/#xml

 ___
 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

[Gimp-developer] About closing feature requests as invalid

[Joao S. O. Bueno]

As of lately,
new, sometimes simple, feature requests added to bugzilla are being
quickly closed as invalid, with a short-text inviting the reporter to
discuss the feature here (developer mailing list) rather than
entering then at bugzilla.

This here is an  invitation for us to discuss this policy and set it
as official or not.

Personally, I find this to be harmful to the project. I think closing
a feature request
outright as invalid is more or less equivalent to slamming a door  in the
face of someone which is otherwise eager to help.

Even if the text always contain looks a nice idea, let's talk about
it on the mailing list,
the invalid', if only for the status name means... invalid. It is
not a nice word to receive
as an evaluation for what one thinks is a cool idea to the program

Moreover, it is not like we have been talkign about small aditions to
GIMP in this list,
and finding this is cool, it might go in right now or we have to
draft an UI spec to that (and
_actyually_ have such a draft made.

On the other hand most features I see being posted here have
discussions that fade away
into oblivion after a few replies, if that much.

i agree that the list could be used for that, but it is has not been
the case over the last
few years.


And still, a third point I see as counter-productive with the idea
ofmaking the list
mandatory for anyone with a new idea to GIMP: sometimes one may care
even to the
point of detailing an idea, and posting it to bugzilla, but the person
is not (and IMHO, should not)
necessarily be comited to helping GIMP to the point of joining the
development mailing list. So,
the person could simply think well, I tried to help this program, but
let me go back to my stuff). I'd do just so after filing bug reports
to any other program I just use in a normal basis, and fortunately it
did not happen there - and I am happy some of the ideas or suggestions
I just filled in the respective bug tracker ended up as nice features
instead of having them
invalidated because I was not willing to join the development
mailing list of each project.

So, I for one, feel like such requests in bugzilla should be left in
the New or Unconfirmed state,
with a text inviting the person to discuss it either her or on IRC,
stating that it might never
part from unconfirmed otherwise (but also, it could happen -
requests as simple as
having an option to display a Layer's size could be done by any of the
regular contributors
if he felt like it and had the time).

Whatever your (all) position on this, I'd like to state I am against
the policy of simply marking
a bug request as invalid, when it is not necessarily so,  a couple
of hours/days after it is filled in.

(Ref: https://bugzilla.gnome.org/show_bug.cgi?id=728493)


  js
 --
___
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] Fwd: Gimp Registry Future

[Joao S. O. Bueno]

Hi Sven -

It is nice to read this -
I am very interested in having it working on the client side - that is, a
GIMP plug-in that
could make one-click download of plug-ins, scripts and other resources
(brushes, tool settings, gradients and so on).

Having an API SPEC for the registry would be something great, because if
the current
implementation is found lacking in some aspects, it could later be changed
with
relative little pain, provided the API is respected.

We could build-up something that would allow users with different roles
(that is, system known  to individuals who are
reasonably well-known and accepted within their respective communities )
who can sign plug-ins, resources, and we should mostly try to get the build
of plug-in binaries
for windows and mac, and possibly even some distributions, automated in
some form (Jenkins
can do the building for testing purposes, I suppose we could fetch the
binaries it generates in
some form?).

To get working going on the registry API itself, maybe we could start work
on it in
a wiki page, and in a later state consolidate that into a more stable
document that
can be rendered into code.


Regards,

  js
 --





On 9 April 2014 09:57, Michael Schumacher schum...@gmx.de wrote:

 On 09.04.2014 14:51, Alexandre Prokoudine wrote:

  The expected effect of that will be a huge increase of deployed
  extensions and, as a consequence, an increased interest to GIMP from
  people who write exploits. My concern is how this interest can
  realistically be handled, because we shall be paying for a better
  technology with an increased reputation risk.

 The idea here is to cut down the number of people who may contribute
 binaries, from about everyone right now to individuals who are
 reasonably well-known and accepted within their respective communities
 (for example, the various IRC channels or forums around GIMP).


 --
 Regards,
 Michael
 GPG: 96A8 B38A 728A 577D 724D 60E5 F855 53EC B36D 4CDD
 ___
 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

[Gimp-developer] Creation of a set of operations item

[Joao S. O. Bueno]

Hi,
I would like to discuss about the possibility
 of a Set of operations GIMP item -

In the current state of GIMP, I think one
nice thing to have would be the ability to
specify sets of GEGL operations that could
be re-used across the UI in some different places.

One example of such Set of operations could be,
for example, a gaussian blur filter - the set
includes the parameters as well. Another
example could be a Resample to 50% size, Unsharp mask
set.

Where could those be used?
I thought of primarily two places - with more potential
nice places to come along:

1. As an adjust layer - just that - have
a special Layer class that encapsulates a set
of Gegl operations, and apply then to the
rendering of the layer imediatelly bellow.
This would give us Adjustment layers
as they are called in other software,
essentialy for free

2. Attached to an image, as a set to be
automatically applied before exporting the
image to an specific format.
Currently, the merge-visible-layers action
is performed at this stage, for most formats.
But in some mail-threads here it became clear that
the ability to resize an image to an specific
size, among other things, could greatly
simplify the current workflow for keeping
a high-quality XCF image, and exporting
incremental versions of down-sampled/filtered
versions for production. (Like in edit, save,
resize to 50%, export as PNG - undo to further
editing the image, and the resize is lost, and must
be reapplied when exporting the new version)

And there could be some bonus places to attach these
sets of operations:
3. To patterns, before applying them - so
that rotation and scaling of patterns would
be easy
4. To brush masks, as part of the painting dynamics.


Can we discuss this further along?
I know Mitch is experimenting with
operations attached to layers, but I don't
know wether they are along thse lines, or more
like recording all operations mad in a layer,
in an early quest to non destructive editting.

Maybe there is a roadmap for a similar
thing already, that I am not aware of - but
having the sets of operations behave
as regular GIMP items that can be used - and
being able to pick/create then at the layers dialog
bucket fill tool options, export dialogs, could
be a nice way of enabling the possibilities
of GEGL and non-destructive editing to end users.

Regards,

  js
 --
___
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] Creation of a set of operations item

[Joao S. O. Bueno]

Hi,
I would like to discuss about the possibility
 of a Set of operations GIMP item -

In the current state of GIMP, I think one
nice thing to have would be the ability to
specify sets of GEGL operations that could
be re-used across the UI in some different places.

One example of such Set of operations could be,
for example, a gaussian blur filter - the set
includes the parameters as well. Another
example could be a Resample to 50% size, Unsharp mask
set.

Where could those be used?
I thought of primarily two places - with more potential
nice places to come along:

1. As an adjust layer - just that - have
a special Layer class that encapsulates a set
of Gegl operations, and apply then to the
rendering of the layer imediatelly bellow.
This would give us Adjustment layers
as they are called in other software,
essentialy for free

2. Attached to an image, as a set to be
automatically applied before exporting the
image to an specific format.
Currently, the merge-visible-layers action
is performed at this stage, for most formats.
But in some mail-threads here it became clear that
the ability to resize an image to an specific
size, among other things, could greatly
simplify the current workflow for keeping
a high-quality XCF image, and exporting
incremental versions of down-sampled/filtered
versions for production. (Like in edit, save,
resize to 50%, export as PNG - undo to further
editing the image, and the resize is lost, and must
be reapplied when exporting the new version)

And there could be some bonus places to attach these
sets of operations:
3. To patterns, before applying them - so
that rotation and scaling of patterns would
be easy
4. To brush masks, as part of the painting dynamics.


Can we discuss this further along?
I know Mitch is experimenting with
operations attached to layers, but I don't
know wether they are along thse lines, or more
like recording all operations mad in a layer,
in an early quest to non destructive editting.

Maybe there is a roadmap for a similar
thing already, that I am not aware of - but
having the sets of operations behave
as regular GIMP items that can be used - and
being able to pick/create then at the layers dialog
bucket fill tool options, export dialogs, could
be a nice way of enabling the possibilities
of GEGL and non-destructive editing to end users.

Regards,

  js
 --
___
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.6 french mac manual

[Joao S. O. Bueno]

Hi marianne -

While some of your concerns could be more carefully addressed, please
note that GIMP 2.6 has been discontinued almost 2 years ago. The
current stable option of GIMP is 2.8 - and we have new people
(volunteers as you said)  actively working on the actual GIMP program
release for the Mac. The manual is a separate, huge, hybrid software
and documentation project and I think it had not been tackled by the
Mac folks in recent months or years.

Maybe your message could spark address in a fresh and working manual
release for Mac if there is none at the moment - but I can't see as
writing it in a hostile tone as you had just done could make anyone
more interested in working on that in their free time.

  js
 --

On 1 March 2014 11:00, marianne ganeau marianne.gan...@wanadoo.fr wrote:
 … First : it's almost impossible to join you to report a problem or a bug. I
 can understand that you are volunteers faced with many requests but it
 doesn't explain or excuse nothing because if you are responsible of a
 project you have to be in touch with your users. When I was volunteers for
 others projects it was my philosophy. Since in the mailing lists you can't
 find absolultely nothing because there is no mecanism of search in thousands
 and thousands and thousands of pages !
 Second : I have several problems with Gimp and I could not find nothing in
 the lists or other bugs pages : hopeless.
 My prinicipal problems : I could download the GIMP 2.6 french Mac manual…
 But after downloading the .zip and opening it, I installed the package and
 the result of this installation on my hard disk is only another « package »
 which make… another installation but all ends with an « error » in this
 second installation… I tried ten times and each ended with the same result.
 And impossible to find an explanation in the lists or bug reports : am I
 alone to have this problem 
 The other problem I have with Gimp: The ufraw which is integrated in 2.6
 GIMP (my operating system is Mac OS 10.4.11) cann't read correctly the raws
 of my camera. So, I should need to download the ufraw 0.19.2 which knows
 this camera… I could download it but I obtain a folder and I don't know how
 install it in Gimp and… and one more time, impossible to find a help in any
 part.
 Sure, I'm not a good computerist and perhaps I'm not able to work with free
 softwares, but I was able to work with my macs from approximatively 30 years
 and I could do maintenance and repairs for ten computers in my job. So I'm
 not so stupid but I can need for help !!! and I don't find where is the help
 in your world and I'm sorry because the free softwares are a fantastic idea
 but which would require some solidarity. I did'nt find it here.
 Perhaps can you explain to me ?
 Best regards,
 Pierre Jacquin.

 ___
 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

Re: [Gimp-developer] assets in the high bith depth age

[Joao S. O. Bueno]

I agree with the file-format,
ad I don't think keeping the i18n's in file is a bad thing to do.

The idea of having a file as a pill containing all the translations,
and such seens much
more tasty than having to distribute separated i18n resources when
I publish, say, a color palette on my blog.

Distributors of third party files are welcome to accept downstream
contributions to the assets
they create, or license their works in a way to allow for the creation
of new versions,
containing more languages.

However, one option does not exclude the other - the use of the
localization could be made in a way
to use either built-in translations for colors/metadata or look for
them in an external location
if the former way defaults. (then one could have the best of both Worlds)



  js
 --


On 9 February 2014 18:45, Ofnuts ofn...@laposte.net wrote:
 On 02/09/2014 07:55 PM, Alexandre Prokoudine wrote:

 Hi,

 I'm curious if we have a plan for assets in v2.10 and onwards now that
 16/32 bit is possible. Color palettes and gradients are still based on
 raw 8bit RGB values, and pattern files are 8bit as well.

 FilmGIMP/Cinepaint fixed that in the past by converting everything
 to 16bit integer (afaik, integer), but I'm not sure if that's such a
 good idea.

 Some things to consider, in no particular order:

 - IMO, ideally, stock color palettes should be using a linear
 device-independent color space (some sort of LCh?);
 - it should be possible to use palettes that rely on arbitrary color
 models (RGB, LAB) to make paint vendors happy;
 - we still need to solve the i18n issue that was raised recently
 (non-translatable palettes/colors/etc. names).

 In my opinion, a sensible way to approach that would be using an
 already available, but somewhat forgotten file format devised by
 Olivier Berten during his work on SwatchBooker:

 http://selapa.net/swatchbooker/

 To reiterate my earlier email to create@, the benefits of this file format
 are:

 - simple combination of XML + ZIP
 - (nearly) any color model + optional mapping to an embedded ICC profile
 - flat colors and gradients supported
 - spot colors supported
 - i18n-ized names of all metadata fields and color names

 There is no other file format that would provide the same set of
 features for us, free or non-free:

 http://www.selapa.net/swatches/colors/fileformats.php

 So the questions are:

 - Is changing the assets file format something we need to do for 2.10
 (or maybe at all)?
 - Is the SwatchBooker's file format right for us?
 - do we actually have resources to make the switch?

 Opinions?


 Yes, that seems necessary.

 But I don't like much how i18n is handled in the SwatchBooker format.  I
 don't think the file should contain the names in multiple languages. Most
 resources distributed outside of Gimp (DeviantArt, etc...) are by isolated
 authors, and I would not expect their resources to be tagged in more than
 two or three languages (English plus their native languages). I18N support
 is done by users, and that would mean making a local version of the file to
 display the file in the user's language. I would think a single name in the
 file, remapped using a locale-dependent translation file (one in /usr/share
 on in the user's profile) would let users rename resources more efficiently.
 This method could also be used to display localized names for other
 resources (brushes, patterns...).

 ___
 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

Re: [Gimp-developer] Gimp Manual Roadmap proposal

[Joao S. O. Bueno]

Hi Roman -
when you talk about a 3.0 manual version in 3.0 - I am with the
impression that the
purposed changes would take place before GIMP 3.0 itself (as the next version
shall be 2.10)

So - it looks like the purposed version numbering would dissociate the
manual version from GIMP's version - is that so?  I think that might
be confusing - although on a second thought it could be
a manageable confusion, if it is clearly specified, inv arious places, that,
for example, gimp-help-2 3.0 refers to gimp-2.10 .

(As for the idea of going github I am of the same opinion as Jehan.
We could put a mirror (fork in github parlor) there - but the
authoritative repository
should, by the reasons listed and maybe some more,
be kept in the gnome infrastructure).


regards,

  js
 --
___
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-docs] Gimp Manual Roadmap proposal

[Joao S. O. Bueno]

RyoTa :

how much do you know about Publican? Do you think it is possible to
change it so that it would allow
the extra forms in which we use these links could work? (We'd try to
commit these changes upstream, of course).

otherwise, I agree it is not a suitable option.


  js
 --


On 7 February 2014 12:52, RyoTa SimaMoto liangtai@gmail.com wrote:
 Hi,

 I am warry about to use Publican.

 Publican prohibits to use link linkend=...WORD(S)/link tag
 then allows xref linkend=.../ tag only for internal hyperlink.
 (xreflabel is also disallowed.)
 http://jfearn.fedorapeople.org/en-US/Publican/3.2/html/Users_Guide/appe-Users_Guide-Disallowed_elements_and_attributes.html

 That means we need revise whole text so that each targeted section
 has a title.  In much cases on our document, we use link with
 verb/noun for representing an action, a filter, or a tool of GIMP
 instead of using its title in the reference section.  To replace it
 with xref, almost links may be reformed in 'see also' style,
 because it cannot be replaced with other adjusted phrase for inline
 context at referring text.

 I presume some translators may unwelcome this restriction especially
 for languages that have conjugation and/or declension, when xref
 tag happens in the middle of text structure.

 If this rule does not make any matters for you, Publican may be the
 best choice.

 Cheers,
 -=-=-=-
 RyoTa SimaMoto liangtai@gmail.com


 2014-02-05, Roman Joost romanof...@gimp.org:
 Hi,

 I've put together a Roadmap proposal under:

 http://wiki.gimp.org/index.php/Documentation:Main

 Any feedback is welcome. Some of the points are not to be read as: go
 ahead and implement, but rather look into it for it's feasibility.

 If there are no objections or comments I'd basically call the roadmap
 silently as accepted. For each point I think it'll be good to create
 bugs so we can track progress.

 Kind Regards,
 --
 Roman Joost
 www: http://www.romanofski.de
 email: romanof...@gimp.org
 ___
 gimp-docs-list mailing list
 gimp-docs-l...@gnome.org
 https://mail.gnome.org/mailman/listinfo/gimp-docs-list

 ___
 gimp-docs-list mailing list
 gimp-docs-l...@gnome.org
 https://mail.gnome.org/mailman/listinfo/gimp-docs-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

Re: [Gimp-developer] Python plugin dev: getting picked color from gimpui.PickButton.color-picked event callback?

[Joao S. O. Bueno]

You are really trying something very different than what the current
GIMP-Python integration is thought of to do:
You are using gobject introspection to call functions that up to now
have only been called from native-code
plug-ins (normally in C), and have no provision to be called from
Python or other language supported
by gobject introspection but for the automatic generation of the bindings.

I am in fact surprised you could get this far.

GIMP-Python plug-ins, AKA python-fu, are designed to around a python-module
that is delivered with GIMP, and comunicates with GIMP through the
Procedural database (PDB).
The module does have some higher level constructs, such as images,
layers, layer-groups,
but these are just rebuilt on the Python side from  values such as
numeric and string IDs fetched
from GIMP through pdb calls.

That said, you can see all your available API by going to help-PDB
browser on GIMP.
(Open any .py file that comes with GIMP to see how the plug-ins are
registered and created,
if yours go on a completely different way by trying to use the libgimp API)

Now, plug-ins in GIMP - neither the ones built using native code - are
not supposed
to be able to change the active tool while running - so, to get
exactly what you want is impossible.

You can make a Python plug-in that will display a custom gtk+ window,
change a layer's visibility,
and display instructions for the user to change to the color picker
tool (maybe your hack with gobject
can do that, but I would not trust it across GIMP versions/platforms),
and pick a color.
At this time, the plug-in can read the picked color with a call to
pdb.gimp_context_get_foreground .

  js
 --



On 5 February 2014 21:20, Viet Nguyen vietjtngu...@gmail.com wrote:
 My goal is to write behavior where a click on my special pick button will

 1. Modify layer visibility
 2. Run the normal pick tool
 3. Do something with the picked color

 I'm trying to do this as a Python plugin so I'm trying to implement this
 using `gimpui.PickButton` and adding event callbacks for `clicked` and
 `color-picked`. I'm using `pydoc gimpui` as a reference.

 Unfortunately the Python API apparently has obscured the color data
 structure that gets passed to the `color-picked` event callback. It passes
 it as a `gobject.gpointer` which is just an intractable pointer (see
 http://developer.gimp.org/api/2.0/libgimpwidgets/GimpPickButton.html#GimpPickButton-color-pickedand
 https://developer.gnome.org/glib/2.37/glib-Basic-Types.html#gpointer). I
 don't know of any way to pull out the triple double union in Python.

 A simpler solution would be to simply activate the standard color picker,
 but I can't figure out how to do that with the API available. I would
 appreciate any help and/or ideas on this.

 Thanks!

 Viet
 ___
 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

Re: [Gimp-developer] Release and translation of textures

[Joao S. O. Bueno]

On 4 February 2014 21:56, Michael Bauer f...@akerbeltz.org wrote:
 Hi,

 Two questions - I've got the main UI translation for Gaelic (gd) at 97%
 (some strings I need to check in context) but I was wondering at this point
 what the process for getting a new locale into release is? Is it automatic
 or do I need to file a bug and go through a release process?

 The other question is about the textures - they are the most noticable
 non-localized part of the UI at the moment and they're not in the main po.
 I've looked at the other files with the gimp- prefix on Gnome but can't see
 them in there either (stuff like Ancrylic, Grass, Smoke...)


Unfortunately names for GIMP resources - such as textures (patterns),
brushes, palettes, gradients are not internationalized, and are untranslatable.


 What file are they in?

 Cheers

 Michael
 ___
 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

Re: [Gimp-developer] Get pointer coordinates in a python script

[Joao S. O. Bueno]

All painting is done in a GEGL Buffer -
but the events got from the user don't traverse a GEGL interface into
GEGL nodes which paint on these buffers: I think
it should not be to hard to think of a way (I am not saying
about it would not be hard to implement - I am saying
it would not be hard to think about it) - of
getting the events processed in GIMP,  have
the parts which does the dynamics in a separate logic layer,
in a way one could get the processed events in an arbitrary
GEGL node - the events would simply be an input.

That way, the modular design of GEGL could be used
to create modular tools into GIMP.


  js
 --

On 26 January 2014 00:47, Daniel Sabo daniels...@gmail.com wrote:
 All painting is GEGL based in 2.10; I don't think there is any plan to
 allow arbitrary ops for painting. You can't retrieve coordinates is
 because plugins run in their own process and can't access Gimp's event
 loop or windows. It would be hypothetically possible for Gimp to pump
 events across to the plugin process, but my understand is that
 preventing plugins from interacting with Gimp's GUI was an intentional
 design decision.
___
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] Get pointer coordinates in a python script

[Joao S. O. Bueno]

On 25 January 2014 10:30, Dimitri Robert dimi...@gabian-libre.org wrote:
 Hi,

 I need to get pointer coordinates for a Python script but I didn't found the
 methode to do that.

 Result of my searches :
 - no function in the pdb
 - need to use PyGTK and gtk.gdk.Event.get_coords but I don't need to create
 Event and Window objects, just to found existing.

 How to use canvas Window and Event object?

 f
 But, maybe am I on a bad path...

That is the keyword for the only existing work-around
path.
The only current way to retrieve user coordinates on an image
from a Python script is to ask the user to draw a Path
(vector) with the paths tool beforehand (or at least,
before pressing the script's ok button) and then
use the vectors pdb calls to retrieve those coordinates.

There is no way to retrieve information in an interactive
way - but for a bad hack: letting your plug-in
running and retrieve coordinates from the active paths
by pooling it at each few tenths of a second.

When transitioning to GEGL painting, which
is not scheduled to happen to gimp 2.10 -
maybe it will be possible to use arbitrary GEGL meta-operations
to respond to GIMP events. My idea is that it should be
possible to create such meta-operations from Python
or other language bindings - but this is loong downroad,
and as far as I think, had not been discussed among
the developers in any detail.

  js
 --


 --
 Dimitri Robert
 Jabber — dimitrirob...@jabber.fr
 Twitter — @DimitriLav
 ___
 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

Re: [Gimp-developer] Enhancement request for .cur cursor files

[Joao S. O. Bueno]

I don't know if closing the bugt report as invalid is a nice choice,
if it is a valid feature being requested.

Are there more bug reports asking for the same thing? (/me shyes away
of dealing with bugzilla)  - so this would be a duplicate?

From your quotes above, it is clear that creating cursos files does
fit in the product vision, and I do agree it GIMP should have support
for it.

  js
 --

On 19 January 2014 04:30, scl scl.gp...@gmail.com wrote:
 Hi,

 currently we have a bug report to add export for .cur files:
 https://bugzilla.gnome.org/show_bug.cgi?id=722472

 To triage this I looked around in the plug-in registry
 and former postings on the mailinglists. I found that
 this request came up from time to time (often together
 with the wish for animated cursor files (.ani)).
 There was also a [solution] for .ani files at GIMPTalk,
 which could probably be used or GEGL-ified with some adaptions.
 In the past this request was [refused], because it was considered
 too special.

 On the other hand - looking at our [product vision],
 we defined GIMP as 'a high-end application for producing icons,
 graphical elements of web pages and art for user interface elements'-
 If in vanilla GIMP is room for rather exotic formats like
 KISS Cel, XJT, FITS or DICOM, why not for those that meet our vision?
 The Linux build of GIMP 2.8 contains 'X11 mouse pointer (*.xmc)'
 which is one step into the right direction, but useless for
 Windows users.
 Viewing it from this point of view I would say it could be part
 of GIMP.

 How do we proceed with this request?

 Kind regards,

 Sven


 [refused]:
 http://search.gmane.org/?query=.curgroup=gmane.comp.video.gimp.user

 [solution]:
 http://www.gimptalk.com/index.php?showtopic=27281

 [product vision]:
 http://gui.gimp.org/index.php/GIMP_UI_Redesign#product_vision
 ___
 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

Re: [Gimp-developer] Image history access from python

[Joao S. O. Bueno]

Hi Pacco-

yes, subverting Path creation for getting user coordinates is currently the only
way GIMP plug-ins have to get them. (You could however, clear the
paths on the plug-in call if in your workflow clearing them become a
burden)


It is interesting to note that even the C plug-ins that ship with GIMP can only
get image coordinates by re-creating an image preview inside their window
(that could be done from Python plug-ins as well). But this is done by
old-style plug-ins  - new style plug-ins, using GEGL, don have much
of an UI definition yet, besides automatically generated UIs from the
GEGL-operation parameters.

I had proposed a couple of times in the past (distant past by now) to have
a way to call-back plug-ins upon user
actions on the images. Such a discussion should pop back
anytime soon, since on-dialog image previews for plug-ins
are now a thing of the past.

I don't think your proposal as is should fly though - I can't see
how to define
an image click from within a plug-in like you do. A click using what
tool? What settings?

Maybe a plug-in tool that would give a plug-in (or Gegl-op ) access
to all stroke parameters, more or less as specified in the ink markup
language would be a
more solid approach for GIMP (http://www.w3.org/TR/InkML/) in the
foreseable future.

  js
 --

On 15 January 2014 07:42, Paco Garcia jfga...@gmail.com wrote:
 hi, it would be very helpful to have access to the history of each image 
 object
 from python, at least to the coordinates where the user has pressed, for
 example in two of my scripts to take coordinates from the user I force them
 to create paths of only use the coordinates of two nodes, if I had access
 to the user history clicks only have to access the last two clicks, for
 example:
 img = gimp.image_list () [0]
 h = img.History
 x1, y1 = h.mousePos [h.Length-1]
 x2, y2 = h.mousePos [h.Length]
 Or something like this
 Currently forced the user to create paths which then has to clear, the
 examples are:
 http://www.arakne.es/en/dessign/gimp-python-plugin-rotate-image-using-paths/
 http://www.arakne.es/en/dessign/gimp-script-stitch-layers/
 Paco García
 ___
 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

Re: [Gimp-developer] how far from 2.10?

[Joao S. O. Bueno]

 OK, maybe I'm pessimistic here, even if some of my python scripts had to be
 reworked between 2.6 and 2.8, which have far less differences than 2.8 and
 2.10. Then in the current API there are still many values with 0-255 ranges
 (gimp-drawable-{get|set}-pixel (),gimp-histogram) for instance. So either
 there is absolutely no change in the API and the script may produce
 sub-optimal results in images with high bit depth, or there is some change
 and the script has to be reworked and may be made bimodal or forked to
 support 2.8 and 2.10.

If the PDB/Python API is to  support even the majority  of the new
functionalities, i t will need
a lot of additions/rethink. And it is not only on the Python side.
On the other hand, It would not be nice to add a   lot of new calls to
the API for 2.10, and get those invalidated by the transition to a
GIMP 3.0 afterwards, so we better have some care in picking the new
calls.

When working from Python code, the ideal direction to go is easy to
imagine: to have a couple PDB calls to get a GEGL buffer (or source
node) returned from GIMP, and then using GEGL-based code to perform
the actual image operations, and return a node, or buffer back to
GIMP.

That way, one won't need to rewrite every PDB call to support several
pixel formats, and that would be valid only for GIMP 2.10.

On the other hand, it is not currently easy to use GEGL bindings to
the Python linguage -
due to tha fact that all binding is delegated to be auto-generated by
gobject introspection, which in, its turn, is only maintained for
glib3, gtk+3 - (while GEGL is tied to glib2).

I could get it working, more or less here - some calls simply crash -
and started a small project to wrap the g.i. automatically generated
objects ito things friendler to the Python developer (check
https://github.com/jsbueno/python-gegl), but that depends that one
sets-up g.i. and pygobject, correctly previously. And these projects
branchs to support glib2 are apparently unmaintained, and had already
bit-rot a bit. (If someone can get pygobject working cleanly with
GEGL, please do tell me and say which versions you have used)

Still, I maintain that, at least for a Python API, that would be the
better way to go - we'd have to either unrot pygobject + gegl
bindings, or find another route to  use GEGL from Python that would be
api-compatible to pygobject + gegl on glib3.

(So that is also my what is missing before  2.10 in what concerns
automating GIMP via Python)

  js
 --
___
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] Why so COMPLICATED?

[Joao S. O. Bueno]

On 27 December 2013 16:22, Sam Gleske sam.mxra...@gmail.com wrote:
 Original message below.  I see a good feature recommendation here.  Sliders
 for fuzzy selection in the select Tool Options dialogs.  I think it would
 be useful.



Well, that is there since...forever!
The task at hand here is somewaht different - giving
control to fuzzy out the contents on paste - that makes the difference,
for two things:
1) you can see the final result as you play along with the silder
2) you make the pasted content fuzzy so that it has
100% transparency on its border. With fuzzy selections,
you get 50% transparency on the border, before cutting. After pasting,
one has to go through all the steps listed above, and they are
quite a few.


 On Mon, Dec 16, 2013 at 2:34 PM, SirCrow for...@gimpusers.com wrote:

 Hello.  I've tried using GIMP many times, yet I've accomplished very
 little,
 given all of GIMP's functionality.  For example:

 If I want to select part of an image and copy it to another area or to a
 new
 image/layer, and also FEATHER the edges, here's how I'd do it in an old
 graphics
 app I often used years ago:

 1. Select the area.
 2. Hold Ctrl while moving selection with Move tool.
 3. Use the slider to soften the edges to my liking.
 4. Press Enter to anchor selection.  Done.

 And there were sliders also for opacity and other things.  So very SIMPLE
 because the prog. was designed very intuitively.  How would I accomplish
 the
 same in GIMP?  Well, most of the time, I WOULD ACCOMPLISH NOTHING!  At
 best, I'd
 enter values into the box, not like the result, enter new values, repeat.
  And
 that's on a good day.

 PLEASE, I beg you, somebody write a SCRIPT/PLUGIN that allows the use of
 sliders
 exactly as described above!  I desperately want to be a HAPPY GIMP user,
 but I'm
 growing ever more hopeless.  I don't want to turn on my older PC just to
 use a
 graphics app that actually lets me get things done.  Thank you.

 Joe

 --
 SirCrow (via www.gimpusers.com/forums)
 ___
 gimp-user-list mailing list
 List address:gimp-user-l...@gnome.org
 List membership: https://mail.gnome.org/mailman/listinfo/gimp-user-list

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

Re: [Gimp-developer] Scripting: creating a channel from a layer in another image and other channel-related manoeuvres

[Joao S. O. Bueno]

When in doubt,  gimp-edit-copy and gimp-edit-paste can be quite handy
to transfer pixels across layers/channels/images.

On 14 December 2013 11:49, Ofnuts ofn...@laposte.net wrote:
 On 12/14/2013 12:21 AM, Ofnuts wrote:

 Then, gimp-layer-create-mask will accept a ADD-CHANNEL-MASK (6) type, but
 in this case how do I specify the channel?


 Some googling got me an answer to this (it uses the active channel) so I
 have that part covered. Now for the other question, any takers?


 ___
 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://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://gnome.org/archives/gimp-developer-list

Re: [Gimp-developer] Gimp from git Gegl Gaussian Blur and Unsharp Mask useability issues

[Joao S. O. Bueno]

Agreeded - the size sliders in GIMP are a problem -
I've implemented the logarithmic slider  back in the time - and it was
ovecome by the new linear sliders. I still don't see how the lienar
sliders make sense - when painting detail one endś up using the left
5% of the slider to count values.
(The new widget also takes more well positioned clicks to allow one to
type in a new value - on the up-to-2.6 widget, one could click, swipe
over the text entry box - that would select the value there, and just
type in a  new value -
the way the new one misbehaves is subtle, but far harder to use )

Can we rethink those sliders for gimp 2.10 ? Not trying to add new
features/fixes like I tried in the final days before 2.8 (make the
click on botton half to slide the value behavior to be sensible to
mouse speed),  - but check how is the actual usage, and put in place
something less clumsy  instead?

(And have in mind you are talking about a value one sets ina  dialog,
but the same disfunctional widgets are used when painting)
On 3 December 2013 15:34, Elle Stone ellest...@ninedegreesbelow.com wrote:
 For a sample camera-generated jpeg, in Gimp 2.8, Radius 50.0, Amount 0.15,
 Threshold 0 does a nice job. Experimenting, the Gimp 2.9 USM settings that
 produce a similar result are Std. Dev. 4.00, Scale 0.20. These are very
 small values on a very large slider range.
___
gimp-developer-list mailing list
List address:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list

Re: [Gimp-developer] Gimp from git Gegl Gaussian Blur and Unsharp Mask useability issues

[Joao S. O. Bueno]

On 3 December 2013 17:10, Teo Mazars maza...@ensimag.grenoble-inp.fr wrote:
 Hah, and the computational explosion with bad parameters is a known bug in 
 a lot of GEGL operations, it may even make GIMP crash. It probably needs to 
 be fixed in each operation individually, but this is not obvious... Perhaps 
 we will need to make the process step of GeglOperations cancellable at some 
 point? Unclear...


Certainly it would be a lot better if while trying to click on the
number to type in a new valuein the Gaussian Blur filter dialog in
GIMP, you could not accidentally click on the bar bringnig the
radius to 850, and having to wait several seconds until GIMP becomes
responsive again.


accidentally is quoted, because it is actually very hard not to make
that happen. I know the widgets are pretty - no one can deny that -
but maybe, just letting the typeable values lie outside the range of
the slider would be a nice-enough fix already.
___
gimp-developer-list mailing list
List address:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list

Re: [Gimp-developer] pathon-scripts with GEGL?

[Joao S. O. Bueno]

I've writing started such CPython bindings yesterday - in time we
should expose the buffers in a proper way.

https://github.com/jsbueno/python-gegl


What is difficult to do via pygobject bindings is to make use of GEGL
itself - the linked example file of yesterday sepeaks for itself.

While GEGL in C has provisions for function calls to be made emulating
named parameters from Python, for, for example, setting various
properties at once, I didn't get that to work from Python. Moreover, a
Python user wll rather do: pngnode.path = myfile.png - rather than
pngnode.set_property(path, myfile.png) as is required by the
automated bindings.

Daniel - if you are into it, I've hit a but at my first steps: when using
GParamSpec objects (via an operation_list_properties call) I had the
Python interpreter segfaulting (it happens on trying to introspect the
GParamSpec objects with dir,  but in other occasions I could not
isolate as well)

js
  --


On 29 November 2013 05:31, Daniel Sabo daniels...@gmail.com wrote:
 Assuming were talking about gegl-master here, what are you unable to
 do via introspection? The introspection bindings have full coverage of
 the GEGL API. Mainipulating pixels directly (rather than though
 operations) involves more copying in Python than is C because Python
 has no concept of mutable buffers. It would be possible to expose
 things via ctypes or numpy, but that requires writing a CPython module
 and will probably not be part of GEGL itself.

 To get/set raw pixels from from a gegl buffer use Buffer.get(...) and
 Buffer.set(...).
___
gimp-developer-list mailing list
List address:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list

Re: [Gimp-developer] pathon-scripts with GEGL?

[Joao S. O. Bueno]

Ok - if it is working in current stable versions, I am fine them
(yesterday I falied to build pygobject 2.28.6 on a first try, in a
clean prefix., will try harder later on).



On 29 November 2013 13:32, Daniel Sabo daniels...@gmail.com wrote:
 $ python
 Python 2.7.3 (default, Jul 24 2012, 11:41:40)
 [GCC 4.6.3 20120306 (Red Hat 4.6.3-2)] on linux2
 from gi.repository import Gegl
 Gegl.init([])[]
 params = Gegl.operation_list_properties(gegl:png-load)

 (python:21947): GEGL-gegl-operations.c-WARNING **: Adding
 GeglChantinvert-linear_c shadows GeglChantinvert_c for operation
 gegl:invert
 /usr/lib64/python2.7/site-packages/gi/types.py:43: Warning:
 g_object_get_qdata: assertion 'G_IS_OBJECT (object)' failed
   return info.invoke(*args, **kwargs)
 /usr/lib64/python2.7/site-packages/gi/types.py:43: Warning:
 g_object_ref_sink: assertion 'G_IS_OBJECT (object)' failed
   return info.invoke(*args, **kwargs)

 ** (python:21947): CRITICAL **: pygobject_register_wrapper: assertion
 'PyObject_TypeCheck(self, PyGObject_Type)' failed
 dir(params[0])
 Segmentation fault (core dumped)
 $

 There are bugs is older versions of pygobject related to dir() and tab
 completion in the interactive interpreter, I suspect you're hitting
 one of those.

 I can't replicate this crash when using pygobject 2.28.6 and
 gobject-introspection 1.38.0, but I have seen similar issues on Ubuntu
 12.04 which uses gobject-introspection 1.32.0.

 The warning about GeglChantinvert-linear_c shadows GeglChantinvert_c
 means you have old files in your $PREFIX/lib/gegl-0.3/ directory you
 should probably delete.
___
gimp-developer-list mailing list
List address:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list

Re: [Gimp-developer] pathon-scripts with GEGL?

[Joao S. O. Bueno]

There are currently no, that I know, scripts that use both GIMP-Python and
PyGegl - if there are, tehre is no integration between both.

Python + GEGL should work fine though Pygobject introspection -  but
currently there is no straightforward way for retrieving a GEGL Buffer for
a GIMP drawable, operate on it, and putting it back on GIMP.  - We
certainly should think about providing this
functionality for GIMP though.



On 28 November 2013 08:38, Gunold Brunbauer gunoldbrunba...@online.dewrote:

 I want to get used to python-scripting in gimp. Therefor I want to study
 some scripts. Can anybody recommend me some scripts which are easy to
 understand and use GEGL?

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

Re: [Gimp-developer] pathon-scripts with GEGL?

[Joao S. O. Bueno]

Here -
I've put together this proof-of-concept snippet using Python + Gobject
introspection + GEGL -

While both GEGL, Gobject and Python are higly introspective tecnologies,
leaving them connecting all by themselves
as is the current status of Python + GEGL leave space for a lot of
improvement -
(the Python introspection cannot introspect into GEGL stuff, but for
indirectly calling the GEGL API,
and setting proeprties on GEGL nodes has to be done by the C API as well,
despite
Python's (and gobjects's) numerous features for property handling)

http://pastebin.com/aiZ4Zv87


  js
 --


On 28 November 2013 12:46, Joao S. O. Bueno gwid...@mpc.com.br wrote:

 There are currently no, that I know, scripts that use both GIMP-Python and
 PyGegl - if there are, tehre is no integration between both.

 Python + GEGL should work fine though Pygobject introspection -  but
 currently there is no straightforward way for retrieving a GEGL Buffer for
 a GIMP drawable, operate on it, and putting it back on GIMP.  - We
 certainly should think about providing this
 functionality for GIMP though.



 On 28 November 2013 08:38, Gunold Brunbauer gunoldbrunba...@online.dewrote:

 I want to get used to python-scripting in gimp. Therefor I want to study
 some scripts. Can anybody recommend me some scripts which are easy to
 understand and use GEGL?

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

[Gimp-developer] Python wrappers for easier GEGL access -

[Joao S. O. Bueno]

Hi there -

as you may know, i tis possible to use GEGL from Python and other languages
by using gobject introspection -

But the automated bindings generated make it too verbose, and
make poor use of the introspection built-in GEGL itself -

So I've created these lightweight wrappers over the automatic bindings,
with the main objective of exposing GEGL's introspection facilities
transparently
in Python:

https://pypi.python.org/pypi/python-gegl/0.1
https://github.com/jsbueno/python-gegl/releases/tag/v0.1

The little code that is in there now should be enough to get
started in popularizing GEGL as a general purpose Imaging Library
for people doing Python -
if only we can make pygobject installation itself easier. :-/


  js
 --
___
gimp-developer-list mailing list
List address:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list

Re: [Gimp-developer] Blinds filter unavailable in GIMP master

[Joao S. O. Bueno]

Anyway - I consider this particular filter long due obsolete.
I do use filter-render-pattern-grid (set vertical grid width to 0) for a
much better horizontal stripping effect.


On 1 November 2013 20:06, Michael Natterer mi...@gimp.org wrote:
 On Fri, 2013-11-01 at 21:55 +0100, scl wrote:
 Hi,

 where has the Distorts/Blinds... filter gone in master?
 I looked twice and refreshed the scripts, but the filter
 is away. It happens in GIMP master on Linux and Windows.
 Also the [GEGL porting matrix] doesn't contain it.
 Is this a bug or by intention?

 It's this commit:

 commit 5a851c3c9b2b777170fbee4fafdd27e91c01baf4
 Author: Øyvind Kolås pip...@gimp.org
 Date:   Thu May 3 03:59:19 2012 +0200

 plugins: hide blinds operation

 But I don't remember why exactly it was hidden.

 --Mitch


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

Re: [Gimp-developer] Quick-edit workflow

[Joao S. O. Bueno]

On 31 October 2013 05:36, Karl-Heinz Zimmer khzim...@posteo.de wrote:
 Yes, you can add such a shortcut, please go to:

Edit / Keyboard shortcuts ...

Just a somewhat  unrelated notice - as I consider this one of GIMP's
most important features:
in GIMP you don't have to go to Edit-Preferences-Interface-Edit
Keyboard Shortcuts, navigate in a
separate structure to your feature, and then pick a  keyboard
shortcut. That is there, and works - but what is cool
is the Dynamic Keyboard Shortcuts feature - enable it once in
edit-preferences-interfaces -
and never step out of your workflow to assign a shortcut again: Just
pick a shortcut when you are about to use
a feature, on the very same menu you use all the time.

(it doesn't warn you if you overwrite a shortcut - but then, you can
simply restore any accidentaly changed shortcut just as  easily)


  js
 --
___
gimp-developer-list mailing list
List address:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list

Re: [Gimp-developer] Of Palettes and Plug-ins

[Joao S. O. Bueno]

On 7 September 2013 03:20, Warren Turkal w...@penguintechs.org wrote:
 On Fri, Sep 6, 2013 at 11:20 AM, Joao S. O. Bueno gwid...@mpc.com.br
 wrote:

 From the above comment, I assume that what I want to do will be hard. Any
 pointers on what would need to change to make it more useful? I'd be happy
 to try to do some of the work if it ends in making possible what I want to
 do.

Let me say it again:
The string IS the Pallete as far as any code relating to GIMP via PDB is
concerned. It works more like an ID than as a name.  And the PDB is
quite complete in what relates to Palette
manipulation.


Check this Python-fu Session - it creates a new palette and adds entries to it,
just as you want:


GIMP 2.9.1 Python Console
Python 2.7.3 (default, Jul 24 2012, 11:41:40)
[GCC 4.6.3 20120306 (Red Hat 4.6.3-2)]

 pal_id = warren palette

 pal_id = pdb.gimp_palette_new(pal_id)
 print pal_id
warren palette
 pdb.gimp_palette_add_color(pal_id, black, (0,0,0))
Traceback (most recent call last):
  File input, line 1, in module
error: procedure not found
 pdb.gimp_palette_add_entry(pal_id, black, (0,0,0))
0
 pdb.gimp_palette_add_entry(pal_id, golden yellow, (255,230,0))
1
 pdb.gimp_palette_add_entry(pal_id, pinkish, (255,200,150))
2


And voilá- when I look in the Palette's dialog, in GIMP, the new
Palette _is there_,
with all three colors, fully featured as any other GIMP's palette
and with all the export options enabled for it.

Just take care with the line that goes:
 pal_id = pdb.gimp_palette_new(pal_id)

It is important to store the ID as the return value of the call to
gimp_palette_new,
because it the palette name you attempt to create already exists, GIMP will
automatically modify the name with a numbering scheme - and the modified name
will be the ID for that pallete.

In practice, a Python Script manipulating Palletes never needs to do
anything with the
value passed around as a PF_PALETTE - (if it is a plug-in to
manipulate them in place, that is) -
it is just passed into the plug-in, and it is iused as an ID for all
Palette related calls.

BTW, it just occurred me that you might not yet be aware of the
procedure-browser functionality:
in GIMP, just open help-procedure browser - now type palette in the
search box -
there you are, all palette related calls available for your plug-in.






 But having the string passed around between plug-ins works as nicely
 as it can be - I had written some palette creating/exporting a few
 years ago.


 Passing around a string doesn't really suit the use case I want to
 implement. I basically want the plugin to be able to return a palette that
 the core code registers if the running of the plugin is successful.

 Are there any pointers for doing this kind of thing that I should be looking
 at?

 Thanks,
 wt
___
gimp-developer-list mailing list
List address:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list

Re: [Gimp-developer] Of Palettes and Plug-ins

[Joao S. O. Bueno]

On 7 September 2013 04:18, Warren Turkal w...@penguintechs.org wrote:
 I haven't found any way to make that interface work for what I am doing.
 Basically, I need to be able to return a palette object, but not one in the
 UI yet. That palette object can then be loaded by the existing gimp code
 into a new palette in the UI. Note that this is a slightly simplified
 description as all the current palette loaders return a GList* with only
 one entry to a palette object. This code is here.

No, there is no such thing as a Palette object, but not one on the UI yet
in GIMP.
You create  a new palette live, in GIMP.
If you  need it not to appear in the objec, just maintain all palette
data in a data structure
in your own code.
(In python it would be a list of tuples - or a list of dictionaries if you need
better than O(N) access to an entry given its name or it's core value)
And you will need a function call to commit your data structure to
a palette in the UI when it is the time -
That would be about five lines of code, including
the function declaration.

If you want to access a non-UI visible GIMP Palette  in several
plug-ins, and want to use GIMP's palette PDB calls for that,
you have to, in the same plug-in: commit your data to a new, temporary,
GIMP Palette, do whatever you want with it (including exporting for an
specific format by calling another plug-in), and remove it from GIMP's
Palette list with pdb.gimp_palette_delete.

  js
 --



  js
 --
___
gimp-developer-list mailing list
List address:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list

Re: [Gimp-developer] Of Palettes and Plug-ins

[Joao S. O. Bueno]

Hi  -

Yes, the paramerter PF_PALETTE is passed around as a string - but that
string is teh palette name in GIMP-  teh palette is them usable with
all palette -related PDB functions


There is no higher level Palette object on the Python side - and it
makes little sens implementing one with the bindigns as they are now
(it would require writting the pallete functionality in low-level C)

But having the string passed around between plug-ins works as nicely
as it can be - I had written some palette creating/exporting a few
years ago.



On 6 September 2013 14:11, Chris Mohler cr33...@gmail.com wrote:
 On Thu, Sep 5, 2013 at 11:30 PM, Warren Turkal w...@penguintechs.org wrote:
 Just so you all know, this actually started with my wife wanting to import
 *.ase palettes in .

 Same here, but I just wanted to use Kuler palettes.  Adobe claims the
 .ase specs are in the PS SDK, but if they are I never found them.

 That's about as far down the rabbit hole as I got - I didn't feel like
 reverse-engineering the PS palette format.

 Back to your main question: unless I'm out of touch, I believe all of
 the file loader plugins need to be written in C.  I could well be
 wrong though.  It's been quite some time since I touched anything
 having to do with GIMP besides the occasional plug-in in Python.

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

Re: [Gimp-developer] Of Palettes and Plug-ins

[Joao S. O. Bueno]

Besides  - you have to check what makes more sense - I't think Palette
exporting/importing plug-ins have to be on the Palletes context menu

My basic design is going to be as follows:

   - Add a procedure to register a palette loader

There is no such thing as a palette loader - but there are plug-ins that
are registered under thhe Palette context menu. Ther is a sub-menu
named Export as... -
I think a loader should be under palette/Import/title

   This procedure will check that registered procedure take an int32 and
   two strings and return a palette. The args are the same as those for the
   image importer, and the return is a palette instead of an image.
If it is a Python script, maybe you  prefer using PF_FILE instead
of a string - that allows you to programatically pass a  file path,
but the automatic
Python-fu interface would open a nice file dialog to use your plug-in directly.

   - Write a python (or other language) procedure to implement that
   interface.
Python recomended - some of the options in the Pallete context menu
are already in Python, copy one of them and it will be easier for you
to make your own.

And finally -as noted in the other e-mail I sent: the returend
PF_PALETTE is a string, but
a string corresponding to a unique name palette in GIMP, which is used
as ID for all Palette related
PDB calls.

  js
 --


On 6 September 2013 15:24, Jon Nordby jono...@gmail.com wrote:
 On 6 September 2013 19:11, Chris Mohler cr33...@gmail.com wrote:
 On Thu, Sep 5, 2013 at 11:30 PM, Warren Turkal w...@penguintechs.org wrote:
 Just so you all know, this actually started with my wife wanting to import
 *.ase palettes in .


 Back to your main question: unless I'm out of touch, I believe all of
 the file loader plugins need to be written in C.  I could well be
 wrong though.  It's been quite some time since I touched anything
 having to do with GIMP besides the occasional plug-in in Python.

 The OpenRaster file loader/saver (file-ora) is written in Python. It
 does not do any pixel manipulation of its own though.

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

Re: [Gimp-developer] non-destructive editing and adjustment layers

[Joao S. O. Bueno]

On 1 September 2013 05:56,  kcle...@users.sourceforge.net wrote:

 I mean that whenever a plugin is used on an image with the channel
 size larger than the plugin can support, gimp should output a warning
 message about loss of precision.  So I guess would adding a simple
 check like this involve much much less work than the porting of a
 plugin to GEGL?


GEGLIfied Plug-ins have an ostensive G icon next to their menu entries-
if you are taking care not ot use legacy plug-in it is easy not to
pick tehn by mistake.

Also, GEGLfied plug-ins make their preview staright on Canvas, just
like GIMP's itnernal tools -
if you open a plug-in dialog with a built-in preview - or simply no
preview on canvas, there is time
to cancel.

Other than that, there is no automated warning;

  js
 --
___
gimp-developer-list mailing list
List address:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list

Re: [Gimp-developer] Need help with Python on GIMP 2.8 for bug fixing

[Joao S. O. Bueno]

teh _ is a call to be used when your plug-in is written with
multi-lingual support - either
write your plug-in copying the _ related bits from another python
plug-in with localisation, or leave it apart for now - just put on the
beggining files of your plug-in something along:

_ = lambda x: x

This will give you a mockup translating function that will allow you
to focus first on the development, and you can polish it to get i18n
working later on.

  js
 --

On 2 August 2013 16:41, Ofnuts ofn...@laposte.net wrote:
 On 08/02/2013 08:33 PM, b...@neeneenee.de wrote:


 Dear GIMP devs,

 i'm the author of CMYK Tiff 2 PDF which is an addon for GIMP and the
 Seperate+ plugin.
 My script is part of the plugin registry too.

 But it seems it doesn't show up in GIMP 2.8./ Ubuntu.

 I changed the pythin script registration to:

 register(
 python-fu-cmyk-tiff-2-pdf,
 CMYK Tiff 2 PDF,
 CMYK Tiff 2 PDF 20130802\nCreating a CMYK PDF for prepress from a
 CMYK Tiff image.,
 Eckhard M. Jaeger, http://my.opera.com/area42/blog/;,
 GPL V2 License,
 2013,
 *,
 *,
 [
 (PF_FILENAME,this_file1, _(CMYK Tiff Images), ),
 (PF_FILENAME,this_file2, _( ), ),
 (PF_RADIO, this_compress,  _(Compression), 0,
 ((JPEG 95% Quality,0), (Zip Full Quality,2), (No
 Compression,4))),
 (PF_SPINNER,this_dpi, _(Resolution (dpi)), 300,
 (0,2400,50)),
 (PF_TOGGLE,delete_files, _(Delete Images\nafter PDF
 creation), False),
 (PF_TOGGLE,start_viewer, _(Start PDF Viewer\nafter
 export), True),
 ],
 [],
 python_fu_cmyk_tiff_2_pdf,
 domain=(gimp20-python, gimp.locale_directory),
 menu=Image/Image/Separate/
 )
 main()


 But i didn't get it running.

 Any help or idea?

 ___



  File /home/me/.gimp-2.8/plug-ins/testreg.py, line 17, in module

 (PF_FILENAME,this_file1, _(CMYK Tiff Images), ),
 NameError: name '_' is not defined


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

Re: [Gimp-developer] GIMP python (pythonfu) plugin: How to include the PreviewArea from gimpui

[Joao S. O. Bueno]

On 20 July 2013 17:58, Alexandre Prokoudine
alexandre.prokoud...@gmail.com wrote:
 On Sat, Jul 20, 2013 at 9:22 PM, Akkana Peck akk...@shallowsky.com wrote:
 Michael Schroeder writes:
 I am writing a plugin for Gimp. It works alright via the GIMP UI and
 command line by registering it to gimp. But I would wish to offer also a
 Preview area in the UI, and apparently it is not so easy to add the
 PreviewArea from the gimpui python package to the input dialog.

 Since I haven't seen any other responses:

 I don't think there's a way to add a formal preview area in Python.

 AFAIK, that was one of the points of GIMP's GSoC2010 project re
 Python. The one that was never merged.

That part was not complete, anyway.  :-/

But in current GIMP what makes sense is to figure out how to make GEGL
calls from GIMP-Python plug-ins, and create an on-screen preview API
using the GEGL capabilities. And while one is at that, there is the
need port Python-fu from pygtk to gobject introspection as well - I
hacked a bit on it a while ago, and I think it can be done while
keeping backwards compatibility for python-fu scripts.


  js
 --

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

Re: [Gimp-developer] Text Editor Popup/Overlay Dialog

[Joao S. O. Bueno]

On 26 June 2013 13:15, Jake Blank jaketbl...@gmail.com wrote:
 The overlay-ed Text Editor in Gimp 2.8+ is extremely annoying - how can I
 choose a proper font if I can't see my image?! afaik there's no way to
 disable it :/

Indeed - maybe everyone agrees it could be hidden if the user sets the
user editor on the
tool options (to type the text in a pop-window)?

  js
 --


 Please tell me I'm wrong!
 ___
 gimp-developer-list mailing list
 List address:gimp-developer-list@gnome.org
 List membership: https://mail.gnome.org/mailman/listinfo/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