[Geany-Devel] Any votes for a "Project-Tree" plugin?
olymk2 at xxxxx
Thu Apr 24 08:34:44 UTC 2014
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,
>> 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
>> > 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.
>> > 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 :)
>> > 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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Devel