...

Use "Store project file inside the project base directory" by default

Personally I usually do this anyway, what do other people think?

Same here. Actually all of what @techee described sounds as if he was looking over my shoulder when I was creating a project. And it happens every single time, I fill the name, have to correct the paths and then open settings.

Can I suggest instead of serial popups, have a single popup with base path at the top with focus on it and the other entries insensitive. When the base path is entered fill the other entries as described and set sensitive for users to twiddle as needed.

That would be possible but it actually requires an extra click from the user to open the directory dialog anyway plus there has to be some initial value in the base path entry like `~/projects` which may not exist and may confuse users.

Basically, the way I see the project creation process is: project creation = opening the directory with the project. This is the first step this pull request does, the second dialog is just the possibility of further customization but in most cases can just be confirmed.

I've been keeping project files together, outside of the project folders. To switch to something else, I can double click the relevant project file without having to do much navigation in the file manager. To access the contents of the project folder with the file manager or terminal, I use a keybinding with geany/geany-plugins#1126.

Just to be clear, this pull request just changes the defaults for the option "General->Miscellaneous->Store project file inside the project base directory" and your use case is still preserved.

Just to be clear... your use case is still preserved.

That's good to know... I had seen a previous pull request that didn't preserve it.

but it actually requires an extra click from the user to open the directory dialog anyway

Its a pity we can't change the name of the open dialog to "Select project base directory" and go straight there, or maybe we can if a FileChooserWidget is embedded in the first dialog?

there has to be some initial value in the base path entry

`Edit->Preferences->General->Startup->Paths: Project files` I would have thought.

What about a "wizard" interface?

For the wizard to make some sense, all the dialogs would have to be embedded in the wizard - otherwise the wizard would mean just more clicking around to open the other dialogs. Then it means to have embedded folder chooser (not sure if it's possible) but worse, the project properties dialog. I just don't think this is worth the extra effort.

If the project file could be renamed/moved from the Project Properties dialog... you could add a new menu item to the Project menu: "New (from Folder)..." When clicked, the user would select a folder. Then the Project Properties would be opened with everything filled in with defaults. The filename could be highlighted to indicate that it can be edited. The user would be able to change other options as desired. (I'm assuming most people would want to edit preferences and properties after creating a project. So this would save several clicks.)

The problem with configurable project file name is that once you allow that, you allow moving projects to different directories and things start breaking when users use relative base path or `%p` from within the build tab. Users can of course do this from the file manager (and deal with the problems by themselves) but I wouldn't encourage this inside Geany.

Its a pity we can't change the name of the open dialog to "Select project base directory"

This is exactly what the patch does, it's just called "Select project base path".

and go straight there

I wouldn't skip the "New Project" dialog personally. This is the only chance to change the location of Geany's project file and the suggested path derived from the base path may not suit everyone (e.g. someone wants to have the Geany project file inside a subdirectory of the base path).

The problem with configurable project file name is that once you allow that, you allow moving projects to different directories and things start breaking when users use relative base path or %p from within the build tab. Users can of course do this from the file manager (and deal with the problems by themselves) but I wouldn't encourage this inside Geany.

You could... Check whether the path is relative and convert to absolute paths if needed. This should be better to keep things working than if the user moves files around in a file manager.

Well, yeah, one could do anything, it's just a matter what's a realistic amount of work for such a minor feature - this would be a lot of work and a lot of refactoring to do (just check build.c and imagine you have to update every single build command for every single filetype where %p appears). I don't have time (and motivation) to write this and I guess nobody has time to review such a patch and I guess nobody will be very thrilled about adding code like that that has to be maintained.

OK, forget about that, `%p` will just get expanded to the project base path so there should be no change needed. But I still think moving the project file while the project this file describes is loaded would be really tricky.

It looks like you've been working on variations of this for 7-8 years.

Exactly, and it never got merged. So the current strategy is to write 1. very small patches 2. that ideally don't add much code that would have to be maintained 3. that are very easy to review to preserve reviewer's time (yes, I know, says the guy who wrote the terrible patches for tag manager that cost 1 year of Colomban's life) 4. that are compatible with existing user's workflow and don't break anything for them

Renaming project file may be useful for someone but it's something I personally don't find essential, don't know other editors that would do that and don't feel very motivated to do that myself. It could be another PR if someone is interested to do it.

I don't think it's an improvement of user experience with creating projects either - yes, one dialog could be eliminated but at the cost that the project file is created at a place where the user didn't want to have it (e.g. because the "set project file inside the project directory" is set to something different than he expects) and will have to change it manually afterwards (if he actually notices).

@xiota How does this help? What you suggest is more or less how project creation works (or rather doesn't work) now. So for instance, assume that the preselected values are

1. Name: My Project 2. Filename: /Users/techet/projects/my-project.geany 3. Base path: /Users/techet/projects/my-project

and I want to open a project I just downloaded from the Internet which is in the `/Users/techet/Downloads/my-project` directory and the desired output is

1. Name: my-project 2a. either Filename: /Users/techet/Downloads/my-project/my-project.geany 2b. or Filename: /Users/techet/projects/my-project.geany 3. Base path: /Users/techet/Download/my-project

This is what you get automatically with this patch when you select base path first (2a or 2b depend on the project location settings).

Now without the open dialog at the beginning, as a normal user I don't know that I should start with (3) first and select the base path in the first step to get (1) and (2) filled in. If I start with (1) first, there's no chance to fill in (2) and (3) because Geany doesn't know I want to open something in Downloads. If I start with (2) first, Geany doesn't know where the project itself is stored, the project file can be stored elsewhere.

So once again, what this patch does is that it makes project creation as simple as opening a directory with sensible values filled in. This directory is selected in the very first step, otherwise no good guesses can be made about the other form values.

As I understand, this PR changes the current New Project behavior to:

1. Introduce a new popup so that the user chooses the base path before naming the project or choosing a project file name. 2. Automatically fill in the project name and filename based on the project folder.

What I dislike about this new method.

* Adds new popups (folder selection). * Increases the number of steps for users who do not want the defaults. * *Requires* users to select the project base path first. What about users who prefer to name the project first or select a filename first? + There are legitimate cases where the base path aren't known at time of project creation. (example below) * *Still* confusing for users who (are completely new to projects and) don't know the purpose of selecting the folder. + Most people do not stay new users forever. Experienced users should be allowed to streamline their workflow. This PR *prevents* that.

My workflow has been:

1. Choose a filename for the project first. 2. Then change the name. 3. Change the base path last. Sometimes I leave it alone and change it from Project Preferences later because the project folder may not yet exist at the time of project creation. For instance, I may not have cloned from git yet. 4. Update build commands *and* paths. (I sometimes defer choosing base path to the Project Preferences dialog because build commands and paths cannot be changed from the new project dialog.)

So this PR is *not* "compatible with [all] existing user's workflow*".

How does this help? What you suggest is more or less how project creation works (or rather doesn't work) now.

* Geany currently does not currently have any (usable) defaults filled in when the new project dialog is opened. (filename is filled in with a path, which is useless; base path is filled in with the project path, which is also pretty much useless) + The change I suggest is to have some defaults that should obviously be changed, like "New Project", ".../New Project.geany", ".../New Project/". + This change would let users know what types of values should be entered. For example, that projects have a `.geany` extension. * Geany currently only auto-fills the other fields when the name field is filled in first. + By auto-filling the other fields when *any* field is changed, your prefered process (selecting the base path first) is supported.

Now without the open dialog at the beginning, as a normal user I don't know that I should start... select the base path in the first step...

Currently, users can change the fields in *any* order they want. It is your *personal* preference to start with folder first. Other users should not be *forced* to conform to your personal preference.

So once again, what this patch does is that it makes project creation as simple as opening a directory with sensible values filled in.

That is not *all* this PR does. It also breaks any workflow that does not conform to your personal preference of filling in the folder first. It adds extra steps for anyone who doesn't want to use your preferred defaults.

What (technically) prevents this PR from being implemented as a plugin?

the current experience of opening projects is terrible.

I'm *not* saying the current experience is great/can't be improved. The issue is that Geany currently allows new-project workflows that this PR completely eliminates. I've made suggestions that would avoid that problem.

it's a necessity if you want to set the other 2 values correctly.

Setting project basepath first is not a "necessity".

* Geany currently allows the fields to be completed in any order. * The project name and base path can be changed independently from Project Preferences (showing that they are not related). * The file can be located anywhere, moved in a file manager, symlinked, whatever, like any other file, independently of the project base path.

But again, this is how other editors work...

Other editors doing things a certain way doesn't mean Geany must also. Geany does lots of things differently from other editors. If other editors are so great, why use Geany in the first place?

what people in #2245 suggested - open project as if it were a directory.

#2245 (and #1171) suggest opening folders as if they were projects. This PR is not close to doing that. For instance, what happens if a user drag/drops a folder into Geany? What happens if a user runs `geany /path/to/folder/`? These could be implemented without touching the New Project workflow.

If you press cancel in the first dialog or select a whatever directory, you can customize everything in the second dialog.

That is not obvious at all. Cancel usually aborts a process entirely. So another strike against this PR. Users who start the new project creation process have to cancel twice to truly cancel the process.

...

What (technically) prevents this PR from being implemented as a plugin?

Geany API doesn't contain a function to open project and I don't think this function should be added.

Why not? It could be useful for some project-based plugin, like Workbench.

Open project properties in the last step is just a convenience thing I added but I don't find essential and can be dropped if disliked by others. If desired, I could leave "Project->New.." as it behaves now and add "Project->New from folder..." with this new behavior.

New menu item (*Project / New from folder...*) plus no second dialog after folder selection is preferable to the implementation of this PR.

I think it makes most sense if the open directory dialog pops up first.

All other solutions IMHO have the risk to be overwhelming, and the risk to suggest this might be a "classic monolithic IDE with overcomplicated settings" scenario again. By having just a simple directory open dialog show immediately & at first the user is kind of primed this is a more modern workflow, and then when a follow-up settings thing shows up *but with everything already filled out* it is way more obvious that touching anything else is optional, and that geany is quite happy to proceed without me bothering with more than just having specified the folder. I think that would not be obvious if I was greeted with a base folder + name + whatever dialog to start with, with nothing filled in yet.

IMO opening file chooser automatically gives the false impression that a base directory is strictly necessary (it isn't). Also, it immediately hides the actual project creation dialog which seems awkward.

Both of these would be fixed however with a separate `Project>From Folder...` action, and with simply only showing the project creation dialog after that prompt.

Where are they stored right now? In other modern IDEs with the folder-as-a-project concept, they're usually somewhere in that folder (either at the root or in a subfolder), since a VCS/repo base is often expected to be at the project folder level, too - inside that project folder, not its parent. So if they're outside right now, I think that change would make sense, especially as just an option people can use if they want.

It can be anywhere you wish - the "base path" inside the project file defines the actual project directory. From my previous attempts to do something about projects I learned there are passionate lovers of this feature so it has to stay as an option.

I'm now leaning towards to what @ell1e suggested - keeping the "Project->New" dialog or slightly improving it and in addition having "Project->New from directory" that skips the second dialog and uses the default values I described in my first post. Again, it would be better to have defaults to store the project into the project directory because this would skip further configuration of the location of the project completely and users might be surprised where the project file got stored.

Perhaps this would allow removing the pref altogether. "Project->New from folder" would spawn the file chooser and then show the pre-filed dialog for confirmation (maybe one wants to change the project name, if you're running multiple projects against the same source repo). And it would default to placing the project file in the project. "Project->New" would spawn the project dialog directly. I think (some of) the improvements presented here should still be applied, like filing the dialog in case the base directory is selected first. However, it would default to placing the project file in ~/projects.

So basically your initial proposal under a separate button while also improving the creation process for current usages. "Store project file inside the project base directory" would be untouched (or even deprecated/removed).

@ell1e "open" is a separate functionality (that already exists). Also since there may be more than one project.geany file in a directory re-purposing "New from folder" for "Open" could become complicated.

Perhaps this would allow removing the pref altogether. "Project->New from folder" would spawn the file chooser and then show the pre-filed dialog for confirmation (maybe one wants to change the project name, if you're running multiple projects against the same source repo).

I have no problem with the double-dialog thing and I actually prefer this for more flexibility and clarity about where the project gets stored - I just thought it was something that was generally disliked here. From playing with it myself it feels quite natural and this is really just one click without any extra filling.

And it would default to placing the project file in the project.

But here I don't see a reason why not respect user's preference for the location of the project file when we have such a configuration option and people seem to use it. I think both "external project storer" and "internal project storer" type of people could benefit from this feature alike without having to modify the project file location manually.

If the second dialog for confirmation stays there, the defaults for "Store project file inside the project base directory" wouldn't be so critical though I would still prefer defaulting to something that behaves in a similar way like other editors (plus there's no requirement for setting the "project files" directory to something valid first).

So my current proposal would be the original proposal (minus opening the project configuration) under "Project->New from folder" while keeping "Project->New" untouched and defaulting to "Store project file inside the project base directory" enabled.

@ell1e "open" is a separate functionality (that already exists). Also since there may be more than one project.geany file in a directory re-purposing "New from folder" for "Open" could become complicated.

Yeah, the whole trouble with Geany projects is their (IMO) excessive flexibility but people are already used to the various ways how Geany projects can be stored and it's up to us to keep things compatible with existing use cases. I guess if I were to create Geany projects from scratch, I would just create a (possibly hidden) subdirectory in the project directory with various configuration files. Opening/creating a project would be just one thing - either a project is found and opened or it is created. The session split would be a non-issue because we could have as many files in the config directory as we would wish without any consequences. But we have to live with the situation that users have possibly multiple project files in the project base directory under different names or these files are stored somewhere outside the project.

I TL;DRed much of the above, sorry if I repeat anything.

@ell1e

I think it makes most sense if the open directory dialog pops up first. Here are my two cents on why:

Another reference point is that Vscode asks for a directory first for where to find code for the project, and put its `.Vscode` directory, and thats all it asks, everything "just works" after that. Eclipse insists on putting things in a "Workspace" which is in the users home. Vscode has workspaces but I havn't tried them yet, "single directory" being enough for what I'm using it for.

In the case of both of these I am in the position of being a new user, and my reactions seem to pretty much mirror new users of Geany, basically "I just want to do my work, not fiddle with your IDE". And can say the Vscode method is fast and easy for the single file C++ things I am using it for, and Eclipse is annoying to set up but then seems to support complex projects pretty much automatically from then.

@techee

But here I don't see a reason why not respect user's preference for the location of the project file

Yes, (AFAICT) having _BOTH_ project files in users home and project files in the project directory are used, maybe even by the same user (me) for different "projects".

Supporting that by having "Project->New" that defaults to something user specific as the project file location and has no base directory by default, and "Project New from directory" that opens the file dialog at the directory of the current file and sets both location of project file and project base directory seems a better way than making the process more complex by trying to combine them.

So my current proposal would be the original proposal (minus opening the project configuration) under "Project->New from folder" while keeping "Project->New" untouched and defaulting to "Store project file inside the project base directory" enabled.

I just did this in #3042 and I'm closing this pull request in favor of the mentioned pull request.