Blog | Admin | Archives

Gallery2: Great Featureset, Poor Execution

This weekend, I took a real stab at Gallery2. It has an immense yet well-managed feature set, it is spectacularly modular, and it is highly configurable. Unfortunately, underneath its glossy exterior, it is depressingly slow, and, if I dare demean a feat that I in no way consider myself capable of accomplishing, the software is very poorly done under the hood.

Unlike the last time I tried, I figured out how to set the name of the main gallery page. The answer is really simple, once one understands the way that gallery thinks – the main gallery page is itself an album. Once I understood this, it was easy to change this album’s name. Also, getting rid of the sidebar became easier once I understood that in Gallery 2 allows default configurations that apply globally but can be overridden at any level. Before, I had removed all items from the main gallery’s sidebar, expecting it to remove from each sub-gallery as well. Unfortunately, they retained the global configuration and the sidebar remained. My initial attempts at getting the durned thing to work I think speaks volumes about the Gallery 2 experience: wonderfully cumbersome.

However, I persisted and recently got everything working just about how I wanted it to be working. Well, almost. You see, I had imported all of my Gallery 1 images using the nice import feature, setting the title and summary fields appropriately. However, after importing and browsing around a while, I decided I wanted the description fields to have whatever the summary field had. This was an option available upon import, but not afterwards. Well, no problem, I thought. I know SQL well and I can have the database copy the correct information over. Right? Wrong!

After wading through the tens of tables, none of which were particularly well named for someone embarking on my task to figure out, I successfully completed the query and verified my results using phpMyAdmin. However, when viewing the gallery pages, the changes I had made didn’t show up. So I tried editing one of the description fields using the Gallery interface to do so. Trying to save the change resulted in a gallery error with a stack trace a dozen lines long. I had to go back and undo my changes in order to restore order to the universe. To find out where I went wrong, I dumped the database using phpMyAdmin before and after making a change using the Gallery interface. The secret was that a timestamp was changing that somehow cued Gallery in to the change it was making. Without the proper timestamp change, changed data doesn’t show up and further attempts to edit fail.

Unwilling to learn the Gallery 2 API just to fix this one problem (a task I tried to wing last night, but failed despite meticulously following documentation and diving pretty deep into the code), I came up with an alternate solution: deleting all the albums and reimporting them correctly. Quick trick, right? Wrong! It turns out that deleting albums is a long and involved process that takes a long, long time, at least on oasis, the machine running silverfir.net. What could be so complicated about deleting an album? Maybe it had to modify those timestamps for every picture it deletes? I wouldn’t be surprised!

So, after the delete finished (several minutes later for a little over 3,000 pictures), I proceeded to re-import my Gallery 1 albums, this time using the correct settings. Straightforward, right? Wrong! Each album I imported inherited the settings of the main gallery instead of the global defaults. I had set up the main gallery to display albums, and the global defaults to display pictures. So I had to go to each gallery and manually change the settings – a cumbersome process made worse when each page is sluggish to load.

I finished this whole process not too long ago. However, the stack of issues I had to fight against took their toll. Combined with infernal sluggishness, I am strongly considering throwing away all of this work and simply moving to Gallery 1.5. While not database driven, I’m pretty sure I don’t want a database-driven application built by the same people that developed the insanity that is Gallery 2’s backend.

I say all of this with much respect for the Gallery 2 team. Their software is a work of art. But I’m not ready to call it good. Good software makes hard tasks easy and does what you expect. Gallery 2 has done neither for me. For all of its features, it seems to lose sight of what is most important: displaying images quickly and easily.

2 Responses to “Gallery2: Great Featureset, Poor Execution”

  1. Stickman Says:

    I’m planning on building my own gallery sometime. Give me a list of features you want and how you want it to behave and I’ll see if I can work any of them into my plans. I’m crazy about optimization, and I develop on an old dual PII 266. If the code isn’t fast enough on that machine, I fix things until it is.

    Don’t expect it to appear in all its glory anytime soon, though. I’m too paranoid to use someone else’s software, but I’m too busy to really make my own.

    Right now I’ve got the most basic of “galleries” up that took me all of five minutes to make. It’s more of a “sketchwar” than a “gallery”, though.

    http://www.skaarjonastick.com/gimpystick/

  2. The Deliverator - Wannabee Says:

    New Blog Addition
    I chose to install Gallery 1.5 rather than the current 2.0 release based largely on Ryan’s mixed experiences with version 2.

Leave a Reply