[Geany-Devel] Any votes for a "Project-Tree" plugin?

[Oly]

I have pushed a newer version, cleaned up the code quite a bit and put some
short comments in on what each method does, still plenty to clean up but
hopefully a bit easy to look out now.
I even fixed a few bugs :)


On Fri, Apr 18, 2014 at 9:56 AM, Oly <olymk2 at gmail.com> wrote:

> Martin i just pushed the code, only tested using geanypy in my repo which
> should be the latest, i think it pulls from git automatically and
> repackages it for me.
>
> i normally checkout the projects and symlink them into the geanypy folder,
> if you get stuck ping me on irc g+ or email with the error and I will do my
> best to help.
>
> also you need to add some project folders in the prefs, any sub folders to
> that path are considered a project and will create a geany.history file
> within the project and geany.project file.
>
>
>
> On Fri, Apr 18, 2014 at 9:50 AM, Lex Trotman <elextr at gmail.com> wrote:
>
>> [...]
>> >
>> >
>> >
>> > The root problem is that geanypy is a plugin at all!
>>
>> In the sense that being a plugin causes the restrictions you list below,
>> yes.
>>
>> But its only because the plugin interface does not contemplate the
>> situation of one plugin being a "proxy" for several others.
>>
>> Matthew did a great job making Geanypy within the restrictions of the
>> existing API.
>>
>> >
>> > The support for non-C plugins should be in the core as well, then Python
>> > (and others languages) plugins can be first-class-citizens in all
>> aspects
>> > that are problematic right now:
>> >  * Distribution within geany-plugins
>> >  * Adding Keybinding to geany
>> >  * Listing plugins
>> >
>> > Really, if the core is hesitant to large changes, then it should at
>> least do
>> > as best as possible to support plugins which implement these changes.
>> It's
>> > the core's job to provide the best experience for plugin developers.
>>
>> It would be better that the API be modified like this, so that
>> something like Geanypy could act as a proxy for other plugins (which
>> appear as "first class" plugins) and so a plugin can provide bindings
>> of the API in another language.
>>
>> This allows more languages to be added easily by anyone rather than
>> requiring changes to core for each language someone wants to use for
>> plugins.  (this might even solve the VAPI argument, just make it a
>> plugin, or more than one plugin if no agreement is reached :)
>>
>> Cheers
>> Lex
>>
>> >
>> > Best regards
>> >
>> > _______________________________________________
>> > Devel mailing list
>> > Devel at lists.geany.org
>> > https://lists.geany.org/cgi-bin/mailman/listinfo/devel
>> _______________________________________________
>> Devel mailing list
>> Devel at lists.geany.org
>> https://lists.geany.org/cgi-bin/mailman/listinfo/devel
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.geany.org/pipermail/devel/attachments/20140424/2275fcf2/attachment.html>