For example, the most recent file you worked with is from that directory (you opened a file in that directory or saved a file to that directory). You then closed the file and create a new file. The directory is no longer remembered. It will default to save the new file into `C:\Program Files\Geany`. Anyway, `C:\Program Files\Geany` is not a location to save your files.
Normally the dialog opens in the directory of the current document. If that does not exist (no documents open or a new unsaved document) it opens with the current working directory. For Geany started from the command line this is sensible.
Unfortunately on Windows for some Windows weirdness the working directory is changed from the startup working directory to the only other directory Geany knows must exist, the installation directory, the comment in the code says:
```C /* On Windows, change the working directory to the Geany installation path to not lock * the directory of a file passed as command line argument (see bug #2626124). * This also helps if plugins or other code uses relative paths to load * any additional resources (e.g. share/geany-plugins/...). */ ```
Not sure where that bug number is from, Sourceforge never went that high, maybe its pre-Sourceforge SVN. One of our [elephants](https://en.wikipedia.org/wiki/Elephants_Can_Remember) might know more.
I didn't start Geany from the command line. On Windows, there is no reasons for me to start Geany from the command line.
Doesn't matter, as the post above says the working directory is changed on Windows to avoid some problem with file locking that doesn't happen on Linux.
Starting Geany from a GUI means there is no sensible directory to open in, so as stated above, the working directory is changed to the install directory on Windows, so thats where it opens. Not sure what it does on Linux, might depend on the distro.
Closed #3664 as resolved.
Just to clarify, the described behavior is not implemented. To me it first read like a bug report but it is not, the current behavior is rather intended. Though it could be changed if someone wants to.
It is completely unrelated to Windows, on Linux Geany behaves the same (except that the default directory is usually $HOME and not the installation directory).
Not sure where that bug number is from, Sourceforge never went that high, maybe its pre-Sourceforge SVN. One of our [elephants]
Uh, apparently I'm an elephant. The bug number in the code corresponds to issue https://sourceforge.net/p/geany/bugs/268/. Some years ago, Sourceforge converted the long bug numbers to shorter ones, you can still search for the old IDs on the Sourceforge site and it finds the correct issues.
But still unrelated to the OP.
Uh, apparently I'm an elephant.
Well, Enricos never forget, as just proved :grin:.
Clearly I wasn't clear enough so to be clear (pun intended) after unravelling the spaghetti (code) the process for setting the base path of the file dialog is the same on all platforms (first found "wins"):
1. the directory of the current document unless no document or current does not have a filename, ie `untitled` 2. if a project is open then the project base path if it is valid 3. if `Edit->Preferences->General->Startup->Startup Path` is set then that value (which I didn't know until tracing the code) 4. if none of the above, the gtk file chooser is left to its own devices, and seems to choose the current working directory
The OP said "Anyway, C:\Program Files\Geany is not a location to save your files." and I concur, but what I was saying was that occurs because of point 4 _and_ the fact that on Windows the working directory is changed to the install dir due to silly windows locking process current dirs. Although the OP has "no reasons for me to start Geany from the command line" clearly others do, or the locking problem would not have been noticed and the SF bug would not have been raised. The solution of changing the WD to some other directory that the user won't want to remove is good, and the Geany install directory is all Geany can be sure exists, so using that is reasonable. But it has the side effect of becoming the default location of the open dialog.
On Linux the working dir is not changed and using that makes sense if Geany is started from the command line, but if started from the menu/shortcut it will be whatever the window management system chooses as the working dir, and as noted above at least on some systems that is HOME.
So yes everything is intended, but it has the side effect of having the open/save dialog open in an unhelpful directory by default on windows.
Anyway having discovered the setting at point 3 exists, @iahung3 that looks like a solution for you, set it somewhere that you find useful, note it is an absolute path.
Although the OP has "no reasons for me to start Geany from the command line" clearly others do, or the locking problem would not have been noticed and the SF bug would not have been raised.
I don't know how Windows does it, but the same problem would happen if the default working directory is the one containing the file to open (e.g. if the WD is `C:\A\B` when opening file `C:\A\B\c`), which wouldn't seem particularly silly to me.
Anyway having discovered the setting at point 3 exists, @iahung3 that looks like a solution for you, set it somewhere that you find useful, note it is an absolute path.
Alternatively *if* Windowsers agree, we possibly could try and default the open/save dialogs to [`g_get_home_dir()`](https://docs.gtk.org/glib/func.get_home_dir.html) on Windows I guess.
I don't know how Windows does it, but the same problem would happen if the default working directory is the one containing the file to open (e.g. if the WD is C:\A\B when opening file C:\A\B\c), which wouldn't seem particularly silly to me.
IIUC thats what the SF bug is about, windows locks its WD[^1], and so the only "solution" is to change the WD so windows locks some irrelevant directory. Because that directory has to exist to CWD to it, the Geany solution of using its install is reasonable, its pretty sure to exist :-).
Alternatively if Windowsers agree, we possibly could try and default the open/save dialogs to [g_get_home_dir()](https://docs.gtk.org/glib/func.get_home_dir.html) on Windows I guess.
Thats possibly sensible, yeah.
[^1]: its not as silly as it seems, not allowing the base for relative paths to be removed while the process executes is good.
Is there any point in putting efforts into this? As @elextr pointed out already a good option for the OP problem (`Edit->Preferences->General->Startup->Startup Path`), I think Geany is already customisable enough to leave it as is.
@b4n @eht16 Note that none of the suggestions above nor the `Startup Path` setting actually address the OP.
Without a project when the current document has never been saved or all documents are closed, Geany next starts the open/save dialog in a fixed directory, unrelated to where the user has just had files open, or even still has files open if its saving a new file. This happens on all platforms, just the fixed directory is different.
I suspect the maintainers are all too used to running Geany with projects, and so don't see the inconvenience. Without a project it is not just at startup or when all files are closed, but also when any new file is saved.
All the discussion has been about modifying that fixed directory to something more useful, which is fine, but does not address the actual issue, that the user has to re-navigate to the directory they want to use.
The suggestion by the OP of remembering the last directory used seems to me to be more likely to be correct than any fixed directory.
But of course "somebody" has to do it.
github-comments@lists.geany.org