This is an extension containing a few demo plug-ins. This is good to
demonstrate the extension format. It will also allow to disable these
plug-ins (if at some point, one doesn't want to show these demo
plug-ins anymore).
And finally it deals with the fact that our plug-in code is stupid, as
it just tries to find the first executable with the same name (minus
extension) as the plug-in folder. This doesn't go well on Windows, where
the permission system is non-existent. So our code just ends up trying
to run the first file with a similar name in a plug-in folder. As the C
goat-exercise contains both an exe and the C source (and the system
probably returns files in alphabetic order), GIMP under Windows tries to
run the C source instead of the executable (this obviously doesn't go
well).
We could try to do more complex logics, like not aborting if the first
file run fails and try the next one in the plug-in folder. Or maybe just
rename the C file to another name. But any of these is just in the end
the proof that our plug-in discovery right now is just bogus. The
extension system is explicit, not based on randomly trying out files.
Plug-ins entry points are explicitly listed in the metadata manifest.
It's done, all Python plug-ins have been either ported to the new API +
Python 3, or they have been discarded (and moved to gimp-data-extras for
whoever wants to salvage them).
Let's get rid of the outdated pygimp directory (whose code has not been
built in the master branch for years now anyway)! Woohoo!
We will fill this up with more examples of plug-ins in other languages.
Also we will improve a bit the examples to redirect people to source
code so that they understand what these plug-ins are.
Localization still doesn't work, but this is normal (po-python is not
installed). I will later make the proper tests for this.
Other than this, it is a pretty simple port. It lost all particularities
and facilities of pygimp, but the fact that it now works similarly to
the C API is quite nice too.
It still uses the legacy API for plug-ins though and will have to be
ported further when the new API will be stable.
Also I still haven't figured out why we need to return the number of
returned values. With the proper annotations, an array length parameter
disappears in introspected Python (because it is useless as Python lists
know their length). But it would seem that this annotation doesn't work
the same for returned values, which is a bit sad as it creates ugly
redundancy.
It can be noted that I an going to move all Python plug-ins from
plug-ins/pygimp/plug-ins/ to plug-ins/python/. The whole pygimp/
subdirectory will actually be deleted eventually (I keep it around for
now as reference) as Python plug-in should not need to be considered
particularly from now on. They can just be considered as generic
executables.
so file-tiff-load and file-tiff-save are always built. Also move them
to their own folder plug-ins/file-tiff/ because they will soon share
some common GIO code.
and build file-uri unconditionally, always using GIO. Use more GFiles
instead of URIs in the plug-in in preparation of moving its
functionality to the core.
Don't check for it as if it were optional, and error out further down
in configure.ac. Instead error out immediately and remove all other
checks and Makefile hacks.
Based on original patches from Hartmut Kuhse and modified
by Michael Natterer. Changes include:
- remove libexif dependency and add a hard dependency on gexiv2
- typedef GExiv2Metadata to GimpMetadata to avoid having to
include gexiv2 globally
- add basic GimpMetadata handling functions to libgimpbase
- add image and image file specific metadata functions to libgimp,
including the exif orientation image rotate dialog
- port plug-ins to use the new APIs
- port file-tiff-save's UI to GtkBuilder
- add new plug-in "metadata" to view the image's metadata
- keep metadata around as GimpImage member in the core
- update the image's metadata on image size, resolution and precision
changes
- obsolete the old metadata parasites
- migrate the old parasites to new GimpMetadata object on XCF load
This is a basic implementation of an OpenEXR loader. This
"infrastructure" is required for any further work. It consists of:
* The build system changes.
* A C wrapper around the OpenEXR library, which is necessary as it's not
possible to intermix GIMP's code with C++ code.
* A basic image loader. Chroma is not supported currently, and some
other weird files like multi-view files are unsupported. These can be
added when necessary. There is no UI, but it should be straightforward
to add new features like this on top of this work.
It will never hold high bit depths using JPEG compression, and nobody
is going to port it to layer groups and whatever either. Wolfgang
says it's obsolete, whoever needs to convert old files can use 2.8.
To give us experience with Glade + GtkBuilder, use it for the save
dialog in the PNG plug-in. The layout is as good as
identical. Mnemonics still works and strings are still translated.
2008-10-09 Sven Neumann <sven@gimp.org>
Bug 555697 – build fails if configured with --without-libjpeg
* plug-ins/Makefile.am: applied patch from Simon Zilliken that
disables the build of the PSD plug-in if JPEG support is
disabled.
svn path=/trunk/; revision=27196
2008-08-11 Michael Natterer <mitch@gimp.org>
* plug-ins/bmp/*
* plug-ins/faxg3/*
* plug-ins/fits/*
* plug-ins/fli/*
* plug-ins/ico/*
* plug-ins/jpeg/*
* plug-ins/psd/*
* plug-ins/sgi/*
* plug-ins/uri/*
* plug-ins/xjt/*: removed these...
* plug-ins/file-bmp/*
* plug-ins/file-faxg3/*
* plug-ins/file-fits/*
* plug-ins/file-fli/*
* plug-ins/file-ico/*
* plug-ins/file-jpeg/*
* plug-ins/file-psd/*
* plug-ins/file-sgi/*
* plug-ins/file-uri/*
* plug-ins/file-xjt/*: and moved them here. Changed executable
names to "file-foo".
* plug-ins/Makefile.am: changed accordingly.
* plug-ins/common/*: rename all file plug-ins to file-foo.c. Get
rid of the names "poppler" and "postscript" and call them
"file-pdf" and "file-ps" because the conflict with standard
autofoo targets is gone.
* plug-ins/common/plugin-defs.pl: changed accordingly.
* plug-ins/common/mkgen.pl: make sure cflags variables are named
"PLUG_IN_NAME_CFLAGS" and not "PLUG-IN-NAME_CFLAGS"
* plug-ins/common/Makefile.am: regenerated.
* configure.in: change folders and variable names to match above
changes.
svn path=/trunk/; revision=26494
2008-03-24 Michael Natterer <mitch@gimp.org>
The icon plugin should simply be "ico" just as the other file
plug-ins.
* plug-ins/win-icon -> ico
* configure.in
* plug-ins/Makefile.am: changed accordingly.
svn path=/trunk/; revision=25200
2008-03-24 Michael Natterer <mitch@gimp.org>
There is no colormap involved in this plug-in, rename it again...
* plug-ins/colormap-rotate -> color-rotate.
* configure.in
* plug-ins/Makefile.am: changed accordingly.
svn path=/trunk/; revision=25198
2007-12-20 Sven Neumann <sven@gimp.org>
* configure.in
* plug-ins/Makefile.am
* plug-ins/psd: added new PSD load plug-in written by John Marshall.
This plug-in adds a couple of features. See bug #448181 for details.
* plug-ins/common/Makefile.am
* plug-ins/common/plugin-defs.pl
* plug-ins/common/psd-load.c: removed old psd-load plug-in.
svn path=/trunk/; revision=24408
2006-12-02 Mukund Sivaraman <muks@mukund.org>
* configure.in: dropped the required libcurl version to 7.15.1
* plug-ins/Makefile.am: made uri build on win32 if libcurl is
detected
2006-10-16 Sven Neumann <sven@gimp.org>
* plug-ins/winicon/Makefile.am
* plug-ins/winicon/icodialog.c
* plug-ins/winicon/icoload.c
* plug-ins/winicon/icosave.c
* plug-ins/winicon/main.h: applied patch from Aurimas Juška that
adds support for the loading and saving Vista 256x256 PNG
Compressed Icons (bug #352899).
* configure.in
* plug-ins/Makefile.am: don't build the winicon plug-in if PNG
support has been explicitely disabled.
Jehan