[Geany-devel] Proposal: Project settings split - adding geany features

[Matthew Brush]

On 11/03/2011 05:21 PM, Lex Trotman wrote:
> [...]
>> First, I'd like to address these points, but I have actually thought of an
>> alternative proposal which hopefully you might like and has much less impact
>> on code. I'll start a new thread.
>
> Ok, all specific points transferred to that thread.
>
> Just one note that the point of raising it in the ML before doing it
> was to see if anyone had better ideas for a solution.  Geany needs
> more of that, as exhausting as it may be, rather than taking the first
> suggestion or patch or pre-implemented pull request.  So thanks to
> Nick and all who contributed.
>

This is just my take on the topic/issues in general and there's probably 
some things I haven't thought of but ...

It seems complicated having two separate project files for a single 
project, from a user POV.  Wanting to check a project file into VCS 
seems like quite a common thing to do, and I might even do it for my own 
projects if the situation(s) in Geany were improved.

The way I see it, there's two issues currently:
   - session settings mixed with preference settings
   - things that should be able to be project-specific aren't

At a high level, the most sensible thing to do IMO, is to split out 
state/session information into a separate file 
(~/.config/geany/.geanysession) for Geany itself, and then mirror this 
in the project directory (~/project-under-vcs/foobar.geany and 
~/project-under-vcs/.geanysession).

Basically everything in geany.conf that is "stateful" should not be in 
that file.  Things like window geometry, open/recent files, sidebar pane 
position/etc.  I guess the delimiter here would be things that the user 
changes explicitly vs. those they change implicitly.  For example, the 
user doesn't change the sidebar position in a spin box, they just drag 
around the the splitter and expect Geany to respect this across 
runs/instances.  They don't choose a list of files that should open next 
run using filechooserbuttons, they just open the files and expect them 
to open again if they were open last close.  In this example, whether or 
not to re-open files on next run would be a preference.

Now take everything I just wrote and apply it to two other files; 
~/my-project/projectfile.geany and ~/my-project/.geanysession.  When a 
project opens, the project file and project session file "overlay" on 
top of the global/default settings/keys from ~/.config/geany/geany.conf 
and ~/.config/geany/.geanysession.  Changes to the sidebar position for 
example would get written to ~/my-project/.geanysession and a change of 
indent type would go into ~/my-project/projectfile.geany.

It's not exactly trivial to code it, but really it's just about which 
GKeyFile gets read and written to, the guts of the files would be mostly 
the same as now, just the project prefs file would be a copy of 
geany.conf with a [project] group, and the state data would be split out 
into separate keyfiles for each.  The logic to decide which file-set is 
simple: if project is open use the project files otherwise use the 
global/default files.  The logic to decide which things are session vs. 
non-session could use the approach I mentioned above.

I would +1 something like I've described assuming two things:

   - someone cares enough to do it (Lex?)
   - the code isn't just tacked onto the existing code, but instead the 
time is taken to clean up the existing code around this and implement it 
right so that all preferences and session data are split, and both are 
available in both projects and non-projects (except where it might not 
make sense, can't think of an example).

Doing this would solve both the code maintenance issue - by generally 
improving the whole project support and session support and related code 
- as well as solve the origin problems and in fact even improve Geany 
substantially, IMO.

The issue of backwards compatibility could be solved by adding a 
function that splits out the settings and writes them to the separate 
files if an "old-style" geany.conf or myproject.geany file are detected 
- probably confirming this with the user via a dialog or something. 
This shouldn't be terribly hard.

Sorry for the long explanation.

>
> As an example Geany has many places where a short function then calls
> another short function which calls another short function, none of
> which are re-used.  Personally I find this way of writing code less
> efficient and very hard to follow and understand as a whole, but
> others find it easier to think only in terms of each little piece.
> YMMV
>

Although it's somewhat off-topic, I have to agree.  IMO, if a little 
chunk of code is only used in one spot, it shouldn't have it's own 
function, at least in most cases.  I find it much easier to follow a 
slightly longer function than chasing the logic around little blobs of 
code scattered around the files.

Cheers,
Matthew Brush