Hi, I'm coming from TextMate 2 on Mac, and TextMate does a great job with projects - by essentially making it invisible (frictionless). You just open a folder, and that folder automatically becomes a project.
Geany could easily do something similar in my opinion. I don't know if the GNOME file picker allows you to pick either a directory or file, but if so, just do that and automatically create a new project file with the same name as the directory you 'Open'. If not, just have a separate "Project -> New from folder" menu option that is for choosing a directory.
If you implement this it will really make using Geany a lot nicer. Imagine being able to open up any random git clone you did and having everything 'just work'. Especially if you have the .editorconfig plugin installed.
Failing that, you could at least remove a little friction from the New Project form. I think if the path in the 'Filename' option is changed, it should automatically adjust the 'Base path' to match it.
There are three or four project plugins available for Geany which implement various versions of the "one directory" paradigm. Perhaps you should check out those.
@chrisgraham I fully agree, and have been considering making a pull request to do this, or least investigating how difficult it would be. Being able to change into a source directory and type `geany .` and not have fiddle with making/closing/opening projects would be super handy. SublimeText and VSCode, two other editors I use from time to time, also do this.
@elextr using plugins which add even more ceremony to opening/using projects is the antithesis of this feature request.
Related to and/or duplicate of #450, #1171, http://geany-users.466218.n3.nabble.com/Geany-Users-open-folder-td4025296.ht...
@codebrainz yes, but __which__ plugin features will you choose to make core? The fact that there is more than one says to me that there isn't agreement on what those features should be, and then people like me don't have the project file in the git directory but the one above, that also contains the build directory(s).
yes, but which plugin features will you choose to make core?
It's actually less "features" than even the builtin project support, let alone plugins. You just run `geany some/dir` and it takes the directory passed to it as the base path of the project, and the basename of the directory as the project name (for display purposes only), and you get zero-configuration projects for the simple case.
TL;DR: I think projects in Geany need a complete rethinking and rework
I agree with the principle here. Geany wants to be fast and small but with powerful features. So I agree that we should ship a bare minimum feature-set to turn a "drive-by git clone" into a (temporary) project, with some smarts about what to do with the project.
- detect vcs type, read .gitignore - generate tags - detect how to build for the most common build systems (remember not all projects are compiled C code)
Projects are currently rather poor. Annoying to set up and they don't offer truly useful features that justify setting them up. This is why so many project plugins exist, but they rather add more features to the project instead of making the setup easier. But those plugins cross the line of "fast and small but with powerful features" because they're even more difficult to setup...I've tried them all.
And then there is the annoying fact that the file list and project config are the same file so it's simply not possible to check it into VCS.
Projects are currently rather poor. Annoying to set up and they don't offer truly useful features that justify setting them up. This is why so many project plugins exist, but they rather add more features to the project instead of making the setup easier. But those plugins cross the line of "fast and small but with powerful features" because they're even more difficult to setup...I've tried them all.
I have added some simplifications in the last weeks/months to the Workbench plugin. It can now set the filter using the ```.gitignore``` file - so you don't need to type in the filter patterns anymore (but yes - you have to setup the option still). Also for quick setup there is a menu item "Search projects". It crawls through a directory for ```.geany``` files and shows the list of found files. Then the user can select which projects shall be added to the Workbench. At the moment the plugin does not create or change projects so there is room for improvment. Feature request/ideas are welcome but please open a new ticket in Geany-Plugins then.
@kugel-
I think projects in Geany need a complete rethinking and rework ...
Agreed.
I don't think Geany does projects, and the feature it has thats called "projects" is misnamed. That causes people to expect something like all the other IDEs "projects" features. The current really lightweight "named sessions" feature Geany has is really good in many cases, so it should be kept (but renamed) and a "proper" projects capability added.
However a "proper" projects capability is inherently language and toolchain specific. A C/C++ project needs different features to a Javascript one to a Julia one to a Python one. And the users expect that too, a Python project doesn't "Compile" or "Make" stuff.
One thing that would really help is if filetypes could load plugins automatically to support their language/toolchain. I used to have a prototype of this, its really easy to do, and it would allow a filetype selection to import the smarts not just for its type of project, but for its whole infrastructure.
@kugel- and @chrisgraham
But one thing I'm somewhat confused about is what you actually gain by setting up the current "project" on a directory? Current projects have no capability of reading the language, compilers, toolchain or any of what a "project" in other IDEs implies, so what does it give you to "set one up" on a particular random git checkout?
The current really lightweight "named sessions" feature Geany has is really good in many cases, so it should be kept (but renamed)
There are many project specific settings besides sessions.
the file list and project config are the same file so it's simply not possible to check it into VCS.
Yes, this is a long and standing issue. Having a separate session file would fix this. Conceivably other project settings would fit there too, not just session info.
Yes, this is a long standing issue. Having a separate session file would fix this.
Yeah, there are discussions going back to 2013 on the Geany devel ML, eg https://www.mail-archive.com/devel@lists.geany.org/msg01278.html was the first that searching for "session file" found, but no actual designs that were agreed and implemented.
This is *the* major reason why I personally don't use geany :cry: I love the new fancy "open folder" concept where the folder just magically is shown as a complete file tree, but Geany only allows me to open single files or a project file by default. It just feels clumsy and inflexible, in particular the concept of project files just feels so outdated... All the newer IDEs like VS Code get it right, but they also all use Electron and run really poorly. It's quite a shame and it'd be so cool if geany could do this better out of the box!
To make a concrete UI suggestion, I think the file menu could be changed to:
``` New File New File (with template) >... Open Folder as Project... Open File... Open Selected File Recent Files ``` ... and the `Properties` entry expanded to a sub menu: ``` Properties > Current File Properties > Project Folder (grayed out if no project folder opened) ``` And the `Project` menu could then eventually just be removed. The new `Properties > Project Folder` would handle any settings worth keeping in a sort of `.geany-settings.yml` file in an opened-as-project folder and therefore replace `Project > Properties` in the long run.
The `Documents` tab could then be automatically opened if `Open Folder...` is done, and list the opened project folder automatically with all its files (rather than just the opened ones), or if you don't want to expand it like that, there could be a separate `Project Folder` tab that otherwise looks like the `Documents` tab but behaves that way with listing all folder files rather than just the opened tabs.
For anyone interested, I created a pull request trying to solve this issue here #3018.
github-comments@lists.geany.org