On 2/26/07, Bo Lorentsen bl@lue.dk wrote:
Alexandre Moreira wrote:
One of the best ways to have a scripting engine inside a plug-in-enabled software would be (IMHO, of course) the X-Chat approach, that is: to have the plug-in system powerful enough to accommodate the script engine on top of it, so that the scripts would be just as powerful as any plug-in and take the burden off the main developers.
So, what you say is that a good plugin system will be able to hold a scripting engine. As it is the same interface ?
Yes, that is it. The Scripting languages can all then talk to their engine wrappers that is directly connected to the plug-in interface.
I think my worry in this regard is that if this plugin or scripting system is not a part of the basic and early design, it will simply not be as powerfull as it need to be.
I know this, and I am pretty sure the core devs all know this. But it is a matter of intended behavior and focus. The guys who started this didn't (at the time, at least) see the compelling need for the plug-in system and focused on what they need, giving us the fast and fairly complete lightweight IDE. But what I think was most important to them was to scratch their own itches as is the norm in Open Source Software.
That said, what I really mean is: Ok, perhaps now that we're thinking in plug-in systems the fact of it being ignored on the start of the project is bad, but we have to remember that Geany weren't supposed to have these, and the guys are planning it simply because the users wanted. So, we better just let it go and help wherever we can to make this thing the best it can be.
As a great side effect, the user that does not intend to use a certain script engine could just don't load the plug-in that provides it, and multiple independent developers can develop engines that make it possible for users to load plug-ins in different languages.
The "pay as you go" idea, so the main core will remain small and snappy, but it will be extensible.
I believe it is an all win situation, just would take long to get the whole plug-in architecture done before we (as in you, lol) can have any script support.
The only "problem" with a plugin architecture that it is more difficult to master, and will keep non c programmers from contributing.
There is always going to be c programmers around a C-based project. The only thing that will need to be done is to encourage some of those to write engine wrappers for some easier languages such as Lua, TCL or Python, which are 3 easy-to-embed languages.
PS: Unfortunately I couldn't get Geany to fulfill some very specific needs of mine (I have just been using Vim for too long) and I am not a user anymore, but I simply love the way and speed that it is being developed and watch the mail list and try to test a new release version every now and then.
Would a plugin and/or scripting possibility be able to help you making geany more the tool of your chooice ? If it could help, what level of integration would it then need ?
Its not that simple. It is just that me and Geany like to work in somewhat different ways and I'd have to extend it a great deal to make me comfortable with. At the same time, I think the whole software is great and can be useful for a number of users so big that it deserves all the help it can get. It is pretty much what I say about KDE... It is a great peace of software. Really, I admire the guys who write it. I just can't get used to actually working on it. Personal preferences.
I'm too used to heavyweight tools, be it in the form of huge IDEs (Eclipse, Netbeans and these days at work, Visual Studio.Net) or the let-me-modify-every-weird-bit-of-the-application editors like Emacs and Vim.
But I don't want to extend this piece of the discussion any longer. I should probably have directed this "PS" message to the core devs instead of sending it to the list. I'm sorry.
Regards, Alexandre Moreira.
/BL _______________________________________________ Geany mailing list Geany@uvena.de http://uvena.de/cgi-bin/mailman/listinfo/geany