[Geany-devel] GProject - the second attempt
elextr at xxxxx
Fri Jul 9 01:37:02 UTC 2010
>>> Remove the "set" button from the project properties dialog
>>> Unless I miss something the button just adds %d to the corresponding
>>> fields, but this is already the default settings so I don't see any
>>> point of doing it.
>> I think so too.
> I was wrong about %d being default (it was set this way in my global
> settings) but I still don't like the button much. First it takes too
> much time for my brain to understand what the long label says, second
> it's no problem to set the %d manually. But I don't care too much
> about this particular patch.
It actually sets them to %p not %d, but I agree that it should go,
someone wanted it to give a single click replacement for the checkbox
that was there (in 0.18 and before) but I think its confusing.
>>> Use relative paths in the project files
>> Hmm, I thought there was something like this already, but haven't
>> checked, so maybe.
> No, there's nothing like that. I understand that using full paths may
> be useful in some special cases to move the project file separately
> from the project files to a completely different place without
> breaking things, but in my opinion being able to move a project
> together with the project file to a different directory (PC) without
> breaking the paths is much more useful.
I'd find that very useful, second the motion
> (The patch (mis)uses short evaluation of boolean expressions in C so
> this is probably what you have overlooked.)
Its a perfectly valid use and a widely used idiom, don't apologise for it.
> The "find in project files" item is identical to "find in files" but
> always using the project's base directory no matter what file is
> The reason why I think it's better to put these entries into the
> project menu is that when the user uses my gproject plugin, it is
> completely invisible for him that it's some kind of extension of geany
> - everything is integrated to the current project handling and it
> would look a bit strange if some entries related to the project would
> be under the project menu and some under the tools menu.
Totally agree, Geany doesn't (yet) support plugins integrating
themselves fully into Geany, but its something that needs thinking
about as a general capability to allow a more seamless user
experience, maybe we can look at how tools like Firefox do it.
The problem with the current approach is that each time someone comes
along with a good idea they have to request access to parts of Geany
from the primary developers and then there is a discussion of what is
right to make available or add to the core. All of which wastes the
core developers time and reduces what else they can do. A more
general plugin system would save them having to do that.
> One more thing that might be needed by plugins (but which isn't needed
> by gproject so I haven't added the API methods) is the ability to add
> their own validators of the dialog entries the given plugins added.
> There could be something like register_validator() and
> unregister_validator() whose argument would be a pointer to the
> validator function. Geany would keep a list of these pointers and run
> all the functions to see if everything is valid before it sends the
> above signal. The functions could also return some error string used
> by a pop up error dialog. As I said, I don't need it but could be
> added when some plugin requires such a functionality.
This is a good idea that needs to be addressed as part of an overall
discussion of how plugins integrate with Geany. I guess when everyone
gets some time :-(.
More information about the Devel