Improve user experience when creating new projects

[techee]

At the moment, when creating a project, the user is greeted with the
dialog containing:

1. Name
2. Filename
3. Base path

The user is expected to type the name of the project into (1), and then,
Geany tries to guess the base path and file name. The guess simply takes
the project directory specified in settings and appends the name. When the
project is located anywhere else than in the projects directory,
the guessed values are wrong and have to be entered manually which is
quite annoying. In addition, the dialog doesn't make it clear that the
user should start with (1), when he starts with (2) or (3), he has to
fill in all 3 values manually.

I think we can do better - instead of entering the project name and
guessing base path based on that, we can go the other way round; first,
get the base path and then, from the base path provided by the user,
set the project name and project file.

With this approach, Project->New:
a. First pops up a open directory dialog to specify base path
b. After that, opens the (currently used) New Project dialog which
is pre-filled in the following way:

1. Name: The last directory in base_path
2. Filename: depending on "store project file inside the project base
   directory" settings either in base_path/(1).geany or projects_dir/(1).geany
3. Base path: path specified in (a)

This way, in most cases, the user will only have to select the base
directory in the first step and use the pre-filled values without
any modification no matter whether the project is stored in the projects
directory or not.

The other 2 patches:

1. Simplify configuration of the project by automatically opening the project properties dialog upon project creation.
2. Use "Store project file inside the project base directory" by default
   For more description of these 2 patches, see the commit messages.

[elextr]

I totally agree the "new project" dialog is dodgy and confuses people.

I think we can do better - instead of entering the project name and
guessing base path based on that, we can go the other way round; first,
get the base path and then, from the base path provided by the user,
set the project name and project file.

This approach seems better than the existing confusion.

a. First pops up a open directory dialog to specify base path
b. After that, opens the (currently used) New Project dialog which
is pre-filled in the following way:

Name: The last directory in base_path
Filename: depending on "store project file inside the project base
directory" settings either in base_path/(1).geany or projects_dir/(1).geany
Base path: path specified in (a)

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.

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

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

[dolik-rce]

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.

[techee]

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.

[xiota]

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

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

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.

geany/geany.geany
geany/geany-plugins.geany
geany/plugin-geanylua.geany
geany/plugin-project-organizer.geany
geany/plugin-tweaks-ui.geany
geany/plugin-etc.geany

[techee]

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.

[xiota]

Can I suggest instead of serial popups ...

What about a "wizard" interface? A single dialog that indicates progress through some number of steps? Does GTK have a standard wizard system? (Personally, I don't like wizards dialogs, but I like multiple popups even less.)

[xiota]

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 (appear to) preserve it.

[xiota]

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.)

[elextr]

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.

[elextr]

Can I suggest instead of serial popups ...

What about a "wizard" interface? A single dialog that indicates progress through some number of steps? Does GTK have a standard wizard system? (Personally, I don't like wizards dialogs, but I like multiple popups even less.)

No Wizards just Assistants, never tried it, don't know how applicable it is.

[techee]

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).

[xiota]

Related: #2245, #450.

[xiota]

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.

[techee]

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.

[techee]

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.

[xiota]

Well, yeah, one could do anything, it's just a matter what's a realistic amount of work for such a minor feature...

Based on the code in your other PR, the checks and conversion for relative/absolute paths are just a dozen or so lines, most of it declarations and cleanup. Then maybe another dozen or so lines of GUI code.

I don't have time (and motivation) to write this and I guess nobody has time to review such a patch...

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

But I still think moving the project file while the project this file describes is loaded would be really tricky.

Update the paths and save/close the project. Move and reload the file.

[techee]

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]

Renaming project file may be useful for someone but it's something I personally don't find essential... It could be another PR if someone is interested to do it.

Agree that it would be better as a separate PR.

that are compatible with existing user's workflow and don't break anything for them

This PR changes the project creation workflow. Here's an approach that would minimize changes to the current workflow:

• Have a default project name, filename, and basepath already filled in. Something like "New Project", which is preselected so the user can change it if desired.
  • This would make understanding the meaning of the fields easier.
• When any field is changed, change the fields that haven't yet been changed by the user to match.
  • No new steps would be added
  • Users can fill in options in whatever order they want.
• Extend the Preferences / General / Startup / Paths / Project files to accept . and .. to refer to the project base path and the project parent folder.

[techee]

@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
2. a. either Filename: /Users/techet/Downloads/my-project/my-project.geany
   b. 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.

[techee]

Maybe, as mentioned in #2245, we could rename "Project -> New..." to "Project -> New from folder..." so it's clear what the initial directory selection dialog is.

[xiota]

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".

[xiota]

Maybe, as mentioned in #2245, we could rename "Project -> New..." to "Project -> New from folder..." so it's clear what the initial directory selection dialog is.

I am against renaming and changing the behavior of the existing menu item. Users should not be required to select the folder first. There are cases where the folder may not be known at the time of project creation (eg, has not been cloned from git yet).

I suggested adding a new menu item earlier.

[xiota]

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

• Geany does not currently have any (usable) defaults filled in when the new project dialog is opened. (filename is filled in with a folder path, which is useless; base path is filled in with the "project files" 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.

[elextr]

See #3022

[xiota]

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

[techee]

@xiota I'm not sure I'll have time to continue in this discussion which doesn't seem to lead anywhere and I'll leave space for discussion for others. Ultimately it won't be up to you or me if this pull request gets merged and our opinions are known now - it would be nice to get feedback from others too so I'd encourage everyone to try and decide for himself.

A few random notes:

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.

I think I'm an experienced user of Geany and the current experience of opening projects is terrible. @dolik-rce agrees, the guys in #2245 agree, other guys I talked with in person agree. I respect your opinion but if it's just a matter of doing things in a different order, you'll just have to get used to a slightly different workflow but nothing will be dropped.

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.

It's not a personal preference - it's a necessity if you want to set the other 2 values correctly. But again, this is how other editors work and what people in #2245 suggested - open project as if it were a directory. And newcomers will be used to that much more than the tedious project creation Geany has now - in every editor you just have to specify in which directory your project is.

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.

It doesn't. If you press cancel in the first dialog or select a whatever directory, you can customize everything in the second dialog. But I think once you get used to it, I'll actually be happy when everything is pre-filled for you.

(I) 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.

It's just a matter of doing things in a different order - if you don't have a folder with a project, you don't need the Geany project and its creation can wait until the moment you have your sources. When you know project opening works this way, you'll just create the folder first. But again, as stated before, you still have your option to customize everything in the second dialog. Other editors won't allow you to create a project without having a directory for sources and I doubt anyone has ever complained about that.

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. I definitely won't create a plugin just for this.

To be clear about some things:

1. 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.
2. If desired, I could leave "Project->New.." as it behaves now and add "Project->New from folder..." with this new behavior.

[xiota]

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.

[techee]

@xiota You have expressed your preferences here, I have expressed my (but not really just my actually) preferences here (same in #3015) and I'm not going to continue in this discussion. It's just beating a dead horse at this point.

[ell1e]

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

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 & as first thing, 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.

Cancel usually aborts a process entirely

I find this one a good point however. But I don't see why canceling picking a folder couldn't just fully back out. For a new project with no folder yet, if the folder picker has a "New Folder" button I think it would be fairly obvious for most users to just use that and to pick the new empty folder then.

If desired, I could leave "Project->New.." as it behaves now and add "Project->New from folder..." with this new behavior.

Fwiw, I think that also sounds like fairly intuitive to use to me while providing some more obvious flexibility. So maybe that'd be a good middle-ground? Edit: or I guess Project->New or reopen from folder... might make more sense? Or just Project>From Folder... Since I assume that'll work for existing folders with projects already in them too, not just for making new ones...?

[kugel-]

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.

So I would rather like to see a button to open the file chooser next to base diectory text entry (which I agree should be moved to the top). Then, one can leave that empty (or enter a non-existant path) and chose project file, or one uses the file chooser to select a base directory, in which case the other 2 fields are filed automatically.

I don't necessarily agree with turning on "Store project file inside the project base directory". I don't feel very strong about it but it seems out of place for this PR and should be discussed separately. I don't see that it's a required for improving the project creation dialog itself.

The same goes for automatically opening the project configuration. It could just as well turn out to be annoying so let's discuss that separately.

[ell1e]

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 could be fixed however with a separate Project>From Folder... action, and with simply only showing the project creation dialog after the folder prompt. The regular Project>New could then not show this folder prompt in advance, and work more like how you suggest.

Edit: a quick question on:

I don't necessarily agree with turning on "Store project file inside the project base directory".

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.

[techee]

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.

Just wondering, is the project actually usable for anything if the base path isn't specified? (Well, maybe really just as a named session.)

I don't necessarily agree with turning on "Store project file inside the project base directory". I don't feel very strong about it but it seems out of place for this PR and should be discussed separately. I don't see that it's a required for improving the project creation dialog itself.

Like @ell1e I think this is what basically every other editor does and will be the more standard (I'm not saying better, it's a matter of personal preference) behavior. The impact of this on the project opening experience is that this is independent of whether the user configured the projects directory settings to something valid or not so it will work out of the box.

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.

The same goes for automatically opening the project configuration. It could just as well turn out to be annoying so let's discuss that separately.

Let's discuss it separately then.

[techee]

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.

[ell1e]

IMHO more options in an IDE are usually good, if the defaults are ok. I think putting the project files inside the project folder might be a reasonable default at least.

Regarding the naming of Project>New From Folder..., just in case it was missed as I pointed out above this could make people think if a project folder already exists (e.g. cloned from VCS/a repo with geany project files already inside that repo) that it wouldn't work, which would be a bit unlike other IDEs with this concept where you can just pick a folder and if it's without a project file so far it creates a project in it, otherwise it just opens it. That is why I think a more neutral Project>From Folder... might be nice, since then it could adopt this "create or open" concept in its behavior as well. Edit: not that it needs to, but it might be what most users expect from other editors/IDEs out there

[kugel-]

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.

[ell1e]

"Store project file inside the project base directory" would be untouched (or even deprecated/removed).

How about making it a checkbox in the project creation dialog, and for "New" it would default to inside ~/projects (which means unchecked I guess?), and for "New from folder" to inside the project folder/checked as you suggest - but with an obvious way to toggle it right there in the creation dialog. That would also make it easier to find than a global pref for those who don't like the respective default.

[techee]

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.

[techee]

How about making it a checkbox in the project creation dialog, and for "New" it would default to inside ~/projects (which means unchecked I guess?), and for "New from folder" to inside the project folder/checked as you suggest - but with an obvious way to toggle it right there in the creation dialog. That would also make it easier to find than a global pref for those who don't like the respective default.

It would be possible to have such a button but it would have to affect the path that was already pre-filled with something based on this preference set inside the preferences dialog. Checking/unchecking should probably modify the path to the corresponding value. The question is whether this modification should happen even if the user manually started typing some another path. This might be a source of extra confusion.

[elextr]

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.

[techee]

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.