Le Sat, 17 Sep 2016 23:09:02 +0200, Benoît Minisini <gam...@users.sourceforge.net> a écrit:
Advertising
> 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, -- Adrien Prokopowicz ------------------------------------------------------------------------------ _______________________________________________ Gambas-user mailing list Gambas-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/gambas-user
