Thanks for pushing the newer version. Actually, I've got a fair distance into rolling my own thing as a Python geany plugin in the meantime.
Unfortunately (for me) the majority of the week was spent battling with drag-and-drop functions for my specific tree thing. Grrr. On the plus side, it's now in a semi-usable state (for my needs) and I'll dog-food it for a week or so before I push up this part of my 'sketchpad' git repo to GitHub. The tree structure is saved/loaded from a .ini flat file reliably. As well as the project-tree stuff, there are interesting functions(!) in there to auto-generate a menubar (and popup) from specially named member functions (eg: '_menubar_0_File_2_SaveProject' creates a dropdown under a File heading with a SaveProject entry that calls that function). It saves a bunch of (very copy-pasty) time linking it up manually. All the Best Martin :-) On 24 April 2014 16:34, Oly <oly...@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 <oly...@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 <ele...@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@lists.geany.org >>> > https://lists.geany.org/cgi-bin/mailman/listinfo/devel >>> _______________________________________________ >>> Devel mailing list >>> Devel@lists.geany.org >>> https://lists.geany.org/cgi-bin/mailman/listinfo/devel >>> >> >> > > _______________________________________________ > Devel mailing list > Devel@lists.geany.org > https://lists.geany.org/cgi-bin/mailman/listinfo/devel > >
_______________________________________________ Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
