[Geany-devel] GProject - the second attempt

[Jiří Techet]

On Fri, Jul 9, 2010 at 03:37, Lex Trotman <elextr at gmail.com> wrote:
> Hi Jiri
>
>
>>>>     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
>> active.
>>
>> 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.

On the other hand, we could easily overdo it with plugin API
generality. Geany should definitely not become Eclipse written in C.
In my opinion the current approach of introducing API functions on
demand is alright. The amount of things the plugins can already do is
satisfactory for most of the plugins I guess. My plugin is a bit
exceptional in being the first plugin that extends the project
management of geany and therefore needs some extra functions and
signals for that (not so many though, most of the patches are just
general geany improvements). And talking about every single additional
API function with geany developers is good in the sense that the given
function is considered from more viewpoints and sufficient brain time
is spent before introducing a possibly nonsense function into the API.
Also introducing API functions in advance can cause that these
functions are poorly tested because there's nothing that uses them. I
also like that the API is restrictive a bit - plugins shouldn't be
able to modify geany completely so it becomes a different editor -
they should just extend it in a certain way.

But I don't have anything against looking at how others do it - there
are surely good (and bad) lessons we can learn. If I should say a
single thing I dislike about how plugins are implemented in geany (and
there's actually only this single complaint), it is the fact that by
including geanyplugin.h I also include lots of function prototypes
that don't belong to the API. It happened to me several times that I
copied some code from geany into my plugin, compiled it without any
problem, but then the plugin didn't load because the function I used
was not a part of the API. Some macros or whatever should be used to
prevent non-API functions and data structures from being included by
the plugins.

Cheers,

Jiri

>
>
>> 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 :-(.
>
>>
>
> Cheers
> Lex
> _______________________________________________
> Geany-devel mailing list
> Geany-devel at uvena.de
> http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
>