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  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/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 
>
> (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] non-destructive editing and adjustment layers

[Joao S. O. Bueno]

On 1 September 2013 05:56,   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] 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  wrote:
> On Thu, Sep 5, 2013 at 11:30 PM, Warren Turkal  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 /Import/"

   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  wrote:
> On 6 September 2013 19:11, Chris Mohler  wrote:
>> On Thu, Sep 5, 2013 at 11:30 PM, Warren Turkal  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] Of Palettes and Plug-ins

[Joao S. O. Bueno]

On 7 September 2013 03:20, Warren Turkal  wrote:
> On Fri, Sep 6, 2013 at 11:20 AM, Joao S. O. Bueno 
> 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 "", line 1, in 
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  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] API to parse a saved GIMP's curves file

[Joao S. O. Bueno]

otherwise, you could write your plug-in in Python instead of scheme,
and parse these files
in 15-20 lines of code.

On 26 September 2013 11:48, Kevin Cozens  wrote:
> On 13-09-25 05:21 AM, Alessandro Francesconi wrote:
>>
>> I’m developing a plugin that must read the contents of a GIMP “curves”
>> file
>
> [snip]
>>
>> # GIMP curves tool settings
>>
>>
>> (time 0)
>> (channel value)
>> (curve
>> (curve-type smooth)
>> (n-points 17)
>> (points 34 0.00 0.00 -1.00 -1.00 [other X Y
>> points...])
>> (n-samples 256)
>> (samples 256 0.00 0.012218 [other samples...])
>>
>> )
>
>
> Hm... interesting. Someone chose to save the settings in a format that looks
> a bit like Scheme code. Unfortunately it isn't Scheme-like enough that you
> could use the "load" function in a Script-Fu script to load the curve
> settings via a script and use the contents of the file.
>
> The Procedure browser doesn't list any calls for saving or loading curves.
> If others thing it would be a worthwhile addition to the API an enhancement
> request could be find in bugzilla.
>
> --
> Cheers!
>
> Kevin.
>
> http://www.ve3syb.ca/   |"Nerds make the shiny things that distract
> Owner of Elecraft K2 #2172  | the mouth-breathers, and that's why we're
> | powerful!"
> #include  | --Chris Hardwick
>
> ___
> gimp-developer-list mailing list
> List address:gimp-developer-list@gnome.org
> List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
___
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  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] 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  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 
> 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] 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 wrote:

> 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  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 wrote:
>
>> 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] 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  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  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] 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  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  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] Gimp from git Gegl Gaussian Blur and Unsharp Mask useability issues

[Joao S. O. Bueno]

On 4 December 2013 19:50, Teo Mazars  wrote:
>> This Gaussian blur slider range doesn't really allow slider selection
>> of
>> small, precise values less than 1, so typing in values is still
>> necessary. A logarithm-type scale might be better than a linear scale
>> as
>> the useful range for blur necessarily is large, and the larger the
>> image, the larger the useful range.
>
> [...]
>
>> The other gegl_chant_double_ui values are pretty obvious. What does
>> the
>> value "1.5" do?
>
> The "1.5" is the UI exponent you were asking for in Gaussian Blur, 1.0 is 
> linear. If 1.5 is not enough, you may try 2.0 or larger. For the slider step 
> problem, I don't know much about that sorry... I think the new UI values you 
> suggest are good. So please, try some more by tweaking the exponent and you 
> can commit directly to GEGL master those changes, if you want.
>
>>
>> A way to type in values without risking accidentally causing a very
>> large radius operation would be very welcome.
>
> Agreed, I am not sure how to solve that though...
>
>> I wonder what values other people might find useful for Gaussian blur
>> and USM? I have a 10MP camera. Someone with a 30 or 40MP camera
>> probably
>> would need a larger range, which is one reason why user-settable
>> ranges
>> might be a nice feature. Different styles of processing would be
>> another.
>
> I agree too, but this is also an UI problem and I am really not an expert. A 
> reasonable arbitrary UI range + exponent is already a step forward.


What if we can think of a way of hint up values for the UI, but not
constrain the operator values themselves by these values - so that one
could make a 2000-radius gaussian blur, if really needed?
(despite any UI changes themselves to allow suitable ranges depending
on the image size
for certain controls? - (brush radius and gaussian blur come to mind) )



>
> Thank you,
>
> Téo
> ___
> 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] 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  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-user] Why so COMPLICATED?

[Joao S. O. Bueno]

On 27 December 2013 16:22, Sam Gleske  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  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] 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] 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  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] 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  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=.cur&group=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] Enhancement request for .cur cursor files

[Joao S. O. Bueno]

So, here is the list :-)

There is the request, it seens to match the product vision , and I
think it is a valid request.

Anyone ahs some more information on the .cur files (or the .ani) for
taht case that we could throw in the feature request?

On 20 January 2014 14:38, Richard  wrote:
>> Date: Sun, 19 Jan 2014 18:15:17 -0200
>> From: gwid...@mpc.com.br
>> To: scl.gp...@gmail.com
>> CC: gimp-developer-list@gnome.org
>> Subject: Re: [Gimp-developer] Enhancement request for .cur cursor files
>
>>
>> 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?
>>
>
> I've been through this.  A lot of the time the closing post is a request to
> discuss it on the mailing list -before- filing it as a bug report.
>
> -- Stratadrake
> strata_ran...@hotmail.com
> 
> Numbers may not lie, but neither do they tell the whole truth.
___
gimp-developer-list mailing list
List address:gimp-developer-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  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] 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  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] Gimp Programmer Requirement

[Joao S. O. Bueno]

On 27 January 2014 22:24, Sam Gleske  wrote:
> On Mon, Jan 20, 2014 at 12:51 PM, p...@ppg7.com  wrote:
>
>> I have subscribed for access to your mail list for developers although I
>> am not
>> sure that I am accessing the developers correctly. Please forgive me if I
>> have
>> done this incorrectly.
>>
>>
> You're correct.  What you did was incorrect.  This is a developer mailing
> list for developers to coordinate the discussion of further developing
> GIMP.  Your efforts are best directed to a job posting website where you
> can better outline the requirements of workers.  If you're merely looking
> for contract work there are plenty of freelance programmer websites in
> which you could post.
>

I don think it was an "incorrect post" in anyway.
People are free to post here to GIMP development subject, and the probability
of finding someone proeficient with GIMP code interested in doing
whatever he needs here
is much higher than in a generic freelancer site.

Moreover, it can give opportunity for someone involved in GIMP as a
volunteer to
get paid, if not to implement improvements directly in GIMP, at least to get
more aquaintted with different places of the code base.
If a subscriber of this list pick the job, I think the chances of him
contributing back to the project or getting involved are far greater
than someone that would accept the offer in a freelancer site.

Therefore, I think posting here is far better for him and for the
project alike.

  js
 -><-




>
>
>> This message contains confidential information and is intended only for the
>> individual named
>>
>
> I realize you probably send out the stamp with every email however the
> developer mailing list (and all associated GIMP mailing lists) are publicly
> archived conversations.  Confidential information should never be broadcast
> through email in general since it is accepted as being wholly insecure.
>
> In any case, good luck finding someone to assist you with your project
> through other avenues than this mailing list.
>
> SAM
> ___
> gimp-developer-list mailing list
> List address:gimp-developer-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 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  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  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] 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  wrote:
> Hi,
>
> I am warry about to use Publican.
>
> Publican prohibits to use WORD(S) tag
> then allows  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 .  In much cases on our document, we use  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 , 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 
> 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 
>
>
> 2014-02-05, Roman Joost :
>> 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] 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  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 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  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] [GUI] Scrollbars for Script-Fu dialogs

[Joao S. O. Bueno]

I've actually seen "in the wild" a script-fu fork that would add
options for explicitliy creating widget columns.
AFAIK, author of that have never contacted the GIMP developers -
let me google around to try and find it -

Ah, here - someone had actually hacked the Python-fu to allow greater
control of the generated UI:

http://gimpchat.com/viewtopic.php?f=9&t=9378

And as for script-fu,a couple of days ago, someone made a scroolbar
enabled version -
this is such a straightforward workaround for UI's getting larger than
the screen that maybe it
could be considered a bug-fix and go into gimp-2.8:

http://gimpchat.com/viewtopic.php?f=9&t=9824


(disclaimer: I had not tried either, just saw the screenshots)

  js
 -><-

On 2 March 2014 10:07, Crazy Aunt Gail's, LLC  wrote:
> While GnuTux was working on his patch, I was investigating the possibility of 
> a tabbed approached. Here are some of my thoughts on the matter.
>
> A tabbed approach could either be implemented automatically or specified 
> within the script. The first problem posed by an automatic approach is how 
> the table of widgets should be split into multiple tabs. If it is hardcoded 
> as a fixed number of widgets per page then users with large screen displays 
> would
> be penalized by choosing too small a number, whereas too large a number 
> invites
> the same problem we're attempting to solve. Splitting the tabs based
> upon a calculation of the available screen real estate seems to me as running 
> counter to the philosophy
> of letting GTK and the window manager handle such things. Whether
> hard-coded or derived, there are also the problems of whether the
> widgets should be divided evenly amongst the tabs (we probably wouldn't
> want to add a new tab for just one or two widgets) and how to label the
> tabs.
>
>
___
gimp-developer-list mailing list
List address:gimp-developer-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] 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  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

Re: [Gimp-developer] Fwd: Gimp Registry Future

[Joao S. O. Bueno]

Just for the record, I second all of Jehan's concerns -
Although I don't think the "GIMP authenticated server" should be the only
possible way to install managed plug-ins:

Users should be given an option to change the plug-in server to
"unofficial" ones.
They just should be very clearly warned on
doing so that they will be then installing any random binary.
(changing the server does not have to be an easy task).

Even if most people find we should make it difficult-as-in-recompiling to
change
the plug-in·server, maybe the other assets can have less strict rules.


  js
 -><-



On 11 April 2014 05:31, Jehan Pagès  wrote:

> Hi,
>
> On Fri, Apr 11, 2014 at 7:13 PM, Ingo Lütkebohle 
> wrote:
> > Oh, and just to clarify, I also mean that effort for *authors* should be
> > taken into account.
>
> Ok well I understood everything until your "clarification". What
> effort for which authors?
>
> > On Fri, Apr 11, 2014 at 9:11 AM, Ingo Lütkebohle 
> wrote:
> >>
> >> Jehan,
> >>
> >> I wholeheartedly support your concerns, but I would advise trying to
> think
> >> of ways of approaching this in a simpler way. If the registry can
> support
> >> you in that, let me know.
>
> Well some things can be simplified for the first release, like code
> reviews as I said. But some things can't, in my opinion. In
> particular, we absolutely need to secure the plugin provenance (secure
> channel, signing or any other method) and we absolutely can't
> automatically install any binary, with executable rights, generated by
> any random person on the internet.
>
> For me, there could be absolutely no discussion about it. That's about
> respecting our community, but also about responsibility. The risks to
> have malwares are too big, especially for a program as well known,
> hence spread, as GIMP. We all know this. As you said yourself, the
> registry is receiving more and more abuse. That's an open door for
> spam, scam, and much worse. We even have more and more fake GIMP going
> on nowaydays on the web, and even on some app stores (very recently
> there was such a case, and Michael had to ask for the fake app to be
> taken down). We seem to be told on the mailing list of a scam
> involving GIMP every few weeks, and that's without counting all the
> ones we never hear about. So allowing to install any random,
> unreviewed and uncontrolled executable, which can be run under the
> user's rights from our official build? That's like creating a
> backdoor, a big security breach into a user's data and system.
> So no, I don't think there can be much simpler way to this problem.
>
> Note that of course, as a developer, I would first develop a basic
> system without much security for quick feature test. But the finale
> released system must have all the security in place, when dealing with
> such a dangerous feature.
>
> >> Other than that, the whole searching and browsing UI is likely far from
> >> trivial as you suggest.
>
> Yes you are right. I did not mean to imply all the rest was just easy
> stuff (though I mistakenly said so). UI and search algorithm are also
> important and difficult (as always). But I still meant to say that for
> this specific feature, the security should be taken very seriously. It
> just seems to me that your original call (which I saw, has been
> relayed by some websites as gimpusers.com) seems to completely
> overlook this side, which I think is primordial.
>
> Jehan
>
> >> cheers
> >>
> >>
> >>
> >> On Fri, Apr 11, 2014 at 3:08 AM, Jehan Pagès <
> jehan.marmott...@gmail.com>
> >> wrote:
> >>>
> >>> Hi,
> >>>
> >>> On Thu, Apr 10, 2014 at 4:06 PM, scl  wrote:
> >>> > Hi,
> >>> >
> >>> > it's interesting to see what interest such a post can trigger ;-)
> >>> > To be honest, it wasn't me who started the discussion, I just
> forwarded
> >>> > Ingo's call to the mailing list.
> >>> >
> >>> > 'GIMP is easily user-extendable, by ‘one-click’ installation of
> >>> > plug-ins.' is a part of our product-vision and as far as I remember
> >>> > there have already been many ideas on this topic, dating back to
> 2003.
> >>> >
> >>> > For both the registry and GIMP the situation changes:
> >>> > Registry: from some or many users who know and use the registry to
> >>> > potentially every user who can access it conveniently from GIMP.
> These
> >>> > are millions.
> >>> > GIMP: From a standalone application that uses mostly local data to
> >>> > an application with tighter access to an online service.
> >>> >
> >>> > I think before we start losing ourselves prematurely in
> implementation
> >>> > details like programming language and data formats we should clarify
> >>> > the overall picture first:
> >>> > - What are the concrete requirements: functional and nonfunctional
> >>> > requirements,
> >>> > - user interaction,
> >>> > - overall technical architecture and integration into GIMP,
> >>> > - reuse of existing solutions like package managers,
> >>> > - who will also care in future for the registry and the plug-in
> >>> >

[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] About closing feature requests as invalid

[Joao S. O. Bueno]

On 20 April 2014 03:44, scl  wrote:
> Indeed, the definition of 'Invalid' lacks of clarity:
> 'This bug is in some way not valid...'.
> But if we close bugs we will neither fix nor accept patches
> we clearly use the state='CLOSED-WONTFIX'.
> Why would we use 'CLOSED-INVALID' for this?

That distinction might be clear for someone acquainted with
bugzilla and the status we do use - but it certainly won't
be read this way for someone getting to bugzilla.
As I said before, it reads "invalid".

One other thing I did not mention: bugzilla is hard-enough to get through
to a single feature request - it has a  "90s" look and feel, and suffer of poor
usability even for the web of that time. So if after one gets through it all,
we just say it is invalid, we might just get a "nerver mind. At least I tried".

(the hardest part in bugzilla maybe be  picking "GIMP" from other 100s
of projects
in a plain html(2.0) scrolling thingie, not to mention the defaults that can't
actually be seen in the other widgets, until one has clicked (and changed) them)

And them, about adding voting and more niceties to bugzilla:
unfortunatelly we share
bugzilla with gnome, and can't just go about changing it on our own.
So this is another
set of variables and constraints in this discussion.

  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] [FEAT-REQUEST] A way to quickly know layer dimensions in Gimp

[Joao S. O. Bueno]

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

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

Re: [Gimp-developer] About closing feature requests as invalid

[Joao S. O. Bueno]

As  for this detailed intended workflow: it looks like the best of all Worlds,
and is ok for me. Thankyou for all the effort you put on this.

On 21 April 2014 15:24, scl  wrote:
> Hi,
>
>
> On  19.4.2014 at 6:29 PM Joao S. O. Bueno wrote:
>>
>> 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,
>
>
> I think 'Unconfirmed' is exactly the state we can use here:
> the request is yet to be confirmed - in this case to find out
> whether there is a real need for it. 'Unconfirmed' also is
> not offending.
>
> From the three alternatives Bugzilla, IRC and mailing list a
> mailing list has the best visibility to the target audience
> and should in my opinion be preferred.
> Currently we use the GIMP developer mailing list but our users
> are likely not there, but rather on the GIMP users mailing list.
> At the end we write software for users and it's good practice
> in open source to listen to the users. On the other hand the
> developers are on the GIMP users list, too, so we catch them all.
> Therefore I'm for discussing new features on the GIMP users
> mailing list.
>
> Another point are feature requests that arrive at Peter's GUI
> brainstorm. I find the GUI brainstorm's intention a great idea that
> should be kept alive. In my opinion it could also be used to collect UI
> ideas for later features, but it should not be misunderstood as a
> letter box for feature requests.
>
> My proposal to handle feature requests:
>
> 1)
> a) A request is made in Bugzilla.
> If it is a duplicate: RESOLVED DUPLICATE.
> If it is a troll request, like to bring back the 2.6 save behaviour:
> RESOLVED-WONTFIX or RESOLVED-INVALID.
> If it is a valid feature request: UNCONFIRMED, forward discussion to
> the GIMP users mailing list. We set Platform:=all, Importance:=enhancement.
> If it is unclear whether it is a bug report or feature request:
> forward discussion to the GIMP users mailing listto clarify its
> character there.
>
> We reply in timely manner with a friendly stock answer. This is not
> meant to fob somebody off like an arrogant company but to ease our own
> work. Who likes to use own words is free to do so.
>
> b) A request is made to the GUI brainstorm:
> If it is a valid request, then Peter replies shortly and forwards the
> request to the mailing list. In the meantime the idea gets the tag 'New
> feature' on the brainstorm blog and can be referred from the mailing
> list post to clarify the idea.
>
> c) A request is made on a third party website, like Stackoverflow
> or a forum.
> If it is a valid request, then the present GIMP team member replies
> shortly and forwards the request to the mailing list.
>
> 2) The topic will be discussed on the GIMP users mailing list.
> Yet we should find a default action when no discussion comes up.
> Does it mean 'Yes' or 'No'?
>
> 3) When the discussion has finished we take the result in a timely
> manner to Bugzilla.
> If the request is accepted, then it goes into state 'NEW' and we
> add a short summary, links to the ML discussion and the UI brainstorm.
> If the request is rejected, we close the bug with WONTFIX.
> In both cases we add the Bugzilla link to the mailing list thread
> for future investigations.
>
> How do you people think about it?
>
> Joao, you mentioned some open requests on the mailing list
> that haven't made it into Bugzilla yet. Do you have them at
> hand so we can bring them to Bugzilla now?

No, not at hand - when I mentioned I was thinking of my thread on
"set of operations", which Peter described as a way to do "Macros",
I sentto the list 2-3 weeks prior to the LGM
(pause to search reference on the list archives - found:

http://blog.gmane.org/gmane.comp.video.gimp.devel/day=20140315)


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

[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  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] Big problem with Gimp G'MIC with upcoming Gimp 2.10

[Joao S. O. Bueno]

And of course, becoming incompatible with C++ all of a sudden, if it
builds today, would be a serious bug - so
don't be afraid that would happen for free like that. And please,
complain otherwise.

On 26 April 2014 04:39, Thorsten Stettin  wrote:
> Am 26.04.2014 04:29, schrieb Michael Henning:
>
>> This was just fixed a day or two ago on gimp master. If you pull and
>> rebuild gimp, you should be fine.
>>
>> https://git.gnome.org/browse/gimp/commit/?id=c808789e1df880046273c9de0a8e61b1b232ebd3
>
> Great work. Thanks
>
>>
>> But, thanks for the report!
>>
>> 2014-04-25 19:24 GMT-04:00 Thorsten Stettin :
>>>
>>> Hi, folks,
>>>
>>> I have a big problem. The Gimp G'MIC code is written in C++. The problem
>>> is
>>> the variable name "private". It is a C++ keyword.
>>> E.g:
>>> *
>>> struct _GimpColorProfileView**
>>> **{**
>>> **  GtkTextView  parent_instance;**
>>> **
>>> **  GimpColorProfileViewPrivate *private;**
>>> **};**
>>> *
>>> In file /usr/include/gimp-2.0/libgimpwidgets/gimpcolorprofileview.h
>>> Please avoid using C++ keywords in C code. Could you change it?
>>>
>>> Thanks in advance
>>>
>>> Thorsten
>>>
>>> --
>>> Lao-Tse sagt: Nichtstun ist besser, als mit viel Mühe nichts zu schaffen.
>>> Und er sagt auch: Ich habe drei Schätze, die ich hüte und hege. Der eine
>>> ist
>>> die Liebe, der zweite ist die Genügsamkeit, der dritte ist die Demut. Nur
>>> der Liebende ist mutig, nur der Genügsame ist großzügig, nur der Demütige
>>> ist fähig zu herrschen.
>>>
>>> ___
>>> gimp-developer-list mailing list
>>> List address:gimp-developer-list@gnome.org
>>> List membership:
>>> https://mail.gnome.org/mailman/listinfo/gimp-developer-list
>>> List archives:   https://mail.gnome.org/archives/gimp-developer-list
>
>
>
> --
> Lao-Tse sagt: Nichtstun ist besser, als mit viel Mühe nichts zu schaffen.
> Und er sagt auch: Ich habe drei Schätze, die ich hüte und hege. Der eine ist
> die Liebe, der zweite ist die Genügsamkeit, der dritte ist die Demut. Nur
> der Liebende ist mutig, nur der Genügsame ist großzügig, nur der Demütige
> ist fähig zu herrschen.
>
>
> ___
> gimp-developer-list mailing list
> List address:gimp-developer-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  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

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

[Joao S. O. Bueno]

Bringing this topic back, since I think it matters - and more people
could be dealing with this than striclty fidling at the core;


On 9 February 2014 16:55, 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?
>


we could start talking more about evolving the format.

I pǘe been talking with some heavy users (for professional use, even) -
and one thing they miss is more consistency on asst handling
(you can rename a palette or a gradient inline in the gradient list
dialog, but not a pattern or a brush, for example).

> Alexandre
> ___
___
gimp-developer-list mailing list
List address:gimp-developer-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  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] How to call gimp_export_image() from Python plugin

[Joao S. O. Bueno]

On 18 June 2014 07:43, Vladimir Rutsky  wrote:
> On Wed, Jun 18, 2014 at 7:32 AM, Joao S. O. Bueno  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  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 .  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  wrote:
>>
>> On 18 June 2014 07:43, Vladimir Rutsky  wrote:
>>>
>>> On Wed, Jun 18, 2014 at 7:32 AM, Joao S. O. Bueno 
>>> 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
&

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  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]
> 
 image.layers[0].layers[0].parent # should return the same layer as above 
 but gives
> 
>
> 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 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 .  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  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  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 .  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  wrote:
> yes - this is a bug - and it can be open in the bugtracker.
>
> On 18 June 2014 22:41, Seldom Needy  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]
>> 
>>>>> image.layers[0].layers[0].parent # should return the same layer as above 
>>>>> but gives
>> 
>>
>> 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] Python-fu GIMP Layer "parent" property error

[Joao S. O. Bueno]

On 20 June 2014 04:08, Ofnuts  wrote:
> On 20/06/14 03:38, Joao S. O. Bueno wrote:
>>
>> Issue fixed in master and 2.8 branch.  (It will be generally
>> available as of gimp 2.8.12)
>>
>> Thanks for spotting that.
>
>
> While we are at it, it there an explanation why there are both "layers" and
> "children" attributes in a gimp.GroupLayer, that return essentially the same
> thing but with a different class;
>
>>>> image=gimp.image_list()[0]
>>>> g=image.layers[0]
>>>> print g
> 
>>>> g.children
> [, ]
>>>> g.layers
> [, ]
>>>>
>
> In practice, the "children" method is a bit of  a pain when you walk the
> tree, because the image has "layers" but no "children".
>
> But a gimp.Layer has "children" but no "layers"...
>
> All this is highly confusing... with a single "layers" attribute that always
> returns a GroupLayer when possible things would be simpler IMHO.

Hi -
All drawables descend from GIMP Item - which has the "children" property.
The GroupLayer class inheritance order, in pygimp is thus:
GroupLayer<-Layer<-Drawable<-Item

The GroupLayer explicitly implements the "layers" attribute, as in a
GIMP Image -
that is my fault, when I implemented that. I was so used to iterating
over an image
"layers" that not even thought otherwise when implementing GroupLayers
on the Python side.

Anyway, with this specific bug fix, both methods are returning the
same. That is:
"children" and "layers" are aliases on the Python side - the
difference being that plain
"Layer" objects do not have a "layers" property, but all of them have
a "children" property
(which returns an empty list in this case).

  js
 -><-


In gimp 2.8,  Items where refactored to be able to be containers, and do have
the "children" method. Pygimp mimics that, even though no other kind of
item, currently, is a container.

> ___
> gimp-developer-list mailing list
> List address:gimp-developer-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  wrote:
> On 19 June 2014 20:38, Ed .  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 so

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

[Joao S. O. Bueno]

> What is GIO?

It stands for "Gobject Introspection O"

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  wrote:
> On 20.06.2014 04:42, Joao S. O. Bueno wrote:
>>
>> On 19 June 2014 20:38, Ed .  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 functi

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

[Joao S. O. Bueno]

On 21 June 2014 18:02, Ed .  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 O"
>
> 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  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

Re: [Gimp-developer] Blend Tool UI

[Joao S. O. Bueno]

On 25 June 2014 01:59, Michael Henning  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, Filters>Render 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  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. ) 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 m

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  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] User of Software

[Joao S. O. Bueno]

On 14 July 2014 07:15, Lythgoe Sharon  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
> IM&T Training Manager
>
> IT Training Department
>
>
>
> t.  01942 82 2020
>
> e.   sharon.l.lyth...@wwl.nhs.uk 
>
> w.   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
>
>
>
>      
>
>
>
>
> ___
> gimp-developer-list mailing list
> List address:gimp-developer-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 
Date: 13 August 2014 23:30
Subject: [Gimp-developer] ANNOUNCE: GIMP User Manual 2.8.2 released
To: GIMP Docs , Gimp Developer
, GIMP User 


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] 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  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] Query about Brushes and names

[Joao S. O. Bueno]

On 10 September 2014 08:09, Andrew Francis  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] 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  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] 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  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-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
 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
>>  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] 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  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] Drop shadow - a question from an user - developer-version 2.9

[Joao S. O. Bueno]

On 9 February 2015 at 09:15, Alexandre Prokoudine
 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] 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
 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] 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 _  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]

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

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

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 _  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  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  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 ma

Re: [Gimp-developer] Question about Neon Edge Detection Feature

[Joao S. O. Bueno]

Hello David --

Thank you for your compliment and sharing your work - but
these lists do not accept e-mail attachments - they are automatically removed.

You will have to find a web page and upload your work there, and share
the links.

You might also be interested in sending the links to gimp-users list,
so as to reach
a broader audience.


As for the filters: They are pure mathematical  operations, and are
actually simple in nature.
They are specific kernel convolution operators (at least most of them
- maybe one or other of
GIMP's algorithms include some other step, like coloring up the results).

You can read more about this type of operation here:
http://en.wikipedia.org/wiki/Kernel_(image_processing)

And most importantly - you can try different custom convolutions in GIMP using
the generic convolution filter you can find at
"Filters->Generic>Convolution Matrix"

Regards,

  js


On 2 March 2015 at 14:22, Rosenthal, David  wrote:
> Hi, I have been using GIMP for about 5 years and love working with it.
> Thank you to all who have made this wonderful tool possible.
> I use the edge detection filter a lot on cloud formations. Sometimes I get
> results so fantastic, I wonder if there is any 'intelligence' coded into
> the filter to create meaningful forms out of random data, or , is it really
> finding something that we can't see. I enclose a couple of particularly
> apocalyptic results.
> I've tested many combinations , including applying equalization, levels,
> invert etc but the best results are a simple NEON edge filter with settings
> of 9/.3.
> I am attaching the original photos and their 'neoned' results (using the
> Spencer Kimball plugin - which gives simiar results to directly running the
> Neon Edge Filter in GIMP 2.8). I reduced the size to make the overall email
> smaller. (All photo's by the way are unretouched, including ...1846 which
> seems to show a few weird things in the original photo: person  sitting on
> cloud reading a book at about 3 o'clock along with something billowing out
> clouds.)
> Is it just me that gets these apocalyptic images ? (not just from clouds
> too!)
> I would be interested in any comments you may have on this Is question.
> Thank you very much.
>
> *- david *
>
>
>
>
>
> *Regards,David Rosenthal*
> ___
> gimp-developer-list mailing list
> List address:gimp-developer-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  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 Image>Duplicate. 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] Cage Transform Tool's transformations

[Joao S. O. Bueno]

On 17 March 2015 at 18:20, Elle Stone  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] 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  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  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] 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  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] Gimp in private schools and educational institutions

[Joao S. O. Bueno]

On 15 April 2015 at 05:40, Simon Budig  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] 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  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 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  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
> __

Re: [Gimp-developer] Sourceforge downloads

[Joao S. O. Bueno]

On 26 May 2015 at 12:08, Jernej Simončič  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] Sourceforge downloads

[Joao S. O. Bueno]

On 27 May 2015 at 09:49, Jehan Pagès  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] rollApp GIMP usage

[Joao S. O. Bueno]

On 27 May 2015 at 09:00, Boudewijn Rempt  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] 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] 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] 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

[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] 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

Re: [Gimp-developer] Gitlab as a replacement for registry.gimp.org

[Joao S. O. Bueno]

An asset manager is undoubtedly  something  needed very badly -

There are some features that would be needed - which Jehan summarized quite
well in an e-mail sent about 2 years ago (I remember the date because I was just
back from Leipzig)

At first, I think requiring all assets to be in a git repository (git
uses URLs - no need
to require a specific provider) - would itself be overkill. So maybe,
just make content
'uploadable" might be enough. On the other hand, gitlab might provide
ownership and content meta-information in a way we would not need to
care about them -
just a system for one to enter a git (gitlab) URL and branch name - maybe
requiring certain information to be in the repository.

Curation of assets remains one of the hardest points - it might be a
_lot_ of _boring_ work -
and even somewhat dangerous - but still, I can imagine 2 categories of assets -
one endorsed by the "GIMP team" - - i.e. curated - with no dangerous
scripts/plug-ins,
and a "watch yourself"   mode in which anything could be downloadable.


Either way- wathever is designed to register GIMO assets server side,
a Python program can be made, to
run as a GIMP plug-in, that would provide a search, download and
install interface for things
registered on the server side. This program is not a huge thing to do
and would effectively provide GIMP
with its own "asset-store".

Anyway - just to get the ball rolling -
I suppose this could be a topic with its own BoF session in London

On 1 April 2016 at 17:32, Pat David  wrote:
> Continuing on some discussions from irc...
>
> Registry.gimp.org is down for the count.
>
> I was thinking recently about some ideas for a possible replacement.
> Mostly thinking along the lines of what made the registry work well for
> folks.
>
> In the rest of this email, I'll use the term "asset(s)" to refer to things
> like plug-ins, scripts, or brushes/gradients/curves/other assets.
>
> Some essential functionality based on the old registry drupal instance:
>
> 1. Upload/Download assets for GIMP.
> 2. Describe the asset (usually by the uploader).
> 3. Comment on the assets.
>
> This was handled previously by using drupal, which treated each entry as a
> post/node that included the ability to upload files, write about the files
> as a post, and had comment threads below it.
>
> Keeping this functionality would be good, I think.  The ability to post an
> asset is a given, but the ability to interact around it helps foster the
> community (and provides nice feedback for the authors).
>
> From those thoughts, what would be nice to have in a replacement:
>
> 1. Provide at least the same previous functionality (as listed above).
> 2. Managed or easier to manage and keep updated.
> 3. Easier account management.
> 4. Collaborative environment for shared assets
> 5. Support possible GIMP integration in the future (one-click asset
> install?).
>
>
>
> GitLab?
> ==
>
> Initially, I had thought Github might be a good option for this but given
> its closed-source nature decided to investigate something like GitLab
> instead.
>
> I like this idea personally due to some nice infrastructure:
>
> 1. The service is hosted + managed (and available as Free Software just in
> case we felt we needed to break out and host it ourselves).
> 2. The service integrates OAuth sign-in using a few different account types
> (lowers barrier to entry to participate).
> a. they use accounts, Google, Twitter, Github, or bitbucket accounts
> for sign-in.
> 3. Projects maintain all the git-goodness for control and tracking
> 4. Projects created as a git project can have a full description/README
> along with issue tracking integrated in the site
>
> So, we can fulfill the original registry functionality and get the added
> benefit of a git infrastructure for those wanting to contribute, user
> accounts using OAuth to make it easy to participate, and the ability to do
> some interesting things (git submodules).
>
> In speaking with Jehan about this, we should also consider what might be
> needed to support the ability to install assets from within GIMP in the
> future easily.
>
>
> Organization
> =
>
> Jehan suggested that each script/plugin/asset have it's own git repo.
> This would be handy, particularly if script authors did this as well (as it
> considerably eases the inclusion of external repos as submodules).
> However, akk points out that many folks don't (won't?) organize their repos
> in this way (it gets a little... unwieldy pretty quickly if you have many
> scripts).
>
> I'd like some input on what would make the most sense or work best for
> possible organization of repos.
>
> I was also thinking that we could include some simple metadata in both any
> script files and the README.md files as a means to possibly help parsing
> relevant information for automated inclusion at a later date (GIMP plug-ins
> installer type of idea).
>
>
> Curation
> ==
>
> Initially I was thinking that curating the scripts for inclusi

Re: [Gimp-developer] [Gimp-web] Gitlab as a replacement for registry.gimp.org

[Joao S. O. Bueno]

On 1 April 2016 at 18:14, Kasim Ahmic  wrote:
> I personally am a huge supporter of redoing the registry, and I like the 
> ideas you've proposed here. My only concern is one that was actually brought 
> up by someone else a few months ago; registry integration within GIMP and the 
> possibility of viruses.
>
> I don't quite remember who mentioned it, but they brought up that registry 
> integration within GIMP itself could potentially open the doors to viruses 
> unless a virus detection feature was built into GIMP as well. Now, I'm not 
> entirely sure how true this is but I would like to hear a final say on this 
> whether this is an actual issue or not.
>
> If it is an issue, what would be the best way to handle it? I'd imagine that 
> building virus scanning within GIMP would take quite a long time and be 
> pretty impractical. As such, I would suggest that we go with a self hosted 
> solution so that we could incorporate a virus scanner on there to scan all 
> the uploaded assets. Either that, or a hosted solution like GitLab that come 
> with a virus scanning option along with it.
>
> Again, not sure how much of an issue this even is. Just a thought.

So - this would be one of the main  purposes of a "curation" -
Only non-malicious assets would be made available as "safe" from the
server-side.
Having security features on the client side (i.e. on the computer of
the person running GIMP), is
not feasible: one single line of code in a rogue plug-in can wipe the
user harddrive.
. Assuring assets are safe, even if few, and can't be maliciously
modified, in the repository is hard enough -
but can be done.

The hard-to-balance thing is allowing publication of assets by a large
amount of people, and having process/volunteers
to ensure these assets are safe. Either way, I think the download and
install should be done with a few clicks from wthin GIMP itself -
we don't have to burden users to locate the file in a browser,
download it, copy it to the right folder, set its file properties
if that is not needed. If the assets represent a danger, they will
represent an equal danger in this "manual way".


>
>  - Kasim Ahmić
>
> Sent from my iPhone
>
>> On Apr 1, 2016, at 4:32 PM, Pat David  wrote:
>>
>> Continuing on some discussions from irc...
>>
>> Registry.gimp.org is down for the count.
>>
>> I was thinking recently about some ideas for a possible replacement.
>> Mostly thinking along the lines of what made the registry work well for
>> folks.
>>
>> In the rest of this email, I'll use the term "asset(s)" to refer to things
>> like plug-ins, scripts, or brushes/gradients/curves/other assets.
>>
>> Some essential functionality based on the old registry drupal instance:
>>
>> 1. Upload/Download assets for GIMP.
>> 2. Describe the asset (usually by the uploader).
>> 3. Comment on the assets.
>>
>> This was handled previously by using drupal, which treated each entry as a
>> post/node that included the ability to upload files, write about the files
>> as a post, and had comment threads below it.
>>
>> Keeping this functionality would be good, I think.  The ability to post an
>> asset is a given, but the ability to interact around it helps foster the
>> community (and provides nice feedback for the authors).
>>
>> From those thoughts, what would be nice to have in a replacement:
>>
>> 1. Provide at least the same previous functionality (as listed above).
>> 2. Managed or easier to manage and keep updated.
>> 3. Easier account management.
>> 4. Collaborative environment for shared assets
>> 5. Support possible GIMP integration in the future (one-click asset
>> install?).
>>
>>
>>
>> GitLab?
>> ==
>>
>> Initially, I had thought Github might be a good option for this but given
>> its closed-source nature decided to investigate something like GitLab
>> instead.
>>
>> I like this idea personally due to some nice infrastructure:
>>
>> 1. The service is hosted + managed (and available as Free Software just in
>> case we felt we needed to break out and host it ourselves).
>> 2. The service integrates OAuth sign-in using a few different account types
>> (lowers barrier to entry to participate).
>>a. they use accounts, Google, Twitter, Github, or bitbucket accounts
>> for sign-in.
>> 3. Projects maintain all the git-goodness for control and tracking
>> 4. Projects created as a git project can have a full description/README
>> along with issue tracking integrated in the site
>>
>> So, we can fulfill the original registry functionality and get the added
>> benefit of a git infrastructure for those wanting to contribute, user
>> accounts using OAuth to make it easy to participate, and the ability to do
>> some interesting things (git submodules).
>>
>> In speaking with Jehan about this, we should also consider what might be
>> needed to support the ability to install assets from within GIMP in the
>> future easily.
>>
>>
>> Organization
>> =
>>
>> Jehan suggested that each script/plugin/asset have it's own git 

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