GNOME Bugzilla – Bug 653343
Items in the What column should be insensitive if there is no event associated with them
Last modified: 2018-05-22 14:52:13 UTC
- Pick a contact with whom you never had audio chats in the Who column - Pick Calls in the What column - No event is displayed In such case the Calls entry should be insenstive.
http://cgit.collabora.com/git/user/pochu/empathy.git/log/?h=history-unsensitive-filters There are a couple of problems: We can't know whether we have events for subtypes (e.g. missed/outgoing/incoming calls), so we set them as the parent. So e.g .if there are no calls, all the call subtypes will be unsensitive too, which is fine, but if there are only incoming calls but no outgoing/missed calls, all the call types will be marked as sensitive and if you click on them, nothing will be displayed. This is a bit hard to fix in the logger as all the call events are stored in the same .call.log files, so it would need to parse them to see if the subtype is present instead of just looking for .call.log files. Also the logger only has a call to know whether an entity has logs of one type for any date, but not for one in particular, so it can happen that you had a call with Alice on June 20th but you have 'Today' selected (and you don't have any calls with her today), then the call filters will be sensitive. This should be easier to fix in the logger, by just adding a tpl_log_manager_exists_for_date() that only looks for the asked $date.$type.log. I've just opened https://bugs.freedesktop.org/show_bug.cgi?id=38973 for it. We can't fix these without logger changes (unless we unnecessarily retrieve logs just to see if events of one type exist which is a pretty bad idea) so we can merge this with these two problems and fix them when we can.
I agree, let's fix what we can now and keep this bug open until logger gains the API we need. (In reply to comment #1) > http://cgit.collabora.com/git/user/pochu/empathy.git/log/?h=history-unsensitive-filters I'd add some comments to explain the semantic of the different for loops, it's not clear after a first reading of the code.
(In reply to comment #2) > I'd add some comments to explain the semantic of the different for loops, it's > not clear after a first reading of the code. Done (amended)
I think it would be worth factoring out a set_event_type_sensitivity() or something changing its COL_WHAT_SENSITIVE and its sub type.
(In reply to comment #4) > I think it would be worth factoring out a set_event_type_sensitivity() or > something changing its COL_WHAT_SENSITIVE and its sub type. Good idea, done (I'll squash before merging)
(In reply to comment #1) > Also the logger only has a call to know whether an entity has logs of one type > for any date, but not for one in particular, so it can happen that you had a > call with Alice on June 20th but you have 'Today' selected (and you don't have > any calls with her today), then the call filters will be sensitive. This should > be easier to fix in the logger, by just adding a > tpl_log_manager_exists_for_date() that only looks for the asked > $date.$type.log. I've just opened > https://bugs.freedesktop.org/show_bug.cgi?id=38973 for it. Actually this may not be a problem (depending on how we want the History window to behave): if you have a day selected for which there are no e.g. calls, but there are for other days, "Calls" will be marked as sensitive. But clicking on it will change the day to one with available calls, so calls will be displayed, but the date will change. Now the question is whether we want to keep that or not, but it's not as bad as I initially thought.
Merged
Matthew, can you read comment #6 and say whether the current behaviour is fine or we should also grey out event types in that case (when events exist for that type but for different dates than the selected ones) ?
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/empathy/issues/398.