On 2/26/07, Bo Lorentsen <bl(a)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(a)uvena.de
http://uvena.de/cgi-bin/mailman/listinfo/geany