AlanHorkan is currently certified at Master level.

Name: Alan Horkan
Member since: 2002-09-14 15:39:05
Last Login: 2011-07-18 01:29:52

FOAF RDF Share This

Homepage: http://advogato.org/person/AlanHorkan/

Notes:

Code may not be my main contribution to Open Source but I make myself useful with a little bit of everything (usability, bugfinding, general helpful encouragement).
Alan particularly likes cross platform software like AbiWord, Mozilla, OpenOffice, and projects like Inkscape, Dia> and the GNU Image Manipulation Program.

Alan is moderator of the Gnome Usability Mailing list.
Alan can often be found on irc.gnome.org usually on the channel #abiword.
Alan's email address is horkan a at maths dot tcd dot ie
Alternatively you can try contacting alanhorkan at Gmail or Yahoo! although these addresses get checked far less often.

LiveJournal for Alan Horkan
Technorati Profile for Alan Horkan

Projects

Articles Posted by AlanHorkan

Recent blog entries by AlanHorkan

Syndication: RSS 2.0

Krita 2.9

Congratulations to Krita on releasing version 2.9 and a very positive write-up for Krita by Bruce Byfield writing for Linux Pro Magazine.

I'm amused by his comment comparing Krita to "the cockpit of a fighter jet" and although there are some things I'd like to see done differently* I think Krita is remarkably clear for a program as complex as it is and does a good job of balancing depth and breadth. (* As just one example: I'm never going to use "File, Mail..." so it's just there waiting for me to hit it accidentally, but far as I know I cannot disable or hide it.)

Unfortunately Byfield writes about Krita "versus" other software. I do not accept that premise. Different software does different things, users can mix and match (and if they can't that is a different and bigger problem). Krita is another weapon in the arsenal. Enjoy Krita 2.9.

Syndicated 2015-02-25 23:42:50 from Alan Horkan

OpenRaster Python Plugin

OpenRaster Python Plugin

Early in 2014, version 0.0.2 of the OpenRaster specification added a requirement that each file should include a full size pre-rendered image (mergedimage.png) so that other programs could more easily view OpenRaster files. [Developers: if your program can open a zip file and show a PNG you could add support for viewing OpenRaster files.*]

The GNU Image Manipulation Program includes a python plugin for OpenRaster support, but it did not yet include mergedimage.png so I made the changes myself. You do not need to wait for the next release, or for your distribution to eventually package that release you can benefit from this change immediately. If you are using the GNU Image Manipulation Program version 2.6 you will need to make sure you have support for python plugins included in your version (if you are using Windows you wont), and if you are using version 2.8 it should already be included. (If the link no longer works, see instead https://gitorious.org/openraster/gimp-plugin-file-ora/ as I hope the change will be merged there soon.)

It was only a small change but working with Python and not having to wait for code to compile make it so much easier.

* Although it would probably be best if viewer support was added at the toolkit level, so that many applications could benefit.

Syndicated 2015-02-18 19:14:34 from Alan Horkan

OpenRaster and OpenDocument: Metadata

OpenRaster is a file format for the exchange of layered images, and is loosely based on the OpenDocument standard. I previously wrote about how a little extra XML can make a file that is both OpenRaster and OpenDocument compatible. The OpenRaster specification is small and relatively simple, but it does not do everything, so what happens if a developer wants to do something not covered by the standard? What if you want to include metadata?

How about doing it the same way as OpenDocument, it does not have to be complicated. OpenDocument already cleverly reused the existing Dublin Core (dc) standard for metadata, and includes a file called meta.xml in the zip container. A good idea worth borrowing, a simplified example file follows:

Sample OpenDocument Metadata[Pastebin]

(if you can't see the XML here directly, see the link to Pastebin instead.)

I extended the OpenRaster code in Pinta to support metadata in this way. This is the easy part, it gets more complicated if you want to do more than import and export within the same program. As before the resulting file can renamed from .ora to .odg and be opened using OpenOffice* allowing you to view the image and the metadata too. The code is Pinta OraFormat.cs is freely available on GitHub under the same license (MIT X11) as Pinta. The relevant sections of are "ReadMeta" and "GetMeta". A Properties dialog and other code was also added, and I've edited a screenshot of Pinta to show both the menu and the dialog at the same time:

[* OpenOffice 3 is quite generous, and opens the file without complaint. LibreOffice 4 is far less forgiving and gives an error unless I specifically choose "ODF Drawing (.odg)" as the file type in the Open dialog]

Syndicated 2015-02-13 00:38:44 from Alan Horkan

OpenRaster and OpenDocument

OpenRaster is a file format for layered images. The OpenRaster specification is small and relatively easy to understand, essentially each layer is represented by a PNG image, and other information is contained written in XML and it is all contained in a Zip Archive. OpenRaster is inspired by OpenDocument.
OpenDocument is a group of different file formats, including word processing, spreadsheets, and vector drawings. The specification is huge and continues to grow. It cleverly reuses many existing standards, avoiding repeating old mistakes, and building on existing knowledge.

OpenRaster can and should reuse more from OpenDocument.



It is easy to say but putting it into practice is harder. OpenDocument is a huge standard so where to begin? I am not even talking about the OpenDocument Graphics (.odg) specifically but more generally than that. It is best that show it with an example. So I created an example OpenRaster image with some fractal designs. You can unzip this file and see that like a standard OpenRaster file it contains:


fractal.ora  
 ├ mimetype
 ├ stack.xml
 ├ data/
 │  ├ layer0.png
 │  ├ layer1.png
 │  ├ layer2.png
 │  ├ layer3.png
 │  ├ layer4.png
 │  └ layer5.png
 ├ Thumbnails/
 │  └ thumbnail.png
 └ mergedimage.png

It also unusually contains two other files manifest.xml content.xml. Despite the fact that OpenDocument is a huge standard the minimum requirements for a valid OpenDocument file comes down to just a few files. The manifest is a list of all the files contained in the archive, and content.xml is the main body of the file, and does some of the things that stack.xml does in OpenRaster (for the purposes of this example, it does many other things too). The result of these two extra files, a few kilobytes of extra XML, is that the image is both OpenRaster AND OpenDocument "compatible" too. Admittedly it is an extremely small tiny subset of OpenDocument but it allows a small intersection between the two formats. You can test it for yourself, rename the file from .ora .odg and LibreOffice can open the image.

To better demonstrate the point, I wanted to "show it with code!" I decided to modify Pinta (a Paint program written in GTK and C#) and my changes are on GitHub. The relevant file is Pinta/Pinta.Core/ImageFormats/OraFormat.cs which is the OpenRaster importer and exporter.

This is a proof of concept, it is limited and not useful to ordinary users. The point is only to show that OpenRaster could borrow more from OpenDocument. It is a small bit of compatibility that is not important by itself but being part of the larger group could be useful.

Syndicated 2014-12-12 04:03:51 from Alan Horkan

Developing MComix. Part 1: A rose by any other name...

Comix is a comic and image viewer program written using Python and GTK. I was interested in making a few changes to the project. I am getting back into programming, learning a more about PyGTK and hopefully making some improvements the program will fit better on a small screen netbook. Unfortunately Comix is unmaintained, the developer of the project seems to be unavailable and has not made any updates since 2009. (You can discover this for yourself by checking the Comix website particularly by checking the Sourceforge page for Comix and taking a look at the last date on the Changelog, and various reports in the bug tracker. It may still be possible to get in contact with him but the project is not active.)

I was pleased to discover MComix a fork of Comix, continuing on from Comix version 4.0.4. It isn't clear what the M in MComix stands for but from the picture in the about dialog I think "Monkey Comix" is a fairly safe guess.
(Later I also discovered another fork of Comix by HellHover which incorporates many of the patches submitted to Comix. It is more like a spork than a fork, as it keeps close to the original.)

The attitude and prompt reponse from the MComix developers was encouraging so I got to work putting together a few changes and sending in a patch (after a discussion clarifying that MComix is licensed under the GNU GPL version 2).
Freedom to change the source code and even fork the project is a great power to have but it comes with responsibility. Getting others to help is not easy, you want people to submit code, help with translations, or get a project packaged nicely for different operating systems, and generally help with the work of maintaining a project, so even though forking is possible it is not something you want to do unless absolutely necessary. Knowing it would take some time and effort to make changes it is a great relief to know there is a good chance others will accept the change help maintain it. Putting a lot of work into a patch and having it go to waste, is a big disappointment and severly discourages anyone from contributing to a project.

The patches took less time to write and test than the email explaining the rationale for the changes. Developers often like to do things their own way, and a without a proper explanation, patches might not be accepted. As a fork of Comix I was optimistic the developers would be more accepting of change but I wasn't going to take any chances.

The first - and to my mind most important - change was relatively simple but something I would strongly recommend to any program, especially a fork: separate out the name of the program. I set a constant and called it "APPNAME" and replaced the word MComix, so that if the name ever needs to be changed again or even changed back to Comix it can be done with only a few small changes.
The long and winding history of Mosiac, Netscape, Mozilla, m/b, Phoenix, Firebird, Firefox, Iceweasel, is a particularly extreme example of the many name changes a project can go through. If someone doesn't like the name the can easily change it without needing to fork the project. Making it a little bit easier for others to customize and fork the code gives them one less reason why they would need to, and they can continue to pool their efforts on the things they do agree on.

The patch also contained changes to help with internationalisation (i18n) and localisation (l10n).
There was also a small change to the command line arguments.

When the patch was accepted I was very satisfied and confident the developers were the kind of people I would enjoy working with further. Answers to a few other questions in my email confirmed our interests were different but mutually beneficial. Straight away I was thinking about the next changes I might make.

Syndicated 2011-04-23 23:49:11 from Alan Horkan

365 older entries...

 

AlanHorkan certified others as follows:

  • AlanHorkan certified cinamod as Master
  • AlanHorkan certified alan as Master
  • AlanHorkan certified AlanHorkan as Master
  • AlanHorkan certified hub as Master
  • AlanHorkan certified larsrc as Journeyer
  • AlanHorkan certified Uraeus as Master
  • AlanHorkan certified gman as Master
  • AlanHorkan certified bradyn as Apprentice
  • AlanHorkan certified sisob as Master
  • AlanHorkan certified wlach as Master
  • AlanHorkan certified caolan as Master
  • AlanHorkan certified Telsa as Master
  • AlanHorkan certified jdub as Master
  • AlanHorkan certified glasseyes as Master
  • AlanHorkan certified Adrian as Journeyer
  • AlanHorkan certified tml as Master
  • AlanHorkan certified RyanPavlik as Master
  • AlanHorkan certified joncruz as Apprentice
  • AlanHorkan certified louie as Master
  • AlanHorkan certified miguel as Master
  • AlanHorkan certified robsta as Journeyer
  • AlanHorkan certified msevior as Master
  • AlanHorkan certified bwh as Master
  • AlanHorkan certified Spooky as Master

Others have certified AlanHorkan as follows:

  • AlanHorkan certified AlanHorkan as Master
  • hub certified AlanHorkan as Journeyer
  • larsrc certified AlanHorkan as Apprentice
  • mhatta certified AlanHorkan as Apprentice
  • sisob certified AlanHorkan as Journeyer
  • voltron certified AlanHorkan as Apprentice
  • Uraeus certified AlanHorkan as Journeyer
  • ariya certified AlanHorkan as Journeyer
  • Perrin certified AlanHorkan as Journeyer
  • wlach certified AlanHorkan as Apprentice
  • strider certified AlanHorkan as Journeyer
  • fxn certified AlanHorkan as Journeyer
  • ladis certified AlanHorkan as Journeyer
  • mdupont certified AlanHorkan as Apprentice
  • byte certified AlanHorkan as Journeyer
  • glasseyes certified AlanHorkan as Apprentice
  • RyanPavlik certified AlanHorkan as Journeyer
  • bolsh certified AlanHorkan as Apprentice
  • mikeycooper certified AlanHorkan as Journeyer
  • chrisime certified AlanHorkan as Journeyer
  • Lobster certified AlanHorkan as Journeyer
  • mirwin certified AlanHorkan as Apprentice
  • wspace certified AlanHorkan as Journeyer
  • zbowling certified AlanHorkan as Journeyer
  • pvanhoof certified AlanHorkan as Master
  • superant certified AlanHorkan as Journeyer
  • dragotown certified AlanHorkan as Journeyer
  • lucasr certified AlanHorkan as Journeyer
  • shlomif certified AlanHorkan as Master

[ Certification disabled because you're not logged in. ]

New Advogato Features

New HTML Parser: The long-awaited libxml2 based HTML parser code is live. It needs further work but already handles most markup better than the original parser.

Keep up with the latest Advogato features by reading the Advogato status blog.

If you're a C programmer with some spare time, take a look at the mod_virgule project page and help us with one of the tasks on the ToDo list!

X
Share this page