[KPhotoAlbum] A few stacking issues
rlk at alum.mit.edu
Fri Jan 25 15:49:39 CET 2013
On Fri, 25 Jan 2013 15:39:11 +0100, Johannes Zarl wrote:
> On Friday 25 January 2013 01:42:58 Robert Krawitz wrote:
>> On Fri, 25 Jan 2013 01:38:22 +0100, Johannes Zarl wrote:
>> > On Friday 25 January 2013 01:11:32 Robert Krawitz wrote:
>> > Well, it doesn't make the behaviour more useful for you, but it also
>> > means that the real bug lies with the autostacking-problems you
>> > mentioned. If autostacking worked properly for you, you wouldn't need
>> > the workaround. I just don't want to dig into this problem, if I'll
>> > realize later that the problem lies somewhere else ;-)
>> That's not so. Sometimes I may want the JPEG and sometimes I may want
>> the RAW, depending upon what I'm doing.
> I didn't want to imply that your "ideal workflow" is unreasonable. But the current "intended behaviour" is for the export to use the top-image of each stack. If KPA is not doing that, than that would be a bug.
> If you want KPA to do things differently (e.g. ask the user for each stack which image to select), then that is a feature request, and honors a discussion asking questions like "how does it affect other users with different workflows?" or "is somebody willing to implement it?".
Agreed; that's why I'm raising the issue.
>> (Also, if the purpose is to be able to populate a foreign database, it
>> really should be exporting *all* files in the stack.)
> This was a deliberate design choice (there was a discussion on this list a while back, but I don't remember the exact date).
> The idea behind this behaviour is the following:
> a) If someone wants to export/run a kipi-plugin on only the "top images" (i.e. the unstacked images + the top images of the stacks), one can do so by just selecting the unexpanded stacks.
> b) If someone wants to export/run a kipi-plugin on all images, then one can do so by first selecting "expand all stacks".
> If the export automatically expanded the stacks, use-case a) would break.
OK -- but is the stacking information then lost when everything is
Robert Krawitz <rlk at alum.mit.edu>
MIT VI-3 1987 - Congratulations MIT Engineers men's hoops Final Four!
Tall Clubs International -- http://www.tall.org/ or 1-888-IM-TALL-2
Member of the League for Programming Freedom -- http://ProgFree.org
Project lead for Gutenprint -- http://gimp-print.sourceforge.net
"Linux doesn't dictate how I work, I dictate how Linux works."
More information about the KPhotoAlbum