New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
session_split branch long term issue: applicability to projects #3015
Comments
So far a "project" is mostly a named session, with various extensions in the past to make it look more like something project. I, too, would like to change that situation. Store the session part elsewhere (your suggestion is nice), so that the remaining project part is largely static and invariant across systems, so that can be checked in. Likewise, my goal for the session split is to be able to store geany.conf in my personal "dotfiles" repository that I sync between laptop and workstation. @elextr @eht16 @b4n is this something you'd agree with? If yes, then we should target that and I'd volunteer to help getting this done. |
This is good to know for when I attempt to extend the stash system. |
Nobody is thinking big enough, I suggest an alternative option. Remove all the project code. Then make "projects" to use the equivalent of A note on the OP, who will delete the session files? I remember @kugel- being worried about that when |
The same entity who deletes the thumbnail cache. It would be simple to keep a list (in
Apparently no longer an issue since the session_split branch has been merged without addressing it. |
Ok, "remove all the existing project code", obviously there is then new code based on my suggestion to be added.
Why? Plugins should not be writing to these files directly, they should be writing to the
Why? We can leave project related functions, they just have to act on different structures inside Geany. Then they can be deprecated for a few years, then they can be removed at a point that the ABI is broken anyway.
Why? I havn't even mentioned what the GUI should look like, and to be clear I would want it to be at least the current capability (but with a more intuitive
No, it is the extension of an existing capability to be much more capable, projects would be able to set any setting.
Because there is no choice to make, unless for some reason a user wants to remain straight jacketed by the existing projects capability. As I said above, it is not removing any capability so it doesn't need a choice by the user.
Guess @kugel- was persuaded enough not to worry. |
And to add, changes to stash would be instrumental to this changeover. |
You'll need to explain in a lot more detail what you have in mind.
Removing all or even just existing project code is essentially the removal of all/existing project functionality. That would mean, no more
You don't appear to really mean "remove all [/existing] project code", but to modify/extend projects in some undefined manner.
What changes? How do you expect it will be used? |
I don't like @elextr proposal. I want project files to be suitable for shipping it with the project itself. Carrying all user preferences (GUI-related or not) is not appropriate.
Well the session split for projects is not implemented yet. My worries was about where to store .conf. @xiota idea is nice, but the I'm not sure if XDG_CACHCE_DIR is appropriate. Normally it contains files that can be regenerated by programs without user interaction, like your thumbnail example. @admorris wanted to work on it but he disappeared unfortunately. |
I see I wasn't clear enough, sessions would still be split out from projects, which would only contain settings that were needed to be different for whatever the project the user was working on, not every setting but it could change any setting, instead of the current limitations. The point however is to allow (but not force) projects to contain any setting, even tweaked filetype files if its appropriate to the particular project a user is working on. @xiota this is a first suggestion of an idea, if you are looking for a complete design its not available, we will have to develop it, patience. There may be impossible obstacles, but its the way many other IDEs and other applications work, so I doubt its unimplementable. As to stash, the suggestion would be that stash supports overriding where sources of a specific setting override another. See for example how the build menu overriding works. At the moment it does not use stash since stash doesn't support the capabilities it needs, but as you say, there is no reason not to expand stash to do so. |
Do you have an example? |
Eclipse, depending where I invoke the preferences window from. it asks me if I want to edit the setting in the workbench or the project. I don't know if every setting is overridable, its got far more than Geany, and I'm only a baby Eclipse user. |
Some options:
#3000 (will be split into ~6 PRs) includes an override for non-GUI settings in stash. I wrote it with plugin use in mind, but it (or something similar) could also be used for projects, sessions, etc. |
When I said I'm unsure about XDG_CACHCE_DIR this means:
|
I just listed the major options I could think of at the time.
It depends on what you consider "session" settings. It seems different classification schemes are being mixed up under the "session" banner. For instance, @elextr stated that only settings affecting edited files are config and all GUI settings are session. That seems to better fit division by shared/personal. In a project, settings that affect edited files could be shared, while GUI settings are based on personal preference. I consider any setting Geany automatically manages as "session", while settings users explicitly set in preferences as "config".
Using this guideline, pretty much anything in session can be regenerated without consequence (since they'd all be auto-managed). If the session file is lost, the worst that would happen is the user would have to reopen some files. So But if "session" files contain a lot of settings that can't be regenerated, |
I didn't go through the whole discussion so I maybe missed something, just noticed this:
Does it mean the session information will be lost if the project directory is moved somewhere else? The whole point of #3021 is to preserve the session when the project directory is moved to some other place (which, right now, is quite annoying). |
If the project config and session are split, any scheme that is able to distinguish projects with different paths, but same basename, will risk allowing the session to be orphaned.
|
Well, what's actually the reason for this split? What problem does it try to solve? To me it seems it just introduces its own set of new problems. |
@kugel- Has described it this way:
As I've noted, there are ways to preserve your use case (retaining session info after moving project files). Personally, I would prefer to eventually have all three of the following:
|
But does anyone actually want to check in that? To be specific, when this change happens, will we, developers of Geany, want to have the project file checked in the Geany repository? I personally would say no. And I assume that one of the reasons why you store your project files outside the project directory is that it isn't version-controlled so you actually aren't a user of such a feature anyway.
Either do it or don't do it for everyone - having to deal with settings that are hard to explain to users and having to maintain 2 different modes of session storage isn't exactly what Geany needs.
No idea what this means.
Won't work if you move the whole project directory to a different location. (Not even talking about moving it to a different machine.)
This is probably the only sane option but then you are facing problems like sharing session files by 2 different projects when you have one Nobody prevents us to write code like that but I would leave such features to editors like Eclipse. Geany is a simple editor, we should come up with simple solutions that are easy to reason about and easy to explain to users. |
Apparently @kugel- does.
I store projects in a centralized location so I can easily switch among them. I'm not against checking in a project file if the issues are resolved. If a suitable project file were version controlled, I could copy or symlink it. This makes new-project creation easier for new users because they don't have to do it at all.
Different people have different preferences, so I am for having more options, provided the program logic they control is not too complex. The current config/session split implementation is likely not the end. With appropriate changes, preferences could very easily be moved around in different files.
For moving to a different computer, I suggested having a preference to store the session in the project file. If you don't like having the option, you don't have to use it.
Simple? Have you seen the 74-page manual? |
See #3022 |
I don't know, maybe @kugel- has more to add, but I can't imagine I'd go to some open source project and suggest adding the Geany project configuration file - I'd be stoned to death because everyone uses a different editor. And I can't imagine I'd want that for Geany itself (which is probably the editor we all here use for Geany development). For instance, with my 8 core machine, I use There are IDEs where you simply have to include the project in VCS because these IDEs define how to build the project. Geany is not such an IDE - there has to be an external build system which is independent of Geany. Geany's project is just a selection of your personal preferences how to invoke the build system and this is not something that should be forced to others. Could you point me to a project that version controls VS Code, Sublime Text (or similar editor of your choice) to VCS?
But we should decide what feature is a good idea and what feature isn't. Blindly implementing every single feature users suggest without considering its implications isn't good for Geany. Question: did anyone ever actually wanted this feature in those 700-ish open issues we have?
Could you clarify what this is good for?
If we decide to change any Geany settings in projects, we can do this already.
As I said, nothing in Geany projects is suitable for sharing among multiple users - it's all personal preferences. And if you want to be able to change any settings in projects as stated above, things will get even worse.
If there appears some compelling reason in the future that overweights the drawbacks of of the current design, let's implement it then. But until then it's just the drawbacks and things like "it might be useful" without saying exactly what for.
You seem to be a fond of solving everything by adding new configuration options - but if we added configuration options at the rate you suggest adding them, everything would get quickly out of control. And this is even more true with configuration options that are specific to our internal implementation - when there's a configuration option "use CRLF for line endings", everyone knows what it does. If you add configuration option "store session information into project files", nobody knows what it does and what implication it has because it's specific to our implementation.
I've been around much longer than you and I have contributed to that manual too so yeah, I have seen it. And we don't want to convert that file to a 1000-page manual by adding new and new configuration options. |
To be clear, I mostly dislike the design that sessions are stored somewhere deeply in but had 6 years to realize it was a bad idea ;-). (No, frankly, basically I abandoned #450 because I realized this isn't a good match for Geany.) If it turns out turns out that splitting projects/sessions has some big benefits (and I don't see that myself now), I would much rather see |
That's part of why I suggested
That is a scenario I would prefer to avoid, and it illustrates why I like options. People have different, incompatible preferences. Save location is extremely easy to change. If you want side-by-side files, you can have it via an option. Let other people store their sessions elsewhere. If you insist on not providing options, you're basically saying everyone should be forced to use your personal preferences. (Like when you had me remove the option to change the terminal command in prjorg. Until I rewrite preferences to your liking, anyone who uses that command is pretty much forced to use xterm. The saving grace is that few people prefer xterm, so there's motivation to eventually add the option to change it.) |
I use Geany also for work and there we happily accept editor-specific files in the repos if it helps our engineers to get their job done. This is especially true for Windows and OSX stuff where we commit the whole VS and Xcode project metadata (multiple files). I also wouldn't take it as a given that each and every FOSS project would stone you to death, that seems extremely exaggerated. I can imagine a lot of project maintainers aren't opposed if it helps on-boarding contributors or making their lifes any easier. After all, it's just a text file that doesn't hurt anybody else. If we accept geany.geany within Geany itself it would indicate that the scheme is working as intended, so I wouldn't say no. |
Good employer :-).
Yes, but this is a necessity - in XCode for instance the project itself defines how to build it and I, too, have it committed for the macOS launcher of Geany here: https://github.com/geany/geany-osx/tree/master/Launcher/geany/geany.xcodeproj Geany, on the other hand, doesn't define the build process itself and the way I see it, it's a bunch of personal preferences of how to run the build process or launch your project and these may differ user to user. I gave the example with Or to tell it in another way in terms of XCode: xcode project ~~ autotools or meson build system and is committed Since the way I see Geany projects is personal preferences only, I don't see much need for the project/session split (and having to deal with the various problems discussed above). |
geany.conf
andsession.conf
are basically hard coded (macro defines). This doesn't address splitting config/session in project files.keyfile.c
andproject.c
are currently parallel keyfile management implementations. The session split doesn't do anything to unify them, and potentially makes unifying them more difficult. (Especially if there's resistance to changing code that's already been merged.)A minor change that would make unifying geany and project sessions easier is to change the location and filename of
session.conf
. Instead of hard coding it, it could be stored in~/.cache/geany/sessions
with filename[basename]-[md5-of-path-of-original-conf].session.conf
. (This is somewhat based on how image thumbnails are cached.)Note:
keyfile.c
andproject.c
would use the same function to lookup/generate the session path. The function could reside instash.c
orutils.c
.The text was updated successfully, but these errors were encountered: