On Sat, Jun 12, 2010 at 01:06, Jiří Techet techet@gmail.com wrote:
On Fri, Jun 11, 2010 at 19:30, Dimitar Zhekov dimitar.zhekov@gmail.com wrote:
On Fri, 11 Jun 2010 00:17:13 +0200 Jiří Techet techet@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 without making the paths invalid. As you have no control of what happens outside the base directory, the additional paths may be moved and the project settings becomes inconsistent. Also displaying these extra directories might be confusing (where in the tree should they be displayed?) - I'd like to display only what's on the disk without the need of "meta" directories.
My current preference is to support only a single project and solve the rest by what the unix filesystem already offers. If people want to use external directories, they should add a symlink to them into the project directory (if you ask what about Windows users, my answer will be that they should start using Linux). If the symlink becomes invalid, it just won't be read but there will be no settings inconsistency. The symlinked directories would be displayed in a different color in the tree.
Thinking about it again the symlinks might not be the best idea and may cause other problems. So I'm re-thinking your original idea again, still I would prefer something a bit different. Needs more thinking...
Jiri