GNOME issueshttps://gitlab.gnome.org/groups/GNOME/-/issues2021-05-19T15:03:07Zhttps://gitlab.gnome.org/GNOME/shotwell/-/issues/3124exported camera-developed photo has wrong crop region2021-05-19T15:03:07ZBugzillaexported camera-developed photo has wrong crop region## Submitted by Adam Dingle
Assigned to **Eric Gregory**
**[Link to original bug (#717981)](https://bugzilla.gnome.org/show_bug.cgi?id=717981)**
## Description
---- Reported by adam@yorba.org 2011-08-30 04:32:00 -0700 ----
Ori...## Submitted by Adam Dingle
Assigned to **Eric Gregory**
**[Link to original bug (#717981)](https://bugzilla.gnome.org/show_bug.cgi?id=717981)**
## Description
---- Reported by adam@yorba.org 2011-08-30 04:32:00 -0700 ----
Original Redmine bug id: 4069
Original URL: http://redmine.yorba.org/issues/4069
Searchable id: yorba-bug-4069
Original author: Adam Dingle
Original description:
To see the problem:
1. Import this RAW photo into Shotwell:
http://www.yorba.org/download/scratch/crop_bug.cr2
This is a 3684 x 2760 photo with a 1600 x 1200 embedded JPEG.
2. Set the photo's developer to Camera.
3. Open the photo and crop it so that only the yellow building at the center
of the photo is visible.
4. Drag the photo to the desktop to export it. You'll see that the exported
photo contains only blue sky, not the yellow building.
Related issues:
* related to shotwell - 4055: Uploading to Picasa "loses" exposure tweaks (Fixed)
---- Additional Comments From shotwell-maint@gnome.bugs 2013-05-01 11:38:00 -0700 ----
### History
---
Comment 1
Updated by Lucas Beeler about 2 years ago
* **Category** set to _4_
* **Assignee** set to _Eric Gregory_
---
Comment 2
Updated by Eric Gregory about 2 years ago
* **Status** changed from _Open_ to _Review_
---
Comment 3
Updated by Jim Nelson about 2 years ago
* **Description** updated (diff)
---
Comment 4
Updated by Eric Gregory about 2 years ago
* **Description** updated (diff)
* **Status** changed from _Review_ to _5_
* **Resolution** set to _fixed_
Fixed in 17aaa5660ad635bb899afe50c2091acf6a37321b
---
Comment 5
Updated by Charles Lindsay 7 months ago
* **Status** changed from _5_ to _Fixed_
--- Bug imported by chaz@yorba.org 2013-11-25 21:54 UTC ---
This bug was previously known as _bug_ 4069 at http://redmine.yorba.org/show_bug.cgi?id=4069
Unknown Component
Using default product and component set in Parameters
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.
Version: 0.11.1
Resolution: RESOLVED FIXEDhttps://gitlab.gnome.org/GNOME/shotwell/-/issues/3123editing commands should not be available when photo file is missing2021-05-19T13:05:57ZBugzillaediting commands should not be available when photo file is missing## Submitted by Adam Dingle
**[Link to original bug (#717980)](https://bugzilla.gnome.org/show_bug.cgi?id=717980)**
## Description
---- Reported by adam@yorba.org 2011-08-30 06:56:00 -0700 ----
Original Redmine bug id: 4070
Or...## Submitted by Adam Dingle
**[Link to original bug (#717980)](https://bugzilla.gnome.org/show_bug.cgi?id=717980)**
## Description
---- Reported by adam@yorba.org 2011-08-30 06:56:00 -0700 ----
Original Redmine bug id: 4070
Original URL: http://redmine.yorba.org/issues/4070
Searchable id: yorba-bug-4070
Original author: Adam Dingle
Original description:
To see the problem:
1. # Import a photo in place.
1. # While Shotwell is still running, delete or rename the photo file.
1. # Open the photo in Shotwell. You'll see a black screen with a message "Photo source file missing: (filename)". In this view, notice that the Crop, Red-eye and Adjust buttons are enabled. They shouldn't be. In this view I've also sometimes seen that the Photos->Developer menu is erroneously enabled.
---- Additional Comments From shotwell-maint@gnome.bugs 2013-05-01 11:38:00 -0700 ----
### History
---
Comment 1
Updated by Jim Nelson about 2 years ago
* **Description** updated (diff)
* **Category** set to _4_
* **Target version** deleted (`<strike>`_0.12_`</strike>`)
---
Comment 2
Updated by Clinton Rogers over 1 year ago
* **Status** changed from _Open_ to _Review_
* **% Done** changed from _0_ to _70_
---
Comment 3
Updated by Adam Dingle over 1 year ago
* **Target version** set to _0.12_
---
Comment 4
Updated by Clinton Rogers over 1 year ago
* **Status** changed from _Review_ to _5_
* **% Done** changed from _70_ to _100_
* **Resolution** set to _fixed_
39206470dac77ed147314ce95b0fd826e000b5a3
---
Comment 5
Updated by Charles Lindsay 7 months ago
* **Status** changed from _5_ to _Fixed_
--- Bug imported by chaz@yorba.org 2013-11-25 21:54 UTC ---
This bug was previously known as _bug_ 4070 at http://redmine.yorba.org/show_bug.cgi?id=4070
Unknown Component
Using default product and component set in Parameters
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.
Version: 0.12
Resolution: RESOLVED FIXEDhttps://gitlab.gnome.org/GNOME/shotwell/-/issues/3122With metadata writing on, unwanted tags are generated when the user drags a c...2021-05-19T13:05:54ZBugzillaWith metadata writing on, unwanted tags are generated when the user drags a child tag to the top level.## Submitted by cli..@..ba.org
Assigned to **Lucas Beeler**
**[Link to original bug (#717979)](https://bugzilla.gnome.org/show_bug.cgi?id=717979)**
## Description
---- Reported by clinton@yorba.org 2011-08-30 15:05:00 -0700 ---...## Submitted by cli..@..ba.org
Assigned to **Lucas Beeler**
**[Link to original bug (#717979)](https://bugzilla.gnome.org/show_bug.cgi?id=717979)**
## Description
---- Reported by clinton@yorba.org 2011-08-30 15:05:00 -0700 ----
Original Redmine bug id: 4071
Original URL: http://redmine.yorba.org/issues/4071
Searchable id: yorba-bug-4071
Original author: Clinton Rogers
Original description:
Steps to reproduce:
With metadata writing enabled, import some metadata-capable photos that
contain no metadata.
Create a tag named 'a'.
Create a child tag under 'a' named 'b'.
Create a child tag under 'b' named 'c'.
At the top level, create a tag named 'b'.
Add at least one photograph to 'c'.
Add at least one photograph to the top level 'b'.
Drag the nested 'b' up to the 'Tags' tree item and drop it.
Notice that, frequently, incorrect and unwanted tags suddenly appear.
**NOTE:** the bug is not sensitive to what tags are named, so 'a', 'b' and 'c' may be replaced by any valid name.
Related issues:
* related to shotwell - 4074: When metadata writing is turned on, reimport
can cause HT... (Fixed)
* related to shotwell - 4096: "Hierarchical Subject" not updated when
metadata writing on (Fixed)
---- Additional Comments From shotwell-maint@gnome.bugs 2013-05-01 11:38:00 -0700 ----
### History
---
Comment 1
Updated by Clinton Rogers about 2 years ago
* **Description** updated (diff)
---
Comment 2
Updated by Jim Nelson about 2 years ago
* **Assignee** set to _Lucas Beeler_
---
Comment 3
Updated by Lucas Beeler about 2 years ago
* **Status** changed from _Open_ to _5_
* **Resolution** set to _fixed_
Fixed in 5da85af71ee77f4d8b9223ed017ed88001769970
---
Comment 4
Updated by Charles Lindsay 7 months ago
* **Status** changed from _5_ to _Fixed_
--- Bug imported by chaz@yorba.org 2013-11-25 21:54 UTC ---
This bug was previously known as _bug_ 4071 at http://redmine.yorba.org/show_bug.cgi?id=4071
Unknown Component
Using default product and component set in Parameters
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.
Version: 0.11.1
Resolution: RESOLVED FIXEDhttps://gitlab.gnome.org/GNOME/shotwell/-/issues/3121Shotwell preferences are lost when restarting Shotwell (GSettings 'default-se...2021-05-19T13:05:52ZBugzillaShotwell preferences are lost when restarting Shotwell (GSettings 'default-service' key)## Submitted by Eric Gregory
Assigned to **Jim Nelson**
**[Link to original bug (#717978)](https://bugzilla.gnome.org/show_bug.cgi?id=717978)**
## Description
---- Reported by eric@yorba.org 2011-08-30 15:54:00 -0700 ----
Orig...## Submitted by Eric Gregory
Assigned to **Jim Nelson**
**[Link to original bug (#717978)](https://bugzilla.gnome.org/show_bug.cgi?id=717978)**
## Description
---- Reported by eric@yorba.org 2011-08-30 15:54:00 -0700 ----
Original Redmine bug id: 4072
Original URL: http://redmine.yorba.org/issues/4072
Searchable id: yorba-bug-4072
Original author: Eric Gregory
Original description:
The default RAW developer in the Shotwell preferences has two states: Camera
and Shotwell. Shotwell is the default.
For some reason, every few times you start Shotwell and examine the
preferences, it gets set to Shotwell. Note that this does not reproduce every
single time.
**UPDATE:**
This actually happens to other settings, but it's not every time. It seems
the GConf->GSettings data migration dies every time, so it's never considered
"complete." This causes Shotwell to stomp on my settings every time I restart
Shotwell.
%{=display: none;} %Here's the error from the debug log:
bq.
Starting program: /home/eric/Development/shotwell/shotwell
[Thread debugging using libthread_db enabled]
* (process:16469): DEBUG: GConfEngine.vala:191: Converting GConf settings to gsettings...
* Message: GConfEngine.vala:201: Error 6 running gsettings-data-convert: stdout="" stderr="
GLib-GIO-ERROR **: Settings schema 'org.yorba.shotwell.sharing' does not
contain a key named 'default-service'
aborting...
"
* (process:16469): DEBUG: GConfEngine.vala:205: GConf to gsettings conversion completed%{=display: none;} %%{=display: none;} %
Related issues:
* related to shotwell - 4073: GLib-GIO-ERROR causing system start-up delay
with latest ... (Fixed)
---- Additional Comments From shotwell-maint@gnome.bugs 2013-05-01 11:38:00 -0700 ----
### History
---
Comment 1
Updated by Eric Gregory about 2 years ago
* **Subject** changed from _Default RAW developer gets reset to Shotwell_ to _Shotwell preferences are lost when restarting Shotwell (GSettings 'default-service' key)_
* **Description** updated (diff)
Updated description to reflect problem.
---
Comment 2
Updated by Eric Gregory about 2 years ago
* **Assignee** deleted (`<strike>`_Eric Gregory_`</strike>`)
---
Comment 3
Updated by Jim Nelson about 2 years ago
* **Category** set to _4_
* **Assignee** set to _Jim Nelson_
---
Comment 4
Updated by Jim Nelson about 2 years ago
* **Status** changed from _Open_ to _5_
* **Resolution** set to _fixed_
Eric checked and the patch for #4073 does solve the Preferences problem, so
closing this ticket.
---
Comment 5
Updated by Charles Lindsay 7 months ago
* **Status** changed from _5_ to _Fixed_
--- Bug imported by chaz@yorba.org 2013-11-25 21:54 UTC ---
This bug was previously known as _bug_ 4072 at http://redmine.yorba.org/show_bug.cgi?id=4072
Unknown Component
Using default product and component set in Parameters
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.
Version: 0.11.1
Resolution: RESOLVED FIXEDhttps://gitlab.gnome.org/GNOME/shotwell/-/issues/3120GLib-GIO-ERROR causing system start-up delay with latest release2021-05-19T13:05:50ZBugzillaGLib-GIO-ERROR causing system start-up delay with latest release## Submitted by an unknown user
Assigned to **Jim Nelson**
**[Link to original bug (#717977)](https://bugzilla.gnome.org/show_bug.cgi?id=717977)**
## Description
---- Reported by shotwell-maint@gnome.bugs 2011-08-30 16:21:00 -0...## Submitted by an unknown user
Assigned to **Jim Nelson**
**[Link to original bug (#717977)](https://bugzilla.gnome.org/show_bug.cgi?id=717977)**
## Description
---- Reported by shotwell-maint@gnome.bugs 2011-08-30 16:21:00 -0700 ----
Original Redmine bug id: 4073
Original URL: http://redmine.yorba.org/issues/4073
Searchable id: yorba-bug-4073
Original author: Forage -
Original description:
Hi,
An error is occurring right after logging in, causing quite a significant
start-up delay. This started to happen after I updated Shotwell to version
0.11 from https://launchpad.net/~yorba/+archive/ppa
Because my system seems to hang for a short while right after logging in I
started looking at the logs and in syslog I found:
_Aug 31 00:23:37 Khazad-dum gnome-session1912: WARNING: Application
'gsettings-data-convert.desktop' failed to register before timeout_
This let me to perform _gsettings-data-convert_ manually in the terminal,
resulting in:
_$ gsettings-data-convert
GLib-GIO-ERROR **: Settings schema 'org.yorba.shotwell.sharing' does not
contain a key named 'default-service'
aborting...
Aborted_
This is the cause of the system freeze as far as I can tell since I can't find
any other obvious problems in the logs.
Version: Shotwell 0.11
OS: Ubuntu 11.04 (x86)
Also: When I updated Shotwell I found to weird that it required a system
reboot to complete. This should never be required for such an application,
should it?
Let me know if you need any more information.
Related issues:
* related to shotwell - 4056: Ensure all publishing keys are converted from
GConf to GS... (Fixed)
* related to shotwell - 3981: [norepro] Crashes on startup with assertion
failure in so... (Fixed)
* related to shotwell - 4072: Shotwell preferences are lost when restarting
Shotwell (G... (Fixed)
---- Additional Comments From shotwell-maint@gnome.bugs 2013-05-01 11:38:00 -0700 ----
### History
---
Comment 1
Updated by Jim Nelson about 2 years ago
* **Priority** changed from _Normal_ to _High_
* **Target version** set to _0.11.1_
We've seen something similar to this in #3981 (which is an unrelated bug, so
this problem is ticketed in #4056). I thought maybe this had to do with
running Shotwell from its build directory, but as you upgraded from our PPA,
that's not the issue.
Do you happen to know what version of Shotwell you were running before you
upgraded?
Also, you're correct, you shouldn't have to reboot your system when you
install Shotwell. Is it possible other packages were installed by Synaptic as
well, and that they required the reboot?
Also, I don't know why your login is taking so long. It looks like a
gsettings-data-convert problem. We don't execute the program until you run
Shotwell.
---
Comment 2
Updated by Forage - about 2 years ago
Before the update I had version 0.10 installed, also from the same PPA. I
checked the history and Shotwell was the only package installed/updated that
day (August 25). No other installations nor updates where done on the day
before and the day after, so it has to be Shotwell requiring the reboot.
Right after the update, the indicator icon of the menu with the logout-
shutdown options turned red, meaning a reboot is required. Running GNOME-
classic by the way, not GNOME Shell or Unity.
---
Comment 3
Updated by Jim Nelson about 2 years ago
Ok -- thanks for the info, this will help us repro it here and get a fix out!
---
Comment 4
Updated by Jim Nelson about 2 years ago
* **Assignee** set to _Jim Nelson_
---
Comment 5
Updated by Jim Nelson about 2 years ago
* **Status** changed from _Open_ to _5_
* **Resolution** set to _fixed_
Fixed in r05ac3bb538dd3f402c3c243204b6973d28b6a07f The default-service
element wasn't present in the gsettings schema, causing gsettings-data-convert
to yarf every time.
This **might** fix #4072, but I can't reproduce that problem to begin with.
(Eric, can you try reproing it with the latest trunk?) This might also close
#4056, but more investigation is required.
Forage, I don't know if you can download our trunk and build and test
yourself, but you're welcome to try. I was able to reproduce the problem here
and this patch fixes it. So, if you can't, this should be solved in 0.11.1.
---
Comment 6
Updated by Forage - about 2 years ago
Thanks for fixing this Jim.
I can build and test it myself no problem, but I'm always hesitant to replace
exiting software with self-compiled versions. Installing it next to the
existing Shotwell is no option in this case. I'd rather wait for 0.11.1, which
I assume won't take weeks to be released.
P.s. please disable the CKeditor in this issue tracker. It's a PITA to use and
it makes the update e-mails pretty much useless with all the HTML code
included ;-)
---
Comment 7
Updated by Jim Nelson about 2 years ago
Understood, Forage. Can't give you a specific date when 0.11.1 will be out,
but hopefully it's sooner rather than later.
Removing CKEditor is definitely something we want to do:
[#3878](http://redmine.yorba.org/issues/3878 ) Unfortunately we're short-
staffed right now and working hard to get 0.11.1 out the door.
---
Comment 8
Updated by Forage - about 2 years ago
Fix confirmed to work, thanks! No more 10 sec wait when logging in.
Also, no reboot required when updating this time.
---
Comment 9
Updated by Charles Lindsay 7 months ago
* **Status** changed from _5_ to _Fixed_
--- Bug imported by chaz@yorba.org 2013-11-25 21:54 UTC ---
This bug was previously known as _bug_ 4073 at http://redmine.yorba.org/show_bug.cgi?id=4073
Unknown Component
Using default product and component set in Parameters
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.
Version: 0.11.1
Resolution: RESOLVED FIXEDhttps://gitlab.gnome.org/GNOME/shotwell/-/issues/3119When metadata writing is turned on, reimport can cause HTags to reappear as f...2021-05-19T13:05:48ZBugzillaWhen metadata writing is turned on, reimport can cause HTags to reappear as flat tags## Submitted by Lucas Beeler
Assigned to **Lucas Beeler**
**[Link to original bug (#717976)](https://bugzilla.gnome.org/show_bug.cgi?id=717976)**
## Description
---- Reported by lucas@yorba.org 2011-08-30 17:32:00 -0700 ----
O...## Submitted by Lucas Beeler
Assigned to **Lucas Beeler**
**[Link to original bug (#717976)](https://bugzilla.gnome.org/show_bug.cgi?id=717976)**
## Description
---- Reported by lucas@yorba.org 2011-08-30 17:32:00 -0700 ----
Original Redmine bug id: 4074
Original URL: http://redmine.yorba.org/issues/4074
Searchable id: yorba-bug-4074
Original author: Lucas Beeler
Original description:
None
Related issues:
* related to shotwell - 4071: With metadata writing on, unwanted tags are
generated whe... (Fixed)
* related to shotwell - 4081: F-Spot import creates both top-level and
hierarchical tag... (Fixed)
* related to shotwell - 4096: "Hierarchical Subject" not updated when
metadata writing on (Fixed)
---- Additional Comments From shotwell-maint@gnome.bugs 2013-05-01 11:38:00 -0700 ----
### History
---
Comment 1
Updated by Lucas Beeler about 2 years ago
* **Status** changed from _Open_ to _5_
* **Resolution** set to _fixed_
Fixed in 5da85af71ee77f4d8b9223ed017ed88001769970
---
Comment 2
Updated by Charles Lindsay 7 months ago
* **Status** changed from _5_ to _Fixed_
--- Bug imported by chaz@yorba.org 2013-11-25 21:54 UTC ---
This bug was previously known as _bug_ 4074 at http://redmine.yorba.org/show_bug.cgi?id=4074
Unknown Component
Using default product and component set in Parameters
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.
Version: 0.11.1
Resolution: RESOLVED FIXEDhttps://gitlab.gnome.org/GNOME/shotwell/-/issues/3118Tags: keystrokes become ignored after Shotwell loses, then regains focus whil...2021-05-19T13:05:46ZBugzillaTags: keystrokes become ignored after Shotwell loses, then regains focus while a tag name is open for editing.## Submitted by cli..@..ba.org
**[Link to original bug (#717975)](https://bugzilla.gnome.org/show_bug.cgi?id=717975)**
## Description
---- Reported by clinton@yorba.org 2011-08-30 18:52:00 -0700 ----
Original Redmine bug id: 407...## Submitted by cli..@..ba.org
**[Link to original bug (#717975)](https://bugzilla.gnome.org/show_bug.cgi?id=717975)**
## Description
---- Reported by clinton@yorba.org 2011-08-30 18:52:00 -0700 ----
Original Redmine bug id: 4075
Original URL: http://redmine.yorba.org/issues/4075
Searchable id: yorba-bug-4075
Original author: Clinton Rogers
Original description:
Steps to reproduce:
In Shotwell, click on an already selected tag. Notice that the tag name is now
in 'edit' mode and can be typed into.
Alt-Tab away from Shotwell.
Alt-Tab back to Shotwell.
Attempt to type in the tag name from step one.
Notice that, even though the tag name is still highlighted, it can no longer
be typed into.
---- Additional Comments From shotwell-maint@gnome.bugs 2013-05-01 11:46:00 -0700 ----
### History
---
Comment 1
Updated by Clinton Rogers about 2 years ago
Further experimentation reveals that, when this occurs, the following is
displayed in the console:
(shotwell:24187): Gtk-CRITICAL **: IA__gtk_widget_has_focus: assertion
`GTK_IS_WIDGET (widget)' failed
(shotwell:24187): GLib-GObject-CRITICAL **: g_object_get: assertion
`G_IS_OBJECT (object)' failed
---
Comment 2
Updated by Clinton Rogers about 2 years ago
* **Assignee** set to _Clinton Rogers_
* **Target version** set to _0.11.1_
---
Comment 3
Updated by Clinton Rogers about 2 years ago
* **Assignee** deleted (`<strike>`_Clinton Rogers_`</strike>`)
* **Target version** changed from _0.11.1_ to _0.12_
---
Comment 4
Updated by Adam Dingle about 2 years ago
* **Description** updated (diff)
* **Status** changed from _Open_ to _5_
* **Resolution** set to _wontfix_
In git master I no longer see these assertions. I think the Alt+Tab behavior
is so minor that it's not worth trying to fix.
---
Comment 5
Updated by Charles Lindsay 7 months ago
* **Status** changed from _5_ to _Invalid_
--- Bug imported by chaz@yorba.org 2013-11-25 21:54 UTC ---
This bug was previously known as _bug_ 4075 at http://redmine.yorba.org/show_bug.cgi?id=4075
Unknown Component
Using default product and component set in Parameters
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.
Version: 0.12
Resolution: RESOLVED INVALIDhttps://gitlab.gnome.org/GNOME/shotwell/-/issues/3117single click should no longer edit a tag name2021-05-19T13:05:44ZBugzillasingle click should no longer edit a tag name## Submitted by Lucas Beeler
Assigned to **cli..@..ba.org**
**[Link to original bug (#717974)](https://bugzilla.gnome.org/show_bug.cgi?id=717974)**
## Description
---- Reported by lucas@yorba.org 2011-08-30 19:43:00 -0700 ----
...## Submitted by Lucas Beeler
Assigned to **cli..@..ba.org**
**[Link to original bug (#717974)](https://bugzilla.gnome.org/show_bug.cgi?id=717974)**
## Description
---- Reported by lucas@yorba.org 2011-08-30 19:43:00 -0700 ----
Original Redmine bug id: 4076
Original URL: http://redmine.yorba.org/issues/4076
Searchable id: yorba-bug-4076
Original author: Lucas Beeler
Original description:
A single mouse-down event on a tag that's selected in the sidebar currently
edits the name of the tag. This was fine when tags were flat, but with HTags
it interferes with drag-and-drop. We should consider making a double-click the
edit trigger instead of a single-click.
Related issues:
* related to shotwell - 4085: Non-rename rename winds up on the undo stack (Fixed)
---- Additional Comments From shotwell-maint@gnome.bugs 2013-05-01 11:38:00 -0700 ----
### History
---
Comment 1
Updated by Adam Dingle about 2 years ago
* **Target version** changed from _0.12_ to _0.11.1_
I agree we need to change this: I've also noticed the interference with drag
and drop, and it will be even worse when we support multi-select (#2275). I
don't know that there's precedent in the GNOME world for a double click
meaning a rename, however. I might be inclined to take a different path: if
you want to rename a tag, you need to right click and choose Rename from a
context menu, or press F2. That's how Nautilus works, by the way. Could we
simply do that for 0.11.1?
---
Comment 2
Updated by Adam Dingle about 2 years ago
* **Subject** changed from _Move from single-click editing to double-click editing of selected tags_ to _single click should no longer edit a tag name_
---
Comment 3
Updated by Lucas Beeler about 2 years ago
* **Assignee** set to _Clinton Rogers_
Agreed, Adam. Let's follow the lead of Nautilus here. Double-click to edit is
an artifact of my growing up with the classic Mac OS, so while its expected
for Lucas Beeler, it might not be expected for GNOME users at large.
Also assigning this ticket to Clinton, since he's almost finished his work on
#3887 and it'd be great to have him work on a code-related ticket (as opposed
to just docs) for 0.11.1.
---
Comment 4
Updated by Clinton Rogers about 2 years ago
* **Status** changed from _Open_ to _Review_
Patch submitted via email.
As written, however, it introduces a UI inconsistency, since now events can be
renamed with a single click, but tags (and future drag-source tree entries)
can't be; please let me know if you'd like something different here.
---
Comment 5
Updated by Adam Dingle about 2 years ago
I think we should be consistent through the entire sidebar tree: a single
click should no longer rename anything.
---
Comment 6
Updated by Clinton Rogers about 2 years ago
* **Status** changed from _Review_ to _5_
* **Resolution** set to _fixed_
22f8b1fdf900d0e10cbcc430b6845d13179bf40a
---
Comment 7
Updated by Charles Lindsay 7 months ago
* **Status** changed from _5_ to _Fixed_
--- Bug imported by chaz@yorba.org 2013-11-25 21:54 UTC ---
This bug was previously known as _bug_ 4076 at http://redmine.yorba.org/show_bug.cgi?id=4076
Unknown Component
Using default product and component set in Parameters
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.
Version: 0.11.1
Resolution: RESOLVED FIXEDhttps://gitlab.gnome.org/GNOME/shotwell/-/issues/3116JPEG from trashed RAW+JPEG or editable is auto-imported on startup2021-05-19T13:05:42ZBugzillaJPEG from trashed RAW+JPEG or editable is auto-imported on startup## Submitted by Adam Dingle
Assigned to **Eric Gregory**
**[Link to original bug (#717973)](https://bugzilla.gnome.org/show_bug.cgi?id=717973)**
## Description
---- Reported by adam@yorba.org 2011-08-30 23:20:00 -0700 ----
Ori...## Submitted by Adam Dingle
Assigned to **Eric Gregory**
**[Link to original bug (#717973)](https://bugzilla.gnome.org/show_bug.cgi?id=717973)**
## Description
---- Reported by adam@yorba.org 2011-08-30 23:20:00 -0700 ----
Original Redmine bug id: 4077
Original URL: http://redmine.yorba.org/issues/4077
Searchable id: yorba-bug-4077
Original author: Adam Dingle
Original description:
Maximilian B reported this on the mailing list:
1. enable watch library directory for new files
2. set RAW developer default to camera
3. import paired RAW+JPEG
4. press DEL key to trash a paired photo
5. close and restart shotwell
6. trashed RAW will appear in trash, JPEG will be discovered and a new
event will be created containing that JPEG
(7. empty trash will remove both files from library and filesystem)
I see this too. When I tried this, I had the default developer set to Camera;
in step 6, Shotwell also auto-imported the _embedded.jpg file as a separate
photo (which showed up in No Event).
---- Additional Comments From shotwell-maint@gnome.bugs 2013-05-01 11:38:00 -0700 ----
### History
---
Comment 1
Updated by Eric Gregory about 2 years ago
* **Category** set to _4_
* **Assignee** set to _Eric Gregory_
* **Keywords** set to _raw_
---
Comment 2
Updated by Eric Gregory about 2 years ago
* **Subject** changed from _JPEG from trashed RAW+JPEG is auto-imported on startup_ to _JPEG from trashed RAW+JPEG or editable is auto-imported on startup_
* **Keywords** changed from _raw_ to _raw, editables, trash, offline_
Update: this is part of a larger issue. Offline and trash holding tanks don't
know anything about "backing files," whether they be editables or RAW
developments. You can see the same problem with editables with the following
steps:
Enable library monitor
Import a photo and edit it with Gimp
Move the photo to the trash
Restart Shotwell
You'll now see the edited "_modified" file imported as a new photo.
---
Comment 3
Updated by Eric Gregory about 2 years ago
* **Status** changed from _Open_ to _Review_
---
Comment 4
Updated by Eric Gregory about 2 years ago
* **Status** changed from _Review_ to _5_
* **Resolution** set to _fixed_
Fixed in 036071b3db2ce6e6d55aa5057c2025feb702e448
---
Comment 5
Updated by Charles Lindsay 7 months ago
* **Status** changed from _5_ to _Fixed_
--- Bug imported by chaz@yorba.org 2013-11-25 21:54 UTC ---
This bug was previously known as _bug_ 4077 at http://redmine.yorba.org/show_bug.cgi?id=4077
Unknown Component
Using default product and component set in Parameters
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.
Version: 0.11.1
Resolution: RESOLVED FIXEDhttps://gitlab.gnome.org/GNOME/shotwell/-/issues/3115Repeatable crash on vewing original of (even unmodified) RAW images2021-05-19T13:05:40ZBugzillaRepeatable crash on vewing original of (even unmodified) RAW images## Submitted by an unknown user
Assigned to **Eric Gregory**
**[Link to original bug (#717972)](https://bugzilla.gnome.org/show_bug.cgi?id=717972)**
## Description
---- Reported by shotwell-maint@gnome.bugs 2011-08-30 23:33:00 ...## Submitted by an unknown user
Assigned to **Eric Gregory**
**[Link to original bug (#717972)](https://bugzilla.gnome.org/show_bug.cgi?id=717972)**
## Description
---- Reported by shotwell-maint@gnome.bugs 2011-08-30 23:33:00 -0700 ----
Original Redmine bug id: 4078
Original URL: http://redmine.yorba.org/issues/4078
Searchable id: yorba-bug-4078
Original author: Alex Vandiver
Original description:
Images were originally imported with Shotwell 0.9.3, from Ubuntu Natty. After
upgrading to 0.11.0 from the PPA, pressing shift when viewing a RAW image
causes a repeatable crash. This happens even if the image has not been
modified in Shotwell in any way. The crash crash does _not_ occur with the
.JPG version of the image which was imported at the same time.
Related issues:
* related to shotwell - 4062: JPEG mimic created only when switching
developers (Fixed)
---- Additional Comments From shotwell-maint@gnome.bugs 2013-05-01 11:38:00 -0700 ----
### History
---
Comment 1
Updated by Adam Dingle about 2 years ago
* **Priority** changed from _High_ to _Urgent_
* **Target version** set to _0.11.1_
Thanks for the bug report. I can reproduce this in the current trunk:
1. # Make sure that the RAW Developer preference is set to Shotwell.
1. # Import a RAW photo from disk.
1. # Open the RAW photo in Shotwell.
1. # Press Shift. Shotwell will crash.
This happens only if the default RAW Developer is Shotwell, not Camera. (I
suspect this crash may be a side effect of #4062: perhaps the JPEG mimic is
expected to exist but is absent, causing the crash.)
---
Comment 2
Updated by Lucas Beeler about 2 years ago
* **Category** set to _4_
* **Assignee** set to _Eric Gregory_
Hey Eric, can you take this on since you're the RAW developer guy? It's a
crasher, so let's prioritize it.
---
Comment 3
Updated by Eric Gregory about 2 years ago
Looks like Adam's comment is spot on. This only occurs when there's no
Shotwell-developed JPEG on disk.
---
Comment 4
Updated by Eric Gregory about 2 years ago
* **Status** changed from _Open_ to _Review_
---
Comment 5
Updated by Eric Gregory about 2 years ago
Fixed in e49c6d75529e56a8997283de6e3a67be8aac95a4 with #4062
---
Comment 6
Updated by Eric Gregory about 2 years ago
* **Status** changed from _Review_ to _5_
* **Resolution** set to _fixed_
---
Comment 7
Updated by Charles Lindsay 7 months ago
* **Status** changed from _5_ to _Fixed_
--- Bug imported by chaz@yorba.org 2013-11-25 21:54 UTC ---
This bug was previously known as _bug_ 4078 at http://redmine.yorba.org/show_bug.cgi?id=4078
Imported an attachment (id=262161)
Imported an attachment (id=262162)
Unknown Component
Using default product and component set in Parameters
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.
Version: 0.11.1
Resolution: RESOLVED FIXEDhttps://gitlab.gnome.org/GNOME/shotwell/-/issues/3114dragging RAW and JPEG from Nautilus yields RAW+JPEG2021-05-19T13:05:38ZBugzilladragging RAW and JPEG from Nautilus yields RAW+JPEG## Submitted by Adam Dingle
Assigned to **Eric Gregory**
**[Link to original bug (#717971)](https://bugzilla.gnome.org/show_bug.cgi?id=717971)**
## Description
---- Reported by adam@yorba.org 2011-08-30 23:48:00 -0700 ----
Ori...## Submitted by Adam Dingle
Assigned to **Eric Gregory**
**[Link to original bug (#717971)](https://bugzilla.gnome.org/show_bug.cgi?id=717971)**
## Description
---- Reported by adam@yorba.org 2011-08-30 23:48:00 -0700 ----
Original Redmine bug id: 4079
Original URL: http://redmine.yorba.org/issues/4079
Searchable id: yorba-bug-4079
Original author: Adam Dingle
Original description:
Here's an oddity: In Nautilus, select a RAW photo and a JPEG photo that have
the same basename and are in the same folder. Drag them into Shotwell.
You'll end up with a RAW+JPEG photo, despite the face that Shotwell is really
only supposed to import RAW+JPEG from cameras at this point!
Strictly speaking this is a bug, since I think that dragging in the containing
folder (which will import the RAW and JPEG photos separately) should be
equivalent to dragging in the files themselves. I'm slightly tempted not to
fix this, however, since it is a convenient hack for testing RAW+JPEG even if
you don't happen to have a RAW-capable camera handy.
Related issues:
* related to shotwell - 3977: can't import RAW+JPEG from folder (Fixed)
* related to shotwell - Task #4061: document RAW+JPEG and RAW developer
selection (Fixed)
---- Additional Comments From shotwell-maint@gnome.bugs 2013-05-01 11:45:00 -0700 ----
### History
---
Comment 1
Updated by Adam Dingle about 2 years ago
Hm - this even works for groups of files. If I select all files in a folder
which contains lots of RAW+JPEG pairs and drag them all together into
Shotwell, then Shotwell actually imports them all as RAW+JPEG pairs.
---
Comment 2
Updated by Lucas Beeler about 2 years ago
I'm inclined to call this a feature, not a bug. But I won't mark it as wontfix
until the team can discuss it tomorrow.
---
Comment 3
Updated by Jim Nelson about 2 years ago
* **Category** set to _4_
However, if you drag in the folder containing the files, they won't be paired.
---
Comment 4
Updated by Jim Nelson about 2 years ago
* **Assignee** set to _Eric Gregory_
---
Comment 5
Updated by Eric Gregory about 2 years ago
* **Status** changed from _Open_ to _Review_
---
Comment 6
Updated by Eric Gregory about 2 years ago
* **Status** changed from _Review_ to _5_
* **Resolution** set to _invalid_
Rather than fixing this, we decided this was the expected behavior and patched
things up so importing from a folder (see #3977) worked as well.
---
Comment 7
Updated by Charles Lindsay 7 months ago
* **Status** changed from _5_ to _Invalid_
--- Bug imported by chaz@yorba.org 2013-11-25 21:54 UTC ---
This bug was previously known as _bug_ 4079 at http://redmine.yorba.org/show_bug.cgi?id=4079
Unknown Component
Using default product and component set in Parameters
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.
Version: 0.11.1
Resolution: RESOLVED INVALIDhttps://gitlab.gnome.org/GNOME/shotwell/-/issues/3113F-Spot import creates both top-level and hierarchical tags if tags present in...2021-05-19T13:05:37ZBugzillaF-Spot import creates both top-level and hierarchical tags if tags present in files## Submitted by Adam Dingle
Assigned to **Lucas Beeler**
**[Link to original bug (#717970)](https://bugzilla.gnome.org/show_bug.cgi?id=717970)**
## Description
---- Reported by adam@yorba.org 2011-08-31 01:12:00 -0700 ----
Ori...## Submitted by Adam Dingle
Assigned to **Lucas Beeler**
**[Link to original bug (#717970)](https://bugzilla.gnome.org/show_bug.cgi?id=717970)**
## Description
---- Reported by adam@yorba.org 2011-08-31 01:12:00 -0700 ----
Original Redmine bug id: 4081
Original URL: http://redmine.yorba.org/issues/4081
Searchable id: yorba-bug-4081
Original author: Adam Dingle
Original description:
Suppose that an F-Spot user has enabled the preference to store tags inside
photo files, and that the user has created hierarchical tags in F-Spot. When
Shotwell imports from the F-Spot database, it will create two copies of each
hierarchical tag: one inside the tag hierarchy and one at top level. This
makes F-Spot import pretty much unusable for any F-Spot user who's storing
tags inside photo files (as many users do, I'm sure.)
I hope we can find some solution to this for 0.11.1. Perhaps when importing
from F-Spot we can ignore tags present in the photo files and only use tags
from the F-Spot database. I fear, however, that the Shotwell startup scan
might notice the non-hierarchical tags in the photo files (F-Spot doesn't
write out the tag hierarchy to photo metadata, by the way) and once again try
to recreate the top-level tags. If that's the case, we may need to implement
#4051 at least partially in order to fix this.
Related issues:
* related to shotwell - 4051: imported non-hierarchical tag should match
existing hiera... (Fixed)
* related to shotwell - 4074: When metadata writing is turned on, reimport
can cause HT... (Fixed)
* related to shotwell - 4090: crash after f-spot import. (Fixed)
---- Additional Comments From shotwell-maint@gnome.bugs 2013-05-01 11:38:00 -0700 ----
### History
---
Comment 1
Updated by Jim Nelson about 2 years ago
Lucas believes this might be related to #4074. Hopefully we can knock these
two (and possibly #4071) out in one go.
---
Comment 2
Updated by Jim Nelson about 2 years ago
* **Category** set to _4_
* **Assignee** set to _Lucas Beeler_
---
Comment 3
Updated by Lucas Beeler about 2 years ago
* **Status** changed from _Open_ to _5_
* **Resolution** set to _fixed_
Fixed in c59cc117b1aa89fe6e71f638ef5f1aae14546ebf and
2aca73567a01d176ba69de6222cb57590d1a1cfe
---
Comment 4
Updated by Adam Dingle about 2 years ago
* **Status** changed from _5_ to _Open_
* **Target version** changed from _0.11.1_ to _0.11.2_
* **Resolution** deleted (`<strike>`_fixed_`</strike>`)
A user on the mailing list reported that this bug was still present in 0.11.1.
I just tried this myself and he's right: the bug is still there. To see this:
1. In F-Spot, make sure that the option "Store tags and descriptions -> Inside
the image files" is on.
2. In F-Spot, create a parent and a child tag. Assign the parent tag to one
photo and the child tag to another.
3. Import into Shotwell. Shotwell will create the child tag twice: both in
its proper position and also at top level.
---
Comment 5
Updated by Jim Nelson about 2 years ago
The user has supplied screenshots, EXIF dumps, and sample files here:
http://lists.yorba.org/pipermail/shotwell/2011-September/002950.html
---
Comment 6
Updated by Jim Nelson about 2 years ago
* **Assignee** changed from _Lucas Beeler_ to _Clinton Rogers_
Lucas is having trouble reproducing this at home. We've asked the reporter to
send a full Shotwell log. In the meantime, I've asked Clinton to attempt to
reproduce this here in the office.
---
Comment 7
Updated by Jim Nelson about 2 years ago
* **Assignee** changed from _Clinton Rogers_ to _Lucas Beeler_
Just as I wrote the last entry the reporter wrote back that he now couldn't
reproduce the problem, but after a little investigation realized what was
going on:
http://lists.yorba.org/pipermail/shotwell/2011-September/002966.html
Reassigning to Lucas, as now we should have enough information to reproduce
this behavior in house. From his description it seems there is still an issue
when multiple metadata fields are filled in with keywords from F-Spot.
---
Comment 8
Updated by Lucas Beeler about 2 years ago
* **Status** changed from _Open_ to _5_
* **Resolution** set to _fixed_
Very subtle, but fixed in 55f54e6c1a9274e252160a094673f3a144b114b0
---
Comment 9
Updated by Charles Lindsay 7 months ago
* **Status** changed from _5_ to _Fixed_
--- Bug imported by chaz@yorba.org 2013-11-25 21:54 UTC ---
This bug was previously known as _bug_ 4081 at http://redmine.yorba.org/show_bug.cgi?id=4081
Unknown Component
Using default product and component set in Parameters
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.
Version: 0.11.2
Resolution: RESOLVED FIXEDhttps://gitlab.gnome.org/GNOME/shotwell/-/issues/3112Corrupted POT file in the repository2021-05-19T13:05:35ZBugzillaCorrupted POT file in the repository## Submitted by an unknown user
Assigned to **Lucas Beeler**
**[Link to original bug (#717969)](https://bugzilla.gnome.org/show_bug.cgi?id=717969)**
## Description
---- Reported by shotwell-maint@gnome.bugs 2011-08-31 02:27:00 ...## Submitted by an unknown user
Assigned to **Lucas Beeler**
**[Link to original bug (#717969)](https://bugzilla.gnome.org/show_bug.cgi?id=717969)**
## Description
---- Reported by shotwell-maint@gnome.bugs 2011-08-31 02:27:00 -0700 ----
Original Redmine bug id: 4082
Original URL: http://redmine.yorba.org/issues/4082
Searchable id: yorba-bug-4082
Original author: Milo Casagrande
Original description:
While fixing translations for Ubuntu, I spotted an error in the POT file under
po/shotwell-core/ for Shotwell 0.11 (but I see it also in master).
The error is this one:
#: src/Dialogs.vala:1283
msgid "Set _all photos/videos to this time"
msgstr ""%m/%d/%Y, %I:%M:%S %p
I think that maybe regenerating the POT file should fix that.
---- Additional Comments From shotwell-maint@gnome.bugs 2013-05-01 11:38:00 -0700 ----
### History
---
Comment 1
Updated by Adam Dingle about 2 years ago
* **Assignee** set to _Lucas Beeler_
* **Priority** changed from _Normal_ to _High_
* **Target version** set to _0.11.1_
---
Comment 2
Updated by Lucas Beeler about 2 years ago
* **Category** set to _4_
* **Status** changed from _Open_ to _5_
* **Resolution** set to _fixed_
Fixed in 3bb4adaca2cbce53e67431a86051bcff69f7dc90
---
Comment 3
Updated by Charles Lindsay 7 months ago
* **Status** changed from _5_ to _Fixed_
--- Bug imported by chaz@yorba.org 2013-11-25 21:54 UTC ---
This bug was previously known as _bug_ 4082 at http://redmine.yorba.org/show_bug.cgi?id=4082
Unknown Component
Using default product and component set in Parameters
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.
Version: 0.11.1
Resolution: RESOLVED FIXEDhttps://gitlab.gnome.org/GNOME/shotwell/-/issues/3111make cropping aspect ratio more persistent2021-05-19T13:05:32ZBugzillamake cropping aspect ratio more persistent## Submitted by an unknown user
**[Link to original bug (#717968)](https://bugzilla.gnome.org/show_bug.cgi?id=717968)**
## Description
---- Reported by shotwell-maint@gnome.bugs 2011-08-31 03:38:00 -0700 ----
Original Redmine bu...## Submitted by an unknown user
**[Link to original bug (#717968)](https://bugzilla.gnome.org/show_bug.cgi?id=717968)**
## Description
---- Reported by shotwell-maint@gnome.bugs 2011-08-31 03:38:00 -0700 ----
Original Redmine bug id: 4083
Original URL: http://redmine.yorba.org/issues/4083
Searchable id: yorba-bug-4083
Original author: Florian K
Original description:
I'd like to be able to do this:
* Set the aspect ratio for cropping.
* Go through my pictures and easily crop the pictures to the chosen aspect ratio.
See F-Spot for a quite comfortable implementation. (Just keeping last chosen
aspect ratio and automatically initiating cropping tool when dragging on a
picture)
Related issues:
duplicates shotwell - Feature #3566: remember last used crop ratio (Fixed)
---- Additional Comments From shotwell-maint@gnome.bugs 2013-05-01 11:46:00 -0700 ----
### History
---
Comment 1
Updated by Adam Dingle about 2 years ago
* **Status** changed from _Open_ to _5_
* **Resolution** set to _duplicate_
A duplicate of #3566.
---
Comment 2
Updated by Florian K about 2 years ago
Searched for "aspect ratio" and didn't find 3566. Sorry for the noise...
---
Comment 3
Updated by Charles Lindsay 7 months ago
* **Status** changed from _5_ to _Duplicate_
--- Bug imported by chaz@yorba.org 2013-11-25 21:54 UTC ---
This bug was previously known as _bug_ 4083 at http://redmine.yorba.org/show_bug.cgi?id=4083
Unknown Component
Using default product and component set in Parameters
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: RESOLVED DUPLICATEhttps://gitlab.gnome.org/GNOME/shotwell/-/issues/3110straighten photos by drawing a line2021-05-19T13:05:31ZBugzillastraighten photos by drawing a line## Submitted by an unknown user
**[Link to original bug (#717967)](https://bugzilla.gnome.org/show_bug.cgi?id=717967)**
## Description
---- Reported by shotwell-maint@gnome.bugs 2011-08-31 03:50:00 -0700 ----
Original Redmine bu...## Submitted by an unknown user
**[Link to original bug (#717967)](https://bugzilla.gnome.org/show_bug.cgi?id=717967)**
## Description
---- Reported by shotwell-maint@gnome.bugs 2011-08-31 03:50:00 -0700 ----
Original Redmine bug id: 4084
Original URL: http://redmine.yorba.org/issues/4084
Searchable id: yorba-bug-4084
Original author: Florian K
Original description:
(Not sure if this is already in 3669)
For fast precise rotating of photos this feature would be nice:
Draw a line on an item of the picture that is either a perfectly horizontal
part (e.g. horizont) or a perfectly vertical part (e.g. tree, pillar).
Then automatically rotate the image so that this line is either horizontal or
vertical. (< 45 ° rotation, further rotation can be done by 90° rotate tool).
Related issues:
* related to shotwell - Feature #3669: straighten part 3: straighten tool (Invalid)
duplicates shotwell - Feature #61: straighten photo (Fixed)
---- Additional Comments From shotwell-maint@gnome.bugs 2013-05-01 11:46:00 -0700 ----
### History
---
Comment 1
Updated by Jim Nelson about 2 years ago
* **Category** set to _4_
This doesn't exactly mirror what we want the Straighten tool to do, so I won't
mark this as a duplicate. I am curious, though, are there other applications
out there that have this functionality?
---
Comment 2
Updated by Wolfgang Steitz about 2 years ago
there is a Gimp plugin with a similar functionality:
http://registry.gimp.org/node/22910.
---
Comment 3
Updated by Adam Dingle about 2 years ago
* **Description** updated (diff)
* **Status** changed from _Open_ to _5_
* **Resolution** set to _duplicate_
If we implement this I think it should be part of the straighten tool, so I'd
like to consider this a duplicate of #61. Feel free to add comments or
suggestions to that ticket.
---
Comment 4
Updated by Charles Lindsay 7 months ago
* **Status** changed from _5_ to _Duplicate_
--- Bug imported by chaz@yorba.org 2013-11-25 21:54 UTC ---
This bug was previously known as _bug_ 4084 at http://redmine.yorba.org/show_bug.cgi?id=4084
Unknown Component
Using default product and component set in Parameters
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: RESOLVED DUPLICATEhttps://gitlab.gnome.org/GNOME/shotwell/-/issues/3109Non-rename rename winds up on the undo stack2021-05-19T13:05:29ZBugzillaNon-rename rename winds up on the undo stack## Submitted by Jim Nelson
Assigned to **Lucas Beeler**
**[Link to original bug (#717966)](https://bugzilla.gnome.org/show_bug.cgi?id=717966)**
## Description
---- Reported by jim@yorba.org 2011-08-31 16:58:00 -0700 ----
Origi...## Submitted by Jim Nelson
Assigned to **Lucas Beeler**
**[Link to original bug (#717966)](https://bugzilla.gnome.org/show_bug.cgi?id=717966)**
## Description
---- Reported by jim@yorba.org 2011-08-31 16:58:00 -0700 ----
Original Redmine bug id: 4085
Original URL: http://redmine.yorba.org/issues/4085
Searchable id: yorba-bug-4085
Original author: Jim Nelson
Original description:
To reproduce:
1. Click on a tag in the sidebar.
2. Click on it again to initiate a rename.
3. Press Enter.
If you click on Edit, you'll see "Undo Rename Tag 'cow' to 'cow'" (or whatever
name it was). This won't happen if you press Escape in step 3 rather than
Enter.
This also happens if you press F2 in step 2, so closing #4076 won't fix this.
Related issues:
* related to shotwell - Feature #4076: single click should no longer edit a tag
name (Fixed)
---- Additional Comments From shotwell-maint@gnome.bugs 2013-05-01 11:38:00 -0700 ----
### History
---
Comment 1
Updated by Lucas Beeler about 2 years ago
* **Assignee** set to _Lucas Beeler_
I've already fixed this in my local repo while working on another tags-related
ticket.
---
Comment 2
Updated by Lucas Beeler about 2 years ago
Fixed in a4f63279ae9efc7190e46a43ab60c0d8630e3163.
---
Comment 3
Updated by Lucas Beeler about 2 years ago
* **Status** changed from _Open_ to _5_
* **Resolution** set to _fixed_
---
Comment 4
Updated by Charles Lindsay 7 months ago
* **Status** changed from _5_ to _Fixed_
--- Bug imported by chaz@yorba.org 2013-11-25 21:54 UTC ---
This bug was previously known as _bug_ 4085 at http://redmine.yorba.org/show_bug.cgi?id=4085
Unknown Component
Using default product and component set in Parameters
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.
Version: 0.11.1
Resolution: RESOLVED FIXEDhttps://gitlab.gnome.org/GNOME/shotwell/-/issues/3108Wrong German text string2021-05-19T13:05:27ZBugzillaWrong German text string## Submitted by an unknown user
**[Link to original bug (#717965)](https://bugzilla.gnome.org/show_bug.cgi?id=717965)**
## Description
---- Reported by shotwell-maint@gnome.bugs 2011-09-01 07:10:00 -0700 ----
Original Redmine bu...## Submitted by an unknown user
**[Link to original bug (#717965)](https://bugzilla.gnome.org/show_bug.cgi?id=717965)**
## Description
---- Reported by shotwell-maint@gnome.bugs 2011-09-01 07:10:00 -0700 ----
Original Redmine bug id: 4086
Original URL: http://redmine.yorba.org/issues/4086
Searchable id: yorba-bug-4086
Original author: Philipp Moll
Original description:
In the import Dialog shotwell offers three options (see attached image):
"Abbrechen", "Fotos kopieren", "Import läuft gerade".
That last one "Import läuft gerade" doesn't make sense to me. Shouldn't it be
named "Fotos verlinken"?
Shotwell 0.11, Ubuntu 10.10
Related issues:
duplicates shotwell - 4052: Import in Place has confusing translation in
German (Fixed)
---- Additional Comments From shotwell-maint@gnome.bugs 2013-05-01 11:46:00 -0700 ----
### History
---
Comment 1
Updated by Jonas Bushart about 2 years ago
* **Resolution** set to _duplicate_
Already changed in trunk.
Duplicate of #4052
(PS: I cannot change status to closed)
---
Comment 2
Updated by Jim Nelson about 2 years ago
* **Status** changed from _Open_ to _5_
---
Comment 3
Updated by Charles Lindsay 7 months ago
* **Status** changed from _5_ to _Duplicate_
--- Bug imported by chaz@yorba.org 2013-11-25 21:54 UTC ---
This bug was previously known as _bug_ 4086 at http://redmine.yorba.org/show_bug.cgi?id=4086
Imported an attachment (id=262160)
Unknown Component
Using default product and component set in Parameters
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: RESOLVED DUPLICATEhttps://gitlab.gnome.org/GNOME/shotwell/-/issues/3107Frequent crashes/segfaults2021-05-19T13:05:25ZBugzillaFrequent crashes/segfaults## Submitted by an unknown user
**[Link to original bug (#717964)](https://bugzilla.gnome.org/show_bug.cgi?id=717964)**
## Description
---- Reported by shotwell-maint@gnome.bugs 2011-09-01 07:20:00 -0700 ----
Original Redmine bu...## Submitted by an unknown user
**[Link to original bug (#717964)](https://bugzilla.gnome.org/show_bug.cgi?id=717964)**
## Description
---- Reported by shotwell-maint@gnome.bugs 2011-09-01 07:20:00 -0700 ----
Original Redmine bug id: 4087
Original URL: http://redmine.yorba.org/issues/4087
Searchable id: yorba-bug-4087
Original author: Philipp Moll
Original description:
My shotwell crashes in various situations
Example of how I create a crash:
1.) I start shotwell (on an empty Photos.db and empty import directory)
2.) I import 11 photos that are already tagged.
3.) I delete one of these Tags
4.) Shotwell crashes saying:
(shotwell:8199): GLib-GObject-CRITICAL **: g_object_ref: assertion
`object->ref_count > 0' failed
Error: Directory Sony with 8704 entries considered invalid; not read.
Speicherzugriffsfehler
Speicherzugriffsfehler == Segmentation fault
The same may happen when I delete an event or import more photos and so on. It
happens very frequently. Well sometimes I can do an action (like deleting a
tag) and it does not crash but the next time I do the very same action it
does.
This problems exist since at least since shotwell 0.8.1 .
Shotwell 0.11 @ Ubuntu 10.10 32bit
---- Additional Comments From shotwell-maint@gnome.bugs 2013-05-01 11:46:00 -0700 ----
### History
---
Comment 1
Updated by Philipp Moll about 2 years ago
* **File** shotwell.gdb added
* **File** shotwell.log added
Oh and here are the log and gdb files.
---
Comment 2
Updated by Philipp Moll about 2 years ago
I was able to solve this problem by uninstalling the gnome2-globalmenu.
-> sudo apt-get remove libglobalmenu-gnome
Well it would be nice to have globalmenu running together with shotwell.
---
Comment 3
Updated by Lucas Beeler about 2 years ago
* **Status** changed from _Open_ to _5_
* **Resolution** set to _wontfix_
We've looked into this and the problems are on the GNOME global menu dev's
side. Closing as wontfix.
---
Comment 4
Updated by Charles Lindsay 7 months ago
* **Status** changed from _5_ to _Invalid_
--- Bug imported by chaz@yorba.org 2013-11-25 21:54 UTC ---
This bug was previously known as _bug_ 4087 at http://redmine.yorba.org/show_bug.cgi?id=4087
Imported an attachment (id=262158)
Imported an attachment (id=262159)
Unknown Component
Using default product and component set in Parameters
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: RESOLVED INVALIDhttps://gitlab.gnome.org/GNOME/shotwell/-/issues/3106Assertion in PhotoMonitor: ERROR:arraylist.c:483:gee_array_list_real_get: ass...2021-05-19T13:05:23ZBugzillaAssertion in PhotoMonitor: ERROR:arraylist.c:483:gee_array_list_real_get: assertion failed: (index < self->_size)## Submitted by Jim Nelson
Assigned to **Jim Nelson**
**[Link to original bug (#717963)](https://bugzilla.gnome.org/show_bug.cgi?id=717963)**
## Description
---- Reported by jim@yorba.org 2011-09-01 15:50:00 -0700 ----
Origina...## Submitted by Jim Nelson
Assigned to **Jim Nelson**
**[Link to original bug (#717963)](https://bugzilla.gnome.org/show_bug.cgi?id=717963)**
## Description
---- Reported by jim@yorba.org 2011-09-01 15:50:00 -0700 ----
Original Redmine bug id: 4088
Original URL: http://redmine.yorba.org/issues/4088
Searchable id: yorba-bug-4088
Original author: Jim Nelson
Original description:
Some users at Launchpad are seeing this assertion when they first run
Shotwell. Looking at the code, I see that the problem is due to improper
bounds checking before accessing an ArrayList.
Downstream bug: https://bugs.launchpad.net/ubuntu/+source/shotwell/+bug/836268
Related issues:
* duplicated by shotwell - 4105: Crash shortly after startup (Duplicate)
* duplicated by shotwell - 4169:
ERROR:arraylist.c:483:gee_array_list_real_get: assertion ... (Duplicate)
---- Additional Comments From shotwell-maint@gnome.bugs 2013-05-01 11:38:00 -0700 ----
### History
---
Comment 1
Updated by Jim Nelson about 2 years ago
* **Status** changed from _Open_ to _5_
* **Resolution** set to _fixed_
To reproduce the problem:
* Have a RAW+JPEG pair in your library directory.
* Close Shotwell
* Make a copy of a paired JPEG in the same directory as the original JPEG and its RAW file.
* Restart Shotwell
The crash will occur after a moment.
Fixed in r36170cd36ed225808f1e0c6dee5c10e6485d7b71
---
Comment 2
Updated by Charles Lindsay 7 months ago
* **Status** changed from _5_ to _Fixed_
--- Bug imported by chaz@yorba.org 2013-11-25 21:54 UTC ---
This bug was previously known as _bug_ 4088 at http://redmine.yorba.org/show_bug.cgi?id=4088
Unknown Component
Using default product and component set in Parameters
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.
Version: 0.11.1
Resolution: RESOLVED FIXEDhttps://gitlab.gnome.org/GNOME/shotwell/-/issues/3105Camera developed RAW images don't keep transformations between sessions2021-05-19T13:05:21ZBugzillaCamera developed RAW images don't keep transformations between sessions## Submitted by Eric Gregory
Assigned to **Eric Gregory**
**[Link to original bug (#717962)](https://bugzilla.gnome.org/show_bug.cgi?id=717962)**
## Description
---- Reported by eric@yorba.org 2011-09-01 17:14:00 -0700 ----
Or...## Submitted by Eric Gregory
Assigned to **Eric Gregory**
**[Link to original bug (#717962)](https://bugzilla.gnome.org/show_bug.cgi?id=717962)**
## Description
---- Reported by eric@yorba.org 2011-09-01 17:14:00 -0700 ----
Original Redmine bug id: 4089
Original URL: http://redmine.yorba.org/issues/4089
Searchable id: yorba-bug-4089
Original author: Eric Gregory
Original description:
Import a RAW file
Set the developer to Camera (if not already set)
Make an obvious change to the image in Shotwell, i.e. crop or color change
Restart Shotwell
Open the image
Note that if the image appears normal at first, try zooming or resizing the
window. It will snap back into untransformed mode and stay that way.
Related issues:
* related to shotwell - 4055: Uploading to Picasa "loses" exposure tweaks (Fixed)
---- Additional Comments From shotwell-maint@gnome.bugs 2013-05-01 11:38:00 -0700 ----
### History
---
Comment 1
Updated by Eric Gregory about 2 years ago
* **Status** changed from _Open_ to _Review_
---
Comment 2
Updated by Eric Gregory about 2 years ago
* **Status** changed from _Review_ to _5_
* **Resolution** set to _fixed_
Fixed in fe82212d67b9e0c1c9b2f7558ef5be7169cecb48
---
Comment 3
Updated by Charles Lindsay 7 months ago
* **Status** changed from _5_ to _Fixed_
--- Bug imported by chaz@yorba.org 2013-11-25 21:54 UTC ---
This bug was previously known as _bug_ 4089 at http://redmine.yorba.org/show_bug.cgi?id=4089
Unknown Component
Using default product and component set in Parameters
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.
Version: 0.11.1
Resolution: RESOLVED FIXED