Remove all the project code.

Ok, "remove all the existing project code", obviously there is then new code based on my suggestion to be added.

This will break multiple plugins.

Why? Plugins should not be writing to these files directly, they should be writing to the g_key_file structure obtained from Geany, as project-organiser does. It doesn't matter which file that structure maps to if it has the settings in it.

This breaks existing API.

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.

This breaks how users interact with projects.

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 New Project dialog).

This is the removal of an existing capability.

No, it is the extension of an existing capability to be much more capable, projects would be able to set any setting.

Users aren't given any choice in the matter.

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.

Apparently no longer an issue since the session_split branch has been merged without addressing it.

Guess @kugel- was persuaded enough not to worry.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications on the go with GitHub Mobile for iOS or Android.