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