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
_______________________________________________
Geany-devel mailing list
Geany-devel@uvena.de
https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
