Gnome file chooser/selector is way to small

[Fredrik]

Today, many people use resolution like 1280*1024 and even 1600*1200.

Todays file selector dialog is WAY to small. It should use a (configurable) percent of the screen height/width.

I KNOW that this is one of the reasons people think Linux is bad. Maybe it sounds strange, but if the first thing you see is a tiny tiny file selector and you have to scroll forever you get get pretty dissapointed if you are used to the windows file selector. It is better then gnomes. Time to change that ...

[Sebastien Bacher (seb128)]

Thank you for your bug. Could you attach a screenshot illustrating your problem? Is your problem the ~5 folder lines displayed by default?

[Fredrik (fredrk)]

Yes.

It should be more like 75% of screen height and not a fixed number of lines.

I se nog god reason why not fill more of the screen as the user has made the choice to select a file. When you have 100+ files and dirs in a directory (home dir for example) and you only see ~5 lines at the time it takes to much time scrolling.

[Sebastien Bacher (seb128)]

I've forwarded your request upstream: http://bugzilla.gnome.org/show_bug.cgi?id=385011

[Sebastien Bacher (seb128)]

Duplicate of http://bugzilla.gnome.org/show_bug.cgi?id=325477 which has a patch

[Fredrik (fredrk)]

Couldn't anybody apply this patch to the ubuntu packages?

[Fredrik (fredrk)]

The patch in the link won't install in Edgy.

gnutls11 can't be installed. The packages depends on that package.

Users should not be forced to compiler their own gtk2 to get a proper file selector ...

[Sebastien Bacher (seb128)]

On mar, 2006-12-12 at 14:45 +0000, Fredrik Sjögren wrote:
> Couldn't anybody apply this patch to the ubuntu packages?

hurrying up patches before they get upstream comments is usually not a
good idea, we will likely wait a few extra days and get something
approved by upstream

[Sebastien Bacher (seb128)]

Fixed upstream, I'll look at the patch for feisty if there is no new GTK tarball rolled

[Fredrik (fredrk)]

You are my hero.

[Sebastien Bacher (seb128)]

Looks like the code is still not working as expected, not likely to change on 7.04 now

[Fredrik (fredrk)]

It's 6 months to 6.10 ...

Couldn't it be fixed?

At least around me I often hear "Gonme has bad file selectors".

[Sebastien Bacher (seb128)]

the bug can be fixed, GTK is open source, you can try to work on it if you want

[Jonathan Carter (jonathan)]

This seems to be fixed in GTK 2.1, which is included in Gutsy

[Sebastien Bacher (seb128)]

the bug is fixed in gutsy

[Claudio Shah (claudio-shah)]

In https://bugs.launchpad.net/bugs/112642 someone stated, that the problem only appears in combination with compiz, so please make sure it is fixed in gutsy with compiz enabled (by default). Thanks.

[Milan Bouchet-Valat (nalimilan)]

I confirm last comment: Compiz makes this bug appear. With it enabled, the expander does not resize the dialog enough.

[Milan Bouchet-Valat (nalimilan)]

This has just been fixed upstream today (see upstream bug). Can we hope this gets into Hardy?

[Milan Bouchet-Valat (nalimilan)]

Request to integrate this 3 lines commit into compiz in Hardy.

[Pedro Villavicencio (pedro)]

compiz upstream task has been fixed, thanks for reporting.

[quixote (commer-greenglim)]

If it's been fixed, why in hell do I have a pathetically small file selector box under Hardy 8.04?

One of the early commenters was right: this is one of the first usability issues a new user bumps into. If it annoys an ubuntu fanatic like me, what's it doing to them?

And, no, sorry, I don't know enough to contribute to fixing the bug. Nor do I know how to recompile gtk. I'd just like a dialog window I can resize THAT STAYS THAT WAY. (Do I sound frustrated? Really?)

If it's compiz's fault --and much as I like compiz on the whole -- how do I turn it off? Can I turn it off?

Honestly, this is such a visible and important usability issue that it really needs to be dealt with faster than two years!

I wish I could fix it. Unfortunately, all I can do is complain :(

[Travis Watkins (amaranth)]

Are you saying you still see this in hardy? We have the fix from compiz and the fix from gtk+ in hardy right now.

[Don Capo (doncapo)]

No. Its much better after we updated to Hardy. Thank you from thousands of users.

[Owen Williams (ywwg)]

this bug seems to have reappeared in Intrepid. I never saw this bug before, but now that I've updated I'm getting very small save boxes. This is with compiz.

[traxxas (traxxas)]

I'm also seeing this bug in Intrepid. It looks like sometimes the last size stored isn't available because I can see the window start small and then get redrawn to a larger size a few milliseconds later. I'm using compiz and this is an upgraded machine from Hardy.

[Harrison (harrisonchen)]

I'm also only seeing this in intrepid. It happens both under compiz and metacity.

It happens rather unpredictably.

[hackel (hackel)]

I have been getting this for a while as well. It is really frustrating, as I have to resize the file dialogue every single time!

[Milan Bouchet-Valat (nalimilan)]

Could you tell us what applications you're seeing this bug with? I've been investigating this, but I've not been able to reproduce it.

Harrison: you say it's unpredictable. How often do you see it? Could you try to find some determinations to it (applications, folders...)?

hackel: do you get this everytime and with every application?

traxxas: from a recent change in the code, the window is resized *after* being shown, thus it's not centered. The cause of that is easy to detect, I'm trying to see what we can do. But the link with the bug is not clear to me.

Could you all give more precise information? What window manager are you using (please try Compiz and Metacity), what applications, how often... ? Thanks!

[hackel (hackel)]

The screenshot I posted was from the Sound Preferences, when choosing a custom sound. This is only happening under Compiz, it works fine under Metacity. The behaviour seems consistent.

I also get the problem with Firefox, but not consistently. The dialogue always opens small but sometimes it doesn't resize. I can't figure out what is triggering this at all. The first few times I brought up the open file dialogue, it was small, but now it is resizing it every time. So far I have only seen it with the Open File dialogue, not Save File.

I will post any other instances where I notice it. I think the real problem is the resizing--is this really necessary? If it must have a default size, can't it be resized before the window is made visible?

[Milan Bouchet-Valat (nalimilan)]

Thanks for your feedback. I cannot reproduce this behavior. What do you get if you resize the dialog and launch it again?

Obviously, resizing should happen before showing the window. This is IMHO a little bug and should be relatively easy to fix.

[hackel (hackel)]

Resizing manually has no effect. I tried resetting my compiz settings to the defaults, and now every once in a while the Sound Preferences dialogue will resize correctly, whereas before it was not resized every time. Still no closer to figuring out what causes it to resize or not.

[Don Capo (doncapo)]

This used to be true for me, but we updated from Drake to Hardy, and the
problem was gone. You may/please take me off the list for this bug.

Thank you,

Don Capo

[Milan Bouchet-Valat (nalimilan)]

Don Capo: we cannot unsubscribe you, but you can do this using the link in the panel on the right.

[Benjamin Geer (benjamin-geer)]

I started getting this problem after I upgraded to Ubuntu Intrepid. It seems to be randomly intermittent; clicking "Open" in gedit repeatedly causes it to happen about half the time. Disabling Compiz makes it go away for me.

[Nguyen Dinh Trung (dinhtrung)]

We can have a work around for this situation.
Install Compiz config settings, and use 2 more plugins: Place Windows and Window Rules.
- On Window Rules, choose the "Size Rule" tab.
-- Add a new rule with this settings:
---- Sized Windows: type=dialog
---- X size and Y size about 800x600

- On Place Windows, choose Fixed Window Placement:
-- Add a Windows with Fixed position:
------ type=dialog
------ XY position : 150 x 200 (please choose as you like, but test carefully. I still don't get what is the best position in this settings).

After these steps, whenever I open a dialog like Save, Save as, Open, etc, the window will be placed center of the screen, and the dimension are 800x600. Don't know if this will cause any issue.

[Benjamin Geer (benjamin-geer)]

dinhtrung, I tried your workaround, but it causes some dialogs to behave strangely, e.g. the "Find" dialog in gedit, which is much too big, then resizes itself when you try to close it.

[xtknight (xt-knight)]

hackel: yup i'm getting the same thing. It is insanely agitating and almost made me switch completely to KDE.

I'll see what I can do to debug this but it happens to me almost all the time. I think one time totem showed a "loading" box and then the following file-open box became the same size as the small loading splash screen. And then I've had the problem with various programs ever since.

[Milan Bouchet-Valat (nalimilan)]

A GTK+ developer is working on that, he should find the problem quite easily. I've updated the remote bug watch to point the the right bug report, the other is outdated.

[Christian Mertes (cmertes)]

The priority shouldn't be low. I have a 1920x1200 pixel 15.4" display and the file chooser isn't too small, it's unusable. I have to change its size every time I use it. Every single time. Let me repeat this: Every single freaking time! You never knew how many file chooser dialogues you use before you get annoyed by every single one of them. I give any developer one day with my laptop and the priority will go to high.

[Milan Bouchet-Valat (nalimilan)]

Don't worry, the priority in Launchpad is not relevant for this bug since Ubuntu developers won't fix it. GTK+ guys who are working on that use their own (subjective) priority. Anyway, priorities only bind people who believe in them...

And when a fix will be available, we'll better need a nice volunteer to make a debdiff including the new patch, so that it's uploaded ASAP. So get ready... ;-)

[Christian Mertes (cmertes)]

Debdiff, uh, yup. I never did any Debian packaging but if you tell me it's not half a day of reading to do five minutes of real work I will see what I can do.

[Loïc Minier (lool)]

If you don't want to learn how to create a debdiff that's fine; it also helps to just attach a patch from upstream.

A debdiff or attaching the upstream patch (or a pointer to it) in launchpad makes it easier for us to review and integrate changes, and hence gets more chances of being quickly merged.

[hackel (hackel)]

Has anyone experienced this bug who is not running Compiz? I don't believe this is a gtk issue at all. It seems as if Compiz is somehow ignoring the window resize that normally occurs. I still think this behaviour is broken, but that is a totally separate issue. Don't blame the gtk guys for this, or expect a solution, unless you can reproduce it without Compiz running. Also, I probably wouldn't expect a fix for this issue in Jaunty, so don't worry about debdiffs or patches or anything of the sort. It will get merged with the next Compiz release.

[Milan Bouchet-Valat (nalimilan)]

The GtkFileChooserDialog is resizing itself after being shown. This is the root problem, which causes positioning issues even when the dialog is not too small. This is a GTK bug, there are several rough patches proposed upstream, and the commit that introduced the problem is identified. Now, Compiz may raise problems by refusing to resize the dialog immediately after it's been shown - this may be a nice behavior to avoid window instability, or it may sheerly be a bug.

I don't understand what do you mean about Jaunty and a Compiz update. This will surely get into Intrepid if a nice patch is provided, and yes, a debdiff will help. The fix in Compiz won't come since the bug we reported to them was about another issue and was already released in Hardy.

[hackel (hackel)]

So you are saying that Metacity simply ignores this "bug" that gtk is producing? It seems like two separate issues to me. One issue is that gtk is resizing the dialogue in the first place. That's not what this particular report is about, but solving it would probably hide this bug. This bug is about the 2nd issue, that compiz is not *always* following this resize directive. Like you said, maybe it is to avoid window instability or some such, but it's still incorrect. So, in my opinion both issues need to be solved, and it seems like they should be tracked separately. If the gtk issue is solved before the compiz issue, then the compiz issue may continue on unsolved, only to resurface at some later time.

I would not expect an issue like this will warrant an update in Intrepid, so we would just have to wait for it to be merged upstream so as to appear in the next release. There seems to be some other factor at work here, because a great number of people are not experiencing this bug, otherwise it would indeed be a higher priority. Could it be screen resolution/DPI? I'm also running 1920x1200 like Christian, at 150 dpi. Perhaps the 2nd resize values is being calculated based on the font size + DPI? I will see if I can reproduce this with a new account at the unfortunate standard of 96 dpi.

[Milan Bouchet-Valat (nalimilan)]

AFAICS, there's no reason why a well-designed dialog should resize itself immediately after being shown. So the bug is in GTK+, maybe there's something in Compiz too but that's not the real source of the issue. Please check that Metacity does not trigger this before going further on that subject.

Anyway, there are two parts in this bug but you won't treat them separately, that's of no use. If you like, go to the Compiz upstream bug report and see what they say, but in GTK+ a single fix will do the trick. And I'm able to experience the bug with a 1024x768 resolution, so that's not the problem.

Please stop spamming the report with considerations other than technical: the priority is 'Low' not because the number of people experiencing this, bug because it's not preventing you from performing any task, it's only highly annoying - and read again my previous comment about that. About the update in Intrepid: again, there's no reason it doesn't get into intrepid-updates if a patch is provided in time, read Loïc's comment above. Now let's wait.

[Danny Baumann (dannybaumann)]

I would like to look into what makes it fail under compiz, but I have _not_ been able to reproduce it using compiz from git master and gtk+ 2.14.5 (Fedora 10). I do see the resize-after-window-map problem, though. The window size constraining code in compiz is essentially untouched between 0.7.8 and git master.

If someone can tell me a way how to reliably reproduce it, please go ahead. I realize that me using F10 is another variable in the game, but I really don't have time to install Ubuntu just for reproducing this issue.

[Milan Bouchet-Valat (nalimilan)]

You can try in Abiword, I'm seeing this everytime with that program and not with others - I'm not sure why. Else ask to Compiz developers, they may have a clue.

[Danny Baumann (dannybaumann)]

I don't think there's much point in asking myself ;)
I can't reproduce it with abiword either, though.

[Milan Bouchet-Valat (nalimilan)]

GTK+ developers fixed this in GTK trunk. But I'm not sure how this will eventually reach Intrepid. If somebody can package the attached patch, it should quite simply do the trick (from revision 22118 for reference). More patches were committed upstream, but they're rather improvements than fixes.

[goto (gotolaunchpad)]

found a workaround until the bug is fixed.
using the windows rules plugin for compiz set the size rules to title=Open Files and then specify a new size for the windows. repeat for any other windows as needed

[Lukas Kolbe (lukas-einfachkaffee)]

The patch from above seems to fix it for me, although there's an empty window of the same small size as before, and the next blink it's gone bigger and fully loaded.

This happens only when in Compiz, not metacity.

[Milan Bouchet-Valat (nalimilan)]

Maybe I posted the wrong patch. There are four of them, and two that can be relevant to our bug. But maybe the present one is better, I'm not sure why I chose the other first (see attached revision 22117).

[traxxas (traxxas)]

Milan's 22117 patch applied to gtk+2.0_2.14.4 sources fixes the problem for me in firefox, gedit, and abiword (3 apps I have the most usage and see the bug in often). I can provide the package if needed for wider testing so we can get this to the proposed repo.

[Milan Bouchet-Valat (nalimilan)]

If you build a package, please provide a debdiff so that it can be committed to intrepid-proposed when it's been tested (there should be no problem). See https://wiki.ubuntu.com/PackagingGuide/Recipes/Debdiff, but you've made the hardest part! ;-)

[hackel (hackel)]

Does this patch actually fix the problem of the file dialogue resizing at all (it shouldn't), or does it just make the resizing work properly? I'm wondering if a separate bug needs to be filed against the resizing behaviour.

[Milan Bouchet-Valat (nalimilan)]

You can have a look at the upstream report: the last patch I posted should make the dialog set its size *before* it's shown, which fixes all the problems mentioned here. In addition, GTK 2.16 will always remember the size you set manually to the dialog. I guess this is all that can make you happy!

[Andrew Cholakian (andrew-cholakian)]

dinhtrung's solution works better for me if I select the window by title. That way it doesn't impact other programs nearly as much.

[Sebastien Bacher (seb128)]

the issue is fixed in jaunty now