[Gambas-user] I added "External Tools" to my gambas :)

[bb]

On Thu, 2022-01-27 at 22:57 +0100, Benoît Minisini wrote:
>  (Snipped. In reply to BruceS proposed approach)
> 
> Hi,
> 
> I'm not against the principle, but the implementation.
> 
> I have already thought about that in the past, and I would prefer
> having 
> IDE plugins written in Gambas, not in bash.
> 
> The plugins could be external Gambas executables / scripts, or Gambas
> libraries that would run in-process.
> 
> The former would work through an API, i.e. a class exported by the
> IDE. 
> It is more "dangerous" for the IDE, but it would work faster, and
> would 
> give plugins more power, that power being limited by the exported
> API.
> 
> Now there are different kind of plugins :
> 
> - Project-wide plugins: they modify the entire project, or some files
> of 
> the project. For example, optimizing all the PNG files of a project, 
> cleaning the project...
> 
> - Plugins that work with a specific file (source code file, form
> file, 
> text file, image file...). Plugin that run on a text file or a source
> code file may act only on the current selection ; plugin that run on
> an 
> image may act only on the current selection...
> 
> - Plugins that run something else, using the project as a read-only 
> souce. For example, counting the number of lines of code.
> 
> A plugin library may have a specific form that would be used for 
> configuring the plugin. That form may be embedded in a global IDE
> dialog 
> with the configuration forms of all other plugins.
> 
> Project-wide plugins will be associated with an action, a icon, and a
> menu entry that will be inserted in the global toolbar and inside a 
> specific global menu.
> 
> Editor-wide plugins will be associated with an action and a icon that
> would be inserted in the editor toolbar, and a menu entry that will
> be 
> inserted in the editor specific popup-menu.
> 
> Some text file inside the plugin archive will describe the plugin 
> contents for the IDE.
> 
> Note that at the moment Gambas does not know how to unload a library.
> So 
> disabling a plugin would release the memory only on next launch.
> 
> These plugins libraries will be installed in specific directories
> like 
> '/usr/share/gambas3/ide-plugins' or '~/.local/share/gambas3/ide-
> plugins'.
> 
> What do you think?
> 
Indeed!

I did try to achieve something like this some years ago with limited
success (and the source is long gone).

Two problems that I recall I encountered were:

1. "Locking" the IDE such that you couldn't say start a plugin, flip
back to the IDE and start another. That may create a conflict should
they both update the project or its' contents. Then again you may want
to have one or more read-only plugins monitoring the project in the
background. 

2. Whether or not to automatically save the project before invoking the
plugin. Consider this example. I am working on a library project and
suddenly think the changes I am making may adversely affect the
projects that use this library. We have a third project that searches
for all projects that use a library i.e. a possible read-only plugin.
In that case I certainly don't want the current (library) project saved
automatically - I may want to revert some of or all the changes I have
been making.

Another consideration is callbacks to the IDE from within the plugin. I
don't know whether that could be possible at all but one instance that
I considered unsuccessfully was where the entire project is "modified"
externally by the plugin, say it runs some git that results in the IDE
image of the project being "incorrect". What I tried to achieve without
real success was a way to signal back to the IDE that its' view of the
project was "dirty" and a reload was necessary.  

Anyway that's just a few thoughts.
b