[KPhotoAlbum] Picture selection workflow, etc.

[Miika Turkia]

On Thu, Dec 29, 2011 at 12:49 AM, Joe <josephj at main.nc.us> wrote:
> Great!  Continue Later is exactly what I want for the first issue.
>
> Maybe someday there'll be a KPA manual to look these things up  in.
> That's the weakest link in an otherwise outstanding project.
>
> Joe
>
> More responses inline.
>
> On 12/28/2011 05:40 AM, Miika Turkia wrote:
>>
>> On Wed, Dec 28, 2011 at 10:10 AM, Joe<josephj at main.nc.us>  wrote:
>>>
>>> The following is what I'm doing and why it doesn't work very well.  I'm
>>> open
>>> to suggestions on how to do it better! And I have a few ideas.
>>> I'm not saying this is the way KPA is supposed to work or that there's
>>> not
>>> already a better way.  Just that, if there is one, I don't know what it
>>> is.
>>
>> Here is some tips that will hopefully be enough for you (at least for
>> the first issue).
>>
>>> I am selecting some pictures to print from a  large collection (24k
>>> pictures, a small percentage of which are tagged.  Hopefully, I'll get it
>>> done someday!)
>>>
>>> I create a new keyword "0_select" (so it shows up first on the sorted
>>> keyword list in search) and I add that tag to each picture I select (more
>>> than one at a time where possible).
>>>
>>> This works, but raises a number of issues.
>>>
>>> 1) If the picture was untagged, (my keyword for that is "untagged"),
>>> adding
>>> the 0_select tag causes the "untagged" keyword to be automatically
>>> removed.
>>>  (I suppose I could just turn that feature off and do it manually.)  When
>>> I'm done with this selection, I have two choices.  a) Leave the keyword
>>> there forever and don't reuse it until I have fully tagged all the
>>> pictures
>>> with that tag or b) remove the tag from the pictures and consequently
>>> lose
>>> the ability to find them as untagged in the future.
>>>
>>> This problem is an artifact of the larger issue that selecting pictures
>>> is
>>> conceptually disjoint from tagging them and using the same facility for
>>> both
>>> (I forget what this "programming" sin is officially called - something
>>> about
>>> dependencies within variables or improper normalization) is flawed
>>> design.
>>>
>>> Suggestion:  *If* this is the way it's done, then one improvement (really
>>> a
>>> workaround for a conceptual shortcoming) to kpa would be to allow the
>>> user
>>> to select the "untagged" keyword  and have it stick.  Currently, it
>>> deletes
>>> itself.  (Also, I sometimes add some tags to a set of pictures, but know
>>> I
>>> need to go back and add more, so I'd like to use "untagged" semantically
>>> as
>>> "not finished tagging".)  So, I'd like to be able to add some tags and
>>> still
>>> have the "untagged" keyword stick.  I guess the best of both worlds would
>>> be
>>> to have every new picture I add automatically marked as "untagged", but
>>> for
>>> KPA to leave that field alone from then on and leave it up to me to
>>> delete
>>> it manually.
>>
>> - new pictures are automatically marked as untagged
>> - when tagging images you have two confirmation buttons, Done and
>> Continue Later. The first one automatically removes the untagged tag
>> and latter leaves the untagged there (but does not add it if there is
>> no untagged tag)
>>
>> Sounds like you are describing the behaviour of the Continue Later
>> button in your suggestion.
>>
>>> 2) When I'm selecting-by-tag a lot of pictures (using a tag as above), a
>>> lot
>>> of things can happen to make me lose my place in the large collection of
>>> pictures - anything from hitting left click or down arrow by accident
>>> instead of ctrl left click/ctrl down arrow  and  clearing all the
>>> previously
>>> (mouse click) selected pictures; having to quit and resume later; hitting
>>> ctrl home or end or letting keyboard repeat go wild by holding down a
>>> positioning key too long ....
>>>
>>> When something like this happens, I lose track of where I am and what's
>>> selected-by-tagand what's not.  I can use search to show me all the
>>> selected-by-tagpictures.  That works, but disrupts my context because
>>> once I
>>> find the last picture that was selected-by-tag, it's not very easy to get
>>> back to it once the search is undone.  I have to look for it by date or
>>> its
>>> cryptic file name.  This works, but it's less than elegant.  It also
>>> doesn't
>>> let me see what's not selected-by-tag, but should be.
>>>
>>> Suggestion: Add a new type of search/filter that finds things exactly the
>>> way the current search does, but instead of eliminating everything else
>>> and
>>> just showing the new selection, add an attribute to each picture like
>>> changing the color of its border to a custom color or maybe even adding a
>>> badge to it like kde does with icons.  If that was done, my context would
>>> not be disturbed.  I'd still be looking at the same selection of pictures
>>> I
>>> was looking at before the search (without even moving anything on my
>>> screen!)and I could instantly tell which ones were selected-by-tagand
>>> which
>>> weren't.  This would be even more awesome if it could "display" the
>>> results
>>> of more than one search at a time.  That would be "easy" by just using
>>> different colors for each selected-by-tag search/filterand figuring out
>>> what
>>> to do when these selections overlap or allowing more than one badge per
>>> picture.
>>
>> I think search is the only functionality that discards the information
>> of previous selections. So you can add more filtering criteria after
>> search or filtering by clicking the categories. And going back removes
>> the latest filtering criteria. E.g. start with search of images shot
>> in home town and that includes John. Then check the thumbnails..and
>> see that you need only images that were shot in birthday (event)...hit
>> back. Select e.g. category event and keyword birthday from there. Now
>> the filtering includes home town, John, birthday.
>>
>> There is also an option to include categories in the thumbnail view (I
>> haven't tried it). Not exactly what you describe in colors but at
>> least it might be useful to you.
>>
>> Anyway, dynamic selection based on some search criteria within the
>> current set of images is something that would be useful to me also.
>
> Not entirely sure what you mean by "dynamic selection based on some search
> criteria within the current set of images".

Marking images by a keyword or some other search criteria (within the
selection). Just like control clicking the ones you want, except the
selection would be done by search results automatically. Somewhat
different use-case than what you describe but almost same as the first
phase of your explanation.

> What I want is to see attributes of a selection of pictures that don't all
> have exactly the same attributes.
>
> Thumbnails won't help very much because it shows attributes one at a time so
> I'd have to look at the thumbnail of every picture.
> Also, thumbnails are mostly unusable for me in KPA 4.1.1 because there's no
> delay displaying them on mouse over so they jump all over the place when I
> move the mouse.  I requested a fix for this and someone did it almost right
> away, but since I haven't yet figured out how to build KPA from git, etc., I
> don't have access to it.  (See my post on the new release thread.)

I sure understand if you are not willing to compile KPA yourself but
just in case:
https://mail.kdab.com/pipermail/kphotoalbum/2011-July/004747.html

miika