Hi ...
I have just found this nice little IDE project, and I like the basic idea of a simple and fast IDE in GTK2.
But I have some questions about your future plans.
In the 0.11 code (from SVN) there is the start of a project manager but it seems a bit primitive, what is the plan for this project manager ?
Have anyone thought about making it all script able in f.ex. python (or lua :-)), to make it possible for the script to handle compiler output, generate Makefiles (from project lists), or make custom script manipulation ( and in the mean time keep the overhead down) ? I know this is not a new emacs, but scripting is a very strong feature if done properly :-)
I realize that if this have to remain a small application, it need to keep features (and init time) down, but this could be some nice and strong features, that only cost if used.
I am looking forward to see how this project unfold :-)
Regards
/BL
On Sat, 24 Feb 2007 23:31:59 +0100, Bo Lorentsen bl@lue.dk wrote:
Hi Bo,
In the 0.11 code (from SVN) there is the start of a project manager but it seems a bit primitive, what is the plan for this project manager ?
at the moment only the management of some project data(like name, file patterns, base path, description) is possible, more things and actual functionality will follow soon. So, at the moment you can create and open project files which contain information about a project but you can't do anything with it ;-). In the future you'll can set up separate build options for the whole project, specify file patterns to define which files belong to a project and some other things.
Have anyone thought about making it all script able in f.ex. python
Me not. And personally, I don't like it very much. We are planning to add a plugin interface somewhen and then many things could be realised as plugins independent from the main code.
(or lua :-)), to make it possible for the script to handle compiler output, generate Makefiles (from project lists), or make custom script manipulation ( and in the mean time keep the overhead down) ?
Compiler output will already be parsed. Makefile creation could be added or could be a plugin in the future.
Any ideas and suggestions are welcome.
Regards, Enrico
-- Get my GPG key from http://www.uvena.de/pub.key
Enrico Tröger wrote:
at the moment only the management of some project data(like name, file patterns, base path, description) is possible, more things and actual functionality will follow soon. So, at the moment you can create and open project files which contain information about a project but you can't do anything with it ;-).
So I have noticed :-)
In the future you'll can set up separate build options for the whole project, specify file patterns to define which files belong to a project and some other things.
Hmm, ok ... so you can't add and delete files in a project at the moment, but what is the end goal of this project manager function ?
Have anyone thought about making it all script able in f.ex. python
Me not. And personally, I don't like it very much. We are planning to add a plugin interface somewhen and then many things could be realised as plugins independent from the main code.
Ok, plugin structure will be able to access all the geany functionality ?
Compiler output will already be parsed. Makefile creation could be added or could be a plugin in the future.
Ok, but the general idea is plugins, and no scripting ...
/BL
On Sun, 25 Feb 2007 21:01:04 +0100, Bo Lorentsen bl@lue.dk wrote:
Hi,
In the future you'll can set up separate build options for the whole project, specify file patterns to define which files belong to a project and some other things.
Hmm, ok ... so you can't add and delete files in a project at the moment, but what is the end goal of this project manager function ?
To use projects ;-). Seriously, some of the main features will be project related session restoring and project related build options. But we are at a very ealier stage, so please be patient.
Have anyone thought about making it all script able in f.ex. python
Me not. And personally, I don't like it very much. We are planning to add a plugin interface somewhen and then many things could be realised as plugins independent from the main code.
Ok, plugin structure will be able to access all the geany functionality ?
Well, I'm not sure at the moment. But the whole plugin interface has to be designed and this won't be done in the near future. Sorry.
Compiler output will already be parsed. Makefile creation could be added or could be a plugin in the future.
Ok, but the general idea is plugins, and no scripting ...
I don't say: no scripting! But at the moment there are no plans ;-).
Regards, Enrico
-- Get my GPG key from http://www.uvena.de/pub.key
Enrico Tröger wrote:
To use projects ;-). Seriously, some of the main features will be project related session restoring and project related build options. But we are at a very ealier stage, so please be patient.
Ok, that makes sense ...
Well, I'm not sure at the moment. But the whole plugin interface has to be designed and this won't be done in the near future. Sorry.
Ok, but I just think that if the plugin or scripting structure are in place early in the development of geany, people could start to hack scripts that fast and easy make the core geany application do what they which it to do.
Some of these scripts may end up in some Geany buildin functions (convertet to c) or global scripts, or they my just be local scripts making a developer happy :-)
Scripts could control project, editor, compilation and even debugging, and the core IDE could still remain quite small, clean and fast loading.
I don't say: no scripting! But at the moment there are no plans ;-).
Ok, sounds good ...
/BL
On 2/25/07, Bo Lorentsen bl@lue.dk wrote:
Enrico Tröger wrote:
To use projects ;-). Seriously, some of the main features will be project related session restoring and project related build options. But we are at a very ealier stage, so please be patient.
Ok, that makes sense ...
Well, I'm not sure at the moment. But the whole plugin interface has to be designed and this won't be done in the near future. Sorry.
Ok, but I just think that if the plugin or scripting structure are in place early in the development of geany, people could start to hack scripts that fast and easy make the core geany application do what they which it to do.
Some of these scripts may end up in some Geany buildin functions (convertet to c) or global scripts, or they my just be local scripts making a developer happy :-)
Scripts could control project, editor, compilation and even debugging, and the core IDE could still remain quite small, clean and fast loading.
I don't say: no scripting! But at the moment there are no plans ;-).
Ok, sounds good ...
I rarely contribute (actually most like never) to this project this days but, as I have some sort of experience with plug-ins and script systems, I believe I could help this.
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.
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.
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.
Just my two cents, feel free to ignore if you don't agree :)
Regards, Alexandre Moreira.
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.
If this bothers anyone (most importantly, Nick and Enrico) please tell me and I'll refrain from posting "out of the community" point of view messages :) I'm just trying to help the way I can.
/BL _______________________________________________ Geany mailing list Geany@uvena.de http://uvena.de/cgi-bin/mailman/listinfo/geany
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 ?
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.
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.
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 ?
/BL
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