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 92566 - The --geometry command line option doesn't work in spatial mode or with maximized windows
The --geometry command line option doesn't work in spatial mode or with maxim...
Product: nautilus
Classification: Core
Component: general
Other Linux
: Normal minor
: 2.24.x
Assigned To: Nautilus Maintainers
Nautilus Maintainers
Depends on:
Reported: 2002-09-05 11:08 UTC by Anand
Modified: 2008-05-19 12:36 UTC
See Also:
GNOME target: ---
GNOME version: 2.23/2.24

proposed patch (1.85 KB, patch)
2008-05-12 17:55 UTC, Cosimo Cecchi
none Details | Review

Description Anand 2002-09-05 11:08:39 UTC
I'm using a September 3rd build from CVS on a RH 7.1 Linux machine. 

I tried running invoking nautilus from the command line using the --
geometry option.

Tried out commands like:
nautilus --geometry 400x800+100+300
nautilus --geometry 800x400+100+300
nautilus --geometry 400x800+300+100
nautilus --geometry 400x100+900+300

The nautilus window dimension does not change for any of the above 
commands. The X and Y positions are however respected by nautilus and the 
new windows are placed properly.
Comment 1 David Kennedy 2002-11-23 22:27:13 UTC
Verified in 2.1.1 as well - none of the geometry options work. Leaving
normal/normal, adding GNOMEVER2.1 and bugsquad
Comment 2 Luis Villa 2002-12-02 23:58:56 UTC
I'm going to take the liberty of marking this minor; I don't know
anyone who actually regularly uses this option.
Comment 3 David Kennedy 2003-03-25 19:34:26 UTC
still present in 2.2
Comment 4 Kjartan Maraas 2003-10-28 20:58:51 UTC
Still here in 2.4.x
Comment 5 Christian Kirbach 2006-01-11 18:56:23 UTC
2.12.2 still
Comment 6 Robin Sonefors (ozamosi) 2006-07-27 12:34:16 UTC
I had a look at this. I don't understand anything when ORBit gets into the picture, so I didn't manage to solve it.

However, I noted that the geometry option does work if you add a path at the end of the command. That means:

Does not work: nautilus -g 100x100
Does work: nautilus -g 100x100 .

This is not the same behaviour that the original poster reported, but it affects the same command line option, and I think this is what all the others have reported.
Comment 7 Larry Olin Horn 2008-05-09 05:58:29 UTC
Still here in 2.20.0.

Requested fix: --geometry should override remembered positions

It appears that what actually happens is that if you are opening a directory for the first time, the --geometry options are used.  On subsequent opens, the remembered position of the window overrides the command line options.  Note that this is slightly different than what comment #6 states.

This wasn't an issue for me until nautilus stopped remembering positions of softlinks by name (I don't know exactly when; I've just upgraded from Fedora Core 6 to Fedora 8.)  I have a softlink "Today" that changes daily.  It's aggravating that it now opens mid screen (on first open of a new day) rather than at the size and position I've always kept "Today" at.  Trying to override that via --geometry didn't work.

 $ nautilus --version
 GNOME nautilus 2.20.0
 $ cat /etc/redhat-release
 Fedora release 8 (Werewolf)
 $ uname -a
 Linux joule #1 SMP Sat Apr 19 12:39:34 EDT 2008 i686 i686 i386 GNU/Linux

Comment 8 Tony Whelan 2008-05-10 23:15:20 UTC
Problem remains in GNOME nautilus 2.22.2

The reason I care about the geometry argument is that I wanted to have a button (script) that launches 2 Nautilus browser windows in split-window fashion, to facilitate drag-and-drop operations. Here's my little test script for it:

nautilus --geometry=1280x512+0+0
nautilus --geometry=1280x512+0+512

This should open two full-width windows (my screen res is 1280x1024), one at top of screen and other at lower half of screen. 

I wonder if I shouldn't make the switch to KDE, and use Dolphin ....
Comment 9 Cosimo Cecchi 2008-05-11 00:43:22 UTC
I'm using SVN trunk and I'm not able to reproduce this bug with any of the steps in this report.

$ nautilus --geometry=foo

does *nothing* here, but

$ nautilus --geometry=foo /path/to/foler

correctly opens a window with the right size.
Maybe I'm missing something?
Comment 10 Tony Whelan 2008-05-11 01:01:09 UTC

I'm afraid that doesn't work for me. 

As far as I can tell, Nautilus remembers the last window size and position it had, and ignores any subsequent geometry argument passed via a command line.

You can test it by running the command as you suggested, then resize the resultant window (eg maximise it), then close it. If you now run the exact same command again, I think you will find that the window opens with the resized dimensions rather than those in the geometry command.


Comment 11 Tony Whelan 2008-05-11 01:02:21 UTC
Cosimo, please excuse the typo in your name above
Comment 12 A. Walton 2008-05-11 01:10:46 UTC
Please test trunk, this commit should have fixed that.

2008-04-27  Cosimo Cecchi  <>

	* src/nautilus-navigation-window.c:
	Always properly remember window size, also in the case the window is
	closed being maximized. (#385176).
Comment 13 Cosimo Cecchi 2008-05-11 01:12:49 UTC
Tony, thanks for the quick follow-up.
I can reproduce it too with your steps, but only if I maximize the window, i.e. it will ignore the --geometry argument until I demaximize it.
Comment 14 Tony Whelan 2008-05-11 01:17:32 UTC
Cosimo, I believe you're correct - de-maximising the window before closure does seem to allow a subsequent geometry argument to function correctly.

Comment 15 Larry Olin Horn 2008-05-11 02:17:57 UTC
Just for clarification (since the Summary was changed to include "maximized") ...

I almost never use maximized windows.  None of the problems I've had have involved maximized windows, nor did any of the tests I performed involve maximized windows, either starting out, during the process, nor at the end.

    nautilus --geometry=foo path/to/dir

works, *if* the dir has never been opened before; however, the same command

    nautilus --geometry=foo path/to/dir

for subsequent opens ignores --geometry; it instead uses remembered geometry (note: NEVER maximized, just repositioned and/or resized)

Is anyone aware of when this was fixed for NON-maximized windows after v2.20.0 (that was the version I mentioned in my original comment).
Comment 16 Cosimo Cecchi 2008-05-11 10:09:27 UTC
Larry, I believe you're right too, though that only happens in spatial mode. Modifying the summary, let's try to get this fixed for 2.24.
Comment 17 Cosimo Cecchi 2008-05-12 17:55:05 UTC
Created attachment 110789 [details] [review]
proposed patch

This happens because in nautilus-shell.c we set the geometry immediately after creating the window. This isn't right because when we create a spatial window, the saved geometry is a metadata of the location we're going to open, and the metadata is retrieved asynchronously. So we end setting our geometry before the saved one, losing the information.

Attached patch solves this setting the geometry only after the window has emitted the "loading_uri" signal, which is done after the metadata is set, but before showing the window.
Comment 18 Christian Neumair 2008-05-19 12:29:18 UTC
We are discussing way to many issues in this bug report, and some of the reports are not entirely clear because it is not specified whether people use spatial or navigational mode.

The original issue Anand reported has definitly been fixed. It works like a charm with Nautilus 2.22 or later. Larry seems to have the same problem. I suppose it was a Metacity issue, though I can not proof it.

Tony's issue that browser windows are opened in a maximized state even if --geometry has been passed in has been fixed by the commit mentioned in comment 12, and two commits I made some minutes ago:

I am closing this bug report as fixed. Please open a new one if you still have issues with Nautilus 2.22.3, 2.23.3 (not yet released) or later.
Comment 19 Cosimo Cecchi 2008-05-19 12:36:40 UTC
Sorry, clicked the wrong button.
I'm opening a new bug for this, your patch doesn't solve what I describe in comment #17.