Emerald Editor Discussion
May 28, 2017, 09:36:41 pm *
Welcome, Guest. Please login or register.
Did you miss your activation email?

Login with username, password and session length
News:
 
   Home   Help Search Login Register  
Pages: [1] 2 3
  Print  
Author Topic: Some more thoughts on plugins/scripting  (Read 22355 times)
0 Members and 1 Guest are viewing this topic.
Feldon
Gem Cutter
****
Posts: 106


« on: January 05, 2007, 03:49:01 am »

I can't remember if I saw this already, but here's what I'm thinking...

There should be something I will call Actions.

Actions are programmed tasks.  These tasks can be simple (Copy, Paste, Save, Close), or they can be more complex (Search, Replace, Go To Line).  The more complex tasks might involve a multi-step form, as in Search/Replace.

There can also be Nested or Compound Actions.  For example, the action 'Move Text to Line' could contain the series of actions Cut, Go To Line, and Paste.

Emerald Editor would come with a number of, unalterable, pre-defined actions.


Plugins could, among other things, add additional programmed actions to the mix.

A simple scripting system, then, might allow a user to combine actions with variables, user input, etc. to create their own, simpler, 'programmed' actions.


Actions can then be made accessible for use in a number of areas: user-defined toolbars, user-defined context menus, user-defined keyboard shortcuts, user-defined menu's, etc.  Of course, the pre-defined actions will be found throughout the core program.
Logged
Szandor
Senior Miner
***
Posts: 92



« Reply #1 on: January 05, 2007, 07:19:38 am »

This would be kinda like Firefox works, right? That's generally a good approach I think since it gives plugin developers easy access to key functions in the program. The easier it is to develop plugins, the larger the user base will be.
Logged

"Cleverly disguised as an original signature..."
Kamots
Miner
**
Posts: 22


Perpetual Student


« Reply #2 on: January 09, 2007, 02:50:31 am »

That's a very good approach to writing plug-ins and similar pieces of add-on software. I think Szandor is right; this is how Mozilla did lay out some of their extension system. We can always model our plug-in system after another one which is tried and true.
Logged
Arantor
Site Administrator
Administrator
Master Jeweller
*****
Posts: 618



« Reply #3 on: January 11, 2007, 11:46:58 pm »

If it works, run with it.

One question: would plugins be able to consider other plugins as dependencies? E.g. if you have a 'function' of sorts as part of that extension (because having it as pure linear code would be nasty if it did anything more than twice), could you not in theory build a library of common EE manipulations and then call functions from them?

Perhaps if you were writing a 'word analyser' toolkit extension, you might build a core analyser system (including functions like breaking sentences down into words), then have functions which run on those.

As much as I can see the benefits of having libraries of functions, there are of course the obvious issues of versioning (even Firefox has this to some degree; there are plenty of extensions marked as 1.x only even though they would run fine in 2.0.0.1)

I don't want to have to limit functionality of plugins, I'd really like to see it that a plugin which works on 1.0 would work on 2.0 without any alterations (or minor ones at most), but I cannot expect something for 2.0 to work as expected on 1.0 if it requires functions provided by 2.0.
Logged

"Cleverly disguised as a responsible adult!"
Szandor
Senior Miner
***
Posts: 92



« Reply #4 on: January 12, 2007, 11:04:35 am »

One question: would plugins be able to consider other plugins as dependencies?
I think that would be a good idea. This is how Miranda IM works, and it works fine. For Miranda there are some plugins that are written to provide no actual functionality on their own, but to enable other plugins to use the same functions.
Logged

"Cleverly disguised as an original signature..."
Feldon
Gem Cutter
****
Posts: 106


« Reply #5 on: January 12, 2007, 10:01:57 pm »

Also, unlike something akin to the Linux Kernel, we don't expect people to want to use multiple versions of Emerald Editor.  That is, we don't expect someone would have to stick to version 1.5 even though version 2.0 is out.  This reduces the complexity of plugin-dependencies as plugins only have to support the most recent version of the editor.

So yes, I would expect some plugin-dependency may occur, and I don't think its necessarily a bad thing.
Logged
rageboy
Jeweller
*****
Posts: 305

Ankit Singla


« Reply #6 on: May 12, 2007, 07:16:00 pm »

Also, unlike something akin to the Linux Kernel, we don't expect people to want to use multiple versions of Emerald Editor.  That is, we don't expect someone would have to stick to version 1.5 even though version 2.0 is out. 

Why don't we expect people to use old versions? Personally I've run across that a lot, but personally I think people should update to betas when they become available, so if someone complains I tell them to update Wink

Quote
This reduces the complexity of plugin-dependencies as plugins only have to support the most recent version of the editor.

So yes, I would expect some plugin-dependency may occur, and I don't think its necessarily a bad thing.
Logged
Feldon
Gem Cutter
****
Posts: 106


« Reply #7 on: May 12, 2007, 09:22:10 pm »

Well, betas are a little different.  I was referring to stable versions.  For a project like Emerald Editor I don't see why someone would use version 1.5 'stable' when version 2.0 'stable' is already out.
Logged
rageboy
Jeweller
*****
Posts: 305

Ankit Singla


« Reply #8 on: May 12, 2007, 09:36:28 pm »

Oh I know. I was talking about stable too. For instance Firefox and Thunderbird. I know a lot of people who are still using 1.5 even though 2 is out for both. It doesn't make sense, but I guess that's the way it goes.
Logged
John Yeung
Senior Miner
***
Posts: 85


« Reply #9 on: May 16, 2007, 03:03:13 am »

I specifically prefer Crimson 3.60 to 3.70.  There are simply times when a new version changes or removes something that you like in an older version, and you don't want to give that up.  Doesn't matter that the new one is "as stable" as the old one.  And sometimes the new one isn't as stable as the old one, despite being a "full release", so that is another reason some folks stick with older versions.  I'm also still using IE6 because there is some software I need for my job which doesn't work with IE7.  There are all sorts of valid reasons for wanting to stick with old versions.

Personally, I am not against letting people use old stuff even without a "valid" reason--just the fact that they want to use it is good enough reason for me.  I am not saying you should make things backward-compatible forever, just that it's desirable to be able to accommodate them if it's not too much trouble, and be polite about it if it is.  (Don't disparage such users for "not making sense". Wink )

John
Logged
Feldon
Gem Cutter
****
Posts: 106


« Reply #10 on: May 17, 2007, 12:02:04 am »

Before I continue to talk about versioning, I think I'm going to give another go at explaining what I'm thinking.

I will differentiate between the Emerald Editor Core, a Plugins Interface, and an Actions Interface.

The Emerald Editor Core
The Emerald Editor Core is what this team is going to build and make available for download.  It would include the basic functionality everyone expects in a text editor, such as a window to type text into.  The Core would also include two interfaces for expanding on it: 1) a Plugins interface and 2) an Actions interface.

The Plugins Interface
Plugins could be added via an interface similar to the Firefox Add-On's interface.  There are three main types of plugins.

First, some plugins change the way the Emerald Editor core works.  Examples are probably best.  Plugins could be written that:
-cause text entered into the editor window to always be entered in upper case, regardless of the CAPS lock or Shift button.
-cause Emerald Editor to minimize to a system tray icon instead of the taskbar.

Second, some plugins provide the functionality to perform specific actions.  For example, plugins could be written so that:
-a pop-up box would be made visible that said 'SURPRISE!'
-a user could setup a connection to and then browse an SVN server.

Third, some plugins can be both.

But how do you actually make use of a Plugin?  For the first type of plugin, this is a non-issue.  There are no user options, no dialog box is required, this functionality (text in upper case, and minimizing to taskbar) just IS.  However, for the second type of plugin, there needs to be some way to configure them, to activate them.  i.e. How do you tell the Emerald Editor core to make use of the Surprise Plugin and pop-up a box?  How do you tell the Emerald Editor core to make use of the SVN Plugin and pop-up the SVN interface?

One method is for the Plugin authors to be responsible for creating menu items or toolbar options or keyboard shortcuts in order to access or initiate their plugin's various functions.  However, I think that's adding complexity for the plugin programmer that isn't required.  Which brings us to Actions.


The Actions Interface
Actions are the bridge between the Emerald Editor Core and Plugins.  Actions are what call the various functions in the Emerald Editor Core and any installed Plugins.  Some Actions, such as Open/Close/Save/Exit would likely be included in the Emerald Editor Core.  However, each plugin would also be able to define any number of Actions.  Given this list of Actions, an end-user would be able to assign them to various menu locations (I want Close in the File menu), toolbar locations (I want Exit on my Standard toolbar), keyboard shortcuts (I want Ctrl+U to open the SVN interface), and anything else we want to open up to user customization.

The benefits are that the plugin programmer doesn't have to know much about the main Emerald Editor interface, and the front-end remains completely customizable to the user.


Versioning
So, where does versioning fit in.  Clearly, not all plugins will be able to work with every version of Emerald Editor.  Plugin 1.0 might work with EE4 but not EE5, while plugin 2.0 might work with EE5 and not EE4.  Doesn't that get confusing.

I think the simple answer is to require that every plugin define what version(s) of EE it is compatible with.  We can then tell the EE plugins interface to only look for plugins that are compatible with it.  So, if you had EE4 installed, when you searched for plugins you would only see Plugin 1.0 as available.  On the other hand, if you had EE5 installed, you would only see Plugin 2.0 as available.

What about the case where a parent plugin requires a child plugin?  Again, I think the parent Plugin should have to define the name and version of the child plugin it requires.  In this way, EE can quickly check to see if these plugins are ALL compatible.  You don't want EE to install the parent but not the child!

Compound Actions
This was a secondary idea I had, and described below.  What I'm basically talking about are Macros.  Each step in the Macro would be a call to an Action.  The user could pre-define the necessary inputs for the Action, or if not completed, they would be prompted for the input when they run the macro.  For example, the 'Go To Line...' Action would need to know what line number you want.  You could pre-define it to be line 5, or you could let EE prompt you whenever you run the Macro.

Each Macro would be named and would become its own Action.  In this way, a Macro could then be added to a menu, or a toolbar or keyboard shortcut.  They could also be added to other Macros.

Versioning here is not really an issue, because the only plugins you were able to install were versioned correctly, and so the only Actions available are ones that work correctly.

At one point I was thinking a Macro could be used by a plugin, but this doesn't really make any sense, as Macros should stay completely user-defined.  Also, it avoids even more versioning issues.


What do you think of all this?

« Last Edit: May 17, 2007, 12:08:49 am by Feldon » Logged
rageboy
Jeweller
*****
Posts: 305

Ankit Singla


« Reply #11 on: May 17, 2007, 02:22:46 pm »

Heh. Maybe it's just me but I kind of thought that was understood. I guess one thing we could do is make a separate menu item just for plugins. That might be helpful, partly so you know what does and doesn't come with core. Within that menu, we would have a preferences/options item to configure them. Anything else would be menu items that the plugins themselves would want to add if any.
Logged
Pvt_Ryan
Master Jeweller
******
Posts: 422



WWW
« Reply #12 on: May 17, 2007, 04:00:49 pm »

We should be careful how we develop this as tbh what has been described sounds an awful lot like eclipse.. We need to be careful to keep true to CE where possible.

While i agree there should be potential for plugins etc, I think we should have the core functionality the same as CE (with improvements where possible).

EE should have some of the most common language syntaxes (or none) by default.. I am eager for a SVN repo with just syntaxes in it and some form of moderation for all syntaxes submitted.
Logged
rageboy
Jeweller
*****
Posts: 305

Ankit Singla


« Reply #13 on: May 17, 2007, 04:06:02 pm »

well actually I was thinking more along the lines of pidgin than eclipse. (tools menu in particular). Also, I think that although we should try to add stuff to core, I think it would be a huge help to only keep the absolutely necessary stuff in core. As I mentioned in some other thread, you could have multiple installations (minimal, lite, full, custom) that decided the "features" (implemented as plugins) to install that the user could choose during installation, which would make the installer easier to write. Then the features that user deems necessary could be installed without the need to make the program much larger or slower. The main problem with adding functionality directly to the program is the potential for a large program size.
« Last Edit: May 17, 2007, 04:09:26 pm by rageboy » Logged
Crul
Prospector
*
Posts: 4


« Reply #14 on: May 17, 2007, 05:07:39 pm »

well actually I was thinking more along the lines of pidgin than eclipse. (tools menu in particular). Also, I think that although we should try to add stuff to core, I think it would be a huge help to only keep the absolutely necessary stuff in core. As I mentioned in some other thread, you could have multiple installations (minimal, lite, full, custom) that decided the "features" (implemented as plugins) to install that the user could choose during installation, which would make the installer easier to write. Then the features that user deems necessary could be installed without the need to make the program much larger or slower. The main problem with adding functionality directly to the program is the potential for a large program size.

I thought that I had read somewhere that for EE the goal was to have it run without any installation process. This would allow anyone to carry it around in their USB key and run it straight from there if they choose. Or am I just dreaming this up and this has never been mentioned?
Logged
Pages: [1] 2 3
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2013, Simple Machines Valid XHTML 1.0! Valid CSS!
Page created in 0.144 seconds with 18 queries.