[Gambas-user] IDE extensions?

[Benoît Minisini]

Le 18/09/2016 à 10:16, Adrien Prokopowicz a écrit :
> Le Sat, 17 Sep 2016 23:09:02 +0200, Benoît Minisini
> <gambas at ...1...> a écrit:
>
>> Hi,
>>
>> Would people be interested in some sort of IDE extensions?
>>
>> The idea is making a dedicated tag in the software farm for IDE
>> extensions.
>>
>> Then, once installed, the extension program is automatically detected by
>> the IDE.
>>
>> Then a menu entry will be added in the IDE.
>>
>> When the user clicks on that menu entry, the extension program is run.
>> It will receive the project path in its argument, and eventually other
>> informations: the current edited file for example, or whatever else is
>> needed.
>>
>> This is the principle.
>>
>> If anymone is interested in something like that, please tell.
>>
>> Regards,
>>
>
> I like the idea a lot, so i'll add my two cents to the discussion. :-)
>
> First, I like the idea of using the Software Farm for extensions/plugins.
> However, I think it would be nice to have some kind of shortcut
> (like Options > IDE Extensions …), because going to the Software Farm
> itself isn't very intuitive when you are looking for plugins to install.
>
> The thing that feels a bit wierd to me, is the implementation itself.
> While it is the simplest, having only a menu entry and an executable
> being run is very restrictive.
> The extension program would have no access to the IDE's state
> whatsoever, and would have little to no information about the open project.
>
> With this design, the only things that I can see being implemented are
> programs being run in the current project directory, and running a single
> background task, or opening a big pop-up window, because the extension
> would need to be completely external.
> Therefore, I think the extension should have access to some of the IDE's
> classes (the exported ones).
>
> However, I've noticed that there are quite a bit of Gambas projects
> out there, that could be/are using some sort of plugins like this, not
> only the IDE.
>
> Currently, in order to to something like this, you have to mess with
> Component.Load(), have the plugin to export some classes, and have the
> main application to use some dynamic introspection to fetch some
> specific method, and run it. All of this already looks like some
> stange voodoo magic.
>
> Moreover, you cannot directly access the exported Classes from the
> plugin's project, because the compiler doesn't know them.
> You would have to access them at runtime only, using dynamic introspection,
> which is just terrible at this point.
>
> My point is: I would really like to have a nice, standard way for adding
> plugins to Gambas applications, maybe through a component or something.
> It would therefore not only be ridiculously easy to add simple plugins
> to the IDE (while still allowing to make it evolve and add more features
> later), but also for any Gambas application that wants it. :-)
>
> I've been thinking about something like this for quite some time actually,
> and your message raised interest about this to me again.
>
> Here are the ideas that I came up with, please tell me what you think! :-)
> (This is purely in my head, there are probably some things that I missed.
> I am just pasting all the ideas I have, I apologize for the long post.)
>
> In order to easily implement plugins like I described above, two things
> are necessary:
> - The ability for the application to load plugins from archive files, and
>    then run a specific method (most likely Main() ).
> - The ability for the plugin to access the application's exported classes,
>    which would basically form an API to let the plugin do anything it wants
>    (like adding menu entries, extra docks/windows, registering to events...)
>
> For the first one, I think a simple static method like Plugin.Load(file)
> should suffice. It could maybe return a Plugin object with some metadata
> about the plugin file (version, authors, …), but that's just extra.
> It might be tricky to access the Main() method of the plugin without it
> being exported (I don't think it's possible from pure Gambas code), but
> the interpeter itself should be able to do this without any problem.
>
> The second part may be tricky, as both the compiler and the IDE need
> information they currently don't have.
>
> To me, the ideal workflow for a plugin maker would be the following:
> - Creating a plugin project,
> - Selecting the application I want to create the plugin for,
> - All the exported classes from the application are loaded by the
>    IDE (for autocompletion/documentation), and by the compiler
>    (for … compiling, I guess).
> - (Maybe) Hitting the run button will run the app with the plugin
>    loaded, allowing for quick testing iterations.
>
> I'm not sure about the last part, as it would not be possible with
> manual plugin loading like a Plugin.Load() method, so another solution
> should be found there (if any).
>
> In order for the rest to work, the compiler and the IDE would need to read
> external info files from a specific target. Info files can be generated
> easily from source project, and I think you can extract them from
> executable archives (not sure about this one) ?
> I think the nicest way to do this is to create a separate "plugin" project
> type, with an extra parameter to inform the compiler about the targeted
> application, which could then be used by the IDE.
>
> I think that's all I have. It sure is much more complex than your
> proposition Benoît, but I think it is much more interesting on the
> long-run.
>
> Again, sorry for the long post, and I would love to hear you on this. :-)
>
> Regards,
>


I understand your point of view, but :

- I don't want people to say that the IDE is unstable because of a bug 
in an extension.

- I don't want to debug the extensions made by other people.

So the design I described is the simplest I could find. That way a bug 
in an extension is clearly identified, both by the developper and the 
user. Moreover, the interface between the IDE and the extension being 
minimal, the backward-compatibility is easier to achieve.

Anyway, it's better to start with something very simple, and enhance the 
concept progressively, according to what extensions are developed.

Regards,

-- 
Benoît Minisini