Emerald Editor Discussion
March 29, 2017, 12:12:46 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: Plug-in ability  (Read 21070 times)
0 Members and 1 Guest are viewing this topic.
ce2000
Miner
**
Posts: 21


WWW
« on: May 24, 2006, 06:45:04 am »

since the devs might not want to put all the suggestions into the main app, maybe there could be a plugin feature that would add on to the existing core app.

feel free to put it off until later on, when EE is rocking Smiley
Logged

daemon
Developers
Gem Cutter
***
Posts: 107


WWW
« Reply #1 on: May 25, 2006, 04:08:28 am »

I think plugins will definitely be done (though maybe not for 1.0). But I have no experience making a plugin architecture in C++/Java so hopefully we'll get somebody who does, or I'll do some research.
Logged
Arantor
Site Administrator
Administrator
Master Jeweller
*****
Posts: 618



« Reply #2 on: May 26, 2006, 01:58:50 pm »

Well, a plug-in architecture has been on the cards for some time, although I'm not sure how.

C/Java is a possibility but I think the bulk of the plug-in people would prefer something like Lua, which does seem to make sense after all. My only concern is package bloat - it'll get bigger if we add something like that in. But I think it is a very important feature to include, because it allows so much other stuff to happen.

In fact, it may be that we write a number of the core features as "pre-included" plugins, so to speak, using Lua or whatever. But I really couldn't say at this stage, since getting a core app is much more of the priority, but it is on the back-burners - I know alpha and myself have been considering it elsewhere in the forum.
Logged

"Cleverly disguised as a responsible adult!"
awmyhr
Senior Miner
***
Posts: 95

Maintainer of Obscure and Unused Ports


WWW
« Reply #3 on: May 26, 2006, 03:55:29 pm »

Quote from: Arantor
In fact, it may be that we write a number of the core features as "pre-included" plugins, so to speak, using Lua or whatever. But I really couldn't say at this stage, since getting a core app is much more of the priority, but it is on the back-burners - I know alpha and myself have been considering it elsewhere in the forum.
This is would be an interesting approach, where at the core of the editor is merely a 'plugin' engine, and basically every feature is a 'plug-in.'  Then provide a facility where each user can configure for themselves which features get loaded.  Then a user could have a super lightweight configuration for their usb keychain, and the full-blown option laden version for their QuadProc MacPro.  Creating the plugins in something like Lua would likely help with our cross-platform goals, then we don't have to have "Plugin-X for windows, Plugin-X for Mac, Oops, no Plugin-X for Linux" type problems...
Logged

-->>  This Space 4 Rent  <<--
daemon
Developers
Gem Cutter
***
Posts: 107


WWW
« Reply #4 on: May 26, 2006, 11:24:32 pm »

Well, a plug-in architecture has been on the cards for some time, although I'm not sure how.

C/Java is a possibility but I think the bulk of the plug-in people would prefer something like Lua, which does seem to make sense after all. My only concern is package bloat - it'll get bigger if we add something like that in. But I think it is a very important feature to include, because it allows so much other stuff to happen.

In fact, it may be that we write a number of the core features as "pre-included" plugins, so to speak, using Lua or whatever. But I really couldn't say at this stage, since getting a core app is much more of the priority, but it is on the back-burners - I know alpha and myself have been considering it elsewhere in the forum.

Personally, I think that using the native language (C++) would be better because then we don't have to write a separate interpreter and people can just use the public API that we setup and inherit from wxStEdit.
Logged
Arantor
Site Administrator
Administrator
Master Jeweller
*****
Posts: 618



« Reply #5 on: May 26, 2006, 11:37:27 pm »

True, but I don't want to get into the realms of having platform-dependent plugins. That was one of the reasons I gave up playing with Adventure Game Studio for developing point-n-click adventures, since all the plugins were pretty much Windows-only.

I'd like plugins to be written in a language which is totally platform independent, especially if they are going to be distributed separately to the core (even the "core" features may be plugins, as such), and which will be more friendly to less technical people than C/C++/Java.

However, I do see the merits of having a totally native plugin architecture - it's faster, there is less to debug etc. but I don't want to overlook the benefits of having that abstraction layer.
Logged

"Cleverly disguised as a responsible adult!"
Wraithan
Prospector
*
Posts: 9


« Reply #6 on: May 30, 2006, 07:24:52 pm »

For a hacking program for a game I play, their plugin system is C++, you just have to compile the plugin with the core source, then you can distribute the .dll along with the source so people can compile it themselves if they don't trust the source of the .dll.
Logged
daemon
Developers
Gem Cutter
***
Posts: 107


WWW
« Reply #7 on: May 30, 2006, 11:41:31 pm »

For plugins, we could create a Sourceforge project once we're ready and use either their compile farms our the community could compile it for the platforms needed that the author doesn't have access to.

I just think that having the native API will be significantly faster and more powerful than using an intermediary.
Logged
Arantor
Site Administrator
Administrator
Master Jeweller
*****
Posts: 618



« Reply #8 on: May 31, 2006, 12:07:46 am »

Yes, it probably would be faster in many respects (and speed is definitely a watchword for Emerald Editor), but at the same time so is ease of development.

I don't have any real problem with using C++, since then that is one less level of complexity in the engine, and one less 'thing' to maintain. I just think it would make troubleshooting and maintaining the plugins a little harder to do.
Logged

"Cleverly disguised as a responsible adult!"
Matthew1344
Gem Cutter
****
Posts: 103


« Reply #9 on: May 31, 2006, 01:36:34 pm »

I don't know anything about plugin architecture development, but if C++ (EE native) was used, what would prevent a scripting language plugin to be written on top of that? 

To illustrate, could I add the "VBScripting Engine" plugin (which is written in C++) and then add VBScript plugins which are dependent on that?  And of course if I didn't have any VBScript plugins (or didn't care to develop any myself), I wouldn't need to install the VBScripting Engine.

Too complicated?  Perhaps.  Again, I'm talking about things I don't know, but I thought I'd mention it in case it might stir some thoughts and discussion.
Logged
awmyhr
Senior Miner
***
Posts: 95

Maintainer of Obscure and Unused Ports


WWW
« Reply #10 on: May 31, 2006, 02:50:17 pm »

Then we start to get into the realm of platform specific plug-ins.  The (likely true) assumption is of course that the majority of users will be Windows users (at least at first), but we are attempting to create a cross-platform prodcut. 

<begin long tiresome rant>
The question then becomes, do we want a truely cross-platform product, where user-created content (i.e., syntexes, language files, plug-ins) are (more or less) garunteed to work on all supported platforms?  Or do we want a half-rear-ended cross-platform support where we cater to the largest group of users (i.e, Windows) and our answer to all questions like "This VBScript plugin won't work on Linux" becomes "the source is there, code it yourself."?

This is why I'd like to see the plug-in system use something that can be built-in (like Lua).  Then if we only have one person working on the FreeBSD version, they just have to concentrate on the core code knowing that most (if not all) plug-ins will work with no additional effort as long as the core works.  If we go with C++ (or the like) this theoretical FreeBSD developer would then be deluged with requests to compile this and that plugin until they get fed up and move on to another project.

I've been that user before, where I wondered out loud why feature XYZ of the supposed cross-platform program ZXY doesn't work on platform YZX, and the answer was a very rude "the source is there, stop whining and code it yourself."  I instead found an alternative to ZXY.  This is not the way to grow a project.
</long tiresome rant>
Logged

-->>  This Space 4 Rent  <<--
Matthew1344
Gem Cutter
****
Posts: 103


« Reply #11 on: May 31, 2006, 04:26:22 pm »

<begin long tiresome rant> ... </long tiresome rant>

Hmm... good point.  Perhaps we could build a very large badger?  Smiley

If I might further display my ignorance, here's another thought... What about doing it the same way (or a similar way) that Firefox does it?  This would be a strategic move, such that there would already be a lot of developers capable of writing plug-ins.
Logged
Matthew1344
Gem Cutter
****
Posts: 103


« Reply #12 on: May 31, 2006, 04:42:28 pm »

FYI, the following is from the "uses" page on Lua's website...

Quote
SciTE
Scintilla.org
SciTE is a SCIntilla based Text Editor. Originally built to demonstrate Scintilla, it has grown to be a generally useful editor with facilities for building and running programs. It is best used for jobs with simple configurations. SciTE features a lot of modern editor features (most provided by Scintilla) like syntax highlighting of code, call tips, autocompletion of code, folding, etc. Since version 1.60, Lua can be used to perform operations on the current buffer, using the full API of the Scintilla component.

I'll say nothing more on this topic, as I don't even know enough to judge whether or not anything I'm saying is helpful.   Undecided
Logged
Arantor
Site Administrator
Administrator
Master Jeweller
*****
Posts: 618



« Reply #13 on: May 31, 2006, 05:11:54 pm »

I have to admit I can see both sides of the argument (I should - I think I've argued both sides!!)

Let's sum it up:
C++/Java
Pros:
  Popular and well-known
  Faster than an abstraction layer

Cons:
  Harder to maintain and debug
  Not as cross-platform which will detract from support

Lua
Pros:
  Easier to code
  Can be cross-platform with little extra (if any) effort

Cons:
  Not so well known
  Slightly slower


I still believe to a degree that a plugin system, rather than an open-ended C++ API, is the way forward, and since it has been proven that Scintilla can be linked with Lua in SciTE, I don't see why we can't use Lua. It seems to be the most popular non-C++, non-Java language that has been suggested, and seems to be fairly lightweight.
Logged

"Cleverly disguised as a responsible adult!"
daemon
Developers
Gem Cutter
***
Posts: 107


WWW
« Reply #14 on: June 01, 2006, 01:36:19 am »

Lua shouldn't be an option, IMHO, because it involves us adding code to make Lua work with our product. Plus, Lua is not an object-oriented based language: therefore, it will be harder to export our C++ symbols (objects) to it.

Swig, on the other hand, generates wrappers and native bindings for all kinds of languages, including PHP, Ruby, Python, Perl, and TCL. I think this will work, but I haven't had a lot of time to read up on it. We don't have to change our code for this to work (except for adding a callback to allow for runtime modifications of our program), and it supports more familiar languages.
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.13 seconds with 19 queries.