Just a kind thank you note to the gThumb authors for completely breaking my workflow by re-inventing the paradigm used to save imported pictures. Until now, all my pictures landed in a predictable location, using a predictable filename pattern that was easily searchable. Not anymore. Now, files land into my home directory, according to some recursive folder pattern that further complicates searching for files and requires a few more clicks to accomplish. Dammit! Couldn't you at least make this configurable, so that those of us who prefer to retain the old paradigm can?!
Note: re-inventing an application's paradigms is always a very bad idea. If you're a software developer who is reading this, please keep it in mind and go scratch your itch to change the world somewhere else. Thank you.
Post Scriptum
Many thanks to Damon Lynch for pointing me to his own professional picture importer called Rapid. This is an extremely configurable importing tool and, lo and behold, Damon even offers builds for Ubuntu via his PPA!
Still, the consequence of this mess is that migrating to Rapid means that I'll be loosing gThumb's simple but extremely efficient editing tools. To me, one strength of gTthumb was this unique combination of picture importing with basic editing tools. Now, I'm forced to split these interconnected tasks, simply because someone chose to completely rethink gThumb's paradigms. I'm of course aware of Gimp's existence, but repeated attempts at mastering it made me conclude that it's entirely the wrong software for my needs and essentially overkill. By contrast, gThumb offers just enough tools to enable someone to crop images to useful sizes and to adjust color balances in easy steps; it does the job without hassle, which is not the case with Gimp.
Thinking out loud, it is precisely on days like these that the urge to create my own Linux distribution keeps on coming to mind. Retaining consistent paradigms in the desktop environment and applications that I use, not to mention maintaining the number of duplicate libraries to a bare minimal, has been a constant struggle and, noticing how some developers' urge to re-invent the wheel every other day, using whatever new programming language of the day, persistently takes precedence over keeping system resource consumption to a bare minimum and over preserving user sanity, I'm slowly coming to the conclusion that Free Software has veered way too far into the bazaar and urgently needs a copious amount of cathedral to make it usable for mere mortals again.
Some dpkg-based distribution where the only scripting language allowed is Bourne shell and the only programming languages C or C++ comes to mind. Of course, this would also require porting popular application from e.g. Java, Python, etc. which would be a colossal amount of work. Still, I think that the time has come for this to happen. As an added bonus, this would make applications usable again on embedded devices with spartan CPU, RAM and storage resources, so this project could generate huge benefits to the embedded Linux industry. Based on my experience at my previous jobs, I have a rather clear picture (pun intended) of what needs to be done and of who I would hire to make it happen. What I'm missing are investors. Who's with me?
17 comments:
Perhaps you will find this program helpful: http://www.damonlynch.net/rapid/
Victor: what would reverting all changes really accomplish?
Damon: Absolutely brilliant application. Thank you! Of course, it is strictly an importer, but its configurability makes it worth it. Sadly, it means that I'll need to find another application to replace gThumb's over-simple editing features, though.
I would like to thank the gThumb developers for all the improvements they have made this cycle. New gThumb is a massive improvement!
Isn't F-Spot capable of offering you what you want? It imports into a directory tree, and has edit mode for colour levels and cropping and so on...
The package manager is supposed to abstract the programming language and install specifics from the end-user. What benefit would restricting a distribution to only running applications written in a single language bring to the end-user?
@David Ron
I don't care what language an app is written in so long as it's native. I don't want to see ANY non-GTK apps in the Ubuntu Software Center. No Swing, No XUL, No Qt, no mosaic, no Windows.
..and after I move to KDE4, which is imminent, I don't want to see ANY non-Qt apps, no GTK, no XUL, no Swing.. part of why I'm switching is that gnome has no native presentation app, while KDE has KOffice.
You're complaining about gThumb re-inventing the wheel, but then go on to suggest that you'd create a new linux distribution by... re-inventing thousands of wheels by creating those wheels with a single choice of language. It's a little ironic.
I import my pictures by dragging them off the camera - I don't trust "import" programs. After that jBrout is used to add tags, then Picasa can index them and provide basic editing. Or gThumb.
It *is* configurable, there is a Preferences button in the import dialog to disable the automatic sub-folder creation.
Paolo: it *used* to be configurable. Not anymore.
Out of curiosity: Which version of gthumb are you using, the one currently in lucid (2.11.1) or the latest release 2.11.2?
Following the gthumb mailinglist I would think that the developers are aware of regressions and want them to fix before an 2.12 release, so I think it's not too useful too rant about a not-ready version... And finally: Did you file a bug or send a mail to the list...?
Marcel: it is clearly not a bug. Rather, 2.11 introduced a number of significant changes in how the application's basic tasks are performed. Looking at gconf keys for gThumb via gconf-editor, I notice that a number of keys are simply no longer used. The one defining the path where to save imported pictures is one of them. Looking closer, it appears that the upstream authors simply decided that automatically creating albums for all pictures that get imported and saving them in a directory tree following the year/month/day hierarchy was the new way to do things.
maybe you could try phraymd (new app in python)
https://launchpad.net/phraymd
Martin-Éric: Sorry, but I'm still a bit confused about your post. But I can't really comment on differences to the previous workflow -- the importer didn't work for me at all with raw files in 2.10...
But this recursive folder thingy (which I never liked in F-Spot as well) *is* certainly configurable: as Paolo said: Preferences -> uncheck "Automatic subfolders" or use a custom format (containing just event name, for example). So the only difference I'm seeing is that files are no longer renamed with a "%05d.something" name, right? If this is important to you, than why not file a bug or talk to the developers on the mailing list? It's still an unstable version where things are in flux...
So, in short: I think the new gthumb is a great improvement over the older versions and the developers did a great job. Unfair rants like this really don't help anyone :-|
Marcel: the format used to be something like destination/2009-12-25--23.16.10 but this is no longer possible. The best I can achieve is destination/2009-12-25 and it already uses a different gconf key than the previous one to configure that, so whatever settings I had configured for this went nowhere the day 2.11 was pushed into Lucid.
*Sigh*, so you're really complaining about the version in lucid which is an intermediate unstable version... The most recent upstream version has a "custom" folder setting, where you can use date and time formatting and get the behavior you want.
So maybe contact the Ubuntu packager or file a bug about Lucid not shipping the latest upstream code. And possibly it's a bug that you're old settings are not transferred to the new version.
But seriously, when you're are using an alpha release of a distribution you should expect some temporary regressions or even breakage without starting such a rant.
Marcel: I have personally uploaded the very latest upstream to Lucid. Even then, that doesn't resolve the issue: after configuring a custom path, I found gThumb creating one folder FOR EACH PICTURE. I mean, come on! How stupid can this get?
Hi,
thanks for uploading -- although it seems you broke the amd64 package on your way (it's not updated and therefore no longer compatible with gthumb-data).
I see your problem with the custom folder -- it's getting the current time for every picture and not once for the import, that is clearly a bug. Although I don't really see the point in the old setting, why use minutes and seconds for the folder name in the first place...?
I'm feeling a bit awkward defending gthumb without having anything to do with the development. Actually I'm quite sure that if you posted your blog post to the gthumb mailing list instead to your blog, all your issues would have been solved by now :-/
Post a Comment