[Geany-devel] [ANNOUNCE] gproject - yet another geany project plugin

[Jiří Techet]

On Fri, Jun 11, 2010 at 19:30, Dimitar Zhekov <dimitar.zhekov at gmail.com> wrote:
> On Fri, 11 Jun 2010 00:17:13 +0200
> Jiří Techet <techet at 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.

>
> 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.

Continuing in my idea above, similarly to "ignored dirs patterns"
there could be "ignored dirs for tag generation patterns" (both of
these settings could be made more flexible, e.g. could contain
something like .gitignore does - right now the patterns match against
the current directory only so you cannot ignore only e.g. the toplevel
"src" directory and keep others)

>
> 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...

Should be solved with my variant too.

>
> Header/source - based on the current file's path, of course.

Internally I could treat symlinked dirs as projects with base
directory where the symlink points to so header/source swapping could
work for external projects too.

>
> And of course, connect to Geany's new/open/close project, instead of
> having duplicate actions on the sidebar.

Not possible now. Geany also should make it possible for plugins to
add a new tab to the project properties dialog so all the project
settings are at one place.

>
> Using "additional paths" may be helpful to Yura Siamashka too - there
> would be no need to deal with several projects.

The symlink solution works here too I think (after all, it's just a
different implementation of your idea).

Thanks a lot for spending your time thinking about how to improve the
plugin! It has been very inspiring for me. Please let me know what you
think about my variant of your idea.

Cheers,

Jiri