Hi,
I would like to announce yet another project management plugin for geany. The main reason behind its creation is that I work with thousands of source files and the session-based "project" geany uses isn't sufficient for my purpose. I also had a look at geanyprj and while I like some of the ideas behind it, there are some things that don't fit my needs so I decided to create a new plugin (even though I took geanyprj as a base of the plugin, it has been completely rewritten). The things similar to geanyprj are:
* the location of the configuration file determines the root path of the project * glob-like patterns are used to determine the files belonging to the project (contrary to geanyprj this is the only way to set the files belonging to the project)
On the other hand, there are quite many differences:
* the project files are displayed in the form of a tree in the sidebar (absolutely necessary for big projects) * several projects can be opened simultaneously (one of them is the active project, depending on the current document) * you can specify patterns for source and header files separately - there is a "swap header/source" functionality that finds the corresponding header/source to the currently opened document (same base name matching header/source pattern) * in addition, you can specify "other" project files - headers, sources and other files have different icons in the sidebar, which makes them easier to distinguish * patterns can also be used to ignore some directories you don't want to belong to the project (CVS, .git, ...) * all the project files can be scanned for tags, but this can also be disabled for big projects. * there is a possibility to find a project file by name * search in project files - the project file patterns are passed to grep, which speeds up things considerably by not having to search the binaries * many minor usability improvements * works well for huge projects (I used linux kernel for testing it and it works quite well if tag generation is disabled)
The sidebar has its own toolbar so most of the actions are available directly from there. The first item in the menu, Reload all, is probably the most important one - it automatically opens the corresponding project for all the opened files (geanyprj does this automatically, but for big projects this is rather annoying). In addition, there is a menu under Tools; however, the items in the menu are not supposed to be used from the menu - you should rather assign a keybinding for them as these are used frequently (header/source swapping, searching in project files, finding project file). Also there is a context menu for the items in the sidebar - the menu differs for different elements - projects, folders, files.
You can get the sources here:
Unfortunately, I had to make a few modifications to geany itself because its API just didn't provide the functionality I needed in several cases. I created a new geany project at gitorious:
(you may want to take it over and keep it up-to-date - it's better than your html-accessed git repository and allows external developers create their own clones [you may also want to switch to git completely - it's so much better than svn]). This is just a clone of the mainline. Then there is my personal clone with the modifications:
http://gitorious.org/~techy/geany/techys-geany
There are four branches: * gproject-deps - API additions required by gproject * fixes - fixes that should be applied regardless of gproject * changebar - this is just for those interested - I've ported the changebar from codeblocks - something I can't live without. This however means to maintain a branch of scintilla and I'm not sure if this is something you want. * all - all the above branches combined
(For those less familiar with git - these are remote branches and you have to create a remote tracking branch; type something like this after cloning the repository:
git checkout remotes/origin/all -b all
to checkout the "all" branch)
The sources aren't yet in the state I would normally require before making a release but I can see that geany release 0.19 is coming and it would be nice if it could include the API changes I've made. So here are a few things which I feel would deserve some more attention: * there are possibly some minor leaks - I have to go through the sources carefully to make sure that I deallocate everything. There shouldn't be any dramatic leaks though. * during the implementation I was just lazy to convert utf8 to locale and back - it's present somewhere but there are places where I don't do that so if you have your sources with some locale characters, some things may not work * no support for windows - this is something that someone else has to do - I don't use windows myself * no localization support yet - TODO * for big projects I'd like to create some basic ctags support. The tag manager used by geany is totally unusable for big projects because building the object hierarchy has quadratic to exponential complexity. I need a simple tag support that works in linear time.
Comments and feature requests are welcome. However, beware that I want to keep the project management simple - I've spent quite a lot of time thinking how to keep it minimal. So while I'm sure there are many usability improvements possible, don't be too disappointed if I refuse your feature suggestion because I feel it complicates things too much. I really don't want to create Eclipse v2.
Finally, there are a few things I dislike about geany and that I'd wish to be addressed in some way: * I'd like to have the same "rights" as the session-based project support has. However, there are things I just can't do - I can't set the base directory where build is performed, I can't set per-project indentation options and so on. (It's totally unclear to me how I'm supposed to use the GeanyProject structure - apparently it's meant to be read-only, but then what is it good for?) * I find the session-based project conceptually wrong - having several files opened doesn't mean that they belong to the same project - for instance I often work on several projects in parallel and have their files opened in parallel. Briefly, session != project * Is there any technical reason why searches and builds cannot be interrupted? It's pretty annoying because the build of some of the subsystems of the project I'm working on takes half an hour and I want to be able to interrupt it when I start the build by accident.
And there are lots of things I _like_ about geany - especially that it's so lightweight, yet powerful - this is why I found it worth spending my time creating the plugin. Thanks for the nice editor and tell me your opinion about my plugin!
Cheers,
Jiri
On 8 June 2010 07:38, Jiří Techet techet@gmail.com wrote:
Hi,
Hi, havn't had time to look at your code but a couple of comments below.
I would like to announce yet another project management plugin for geany. The main reason behind its creation is that I work with thousands of source files and the session-based "project" geany uses isn't sufficient for my purpose. I also had a look at geanyprj and while I like some of the ideas behind it, there are some things that don't fit my needs so I decided to create a new plugin (even though I took geanyprj as a base of the plugin, it has been completely rewritten). The things similar to geanyprj are:
- the location of the configuration file determines the root path of the project
- glob-like patterns are used to determine the files belonging to the
project (contrary to geanyprj this is the only way to set the files belonging to the project)
On the other hand, there are quite many differences:
- the project files are displayed in the form of a tree in the sidebar
(absolutely necessary for big projects)
- several projects can be opened simultaneously (one of them is the
active project, depending on the current document)
Geany is working towards proper multiple instance support which will allow you to have a different project in each instance, basic capability is in 0.19 and X session support (shutdown and restore the state of multiple instances on logout/login) in the future. Also gets you multiple windows on multiple screens.
- you can specify patterns for source and header files separately -
there is a "swap header/source" functionality that finds the corresponding header/source to the currently opened document (same base name matching header/source pattern)
Nice, I'd like to add that to the filetype config to have it available in the base Geany, sometime :).
- in addition, you can specify "other" project files - headers,
sources and other files have different icons in the sidebar, which makes them easier to distinguish
- patterns can also be used to ignore some directories you don't want
to belong to the project (CVS, .git, ...)
- all the project files can be scanned for tags, but this can also be
disabled for big projects.
- there is a possibility to find a project file by name
- search in project files - the project file patterns are passed to
grep, which speeds up things considerably by not having to search the binaries
- many minor usability improvements
- works well for huge projects (I used linux kernel for testing it and
it works quite well if tag generation is disabled)
The sidebar has its own toolbar so most of the actions are available directly from there. The first item in the menu, Reload all, is probably the most important one - it automatically opens the corresponding project for all the opened files
Sorry, I'm not sure what you mean, do you mean, for a specified project, open all the files that were open last time you worked on the project??
(geanyprj does this
automatically, but for big projects this is rather annoying). In addition, there is a menu under Tools; however, the items in the menu are not supposed to be used from the menu - you should rather assign a keybinding for them as these are used frequently (header/source swapping, searching in project files, finding project file). Also there is a context menu for the items in the sidebar - the menu differs for different elements - projects, folders, files.
You can get the sources here:
Unfortunately, I had to make a few modifications to geany itself because its API just didn't provide the functionality I needed in several cases. I created a new geany project at gitorious:
(you may want to take it over and keep it up-to-date - it's better than your html-accessed git repository and allows external developers create their own clones [you may also want to switch to git completely
- it's so much better than svn
Personally I agree with this, but it depends on the developers preferences, how much control they have of their environments (one may still be on SVN 1.4), for example corporate Red Hat Enterprise environments can be a long way behind the bleeding edge, and depends on what capabilities their hosting system has.
]). This is just a clone of the
mainline. Then there is my personal clone with the modifications:
http://gitorious.org/~techy/geany/techys-geany
There are four branches:
- gproject-deps - API additions required by gproject
- fixes - fixes that should be applied regardless of gproject
- changebar - this is just for those interested - I've ported the
changebar from codeblocks - something I can't live without. This however means to maintain a branch of scintilla and I'm not sure if this is something you want.
- all - all the above branches combined
(For those less familiar with git - these are remote branches and you have to create a remote tracking branch; type something like this after cloning the repository:
git checkout remotes/origin/all -b all
to checkout the "all" branch)
The sources aren't yet in the state I would normally require before making a release but I can see that geany release 0.19 is coming and it would be nice if it could include the API changes I've made.
Speaking for the main developers, its unlikely. There will not be time as the release is last weekend :) Ok, delayed to this weekend. And of course there can be no string impacts and I doubt that API changes will be accepted either.
Again, unless contradicted, you should submit your changes as individual patches, one per change with explanation, so they can be reviewed one at a time. Having to grab them all from your repository makes the job too big and less likely to happen.
So
here are a few things which I feel would deserve some more attention:
- there are possibly some minor leaks - I have to go through the
sources carefully to make sure that I deallocate everything. There shouldn't be any dramatic leaks though.
- during the implementation I was just lazy to convert utf8 to locale
and back - it's present somewhere but there are places where I don't do that so if you have your sources with some locale characters, some things may not work
- no support for windows - this is something that someone else has to
do - I don't use windows myself
- no localization support yet - TODO
- for big projects I'd like to create some basic ctags support. The
tag manager used by geany is totally unusable for big projects because building the object hierarchy has quadratic to exponential complexity. I need a simple tag support that works in linear time.
Feel free to build it, and please make C++ template support work better :)
Comments and feature requests are welcome. However, beware that I want to keep the project management simple - I've spent quite a lot of time thinking how to keep it minimal. So while I'm sure there are many usability improvements possible, don't be too disappointed if I refuse your feature suggestion because I feel it complicates things too much. I really don't want to create Eclipse v2.
True!!
Finally, there are a few things I dislike about geany and that I'd wish to be addressed in some way:
- I'd like to have the same "rights" as the session-based project
support has. However, there are things I just can't do - I can't set the base directory where build is performed,
In 0.19 the working directory of a build can be set by the user, after that release it is intended that the next version of the build system will have a plugin API so that the plugin can set commands, other users want to do things like setting commands based on file contents and other "interesting" things. ;-S In fact because of the apparent complexity that the "set build commands" dialog will have, Geany will contain only a cut down version and the full dialog will be in a plugin.
I can't set per-project
indentation options and so on. (It's totally unclear to me how I'm supposed to use the GeanyProject structure - apparently it's meant to be read-only, but then what is it good for?)
It has to be read only because the code in Geany assumes that it meets certain invariants, if you could modify it you could break it. Same for build info for now. The guys are happy to consider requests for additions to the API, such as setting indentations, but please submit them early in the release cycle.
- I find the session-based project conceptually wrong - having several
files opened doesn't mean that they belong to the same project - for instance I often work on several projects in parallel and have their files opened in parallel. Briefly, session != project
Depends on your definition of "project", for Geany a project is just a set of files that you are working on at one time, whether they reside in one tree or not. IIUC your definition is "files in one tree". Neither is "correct" just different.
- Is there any technical reason why searches and builds cannot be
interrupted?
The short answer is yes.
The longer answer is that since the user can run any build tool it is generally not possible to guarantee safe killing of builds, so it isn't allowed in 0.19. Also just killing the head process isn't guaranteed to stop builds using remotes.
It is understood that for large systems this is an annoyance, so in the next version of the build system it is intended to be configurable, off by default, but if you know what you are doing you can turn it on and define the action required, kill the process and/or run some command eg to stop the build farm.
It's pretty annoying because the build of some of the
subsystems of the project I'm working on takes half an hour and I want to be able to interrupt it when I start the build by accident.
And there are lots of things I _like_ about geany - especially that it's so lightweight, yet powerful
Agree, thats also why I contribute.
- this is why I found it worth
spending my time creating the plugin. Thanks for the nice editor and tell me your opinion about my plugin!
Cheers,
Jiri _______________________________________________ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Hi, thanks for the response. A few comments of mine below:
On Tue, Jun 8, 2010 at 03:03, Lex Trotman elextr@gmail.com wrote:
On 8 June 2010 07:38, Jiří Techet techet@gmail.com wrote:
Hi,
Hi, havn't had time to look at your code but a couple of comments below.
I would like to announce yet another project management plugin for geany. The main reason behind its creation is that I work with thousands of source files and the session-based "project" geany uses isn't sufficient for my purpose. I also had a look at geanyprj and while I like some of the ideas behind it, there are some things that don't fit my needs so I decided to create a new plugin (even though I took geanyprj as a base of the plugin, it has been completely rewritten). The things similar to geanyprj are:
- the location of the configuration file determines the root path of the project
- glob-like patterns are used to determine the files belonging to the
project (contrary to geanyprj this is the only way to set the files belonging to the project)
On the other hand, there are quite many differences:
- the project files are displayed in the form of a tree in the sidebar
(absolutely necessary for big projects)
- several projects can be opened simultaneously (one of them is the
active project, depending on the current document)
Geany is working towards proper multiple instance support which will allow you to have a different project in each instance, basic capability is in 0.19 and X session support (shutdown and restore the state of multiple instances on logout/login) in the future. Also gets you multiple windows on multiple screens.
OK, I understand. Still in certain situations it's better to have several different projects (here I mean project in the sense I understand it) opened in the single instance. Won't remove this feature ;-)
- you can specify patterns for source and header files separately -
there is a "swap header/source" functionality that finds the corresponding header/source to the currently opened document (same base name matching header/source pattern)
Nice, I'd like to add that to the filetype config to have it available in the base Geany, sometime :).
Should be pretty easy.
- in addition, you can specify "other" project files - headers,
sources and other files have different icons in the sidebar, which makes them easier to distinguish
- patterns can also be used to ignore some directories you don't want
to belong to the project (CVS, .git, ...)
- all the project files can be scanned for tags, but this can also be
disabled for big projects.
- there is a possibility to find a project file by name
- search in project files - the project file patterns are passed to
grep, which speeds up things considerably by not having to search the binaries
- many minor usability improvements
- works well for huge projects (I used linux kernel for testing it and
it works quite well if tag generation is disabled)
The sidebar has its own toolbar so most of the actions are available directly from there. The first item in the menu, Reload all, is probably the most important one - it automatically opens the corresponding project for all the opened files
Sorry, I'm not sure what you mean, do you mean, for a specified project, open all the files that were open last time you worked on the project??
No - what you say is done already by geany (it automatically opens the files that were open when you closed geany). What my plugin does (and actually what geanyprj does too) is that for each of the opened files it tries to find the project configuration file and load the project. If it doesn't find the project file in the directory where the source file is located, it tries the same in all its parent directories (the project configuration file has always the same name). Of course if the project is already opened, it doesn't reopen it again. It's the same way how git works - in whatever project directory you run git, it goes up in the directory structure and tries to find the .git directory.
(geanyprj does this
automatically, but for big projects this is rather annoying). In addition, there is a menu under Tools; however, the items in the menu are not supposed to be used from the menu - you should rather assign a keybinding for them as these are used frequently (header/source swapping, searching in project files, finding project file). Also there is a context menu for the items in the sidebar - the menu differs for different elements - projects, folders, files.
You can get the sources here:
Unfortunately, I had to make a few modifications to geany itself because its API just didn't provide the functionality I needed in several cases. I created a new geany project at gitorious:
(you may want to take it over and keep it up-to-date - it's better than your html-accessed git repository and allows external developers create their own clones [you may also want to switch to git completely
- it's so much better than svn
Personally I agree with this, but it depends on the developers preferences, how much control they have of their environments (one may still be on SVN 1.4), for example corporate Red Hat Enterprise environments can be a long way behind the bleeding edge, and depends on what capabilities their hosting system has.
Of course this is a matter of personal preference. Being an open source project maintainer myself, I find git a real help and I prefer if the contributors submit their patches by using git. And I don't think that there are really any technical reasons for not using git - I use SLES 9 at work and git compiles there just fine.
]). This is just a clone of the
mainline. Then there is my personal clone with the modifications:
http://gitorious.org/~techy/geany/techys-geany
There are four branches:
- gproject-deps - API additions required by gproject
- fixes - fixes that should be applied regardless of gproject
- changebar - this is just for those interested - I've ported the
changebar from codeblocks - something I can't live without. This however means to maintain a branch of scintilla and I'm not sure if this is something you want.
- all - all the above branches combined
(For those less familiar with git - these are remote branches and you have to create a remote tracking branch; type something like this after cloning the repository:
git checkout remotes/origin/all -b all
to checkout the "all" branch)
The sources aren't yet in the state I would normally require before making a release but I can see that geany release 0.19 is coming and it would be nice if it could include the API changes I've made.
Speaking for the main developers, its unlikely. There will not be time as the release is last weekend :) Ok, delayed to this weekend. And of course there can be no string impacts and I doubt that API changes will be accepted either.
Ah, OK, didn't know it was so close. On the other hand these are really just few-liners so might be worth considering. These are the requirements for gproject to work:
http://gitorious.org/~techy/geany/techys-geany/commit/6806f193b475e24dee649d...
http://gitorious.org/~techy/geany/techys-geany/commit/0b25a1225a7425ab7d726c...
http://gitorious.org/~techy/geany/techys-geany/commit/f11ab5f59cf4201d08f04f...
And this fix should definitely go to 0.19:
http://gitorious.org/~techy/geany/techys-geany/commit/62deb4ec5c2b8de4d0979c...
I think I didn't properly describe this one in the commit log - there is a 600ms interval in which the panel displaying the current file name isn't displayed. If you switch tabs with a keybinding and do it too quickly (press it twice in the 600ms period), the wrong file is put on top of the stack. The patch could be smaller but I found the code a little confusing so I tried to make it clearer a bit.
The few more patches are trivial ones. The changebar patch is meant just for testing and not for integration to 0.19.
Again, unless contradicted, you should submit your changes as individual patches, one per change with explanation, so they can be reviewed one at a time. Having to grab them all from your repository makes the job too big and less likely to happen.
Huh, really? What makes the job "too big" exactly? The reason why I submitted the patches this way is just the opposite - to make them easier to merge. You just "git pull" and that's it. As I said, as a maintainer of an open source project I prefer patches submitted this way but it's no problem for me to submit them in the traditional way (after all, anyone can do that by runing git format-patch after cloning the repository - I still don't see your point).
So
here are a few things which I feel would deserve some more attention:
- there are possibly some minor leaks - I have to go through the
sources carefully to make sure that I deallocate everything. There shouldn't be any dramatic leaks though.
- during the implementation I was just lazy to convert utf8 to locale
and back - it's present somewhere but there are places where I don't do that so if you have your sources with some locale characters, some things may not work
- no support for windows - this is something that someone else has to
do - I don't use windows myself
- no localization support yet - TODO
- for big projects I'd like to create some basic ctags support. The
tag manager used by geany is totally unusable for big projects because building the object hierarchy has quadratic to exponential complexity. I need a simple tag support that works in linear time.
Feel free to build it, and please make C++ template support work better :)
I'm absolutely not interested in improving the parsing - especially with C++ - you are almost guaranteed to fail - C++ is just too terrible language (which I use daily at work). maybe you could use LLVM's clang parser, but that might be too slow. I just want something that works in most cases and which is fast enough to handle about 10000 C++ source files. Tag manager used by geany isn't the one.
Comments and feature requests are welcome. However, beware that I want to keep the project management simple - I've spent quite a lot of time thinking how to keep it minimal. So while I'm sure there are many usability improvements possible, don't be too disappointed if I refuse your feature suggestion because I feel it complicates things too much. I really don't want to create Eclipse v2.
True!!
Finally, there are a few things I dislike about geany and that I'd wish to be addressed in some way:
- I'd like to have the same "rights" as the session-based project
support has. However, there are things I just can't do - I can't set the base directory where build is performed,
In 0.19 the working directory of a build can be set by the user, after that release it is intended that the next version of the build system will have a plugin API so that the plugin can set commands, other users want to do things like setting commands based on file contents and other "interesting" things. ;-S In fact because of the apparent complexity that the "set build commands" dialog will have, Geany will contain only a cut down version and the full dialog will be in a plugin.
To be honest, I find the new build dialog in 0.19 (and how it interacts with the session-project) pretty confusing - when you use it for the first time, you have no idea what it does (I had to look at the sources to be sure). It's quite against the overall geany spirit, where you just know immediately how things work. And "Non-Filetype Commands" belongs among the most absurd settings names I've ever seen.
I can't set per-project
indentation options and so on. (It's totally unclear to me how I'm supposed to use the GeanyProject structure - apparently it's meant to be read-only, but then what is it good for?)
It has to be read only because the code in Geany assumes that it meets certain invariants, if you could modify it you could break it. Same for build info for now. The guys are happy to consider requests for additions to the API, such as setting indentations, but please submit them early in the release cycle.
The best thing would be to make the current session-based project just an ordinary plugin - this way it would be guaranteed that all it uses is available for other plugins too.
- I find the session-based project conceptually wrong - having several
files opened doesn't mean that they belong to the same project - for instance I often work on several projects in parallel and have their files opened in parallel. Briefly, session != project
Depends on your definition of "project", for Geany a project is just a set of files that you are working on at one time, whether they reside in one tree or not. IIUC your definition is "files in one tree". Neither is "correct" just different.
I understand the semantics, but I don't understand why it isn't called "session". Of course you can call it project, but the rest of the world uses the the word project for something different. I would just use the same naming as everybody else does.
- Is there any technical reason why searches and builds cannot be
interrupted?
The short answer is yes.
The longer answer is that since the user can run any build tool it is generally not possible to guarantee safe killing of builds, so it isn't allowed in 0.19. Also just killing the head process isn't guaranteed to stop builds using remotes.
I don't really need that it's guaranteed that the program stops, but it would be good if geany at least tried. Sending SIGINT and SIGKILL two seconds later if the program does not stop would be fine with me.
It is understood that for large systems this is an annoyance, so in the next version of the build system it is intended to be configurable, off by default, but if you know what you are doing you can turn it on and define the action required, kill the process and/or run some command eg to stop the build farm.
Then geany should provide a way to tell me the PID of the process.
Jiri
Hi again,
Note I wasn't criticising your plugin, but wanted to make sure you knew about some potential upcoming capabilities that might also be useful in combination.
On 9 June 2010 02:59, Jiří Techet techet@gmail.com wrote:
Hi, thanks for the response. A few comments of mine below:
On Tue, Jun 8, 2010 at 03:03, Lex Trotman elextr@gmail.com wrote:
On 8 June 2010 07:38, Jiří Techet techet@gmail.com wrote:
Hi,
Hi, havn't had time to look at your code but a couple of comments below.
I would like to announce yet another project management plugin for geany. The main reason behind its creation is that I work with thousands of source files and the session-based "project" geany uses isn't sufficient for my purpose. I also had a look at geanyprj and while I like some of the ideas behind it, there are some things that don't fit my needs so I decided to create a new plugin (even though I took geanyprj as a base of the plugin, it has been completely rewritten). The things similar to geanyprj are:
- the location of the configuration file determines the root path of the project
- glob-like patterns are used to determine the files belonging to the
project (contrary to geanyprj this is the only way to set the files belonging to the project)
On the other hand, there are quite many differences:
- the project files are displayed in the form of a tree in the sidebar
(absolutely necessary for big projects)
- several projects can be opened simultaneously (one of them is the
active project, depending on the current document)
Geany is working towards proper multiple instance support which will allow you to have a different project in each instance, basic capability is in 0.19 and X session support (shutdown and restore the state of multiple instances on logout/login) in the future. Also gets you multiple windows on multiple screens.
OK, I understand. Still in certain situations it's better to have several different projects (here I mean project in the sense I understand it) opened in the single instance. Won't remove this feature ;-)
Oh sure, I wasn't suggesting you should.
- you can specify patterns for source and header files separately -
there is a "swap header/source" functionality that finds the corresponding header/source to the currently opened document (same base name matching header/source pattern)
Nice, I'd like to add that to the filetype config to have it available in the base Geany, sometime :).
Should be pretty easy.
Coding is easy, time is hard
- in addition, you can specify "other" project files - headers,
sources and other files have different icons in the sidebar, which makes them easier to distinguish
- patterns can also be used to ignore some directories you don't want
to belong to the project (CVS, .git, ...)
- all the project files can be scanned for tags, but this can also be
disabled for big projects.
- there is a possibility to find a project file by name
- search in project files - the project file patterns are passed to
grep, which speeds up things considerably by not having to search the binaries
- many minor usability improvements
- works well for huge projects (I used linux kernel for testing it and
it works quite well if tag generation is disabled)
The sidebar has its own toolbar so most of the actions are available directly from there. The first item in the menu, Reload all, is probably the most important one - it automatically opens the corresponding project for all the opened files
Sorry, I'm not sure what you mean, do you mean, for a specified project, open all the files that were open last time you worked on the project??
No - what you say is done already by geany (it automatically opens the files that were open when you closed geany). What my plugin does (and actually what geanyprj does too) is that for each of the opened files it tries to find the project configuration file and load the project. If it doesn't find the project file in the directory where the source file is located, it tries the same in all its parent directories (the project configuration file has always the same name). Of course if the project is already opened, it doesn't reopen it again. It's the same way how git works - in whatever project directory you run git, it goes up in the directory structure and tries to find the .git directory.
Ok, I see, I don't use Geanyprj so comparing to it didn't help :)
(geanyprj does this
automatically, but for big projects this is rather annoying). In addition, there is a menu under Tools; however, the items in the menu are not supposed to be used from the menu - you should rather assign a keybinding for them as these are used frequently (header/source swapping, searching in project files, finding project file). Also there is a context menu for the items in the sidebar - the menu differs for different elements - projects, folders, files.
You can get the sources here:
Unfortunately, I had to make a few modifications to geany itself because its API just didn't provide the functionality I needed in several cases. I created a new geany project at gitorious:
(you may want to take it over and keep it up-to-date - it's better than your html-accessed git repository and allows external developers create their own clones [you may also want to switch to git completely
- it's so much better than svn
Personally I agree with this, but it depends on the developers preferences, how much control they have of their environments (one may still be on SVN 1.4), for example corporate Red Hat Enterprise environments can be a long way behind the bleeding edge, and depends on what capabilities their hosting system has.
Of course this is a matter of personal preference. Being an open source project maintainer myself, I find git a real help and I prefer if the contributors submit their patches by using git. And I don't think that there are really any technical reasons for not using git - I use SLES 9 at work and git compiles there just fine.
]). This is just a clone of the
mainline. Then there is my personal clone with the modifications:
http://gitorious.org/~techy/geany/techys-geany
There are four branches:
- gproject-deps - API additions required by gproject
- fixes - fixes that should be applied regardless of gproject
- changebar - this is just for those interested - I've ported the
changebar from codeblocks - something I can't live without. This however means to maintain a branch of scintilla and I'm not sure if this is something you want.
- all - all the above branches combined
(For those less familiar with git - these are remote branches and you have to create a remote tracking branch; type something like this after cloning the repository:
git checkout remotes/origin/all -b all
to checkout the "all" branch)
The sources aren't yet in the state I would normally require before making a release but I can see that geany release 0.19 is coming and it would be nice if it could include the API changes I've made.
Speaking for the main developers, its unlikely. There will not be time as the release is last weekend :) Ok, delayed to this weekend. And of course there can be no string impacts and I doubt that API changes will be accepted either.
Ah, OK, didn't know it was so close. On the other hand these are really just few-liners so might be worth considering. These are the requirements for gproject to work:
http://gitorious.org/~techy/geany/techys-geany/commit/6806f193b475e24dee649d...
http://gitorious.org/~techy/geany/techys-geany/commit/0b25a1225a7425ab7d726c...
http://gitorious.org/~techy/geany/techys-geany/commit/f11ab5f59cf4201d08f04f...
And this fix should definitely go to 0.19:
http://gitorious.org/~techy/geany/techys-geany/commit/62deb4ec5c2b8de4d0979c...
I think I didn't properly describe this one in the commit log - there is a 600ms interval in which the panel displaying the current file name isn't displayed. If you switch tabs with a keybinding and do it too quickly (press it twice in the 600ms period), the wrong file is put on top of the stack. The patch could be smaller but I found the code a little confusing so I tried to make it clearer a bit.
Ok, up to the guys if they have time.
The few more patches are trivial ones. The changebar patch is meant just for testing and not for integration to 0.19.
I'd like to suggest you tag commits you are going to refer to, not leave them as hashes, which of the links above is this one?
Again, unless contradicted, you should submit your changes as individual patches, one per change with explanation, so they can be reviewed one at a time. Having to grab them all from your repository makes the job too big and less likely to happen.
Huh, really? What makes the job "too big" exactly? The reason why I submitted the patches this way is just the opposite - to make them easier to merge. You just "git pull" and that's it. As I said, as a maintainer of an open source project I prefer patches submitted this way but it's no problem for me to submit them in the traditional way (after all, anyone can do that by runing git format-patch after cloning the repository - I still don't see your point).
The point is you are forcing people to clone your repo to get the patch.
Then, which commits are meant to be individual patches?
Since as I said above, treating the whole set as one change is less acceptable than smaller individual patches, harder to review. Thats what I meant by too big.
Sure its easier if everyone is using git, but ATM this is an SVN project.
So
here are a few things which I feel would deserve some more attention:
- there are possibly some minor leaks - I have to go through the
sources carefully to make sure that I deallocate everything. There shouldn't be any dramatic leaks though.
- during the implementation I was just lazy to convert utf8 to locale
and back - it's present somewhere but there are places where I don't do that so if you have your sources with some locale characters, some things may not work
- no support for windows - this is something that someone else has to
do - I don't use windows myself
- no localization support yet - TODO
- for big projects I'd like to create some basic ctags support. The
tag manager used by geany is totally unusable for big projects because building the object hierarchy has quadratic to exponential complexity. I need a simple tag support that works in linear time.
Feel free to build it, and please make C++ template support work better :)
I'm absolutely not interested in improving the parsing - especially with C++ - you are almost guaranteed to fail - C++ is just too terrible language (which I use daily at work).
Oh well, it was worth asking :D, if you don't ask you don't get.
maybe you could use
LLVM's clang parser, but that might be too slow. I just want something that works in most cases and which is fast enough to handle about 10000 C++ source files. Tag manager used by geany isn't the one.
Comments and feature requests are welcome. However, beware that I want to keep the project management simple - I've spent quite a lot of time thinking how to keep it minimal. So while I'm sure there are many usability improvements possible, don't be too disappointed if I refuse your feature suggestion because I feel it complicates things too much. I really don't want to create Eclipse v2.
True!!
Finally, there are a few things I dislike about geany and that I'd wish to be addressed in some way:
- I'd like to have the same "rights" as the session-based project
support has. However, there are things I just can't do - I can't set the base directory where build is performed,
In 0.19 the working directory of a build can be set by the user, after that release it is intended that the next version of the build system will have a plugin API so that the plugin can set commands, other users want to do things like setting commands based on file contents and other "interesting" things. ;-S In fact because of the apparent complexity that the "set build commands" dialog will have, Geany will contain only a cut down version and the full dialog will be in a plugin.
To be honest, I find the new build dialog in 0.19 (and how it interacts with the session-project) pretty confusing - when you use it for the first time, you have no idea what it does (I had to look at the sources to be sure).
As I said there is more of build-system changes to come after 0.19, please provide input for how the dialog and the documentation (so you don't have to read the source) can be improved (on another thread as OT for this one). Note the intention is that there will be a simple and a full featured dialog, I doubt the full featured one will be automatically usable without RTFM, but the simple one should be, so all inputs that help getting to that situation are welcome.
It's quite against the overall geany spirit,
where you just know immediately how things work. And "Non-Filetype Commands" belongs among the most absurd settings names I've ever seen.
Please explain why and alternatives, obviously I knew what I meant and no one else criticised it (so far) so I need to understand why it confuses you to be able to fix it.
I can't set per-project
indentation options and so on. (It's totally unclear to me how I'm supposed to use the GeanyProject structure - apparently it's meant to be read-only, but then what is it good for?)
It has to be read only because the code in Geany assumes that it meets certain invariants, if you could modify it you could break it. Same for build info for now. The guys are happy to consider requests for additions to the API, such as setting indentations, but please submit them early in the release cycle.
The best thing would be to make the current session-based project just an ordinary plugin - this way it would be guaranteed that all it uses is available for other plugins too.
If it was being added today, maybe it would be done that way, but now it would be too much work for too little gain IMHO.
- I find the session-based project conceptually wrong - having several
files opened doesn't mean that they belong to the same project - for instance I often work on several projects in parallel and have their files opened in parallel. Briefly, session != project
Depends on your definition of "project", for Geany a project is just a set of files that you are working on at one time, whether they reside in one tree or not. IIUC your definition is "files in one tree". Neither is "correct" just different.
I understand the semantics, but I don't understand why it isn't called "session". Of course you can call it project, but the rest of the world uses the the word project for something different. I would just use the same naming as everybody else does.
But session is also an overloaded term :), used to refer to the window manager functionality, see also the sm branch which isn't related to the Geany project functionality.
No one is going to win this argument, we have overloaded terms throughout programming and will just have to live with them :(
- Is there any technical reason why searches and builds cannot be
interrupted?
The short answer is yes.
The longer answer is that since the user can run any build tool it is generally not possible to guarantee safe killing of builds, so it isn't allowed in 0.19. Also just killing the head process isn't guaranteed to stop builds using remotes.
I don't really need that it's guaranteed that the program stops, but it would be good if geany at least tried. Sending SIGINT and SIGKILL two seconds later if the program does not stop would be fine with me.
Killing head process may not kill build, especially remote ones. When we last had discussions on this I happened to be consulting to a company whose build servers had just this annoying characteristic so can speak with sad authority.
It is understood that for large systems this is an annoyance, so in the next version of the build system it is intended to be configurable, off by default, but if you know what you are doing you can turn it on and define the action required, kill the process and/or run some command eg to stop the build farm.
Then geany should provide a way to tell me the PID of the process.
Won't be needed when you can configure the kill into Geany, patience :D
Cheers Lex
Jiri _______________________________________________ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
On Wed, Jun 9, 2010 at 03:40, Lex Trotman elextr@gmail.com wrote:
Hi again,
Note I wasn't criticising your plugin, but wanted to make sure you knew about some potential upcoming capabilities that might also be useful in combination.
I absolutely understand. In fact, I prefer critical voices - it makes no sense to say each other how good we are (we know that already, don't we ;-). So please take also my comments in this sense.
OK, I understand. Still in certain situations it's better to have several different projects (here I mean project in the sense I understand it) opened in the single instance. Won't remove this feature ;-)
Oh sure, I wasn't suggesting you should.
Was rather joke from my side. On the other hand "removing features" was the way I developed the plugin - originally I planned many more features but then ended with a minimal consistent set of features that play well with the rest of geany.
- you can specify patterns for source and header files separately -
there is a "swap header/source" functionality that finds the corresponding header/source to the currently opened document (same base name matching header/source pattern)
Nice, I'd like to add that to the filetype config to have it available in the base Geany, sometime :).
Should be pretty easy.
Coding is easy, time is hard
Very true.
(But the coding part applies for reasonably small and simple projects like geany, not multithreaded, multiprocess, multiserver projects communicating using CORBA consisting of thousands of source files, which is something I have to work with at work).
Ah, OK, didn't know it was so close. On the other hand these are really just few-liners so might be worth considering. These are the requirements for gproject to work:
http://gitorious.org/~techy/geany/techys-geany/commit/6806f193b475e24dee649d...
http://gitorious.org/~techy/geany/techys-geany/commit/0b25a1225a7425ab7d726c...
http://gitorious.org/~techy/geany/techys-geany/commit/f11ab5f59cf4201d08f04f...
And this fix should definitely go to 0.19:
http://gitorious.org/~techy/geany/techys-geany/commit/62deb4ec5c2b8de4d0979c...
I think I didn't properly describe this one in the commit log - there is a 600ms interval in which the panel displaying the current file name isn't displayed. If you switch tabs with a keybinding and do it too quickly (press it twice in the 600ms period), the wrong file is put on top of the stack. The patch could be smaller but I found the code a little confusing so I tried to make it clearer a bit.
Ok, up to the guys if they have time.
Sure.
The few more patches are trivial ones. The changebar patch is meant just for testing and not for integration to 0.19.
I'd like to suggest you tag commits you are going to refer to, not leave them as hashes, which of the links above is this one?
None ;-). Instead of tags I created different branches (described in my original mail) - if you want to quickly see what's in the branches, just click the branch name here:
http://gitorious.org/~techy/geany/techys-geany
(branches: changebar fixes gproject-deps all) The first three links are from the gproject-deps branch and the last one from the fixes branch. The changebar is, not surprisingly, in the changebar branch.
Again, unless contradicted, you should submit your changes as individual patches, one per change with explanation, so they can be reviewed one at a time. Having to grab them all from your repository makes the job too big and less likely to happen.
Huh, really? What makes the job "too big" exactly? The reason why I submitted the patches this way is just the opposite - to make them easier to merge. You just "git pull" and that's it. As I said, as a maintainer of an open source project I prefer patches submitted this way but it's no problem for me to submit them in the traditional way (after all, anyone can do that by runing git format-patch after cloning the repository - I still don't see your point).
The point is you are forcing people to clone your repo to get the patch.
Then, which commits are meant to be individual patches?
The master branch is equivalent to geany mainline, the branches contain my patches (quite a standard way how to submit patches with git). My repo is a clone of the geany project I've created here:
It would be best if this was taken over by the geany developers and kept up to date with the current mainline.
Since as I said above, treating the whole set as one change is less acceptable than smaller individual patches, harder to review. Thats what I meant by too big.
Well, there is no "whole set" there - the individual patches are in the form of commits.
Sure its easier if everyone is using git, but ATM this is an SVN project.
It's true that I've used the workflow typical for a git project - from geany web page, which offers both git and SVN repository I assumed that I can chose either of them. If git is not supposed to be used, then it should be removed from there because this makes things confusing (or at least there should be a warning saying: "Don't use the following git repository").
Anyway, no problem for me to provide the changes in the form of individual patches. I'll just wait for the main developer's opinion on this before spamming with additional emails.
I can see that there are people here not so much familiar with git, so I'll just describe in more detail how to get the modified geany and the plugin (the following gets the "all" branch that contains all the patches):
For geany, do the following:
git clone git@gitorious.org:~techy/geany/techys-geany.git cd to the downloaded directory git checkout remotes/origin/all -b all build and install geany
For the plugin do the following:
git clone git@gitorious.org:gproject/mainline.git cd to the downloaded directory ./autogen.sh; make; sudo make install
Finally, there are a few things I dislike about geany and that I'd wish to be addressed in some way:
- I'd like to have the same "rights" as the session-based project
support has. However, there are things I just can't do - I can't set the base directory where build is performed,
In 0.19 the working directory of a build can be set by the user, after that release it is intended that the next version of the build system will have a plugin API so that the plugin can set commands, other users want to do things like setting commands based on file contents and other "interesting" things. ;-S In fact because of the apparent complexity that the "set build commands" dialog will have, Geany will contain only a cut down version and the full dialog will be in a plugin.
To be honest, I find the new build dialog in 0.19 (and how it interacts with the session-project) pretty confusing - when you use it for the first time, you have no idea what it does (I had to look at the sources to be sure).
As I said there is more of build-system changes to come after 0.19, please provide input for how the dialog and the documentation (so you don't have to read the source) can be improved (on another thread as OT for this one). Note the intention is that there will be a simple and a full featured dialog, I doubt the full featured one will be automatically usable without RTFM, but the simple one should be, so all inputs that help getting to that situation are welcome.
It's quite against the overall geany spirit,
where you just know immediately how things work. And "Non-Filetype Commands" belongs among the most absurd settings names I've ever seen.
Please explain why and alternatives, obviously I knew what I meant and no one else criticised it (so far) so I need to understand why it confuses you to be able to fix it.
Well, what I dislike is that there is _any_ build dialog like this in geany. The only thing that should be possible is to:
1. run a user provided command 2. in the user provided (base) directory
(And this is basically what geany used to do before 0.19) Plugins should be allowed to change these two depending on their needs (not possible now). Period. Nothing more. For more complex projects you should use makefiles so the user provided command will be "make" executed in the base directory of the project.
I can't set per-project
indentation options and so on. (It's totally unclear to me how I'm supposed to use the GeanyProject structure - apparently it's meant to be read-only, but then what is it good for?)
It has to be read only because the code in Geany assumes that it meets certain invariants, if you could modify it you could break it. Same for build info for now. The guys are happy to consider requests for additions to the API, such as setting indentations, but please submit them early in the release cycle.
The best thing would be to make the current session-based project just an ordinary plugin - this way it would be guaranteed that all it uses is available for other plugins too.
If it was being added today, maybe it would be done that way, but now it would be too much work for too little gain IMHO.
The most important thing is that geany stops accessing GeanyProject struct directly. It should be the project that requests e.g. setting the base directory, not geany reading it from the project's data structures. But this is pretty easy to fix - I can do that (and possibly convert the current project to plugin) if there is general interest in that.
- I find the session-based project conceptually wrong - having several
files opened doesn't mean that they belong to the same project - for instance I often work on several projects in parallel and have their files opened in parallel. Briefly, session != project
Depends on your definition of "project", for Geany a project is just a set of files that you are working on at one time, whether they reside in one tree or not. IIUC your definition is "files in one tree". Neither is "correct" just different.
I understand the semantics, but I don't understand why it isn't called "session". Of course you can call it project, but the rest of the world uses the the word project for something different. I would just use the same naming as everybody else does.
But session is also an overloaded term :), used to refer to the window manager functionality, see also the sm branch which isn't related to the Geany project functionality.
No one is going to win this argument, we have overloaded terms throughout programming and will just have to live with them :(
Sure, the last thing I want is to start a flame war on this topic. I was just expressing my opinion about the naming - I would still call the current project "session" (see my response to Dimitar why), but this is really not that important.
And to be clear, I'm not saying that the way the project support works now is completely wrong either. I can imagine it works pretty well for small projects like geany itself. At university I was using SciTE as the editor for everything and it was just fine (yes, and SciTE calls the thing "session" ;-). But for projects with thousands of source files and hundreds of directories it's just no fun, believe me. And neither eclipse nor codeblocks work well for such big projects because they do crazy "automatic" things that are supposed to "simplify your life". I have submitted many patches for codeblocks until I realized it's just unfixable in principle. And back then I just had no idea that there is such a nice editor like geany (it really needs better marketing!).
- Is there any technical reason why searches and builds cannot be
interrupted?
The short answer is yes.
The longer answer is that since the user can run any build tool it is generally not possible to guarantee safe killing of builds, so it isn't allowed in 0.19. Also just killing the head process isn't guaranteed to stop builds using remotes.
I don't really need that it's guaranteed that the program stops, but it would be good if geany at least tried. Sending SIGINT and SIGKILL two seconds later if the program does not stop would be fine with me.
Killing head process may not kill build, especially remote ones. When we last had discussions on this I happened to be consulting to a company whose build servers had just this annoying characteristic so can speak with sad authority.
It is understood that for large systems this is an annoyance, so in the next version of the build system it is intended to be configurable, off by default, but if you know what you are doing you can turn it on and define the action required, kill the process and/or run some command eg to stop the build farm.
Then geany should provide a way to tell me the PID of the process.
Won't be needed when you can configure the kill into Geany, patience :D
Good to hear it is being worked on (and that it won't have to be me who implements this ;-).
(I'm pretty curious how you're going to kill the remote builds.)
Cheers,
Jiri
Cheers Lex
On Wed, 9 Jun 2010 13:06:45 +0200 Jiří Techet techet@gmail.com wrote:
Sure its easier if everyone is using git, but ATM this is an SVN project.
It's true that I've used the workflow typical for a git project - from geany web page, which offers both git and SVN repository I assumed that I can chose either of them. If git is not supposed to be used, then it should be removed from there because this makes things confusing (or at least there should be a warning saying: "Don't use the following git repository").
It's pretty clear from the GIT page that it's a read-only mirror. We don't have a writable GIT repo.
Anyway, no problem for me to provide the changes in the form of individual patches. I'll just wait for the main developer's opinion on this before spamming with additional emails.
Individual patches are better. That saves us time. Just looking through a Git repository isn't a good way to explain changes.
Regards, Nick
On Wed, Jun 9, 2010 at 15:06, Nick Treleaven nick.treleaven@btinternet.com wrote:
On Wed, 9 Jun 2010 13:06:45 +0200 Jiří Techet techet@gmail.com wrote:
Sure its easier if everyone is using git, but ATM this is an SVN project.
It's true that I've used the workflow typical for a git project - from geany web page, which offers both git and SVN repository I assumed that I can chose either of them. If git is not supposed to be used, then it should be removed from there because this makes things confusing (or at least there should be a warning saying: "Don't use the following git repository").
It's pretty clear from the GIT page that it's a read-only mirror. We don't have a writable GIT repo.
OK, I've just noticed:
"Read-only mirrors of the SVN repositories, updated shortly after real commits in the SVN repository."
But then I don't see the point of providing it if you cannot pull other people's clones of your repo.
Anyway, no problem for me to provide the changes in the form of individual patches. I'll just wait for the main developer's opinion on this before spamming with additional emails.
Individual patches are better. That saves us time. Just looking through a Git repository isn't a good way to explain changes.
OK, will send them later today
Regards,
Jiri
On Wed, 9 Jun 2010 15:36:32 +0200 Jiří Techet techet@gmail.com wrote:
It's pretty clear from the GIT page that it's a read-only mirror. We don't have a writable GIT repo.
OK, I've just noticed:
"Read-only mirrors of the SVN repositories, updated shortly after real commits in the SVN repository."
But then I don't see the point of providing it if you cannot pull other people's clones of your repo.
So people can commit locally.
Regards, Nick
Am 09.06.2010 13:06, schrieb Jiří Techet:
It's true that I've used the workflow typical for a git project - from geany web page, which offers both git and SVN repository I assumed that I can chose either of them. If git is not supposed to be used, then it should be removed from there because this makes things confusing (or at least there should be a warning saying: "Don't use the following git repository").
Doesn't it clearly say that the git repo is a read-only mirror? And you can pull from it like normal, you just cannot push to it. I don't see why it shouldn't be used.
On Wed, Jun 9, 2010 at 15:16, Thomas Martitz thomas.martitz@student.htw-berlin.de wrote:
Am 09.06.2010 13:06, schrieb Jiří Techet:
It's true that I've used the workflow typical for a git project - from geany web page, which offers both git and SVN repository I assumed that I can chose either of them. If git is not supposed to be used, then it should be removed from there because this makes things confusing (or at least there should be a warning saying: "Don't use the following git repository").
Doesn't it clearly say that the git repo is a read-only mirror? And you can pull from it like normal, you just cannot push to it. I don't see why it shouldn't be used.
Yes, my fault. I should read more carefully before posting a rant. Please forget my comments regarding git. (Switching to git would be really nice though).
Jiri
Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
On 9 June 2010 21:06, Jiří Techet techet@gmail.com wrote:
On Wed, Jun 9, 2010 at 03:40, Lex Trotman elextr@gmail.com wrote:
Hi again,
Note I wasn't criticising your plugin, but wanted to make sure you knew about some potential upcoming capabilities that might also be useful in combination.
I absolutely understand. In fact, I prefer critical voices - it makes no sense to say each other how good we are (we know that already, don't we ;-). So please take also my comments in this sense.
OK, I understand. Still in certain situations it's better to have several different projects (here I mean project in the sense I understand it) opened in the single instance. Won't remove this feature ;-)
Oh sure, I wasn't suggesting you should.
Was rather joke from my side. On the other hand "removing features" was the way I developed the plugin - originally I planned many more features but then ended with a minimal consistent set of features that play well with the rest of geany.
- you can specify patterns for source and header files separately -
there is a "swap header/source" functionality that finds the corresponding header/source to the currently opened document (same base name matching header/source pattern)
Nice, I'd like to add that to the filetype config to have it available in the base Geany, sometime :).
Should be pretty easy.
Coding is easy, time is hard
Very true.
(But the coding part applies for reasonably small and simple projects like geany, not multithreaded, multiprocess, multiserver projects communicating using CORBA consisting of thousands of source files, which is something I have to work with at work).
Ah, OK, didn't know it was so close. On the other hand these are really just few-liners so might be worth considering. These are the requirements for gproject to work:
http://gitorious.org/~techy/geany/techys-geany/commit/6806f193b475e24dee649d...
http://gitorious.org/~techy/geany/techys-geany/commit/0b25a1225a7425ab7d726c...
http://gitorious.org/~techy/geany/techys-geany/commit/f11ab5f59cf4201d08f04f...
And this fix should definitely go to 0.19:
http://gitorious.org/~techy/geany/techys-geany/commit/62deb4ec5c2b8de4d0979c...
I think I didn't properly describe this one in the commit log - there is a 600ms interval in which the panel displaying the current file name isn't displayed. If you switch tabs with a keybinding and do it too quickly (press it twice in the 600ms period), the wrong file is put on top of the stack. The patch could be smaller but I found the code a little confusing so I tried to make it clearer a bit.
Ok, up to the guys if they have time.
Sure.
The few more patches are trivial ones. The changebar patch is meant just for testing and not for integration to 0.19.
I'd like to suggest you tag commits you are going to refer to, not leave them as hashes, which of the links above is this one?
None ;-). Instead of tags I created different branches (described in my original mail) - if you want to quickly see what's in the branches, just click the branch name here:
My misunderstanding
http://gitorious.org/~techy/geany/techys-geany
(branches: changebar fixes gproject-deps all) The first three links are from the gproject-deps branch and the last one from the fixes branch. The changebar is, not surprisingly, in the changebar branch.
That seems a bit confusing, maybe we should call them all Bruce (Monty Python reference :)
Again, unless contradicted, you should submit your changes as individual patches, one per change with explanation, so they can be reviewed one at a time. Having to grab them all from your repository makes the job too big and less likely to happen.
Huh, really? What makes the job "too big" exactly? The reason why I submitted the patches this way is just the opposite - to make them easier to merge. You just "git pull" and that's it. As I said, as a maintainer of an open source project I prefer patches submitted this way but it's no problem for me to submit them in the traditional way (after all, anyone can do that by runing git format-patch after cloning the repository - I still don't see your point).
The point is you are forcing people to clone your repo to get the patch.
Then, which commits are meant to be individual patches?
The master branch is equivalent to geany mainline, the branches contain my patches (quite a standard way how to submit patches with git). My repo is a clone of the geany project I've created here:
It would be best if this was taken over by the geany developers and kept up to date with the current mainline.
Since as I said above, treating the whole set as one change is less acceptable than smaller individual patches, harder to review. Thats what I meant by too big.
Well, there is no "whole set" there - the individual patches are in the form of commits.
Sure its easier if everyone is using git, but ATM this is an SVN project.
It's true that I've used the workflow typical for a git project - from geany web page, which offers both git and SVN repository I assumed that I can chose either of them. If git is not supposed to be used, then it should be removed from there because this makes things confusing (or at least there should be a warning saying: "Don't use the following git repository").
It does say read only, I'd take that as meaning you can't push to this.
Anyway, no problem for me to provide the changes in the form of individual patches. I'll just wait for the main developer's opinion on this before spamming with additional emails.
Good idea.
I can see that there are people here not so much familiar with git, so I'll just describe in more detail how to get the modified geany and the plugin (the following gets the "all" branch that contains all the patches):
For geany, do the following:
git clone git@gitorious.org:~techy/geany/techys-geany.git cd to the downloaded directory git checkout remotes/origin/all -b all build and install geany
For the plugin do the following:
git clone git@gitorious.org:gproject/mainline.git cd to the downloaded directory ./autogen.sh; make; sudo make install
Sigh, this isn't your fault, but I have problems with installing unknown software to system directories and plugins autofools is broken WRT installing to a non-standard prefix, waf build works if your plugin had a wscript.
Finally, there are a few things I dislike about geany and that I'd wish to be addressed in some way:
- I'd like to have the same "rights" as the session-based project
support has. However, there are things I just can't do - I can't set the base directory where build is performed,
In 0.19 the working directory of a build can be set by the user, after that release it is intended that the next version of the build system will have a plugin API so that the plugin can set commands, other users want to do things like setting commands based on file contents and other "interesting" things. ;-S In fact because of the apparent complexity that the "set build commands" dialog will have, Geany will contain only a cut down version and the full dialog will be in a plugin.
To be honest, I find the new build dialog in 0.19 (and how it interacts with the session-project) pretty confusing - when you use it for the first time, you have no idea what it does (I had to look at the sources to be sure).
As I said there is more of build-system changes to come after 0.19, please provide input for how the dialog and the documentation (so you don't have to read the source) can be improved (on another thread as OT for this one). Note the intention is that there will be a simple and a full featured dialog, I doubt the full featured one will be automatically usable without RTFM, but the simple one should be, so all inputs that help getting to that situation are welcome.
It's quite against the overall geany spirit,
where you just know immediately how things work. And "Non-Filetype Commands" belongs among the most absurd settings names I've ever seen.
Please explain why and alternatives, obviously I knew what I meant and no one else criticised it (so far) so I need to understand why it confuses you to be able to fix it.
Well, what I dislike is that there is _any_ build dialog like this in geany. The only thing that should be possible is to:
- run a user provided command
- in the user provided (base) directory
(And this is basically what geany used to do before 0.19) Plugins should be allowed to change these two depending on their needs (not possible now).
As I said coming, patience :-)
Period. Nothing more. For more complex projects you
should use makefiles so the user provided command will be "make" executed in the base directory of the project.
In another post on this thread you complain about IDEs that limit how projects work (agree completely BTW), but you would restrict Geany to only one build tool? ;-)
The update to the build system is to support running any commands, make,nmake, waf, scons, cmake, ant, bjam, my_favourite_shell_script etc so the "Non-filetype commands" can't be called "make commands" anymore, and unfortunately the name "Build" has been appropriated for link, other suggestions welcome though, but there aren't many commonly understood terms about.
It is also to allow the commands to be configured differently for different projects, since, if you use software from lots of sources, you get lots of build systems.
I can't set per-project
indentation options and so on. (It's totally unclear to me how I'm supposed to use the GeanyProject structure - apparently it's meant to be read-only, but then what is it good for?)
It has to be read only because the code in Geany assumes that it meets certain invariants, if you could modify it you could break it. Same for build info for now. The guys are happy to consider requests for additions to the API, such as setting indentations, but please submit them early in the release cycle.
The best thing would be to make the current session-based project just an ordinary plugin - this way it would be guaranteed that all it uses is available for other plugins too.
If it was being added today, maybe it would be done that way, but now it would be too much work for too little gain IMHO.
The most important thing is that geany stops accessing GeanyProject struct directly. It should be the project that requests e.g. setting the base directory, not geany reading it from the project's data structures.
I'm not quite sure what you mean, sure your plugin needs to be able to set the project base directory and API is needed for that. So you will be requesting a change to the setting. That anything in Geany that uses this info reads it from a structure called a GeanyProject seems irrelevant, it has to be somewhere :).
But this is pretty easy to fix - I can do that (and
possibly convert the current project to plugin) if there is general interest in that.
- I find the session-based project conceptually wrong - having several
files opened doesn't mean that they belong to the same project - for instance I often work on several projects in parallel and have their files opened in parallel. Briefly, session != project
Depends on your definition of "project", for Geany a project is just a set of files that you are working on at one time, whether they reside in one tree or not. IIUC your definition is "files in one tree". Neither is "correct" just different.
I understand the semantics, but I don't understand why it isn't called "session". Of course you can call it project, but the rest of the world uses the the word project for something different. I would just use the same naming as everybody else does.
But session is also an overloaded term :), used to refer to the window manager functionality, see also the sm branch which isn't related to the Geany project functionality.
No one is going to win this argument, we have overloaded terms throughout programming and will just have to live with them :(
Sure, the last thing I want is to start a flame war on this topic. I was just expressing my opinion about the naming - I would still call the current project "session" (see my response to Dimitar why), but this is really not that important.
And to be clear, I'm not saying that the way the project support works now is completely wrong either. I can imagine it works pretty well for small projects like geany itself.
Yes its good at this.
At university I was using SciTE as
the editor for everything and it was just fine (yes, and SciTE calls the thing "session" ;-). But for projects with thousands of source files and hundreds of directories it's just no fun, believe me.
I can believe its not good at this. Is anything?
And
neither eclipse nor codeblocks work well for such big projects because they do crazy "automatic" things that are supposed to "simplify your life". I have submitted many patches for codeblocks until I realized it's just unfixable in principle. And back then I just had no idea that there is such a nice editor like geany (it really needs better marketing!).
Yes, its the usual problem of the developers having one use case in mind, but because its good, finding that their tool gets used in much wider set of use cases. Therefore no-one has thought of making some parts of the system open for plugins, its not poor design, just progress.
OTOH I don't see why you want to take out the current project system, it shouldn't get in your way, but if it does ask about changes, and having a built in simple system for simple uses is important. Keeping simple things simple is a reason for further work on the build system so your simple needs are met by default, but my complicated ones are possible with a plugin. (oh and your complicated one for killing builds :) )
- Is there any technical reason why searches and builds cannot be
interrupted?
The short answer is yes.
The longer answer is that since the user can run any build tool it is generally not possible to guarantee safe killing of builds, so it isn't allowed in 0.19. Also just killing the head process isn't guaranteed to stop builds using remotes.
I don't really need that it's guaranteed that the program stops, but it would be good if geany at least tried. Sending SIGINT and SIGKILL two seconds later if the program does not stop would be fine with me.
Killing head process may not kill build, especially remote ones. When we last had discussions on this I happened to be consulting to a company whose build servers had just this annoying characteristic so can speak with sad authority.
It is understood that for large systems this is an annoyance, so in the next version of the build system it is intended to be configurable, off by default, but if you know what you are doing you can turn it on and define the action required, kill the process and/or run some command eg to stop the build farm.
Then geany should provide a way to tell me the PID of the process.
Only on *ix, on windows a "Pid" is an opaque pointer.
Won't be needed when you can configure the kill into Geany, patience :D
Good to hear it is being worked on (and that it won't have to be me who implements this ;-).
(I'm pretty curious how you're going to kill the remote builds.)
I won't, the default will be to kill the head process like now, but the user can select to run a command instead. Which, of course, they can configure to run whatever command stops their build servers, after all they had to configure the command or build script that started them.
Keeps Geany lightweight and not dependent on anything. And should work on windows.
Cheers,
Jiri
Cheers Lex
Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
On Wed, 9 Jun 2010 23:22:51 +1000 Lex Trotman elextr@gmail.com wrote:
Sigh, this isn't your fault, but I have problems with installing unknown software to system directories and plugins autofools is broken WRT installing to a non-standard prefix, waf build works if your plugin had a wscript.
Please explain in further detail, so that it can be fixed. Thanks.
On Wed, Jun 9, 2010 at 16:56, Chow Loong Jin hyperair@gmail.com wrote:
On Wed, 9 Jun 2010 23:22:51 +1000 Lex Trotman elextr@gmail.com wrote:
Sigh, this isn't your fault, but I have problems with installing unknown software to system directories and plugins autofools is broken WRT installing to a non-standard prefix, waf build works if your plugin had a wscript.
Ah, I think I just misread this paragraph - there were really many strange things in the geanyprj configure.ac (e.g. make distcheck didn't work because of the hardcoded plugin directory) - that's why I modified it quite heavily and installing to arbitrary prefix should work (at least make distcheck, which tests this, works now).
Regards,
Jiri
Please explain in further detail, so that it can be fixed. Thanks.
-- Kind regards, Chow Loong Jin
Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Hi Chow,
remembering that I'm AC_illiterate :) the problem seems to be that plugins configure where they install based on where geany's pkg-config says, ignoring what the --prefix option says.
The --prefix should override the standard location
Cheers Lex
On 10 June 2010 00:56, Chow Loong Jin hyperair@gmail.com wrote:
On Wed, 9 Jun 2010 23:22:51 +1000 Lex Trotman elextr@gmail.com wrote:
Sigh, this isn't your fault, but I have problems with installing unknown software to system directories and plugins autofools is broken WRT installing to a non-standard prefix, waf build works if your plugin had a wscript.
Please explain in further detail, so that it can be fixed. Thanks.
-- Kind regards, Chow Loong Jin
Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
On Thu, 10 Jun 2010 11:16:53 +1000 Lex Trotman elextr@gmail.com wrote:
Hi Chow,
remembering that I'm AC_illiterate :) the problem seems to be that plugins configure where they install based on where geany's pkg-config says, ignoring what the --prefix option says.
The --prefix should override the standard location
Ah yes, there was that issue. My intention was for it to use Geany's prefix, simply because there really isn't a point in stuffing plugins where you don't have a Geany installation. e.g. Geany in /usr, but geany-plugins at /usr/local would cause some confusion. Hence, what was done was:
1. autodetect Geany's ${pkglibdir} and install plugins in there. 2. Allow manual specification of Geany's prefix by --with-geany-prefix=/some/other/path
Come to think of it, I don't really remember why I wanted to use --with-geany-prefix separately from --prefix. Perhaps --with-geany-prefix's functionality should be shifted to --prefix instead. What do you think? That should fix all your issues.
On 10 June 2010 16:23, Chow Loong Jin hyperair@gmail.com wrote:
On Thu, 10 Jun 2010 11:16:53 +1000 Lex Trotman elextr@gmail.com wrote:
Hi Chow,
remembering that I'm AC_illiterate :) the problem seems to be that plugins configure where they install based on where geany's pkg-config says, ignoring what the --prefix option says.
The --prefix should override the standard location
Ah yes, there was that issue. My intention was for it to use Geany's prefix, simply because there really isn't a point in stuffing plugins where you don't have a Geany installation. e.g. Geany in /usr, but geany-plugins at /usr/local would cause some confusion. Hence, what was done was:
- autodetect Geany's ${pkglibdir} and install plugins in there.
Oh yes thats correct for system installed versions.
- Allow manual specification of Geany's prefix by
--with-geany-prefix=/some/other/path
Ahhh, I'd never heard of the --with-geany-prefix option, that would be why I didn't use it.
Come to think of it, I don't really remember why I wanted to use --with-geany-prefix separately from --prefix. Perhaps --with-geany-prefix's functionality should be shifted to --prefix instead. What do you think? That should fix all your issues.
Yes I think that would do it, thanks,
I guess I am expecting that if I configured a version of Geany with --prefix then plugins configured the same would link with the ABI and install in the directories of the Geany with the same --prefix.
For testing a plugin like Jiri's which needs a modified version of Geany to run, it needs to use the version of Geany with the patches in it, not the system install.
Cheers Lex
-- Kind regards, Chow Loong Jin
Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
On Thu, 10 Jun 2010 17:41:13 +1000 Lex Trotman elextr@gmail.com wrote:
On 10 June 2010 16:23, Chow Loong Jin hyperair@gmail.com wrote:
On Thu, 10 Jun 2010 11:16:53 +1000 Lex Trotman elextr@gmail.com wrote:
Hi Chow,
remembering that I'm AC_illiterate :) the problem seems to be that plugins configure where they install based on where geany's pkg-config says, ignoring what the --prefix option says.
The --prefix should override the standard location
Ah yes, there was that issue. My intention was for it to use Geany's prefix, simply because there really isn't a point in stuffing plugins where you don't have a Geany installation. e.g. Geany in /usr, but geany-plugins at /usr/local would cause some confusion. Hence, what was done was:
- autodetect Geany's ${pkglibdir} and install plugins in there.
Oh yes thats correct for system installed versions.
- Allow manual specification of Geany's prefix by
--with-geany-prefix=/some/other/path
Ahhh, I'd never heard of the --with-geany-prefix option, that would be why I didn't use it.
Come to think of it, I don't really remember why I wanted to use --with-geany-prefix separately from --prefix. Perhaps --with-geany-prefix's functionality should be shifted to --prefix instead. What do you think? That should fix all your issues.
Yes I think that would do it, thanks,
I guess I am expecting that if I configured a version of Geany with --prefix then plugins configured the same would link with the ABI and install in the directories of the Geany with the same --prefix.
For testing a plugin like Jiri's which needs a modified version of Geany to run, it needs to use the version of Geany with the patches in it, not the system install.
Actually I think it's now --with-geany-libdir, since ${libdir} is not necessarily /usr/lib on all platforms. But it's broken, since I forgot to change one instance of "geany-prefix" to "geany-libdir" in geany.m4. I'll fix it immediately, for the time being. I'll implement the changes I mentioned after 0.19 is out.
On Thu, Jun 10, 2010 at 08:23, Chow Loong Jin hyperair@gmail.com wrote:
On Thu, 10 Jun 2010 11:16:53 +1000 Lex Trotman elextr@gmail.com wrote:
Hi Chow,
remembering that I'm AC_illiterate :) the problem seems to be that plugins configure where they install based on where geany's pkg-config says, ignoring what the --prefix option says.
The --prefix should override the standard location
Ah yes, there was that issue. My intention was for it to use Geany's prefix, simply because there really isn't a point in stuffing plugins where you don't have a Geany installation. e.g. Geany in /usr, but geany-plugins at /usr/local would cause some confusion. Hence, what was done was:
- autodetect Geany's ${pkglibdir} and install plugins in there.
- Allow manual specification of Geany's prefix by
--with-geany-prefix=/some/other/path
Come to think of it, I don't really remember why I wanted to use --with-geany-prefix separately from --prefix. Perhaps --with-geany-prefix's functionality should be shifted to --prefix instead. What do you think? That should fix all your issues.
You can have a look what I do in gproject:
http://gitorious.org/gproject/mainline/blobs/master/configure.ac http://gitorious.org/gproject/mainline/blobs/master/src/Makefile.am
I would say it's sufficient this way, or do you see some problem there?
Jiri
On Thu, 10 Jun 2010 17:29:26 +0200 Jiří Techet techet@gmail.com wrote:
On Thu, Jun 10, 2010 at 08:23, Chow Loong Jin hyperair@gmail.com wrote:
On Thu, 10 Jun 2010 11:16:53 +1000 Lex Trotman elextr@gmail.com wrote:
Hi Chow,
remembering that I'm AC_illiterate :) the problem seems to be that plugins configure where they install based on where geany's pkg-config says, ignoring what the --prefix option says.
The --prefix should override the standard location
Ah yes, there was that issue. My intention was for it to use Geany's prefix, simply because there really isn't a point in stuffing plugins where you don't have a Geany installation. e.g. Geany in /usr, but geany-plugins at /usr/local would cause some confusion. Hence, what was done was:
- autodetect Geany's ${pkglibdir} and install plugins in there.
- Allow manual specification of Geany's prefix by
--with-geany-prefix=/some/other/path
Come to think of it, I don't really remember why I wanted to use --with-geany-prefix separately from --prefix. Perhaps --with-geany-prefix's functionality should be shifted to --prefix instead. What do you think? That should fix all your issues.
You can have a look what I do in gproject:
http://gitorious.org/gproject/mainline/blobs/master/configure.ac http://gitorious.org/gproject/mainline/blobs/master/src/Makefile.am
I would say it's sufficient this way, or do you see some problem there?
You also need to export PKG_CONFIG_PATH=${libdir}/geany prior to PKG_CHECK_MODULES, so that you get the correct GEANY_CFLAGS and GEANY_LIBS (otherwise it'll take the system-wide one for compiling).
On Thu, Jun 10, 2010 at 18:21, Chow Loong Jin hyperair@gmail.com wrote:
On Thu, 10 Jun 2010 17:29:26 +0200 Jiří Techet techet@gmail.com wrote:
On Thu, Jun 10, 2010 at 08:23, Chow Loong Jin hyperair@gmail.com wrote:
On Thu, 10 Jun 2010 11:16:53 +1000 Lex Trotman elextr@gmail.com wrote:
Hi Chow,
remembering that I'm AC_illiterate :) the problem seems to be that plugins configure where they install based on where geany's pkg-config says, ignoring what the --prefix option says.
The --prefix should override the standard location
Ah yes, there was that issue. My intention was for it to use Geany's prefix, simply because there really isn't a point in stuffing plugins where you don't have a Geany installation. e.g. Geany in /usr, but geany-plugins at /usr/local would cause some confusion. Hence, what was done was:
- autodetect Geany's ${pkglibdir} and install plugins in there.
- Allow manual specification of Geany's prefix by
--with-geany-prefix=/some/other/path
Come to think of it, I don't really remember why I wanted to use --with-geany-prefix separately from --prefix. Perhaps --with-geany-prefix's functionality should be shifted to --prefix instead. What do you think? That should fix all your issues.
You can have a look what I do in gproject:
http://gitorious.org/gproject/mainline/blobs/master/configure.ac http://gitorious.org/gproject/mainline/blobs/master/src/Makefile.am
I would say it's sufficient this way, or do you see some problem there?
You also need to export PKG_CONFIG_PATH=${libdir}/geany prior to PKG_CHECK_MODULES, so that you get the correct GEANY_CFLAGS and GEANY_LIBS (otherwise it'll take the system-wide one for compiling).
True, thanks for the hint.
Jiri
Hi,
http://gitorious.org/~techy/geany/techys-geany
(branches: changebar fixes gproject-deps all) The first three links are from the gproject-deps branch and the last one from the fixes branch. The changebar is, not surprisingly, in the changebar branch.
That seems a bit confusing, maybe we should call them all Bruce (Monty Python reference :)
NI !
It's true that I've used the workflow typical for a git project - from geany web page, which offers both git and SVN repository I assumed that I can chose either of them. If git is not supposed to be used, then it should be removed from there because this makes things confusing (or at least there should be a warning saying: "Don't use the following git repository").
It does say read only, I'd take that as meaning you can't push to this.
Of course I can't push to it but the project maintainers could pull from me and push by themselves (for git projects typically only one person has push rights, the others just ask the maintainer for pulling from their tree and if he likes the patches, he pushes them to the main repository).
But you are right, I've overlooked that this is just a SVN mirror.
Anyway, no problem for me to provide the changes in the form of individual patches. I'll just wait for the main developer's opinion on this before spamming with additional emails.
Good idea.
I can see that there are people here not so much familiar with git, so I'll just describe in more detail how to get the modified geany and the plugin (the following gets the "all" branch that contains all the patches):
For geany, do the following:
git clone git@gitorious.org:~techy/geany/techys-geany.git cd to the downloaded directory git checkout remotes/origin/all -b all build and install geany
For the plugin do the following:
git clone git@gitorious.org:gproject/mainline.git cd to the downloaded directory ./autogen.sh; make; sudo make install
Sigh, this isn't your fault, but I have problems with installing unknown software to system directories and plugins autofools is broken WRT installing to a non-standard prefix, waf build works if your plugin had a wscript.
And I dislike using non-standard solutions (as standard I consider autotools, despite all its drawbacks), so we have a nice deadlock here :-).
Well, what I dislike is that there is _any_ build dialog like this in geany. The only thing that should be possible is to:
- run a user provided command
- in the user provided (base) directory
(And this is basically what geany used to do before 0.19) Plugins should be allowed to change these two depending on their needs (not possible now).
As I said coming, patience :-)
Period. Nothing more. For more complex projects you
should use makefiles so the user provided command will be "make" executed in the base directory of the project.
In another post on this thread you complain about IDEs that limit how projects work (agree completely BTW), but you would restrict Geany to only one build tool? ;-)
Not only one, but only _the_ one the user provides. The dialog should look this way:
Build command: edit_box Base directory: edit_box
so if I provide something like
Build command: make Base directory: /home/techet/projects/geany
it would run:
cd /home/techet/projects/geany make
(+ there should be a possibility to use the variables like %e, %f, ...)
The update to the build system is to support running any commands, make,nmake, waf, scons, cmake, ant, bjam, my_favourite_shell_script
But the current build system (and the one present in 0.18) already _can_ do that, see above. And yes, at work I use my own script that based on the current file detects the current subsystem, runs other necessary scripts and starts the build of the subsystem. Why do we need the special cases as above?
etc so the "Non-filetype commands" can't be called "make commands" anymore, and unfortunately the name "Build" has been appropriated for link, other suggestions welcome though, but there aren't many commonly understood terms about.
It is also to allow the commands to be configured differently for different projects, since, if you use software from lots of sources, you get lots of build systems.
For this I would suggest just a list of build_command/base_directory pairs that the user can save, load and delete.
The most important thing is that geany stops accessing GeanyProject struct directly. It should be the project that requests e.g. setting the base directory, not geany reading it from the project's data structures.
I'm not quite sure what you mean, sure your plugin needs to be able to set the project base directory and API is needed for that. So you will be requesting a change to the setting. That anything in Geany that uses this info reads it from a structure called a GeanyProject seems irrelevant, it has to be somewhere :).
Well, I find the way things work now pretty hacky. Geany is interested in only about two or three members of the structure - the rest is irrelevant for geany but still the whole structure has to be passed to geany. If for these members there exist new accessing methods in the API, the session-project should start using them too and geany should use its own internal structure where only the needed members are used.
And to be clear, I'm not saying that the way the project support works now is completely wrong either. I can imagine it works pretty well for small projects like geany itself.
Yes its good at this.
At university I was using SciTE as
the editor for everything and it was just fine (yes, and SciTE calls the thing "session" ;-). But for projects with thousands of source files and hundreds of directories it's just no fun, believe me.
I can believe its not good at this. Is anything?
geany + gproject ;-)
What you need is to be able to quickly navigate between the files. For this reason I had to fix the tab switching bug and introduced header/source swapping.
You need to be able to filter out as many extra files as possible (that's why only the files that match the pattern you provide are included in the project).
You need fast searches in files. grep is pretty fast when you restrict it only to the source files. So the plugin uses the patterns you provide as a definition of the files belonging to the project and automatically adds the restrictions as an extra potion in the find in files dialog; e.g.
--include=*.c --include=*.h
The first search is always slow, because the project files have to be read from the disk. But the subsequent searches are pretty fast because the files are already cached by the OS. So searching for "torvalds" in the whole linux tree (only *.c and *.h files) takes just about 3 seconds.
Then you need to be able to quickly find a file by name. In my plugin you can use an arbitrary glob pattern for that (the leading and trailing * are inserted for you so you just need to type a part of the file name).
Also building the file tree should be as fast as possible. Again, this is relatively slow when you open the project for the first time, but any subsequent project opening is very fast (2 seconds for linux kernel, from this only about 0.5 second creating the file tree).
Also there is also a feature that the selected file in the file tree automatically follows the currently opened file - so the tree automatically expands and locates the current file for you - this simplifies locating the current subsystem.
And most importantly, the editor should be relatively sane and not to try to reparse the whole project every time you edit or save something - 100pct CPU usage is guaranteed all the time in this case.
The current geany attempt to project is not good enough - I can't open 10000 files. On the other hand, geany doesn't provide a good enough way how to quickly access non-opened files, which is the purpose of my plugin.
And
neither eclipse nor codeblocks work well for such big projects because they do crazy "automatic" things that are supposed to "simplify your life". I have submitted many patches for codeblocks until I realized it's just unfixable in principle. And back then I just had no idea that there is such a nice editor like geany (it really needs better marketing!).
Yes, its the usual problem of the developers having one use case in mind, but because its good, finding that their tool gets used in much wider set of use cases. Therefore no-one has thought of making some parts of the system open for plugins, its not poor design, just progress.
OTOH I don't see why you want to take out the current project system, it shouldn't get in your way, but if it does ask about changes, and having a built in simple system for simple uses is important. Keeping simple things simple is a reason for further work on the build system so your simple needs are met by default, but my complicated ones are possible with a plugin. (oh and your complicated one for killing builds :) )
I absolutely don't wish to replace the current system - it's OK for simple use cases (the reason why I wanted to make it plugin was to make absolutely sure that the API contains all the required functionality for whatever project management plugin). I only wish to create an alternative project management that works well with huge projects. All I want is that I can do the same things as the current session-project does - which I can't now (and also if there was just me, I would rename the current project to "session" and gproject to "project" :-)
And my plugin keeps simple things simple - I hope one day in the future some brave man will actually test it to see...
(I'm pretty curious how you're going to kill the remote builds.)
I won't, the default will be to kill the head process like now, but
Like now? There is nothing like that now AFAIK.
Jiri
Hi again,
<snip>
Sigh, this isn't your fault, but I have problems with installing unknown software to system directories and plugins autofools is broken WRT installing to a non-standard prefix, waf build works if your plugin had a wscript.
And I dislike using non-standard solutions (as standard I consider autotools, despite all its drawbacks), so we have a nice deadlock here :-).
Your prerogative, but it means that I won't test your plugin.
In another post on this thread you complain about IDEs that limit how projects work (agree completely BTW), but you would restrict Geany to only one build tool? ;-)
Not only one, but only _the_ one the user provides. The dialog should look this way:
Build command: edit_box Base directory: edit_box
Ummmm, thats what the command and working directory columns are
so if I provide something like
Build command: make Base directory: /home/techet/projects/geany
it would run:
cd /home/techet/projects/geany
Unix only, not portable, thats why the working directory isn't done that way.
make
So you don't want make object or make target???
If you do have them then you need to be able to define where the arguments and options go on each of these build commands.
Builders other than make require options and arguments in different orders, thats what started the whole build system update in the first place, the arguments Geany 0.18 pasted didn't work for some builders.
So the dialog allows the whole command to be configured, and since you are not running make any more, it allows the menu label to be changed to say what you are doing.
(+ there should be a possibility to use the variables like %e, %f, ...)
The update to the build system is to support running any commands, make,nmake, waf, scons, cmake, ant, bjam, my_favourite_shell_script
But the current build system (and the one present in 0.18) already _can_ do that, see above. And yes, at work I use my own script that based on the current file detects the current subsystem, runs other necessary scripts and starts the build of the subsystem. Why do we need the special cases as above?
See above.
etc so the "Non-filetype commands" can't be called "make commands" anymore, and unfortunately the name "Build" has been appropriated for link, other suggestions welcome though, but there aren't many commonly understood terms about.
It is also to allow the commands to be configured differently for different projects, since, if you use software from lots of sources, you get lots of build systems.
For this I would suggest just a list of build_command/base_directory pairs that the user can save, load and delete.
Thats exactly what the project preferences build tab is.
At university I was using SciTE as
the editor for everything and it was just fine (yes, and SciTE calls the thing "session" ;-). But for projects with thousands of source files and hundreds of directories it's just no fun, believe me.
I can believe its not good at this. Is anything?
geany + gproject ;-)
As we say here, this has been a paid political advertisement :-)
What you need is to be able to quickly navigate between the files. For this reason I had to fix the tab switching bug and introduced header/source swapping.
You need to be able to filter out as many extra files as possible (that's why only the files that match the pattern you provide are included in the project).
You need fast searches in files. grep is pretty fast when you restrict it only to the source files. So the plugin uses the patterns you provide as a definition of the files belonging to the project and automatically adds the restrictions as an extra potion in the find in files dialog; e.g.
--include=*.c --include=*.h
The first search is always slow, because the project files have to be read from the disk. But the subsequent searches are pretty fast because the files are already cached by the OS. So searching for "torvalds" in the whole linux tree (only *.c and *.h files) takes just about 3 seconds.
Then you need to be able to quickly find a file by name. In my plugin you can use an arbitrary glob pattern for that (the leading and trailing * are inserted for you so you just need to type a part of the file name).
Also building the file tree should be as fast as possible. Again, this is relatively slow when you open the project for the first time, but any subsequent project opening is very fast (2 seconds for linux kernel, from this only about 0.5 second creating the file tree).
Also there is also a feature that the selected file in the file tree automatically follows the currently opened file - so the tree automatically expands and locates the current file for you - this simplifies locating the current subsystem.
And most importantly, the editor should be relatively sane and not to try to reparse the whole project every time you edit or save something
- 100pct CPU usage is guaranteed all the time in this case.
The current geany attempt to project is not good enough - I can't open 10000 files. On the other hand, geany doesn't provide a good enough way how to quickly access non-opened files, which is the purpose of my plugin.
As I said before, I'm not saying there is anything wrong with your plugin, I can see the need.
OTOH I don't see why you want to take out the current project system, it shouldn't get in your way, but if it does ask about changes, and having a built in simple system for simple uses is important. Keeping simple things simple is a reason for further work on the build system so your simple needs are met by default, but my complicated ones are possible with a plugin. (oh and your complicated one for killing builds :) )
I absolutely don't wish to replace the current system - it's OK for simple use cases (the reason why I wanted to make it plugin was to make absolutely sure that the API contains all the required functionality for whatever project management plugin). I only wish to create an alternative project management that works well with huge projects. All I want is that I can do the same things as the current session-project does - which I can't now (and also if there was just me, I would rename the current project to "session" and gproject to "project" :-)
And my plugin keeps simple things simple - I hope one day in the future some brave man will actually test it to see...
See why not above.
(I'm pretty curious how you're going to kill the remote builds.)
I won't, the default will be to kill the head process like now, but
Like now? There is nothing like that now AFAIK.
Sorry to confuse, I meant like the execute menu items do now.
Cheers Lex
Jiri _______________________________________________ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
On Thu, 10 Jun 2010 10:54:46 +1000 Lex Trotman elextr@gmail.com wrote:
Sigh, this isn't your fault, but I have problems with installing unknown software to system directories and plugins autofools is broken WRT installing to a non-standard prefix, waf build works if your plugin had a wscript.
And I dislike using non-standard solutions (as standard I consider autotools, despite all its drawbacks), so we have a nice deadlock here :-).
Your prerogative, but it means that I won't test your plugin.
I have a great solution to break this deadlock. How about putting the plugin into the geany-plugins combined project, and allowing us to collaboratively maintain both the waf and autotools build systems?
As it is currently, Enrico does most of the work maintaining the waf build system, and I, autotools.
Putting your plugin into the combined geany-plugins project will also mean that your plugin will then have synchronized releases with Geany, and get packaged into major distributions easier as well. A win all round, don't you think? :-)
On 10 June 2010 16:53, Chow Loong Jin hyperair@gmail.com wrote:
On Thu, 10 Jun 2010 10:54:46 +1000 Lex Trotman elextr@gmail.com wrote:
Sigh, this isn't your fault, but I have problems with installing unknown software to system directories and plugins autofools is broken WRT installing to a non-standard prefix, waf build works if your plugin had a wscript.
And I dislike using non-standard solutions (as standard I consider autotools, despite all its drawbacks), so we have a nice deadlock here :-).
Your prerogative, but it means that I won't test your plugin.
I have a great solution to break this deadlock. How about putting the plugin into the geany-plugins combined project, and allowing us to collaboratively maintain both the waf and autotools build systems?
As it is currently, Enrico does most of the work maintaining the waf build system, and I, autotools.
Putting your plugin into the combined geany-plugins project will also mean that your plugin will then have synchronized releases with Geany, and get packaged into major distributions easier as well. A win all round, don't you think? :-)
Yes, I'd encourage Jiri to do that when his plugin is mature enough, even he notes problems that won't be fixed by the plugins release for 0.19.
Cheers Lex
-- Kind regards, Chow Loong Jin
Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
On Thu, 10 Jun 2010 17:46:37 +1000 Lex Trotman elextr@gmail.com wrote:
Yes, I'd encourage Jiri to do that when his plugin is mature enough, even he notes problems that won't be fixed by the plugins release for 0.19.
Yes of course, nothing new should enter geany-plugins until 0.19 gets released, since it's just around the corner.
On Wed, 9 Jun 2010 23:22:51 +1000 Lex Trotman elextr@gmail.com wrote:
The update to the build system is to support running any commands, make,nmake, waf, scons, cmake, ant, bjam, my_favourite_shell_script etc so the "Non-filetype commands" can't be called "make commands" anymore, and unfortunately the name "Build" has been appropriated for link, other suggestions welcome though, but there aren't many commonly understood terms about.
I agree that Non-filetype commands is not a great term. I would prefer "Global" or "General" commands, even if less specific, it's fairly clear and less tortuous.
Regards, Nick
On 10 June 2010 02:04, Nick Treleaven nick.treleaven@btinternet.com wrote:
On Wed, 9 Jun 2010 23:22:51 +1000 Lex Trotman elextr@gmail.com wrote:
The update to the build system is to support running any commands, make,nmake, waf, scons, cmake, ant, bjam, my_favourite_shell_script etc so the "Non-filetype commands" can't be called "make commands" anymore, and unfortunately the name "Build" has been appropriated for link, other suggestions welcome though, but there aren't many commonly understood terms about.
I agree that Non-filetype commands is not a great term. I would prefer "Global" or "General" commands, even if less specific, it's fairly clear and less tortuous.
Well global, to me, means the system files, which it does not change. I thought General was too general, but if most agree that it makes sense I am happy to change it.
Cheers Lex
Regards, Nick _______________________________________________ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
On Wed, 09 Jun 2010 15:11:48 +0200 Thomas Martitz thomas.martitz@student.htw-berlin.de wrote:
Am 09.06.2010 03:40, schrieb Lex Trotman:
Sure its easier if everyone is using git, but ATM this is an SVN project.
Although most, if not all, geany developers use git, don't they?
Do you mean git-svn? The Git repo is not writable.
I don't use Git for Geany, but wouldn't mind if everyone else wants to switch to it.
Regards, Nick
Am 09.06.2010 18:09, schrieb Nick Treleaven:
On Wed, 09 Jun 2010 15:11:48 +0200 Thomas Martitzthomas.martitz@student.htw-berlin.de wrote:
Am 09.06.2010 03:40, schrieb Lex Trotman:
Sure its easier if everyone is using git, but ATM this is an SVN project.
Although most, if not all, geany developers use git, don't they?
Do you mean git-svn? The Git repo is not writable.
Yes, to me it looks like the vast majority of contributors use git (and git svn to commit to the geany/geany-plugins svn). My perception may not be very accurate though.
I don't use Git for Geany, but wouldn't mind if everyone else wants to switch to it.
Maybe it would be a good time to consider it in a serious manner. I would very much appreciate a switch to git :) OTOH my opinion doesn't matter very much, I guess.
Best regards.
On Wed, 09 Jun 2010 18:15:02 +0200 Thomas Martitz thomas.martitz@student.htw-berlin.de wrote:
Am 09.06.2010 18:09, schrieb Nick Treleaven:
On Wed, 09 Jun 2010 15:11:48 +0200 Thomas Martitzthomas.martitz@student.htw-berlin.de wrote:
Am 09.06.2010 03:40, schrieb Lex Trotman:
>>> Sure its easier if everyone is using git, but ATM this is an SVN >>> project.>> Although most, if not all, geany developers use git, don't they?> Do you mean git-svn? The Git repo is not writable.Yes, to me it looks like the vast majority of contributors use git (and git svn to commit to the geany/geany-plugins svn). My perception may not be very accurate though.
I don't use Git for Geany, but wouldn't mind if everyone else wants to switch to it.
Maybe it would be a good time to consider it in a serious manner. I would very much appreciate a switch to git :) OTOH my opinion doesn't matter very much, I guess.
If Geany switches, I'd love for geany-plugins to switch as well.
On 10 June 2010 02:57, Chow Loong Jin hyperair@gmail.com wrote:
On Wed, 09 Jun 2010 18:15:02 +0200 Thomas Martitz thomas.martitz@student.htw-berlin.de wrote:
Am 09.06.2010 18:09, schrieb Nick Treleaven:
On Wed, 09 Jun 2010 15:11:48 +0200 Thomas Martitzthomas.martitz@student.htw-berlin.de wrote:
>> Am 09.06.2010 03:40, schrieb Lex Trotman:
>>> Sure its easier if everyone is using git, but ATM this is an SVN >>> project.
>> Although most, if not all, geany developers use git, don't they?
> Do you mean git-svn? The Git repo is not writable.
Yes, to me it looks like the vast majority of contributors use git (and git svn to commit to the geany/geany-plugins svn). My perception may not be very accurate though.
I don't use Git for Geany, but wouldn't mind if everyone else wants to switch to it.
Maybe it would be a good time to consider it in a serious manner. I would very much appreciate a switch to git :) OTOH my opinion doesn't matter very much, I guess.
If Geany switches, I'd love for geany-plugins to switch as well.
The switch to a dvcs would be useful since local version control would then be integrated with the main vcs (if you wanted it to be).
If Geany switches then the process needs to be decided and promulgated first.
Can personal branches be hosted on your host or only branches created by you, allows sm, the new unstable and bs to operate mostly like now, separate but globally visible. Who is your host?
Who has permissions to do what, Git can have very fine control over who can do what.
What workflow are you going to follow? eg stable branch only releases are committed to, unstable that reviewed changes and patches are committed to? or what?
Having both SVN and Git committable is difficult so everyone would have to switch.
As usual the problems are non-technical ones :)
Cheers Lex
-- Kind regards, Chow Loong Jin
Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
On Thu, Jun 10, 2010 at 02:00, Lex Trotman elextr@gmail.com wrote:
On 10 June 2010 02:57, Chow Loong Jin hyperair@gmail.com wrote:
On Wed, 09 Jun 2010 18:15:02 +0200 Thomas Martitz thomas.martitz@student.htw-berlin.de wrote:
Am 09.06.2010 18:09, schrieb Nick Treleaven:
On Wed, 09 Jun 2010 15:11:48 +0200 Thomas Martitzthomas.martitz@student.htw-berlin.de wrote:
>> Am 09.06.2010 03:40, schrieb Lex Trotman:
>>> Sure its easier if everyone is using git, but ATM this is an SVN >>> project.
>> Although most, if not all, geany developers use git, don't they?
> Do you mean git-svn? The Git repo is not writable.
Yes, to me it looks like the vast majority of contributors use git (and git svn to commit to the geany/geany-plugins svn). My perception may not be very accurate though.
I don't use Git for Geany, but wouldn't mind if everyone else wants to switch to it.
Maybe it would be a good time to consider it in a serious manner. I would very much appreciate a switch to git :) OTOH my opinion doesn't matter very much, I guess.
If Geany switches, I'd love for geany-plugins to switch as well.
The switch to a dvcs would be useful since local version control would then be integrated with the main vcs (if you wanted it to be).
If Geany switches then the process needs to be decided and promulgated first.
Can personal branches be hosted on your host or only branches created by you, allows sm, the new unstable and bs to operate mostly like now, separate but globally visible. Who is your host?
Who has permissions to do what, Git can have very fine control over who can do what.
What workflow are you going to follow? eg stable branch only releases are committed to, unstable that reviewed changes and patches are committed to? or what?
I'm a maintainer of this project:
http://projects.gnome.org/libchamplain
so I can describe my personal experience with git the way I use it (I'm not saying that it's the best workflow or that you have to use it, it's just one of the possible alternatives).
First, I use two repositories that users can pull from; one at gnome:
git://git.gnome.org/libchamplain
and one at gitorious:
http://gitorious.org/libchamplain
There is only me who can push to these repositories and I always push to both synchronously at the same time. Actually I'm pushing to the repository at gnome only because gnome projects have to use this repository - otherwise the one at gitorious would be just fine. The nice thing about gitorious is can host anyone else's clones (with their own patches) of the master repository. So contributors do their development at their own clones and once they are finished, they request a merge. Then I pull their changes and apply them if I like them. I do rebases on top of the mainline's (or the appropriate branch's) HEAD - this makes the history linear and easier to follow (I know Linus discourages from rebasing in linux kernel but for such small projects like geany and libchamplain there is very small risk that someone would start his work on top of other person's branch).
So in short I would suggest: 1. One person with push rights 2. Using gitorious (github or whatever) so contributors can have their own clones hosted somewhere 3. Using rebase to have linear history
Jiri
On Wed, 9 Jun 2010 17:09:49 +0100, Nick wrote:
On Wed, 09 Jun 2010 15:11:48 +0200 Thomas Martitz thomas.martitz@student.htw-berlin.de wrote:
Am 09.06.2010 03:40, schrieb Lex Trotman:
Sure its easier if everyone is using git, but ATM this is an SVN project.
Although most, if not all, geany developers use git, don't they?
Do you mean git-svn? The Git repo is not writable.
I don't use Git for Geany, but wouldn't mind if everyone else wants to switch to it.
Me neither. If we want, we can switch to GIT.
Since my experience with GIT is very limited so far, I don't mind which way we want to go and how to organise the repository regarding branch strategies and such. The only requirement/wish I have that we don't host the repository on gitorious or github or such social coding platforms, that sucks.
I'd prefer repo.or.cz or Sourceforge or something self-hosted.
And I think any further discussion on this topic should move into a new thread. So, the next replier should break out :).
Regards, Enrico
On Tue, 8 Jun 2010 18:59:35 +0200 Jiří Techet techet@gmail.com wrote:
And this fix should definitely go to 0.19:
http://gitorious.org/~techy/geany/techys-geany/commit/62deb4ec5c2b8de4d0979c...
I think I didn't properly describe this one in the commit log - there is a 600ms interval in which the panel displaying the current file name isn't displayed. If you switch tabs with a keybinding and do it too quickly (press it twice in the 600ms period), the wrong file is put on top of the stack. The patch could be smaller but I found the code a little confusing so I tried to make it clearer a bit.
Thanks for finding & fixing the bug. However, I'm not sure we should put this in the release as the bug isn't too important and the fix changes quite a bit of code.
BTW, why do you destroy the dialog instead of hiding it?
Regards, Nick
On Wed, Jun 9, 2010 at 14:56, Nick Treleaven nick.treleaven@btinternet.com wrote:
On Tue, 8 Jun 2010 18:59:35 +0200 Jiří Techet techet@gmail.com wrote:
And this fix should definitely go to 0.19:
http://gitorious.org/~techy/geany/techys-geany/commit/62deb4ec5c2b8de4d0979c...
I think I didn't properly describe this one in the commit log - there is a 600ms interval in which the panel displaying the current file name isn't displayed. If you switch tabs with a keybinding and do it too quickly (press it twice in the 600ms period), the wrong file is put on top of the stack. The patch could be smaller but I found the code a little confusing so I tried to make it clearer a bit.
Thanks for finding & fixing the bug. However, I'm not sure we should put this in the release as the bug isn't too important and the fix changes quite a bit of code.
Sure, as you wish. On the other hand I've been using geany with this modification for 2 months without any problem (and I find this feature quite important as I work with lots of files and want to be able to switch between them reliably) while before the tab switching just didn't work for me.
BTW, why do you destroy the dialog instead of hiding it?
It's just that I can write
if (switch_dialog)
instead of
if (switch_dialog && GTK_WIDGET_VISIBLE(switch_dialog))
but I can change that if your preference is different.
Regards,
Jiri
On Wed, 9 Jun 2010 15:10:22 +0200 Jiří Techet techet@gmail.com wrote:
BTW, why do you destroy the dialog instead of hiding it?
It's just that I can write
if (switch_dialog)
instead of
if (switch_dialog && GTK_WIDGET_VISIBLE(switch_dialog))
but I can change that if your preference is different.
When I wrote the code I assumed it would be faster to keep the dialog than reconstruct it each time, but I didn't do any benchmarking.
Another general issue is that doing more than one change in a 'patch' makes it harder to review.
Regards, Nick
On Wed, Jun 9, 2010 at 18:17, Nick Treleaven nick.treleaven@btinternet.com wrote:
On Wed, 9 Jun 2010 15:10:22 +0200 Jiří Techet techet@gmail.com wrote:
BTW, why do you destroy the dialog instead of hiding it?
It's just that I can write
if (switch_dialog)
instead of
if (switch_dialog && GTK_WIDGET_VISIBLE(switch_dialog))
but I can change that if your preference is different.
When I wrote the code I assumed it would be faster to keep the dialog than reconstruct it each time, but I didn't do any benchmarking.
Optimizations like this would make sense only if you were trying to open the window 1000-times per second, otherwise the performance difference is absolutely unimportant.
Another general issue is that doing more than one change in a 'patch' makes it harder to review.
I wanted to make the code a bit more readable, that's why there are more changes. For instance I renamed
switch_dialog_cancelled
to
switch_in_progress
(and inverted the boolean value) because the name was a bit confusing (switch_dialog_cancelled is set to FALSE [read "uncancelled", which is a bit ugly] 600ms before the switch dialog actually appears). If you wish, I can try to split it into more patches, I'm just afraid I introduce some extra bugs on the way.
I've also noticed that I mix spaces and tabs for indents - I'll fix that.
Regards,
Jiri
Regards, Nick _______________________________________________ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
On Wed, 9 Jun 2010 18:48:51 +0200 Jiří Techet techet@gmail.com wrote:
BTW, why do you destroy the dialog instead of hiding it?
It's just that I can write
if (switch_dialog)
instead of
if (switch_dialog && GTK_WIDGET_VISIBLE(switch_dialog))
but I can change that if your preference is different.
When I wrote the code I assumed it would be faster to keep the dialog than reconstruct it each time, but I didn't do any benchmarking.
Optimizations like this would make sense only if you were trying to open the window 1000-times per second, otherwise the performance difference is absolutely unimportant.
I suppose so in this case. For the Open dialog it may be important as that can be slow to populate.
Another general issue is that doing more than one change in a 'patch' makes it harder to review.
I wanted to make the code a bit more readable, that's why there are more changes. For instance I renamed
switch_dialog_cancelled
to
switch_in_progress
(and inverted the boolean value) because the name was a bit confusing (switch_dialog_cancelled is set to FALSE [read "uncancelled", which is a bit ugly] 600ms before the switch dialog actually appears). If you wish, I can try to split it into more patches, I'm just afraid I introduce some extra bugs on the way.
OK, don't bother.
I've also noticed that I mix spaces and tabs for indents - I'll fix that.
Regards, Nick
On Tue, 8 Jun 2010 18:59:35 +0200 Jiří Techet techet@gmail.com wrote:
To be honest, I find the new build dialog in 0.19 (and how it interacts with the session-project) pretty confusing - when you use it for the first time, you have no idea what it does (I had to look at the sources to be sure).
I assume you mean the 'Set Build Commands' dialog when you have a project open. I think that may be a bug - IMO the Project Properties Build tab should be shown instead. It is confusing ATM.
Regards, Nick
On Wed, Jun 9, 2010 at 18:15, Nick Treleaven nick.treleaven@btinternet.com wrote:
On Tue, 8 Jun 2010 18:59:35 +0200 Jiří Techet techet@gmail.com wrote:
To be honest, I find the new build dialog in 0.19 (and how it interacts with the session-project) pretty confusing - when you use it for the first time, you have no idea what it does (I had to look at the sources to be sure).
I assume you mean the 'Set Build Commands' dialog when you have a project open. I think that may be a bug - IMO the Project Properties Build tab should be shown instead. It is confusing ATM.
There are several confusing things:
1. The first section in the dialog ("filetype commands") depends on the currently opened document. This wasn't clear to me at all. First I thought that this was static. Then I noticed that it changes but I was wondering how you set the file type. I would prefer if there was a combo box where the item gets automatically selected based on the current file, but which you can also manually change. This will give people some indication that the first group is dynamic.
2. What you say - when the project is open, it's not clear whether you are editing global options or project ones. IMO by build->set build commands you should always set the global options and in project properties the project options. Things get confusing when you start changing semantics of menu items based on whether the project is open or not.
3. The popup dialog for "make custom target" should be more flexible, not hardcoded for item 2. I think there should be a new variable, e.g. %t, which, when found inside command, causes that the window appears and then substitutes %t with what the user specifies. This will make it usable for other commands too.
4. non-filetype commands deserves a better name - I quite like your "general" commands ("global" could be confused in the context of setting global/per-project options). And I would also put them first in the dialog - starting from general options to more specific options (which means that execute command should come second). I had a problem that somehow automatically I started editing the commands in the first group (filetype) even though I wanted to edit the second group (non-filetype).
OK, I wanted to write more things I dislike but after spending one hour looking at the dialog I think I start understanding what's behind it. There really needs to be a clear indication that the first group is dynamic and I think the combobox is a good way to do that.
Regards,
Jiri
On 10 June 2010 07:02, Jiří Techet techet@gmail.com wrote:
On Wed, Jun 9, 2010 at 18:15, Nick Treleaven nick.treleaven@btinternet.com wrote:
On Tue, 8 Jun 2010 18:59:35 +0200 Jiří Techet techet@gmail.com wrote:
To be honest, I find the new build dialog in 0.19 (and how it interacts with the session-project) pretty confusing - when you use it for the first time, you have no idea what it does (I had to look at the sources to be sure).
Any suggestions on how the manual could be improved, it should be RTFM, not RTFS :)
I assume you mean the 'Set Build Commands' dialog when you have a project open. I think that may be a bug - IMO the Project Properties Build tab should be shown instead. It is confusing ATM.
There are several confusing things:
- The first section in the dialog ("filetype commands") depends on
the currently opened document. This wasn't clear to me at all. First I thought that this was static. Then I noticed that it changes but I was wondering how you set the file type. I would prefer if there was a combo box where the item gets automatically selected based on the current file, but which you can also manually change. This will give people some indication that the first group is dynamic.
Its how Geany has already worked, the commands changed with current filetype.
Well it does actually say "filetype xxx commands", but your idea isn't impossible either, but see questions below.
- What you say - when the project is open, it's not clear whether you
are editing global options or project ones. IMO by build->set build commands you should always set the global options and in project properties the project options.
Thats what should happen, if you think it isn't its a bug, let me know
Things get confusing when you start
changing semantics of menu items based on whether the project is open or not.
- The popup dialog for "make custom target" should be more flexible,
not hardcoded for item 2. I think there should be a new variable, e.g. %t, which, when found inside command, causes that the window appears and then substitutes %t with what the user specifies. This will make it usable for other commands too.
Agreed, already planned to be added for v2, %c{message to show on popup} gets substituted by user input (I used c for custom not t for target :)
- non-filetype commands deserves a better name - I quite like your
"general" commands ("global" could be confused in the context of setting global/per-project options). And I would also put them first in the dialog - starting from general options to more specific options (which means that execute command should come second). I had a problem that somehow automatically I started editing the commands in the first group (filetype) even though I wanted to edit the second group (non-filetype).
Well the order has the 0.18 items first for backward compatibility, but I agree that the order isn't optimal so I planned to make it configurable (I actually want some more groups) but I havn't got a good solution for the headings (other than fixed strings, which would let you change "non-filetype" to whatever you want :) Personally I think "general" is a bit too, well, general, to be meaningful
OK, I wanted to write more things I dislike but after spending one hour looking at the dialog I think I start understanding what's behind it. There really needs to be a clear indication that the first group is dynamic and I think the combobox is a good way to do that.
But what do you do if the user changes the filetype? Do you forget any changes so far? Or you have to save them in temporary storage until the user selects apply or cancel and hope that the user meant to change both filetypes rather than starting to change one, discovering that they had the wrong type (because of the wrong current doc) and changed to the one they want. Thats why both dialogs are modal, so the current document can't be changed, so this section doesn't change.
Cheers Lex
Regards,
Jiri _______________________________________________ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
On Thu, Jun 10, 2010 at 01:25, Lex Trotman elextr@gmail.com wrote:
On 10 June 2010 07:02, Jiří Techet techet@gmail.com wrote:
On Wed, Jun 9, 2010 at 18:15, Nick Treleaven nick.treleaven@btinternet.com wrote:
On Tue, 8 Jun 2010 18:59:35 +0200 Jiří Techet techet@gmail.com wrote:
To be honest, I find the new build dialog in 0.19 (and how it interacts with the session-project) pretty confusing - when you use it for the first time, you have no idea what it does (I had to look at the sources to be sure).
Any suggestions on how the manual could be improved, it should be RTFM, not RTFS :)
I assume you mean the 'Set Build Commands' dialog when you have a project open. I think that may be a bug - IMO the Project Properties Build tab should be shown instead. It is confusing ATM.
There are several confusing things:
- The first section in the dialog ("filetype commands") depends on
the currently opened document. This wasn't clear to me at all. First I thought that this was static. Then I noticed that it changes but I was wondering how you set the file type. I would prefer if there was a combo box where the item gets automatically selected based on the current file, but which you can also manually change. This will give people some indication that the first group is dynamic.
Its how Geany has already worked, the commands changed with current filetype.
Well it does actually say "filetype xxx commands", but your idea isn't impossible either, but see questions below.
I know, but it's not clear it's dynamic. Also if you want to change the commands for N file types you have to locate N times the file with the right extension and then open the dialog - not much fun.
- What you say - when the project is open, it's not clear whether you
are editing global options or project ones. IMO by build->set build commands you should always set the global options and in project properties the project options.
Thats what should happen, if you think it isn't its a bug, let me know
Well, that's what I was talking about in the other email - if you don't override a command in the project, it appears as if you were editing both the global options and the project options simultaneously - that's really way too confusing.
Things get confusing when you start
changing semantics of menu items based on whether the project is open or not.
- The popup dialog for "make custom target" should be more flexible,
not hardcoded for item 2. I think there should be a new variable, e.g. %t, which, when found inside command, causes that the window appears and then substitutes %t with what the user specifies. This will make it usable for other commands too.
Agreed, already planned to be added for v2, %c{message to show on popup} gets substituted by user input (I used c for custom not t for target :)
- non-filetype commands deserves a better name - I quite like your
"general" commands ("global" could be confused in the context of setting global/per-project options). And I would also put them first in the dialog - starting from general options to more specific options (which means that execute command should come second). I had a problem that somehow automatically I started editing the commands in the first group (filetype) even though I wanted to edit the second group (non-filetype).
Well the order has the 0.18 items first for backward compatibility, but I agree that the order isn't optimal so I planned to make it configurable (I actually want some more groups) but I havn't got a good solution for the headings (other than fixed strings, which would let you change "non-filetype" to whatever you want :) Personally I think "general" is a bit too, well, general, to be meaningful
If I can ask for something, then please don't add any extra options to the dialog. It's already confusing enough ;-).
I know general is too general but non-filetype is so specific that nobody can imagine anything concrete under it. Unfortunately I'm pretty bad at naming things in a good way so I won't help much here.
OK, I wanted to write more things I dislike but after spending one hour looking at the dialog I think I start understanding what's behind it. There really needs to be a clear indication that the first group is dynamic and I think the combobox is a good way to do that.
But what do you do if the user changes the filetype? Do you forget any changes so far? Or you have to save them in temporary storage until the user selects apply or cancel and hope that the user meant to change both filetypes rather than starting to change one, discovering that they had the wrong type (because of the wrong current doc) and changed to the one they want. Thats why both dialogs are modal, so the current document can't be changed, so this section doesn't change.
Good point. I would probably pop up a question dialog asking whether the changed settings should be saved when the user switches between filetypes and makes some modifications (the dialog shouldn't appear if there is no modification).
Cheers,
Jiri
On 10 June 2010 02:15, Nick Treleaven nick.treleaven@btinternet.com wrote:
On Tue, 8 Jun 2010 18:59:35 +0200 Jiří Techet techet@gmail.com wrote:
To be honest, I find the new build dialog in 0.19 (and how it interacts with the session-project) pretty confusing - when you use it for the first time, you have no idea what it does (I had to look at the sources to be sure).
I assume you mean the 'Set Build Commands' dialog when you have a project open. I think that may be a bug - IMO the Project Properties Build tab should be shown instead. It is confusing ATM.
No it shouldn't open the project tab, the project menu does that. If you have a project open there are *two* places where the commands are edited, one for those defined in the project and one for those not defined in the project which still get used if no project command overrides them.
When you create a project you don't have to copy all the commands into the project, you still get the normal ones until you define one in the project which overrides the normal one.
Yes I realised a while ago it can be confusing, thats part of why I want to combine both dialogs into one in v2.0.
Cheers Lex
Regards, Nick _______________________________________________ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
On Thu, Jun 10, 2010 at 00:52, Lex Trotman elextr@gmail.com wrote:
On 10 June 2010 02:15, Nick Treleaven nick.treleaven@btinternet.com wrote:
On Tue, 8 Jun 2010 18:59:35 +0200 Jiří Techet techet@gmail.com wrote:
To be honest, I find the new build dialog in 0.19 (and how it interacts with the session-project) pretty confusing - when you use it for the first time, you have no idea what it does (I had to look at the sources to be sure).
I assume you mean the 'Set Build Commands' dialog when you have a project open. I think that may be a bug - IMO the Project Properties Build tab should be shown instead. It is confusing ATM.
No it shouldn't open the project tab, the project menu does that. If you have a project open there are *two* places where the commands are edited, one for those defined in the project and one for those not defined in the project which still get used if no project command overrides them.
When you create a project you don't have to copy all the commands into the project, you still get the normal ones until you define one in the project which overrides the normal one.
Yes I realised a while ago it can be confusing, thats part of why I want to combine both dialogs into one in v2.0.
Yes, it's pretty confusing. Once you create a project you don't expect that what you see in the build tab changes based on what change you make in the global settings (until you modify the commands in the project for the first time). This makes the project totally unportable because it depends on the global settings of the current instance of geany. So if I move the project from my home computer to work, things just can stop working because I have different global settings there.
What I would suggest is that upon project creation you make a complete copy of the global settings and since then the two are edited independently. Otherwise all the settings is a total mess.
Cheers,
Jiri
Cheers Lex
Regards, Nick _______________________________________________ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Hi,
Note to self, read the whole thread before replying to any :-) see my other reply plus below.
Yes I realised a while ago it can be confusing, thats part of why I want to combine both dialogs into one in v2.0.
Yes, it's pretty confusing. Once you create a project you don't expect that what you see in the build tab changes based on what change you make in the global settings (until you modify the commands in the project for the first time). This makes the project totally unportable because it depends on the global settings of the current instance of geany. So if I move the project from my home computer to work, things just can stop working because I have different global settings there.
What I would suggest is that upon project creation you make a complete copy
Thats just what I didn't want to do, remember there are filetype commands and execute commands too makes each project copy big.
of the global settings and since then the two are edited
independently. Otherwise all the settings is a total mess.
And you program in C++ !! I'd have thought overriding some entries only would be easy to understand :-)
Seriously, yes the whole thing should be in one dialog so that you can see what overrides what and edit the one you want, thats part of v2.0.
Cheers Lex
On Thu, Jun 10, 2010 at 03:07, Lex Trotman elextr@gmail.com wrote:
Hi,
Note to self, read the whole thread before replying to any :-) see my other reply plus below.
Yes I realised a while ago it can be confusing, thats part of why I want to combine both dialogs into one in v2.0.
Yes, it's pretty confusing. Once you create a project you don't expect that what you see in the build tab changes based on what change you make in the global settings (until you modify the commands in the project for the first time). This makes the project totally unportable because it depends on the global settings of the current instance of geany. So if I move the project from my home computer to work, things just can stop working because I have different global settings there.
What I would suggest is that upon project creation you make a complete copy
Thats just what I didn't want to do, remember there are filetype commands and execute commands too makes each project copy big.
Then I would suggest that there are no per-project filetype commands and you just copy the global ones. In project you care about a set of files so global/general/non-filetype options are the ones you want to change. This seems to be the most reasonable solution now.
But really, think about how this is agains anything the user would expect. What the user sees is that:
* sometimes changing the command in the "set build command" dialog changes the settings in the project * sometimes it doesn't change the project
and he has no indication when this happens (there is no indication that the settings has been overridden in the project dialog so it's just invisible). This is totally stupid.
of the global settings and since then the two are edited
independently. Otherwise all the settings is a total mess.
And you program in C++ !! I'd have thought overriding some entries only would be easy to understand :-)
Yes, but I didn't say I like C++ - I don't. The language is made in a completely wrong way. Unfortunately the fact is that it's one of the most wide-spread "low-level" OO languages with lots of libraries existing for it and programs written in it. But I really hope that one day it gets replaced by something like go:
But the fact that C++ does things in a stupid way doesn't mean we have to do it too. We can't change C++ but we can make geany to be easy to use. I prefer simple and less flexible GUI that is easy to use than complex "I can do all" GUI that nobody understands (and that's geany's philosophy at least from what I have seen). So as I said, I would just remove the filetype options from the project settings.
Seriously, yes the whole thing should be in one dialog so that you can see what overrides what and edit the one you want, thats part of v2.0.
No, seriously, it shouldn't. How will it work with different project plugins? Please describe how you imagine the dialog should work so I can tell you why it's not a good idea ;-).
Cheers,
Jiri
On 10 June 2010 19:44, Jiří Techet techet@gmail.com wrote:
On Thu, Jun 10, 2010 at 03:07, Lex Trotman elextr@gmail.com wrote:
Hi,
Note to self, read the whole thread before replying to any :-) see my other reply plus below.
Yes I realised a while ago it can be confusing, thats part of why I want to combine both dialogs into one in v2.0.
Yes, it's pretty confusing. Once you create a project you don't expect that what you see in the build tab changes based on what change you make in the global settings (until you modify the commands in the project for the first time). This makes the project totally unportable because it depends on the global settings of the current instance of geany. So if I move the project from my home computer to work, things just can stop working because I have different global settings there.
What I would suggest is that upon project creation you make a complete copy
Thats just what I didn't want to do, remember there are filetype commands and execute commands too makes each project copy big.
Then I would suggest that there are no per-project filetype commands and you just copy the global ones. In project you care about a set of files so global/general/non-filetype options are the ones you want to change. This seems to be the most reasonable solution now.
No, that doesn't handle when projects use different compilers or targets compared to the default ones, changing the commands in the build dialog when swapping between projects is tedious and error prone.
But really, think about how this is agains anything the user would expect. What the user sees is that:
- sometimes changing the command in the "set build command" dialog
changes the settings in the project
The set build commands *never* changes anything in the project, where defined, the project command overrides the normal ones.
- sometimes it doesn't change the project
and he has no indication when this happens (there is no indication that the settings has been overridden in the project dialog so it's just invisible). This is totally stupid.
This is unproductive, I've already said this UI is proposed to change, just repeating its bad gets us nowhere.
of the global settings and since then the two are edited
independently. Otherwise all the settings is a total mess.
And you program in C++ !! I'd have thought overriding some entries only would be easy to understand :-)
Yes, but I didn't say I like C++ - I don't. The language is made in a completely wrong way. Unfortunately the fact is that it's one of the most wide-spread "low-level" OO languages with lots of libraries existing for it and programs written in it. But I really hope that one day it gets replaced by something like go:
And I'm not getting into an argument on languages
But the fact that C++ does things in a stupid way doesn't mean we have to do it too. We can't change C++ but we can make geany to be easy to use. I prefer simple and less flexible GUI that is easy to use than complex "I can do all" GUI that nobody understands (and that's geany's philosophy at least from what I have seen). So as I said, I would just remove the filetype options from the project settings.
Seriously, yes the whole thing should be in one dialog so that you can see what overrides what and edit the one you want, thats part of v2.0.
No, seriously, it shouldn't. How will it work with different project plugins? Please describe how you imagine the dialog should work so I can tell you why it's not a good idea ;-).
As I said many posts ago, there will be an interface for plugins to set the commands to be used, so use your own dialog, the Geany dialog will just note that "This command has been set by the xxx plugin" or similar message.
Cheers Lex
Cheers,
Jiri _______________________________________________ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
On Thu, Jun 10, 2010 at 12:35, Lex Trotman elextr@gmail.com wrote:
On 10 June 2010 19:44, Jiří Techet techet@gmail.com wrote:
On Thu, Jun 10, 2010 at 03:07, Lex Trotman elextr@gmail.com wrote:
Hi,
Note to self, read the whole thread before replying to any :-) see my other reply plus below.
Yes I realised a while ago it can be confusing, thats part of why I want to combine both dialogs into one in v2.0.
Yes, it's pretty confusing. Once you create a project you don't expect that what you see in the build tab changes based on what change you make in the global settings (until you modify the commands in the project for the first time). This makes the project totally unportable because it depends on the global settings of the current instance of geany. So if I move the project from my home computer to work, things just can stop working because I have different global settings there.
What I would suggest is that upon project creation you make a complete copy
Thats just what I didn't want to do, remember there are filetype commands and execute commands too makes each project copy big.
Then I would suggest that there are no per-project filetype commands and you just copy the global ones. In project you care about a set of files so global/general/non-filetype options are the ones you want to change. This seems to be the most reasonable solution now.
No, that doesn't handle when projects use different compilers or targets compared to the default ones, changing the commands in the build dialog when swapping between projects is tedious and error prone.
I like keeping things simple, especially for features that are not used so frequently. I've *never* ever used the option to compile a single file of a project in any IDE - I've always compiled the whole project (or its subsystem). I imagine that it can be useful for individual files, but it's really not much useful for the project, so I would just remove it for the project.
One just shouldn't overdo it with trying to be as generic as possible. If you wanted to create a super-customizable project, you would have to add all the extensions from filetype_extensions.conf (by the way how does the project handle the case when some file type is defined in the project but not in filetype_extensions.conf?) and many other options.
But really, think about how this is agains anything the user would expect. What the user sees is that:
- sometimes changing the command in the "set build command" dialog
changes the settings in the project
The set build commands *never* changes anything in the project, where defined, the project command overrides the normal ones.
But there is *no* indication that something has been overridden in the project properties dialog. The user has to open the project properties file to see it; otherwise the behaviour is totally unpredictable. If you defined a project two months ago you just forget which commands have been overridden and you have no clue what you are looking at in the project properties dialog - the overridden value or the default value.
- sometimes it doesn't change the project
and he has no indication when this happens (there is no indication that the settings has been overridden in the project dialog so it's just invisible). This is totally stupid.
This is unproductive, I've already said this UI is proposed to change, just repeating its bad gets us nowhere.
Sure, that's why I'm proposing the solution above. It would be good if you could describe how the united dialog should operate because right now I just have no idea how it could help.
of the global settings and since then the two are edited
independently. Otherwise all the settings is a total mess.
And you program in C++ !! I'd have thought overriding some entries only would be easy to understand :-)
Yes, but I didn't say I like C++ - I don't. The language is made in a completely wrong way. Unfortunately the fact is that it's one of the most wide-spread "low-level" OO languages with lots of libraries existing for it and programs written in it. But I really hope that one day it gets replaced by something like go:
And I'm not getting into an argument on languages
But the fact that C++ does things in a stupid way doesn't mean we have to do it too. We can't change C++ but we can make geany to be easy to use. I prefer simple and less flexible GUI that is easy to use than complex "I can do all" GUI that nobody understands (and that's geany's philosophy at least from what I have seen). So as I said, I would just remove the filetype options from the project settings.
Seriously, yes the whole thing should be in one dialog so that you can see what overrides what and edit the one you want, thats part of v2.0.
No, seriously, it shouldn't. How will it work with different project plugins? Please describe how you imagine the dialog should work so I can tell you why it's not a good idea ;-).
I hope you didn't take my last sentence too literally - I just can't imagine how this would work so I'd like to know more details about it.
As I said many posts ago, there will be an interface for plugins to set the commands to be used, so use your own dialog, the Geany dialog will just note that "This command has been set by the xxx plugin" or similar message.
I just hope it won't be like that - the plugins should use their own set of options separate from the global (default) options. If you do something like that, how will you edit the non-overridden command?
(A note: I really don't want this thread to become a flame war. I'm just unhappy how things work now and would like do find the most easy to use solution acceptable for everybody.)
Cheers,
Jiri
On Thu, 10 Jun 2010 11:44:24 +0200 Jiří Techet techet@gmail.com wrote:
And you program in C++ !! I'd have thought overriding some entries only would be easy to understand :-)
Yes, but I didn't say I like C++ - I don't. The language is made in a completely wrong way. Unfortunately the fact is that it's one of the most wide-spread "low-level" OO languages with lots of libraries existing for it and programs written in it. But I really hope that one day it gets replaced by something like go:
Go is not a good replacement for C++, try D. Some people say Go is a good replacement for C.
Regards, Nick
On 10 June 2010 21:03, Nick Treleaven nick.treleaven@btinternet.com wrote:
On Thu, 10 Jun 2010 11:44:24 +0200 Jiří Techet techet@gmail.com wrote:
And you program in C++ !! I'd have thought overriding some entries only would be easy to understand :-)
Yes, but I didn't say I like C++ - I don't. The language is made in a completely wrong way. Unfortunately the fact is that it's one of the most wide-spread "low-level" OO languages with lots of libraries existing for it and programs written in it. But I really hope that one day it gets replaced by something like go:
Go is not a good replacement for C++, try D. Some people say Go is a good replacement for C.
And some people say that it has sadly made some decisions that prevent it being that, but with Google behind it it may succeed anyway, after all C succeeded for non technical reasons.
And some say C++ is best replaced by functional languages, if only I could get my head around tail calls.
Cheers Lex
Regards, Nick _______________________________________________ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
On Thu, 10 Jun 2010 23:23:21 +1000 Lex Trotman elextr@gmail.com wrote:
Go is not a good replacement for C++, try D. Some people say Go is a good replacement for C.
And some people say that it has sadly made some decisions that prevent it being that, but with Google behind it it may succeed anyway, after all C succeeded for non technical reasons.
And some say C++ is best replaced by functional languages, if only I could get my head around tail calls.
There may be valid arguments to replace certain (or all) uses of C++ with conceptually different languages. If this is the case, perhaps Go might appeal to some C++ users. But if you want a language that is philosophically similar to C++, D is pretty close.
D 2.0 also provides some handy features for functional programming - lazy evaluation (D1 also), immutable data, pure functions, [implicit non-sharing of memory across threads].
Regards, Nick
On Thu, Jun 10, 2010 at 15:23, Lex Trotman elextr@gmail.com wrote:
On 10 June 2010 21:03, Nick Treleaven nick.treleaven@btinternet.com wrote:
On Thu, 10 Jun 2010 11:44:24 +0200 Jiří Techet techet@gmail.com wrote:
And you program in C++ !! I'd have thought overriding some entries only would be easy to understand :-)
Yes, but I didn't say I like C++ - I don't. The language is made in a completely wrong way. Unfortunately the fact is that it's one of the most wide-spread "low-level" OO languages with lots of libraries existing for it and programs written in it. But I really hope that one day it gets replaced by something like go:
Go is not a good replacement for C++, try D. Some people say Go is a good replacement for C.
And some people say that it has sadly made some decisions that prevent it being that, but with Google behind it it may succeed anyway, after all C succeeded for non technical reasons.
It's definitely not a replacement for C - C is just a higher-level assembler that is (mis)used by projects that would normally use a higher-level language if there was a sane alternative (geany for example). You can almost see the instructions into which it translates. I can't imagine that projects like linux kernel would ever use a garbage-collected languauge.
I've never used D so I can't comment much on that but as Lex said - D has no chance because there is no big corporation behind it, while for go I see some chances. And I like many design decisions behind go - the good thing is that they have taken into account both practical and theoretical aspects. One has to make compromises (e.g. to have easy to use build commands dialog or more general dialog ;-), but I think they went the right direction. And it's fast. I spend one hour a day just compiling with C++ code.
Anyway, for practical reasons the best choice right now is to stick with C, C++, Python, and if I have to, Java. One should just use the most portable, tested and widespread language.
And some say C++ is best replaced by functional languages, if only I could get my head around tail calls.
From my experience with Haskell my impression is that functional
languages don't scale well for bigger projects, that's why they are not so much used - I've seen their uses just for toy-applications (there are exceptions like darcs, but these are real exceptions). And at the end if you want to do things like GUI or SQL, you have to use monads, which is just functional reinvention of procedural languages.
Cheers,
Jiri
On Thu, 10 Jun 2010 16:28:42 +0200 Jiří Techet techet@gmail.com wrote:
Go is not a good replacement for C++, try D. Some people say Go is a good replacement for C.
And some people say that it has sadly made some decisions that prevent it being that, but with Google behind it it may succeed anyway, after all C succeeded for non technical reasons.
It's definitely not a replacement for C - C is just a higher-level assembler that is (mis)used by projects that would normally use a higher-level language if there was a sane alternative (geany for example). You can almost see the instructions into which it translates. I can't imagine that projects like linux kernel would ever use a garbage-collected languauge.
I've never used D so I can't comment much on that but as Lex said - D has no chance because there is no big corporation behind it, while for
I agree it helps, but are there really no successful widespread languages that didn't have corporate backing?
go I see some chances. And I like many design decisions behind go - the good thing is that they have taken into account both practical and theoretical aspects. One has to make compromises (e.g. to have easy to use build commands dialog or more general dialog ;-), but I think they went the right direction.
Go doesn't give the user much power vs C++ or D. That's why I think D is a more natural replacement for C++.
And it's fast. I spend one hour a day just compiling with C++ code.
A D developer says it's faster than Go at compiling, and it has templates: http://www.digitalmars.com/pnews/read.php?server=news.digitalmars.com&gr...
Anyway, for practical reasons the best choice right now is to stick with C, C++, Python, and if I have to, Java. One should just use the most portable, tested and widespread language.
Then no better ones will come along, but I understand what you're saying.
Regards, Nick
On Thu, Jun 10, 2010 at 17:25, Nick Treleaven nick.treleaven@btinternet.com wrote:
On Thu, 10 Jun 2010 16:28:42 +0200 Jiří Techet techet@gmail.com wrote:
Go is not a good replacement for C++, try D. Some people say Go is a good replacement for C.
And some people say that it has sadly made some decisions that prevent it being that, but with Google behind it it may succeed anyway, after all C succeeded for non technical reasons.
It's definitely not a replacement for C - C is just a higher-level assembler that is (mis)used by projects that would normally use a higher-level language if there was a sane alternative (geany for example). You can almost see the instructions into which it translates. I can't imagine that projects like linux kernel would ever use a garbage-collected languauge.
I've never used D so I can't comment much on that but as Lex said - D has no chance because there is no big corporation behind it, while for
I agree it helps, but are there really no successful widespread languages that didn't have corporate backing?
Unfortunately we're not living in the 70's or 80's, where the best had a chance, and there's a lot of software written in the mainstream languages. These applications won't get rewritten just because some better language appeared (or do you plan to rewrite geany in D? :-). In the last 15 years the only successful languages were those where some big company was behind (Java, C#).
go I see some chances. And I like many design decisions behind go - the good thing is that they have taken into account both practical and theoretical aspects. One has to make compromises (e.g. to have easy to use build commands dialog or more general dialog ;-), but I think they went the right direction.
Go doesn't give the user much power vs C++ or D. That's why I think D is a more natural replacement for C++.
D looks much closer to C++, but I like the go people had a fresh look at a language design and as I said, I like many of their decisions. (I don't say it's better or worse than D - I would have to learn D first and use go for a reasonably big application.)
And it's fast. I spend one hour a day just compiling with C++ code.
A D developer says it's faster than Go at compiling, and it has templates: http://www.digitalmars.com/pnews/read.php?server=news.digitalmars.com&gr...
Well, it really depends if he was compiling a single file or a library with many includes. What makes the compilation of C++ slow is that it has to parse the same headers again and again every time they are included (and all the includes inside the includes). This is eliminated in go. If D uses includes, then it will be slow for big projects too.
Jiri
On Thu, 10 Jun 2010 17:48:39 +0200 Jiří Techet techet@gmail.com wrote:
I agree it helps, but are there really no successful widespread languages that didn't have corporate backing?
Unfortunately we're not living in the 70's or 80's, where the best had a chance, and there's a lot of software written in the mainstream
I think that's a bit pessimistic.
languages. These applications won't get rewritten just because some better language appeared (or do you plan to rewrite geany in D? :-). In the last 15 years the only successful languages were those where some big company was behind (Java, C#).
It's not normally a good idea to rewrite applications. But new applications could be written in a language like D or Go (obviously).
Any successful language will need to interface well with C.
And it's fast. I spend one hour a day just compiling with C++ code.
A D developer says it's faster than Go at compiling, and it has templates: http://www.digitalmars.com/pnews/read.php?server=news.digitalmars.com&gr...
Well, it really depends if he was compiling a single file or a library
The link says: "So the go compiler compiles 120KLOC in 9.23 seconds. I got curious so I just tested dmd against Phobos (88KLOC). That takes 1.24 seconds on my laptop."
Phobos is D's standard library, and includes templates quite a bit.
with many includes. What makes the compilation of C++ slow is that it has to parse the same headers again and again every time they are included (and all the includes inside the includes). This is eliminated in go. If D uses includes, then it will be slow for big projects too.
It doesn't use includes per say, but compiler-generated .di files. C++ parsing is slow anyway because of templates.
(I think both D and Go have ways to speed up compilation further).
Regards, Nick
On 11 June 2010 02:15, Nick Treleaven nick.treleaven@btinternet.com wrote:
On Thu, 10 Jun 2010 17:48:39 +0200 Jiří Techet techet@gmail.com wrote:
I agree it helps, but are there really no successful widespread languages that didn't have corporate backing?
If success = widespread use then python and php?
Unfortunately we're not living in the 70's or 80's, where the best had a chance, and there's a lot of software written in the mainstream
I think that's a bit pessimistic.
I too think that it is possible for the best to succeed without corporate backing, but also for "not the best" to succeed with corporate backing. I'd list C (AT&T), Java (Sun), C# (MS), Javascript (Netscape) in that category, and funny, but they all look much the same, maybe the corporate suit has been replaced by the corporate braces { }.
languages. These applications won't get rewritten just because some better language appeared (or do you plan to rewrite geany in D? :-). In the last 15 years the only successful languages were those where some big company was behind (Java, C#).
Never re-write whole applications, see KDE 4 for most of the reasons.
It's not normally a good idea to rewrite applications. But new applications could be written in a language like D or Go (obviously).
Any successful language will need to interface well with C.
True, its the common interface language between all the others.
Which brings up mixed language systems, I've seen a very successful (closed source) system that uses Python as the front end for GUI and scripting where dynamic characteristics are very helpful, and C++ as the backend for the crunching where static characteristics make for good code.
And it's fast. I spend one hour a day just compiling with C++ code.
A D developer says it's faster than Go at compiling, and it has templates: http://www.digitalmars.com/pnews/read.php?server=news.digitalmars.com&gr...
Well, it really depends if he was compiling a single file or a library
The link says: "So the go compiler compiles 120KLOC in 9.23 seconds. I got curious so I just tested dmd against Phobos (88KLOC). That takes 1.24 seconds on my laptop."
Phobos is D's standard library, and includes templates quite a bit.
with many includes. What makes the compilation of C++ slow is that it has to parse the same headers again and again every time they are included (and all the includes inside the includes). This is eliminated in go. If D uses includes, then it will be slow for big projects too.
It doesn't use includes per say, but compiler-generated .di files. C++ parsing is slow anyway because of templates.
Yeah, just try using some of the Boost libraries heavily :-(
(I think both D and Go have ways to speed up compilation further).
The reason I originally said that I wouldn't get into a language discussion is because as entertaining and intellectually stimulating as such discussions are (I subscribe to LtU http://lambda-the-ultimate.org/ ) in reality most of the factors which control the selection of languages are non-technical, tool availability, programmer experience and training costs for switching, and good old fear (will I be blamed for a project failing if I try something new).
To give the discussion a Geany flavour (just for the look of it you know, so Enrico doesn't complain we are too OT ;-) this is why Geany should not impose specific workflows or prevent them, we don't know what the "next big thing" will be.
And to answer Jiri's question on a previous post, use of functional languages in anger, if you are in Europe the majority of your phone calls are handled by a functional language, Erlang, which Ericsson use to program their exchanges. Large projects, real time, high reliability, fault tolerance, concurrency ... not a bad list.
Cheers Lex
Regards, Nick _______________________________________________ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
On Fri, Jun 11, 2010 at 00:17, Lex Trotman elextr@gmail.com wrote:
On 11 June 2010 02:15, Nick Treleaven nick.treleaven@btinternet.com wrote:
On Thu, 10 Jun 2010 17:48:39 +0200 Jiří Techet techet@gmail.com wrote:
I agree it helps, but are there really no successful widespread languages that didn't have corporate backing?
If success = widespread use then python and php?
It was caused by the move towards dynamic scripting languages during the internet boom. Big companies overslept and developers just took what was available. But for static languages such a boom was in the 90's on desktops where static languages are used most and the "language culture" is quite firmly established.
And I'm pretty happy with python (ruby users have to forgive me) which might hopefully replace the ugly php one day (perl will fortunately kill itself with infinite perl 6 development) so the future in the dynamic language area looks bright.
Unfortunately we're not living in the 70's or 80's, where the best had a chance, and there's a lot of software written in the mainstream
I think that's a bit pessimistic.
I too think that it is possible for the best to succeed without corporate backing, but also for "not the best" to succeed with corporate backing. I'd list C (AT&T), Java (Sun), C# (MS), Javascript (Netscape) in that category, and funny, but they all look much the same, maybe the corporate suit has been replaced by the corporate braces { }.
languages. These applications won't get rewritten just because some better language appeared (or do you plan to rewrite geany in D? :-). In the last 15 years the only successful languages were those where some big company was behind (Java, C#).
Never re-write whole applications, see KDE 4 for most of the reasons.
Well, GNOME might do something similar with GMONE Shell, which looks very scary to me in its current form. If it's too bad, I'll switch to xfce.
It's not normally a good idea to rewrite applications. But new applications could be written in a language like D or Go (obviously).
Any successful language will need to interface well with C.
True, its the common interface language between all the others.
Which brings up mixed language systems, I've seen a very successful (closed source) system that uses Python as the front end for GUI and scripting where dynamic characteristics are very helpful, and C++ as the backend for the crunching where static characteristics make for good code.
And that's the best way of doing things because every language is good for something else (see my last paragraph - yes, I'm not replying in top-down manner :-)
And it's fast. I spend one hour a day just compiling with C++ code.
A D developer says it's faster than Go at compiling, and it has templates: http://www.digitalmars.com/pnews/read.php?server=news.digitalmars.com&gr...
Well, it really depends if he was compiling a single file or a library
The link says: "So the go compiler compiles 120KLOC in 9.23 seconds. I got curious so I just tested dmd against Phobos (88KLOC). That takes 1.24 seconds on my laptop."
Phobos is D's standard library, and includes templates quite a bit.
with many includes. What makes the compilation of C++ slow is that it has to parse the same headers again and again every time they are included (and all the includes inside the includes). This is eliminated in go. If D uses includes, then it will be slow for big projects too.
It doesn't use includes per say, but compiler-generated .di files. C++ parsing is slow anyway because of templates.
Yeah, just try using some of the Boost libraries heavily :-(
Why do you think I spend 1 hour a day compiling ;-)
(I think both D and Go have ways to speed up compilation further).
The reason I originally said that I wouldn't get into a language discussion is because as entertaining and intellectually stimulating as such discussions are (I subscribe to LtU http://lambda-the-ultimate.org/ ) in reality most of the factors which control the selection of languages are non-technical, tool availability, programmer experience and training costs for switching, and good old fear (will I be blamed for a project failing if I try something new).
To give the discussion a Geany flavour (just for the look of it you know, so Enrico doesn't complain we are too OT ;-) this is why Geany should not impose specific workflows or prevent them, we don't know what the "next big thing" will be.
And to answer Jiri's question on a previous post, use of functional languages in anger, if you are in Europe the majority of your phone calls are handled by a functional language, Erlang, which Ericsson use to program their exchanges. Large projects, real time, high reliability, fault tolerance, concurrency ... not a bad list.
The thing I develop is this:
http://www.egos.esa.int/portal/egos-web/products/MCS/SCOS2000/
and it's good old C++ (and C++ified C) :-). And sure functional languages have many advantages - apart from other things it's much easier to prove the correctness of the program written in a functional language and many parallelism-related problems just vanish.
I don't like the discussions where people defend their "best" programming language. There is no best programming language, it depends on what you want to use the language for. For web (and possibly simple GUI applications), a dynamic language. For anything that requires good performance, C, C++. If your company forces you to, Java. If you are doomed to working under Windows, C#. For highly secure systems, functional languages. And I'm naming the widespread languages because you'll probably need some extra libraries that won't be available for the more esoteric languages. I just think that for OO languages the number of use cases is much higher than for functional languages. And most often you are not the one who makes the decision - you come to the existing messy code and just contribute to making it even messier.
Jiri
On 11 June 2010 09:37, Jiří Techet techet@gmail.com wrote:
On Fri, Jun 11, 2010 at 00:17, Lex Trotman elextr@gmail.com wrote:
On 11 June 2010 02:15, Nick Treleaven nick.treleaven@btinternet.com wrote:
On Thu, 10 Jun 2010 17:48:39 +0200 Jiří Techet techet@gmail.com wrote:
I agree it helps, but are there really no successful widespread languages that didn't have corporate backing?
If success = widespread use then python and php?
It was caused by the move towards dynamic scripting languages during the internet boom. Big companies overslept and developers just took what was available. But for static languages such a boom was in the 90's on desktops where static languages are used most and the "language culture" is quite firmly established.
I think static languages are pretty heavily used on servers too, see the whole business computer market :-)
And I'm pretty happy with python
Agree
(ruby users have to forgive me) which
might hopefully replace the ugly php one day
Agree, but not too hopeful
(perl will fortunately
kill itself with infinite perl 6 development
Agree
) so the future in the
dynamic language area looks bright.
Unfortunately we're not living in the 70's or 80's, where the best had a chance, and there's a lot of software written in the mainstream
I think that's a bit pessimistic.
I too think that it is possible for the best to succeed without corporate backing, but also for "not the best" to succeed with corporate backing. I'd list C (AT&T), Java (Sun), C# (MS), Javascript (Netscape) in that category, and funny, but they all look much the same, maybe the corporate suit has been replaced by the corporate braces { }.
languages. These applications won't get rewritten just because some better language appeared (or do you plan to rewrite geany in D? :-). In the last 15 years the only successful languages were those where some big company was behind (Java, C#).
Never re-write whole applications, see KDE 4 for most of the reasons.
Well, GNOME might do something similar with GMONE Shell, which looks very scary to me in its current form. If it's too bad, I'll switch to xfce.
Ain't open source choice wonderful
It's not normally a good idea to rewrite applications. But new applications could be written in a language like D or Go (obviously).
Any successful language will need to interface well with C.
True, its the common interface language between all the others.
Which brings up mixed language systems, I've seen a very successful (closed source) system that uses Python as the front end for GUI and scripting where dynamic characteristics are very helpful, and C++ as the backend for the crunching where static characteristics make for good code.
And that's the best way of doing things because every language is good for something else (see my last paragraph - yes, I'm not replying in top-down manner :-)
I hope its not bottom up :-), perhaps the comments need to be object oriented :-)
And it's fast. I spend one hour a day just compiling with C++ code.
A D developer says it's faster than Go at compiling, and it has templates: http://www.digitalmars.com/pnews/read.php?server=news.digitalmars.com&gr...
Well, it really depends if he was compiling a single file or a library
The link says: "So the go compiler compiles 120KLOC in 9.23 seconds. I got curious so I just tested dmd against Phobos (88KLOC). That takes 1.24 seconds on my laptop."
Phobos is D's standard library, and includes templates quite a bit.
with many includes. What makes the compilation of C++ slow is that it has to parse the same headers again and again every time they are included (and all the includes inside the includes). This is eliminated in go. If D uses includes, then it will be slow for big projects too.
It doesn't use includes per say, but compiler-generated .di files. C++ parsing is slow anyway because of templates.
Yeah, just try using some of the Boost libraries heavily :-(
Why do you think I spend 1 hour a day compiling ;-)
I don't suppose you use spirit?
(I think both D and Go have ways to speed up compilation further).
The reason I originally said that I wouldn't get into a language discussion is because as entertaining and intellectually stimulating as such discussions are (I subscribe to LtU http://lambda-the-ultimate.org/ ) in reality most of the factors which control the selection of languages are non-technical, tool availability, programmer experience and training costs for switching, and good old fear (will I be blamed for a project failing if I try something new).
To give the discussion a Geany flavour (just for the look of it you know, so Enrico doesn't complain we are too OT ;-) this is why Geany should not impose specific workflows or prevent them, we don't know what the "next big thing" will be.
And to answer Jiri's question on a previous post, use of functional languages in anger, if you are in Europe the majority of your phone calls are handled by a functional language, Erlang, which Ericsson use to program their exchanges. Large projects, real time, high reliability, fault tolerance, concurrency ... not a bad list.
The thing I develop is this:
http://www.egos.esa.int/portal/egos-web/products/MCS/SCOS2000/
Looks like a fun area to work, I used to be in Defence/Aerospace.
and it's good old C++ (and C++ified C) :-). And sure functional languages have many advantages - apart from other things it's much easier to prove the correctness of the program written in a functional language and many parallelism-related problems just vanish.
The proofs bit is why there was a push into the functional area by the business community up to the GFC.
I don't like the discussions where people defend their "best" programming language. There is no best programming language, it depends on what you want to use the language for.
Totally Agree
For web (and
possibly simple GUI applications), a dynamic language.
Agree
For anything
that requires good performance, C, C++.
Mostly agree, a few problem domains seem to work better in functional languages, even good old Lisp can beat C is a few cases where lazy evaluation saves a lot of unneeded work. C and C++ also have to allow for aliases which can add significant cost in some codes, or rather it prevents some optimisations. And on big number crunching these days they are nearly as fast as Fortran.
If your company forces you to,
Java. If you are doomed to working under Windows, C#. For highly secure systems, functional languages.
But only if you trust the functional implementation :)
And I'm naming the widespread
languages because you'll probably need some extra libraries that won't be available for the more esoteric languages.
Agree, unless the language provides a C foreign function interface.
I just think that for OO
languages the number of use cases is much higher than for functional languages. And most often you are not the one who makes the decision - you come to the existing messy code and just contribute to making it even messier.
Agree, and as a contractor I resemble that remark.
Cheers Lex
Jiri _______________________________________________ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
On Thu, 10 Jun 2010 11:44:24 +0200 Jiří Techet techet@gmail.com wrote:
Yes, it's pretty confusing. Once you create a project you don't expect that what you see in the build tab changes based on what change you make in the global settings (until you modify the commands in the project for the first time). This makes the project totally unportable because it depends on the global settings of the current instance of geany. So if I move the project from my home computer to work, things just can stop working because I have different global settings there.
What I would suggest is that upon project creation you make a complete copy
Thats just what I didn't want to do, remember there are filetype commands and execute commands too makes each project copy big.
Then I would suggest that there are no per-project filetype commands and you just copy the global ones. In project you care about a set of files so global/general/non-filetype options are the ones you want to change. This seems to be the most reasonable solution now.
I have argued that project filetype commands are useful, but you have a good argument here. Perhaps the complexity is not worth it when project non-filetype commands could suffice.
I also like the copying non-project commands into the project idea.
Seriously, yes the whole thing should be in one dialog so that you can see what overrides what and edit the one you want, thats part of v2.0.
No, seriously, it shouldn't. How will it work with different project plugins? Please describe how you imagine the dialog should work so I can tell you why it's not a good idea ;-).
I agree with Lex here but only if editing non-project commands when a project is open is necessary.
Geany's project concept is integrated in a number of places, not just for sessions or build commands. Project plugins should not aim to take over Geany's project functionality, but work alongside it IMO. That may require API additions, but less so than rewriting all Geany's project functionality.
Regards, Nick
On 10 June 2010 21:23, Nick Treleaven nick.treleaven@btinternet.com wrote:
On Thu, 10 Jun 2010 11:44:24 +0200 Jiří Techet techet@gmail.com wrote:
Yes, it's pretty confusing. Once you create a project you don't expect that what you see in the build tab changes based on what change you make in the global settings (until you modify the commands in the project for the first time). This makes the project totally unportable because it depends on the global settings of the current instance of geany. So if I move the project from my home computer to work, things just can stop working because I have different global settings there.
What I would suggest is that upon project creation you make a complete copy
Thats just what I didn't want to do, remember there are filetype commands and execute commands too makes each project copy big.
Then I would suggest that there are no per-project filetype commands and you just copy the global ones. In project you care about a set of files so global/general/non-filetype options are the ones you want to change. This seems to be the most reasonable solution now.
I have argued that project filetype commands are useful, but you have a good argument here. Perhaps the complexity is not worth it when project non-filetype commands could suffice.
You could probably make an argument that non-filetype commands are sufficient for C/C++ and other "building a big thing" type languages, but other filetypes supported by Geany are more centred around the individual file.
And don't think just in terms of compile/link type operations.
I don't think that the potential uses of filetype commands have been explored much, even for C/C++ there is code analysis tools, prettyfiers, hey I'm giving myself ideas here..
And then it becomes important to be able to configure them per project. Also don't think of it as one project file per source tree, I'm using multiple project files to save the differing configurations when using differing tool sets for the same source tree.
We also have the filetype dependent execute commands to consider, pointing to the executables in the build directory rather than in the source directory is likely to be common.
I also like the copying non-project commands into the project idea.
Makes the whole thing easier to implement of course, but then for the common things, the user has to change it in all project files.
I don't think its a good idea for filetype commands though, and even for the executes it is a bit of a load copying all languages just to edit one.
Seriously, yes the whole thing should be in one dialog so that you can see what overrides what and edit the one you want, thats part of v2.0.
No, seriously, it shouldn't. How will it work with different project plugins? Please describe how you imagine the dialog should work so I can tell you why it's not a good idea ;-).
I agree with Lex here but only if editing non-project commands when a project is open is necessary.
Geany's project concept is integrated in a number of places, not just for sessions or build commands. Project plugins should not aim to take over Geany's project functionality, but work alongside it IMO. That may require API additions, but less so than rewriting all Geany's project functionality.
I don't know if you want to put what I'm about to say in a new thread, but I think that there is a lot of potential for adding a lot of power and usability in the grouping of the session management features, with Geany project/session features, with the ideas in Jiris plugin, with the ideas in the build system.
But there is also potential for the overlap of these implementations to become a source of friction.
Maybe there should be a bit of top level design over how these are all incorporated (even if parts are plugins, Jiris project and my complicated make configurator, as Jiri points out they need appropriate facilities in the core and access to them)
For instance is it worth while separating the session part of the inbuilt project so that it can be made to work nicely with/without the sm code (which IIUC won't work on windows so the old session is still needed). Then the project features of the project system are separate and don't get confused with the session part.
Cheers lex
Regards, Nick _______________________________________________ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
On Thu, Jun 10, 2010 at 14:59, Lex Trotman elextr@gmail.com wrote:
On 10 June 2010 21:23, Nick Treleaven nick.treleaven@btinternet.com wrote:
On Thu, 10 Jun 2010 11:44:24 +0200 Jiří Techet techet@gmail.com wrote:
Yes, it's pretty confusing. Once you create a project you don't expect that what you see in the build tab changes based on what change you make in the global settings (until you modify the commands in the project for the first time). This makes the project totally unportable because it depends on the global settings of the current instance of geany. So if I move the project from my home computer to work, things just can stop working because I have different global settings there.
What I would suggest is that upon project creation you make a complete copy
Thats just what I didn't want to do, remember there are filetype commands and execute commands too makes each project copy big.
Then I would suggest that there are no per-project filetype commands and you just copy the global ones. In project you care about a set of files so global/general/non-filetype options are the ones you want to change. This seems to be the most reasonable solution now.
I have argued that project filetype commands are useful, but you have a good argument here. Perhaps the complexity is not worth it when project non-filetype commands could suffice.
You could probably make an argument that non-filetype commands are sufficient for C/C++ and other "building a big thing" type languages, but other filetypes supported by Geany are more centred around the individual file.
And don't think just in terms of compile/link type operations.
I don't think that the potential uses of filetype commands have been explored much, even for C/C++ there is code analysis tools, prettyfiers, hey I'm giving myself ideas here..
But why can't these be configured globally? You'll have several alternative commands per filetype one of which you chose. The complications are just not worth it IMO.
And then it becomes important to be able to configure them per project. Also don't think of it as one project file per source tree, I'm using multiple project files to save the differing configurations when using differing tool sets for the same source tree.
Could you give me concrete example where you need different per-project filetype commands? (And why it can't be solved with several global commands?)
We also have the filetype dependent execute commands to consider, pointing to the executables in the build directory rather than in the source directory is likely to be common.
Ahh, the execute commands are also per-filetype? (I don't use them, so I don't know.) But there is absolutely no indication in the dialog that they are! Is there any need for that? Now it's getting Eclipse-ish (I hope I haven't offended you too much with such a strong word ;-). The only person who currently understands how it works is you - and that's pretty bad. The whole project configuration needs serious simplification.
File types are defined globally, so I would define file type commands globally too. You already have three "slots" that you can fill in with different commands. Instead of adding file type commands per project I would rather suggest:
1. to increase the number of slots 2. to make the number of slots unlimited
Then you can add several alternative commands for every file and just chose the one you wish in whatever project you are. It will also be clear what you run - "compile" will always mean the same while now it can mean different things for the same file depending on what project is open. Why do these have to be per-project and not per-geany? I have serious usability problems with constantly thinking in which mode I am (think about why you prefer geany to vi ;-)
I also like the copying non-project commands into the project idea.
Makes the whole thing easier to implement of course, but then for the common things, the user has to change it in all project files.
Projects should be independent, not to have an invisible magical link.
I don't think its a good idea for filetype commands though, and even for the executes it is a bit of a load copying all languages just to edit one.
See above, I would just use several global filetype commands available everywhere.
Seriously, yes the whole thing should be in one dialog so that you can see what overrides what and edit the one you want, thats part of v2.0.
No, seriously, it shouldn't. How will it work with different project plugins? Please describe how you imagine the dialog should work so I can tell you why it's not a good idea ;-).
I agree with Lex here but only if editing non-project commands when a project is open is necessary.
Geany's project concept is integrated in a number of places, not just for sessions or build commands. Project plugins should not aim to take over Geany's project functionality, but work alongside it IMO. That may require API additions, but less so than rewriting all Geany's project functionality.
I think that:
1. the GeanyProject structure should be private for the project implementation and contain those things that are relevant to the session-project (I have similar private structure for my project) 2. app->project should contain a structure GeanyProjectSettings that contains only those members relevant for geany (from looking at the sources, it's mainly base_path - I've seen also file_name and build_filetypes_list, but I'm not sure if these are so much necessary). 3. plugins should be able to change the members of app->project (or just replace it)
Cheers,
Jiri
On Thu, 10 Jun 2010 17:24:39 +0200 Jiří Techet techet@gmail.com wrote:
- the GeanyProject structure should be private for the project
implementation and contain those things that are relevant to the session-project (I have similar private structure for my project) 2. app->project should contain a structure GeanyProjectSettings that contains only those members relevant for geany (from looking at the sources, it's mainly base_path - I've seen also file_name and build_filetypes_list, but I'm not sure if these are so much necessary). 3. plugins should be able to change the members of app->project (or just replace it)
BTW, Structure fields in the API are there to avoid having to add setter/getter functions.
I still think that Geany's project support should not be overridden by plugins, only augmented. E.g. maybe a plugin could disable session management, but Geany still decides when to open and close a project.
Otherwise it's a mess e.g. with project indentation settings.
Regards, Nick
On Thu, Jun 10, 2010 at 17:39, Nick Treleaven nick.treleaven@btinternet.com wrote:
On Thu, 10 Jun 2010 17:24:39 +0200 Jiří Techet techet@gmail.com wrote:
- the GeanyProject structure should be private for the project
implementation and contain those things that are relevant to the session-project (I have similar private structure for my project) 2. app->project should contain a structure GeanyProjectSettings that contains only those members relevant for geany (from looking at the sources, it's mainly base_path - I've seen also file_name and build_filetypes_list, but I'm not sure if these are so much necessary). 3. plugins should be able to change the members of app->project (or just replace it)
BTW, Structure fields in the API are there to avoid having to add setter/getter functions.
I still think that Geany's project support should not be overridden by plugins, only augmented. E.g. maybe a plugin could disable session management, but Geany still decides when to open and close a project.
Can be, I have nothing against it. What I'm trying to say is that it should be this way (in OO terminology):
* there is a CoreProject class with the core project functionality geany requires. What I want is that CoreProject is different from the current SessionProject (I mean the current project support that I'd call session ;-), just a subset of it relevant for geany itself.
* there would be extensions of this core functionality - in OO terms, SessionProject, GProject and GeanyPrj would inherit from CoreProject
Otherwise it's a mess e.g. with project indentation settings.
Glad you said it first, I feel I have been too negative in the past two days ;-). I also don't understand why there are the "editor" options like maximal column width. This seems quite an arbitrary option taken from the preferences dialog. With such logic you could put almost anything from preferences into project. I would just remove it. (On the other hand I understand the indent options, they are definitely useful.)
Regards,
Jiri
On Thu, 10 Jun 2010 18:10:57 +0200 Jiří Techet techet@gmail.com wrote:
Otherwise it's a mess e.g. with project indentation settings.
Glad you said it first, I feel I have been too negative in the past
I didn't mean Geany's implementation is a mess, I meant if a plugin overrode the project support it would have to reimplement indent settings in a dialog.
two days ;-). I also don't understand why there are the "editor" options like maximal column width. This seems quite an arbitrary option taken from the preferences dialog. With such logic you could put almost anything from preferences into project. I would just remove it. (On the other hand I understand the indent options, they are definitely useful.)
It's useful to override some things which change from project to project, we think there should be more project override prefs but we haven't got around to it yet. The long line marker override was sent as a patch and it seems useful.
Regards, Nick
On Thu, Jun 10, 2010 at 18:20, Nick Treleaven nick.treleaven@btinternet.com wrote:
On Thu, 10 Jun 2010 18:10:57 +0200 Jiří Techet techet@gmail.com wrote:
Otherwise it's a mess e.g. with project indentation settings.
Glad you said it first, I feel I have been too negative in the past
I didn't mean Geany's implementation is a mess, I meant if a plugin overrode the project support it would have to reimplement indent settings in a dialog.
I meant the same. Geany's code on the other hand looks pretty reasonable. First I was surprised that it isn't (g)object-oriented but it looks it reduces the amount of code considerably. The header files look nice - the set of functions in the headers is small, which is a good sign and I haven't seen anything horrible in the sources. The only thing I dislike are the global variables.
There are only two major things I see as a problem now - how the projects work and the complexity and weired semantics of the build dialog, but you know that already. Contrary to other IDEs, I think geany is fixable; I'm just afraid it might go in the direction of other IDEs by adding features and getting bloated (how ironic from a person who added new features by creating a new plugin, but you understand me I think).
two days ;-). I also don't understand why there are the "editor" options like maximal column width. This seems quite an arbitrary option taken from the preferences dialog. With such logic you could put almost anything from preferences into project. I would just remove it. (On the other hand I understand the indent options, they are definitely useful.)
It's useful to override some things which change from project to project, we think there should be more project override prefs but we haven't got around to it yet. The long line marker override was sent as a patch and it seems useful.
I'm just afraid of "lost in dialogs, lost in overrides, not knowing what settings is currently applied hell" I know from other IDEs. Should be made carefully.
Jiri
<snip>
I'm just afraid of "lost in dialogs, lost in overrides, not knowing what settings is currently applied hell" I know from other IDEs. Should be made carefully.
Very true, I too have used Eclipse...
Trouble is each setting makes sense as a project specific setting in some use cases, so how do you judge which to limit.
Just because I don't need a feature as project specific, does that justify not accepting a patch from someone who does need it?
Its a difficult question for project maintainers.
Cheers Lex
Jiri _______________________________________________ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
On 11 June 2010 02:20, Nick Treleaven nick.treleaven@btinternet.com wrote:
On Thu, 10 Jun 2010 18:10:57 +0200 Jiří Techet techet@gmail.com wrote:
Otherwise it's a mess e.g. with project indentation settings.
Glad you said it first, I feel I have been too negative in the past
I didn't mean Geany's implementation is a mess, I meant if a plugin overrode the project support it would have to reimplement indent settings in a dialog.
two days ;-). I also don't understand why there are the "editor" options like maximal column width. This seems quite an arbitrary option taken from the preferences dialog. With such logic you could put almost anything from preferences into project. I would just remove it. (On the other hand I understand the indent options, they are definitely useful.)
It's useful to override some things which change from project to project, we think there should be more project override prefs but we haven't got around to it yet.
+1
The long line marker override was sent as
a patch and it seems useful.
+1
Cheers Lex
Regards, Nick _______________________________________________ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
On 11 June 2010 01:24, Jiří Techet techet@gmail.com wrote:
On Thu, Jun 10, 2010 at 14:59, Lex Trotman elextr@gmail.com wrote:
On 10 June 2010 21:23, Nick Treleaven nick.treleaven@btinternet.com wrote:
On Thu, 10 Jun 2010 11:44:24 +0200 Jiří Techet techet@gmail.com wrote:
Yes, it's pretty confusing. Once you create a project you don't expect that what you see in the build tab changes based on what change you make in the global settings (until you modify the commands in the project for the first time). This makes the project totally unportable because it depends on the global settings of the current instance of geany. So if I move the project from my home computer to work, things just can stop working because I have different global settings there.
What I would suggest is that upon project creation you make a complete copy
Thats just what I didn't want to do, remember there are filetype commands and execute commands too makes each project copy big.
Then I would suggest that there are no per-project filetype commands and you just copy the global ones. In project you care about a set of files so global/general/non-filetype options are the ones you want to change. This seems to be the most reasonable solution now.
I have argued that project filetype commands are useful, but you have a good argument here. Perhaps the complexity is not worth it when project non-filetype commands could suffice.
You could probably make an argument that non-filetype commands are sufficient for C/C++ and other "building a big thing" type languages, but other filetypes supported by Geany are more centred around the individual file.
And don't think just in terms of compile/link type operations.
I don't think that the potential uses of filetype commands have been explored much, even for C/C++ there is code analysis tools, prettyfiers, hey I'm giving myself ideas here..
But why can't these be configured globally? You'll have several alternative commands per filetype one of which you chose.
I thought about that in the early days, but it makes the menu too big and each user has to configure a command for each project they work on and then remember which command to use.
The
complications are just not worth it IMO.
And then it becomes important to be able to configure them per project. Also don't think of it as one project file per source tree, I'm using multiple project files to save the differing configurations when using differing tool sets for the same source tree.
Could you give me concrete example where you need different per-project filetype commands? (And why it can't be solved with several global commands?)
It can always be solved with global commands but see above for why thats not a good idea.
We also have the filetype dependent execute commands to consider, pointing to the executables in the build directory rather than in the source directory is likely to be common.
Ahh, the execute commands are also per-filetype? (I don't use them, so I don't know.) But there is absolutely no indication in the dialog that they are! Is there any need for that? Now it's getting Eclipse-ish (I hope I haven't offended you too much with such a strong word ;-). The only person who currently understands how it works is you - and that's pretty bad. The whole project configuration needs serious simplification.
The per filetype execute commands have been a part of Geany for a long time, its nothing to do with my build system additions. A functionality in non-C languages depends on them, eg for Latex they start dvi viewers.
In retaliation for your hurtful comment about Eclipse :-) I am going to suggest you stop trying to remove functionality that you don't understand because you don't personally use it, and that you RTFM (and then tell me how to improve it so you do understand :-).
File types are defined globally, so I would define file type commands globally too. You already have three "slots" that you can fill in with different commands. Instead of adding file type commands per project I would rather suggest:
- to increase the number of slots
- to make the number of slots unlimited
RTFM, hidden prefs
Then you can add several alternative commands for every file and just chose the one you wish in whatever project you are.
And you use global variables throughout your code too I suppose :-) but effectively you are saying the GUI equivalent IIUC.
It will also be
clear what you run - "compile" will always mean the same while now it can mean different things for the same file depending on what project is open.
Yes, because project 1 uses a different compiler to project 2, its still compile, you do not want every user to have to configure several compile commands before they start work on a project and then having to remember which to use. And no, using make isn't the answer, consider one project using python 2.6 and the other using python 3.1, Python workflow doesn't use make.
Why do these have to be per-project and not per-geany? I have
serious usability problems with constantly thinking in which mode I am (think about why you prefer geany to vi ;-)
Ouch jibes about vi are as hurtful as Eclipse :-) seriously though, you are not meant to think about it, just use compile and the right one for your project (or no project) will be used.
I also like the copying non-project commands into the project idea.
Makes the whole thing easier to implement of course, but then for the common things, the user has to change it in all project files.
Projects should be independent, not to have an invisible magical link.
But then each project has a copy of all commands even though they don't want to change them, so you have to go around and keep all the projects in sync if anything common does change.
I don't think its a good idea for filetype commands though, and even for the executes it is a bit of a load copying all languages just to edit one.
See above, I would just use several global filetype commands available everywhere.
Seriously, yes the whole thing should be in one dialog so that you can see what overrides what and edit the one you want, thats part of v2.0.
No, seriously, it shouldn't. How will it work with different project plugins? Please describe how you imagine the dialog should work so I can tell you why it's not a good idea ;-).
I agree with Lex here but only if editing non-project commands when a project is open is necessary.
Geany's project concept is integrated in a number of places, not just for sessions or build commands. Project plugins should not aim to take over Geany's project functionality, but work alongside it IMO. That may require API additions, but less so than rewriting all Geany's project functionality.
I think that:
- the GeanyProject structure should be private for the project
implementation and contain those things that are relevant to the session-project (I have similar private structure for my project)
Well, other than specific parts exposed in the API because other plugins need them, it is private to Geany.
- app->project should contain a structure GeanyProjectSettings that
contains only those members relevant for geany (from looking at the sources, it's mainly base_path - I've seen also file_name and build_filetypes_list, but I'm not sure if these are so much necessary).
Again, you appear to be commenting on the basis that if you don't use it, it isn't needed.
- plugins should be able to change the members of app->project (or
just replace it)
Yes, what API do you need added? Nick and I have both asked, but you have instead persisted in trying to force your specific view of the world and not answered the question.
Final comment, all your suggestions are predicated on your view of the world that one tree = one project. Others have the model of several projects/variants being built off the one source tree, or several trees = one project. Please try to understand that your workflow isn't the only one supported by Geany and stop trying to prevent others.
And now I'll climb down off my soapbox :-)
Cheers Lex
Cheers,
Jiri _______________________________________________ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
On Fri, Jun 11, 2010 at 01:18, Lex Trotman elextr@gmail.com wrote:
On 11 June 2010 01:24, Jiří Techet techet@gmail.com wrote:
On Thu, Jun 10, 2010 at 14:59, Lex Trotman elextr@gmail.com wrote:
On 10 June 2010 21:23, Nick Treleaven nick.treleaven@btinternet.com wrote:
On Thu, 10 Jun 2010 11:44:24 +0200 Jiří Techet techet@gmail.com wrote:
> Yes, it's pretty confusing. Once you create a project you don't expect > that what you see in the build tab changes based on what change you > make in the global settings (until you modify the commands in the > project for the first time). This makes the project totally unportable > because it depends on the global settings of the current instance of > geany. So if I move the project from my home computer to work, things > just can stop working because I have different global settings there. > > What I would suggest is that upon project creation you make a complete > copy
Thats just what I didn't want to do, remember there are filetype commands and execute commands too makes each project copy big.
Then I would suggest that there are no per-project filetype commands and you just copy the global ones. In project you care about a set of files so global/general/non-filetype options are the ones you want to change. This seems to be the most reasonable solution now.
I have argued that project filetype commands are useful, but you have a good argument here. Perhaps the complexity is not worth it when project non-filetype commands could suffice.
You could probably make an argument that non-filetype commands are sufficient for C/C++ and other "building a big thing" type languages, but other filetypes supported by Geany are more centred around the individual file.
And don't think just in terms of compile/link type operations.
I don't think that the potential uses of filetype commands have been explored much, even for C/C++ there is code analysis tools, prettyfiers, hey I'm giving myself ideas here..
But why can't these be configured globally? You'll have several alternative commands per filetype one of which you chose.
I thought about that in the early days, but it makes the menu too big and each user has to configure a command for each project they work on and then remember which command to use.
To me this seems to be much better than the current state and would solve all the problems I have with the current settings (like the mess with the project filetype configuration). As we talked about it in our programming language thread - one has to make compromises during the design - this solution is very slightly less flexible but much easier to understand how it works, which is more important IMO.
The
complications are just not worth it IMO.
And then it becomes important to be able to configure them per project. Also don't think of it as one project file per source tree, I'm using multiple project files to save the differing configurations when using differing tool sets for the same source tree.
Could you give me concrete example where you need different per-project filetype commands? (And why it can't be solved with several global commands?)
It can always be solved with global commands but see above for why thats not a good idea.
We also have the filetype dependent execute commands to consider, pointing to the executables in the build directory rather than in the source directory is likely to be common.
Ahh, the execute commands are also per-filetype? (I don't use them, so I don't know.) But there is absolutely no indication in the dialog that they are! Is there any need for that? Now it's getting Eclipse-ish (I hope I haven't offended you too much with such a strong word ;-). The only person who currently understands how it works is you - and that's pretty bad. The whole project configuration needs serious simplification.
The per filetype execute commands have been a part of Geany for a long time, its nothing to do with my build system additions. A functionality in non-C languages depends on them, eg for Latex they start dvi viewers.
In retaliation for your hurtful comment about Eclipse :-) I am going to suggest you stop trying to remove functionality that you don't understand because you don't personally use it, and that you RTFM (and then tell me how to improve it so you do understand :-).
No, my point wasn't that they shouldn't be per filetype - my point was that the dialog doesn't say that! So at least there should be something like "execute commands for C files". In addition, the order of the groups in the dialog suggests that they are global - first group is per filetype, the second group is global and you expect that the third group is global too because it follows the global options and the title doesn't tell you.
Ideally, I would like to see: * Non-filetype commands first * Filetype commands + executes second - they would have to be somehow visually grouped so you would know they are per-filetype. I think the combobox with the currently selected language would contribute to making it clear these are dynamic.
File types are defined globally, so I would define file type commands globally too. You already have three "slots" that you can fill in with different commands. Instead of adding file type commands per project I would rather suggest:
- to increase the number of slots
- to make the number of slots unlimited
RTFM, hidden prefs
I'll read it once it's online on geany's web page. But unless I overlook something, it's not there right now. But if there is such an option, great, no extra implementation needed.
Then you can add several alternative commands for every file and just chose the one you wish in whatever project you are.
And you use global variables throughout your code too I suppose :-)
Nope, I avoid them (for multithreaded server applications anything like global variable is evil). For gproject I use only static variables per-file which are a sort of alternative to member variables in classes.
but effectively you are saying the GUI equivalent IIUC.
Not quite sure what you mean here.
It will also be
clear what you run - "compile" will always mean the same while now it can mean different things for the same file depending on what project is open.
Yes, because project 1 uses a different compiler to project 2, its still compile, you do not want every user to have to configure several compile commands before they start work on a project and then having to remember which to use. And no, using make isn't the answer, consider one project using python 2.6 and the other using python 3.1, Python workflow doesn't use make.
But you can still use the global commands to run python (whatever version you want).
Why do these have to be per-project and not per-geany? I have
serious usability problems with constantly thinking in which mode I am (think about why you prefer geany to vi ;-)
Ouch jibes about vi are as hurtful as Eclipse :-) seriously though, you are not meant to think about it, just use compile and the right one for your project (or no project) will be used.
No, because you don't have any indication that a command is overridden in project. So even you know you saw there was python2 in the project properties last week and you know you haven't changed the project, you will be running python3 because meanwhile you changed your global properties. This is just totally wrong. My suggestion was to drop the per-filetype commands from the project, but you can use whatever other reasonable way. It just has to be fixed some way.
I also like the copying non-project commands into the project idea.
Makes the whole thing easier to implement of course, but then for the common things, the user has to change it in all project files.
Projects should be independent, not to have an invisible magical link.
But then each project has a copy of all commands even though they don't want to change them, so you have to go around and keep all the projects in sync if anything common does change.
See above, this is confusing. One more idea I have is to have all the project filetype commands initially blank - meaning they use the global commands. There would be a "copy from global commands" button that fills the commands by those used in the global options (to help you initially fill the commands). Once the filetype commands aren't blank in the project, it means the commands override the global commands. With this you'll know when some commands are overridden or use the global settings.
I don't think its a good idea for filetype commands though, and even for the executes it is a bit of a load copying all languages just to edit one.
See above, I would just use several global filetype commands available everywhere.
Seriously, yes the whole thing should be in one dialog so that you can see what overrides what and edit the one you want, thats part of v2.0.
No, seriously, it shouldn't. How will it work with different project plugins? Please describe how you imagine the dialog should work so I can tell you why it's not a good idea ;-).
I agree with Lex here but only if editing non-project commands when a project is open is necessary.
Geany's project concept is integrated in a number of places, not just for sessions or build commands. Project plugins should not aim to take over Geany's project functionality, but work alongside it IMO. That may require API additions, but less so than rewriting all Geany's project functionality.
I think that:
- the GeanyProject structure should be private for the project
implementation and contain those things that are relevant to the session-project (I have similar private structure for my project)
Well, other than specific parts exposed in the API because other plugins need them, it is private to Geany.
- app->project should contain a structure GeanyProjectSettings that
contains only those members relevant for geany (from looking at the sources, it's mainly base_path - I've seen also file_name and build_filetypes_list, but I'm not sure if these are so much necessary).
Again, you appear to be commenting on the basis that if you don't use it, it isn't needed.
Don't take the list of required members of the settings structure I mentioned too seriously - others are reasonable for all projects too (but some are not and these should be private). Regarding the rest, see my comment below.
- plugins should be able to change the members of app->project (or
just replace it)
Yes, what API do you need added? Nick and I have both asked, but you have instead persisted in trying to force your specific view of the world and not answered the question.
Final comment, all your suggestions are predicated on your view of the world that one tree = one project. Others have the model of several projects/variants being built off the one source tree, or several trees = one project. Please try to understand that your workflow isn't the only one supported by Geany and stop trying to prevent others.
I think you misunderstand the message behind my comments (and possibly I wasn't expressing myself clearly).
The only two things I want is: * to have simple and understandable settings dialogs with clear semantics * every project management plugin to have the same rights as the default one
The rest were just the means of how to achieve that. I'm not strictly against per-project filetype commands; what I want to say is that IMO the additional extra flexibility doesn't justify the confusingness. But see see what I suggest above as the solution that preserves per-project filetype commands. Regarding project management plugin, I don't want to take over all the functionality of the current project - some of its features interfere with the features of my plugin. That's why I want to to have one "project superclass" implementing the things common to all projects and let the concrete implementations do the things their (possibly different) way.
And now I'll climb down off my soapbox :-)
Was not necessary to climb up :-).
Cheers,
Jiri
To me this seems to be much better than the current state and would solve all the problems I have with the current settings
As I have said just because you have problems doesn't mean that other people should give up functionality that they use.
(like the mess
with the project filetype configuration). As we talked about it in our programming language thread - one has to make compromises during the design - this solution is very slightly less flexible but much easier to understand how it works, which is more important IMO.
The
complications are just not worth it IMO.
And then it becomes important to be able to configure them per project. Also don't think of it as one project file per source tree, I'm using multiple project files to save the differing configurations when using differing tool sets for the same source tree.
Could you give me concrete example where you need different per-project filetype commands? (And why it can't be solved with several global commands?)
It can always be solved with global commands but see above for why thats not a good idea.
We also have the filetype dependent execute commands to consider, pointing to the executables in the build directory rather than in the source directory is likely to be common.
Ahh, the execute commands are also per-filetype? (I don't use them, so I don't know.) But there is absolutely no indication in the dialog that they are! Is there any need for that? Now it's getting Eclipse-ish (I hope I haven't offended you too much with such a strong word ;-). The only person who currently understands how it works is you - and that's pretty bad. The whole project configuration needs serious simplification.
The per filetype execute commands have been a part of Geany for a long time, its nothing to do with my build system additions. A functionality in non-C languages depends on them, eg for Latex they start dvi viewers.
In retaliation for your hurtful comment about Eclipse :-) I am going to suggest you stop trying to remove functionality that you don't understand because you don't personally use it, and that you RTFM (and then tell me how to improve it so you do understand :-).
No, my point wasn't that they shouldn't be per filetype - my point was that the dialog doesn't say that! So at least there should be something like "execute commands for C files". In addition, the order of the groups in the dialog suggests that they are global - first group is per filetype, the second group is global and you expect that the third group is global too because it follows the global options and the title doesn't tell you.
The order of the rows in the dialog matches the order of the menu items in the menu.
The menu is the same as it was in 0.18, one of the design requirements.
Ideally, I would like to see:
- Non-filetype commands first
- Filetype commands + executes second - they would have to be somehow
visually grouped so you would know they are per-filetype. I think the combobox with the currently selected language would contribute to making it clear these are dynamic.
File types are defined globally, so I would define file type commands globally too. You already have three "slots" that you can fill in with different commands. Instead of adding file type commands per project I would rather suggest:
- to increase the number of slots
- to make the number of slots unlimited
RTFM, hidden prefs
I'll read it once it's online on geany's web page. But unless I overlook something, it's not there right now. But if there is such an option, great, no extra implementation needed.
If you've got the Geany source then its in the doc directory, Geany.html, this is kept up to date so even developers don't need the tools installed to make it from source.
(unless they are editing it of course)
Then you can add several alternative commands for every file and just chose the one you wish in whatever project you are.
And you use global variables throughout your code too I suppose :-)
Nope, I avoid them (for multithreaded server applications anything like global variable is evil). For gproject I use only static variables per-file which are a sort of alternative to member variables in classes.
I'm sure you don't thats why I had the :-)
but effectively you are saying the GUI equivalent IIUC.
Not quite sure what you mean here.
As I understand, you are saying that the filetype commands should be global, not possibly dependent on the project, so if I have two projects which need different commands then the only option I have is to configure two menu items each with a different command and both of these will be visible no matter which project is open and even if no project is open.
And it is up to me, the user, to remember which project I have open and select the correct menu item.
If I have misunderstood please explain what you meant.
It will also be
clear what you run - "compile" will always mean the same while now it can mean different things for the same file depending on what project is open.
Yes, because project 1 uses a different compiler to project 2, its still compile, you do not want every user to have to configure several compile commands before they start work on a project and then having to remember which to use. And no, using make isn't the answer, consider one project using python 2.6 and the other using python 3.1, Python workflow doesn't use make.
But you can still use the global commands to run python (whatever version you want).
See above, I don't want to select, I want Geany to select based on which project I'm using.
Why do these have to be per-project and not per-geany? I have
serious usability problems with constantly thinking in which mode I am (think about why you prefer geany to vi ;-)
Ouch jibes about vi are as hurtful as Eclipse :-) seriously though, you are not meant to think about it, just use compile and the right one for your project (or no project) will be used.
No, because you don't have any indication that a command is overridden in project. So even you know you saw there was python2 in the project properties last week and you know you haven't changed the project, you will be running python3 because meanwhile you changed your global properties. This is just totally wrong. My suggestion was to drop the per-filetype commands from the project, but you can use whatever other reasonable way. It just has to be fixed some way.
No you've got it the wrong way around, the way it works is the project overrides the user settings which override the Geany installed global settings the other way around would indeed be silly.
I don't think it needs to be fixed, I think you've misunderstood.
As for not having an indication of overriding, I AGREE with you and I keep saying that I intend to combine the two dialogs so that you can see this. But it won't start until 0.19 is released.
I also like the copying non-project commands into the project idea.
Makes the whole thing easier to implement of course, but then for the common things, the user has to change it in all project files.
Projects should be independent, not to have an invisible magical link.
But then each project has a copy of all commands even though they don't want to change them, so you have to go around and keep all the projects in sync if anything common does change.
See above, this is confusing. One more idea I have is to have all the project filetype commands initially blank - meaning they use the global commands.There would be a "copy from global commands" button that fills the commands by those used in the global options (to help you initially fill the commands).
That may be useful, also when they are in the same dialog then you can see both and cut and paste so it might not be needed then, lets see.
Currently the global command is shown in the project dialog so you know what that menu item will run and as a convenience and since most of the time you only want to change an option or two, with there being two dialogs it was intended to be helpful. I actually tried to make them grey until you type (like the Google search box before you type something in it) but it isn't possible with a GtkEntry and a full TextView for each item seemed an overkill.
As it is, whats shown in the project build tab is what will be run when the menu item is activated. Its a compromise with two dialogs which is why I want to combine them.
Once the filetype commands aren't
blank in the project, it means the commands override the global commands. With this you'll know when some commands are overridden or use the global settings.
I don't think its a good idea for filetype commands though, and even for the executes it is a bit of a load copying all languages just to edit one.
See above, I would just use several global filetype commands available everywhere.
> Seriously, yes the whole thing should be in one dialog so that you can > see what overrides what and edit the one you want, thats part of v2.0. >
No, seriously, it shouldn't. How will it work with different project plugins? Please describe how you imagine the dialog should work so I can tell you why it's not a good idea ;-).
I agree with Lex here but only if editing non-project commands when a project is open is necessary.
Geany's project concept is integrated in a number of places, not just for sessions or build commands. Project plugins should not aim to take over Geany's project functionality, but work alongside it IMO. That may require API additions, but less so than rewriting all Geany's project functionality.
I think that:
- the GeanyProject structure should be private for the project
implementation and contain those things that are relevant to the session-project (I have similar private structure for my project)
Well, other than specific parts exposed in the API because other plugins need them, it is private to Geany.
- app->project should contain a structure GeanyProjectSettings that
contains only those members relevant for geany (from looking at the sources, it's mainly base_path - I've seen also file_name and build_filetypes_list, but I'm not sure if these are so much necessary).
Again, you appear to be commenting on the basis that if you don't use it, it isn't needed.
Don't take the list of required members of the settings structure I mentioned too seriously - others are reasonable for all projects too (but some are not and these should be private). Regarding the rest, see my comment below.
- plugins should be able to change the members of app->project (or
just replace it)
Yes, what API do you need added? Nick and I have both asked, but you have instead persisted in trying to force your specific view of the world and not answered the question.
Final comment, all your suggestions are predicated on your view of the world that one tree = one project. Others have the model of several projects/variants being built off the one source tree, or several trees = one project. Please try to understand that your workflow isn't the only one supported by Geany and stop trying to prevent others.
I think you misunderstand the message behind my comments (and possibly I wasn't expressing myself clearly).
The only two things I want is:
- to have simple and understandable settings dialogs with clear semantics
See above
- every project management plugin to have the same rights as the default one
The rest were just the means of how to achieve that. I'm not strictly against per-project filetype commands; what I want to say is that IMO the additional extra flexibility doesn't justify the confusingness. But see see what I suggest above as the solution that preserves per-project filetype commands. Regarding project management plugin, I don't want to take over all the functionality of the current project - some of its features interfere with the features of my plugin. That's why I want to to have one "project superclass" implementing the things common to all projects and let the concrete implementations do the things their (possibly different) way.
Thats one way to do it.
But if Nick feels that the existing project system is hard to take out, then I would listen to his experience, he knows it better than I do.
Instead could you please enumerate where it interferes with what you want to do, so that the relative effort of preventing the interference vs major change can be assessed.
And can you please specify what you want to do in terms of setting commands so I can ensure that the new API can do what you need.
Cheers Lex
And now I'll climb down off my soapbox :-)
Was not necessary to climb up :-).
Cheers,
Jiri _______________________________________________ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
On Fri, Jun 11, 2010 at 14:07, Lex Trotman elextr@gmail.com wrote:
To me this seems to be much better than the current state and would solve all the problems I have with the current settings
As I have said just because you have problems doesn't mean that other people should give up functionality that they use.
This is the point where one has to make a choice:
1. Start a flame war that won't lead to anything useful 2. Give up despite being convinced about something different and try to find a solution that's acceptable for all
I have chosen the second option (even though the first is tempting too :-) so forget all I have written about removing per-filetype options from the project settings dialog.
No, my point wasn't that they shouldn't be per filetype - my point was that the dialog doesn't say that! So at least there should be something like "execute commands for C files". In addition, the order of the groups in the dialog suggests that they are global - first group is per filetype, the second group is global and you expect that the third group is global too because it follows the global options and the title doesn't tell you.
The order of the rows in the dialog matches the order of the menu items in the menu.
I would prefer an inconsistency with the menu (nobody will notice) but have per-filetype commands grouped.
The menu is the same as it was in 0.18, one of the design requirements.
No, because you don't have any indication that a command is overridden in project. So even you know you saw there was python2 in the project properties last week and you know you haven't changed the project, you will be running python3 because meanwhile you changed your global properties. This is just totally wrong. My suggestion was to drop the per-filetype commands from the project, but you can use whatever other reasonable way. It just has to be fixed some way.
No you've got it the wrong way around, the way it works is the project overrides the user settings which override the Geany installed global settings the other way around would indeed be silly.
Of course, I understand it this way. The above paragraph says that you look at the project options thinking that these options are valid for the project only, but in fact, they are global and change whenever you change the global options.
I don't think it needs to be fixed, I think you've misunderstood.
As for not having an indication of overriding, I AGREE with you and I keep saying that I intend to combine the two dialogs so that you can see this. But it won't start until 0.19 is released.
I asked twice already without much detailed response so I'll ask again - could you describe how you imagine this will work? For instance, I have no idea how you plan to make both the project options and the global options editable for the same command in the single dialog if project is loaded (without making the dialog too scary). You might consider what I propose below instead.
See above, this is confusing. One more idea I have is to have all the project filetype commands initially blank - meaning they use the global commands.There would be a "copy from global commands" button that fills the commands by those used in the global options (to help you initially fill the commands).
That may be useful, also when they are in the same dialog then you can see both and cut and paste so it might not be needed then, lets see.
Currently the global command is shown in the project dialog so you know what that menu item will run and as a convenience and since most of the time you only want to change an option or two, with there being two dialogs it was intended to be helpful. I actually tried to make them grey until you type (like the Google search box before you type something in it) but it isn't possible with a GtkEntry and a full TextView for each item seemed an overkill.
OK, a better idea than the one with "copy from global commands" - initially you could make all the edit boxes inactive but containing the global per-filetype options (so you see what is used). There would be an "override" button that would activate all the edit boxes and since then, these would be copied to the project and override the global options. The override button could be a toggle button - the second state would be "use default" that would just delete the override from the project, deactivate the edit boxes, and return back to the global settings for the filetype. This is explicit, has clear semantics and shouldn't cause any confusion. If the per-filetype options are grouped together and if there is a clear indication that these are per-filetype (I suggest the combo box), then I'm perfectly happy about this solution. What do you think?
As it is, whats shown in the project build tab is what will be run when the menu item is activated. Its a compromise with two dialogs which is why I want to combine them.
But if I understand it correctly, this won't make it possible to edit both global and project properties if the project is loaded. Also all project settings should be definable in a single dialog. Everything else is the "lost in dialog hell" I was talking about.
- every project management plugin to have the same rights as the default one
The rest were just the means of how to achieve that. I'm not strictly against per-project filetype commands; what I want to say is that IMO the additional extra flexibility doesn't justify the confusingness. But see see what I suggest above as the solution that preserves per-project filetype commands. Regarding project management plugin, I don't want to take over all the functionality of the current project - some of its features interfere with the features of my plugin. That's why I want to to have one "project superclass" implementing the things common to all projects and let the concrete implementations do the things their (possibly different) way.
Thats one way to do it.
But if Nick feels that the existing project system is hard to take out, then I would listen to his experience, he knows it better than I do.
Instead could you please enumerate where it interferes with what you want to do, so that the relative effort of preventing the interference vs major change can be assessed.
And can you please specify what you want to do in terms of setting commands so I can ensure that the new API can do what you need.
See my talk with Dimitar (I know you did, thanks for the hint, I've completely overlooked that you get GKeyFile as the parameter) - my thinking about how to integrate my project management to geany has changed a bit. With GKeyFile of the settings available, which I thought was the most serious missing thing in the interface, I could actually start changing the implementatiton and see what else is missing on the way (there is already some missing API mentioned in the reply to Dimitar - unless I overlook some more functions and data structures).
Cheers,
Jiri
On 12 June 2010 10:15, Jiří Techet techet@gmail.com wrote:
On Fri, Jun 11, 2010 at 14:07, Lex Trotman elextr@gmail.com wrote:
To me this seems to be much better than the current state and would solve all the problems I have with the current settings
As I have said just because you have problems doesn't mean that other people should give up functionality that they use.
This is the point where one has to make a choice:
- Start a flame war that won't lead to anything useful
- Give up despite being convinced about something different and try
to find a solution that's acceptable for all
I have chosen the second option (even though the first is tempting too :-)
Awww, you're no fun ;-) but thanks for being constructive
so forget all I have written about removing per-filetype options
from the project settings dialog.
No, my point wasn't that they shouldn't be per filetype - my point was that the dialog doesn't say that! So at least there should be something like "execute commands for C files". In addition, the order of the groups in the dialog suggests that they are global - first group is per filetype, the second group is global and you expect that the third group is global too because it follows the global options and the title doesn't tell you.
The order of the rows in the dialog matches the order of the menu items in the menu.
I would prefer an inconsistency with the menu (nobody will notice) but have per-filetype commands grouped.
I don't know that nobody will notice, and I personally very strongly prefer them to match, after all what you are doing is configuring the menu, lets see what others think after they have used it a bit.
The menu is the same as it was in 0.18, one of the design requirements.
No, because you don't have any indication that a command is overridden in project. So even you know you saw there was python2 in the project properties last week and you know you haven't changed the project, you will be running python3 because meanwhile you changed your global properties. This is just totally wrong. My suggestion was to drop the per-filetype commands from the project, but you can use whatever other reasonable way. It just has to be fixed some way.
No you've got it the wrong way around, the way it works is the project overrides the user settings which override the Geany installed global settings the other way around would indeed be silly.
Of course, I understand it this way. The above paragraph says that you look at the project options thinking that these options are valid for the project only, but in fact, they are global and change whenever you change the global options.
I don't think it needs to be fixed, I think you've misunderstood.
As for not having an indication of overriding, I AGREE with you and I keep saying that I intend to combine the two dialogs so that you can see this. But it won't start until 0.19 is released.
I asked twice already without much detailed response so I'll ask again
- could you describe how you imagine this will work? For instance, I
have no idea how you plan to make both the project options and the global options editable for the same command in the single dialog if project is loaded (without making the dialog too scary). You might consider what I propose below instead.
There will be two dialogs, one built-in which provides the main capabilities in a simple package. As you say, seeing all the possibilities might be scary the first time, so that dialog will be in a plugin and will be multi level.
As to exactly what is in the simple dialog, thats not yet finalised, I have already suggested that there may be some "robust" discussion on that, all suggestions welcome :-)
ATM I am in the middle of trying to get the greying out to work again. To get into 0.19 any change must be minimal and must not change strings, which rules out new buttons. If I can't get it to work, then I will probably go with leaving them blank.
See above, this is confusing. One more idea I have is to have all the project filetype commands initially blank - meaning they use the global commands.There would be a "copy from global commands" button that fills the commands by those used in the global options (to help you initially fill the commands).
BTW what you are editing in the "set build commands" dialog are user settings not global ones, the global ones are in system directories and would need root to edit.
That may be useful, also when they are in the same dialog then you can see both and cut and paste so it might not be needed then, lets see.
Currently the global command is shown in the project dialog so you know what that menu item will run and as a convenience and since most of the time you only want to change an option or two, with there being two dialogs it was intended to be helpful. I actually tried to make them grey until you type (like the Google search box before you type something in it) but it isn't possible with a GtkEntry and a full TextView for each item seemed an overkill.
OK, a better idea than the one with "copy from global commands" - initially you could make all the edit boxes inactive but containing the global per-filetype options (so you see what is used). There would be an "override" button that would activate all the edit boxes and since then, these would be copied to the project and override the global options. The override button could be a toggle button - the second state would be "use default" that would just delete the override from the project, deactivate the edit boxes, and return back to the global settings for the filetype. This is explicit, has clear semantics and shouldn't cause any confusion. If the per-filetype options are grouped together and if there is a clear indication that these are per-filetype (I suggest the combo box), then I'm perfectly happy about this solution. What do you think?
Too big a change for 0.19 IMO, after that, maybe, but see other proposal below
As it is, whats shown in the project build tab is what will be run when the menu item is activated. Its a compromise with two dialogs which is why I want to combine them.
But if I understand it correctly, this won't make it possible to edit both global and project properties if the project is loaded. Also all project settings should be definable in a single dialog. Everything else is the "lost in dialog hell" I was talking about.
Yes, project properties and set build commands should show the same thing.
You will be able to edit either, as I said above the complete dialog will be big and the exact operation of the simple one is still up for grabs.
My current thinking is that the dialog that is shown is read only and shows what will actually be run, and then there is an edit button which shows a sub-dialog. If a project is open the subdialog has two sets of fields, if no project then only one set, or the project fields are insensitive (which I think is better GUI design practice since the user can see where that info will be edited when the project is open)
For the first dialog, suggestions on how to simply show where that setting comes from are welcome, the simplest is of course to just say "from project", "from user", "from global" or whatever but it does use a bit of space.
- every project management plugin to have the same rights as the default one
The rest were just the means of how to achieve that. I'm not strictly against per-project filetype commands; what I want to say is that IMO the additional extra flexibility doesn't justify the confusingness. But see see what I suggest above as the solution that preserves per-project filetype commands. Regarding project management plugin, I don't want to take over all the functionality of the current project - some of its features interfere with the features of my plugin. That's why I want to to have one "project superclass" implementing the things common to all projects and let the concrete implementations do the things their (possibly different) way.
Thats one way to do it.
But if Nick feels that the existing project system is hard to take out, then I would listen to his experience, he knows it better than I do.
Instead could you please enumerate where it interferes with what you want to do, so that the relative effort of preventing the interference vs major change can be assessed.
And can you please specify what you want to do in terms of setting commands so I can ensure that the new API can do what you need.
See my talk with Dimitar (I know you did, thanks for the hint, I've completely overlooked that you get GKeyFile as the parameter) - my thinking about how to integrate my project management to geany has changed a bit. With GKeyFile of the settings available, which I thought was the most serious missing thing in the interface, I could actually start changing the implementatiton and see what else is missing on the way (there is already some missing API mentioned in the reply to Dimitar - unless I overlook some more functions and data structures).
Sorry, maybe I'm going blind, all I can see is the settings question.
Cheers Lex
Cheers,
Jiri _______________________________________________ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
<snip>
My current thinking is that the dialog that is shown is read only and shows what will actually be run, and then there is an edit button which shows a sub-dialog. If a project is open the subdialog has two sets of fields, if no project then only one set, or the project fields are insensitive (which I think is better GUI design practice since the user can see where that info will be edited when the project is open)
On re-re-re-reading this I realised that it might not be clear that the first dialog is a table with a row for each menu item and that there is an edit button for each row of the dialog. The edit subdialog shows the settings for that menu item only.
Describing GUIs in words isn't easy given how imprecise English is.
Cheers Lex
For the first dialog, suggestions on how to simply show where that setting comes from are welcome, the simplest is of course to just say "from project", "from user", "from global" or whatever but it does use a bit of space.
<snip>
On Sat, Jun 12, 2010 at 02:59, Lex Trotman elextr@gmail.com wrote: (snip)
See my talk with Dimitar (I know you did, thanks for the hint, I've completely overlooked that you get GKeyFile as the parameter) - my thinking about how to integrate my project management to geany has changed a bit. With GKeyFile of the settings available, which I thought was the most serious missing thing in the interface, I could actually start changing the implementatiton and see what else is missing on the way (there is already some missing API mentioned in the reply to Dimitar - unless I overlook some more functions and data structures).
Sorry, maybe I'm going blind, all I can see is the settings question.
Ah, one more post based on what I thought I had seen or written. OK, what I think is missing unless I overlook something is the ability to add a new tab to the project options dialog to avoid project options scattered over several places.
Cheers,
Jiri
On 14 June 2010 10:04, Jiří Techet techet@gmail.com wrote:
On Sat, Jun 12, 2010 at 02:59, Lex Trotman elextr@gmail.com wrote: (snip)
See my talk with Dimitar (I know you did, thanks for the hint, I've completely overlooked that you get GKeyFile as the parameter) - my thinking about how to integrate my project management to geany has changed a bit. With GKeyFile of the settings available, which I thought was the most serious missing thing in the interface, I could actually start changing the implementatiton and see what else is missing on the way (there is already some missing API mentioned in the reply to Dimitar - unless I overlook some more functions and data structures).
Sorry, maybe I'm going blind, all I can see is the settings question.
Ah, one more post based on what I thought I had seen or written. OK, what I think is missing unless I overlook something is the ability to add a new tab to the project options dialog to avoid project options scattered over several places.
Sounds sensible to me, is a function you pass a notebook tab to add and one to request its removal enough? Or do Nick or Enrico have better ideas?
Cheers Lex
Cheers,
Jiri _______________________________________________ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
On Mon, Jun 14, 2010 at 03:26, Lex Trotman elextr@gmail.com wrote:
On 14 June 2010 10:04, Jiří Techet techet@gmail.com wrote:
On Sat, Jun 12, 2010 at 02:59, Lex Trotman elextr@gmail.com wrote: (snip)
See my talk with Dimitar (I know you did, thanks for the hint, I've completely overlooked that you get GKeyFile as the parameter) - my thinking about how to integrate my project management to geany has changed a bit. With GKeyFile of the settings available, which I thought was the most serious missing thing in the interface, I could actually start changing the implementatiton and see what else is missing on the way (there is already some missing API mentioned in the reply to Dimitar - unless I overlook some more functions and data structures).
Sorry, maybe I'm going blind, all I can see is the settings question.
Ah, one more post based on what I thought I had seen or written. OK, what I think is missing unless I overlook something is the ability to add a new tab to the project options dialog to avoid project options scattered over several places.
Sounds sensible to me, is a function you pass a notebook tab to add and one to request its removal enough? Or do Nick or Enrico have better ideas?
It would be enough if you make the GtkNotebook of the dialog accessible through GeanyMainWidgets or the GeanyProject structure (I do something similar when adding the new tab to the sidebar through sidebar_notebook in GeanyMainWidgets). But then the dialog should be created when the user opens a project (and hidden) and already be available when the project-open signal is emitted. The dialog should also be only hidden when it is closed. I haven't checked the sources so I don't know whether geany already does it this way or not.
Cheers,
Jiri
On Thu, 10 Jun 2010 22:59:11 +1000 Lex Trotman elextr@gmail.com wrote:
What I would suggest is that upon project creation you make a complete copy
Thats just what I didn't want to do, remember there are filetype commands and execute commands too makes each project copy big.
Then I would suggest that there are no per-project filetype commands and you just copy the global ones. In project you care about a set of files so global/general/non-filetype options are the ones you want to change. This seems to be the most reasonable solution now.
I have argued that project filetype commands are useful, but you have a good argument here. Perhaps the complexity is not worth it when project non-filetype commands could suffice.
You could probably make an argument that non-filetype commands are sufficient for C/C++ and other "building a big thing" type languages, but other filetypes supported by Geany are more centred around the individual file.
And don't think just in terms of compile/link type operations.
I don't think that the potential uses of filetype commands have been explored much, even for C/C++ there is code analysis tools, prettyfiers, hey I'm giving myself ideas here..
And then it becomes important to be able to configure them per project. Also don't think of it as one project file per source tree,
The point was that if you want to override the non-project filetype commands you could do that with project non-filetype commands.
It might be less nice to use though, so I'm not suggesting implementing it, just thinking out loud a bit.
I'm using multiple project files to save the differing configurations when using differing tool sets for the same source tree.
We also have the filetype dependent execute commands to consider, pointing to the executables in the build directory rather than in the source directory is likely to be common.
I think of those grouped in with filetype commands, they just do different things :-p
I also like the copying non-project commands into the project idea.
Makes the whole thing easier to implement of course, but then for the common things, the user has to change it in all project files.
I don't think its a good idea for filetype commands though, and even for the executes it is a bit of a load copying all languages just to edit one.
I wasn't suggesting copying those into the project file, but only if we didn't have project filetype commands (and project filetype execute commands - phew).
Regards, Nick
On 11 June 2010 01:36, Nick Treleaven nick.treleaven@btinternet.com wrote:
On Thu, 10 Jun 2010 22:59:11 +1000 Lex Trotman elextr@gmail.com wrote:
What I would suggest is that upon project creation you make a complete copy
Thats just what I didn't want to do, remember there are filetype commands and execute commands too makes each project copy big.
Then I would suggest that there are no per-project filetype commands and you just copy the global ones. In project you care about a set of files so global/general/non-filetype options are the ones you want to change. This seems to be the most reasonable solution now.
I have argued that project filetype commands are useful, but you have a good argument here. Perhaps the complexity is not worth it when project non-filetype commands could suffice.
You could probably make an argument that non-filetype commands are sufficient for C/C++ and other "building a big thing" type languages, but other filetypes supported by Geany are more centred around the individual file.
And don't think just in terms of compile/link type operations.
I don't think that the potential uses of filetype commands have been explored much, even for C/C++ there is code analysis tools, prettyfiers, hey I'm giving myself ideas here..
And then it becomes important to be able to configure them per project. Also don't think of it as one project file per source tree,
The point was that if you want to override the non-project filetype commands you could do that with project non-filetype commands.
It might be less nice to use though, so I'm not suggesting implementing it, just thinking out loud a bit.
Thinking is good, but how would you specify which non-project filetype command would be overridden by which project non-filetype command and not confuse things further?
We have to get that terminology sorted out don't we :-)
I'm using multiple project files to save the differing configurations when using differing tool sets for the same source tree.
We also have the filetype dependent execute commands to consider, pointing to the executables in the build directory rather than in the source directory is likely to be common.
I think of those grouped in with filetype commands, they just do different things :-p
True, I just wanted to make sure that they weren't forgotten.
I also like the copying non-project commands into the project idea.
Makes the whole thing easier to implement of course, but then for the common things, the user has to change it in all project files.
I don't think its a good idea for filetype commands though, and even for the executes it is a bit of a load copying all languages just to edit one.
I wasn't suggesting copying those into the project file, but only if we didn't have project filetype commands (and project filetype execute commands - phew).
Ok.
Regards, Nick _______________________________________________ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
On Mon, 7 Jun 2010 23:38:19 +0200 Jiří Techet techet@gmail.com wrote:
- I find the session-based project conceptually wrong - having several
files opened doesn't mean that they belong to the same project - for instance I often work on several projects in parallel and have their files opened in parallel. Briefly, session != project
Depends what you call of a project. How about "the files in a certain directory and it's subdirectories"? All open source software is distributed this way, and without any IDE-specific projects.
With this definition, the Geany "project" is only a set of files (from the entire project) that you're currently working on, plus the ability to Compile one of them, or Make the project. Yes, session ! = project, and you can't, say, set individual compilation settings for a certain file. But there is a Makefile for this, and heavier IDEs like Code::Blocks.
The reason to include all project files in a list will be to provide additional functionality for them. However: source/header switching can be implemented without any project; searching in the project files is not much different from Find in files; finding a project file is much easier with the file manager; headers, sources and other files already have different icons in the file manager, and you can sort them by name, type and a bunch of other things. Novadays FMs can even show you a tooltip, consisting of the first 10-15 lines of the file - but it would have been nice if they could skip the GPL. :)
On Tue, Jun 8, 2010 at 19:03, Dimitar Zhekov dimitar.zhekov@gmail.com wrote:
On Mon, 7 Jun 2010 23:38:19 +0200 Jiří Techet techet@gmail.com wrote:
- I find the session-based project conceptually wrong - having several
files opened doesn't mean that they belong to the same project - for instance I often work on several projects in parallel and have their files opened in parallel. Briefly, session != project
Depends what you call of a project. How about "the files in a certain directory and it's subdirectories"? All open source software is
Precisely! That's _exactly_ what my plugin does - you set the base directory by putting the project definition file there and use wildcards to specify what files you want to be present in the project (e.g. *.c;*.h;*.am)
distributed this way, and without any IDE-specific projects.
And I completely agree here - they shouldn't include any IDE-specific project. But you should be able to quickly access the source files (and filter out the files you are not interested in). And that's what my plugin does. I always hated about different IDEs how hard it is to create a project. You also had to keep your project up to date with the added/removed files. You don't have to do this here because you define the project by the means of patterns, not a list of files that are present in the project.
I'm a bit unhappy that people post comments without trying it first :-(.
With this definition, the Geany "project" is only a set of files (from the entire project) that you're currently working on, plus the ability
Which contradicts what you just said before - a project is a set of files in a directory (and its subdirectories), not the subset of files you are working on right now. Compare the following two phrases:
open source project open source set of files I'm working on right now
They are not equal.
to Compile one of them, or Make the project. Yes, session ! = project, and you can't, say, set individual compilation settings for a certain file. But there is a Makefile for this, and heavier IDEs like Code::Blocks.
I absolutely agree - I hate when IDEs try to do the work of autoconf+automake. But again, this is NOT what my plugin does. Please test it first.
The reason to include all project files in a list will be to provide additional functionality for them. However: source/header switching can be implemented without any project; searching in the project files is
How will you know where to search for the header/source then? They don't have to be necessarily stored in the same directory (very true for the project I'm working on at work, but many other projects actually - it's quite common to put includes to a completely separate directory).
not much different from Find in files; finding a project file is much easier with the file manager; headers, sources and other files already
Really? Let's suppose you want to use grep (you could use ack-grep but grep is much faster if restricted to the correct files [still I'm talking about projects with tens of thousands source files]). First you have to leave geany and switch to console. Second, you'll need it to restrict only to sources you want - you'll have to type a lot of things like --include=*.c. Third you perform the search. Fourth you'll have to manually open the file by geany. I really don't think it's easier especially if you have to do it frequently.
have different icons in the file manager, and you can sort them by
Plus you'll see all of the garbage files like *.o *.so and so on which you'll never ever edit by the editor. Not really nice to navigate in such a directory. And again, you have to switch from geany to your file manager which slows you down. The different header/source icons aren't a key feature of the plugin but my brain finds them very useful when trying to open the correct file.
name, type and a bunch of other things. Novadays FMs can even show you a tooltip, consisting of the first 10-15 lines of the file - but it would have been nice if they could skip the GPL. :)
So how about testing the plugin? I'd like to know (1) that it builds and works for someone else too, and (2) would like to get a feedback based on your real experience with it, not your assumptions how you think it works ;-).
Jiri
-- E-gards: Jimmy _______________________________________________ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
On Tue, 8 Jun 2010 22:19:37 +0200 Jiří Techet techet@gmail.com wrote:
On Tue, Jun 8, 2010 at 19:03, Dimitar Zhekov dimitar.zhekov@gmail.com wrote:
Depends what you call of a project. How about "the files in a certain directory and it's subdirectories"? All open source software is
Precisely! That's _exactly_ what my plugin does - you set the base directory by putting the project definition file there and use wildcards to specify what files you want to be present in the project (e.g. *.c;*.h;*.am) [...] But you should be able to quickly access the source files (and filter out the files you are not interested in)
Yet another file system browser...
With this definition, the Geany "project" is only a set of files (from the entire project) that you're currently working on, plus the ability
Which contradicts what you just said before - a project is a set of files in a directory (and its subdirectories), not the subset of files you are working on right now. Compare the following two phrases:
open source project open source set of files I'm working on right now
They are not equal.
Yes, so I wrote "session != project". Your mistake is the assumption that the Geany project and the file system project absolutely _have_ to be identical, and anything else is "conceptually wrong". No, it's just different. Improving the Geany projects (for example the Build settings) is not a matter of "fixing" by replacing them with something completely different.
The reason to include all project files in a list will be to provide additional functionality for them. However: source/header switching can be implemented without any project; searching in the project files is
How will you know where to search for the header/source then? They don't have to be necessarily stored in the same directory (very true for the project I'm working on at work, but many other projects actually - it's quite common to put includes to a completely separate directory).
Under the project base path. Of course, it's easier to find if you already have the file list.
not much different from Find in files; finding a project file is much easier with the file manager; headers, sources and other files already
Really? Let's suppose you want to use grep [...] First you have to leave geany and switch to console [...]
Huh? Search -> Find in files.
grep is much faster if restricted to the correct files [still I'm talking about projects with tens of thousands source files]).
I'm not quite sure Geany is the best tool for this...
Plus you'll see all of the garbage files like *.o *.so and so on which you'll never ever edit by the editor. Not really nice to navigate in such a directory. And again, you have to switch from geany to your file manager which slows you down.
Scrolling the sidebar tabs is not fast either, and browsing a project with tens of thousands of files (or anything > 300 from my experience), using a side-window, without the powerful navigation of a file manager...
It seems to me that simply adding a "project patterns" field in the Geany project settings dialog, and making the patterns available to all browser plugins and Find in files, would have been better than duplicating functionality.
So how about testing the plugin? I'd like [...] to get a feedback based on your real experience with it, not your assumptions how you think it works ;-).
$ git clone http://gitorious.org/gproject Initialized empty Git repository in [...] fatal: http://gitorious.org/gproject/info/refs not found: did you run git update-server-info on the server?
$ git clone git://gitorious.org/gproject Initialized empty Git repository in [...] fatal: The remote end hung up unexpectedly
My experience with git is very limited (Windows GUI only), yet these look like server errors.
P.S. Thanks for fixing C-Tab.
On Thu, 10 Jun 2010 20:54:34 +0300 Dimitar Zhekov dimitar.zhekov@gmail.com wrote:
On Tue, 8 Jun 2010 22:19:37 +0200 Jiří Techet techet@gmail.com wrote:
On Tue, Jun 8, 2010 at 19:03, Dimitar Zhekov dimitar.zhekov@gmail.com wrote:
Depends what you call of a project. How about "the files in a certain directory and it's subdirectories"? All open source software is
Precisely! That's _exactly_ what my plugin does - you set the base directory by putting the project definition file there and use wildcards to specify what files you want to be present in the project (e.g. *.c;*.h;*.am) [...] But you should be able to quickly access the source files (and filter out the files you are not interested in)
Yet another file system browser...
With this definition, the Geany "project" is only a set of files (from the entire project) that you're currently working on, plus the ability
Which contradicts what you just said before - a project is a set of files in a directory (and its subdirectories), not the subset of files you are working on right now. Compare the following two phrases:
open source project open source set of files I'm working on right now
They are not equal.
Yes, so I wrote "session != project". Your mistake is the assumption that the Geany project and the file system project absolutely _have_ to be identical, and anything else is "conceptually wrong". No, it's just different. Improving the Geany projects (for example the Build settings) is not a matter of "fixing" by replacing them with something completely different.
The reason to include all project files in a list will be to provide additional functionality for them. However: source/header switching can be implemented without any project; searching in the project files is
How will you know where to search for the header/source then? They don't have to be necessarily stored in the same directory (very true for the project I'm working on at work, but many other projects actually - it's quite common to put includes to a completely separate directory).
Under the project base path. Of course, it's easier to find if you already have the file list.
not much different from Find in files; finding a project file is much easier with the file manager; headers, sources and other files already
Really? Let's suppose you want to use grep [...] First you have to leave geany and switch to console [...]
Huh? Search -> Find in files.
grep is much faster if restricted to the correct files [still I'm talking about projects with tens of thousands source files]).
I'm not quite sure Geany is the best tool for this...
Plus you'll see all of the garbage files like *.o *.so and so on which you'll never ever edit by the editor. Not really nice to navigate in such a directory. And again, you have to switch from geany to your file manager which slows you down.
Scrolling the sidebar tabs is not fast either, and browsing a project with tens of thousands of files (or anything > 300 from my experience), using a side-window, without the powerful navigation of a file manager...
It seems to me that simply adding a "project patterns" field in the Geany project settings dialog, and making the patterns available to all browser plugins and Find in files, would have been better than duplicating functionality.
So how about testing the plugin? I'd like [...] to get a feedback based on your real experience with it, not your assumptions how you think it works ;-).
$ git clone http://gitorious.org/gproject Initialized empty Git repository in [...] fatal: http://gitorious.org/gproject/info/refs not found: did you run git update-server-info on the server?
$ git clone git://gitorious.org/gproject Initialized empty Git repository in [...] fatal: The remote end hung up unexpectedly
My experience with git is very limited (Windows GUI only), yet these look like server errors.
P.S. Thanks for fixing C-Tab.
It's git://gitorious.org/gproject/mainline.git.
On Thu, Jun 10, 2010 at 19:54, Dimitar Zhekov dimitar.zhekov@gmail.com wrote:
On Tue, 8 Jun 2010 22:19:37 +0200 Jiří Techet techet@gmail.com wrote:
On Tue, Jun 8, 2010 at 19:03, Dimitar Zhekov dimitar.zhekov@gmail.com wrote:
Depends what you call of a project. How about "the files in a certain directory and it's subdirectories"? All open source software is
Precisely! That's _exactly_ what my plugin does - you set the base directory by putting the project definition file there and use wildcards to specify what files you want to be present in the project (e.g. *.c;*.h;*.am) [...] But you should be able to quickly access the source files (and filter out the files you are not interested in)
Yet another file system browser...
...that is integrated to geany and makes it possible to access files fast and gets rid of garbage files. Yes.
With this definition, the Geany "project" is only a set of files (from the entire project) that you're currently working on, plus the ability
Which contradicts what you just said before - a project is a set of files in a directory (and its subdirectories), not the subset of files you are working on right now. Compare the following two phrases:
open source project open source set of files I'm working on right now
They are not equal.
Yes, so I wrote "session != project". Your mistake is the assumption that the Geany project and the file system project absolutely _have_ to be identical, and anything else is "conceptually wrong". No, it's just different. Improving the Geany projects (for example the Build settings) is not a matter of "fixing" by replacing them with something completely different.
I use the build settings geany uses - not sure what's your point here.
I said it many times before, but will repeat it once more - the only thing I dislike about the current project management is the name, not how it works (apart from some details I've been discussing with Lex and Nick).
The reason to include all project files in a list will be to provide additional functionality for them. However: source/header switching can be implemented without any project; searching in the project files is
How will you know where to search for the header/source then? They don't have to be necessarily stored in the same directory (very true for the project I'm working on at work, but many other projects actually - it's quite common to put includes to a completely separate directory).
Under the project base path. Of course, it's easier to find if you already have the file list.
Doing the search every time you want to swap is just slow for 10000+ files.
not much different from Find in files; finding a project file is much easier with the file manager; headers, sources and other files already
Really? Let's suppose you want to use grep [...] First you have to leave geany and switch to console [...]
Huh? Search -> Find in files.
...which searches in all *.o and *.so and other files you are not interested in. The difference for me is 2 minutes versus 4 seconds (ack-grep takes 25 seconds).
grep is much faster if restricted to the correct files [still I'm talking about projects with tens of thousands source files]).
I'm not quite sure Geany is the best tool for this...
Yes, it is together with my plugin (just because geany doesn't do crazy things). I know that some kernel developers use vi and some emacs, but I don't really want to use either of these (I use vi for quick command-line editing but can't imagine to use it for big projects). Forget about Eclipse, codeblocs, Anjuta (I used codeblocks for a while but geany is much better for the job now).
From commercial products it could be slickedit but my company won't
pay for it; and I'm pretty happy with geany.
If you know any other option, I'll be happy to listen.
Plus you'll see all of the garbage files like *.o *.so and so on which you'll never ever edit by the editor. Not really nice to navigate in such a directory. And again, you have to switch from geany to your file manager which slows you down.
Scrolling the sidebar tabs is not fast either, and browsing a project with tens of thousands of files (or anything > 300 from my experience), using a side-window, without the powerful navigation of a file manager...
There's a "find project file by name" feature for quick access. Also you can turn on the mode where the sidebar autoexpands the tree and selects the active file.
It seems to me that simply adding a "project patterns" field in the Geany project settings dialog, and making the patterns available to all browser plugins and Find in files, would have been better than duplicating functionality.
I don't duplicate any functionality - I reuse whatever I can from geany. (Unfortunately I can't use all the features the session project uses, something I've been discussing with Lex and Nick. So some features are missing.)
So how about testing the plugin? I'd like [...] to get a feedback based on your real experience with it, not your assumptions how you think it works ;-).
$ git clone http://gitorious.org/gproject Initialized empty Git repository in [...] fatal: http://gitorious.org/gproject/info/refs not found: did you run git update-server-info on the server?
You should have put the above to your web browser ;-). I described how to get and compile it in about the middle of the email here:
http://lists.uvena.de/geany-devel/2010-June/002474.html
I'd be happy if you tested it - you'd be the first one ;-).
Cheers,
Jiri
On Thu, 10 Jun 2010 22:31:27 +0200 Jiří Techet techet@gmail.com wrote:
I'd be happy if you tested it - you'd be the first one ;-).
I tested your plugin and I really liked it, nice job.
My geanyprj plugin idea about all project files located at the one basedir made bad joke of me. Lately I have to work with lot of crazy code (SDK for different embedded boards). Here is sample structure.
/apps/my_app1 /apps/my_app2 /libs/common_lib /huge_external_app_sources/kernel /huge_external_app_sources/xorg
When I work on "my_app1" I want to be able to use tags for "my_app1" and "common_lib", but I can't do this with one basedir.
Since you have to manually open project in your plugin, I think it won't conflict with your plugin's ideology to make "basedir" as list as all other fields. So both "my_app1" and "common_lib" sources will be part of the project and big nasties as my_app2, kernel and xorg won't.
On Thu, Jun 10, 2010 at 23:07, Yura Siamashka yurand2@gmail.com wrote:
On Thu, 10 Jun 2010 22:31:27 +0200 Jiří Techet techet@gmail.com wrote:
I'd be happy if you tested it - you'd be the first one ;-).
I tested your plugin and I really liked it, nice job.
Thanks for your original plugin - it made me look at the problem in a slightly different way.
My geanyprj plugin idea about all project files located at the one basedir made bad joke of me. Lately I have to work with lot of crazy code (SDK for different embedded boards). Here is sample structure.
/apps/my_app1 /apps/my_app2 /libs/common_lib /huge_external_app_sources/kernel /huge_external_app_sources/xorg
When I work on "my_app1" I want to be able to use tags for "my_app1" and "common_lib", but I can't do this with one basedir.
I work with something similar...
gproject shares the tags of all open projects. You can manually deselect "generate tags for all project files" in the project properties dialog for those projects whose tags you don't wish to be generated.
Since you have to manually open project in your plugin,
Not quite - it's semi-automatic. Your plugin does this completely automatically. If you wish this to happen in my plugin, you have to press the "reload all" button in the sidebar. Then it automatically opens the projects of all the open files and selects the current project based on the current file. The reason why it isn't completely automatic as you did it is that it's slow for big projects and switching between two files coming from different projects was too slow.
I think it won't conflict with your plugin's ideology to make "basedir" as list as all other fields. So both "my_app1" and "common_lib" sources will be part of the project and big nasties as my_app2, kernel and xorg won't.
It kind of starts complicating things. But as tags are shared, isn't this enough for you?
Jiri
On Fri, 11 Jun 2010 02:18:39 +0800 Chow Loong Jin hyperair@gmail.com wrote:
It's git://gitorious.org/gproject/mainline.git.
Thanks.
On Thu, 10 Jun 2010 22:31:27 +0200 Jiří Techet techet@gmail.com wrote:
Yet another file system browser...
...that is integrated to geany and makes it possible to access files fast and gets rid of garbage files. Yes.
No more integrated than the other browser plugins. filebrowser filters the object files too.
It seems to me that simply adding a "project patterns" field in the Geany project settings dialog, and making the patterns available to all browser plugins and Find in files, would have been better than duplicating functionality.
I don't duplicate any functionality - I reuse whatever I can from geany. (Unfortunately I can't use all the features the session project uses, something I've been discussing with Lex and Nick. So some features are missing.)
There are currently patterns in 3 plugins (including gproject) and the ability to enter them in Find in files as --include and --exclude. That's what I meant by duplication.
I'd be happy if you tested it - you'd be the first one ;-).
I did, briefly. On the plus side, the browser works. Now...
Find in project segfaults. I'll compile a -g version tomorrow.
Find file does nothing when started from the menu, and finds nothing when started from the project tree. I expected incrementional search or filter field in the sidebar.
Clicking on a file/directory entry immediately re-selects the editor. Somewhat practical, but an obstacle to the keyboard navigation.
Of course, with a single mixed directory/file tree, and without any pathbar selector, bookmarks, or at least a Go to directory (maybe Find file does this?), navigating inside a large project is clumsy. In a simple directory structure with lots of files, the filebrowser with it's filter is more useful.
I also expected to have the file type actions in the files popup menu, it seems like the most natural thing for a "full project". Not that a project-less browser plugin can't have them... Hmmm, that's an idea.
On Thu, Jun 10, 2010 at 23:09, Dimitar Zhekov dimitar.zhekov@gmail.com wrote:
On Fri, 11 Jun 2010 02:18:39 +0800 Chow Loong Jin hyperair@gmail.com wrote:
It's git://gitorious.org/gproject/mainline.git.
Thanks.
On Thu, 10 Jun 2010 22:31:27 +0200 Jiří Techet techet@gmail.com wrote:
Yet another file system browser...
...that is integrated to geany and makes it possible to access files fast and gets rid of garbage files. Yes.
No more integrated than the other browser plugins. filebrowser filters the object files too.
It seems to me that simply adding a "project patterns" field in the Geany project settings dialog, and making the patterns available to all browser plugins and Find in files, would have been better than duplicating functionality.
I don't duplicate any functionality - I reuse whatever I can from geany. (Unfortunately I can't use all the features the session project uses, something I've been discussing with Lex and Nick. So some features are missing.)
There are currently patterns in 3 plugins (including gproject) and the ability to enter them in Find in files as --include and --exclude. That's what I meant by duplication.
I'd be happy if you tested it - you'd be the first one ;-).
I did, briefly. On the plus side, the browser works. Now...
Thanks a lot for giving it a try!
Find in project segfaults. I'll compile a -g version tomorrow.
Fixed & pushed (I knew about this and had the fix, just forgot to push it). It was because the active file you were looking at didn't belong to the project (or you just didn't have any file opened). If the active file doesn't belong to the project, the project isn't active and the items in the menu have no effect (yes, I should gray them out in this case).
Find file does nothing when started from the menu, and finds nothing when started from the project tree. I expected incrementional search or filter field in the sidebar.
Again, because the project wasn't active. When it is active, it will just write the files it finds into msgwindow. Incremental search is too slow with big projects (this was real pain with codeblocks).
Clicking on a file/directory entry immediately re-selects the editor. Somewhat practical, but an obstacle to the keyboard navigation.
This was intentional, but if many people dislike it, I can disable it.
Of course, with a single mixed directory/file tree, and without any pathbar selector, bookmarks, or at least a Go to directory (maybe Find
What is pathbar selector?
file does this?), navigating inside a large project is clumsy. In a simple directory structure with lots of files, the filebrowser with it's filter is more useful.
I agree that for flat directory structure with lots of files the file browser is probably better - and I'm not going to duplicate its functionality.
We probably come from different worlds - I work with a project with deep directory structure so navigating between files with file browser is painful (but with my plugin when the tree is expanded, it is much easier - I have expanded only those subsystems I'm working on and the rest is collapsed). On the other hand, the directories themselves contain relatively small number of files. Also the files contain the subsystem name in the prefix so it didn't come into my mind that someone may want to search for a directory - I'll add a checkbox for "find in whole name including path" into the find file dialog.
I don't see any need for bookmarks inside the plugin; this should be implemented in geany (I bet people not using this plugin want the functionality too). If you press the last button in the toolbar, the sidebar will follow the current (or bookmarked) file for you.
I also expected to have the file type actions in the files popup menu, it seems like the most natural thing for a "full project". Not that a
You mean the same that the file browser has or do you have something else in mind? Can add those, that's no problem.
Thanks,
Jiri
On Fri, 11 Jun 2010 00:17:13 +0200 Jiří Techet techet@gmail.com wrote:
Find in project segfaults. I'll compile a -g version tomorrow.
Fixed & pushed (I knew about this and had the fix, just forgot to push it). It was because the active file you were looking at didn't belong to the project (or you just didn't have any file opened). If the active file doesn't belong to the project, the project isn't active and the items in the menu have no effect (yes, I should gray them out in this case).
Pulled. So the current file must belong to the project...
Find file does nothing when started from the menu, and finds nothing when started from the project tree. I expected incrementional search or filter field in the sidebar.
Again, because the project wasn't active.
Probably forgot to reopen it after Find in project crashed.
When it is active, it will just write the files it finds into msgwindow. Incremental search is too slow with big projects (this was real pain with codeblocks).
Yes, it displays the matching files in the Messages, and the number after the file name is... The current line if the file is open? No, there are 0s for some open files, and 1s for some unopen files... huh.
Of course, with a single mixed directory/file tree, and without any pathbar selector, bookmarks, or at least a Go to directory (maybe Find
What is pathbar selector?
Invoke File -> Open, that's the line of buttons with path elements at the top (maybe you use a different name for them). Another PBS is to display the path as text, for example "/usr/local/bin", and have each path part cickable.
I don't see any need for bookmarks inside the plugin; this should be implemented in geany (I bet people not using this plugin want the functionality too). If you press the last button in the toolbar, the sidebar will follow the current (or bookmarked) file for you.
Bookmarks with commonly used directories, for example "src".
I also expected to have the file type actions in the files popup menu, it seems like the most natural thing for a "full project". Not that a
You mean the same that the file browser has or do you have something else in mind? Can add those, that's no problem.
The actions from Project -> Properties -> Build. I haven't checked if it's possible to pass an arbitary name to them, or the % substitutions work with the currently open file only.
---
You are probably aware of that, but... Unless you want to really work (compile and make) with 2+ projects, in a single Geany window, as opposed to only opening files from another project, gproject can be implemented as extension to geany projects, instead of an alternative. IMHO, having the two workg together will be much more useful (and require less changes in Geany). Very briefly:
Instead of *.gpc, store the gproject settings in *.geany, removing the duplicates.
Add a gproject setting, "additional paths" or something, which contains a list of paths, for example the base paths of the projects you need to open files from.
Add a gproject setting "Generate tags for additional paths" - since opening a file from them may not be so common, and they can be large.
Well, you won't be able to use another project's "Generate tags for all project files", but OTOH, you'll be able to control the tag scan separately for the base project path and the additional paths.
Browser, Find file, Find in project - display / work with all paths, no matter under which of them (if any) is the current file. The current behaviour is confusing, and to search for a file, I have to select a file from the same project, or switch to the panel and navigate to the project...
Header/source - based on the current file's path, of course.
And of course, connect to Geany's new/open/close project, instead of having duplicate actions on the sidebar.
Using "additional paths" may be helpful to Yura Siamashka too - there would be no need to deal with several projects.
On Fri, Jun 11, 2010 at 19:30, Dimitar Zhekov dimitar.zhekov@gmail.com wrote:
On Fri, 11 Jun 2010 00:17:13 +0200 Jiří Techet techet@gmail.com wrote:
Find in project segfaults. I'll compile a -g version tomorrow.
Fixed & pushed (I knew about this and had the fix, just forgot to push it). It was because the active file you were looking at didn't belong to the project (or you just didn't have any file opened). If the active file doesn't belong to the project, the project isn't active and the items in the menu have no effect (yes, I should gray them out in this case).
Pulled. So the current file must belong to the project...
Yes. The good thing about it is that if you swap between several files from different projects, it automatically selects the active project for you. But I'm aware that this might be confusing. Another option is to select the active project manually - e.g. by using a combobox in the sidebar's statusbar.
Find file does nothing when started from the menu, and finds nothing when started from the project tree. I expected incrementional search or filter field in the sidebar.
Again, because the project wasn't active.
Probably forgot to reopen it after Find in project crashed.
When it is active, it will just write the files it finds into msgwindow. Incremental search is too slow with big projects (this was real pain with codeblocks).
Yes, it displays the matching files in the Messages, and the number after the file name is... The current line if the file is open? No, there are 0s for some open files, and 1s for some unopen files... huh.
Huh here too, that should work. For unopen files it should be 1 and for open files it should be the current line (this is a kind of ugly workaround to make geany to keep the current line and not to jump to the beginning of the file). Could you tell me how to reproduce the problem? It appears to work correctly here.
Of course, with a single mixed directory/file tree, and without any pathbar selector, bookmarks, or at least a Go to directory (maybe Find
What is pathbar selector?
Invoke File -> Open, that's the line of buttons with path elements at the top (maybe you use a different name for them). Another PBS is to display the path as text, for example "/usr/local/bin", and have each path part cickable.
OK I understand, thanks for explanation.
I don't see any need for bookmarks inside the plugin; this should be implemented in geany (I bet people not using this plugin want the functionality too). If you press the last button in the toolbar, the sidebar will follow the current (or bookmarked) file for you.
Bookmarks with commonly used directories, for example "src".
I'm just not sure where to put them. I also don't think it's so much needed - first you have to expand the necessary directories, that's true, but when you continue working with the project, you see your "favorites" in the form of the expanded tree. I'll think about it a bit, but it's not at the top of the list of features I'd like to add.
I also expected to have the file type actions in the files popup menu, it seems like the most natural thing for a "full project". Not that a
You mean the same that the file browser has or do you have something else in mind? Can add those, that's no problem.
The actions from Project -> Properties -> Build. I haven't checked if it's possible to pass an arbitary name to them, or the % substitutions work with the currently open file only.
With the current API, there's no integration with the geany's project possible. Right now it's completely independent of any project functionality of geany. See below.
You are probably aware of that, but... Unless you want to really work (compile and make) with 2+ projects, in a single Geany window, as opposed to only opening files from another project, gproject can be implemented as extension to geany projects, instead of an alternative.
It's actually an interesting alternative and by coincidence I've been thinking about the same when going home by train today. Unfortunately it's not possible right now. If you have a look at what one can do with the project:
http://www.geany.org/manual/reference/project_8h.html
you realize there's nothing you can actually do. You can just read the GeanyProject struct.
IMHO, having the two workg together will be much more useful (and require less changes in Geany). Very briefly:
Instead of *.gpc, store the gproject settings in *.geany, removing the duplicates.
I would have to be able to add extra settings to .geany - not possible now.
Add a gproject setting, "additional paths" or something, which contains a list of paths, for example the base paths of the projects you need to open files from.
I would like to avoid that. I want all the paths to be relative to base_directory so you can move the directory wherever you want without making the paths invalid. As you have no control of what happens outside the base directory, the additional paths may be moved and the project settings becomes inconsistent. Also displaying these extra directories might be confusing (where in the tree should they be displayed?) - I'd like to display only what's on the disk without the need of "meta" directories.
My current preference is to support only a single project and solve the rest by what the unix filesystem already offers. If people want to use external directories, they should add a symlink to them into the project directory (if you ask what about Windows users, my answer will be that they should start using Linux). If the symlink becomes invalid, it just won't be read but there will be no settings inconsistency. The symlinked directories would be displayed in a different color in the tree.
Add a gproject setting "Generate tags for additional paths" - since opening a file from them may not be so common, and they can be large.
Continuing in my idea above, similarly to "ignored dirs patterns" there could be "ignored dirs for tag generation patterns" (both of these settings could be made more flexible, e.g. could contain something like .gitignore does - right now the patterns match against the current directory only so you cannot ignore only e.g. the toplevel "src" directory and keep others)
Well, you won't be able to use another project's "Generate tags for all project files", but OTOH, you'll be able to control the tag scan separately for the base project path and the additional paths.
Browser, Find file, Find in project - display / work with all paths, no matter under which of them (if any) is the current file. The current behaviour is confusing, and to search for a file, I have to select a file from the same project, or switch to the panel and navigate to the project...
Should be solved with my variant too.
Header/source - based on the current file's path, of course.
Internally I could treat symlinked dirs as projects with base directory where the symlink points to so header/source swapping could work for external projects too.
And of course, connect to Geany's new/open/close project, instead of having duplicate actions on the sidebar.
Not possible now. Geany also should make it possible for plugins to add a new tab to the project properties dialog so all the project settings are at one place.
Using "additional paths" may be helpful to Yura Siamashka too - there would be no need to deal with several projects.
The symlink solution works here too I think (after all, it's just a different implementation of your idea).
Thanks a lot for spending your time thinking about how to improve the plugin! It has been very inspiring for me. Please let me know what you think about my variant of your idea.
Cheers,
Jiri
Instead of *.gpc, store the gproject settings in *.geany, removing the duplicates.
I would have to be able to add extra settings to .geany - not possible now.
Hi Jiri,
To do this catch the "project-open" and "project-save" signals from the Geany object, the user_data is a pointer to a GKeyFile of the current project.
So long as you use new key group names (preferably related to your plugin) there won't be any interference and you can also read all the other project settings.
Cheers lex
On Sat, Jun 12, 2010 at 01:06, Jiří Techet techet@gmail.com wrote:
On Fri, Jun 11, 2010 at 19:30, Dimitar Zhekov dimitar.zhekov@gmail.com wrote:
On Fri, 11 Jun 2010 00:17:13 +0200 Jiří Techet techet@gmail.com wrote:
Find in project segfaults. I'll compile a -g version tomorrow.
Fixed & pushed (I knew about this and had the fix, just forgot to push it). It was because the active file you were looking at didn't belong to the project (or you just didn't have any file opened). If the active file doesn't belong to the project, the project isn't active and the items in the menu have no effect (yes, I should gray them out in this case).
Pulled. So the current file must belong to the project...
Yes. The good thing about it is that if you swap between several files from different projects, it automatically selects the active project for you. But I'm aware that this might be confusing. Another option is to select the active project manually - e.g. by using a combobox in the sidebar's statusbar.
Find file does nothing when started from the menu, and finds nothing when started from the project tree. I expected incrementional search or filter field in the sidebar.
Again, because the project wasn't active.
Probably forgot to reopen it after Find in project crashed.
When it is active, it will just write the files it finds into msgwindow. Incremental search is too slow with big projects (this was real pain with codeblocks).
Yes, it displays the matching files in the Messages, and the number after the file name is... The current line if the file is open? No, there are 0s for some open files, and 1s for some unopen files... huh.
Huh here too, that should work. For unopen files it should be 1 and for open files it should be the current line (this is a kind of ugly workaround to make geany to keep the current line and not to jump to the beginning of the file). Could you tell me how to reproduce the problem? It appears to work correctly here.
Of course, with a single mixed directory/file tree, and without any pathbar selector, bookmarks, or at least a Go to directory (maybe Find
What is pathbar selector?
Invoke File -> Open, that's the line of buttons with path elements at the top (maybe you use a different name for them). Another PBS is to display the path as text, for example "/usr/local/bin", and have each path part cickable.
OK I understand, thanks for explanation.
I don't see any need for bookmarks inside the plugin; this should be implemented in geany (I bet people not using this plugin want the functionality too). If you press the last button in the toolbar, the sidebar will follow the current (or bookmarked) file for you.
Bookmarks with commonly used directories, for example "src".
I'm just not sure where to put them. I also don't think it's so much needed - first you have to expand the necessary directories, that's true, but when you continue working with the project, you see your "favorites" in the form of the expanded tree. I'll think about it a bit, but it's not at the top of the list of features I'd like to add.
I also expected to have the file type actions in the files popup menu, it seems like the most natural thing for a "full project". Not that a
You mean the same that the file browser has or do you have something else in mind? Can add those, that's no problem.
The actions from Project -> Properties -> Build. I haven't checked if it's possible to pass an arbitary name to them, or the % substitutions work with the currently open file only.
With the current API, there's no integration with the geany's project possible. Right now it's completely independent of any project functionality of geany. See below.
You are probably aware of that, but... Unless you want to really work (compile and make) with 2+ projects, in a single Geany window, as opposed to only opening files from another project, gproject can be implemented as extension to geany projects, instead of an alternative.
It's actually an interesting alternative and by coincidence I've been thinking about the same when going home by train today. Unfortunately it's not possible right now. If you have a look at what one can do with the project:
http://www.geany.org/manual/reference/project_8h.html
you realize there's nothing you can actually do. You can just read the GeanyProject struct.
IMHO, having the two workg together will be much more useful (and require less changes in Geany). Very briefly:
Instead of *.gpc, store the gproject settings in *.geany, removing the duplicates.
I would have to be able to add extra settings to .geany - not possible now.
Add a gproject setting, "additional paths" or something, which contains a list of paths, for example the base paths of the projects you need to open files from.
I would like to avoid that. I want all the paths to be relative to base_directory so you can move the directory wherever you want without making the paths invalid. As you have no control of what happens outside the base directory, the additional paths may be moved and the project settings becomes inconsistent. Also displaying these extra directories might be confusing (where in the tree should they be displayed?) - I'd like to display only what's on the disk without the need of "meta" directories.
My current preference is to support only a single project and solve the rest by what the unix filesystem already offers. If people want to use external directories, they should add a symlink to them into the project directory (if you ask what about Windows users, my answer will be that they should start using Linux). If the symlink becomes invalid, it just won't be read but there will be no settings inconsistency. The symlinked directories would be displayed in a different color in the tree.
Thinking about it again the symlinks might not be the best idea and may cause other problems. So I'm re-thinking your original idea again, still I would prefer something a bit different. Needs more thinking...
Jiri
On Sat, 12 Jun 2010 01:06:34 +0200 Jiří Techet techet@gmail.com wrote:
On Fri, Jun 11, 2010 at 19:30, Dimitar Zhekov dimitar.zhekov@gmail.com wrote:
On Fri, 11 Jun 2010 00:17:13 +0200 Yes, it displays the matching files in the Messages, and the number after the file name is... The current line if the file is open? No, there are 0s for some open files, and 1s for some unopen files... huh.
Huh here too, that should work. For unopen files it should be 1 and for open files it should be the current line (this is a kind of ugly workaround to make geany to keep the current line and not to jump to the beginning of the file). Could you tell me how to reproduce the problem? It appears to work correctly here.
A zero is displayed for a file open via gproject, which you never navigated into. Once you click inside the editor, use the arrows or something, that becomes non-zero. Not an issue.
Bookmarks with commonly used directories, for example "src".
I'm just not sure where to put them. I also don't think it's so much needed - first you have to expand the necessary directories, that's true, but when you continue working with the project, you see your "favorites" in the form of the expanded tree. I'll think about it a bit, but it's not at the top of the list of features I'd like to add.
I prefer to have bookmarks, for example src and include, and avoid the entire tree as much as possible. And have an idea about them below.
---
You are probably aware of that, but... Unless you want to really work (compile and make) with 2+ projects, [...]
Ah, I forgot to start with the main ideological change (there was only a hint "unless you really need 2+ projects"). So then:
Instead of multi-project, make gproject single-project, multi path (with the base path from Geany project). Then the base and additional paths will be displayed like the current paths for 2+ projects.
With this, you'll will be able to have a "/home/.../geany-testing" as base project path, and several other geany trees as "additonal" for browsing and searching. Or a project with several main paths (Yura's), as long as there is a single build command - that's the limitation.
As of the additional paths being absolute or relative, we woudn't really know if they are part of the project, and even if so, whether they are moved together with the project base path. The absolute paths look like a safe bet...
But what if APs _inside_ the project tree are used as directory bookmarks? :) Obviously, they'll be relative - and so the simplest solution seems the best: let the user enter the APs as absolute or relative, and save/use them as entered.
there could be "ignored dirs for tag generation patterns"
Yes, having directories excluded from tag scan will be much better than any per-project or per-path options. Perpaps a check menu item in the directory right click menu? It'll be good to store these as relative to their path, but that will require a real list of APs, not a single string of space-or-whatever separated entries.
On Sun, Jun 13, 2010 at 14:07, Dimitar Zhekov dimitar.zhekov@gmail.com wrote:
On Sat, 12 Jun 2010 01:06:34 +0200 Jiří Techet techet@gmail.com wrote:
On Fri, Jun 11, 2010 at 19:30, Dimitar Zhekov dimitar.zhekov@gmail.com wrote:
On Fri, 11 Jun 2010 00:17:13 +0200 Yes, it displays the matching files in the Messages, and the number after the file name is... The current line if the file is open? No, there are 0s for some open files, and 1s for some unopen files... huh.
Huh here too, that should work. For unopen files it should be 1 and for open files it should be the current line (this is a kind of ugly workaround to make geany to keep the current line and not to jump to the beginning of the file). Could you tell me how to reproduce the problem? It appears to work correctly here.
A zero is displayed for a file open via gproject, which you never navigated into. Once you click inside the editor, use the arrows or something, that becomes non-zero. Not an issue.
Aha, interesting, I wonder if this is a scintilla bug or an expected behaviour. I can add "if 0 then 1" or something like that.
Bookmarks with commonly used directories, for example "src".
I'm just not sure where to put them. I also don't think it's so much needed - first you have to expand the necessary directories, that's true, but when you continue working with the project, you see your "favorites" in the form of the expanded tree. I'll think about it a bit, but it's not at the top of the list of features I'd like to add.
I prefer to have bookmarks, for example src and include, and avoid the entire tree as much as possible. And have an idea about them below.
Apparently you find one of the best features of the plugin to be its drawback ;-)
You are probably aware of that, but... Unless you want to really work (compile and make) with 2+ projects, [...]
Ah, I forgot to start with the main ideological change (there was only a hint "unless you really need 2+ projects"). So then:
Instead of multi-project, make gproject single-project, multi path (with the base path from Geany project). Then the base and additional paths will be displayed like the current paths for 2+ projects.
With this, you'll will be able to have a "/home/.../geany-testing" as base project path, and several other geany trees as "additonal" for browsing and searching. Or a project with several main paths (Yura's), as long as there is a single build command - that's the limitation.
As of the additional paths being absolute or relative, we woudn't really know if they are part of the project, and even if so, whether they are moved together with the project base path. The absolute paths look like a safe bet...
But what if APs _inside_ the project tree are used as directory bookmarks? :) Obviously, they'll be relative - and so the simplest solution seems the best: let the user enter the APs as absolute or relative, and save/use them as entered.
Just to make sure, do I understand correctly that the bookmarks should be subtrees of the project tree copied and put somewhere behind the project root at the top level? I think this could be done but to be able to quickly distinguish between project/external project/bookmark the sidebar should be somehow divided into three parts (e.g using separators or different color for icons or something like that). Clearly it has to be made sure that the bookmarks are not scanned for tags because the files are already scanned within the project.
there could be "ignored dirs for tag generation patterns"
Yes, having directories excluded from tag scan will be much better than any per-project or per-path options. Perpaps a check menu item in the directory right click menu? It'll be good to store these as relative
I don't like the clicking idea much - for complex trees the ignored dirs would be hiding somewhere in the tree and it would be a nasty clicking exercise to find them.
to their path, but that will require a real list of APs, not a single string of space-or-whatever separated entries.
Well, looking at it it would be best not to have external projects - everything would get clear then - and this is probably how I'll implement it. The external dirs idea already doesn't fulfill my needs - I really need to switch between several projects each of which has the same "rights" as the remaining ones (header/source swapping, searching in project files and so on). But I think that your idea will integrate much better to geany's project management (only a single project open). For more open projects one should probably have more geany instances running (well, tag sharing won't be possible, I know).
Unfortunately I'll have very little time to spend on implementing that in the next two months (even though the implementation looks like only one week of evening coding). But I'll definitely implement that once I have some free time left.
Thanks for your ideas!
Jiri
On Mon, 7 Jun 2010 23:38:19 +0200 Jiří Techet techet@gmail.com wrote:
- for big projects I'd like to create some basic ctags support. The
tag manager used by geany is totally unusable for big projects because building the object hierarchy has quadratic to exponential complexity. I need a simple tag support that works in linear time.
Wouldn't it be better to fix tagmanager (if possible) to work faster - what is the cause of the non-linear behaviour - is it resorting?
Regards, Nick
On Wed, Jun 9, 2010 at 14:58, Nick Treleaven nick.treleaven@btinternet.com wrote:
On Mon, 7 Jun 2010 23:38:19 +0200 Jiří Techet techet@gmail.com wrote:
- for big projects I'd like to create some basic ctags support. The
tag manager used by geany is totally unusable for big projects because building the object hierarchy has quadratic to exponential complexity. I need a simple tag support that works in linear time.
Wouldn't it be better to fix tagmanager (if possible) to work faster - what is the cause of the non-linear behaviour - is it resorting?
Well, I had a very brief look at the tag manager so the following may be wrong. From what I have seen the tag manager maintains a hierarchy of say N objects. If you e.g. remove a file with M objects, for each of the M objects you have to scan the N objects and remove the reference to it. This makes N*M loop iterations (OK, I was wrong about the exponential time if it really works this way, but again, I would have to study the sources more carefully).
API-wise, the slow functions are
tm_workspace_add_object() tm_workspace_remove_object()
I'm not sure if this is fixable - tag manager is definitely more powerful than ctags that just scans the files sequentially without creating any hierarchy. I'm not sure what's all the functionality you use and if ctags' flat structure is enough for you.
Regards,
Jiri
Hi.
I am surprised that no one has commented on this yet. I took the time to compile and try this out (the full package) and I'm impressed. The one thing that has been lacking in geany since forever is proper project support.
I've been trying your features for a couple of days and I feel that it has improved my work flow significantly (mostly the jump to project file thingy). I also like the colored change bar, but I wish it would work with version control systems.
There are bugs that I discovered. Mainly crashes (try jumping to a file from a file outside of the project). But as a whole I would really like to see these API changes implemented so that these features could be provided as plugins for the official distribution.
Keep up the good work!
/hps
On Mon, Jun 7, 2010 at 23:38, Jiří Techet techet@gmail.com wrote:
Hi,
I would like to announce yet another project management plugin for geany. The main reason behind its creation is that I work with thousands of source files and the session-based "project" geany uses isn't sufficient for my purpose. I also had a look at geanyprj and while I like some of the ideas behind it, there are some things that don't fit my needs so I decided to create a new plugin (even though I took geanyprj as a base of the plugin, it has been completely rewritten). The things similar to geanyprj are:
O/_______SNIP____________________
O\