Emerald Editor Discussion
September 20, 2017, 10:57:51 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 23268 times)
0 Members and 2 Guests are viewing this topic.
Arantor
Site Administrator
Administrator
Master Jeweller
*****
Posts: 618



« Reply #30 on: May 25, 2007, 11:21:48 pm »

Actually I think it would be easier and not significantly more work to include column mode as a (semi) standard feature in whatever text editing widget ends up being used.

From my own limited experiences, part of how GDI handles the textbox widgets is to work out the position of the text both in characters from the start and also relative x,y coordinates, and hooking on GUI events to manipulate that should not be too much of an issue in my mind.

But that I think must be the final line on absolute core features.
Logged

"Cleverly disguised as a responsible adult!"
jonnymind
Miner
**
Posts: 18


« Reply #31 on: May 26, 2007, 12:33:56 pm »

Limited base functionalities does not necessarily mean better design.

Every functionality you tear off the engine and put in a plugin will be, at best, impossible to rely on for other plugins, and, at worst, simply unavailable.
I.e. if you want to tear off regex searches from the core engine, every plugin willing to search will have either to:
1) Ensure that regex plugin is loaded in the engine and use it (hard/inadvisable)
2) Use its own regex engine
3) just forget it.

About 1), passing informations through plugins may not be a smart idea as it may seem. In example, this would raise dependency problems and force in cross languages interface we don't need and don't probably want. Managing dependencies requires i.e. centralized web repositories and automated download/install... well, I really wouldn't get in that mess for an editor. I would just run any already existing excellent editor.

About 2), it may go but it means that plugins get bigger and uglier. In example, if you need to load regex module from python you'll need a full python installation. In fact, regex module (but use it as a wildcard name), may depend on other python modules, which must be available... etc. Also, while a regex coded in the search process would probably have direct access to unlimited size virtual storage text data we may wish to use in the engine, using local-specific regex searches will require to translate every single line (or code slice) into the local string representation of the plugin language ( std::string for C++, although faster than PyString, are not an exception).

About 3) well...

So, no, I am against stripping the engine of useful functionalities. Conversely, we should put in the engine any interesting feature, and if we find a plugin written out there by our users that does a very sensible thing, we should integrate it in the engine by the very next version.

As long as they don't bog down startup or normal operations, there is no meaning in strip useful features away. On a nowadays computer (or even cellular phone, actually), loading a 100kb binary application has more or less the same effect as loading a 10MB application: it will be up in a blink. What differs is the need for startup operations. I.e. if the program searches for new files to be indexed at startup, well, that's an operation that will bog down the application. Putting in more code to be used on need won't harm, as long as it doesn't play an active role if not explicitly invoked/activated/requested. And believe me, it takes a DAMNED lot of code to write a 10MB application, provided it is written efficiently. Actually, it takes a whole lot of code even to build a 1MB application.

Also, concerning nowadays USB keys, be an application of 100KB or be it 10MB won't matter much; it will matter MUCH MORE if the application, to do what an user would like to do with it above any other already existing application, is broken in (say) 100 files.

Logged
rageboy
Jeweller
*****
Posts: 305

Ankit Singla


« Reply #32 on: May 26, 2007, 02:24:54 pm »

An important point that people seem to be forgetting is that many plugins, including regex most likely will be included in the program to start with, so cross plugin dependencies aren't so much of an issue. Granted, you're right that more files mean a slower load, but for less powerful systems (not everyone is using a new-ish comp), the size of the binary does matter. I really don't mind taking other plugins and distributing them and keeping them updated, but I think it'd be bad to include every sensible plugin in the source.
Logged
Phil
Administrator
Master Jeweller
*****
Posts: 427


« Reply #33 on: May 26, 2007, 06:40:27 pm »

I agree with Rageboy. I don't think we should clutter the main engine with excess features. IMO if we have a nice dependency system, it would not be an issue to have semi-commonly used features as plug-ins.

Phil
Logged
jonnymind
Miner
**
Posts: 18


« Reply #34 on: May 31, 2007, 09:06:27 am »

An important point that people seem to be forgetting is that many plugins, including regex most likely will be included in the program to start with, so cross plugin dependencies aren't so much of an issue. Granted, you're right that more files mean a slower load, but for less powerful systems (not everyone is using a new-ish comp), the size of the binary does matter. I really don't mind taking other plugins and distributing them and keeping them updated, but I think it'd be bad to include every sensible plugin in the source.

Problem of dependency is not "I hope the feature I need is there", it's about:
1) How to summon a feature you don't know is in which code from other code that can't reasonably know the internals of the target code.
2) Do it efficiently.
3) What to do if feature isn't there.

Libraries as regex, if properly embedded, can grow an exe file of 70-100 kb. That size isn't much of a problem to extra load on ANY machine, including modern cellular phones, but if you really want you can try to see the difference in load time on a x286. Is that old enough?
Well, on that machine, if my memory isn't wrong, disk transfer time was about 1MB/sec which brings load time of our regex to about .1 seconds. Let's say we fix size of extra features for the engine in 1MB. You'll have a lot of extra features in that. Probably more than we could ever stuff in. But let's fix it to 1MB. You'd have about 1s extra load time; let's set another second to apply the global relocation table (I guess it was less on my 286, but let's stick to it). It's 1, 2, and it's there. Or in the case of a poor 286, it's 1..10 for the program and 1, 2 to load the extra stuff we want in.

Do you really want to bog down runtime performances and start get hairy code by not providing basic functionalities everyone wants for THAT?

The more services the engine offers to the plugins, the more powerful, simpler and efficient will be the plugins.

I.e. what if Mozilla didn't offered XUL? -- you wouldn't have chatzilla. And XUL decoding is a damned big piece of code...


« Last Edit: May 31, 2007, 09:08:23 am by jonnymind » Logged
rageboy
Jeweller
*****
Posts: 305

Ankit Singla


« Reply #35 on: May 31, 2007, 12:18:00 pm »

Right. Well I agree that a few libraries, like regex, should probably be included, but in general, we shouldn't just throw something in because we think it might be useful later. I think we'll end up seeing what we need and don't as time progresses based on what users ask for.
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.081 seconds with 18 queries.