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

Jiří Techet techet at xxxxx
Sat Jun 12 06:57:25 UTC 2010


On Sat, Jun 12, 2010 at 01:06, Jiří Techet <techet at gmail.com> wrote:
> 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.

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



More information about the Devel mailing list