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

[Martin Andrews]

Here's a quick screen-shot of how the up-coming project-tree python plugin
looks.  There's a popup (that's difficult to screenshot) to allow the
addition of new groups, and the currently edited file.  The tree doesn't
necessarily have the same structure as the folders on disk (that's handled
very well by other tools) - but I prefer to keep files thematically.  YMMV

Martin
:-)


On 24 April 2014 16:34, Oly <olymk2 at gmail.com> wrote:

> 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
>>>
>>
>>
>
> _______________________________________________
> 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/20140428/be090a9f/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ProjectTree_Screenshot - 04282014 - 01:00:02 PM.png
Type: image/png
Size: 86756 bytes
Desc: not available
URL: <http://lists.geany.org/pipermail/devel/attachments/20140428/be090a9f/attachment-0001.png>