OpenRaster Python Plugin
Thanks to developers Martin Renold and Jon Nordby who generously agreed to relicense the OpenRaster plugin under the Internet Software Consortium (ISC) license (it is a permissive license, it is the license preferred by the OpenBSD project, and also the license used by brushlib from MyPaint). Hopefully other applications will be encouraged to take another look at implementing OpenRaster.
[Edit: The code might possibly also be useful to anyone interested in writing a plugin for other file formats that use ZIP containers or XML. For example XML Paper Specification (XPS) JavaFX (.fxz and the unzipped .fxd), or even OpenDocument]
The code has been tidied to conform to the PEP8 style guide, with only 4 warnings remaining, and they are all concerning long lines of more than 80 characters (E501).
The OpenRaster files are also far tidier. For some bizarre reason the Python developers choose to make things ugly by default, and neglected to include any line breaks in the XML. Thanks to Fredrik Lundh and Effbot.org for the very helpful pretty-printing code. The code has also been changed so that many optional tags are included if and only if they are needed, so if you ever do need to read the raw XML it should be a lot easier.
There isn't much for normal users unfortunately. The currently selected layer is marked in the OpenRaster file, and also if a layer is edit locked. If you are sending files to MyPaint it will correctly select the active layer, and recognize which layers were locked. (No import back yet though.) Unfortunately edit locking (or "Lock pixels") does require version 2.8 so if there is anyone out there stuck on version 2.6 or earlier I'd be interested to learn more, and I will try to adjust the code if I get any feedback. [Edit: No feedback but I fixed it anyway, to keep the plugin compatible with version 2.6.]
I've a few other changes that are almost ready but I'm concerned about compatibility and maintainability so I'm going to take a bit more time before releasing those changes.
The latest code is available from the OpenRaster plugin gitorious project page. [Edit: ... but only until May 2015.]
[Edit: The code might possibly also be useful to anyone interested in writing a plugin for other file formats that use ZIP containers or XML. For example XML Paper Specification (XPS) JavaFX (.fxz and the unzipped .fxd), or even OpenDocument]
The code has been tidied to conform to the PEP8 style guide, with only 4 warnings remaining, and they are all concerning long lines of more than 80 characters (E501).
The OpenRaster files are also far tidier. For some bizarre reason the Python developers choose to make things ugly by default, and neglected to include any line breaks in the XML. Thanks to Fredrik Lundh and Effbot.org for the very helpful pretty-printing code. The code has also been changed so that many optional tags are included if and only if they are needed, so if you ever do need to read the raw XML it should be a lot easier.
There isn't much for normal users unfortunately. The currently selected layer is marked in the OpenRaster file, and also if a layer is edit locked. If you are sending files to MyPaint it will correctly select the active layer, and recognize which layers were locked. (No import back yet though.) Unfortunately edit locking (or "Lock pixels") does require version 2.8 so if there is anyone out there stuck on version 2.6 or earlier I'd be interested to learn more, and I will try to adjust the code if I get any feedback. [Edit: No feedback but I fixed it anyway, to keep the plugin compatible with version 2.6.]
I've a few other changes that are almost ready but I'm concerned about compatibility and maintainability so I'm going to take a bit more time before releasing those changes.
The latest code is available from the OpenRaster plugin gitorious project page. [Edit: ... but only until May 2015.]
Been watching your work on the ORA plugin for a while, but I'm damned if I knew why you don't submit your changes to the upstream GIMP project. Any clues? :)
Alex
Promoting the OpenRaster standard
I want users to benefit as soon as possible, not merely wait for the next release to eventually trickle down to their distribution.
Re: Promoting the OpenRaster standard
Edited at 2015-04-04 03:42 am (UTC)
Re: Promoting the OpenRaster standard
There is no guarantee they will accept the changes. Even if they do it could take long time before that happens. I am not convinced negotiating with the project would be a good use of my time.
I find myself agreeing with a lot of what Bryce Byfield wrote in his article about why he does not file bug reports.
Submitting code and having it rejected or worse bit-rot is even more disheartening.