I originally started programming on a Borland IDE, which allowed me to place my projects files into a tree that was independent of their layout on disk.
I became so attached to it, I helped reimplement similar functionality for SciTE (scitepm).
(I'm not sure whether the attached picture will show up, but it illustrates how I like to group, say the 'cloud' functionality together in a web project, even though the elements of that functionality lie in 'templates', ' static/js', 'static/css', etc)
However, apparently SciTE isn't being updated in my distribution (Fedora), and it would be better to have this functionality embedded in something with forward motion - like Geany.
The functions that this would include are : a) Do a search upwards from the current directory for a suitable '.geany/tree-project.conf' b) Load a tree of files from some YAML-like format on disk, and put them in a side-bar tab c) Allow this tree to be edited (new sub-groups, add a file, delete a file, etc) d) Save tree to disk (typically this wouldn't change much once a project had stabilised - so the file could be put in git, for instance). This wouldn't include 'currently open' indicators, since they're more volatile. e) That's about it : Other tools look like they're already doing a great job for file searching, etc.
If this already exists, please let me know : I don't want to reinvent the wheel.
All the Best Martin :-)
PS: tree-browser in current git looks like a good launching-off point, structure-wise
On 17 April 2014 00:34, Martin Andrews Martin.Andrews@redcatlabs.com wrote:
I originally started programming on a Borland IDE, which allowed me to place my projects files into a tree that was independent of their layout on disk.
I became so attached to it, I helped reimplement similar functionality for SciTE (scitepm).
(I'm not sure whether the attached picture will show up, but it illustrates how I like to group, say the 'cloud' functionality together in a web project, even though the elements of that functionality lie in 'templates', ' static/js', 'static/css', etc)
However, apparently SciTE isn't being updated in my distribution (Fedora), and it would be better to have this functionality embedded in something with forward motion - like Geany.
The functions that this would include are : a) Do a search upwards from the current directory for a suitable '.geany/tree-project.conf' b) Load a tree of files from some YAML-like format on disk, and put them in a side-bar tab c) Allow this tree to be edited (new sub-groups, add a file, delete a file, etc) d) Save tree to disk (typically this wouldn't change much once a project had stabilised - so the file could be put in git, for instance). This wouldn't include 'currently open' indicators, since they're more volatile. e) That's about it : Other tools look like they're already doing a great job for file searching, etc.
If this already exists, please let me know : I don't want to reinvent the wheel.
Have you looked at the two existing project plugins, Geanyprj and GProject and do they do what you want.
Cheers Lex
All the Best Martin :-)
PS: tree-browser in current git looks like a good launching-off point, structure-wise
Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
Am 17.04.2014 02:42, schrieb Lex Trotman:
On 17 April 2014 00:34, Martin Andrews Martin.Andrews@redcatlabs.com wrote:
I originally started programming on a Borland IDE, which allowed me to place my projects files into a tree that was independent of their layout on disk.
I became so attached to it, I helped reimplement similar functionality for SciTE (scitepm).
(I'm not sure whether the attached picture will show up, but it illustrates how I like to group, say the 'cloud' functionality together in a web project, even though the elements of that functionality lie in 'templates', ' static/js', 'static/css', etc)
However, apparently SciTE isn't being updated in my distribution (Fedora), and it would be better to have this functionality embedded in something with forward motion - like Geany.
The functions that this would include are : a) Do a search upwards from the current directory for a suitable '.geany/tree-project.conf' b) Load a tree of files from some YAML-like format on disk, and put them in a side-bar tab c) Allow this tree to be edited (new sub-groups, add a file, delete a file, etc) d) Save tree to disk (typically this wouldn't change much once a project had stabilised - so the file could be put in git, for instance). This wouldn't include 'currently open' indicators, since they're more volatile. e) That's about it : Other tools look like they're already doing a great job for file searching, etc.
If this already exists, please let me know : I don't want to reinvent the wheel.
Have you looked at the two existing project plugins, Geanyprj and GProject and do they do what you want.
Not sure whether one of them can be used as basis -- but ... I think a lot of peob´ple hoping of some extensions of plugin project functions.
Cheers, Frank
[...]
If this already exists, please let me know : I don't want to reinvent the wheel.
Have you looked at the two existing project plugins, Geanyprj and GProject and do they do what you want.
Not sure whether one of them can be used as basis -- but ... I think a lot of peob´ple hoping of some extensions of plugin project functions.
I should have phrased my question: "How much of what you want do these plugins already do."
If they do some/much of your requirements then, as Frank notes, they may provide a more suitable basis for further expansion than starting with a plain treebrowser.
Cheers Lex
Cheers, Frank _______________________________________________ Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
You can add a third to that list :)
https://code.launchpad.net/~oly/geany-project-manager/trunk
I am still working on it but not pushed for a while, currently implementing browser and database functionality to it, very slowly i will add.
I can push up a newer version if anyone want to try it out and take a look.
Scrrenshot here https://plus.google.com/108080448324780364479/posts/G5FSHhPg8sQ
On Thu, Apr 17, 2014 at 10:42 AM, Lex Trotman elextr@gmail.com wrote:
[...]
If this already exists, please let me know : I don't want to reinvent
the
wheel.
Have you looked at the two existing project plugins, Geanyprj and GProject and do they do what you want.
Not sure whether one of them can be used as basis -- but ... I think a lot of peob´ple hoping of some extensions of plugin project functions.
I should have phrased my question: "How much of what you want do these plugins already do."
If they do some/much of your requirements then, as Frank notes, they may provide a more suitable basis for further expansion than starting with a plain treebrowser.
Cheers Lex
Cheers, Frank _______________________________________________ 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
On 17 April 2014 20:32, Oly olymk2@gmail.com wrote:
You can add a third to that list :)
https://code.launchpad.net/~oly/geany-project-manager/trunk
I am still working on it but not pushed for a while, currently implementing browser and database functionality to it, very slowly i will add.
I can push up a newer version if anyone want to try it out and take a look.
Scrrenshot here https://plus.google.com/108080448324780364479/posts/G5FSHhPg8sQ
Oh my, a Python plugin :)
Cheers Lex
[...]
yeah, i also have a snippet plugin and a python code checker plugin on my launchpad and there is a ppa for them as well, i am just not that good at promoting them, i just use them for work :)
On Thu, Apr 17, 2014 at 11:55 AM, Lex Trotman elextr@gmail.com wrote:
On 17 April 2014 20:32, Oly olymk2@gmail.com wrote:
You can add a third to that list :)
https://code.launchpad.net/~oly/geany-project-manager/trunk
I am still working on it but not pushed for a while, currently
implementing
browser and database functionality to it, very slowly i will add.
I can push up a newer version if anyone want to try it out and take a
look.
Scrrenshot here https://plus.google.com/108080448324780364479/posts/G5FSHhPg8sQ
Oh my, a Python plugin :)
Cheers Lex
[...] _______________________________________________ Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
Am 17.04.2014 12:59, schrieb Oly:
yeah, i also have a snippet plugin and a python code checker plugin on my launchpad and there is a ppa for them as well, i am just not that good at promoting them, i just use them for work :)
Maybe you can spread it a little? Maybe we could add at least some to g-p project? Matthew ... how would be the best way doing this btw?
Cheers, Frank
On 17 April 2014 21:17, Frank Lanitz frank@frank.uvena.de wrote:
Am 17.04.2014 12:59, schrieb Oly:
yeah, i also have a snippet plugin and a python code checker plugin on my launchpad and there is a ppa for them as well, i am just not that good at promoting them, i just use them for work :)
Maybe you can spread it a little? Maybe we could add at least some to g-p project? Matthew ... how would be the best way doing this btw?
I just said to Oly on IRC:
Frank would get heartburn trying to figure out how to manage Geanypy plugins in geany-plugins :)
Cheers Lex
Cheers, Frank _______________________________________________ Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
Am 17.04.2014 13:40, schrieb Lex Trotman:
On 17 April 2014 21:17, Frank Lanitz frank@frank.uvena.de wrote:
Am 17.04.2014 12:59, schrieb Oly:
yeah, i also have a snippet plugin and a python code checker plugin on my launchpad and there is a ppa for them as well, i am just not that good at promoting them, i just use them for work :)
Maybe you can spread it a little? Maybe we could add at least some to g-p project? Matthew ... how would be the best way doing this btw?
I just said to Oly on IRC:
Frank would get heartburn trying to figure out how to manage Geanypy plugins in geany-plugins :)
;)
Well.... yepp... Maybe not direct ading to geany-plugins, but having a good way to distribute them. I think _RPG_ was also asking for something like that earlier.
Cheers, Frank
Sorry to follow up (late) to your first email.
Regarding functionality, I've looked at geanyprj and gproject, and neither do what I'm thinking exactly :
gproject : The files are viewed in a nice tree, however that tree reflects the disk layout, rather than functional groups. And attempting to pull in just a few files would result in an ultra-ugly 'filter'.
geanyprj : (With autofill files off) Looks promising, except that list of user-chosen files is just linear. Perhaps this would be the easier one to pop a tree-view into, and still have it loading existing project files in a compatible way
djynn : This looks very promising, however, the author made a breaking change in the source tree last year, and (even though I've now got a version that compiles cleanly) there are some seg-faulting issues that make it too difficult to put through its paces enough to see. It also appears to be pretty unwelcoming code-wise.
So: As it stands, enhancing geanyprj seems like it could be decent approach. Or forking it, since it's overview makes it sound as if its purpose is to dip into lots of projects/codebases, rather than enable good organization of a single project (and context changes, if opened in a different base directory)
Hope this makes sense Martin :-)
PS: But doing this in Python is a lot more appealing than C... But I can see the packaging issues may outweigh the convenience.
On 17 April 2014 19:43, Frank Lanitz frank@frank.uvena.de wrote:
Am 17.04.2014 13:40, schrieb Lex Trotman:
On 17 April 2014 21:17, Frank Lanitz frank@frank.uvena.de wrote:
Am 17.04.2014 12:59, schrieb Oly:
yeah, i also have a snippet plugin and a python code checker plugin on
my
launchpad and there is a ppa for them as well, i am just not that good
at
promoting them, i just use them for work :)
Maybe you can spread it a little? Maybe we could add at least some to g-p project? Matthew ... how would be the best way doing this btw?
I just said to Oly on IRC:
Frank would get heartburn trying to figure out how to manage Geanypy plugins in geany-plugins :)
;)
Well.... yepp... Maybe not direct ading to geany-plugins, but having a good way to distribute them. I think _RPG_ was also asking for something like that earlier.
Cheers, Frank _______________________________________________ Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
[...]
So: As it stands, enhancing geanyprj seems like it could be decent approach. Or forking it, since it's overview makes it sound as if its purpose is to dip into lots of projects/codebases, rather than enable good organization of a single project (and context changes, if opened in a different base directory)
Hope this makes sense Martin :-)
PS: But doing this in Python is a lot more appealing than C... But I can see the packaging issues may outweigh the convenience.
If you don't use one of the existing C plugins as a base, then don't let the questions over Python plugins put you off using it, you don't need to care until (if) you are ready to release it to the geany-plugins. Hopefully we will have gotten our ducks in a row by by that time :)
Also consider you could write plugins in Cython, which to my mind allows the best of both worlds, C and Python, and (untested) Python3. Or you can use C++ for plugins, or Vala.
So you now have too many choices :)
Cheers Lex
On 14-04-17 12:25 PM, Martin Andrews wrote:
Sorry to follow up (late) to your first email.
Regarding functionality, I've looked at geanyprj and gproject, and neither do what I'm thinking exactly :
gproject : The files are viewed in a nice tree, however that tree reflects the disk layout, rather than functional groups. And attempting to pull in just a few files would result in an ultra-ugly 'filter'.
geanyprj : (With autofill files off) Looks promising, except that list of user-chosen files is just linear. Perhaps this would be the easier one to pop a tree-view into, and still have it loading existing project files in a compatible way
djynn : This looks very promising, however, the author made a breaking change in the source tree last year, and (even though I've now got a version that compiles cleanly) there are some seg-faulting issues that make it too difficult to put through its paces enough to see. It also appears to be pretty unwelcoming code-wise.
So: As it stands, enhancing geanyprj seems like it could be decent approach. Or forking it, since it's overview makes it sound as if its purpose is to dip into lots of projects/codebases, rather than enable good organization of a single project (and context changes, if opened in a different base directory)
Hope this makes sense Martin :-)
PS: But doing this in Python is a lot more appealing than C... But I can see the packaging issues may outweigh the convenience.
Packaging issues? Just drop the plugin script(s) into a particular directory and you're done :)
Cheers, Matthew Brush
On 14-04-17 04:43 AM, Frank Lanitz wrote:
Am 17.04.2014 13:40, schrieb Lex Trotman:
On 17 April 2014 21:17, Frank Lanitz frank@frank.uvena.de wrote:
Am 17.04.2014 12:59, schrieb Oly:
yeah, i also have a snippet plugin and a python code checker plugin on my launchpad and there is a ppa for them as well, i am just not that good at promoting them, i just use them for work :)
Maybe you can spread it a little? Maybe we could add at least some to g-p project? Matthew ... how would be the best way doing this btw?
I just said to Oly on IRC:
Frank would get heartburn trying to figure out how to manage Geanypy plugins in geany-plugins :)
;)
Well.... yepp... Maybe not direct ading to geany-plugins, but having a good way to distribute them. I think _RPG_ was also asking for something like that earlier.
Autotools has support for Python built-in, likely all that's needed is to somehow declare a dependency in the make file that each Python plugin depends on libgeanypy.la.
In normal Automake, it might look like this for a plugin "foo":
fooplugin_PYTHON = foo.py bar.py etc.py fooplugindir = $(pkgdatadir)/geanypy/plugins #fooplugin_LDADD = $(top_builddir)/geanypy/src/libgeanypy.la
I'm not sure about the last line, but presumably there's a way in Automake to say "these files depend on that other file, install them both".
Cheers, Matthew Brush
Am 17.04.2014 13:40, schrieb Lex Trotman:
On 17 April 2014 21:17, Frank Lanitz frank@frank.uvena.de wrote:
Am 17.04.2014 12:59, schrieb Oly:
yeah, i also have a snippet plugin and a python code checker plugin on my launchpad and there is a ppa for them as well, i am just not that good at promoting them, i just use them for work :)
Maybe you can spread it a little? Maybe we could add at least some to g-p project? Matthew ... how would be the best way doing this btw?
I just said to Oly on IRC:
Frank would get heartburn trying to figure out how to manage Geanypy plugins in geany-plugins :)
Cheers Lex
The root problem is that geanypy is a plugin at all!
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.
Best regards
[...]
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
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@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
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@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@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
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 olymk2@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@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@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
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@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@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@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
Hi everyone,
I am a new member of the community. I am a computer science student. In one of my courses I need to contribute to an open source project. I have selected geany project to work on. I want to start with a simple problem. Can anyone suggest how can I get started?
Oly :
If your geany-project-manager has its own 'tree-view' (as in the screen-shot), then that may be perfect for me to tinker with ...
The browser & database stuff (while very interesting) isn't on my critical list : All the same, could you do a push of your latest code (assuming that it least doesn't crash!).
Then I can have a nose around the side-bar stuff (and still stay close enough to your code to enable a re-merge later, if it makes sense).
On the packaging side, it would be great to have the incentive of getting something onto the standard packaging system, since then it becomes a simpler (more incremental) task to 'stay current' with geany, and not get left behind (as happened with my previous SciTE dependency).
Martin :-)
On 17 April 2014 18:32, Oly olymk2@gmail.com wrote:
You can add a third to that list :)
https://code.launchpad.net/~oly/geany-project-manager/trunk
I am still working on it but not pushed for a while, currently implementing browser and database functionality to it, very slowly i will add.
I can push up a newer version if anyone want to try it out and take a look.
Scrrenshot here https://plus.google.com/108080448324780364479/posts/G5FSHhPg8sQ
On Thu, Apr 17, 2014 at 10:42 AM, Lex Trotman elextr@gmail.com wrote:
[...]
If this already exists, please let me know : I don't want to reinvent
the
wheel.
Have you looked at the two existing project plugins, Geanyprj and GProject and do they do what you want.
Not sure whether one of them can be used as basis -- but ... I think a lot of peob´ple hoping of some extensions of plugin project functions.
I should have phrased my question: "How much of what you want do these plugins already do."
If they do some/much of your requirements then, as Frank notes, they may provide a more suitable basis for further expansion than starting with a plain treebrowser.
Cheers Lex
Cheers, Frank _______________________________________________ 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
[...]
On the packaging side, it would be great to have the incentive of getting something onto the standard packaging system, since then it becomes a simpler (more incremental) task to 'stay current' with geany, and not get left behind (as happened with my previous SciTE dependency).
To make sure you don't have incorrect expectations let me explain.
Geany-Plugins is a separate project from Geany providing a collection of plugins. Although some of its plugins are made by Geany developers, and it tries to synchronise releases with Geany for user convenience, the plugins are not supported by the Geany project or the Geany-Plugins project. You will still have to maintain any plugin that is part of the collection yourself (or get someone to volunteer for you). And being part of the collection means there is an extra step to that maintenance, beyond just having it in your own github, as you need to submit pull requests to the collection.
Plugins that are not maintained are considered orphaned, and may be removed from the collection. (Well, that threat has not been carried out ... yet :)
Of course being part of the Geany-Plugins collection means you *might* get more contributors than you would just on github, but you *will* get more feature demands, bug reports, complaints etc all of which have to be dealt with. If you would have trouble staying 'current' when your plugin is not in the Geany-Plugins collection, you will have more trouble if your plugin is in the collection, because there is more to do. Of course having other people using your plugin may provide you with an incentive you need.
Initially you may be better off just using github and getting yourself listed on the "Third Party" list on the plugins website.
Cheers Lex
Martin :-)
[...]
I would like to get some of my plugins into the main plugin list, perhaps i could create a pull request for one and we can use it as a test, i dont mind supporting it and fixing bugs the only part i dont really know anything about is the automake side of things.
I will perhaps push the python code checker, its reasonably small / simple plugin.
also not sure how you sort out dependency issues when its not packaged.
martin I will push the code for my project view sometime this weekend, got a few things on so not sure when i will get a minute.
On Fri, Apr 18, 2014 at 6:32 AM, Lex Trotman elextr@gmail.com wrote:
[...]
On the packaging side, it would be great to have the incentive of getting something onto the standard packaging system, since then it becomes a simpler (more incremental) task to 'stay current' with geany, and not get left behind (as happened with my previous SciTE dependency).
To make sure you don't have incorrect expectations let me explain.
Geany-Plugins is a separate project from Geany providing a collection of plugins. Although some of its plugins are made by Geany developers, and it tries to synchronise releases with Geany for user convenience, the plugins are not supported by the Geany project or the Geany-Plugins project. You will still have to maintain any plugin that is part of the collection yourself (or get someone to volunteer for you). And being part of the collection means there is an extra step to that maintenance, beyond just having it in your own github, as you need to submit pull requests to the collection.
Plugins that are not maintained are considered orphaned, and may be removed from the collection. (Well, that threat has not been carried out ... yet :)
Of course being part of the Geany-Plugins collection means you *might* get more contributors than you would just on github, but you *will* get more feature demands, bug reports, complaints etc all of which have to be dealt with. If you would have trouble staying 'current' when your plugin is not in the Geany-Plugins collection, you will have more trouble if your plugin is in the collection, because there is more to do. Of course having other people using your plugin may provide you with an incentive you need.
Initially you may be better off just using github and getting yourself listed on the "Third Party" list on the plugins website.
Cheers Lex
Martin :-)
[...]
Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
martin I will push the code for my project view sometime this weekend,
got a few things on so not sure when i will get a minute.
Oly : Thank you - I've just installed the geanypy from upstream ( https://github.com/codebrainz/geanypy) to play with.
Lex : For the "packaging issues" : I understand that having a plugin as part of the geany-plugins ecosystem is no walk-in-the-park. On the other hand, it's definitely good to know that other people can make use of what one is building - even if that means having to stay on top of things if there are breaking changes in APIs, etc (or indeed, good patches, bug reports or ideas submitted). I agree that starting off 'third party' may be a good idea, although it would make sense to structure the package so that it could be dropped into the main tree relatively painlessly, later.
Cross-fingers I can make sense of the Pythonic interface : It would be great not to have to do a ton of string/tree manipulation in C.
Best Wishes Martin :-)
On 18 April 2014 15:10, Oly olymk2@gmail.com wrote:
I would like to get some of my plugins into the main plugin list, perhaps i could create a pull request for one and we can use it as a test, i dont mind supporting it and fixing bugs the only part i dont really know anything about is the automake side of things.
I will perhaps push the python code checker, its reasonably small / simple plugin.
also not sure how you sort out dependency issues when its not packaged.
martin I will push the code for my project view sometime this weekend, got a few things on so not sure when i will get a minute.
On Fri, Apr 18, 2014 at 6:32 AM, Lex Trotman elextr@gmail.com wrote:
[...]
On the packaging side, it would be great to have the incentive of
getting
something onto the standard packaging system, since then it becomes a simpler (more incremental) task to 'stay current' with geany, and not
get
left behind (as happened with my previous SciTE dependency).
To make sure you don't have incorrect expectations let me explain.
Geany-Plugins is a separate project from Geany providing a collection of plugins. Although some of its plugins are made by Geany developers, and it tries to synchronise releases with Geany for user convenience, the plugins are not supported by the Geany project or the Geany-Plugins project. You will still have to maintain any plugin that is part of the collection yourself (or get someone to volunteer for you). And being part of the collection means there is an extra step to that maintenance, beyond just having it in your own github, as you need to submit pull requests to the collection.
Plugins that are not maintained are considered orphaned, and may be removed from the collection. (Well, that threat has not been carried out ... yet :)
Of course being part of the Geany-Plugins collection means you *might* get more contributors than you would just on github, but you *will* get more feature demands, bug reports, complaints etc all of which have to be dealt with. If you would have trouble staying 'current' when your plugin is not in the Geany-Plugins collection, you will have more trouble if your plugin is in the collection, because there is more to do. Of course having other people using your plugin may provide you with an incentive you need.
Initially you may be better off just using github and getting yourself listed on the "Third Party" list on the plugins website.
Cheers Lex
Martin :-)
[...]
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
