[Geany-Devel] Github Comment Mails
Hi, Is it possible to make an archived mailing list which can contain threads of comments posted to Github (maybe using Github API)? We have sometimes when squash commits it deletes Github comments, but I thought maybe we could have some stable backup + URL to link to (ex. in commit messages, on the mailing list, etc) which could be searchable and googlable and not be deleted by rebase. Cheers, Matthew Brush ___ Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
Re: [Geany-Devel] Github Comment Mails
On 15-08-18 08:43 PM, Lex Trotman wrote: On 19 August 2015 at 13:37, Matthew Brush mbr...@codebrainz.ca wrote: Hi, Is it possible to make an archived mailing list which can contain threads of comments posted to Github (maybe using Github API)? We have sometimes when squash commits it deletes Github comments, but I thought maybe we could have some stable backup + URL to link to (ex. in commit messages, on the mailing list, etc) which could be searchable and googlable and not be deleted by rebase. Or by the remote deleting the branch Yeah, it would be archived and not affected by force pushes, delete branches or editing of comments. Cheers, Matthew Brush ___ Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
Re: [Geany-Devel] CDK Plugin
On 15-07-29 08:46 AM, Pavel Roschin wrote: Is GTK3 really unavoidable dependency? I could spend effort trying to make stuff compatible with both GTK2 and 3 but since GTK+ 2 is obsolete and even Geany will be depending on GTK+ 3 by default soon, it seems pointless to write code that is deprecated before it's even complete. At a quick look it doesn't use scintilla's autocompletion window - what is the reason? Currently it uses Scintilla's. Eventually it will probably provide own popup window that has better items, some extra widgetry and performance improvements over Scintilla's. That would be a great feature. Did you also look at CodeIntel? It could improve support for many languages, not only C/C++. I did not. To the best of my knowledge libclang provides the best and most accurate open source library available for IDEs to hook into the C/C++ compiler and in my experience, besides a having a user-unfriendly API (verbose, inconsistent, undocumented, etc), it offers lots of useful features out of the box. Cheers, Matthew Brush ___ Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
Re: [Geany-Devel] CDK Plugin
On 15-07-28 11:10 PM, Thomas Martitz wrote: Am 29. Juli 2015 06:45:34 MESZ, schrieb Matthew Brush mbr...@codebrainz.ca: Hi All, I started working on a plugin that uses features of libclang for C/C++ projects (CDK = C/C++ Development Kit). The code is at: https://github.com/codebrainz/cdk-plugin If anyone is interested to help out in this early stage, especially with the user interface and experience. I have some interesting features working already but the way humans interact with the plugin really sucks. If anyone is a C/GObject/Glade wizard and wants to help develop the human interface to this plugin, please respond here or send me an email directly. Thanks, Matthew Brush ___ Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel Great work and very interesting! Can you give a quick overview of what it adds to geany's c support, whether planned or already integrated? Does it also improve some of geany's existing features? There's an overview in the README.md file with some current and planned features. From what I understood, libclang is superior to any other tag parser, so to me the question is also if we could use it in the core? But I guess other language support would suffer. I think it's too big and language-specific to go into core. IMO a better approach would be to improve the core to facilitate plugins to override/extend Geany's features with language-specific smarts. This would make it easier to write such plugins and would avoid the core havig all kinds of big dependencies like LibPython, LibVala, LibRuby, or what-have-you. Cheers, Matthew Brush ___ Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
Re: [Geany-Devel] pull request on GitHub, to add GeanyHighlightSelectedWords, into Geany Plugins
On 2015-07-08 07:28 PM, Steve wrote: On Jul 8, 2015 7:18 PM, Matthew Brush mbr...@codebrainz.ca wrote: On 2015-07-08 10:57 AM, Steven Blatnick wrote: So I've finally got a chance to look at my non-API calls. I was able to code around most of them, but there are two that would be much easier if we could make them APIs. (I haven't pushed any of these changes to my git repo yet.) Could we consider making these API? * keybindings_load_keyfile - I dynamically add/remove a variable number of plugin keybindings based on the plugin settings, so this allows me to refresh the results easily. This allows my external-tools plugin to have any number of tools with each their own keybinding. Otherwise, most plugins have a set number of bindings. This sounds dubious. I assume you're talking about `external-tools` plugin? Maybe I don't understand the code enough, but it looks to me like it's just leaking GeanyKeyGroups in `reload_tools()` and then calling `keybindings_load_keyfile()` happens to reload the key group it newly created? I completely agree there needs to be a way to dynamically add/remove keybindings, but I'm not sure we should promote this way if I understand it correctly. IMO, it would be much better to fix Geany. I agree. Maybe a reload_plugin type function? I saw a similar problem in gedit plugins, where you have to restart the editor for some things to take effect. And you're right, if i remember correctly, I just want to be able to reload my own shortcuts, and the existing call does them all, which is overkill to say the least. GeanyPy, which also has sub-tools (still called plugins, but in Python scripts) has the same problem. I'll bet GeanyLua and GeanyMiniScript suffer of the same. * keybindings_lookup_item - I know keybindings_get_item is available already, but I am attempting to look up a core group keybinding and not plugin's own keybindings. This sounds reasonable, though I think it would be better if made public to rename it to something like `keybindings_get_builtin_item()` or something. Also I think we should change the signature to use the correct types (those enums we already expose). Alternatively, is there an event i can tie in to? Basically the issue here is in focusing on the side panel or bottom panel, the focus lands in the wrong place to then capture ctrl+pg_up/down to switch notebook tabs. For example, when focusing my panel in external-tools, I need the focus to update to the read-only text field instead of the notebook tab label. I know I can use tab, but I'm trying to make the usage fluid. You could probably dig-out the appropriate widgets from the Glade/GtkBuilder UI and connect to GtkWidget events such as focus-in and such, but I have the feeling the way you're doing it is better, without having actually looked at this part of the code. * keybindings_dialog_show_prefs_scroll - I remember someone saying the Configure Plugins window would have a button to this already in a later version, but I still don't see it. I only need this API if the button isn't added. Could probably make such a button/link use the same code as the Keybindings button in the Plugin Manager dialog, since it does just that. It might be a bit awkward UI-wise though. I'm not sure why that would be awkward? I'm away from the code right now, but I think this call is the same as that button, it just needs to be made an API. I probably would have to see it. I just mean I can't envision a way to add a Keybindings to that Configure Plugin dialog that would be global to all plugin tabs. Cheers, Matthew Brush ___ Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
Re: [Geany-Devel] pull request on GitHub, to add GeanyHighlightSelectedWords, into Geany Plugins
On 2015-07-08 10:57 AM, Steven Blatnick wrote: [snip] Let me know if this is possible or how I should proceed. I use geany with my plugins daily, and can't upgrade my code base until my plugins are working. I forgot to mention, if you made your plugin part of the Geany-Plugins project (I'm assuming it's FOSS, I couldn't find license), usually core Geany developers will test API changes against GP project to see what breaks and you might even find sometimes patches to your plugin waiting in your inbox, to fix this kind of stuff for you :) Cheers, Matthew Brush ___ Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
Re: [Geany-Devel] [RFC]: No force push policy on Github PRs
On 2015-07-08 01:03 PM, Jiří Techet wrote: On Wed, Jul 8, 2015 at 5:47 AM, Matthew Brush mbr...@codebrainz.ca [snip] So personally I wouldn't carve any rules in stone and would decide case to case. For bigger patches with many review comments it's probably best to ask the reviewer which way he prefers to have the fixes committed. Yeah, of course. I didn't mean, despite how the subject might sound, that we could/should _never_ re-write a PR, just that we shouldn't do so casually/by default, and that if rebasing is desired, that it should be held off until the end when whoever's going to merge it is ready and asks the contributor to do it or does it themselves. Cheers, Matthew Brush ___ Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
Re: [Geany-Devel] pull request on GitHub, to add GeanyHighlightSelectedWords, into Geany Plugins
On 2015-07-08 10:57 AM, Steven Blatnick wrote: So I've finally got a chance to look at my non-API calls. I was able to code around most of them, but there are two that would be much easier if we could make them APIs. (I haven't pushed any of these changes to my git repo yet.) Could we consider making these API? * keybindings_load_keyfile - I dynamically add/remove a variable number of plugin keybindings based on the plugin settings, so this allows me to refresh the results easily. This allows my external-tools plugin to have any number of tools with each their own keybinding. Otherwise, most plugins have a set number of bindings. This sounds dubious. I assume you're talking about `external-tools` plugin? Maybe I don't understand the code enough, but it looks to me like it's just leaking GeanyKeyGroups in `reload_tools()` and then calling `keybindings_load_keyfile()` happens to reload the key group it newly created? I completely agree there needs to be a way to dynamically add/remove keybindings, but I'm not sure we should promote this way if I understand it correctly. IMO, it would be much better to fix Geany. * keybindings_lookup_item - I know keybindings_get_item is available already, but I am attempting to look up a core group keybinding and not plugin's own keybindings. This sounds reasonable, though I think it would be better if made public to rename it to something like `keybindings_get_builtin_item()` or something. Also I think we should change the signature to use the correct types (those enums we already expose). * keybindings_dialog_show_prefs_scroll - I remember someone saying the Configure Plugins window would have a button to this already in a later version, but I still don't see it. I only need this API if the button isn't added. Could probably make such a button/link use the same code as the Keybindings button in the Plugin Manager dialog, since it does just that. It might be a bit awkward UI-wise though. Let me know if this is possible or how I should proceed. I use geany with my plugins daily, and can't upgrade my code base until my plugins are working. Best is to make a PR with the changes you want. Second best is to raise an Issue and hope somebody else wants them enough to do it. Cheers, Matthew Brush ___ Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
Re: [Geany-Devel] [RFC]: No force push policy on Github PRs
On 2015-07-06 11:41 PM, Thomas Martitz wrote: Hello, first of all, I think github should fix this problem, instead of enforcing a suboptimal workflow on us. I reported this problem to github, let's see if they respond. I think I reported it before already. IIRC they said something to the effect of ya we know it's a problem, we'll add it to our list of things to think about fixing (paraphrasing). Am 07.07.2015 um 02:13 schrieb Matthew Brush: Hi All, As anyone trying to follow Pull Requests on Github has probably noticed, when you force push to your PR branch, Github deletes various comments related to the PR, depending on what got clobbered (it seems). Not always. I haven't found a consistent pattern, but it seems worse when commits are removed. This makes it extremely difficult to keep track of and finally merge PRs because issues that may have been raised are gone and it leaves holes in the comments which are a useful way to make sure any issues, notes, ideas, etc. have been dealt with before merging. In addition to the dropped comments, it makes it harder to follow the changes made since it clobbers the Git history too, so you have to basically review the entire changset by looking at the whole diff of all files affected by the PR at once. Well, assuming an updated PR only changes stuff which has been commented on before or are otherwise explicitely noted in a new comment, you do not have to review the entire diff again. And you have to review those parts of the diff you commented on again, other parts should be fine since they received no comment at the first review, right? IMO, it's easier to review a small list of commits rather than a mega commit, even if there's a few little nuisance commits in it. In all cases if you merge something you have to review it completely, it's just easier, IMO, when you can kind of follow the comments interspersed with the commits in the order they were added. Also, if something you tested yesterday worked, you know that when the contributor added commits today, it didn't invalidate everything you had previously reviewed/tested, and have to now start all over. Added to that, re-writing the history makes it a PITA for more than one person to contribute changes to a PR at once. IMO, we should be promoting that kind of thing, not making it harder. So it boils down to lost comments are the main problem. Well it's not the only one, but definitively the one that incited this email about changing our (never really discussed IIRC) policy about re-writing history mid-PR. Another reason to avoid is because it makes it harder to test a PR if the repos history keeps getting munged, it breaks your previous pulls. I propose that we disallow force pushing, rebasing, squashing, etc. on any PR until it is fully ready for final merging. We could probably use a label or milestone or something to signify that a PR has been fully reviewed and is ready for merging. At that point it _might_ make sense to fudge history and get rid of some noisy fixup commits[0]. The more fixup commits the less likely that the post-review cleanup is actually going to happen. The largeish linkage-cleanup branch was almost merged as is, and I'm sure bisection of in the middle of those commits is harder or even impossible. IIRC it actually showed the real history of how the changes evolved and I assume each commit was at least moderately tested. I'd have to look closer to see if there were many noisy commits. Thoughts, opinions? I prefer rebasing and rewriting commits, because that makes my life easier too. I can handle my stuff better if it has a clean history, and it helps me in making design decisions because I try to logically separate stuff in the commits. You could still do that locally as you hack away on stuff, it's only the stuff you pushed to your PR branch that people are pulling from where you wouldn't re-write the history from underneath them (and Github). And merging master into my PR when the PR should eventually be merged into master is not acceptable for, therefore I rebase. Why? IMO there's no big deal merging master into your work branch if it's long-lived enough to warrant it. Continuously rewriting history is common in the patch distribution via mailing lists so it's successfully performed elsewhere. It's really just github being bad at maintaining comments and that should be fixed on their side. Mostly, but also it makes certain stuff easier for everyone. One of the hassles of patches is because you have to keep creating branches to apply them on or keep backing the changes out and applying new patches, etc (basically the same thing as when someone force pushes to their PR branch). PS: Lost comments should still be in your mailbox as a last resort, since github sends notifications for each. The problem is it doesn't send you copies of your own messages :( Cheers, Matthew Brush
Re: [Geany-Devel] [RFC]: No force push policy on Github PRs
On 2015-07-07 06:07 AM, Colomban Wendling wrote: Le 07/07/2015 02:13, Matthew Brush a écrit : [snip] In addition to the dropped comments, it makes it harder to follow the changes made since it clobbers the Git history too, so you have to basically review the entire changset by looking at the whole diff of all files affected by the PR at once. Also true. For that part they could provide a diff between the previous and current state, so at least we could see what changed. But well, it's not (yet) the case. It kind of makes sense that `git push +fackyou` does what it says (regardless if you prefer the -f/--fack-you syntax or not), it still says Dear Git, break this sh1t. Another reason to avoid is because it makes it harder to test a PR if the repos history keeps getting munged, it breaks your previous pulls. Well, true but you can also just create versioned local branches -- so you can even diff them. I generally do that with largish stuff, like: user/pr/v1 user/pr/v2 user/pr/v3 etc. Of course it requires manual intervention, but it's not very hard. It's a good workaround to be sure, but still a workaround. I propose that we disallow force pushing, rebasing, squashing, etc. on any PR until it is fully ready for final merging. […] ready for merging. At that point it _might_ make sense to fudge history and get rid of some noisy fixup commits[0]. Agreed, this should be the default behavior. We should at least try and see how life gets easier. Thomas, since you're one of the most frequent contributors, are you OK if we try this? I think you often rebase when you think it's expected and to just get the damn changes finally merged ... so if we lower the expectation, will it hamper your Geany-Fu a lot? Thoughts, opinions? Everyone else? (Silence = don't care) If it sounds like a good idea, I could probably try and update any relevant documentation (HACKING comes to mind) to make a note of this[1]. Cheers, Matthew Brush [0]: I personally don't think it's a big deal leaving the history to match real life, but I can see how Fix some typo type of commits aren't very useful to keep around. Well, IMO it doesn't make sense to keep endless fixup commits in the final marge. Not only it clobbers history, but it also makes it a lot harder to bisect. Yeah, I can understand this point. The main advantage I see is that when a PR is merged, it has the same set of commits that were proven (via our ad-hoc testing and review procedures) to be OK, as opposed to insert undefined stuff that happened during fixing of merge/rebase conflicts and adjustments of history. Of course, this applies to *fixups*, not incremental development. If changes were made incrementally in the PR it probably makes sense (or may not, depending on the case) to keep the incremental history too. I think we all agree here, just a bit differing on the spectrum of incremental vs oh shyte, oops! commits (both being expected in a PR, naturally). Cheers, Matthew Brush ___ Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
[Geany-Devel] [RFC]: No force push policy on Github PRs
Hi All, As anyone trying to follow Pull Requests on Github has probably noticed, when you force push to your PR branch, Github deletes various comments related to the PR, depending on what got clobbered (it seems). This makes it extremely difficult to keep track of and finally merge PRs because issues that may have been raised are gone and it leaves holes in the comments which are a useful way to make sure any issues, notes, ideas, etc. have been dealt with before merging. In addition to the dropped comments, it makes it harder to follow the changes made since it clobbers the Git history too, so you have to basically review the entire changset by looking at the whole diff of all files affected by the PR at once. Another reason to avoid is because it makes it harder to test a PR if the repos history keeps getting munged, it breaks your previous pulls. I propose that we disallow force pushing, rebasing, squashing, etc. on any PR until it is fully ready for final merging. We could probably use a label or milestone or something to signify that a PR has been fully reviewed and is ready for merging. At that point it _might_ make sense to fudge history and get rid of some noisy fixup commits[0]. Thoughts, opinions? If it sounds like a good idea, I could probably try and update any relevant documentation (HACKING comes to mind) to make a note of this[1]. Cheers, Matthew Brush [0]: I personally don't think it's a big deal leaving the history to match real life, but I can see how Fix some typo type of commits aren't very useful to keep around. [1]: Although force pushing is generally considered bad-practice on public branches, so I doubt too many people would do it without being asked. ___ Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
Re: [Geany-Devel] Windows installer snapshots with GTK 2.24
On 2015-07-02 01:36 PM, Enrico Tröger wrote: On 02/07/15 01:17, Matthew Brush wrote: On 2015-07-01 02:45 PM, Matthew Brush wrote: On 2015-07-01 12:33 PM, Enrico Tröger wrote: On 27/06/15 20:53, Thomas Martitz wrote: Am 27.06.2015 um 01:09 schrieb Enrico Tröger: Hi, I've built new Windows installers from current GIT master. Downloads can be found here: http://download.geany.org/snapshots/ Please note that these are test builds from the current development version, don't expect release quality. You have been warned :). After you installed the snapshots, you can also use the nightly builds again on Windows (i.e. copy the archive contents over the installation). Any feedback is welcome. Nice! I'll try to spin GTK3-based installers soon. Though it needs tiny patches to Geany (PR will follow). Thomas, could you do me a favor and check against which libraries your geany.dll is linked? Basically performing a 'ldd' on Windows. Attached is a short command session to dump object information from the DLL and then grep for DLL Name which lists linked libraries. This is somewhat similar to 'ldd' on Linux. You probably need to adjust the paths to the 'objdump' tool and the geany.dll (objdump.exe should be part of the Mingw installation and reside next to gcc.exe). Background: Frank made me aware that on a clean Windows system, the provided installer won't start because it requires libwinpthread-1.dll which is not distributed by the installer but is part of the Mingw environment. I never noticed this because on my Windows system, the Mingw installation is in $PATH and so this library is always available. I'm curious whether this happens also with your Mingw setup. I guess it will as it seems this is a change in newer gcc versions on Windows. But I want to get sure instead of just guessing :). Right now, I'm playing with static linking options, already tried -static -lpthread but so far without success. If it is just a requirement, we can probably distribute this library as well but if we can avoid it, even better. For cross-compiling it's sometimes useful to add `-static-libstdc++` and `-static-libgcc` compiler/linker options, if not already there. Maybe they would compile that library into Geany.exe statically along with the std stuff. Those are already used (https://github.com/geany/geany/blob/master/wscript#L271). Another alternative might be `-static -lwinpthread-1` with or without the `-1`. Thanks. I already tried static -lpthread and now also your variants but all without success :(. The geany.dll on my system is always linked against libwinpthread-1.dll, even after updating my Mingw environment. I'll keep testing and trying... I remember having this problem before, though I forget how I solved it :( This looks kind of promising: http://stackoverflow.com/a/28001271 Cheers, Matthew Brush ___ Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
Re: [Geany-Devel] Windows installer snapshots with GTK 2.24
On 2015-07-01 12:33 PM, Enrico Tröger wrote: On 27/06/15 20:53, Thomas Martitz wrote: Am 27.06.2015 um 01:09 schrieb Enrico Tröger: Hi, I've built new Windows installers from current GIT master. Downloads can be found here: http://download.geany.org/snapshots/ Please note that these are test builds from the current development version, don't expect release quality. You have been warned :). After you installed the snapshots, you can also use the nightly builds again on Windows (i.e. copy the archive contents over the installation). Any feedback is welcome. Nice! I'll try to spin GTK3-based installers soon. Though it needs tiny patches to Geany (PR will follow). Thomas, could you do me a favor and check against which libraries your geany.dll is linked? Basically performing a 'ldd' on Windows. Attached is a short command session to dump object information from the DLL and then grep for DLL Name which lists linked libraries. This is somewhat similar to 'ldd' on Linux. You probably need to adjust the paths to the 'objdump' tool and the geany.dll (objdump.exe should be part of the Mingw installation and reside next to gcc.exe). Background: Frank made me aware that on a clean Windows system, the provided installer won't start because it requires libwinpthread-1.dll which is not distributed by the installer but is part of the Mingw environment. I never noticed this because on my Windows system, the Mingw installation is in $PATH and so this library is always available. I'm curious whether this happens also with your Mingw setup. I guess it will as it seems this is a change in newer gcc versions on Windows. But I want to get sure instead of just guessing :). Right now, I'm playing with static linking options, already tried -static -lpthread but so far without success. If it is just a requirement, we can probably distribute this library as well but if we can avoid it, even better. For cross-compiling it's sometimes useful to add `-static-libstdc++` and `-static-libgcc` compiler/linker options, if not already there. Maybe they would compile that library into Geany.exe statically along with the std stuff. Cheers, Matthew Brush ___ Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
Re: [Geany-Devel] Windows installer snapshots with GTK 2.24
On 2015-07-01 02:45 PM, Matthew Brush wrote: On 2015-07-01 12:33 PM, Enrico Tröger wrote: On 27/06/15 20:53, Thomas Martitz wrote: Am 27.06.2015 um 01:09 schrieb Enrico Tröger: Hi, I've built new Windows installers from current GIT master. Downloads can be found here: http://download.geany.org/snapshots/ Please note that these are test builds from the current development version, don't expect release quality. You have been warned :). After you installed the snapshots, you can also use the nightly builds again on Windows (i.e. copy the archive contents over the installation). Any feedback is welcome. Nice! I'll try to spin GTK3-based installers soon. Though it needs tiny patches to Geany (PR will follow). Thomas, could you do me a favor and check against which libraries your geany.dll is linked? Basically performing a 'ldd' on Windows. Attached is a short command session to dump object information from the DLL and then grep for DLL Name which lists linked libraries. This is somewhat similar to 'ldd' on Linux. You probably need to adjust the paths to the 'objdump' tool and the geany.dll (objdump.exe should be part of the Mingw installation and reside next to gcc.exe). Background: Frank made me aware that on a clean Windows system, the provided installer won't start because it requires libwinpthread-1.dll which is not distributed by the installer but is part of the Mingw environment. I never noticed this because on my Windows system, the Mingw installation is in $PATH and so this library is always available. I'm curious whether this happens also with your Mingw setup. I guess it will as it seems this is a change in newer gcc versions on Windows. But I want to get sure instead of just guessing :). Right now, I'm playing with static linking options, already tried -static -lpthread but so far without success. If it is just a requirement, we can probably distribute this library as well but if we can avoid it, even better. For cross-compiling it's sometimes useful to add `-static-libstdc++` and `-static-libgcc` compiler/linker options, if not already there. Maybe they would compile that library into Geany.exe statically along with the std stuff. Another alternative might be `-static -lwinpthread-1` with or without the `-1`. Cheers, Matthew Brush ___ Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
Re: [Geany-Devel] f403e7e (PR#188) - Maintain edit history on document reload
On 2015-06-29 02:24 AM, Lex Trotman wrote: On 29 June 2015 at 18:24, Thomas Martitz ku...@rockbox.org wrote: Am 29.06.2015 um 00:32 schrieb Lex Trotman: On 29 June 2015 at 07:41, Colomban Wendling lists@herbesfolles.org wrote: Le 26/06/2015 07:22, Thomas Martitz a écrit : […] However, as we entered string freeze, I don't suppose a new dialog like this is acceptable at this point? It would be really better not to indeed? What else can we do for *this* release? Hum. If this is an important enough issue, I can see these solutions: - Default to not keep history (hence prompt); - Add an extra hidden setting don't show this message again-like for a *future* dialog/infobar, so it still always asks unless the user manually changes this hidden setting. Both are suboptimal for this feature, but if it's a problem we can probably delay default enabling to the next cycle. Or just put a BIG notice in the release notes Reload is now undoable so it doesn't prompt any more That helps only existing users, and only that fraction that actually reads release notes (I would think the bulk of them doesn't). Well, yes, thats true, but it is something that can be done anyway, since it has no impact on code or strings or anything else :) Perhaps it would be indeed best to not toggle the default for this release already? PS: I do love this feature now that I'm aware of the undo'ability, it's not like I want to act against it. I just fear it creates user confusion for both new and existing users alike. Certainly it gave you a fright, and its admirable that you try to save others from it, but personally I think you are too worried. Not only it gave him fright, it lost him work because the change in behaviour is not common/obvious and lacks the visual queues needed to make one realize what has happened. Cheers, Matthew Brush ___ Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
Re: [Geany-Devel] Spawn module API
On 2015-06-27 12:46 PM, Dimitar Zhekov wrote: [...] An updated list of the API-s asked to remain public: meWIF* lexspawn_get_program_name lexspawn_check_command me/lexspawn_kill_process spawn_async_with_pipes lexspawn_async me/lexspawn_with_callbacks mespawn_write_data lex?spawn_get_exit_status_cb lexspawn_sync We should only export what you have concrete plans to use during the next cycle. If Lex wants update plugins during the next cycle to use other parts of the API, we can expose them at the time that the PR is made. No point to speculatively expose API that nobody has immediate plans to use. Cheers, Matthew Brush ___ Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
Re: [Geany-Devel] Student looking for professional experience
On 2015-06-26 02:01 PM, Minh Bui wrote: Hello, my name is Minh and I'm currently a sophomore in college, looking for open source project to strengthen my coding skill. I know Java and C and have a little exposure to C++. I have previously used Geany a lot for doing my school assignments and recently I stumbled across the development section. I'm still very new in contributing to a large scale project like this. I look forward to work along with the team. Welcome! Feel free to ask on this list if you have any questions. Cheers, Matthew Brush ___ Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
Re: [Geany-Devel] Spawn module API
On 2015-06-20 08:12 PM, Matthew Brush wrote: Hi All, I just noticed that the new spawn code exposes almost every single bit of API possible. Do we really want to do that, or should we limit it only to what is currently needed by any plugins? A quick survey of Geany-Plugins shows no usage of any of this yet. IMO, we shouldn't expose anything which is not needed by plugins, especially if it's not related to the plugin API. One further thought before we get locked into the exposed API. Shouldn't all the spawn stuff be in the utils_* namespace? From the plugin developer perspective it's just some more utility functions like the ones it improves upon already in the utils_ namespace and that seems to be the place where we dump all the general purpose convenience functions and stuff that makes up for GLib short-comings, and that's effectively what this is. If we wanted to keep the file-wise isolation of the spawn code, we could just tweak the Doxygen comments a bit to put the functions under that section of the API docs, rather than giving a handful of helper functions their own whole module (API-wise, ex. namespace and docs). Any opinions? Cheers, Matthew Brush ___ Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
Re: [Geany-Devel] f403e7e (PR#188) - Maintain edit history on document reload
On 2015-06-24 09:30 AM, Colomban Wendling wrote: Le 24/06/2015 17:04, Thomas Martitz a écrit : Hello I have just noticed that current git, by default, doesn't prompt anymore when reloading documents, even when they are changed. I traced it back to the $SUBJECT commit. IMO it's fine to keep the undo history on reload and not prompt, but it's not fine if the file is currently modified (unsaved) and reloading throws all unsaved changes away, without warning. This is especially problematic because the new pref is on by default so users will probably be surprised by the new, changed behavior and lose some hours of work (happend to me...). How does it loose work? you can undo the reload and you get your stuff back, don't you? It's not super obvious you can undo because it seems like the document's dirty state is cleared, so the tab label isn't red, etc. I didn't realize this feature, even though I vaguely remember when it was committed. It seems fine, but I wouldn't have realized I could just undo. I usually associate file-related actions to clearing the undo buffer, but it might just be what I'm used to. I'm asking for restoring the prompt (by default), at the very least if the file is unsaved. Would be fine with me, as I don't think reload is something done so often that a confirmation would be much pain. We could restore the previous confirmation behavior. I reload a lot :) I think the only weird behaviour besides the clearing the dirty state, is that if you are editing a file, then edit it externally, then come back to Geany, it rightly warns you using a nice document message, giving the choice to reload, overwrite or do nothing. If you press the toolbar reload button, it dismisses the document infobar. That's not in itself necessarily a bad thing, because you're basically saying yes, i want to reload, go away. However, if you clicked the toolbar save button instead of reload, it asks Yet Again, this time with a modal dialog, what the document infobar is already asking, to save/overwrite the file. It's kind of subtle but seems a bit inconsistent, IMO. Cheers, Matthew Brush ___ Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
Re: [Geany-Devel] f403e7e (PR#188) - Maintain edit history on document reload
On 2015-06-24 05:47 PM, Lex Trotman wrote: [...] I wonder if there's a more simple way to reduce confusion and increase visibility other than an annoying dialog or document message. Maybe as a separate action with a different name in the edit menu? Menu, what menu? I use the toolbar button. Changing the name won't help here. Then maybe just having it keep the tab label red and asterisk in the window title is enough. I think those would've been enough of a clue for me to figure out I could undo. Cheers, Matthew Brush ___ Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
Re: [Geany-Devel] Spawn module API
On 2015-06-23 09:04 AM, Dimitar Zhekov wrote: On 23.6.2015 г. 02:25, Matthew Brush wrote: [...] One thing I forgot: the plugin API currently exports utils_spawn_[a]sync, and a few plugins use utils_spawn_sync. These functions were (partially correct) wrappers around the old glib/win32 spawn, and are now wrappers around spawn_[a]sync. Someday, in the distant future, they should be obsoleted... +1 I get what you're saying but I also feel uneasy about blanket exporting of APIs with no current users of it, so we don't know exactly what really needs to be exported. Well, with nothing from spawn exported, we can be pretty sure that all plugins _will_ be using utils_spawn and g_spawn instead. :) I think the general policy is to export stuff on demand as plugins need it. Seeing as you wrote the API in question, I'm assuming you know best the stuff you will need, so I don't personally see much problem preemptively exposing that stuff[0]. From you're previous email you mentioned the stuff checked with [x] below: [ ] spawn_get_program_name() [ ] spawn_check_command() [x] spawn_kill_process() [ ] spawn_async_with_pipes() [ ] spawn_async() [x] spawn_with_callbacks() [x] spawn_write_data() [ ] spawn_get_exit_status() [ ] spawn_sync() [x] SpawnFlags [x] SpawnReadFunc [x] SpawnWriteData Is that sufficient, or is there other stuff? I will remove the /** from anything that is not expected to be needed, if nobody objects. About the WIF* macros, those (at present) are not officially part of the plugin API as they have no Doxygen comments, though they will still be visible to plugins since they're macros and bypass the linker trick we use to hide functions. I think it would be best to add documentation to those (and possible define them into the GEANY_ 'namespace'?), at the very least to ensure nobody accidentally moves or hides them. Just the other day I tried to move them into spawn.c thinking they were there on accident, but then I left them because another .c file uses them so they need to be in a (not necessarily public) header. We should make Colomban decide :) The leading developers should decide - including you. Well you know my opinion :) I think everyone pretty much agrees we shouldn't expose stuff unrelated to the plugin API, and I think we all also agree it's stupid for plugins to have to copypaste code that exists already or else use an inferior version. I also think everyone agrees that a separate utility library would be a good idea. The problem I have is that once this API makes it into the next release, it's forever stuck inside Geany and we'll have to keep it indefinitely, regardless if something possibly better[1] like GProcess comes available to us, and we don't even use it internally anymore. Cheers, Matthew Brush [0]: At least until we establish a policy around what belongs in the plugin API or not. [1]: I have no idea if it's better, just an example. ___ Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
Re: [Geany-Devel] Spawn module API
On 2015-06-23 01:40 PM, Lex Trotman wrote: On 24 June 2015 at 02:04, Dimitar Zhekov dimitar.zhe...@gmail.com wrote: On 23.6.2015 г. 02:25, Matthew Brush wrote: [...] One thing I forgot: the plugin API currently exports utils_spawn_[a]sync, and a few plugins use utils_spawn_sync. These functions were (partially correct) wrappers around the old glib/win32 spawn, and are now wrappers around spawn_[a]sync. Someday, in the distant future, they should be obsoleted... I get what you're saying but I also feel uneasy about blanket exporting of APIs with no current users of it, so we don't know exactly what really needs to be exported. In a previous post Dimitar has listed the API he requests for his plugin, so that (at least) should be made available in 1.25. It is spurious to make him and therefore any potential windows users wait for another release cycle. He listed some of the API that is exposed. There's nothing spurious about being cautious about mass-exporting API that nobody even asks for, IMO. Well, with nothing from spawn exported, we can be pretty sure that all plugins _will_ be using utils_spawn and g_spawn instead. :) Yes, the argument that nothing uses it is also spurious given the API only just came into existence. Nobody made any argument that nobody uses, I just mentioned that nobody is using it YET (since they could've, as it's all exported for plugins ATM in Git master), so we could therefore unexpose it without causing anybody grief. There's nothing spurious going on here. Cheers, Matthew Brush ___ Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
Re: [Geany-Devel] Spawn module API
On 2015-06-20 08:12 PM, Matthew Brush wrote: Hi All, I just noticed that the new spawn code exposes almost every single bit of API possible. Do we really want to do that, or should we limit it only to what is currently needed by any plugins? A quick survey of Geany-Plugins shows no usage of any of this yet. IMO, we shouldn't expose anything which is not needed by plugins, especially if it's not related to the plugin API. See: https://github.com/geany/geany/pull/523 Cheers, Matthew Brush ___ Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
[Geany-Devel] Spawn module API
Hi All, I just noticed that the new spawn code exposes almost every single bit of API possible. Do we really want to do that, or should we limit it only to what is currently needed by any plugins? A quick survey of Geany-Plugins shows no usage of any of this yet. IMO, we shouldn't expose anything which is not needed by plugins, especially if it's not related to the plugin API. Cheers, Matthew Brush ___ Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
Re: [Geany-Devel] pull request on GitHub, to add GeanyHighlightSelectedWords, into Geany Plugins
On 2015-05-27 05:25 AM, marius buzea wrote: Hello, I would like to add GeanyHighlightSelectedWords, to Geany Plugins. [snip] See https://github.com/geany/geany/pull/513 Cheers, Matthew Brush ___ Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
Re: [Geany-Devel] Autotools and Waf options (Was: Re: Msys2 to compile on win32)
On 2015-06-06 05:57 AM, Colomban Wendling wrote: Le 06/06/2015 13:07, Dimitar Zhekov a écrit : […] I'm using waf under Linux as well, since it keeps the source tree clean, You can do the same with Autotools, though it admittedly doesn't enforce it. Just run configure from the directory you want the build files in, e.g: $ mkdir _build $ cd _build $ ../configure [options] That's only partially true, at least when using a Git clone. autogen.sh script puts quite a few files in the source directory, and then make will put even more, if building any of the Vala plugin. It is true for the release tarball though, if you don't mind using Vala compiler of the person making the tarball. Cheers, Matthew Brush ___ Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
Re: [Geany-Devel] Open Source Work At Geany
On 2015-05-31 05:23 PM, Atal Akbari wrote: Hi, my name Is Atal Akbari, I am a 3rd year Computer Science student at Ryerson University, currently looking for open source work in order to test my developing skills at a professional level. I choose Geany as my first open source project because I have previously used Geany and came across the development section while surfing through the website. In addition to this the C/C++ programming language is my strong suit and I am very interested in strengthening my C/C++ skill set. Thank you for the opportunity looking forward to working with the team! , Atal Akbari Welcome! If you have any questions concerning the code - which, for what it's worth, isn't C/C++, it's just plain olde C :) - or to discuss something you'd like to work on, feel free to send message on this mailing list or go on the #geany IRC channel on FreeNode, where some of the Geany community and developers hang out. Cheers, Matthew Brush ___ Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
Re: [Geany-Devel] pull request on GitHub, to add GeanyHighlightSelectedWords, into Geany Plugins
On 2015-05-29 02:03 PM, Jiří Techet wrote: On Fri, May 29, 2015 at 1:25 AM, Matthew Brush mbr...@codebrainz.ca wrote: Ideally you could improve the underlying implementation of an existing one if your way is better[0] and they perform the same function. It's really confusing for users to figure out what is the right plugin when there's too many doing the same thing. The same thing happens with GeanyGDB, Debugger, and Scope right now. That being said, showing occurrences of the word is such a common and fairly useful feature for an IDE, I'd personally rather see the 3-4 existing plugins obsoleted by a good implementation in core Geany[1]. Cheers, Matthew Brush +1 on having it directly in Geany. And IMO, the simplest possible implementation should be used - i.e. using just strstr() for finding the names and highlighting the whole editor and not just the visible part and redoing this when scrolling. KMP is quite an overkill in this case - it would be useful only if 1. The text to locate would be long (which isn't the case because function/variable names are quite short) 2. The searched text would contain many prefixes from the text to locate (again not the case - variables/functions can have common prefix but typically there will be at most one per line and not like every second character). Most of the time strstr() will find different characters at the first position and advance to the next character. If you consider what we are doing when the document changes - i.e. parsing the document twice, once by scintilla lexer, once by ctags parser - and this happens on the main thread and nobody notices it, then the search part in the highlighting will be almost for free. I might try and improve this feature this weekend if I get some time. One thing I think would make it much better would be if it was based on semantics (ex. the variable i would only be highlighted in the current loop, since that's where it is scoped), but I think that's not really possible at present. I was thinking something like this for implementation: - Have a preference to enable the feature (since it would now be automatic). Have the preference turned off by default. Put the preference in Preferences-Editor-Display as a checkbox called Highlight current word or similar. Or would it be better under Preferences-Editor-Features? - Use a different indicator number than the current Mark All feature, so it won't clash with the one used for the Search dialog and can have different styling. - Remove the Mark All keybinding. Also make these new indicator types not cleared by the Document-Remove Markers menu item. - Upon Scintilla notification of position changed, check if there's a current word at the cursor. - If not, clear the indicators used for this feature (but not the Mark All ones activated from the Search Dialog). - If there is a current word but it's the same as last time, do nothing. - If there is a current word and it's different from the last one, clear the indicators and then have Scintilla close its gap buffer by getting the character pointer to it. - Use strstr() starting at the character pointer to the buffer start, comparing the bytes with the bytes of the current word, working its way through the whole document. - For each non-NULL return of strstr(), set an indicator at position `foundPtr - docStartPtr` with the indicator length as the number of bytes in the current word, and then use strstr() again starting at `foundPtr + currentWordLength`, repeat to end. Does that sound fairly reasonable? The only thing I'm not 100% sure about is handling of multi-byte characters in the UTF-8 of the wordchars or the buffer, but it seems like it should just work since it's just comparing raw bytes, and at worst, setting a indicator position in Scintilla that is between two bytes of the same multi-byte char (but not moving the caret there, so no weird editing bugs). Cheers, Matthew Brush ___ Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
Re: [Geany-Devel] pull request on GitHub, to add GeanyHighlightSelectedWords, into Geany Plugins
On 2015-05-29 04:45 PM, Matthew Brush wrote: [snip] I was thinking something like this for implementation: [snip] - Upon Scintilla notification of position changed, check if there's a current word at the cursor. Question: Is it important to make it mark the selection if there is one, otherwise the current word? I've never seen or used that in other editors where I've seen this feature (though I don't doubt it exists) but I think it was mentioned in another message in this thread (and is how the current manual Mark All feature works, apparently). Cheers, Matthew Brush ___ Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
Re: [Geany-Devel] [geany/geany] f03206: Windows: Compile geany_private.rc into Geany.exe for version data and icon
On 15-04-18 03:51 AM, Enrico Tröger wrote: On 18/04/15 11:47, Enrico Tröger wrote: On 17/04/15 21:32, Colomban Wendling wrote: Le 12/04/2015 22:54, Enrico Tröger a écrit : Branch: refs/heads/master Author: Enrico Tröger enrico.troe...@uvena.de Committer: Enrico Tröger enrico.troe...@uvena.de Date:Sun, 12 Apr 2015 20:54:16 UTC Commit: f03206744361baac1c811db97f5d2816409d7787 https://github.com/geany/geany/commit/f03206744361baac1c811db97f5d2816409d7787 Log Message: --- Windows: Compile geany_private.rc into Geany.exe for version data and icon Should we integrate geany_private.rc in the library too? This isn't done with Autotools, but could be added. It's not really necessary. For Waf, I just added it to the binary where it is necessary and kept it for the library. The rc file serves two main purposes: - add the icon to the binary - add versioning information to the binary (e.g. in the file properties dialog in the Details tab) While especially the icon is important for the binary, I guess the rc file is just nice to have for the library but not necessary. But I agree we should do the same for Waf and autotools, either link it or don't link it. I don't mind which way to go. After thinking a bit more about this, I think we should not link the rc file against the library. We also don't link it against the plugin libraries. The rc file contains settings that the resulting binary is an executable and it includes also the geany.exe.manifest. Both do not apply to the library. So it is actually wrong to use that rc file for the library. If there are no objections, I will remove linking the rc file against the library in Waf. None here. I think the way it might make sense is if it contained artwork, UIs, translations and stuff like they often do for Win32 API projects, and that were actually used in libgeany.dll, but since we just use it for the .exe icon, meta-info, styles, etc. I tend to agree it makes more sense linked to the .exe. We might still want an .rc file for the library though, if it's important to show the correct meta-info in Windows explorer for the .dll file (I dunno if it is?). Cheers, Matthew Brush ___ Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
Re: [Geany-Devel] [geany/geany-plugins] 73ae49: waf: Fix the checks for openpty() on FreeBSD
On 15-04-16 02:20 PM, Colomban Wendling wrote: Le 16/04/2015 23:14, Thomas Martitz a écrit : Am 16.04.2015 um 21:47 schrieb Enrico Tröger: On 16/04/15 18:47, Dimitar Zhekov wrote: On 16.4.2015 г. 12:37, Thomas Martitz wrote: Am 15.04.2015 um 19:15 schrieb Dimitar Zhekov: […] In my splitwindow2 patches I underline the text label in active tab. So that the user can tell which of the 2 notebooks is active currently (the tabs alone don't show that). Would that be a worthy fix to your problem? Yes. The ability to have the current tab underlined, italic or bold seems like a good thing to have, irrespective of my problems with 2.24 + Win~1. It probably should be done programmatically? I sort of like the idea. And would agree that it might be not just useful on Windows. Thomas, can this be done in code so it could be enabled/disabled by a setting? Sure, but why would you disable it? Because it's damn ugly :) (and serves absolutely no purpose -- for me) +1, and it's also something that should be controlled by user/system themes, not the app, IMO. Is a pref necessary? Yes. +1. If people really want it, I'd appreciate to be able to disable it. And at least with my splitwindow2 patch set something like this is needed to determine the focused document (each notebook can have an active doc, but only one of them can be focused at any time). Only if the splitwindow is actually used. And even, underlying the tab might not be the best visual indicator ever, though I can't suggest something easy that would actually work (I'd think a better one would be some kind of slightly deactivated editor, but while doable it's a bit annoying with Scintilla). Or maybe just a special border around the focused scintilla or nothing at all (except the correct window title, and blinking cursor). Cheers, Matthew Brush ___ Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
Re: [Geany-Devel] [geany/geany-plugins] 73ae49: waf: Fix the checks for openpty() on FreeBSD
On 15-04-15 10:15 AM, Dimitar Zhekov wrote: On 14.4.2015 г. 22:37, Enrico Tröger wrote: On 13/04/15 19:33, Dimitar Zhekov wrote: In 2.24, the horizontal tabs under Win~1 have this flat or modern or whatever look, and you can only distinguish the current tab via a slight 3D effect. And unlike 3.x, where you can easily set the active tab I don't get it. For me it looks like as in the attached screenshot. I don't have a GTK 2.16 build at hand for a direct comparison but the notebook tabs look OK to me in the GTK 2.24 build. That's exactly what I'm talking about. The white horizontal line, which normally gives nice outline [vertical_tabs], but is almost lost due to the white editor background, combined with the identical unchangeable background for the tabs. Not completely indistinguishable, but much worse than 2.22, and hard on many tabs. We could re-parent the Scintilla widget into a frame (or whichever is the proper widget) and set its border shadow to in or etched in, which would probably look more appropriate on Windows[0][1][2], and likely still look fine on most non-Windows themes. Alternatively, we could probably tweak the default windows theme (engine) to make it look more native. Cheers, Matthew Brush [0]: http://www.testech-elect.com/ontime/vstudio.gif [1]: http://cache.filehippo.com/img/ex/626__notepad1.png [2]: http://scitedebug.luaforge.net/scite-debug.png ___ Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
Re: [Geany-Devel] [geany/geany-plugins] 73ae49: waf: Fix the checks for openpty() on FreeBSD
On 15-04-12 10:20 AM, Dimitar Zhekov wrote: [snip] While on configuring, the README file still lists gtk+ 2.16 as a minimum requirement for Geany - but it's actually 2.18 with GtkInfoBar now, right? I can cut an entire module (gtk216.[ch]) from Scope if 2.18 is the minimum required version... I just merged PR #245[0], so 2.24 should be good version to use. Cheers, Matthew Brush [0]: https://github.com/geany/geany/pull/245 ___ Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
Re: [Geany-Devel] New plugin loader mechanisms
On 15-03-25 04:22 PM, Thomas Martitz wrote: Am 18.03.2015 um 22:55 schrieb Matthew Brush: On 15-03-18 09:42 AM, Thomas Martitz wrote: tl;dr - Key functions gboolean geany_load_module(GeanyPlugin *, GModule *) What is the GModule* for? Is it a .dll that Geany opened on behalf of the plugin based on selection in Plugin Manager? That's the function exported by native (C/C++) plugins that want to register as plugins with Geany. With my proposal that's the only function of a plugin that Geany gets through g_module_open(). Since this only applies to native shared libraries, the corresponding GModule is passed. This function is similar to libpeas' peas_register_types(). Is it where resident plugins should register their GTypes similar to Peas? The main reason I asked about it is because it seems to have the same call time, argument and similar return semantics as the existing GModule hook `g_module_check_init()`. I get that it passes the plugin struct too, and has a more useful name, mostly I was just curious about when to use which one. What is the expected use of the GModule parameter? I'm curious if it's useful at all, or just exposing the loader's externals, and maybe whether if it's only for special use-case, that it might be better to just use `g_module_open(NULL)` in those place(s). Cheers, Matthew Brush ___ Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
Re: [Geany-Devel] New plugin loader mechanisms
On 15-03-25 04:22 PM, Thomas Martitz wrote:
Am 18.03.2015 um 22:55 schrieb Matthew Brush:
[snip]
```
static Plugin my_plugin = {
.name= Foo,
.version = 0.1,
.author = Me,
.description = Foo plugin,
.api_min = 200,
.abi_ver = GEANY_ABI_VERSION,
.init= my_plugin_init,
.configure = my_plugin_configure,
.help= my_plugin_help,
.deinit = my_plugin_cleanup,
};
[sniip]
Thanks for your suggestion to make the plugin_set_info() obsolete and
move filing the info fields before geany_plugin_register(). I will
incoperate that into my v2 of my proposal.
If you squint your eyes just right, it looks like you could re-write the
PLUGIN_SET_INFO() in a way to be source-compatible (but obviously not
binary-compatible) with the old way, since nobody used plugin_set_info()
directly, and the hook functions you moved/proposed only add an argument
(which Geany could read, or not, based on the ABI version).
Just a passing thought.
Cheers,
Matthew Brush
___
Devel mailing list
Devel@lists.geany.org
https://lists.geany.org/cgi-bin/mailman/listinfo/devel
Re: [Geany-Devel] debug output on win32
On 15-03-22 04:30 PM, the Adib wrote: Hello all, I have installed a buildenvironment on my Win32 virtualbox. I want to investigate in the source code and have some debug output from the running application. I tried printf as well as geany_debug. I also set G_MESSAGES_DEBUG=all. However starting the application from the commandshell cmd: - returns immediatel to the promt, without waiting the application to close, - does not output any debug hint on the console. Could you guide me how to have some informative output from the running application. Since you did not say so, I have to ask, did you run it with verbose messages like `geany -v`? Cheers, Matthew Brush ___ Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
Re: [Geany-Devel] New plugin loader mechanisms
On 15-03-18 03:05 PM, Thomas Martitz wrote: Am 18.03.2015 um 22:15 schrieb Matthew Brush: [...] void (*init) (GeanyPlugin *plugin, gpointer pdata); Please make this gboolean. A plugin may have the correct API and ABI, but be unable to startup / initialize for some reason. For example, Scope requires scope.glade in the plugin data directory). +1, I've always wanted a way to signal Geany don't bother, it's just going to crash you if you keep going. The only way I can see to handle critical failures without a status return from there is to keep a global variable and guard each function so it can't execute its normal code, which is a bit of a pain and weird for users if the plugin loads but doesn't do anything. Another useful thing might be to provide a way to return a reason message as well, then when Geany gets the failure return it can open an error dialog and show the user a message that the plugin couldn't be loaded, and show the reason string and maybe some bug-reporting info or something. Thinking about it, if the plugin can't run because it's missing resource files required for its operation, then I think it should be treaded like incompatible plugins. This has the benefit that they will be attempted to be loaded on the next startup if the user had previously selected it. For resource files like say a GtkBuilder UI file, I'd agree, but there may be some other cases, for example if a plugin dynamically loaded some particular library (or variant of a library) based on user configuration, it'd be useful to report to the user that the library is wrong, or no longer available, or whatever. Incompatible plugins simply return false in geany_load_module() [I've implemented a safety guard geany_load_modules() even though the abi/api version check failed]. The plugin can also print the reason to stdout/msgwin/error dialog from within that function, although IMO a dialog is too intrusive. I generally hate dialogs, but I think a plugin failing to load is a fine use for one since it doesn't happen with high frequency, and just dumping g_critical() or equivalent on the console is useless/confusing if the user hasn't launched from a terminal (and doesn't realize about Help-Debug Messages). I'm thinking if the plugin loaded successfully, then it should be operational too. Meaning that init() should not fail, but simply activate the plugin. As outlined above, my proposal already covers the case compatible but not operational due to missing runtime dependencies you described. For cases like GeanyPy which loads arbitrary Python scripts (which are even fully executed on import), and in a language where Exceptions are common (especially during development), it would probably be useful to signal that the plugin script couldn't be loaded and maybe even be able to provide a formatted traceback of the Python exception or such. Cheers, Matthew Brush ___ Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
Re: [Geany-Devel] New plugin loader mechanisms
On 15-03-18 03:55 PM, Thomas Martitz wrote: Am 18.03.2015 um 23:21 schrieb Matthew Brush: On 15-03-18 03:05 PM, Thomas Martitz wrote: Am 18.03.2015 um 22:15 schrieb Matthew Brush: [...] void (*init) (GeanyPlugin *plugin, gpointer pdata); Please make this gboolean. A plugin may have the correct API and ABI, but be unable to startup / initialize for some reason. For example, Scope requires scope.glade in the plugin data directory). Thinking about it, if the plugin can't run because it's missing resource files required for its operation, then I think it should be treaded like incompatible plugins. This has the benefit that they will be attempted to be loaded on the next startup if the user had previously selected it. For resource files like say a GtkBuilder UI file, I'd agree, but there may be some other cases, for example if a plugin dynamically loaded some particular library (or variant of a library) based on user configuration, it'd be useful to report to the user that the library is wrong, or no longer available, or whatever. Based on user configuration implies that it's a decision that is made after the plugin's init(). If it allows the user to configure it without this dependency then the plugin is considered operational, and init() should not fail. Remember that a init() == FALSE would imply that the plugin cannot be activated, and therefore not configured (i.e. you cannot configure back so that it doesn't need the missing dependency). Such custom requirements errors are better placed in the plugin code itself. I'm thinking if the plugin loaded successfully, then it should be operational too. Meaning that init() should not fail, but simply activate the plugin. As outlined above, my proposal already covers the case compatible but not operational due to missing runtime dependencies you described. For cases like GeanyPy which loads arbitrary Python scripts (which are even fully executed on import), and in a language where Exceptions are common (especially during development), it would probably be useful to signal that the plugin script couldn't be loaded and maybe even be able to provide a formatted traceback of the Python exception or such. In my roadmap geanypy does not load scripts in its init(), but through a separate API (so that the scripts integrate into the main plugin manager). Anyway, geanypy init() isn't the right place because geanypy can load multiple scripts, and which scripts can change afterwards after init has run. And finally, all those scripts do not change the fact that geanypy itself is operational, and this is what we're talking about. I think I misunderstood the purpose of your `init()` function. I thought it was a hook to allow the plugin manager/geany to be able to initialize multiple plugins from the same .dll/module (ex. sub-plugins, etc). If that's not the case, isn't the `init()` pointer in the struct basically redundant as plugins could do their initialization in the roughly equivalent `geany_load_module()` that is also called once per .dll? For that matter, why not just leave the hooks all as loose functions (as opposed to set into a structure), and just fix the prototypes to pass around GeanyPlugin* and/or user_data, or whatever improvements? AFAIK there's no issue with symbols/collisions if Geany just uses RTLD_LOCAL when dlopen-ing the plugin module. Cheers, Matthew Brush ___ Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
Re: [Geany-Devel] New plugin loader mechanisms
bool (*deinit) (Plugin*); // could signal unloading problem
}
Plugin;
```
Then the register function could be like:
```
bool plugin_register (GeanyPlugin *module, // geany's plugin context
Plugin *plugin); // real/sub-plugin ctx
```
Inside a normal plugin it could do:
```
static Plugin my_plugin = {
.name= Foo,
.version = 0.1,
.author = Me,
.description = Foo plugin,
.api_min = 200,
.abi_ver = GEANY_ABI_VERSION,
.init= my_plugin_init,
.configure = my_plugin_configure,
.help= my_plugin_help,
.deinit = my_plugin_cleanup,
};
G_MODULE_EXPORT
bool plugin_load_module (GeanyPlugin *module_plugin)
{
return plugin_register (module_plugin, my_plugin);
}
```
Or for a proxying-type plugin (ex. GeanyPy/GeanyLua):
```
G_MODULE_EXPORT
bool plugin_load_module (GeanyPlugin *module_plugin)
{
Plugin *plug = g_new0 (Plugin, 1);
*plug = my_plugin;
plug-name = Joe's plugin;
plug-version = etc...
plug-plugin_data = PyObject_New(...); // or lua_new() or whatever
return plugin_register (module_plugin, plug);
}
```
Just some ideas based on yours and mine previous work around this.
There's many ways to skin this cat :)
Cheers,
Matthew Brush
___
Devel mailing list
Devel@lists.geany.org
https://lists.geany.org/cgi-bin/mailman/listinfo/devel
Re: [Geany-Devel] New plugin loader mechanisms
On 15-03-18 01:23 PM, Dimitar Zhekov wrote:
On 18.3.2015 г. 18:42, Thomas Martitz wrote:
- Global symbols. Plugins binaries have to export a number of global
symbols (geany_{functions,data,plugin}, plugin_{init,...,cleanup}). This
kind of sucks, because they pollute the global namespace (in theory).
Luckily on unix or win32 systems this is not a problem because they can
restrict the symbol visibility of shared libraries. It's still bad
practice. Ideally plugins should have zero global symbols, everything
being static or hidden to the plugin binary.
Scope contains 20 source files and 22 headers. Using static is not an
option, and marking everything global as hidden will be cumbersome,
ugly, and easy to miss (inexperienced plugin developers are sure to miss
symbols).
Why does it need so many globals? Shouldn't the only globals really be
the stuff Geany requires? I'm wondering because one day it would be cool
to able to do stuff like having multiple instances in-process and to
allow a plugin per in-process instance or some stuff like this. With
the additional userdata pointer, in theory one could make a big huge
structure containing all their global (instance) state and have that
passed around, and then there's less issue with symbols and multiple
instances and such.
(I get that it's _not_ like that for Scope, but in theory it could've
been and for new plugins it could be recommended).
[...]
void (*init) (GeanyPlugin *plugin, gpointer pdata);
Please make this gboolean. A plugin may have the correct API and ABI,
but be unable to startup / initialize for some reason. For example,
Scope requires scope.glade in the plugin data directory).
+1, I've always wanted a way to signal Geany don't bother, it's just
going to crash you if you keep going. The only way I can see to handle
critical failures without a status return from there is to keep a global
variable and guard each function so it can't execute its normal code,
which is a bit of a pain and weird for users if the plugin loads but
doesn't do anything.
Another useful thing might be to provide a way to return a reason
message as well, then when Geany gets the failure return it can open an
error dialog and show the user a message that the plugin couldn't be
loaded, and show the reason string and maybe some bug-reporting info or
something.
Cheers,
Matthew Brush
___
Devel mailing list
Devel@lists.geany.org
https://lists.geany.org/cgi-bin/mailman/listinfo/devel
Re: [Geany-Devel] Wish for Wishlist and bug in Homepage
On 13-11-12 12:26 AM, theUser BL wrote: I want to say, that it would be nice, if a DocumentMap/MiniMap would be added to Geany. Please add it to the Wishlist on your side. I wrote a plugin lately to do this, it lives here for now: https://github.com/codebrainz/overview-plugin Cheers, Matthew Brush ___ Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
Re: [Geany-Devel] using Coverity to audit the code base
On 15-03-07 12:59 PM, Liviu Andronic wrote: On Thu, Feb 26, 2015 at 7:18 PM, Colomban Wendling lists@herbesfolles.org wrote: Hey, Le 12/02/2015 22:21, Liviu Andronic a écrit : Dear all, Recently I've discovered Coverity, a code checking tool, and went ahead and submitted the Geany code for static analysis by this service: https://scan.coverity.com/projects/1388 Quoting Coverity's Scan User Agreement: You will not publish any findings regarding or resulting from use of the Service or the Software; IANAL, but this looks like we couldn't discuss an issue it found on e.g. this mailing list. And your report about what it did find in Geany's code is already a violation of that agreement. More, just for the fun: “Confidential Information” means: […] (d) any results of operation from use of the Software or the Service; Without limiting the generality of the foregoing, You agree that You will not post […] the results of the Service […] on any network that is accessible by anyone. And this is the Scan User Agreement, I couldn't even find the Scan Terms of Use (at least not without trying to actually register myself). So… really? Regards, Colomban PS: Of course one will tell me that in practice they won't come after us for discussing a fix, but if it really is against the UA I'd rather not try and see what happens. I haven't gotten any reply to my request for clarification. But I've also discussed this issue with LyX devels. The opinion there is that it's common sense to simply ignore the overly restrictive aspects of Coverity's User Agreement. It's highly unlikely that they'll come chasing for discussing a bug on the ML, and if they do, this shall be incredibly negative PR for them given all the efforts that they make to attract the open-source community. Given that very big projects use Coverity regularly, like LibreOffice or the Linux Kernel, perhaps it's not worth stressing too much about this. Of course Geany maintainers are free to choose their stance on this issue. And if you're unhappy with the current situation, I could as well try to ask them to remove Geany from their service. Another way would be, for instance, to set up a dedicated, private ML (e.g. geany-dev-coverity) to which only members with access to Coverity can post/read. This should avoid most of the nagging related to their UA. Hi, It's unclear what advantage Coverity has over just running Clang Static Analyzer and their various sanitizers. Is it just for the web UI or something? Cheers, Matthew Brush ___ Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
Re: [Geany-Devel] suggestion: Renaming GProject to ProjectTree
On 14-12-11 12:32 PM, Jiří Techet wrote: Hi, I've just pushed quite a few changes to my GProject plugin (unfortunately in a single commit because I was making these changes while working on the tag manager and it was too painful to rebase multiple commits every time I changed the Geany API). If there are some problems, please let me know. Before announcing the changes on the users mailing list, there's one more change I'd like to make - make the plugin name a little more descriptive so it's easier to find by users who are looking for a plugin which displays a file tree in the sidebar. For this reason I'd like to rename the plugin to ProjectTree. Please let me know if you have a better idea for the plugin name or if you think renaming the plugin isn't a good idea. ProjectTree only covers one part of the plugin. What about FilteredFileListAndAutoTagger? Or something like that, but shorter :) P.S. I found a bug in GProject where it keeps adding more and more tabs to the project dialog. If the GitHub Issues gets turned on for Geany-Plugins I'll open a bug report, if it's not fixed yet. Cheers, Matthew Brush ___ Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
Re: [Geany-Devel] Linkage-Cleanup Build System Breakage
On 14-10-26 04:16 PM, Enrico Tröger wrote: On 26/10/14 18:25, Matthew Brush wrote: On 14-10-26 07:14 AM, Enrico Tröger wrote: [snip] If the Win32 Nightlies break it will most likely be trivial changes to the Makefile.ams. I don't have an environment like it uses to test. The Win32 nightlies are built using Waf, so fixing Waf will fix it all :). I thought the nightlies were using Mingw because there's all those duplicate code paths in the Makefile.ams for Mingw. Who uses those? We added those years ago to support cross-compilation. IIRC this was before Waf. Yeah, we really should consolidate the available build systems and clean up the rest :). I don't use autotools based cross-compilation. I had a try at this for a while and after a number of changes it's almost working. I got past the build system, compiler, and linker problems, but now it's giving grief because of the non-standard (with respect to Autotools) directory layout and the special cases we have about using a data directory instead of putting in share/geany. Is there any possibility we could use the same Unixey directory layout for Win32 builds too? My dream is in some distant future to have the Autotools build system able to build natively and cross-compiled and adding rules needed to make the Windows installer and everything. This would also be great for continuous integration and/or nightly builds in the future too, as we would mostly have the exact same build system with the same compiler/linker options and only minor differences to satisfy the differences between platforms. Just think of how much easier it would be if at release time all you had to do was: make dist-win32 And just upload the resulting installer .exe[0] :) Cheers, Matthew Brush [0]: Which would be the exact same installer .exe everyone's been testing with from the CI/nightlies all along. ___ Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
Re: [Geany-Devel] Linkage-Cleanup Build System Breakage
On 14-10-26 07:14 AM, Enrico Tröger wrote: Hi, I don't really know enough about Waf to fix it. Since it needs Python anyway, we could just use one of its XML libraries to grab the names from the GtkBuilder file, and do the replacements using its text-handling functions. It wouldn't require sed/sort utils. I originally had a Python script[3] doing this, but I'm just not sure how to integrate that code into Waf. I' work on the Waf part but this will take at least two weeks as I'm almost not on the PC during the next two weeks. OK. If the Win32 Nightlies break it will most likely be trivial changes to the Makefile.ams. I don't have an environment like it uses to test. The Win32 nightlies are built using Waf, so fixing Waf will fix it all :). I thought the nightlies were using Mingw because there's all those duplicate code paths in the Makefile.ams for Mingw. Who uses those? Geany-Plugins Autotools should be fine since it will pickup the new I checked out codebrainz/wip/linkage-cleanup but got build errors with autotools: ---snip- tm_source_file.c:31:60: fatal error: ../src/pluginexport.h: No such file or directory #include ../src/pluginexport.h /* for GEANY_API_SYMBOL */ ^ compilation terminated. Makefile:490: recipe for target 'tm_source_file.lo' failed ---snap- src/pluginexport.h seems missing? Oops, I had this file ignored locally for some reason. I squashed it into the correct commit and force pushed it. It should be OK now. Cheers, Matthew Brush ___ Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
Re: [Geany-Devel] Linkage-Cleanup Build System Breakage
On 14-10-26 04:16 PM, Enrico Tröger wrote: On 26/10/14 18:25, Matthew Brush wrote: On 14-10-26 07:14 AM, Enrico Tröger wrote: Hi, I don't really know enough about Waf to fix it. Since it needs Python anyway, we could just use one of its XML libraries to grab the names from the GtkBuilder file, and do the replacements using its text-handling functions. It wouldn't require sed/sort utils. I originally had a Python script[3] doing this, but I'm just not sure how to integrate that code into Waf. I' work on the Waf part but this will take at least two weeks as I'm almost not on the PC during the next two weeks. OK. I got a very basic working version, see attachment. However, I almost didn't test it and things like library versioning are missing. In Autotools libtool versions is not used yet anyway. It's just set to 0:0:0 same as the defaults. I just added that for future use. As said, the rest will take some time. OK. If the Win32 Nightlies break it will most likely be trivial changes to the Makefile.ams. I don't have an environment like it uses to test. The Win32 nightlies are built using Waf, so fixing Waf will fix it all :). I thought the nightlies were using Mingw because there's all those duplicate code paths in the Makefile.ams for Mingw. Who uses those? We added those years ago to support cross-compilation. IIRC this was before Waf. Yeah, we really should consolidate the available build systems and clean up the rest :). I don't use autotools based cross-compilation. This is good news. I have done work on Win32/MSYS Autotools but I didn't want to break this special path which is same/similar I needed. Some day I will push some changes to consolidate both branches in Makefile.ams and having a working Win32/MSYS Autotools :) Cheers, Matthew Brush ___ Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
[Geany-Devel] Linkage-Cleanup Build System Breakage
Hi All, and especially build system maintainers :) I have made a pull request[0] to cleanup the symbol exports of Geany. The PR description pretty much covers the details. If I merge this, it's going to break the makefile.win32 files, Waf and possibly the Win32 Nightly builds. I can probably fix-up the makefile.win32 files if nobody else will as it's just plain GNU make and should be similar changes as the Autotools. It will require a couple more *nix utilities, namely `sed`, `sort`, and `uniq` (or a `sort` that supports the `-u` option). A quick search finds sed[1] and coreutils[2] which contains `sort` (probably with -u option) and `uniq`. I assume MSYS also includes these common utils. I don't really know enough about Waf to fix it. Since it needs Python anyway, we could just use one of its XML libraries to grab the names from the GtkBuilder file, and do the replacements using its text-handling functions. It wouldn't require sed/sort utils. I originally had a Python script[3] doing this, but I'm just not sure how to integrate that code into Waf. If the Win32 Nightlies break it will most likely be trivial changes to the Makefile.ams. I don't have an environment like it uses to test. Geany-Plugins Autotools should be fine since it will pickup the new library from the pkg-config flags. There's a couple bugs in some (of my) plugins where it misses the needed linker flags which are trivial to fix. I don't know if Waf uses pkg-config or what, but if not, it will need to add the equivalent of something like `-L/geanys/lib/dir -lgeany` to be able to find and link to the new library. Is everyone OK if this PR was merged to master and we had to fix up some build system stuff? Alternatively, I could also add anyone for push rights on my geany fork or push it to a branch on main geany repo if we wanted to sort-out the integration issues before merging to the main master branch. Cheers, Matthew Brush [0]: https://github.com/geany/geany/pull/358 [1]: http://gnuwin32.sourceforge.net/packages/sed.htm [2]: http://gnuwin32.sourceforge.net/packages/coreutils.htm [3]: https://raw.githubusercontent.com/codebrainz/geany/74d21da4570c777a4a112b7438a6608e0caf6c40/scripts/signalconn ___ Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
[Geany-Devel] Infobar file deleted/renamed behaviour
Hi All, Since there's some discussion about infobar behaviour, I thought I'd mention a couple things I've noticed using it in my day-to-day workflow. When you delete a file from disk, and then assuming the infobar kicked in (see below), it pops up the infobar as expected. The problem is that there's no quick way to say Ya, ya, I deleted that on purpose, just close the file. IMO, there should be a Close button on the infobar that allows you to bypass the redundant dialog that pops up when trying to close a document that you've been notified about, for example: - File foo.txt was not found on disk[Resave][Dismiss][Close] Some different message here - Clicking the proposed [Close] button would have the same effect as what currently requires two steps; clicking the tab close button or Close menu item and then clicking the Don't Save button in the dialog that pops up. Does that sound reasonable? The other thing I wondered is, should we not do a disk check on a file that hasn't been switched to when it's being closed? I mean we do the check and show the infobar on tab-switch (due to lacking proper/usable inotify support), but if the user doesn't actually switch to the tab, then we just close the file without any warning that the buffer in that document has no disk file anymore and closing it will lose those contents forever. Thoughts? Cheers, Matthew Brush ___ Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
Re: [Geany-Devel] Infobar file deleted/renamed behaviour
On 14-10-22 06:53 PM, Lex Trotman wrote: On 23 October 2014 11:53, Matthew Brush mbr...@codebrainz.ca wrote: Hi All, Since there's some discussion about infobar behaviour, I thought I'd mention a couple things I've noticed using it in my day-to-day workflow. When you delete a file from disk, and then assuming the infobar kicked in (see below), it pops up the infobar as expected. The problem is that there's no quick way to say Ya, ya, I deleted that on purpose, just close the file. IMO, there should be a Close button on the infobar that allows you to bypass the redundant dialog that pops up when trying to close a document that you've been notified about, for example: - File foo.txt was not found on disk[Resave][Dismiss][Close] Some different message here - Clicking the proposed [Close] button would have the same effect as what currently requires two steps; clicking the tab close button or Close menu item and then clicking the Don't Save button in the dialog that pops up. Does that sound reasonable? Yes, would just ask for some space between dismiss and close for those with bad aim (like me :) BTW which is default (if any)? The other thing I wondered is, should we not do a disk check on a file that hasn't been switched to when it's being closed? I mean we do the check and show the infobar on tab-switch (due to lacking proper/usable inotify support), but if the user doesn't actually switch to the tab, then we just close the file without any warning that the buffer in that document has no disk file anymore and closing it will lose those contents forever. Sounds like a sensible safe default behaviour, but with a various pref to turn it off for those whose workflow makes it *really* annoying. And/or a way to dismiss many together for bulk operations like Close All and Close Others (and obviously when exiting). Sometimes you see those dialogs like: ++ |- Unsaved Changes! -X-| ++ | The following files are not saved: | | == | | [ ] Resignation_Letter.txt | | [ ] Wedding_Vows_WIP.md | | [ ] Baby_Pictures.xpm| | [ ] ... | | == | | Do you want to save them? | | -- | | [ No, Just Exit] [ Yes Please ] [ Cancel ] | ++ We could do something like that. Cheers, Matthew Brush ___ Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
Re: [Geany-Devel] Windows GTK Runtime 2.24 and config directory
On 14-09-30 06:40 AM, Enrico Tröger wrote: Hey, Attached is the trivial diff of my changes to your confdir.c. So, if my modifications work also on your Windows XP, I'd say go ahead and commit your changes and I will start to build the installer. Will test soon, but just looking they should be fine. *little-ping* Or, if you are busy but agree, I could commit the changes myself. If you don't mind to commit them yourself, that would go faster :) Cheers, Matthew Brush ___ Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
Re: [Geany-Devel] Switched to Win~1
On 14-09-23 09:23 AM, Dimitar Zhekov wrote: On 22.9.2014 г. 14:12, Nick Treleaven wrote: Now, Geany under Win~1 has some deficiencies, due to gtk+, so I'll Such as? Compared to a regular programmers editor for Win~1: +++ It's an IDE, not simply an editor, and is still light. ++ I have experience with it. + Nice plugins. + Real code page convertor, not Interpret as code page foo only. - Non-native interface. Pretty much a norm these days, and can be fixed to some extend. It's worse with GTK3 too, it only makes any attempt to look native when you have themes activated in Windows, so if you are using the classic Windows theme, it falls back to the builtin GTK+ theme, which looks nothing like anything on any desktop. - With gtk+2, randomly starts to eat several % of CPU time. Not a real problem, except for laptops. With gtk+ 3.8, see Geany with gtk+ 3.6.4 under Windows. - Does not work with all monospaced TrueType fonts. Maybe same issue as this, for me it also cuts off the last pixel or two (horizontally) of each character. Still usable like that but fonts look weird and it's distracting. - Find in Files for locale texts is broken (passing locale file names to tools is almost surely broken too, but the locale file names support in glib is terrible anyway). [1] It's not usable out-of-the box either, unless someone happens to have grep utility in their %PATH%. Cheers, Matthew Brush ___ Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
Re: [Geany-Devel] SourceFarce
On 14-09-22 04:44 AM, Nick Treleaven wrote: On 01/09/2014 03:27, Matthew Brush wrote: I deleted my Source Forge account after like 20 times of losing my comments. This final time it was a detailed C++ explanation on Scintilla's bug tracker that took a lot of thought and effort to write, which as usual I lost I've not used it much, but last week I experienced this. Submitting a comment when I'm apparently logged-in then made me login again, where I am greeted by the same page without my comment. Hitting back failed to allow me to recover my 'unsubmitted' comment (that sometimes works on other sites). Perhaps there's some kind of login timeout, but either way the situation sucks. That's exactly it. I think it must be an issue between SourceForge's user/login system and the (somehow independent-ish) Allura software we're (trying) to use for our bug tracker. I asked on #allura freenode channel a few times with no response, and of course to submit a bug report requires to use SourceForge :) Cheers, Matthew Brush ___ Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
Re: [Geany-Devel] Switched to Win~1
On 14-09-22 08:48 AM, Steven Blatnick wrote: Responses below: On 09/22/2014 09:23 AM, Dimitar Zhekov wrote: After 15 years of using Linux desktop, 3 of which as maintainer of a source-based distribution? :) I'm glad (if you want to call it that) to hear that it sounds like only a recent trend to abandon the users. I hope they figure things out, because it's been a painful few years because of the recent trends. I'm surprised at how much grief some of these projects have caused to linux users as a whole, but it's like they are ignoring their constituents. Linux. I fight for the users ;-) (tron reference) But you are right that systemd is not the only reason. KDE 4, GNOME 3, FF[1], the list goes on, and recently even gtk+ 2.24.23+ (IIRC the revision) is slightly broken. Guess I finally lost faith in the Linux as desktop. I hope, for all of you, that Xfce 5 will be just fine. I'm also happy to hear someone reiterate my disgruntlement with GNOME 3. One small glimmer of hope is that Ubuntu Mate https://ubuntu-mate.org/ is emerging to fill that nostalgic gap. Unfortunately, I don't know if they are doing anything with systemd, as it will still be based on Ubuntu, but at least I get my sane interfaces back without having to switch to Xfce :-/ They are even packaging compiz, which much of linux practically abandoning it has been another sore spot for me, although that could be blamed on GNOME 3 partly as well for going to Mutter. Now if only I could convince them to package Emerald window decorator. I miss 2007 linux ;-) I especially like these points in Ubuntu Mate's mission: * *Restore the halcyon days of Ubuntu* before Unity https://unity.ubuntu.com/ (I would add GNOME 3 here) was introduced. * Provide a *refuge* for Linux users who prefer a traditional desktop metaphor. It's weird you (and others) seem to dismiss XFCE while citing this as a goal. I've been using Xubuntu for nearly as long as I've been using Linux and it's been a great distro+DE configuration; familiar, painless, configurable, minimal, few bugs, each distro upgrade goes super smooth, and otherwise the whole thing stays out of the way. P.S. I have my fingers crossed Ubuntu will shield me from this systemd brouhaha I keep hearing about :) Cheers, Matthew Brush ___ Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
Re: [Geany-Devel] Switched to Win~1
On 14-09-22 08:23 AM, Dimitar Zhekov wrote: On 22.9.2014 г. 08:46, Thomas Martitz wrote: [snip] Seriously, I can understand that systemd is controversial, but not to the extend to abandon *Unix* altogether. There are many many ways to avoid systemd without going Windows, for example using a distro that doesn't use systemd (Gentoo, Slackware, etc) or one of the BSDs. I could not care less for being controversial - it's *broken* for me. If I'm going to distro-hop, why not Windows? A working desktop, if nothing else. In no particular order, off the top of my head... - Sandboxing - Windows Store - .NET - Boxes - Inaccessible source code - Blue screens - Terrible console and CLI tools - Malware, spamware, bloatware, viruses - Windows Updates, Genuine Advantage, phone home, etc. - Price and the Microsoft Tax - Inferior development tools - Terrible platform APIs (Win32 API, DDK, COM, etc) - Inferior performance - Broken and annoying security model - No special files (pty,lo,etc) - No unified file system hierarchy - No package management - Little to no POSIX or other standards support - etc... That being said, if you cram enough FOSS onto Windows it can be made nearly usable, and also Linux usually runs great in a virtual machine :) Cheers, Matthew Brush ___ Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
Re: [Geany-Devel] Windows GTK Runtime 2.24 and config directory
On 14-08-31 08:49 AM, Frank Lanitz wrote: Am 24.08.2014 um 21:08 schrieb Matthew Brush: On 14-08-24 08:42 AM, Frank Lanitz wrote: Am 24.08.2014 um 17:24 schrieb Matthew Brush: And looking at the code, could never work as is, but the main point is using our own wrapper function to get user config dir, it would need to be written properly :) And having in mind they will add some more magic with later versions of Windows I'm sure this is a bad idea. What magic in what versions? And what's different if the Win32 API call is in GLib vs Geany? I was referring to the layout changes in past and wanted to they, that I'm there will be some changes with further versions. Maybe wasn't very clear about that ;) Using the Win32 API ensures that whenever the layouts change it won't break as Windows will redirect them to the correct location or the Win32 API will internally deal with it. Using GLib functions won't give that level of compatibility (see $subject). Cheers, Matthew Brush ___ Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
Re: [Geany-Devel] Windows GTK Runtime 2.24 and config directory
On 14-08-31 07:38 AM, Enrico Tröger wrote: On 30/08/14 03:04, Matthew Brush wrote: On 14-08-29 07:24 AM, Enrico Tröger wrote: [snip] I'd implement this way first, based on your patch, and if we want, we can change to .../Local later anyway if desired. I think it's probably the easiest solution, with the least code, and most compatibility. If you don't feel like coding it yourself, let me know and I can whip up a (real/working) function to do it. I've been doing a fair bit of Win32 API coding lately so it's fresh on my mind, I I don't mind, if you like to do it, I'd be happy to test the result :). Attached is a function that works standalone, it could drop into the previous patch where the untested/working function was. I have only tested on WinXP. If you don't feel like putting it together manually, I can eventually commit it all together properly once I figure out my build system issues. Tested on Windows 7: I had to change the function to its multibyte variant: SHGetFolderPathAndSubDirW That's the wide character variant, the ASCII one is the A function. You should be able to just use the non-char-specific one as long as we're telling the Win32 API we're using the wide API (I assumed we were since I saw other code in win32.c using wide characters). You need to #define UNICODE or _UNICODE (I always forget) before including windows.h to make it work normally/automagically. Attached is the header I always use to wrap up the Win32 API include/defining weirdness that seems to just work with Unicode without any fuss. Otherwise it spat out compiler warnings and the resulting config directory was: 㩃啜敳獲敜牮捩屯灁䑰瑡屡潒浡湩屧g旄 :). Additionally, I had to add the flag CSIDL_FLAG_CREATE so that the ...\Roaming\geany folder is created initially if it doesn't exist yet. Without that flag, SHGetFolderPathAndSubDirW() would fail if the folder doesn't exist. That should be fine I would think. I just assumed other Geany code dealt with creating it. Alternatively we could maybe use the flag CSIDL_FLAG_DONT_VERIFY since we create the folder in Geany at a later point anyway. Though I didn't test this flag because I guess it's better if Windows creates this special folder. Not sure, I suppose it's fine either way. Attached is the trivial diff of my changes to your confdir.c. So, if my modifications work also on your Windows XP, I'd say go ahead and commit your changes and I will start to build the installer. Will test soon, but just looking they should be fine. Cheers, Matthew Brush #ifndef __WIN32API_H__ #define __WIN32API_H__ #undef UNICODE #undef _UNICODE #undef VC_EXTRALEAN #undef WIN32_LEAN_AND_MEAN #undef _WIN32_WINNT #define UNICODE 1 #define _UNICODE 1 #define VC_EXTRALEAN 1 #define WIN32_LEAN_AND_MEAN 1 #define _WIN32_WINNT 0x0501 #include windows.h #include commctrl.h #include shellapi.h #include wchar.h #endif // __WIN32API_H__ ___ Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
[Geany-Devel] SourceFarce
Hi, Just wanted to let everyone know, I deleted my Source Forge account after like 20 times of losing my comments. This final time it was a detailed C++ explanation on Scintilla's bug tracker that took a lot of thought and effort to write, which as usual I lost due to forgetting how crappy Source Forge login and bug tracking software is. I'm sure nobody really cares, but if there's some Geany bug/feature/patch posted there that anyone thinks I should look at, you'll have to forward me the details. I won't ever use SF.net again (actually blocked whole domain in my /etc/hosts), and won't be contributing anything to any project's bug trackers there. In the meantime, Geany's Github bug tracker is active since a while (though not for Geany-Plugins), so I'll be sure to continue monitoring and contributing to that tracker, and of course the mailing lists. Cheers, Matthew Brush ___ Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
Re: [Geany-Devel] Windows GTK Runtime 2.24 and config directory
On 14-08-29 04:19 PM, Matthew Brush wrote: On 14-08-29 07:24 AM, Enrico Tröger wrote: On 28/08/14 01:49, Matthew Brush wrote: [snip] just can't get Waf working with my new setup because Geany's git tree is not on the C: drive anymore (it's on a mapped/shared drive), which makes Waf choke with errors about no init function (have you ever experienced this error?). Nope. I remember on a prevous Windows VM I had Geany and library includes and libs on a C: drive while the system itself (Windows, Python, ...) was installed on a E: drive. That worked well though both were local drives, nothing mapped. How do you start waf? On my current setup, I added c:\python27 to $PATH, so in the Geany git clone I just type: python waf configure python waf build python waf install and everything works fine. For me, with Python33 in path, it goes like this: X:\python waf configure No function init defined in X:\wscript X: is a geany source directory directory on my host machine shared to guest and mapped to X: I asked about it on Waf's IRC channel and gave some details and it turned out to be a bug in Waf with path joining and Windows drive letters. Fix was pushed within an hour :) https://code.google.com/p/waf/source/detail?r=adb3e907a47db5ac8537b7cf77c032bf4c90cb14name=waf-1.7# Cheers, Matthew Brush ___ Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
Re: [Geany-Devel] Windows GTK Runtime 2.24 and config directory
On 14-08-30 05:04 AM, Enrico Tröger wrote: On 30/08/14 06:47, Matthew Brush wrote: On 14-08-29 07:24 AM, Enrico Tröger wrote: On 28/08/14 01:49, Matthew Brush wrote: On 14-08-27 10:54 AM, Enrico Tröger wrote: Am 24.08.2014 um 17:18 schrieb Matthew Brush: On 14-08-22 11:23 AM, Enrico Tröger wrote: Hi, lately, I started building a new Windows installer which includes a recent GTK 2.24 runtime for Windows which need for future releases. While most things went fine I noticed one problem: GTK, in detail Glib, changed the way g_get_user_data_dir() works on Windows: in older releases, something GLib 2.28 or 2.26 and older, g_get_user_data_dir() returned c:\users\username\AppData\Roaming, in newer GLib versions it returns c:\users\username\AppData\Local. This affects users who already have a config directory located in ...\Roaming and Geany would look in ...\Local now. This is the change I'm talking about: https://git.gnome.org/browse/glib/commit/glib/gutils.c?id=9d80c361418f94c609840ec9f83741aede7e482c How do we want to handle this? - continue using the ...\Roaming directory (and so not using g_get_user_data_dir() anymore) If we went this route we could use something like the attached patch[0]. Maybe it's what the linked commit is referring to about proper Windows programs probably not using those GLib functions? - leave the code as it is, resulting in a new complete config for users - add some code to check if a config in ...\Roaming exists and if so, move it to ...\Local I was thinking about it a bit and it might be good to keep using the Roaming one (ie. whatever Win32 API gives as correct dir) since IIUC it allows users on a domain to sync their config between machines on login/logout. As mentioned in the linked commit, the function we use (g_get_user_config_dir()) only changed to match g_get_user_data_dir(), not because it's the actually a better or more appropriate directory. Hmm, ok. We could do it this way either. I have no clue about this roaming stuff, just thought it might be good to follow GLib to be consistent with config dir location. But I don't mind much. I'd implement this way first, based on your patch, and if we want, we can change to .../Local later anyway if desired. I think it's probably the easiest solution, with the least code, and most compatibility. If you don't feel like coding it yourself, let me know and I can whip up a (real/working) function to do it. I've been doing a fair bit of Win32 API coding lately so it's fresh on my mind, I I don't mind, if you like to do it, I'd be happy to test the result :). just can't get Waf working with my new setup because Geany's git tree is not on the C: drive anymore (it's on a mapped/shared drive), which makes Waf choke with errors about no init function (have you ever experienced this error?). Nope. I remember on a prevous Windows VM I had Geany and library includes and libs on a C: drive while the system itself (Windows, Python, ...) was installed on a E: drive. That worked well though both were local drives, nothing mapped. How do you start waf? On my current setup, I added c:\python27 to $PATH, so in the Geany git clone I just type: python waf configure python waf build python waf install and everything works fine. By trial and error (for lack of Waf documentation), I was able to get it working again. Based on observations alone, it seems that if wscript is in the root directory of a drive (ie. `X:\wscript`), it requires init and shutdown functions to be present in the wscript. All I could find online was some waf source code that provides default implementations for these functions, but for whatever reason that doesn't happen when the wscript is in root dir. See attached patch for what got it going. Should we commit this? I wouldn't, I just wanted to show how I had got it working. IIUC, this is a workaround for the drive letter bug in Waf? And so these two functions are not needed anymore once the mentioned fix in Waf is released? Correct. And yeah, probably better just to stick a new Waf binary (or whatever that file is) in the source tree. I can use my patch locally until then. Cheers, Matthew Brush ___ Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
Re: [Geany-Devel] Windows GTK Runtime 2.24 and config directory
On 14-08-29 07:24 AM, Enrico Tröger wrote: On 28/08/14 01:49, Matthew Brush wrote: On 14-08-27 10:54 AM, Enrico Tröger wrote: Am 24.08.2014 um 17:18 schrieb Matthew Brush: On 14-08-22 11:23 AM, Enrico Tröger wrote: Hi, lately, I started building a new Windows installer which includes a recent GTK 2.24 runtime for Windows which need for future releases. While most things went fine I noticed one problem: GTK, in detail Glib, changed the way g_get_user_data_dir() works on Windows: in older releases, something GLib 2.28 or 2.26 and older, g_get_user_data_dir() returned c:\users\username\AppData\Roaming, in newer GLib versions it returns c:\users\username\AppData\Local. This affects users who already have a config directory located in ...\Roaming and Geany would look in ...\Local now. This is the change I'm talking about: https://git.gnome.org/browse/glib/commit/glib/gutils.c?id=9d80c361418f94c609840ec9f83741aede7e482c How do we want to handle this? - continue using the ...\Roaming directory (and so not using g_get_user_data_dir() anymore) If we went this route we could use something like the attached patch[0]. Maybe it's what the linked commit is referring to about proper Windows programs probably not using those GLib functions? - leave the code as it is, resulting in a new complete config for users - add some code to check if a config in ...\Roaming exists and if so, move it to ...\Local I was thinking about it a bit and it might be good to keep using the Roaming one (ie. whatever Win32 API gives as correct dir) since IIUC it allows users on a domain to sync their config between machines on login/logout. As mentioned in the linked commit, the function we use (g_get_user_config_dir()) only changed to match g_get_user_data_dir(), not because it's the actually a better or more appropriate directory. Hmm, ok. We could do it this way either. I have no clue about this roaming stuff, just thought it might be good to follow GLib to be consistent with config dir location. But I don't mind much. I'd implement this way first, based on your patch, and if we want, we can change to .../Local later anyway if desired. I think it's probably the easiest solution, with the least code, and most compatibility. If you don't feel like coding it yourself, let me know and I can whip up a (real/working) function to do it. I've been doing a fair bit of Win32 API coding lately so it's fresh on my mind, I I don't mind, if you like to do it, I'd be happy to test the result :). I'll try to write it this weekend. just can't get Waf working with my new setup because Geany's git tree is not on the C: drive anymore (it's on a mapped/shared drive), which makes Waf choke with errors about no init function (have you ever experienced this error?). Nope. I remember on a prevous Windows VM I had Geany and library includes and libs on a C: drive while the system itself (Windows, Python, ...) was installed on a E: drive. That worked well though both were local drives, nothing mapped. How do you start waf? On my current setup, I added c:\python27 to $PATH, so in the Geany git clone I just type: python waf configure python waf build python waf install and everything works fine. For me, with Python33 in path, it goes like this: X:\python waf configure No function init defined in X:\wscript X: is a geany source directory directory on my host machine shared to guest and mapped to X: I don't remember if I already mentioned that I started to document the Windows build stuff (as promised months ago :D): https://wiki.geany.org/howtos/win32/build While not yet complete, the basic stuff should be covered. Neat, I'll have a read on it this weekend. BTW, for the 2.24 bump, if you want to update PR# 245[0] as you go, I put some fancy checkboxes to track progress :) Probably I missed some stuff that needs to be done/tested. Thanks, Matthew Brush [0]: https://github.com/geany/geany/pull/245 ___ Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
Re: [Geany-Devel] Windows GTK Runtime 2.24 and config directory
On 14-08-29 07:24 AM, Enrico Tröger wrote:
[snip]
I'd implement this way first, based on your patch, and if we want, we
can change to .../Local later anyway if desired.
I think it's probably the easiest solution, with the least code, and
most compatibility. If you don't feel like coding it yourself, let me
know and I can whip up a (real/working) function to do it. I've been
doing a fair bit of Win32 API coding lately so it's fresh on my mind, I
I don't mind, if you like to do it, I'd be happy to test the result :).
Attached is a function that works standalone, it could drop into the
previous patch where the untested/working function was. I have only
tested on WinXP. If you don't feel like putting it together manually, I
can eventually commit it all together properly once I figure out my
build system issues.
Cheers,
Matthew Brush
gchar *win32_get_user_config_dir(void)
{
HRESULT hr;
wchar_t path[MAX_PATH];
hr = SHGetFolderPathAndSubDir(NULL, CSIDL_APPDATA, NULL, SHGFP_TYPE_CURRENT, Lgeany, path);
if (SUCCEEDED(hr))
{
// GLib always uses UTF-8 for filename encoding on Windows
int u8_size = WideCharToMultiByte(CP_UTF8, 0, path, -1, NULL, 0, NULL, NULL);
if (u8_size 0)
{
gchar *u8_path = g_malloc0(u8_size + 1);
if (u8_path != NULL
WideCharToMultiByte(CP_UTF8, 0, path, -1, u8_path, u8_size, NULL, NULL))
{
return u8_path;
}
}
}
// glib fallback
g_warning(Failed to retrieve Windows config dir, falling back to default);
return g_build_filename(g_get_user_config_dir(), geany, NULL);
}
___
Devel mailing list
Devel@lists.geany.org
https://lists.geany.org/cgi-bin/mailman/listinfo/devel
Re: [Geany-Devel] Windows GTK Runtime 2.24 and config directory
On 14-08-29 07:24 AM, Enrico Tröger wrote: On 28/08/14 01:49, Matthew Brush wrote: On 14-08-27 10:54 AM, Enrico Tröger wrote: Am 24.08.2014 um 17:18 schrieb Matthew Brush: On 14-08-22 11:23 AM, Enrico Tröger wrote: Hi, lately, I started building a new Windows installer which includes a recent GTK 2.24 runtime for Windows which need for future releases. While most things went fine I noticed one problem: GTK, in detail Glib, changed the way g_get_user_data_dir() works on Windows: in older releases, something GLib 2.28 or 2.26 and older, g_get_user_data_dir() returned c:\users\username\AppData\Roaming, in newer GLib versions it returns c:\users\username\AppData\Local. This affects users who already have a config directory located in ...\Roaming and Geany would look in ...\Local now. This is the change I'm talking about: https://git.gnome.org/browse/glib/commit/glib/gutils.c?id=9d80c361418f94c609840ec9f83741aede7e482c How do we want to handle this? - continue using the ...\Roaming directory (and so not using g_get_user_data_dir() anymore) If we went this route we could use something like the attached patch[0]. Maybe it's what the linked commit is referring to about proper Windows programs probably not using those GLib functions? - leave the code as it is, resulting in a new complete config for users - add some code to check if a config in ...\Roaming exists and if so, move it to ...\Local I was thinking about it a bit and it might be good to keep using the Roaming one (ie. whatever Win32 API gives as correct dir) since IIUC it allows users on a domain to sync their config between machines on login/logout. As mentioned in the linked commit, the function we use (g_get_user_config_dir()) only changed to match g_get_user_data_dir(), not because it's the actually a better or more appropriate directory. Hmm, ok. We could do it this way either. I have no clue about this roaming stuff, just thought it might be good to follow GLib to be consistent with config dir location. But I don't mind much. I'd implement this way first, based on your patch, and if we want, we can change to .../Local later anyway if desired. I think it's probably the easiest solution, with the least code, and most compatibility. If you don't feel like coding it yourself, let me know and I can whip up a (real/working) function to do it. I've been doing a fair bit of Win32 API coding lately so it's fresh on my mind, I I don't mind, if you like to do it, I'd be happy to test the result :). just can't get Waf working with my new setup because Geany's git tree is not on the C: drive anymore (it's on a mapped/shared drive), which makes Waf choke with errors about no init function (have you ever experienced this error?). Nope. I remember on a prevous Windows VM I had Geany and library includes and libs on a C: drive while the system itself (Windows, Python, ...) was installed on a E: drive. That worked well though both were local drives, nothing mapped. How do you start waf? On my current setup, I added c:\python27 to $PATH, so in the Geany git clone I just type: python waf configure python waf build python waf install and everything works fine. By trial and error (for lack of Waf documentation), I was able to get it working again. Based on observations alone, it seems that if wscript is in the root directory of a drive (ie. `X:\wscript`), it requires init and shutdown functions to be present in the wscript. All I could find online was some waf source code that provides default implementations for these functions, but for whatever reason that doesn't happen when the wscript is in root dir. See attached patch for what got it going. Cheers, Matthew Brush diff --git a/wscript b/wscript index 22f347f..c214095 100644 --- a/wscript +++ b/wscript @@ -60,6 +60,11 @@ MINIMUM_GLIB_VERSION = '2.20.0' top = '.' out = '_build_' +def init(x): + pass + +def shutdown(x): + pass mio_sources = set(['tagmanager/mio/mio.c']) ___ Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
Re: [Geany-Devel] Windows GTK Runtime 2.24 and config directory
On 14-08-27 10:54 AM, Enrico Tröger wrote: Am 24.08.2014 um 17:18 schrieb Matthew Brush: On 14-08-22 11:23 AM, Enrico Tröger wrote: Hi, lately, I started building a new Windows installer which includes a recent GTK 2.24 runtime for Windows which need for future releases. While most things went fine I noticed one problem: GTK, in detail Glib, changed the way g_get_user_data_dir() works on Windows: in older releases, something GLib 2.28 or 2.26 and older, g_get_user_data_dir() returned c:\users\username\AppData\Roaming, in newer GLib versions it returns c:\users\username\AppData\Local. This affects users who already have a config directory located in ...\Roaming and Geany would look in ...\Local now. This is the change I'm talking about: https://git.gnome.org/browse/glib/commit/glib/gutils.c?id=9d80c361418f94c609840ec9f83741aede7e482c How do we want to handle this? - continue using the ...\Roaming directory (and so not using g_get_user_data_dir() anymore) If we went this route we could use something like the attached patch[0]. Maybe it's what the linked commit is referring to about proper Windows programs probably not using those GLib functions? - leave the code as it is, resulting in a new complete config for users - add some code to check if a config in ...\Roaming exists and if so, move it to ...\Local I was thinking about it a bit and it might be good to keep using the Roaming one (ie. whatever Win32 API gives as correct dir) since IIUC it allows users on a domain to sync their config between machines on login/logout. As mentioned in the linked commit, the function we use (g_get_user_config_dir()) only changed to match g_get_user_data_dir(), not because it's the actually a better or more appropriate directory. Hmm, ok. We could do it this way either. I have no clue about this roaming stuff, just thought it might be good to follow GLib to be consistent with config dir location. But I don't mind much. I'd implement this way first, based on your patch, and if we want, we can change to .../Local later anyway if desired. I think it's probably the easiest solution, with the least code, and most compatibility. If you don't feel like coding it yourself, let me know and I can whip up a (real/working) function to do it. I've been doing a fair bit of Win32 API coding lately so it's fresh on my mind, I just can't get Waf working with my new setup because Geany's git tree is not on the C: drive anymore (it's on a mapped/shared drive), which makes Waf choke with errors about no init function (have you ever experienced this error?). Cheers, Matthew Brush ___ Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
Re: [Geany-Devel] Windows GTK Runtime 2.24 and config directory
On 14-08-22 11:23 AM, Enrico Tröger wrote:
Hi,
lately, I started building a new Windows installer which includes a
recent GTK 2.24 runtime for Windows which need for future releases.
While most things went fine I noticed one problem:
GTK, in detail Glib, changed the way g_get_user_data_dir() works on Windows:
in older releases, something GLib 2.28 or 2.26 and older,
g_get_user_data_dir() returned c:\users\username\AppData\Roaming, in
newer GLib versions it returns c:\users\username\AppData\Local.
This affects users who already have a config directory located in
...\Roaming and Geany would look in ...\Local now.
This is the change I'm talking about:
https://git.gnome.org/browse/glib/commit/glib/gutils.c?id=9d80c361418f94c609840ec9f83741aede7e482c
How do we want to handle this?
- continue using the ...\Roaming directory (and so not using
g_get_user_data_dir() anymore)
If we went this route we could use something like the attached patch[0].
Maybe it's what the linked commit is referring to about proper Windows
programs probably not using those GLib functions?
- leave the code as it is, resulting in a new complete config for users
- add some code to check if a config in ...\Roaming exists and if so,
move it to ...\Local
I was thinking about it a bit and it might be good to keep using the
Roaming one (ie. whatever Win32 API gives as correct dir) since IIUC
it allows users on a domain to sync their config between machines on
login/logout. As mentioned in the linked commit, the function we use
(g_get_user_config_dir()) only changed to match g_get_user_data_dir(),
not because it's the actually a better or more appropriate directory.
Anyway, I don't actually care much either way since I rarely use
Windows, so any fix is fine to me :)
Cheers,
Matthew Brush
[0]: Untested since my win32 geany build environment is once again
broken, it might need tweaking win32 version macros before including
windows.h or using SHGetFolderPath depending on which versions of
Windows we are supporting. Also, the encoding stuff could probably be
handled nicer, without going through UTF-8 step.
diff --git a/src/main.c b/src/main.c
index 279ecdf..cc92906 100644
--- a/src/main.c
+++ b/src/main.c
@@ -608,7 +608,7 @@ static void parse_command_line_options(gint *argc, gchar ***argv)
}
else
{
- app-configdir = g_build_filename(g_get_user_config_dir(), geany, NULL);
+ app-configdir = utils_get_user_config_dir();
}
if (generate_tags)
diff --git a/src/utils.c b/src/utils.c
index e4c5448..574ca8b 100644
--- a/src/utils.c
+++ b/src/utils.c
@@ -2078,3 +2078,13 @@ gchar *utils_parse_and_format_build_date(const gchar *input)
return g_strdup(input);
}
+
+
+gchar *utils_get_user_config_dir(void)
+{
+#ifdef G_OS_WIN32
+ return win32_get_user_config_dir();
+#else
+ return g_build_filename(g_get_user_data_dir(), geany, NULL);
+#endif
+}
diff --git a/src/utils.h b/src/utils.h
index c4df0bd..7e14099 100644
--- a/src/utils.h
+++ b/src/utils.h
@@ -289,6 +289,8 @@ GDate *utils_parse_date(const gchar *input);
gchar *utils_parse_and_format_build_date(const gchar *input);
+gchar *utils_get_user_config_dir(void);
+
G_END_DECLS
#endif /* GEANY_UTILS_H */
diff --git a/src/win32.c b/src/win32.c
index eaf5afb..3fe44e6 100644
--- a/src/win32.c
+++ b/src/win32.c
@@ -1497,4 +1497,34 @@ gchar *win32_get_installation_dir(void)
}
+gchar *win32_get_user_config_dir(void)
+{
+ wchar_t wdata_dir[MAX_PATH] = {0};
+
+ if (SHGetSpecialFolderPath(NULL, CSIDL_APPDATA, TRUE))
+ {
+ /* FIXME: should probably pre-flight the WideCharToMultiByte() call
+ * to get the proper length since this UTF-8 encoded bytes which will
+ * probably be more than when encoded as UTF-16/wchar */
+ gchar u8data_dir[MAX_PATH+1] = {0};
+
+ if (WideCharToMultiByte(CP_UTF8, 0, wdata_dir, -1, u8data_dir, MAX_PATH, NULL, NULL))
+ {
+ gchar *locale_data_dir;
+
+ locale_data_dir = g_win32_locale_filename_from_utf8(u8data_dir);
+
+ if (locale_data_dir)
+ {
+gchar *full_path;
+full_path = g_build_filename(locale_data_dir, geany, NULL);
+g_free(locale_data_dir);
+return full_path;
+ }
+ }
+ }
+
+ return g_build_filename(g_get_user_config_dir(), geany, NULL);
+}
+
#endif
diff --git a/src/win32.h b/src/win32.h
index 72de162c..ad1af90 100644
--- a/src/win32.h
+++ b/src/win32.h
@@ -71,6 +71,8 @@ gchar *win32_get_installation_dir(void);
gchar *win32_expand_environment_variables(const gchar *str);
+gchar *win32_get_user_config_dir(void);
+
G_END_DECLS
#endif /* G_OS_WIN32 */
___
Devel mailing list
Devel@lists.geany.org
https://lists.geany.org/cgi-bin/mailman/listinfo/devel
Re: [Geany-Devel] Windows GTK Runtime 2.24 and config directory
On 14-08-24 08:42 AM, Frank Lanitz wrote: Am 24.08.2014 um 17:24 schrieb Matthew Brush: And looking at the code, could never work as is, but the main point is using our own wrapper function to get user config dir, it would need to be written properly :) And having in mind they will add some more magic with later versions of Windows I'm sure this is a bad idea. What magic in what versions? And what's different if the Win32 API call is in GLib vs Geany? Cheers, Matthew Brush ___ Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
Re: [Geany-Devel] Windows GTK Runtime 2.24 and config directory
On 14-08-22 11:23 AM, Enrico Tröger wrote: Hi, lately, I started building a new Windows installer which includes a recent GTK 2.24 runtime for Windows which need for future releases. [snip] - add some code to check if a config in ...\Roaming exists and if so, move it to ...\Local I'd implement the last choice if there are no objections. This is not nice because we implement again some magic config directory move code but at least the user won't notice that GLib change. Sounds fine to me, even just a one-time dialog telling the user about the change would be useful. Either way the code be put inside win32.c and guarded with an #ifdef G_OS_WIN32 so it doesn't mess up unrelated source files. FWIW, I don't think this is the first time the config directory moved. Even between WinXP and Windows7 the actual directory used had changed, causing a little confusion (for me at least). Cheers, Matthew Brush ___ Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
Re: [Geany-Devel] Possible documentation issue - building docs
On 14-08-16 10:42 PM, James Lownie wrote: Hi everyone, I was building the docs and I found the documented procedures http://www.geany.org/manual/current/index.html#id234 don't work for me. The doco says to do make docs to generate the docs, but I found that there is no target for docs and I just had to go to the docs directory and do make. I was writing up a patch to change the doco when it occurred to me that this might be a platform issue. I'm using Fedora 20 with GNU Make 3.82. Can anyone shed some light on this? Colomban wrote: Subject: Re: [Geany-Devel] Introduction and patch for documentation Hi James, and welcome here! As my first contribution I added some clarification to the section about Projects. Thanks, applied. Just one thing, we try to keep the lines at a maximum of around 72 characters for easier readability of the plain text form. That's no big deal though, I fixed this before committing. I generated a patch file as per the instructions in the doco, and attached it to this email. I hope this is the normal procedure. This is just fine, yes. There is mention of using a pull request, so do people also push their commits to the server? No, for pull requests we use the GitHub repository and their pull request feature (you have your own fork of the repository and push to it, and then ask us to merge something from your repository). Regards, Colomban His mail server was down so I sent this message for him. Cheers, Matthew Brush ___ Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
Re: [Geany-Devel] Introduction and patch for documentation
On 14-08-16 10:42 PM, James Lownie wrote: Hi everyone, To introduce myself, my name is James, I use Geany as a developer and I'm getting involved in the documentation. I've never been involved as a contributor to any open source project before, and I apologise if I break any established protocols :) As my first contribution I added some clarification to the section about Projects. I generated a patch file as per the instructions in the doco, and attached it to this email. I hope this is the normal procedure. There is mention of using a pull request, so do people also push their commits to the server? Thanks, James On 14-08-16 10:42 PM, James Lownie wrote: Hi everyone, I was building the docs and I found the documented procedures http://www.geany.org/manual/current/index.html#id234 don't work for me. The doco says to do make docs to generate the docs, but I found that there is no target for docs and I just had to go to the docs directory and do make. I was writing up a patch to change the doco when it occurred to me that this might be a platform issue. I'm using Fedora 20 with GNU Make 3.82. Can anyone shed some light on this? Colomban wrote: Subject: Re: [Geany-Devel] Introduction and patch for documentation Hi James, and welcome here! As my first contribution I added some clarification to the section about Projects. Thanks, applied. Just one thing, we try to keep the lines at a maximum of around 72 characters for easier readability of the plain text form. That's no big deal though, I fixed this before committing. I generated a patch file as per the instructions in the doco, and attached it to this email. I hope this is the normal procedure. This is just fine, yes. There is mention of using a pull request, so do people also push their commits to the server? No, for pull requests we use the GitHub repository and their pull request feature (you have your own fork of the repository and push to it, and then ask us to merge something from your repository). Regards, Colomban His mail server was down so I sent this message for him. This time to correct thread. Cheers, Matthew Brush ___ Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
Re: [Geany-Devel] build.c missing win32.h include
On 14-08-07 02:58 PM, Colomban Wendling wrote: Le 07/08/2014 23:38, Enrico Tröger a écrit : On 07/08/14 18:41, Colomban Wendling wrote: Le 07/08/2014 18:24, Enrico Tröger a écrit : [...] I'd like to make the nightly builds a bit stricter especially if it helps to spoil out such problems. Any idea how to make such warnings error without using -Werror? I'm afraid -Werror is too hard for cross-compiling. -Werror-implicit-function-declaration I use the following when building Geany, and although it shows a few warnings (one in Scintilla that is fixed upstream, a few harmless const promotions, and a few non-literals passed as printf-like formats) it's pretty neat, maybe we'd like to be able to look at these in the logs. Not sure it's so important though. -Wall -Wextra -g -O2 -Wunused -Wno-unused-parameter -Wunreachable-code -Wformat=2 -Wundef -Wshadow -Wpointer-arith -Wwrite-strings -Waggregate-return -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations -Wmissing-noreturn -Wmissing-format-attribute -Wredundant-decls -Wnested-externs -Werror-implicit-function-declaration -Wno-deprecated-declarations Thanks. I applied these to the Windows nightly builds and also printed the used CFLAGS into the logfile (for reference). http://nightly.geany.org/win32/build_win32_geany_stderr.log Hum, this is weird. There are many more warnings that I saw locally, and the compiled code looks outdated -- when I go to e.g. src/symbols.c:579: warning: will never be executed, I see... an accolade starting the function body. s/accolade/brace/ ... maybe the hook/timer that updates from Git stopped working or something? Also, the headers used seem to generate a lot of shadowing warnings, so maybe we should disable this one. Though, some are really weird, like having a math.h having a global y0 symbol!? Looking in my MinGW math.h, it seems you need to define _NO_OLDNAMES to get rid of those non-ANSII names. It might also be useful to define __STRICT_ANSI__ to get rid of more non-std/non-prefixed names. Anyway, as-is it's not really useful, so maybe we should either fix the warnings or remove the flags triggering them when not important. It would be a lot more useful if there's a way to hide errors that originate in system headers (ie. not any of ours). @Enrico, is there anyway to make the nightlies rebuild on a Git hook instead of only once per day? Like maybe giving 10 minutes buffer time to allow merging massive branches without re-compiling a bunch of times. It would be more immediate feedback on how badly one has broken Windows build :) Cheers, Matthew Brush ___ Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
Re: [Geany-Devel] build.c missing win32.h include
On 14-08-01 09:34 AM, Nick Treleaven wrote: On 01/08/2014 12:23, Lex Trotman wrote: Maybe magic somewhere, the windows nightlys are passing:) I appears that the magic is that the compile options are not strict enough, there are lots of implicit prototype warnings, but they are not errors. OK then. Thanks, you completed two of my TODOs at the end of commit message :) https://github.com/geany/geany/commit/4efcbab33234d13a7c6d1dea2901535d9317e4e1 Cheers, Matthew Brush ___ Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
Re: [Geany-Devel] Geany Contribution
On 14-07-28 12:37 PM, Devyn Collier Johnson wrote: I would like to contribute to Geany by submitting additional license headers and some more file templates like what would be found under /usr/share/geany/templates. I have already made some license headers and file templates. Would the Geany developers be interested in them? If so, then where would be the best place to send them? Would the destination like them as a zip, tarball, etc? Does this mailing list use bottom posting or top posting? I'm pretty sure the licenses are hard-coded, so would require code changes as well. P.S. I have a really out-of-date branch (from 2012) that adds LGPL, BSD, MIT, Apache2, and WTFPL. If you really want I can try and update on the latest Git master, although it might be tricky from 2 years ago. Cheers, Matthew Brush ___ Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
Re: [Geany-Devel] Geany with gtk+ 3.6.4 under Windows
to be things we did slightly weird in GTK2 that is no longer needed or doesn't work exactly the same with GTK3. If we hold off switching to bundled version to GTK3, nobody will use it and it won't get tested or fixed. IMO it would be great to put beta releases/installers for Windows on the website for download so that more people can be testing with GTK3 bundle without having to compile from scratch (far too painful for most users to do), and then we won't end up deciding at some later release date to just switch it and hope for the best. BTW, which Windows version and which GTK+ architecture bundle (32/64) are you using, in case I get a chance to try and reproduce? Cheers, Matthew Brush ___ Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
Re: [Geany-Devel] RFC: Keybindings rewrite
On 14-06-07 03:35 PM, Colomban Wendling wrote: Le 06/06/2014 16:17, Thomas Martitz a écrit : Hello, based up on Matthew's fine GtkActions branch [1] We probably should not define the actions in the Glade file but rather in the code, they aren't really a UI thing but should reflect what the app can do basically. Basically it's rather a replacement for our send_command() rather than simply keybindings. IMO it's much better to use something declarative for this than to write it in code. Even though XML is kind of ugly, it's still more maintainable/easier/etc than C, especially since Glade supports creating/editing/assigning the actions through it's user interface. Originally I was going to create a whole separate GtkBuilder file (ex. actions.xml or such) for actions, but then you loose the possibility to select the actions for the various widgets using Glade's user interface (unless I missed how to make it understand two files at once). I don't really think it's a big deal having them in the main GtkBuilder file, I mean they are *UI* actions used to control the appearance and proxy the behaviour of *UI* widgets already in the same file with other stuff like list models for the UI, etc. Cheers, Matthew Brush ___ Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
Re: [Geany-Devel] RFC: Keybindings rewrite
On 14-06-06 01:35 PM, Thomas Martitz wrote: Am 06.06.2014 16:24, schrieb Yosef Or Boczko: I think it better to port to GAction instead of GtkAction (GtkAction has been deprecated since version 3.10 and will be removed in GTK+ 4), so it will be ease to port geany to GTK+ 4 in the future. We have elaborated GAction. The problem is that it is only recent in Glib/Gtk versions. Geany is committed to support at least the last gtk2 release for some time to come. Also, unless I missed it in the docs, GAction/GSimpleAction do not appear to support associating labels, tooltips, icons, etc with the action so would require duplicating these all over the place (similar to the current way we do it). I think the transition from GtkAction to GAction isn't actually that terrible (mostly search replace) so we can do it at some point in the future. As GtkAction is so useful and what it does is quite simple, IMO we could also create our own replacement class for it in the future, or just take the relevant source files from the GTK+ tree. Cheers, Matthew Brush ___ Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
Re: [Geany-Devel] RFC: Keybindings rewrite
On 14-06-06 07:17 AM, Thomas Martitz wrote:
Hello,
based up on Matthew's fine GtkActions branch [1] I think we could
realistically rewrite keybindings.c use GtkAction/accelerators properly.
Currently it re-implements lots of gtk stuff, such as the actual looping
through the known keybindings for the callback when a keybinding
pressed. When this would be rewritten keybindings.c could probably be
half as large (in LOC terms).
The advantage of doing so would be that plugins could register
keybindings simply by providing a GtkAction instance (and optionally a
GtkMenuItem) instead of a plain callback. This would enable to handle
keybindings in a more natural (from a glib/gtk POV) form through
signals. This is especially interesting for non-C plugins because it
easier to support/implement a gobject-based API then a
function-pointer-based one. This is the major reason I'm interested in
this.
We could alternatively add a GtkActionGroup to each GeanyPlugin(Private)
structure so plugins could just add in their own actions and not have
the core even care much. I can imagine something like this:
void plugin_init(GeanyData *unused)
{
GtkAction *action = gtk_action_new(foo, Foo, Does foo, NULL);
gtk_action_group_add_action(
plugin_get_action_group(geany_plugin), action);
GtkMenuItem *item = gtk_action_create_menu_item(action);
gtk_menu_shell_append(
GTK_MENU_SHELL(geany_data.main_widgets.tools_menu), item);
gtk_widget_show(item);
// etc...
}
The keybindings editor GUI would then be able to know which actions the
plugin wants managed/edited without requiring any special API functions.
I think it is possible to do this without breaking the API or at least
without actual damage because plugins don't use the fields of
GeanyKeyGroup and GeanyKeyBinding so we can change these structs.
Is such a rewrite desirable, and would it have a realistic chance of
getting merged? I'm asking because I don't want to spend time on this
and never get it merged. Otherwise I would volunteer to do this.
Calling it a re-write will mostly likely not help :)
Cheers,
Matthew Brush
___
Devel mailing list
Devel@lists.geany.org
https://lists.geany.org/cgi-bin/mailman/listinfo/devel
Re: [Geany-Devel] [RFC]: Public API comments in headers
On 14-05-29 05:56 AM, Nick Treleaven wrote: On 26/05/2014 01:23, Lex Trotman wrote: If we moved to having public headers that just included actual public symbols, I think it would be advantageous to have those headers totally commented/documented rather than requiring the user to download Geany's source code and cross-reference functions in it to access the comments/docs, or getting hold of the generated Doxygen API documentation. Its neater to have them in the public .h file sure, but I suggest that they are going to be less likely to be kept up to date that way. Most of the editing happens in the .c files (I don't even open the .h much of the time) so the doxygen comments in headers become out of sight, out of mind. Agree, that's an important reason. Another benefit is less rebuilding due to header file changes. It's unclear if you're actually against $topic or just pointing out more reason for keeping the public API comments private. FWIW, the first point will/would be somewhat offset by the fact that public functions could/would have G_MODULE_EXPORT (or we could make some macro like GEANY_API_EXPORT or such for readability) to remind that a public function is being edited and there's sure to be a comment to edit as well. What's more, it's actually not that hard to always in all cases open a single header file and check if you broke the public API/docs, compared to all the other stuff required to making changes. The extra rebuilding would be offset by having the private and public stuff split into separate files, some files wouldn't even need to include the public headers anymore and so wouldn't trigger rebuilding as many files. In addition, if we were really worried about build times/include dependencies, we could use forward declaration in quite a few headers that just use an opaque pointer to a public type instead of including the whole header. I think overall we could actually reduce the amount of re-building required in addition to making the API comments accessible to the public API users who they're meant for. Cheers, Matthew Brush ___ Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
Re: [Geany-Devel] [RFC]: Public API comments in headers
On 14-05-29 08:01 AM, Lex Trotman wrote: On 30 May 2014 00:46, Matthew Brush mbr...@codebrainz.ca wrote: On 14-05-29 05:56 AM, Nick Treleaven wrote: On 26/05/2014 01:23, Lex Trotman wrote: If we moved to having public headers that just included actual public symbols, I think it would be advantageous to have those headers totally commented/documented rather than requiring the user to download Geany's source code and cross-reference functions in it to access the comments/docs, or getting hold of the generated Doxygen API documentation. Its neater to have them in the public .h file sure, but I suggest that they are going to be less likely to be kept up to date that way. Most of the editing happens in the .c files (I don't even open the .h much of the time) so the doxygen comments in headers become out of sight, out of mind. Agree, that's an important reason. Another benefit is less rebuilding due to header file changes. It's unclear if you're actually against $topic or just pointing out more reason for keeping the public API comments private. FWIW, the first point will/would be somewhat offset by the fact that public functions could/would have G_MODULE_EXPORT (or we could make some macro like GEANY_API_EXPORT or such for readability) to remind that a public function is being edited and there's sure to be a comment to edit as well. What's more, it's actually not that hard to always in all cases open a single header file and check if you broke the public API/docs, compared to all the other stuff required to making changes. It just needs a comment on the implementation of the API functions. The need for an API specific macro is a separate technical thing, in this case the purpose is to provide information to those pesky livewares so a comment is fine. :) Just define a snippet with the comment /* API function */ or similar and paste it just before cutting the doxygen comment for transplantation. Yeah, either way, I just meant since with the related changes we would need to put the G_MODULE_EXPORT on the public API functions anyway, we could do something like: #define GEANY_API_EXPORT G_MODULE_EXPORT to provide the same meaning as the comment, provide the needed export, and also to minimize confusion between GtkBuilder exported callbacks and actual public API functions (same as a little comment would). Cheers, Matthew Brush ___ Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
Re: [Geany-Devel] [RFC]: Public API comments in headers
On 14-05-29 11:58 AM, Thomas Martitz wrote: Am 26.05.2014 01:50, schrieb Matthew Brush: Hi, As part of working on cleaning up the exposed API to plugins I got to thinking about where our comments are located. While it's nice to keep the API-documentation-comments right at the definitions of the functions in their respective .c source files, since we only install the headers as a public reference (not even the plugin API docs IIUC), should we not move the API-documentation-comments, that we already diligently ensure exist and are fairly complete, into the headers where they are accessible to plugin developers? If we moved to having public headers that just included actual public symbols, I think it would be advantageous to have those headers totally commented/documented rather than requiring the user to download Geany's source code and cross-reference functions in it to access the comments/docs, or getting hold of the generated Doxygen API documentation. Does anyone feel really strongly about this? Hello, I can't say I feel overly strong but my experience is that when implementation and comments are split that they begin to drift apart sooner or later. I suggest keeping things as they are unless there is a compelling technical advantage. We do a half decent job at documentation (which is better than 90% of other FOSS projects) and we should not risk that. I agree somewhat, but it's actually not very hard to open the related header and check when changing the code, especially since often changing the API documentation means adding a new function, or changing the semantics/signatures of a function, or adding/changing a structure/type, which all requires editing the header anyway, so it's actually not really much extra work. As far as technical advantage, it causes less misleading comments in the source (eg. documenting `@file foo.h` in the foo.c source file), avoids users having to get a copy of the Doxygen docs for the correct version, and finally to keep all the public API comments in the same public header file, instead of the current way where types (structs, typedefs, etc.) are necessarily documented in the header, but functions are documented in the internal non-installed source files. The reference documentation is the doxygen generated html/pdf/etc. It is in many ways superior to headers+comments. The API is available online, and we could also install it on make install, so that plugin authors are not required to download anything. Not everything is actually documented in Doxygen though, so one often needs to reference the headers anyway, plus the online docs are for the latest release and not the development version of Geany (AFAIK), and additionally, installing the docs on make install (unconditionally) would mean we require the user to have at least Doxygen (plus Qt and all the stuff it requires) installed. But I agree we should (also) make the API docs installable and maybe for packagers to make them part of the -dev package for Geany if they wanted to. Cheers, Matthew Brush ___ Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
Re: [Geany-Devel] [RFC]: Public API comments in headers
On 14-05-29 04:37 PM, Lex Trotman wrote: [...] Ok, not super technical, but more compelling than I'm too lazy to open the header file/update the documentation if it's not directly above one place I edit (instead of the other place I most likely have to edit) :) Different people have different workflows, some open everything, some only open the minimum. Yeah, I guess I just see the public headers as the official interface description of the API, so it follows that (IMO) all relevant in-source documentation/comments that describe what's in the API headers should be available in them, instead of scattered into various places. If you have the headers, you can use/understand the interface kind of idea. Everything the plugin writer needs should be in the doxygen API docs. If its not fix that, don't make the plugin writer read the source. After looking at the discussions I have changed my mind and think the comments should *NOT* be moved to the header. OK, so that's one +1 for only some of the doc-comments being in the public headers (structs, enums, etc.), some being in the private/not-installed source files (functions), and some being in separate private/non-installed, non-code files (signals), and then requiring the user to have an Internet connection, Doxygen, or a combination of the not-installed source files and the installed API headers to be able to access the docs (ie status quo). Does anyone else feel strongly either way? FWIW, I don't really feel super strongly, it's just an idea that I had to help make the public headers more useful for the only people they're intended for (ie. plugin developers), along with the other stuff I want to work on like not exposing private stuff, ensuring all public stuff is properly documented, etc. None if this other stuff really hinges on moving the comments to the headers, it's just a parallel idea. Cheers, Matthew Brush ___ Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
Re: [Geany-Devel] Plugin API design question/change proposal
Hi, If nobody's opposed to this, then I'll start working on it shortly. At worst we'll end up with some new `*private.h` files in the `src` directory and maybe find some buggy plugins and/or unintentionally-public API. I'll try to keep the private headers changes separate from the removal of the `geanyfunctions.h`/function pointer macros stuff, since in theory they are independent of each other. Cheers, Matthew Brush On 14-05-20 02:29 AM, Matthew Brush wrote: Hi, Does anyone know why the plugin API was designed to use a bunch of structures containing function pointers, hidden behind macros in geanyfunctions.h? I found the commit where this stuff was added initially (ie. plugin ABI 2-3) but it doesn't mention why it was done like this and I tried to search the mailing list archives but Gmane won't let me search and the other mailing list archive doesn't go back that far. Somebody mentioned it might be because Windows doesn't export symbols by default, but it still doesn't explain why this way chosen over explicitly exporting the symbols using __declspec(dllexport)/G_MODULE_EXPORT which, IIUC, does just this. As mentioned in the Proxy Plugins thread I'm looking into making the headers scanned by GObject-introspection to automate binding the plugin API to non-C plugins, but with all of the private stuff and public stuff mixed together in public headers, it will be hard to do this. Assuming there isn't actually much of a reason for the chosen existing function pointer/structure/macro mechanism, is anybody opposed to just making the API available in the normal C way where the public functions goes in one header that plugins (and core) can use, and one header where the private stuff goes, that doesn't get installed? Just to see the work involved, I tried to do this with the build, document and editor functions. It makes the public/private more explicit, removes lots of extra code, makes only one place to update when adding new functions to the API, doesn't force plugins to import a bunch of private stuff indirectly by #including geanyplugin.h, still makes the symbols available/exported on Windows, and does it without breaking the official (ie. doxygen-commented) parts of the API (but it would need an ABI bump). The experimental changes to build, document, and editor functions are here in my header-cleanup-private branch, based ontop of my header-cleanup branch that I have an open PR for: build.h/buildprivate.h https://github.com/codebrainz/geany/commit/0b1221ce85905a066adfaae62fc73470b34af4d5 document.h/documentprivate.h https://github.com/codebrainz/geany/commit/f5e03bbee2c4edc8fe66c8e0762ef86e1f130857 editor.h/editorprivate.h https://github.com/codebrainz/geany/commit/1534f196d626494b57d408f780dfde022f18dd07 What we could do for commonly used existing private stuff: https://github.com/codebrainz/geany/commit/ac02d5330af2bd2cfcff45609f0e5b02a8b9d72a (Sorry, I just linked the relevant commits instead of the branch so people don't have to figure out which specific ones I'm talking about amidst all the other unrelated ones. It's mostly just to give an idea of what I'm talking about.) I think this would be a fairly big improvement overall and it would finally allow us to sort out what's really private and what's really public, which will make bindings generated by scanning the headers much easier. Some common stuff that wasn't public before (ie. doxygen-commented) but that is still used in plugins could be added as deprecated to the public header or if useful could be properly added with a doxygen comment. This will avoid excessive breakage where plugins were using private stuff. Any opinions, suggestions, reasons about the original design welcome. Cheers, Matthew Brush ___ Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel ___ Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
[Geany-Devel] [RFC]: Public API comments in headers
Hi, As part of working on cleaning up the exposed API to plugins I got to thinking about where our comments are located. While it's nice to keep the API-documentation-comments right at the definitions of the functions in their respective .c source files, since we only install the headers as a public reference (not even the plugin API docs IIUC), should we not move the API-documentation-comments, that we already diligently ensure exist and are fairly complete, into the headers where they are accessible to plugin developers? If we moved to having public headers that just included actual public symbols, I think it would be advantageous to have those headers totally commented/documented rather than requiring the user to download Geany's source code and cross-reference functions in it to access the comments/docs, or getting hold of the generated Doxygen API documentation. Does anyone feel really strongly about this? Cheers, Matthew Brush ___ Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
Re: [Geany-Devel] Another set of Plugin API questions
On 14-05-25 04:38 PM, Matthew Brush wrote: [snip] And my final question: do we support individual includes of Geany's headers that were available? For example, if someone, for some crazy reason wanted to move `struct GeanyDocument` to `document-blah.h` (fake example), is it a plugin bug if they directly included document.h where this type was previously, or is it an API bug because we moved the type to another file, even though we added an and include for the new header inside the central include file `geanyplugin.h`? For a real life example of this, consider this comment from the recent `header-cleanup` merge: https://github.com/geany/geany/commit/4efcbab33234d13a7c6d1dea2901535d9317e4e1#diff-b0d9f5f851974f08ac7c7bd620163687R28 And the likewise patch/PR for the plugin in GP: https://github.com/codebrainz/geany-plugins/commit/307880c0778e27d191305ec6c68355af2512d1d4 In this case I moved `GeanyApp` which was in `geany.h` (which was exposed to plugins via `geanyplugin.h`) to `app.h` of its own, but it broke GeanyLua that included all the stuff that `geanyplugin.h` would've provided it, individually. Is this a plugin bug or a public API break/bug? Cheers, Matthew Brush ___ Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
Re: [Geany-Devel] [RFC]: Public API comments in headers
On 14-05-25 05:23 PM, Lex Trotman wrote: On 26 May 2014 09:50, Matthew Brush mbr...@codebrainz.ca wrote: [snip] If we moved to having public headers that just included actual public symbols, I think it would be advantageous to have those headers totally commented/documented rather than requiring the user to download Geany's source code and cross-reference functions in it to access the comments/docs, or getting hold of the generated Doxygen API documentation. Its neater to have them in the public .h file sure, but I suggest that they are going to be less likely to be kept up to date that way. Most of the editing happens in the .c files (I don't even open the .h much of the time) so the doxygen comments in headers become out of sight, out of mind. If, in future changes, we used the `G_MODULE_EXPORT` stuff, and kept it at the site of the definition (in the C file), it might provide a queue for anyone changing it that it has related boilerplate, being an exported/public function. It might help a bit here at least. Cheers, Matthew Brush ___ Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
Re: [Geany-Devel] Another set of Plugin API questions
On 14-05-25 05:16 PM, Lex Trotman wrote: On 26 May 2014 09:38, Matthew Brush mbr...@codebrainz.ca wrote: [snip] Another example is `filetype_id` which is the enum type in `filetypes.h` that holds the various filetype IDs (ex. GEANY_FILETYPES_C, GEANY_FILETYPES_HTML, etc.). It's completely undocumented, but is used (as gint type) in functions such as `filetypes_index()`. Is it fair to say this whole enum is private, or should it rather be considered public since it was exposed to plugins via the include of `filetypes.h` in `geanyplugin.h`? Again sounds like its a mistake, since the example for `filetypes_index()` uses `GEANY_FILETYPES_C`. At least the enum should be documented. A lazy person like me would say the enum members are part of the API, even though they are not individually documented since their use is obvious in that documentation. IMO, we could just stick some empty/dummy `/**! */` comments after the enumerators if they are indeed public and their meaning is obvious (or whatever trick to get Doxygen to recognize them). Cheers, Matthew Brush ___ Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
Re: [Geany-Devel] RFC: Proxy plugins
On 14-05-21 06:45 AM, Colomban Wendling wrote: Le 19/05/2014 14:17, Thomas Martitz a écrit : [...] Sorry if I sound negative towards libpeas. I'm not fundamentally against it. I try to objectively evaluate it, and it doesn't appear to be the holy grail either, especially with our strong focus on maintaining the plugin ABI/API and exposing the current API via bindings. Amen to that. I'm not saying using Peas is not a good idea, I'm just saying we should step a little back and see things in perspective, and for what they really are. If then Peas still seems to be the most sensible, then great. What makes you think (some of us) haven't done that? It's not my fault people had fantasies about all the wonderment it could provide and are let down to find out that it only saves us rolling one large piece of the non-C language plugin puzzle :) But I agree, it would be fantastic if everyone was on the same page with regards to what libpeas provides and how much of it we'll have to re-write ourselves into the existing loader if we don't use it, and what the dependencies Geany would have afterwards, and how we'd have to manually write language bridges to those hook into those languages (ex. geanypy), etc. Cheers, Matthew Brush ___ Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
Re: [Geany-Devel] Plugin API design question/change proposal
On 14-05-21 04:24 AM, Nick Treleaven wrote: On 20/05/2014 10:29, Matthew Brush wrote: Does anyone know why the plugin API was designed to use a bunch of structures containing function pointers, hidden behind macros in geanyfunctions.h? I found the commit where this stuff was added initially (ie. plugin ABI 2-3) but it doesn't mention why it was done like this and I tried to search the mailing list archives but Gmane won't let me search and the other mailing list archive doesn't go back that far. Somebody mentioned it might be because Windows doesn't export symbols by default, but it still doesn't explain why this way chosen over explicitly exporting the symbols using __declspec(dllexport)/G_MODULE_EXPORT which, IIUC, does just this. The idea was to avoid exporting private symbols, and also to avoid having to build the binary with any dynamic link flags. Since the Glade 3 change, the binary has dynamic link flags anyway, so the reason for this is gone. Thanks for the info! Note: It's a bit annoying that all binary symbols are exported (on some platforms), ideally only symbols marked with some kind of export attribute would be. Yeah, this might not be too tough, using a symbol listing file or `-fvisibility=hidden` or such. Cheers, Matthew Brush ___ Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
[Geany-Devel] Plugin API design question/change proposal
Hi, Does anyone know why the plugin API was designed to use a bunch of structures containing function pointers, hidden behind macros in geanyfunctions.h? I found the commit where this stuff was added initially (ie. plugin ABI 2-3) but it doesn't mention why it was done like this and I tried to search the mailing list archives but Gmane won't let me search and the other mailing list archive doesn't go back that far. Somebody mentioned it might be because Windows doesn't export symbols by default, but it still doesn't explain why this way chosen over explicitly exporting the symbols using __declspec(dllexport)/G_MODULE_EXPORT which, IIUC, does just this. As mentioned in the Proxy Plugins thread I'm looking into making the headers scanned by GObject-introspection to automate binding the plugin API to non-C plugins, but with all of the private stuff and public stuff mixed together in public headers, it will be hard to do this. Assuming there isn't actually much of a reason for the chosen existing function pointer/structure/macro mechanism, is anybody opposed to just making the API available in the normal C way where the public functions goes in one header that plugins (and core) can use, and one header where the private stuff goes, that doesn't get installed? Just to see the work involved, I tried to do this with the build, document and editor functions. It makes the public/private more explicit, removes lots of extra code, makes only one place to update when adding new functions to the API, doesn't force plugins to import a bunch of private stuff indirectly by #including geanyplugin.h, still makes the symbols available/exported on Windows, and does it without breaking the official (ie. doxygen-commented) parts of the API (but it would need an ABI bump). The experimental changes to build, document, and editor functions are here in my header-cleanup-private branch, based ontop of my header-cleanup branch that I have an open PR for: build.h/buildprivate.h https://github.com/codebrainz/geany/commit/0b1221ce85905a066adfaae62fc73470b34af4d5 document.h/documentprivate.h https://github.com/codebrainz/geany/commit/f5e03bbee2c4edc8fe66c8e0762ef86e1f130857 editor.h/editorprivate.h https://github.com/codebrainz/geany/commit/1534f196d626494b57d408f780dfde022f18dd07 What we could do for commonly used existing private stuff: https://github.com/codebrainz/geany/commit/ac02d5330af2bd2cfcff45609f0e5b02a8b9d72a (Sorry, I just linked the relevant commits instead of the branch so people don't have to figure out which specific ones I'm talking about amidst all the other unrelated ones. It's mostly just to give an idea of what I'm talking about.) I think this would be a fairly big improvement overall and it would finally allow us to sort out what's really private and what's really public, which will make bindings generated by scanning the headers much easier. Some common stuff that wasn't public before (ie. doxygen-commented) but that is still used in plugins could be added as deprecated to the public header or if useful could be properly added with a doxygen comment. This will avoid excessive breakage where plugins were using private stuff. Any opinions, suggestions, reasons about the original design welcome. Cheers, Matthew Brush ___ Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
Re: [Geany-Devel] Plugin API design question/change proposal
On 14-05-20 03:38 AM, Lex Trotman wrote: [snip] I know it might be a bit hard to restrict some symbols, like enums that C spits gaily into the global namespace, but if functions and structs are limited to those intended to be available, then that will be a big leap forward. It should be ok if the enums are declared in private header (unless they need to be public), then the plugins are never faced with this namespace pollution. None of this actually *prevents* a plugin writer using the Geany headers to access everything, but in doing so they are alerted to the fact that what they are using may break, or change in subtle and incompatible ways. It doesn't technically prevent them using private functions (on *nix), since they can add a forward declaration if they lookup the function's signature, but for all other uses they couldn't since the the (private) headers would not even be installed on their systems, and for functions it's obviously wrong to be forward-declaring private functions and calling them anyway :) [snip] I'm not sure what percentage of the API this is, but if it has only taken a looong boooring day or two to do it, then its not too bad :) It's one small header (build.h) and two of the biggest ones (document.h and editor.h) and it only took a couple hours, including building geany-plugins a bunch of times to see if they broke. Cheers, Matthew Brush ___ Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
Re: [Geany-Devel] RFC: Proxy plugins
On 14-05-18 10:10 PM, Lex Trotman wrote: [snip] 2. the effort to incorporate it into the existing PM. I don't think this will be very difficult, even from me who loathes GtkTreeView :) IIUC Thomas' proposal would use the existing methods so it doesn't require any changes in these areas. But it requires writing own libpeas (ie. scanners, loaders+runtimes, +gobject-introspection-bindings, etc). Cheers, Matthew Brush ___ Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
Re: [Geany-Devel] RFC: Proxy plugins
On 14-05-18 03:07 PM, Thomas Martitz wrote:
Am 17.05.2014 03:43, schrieb Matthew Brush:
On 14-05-16 03:03 PM, Thomas Martitz wrote:
I think we want to maintain the ability to add loaders on our own,
With Peas you can, in fact it's designed with this purpose in mind,
unlike the existing C-only loader.
If it's designed for that, why doesn't it expose that to its users?
peas-plugin-loader.h is neither documented nor actually shipped, which
makes me think they want to keep their plugin architecture private
(subject to change). Given the GNOME community reputation that really
worries me because we totally want to add loaders to libpeas.
Because I guess they assume that if you're going to write another
language loader you're going to contribute it back to them. It would be
like adding a Scintilla lexer into Geany's source tree without
submitting it back upstream.
without depending on a 3rd party project. Especially for potentially
Meh, we depend on lots of 3rd party projects, several directly and
many indirectly (see `ldd geany`).
Yes, but these generally don't affect the plugin API. When we make
promises about the stability of the plugin API but depend on a 3rd party
to fullfill that promise it's not an ideal situation. Especially when
depending on the GNOME community as with libpeas.
This doesn't affect the plugin *API*. The only part that depends on how
peas does it is in the .plugin ini files stuff. Nothing in the plugin's
code even really has to know about Peas except maybe calling some type
registration function, it's just GObject interfaces after that.
Peas seems to be quite popular in the community around our
framework/UI toolkit and is used by several (if not dozens) of popular
applications, which also means it's readily available in many popular
distros' package repositories.
Even if Peas becomes unmaintained/unsupported, we could roll it into
our own source tree and maintain it like we do ctags and tagmanager
and we still wouldn't have had to write it ourselves :)
Yes I think that would be an acceptable solution once problems arise.
libpeas is pretty tiny isnt it?
I appears to be after some brief looking at the source code.
creating a compat-loader for our existing plugins. It doesn't seem
After experimenting with this a bit, I believe it doesn't make much
sense to make a compatibility layer because a) you still need
basically the same code as the existing loader code, b) you would have
to change/refactor/re-write lots of it c) you would still have two
distinct ways to implement plugin interfaces, d) increases chances of
breaking the existing loader/plugins and e) intertwining the two
loaders would probably make it harder in the distant future to just
drop one of them.
The problem is that libpeas demands a different method of making plugins
available (.ini vs known symbols in the .so file). We definitely want
only one method, even if it means transitioning the symbol method to the
.ini file.
Yeah, this is actually a bonus for both C and non-C plugins. For one, it
means Geany doesn't have to actually load the .so files for C plugins to
read the plugin info, and additionally for not-C languages, it means the
engine can get metadata about the plugin without involving the loaders
(ie. no need to PyInitialize() the interpreter just to get metadata of
unloaded plugin in Plugin Manager GUI).
That being said, if we make existing plugin loader use .INI stuff it
will break all plugins, so maybe we could make some opt-in way that
doesn't.
I don't think b) is true, and for e) it would make it actually simpler
if the one loader is just a plugin of the other one.
For b) I mean mostly just shuffling around/re-factoring code. You're
right about e), re-factoring it this way probably would improve its
encapsulation/isolation.
libpeas readily supports this. Unless I'm missing something.
The loaders (except for C) are plugins, and the build-in ones are
installed in /usr/lib/libpeas-version/loaders/ as .so libraries.
For example, peas-plugin-loader-python.c contains:
G_MODULE_EXPORT void
peas_register_types (PeasObjectModule *module) -- as a regular plugin
{
peas_object_module_register_extension_type (module,
PEAS_TYPE_PLUGIN_LOADER,
PEAS_TYPE_PLUGIN_LOADER_PYTHON);
}
I found that too. But this is not public and not documented. It's also
not installed to /usr/include/libpeas-1.0.
Yikes! Free Software not properly documented! :)
It's not just a case of bad docs here. In this case it means it's not
documented because it's private to libpeas, i.e. an implementation
detail. For the same reason the peas-plugin-loader.h is not
installed/distributed.
While it has a plugin architecture for loaders it doesn't seem designed
to allow for 3rd party loaders.
As above, I presume the idea is that new loaders should be contributed
back upstream.
Since we want plugin authors to be able to create loaders we need
something
Re: [Geany-Devel] RFC: Proxy plugins
On 14-05-13 01:43 AM, Matthew Brush wrote: On 14-05-13 12:54 AM, Thomas Martitz wrote: Am 11.05.2014 20:31, schrieb Dimitar Zhekov: On Sat, 10 May 2014 21:56:30 +0200 Thomas Martitz ku...@rockbox.org wrote: [snip] So why adapt peas when it requires a lot of changes *too* but also severely breaks plugin API? I must be missing something, but it essence it appears to me that adapting peas requires no less effort than what I propose... GeanyPy proxy = ~150 KB. 5 language proxies = ~750 KB, code that will have to be written and maintained. For comparision, geany/src/* = 1.9 MB. peas loader = ~15 KB, language support is in the core, and doesn't change with the new Geany versions, so you don't have to worry about any language(s) becoming unsupported/unmaintained. We must have Geany API (structures and functions) introspected for all new languages somehow. We can do that with large, manual, bug-prone per-language introspection, or with one GLib introspection. Don't be ridiculous. This calculation is severely flawed and you know that. Well it is true we need this either way for non-C languages to interact with the API. In the case of GeanyLua, GeanyPy and most-likely your new proxy plugins it's all whole lot of C code which would probably be too much maintenance burden to be in core. This way is probably the worst approach. GObject-introspection would probably be the best approach, but for the existing exposed API functions/structs, would probably at the very least require changing doc-comments from Doxygen to GTK-DOC (plus adding some annotations), writing some override files to patch it up, and getting rid of the macros hiding function pointers that are members of structures stuff. This still wouldn't produce a good API for non-C languages (or C even), but it would at least make it not completely manual. FWIW, I've been doing some experiments with libpeas as the loader in Geany (in my peas* branches on Github) and for the Python demo plugin (code not pushed to GH yet) I managed to get GObject-Introspection to scan Geany's source code/headers. Most of the work involved just including what you use and/or using defined names like `struct GeanyDocument` instead of `GeanyDocument` because the latter is defined off in some unrelated header. Once GI can grok one header at a time (ie. without pre-processing all the source together like C compiler does), it seems to pickup lots of the API (can't vouch for if or how well the bindings actually works yet). Needs more experimentation/tweaking to be usable still though. Cheers, Matthew Brush ___ Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
Re: [Geany-Devel] RFC: Proxy plugins
On 14-05-16 03:03 PM, Thomas Martitz wrote:
Am 16.05.2014 19:32, schrieb Dimitar Zhekov:
On Fri, 16 May 2014 16:59:17 +0200
Thomas Martitz ku...@rockbox.org wrote:
I have a question regarding libpeas. There doesn't seem to be a public
(nor documented) API to add loaders. From what I can see the current
language support of libpeas is quite poor (only python and seed (that's
JS isnt it?)). Also, they don't seem to very committed to maintaining
their loaders[1].
It doesn't seem to make much sense to support two JavaScript
implementations, although I don't know the specifics of this.
I think we want to maintain the ability to add loaders on our own,
With Peas you can, in fact it's designed with this purpose in mind,
unlike the existing C-only loader.
without depending on a 3rd party project. Especially for potentially
Meh, we depend on lots of 3rd party projects, several directly and many
indirectly (see `ldd geany`).
Peas seems to be quite popular in the community around our framework/UI
toolkit and is used by several (if not dozens) of popular applications,
which also means it's readily available in many popular distros' package
repositories.
Even if Peas becomes unmaintained/unsupported, we could roll it into our
own source tree and maintain it like we do ctags and tagmanager and we
still wouldn't have had to write it ourselves :)
creating a compat-loader for our existing plugins. It doesn't seem
After experimenting with this a bit, I believe it doesn't make much
sense to make a compatibility layer because a) you still need basically
the same code as the existing loader code, b) you would have to
change/refactor/re-write lots of it c) you would still have two distinct
ways to implement plugin interfaces, d) increases chances of breaking
the existing loader/plugins and e) intertwining the two loaders would
probably make it harder in the distant future to just drop one of them.
libpeas readily supports this. Unless I'm missing something.
The loaders (except for C) are plugins, and the build-in ones are
installed in /usr/lib/libpeas-version/loaders/ as .so libraries.
For example, peas-plugin-loader-python.c contains:
G_MODULE_EXPORT void
peas_register_types (PeasObjectModule *module) -- as a regular plugin
{
peas_object_module_register_extension_type (module,
PEAS_TYPE_PLUGIN_LOADER,
PEAS_TYPE_PLUGIN_LOADER_PYTHON);
}
I found that too. But this is not public and not documented. It's also
not installed to /usr/include/libpeas-1.0.
Yikes! Free Software not properly documented! :)
Since we want plugin authors to be able to create loaders we need
something that's stable and documented.
Then why do you want to write our own libpeas into the existing C plugin
loader? It will (at least for some time) be buggier, and less widely
tested/used/maintained (ie. only by us), take lots of extra effort, not
automate the bridge between core and the plugins' language, probably be
less well-documented, and after all, the end result would most-likely
provide an inferior experience for non-C plugin authors.
Best regards.
And for the next probable question, there is no search for .py files,
instead the plugin .ini file (foo.plugin) specifies which loader should
be used (C if missing).
I think this could be a problem too. Unless we maintain two loaders
(that would be better avoided) we need to find a way to have libpeas
We wouldn't have to maintain libpeas, it's a separate project with other
developers maintaining it for us. Eventually in the long distant future
(eg. Geany 2.0), we could drop the old loader and maintain zero loaders :)
find (and load) current plugins. Perhaps we could create a small helper
function that creates a suitable .ini (if it doesn't exist) out of the
current plugin_set_info() before running libpeas scan, for compatibility
purposes.
As mentioned above, this doesn't seem worth the trouble and I don't
think it would be as easy/useful as it seems on the surface. We could
just leave the existing loader without breaking anything, it's quite
stable and works pretty well for plain C plugins that don't want to use
GObject-ish stuff. We could document the Peas loader and related work as
provisional while we get it all integrated and working well with the GI
bindings and still leaving the existing stable C loader in-tact during
this time and for the foreseeable future.
Cheers,
Matthew Brush
___
Devel mailing list
Devel@lists.geany.org
https://lists.geany.org/cgi-bin/mailman/listinfo/devel
Re: [Geany-Devel] RFC: Proxy plugins
On 14-05-16 06:43 PM, Matthew Brush wrote: [snip] As mentioned above, this doesn't seem worth the trouble and I don't think it would be as easy/useful as it seems on the surface. We could just leave the existing loader without breaking anything, it's quite stable and works pretty well for plain C plugins that don't want to use GObject-ish stuff. We could document the Peas loader and related work as provisional while we get it all integrated and working well with the GI bindings and still leaving the existing stable C loader in-tact during this time and for the foreseeable future. Just to be clear, I don't mean to imply that we shouldn't make any effort towards providing a simple way to adapt existing plugins to use the new loader with minimal changes, just that I don't think that this mechanism or some compatibility layer for the loader needs to be a blocker/priority towards providing an alternative parallel loader that eases working in other languages and paves the way for more specific and powerful extension points with more idiomatic interfaces and APIs in multiple languages. Cheers, Matthew Brush ___ Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
Re: [Geany-Devel] RFC: Proxy plugins
On 14-05-10 12:56 PM, Thomas Martitz wrote: Am 10.05.2014 21:06, schrieb Dimitar Zhekov: After that I'd say that LibPeas is perhaps something to be considered for new application but not for our existing codebase. I think we want something that enables proxy plugins while maintaining API and ABI stability. peas does does you describe, and provides build-in loaders for Python 2/3 and JavaScript, i.e. standard languages. Please don't throw it away before even trying to adapt it. As you have mentioned, even for C plugins it's a major change, and it requires a lot of changes to Geany (doesn't it?). So why adapt peas when it requires a lot of changes *too* but also severely breaks plugin API? I must be missing something, but it essence it appears to me that adapting peas requires no less effort than what I propose (it's not actually that much new code, just a lot of refactoring) but also implies a major plugin API breakage (while my proposal can be implemented without API breakage). I don't think it has to break the existing plugin loader interface, we could make a parallel loader that integrates into the current Plugin Manager UI and such. Just leave the existing C hooks in place (ie. plugins.[c], pluginutils.[c], plugindata.h stuff) and maybe recommend people not to use for new plugins. Most of the public API functions could still be shared between core, old-style plugins and new-style plugins (via some manner of bindings for the non-C ones). Cheers, Matthew Brush ___ Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
Re: [Geany-Devel] RFC: Proxy plugins
On 14-05-10 12:06 PM, Dimitar Zhekov wrote: [snip] For python, maybe we can include geanypy/src/*.c in Geany or in a .so library. But if we don't want to end up with more 150+ KB proxies like geanypy, we'd better use introspection. I really admire Matthew and Lex for writing this thing, but that's hardly the best approach, and I don't expect many people to repeat it and maintain such proxy. You can say it, it's actually the worst approach :) It's works OK though, doesn't require additional tools (eg. SWIG/Cython/etc) and is probably more efficient/smaller than using FFI stuff from ctypes module, although it probably doesn't really matter here. +1 for some form of introspection/code generation. Cheers, Matthew Brush ___ Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
Re: [Geany-Devel] Unable to manage mailing list subscription
On 14-05-10 02:59 PM, Development wrote: Greetings, I'm attempting to manage my mailing list subscription on the Geany mailing list, via the web-interface. But when going to https://lists.geany.org/cgi-bin/mailman/options/devel/development I'm greeted with a warning, regarding the certificate: This Connection is Untrusted ... Technical Details lists.geany.org uses an invalid security certificate. The certificate is not trusted because no issuer chain was provided. (Error code: sec_error_unknown_issuer) Thank you for all your time, and consideration. http://en.wikipedia.org/wiki/CAcert.org#Inclusion_status Cheers, Matthew Brush ___ Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
Re: [Geany-Devel] RFC: Proxy plugins
On 14-05-09 01:18 PM, Thomas Martitz wrote: Am 08.05.2014 02:33, schrieb Matthew Brush: Hi Thomas, If the goal is really to enable loading plugins written in other languages, we should take a really extensive look at LibPeas before ruling it out and duplicating it ourselves. It seems especially appropriate since you want to eventually get multi-language support into core, and it provides a small library we can have a hard dependency on that (IIUC) itself has soft-dependencies on all the stuff we don't want to require for Geany (language runtimes, interpreters, etc.). Disclaimer: I'm not a LibPeas expert or even user but from what I've read about it (the docs, tutorials) it sounds like pretty much exactly the end-goal we want for Geany plugins. My $0.02. Cheers, Matthew Brush Right, LibPeas was repeatedly suggested already. However, the first reply was always uhm it would probably require a massive rewrite which is kind of showstopper given how hard it is to get changes into the core. Anyway, I have still looked into it and came to the conclusion that it's not a good fit either way, for several reasons. Please correct me if I'm wrong. a) All API entry points have to be gir-introspectable, .i.e. gobjectified. This is probably the massive rewrite that was suggested. This also implies massive plugin API/ABI breakage I think just the extension points need to be GObjects, for example, say we had a code completion provider API where plugins would be able to provide better completions for a particular language, we would have a completion provider extension point (IIUC). Other examples that we keep talking about being useful in Geany which would each require tweaking the existing code in the ways you propose specifically for proxy plugins include: * Completion providers * Syntax highlighters * Filetype plugins * I had 2 or 3 more that escape me right now b) It would breaks the plugin API in more ways. For example, plugin metadata shall be supplied via an .ini-style file. It wouldn't have to severely break the API functions (eg. the stuff in geanyfunctions.h) but it would most certainly not be compatible with the part of the API used for loading/convenience like all the `plugin_*` functions. c) Plugins need to implement and expose a new gobject in order to be even recognized as plugins (PeasEngine recognizes plugins/extensions by their GType) This is not only fairly trivial in C but many times more trivial in other languages (well at least in Python it's very simple, not sure about other languages). After that I'd say that LibPeas is perhaps something to be considered for new application but not for our existing codebase. I think we want something that enables proxy plugins while maintaining API and ABI stability. IMO, it wouldn't be a big deal as a parallel plugin system/mechanism, while just leaving the old one in place for some years as a legacy C plugins API (most of the API functions are just plain internal Geany functions, not so much work to maintain). Anyway, I don't really care, but I just think we should consider all the problems with the current plugin API and when implementing something as you're proposing, not just hack on something for the one use-case but maybe think about something more extensible/useful in other contexts. Cheers, Matthew Brush ___ Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
Re: [Geany-Devel] multiterm should be disabled if no valac is found
On 14-04-30 05:40 AM, Quentin Glidic wrote: On 2014-04-27 22:41, Matthew Brush wrote: On 14-04-27 01:08 PM, Colomban Wendling wrote: Le 27/04/2014 21:24, Matthew Brush a écrit : Yeah I guess AM_PROG_VALAC() just issues those warnings instead of failing as I'd have expected. In a perfect world, the generated *.[ch] files would be distributed and when compiling (from tarball at least) no Vala compiler would be required. GNOME folks just say that distributing generated files was a bad design idea. I can understand this, however not requiring an extra build-time dependency where not strictly necessary might improve chances of getting distributed (especially ex. on windows, not that multiterm counts :) That's the very reason why the absence of valac doesn't trigger a failure (hence disabling the plugin): because tarballs include the C sources, and then valac isn't required unless you want to change the Vala source. I'm not sure what we can do here… maybe magically detect it's not a tarball and then require valac? Not sure. One not great option would be to check-in the generated source. Just require this little dependency that Vala is for everyone. I'm not strictly opposed, but if it saves someone that is using the tarball/dist from having to install a bunch of Vala stuff even if they have no intention of modifying the original Vala sources, and Valac conveniently outputs nice portable C code, then I'm not sure. Or consider that Git = non-tarball and do: if test -d .git -a -z $VALAC; then AC_MSG_ERROR([valac is required to build from Git]) fi I like this concept best... if you forced on Multiterm/etc/Vala, and you're building from Git, then you need Valac, else soft-fail and just use generated C sources from dist, unless explicitly disabled. Cheers, Matthew Brush ___ Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
Re: [Geany-Devel] Broken download link for c++'s tags
On 14-04-30 05:17 PM, Frodox wrote: There is a broken link on [tags-page] page: - Download all C++ tag files. It leads to [tags-cpp-dl] but the script says Unknown language 'cpp' specified, please use one of:.., c++, ... If you try to load http://wiki.geany.org/get_tags?language=c++ the answer will be unexpected ( Unknown language 'c ' specified ), because plus sign in URI has special meaning. I just edited the page to change the `++` to `%2B%2B`, seems to work fine now. - Also, there is a big list of known languages, like cmake, po, pascal, lisp and so on, on [tags-cpp-dl] page, which are not mention on [tags-page], but tags which can be successfully downloaded (except c# language, due to special meaning of '#'). Is it a bug or a feature... or a Easter egg? :) The script that does the downloads packaging stuff supports all those filetypes (IIRC just the list of Geany ones at the time), so if someone adds new tags to the tags page using correct name in URL they can benefit from the tarball builder script too. Cheers, Matthew Brush ___ Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
Re: [Geany-Devel] Broken download link for c++'s tags
On 14-04-30 07:16 PM, Matthew Brush wrote: On 14-04-30 05:17 PM, Frodox wrote: There is a broken link on [tags-page] page: - Download all C++ tag files. It leads to [tags-cpp-dl] but the script says Unknown language 'cpp' specified, please use one of:.., c++, ... If you try to load http://wiki.geany.org/get_tags?language=c++ the answer will be unexpected ( Unknown language 'c ' specified ), because plus sign in URI has special meaning. I just edited the page to change the `++` to `%2B%2B`, seems to work fine now. Well the tarball is empty, so not fine. I'll try to get around to change the script to use `cpp` everywhere. In the meantime, there's only 4 C++ tag files to download individually :) Cheers, Matthew Brush ___ Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
