After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 717321 - allow hidden photos
allow hidden photos
Status: RESOLVED FIXED
Product: shotwell
Classification: Other
Component: library-mode
unspecified
Other All
: Normal normal
: 0.24
Assigned To: Shotwell Maintainers
Shotwell Maintainers
Depends on:
Blocks:
 
 
Reported: 2011-03-21 02:51 UTC by Adam Dingle
Modified: 2016-08-12 11:58 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Add option to filter by saved search (17.64 KB, patch)
2016-07-22 08:15 UTC, Daniel Landau
none Details | Review
Add option to filter by saved search (17.65 KB, patch)
2016-07-22 11:54 UTC, Daniel Landau
committed Details | Review

Description Charles Lindsay 2013-11-25 21:51:09 UTC


---- Reported by adam@yorba.org 2011-03-21 07:51:00 -0700 ----

Original Redmine bug id: 3384
Original URL: http://redmine.yorba.org/issues/3384
Searchable id: yorba-bug-3384
Original author: Adam Dingle
Original description:

Early versions of Shotwell allowed the user to hide photos.  When we added the
1-5 star rating system, we also added a rating Rejected, which replaced the
notion of hidden photos.  Some users would still like to be able to hide
certain photos, independently of whether those photos are rejected or have any
other rating.  See, for example

http://lists.yorba.org/pipermail/shotwell/2011-March/001922.html

Related issues:
duplicated by shotwell - 5331: [feature request] private photos (Duplicate)



---- Additional Comments From shotwell-maint@gnome.bugs 2013-05-21 11:38:00 -0700 ----

### History

####

#1

Updated by Ivan Sagalaev over 2 years ago

Wanted to dump some thoughts on this to make sure it won't get overlooked:

  * Hidden state should apply not only to individual photos but to events as well. I.e. an event with only hidden photos should also be completely hidden, including event tree in the sidebar (event title may be private/sensitive).
  * If an event has a mix of hidden/public photos and a hidden photo is set as its key photo it should be replaced with a default public when displayed in normal mode.
  * Unlocking hidden view should require some level of protection from accidental triggering, like asking for a password. It shouldn't necessarily use a cryptographically strong storage, just be a fool-proof.

Thanks!

####

#2

Updated by Joseph - over 2 years ago

It might also be nice to be able to hide a tag. Especially with boolean
operators. That way you can search for things like “detroit -autoshowâ€.
Thinking about the hidden idea, it might also be nice to be able to hide a
tag. i.e. adding all photos with a given tag to the hidden set. And how about
having all photos with leading dots or in directories with leading dots
default to hidden.

-Joe

####

#3

Updated by Petros Tsantoulis over 2 years ago

  * **Description** updated (diff)
  * **Priority** changed from _Low_ to _High_

I really like shotwell, but the absence of a "hidden" feature is REALLY a
deal-breaker for me. I'm not talking about extreme

porn or top-secret stuff, but imagine current girlfriend perusing photos from
vacations with ex-girlfriend. Or imagine my mother

seeing photos from crazy night with my buddies. Or imagine invited guests from
work wanting to see some photos from my last

business trip in Amsterdam and seeing ... etc.


To further refine the ideas written above, I think we can go a step further.
So, instead of having

only degrees of quality (rating), one could have degrees of privacy for each
photo. So some photos are "ultra sensitive"

(ideally encrypted and never shown without password), others are "sensitive"
(never uploaded, by default not shown)

and yet others are "public". I guess 3-4 degrees of privacy should do the
trick.


I can live without an enhance feature (there is gimp for that) or complicated
search queries for my 18000 photos. But if need to start

deleting stuff or hiding directories or manually moving photos around, then a
photo organiser is really irrelevant and I can go back

to using "xv".


Thanks for your time and for this otherwise excellent piece of software!

####

#4

Updated by Eric Gregory over 2 years ago

  * **Priority** changed from _High_ to _Low_


####

#5

Updated by Lucas Beeler over 2 years ago

@Petros -- does the rating mechanism not provide some degree of visibility
control in the use cases you're talking about?


####

#6

Updated by Adam Dingle over 2 years ago

  * **Priority** changed from _Low_ to _Normal_

I think that Petros (and others) want a privacy level which is independent of
the rating mechanism.  A rating indicates a photo's quality, which is not the
same as its privacy/sensitivity.

Note that multiple libraries (e.g. specified with 'shotwell -d') might be
another way to solve this problem using an existing mechanism.

####

#7

Updated by Petros Tsantoulis over 2 years ago

Lucas Beeler wrote:

bq.

@Petros -- does the rating mechanism not provide some degree of visibility
control in the use cases you're talking about?

Of course, that's what I'm using right now (although I had to archive some
photos). But it is not fine grained control (ie some photos are very sensible
and some photos are OK for almost everyone except my boss). Furthermore, I
prefer to think that reject applies in the sense of photo "quality" rather
than privacy. A photo that is not beautiful or has some technical flaw can be
kept in the database but "rejected' due to its quality, in case it is needed
later. This is not the same as rejecting a photo that is very beautiful but
private. So if possible (a) make quality and privacy distinct, (b) allow
multiple levels of privacy.

Anyway, thanks for responding so quickly.

####

#8

Updated by Piergiorgio Traversin over 1 year ago

  * **Description** updated (diff)

Any news on this one?

Just a tag (e.g. 'hidden') that by default makes the photos not visible will
do, for the moment.

####

#9

Updated by Lucas Beeler over 1 year ago

This is open source, so patches are always welcome! ;-)

####

#10

Updated by Weiwu Zhang 6 months ago

In an undated article of this website, the feature is introduced:

http://redmine.yorba.org/projects/shotwell/wiki/UsingShotwell04

The article says:

"If you don't want to see a photo but still want to keep it in your library,
you can hide it by selecting it and choosing Photos -> Hide. To see hidden
photos, toggle the menu item View -> Hidden Photos. Once visible, hidden
photos have a red X in the lower right corner. You can unhide selected photos
by choosing Photos -> Unhide."

I checked my shotwell 0.14.1. It doesn't have the described buttons and menu
items. Can someone correct that article?

(Oh how I am averse towards undated article. The world is changing in such a
pace and undated articles are dis-informative: it only wastes time for readers
who are looking for information.)

####

#11

Updated by Joe Bylund 6 months ago

This bug is still open, so this issue is unresolved. That said, marking a
photo as rejected hides the photo, there are a couple of ways to do this:

1) right click, -> rating -> rejected

2) photos -> set rating -> rejected

3) just select the photo and press "9" on the keyboard

The article you reference is about Shotwell 0.4. Hopefully you will find the
answers to other questions you might have at: http://yorba.org/shotwell/help/

####

#12

Updated by Ivan Sagalaev 6 months ago

Joy, in the first comment (http://redmine.yorba.org/issues/3384#note-1) I
described all of the things that marking "Rejected" doesn't do for this
feature. So it's not really a good workaround.

####

#13

Updated by Jim Nelson 6 months ago

  * **Description** updated (diff)
  * **Category** set to _library-mode_

Weiwu, that wiki page is quite old -- it's describing Shotwell 0.4, and we
just released 0.14. I've marked the page (and other old reference material) as
out-of-date, although I won't delete it for archival purposes.



--- Bug imported by chaz@yorba.org 2013-11-25 21:51 UTC  ---

This bug was previously known as _bug_ 3384 at http://redmine.yorba.org/show_bug.cgi?id=3384

Unknown version " in product shotwell. 
   Setting version to "!unspecified".
Unknown milestone "unknown in product shotwell. 
   Setting to default milestone for this product, "---".
Setting qa contact to the default for this product.
   This bug either had no qa contact or an invalid one.
Resolution set on an open status.
   Dropping resolution 

Comment 1 Daniel Landau 2014-05-09 08:36:28 UTC
Instead of privacy filters, would a general "Saved filters" work for the commenters here? In my idea a saved filter would use the same ui for creation as the current saved searches, but applying a saved filter (or several) would work e.g. from the search bar instead of the side bar as is the case with the current saved searches.

I too have the need to not show everything to everyone and I do abuse the rating system for that purpose. Still I don't think that "photo privacy" is something that has a direct place in Shotwell. Especially password protecting or even encrypting would for me seem to be the responsibility of other programs, such as the Desktop Environment, LUKS or TrueCrypt etc. (Using separate user accounts for shotwell, using separate databases and photo storages with shotwell -d, etc).

Shotwell already has a tagging mechanism and a way to filter out tags (saved searches), so I think those could be enough. The saved search feature does not allow for explicit boolean operators, but there is a "contains/does-not-contain" option that can mostly simulate boolean operators.

I think the saved filters feature would in any case be useful, so unless there's strong opposition to it in general (not as a privacy tool) I'm going to go ahead and implement it and hopefully it satisfies the privacy need too.
Comment 2 Daniel Landau 2016-07-22 08:15:43 UTC
Created attachment 331966 [details] [review]
Add option to filter by saved search
Comment 3 Daniel Landau 2016-07-22 08:22:11 UTC
There is a non-squashed version at https://github.com/daniellandau/shotwell/tree/saved-filters.

Thank you Jens for taking up maintanenance, I hope you'll have time at some point to look at this.
Comment 4 Jens Georg 2016-07-22 10:02:10 UTC
Review of attachment 331966 [details] [review]:

Looks nice at a first glance, have to check how the popover looks in the ui.

In general, please try to avoid elements that were deprecated before GTK 3.12 such as Gtk.HBox and Gtk.Stock
Comment 5 Jens Georg 2016-07-22 10:02:11 UTC
Review of attachment 331966 [details] [review]:

Looks nice at a first glance, have to check how the popover looks in the ui.

In general, please try to avoid elements that were deprecated before GTK 3.12 such as Gtk.HBox and Gtk.Stock
Comment 6 Daniel Landau 2016-07-22 10:06:29 UTC
I did most of the work in the end of 2014 and wasn't sure back then if popover introduced in 3.12 was too new :)

Do you want me to change those?
Comment 7 Jens Georg 2016-07-22 11:21:13 UTC
The min version was (implicitly?) bumped to 3.12 some time ago and there are tickets open to remove all deprecated things until 3.10 so I think we should introduce already deprecated things in new code :)

Re Popover, I have to check how it fits in visually, but I don't expect isseus.
Comment 8 Daniel Landau 2016-07-22 11:54:28 UTC
Created attachment 331984 [details] [review]
Add option to filter by saved search

Removed the deprecated items (HBox and Stock)
Comment 9 Jens Georg 2016-07-22 17:05:51 UTC
- The popover feels inconsistent with the flagged popup menu next to it; it should either be a popover as well or this menu should be a normal popup
- I'm slightly confused how this differs from selecting the saved search on the sidebar
Comment 10 Daniel Landau 2016-07-22 17:20:14 UTC
To the first point I suggest making the rating menu a popover too. I didn't use a Menu for this because I wanted to have edit and delete buttons inline as well as an add button.

To the second point, this differs in that you can have a saved search filter an event or any other view. For example:

1. Look at an event but filter only unrated photos because you want to rate everything.
2. Look at photos but hide specific tags.
3. You have printouts of all the 5 star photos and you want to look at all the 3 and 4 star ones in an event/tag to select some to print out.

etc. Some of the use cases could be explicit features (such as show just unrated), but the possibile use cases are endless.
Comment 11 Daniel Landau 2016-07-23 09:20:55 UTC
In terms of moving from the menu to a popover for the rating filter, I feel it's better suited for https://bugzilla.gnome.org/show_bug.cgi?id=768271.
Comment 12 Jens Georg 2016-08-12 11:55:00 UTC
(In reply to Daniel Landau from comment #11)
> In terms of moving from the menu to a popover for the rating filter, I feel
> it's better suited for https://bugzilla.gnome.org/show_bug.cgi?id=768271.

Agree
Comment 13 Jens Georg 2016-08-12 11:58:13 UTC
Attachment 331984 [details] pushed as 5ccfd5d - Add option to filter by saved search