[KPhotoAlbum] Category view problem

Wed Mar 6 16:54:23 GMT 2013

On Wed, Mar 6, 2013 at 6:39 PM, Robert Krawitz <rlk at alum.mit.edu> wrote:
> On Wed, 6 Mar 2013 17:55:25 +0200, Miika Turkia wrote:
>> On Sat, Mar 2, 2013 at 11:14 PM, Reimar Imhof
>> <Reimar.Imhof at netcologne.de> wrote:
>>> Am Sonntag, 24. Februar 2013, 21:35:31 schrieb Reimar Imhof:
>>>
>>>> Am Montag, 18. Februar 2013, 20:26:51 schrieb Miika Turkia:
>>>
>>>> > On Sun, Feb 17, 2013 at 11:55 PM, Robert Krawitz <rlk at alum.mit.edu>
>>>> > wrote:
>>>
>>>> > > On Sat, 16 Feb 2013 22:28:20 -0500, Robert Krawitz wrote:
>>>
>>>> > >> On Sat, 16 Feb 2013 18:14:09 -0500, Robert Krawitz wrote:
>>>
>>>> > >>> I'm having a strange problem with category view.
>>>
>>>> > >>>
>>>
>>>> > >>> I frequently keyword every shot I take at an event. I then select
>>>> > >>> the
>>>
>>>> > >>> ones I'm interested in, and keyword them with the same name,
>>>> > >>> followed
>>>
>>>> > >>> by
>>>
>>>> > >>> "selection". So I might have keywords of
>>>
>>>> > >>>
>>>
>>>> > >>> MIT-Babson Jan. 12, 2013
>>>
>>>> > >>>
>>>
>>>> > >>> and
>>>
>>>> > >>>
>>>
>>>> > >>> MIT-Babson Jan. 12, 2013 selection
>>>
>>>> > >>>
>>>
>>>> > >>> The latter is of course a subcategory of the former.
>>>
>>>> > >>>
>>>
>>>> > >>> The problem is that in category view, the number of photos in the
>>>
>>>> > >>> parent
>>>
>>>> > >>> category is always shown as either exactly the number of photos in
>>>> > >>> the
>>>
>>>> > >>> selection subcategory, or twice that number. If I then click on that
>>>
>>>> > >>> row, the correct number is displayed.
>>>
>>>> > >>>
>>>
>>>> > >>> It appears, though, that it isn't the name that causes this (if I
>>>
>>>> > >>> keyword the subselection XXXX the same thing happens).
>>>
>>>> > >>>
>>>
>>>> > >>> But there's another, much more serious problem. If I select all the
>>>
>>>> > >>> photos in the subselect category, and type ctrl-2 to tag them all, I
>>>
>>>> > >>> cannot selectively remove them from just the subcategory or the
>>>
>>>> > >>> supercategory. Initially, both subcategory and supercategory are
>>>
>>>> > >>> checked. If I check or uncheck either one, both are shown as checked
>>>
>>>> > >>> or
>>>
>>>> > >>> unchecked.
>>>
>>>> > >>>
>>>
>>>> > >>> If I don't make the selection a subcategory of the main keyword, I
>>>
>>>> > >>> don't
>>>
>>>> > >>> have this problem.
>>>
>>>> > >>>
>>>
>>>> > >>> In general, it appears that if there is a category/subcategory
>>>
>>>> > >>> relationship, I cannot use ctrl-2 to change just one of the tags on
>>>
>>>> > >>> images.
>>>
>>>> > >>
>>>
>>>> > >> There are actually two problems, based on git bisect.
>>>
>>>> > >>
>>>
>>>> > >> The first problem (showing bad counts) is:
>>>
>>>> > >>
>>>
>>>> > >> a54dfe608536ae9af2cd2a8407fd02af63cec6f6 is the first bad commit
>>>
>>>> > >> commit a54dfe608536ae9af2cd2a8407fd02af63cec6f6
>>>
>>>> > >> Author: Jesper K. Pedersen <blackie at kde.org>
>>>
>>>> > >> Date: Fri Jan 4 21:35:35 2013 +0100
>>>
>>>> > >>
>>>
>>>> > >> s/Q3Dict/QHash for countedGroupDict
>>>
>>>> > >> :
>>>
>>>> > >> :040000 040000 b3433e714a55b8cade49e21a3d32b3d6e28ee81e
>>>
>>>> > >> :6e4965242e91f5bfbc705e4e38bf370400b36805 M DB>>
>>>
>>>> > >>
>>>
>>>> > >> I haven't figured out what's going on here.
>>>
>>>> > >
>>>
>>>> > > The double negative problem strikes again.
>>>
>>>> > >
>>>
>>>> > > diff --git a/DB/GroupCounter.cpp b/DB/GroupCounter.cpp
>>>
>>>> > > index 7cf04ee..cb5bc87 100644
>>>
>>>> > > --- a/DB/GroupCounter.cpp
>>>
>>>> > > +++ b/DB/GroupCounter.cpp
>>>
>>>> > > @@ -95,7 +95,7 @@ void GroupCounter::count( const StringSet&
>>>> > > categories
>>>
>>>> > > )
>>>
>>>> > >
>>>
>>>> > > }
>>>
>>>> > >
>>>
>>>> > > }
>>>
>>>> > > // The item Nevada should itself go into the group Nevada.
>>>
>>>> > >
>>>
>>>> > > - if ( !countedGroupDict.contains( *categoryIt ) == 0 &&
>>>
>>>> > > _groupCount.contains( *categoryIt ) ) { + if (
>>>
>>>> > > !countedGroupDict.contains( *categoryIt ) && _groupCount.contains(
>>>
>>>> > > *categoryIt ) ) {>
>>>
>>>> > >
>>>
>>>> > > countedGroupDict.insert( *categoryIt);
>>>
>>>> > > (_groupCount[*categoryIt])++;
>>>
>>>> > >
>>>
>>>> > > }
>>>
>>>> >
>>>
>>>> > So is this a fix to the whole issue? Ready to be pushed to master?
>>>
>>>> >
>>>
>>>> > miika
>>>
>>>> > _______________________________________________
>>>
>>>> > KPhotoAlbum mailing list
>>>
>>>> > KPhotoAlbum at mail.kdab.com
>>>
>>>> > https://mail.kdab.com/mailman/listinfo/kphotoalbum
>>>
>>>>
>>>
>>>> Hi,
>>>
>>>>
>>>
>>>> I still have issues with the category view (running latest git).
>>>
>>>> For example when leaving the category view by cancel I'm sometimes asked
>>>> "Do
>>>
>>>> you want to drop your changes?" - and I think I didn't change anything.
>>>
>>>> This problem did not occur with kphotoalbum 4.3.
>>>
>>>> And sometimes there are still this
>>>> "group-and-super-group-checked/unchecked"
>>>
>>>> things. Just sometimes - Terrible for searching the bug...
>>>
>>>>
>>>
>>>> Reimar Imhof
>>>
>>>>
>>>
>>>> _______________________________________________
>>>
>>>> KPhotoAlbum mailing list
>>>
>>>> KPhotoAlbum at mail.kdab.com
>>>
>>>> https://mail.kdab.com/mailman/listinfo/kphotoalbum
>>>
>>>
>>>
>>> Hi,
>>>
>>>
>>>
>>> after searching a while I can provide this patch for listsselect.
>>>
>>>
>>>
>>> I reinserted the loop because in configureItem there is something about
>>> dragAndDrop - well perhaps it's not needed. In that case configureItem could
>>> be completely removed.
>>>
>>> In configureItem I removed the setTristate-call because I've found the
>>> following hint from
>>>
>>> http://lists.trolltech.com/qt-interest/2008-04/thread00080-0.html:
>>>
>>> "The intended usage of Qt::ItemIsTristate is to signify that the
>>>
>>> checked state of an item should be computed as a function of the
>>>
>>> checked states of its child items; e.g. no child items checked =>
>>>
>>> parent becomes unchecked; some child items checked => parent is
>>>
>>> partially checked; all child items checked => parent item checked."
>>
>> Robert, can you check out whether this patch works for you since you
>> are the original reporter. (Or at least it does not introduce any new
>> problem for you if the problem was already sorted out for you.)
>>
>> miika
>
> Can you send me the exact patch that you want me to try on top of
> current git master?

Sure

(I am a bit "out of focus" on this whole issue)

miika
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-In-configureItem-I-removed-the-setTristate-call-beca.patch
Type: application/octet-stream
Size: 1789 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kphotoalbum/attachments/20130306/3a3da8c1/attachment.obj>