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

[Bruce Steers]

On Thu, 27 Jan 2022 at 21:58, Benoît Minisini <g4mba5 at gmail.com> wrote:

> Le 27/01/2022 à 06:34, Bruce Steers a écrit :
> >
> >
> > Right,, now i think it is more worthy your examination.
> >
> > i still have to give it a thorough debugging but the structure is now
> > complete.
> >
> > What i could do with knowing (probably changing) is how i have
> > integrated it to the IDE.  I should imagine your understanding of it all
> > has a much better way to properly integrate it.
> >
> > But i'm border-line offering it for a merge request soon :)
> >
> > Branch.
> > https://gitlab.com/bsteers4/gambas/-/tree/External-Tools
> > <https://gitlab.com/bsteers4/gambas/-/tree/External-Tools>
> >
> > Snapshot.
> > https://forum.gambas.one/download/file.php?id=1018
> > <https://forum.gambas.one/download/file.php?id=1018>
> >
> > Respects
> > BruceS
> >
> > ----[ http://gambaswiki.org/wiki/doc/netiquette ]----
>
> 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?
>

i think that idea is great
I could probably add a shell script running plugin then ;)

But also that is going WAAAAY beyond my capabilities i think and my desire
to "mess" about with the IDE.
This is about as much "mess about with your IDE" as i dare to go ;)

I'm happy to put in some groundwork with this feature (making plugins) but
starting it off (the initial API) will have to be your doing as only you
will know how to integrate it all best.

I'm guessing a Plugin.class that will have the properties/configuration as
described above
like
 hPlugin.AllowFor = Plugin.Allow_Editor + Plugin.Allow_TextEditor +
Plugin.Allow_Form

maybe functions like
hPlugin.Get_FEditor() As FEditor
hPlugin.Get_FTextEditor() As FTextEditor
hPlugin.Get_FForm() As FForm

 to get full control of the editors and use any method / set any property

and stuff like...
Call a method from the Project.class
hPlugn.CallProjectMethod(Name As String, Arguments As Variant[]) as Variant

Hmm, or just hPlugin.GetProject() to access the Project.class

This could be easier than i thought.
I guess you just want the Plugin.class to be able to access the ide's main
classes and away we go....

Or is that too much freedom to cause problems and better to only add
certain safe methods?

As for my external tools addition i've put quite a bit of time into it and
am really digging the functionality of all these new options i have so i'm
going to keep it in my bruces-patched branch until i can do something
similar with plugins,
convert this External Tools mod to a plugin maybe? :)

It's like having advanced snippets, i always remember how overjoyed i was
when i discovered it in the Pluma editor, super useful to just knock up a
script to do a custom function on the doc :)

I've set it so Ctrl+Alt+E opens the tools manager and Ctrl+E triggers a
mnuExternalTools.PopUp at mouse pos  :)
That would be a consideration for the plugins too, a shortcut key to
launch.  i embedded my menu into the "Advanced" submenu and am already fed
up with hunting for it.  much easier to hit Ctrl+E :)

The operation halts if the script returns an error code.
it warns if no text is selected and you've used $GB_SELECTED
Various sanity checks.

Thanks for taking the time to look.
Respects
BruceS
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gambas-basic.org/pipermail/user/attachments/20220128/3c887c3f/attachment.htm>