> Have a look at http://albumshaper.sourceforge.net/ > But be warned: no packages to install, compile from source. Worse, it > uses a very late Qt (4.1.2), and SUSE 10.1 (2 months old!) only has > 4.1.0, not enough for albumshaper. I had a discussion about this with > the author. While I understand that there is a place for cutting-edge > development, this sort of approach is useless for putting Linux on the > desktop of the non-savvy. (And I'm not going to upgrade Qt either.)
Ah. Now we go back to inflexible layout discussions... Can't win, eh? > The problem with all the scripts is that they're ok for you > and me, but > no good to $USER. Which isn't saying anything bad about > $USER, it's just > acknowledging that a computer should be a tool which can be used by > $USER to get the job done, e.g. putting an album online. > > As an aside, I have yet to see a perl GUI app which wasn't so dog slow > as to be useless (not mentioning not looking like puke), but > I have seen > acceptable GUI apps programed in python. Keep your options open before > you spend much more time. Yes I agree with your comments on using perl as a GUI app. Currently my perl "script" is commandline-driven from cron and traverses (optionally updating if things have changed) an entire web directory hierachy which, btw, just happens to share your layout. :-). As far as the ability for $USER to utilise it, that's just a function of a ./configure option which asks them where/how they wish to implement the script. :-) To make it really brain-dead that can be called upon first run. The tricky part is to provide the ability for the user to customise the output results in a simple and concise manner. "Assemble your particular results page from scratch from our supplied widgets or use one of our nifty pre-supplied templates" sounds good but is not that simple to do well. For my extended family, access via the web is the most sensible way for them to see what we're up to. So using a webserver-based language like php is more ideal for me than any other method. I realise that's not completely universal as most people won't have an easily accessable php-capable webserver. However, once I've got what I need coded, I'm quite willing to share some effort in porting it to run standalone if nothing else surfaces in that time. A flat text file is good for a moderate amount of photos, but as you mentioned in another post, I also plan to accomodater large galleries. (My wife "condones" this project as capable of recording our son's life as he grows up so the number of photos/videos will probably end up being quite substantial). Flat text is not great for searching on once the entries exceed a moderate number, and search is another nice-to-have that my wife wishes me to knock up. :-) I suppose I could allow the backend store (and therefore the access methods) to be selectable from a configuration file. Or, and I like this method better and am interested in what exif editors you've played with, I would prefer to embed the comments/keywords/etc. within the image. That would elegantly eliminate the necessity for a database at the expense of possibly requiring me to code a picture viewer function that allows one to add/view these comments. It also makes the images and their descriptions independent of whatever program I make, if an exif-capable viewer is utilised. And, using exif, I don't need to create separate thumbnail files for viewing. Oh yes. The reason that I need to add my own comments in is that I want the description/keyword tags to be in multiple languages and, as one of these is Chinese in my case, a text-file backend store becomes quite problematic. Chinese Character-based filesets are not permitted in the exif standard (one Japanese one is) so I'll have to save the thing as a blob, if I can. If not, then it's back to a SQL database. I could use Dbm, of course. :-) Mpeg and avi files are a different problem of course, but if I have to use SQL for language support, I'll also use it for tags for these file types. So as you can see, I was tending towards php and MySql and will most likely end up implementing at least php but am quite interested in what's available in command-line exif editors in order to use one of those to store the relevant info. Anyone out there got any other ideas about how to do this? Brett.
