(no subject)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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 <gwidion@xxxxxxxxx> wrote:
> On 19 June 2014 20:38, Ed . <ej_zg@xxxxxxxxxxx> 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:  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@xxxxxxxxx
>> 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@xxxxxxxxx
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list




[Index of Archives]     [Video For Linux]     [Photo]     [Yosemite News]     [gtk]     [GIMP for Windows]     [KDE]     [GEGL]     [Gimp's Home]     [Gimp on GUI]     [Gimp on Windows]     [Steve's Art]

  Powered by Linux