Hi,
first sorry for disappearing for such a long time - I didn't have much free time left in the past months and from the time I had I dedicated most of it to the libchamplain library I maintain to make some bigger changes and adapt it to GTK 3 in time for Gnome 3. The good news is that I didn't convert to Eclipse or Emacs meanwhile ;-).
There are still quite many patches I have against geany in my repository and I'd like to have at least part of them merged so I don't have to maintain my own geany branch. So at the moment the highest-priority patches for me are those which are necessary in order to make GProject working so it can become one of official geany plugins. The patches can be found at usual place:
https://gitorious.org/~techy/geany/gproject-geany
under the for_review4 branch. Only the first three of them are needed for GProject so they should have the highest priority when reviewing:
4774306b7f65237ef75b01e8d6c8312dcc5c526e Make project patterns visible 57b4120f94e611e8143fba89e397588de8693ec3 Use project patterns in the FIF dialog 2edb068b81cb6d541d667efecd0ec4c346f0df51 Open the file in the msgwindow even if no linenumber is specified
More info about the patches is in the commit description. If there are some questions, please ask me. Also if you prefer the patches in the form of ordinary patches rather than git repo, just let me know.
Cheers,
Jiri
Am 10.04.2011 15:03, schrieb Jiří Techet:
There are still quite many patches I have against geany in my repository and I'd like to have at least part of them merged so I don't have to maintain my own geany branch. So at the moment the highest-priority patches for me are those which are necessary in order to make GProject working so it can become one of official geany plugins. The patches can be found at usual place:
I just wanted to mention that I'm using your gproject plugin (including the necessary geany patches) for quite a while now. It's working really great and far superior to the built-in project solution. So yes, I'd love to see your patches in!
Best regards.
On Sun, Apr 10, 2011 at 15:03, Jiří Techet techet@gmail.com wrote:
Hi,
first sorry for disappearing for such a long time - I didn't have much free time left in the past months and from the time I had I dedicated most of it to the libchamplain library I maintain to make some bigger changes and adapt it to GTK 3 in time for Gnome 3. The good news is that I didn't convert to Eclipse or Emacs meanwhile ;-).
There are still quite many patches I have against geany in my repository and I'd like to have at least part of them merged so I don't have to maintain my own geany branch. So at the moment the highest-priority patches for me are those which are necessary in order to make GProject working so it can become one of official geany plugins. The patches can be found at usual place:
https://gitorious.org/~techy/geany/gproject-geany
under the for_review4 branch. Only the first three of them are needed for GProject so they should have the highest priority when reviewing:
4774306b7f65237ef75b01e8d6c8312dcc5c526e Make project patterns visible 57b4120f94e611e8143fba89e397588de8693ec3 Use project patterns in the FIF dialog 2edb068b81cb6d541d667efecd0ec4c346f0df51 Open the file in the msgwindow even if no linenumber is specified
More info about the patches is in the commit description. If there are some questions, please ask me. Also if you prefer the patches in the form of ordinary patches rather than git repo, just let me know.
Cheers,
Jiri
Hi,
more than two weeks have passed without any response and I fear it will end the same way as many times before - that I post my patches, nobody looks at them and they get forgotten. I fully understand that people have limited time to work on geany (so do I), the problem is that most of the patches are 9 months old and they haven't been reviewed so far.
Of course I understand that you may not want to have some patches merged to geany - just tell me and I'll either remove or rework them. I'd just like to get some sort of feedback - positive or negative.
Please let me know if there's anything I can help with to get the patches reviewed. Or, if you don't want my patches at all for some reason, please tell me as well so I stop spamming the mailing list with them.
Cheers,
Jiri
On Tue, 26 Apr 2011 11:18:16 +0200 Jiří Techet techet@gmail.com wrote:
On Sun, Apr 10, 2011 at 15:03, Jiří Techet techet@gmail.com wrote:
Hi,
first sorry for disappearing for such a long time - I didn't have much free time left in the past months and from the time I had I dedicated most of it to the libchamplain library I maintain to make some bigger changes and adapt it to GTK 3 in time for Gnome 3. The good news is that I didn't convert to Eclipse or Emacs meanwhile ;-).
There are still quite many patches I have against geany in my repository and I'd like to have at least part of them merged so I don't have to maintain my own geany branch. So at the moment the highest-priority patches for me are those which are necessary in order to make GProject working so it can become one of official geany plugins. The patches can be found at usual place:
https://gitorious.org/~techy/geany/gproject-geany
under the for_review4 branch. Only the first three of them are needed for GProject so they should have the highest priority when reviewing:
4774306b7f65237ef75b01e8d6c8312dcc5c526e Make project patterns visible 57b4120f94e611e8143fba89e397588de8693ec3 Use project patterns in the FIF dialog 2edb068b81cb6d541d667efecd0ec4c346f0df51 Open the file in the msgwindow even if no linenumber is specified
More info about the patches is in the commit description. If there are some questions, please ask me. Also if you prefer the patches in the form of ordinary patches rather than git repo, just let me know.
Cheers,
Jiri
Hi,
more than two weeks have passed without any response and I fear it will end the same way as many times before - that I post my patches, nobody looks at them and they get forgotten. I fully understand that people have limited time to work on geany (so do I), the problem is that most of the patches are 9 months old and they haven't been reviewed so far.
Of course I understand that you may not want to have some patches merged to geany - just tell me and I'll either remove or rework them. I'd just like to get some sort of feedback - positive or negative.
Please let me know if there's anything I can help with to get the patches reviewed. Or, if you don't want my patches at all for some reason, please tell me as well so I stop spamming the mailing list with them.
As from my point, I'm afraid I cannot add much value to this as I'm not very experienced with GOBject and stuff. That's why I didn't mess around with your patches also.
And as I mentioned according to plugin interface discussion, I like to have it this way for enabling GObject fun: I want to have someone with experince managing this kind of stuff.
Cheers, Frank
On Tue, Apr 26, 2011 at 11:30, Frank Lanitz frank@frank.uvena.de wrote:
On Tue, 26 Apr 2011 11:18:16 +0200 Jiří Techet techet@gmail.com wrote:
On Sun, Apr 10, 2011 at 15:03, Jiří Techet techet@gmail.com wrote:
Hi,
first sorry for disappearing for such a long time - I didn't have much free time left in the past months and from the time I had I dedicated most of it to the libchamplain library I maintain to make some bigger changes and adapt it to GTK 3 in time for Gnome 3. The good news is that I didn't convert to Eclipse or Emacs meanwhile ;-).
There are still quite many patches I have against geany in my repository and I'd like to have at least part of them merged so I don't have to maintain my own geany branch. So at the moment the highest-priority patches for me are those which are necessary in order to make GProject working so it can become one of official geany plugins. The patches can be found at usual place:
https://gitorious.org/~techy/geany/gproject-geany
under the for_review4 branch. Only the first three of them are needed for GProject so they should have the highest priority when reviewing:
4774306b7f65237ef75b01e8d6c8312dcc5c526e Make project patterns visible 57b4120f94e611e8143fba89e397588de8693ec3 Use project patterns in the FIF dialog 2edb068b81cb6d541d667efecd0ec4c346f0df51 Open the file in the msgwindow even if no linenumber is specified
More info about the patches is in the commit description. If there are some questions, please ask me. Also if you prefer the patches in the form of ordinary patches rather than git repo, just let me know.
Cheers,
Jiri
Hi,
more than two weeks have passed without any response and I fear it will end the same way as many times before - that I post my patches, nobody looks at them and they get forgotten. I fully understand that people have limited time to work on geany (so do I), the problem is that most of the patches are 9 months old and they haven't been reviewed so far.
Of course I understand that you may not want to have some patches merged to geany - just tell me and I'll either remove or rework them. I'd just like to get some sort of feedback - positive or negative.
Please let me know if there's anything I can help with to get the patches reviewed. Or, if you don't want my patches at all for some reason, please tell me as well so I stop spamming the mailing list with them.
As from my point, I'm afraid I cannot add much value to this as I'm not very experienced with GOBject and stuff. That's why I didn't mess around with your patches also.
Hi Frank, you probably confuse my patches with something else - there's no GObject involved in my code. The G stands for Geany or Glob (whatever you prefer) and the plugin serves for better project management and easier handling of huge projects (displays project file tree, enables header/source swapping, makes searching inside project easier, enables searches by file name).
However, there are still some missing patches (those three mentioned above) I need to get applied in geany in order to make it working. The rest are just random improvements and bug fixes.
And as I mentioned according to plugin interface discussion, I like to have it this way for enabling GObject fun: I want to have someone with experince managing this kind of stuff.
This is actually me but personally I have no interest in introducing gobject into Geany - you need quite a lot of boilerplate code and Geany's code is very nice in doing things in a simple way. Also as you say, it requires some extra knowledge so it reduces the number of possible contributors, which isn't a good thing IMO.
Cheers,
Jiri
On 04/26/11 02:18, Jiří Techet wrote:
On Sun, Apr 10, 2011 at 15:03, Jiří Techettechet@gmail.com wrote: more than two weeks have passed without any response and I fear it will end the same way as many times before - that I post my patches, nobody looks at them and they get forgotten. I fully understand that people have limited time to work on geany (so do I), the problem is that most of the patches are 9 months old and they haven't been reviewed so far.
I think in addition to time constraints, the limited number of committers means that there's basically only 3 people who can/will review patches and commit the changes to the core code.
Of course I understand that you may not want to have some patches merged to geany - just tell me and I'll either remove or rework them. I'd just like to get some sort of feedback - positive or negative.
Heh. I almost sent an identical sentence in a message to the ML a week ago, but then just decided to focus my (limited) development time elsewhere.
Please let me know if there's anything I can help with to get the patches reviewed. Or, if you don't want my patches at all for some reason, please tell me as well so I stop spamming the mailing list with them.
My only suggestions, as someone without commit access, who is outside of the core developers, but who has submitted some patches are to file bug/feature reports on SourceForge so at least your patches won't get buried over time in the archives. I can't imagine any of the developers searching through the ML archives for the word 'patches' to see what else they can review.
Another thing would be to send small digestible patches as attachments, or at least hyperlink to the exact commits, in your email/bug reports/feature requests. Basically, if I was a committer with maybe an hour or two a week to review patches, I would not want to have to learn to use a new VCS, hunt down and clone a local repo, locate the 3 commits, pull out patches for review, and *then* review them.
Of course, all of the above is just my personal observations from my short experiences with this project.
Best of luck, Matthew Brush
On Tue, Apr 26, 2011 at 14:30, Matthew Brush mbrush@codebrainz.ca wrote:
On 04/26/11 02:18, Jiří Techet wrote:
On Sun, Apr 10, 2011 at 15:03, Jiří Techettechet@gmail.com wrote: more than two weeks have passed without any response and I fear it will end the same way as many times before - that I post my patches, nobody looks at them and they get forgotten. I fully understand that people have limited time to work on geany (so do I), the problem is that most of the patches are 9 months old and they haven't been reviewed so far.
I think in addition to time constraints, the limited number of committers means that there's basically only 3 people who can/will review patches and commit the changes to the core code.
Of course I understand that you may not want to have some patches merged to geany - just tell me and I'll either remove or rework them. I'd just like to get some sort of feedback - positive or negative.
Heh. I almost sent an identical sentence in a message to the ML a week ago, but then just decided to focus my (limited) development time elsewhere.
Please let me know if there's anything I can help with to get the patches reviewed. Or, if you don't want my patches at all for some reason, please tell me as well so I stop spamming the mailing list with them.
My only suggestions, as someone without commit access, who is outside of the core developers, but who has submitted some patches are to file bug/feature reports on SourceForge so at least your patches won't get buried over time in the archives. I can't imagine any of the developers searching through the ML archives for the word 'patches' to see what else they can review.
Another thing would be to send small digestible patches as attachments, or at least hyperlink to the exact commits, in your email/bug reports/feature requests. Basically, if I was a committer with maybe an hour or two a week
I did this already here: http://lists.uvena.de/geany-devel/2010-August/thread.html (search for emails with PATCH and my name). I can repeat the same, I just don't want to spam the mailing list too much in case nobody is interested in them.
To be fair, some of the patches were applied eventually but still I find it a bit discouraging that most of the time I posted them to the mailing list, I didn't get any response.
to review patches, I would not want to have to learn to use a new VCS, hunt down and clone a local repo, locate the 3 commits, pull out patches for review, and *then* review them.
Last time I was asking Nick about whether I should rather send the patches by mail he said it was alright the way I did. And as I said above, I can send them by other means as well.
Cheers,
Jiri
On Tue, 26 Apr 2011 11:18:16 +0200 Jiří Techet techet@gmail.com wrote:
more than two weeks have passed without any response and I fear it will end the same way as many times before - that I post my patches, nobody looks at them and they get forgotten. I fully understand that people have limited time to work on geany (so do I), the problem is that most of the patches are 9 months old and they haven't been reviewed so far.
Not an exception, the X session management is 9 months old too. Perhaps we should create a geany-patches project or something?..
I remember the same situation with NEdit 5.5 several years ago: there was a "basic" version and tens of patches, apply-your-favorite-ones to extend the editor. Ironically, one of them was an improved X session management by me. :)
Unfortunately, NEdit died not much later...
On 04/26/11 11:45, Dimitar Zhekov wrote:
On Tue, 26 Apr 2011 11:18:16 +0200 Jiří Techettechet@gmail.com wrote:
more than two weeks have passed without any response and I fear it will end the same way as many times before - that I post my patches, nobody looks at them and they get forgotten. I fully understand that people have limited time to work on geany (so do I), the problem is that most of the patches are 9 months old and they haven't been reviewed so far.
Not an exception, the X session management is 9 months old too. Perhaps we should create a geany-patches project or something?..
It seems to me that the whole problem could be (dis)solved using (for example) GitHub since you can just fork the main repository, hack hack hack, and send a pull request/patch, which winds up in a proper "queue" of pull requests right on the main project repo in a pretty list, so people wanting these features before the developers get time to review them, can see all of these requests in the queue and know they are coming or are available through the forked repositories. Additionally, the core developers get a nice list of pending pull requests to work through, that never gets buried or forgotten, and other "outside" developers can know what everyone else everyone is doing. Also, with using such a VCS, all the patches have the correct authors and can be blamed and so on, complete with a perfect history of the project (including developers who don't have commit access on the main repository).
The icing on the cake, is all the cool network, impact, etc graphs and wicked interface for viewing project history, creating patches, and even committing small bits of code straight through the website (directly on the file or through Gists/pastebins).
I'm saying GitHub because I've only really used this site, I know there are other similar sites, but GitHub interface is *very* nice in comparison to say Gitorious or Launchpad. Also, I don't mean to start a holy war of VCS, I know people all have preferences, but my observation is that all of these DVCS foster community involvement more and lower the barrier of entry to helping out greatly.
Sorry if I sound like I'm on the sales team of GitHub or something, but after using it for a while, SourceForge/SVN seems crude in comparison, and I get really frustrated trying to use the SourceForge interface and contributing to projects hosted on it, especially ones using centralized VCS.
</rant>
Cheers, Matthew Brush
On Wed, Apr 27, 2011 at 02:58, Matthew Brush mbrush@codebrainz.ca wrote:
On 04/26/11 11:45, Dimitar Zhekov wrote:
On Tue, 26 Apr 2011 11:18:16 +0200 Jiří Techettechet@gmail.com wrote:
more than two weeks have passed without any response and I fear it will end the same way as many times before - that I post my patches, nobody looks at them and they get forgotten. I fully understand that people have limited time to work on geany (so do I), the problem is that most of the patches are 9 months old and they haven't been reviewed so far.
Not an exception, the X session management is 9 months old too. Perhaps we should create a geany-patches project or something?..
It seems to me that the whole problem could be (dis)solved using (for example) GitHub since you can just fork the main repository, hack hack hack, and send a pull request/patch, which winds up in a proper "queue" of pull requests right on the main project repo in a pretty list, so people wanting these features before the developers get time to review them, can see all of these requests in the queue and know they are coming or are available through the forked repositories. Additionally, the core developers get a nice list of pending pull requests to work through, that never gets buried or forgotten, and other "outside" developers can know what everyone else everyone is doing. Also, with using such a VCS, all the patches have the correct authors and can be blamed and so on, complete with a perfect history of the project (including developers who don't have commit access on the main repository).
The icing on the cake, is all the cool network, impact, etc graphs and wicked interface for viewing project history, creating patches, and even committing small bits of code straight through the website (directly on the file or through Gists/pastebins).
I'm saying GitHub because I've only really used this site, I know there are other similar sites, but GitHub interface is *very* nice in comparison to say Gitorious or Launchpad. Also, I don't mean to start a holy war of VCS, I know people all have preferences, but my observation is that all of these DVCS foster community involvement more and lower the barrier of entry to helping out greatly.
Sorry if I sound like I'm on the sales team of GitHub or something, but after using it for a while, SourceForge/SVN seems crude in comparison, and I get really frustrated trying to use the SourceForge interface and contributing to projects hosted on it, especially ones using centralized VCS.
I couldn't agree more! I was proposing a switch to git a year ago here:
http://lists.uvena.de/geany-devel/2010-June/002602.html
The conclusion was that nobody was really opposed to it but nobody felt an urgent need for it either so it was left as "maybe in the future". But maybe it's a good time now to renew the discussion now.
Apart from the advantages you mention, using git also greatly reduces maintainer's time when the maintainer trusts the developer who submitted the patches - then the patch "review" can be reduced just to
git pull patches_for_review git push
I'm using gitorious and have no experience with github but I must confess that I'm not completely satisfied with the user interface so maybe github is a better option (personally I don't care so much).
So in short, I agree that using git as VCS could greatly contribute to both fixing the "lost patches problem" and, more importantly, significantly reducing the maintainer's work. I'll be more than happy to help with the VCS migration if the geany community decides for it.
Cheers,
Jiri
On Tue, 26 Apr 2011 17:58:09 -0700 Matthew Brush mbrush@codebrainz.ca wrote:
more than two weeks have passed without any response and I fear it will end the same way as many times before [...]
Not an exception, the X session management is 9 months old too. Perhaps we should create a geany-patches project or something?..
It seems to me that the whole problem could be (dis)solved using (for example) GitHub since you can just fork the main repository, hack hack hack, and send a pull request/patch, [...]
It won't work automagically. When unreviewed for some time, which is the current situation, the patches become obsolete. For example, the recent utils_build_path() broke the xsm once when introduced, and a second time when the returned string became non-static.
[...] so people wanting these features before the developers get time to review them, can see all of these requests in the queue and know they are coming or are available through the forked repositories.
Git will be some improvement, indeed, but I'm a bit afraid of repeating the NEdit situation: instead of busying themselfs with the long patches, the devs simply tell everyone "all extras are there, take whatever you want at your own risk". I know how this ends.
Le 10/04/2011 15:03, Jiří Techet a écrit :
Hi,
Hi,
first sorry for disappearing for such a long time - I didn't have much free time left in the past months and from the time I had I dedicated most of it to the libchamplain library I maintain to make some bigger changes and adapt it to GTK 3 in time for Gnome 3. The good news is that I didn't convert to Eclipse or Emacs meanwhile ;-).
There are still quite many patches I have against geany in my repository and I'd like to have at least part of them merged so I don't have to maintain my own geany branch. So at the moment the highest-priority patches for me are those which are necessary in order to make GProject working so it can become one of official geany plugins. The patches can be found at usual place:
https://gitorious.org/~techy/geany/gproject-geany
under the for_review4 branch. Only the first three of them are needed for GProject so they should have the highest priority when reviewing:
4774306b7f65237ef75b01e8d6c8312dcc5c526e Make project patterns visible
The patch looks reasonable (read ahead), though the UI is wrongly packed, and should better use a GtkEntry now it's single-lined. I fixed this.
57b4120f94e611e8143fba89e397588de8693ec3 Use project patterns in the FIF dialog
Why not. Though, pattern matching don't work when not searching in subdirs (this isn't a flaw of your patch, the same happens currently, need to fix this).
However, I'm not sure to understand why this functionality is this important for you and your plugin?
I understand that if your plugin makes use of some file patterns, it then makes sense to show them in the FIF dialog. But Geany don't use project patterns, and adding such patters to projects seems useless to me since their only usage is to show them in the FIF dialog... but IMHO they don't make much sense since they don't mean anything more than an arbitrary set of patterns stored with the project files (we have pattern history, isn't that sufficient here?).
So maybe there are good reason, but couldn't simply your plugin provide the functionality? (though showing them in FIF dialog would probably not be possible ATM)
2edb068b81cb6d541d667efecd0ec4c346f0df51 Open the file in the msgwindow even if no linenumber is specified
I'll review this one later (tomorrow if it goes right).
Cheers, Colomban
I understand that if your plugin makes use of some file patterns, it then makes sense to show them in the FIF dialog. But Geany don't use project patterns, and adding such patters to projects seems useless to me since their only usage is to show them in the FIF dialog... but IMHO they don't make much sense since they don't mean anything more than an arbitrary set of patterns stored with the project files (we have pattern history, isn't that sufficient here?).
So maybe there are good reason, but couldn't simply your plugin provide the functionality? (though showing them in FIF dialog would probably not be possible ATM)
IIRC Jiri's plugin makes *heavy* use of file patterns, so showing them in FIF is important to giving the user an integrated experience, it wouldn't be good if the plugin provided another FIF system.
As you say a patch is needed to allow that. Storing them in the existing project file was IIIRC a way of getting them to appear in the recent list for FIF.
Cheers Lex
2edb068b81cb6d541d667efecd0ec4c346f0df51 Open the file in the msgwindow even if no linenumber is specified
I'll review this one later (tomorrow if it goes right).
Cheers, Colomban _______________________________________________ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Le 28/04/2011 02:06, Lex Trotman a écrit :
I understand that if your plugin makes use of some file patterns, it then makes sense to show them in the FIF dialog. But Geany don't use project patterns, and adding such patters to projects seems useless to me since their only usage is to show them in the FIF dialog... but IMHO they don't make much sense since they don't mean anything more than an arbitrary set of patterns stored with the project files (we have pattern history, isn't that sufficient here?).
So maybe there are good reason, but couldn't simply your plugin provide the functionality? (though showing them in FIF dialog would probably not be possible ATM)
IIRC Jiri's plugin makes *heavy* use of file patterns, so showing them in FIF is important to giving the user an integrated experience, it wouldn't be good if the plugin provided another FIF system.
As you say a patch is needed to allow that. Storing them in the existing project file was IIIRC a way of getting them to appear in the recent list for FIF.
Well, we already have history to the pattern list anyway (AFAIK?)... and maybe something like fif_set_file_filter() or whatever would be just fine?
Again, I'm not really against adding it, but I feel a bit like it's only useful when using that gproject plugin and only complicates the UI otherwise. But feel free to convince me, I'm open to argumentation ^^
Cheers, Colomban
On Thu, Apr 28, 2011 at 19:52, Colomban Wendling lists.ban@herbesfolles.org wrote:
Le 28/04/2011 02:06, Lex Trotman a écrit :
I understand that if your plugin makes use of some file patterns, it then makes sense to show them in the FIF dialog. But Geany don't use project patterns, and adding such patters to projects seems useless to me since their only usage is to show them in the FIF dialog... but IMHO they don't make much sense since they don't mean anything more than an arbitrary set of patterns stored with the project files (we have pattern history, isn't that sufficient here?).
So maybe there are good reason, but couldn't simply your plugin provide the functionality? (though showing them in FIF dialog would probably not be possible ATM)
IIRC Jiri's plugin makes *heavy* use of file patterns, so showing them in FIF is important to giving the user an integrated experience, it wouldn't be good if the plugin provided another FIF system.
As you say a patch is needed to allow that. Storing them in the existing project file was IIIRC a way of getting them to appear in the recent list for FIF.
Well, we already have history to the pattern list anyway (AFAIK?)... and maybe something like fif_set_file_filter() or whatever would be just fine?
Actually this is how it was originally implemented but (if I remember correctly) then someone on the mailing list suggested the way it's implemented now and I prefer the current implementation at the moment.
Jiri
Le 28/04/2011 01:49, Colomban Wendling a écrit :
Le 10/04/2011 15:03, Jiří Techet a écrit :
[...] 2edb068b81cb6d541d667efecd0ec4c346f0df51 Open the file in the msgwindow even if no linenumber is specified
I'll review this one later (tomorrow if it goes right).
I don't really like the patch and preferred to change msgwin_parse_grep_line() to something that directly parse file[:line[...]] so no need to do everything twice.
Though, why did you add a g_file_test(filename, G_FILE_EXISTS) before document_open_file()? Was it not to show "unable to open file" when the line don't actually contain a file or is this just a duplicate?
However, again, I'm not sure why it's so important for your plugin since it may easily add a line suffix, though it's a little hackish, I admit. Anyway I don't see any reason why not to accept this one. I'd just like you to answer the g_file_test() thing just to make sure it don't have an important role in certain cases.
Regards, Colomban
On Thu, Apr 28, 2011 at 19:46, Colomban Wendling lists.ban@herbesfolles.org wrote:
Le 28/04/2011 01:49, Colomban Wendling a écrit :
Le 10/04/2011 15:03, Jiří Techet a écrit :
[...] 2edb068b81cb6d541d667efecd0ec4c346f0df51 Open the file in the msgwindow even if no linenumber is specified
I'll review this one later (tomorrow if it goes right).
I don't really like the patch and preferred to change msgwin_parse_grep_line() to something that directly parse file[:line[...]] so no need to do everything twice.
I agree it's not very nice, on the other hand I think it's the smallest patch that achieves what I need. Modifying msgwin_parse_grep_line() isn't enough, you'd have to modify parse_file_line() and be _very_ careful because you could screw up parse_compiler_error_line() which uses this function too with different parameters.
Though, why did you add a g_file_test(filename, G_FILE_EXISTS) before document_open_file()? Was it not to show "unable to open file" when the line don't actually contain a file or is this just a duplicate?
Precisely, otherwise the error appears in status bar every time you click a message without a filename in it.
However, again, I'm not sure why it's so important for your plugin since it may easily add a line suffix, though it's a little hackish, I admit.
Exactly. When I search for a file with the given name, then the result like
foo_bar.c:851
looks a little strange (I had to put the current cursor's position there if the file was opened, otherwise the buffer scrolled to a different place). So even though there's a workaround, I'd prefer to have it handled in geany.
Jiri
Le 28/04/2011 22:58, Jiří Techet a écrit :
On Thu, Apr 28, 2011 at 19:46, Colomban Wendling lists.ban@herbesfolles.org wrote:
Le 28/04/2011 01:49, Colomban Wendling a écrit :
Le 10/04/2011 15:03, Jiří Techet a écrit :
[...] 2edb068b81cb6d541d667efecd0ec4c346f0df51 Open the file in the msgwindow even if no linenumber is specified
I'll review this one later (tomorrow if it goes right).
I don't really like the patch and preferred to change msgwin_parse_grep_line() to something that directly parse file[:line[...]] so no need to do everything twice.
I agree it's not very nice, on the other hand I think it's the smallest patch that achieves what I need. Modifying msgwin_parse_grep_line() isn't enough, you'd have to modify parse_file_line() and be _very_ careful because you could screw up parse_compiler_error_line() which uses this function too with different parameters.
I wrote a different implementation, and I think it works OK. Actually I replaced parse_grep_line() by a more generic implementation of file[:line[...]] parsing. If it has any flaw, just let me know :)
Though, why did you add a g_file_test(filename, G_FILE_EXISTS) before document_open_file()? Was it not to show "unable to open file" when the line don't actually contain a file or is this just a duplicate?
Precisely, otherwise the error appears in status bar every time you click a message without a filename in it.
Oh yeah, otherwise everything may be a file, right. Thanks for the precision.
However, again, I'm not sure why it's so important for your plugin since it may easily add a line suffix, though it's a little hackish, I admit.
Exactly. When I search for a file with the given name, then the result like
foo_bar.c:851
looks a little strange (I had to put the current cursor's position there if the file was opened, otherwise the buffer scrolled to a different place). So even though there's a workaround, I'd prefer to have it handled in geany.
Yeah true, even getting it to work properly is quiet a pain, right. Anyway, implemented in SVN now.
Cheers, Colomban
On Sat, Apr 30, 2011 at 23:57, Colomban Wendling lists.ban@herbesfolles.org wrote:
Le 28/04/2011 22:58, Jiří Techet a écrit :
On Thu, Apr 28, 2011 at 19:46, Colomban Wendling lists.ban@herbesfolles.org wrote:
Le 28/04/2011 01:49, Colomban Wendling a écrit :
Le 10/04/2011 15:03, Jiří Techet a écrit :
[...] 2edb068b81cb6d541d667efecd0ec4c346f0df51 Open the file in the msgwindow even if no linenumber is specified
I'll review this one later (tomorrow if it goes right).
I don't really like the patch and preferred to change msgwin_parse_grep_line() to something that directly parse file[:line[...]] so no need to do everything twice.
I agree it's not very nice, on the other hand I think it's the smallest patch that achieves what I need. Modifying msgwin_parse_grep_line() isn't enough, you'd have to modify parse_file_line() and be _very_ careful because you could screw up parse_compiler_error_line() which uses this function too with different parameters.
I wrote a different implementation, and I think it works OK. Actually I replaced parse_grep_line() by a more generic implementation of file[:line[...]] parsing. If it has any flaw, just let me know :)
Looks good after both looking at the implementation and testing it briefly.
Yeah true, even getting it to work properly is quiet a pain, right. Anyway, implemented in SVN now.
I've tested it and my plugin works with mainline geany now - great! I'll need one more thing - to bump the plugin API version number. Even though the API hasn't changed, people shouldn't use my plugin with previous versions of geany (it wouldn't work because they couldn't specify the patterns).
As the next step I'd like to get the plugin into the Geany Plugins project. Can I get commit access (or how does it work)? Apart from that the plugin is now missing some mandatory files like README's NEWS and so on - I'll fix that in the upcoming days. What else needs to be done?
Cheers,
Jiri
Am 02.05.2011 00:03, schrieb Jiří Techet:
I've tested it and my plugin works with mainline geany now - great! I'll need one more thing - to bump the plugin API version number. Even though the API hasn't changed, people shouldn't use my plugin with previous versions of geany (it wouldn't work because they couldn't specify the patterns).
Doesn't that mean the API actually changed? :)
Best regards.
On 2 May 2011 08:06, Thomas Martitz thomas.martitz@student.htw-berlin.de wrote:
Am 02.05.2011 00:03, schrieb Jiří Techet:
I've tested it and my plugin works with mainline geany now - great! I'll need one more thing - to bump the plugin API version number. Even though the API hasn't changed, people shouldn't use my plugin with previous versions of geany (it wouldn't work because they couldn't specify the patterns).
Doesn't that mean the API actually changed? :)
And did any additions/changes get added to the API docs?
Cheers Lex
Best regards. _______________________________________________ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
On Mon, May 2, 2011 at 00:06, Thomas Martitz thomas.martitz@student.htw-berlin.de wrote:
Am 02.05.2011 00:03, schrieb Jiří Techet:
I've tested it and my plugin works with mainline geany now - great! I'll need one more thing - to bump the plugin API version number. Even though the API hasn't changed, people shouldn't use my plugin with previous versions of geany (it wouldn't work because they couldn't specify the patterns).
Doesn't that mean the API actually changed? :)
No actually, it hasn't. There has always (i.e as long as I use geany) been the member
gchar ** file_patterns
inside the GeanyProject struct but it was always NULL because it wasn't set by anything in geany (the code which sets them was #if 0'd out - I don't know the history of geany enough to say why).
Cheers,
Jiri
Le 02/05/2011 00:03, Jiří Techet a écrit :
I'll need one more thing - to bump the plugin API version number. Even though the API hasn't changed, people shouldn't use my plugin with previous versions of geany (it wouldn't work because they couldn't specify the patterns).
A bit ugly in the idea, but I understand the point and it's nothing like a big change, so it's now done (API 211).
As the next step I'd like to get the plugin into the Geany Plugins project. Can I get commit access (or how does it work)?
You need a SF.net account, and then tell it to one of the admins and he'll add you to the project.
Apart from that the plugin is now missing some mandatory files like README's NEWS and so on - I'll fix that in the upcoming days. What else needs to be done?
Integration with the geany-plugins build system if you want to be part of the geany-plugin releases. This may be done by others if you ask to -- e.g. Enrico maintains the Waf build system and Loong Jin the autotools one, but some others may be able to do it too, so just ask here.
Cheers, Colomban
On Mon, May 2, 2011 at 18:46, Colomban Wendling lists.ban@herbesfolles.org wrote:
Le 02/05/2011 00:03, Jiří Techet a écrit :
I'll need one more thing - to bump the plugin API version number. Even though the API hasn't changed, people shouldn't use my plugin with previous versions of geany (it wouldn't work because they couldn't specify the patterns).
A bit ugly in the idea, but I understand the point and it's nothing like a big change, so it's now done (API 211).
Thanks.
As the next step I'd like to get the plugin into the Geany Plugins project. Can I get commit access (or how does it work)?
You need a SF.net account, and then tell it to one of the admins and he'll add you to the project.
Apart from that the plugin is now missing some mandatory files like README's NEWS and so on - I'll fix that in the upcoming days. What else needs to be done?
Integration with the geany-plugins build system if you want to be part of the geany-plugin releases. This may be done by others if you ask to -- e.g. Enrico maintains the Waf build system and Loong Jin the autotools one, but some others may be able to do it too, so just ask here.
I think I can do it myself, the build system doesn't look too complicated. I'll ask for my plugin's inclusion into geany-plugins once I'm done with that.
By the way, if you feel bored, you can have a look at the remaining patches in my branch ;-). A few of them are trivial ones, it's just a matter of deciding whether they should be part of geany or not. And if you don't like how something is implemented, just tell me and I'll make the necessary modifications.
Cheers,
Jiri
Hi Colomban,
thanks a lot for the review!
On Thu, Apr 28, 2011 at 01:49, Colomban Wendling lists.ban@herbesfolles.org wrote:
Le 10/04/2011 15:03, Jiří Techet a écrit :
Hi,
Hi,
first sorry for disappearing for such a long time - I didn't have much free time left in the past months and from the time I had I dedicated most of it to the libchamplain library I maintain to make some bigger changes and adapt it to GTK 3 in time for Gnome 3. The good news is that I didn't convert to Eclipse or Emacs meanwhile ;-).
There are still quite many patches I have against geany in my repository and I'd like to have at least part of them merged so I don't have to maintain my own geany branch. So at the moment the highest-priority patches for me are those which are necessary in order to make GProject working so it can become one of official geany plugins. The patches can be found at usual place:
https://gitorious.org/~techy/geany/gproject-geany
under the for_review4 branch. Only the first three of them are needed for GProject so they should have the highest priority when reviewing:
4774306b7f65237ef75b01e8d6c8312dcc5c526e Make project patterns visible
The patch looks reasonable (read ahead), though the UI is wrongly packed, and should better use a GtkEntry now it's single-lined. I fixed this.
Agree, I just reused what was there before.
57b4120f94e611e8143fba89e397588de8693ec3 Use project patterns in the FIF dialog
Why not. Though, pattern matching don't work when not searching in subdirs (this isn't a flaw of your patch, the same happens currently, need to fix this).
However, I'm not sure to understand why this functionality is this important for you and your plugin?
I understand that if your plugin makes use of some file patterns, it then makes sense to show them in the FIF dialog. But Geany don't use project patterns, and adding such patters to projects seems useless to me since their only usage is to show them in the FIF dialog... but IMHO they don't make much sense since they don't mean anything more than an arbitrary set of patterns stored with the project files (we have pattern history, isn't that sufficient here?).
So maybe there are good reason, but couldn't simply your plugin provide the functionality? (though showing them in FIF dialog would probably not be possible ATM)
I think it is useful for several reasons:
1. If you switch between several projects with different file types, you set the patterns only once and every time you open the project, the patterns in the FIF dialog are set automatically. I tend to forget to set the right patterns when switching projects which then leads to not finding the string you are searching for. Also finding the right patterns for the current project can be challenging if you have a list of very similar patterns (and different permutations like *.c *.h as one pattern and *.h *.c as another). Apart from that, to insert the right patterns for the first time you'd have to first open the project preferences and copy the patterns from there which is much less comfortable.
2. Other plugins can use the patterns. For instance the file browser plugin could be extended to use the patterns to filter the file list. I have another work-in-progress plugin which can be used to generate (and search) a ctags file for the whole project. I use the project patterns to search for tags in only those files that match the patterns.
In general, the patterns define what files belong to the project and anybody who's interested in that information can use it. At the moment the project is defined just by the base directory but nothing more, which isn't sufficient in some cases.
Cheers,
Jiri
Le 28/04/2011 22:18, Jiří Techet a écrit :
[...]
4774306b7f65237ef75b01e8d6c8312dcc5c526e Make project patterns visible
The patch looks reasonable (read ahead), though the UI is wrongly packed, and should better use a GtkEntry now it's single-lined. I fixed this.
Agree, I just reused what was there before.
57b4120f94e611e8143fba89e397588de8693ec3 Use project patterns in the FIF dialog
Why not. Though, pattern matching don't work when not searching in subdirs (this isn't a flaw of your patch, the same happens currently, need to fix this).
However, I'm not sure to understand why this functionality is this important for you and your plugin?
I understand that if your plugin makes use of some file patterns, it then makes sense to show them in the FIF dialog. But Geany don't use project patterns, and adding such patters to projects seems useless to me since their only usage is to show them in the FIF dialog... but IMHO they don't make much sense since they don't mean anything more than an arbitrary set of patterns stored with the project files (we have pattern history, isn't that sufficient here?).
So maybe there are good reason, but couldn't simply your plugin provide the functionality? (though showing them in FIF dialog would probably not be possible ATM)
I think it is useful for several reasons:
- If you switch between several projects with different file types,
you set the patterns only once and every time you open the project, the patterns in the FIF dialog are set automatically. I tend to forget to set the right patterns when switching projects which then leads to not finding the string you are searching for. Also finding the right patterns for the current project can be challenging if you have a list of very similar patterns (and different permutations like *.c *.h as one pattern and *.h *.c as another). Apart from that, to insert the right patterns for the first time you'd have to first open the project preferences and copy the patterns from there which is much less comfortable.
- Other plugins can use the patterns. For instance the file browser
plugin could be extended to use the patterns to filter the file list. I have another work-in-progress plugin which can be used to generate (and search) a ctags file for the whole project. I use the project patterns to search for tags in only those files that match the patterns.
In general, the patterns define what files belong to the project and anybody who's interested in that information can use it. At the moment the project is defined just by the base directory but nothing more, which isn't sufficient in some cases.
Ok, seems reasonable. Both committed now with some small changes, thanks for the patches.
Cheers, Colomban