Discussion:
IDE extensions?
(too old to reply)
Benoît Minisini
2016-09-17 21:09:02 UTC
Permalink
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,
--
Benoît Minisini

------------------------------------------------------------------------------
Adrien Prokopowicz
2016-09-18 08:16:25 UTC
Permalink
Le Sat, 17 Sep 2016 23:09:02 +0200, Benoît Minisini
Post by Benoît Minisini
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

------------------------------------------------------------------------------
Benoît Minisini
2016-09-18 13:41:32 UTC
Permalink
Post by Adrien Prokopowicz
Le Sat, 17 Sep 2016 23:09:02 +0200, Benoît Minisini
Post by Benoît Minisini
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
- 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.
- 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

------------------------------------------------------------------------------
Jussi Lahtinen
2016-09-18 14:39:13 UTC
Permalink
I have no opinion for or against. But what would the extensions do? I think
the IDE pretty much have all the possible useful things..?
I guess something special without general usage. I would be interested in
hearing some ideas.


Jussi

On Sun, Sep 18, 2016 at 12:09 AM, Benoît Minisini <
Post by Benoît Minisini
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,
--
Benoît Minisini
------------------------------------------------------------
------------------
_______________________________________________
Gambas-user mailing list
https://lists.sourceforge.net/lists/listinfo/gambas-user
------------------------------------------------------------------------------
a***@gmail.com
2016-09-20 23:57:28 UTC
Permalink
On Sun, 18 Sep 2016 17:39:13 +0300
Post by Jussi Lahtinen
I have no opinion for or against. But what would the extensions do? I think
the IDE pretty much have all the possible useful things..?
I guess something special without general usage. I would be interested in
hearing some ideas.
Jussi
Here's a few we have already (not farm produce though).

A class skeleton code builder/rebuilder. It parses a class and allows visual addition/modification/deletion of properties, methods, etc. It doesn't provide or allow for editing for actual procedural code but does build code for accessors and some other mechanical procedures (such as skeleton code for initialising the class infrastructure in the constructor. (It also reformats the code so that all procedures are layed out in groups: public, private, (some other mechanicals we use), accessors, handlers.)

A form reviewer: This utility provides a means to review a Gambas3 form definition file highlighting missing features (tooltips etc) and duplicated features (shortcuts and accelerators). It is meant to assist in checking that all the useability factors of a form in a project have been completed properly before releasing the containing project.

A library component installation manager: This project:
* displays information about gambas <b>applications, libraries and components</b> that are either installed on the local computer or which have installable packages,
* highlights packages that have been superseeded (i.e. there is a later package version available),
* provides a mechanism to install specific package versions on the local computer.

A task manager: Simple, "emphasis" on simple, to do list for gambas projects - just what the world needs, another todo list! :-)

A tool to "generate a procedure to handle command line arguments suitable for the gb.args component."

Several other code generators suitable only for the way we "do things" here.


So I for one would prefer to see that there was no forced dependency on the farm. i.e. allow for locally installed tools. In fact, given the current state of versioning in the farm using a shared extension would leave the client developer at the whim of the extension developer. Suppose version 1.2 of an extension is the one I want to use even thought there is a version 3.6 available?

(in fact back in gambas2 days we had modified the IDE to allow for such extensions (I called them "AddIns"). It was fairly simple to implement in the gb2 IDE code and provided almost all of what Benoit mentioned (passing the project context, current class etc) and also had it's own "manager" to allow for adding/removing/activating/deactivating specific addins.

bruce
--
B Bruen <***@gnail.com (sort of)>

------------------------------------------------------------------------------
Christof Thalhofer
2016-09-20 13:44:42 UTC
Permalink
Hello,
Post by Benoît Minisini
Would people be interested in some sort of IDE extensions?
Yes.
Post by Benoît Minisini
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.
I'm currently writing a project for unittesting for Gambas, it is
inspired from http://comunit.sourceforge.net/ and PHPUnit. I would like
to share it on GitHub and if the quality is ok and you agree, name it
"GUnit" or "GbUnit" or so and share it with the Gambas community.

At the moment I am unsure, whether to make a library or a component with it.

This could eventually be a nice candidate for an IDE extension. But I
would like to invoke it by keyboard shortcut, because it would be
something one uses nearly as often as "F5" if one does test driven
programming.

Also it could be an integrated part of the IDE (like profiling) because
it has to run inside the project it has to test. It could be a component
and if a project uses this component, the IDE could recognize it and
runs it by keyboard shortcut.


Alles Gute

Christof Thalhofer
--
Dies ist keine Signatur
Continue reading on narkive:
Loading...