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 622968 - Add File Selector mis-behaves: No Places pane. Ctrl/click action wrong.
Add File Selector mis-behaves: No Places pane. Ctrl/click action wrong.
Status: RESOLVED FIXED
Product: brasero
Classification: Applications
Component: general
2.30.x
Other Linux
: Normal normal
: 2.26
Assigned To: Brasero maintainer(s)
Brasero maintainer(s)
Depends on:
Blocks:
 
 
Reported: 2010-06-27 18:15 UTC by William Cattey
Modified: 2011-02-03 13:57 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Newly created application-settings file Brasero 2.30.2 (390 bytes, application/octet-stream)
2010-07-18 02:49 UTC, William Cattey
Details

Description William Cattey 2010-06-27 18:15:20 UTC
When I switched from Fedora 12 (with brasero 2.28) to Fedora 13 (with brasero 2.30) the File Selector dialog from the Add command changed behavior:

1. The Places pane is no longer part of the dialog.

This is inconvenient for me, because previously I could make a link in the Places pane to the subdirectory containing the files I wanted to use.  A single click got me to where I needed to be.

Now, every time I want to add a file to a project I have to click down, down, down from my home directory to get to where I used to be able to go with a single click in the Places pane.

When I issue the "Save As" command, the Places pane is present, just like it always was.  So there seems to be a difference in the setups of the two different uses of the GTK File Chooser.

2. The right-click action seems subtly wrong now.

As expected, when you Ctrl/click something not previously selected, it adds the item to the list of things to add.

But now, when you Ctrl/click to de-select something from the list of things to add, the item is de-selected, but the dialog box also decides I'm done, closes the dialog box, and adds what has been selected.

Are these two new behaviors intentional?

I really preferred the previous behavior.

-Bill Cattey
Comment 1 Philippe Rouquier 2010-07-06 14:22:34 UTC
Thanks for the report. I think (and I hope you can confirm) that your first problem is related to a bug that has been fixed for 2.30.2.
In 2.30 series there is a new mechanism to "remember" the sizes of the panes. Now unfortunately a bug crept up which entirely hides the side panel on the first run. So basically you should have your left pane but it is hidden; hover your mouse pointer on the left side and see if you can resize it.

As for the second part of your comment, I fixed it. The bug was in our code for multi-dnd.

Please, particularly for issue one, let me know if I was right.
Comment 2 William Cattey 2010-07-06 21:56:38 UTC
Thanks very much for the speedy reply, and for the good news that the problems are fixed in 2.30.2.  (Fedora 13 is built from upstream 2.30.1.)

I've downloaded the 2.30.2 tarball. It will take me a little while to remember how to rpmbuild a new fedora package for testing.  (I've done it before, but it was a while ago and I'm out of practice.)  I'll get back in touch soon with my results.
Comment 3 William Cattey 2010-07-14 17:59:49 UTC
Sorry for the delay, but I finally did a test build.
Surprisingly 2.30.2 has exactly the same mis-behavior I reported.

Sanity checks:  I built with 
http://ftp.acc.umu.se/pub/GNOME/sources/brasero/2.30/brasero-2.30.2.tar.bz2

The menu command, Help -> About pops up a window that says:

        Brasero 2.30.2

But when I issue the "+" command, still the Places pane is missing.
Ctrl/<mouse left> on an already selected item still exits the file
picker.

Why do you think this might be?
Comment 4 Philippe Rouquier 2010-07-17 14:05:11 UTC
Try the following;
first to save some settings:
cp ~/.config/brasero/application-settings ~/.config/brasero/application-settings.back

Then remove the said settings:
rm ~/.config/brasero/application-settings

and try brasero again.

This will remove all UI saved settings (like window size, volume, chosen layout of panes, ...) so nothing very important or long to reset.

If it still does not work, you can restore the file with:
cp ~/.config/brasero/application-settings.back ~/.config/brasero/application-settings

If it works edit, your backed up file (~/.config/brasero/application-settings.back) and remove the following two keys with their values:
stock-file-chooser-percent
brasero-file-chooser-percent

and restore it with the previous command.
Comment 5 William Cattey 2010-07-18 02:49:05 UTC
Created attachment 166102 [details]
Newly created application-settings file Brasero 2.30.2

I wondered if perhaps persistent gnome settings might be the problem.
Alas, the newly created application-settings file is identical to the
one I moved aside.  I have attached the new one to the bug.

What do you suggest as a next step?
Comment 6 William Cattey 2010-09-03 16:38:16 UTC
Fedora 13 took your upstream 2.30.2 update.
With a bit of sleuthing, I figured out why my build didn't remedy the problem:
I had not installed the new brasero-lib RPM I had built.

Your insight about the .config file needing to go away was also key.

In my testing, at one point I had both the right brasero, and right brasero-lib, but the config/application-settings had:
    stock-file-chooser-percent=21
The now-working version has:
    stock-file-chooser-percent=2992

Although it seems a bit odd that a percent over 100 is set.

This resolves item 1 of my report, but the item 2 behavior is STILL present.

I'd be grateful for the answers to the following questions going forward:

1. Is the stock-file-chooser-percent=2992 value sane and correct?

2. Should I expect ctrl/click on an already selected item to act as if I hit the "OK" button instead of de-selecting it?

3. To pursue correct operation on ctrl/click, should we continue with this BZ, or should I open a new one?

Thanks in advance,

-Bill
Comment 7 Fabio Durán Verdugo 2010-12-17 06:15:30 UTC
any news for this report?
Comment 8 Fabio Durán Verdugo 2011-02-03 02:34:59 UTC
Closing this bug report as no further information has been provided. Please feel free to reopen this bug if you can provide the information asked for.
Thanks!
Comment 9 William Cattey 2011-02-03 04:18:57 UTC
Um, excuse me.
I asked a question back in October that was never answered.
Now you are closing the bug report because "no further information has been provided"?

What information are you looking for?
I do not understand the question, "any news for this report?"

I'd be grateful if you'd re-open this bug, examine the behavior I RE -reported
in comment #6, tell me if that behavior which pretty well seems WRONG to me
is the expected correct behavior or not.

If there is indeed missing information I will GLADLY supply it.
But as far as I know, the information needed was from the developer, not the person
reporting the bug (me.)
Comment 10 Fabio Durán Verdugo 2011-02-03 04:55:52 UTC
My question is for testing whether the bug was solved or not, and has no inattention. :-)

reopen the bug.
Comment 11 William Cattey 2011-02-03 13:57:12 UTC
I apologize.  I misunderstood your comment as a request to re-test under Fedora 14/Brasero 2.32.0.

Good news!
I have re-run my test with <CTRL>/<Mouse left>
to select and de-select an item in the GNOME file chooser.

The behavior is now as I expect:
<CTRL>/<Mouse left> on an un-selected item adds it to the selection.
<CTRL>/<Mouse left> on a selected item removes it from the selection.

This bug is fixed.
Again, I apologize for not re-testing more rigorously when I updated to Fedora 14.