On Sat, Jun 12, 2010 at 01:06, Jiří Techet <[email protected]> wrote: > On Fri, Jun 11, 2010 at 19:30, Dimitar Zhekov <[email protected]> > wrote: >> On Fri, 11 Jun 2010 00:17:13 +0200 >> Jiří Techet <[email protected]> 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 _______________________________________________ Geany-devel mailing list [email protected] http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
