> What is GIO? It stands for "Gobject Introspection O<forgot>" It is a framework to,in a more or less automated form, expose C functions and gobject based classes to various languages - including Python. The Python bindings for gtk+3.0 , ofr example, are GIO based - in this way, one does not have to re-especify every function or class one wants to expose to other languages in a manually written C (or other configuration) file. Pygimp today has C modules which have to create Python objects that mimic GIMP objects, and all manipulations of these objects are wrapped by methods exposed to Python which in turn call one of the libgimp functions. With GIO, all libgimp functions could be called directly, and what we would need is an order of magnitude simpler implementation of the objects, directly in Python. I am working on such a layer for GEGL, for example - http://github.com/jsbueno/python-gegl js -><- On 20 June 2014 19:13, Vladimir Rutsky <rutsky.vladimir@xxxxxxxxx> wrote: > On 20.06.2014 04:42, Joao S. O. Bueno 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? > > > 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: 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
