Steps to reproduce:
1. Take a screenshot, save it to Pictures. (Works.)
2. Create a subdirectory under Pictures, say Pictures/Test
3. Take a screenshot, save it to Pictures/Test (Works.)
4. Take a screenshot, try to save it directly under Pictures.
What happens:
The directory chooser always picks the ’Test’ subdirectory.
What I expect to happen:
To be able to choose ’Pictures’ as the directory to save my screenshot in.
Workaround:
In the directory chooser, click the pen icon to edit the path. Navigate to parent directory of ’Pictures’. Click to edit the path, make sure you delete the trailing slash (and anything thereafter) from after ’Pictures’, hit enter.
Additional notes:
Maybe this is a general bug of the directory chooser, but without looking, I haven’t come across other apps that make use of it to verify it’s not just Gnome Screenshot that’s affected.
@Roger: Thanks for the solution. On Ubuntu Precise, GMM 1.0.23.1334-r0 seems to use /usr/local/share/applications instead of /usr/share/applications for the desktop file (there’s also a copy in /opt/google/musicmanager/, but it’s apparently just used for installing the effective file into /usr/local/).
@Nuno: I’m not sure I see the point of encrypting the application-specific password, and then be prompted to enter the key for decrypting the password. Isn’t it more straightforward to just specify the application-specific password when GMM prompts you to? Actually, with the caveat that specifying the password on the commandline means exposing it to trusted users, isn’t having GMM prompt for it a *better* solution securitywise? I guess you do get the benefit of getting to specify your own password which can be as easily memorizable as you dare use though (the application-specific passwords are difficult). Instead of OpenSSL I’d probably use GNOME Keyring, as it gets unlocked during login without an extra prompt for another password. Then pick the key for GMM using gkeyring.
Just a note that this no longer happens now that I’m running 12.04 with Unity; Unity’s run dialog expands tilde correctly. Still broken in Gnome panel 3.2.0 though.
Steps to reproduce:
1. Disable power saving
2. (Re-)boot (logoff may suffice, though I’ve not tested this)
3. Login and don’t touch mouse or keyboard after that
4. Wait
What happens:
Within half an hour (on my system at least) the display signal is turned off (monitor reports ”No signal”).
What you expect to happen:
The screen to stay on as indicated by power saving settings.
Additional info:
1. Any keyboard or mouse activity seems to make it obey the setting: after that the screen won’t go blank on its own (irregardless of whether or not the bug has manifested itself during the session).
2. I’ve disabled screensaver as well, though that probably doesn’t concern this bug.
3. From bug #854624’s comments I picked up this settings listing command, in case it helps:
jani@saegusa:~$ for c in `dconf list /org/gnome/settings-daemon/plugins/power/`; do echo -n ”/org/gnome/settings-daemon/plugins/power/${c}=”; dconf read /org/gnome/settings-daemon/plugins/power/${c}; done
/org/gnome/settings-daemon/plugins/power/sleep-display-ac=0
/org/gnome/settings-daemon/plugins/power/sleep-display-battery=0
As the title says. Steps to reproduce:
0. Run Maximus.
1. Run gnome-terminal.
What I expect to happen:
Gnome terminal window to open maximized.
What happens instead:
Gnome terminal window opens unmaximized.
Additional notes:
/apps/maximus/exclude_class only has Totem listed (no gnome-terminal).
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.)
1. Raise accessibility alongside the top goals of simplicity and usability,
2. aim for those goals more rigorously than currently,
3. communicate how it’s being done (i.e. how doing things the way they’re done in Gnome contributes to those goals).
I’ve outsourced my desktop getting to the goals I raised in #22 to the Gnome project, and I believe that Gnome aiming for them will eventually result in the noble ”It Just Works” user experience for me and my friends using Gnome. Though it is the best effort currently available to that end, we’re not quite there yet.
According to upstream this has been fixed in Gnome 3.0.
Confirming this on Lucid. I use Alt-F2 and ’killall gnome-panel’ to bring the panel back.
I’m running a Lucid desktop, but with UNE as the interface.
In UNIX, the tilde character ~ usually refers to the user’s home directory. However, the run dialog doesn’t seem to support this.
Steps to reproduce:
1. In a terminal:
$ echo ”hello” > ~/foo
$ cat ~/foo
hello
2. Press Alt+F2 to bring up the run dialog. Enter:
gedit ~/foo
Expected result: have ~/foo open in gedit with the content ”hello”.
Actual result: a file called foo opens, but it’s empty and obviously not the one created. From gedit’s title I’m guessing the run dialog passes ~ as the name of a directory residing within the actual ~, user’s home.