Re: [Geany-devel] [ANNOUNCE] gproject - yet another geany project plugin
On Sun, Jun 13, 2010 at 14:07, Dimitar Zhekov dimitar.zhe...@gmail.com wrote: On Sat, 12 Jun 2010 01:06:34 +0200 Jiří Techet tec...@gmail.com wrote: On Fri, Jun 11, 2010 at 19:30, Dimitar Zhekov dimitar.zhe...@gmail.com wrote: On Fri, 11 Jun 2010 00:17:13 +0200 Yes, it displays the matching files in the Messages, and the number after the file name is... The current line if the file is open? No, there are 0s for some open files, and 1s for some unopen files... huh. Huh here too, that should work. For unopen files it should be 1 and for open files it should be the current line (this is a kind of ugly workaround to make geany to keep the current line and not to jump to the beginning of the file). Could you tell me how to reproduce the problem? It appears to work correctly here. A zero is displayed for a file open via gproject, which you never navigated into. Once you click inside the editor, use the arrows or something, that becomes non-zero. Not an issue. Aha, interesting, I wonder if this is a scintilla bug or an expected behaviour. I can add if 0 then 1 or something like that. Bookmarks with commonly used directories, for example src. I'm just not sure where to put them. I also don't think it's so much needed - first you have to expand the necessary directories, that's true, but when you continue working with the project, you see your favorites in the form of the expanded tree. I'll think about it a bit, but it's not at the top of the list of features I'd like to add. I prefer to have bookmarks, for example src and include, and avoid the entire tree as much as possible. And have an idea about them below. Apparently you find one of the best features of the plugin to be its drawback ;-) --- You are probably aware of that, but... Unless you want to really work (compile and make) with 2+ projects, [...] Ah, I forgot to start with the main ideological change (there was only a hint unless you really need 2+ projects). So then: Instead of multi-project, make gproject single-project, multi path (with the base path from Geany project). Then the base and additional paths will be displayed like the current paths for 2+ projects. With this, you'll will be able to have a /home/.../geany-testing as base project path, and several other geany trees as additonal for browsing and searching. Or a project with several main paths (Yura's), as long as there is a single build command - that's the limitation. As of the additional paths being absolute or relative, we woudn't really know if they are part of the project, and even if so, whether they are moved together with the project base path. The absolute paths look like a safe bet... But what if APs _inside_ the project tree are used as directory bookmarks? :) Obviously, they'll be relative - and so the simplest solution seems the best: let the user enter the APs as absolute or relative, and save/use them as entered. Just to make sure, do I understand correctly that the bookmarks should be subtrees of the project tree copied and put somewhere behind the project root at the top level? I think this could be done but to be able to quickly distinguish between project/external project/bookmark the sidebar should be somehow divided into three parts (e.g using separators or different color for icons or something like that). Clearly it has to be made sure that the bookmarks are not scanned for tags because the files are already scanned within the project. there could be ignored dirs for tag generation patterns Yes, having directories excluded from tag scan will be much better than any per-project or per-path options. Perpaps a check menu item in the directory right click menu? It'll be good to store these as relative I don't like the clicking idea much - for complex trees the ignored dirs would be hiding somewhere in the tree and it would be a nasty clicking exercise to find them. to their path, but that will require a real list of APs, not a single string of space-or-whatever separated entries. Well, looking at it it would be best not to have external projects - everything would get clear then - and this is probably how I'll implement it. The external dirs idea already doesn't fulfill my needs - I really need to switch between several projects each of which has the same rights as the remaining ones (header/source swapping, searching in project files and so on). But I think that your idea will integrate much better to geany's project management (only a single project open). For more open projects one should probably have more geany instances running (well, tag sharing won't be possible, I know). Unfortunately I'll have very little time to spend on implementing that in the next two months (even though the implementation looks like only one week of evening coding). But I'll definitely implement that once I have some free time left. Thanks for your ideas! Jiri
Re: [Geany-devel] [ANNOUNCE] gproject - yet another geany project plugin
On Sat, Jun 12, 2010 at 01:06, Jiří Techet tec...@gmail.com wrote: On Fri, Jun 11, 2010 at 19:30, Dimitar Zhekov dimitar.zhe...@gmail.com wrote: On Fri, 11 Jun 2010 00:17:13 +0200 Jiří Techet tec...@gmail.com wrote: Find in project segfaults. I'll compile a -g version tomorrow. Fixed pushed (I knew about this and had the fix, just forgot to push it). It was because the active file you were looking at didn't belong to the project (or you just didn't have any file opened). If the active file doesn't belong to the project, the project isn't active and the items in the menu have no effect (yes, I should gray them out in this case). Pulled. So the current file must belong to the project... Yes. The good thing about it is that if you swap between several files from different projects, it automatically selects the active project for you. But I'm aware that this might be confusing. Another option is to select the active project manually - e.g. by using a combobox in the sidebar's statusbar. Find file does nothing when started from the menu, and finds nothing when started from the project tree. I expected incrementional search or filter field in the sidebar. Again, because the project wasn't active. Probably forgot to reopen it after Find in project crashed. When it is active, it will just write the files it finds into msgwindow. Incremental search is too slow with big projects (this was real pain with codeblocks). Yes, it displays the matching files in the Messages, and the number after the file name is... The current line if the file is open? No, there are 0s for some open files, and 1s for some unopen files... huh. Huh here too, that should work. For unopen files it should be 1 and for open files it should be the current line (this is a kind of ugly workaround to make geany to keep the current line and not to jump to the beginning of the file). Could you tell me how to reproduce the problem? It appears to work correctly here. Of course, with a single mixed directory/file tree, and without any pathbar selector, bookmarks, or at least a Go to directory (maybe Find What is pathbar selector? Invoke File - Open, that's the line of buttons with path elements at the top (maybe you use a different name for them). Another PBS is to display the path as text, for example /usr/local/bin, and have each path part cickable. OK I understand, thanks for explanation. I don't see any need for bookmarks inside the plugin; this should be implemented in geany (I bet people not using this plugin want the functionality too). If you press the last button in the toolbar, the sidebar will follow the current (or bookmarked) file for you. Bookmarks with commonly used directories, for example src. I'm just not sure where to put them. I also don't think it's so much needed - first you have to expand the necessary directories, that's true, but when you continue working with the project, you see your favorites in the form of the expanded tree. I'll think about it a bit, but it's not at the top of the list of features I'd like to add. I also expected to have the file type actions in the files popup menu, it seems like the most natural thing for a full project. Not that a You mean the same that the file browser has or do you have something else in mind? Can add those, that's no problem. The actions from Project - Properties - Build. I haven't checked if it's possible to pass an arbitary name to them, or the % substitutions work with the currently open file only. With the current API, there's no integration with the geany's project possible. Right now it's completely independent of any project functionality of geany. See below. --- You are probably aware of that, but... Unless you want to really work (compile and make) with 2+ projects, in a single Geany window, as opposed to only opening files from another project, gproject can be implemented as extension to geany projects, instead of an alternative. It's actually an interesting alternative and by coincidence I've been thinking about the same when going home by train today. Unfortunately it's not possible right now. If you have a look at what one can do with the project: http://www.geany.org/manual/reference/project_8h.html you realize there's nothing you can actually do. You can just read the GeanyProject struct. IMHO, having the two workg together will be much more useful (and require less changes in Geany). Very briefly: Instead of *.gpc, store the gproject settings in *.geany, removing the duplicates. I would have to be able to add extra settings to .geany - not possible now. Add a gproject setting, additional paths or something, which contains a list of paths, for example the base paths of the projects you need to open files from. I would like to avoid that. I want all the paths to be relative to base_directory so you can move the directory wherever you want
Re: [Geany-devel] [ANNOUNCE] gproject - yet another geany project plugin
On Fri, 11 Jun 2010 00:17:13 +0200 Jiří Techet tec...@gmail.com wrote: Find in project segfaults. I'll compile a -g version tomorrow. Fixed pushed (I knew about this and had the fix, just forgot to push it). It was because the active file you were looking at didn't belong to the project (or you just didn't have any file opened). If the active file doesn't belong to the project, the project isn't active and the items in the menu have no effect (yes, I should gray them out in this case). Pulled. So the current file must belong to the project... Find file does nothing when started from the menu, and finds nothing when started from the project tree. I expected incrementional search or filter field in the sidebar. Again, because the project wasn't active. Probably forgot to reopen it after Find in project crashed. When it is active, it will just write the files it finds into msgwindow. Incremental search is too slow with big projects (this was real pain with codeblocks). Yes, it displays the matching files in the Messages, and the number after the file name is... The current line if the file is open? No, there are 0s for some open files, and 1s for some unopen files... huh. Of course, with a single mixed directory/file tree, and without any pathbar selector, bookmarks, or at least a Go to directory (maybe Find What is pathbar selector? Invoke File - Open, that's the line of buttons with path elements at the top (maybe you use a different name for them). Another PBS is to display the path as text, for example /usr/local/bin, and have each path part cickable. I don't see any need for bookmarks inside the plugin; this should be implemented in geany (I bet people not using this plugin want the functionality too). If you press the last button in the toolbar, the sidebar will follow the current (or bookmarked) file for you. Bookmarks with commonly used directories, for example src. I also expected to have the file type actions in the files popup menu, it seems like the most natural thing for a full project. Not that a You mean the same that the file browser has or do you have something else in mind? Can add those, that's no problem. The actions from Project - Properties - Build. I haven't checked if it's possible to pass an arbitary name to them, or the % substitutions work with the currently open file only. --- You are probably aware of that, but... Unless you want to really work (compile and make) with 2+ projects, in a single Geany window, as opposed to only opening files from another project, gproject can be implemented as extension to geany projects, instead of an alternative. IMHO, having the two workg together will be much more useful (and require less changes in Geany). Very briefly: Instead of *.gpc, store the gproject settings in *.geany, removing the duplicates. Add a gproject setting, additional paths or something, which contains a list of paths, for example the base paths of the projects you need to open files from. Add a gproject setting Generate tags for additional paths - since opening a file from them may not be so common, and they can be large. Well, you won't be able to use another project's Generate tags for all project files, but OTOH, you'll be able to control the tag scan separately for the base project path and the additional paths. Browser, Find file, Find in project - display / work with all paths, no matter under which of them (if any) is the current file. The current behaviour is confusing, and to search for a file, I have to select a file from the same project, or switch to the panel and navigate to the project... Header/source - based on the current file's path, of course. And of course, connect to Geany's new/open/close project, instead of having duplicate actions on the sidebar. Using additional paths may be helpful to Yura Siamashka too - there would be no need to deal with several projects. -- E-gards: Jimmy ___ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] [ANNOUNCE] gproject - yet another geany project plugin
Instead of *.gpc, store the gproject settings in *.geany, removing the duplicates. I would have to be able to add extra settings to .geany - not possible now. Hi Jiri, To do this catch the project-open and project-save signals from the Geany object, the user_data is a pointer to a GKeyFile of the current project. So long as you use new key group names (preferably related to your plugin) there won't be any interference and you can also read all the other project settings. Cheers lex ___ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] [ANNOUNCE] gproject - yet another geany project plugin
On Thu, 10 Jun 2010 10:54:46 +1000 Lex Trotman ele...@gmail.com wrote: Sigh, this isn't your fault, but I have problems with installing unknown software to system directories and plugins autofools is broken WRT installing to a non-standard prefix, waf build works if your plugin had a wscript. And I dislike using non-standard solutions (as standard I consider autotools, despite all its drawbacks), so we have a nice deadlock here :-). Your prerogative, but it means that I won't test your plugin. I have a great solution to break this deadlock. How about putting the plugin into the geany-plugins combined project, and allowing us to collaboratively maintain both the waf and autotools build systems? As it is currently, Enrico does most of the work maintaining the waf build system, and I, autotools. Putting your plugin into the combined geany-plugins project will also mean that your plugin will then have synchronized releases with Geany, and get packaged into major distributions easier as well. A win all round, don't you think? :-) -- Kind regards, Chow Loong Jin signature.asc Description: PGP signature ___ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] [ANNOUNCE] gproject - yet another geany project plugin
On 10 June 2010 16:53, Chow Loong Jin hyper...@gmail.com wrote: On Thu, 10 Jun 2010 10:54:46 +1000 Lex Trotman ele...@gmail.com wrote: Sigh, this isn't your fault, but I have problems with installing unknown software to system directories and plugins autofools is broken WRT installing to a non-standard prefix, waf build works if your plugin had a wscript. And I dislike using non-standard solutions (as standard I consider autotools, despite all its drawbacks), so we have a nice deadlock here :-). Your prerogative, but it means that I won't test your plugin. I have a great solution to break this deadlock. How about putting the plugin into the geany-plugins combined project, and allowing us to collaboratively maintain both the waf and autotools build systems? As it is currently, Enrico does most of the work maintaining the waf build system, and I, autotools. Putting your plugin into the combined geany-plugins project will also mean that your plugin will then have synchronized releases with Geany, and get packaged into major distributions easier as well. A win all round, don't you think? :-) Yes, I'd encourage Jiri to do that when his plugin is mature enough, even he notes problems that won't be fixed by the plugins release for 0.19. Cheers Lex -- Kind regards, Chow Loong Jin ___ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel ___ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] [ANNOUNCE] gproject - yet another geany project plugin
On Thu, 10 Jun 2010 17:46:37 +1000 Lex Trotman ele...@gmail.com wrote: Yes, I'd encourage Jiri to do that when his plugin is mature enough, even he notes problems that won't be fixed by the plugins release for 0.19. Yes of course, nothing new should enter geany-plugins until 0.19 gets released, since it's just around the corner. -- Kind regards, Chow Loong Jin signature.asc Description: PGP signature ___ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] [ANNOUNCE] gproject - yet another geany project plugin
On Thu, 10 Jun 2010 20:54:34 +0300 Dimitar Zhekov dimitar.zhe...@gmail.com wrote: On Tue, 8 Jun 2010 22:19:37 +0200 Jiří Techet tec...@gmail.com wrote: On Tue, Jun 8, 2010 at 19:03, Dimitar Zhekov dimitar.zhe...@gmail.com wrote: Depends what you call of a project. How about the files in a certain directory and it's subdirectories? All open source software is Precisely! That's _exactly_ what my plugin does - you set the base directory by putting the project definition file there and use wildcards to specify what files you want to be present in the project (e.g. *.c;*.h;*.am) [...] But you should be able to quickly access the source files (and filter out the files you are not interested in) Yet another file system browser... With this definition, the Geany project is only a set of files (from the entire project) that you're currently working on, plus the ability Which contradicts what you just said before - a project is a set of files in a directory (and its subdirectories), not the subset of files you are working on right now. Compare the following two phrases: open source project open source set of files I'm working on right now They are not equal. Yes, so I wrote session != project. Your mistake is the assumption that the Geany project and the file system project absolutely _have_ to be identical, and anything else is conceptually wrong. No, it's just different. Improving the Geany projects (for example the Build settings) is not a matter of fixing by replacing them with something completely different. The reason to include all project files in a list will be to provide additional functionality for them. However: source/header switching can be implemented without any project; searching in the project files is How will you know where to search for the header/source then? They don't have to be necessarily stored in the same directory (very true for the project I'm working on at work, but many other projects actually - it's quite common to put includes to a completely separate directory). Under the project base path. Of course, it's easier to find if you already have the file list. not much different from Find in files; finding a project file is much easier with the file manager; headers, sources and other files already Really? Let's suppose you want to use grep [...] First you have to leave geany and switch to console [...] Huh? Search - Find in files. grep is much faster if restricted to the correct files [still I'm talking about projects with tens of thousands source files]). I'm not quite sure Geany is the best tool for this... Plus you'll see all of the garbage files like *.o *.so and so on which you'll never ever edit by the editor. Not really nice to navigate in such a directory. And again, you have to switch from geany to your file manager which slows you down. Scrolling the sidebar tabs is not fast either, and browsing a project with tens of thousands of files (or anything 300 from my experience), using a side-window, without the powerful navigation of a file manager... It seems to me that simply adding a project patterns field in the Geany project settings dialog, and making the patterns available to all browser plugins and Find in files, would have been better than duplicating functionality. So how about testing the plugin? I'd like [...] to get a feedback based on your real experience with it, not your assumptions how you think it works ;-). $ git clone http://gitorious.org/gproject Initialized empty Git repository in [...] fatal: http://gitorious.org/gproject/info/refs not found: did you run git update-server-info on the server? $ git clone git://gitorious.org/gproject Initialized empty Git repository in [...] fatal: The remote end hung up unexpectedly My experience with git is very limited (Windows GUI only), yet these look like server errors. P.S. Thanks for fixing C-Tab. It's git://gitorious.org/gproject/mainline.git. -- Kind regards, Chow Loong Jin signature.asc Description: PGP signature ___ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] [ANNOUNCE] gproject - yet another geany project plugin
On Thu, Jun 10, 2010 at 19:54, Dimitar Zhekov dimitar.zhe...@gmail.com wrote: On Tue, 8 Jun 2010 22:19:37 +0200 Jiří Techet tec...@gmail.com wrote: On Tue, Jun 8, 2010 at 19:03, Dimitar Zhekov dimitar.zhe...@gmail.com wrote: Depends what you call of a project. How about the files in a certain directory and it's subdirectories? All open source software is Precisely! That's _exactly_ what my plugin does - you set the base directory by putting the project definition file there and use wildcards to specify what files you want to be present in the project (e.g. *.c;*.h;*.am) [...] But you should be able to quickly access the source files (and filter out the files you are not interested in) Yet another file system browser... ...that is integrated to geany and makes it possible to access files fast and gets rid of garbage files. Yes. With this definition, the Geany project is only a set of files (from the entire project) that you're currently working on, plus the ability Which contradicts what you just said before - a project is a set of files in a directory (and its subdirectories), not the subset of files you are working on right now. Compare the following two phrases: open source project open source set of files I'm working on right now They are not equal. Yes, so I wrote session != project. Your mistake is the assumption that the Geany project and the file system project absolutely _have_ to be identical, and anything else is conceptually wrong. No, it's just different. Improving the Geany projects (for example the Build settings) is not a matter of fixing by replacing them with something completely different. I use the build settings geany uses - not sure what's your point here. I said it many times before, but will repeat it once more - the only thing I dislike about the current project management is the name, not how it works (apart from some details I've been discussing with Lex and Nick). The reason to include all project files in a list will be to provide additional functionality for them. However: source/header switching can be implemented without any project; searching in the project files is How will you know where to search for the header/source then? They don't have to be necessarily stored in the same directory (very true for the project I'm working on at work, but many other projects actually - it's quite common to put includes to a completely separate directory). Under the project base path. Of course, it's easier to find if you already have the file list. Doing the search every time you want to swap is just slow for 1+ files. not much different from Find in files; finding a project file is much easier with the file manager; headers, sources and other files already Really? Let's suppose you want to use grep [...] First you have to leave geany and switch to console [...] Huh? Search - Find in files. ...which searches in all *.o and *.so and other files you are not interested in. The difference for me is 2 minutes versus 4 seconds (ack-grep takes 25 seconds). grep is much faster if restricted to the correct files [still I'm talking about projects with tens of thousands source files]). I'm not quite sure Geany is the best tool for this... Yes, it is together with my plugin (just because geany doesn't do crazy things). I know that some kernel developers use vi and some emacs, but I don't really want to use either of these (I use vi for quick command-line editing but can't imagine to use it for big projects). Forget about Eclipse, codeblocs, Anjuta (I used codeblocks for a while but geany is much better for the job now). From commercial products it could be slickedit but my company won't pay for it; and I'm pretty happy with geany. If you know any other option, I'll be happy to listen. Plus you'll see all of the garbage files like *.o *.so and so on which you'll never ever edit by the editor. Not really nice to navigate in such a directory. And again, you have to switch from geany to your file manager which slows you down. Scrolling the sidebar tabs is not fast either, and browsing a project with tens of thousands of files (or anything 300 from my experience), using a side-window, without the powerful navigation of a file manager... There's a find project file by name feature for quick access. Also you can turn on the mode where the sidebar autoexpands the tree and selects the active file. It seems to me that simply adding a project patterns field in the Geany project settings dialog, and making the patterns available to all browser plugins and Find in files, would have been better than duplicating functionality. I don't duplicate any functionality - I reuse whatever I can from geany. (Unfortunately I can't use all the features the session project uses, something I've been discussing with Lex and Nick. So some features are missing.) So how about testing the plugin? I'd like [...] to get a
Re: [Geany-devel] [ANNOUNCE] gproject - yet another geany project plugin
On Thu, Jun 10, 2010 at 23:07, Yura Siamashka yura...@gmail.com wrote: On Thu, 10 Jun 2010 22:31:27 +0200 Jiří Techet tec...@gmail.com wrote: I'd be happy if you tested it - you'd be the first one ;-). I tested your plugin and I really liked it, nice job. Thanks for your original plugin - it made me look at the problem in a slightly different way. My geanyprj plugin idea about all project files located at the one basedir made bad joke of me. Lately I have to work with lot of crazy code (SDK for different embedded boards). Here is sample structure. /apps/my_app1 /apps/my_app2 /libs/common_lib /huge_external_app_sources/kernel /huge_external_app_sources/xorg When I work on my_app1 I want to be able to use tags for my_app1 and common_lib, but I can't do this with one basedir. I work with something similar... gproject shares the tags of all open projects. You can manually deselect generate tags for all project files in the project properties dialog for those projects whose tags you don't wish to be generated. Since you have to manually open project in your plugin, Not quite - it's semi-automatic. Your plugin does this completely automatically. If you wish this to happen in my plugin, you have to press the reload all button in the sidebar. Then it automatically opens the projects of all the open files and selects the current project based on the current file. The reason why it isn't completely automatic as you did it is that it's slow for big projects and switching between two files coming from different projects was too slow. I think it won't conflict with your plugin's ideology to make basedir as list as all other fields. So both my_app1 and common_lib sources will be part of the project and big nasties as my_app2, kernel and xorg won't. It kind of starts complicating things. But as tags are shared, isn't this enough for you? Jiri ___ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] [ANNOUNCE] gproject - yet another geany project plugin
On Fri, 11 Jun 2010 02:18:39 +0800 Chow Loong Jin hyper...@gmail.com wrote: It's git://gitorious.org/gproject/mainline.git. Thanks. On Thu, 10 Jun 2010 22:31:27 +0200 Jiří Techet tec...@gmail.com wrote: Yet another file system browser... ...that is integrated to geany and makes it possible to access files fast and gets rid of garbage files. Yes. No more integrated than the other browser plugins. filebrowser filters the object files too. It seems to me that simply adding a project patterns field in the Geany project settings dialog, and making the patterns available to all browser plugins and Find in files, would have been better than duplicating functionality. I don't duplicate any functionality - I reuse whatever I can from geany. (Unfortunately I can't use all the features the session project uses, something I've been discussing with Lex and Nick. So some features are missing.) There are currently patterns in 3 plugins (including gproject) and the ability to enter them in Find in files as --include and --exclude. That's what I meant by duplication. I'd be happy if you tested it - you'd be the first one ;-). I did, briefly. On the plus side, the browser works. Now... Find in project segfaults. I'll compile a -g version tomorrow. Find file does nothing when started from the menu, and finds nothing when started from the project tree. I expected incrementional search or filter field in the sidebar. Clicking on a file/directory entry immediately re-selects the editor. Somewhat practical, but an obstacle to the keyboard navigation. Of course, with a single mixed directory/file tree, and without any pathbar selector, bookmarks, or at least a Go to directory (maybe Find file does this?), navigating inside a large project is clumsy. In a simple directory structure with lots of files, the filebrowser with it's filter is more useful. I also expected to have the file type actions in the files popup menu, it seems like the most natural thing for a full project. Not that a project-less browser plugin can't have them... Hmmm, that's an idea. -- E-gards: Jimmy ___ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] [ANNOUNCE] gproject - yet another geany project plugin
On Wed, Jun 9, 2010 at 03:40, Lex Trotman ele...@gmail.com wrote: Hi again, Note I wasn't criticising your plugin, but wanted to make sure you knew about some potential upcoming capabilities that might also be useful in combination. I absolutely understand. In fact, I prefer critical voices - it makes no sense to say each other how good we are (we know that already, don't we ;-). So please take also my comments in this sense. OK, I understand. Still in certain situations it's better to have several different projects (here I mean project in the sense I understand it) opened in the single instance. Won't remove this feature ;-) Oh sure, I wasn't suggesting you should. Was rather joke from my side. On the other hand removing features was the way I developed the plugin - originally I planned many more features but then ended with a minimal consistent set of features that play well with the rest of geany. * you can specify patterns for source and header files separately - there is a swap header/source functionality that finds the corresponding header/source to the currently opened document (same base name matching header/source pattern) Nice, I'd like to add that to the filetype config to have it available in the base Geany, sometime :). Should be pretty easy. Coding is easy, time is hard Very true. (But the coding part applies for reasonably small and simple projects like geany, not multithreaded, multiprocess, multiserver projects communicating using CORBA consisting of thousands of source files, which is something I have to work with at work). Ah, OK, didn't know it was so close. On the other hand these are really just few-liners so might be worth considering. These are the requirements for gproject to work: http://gitorious.org/~techy/geany/techys-geany/commit/6806f193b475e24dee649dfad854731342b30ebd http://gitorious.org/~techy/geany/techys-geany/commit/0b25a1225a7425ab7d726c80a93476694dee230b http://gitorious.org/~techy/geany/techys-geany/commit/f11ab5f59cf4201d08f04fef8cba40b54843625f And this fix should definitely go to 0.19: http://gitorious.org/~techy/geany/techys-geany/commit/62deb4ec5c2b8de4d0979c55f853f529efde223f I think I didn't properly describe this one in the commit log - there is a 600ms interval in which the panel displaying the current file name isn't displayed. If you switch tabs with a keybinding and do it too quickly (press it twice in the 600ms period), the wrong file is put on top of the stack. The patch could be smaller but I found the code a little confusing so I tried to make it clearer a bit. Ok, up to the guys if they have time. Sure. The few more patches are trivial ones. The changebar patch is meant just for testing and not for integration to 0.19. I'd like to suggest you tag commits you are going to refer to, not leave them as hashes, which of the links above is this one? None ;-). Instead of tags I created different branches (described in my original mail) - if you want to quickly see what's in the branches, just click the branch name here: http://gitorious.org/~techy/geany/techys-geany (branches: changebar fixes gproject-deps all) The first three links are from the gproject-deps branch and the last one from the fixes branch. The changebar is, not surprisingly, in the changebar branch. Again, unless contradicted, you should submit your changes as individual patches, one per change with explanation, so they can be reviewed one at a time. Having to grab them all from your repository makes the job too big and less likely to happen. Huh, really? What makes the job too big exactly? The reason why I submitted the patches this way is just the opposite - to make them easier to merge. You just git pull and that's it. As I said, as a maintainer of an open source project I prefer patches submitted this way but it's no problem for me to submit them in the traditional way (after all, anyone can do that by runing git format-patch after cloning the repository - I still don't see your point). The point is you are forcing people to clone your repo to get the patch. Then, which commits are meant to be individual patches? The master branch is equivalent to geany mainline, the branches contain my patches (quite a standard way how to submit patches with git). My repo is a clone of the geany project I've created here: http://gitorious.org/geany It would be best if this was taken over by the geany developers and kept up to date with the current mainline. Since as I said above, treating the whole set as one change is less acceptable than smaller individual patches, harder to review. Thats what I meant by too big. Well, there is no whole set there - the individual patches are in the form of commits. Sure its easier if everyone is using git, but ATM this is an SVN project. It's true that I've used the workflow typical for a git project - from geany web page, which offers both git and SVN repository
Re: [Geany-devel] [ANNOUNCE] gproject - yet another geany project plugin
On 9 June 2010 21:06, Jiří Techet tec...@gmail.com wrote: On Wed, Jun 9, 2010 at 03:40, Lex Trotman ele...@gmail.com wrote: Hi again, Note I wasn't criticising your plugin, but wanted to make sure you knew about some potential upcoming capabilities that might also be useful in combination. I absolutely understand. In fact, I prefer critical voices - it makes no sense to say each other how good we are (we know that already, don't we ;-). So please take also my comments in this sense. OK, I understand. Still in certain situations it's better to have several different projects (here I mean project in the sense I understand it) opened in the single instance. Won't remove this feature ;-) Oh sure, I wasn't suggesting you should. Was rather joke from my side. On the other hand removing features was the way I developed the plugin - originally I planned many more features but then ended with a minimal consistent set of features that play well with the rest of geany. * you can specify patterns for source and header files separately - there is a swap header/source functionality that finds the corresponding header/source to the currently opened document (same base name matching header/source pattern) Nice, I'd like to add that to the filetype config to have it available in the base Geany, sometime :). Should be pretty easy. Coding is easy, time is hard Very true. (But the coding part applies for reasonably small and simple projects like geany, not multithreaded, multiprocess, multiserver projects communicating using CORBA consisting of thousands of source files, which is something I have to work with at work). Ah, OK, didn't know it was so close. On the other hand these are really just few-liners so might be worth considering. These are the requirements for gproject to work: http://gitorious.org/~techy/geany/techys-geany/commit/6806f193b475e24dee649dfad854731342b30ebd http://gitorious.org/~techy/geany/techys-geany/commit/0b25a1225a7425ab7d726c80a93476694dee230b http://gitorious.org/~techy/geany/techys-geany/commit/f11ab5f59cf4201d08f04fef8cba40b54843625f And this fix should definitely go to 0.19: http://gitorious.org/~techy/geany/techys-geany/commit/62deb4ec5c2b8de4d0979c55f853f529efde223f I think I didn't properly describe this one in the commit log - there is a 600ms interval in which the panel displaying the current file name isn't displayed. If you switch tabs with a keybinding and do it too quickly (press it twice in the 600ms period), the wrong file is put on top of the stack. The patch could be smaller but I found the code a little confusing so I tried to make it clearer a bit. Ok, up to the guys if they have time. Sure. The few more patches are trivial ones. The changebar patch is meant just for testing and not for integration to 0.19. I'd like to suggest you tag commits you are going to refer to, not leave them as hashes, which of the links above is this one? None ;-). Instead of tags I created different branches (described in my original mail) - if you want to quickly see what's in the branches, just click the branch name here: My misunderstanding http://gitorious.org/~techy/geany/techys-geany (branches: changebar fixes gproject-deps all) The first three links are from the gproject-deps branch and the last one from the fixes branch. The changebar is, not surprisingly, in the changebar branch. That seems a bit confusing, maybe we should call them all Bruce (Monty Python reference :) Again, unless contradicted, you should submit your changes as individual patches, one per change with explanation, so they can be reviewed one at a time. Having to grab them all from your repository makes the job too big and less likely to happen. Huh, really? What makes the job too big exactly? The reason why I submitted the patches this way is just the opposite - to make them easier to merge. You just git pull and that's it. As I said, as a maintainer of an open source project I prefer patches submitted this way but it's no problem for me to submit them in the traditional way (after all, anyone can do that by runing git format-patch after cloning the repository - I still don't see your point). The point is you are forcing people to clone your repo to get the patch. Then, which commits are meant to be individual patches? The master branch is equivalent to geany mainline, the branches contain my patches (quite a standard way how to submit patches with git). My repo is a clone of the geany project I've created here: http://gitorious.org/geany It would be best if this was taken over by the geany developers and kept up to date with the current mainline. Since as I said above, treating the whole set as one change is less acceptable than smaller individual patches, harder to review. Thats what I meant by too big. Well, there is no whole set there - the individual patches are in the form of commits.
Re: [Geany-devel] [ANNOUNCE] gproject - yet another geany project plugin
Am 09.06.2010 03:40, schrieb Lex Trotman: Sure its easier if everyone is using git, but ATM this is an SVN project. Although most, if not all, geany developers use git, don't they? ___ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] [ANNOUNCE] gproject - yet another geany project plugin
Am 09.06.2010 13:06, schrieb Jiří Techet: It's true that I've used the workflow typical for a git project - from geany web page, which offers both git and SVN repository I assumed that I can chose either of them. If git is not supposed to be used, then it should be removed from there because this makes things confusing (or at least there should be a warning saying: Don't use the following git repository). Doesn't it clearly say that the git repo is a read-only mirror? And you can pull from it like normal, you just cannot push to it. I don't see why it shouldn't be used. ___ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] [ANNOUNCE] gproject - yet another geany project plugin
Hi, http://gitorious.org/~techy/geany/techys-geany (branches: changebar fixes gproject-deps all) The first three links are from the gproject-deps branch and the last one from the fixes branch. The changebar is, not surprisingly, in the changebar branch. That seems a bit confusing, maybe we should call them all Bruce (Monty Python reference :) NI ! It's true that I've used the workflow typical for a git project - from geany web page, which offers both git and SVN repository I assumed that I can chose either of them. If git is not supposed to be used, then it should be removed from there because this makes things confusing (or at least there should be a warning saying: Don't use the following git repository). It does say read only, I'd take that as meaning you can't push to this. Of course I can't push to it but the project maintainers could pull from me and push by themselves (for git projects typically only one person has push rights, the others just ask the maintainer for pulling from their tree and if he likes the patches, he pushes them to the main repository). But you are right, I've overlooked that this is just a SVN mirror. Anyway, no problem for me to provide the changes in the form of individual patches. I'll just wait for the main developer's opinion on this before spamming with additional emails. Good idea. I can see that there are people here not so much familiar with git, so I'll just describe in more detail how to get the modified geany and the plugin (the following gets the all branch that contains all the patches): For geany, do the following: git clone g...@gitorious.org:~techy/geany/techys-geany.git cd to the downloaded directory git checkout remotes/origin/all -b all build and install geany For the plugin do the following: git clone g...@gitorious.org:gproject/mainline.git cd to the downloaded directory ./autogen.sh; make; sudo make install Sigh, this isn't your fault, but I have problems with installing unknown software to system directories and plugins autofools is broken WRT installing to a non-standard prefix, waf build works if your plugin had a wscript. And I dislike using non-standard solutions (as standard I consider autotools, despite all its drawbacks), so we have a nice deadlock here :-). Well, what I dislike is that there is _any_ build dialog like this in geany. The only thing that should be possible is to: 1. run a user provided command 2. in the user provided (base) directory (And this is basically what geany used to do before 0.19) Plugins should be allowed to change these two depending on their needs (not possible now). As I said coming, patience :-) Period. Nothing more. For more complex projects you should use makefiles so the user provided command will be make executed in the base directory of the project. In another post on this thread you complain about IDEs that limit how projects work (agree completely BTW), but you would restrict Geany to only one build tool? ;-) Not only one, but only _the_ one the user provides. The dialog should look this way: Build command: edit_box Base directory: edit_box so if I provide something like Build command: make Base directory: /home/techet/projects/geany it would run: cd /home/techet/projects/geany make (+ there should be a possibility to use the variables like %e, %f, ...) The update to the build system is to support running any commands, make,nmake, waf, scons, cmake, ant, bjam, my_favourite_shell_script But the current build system (and the one present in 0.18) already _can_ do that, see above. And yes, at work I use my own script that based on the current file detects the current subsystem, runs other necessary scripts and starts the build of the subsystem. Why do we need the special cases as above? etc so the Non-filetype commands can't be called make commands anymore, and unfortunately the name Build has been appropriated for link, other suggestions welcome though, but there aren't many commonly understood terms about. It is also to allow the commands to be configured differently for different projects, since, if you use software from lots of sources, you get lots of build systems. For this I would suggest just a list of build_command/base_directory pairs that the user can save, load and delete. The most important thing is that geany stops accessing GeanyProject struct directly. It should be the project that requests e.g. setting the base directory, not geany reading it from the project's data structures. I'm not quite sure what you mean, sure your plugin needs to be able to set the project base directory and API is needed for that. So you will be requesting a change to the setting. That anything in Geany that uses this info reads it from a structure called a GeanyProject seems irrelevant, it has to be somewhere :). Well, I find the way things work now pretty hacky. Geany is interested in only about two or
Re: [Geany-devel] [ANNOUNCE] gproject - yet another geany project plugin
On Wed, Jun 9, 2010 at 15:16, Thomas Martitz thomas.mart...@student.htw-berlin.de wrote: Am 09.06.2010 13:06, schrieb Jiří Techet: It's true that I've used the workflow typical for a git project - from geany web page, which offers both git and SVN repository I assumed that I can chose either of them. If git is not supposed to be used, then it should be removed from there because this makes things confusing (or at least there should be a warning saying: Don't use the following git repository). Doesn't it clearly say that the git repo is a read-only mirror? And you can pull from it like normal, you just cannot push to it. I don't see why it shouldn't be used. Yes, my fault. I should read more carefully before posting a rant. Please forget my comments regarding git. (Switching to git would be really nice though). Jiri ___ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel ___ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] [ANNOUNCE] gproject - yet another geany project plugin
Hi again, snip Sigh, this isn't your fault, but I have problems with installing unknown software to system directories and plugins autofools is broken WRT installing to a non-standard prefix, waf build works if your plugin had a wscript. And I dislike using non-standard solutions (as standard I consider autotools, despite all its drawbacks), so we have a nice deadlock here :-). Your prerogative, but it means that I won't test your plugin. In another post on this thread you complain about IDEs that limit how projects work (agree completely BTW), but you would restrict Geany to only one build tool? ;-) Not only one, but only _the_ one the user provides. The dialog should look this way: Build command: edit_box Base directory: edit_box U, thats what the command and working directory columns are so if I provide something like Build command: make Base directory: /home/techet/projects/geany it would run: cd /home/techet/projects/geany Unix only, not portable, thats why the working directory isn't done that way. make So you don't want make object or make target??? If you do have them then you need to be able to define where the arguments and options go on each of these build commands. Builders other than make require options and arguments in different orders, thats what started the whole build system update in the first place, the arguments Geany 0.18 pasted didn't work for some builders. So the dialog allows the whole command to be configured, and since you are not running make any more, it allows the menu label to be changed to say what you are doing. (+ there should be a possibility to use the variables like %e, %f, ...) The update to the build system is to support running any commands, make,nmake, waf, scons, cmake, ant, bjam, my_favourite_shell_script But the current build system (and the one present in 0.18) already _can_ do that, see above. And yes, at work I use my own script that based on the current file detects the current subsystem, runs other necessary scripts and starts the build of the subsystem. Why do we need the special cases as above? See above. etc so the Non-filetype commands can't be called make commands anymore, and unfortunately the name Build has been appropriated for link, other suggestions welcome though, but there aren't many commonly understood terms about. It is also to allow the commands to be configured differently for different projects, since, if you use software from lots of sources, you get lots of build systems. For this I would suggest just a list of build_command/base_directory pairs that the user can save, load and delete. Thats exactly what the project preferences build tab is. At university I was using SciTE as the editor for everything and it was just fine (yes, and SciTE calls the thing session ;-). But for projects with thousands of source files and hundreds of directories it's just no fun, believe me. I can believe its not good at this. Is anything? geany + gproject ;-) As we say here, this has been a paid political advertisement :-) What you need is to be able to quickly navigate between the files. For this reason I had to fix the tab switching bug and introduced header/source swapping. You need to be able to filter out as many extra files as possible (that's why only the files that match the pattern you provide are included in the project). You need fast searches in files. grep is pretty fast when you restrict it only to the source files. So the plugin uses the patterns you provide as a definition of the files belonging to the project and automatically adds the restrictions as an extra potion in the find in files dialog; e.g. --include=*.c --include=*.h The first search is always slow, because the project files have to be read from the disk. But the subsequent searches are pretty fast because the files are already cached by the OS. So searching for torvalds in the whole linux tree (only *.c and *.h files) takes just about 3 seconds. Then you need to be able to quickly find a file by name. In my plugin you can use an arbitrary glob pattern for that (the leading and trailing * are inserted for you so you just need to type a part of the file name). Also building the file tree should be as fast as possible. Again, this is relatively slow when you open the project for the first time, but any subsequent project opening is very fast (2 seconds for linux kernel, from this only about 0.5 second creating the file tree). Also there is also a feature that the selected file in the file tree automatically follows the currently opened file - so the tree automatically expands and locates the current file for you - this simplifies locating the current subsystem. And most importantly, the editor should be relatively sane and not to try to reparse the whole project every time you edit or save something - 100pct CPU usage is guaranteed all the time in this
Re: [Geany-devel] [ANNOUNCE] gproject - yet another geany project plugin
Hi, thanks for the response. A few comments of mine below: On Tue, Jun 8, 2010 at 03:03, Lex Trotman ele...@gmail.com wrote: On 8 June 2010 07:38, Jiří Techet tec...@gmail.com wrote: Hi, Hi, havn't had time to look at your code but a couple of comments below. I would like to announce yet another project management plugin for geany. The main reason behind its creation is that I work with thousands of source files and the session-based project geany uses isn't sufficient for my purpose. I also had a look at geanyprj and while I like some of the ideas behind it, there are some things that don't fit my needs so I decided to create a new plugin (even though I took geanyprj as a base of the plugin, it has been completely rewritten). The things similar to geanyprj are: * the location of the configuration file determines the root path of the project * glob-like patterns are used to determine the files belonging to the project (contrary to geanyprj this is the only way to set the files belonging to the project) On the other hand, there are quite many differences: * the project files are displayed in the form of a tree in the sidebar (absolutely necessary for big projects) * several projects can be opened simultaneously (one of them is the active project, depending on the current document) Geany is working towards proper multiple instance support which will allow you to have a different project in each instance, basic capability is in 0.19 and X session support (shutdown and restore the state of multiple instances on logout/login) in the future. Also gets you multiple windows on multiple screens. OK, I understand. Still in certain situations it's better to have several different projects (here I mean project in the sense I understand it) opened in the single instance. Won't remove this feature ;-) * you can specify patterns for source and header files separately - there is a swap header/source functionality that finds the corresponding header/source to the currently opened document (same base name matching header/source pattern) Nice, I'd like to add that to the filetype config to have it available in the base Geany, sometime :). Should be pretty easy. * in addition, you can specify other project files - headers, sources and other files have different icons in the sidebar, which makes them easier to distinguish * patterns can also be used to ignore some directories you don't want to belong to the project (CVS, .git, ...) * all the project files can be scanned for tags, but this can also be disabled for big projects. * there is a possibility to find a project file by name * search in project files - the project file patterns are passed to grep, which speeds up things considerably by not having to search the binaries * many minor usability improvements * works well for huge projects (I used linux kernel for testing it and it works quite well if tag generation is disabled) The sidebar has its own toolbar so most of the actions are available directly from there. The first item in the menu, Reload all, is probably the most important one - it automatically opens the corresponding project for all the opened files Sorry, I'm not sure what you mean, do you mean, for a specified project, open all the files that were open last time you worked on the project?? No - what you say is done already by geany (it automatically opens the files that were open when you closed geany). What my plugin does (and actually what geanyprj does too) is that for each of the opened files it tries to find the project configuration file and load the project. If it doesn't find the project file in the directory where the source file is located, it tries the same in all its parent directories (the project configuration file has always the same name). Of course if the project is already opened, it doesn't reopen it again. It's the same way how git works - in whatever project directory you run git, it goes up in the directory structure and tries to find the .git directory. (geanyprj does this automatically, but for big projects this is rather annoying). In addition, there is a menu under Tools; however, the items in the menu are not supposed to be used from the menu - you should rather assign a keybinding for them as these are used frequently (header/source swapping, searching in project files, finding project file). Also there is a context menu for the items in the sidebar - the menu differs for different elements - projects, folders, files. You can get the sources here: http://gitorious.org/gproject Unfortunately, I had to make a few modifications to geany itself because its API just didn't provide the functionality I needed in several cases. I created a new geany project at gitorious: http://gitorious.org/geany (you may want to take it over and keep it up-to-date - it's better than your html-accessed git repository and allows external developers create
Re: [Geany-devel] [ANNOUNCE] gproject - yet another geany project plugin
On Tue, Jun 8, 2010 at 19:03, Dimitar Zhekov dimitar.zhe...@gmail.com wrote: On Mon, 7 Jun 2010 23:38:19 +0200 Jiří Techet tec...@gmail.com wrote: * I find the session-based project conceptually wrong - having several files opened doesn't mean that they belong to the same project - for instance I often work on several projects in parallel and have their files opened in parallel. Briefly, session != project Depends what you call of a project. How about the files in a certain directory and it's subdirectories? All open source software is Precisely! That's _exactly_ what my plugin does - you set the base directory by putting the project definition file there and use wildcards to specify what files you want to be present in the project (e.g. *.c;*.h;*.am) distributed this way, and without any IDE-specific projects. And I completely agree here - they shouldn't include any IDE-specific project. But you should be able to quickly access the source files (and filter out the files you are not interested in). And that's what my plugin does. I always hated about different IDEs how hard it is to create a project. You also had to keep your project up to date with the added/removed files. You don't have to do this here because you define the project by the means of patterns, not a list of files that are present in the project. I'm a bit unhappy that people post comments without trying it first :-(. With this definition, the Geany project is only a set of files (from the entire project) that you're currently working on, plus the ability Which contradicts what you just said before - a project is a set of files in a directory (and its subdirectories), not the subset of files you are working on right now. Compare the following two phrases: open source project open source set of files I'm working on right now They are not equal. to Compile one of them, or Make the project. Yes, session ! = project, and you can't, say, set individual compilation settings for a certain file. But there is a Makefile for this, and heavier IDEs like Code::Blocks. I absolutely agree - I hate when IDEs try to do the work of autoconf+automake. But again, this is NOT what my plugin does. Please test it first. The reason to include all project files in a list will be to provide additional functionality for them. However: source/header switching can be implemented without any project; searching in the project files is How will you know where to search for the header/source then? They don't have to be necessarily stored in the same directory (very true for the project I'm working on at work, but many other projects actually - it's quite common to put includes to a completely separate directory). not much different from Find in files; finding a project file is much easier with the file manager; headers, sources and other files already Really? Let's suppose you want to use grep (you could use ack-grep but grep is much faster if restricted to the correct files [still I'm talking about projects with tens of thousands source files]). First you have to leave geany and switch to console. Second, you'll need it to restrict only to sources you want - you'll have to type a lot of things like --include=*.c. Third you perform the search. Fourth you'll have to manually open the file by geany. I really don't think it's easier especially if you have to do it frequently. have different icons in the file manager, and you can sort them by Plus you'll see all of the garbage files like *.o *.so and so on which you'll never ever edit by the editor. Not really nice to navigate in such a directory. And again, you have to switch from geany to your file manager which slows you down. The different header/source icons aren't a key feature of the plugin but my brain finds them very useful when trying to open the correct file. name, type and a bunch of other things. Novadays FMs can even show you a tooltip, consisting of the first 10-15 lines of the file - but it would have been nice if they could skip the GPL. :) So how about testing the plugin? I'd like to know (1) that it builds and works for someone else too, and (2) would like to get a feedback based on your real experience with it, not your assumptions how you think it works ;-). Jiri -- E-gards: Jimmy ___ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel ___ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] [ANNOUNCE] gproject - yet another geany project plugin
Hi again, Note I wasn't criticising your plugin, but wanted to make sure you knew about some potential upcoming capabilities that might also be useful in combination. On 9 June 2010 02:59, Jiří Techet tec...@gmail.com wrote: Hi, thanks for the response. A few comments of mine below: On Tue, Jun 8, 2010 at 03:03, Lex Trotman ele...@gmail.com wrote: On 8 June 2010 07:38, Jiří Techet tec...@gmail.com wrote: Hi, Hi, havn't had time to look at your code but a couple of comments below. I would like to announce yet another project management plugin for geany. The main reason behind its creation is that I work with thousands of source files and the session-based project geany uses isn't sufficient for my purpose. I also had a look at geanyprj and while I like some of the ideas behind it, there are some things that don't fit my needs so I decided to create a new plugin (even though I took geanyprj as a base of the plugin, it has been completely rewritten). The things similar to geanyprj are: * the location of the configuration file determines the root path of the project * glob-like patterns are used to determine the files belonging to the project (contrary to geanyprj this is the only way to set the files belonging to the project) On the other hand, there are quite many differences: * the project files are displayed in the form of a tree in the sidebar (absolutely necessary for big projects) * several projects can be opened simultaneously (one of them is the active project, depending on the current document) Geany is working towards proper multiple instance support which will allow you to have a different project in each instance, basic capability is in 0.19 and X session support (shutdown and restore the state of multiple instances on logout/login) in the future. Also gets you multiple windows on multiple screens. OK, I understand. Still in certain situations it's better to have several different projects (here I mean project in the sense I understand it) opened in the single instance. Won't remove this feature ;-) Oh sure, I wasn't suggesting you should. * you can specify patterns for source and header files separately - there is a swap header/source functionality that finds the corresponding header/source to the currently opened document (same base name matching header/source pattern) Nice, I'd like to add that to the filetype config to have it available in the base Geany, sometime :). Should be pretty easy. Coding is easy, time is hard * in addition, you can specify other project files - headers, sources and other files have different icons in the sidebar, which makes them easier to distinguish * patterns can also be used to ignore some directories you don't want to belong to the project (CVS, .git, ...) * all the project files can be scanned for tags, but this can also be disabled for big projects. * there is a possibility to find a project file by name * search in project files - the project file patterns are passed to grep, which speeds up things considerably by not having to search the binaries * many minor usability improvements * works well for huge projects (I used linux kernel for testing it and it works quite well if tag generation is disabled) The sidebar has its own toolbar so most of the actions are available directly from there. The first item in the menu, Reload all, is probably the most important one - it automatically opens the corresponding project for all the opened files Sorry, I'm not sure what you mean, do you mean, for a specified project, open all the files that were open last time you worked on the project?? No - what you say is done already by geany (it automatically opens the files that were open when you closed geany). What my plugin does (and actually what geanyprj does too) is that for each of the opened files it tries to find the project configuration file and load the project. If it doesn't find the project file in the directory where the source file is located, it tries the same in all its parent directories (the project configuration file has always the same name). Of course if the project is already opened, it doesn't reopen it again. It's the same way how git works - in whatever project directory you run git, it goes up in the directory structure and tries to find the .git directory. Ok, I see, I don't use Geanyprj so comparing to it didn't help :) (geanyprj does this automatically, but for big projects this is rather annoying). In addition, there is a menu under Tools; however, the items in the menu are not supposed to be used from the menu - you should rather assign a keybinding for them as these are used frequently (header/source swapping, searching in project files, finding project file). Also there is a context menu for the items in the sidebar - the menu differs for different elements - projects, folders, files. You can get the sources here:
Re: [Geany-devel] [ANNOUNCE] gproject - yet another geany project plugin
On 8 June 2010 07:38, Jiří Techet tec...@gmail.com wrote: Hi, Hi, havn't had time to look at your code but a couple of comments below. I would like to announce yet another project management plugin for geany. The main reason behind its creation is that I work with thousands of source files and the session-based project geany uses isn't sufficient for my purpose. I also had a look at geanyprj and while I like some of the ideas behind it, there are some things that don't fit my needs so I decided to create a new plugin (even though I took geanyprj as a base of the plugin, it has been completely rewritten). The things similar to geanyprj are: * the location of the configuration file determines the root path of the project * glob-like patterns are used to determine the files belonging to the project (contrary to geanyprj this is the only way to set the files belonging to the project) On the other hand, there are quite many differences: * the project files are displayed in the form of a tree in the sidebar (absolutely necessary for big projects) * several projects can be opened simultaneously (one of them is the active project, depending on the current document) Geany is working towards proper multiple instance support which will allow you to have a different project in each instance, basic capability is in 0.19 and X session support (shutdown and restore the state of multiple instances on logout/login) in the future. Also gets you multiple windows on multiple screens. * you can specify patterns for source and header files separately - there is a swap header/source functionality that finds the corresponding header/source to the currently opened document (same base name matching header/source pattern) Nice, I'd like to add that to the filetype config to have it available in the base Geany, sometime :). * in addition, you can specify other project files - headers, sources and other files have different icons in the sidebar, which makes them easier to distinguish * patterns can also be used to ignore some directories you don't want to belong to the project (CVS, .git, ...) * all the project files can be scanned for tags, but this can also be disabled for big projects. * there is a possibility to find a project file by name * search in project files - the project file patterns are passed to grep, which speeds up things considerably by not having to search the binaries * many minor usability improvements * works well for huge projects (I used linux kernel for testing it and it works quite well if tag generation is disabled) The sidebar has its own toolbar so most of the actions are available directly from there. The first item in the menu, Reload all, is probably the most important one - it automatically opens the corresponding project for all the opened files Sorry, I'm not sure what you mean, do you mean, for a specified project, open all the files that were open last time you worked on the project?? (geanyprj does this automatically, but for big projects this is rather annoying). In addition, there is a menu under Tools; however, the items in the menu are not supposed to be used from the menu - you should rather assign a keybinding for them as these are used frequently (header/source swapping, searching in project files, finding project file). Also there is a context menu for the items in the sidebar - the menu differs for different elements - projects, folders, files. You can get the sources here: http://gitorious.org/gproject Unfortunately, I had to make a few modifications to geany itself because its API just didn't provide the functionality I needed in several cases. I created a new geany project at gitorious: http://gitorious.org/geany (you may want to take it over and keep it up-to-date - it's better than your html-accessed git repository and allows external developers create their own clones [you may also want to switch to git completely - it's so much better than svn Personally I agree with this, but it depends on the developers preferences, how much control they have of their environments (one may still be on SVN 1.4), for example corporate Red Hat Enterprise environments can be a long way behind the bleeding edge, and depends on what capabilities their hosting system has. ]). This is just a clone of the mainline. Then there is my personal clone with the modifications: http://gitorious.org/~techy/geany/techys-geany There are four branches: * gproject-deps - API additions required by gproject * fixes - fixes that should be applied regardless of gproject * changebar - this is just for those interested - I've ported the changebar from codeblocks - something I can't live without. This however means to maintain a branch of scintilla and I'm not sure if this is something you want. * all - all the above branches combined (For those less familiar with git - these are remote branches and you have to create a remote
