== Steps to reproduce ==
1. Download https://upload.wikimedia.org/wikipedia/commons/thumb/e/e1/Car_crash_1.jpg/193px-Car_crash_1.jpg?download
2. Open the image in Shotwell Viewer: $ shotwell 193px-Car_crash_1.jpg
3. Select File > Save As…
4. Keep/set Format as ”Current”, don’t change any other parameters
5. Enter ”193px-Car_crash_1.png” (without quotes) as the filename, select OK
== What happens ==
The viewer now displays a black screen, with the text ”Photo source file missing:” followed by the (.png-ending) image path entered in the dialog. The file has not been saved.
== What I expect to happen ==
For the (now misnamed) .png-ending file to have been saved, and be opened in the Viewer.
== Other notes ==
* If an image file with the .png ending already exists, and I choose to overwrite it with the JPEG, the black error screen does not appear; instead the previously-existing PNG image file is then opened in the viewer.
* I’m (intentionally) not doing an actual Format change in the first Save As dialog here. If I do select PNG as the format, then saving the file does work as expected (using any filename extension).
* I used .png just as an example here. Using any variant of /jpe?g/i as the extension seems to work as expected (i.e. the file is saved under the new name), whereas anything else (.gif, .foo etc.) results in the same ”file missing” error as above.
* If the original file is a PNG file, saving it with .jpg (or any other extension for that matter) seems to work as expected (i.e the file is saved under the new name, with the now-incorrect extension).
(My original report at Launchpad: https://bugs.launchpad.net/ubuntu/+source/shotwell/+bug/1710641#. I tweaked some details for the report above, with Shotwell 0.27.4 currently in Bionic.)
Created an attachment (id=259453) [details]
This is in Fedora 19 with current Gthumb 3.2.4. Likewise reproducible in Ubuntu 12.04 with Gthumb 3.1.2 (from a PPA).
Steps to reproduce:
1. Open foo.png
2. Select File > Save As
3. Name the file foo2.png, select Save
4. In the Options dialog, select Cancel
5. Back in the Save As dialog, select Save again
What happens:
The Options dialog now only has Title and the Cancel and Save buttons, no actual options to choose from.
What I expect to happen:
The Options dialog to have options just like at step #4.
More information:
The bug crops up when saving the file as JPEG as well, I just used PNG as an example. It also happens regardless of whether a file is chosen for overwriting or not. After the bug is triggered, subsequent attempts to Cancel and re-enter the Options dialog always bring it up empty, until the Save Dialog is exited (either by Canceling or by going ahead with the Save).
Should the first list include –quit too, as that one also doesn’t seem to work? It (2.96) doesn’t print a warning though, either:
jani@saegusa:~$ rhythmbox-client –quit
jani@saegusa:~$
jani@saegusa:~$ rhythmbox-client –debug –quit
(18:28:03) [0xc97800] [rb_debug_init_match] rb-debug.c:240: Debugging enabled
(18:28:03) [0xc97800] [main] rb-client.c:707: quitting existing instance
jani@saegusa:~$
I reported this on Launchpad [1] and was forwarded upstream.
Steps to reproduce:
1. touch ~/foo_åäö
2. In Nautilus, point at the file created in step 1
3. Right-click for context menu
4. Select Move to Trash
5. Press Ctrl-Z/Select Undo from the Edit menu
What happens:
Nothing
What I expect to happen:
For the file to recover from trash to ~.
What works:
* Undoing Move to Trash with files with no scandinavian letters in their path/filename.
* Recovering foo_åäö by opening Trash and selecting Recover from context menu.
More info:
* Could be that more characters, perhaps all non-ASCII characters render Nautilus’ Undo impotent — I’ve only tested å, ä and ö.
* The Finnish translation for Desktop (~/Desktop) is Työpöytä, which means files moved to trash from Desktop can’t be recovered. Nasty.
*[1] https://bugs.launchpad.net/ubuntu/+source/nautilus/+bug/973620
jani@saegusa:~$ nautilus –version
GNOME nautilus 3.4.0
This looks like a duplicate of bug 538432 [1] though it refers to a different memo, RFC1738.
* [1] https://bugzilla.gnome.org/show_bug.cgi?id=538432
I reported this on Launchpad [1] and was forwarded upstream.
Steps to reproduce:
1. In Nautilus, select Connect to Server
2. Enter ftp server address, select FTP (with login) as type
3. Enter credentials,
4. select ”Remember this password”
5. Connect.
6. Disconnect.
7. Do steps 1.-2. again with the same server.
What happens:
The User name and Password fields remain empty. You have to enter your credentials again if you want to connect.
What I expect to happen:
For the Password field (at the very least) be automatically filled when I enter the associated user name. Better yet, remember and suggest (as default) both the User name and Password used previously.
Alternatively, just use ~/.netrc if that’s available and has the credentials (see [2]).
* [1] https://bugs.launchpad.net/ubuntu/+source/gvfs/+bug/963061
* [2] https://bugs.launchpad.net/bugs/963042
Then I would rephrase this into a bug report as follows: currently, the toolbar navigational buttons (previous, next) are positioned to the right from the location bar. This is inconsistent with what most users probably expect, which is the way they are located in a web browser.
The three web browsers I currently have installed on this system position these elements as follows:
- Epiphany 3.2.1: previous, next buttons above the left end of location bar.
- Firefox 9.0: previous, next buttons to the left from location bar.
- Chromium 15.0.874.121: previous, next buttons to the left from location bar.
From my personal anecdotal evidence, with this background, I say suddenly finding the navigational buttons from the right end of the location bar in one app is undly arduous. Thus this bug’s title should be: Move the navigation buttons to the left of the location bar.
(IIRC this was also how the buttons were back in Gnome 2. If there was some usability reasoning behind moving them to the right, I’d be interested in reading about it.)
As I reported on Launchpad: https://bugs.launchpad.net/ubuntu/+source/gdm/+bug/524497
There’s a usability issue with the login screen’s panel being at the bottom of the screen. It should be at the top, or at the very least the elements that are present in both the login screen and the desktop (the clock and shutdown menu) should be positioned consistently. It’s very confusing as it stands, with the clock and the shutdown function jumping from the bottom of the login screen to the top of the desktop screen when we log in.
Either the top of the screen is the accessibility-wise better place for these elements, in which case they should be there *during the login screen also*, or it isn’t, in which case they shouldn’t be there when we get to the desktop *either*. They shouldn’t be in one place on one screen, in another place on another screen.
The ’All Video Files’ filter, used when opening a video, filters out .flv video files. With the ’All Files’ filter, .flv’s open just fine, so the underlying support is there – the ’All Video Files’ filter just doesn’t know it.
