Re: [Geany-devel] Proposal: Project settings split - adding geany features
On 04/11/2011 00:21, Lex Trotman wrote: 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. Agree if people are likely to disagree on it, if the feature changes much code or causes implications for future additions etc. (Obviously we don't want to discuss everything as it would cause too much delay). My points are not just dev issues - users may want to backup their project file, which would be harder. I don't understand how it would be harder, but anyway thats a specific. You would have to backup 2 files instead of 1 - not hard, *if* you understand this, but still more bother. Users need to read the manual, which would take longer to understand. Again this is a specific, but I don't understand how having session info in a session file and project info in a project file is harder to understand, or that most users would even need to care. I didn't say harder, I said it would take longer. Anyway sometimes they do need to know (e.g. backup). Users might have to use buggier software, as more complex code is always more bug prone. Development issues become user issues indirectly. On 04/11/2011 00:21, Lex Trotman wrote: Complicated isn't an absolute, it very much depends on experience, something you think is blindingly obvious I may find horrendously complex because I've never thought of that paradigm before. I agree that if the implementer considers it simple it is more likely to be right, but that doesn't guarantee that all maintainers will easily get their heads around it. Complicated means more code changed than necessary (for sake of argument). ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Proposal: Project settings split - adding geany features
On Thu, 03 Nov 2011 20:03:02 -0700 Matthew Brush mbr...@codebrainz.ca wrote: 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). Why not ~/.config/geany/geany.session and /.../project.geanysession? I woudn't like geany to place a hidden file in the project directory, with no way to move it in the project file directory. 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. Would be nice, unless Edit - Preferences decides to save the full set of options (even unchanged ones) in projectfile.geany. If I decide to change, say, the symbol list font, and have to do that for every project... well, the current configuration seems pretty reasonable. But compating the two option sets, and (ideally) indicating the default (unchanged) settings with gray, as in the build dialog, goes beyound not exactly trivial. -- E-gards: Jimmy ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Proposal: Project settings split - adding geany features
On 02/11/2011 23:03, Lex Trotman wrote: [...] Everything else is shared via VCS, so its annoying that one thing isn't. As I said, you can already share settings, you just can't easily synchronize them *if* they change. Whats the problem with doing it? It adds code complexity, plus backwards compatibility would make the code more ugly. Having all project settings stored in the same file is neater and easier to understand for users. It makes the manual more complex, maybe helping a little to obscure the important stuff. Nick, this argument is saying that Geany should never change or improve, if you want to stagnate just keep using 0.21 or your favourite version ... Storing information with different uses (personal vs project) in the same file makes life harder for some users, all your arguments only relate to development issues not user issues. 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. The point of arguing this out isn't especially for this feature, but for considering adding other features too. My points are not just dev issues - users may want to backup their project file, which would be harder. Users need to read the manual, which would take longer to understand. Users might have to use buggier software, as more complex code is always more bug prone. Development issues become user issues indirectly. I could bring up the Eclipse argument to say that worse is better. The more use cases Geany caters to, the more Eclipse-like it will be. If there are going to be restrictions on what changes are made to Geany in the future then you need to put that proposal to the Geany community to consider how such decisions are made. No, and also I'm not maintainer any more. But we do need to consider whether adding features is worth the maintenance and possible disruption. Perhaps I was wrong to bring up Eclipse in this case, but I do think there are issues with your proposal which make it bad - as they're related to my proposal I'll deal with them in the new thread. Regards, Nick ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Proposal: Project settings split - adding geany features
[...] 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. The point of arguing this out isn't especially for this feature, but for considering adding other features too. Yes, its worthwhile discussing, but points like making the code overcomplicated etc need to be discussed in terms of a specifc implementation, as generalities they are meaningless (see below for more rant :). My points are not just dev issues - users may want to backup their project file, which would be harder. I don't understand how it would be harder, but anyway thats a specific. Users need to read the manual, which would take longer to understand. Again this is a specific, but I don't understand how having session info in a session file and project info in a project file is harder to understand, or that most users would even need to care. Users might have to use buggier software, as more complex code is always more bug prone. Development issues become user issues indirectly. Complicated isn't an absolute, it very much depends on experience, something you think is blindingly obvious I may find horrendously complex because I've never thought of that paradigm before. I agree that if the implementer considers it simple it is more likely to be right, but that doesn't guarantee that all maintainers will easily get their heads around it. 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 [...] No, and also I'm not maintainer any more. But we do need to consider whether adding features is worth the maintenance and possible disruption. They should always be considered, I just disagree with you (what, never! :) and what I saw as overly general comments, ie motherhood and apple pie. [...] Cheers Lex ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Proposal: Project settings split - adding geany features
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