hi all, I'm new to the list and somewhat new to geany. I'm a developer and have recently moved from Windows + Editpad Pro for my editing to Linux + Geany. The move has been somewhat rocky, mostly due to the slightly different workflow, but there is one "feature" in Editpad that I really found useful and I'd like to bring it to Geany.
Editpad has a sidebar file browser that is a mix of Geany's Documents sidebar + the file browser plugin. That is, it only shows open documents, but it reveals which directory each file is in, like so...
includes pdf - pdf.php - file.php - http.php - index.php - something.php
So if you're working on files in different directories, it gives you a visual representation of that, rather than a flat list of open documents in the Geany Documents sidebar. And it only shows files that are open.
Geany can be made to show the full path of files, but even if all the files are in the same directory, it shows the entire path (/home/adam/.....) for all files.
I was wondering if this functionality already exists in either Geany or in a plugin. If so, I haven't been able to find it. If this functionality doesn't already exist, would it be better for me to look into making a plugin for it? I haven't actually opened up the geany code yet, so I don't know much about what is going on internally. But I would appreciate some steering in the correct direction as to the best way I could implement this.
Thanks all,
Adam
Hi,
On Mon, 25 Feb 2008 12:45:50 -0500 "Adam Plumb" adamplumb@gmail.com wrote:
Editpad has a sidebar file browser that is a mix of Geany's Documents sidebar + the file browser plugin. That is, it only shows open documents, but it reveals which directory each file is in, like so...
includes pdf - pdf.php
- file.php
- http.php
- index.php
- something.php
Sounds good, I wonder how it knows what directories to prune - e.g. for /home/user/code/project/includes presumably all the parent dirs are stripped. I guess it could remove any parent paths which appear in all documents.
So if you're working on files in different directories, it gives you a visual representation of that, rather than a flat list of open documents in the Geany Documents sidebar. And it only shows files that are open.
OK, so the feature would be like an enhanced Documents sidebar tab, not for browsing the file system.
[...]
I was wondering if this functionality already exists in either Geany or in a plugin. If so, I haven't been able to find it. If this
It doesn't exist, at least not in the core (and no plugin authors have responded yet, so probably no plugins do it either).
functionality doesn't already exist, would it be better for me to look into making a plugin for it? I haven't actually opened up the
Personally I think this would be nice to have in the core. @Enrico: what do you think?
geany code yet, so I don't know much about what is going on internally. But I would appreciate some steering in the correct direction as to the best way I could implement this.
I think this can be done by modifying the documents GtkTreeView, which currently uses a flat GtkListStore to use GtkTreeStore. It may require some code refactoring also. This code is in src/treeviews.c.
Please read the HACKING file for some notes about the codebase, and if you have more questions just ask ;-)
Regards, Nick
On Wed, 27 Feb 2008 11:57:55 +0000 Nick Treleaven nick.treleaven@btinternet.com wrote:
Hi.
Sounds good, I wonder how it knows what directories to prune - e.g. for /home/user/code/project/includes presumably all the parent dirs are stripped. I guess it could remove any parent paths which appear in all documents.
IMO this should be the project path. Until Geany has real "project support", stripping the common part is one way to do it.
Another way is the manual grouping. A colleague of mine always uses this approach. He create a group and adds some file to it. There is no path visible, only the group as node. He uses Mr.Ed as editor (on Windows).
On Wed, 27 Feb 2008 13:29:22 +0100 Joerg Desch jd.vvd@web.de wrote:
On Wed, 27 Feb 2008 11:57:55 +0000 Nick Treleaven nick.treleaven@btinternet.com wrote:
Hi.
Sounds good, I wonder how it knows what directories to prune - e.g. for /home/user/code/project/includes presumably all the parent dirs are stripped. I guess it could remove any parent paths which appear in all documents.
IMO this should be the project path. Until Geany has real "project support", stripping the common part is one way to do it.
Probably using the project path would be easier. But Geany allows files from outside the project open, so I think removing common paths would be the neatest solution, but this could be implemented later. Another bonus is that it would work when no project was open.
@Adam Plumb: You could ignore the pruning directories part, (at least for the first implementation), that would take longer to code ;-)
Another way is the manual grouping. A colleague of mine always uses this approach. He create a group and adds some file to it. There is no path visible, only the group as node. He uses Mr.Ed as editor (on Windows).
Personally I don't like this, you'd have to do it at every startup unless the groups were remembered, and a useful auto-group would still be useful anyway.
Regards, Nick
On Wed, 27 Feb 2008 13:28:44 +0000 Nick Treleaven nick.treleaven@btinternet.com wrote:
Probably using the project path would be easier. But Geany allows files from outside the project open,
That's one of the reasons why I've written that Geany has "no real" project support. That's a point that should be discussed too.
Another way is the manual grouping. A colleague of mine always uses this approach. He create a group and adds some file to it. There is no path visible, only the group as node. He uses Mr.Ed as editor (on Windows).
Personally I don't like this, you'd have to do it at every startup unless the groups were remembered, and a useful auto-group would still be useful anyway.
I agree. I work with my files structured by directories too. Nevertheless, it could be a solution. ;-)
One question: stripping the path means, that all entries of the list will display its path?
src/main.c src/foo.h src/bar.c lib/xy.c lib/abc.c doc/README doc/LICENSE doc/manual.txt ....
If so, I would prefer the directories as node of an tree.
[-] src/ main.c foo.h bar.c [-] lib/ xy.c abc.c [-] doc/ README LICENSE manual.txt [+] folded/ ....
On Wed, 27 Feb 2008 14:43:45 +0100 Joerg Desch jd.vvd@web.de wrote:
On Wed, 27 Feb 2008 13:28:44 +0000 Nick Treleaven nick.treleaven@btinternet.com wrote:
Probably using the project path would be easier. But Geany allows files from outside the project open,
That's one of the reasons why I've written that Geany has "no real" project support. That's a point that should be discussed too.
Myself and IIRC Enrico thought it would be good to allow other files outside the project to be opened without having to close all the project files first. But if there is a better alternative, feel free to suggest it ;-)
(OT: Generally Geany development proceeds in a kind of evolutionary way - this seems easier (for me at least) than designing everything at once and maybe not getting around to implementing it.)
[...]
One question: stripping the path means, that all entries of the list will display its path?
I don't think so, I think Adam Plumb's idea was to show the subdirectories as nodes.
Regards, Nick
On Wed, 27 Feb 2008 16:24:24 +0000, Nick Treleaven nick.treleaven@btinternet.com wrote:
On Wed, 27 Feb 2008 14:43:45 +0100 Joerg Desch jd.vvd@web.de wrote:
On Wed, 27 Feb 2008 13:28:44 +0000 Nick Treleaven nick.treleaven@btinternet.com wrote:
Probably using the project path would be easier. But Geany allows files from outside the project open,
That's one of the reasons why I've written that Geany has "no real" project support. That's a point that should be discussed too.
Myself and IIRC Enrico thought it would be good to allow other files outside the project to be opened without having to close all the
Yes, Enrico also thought (and thinks) so. ;-).
Regards, Enrico
On Wed, Feb 27, 2008 at 5:24 PM, Nick Treleaven nick.treleaven@btinternet.com wrote:
Myself and IIRC Enrico thought it would be good to allow other files outside the project to be opened without having to close all the project files first.
FWIW, I also think that (current approach) is good. For example, I'm currently hacking on PHP C code, and two of my applications' PHP code at the same time (testing how changes in PHP affect the applications). So, you could say that I have 3 projects open at once (in a single Geany instance).
On Wed, 27 Feb 2008 16:24:24 +0000 Nick Treleaven nick.treleaven@btinternet.com wrote:
That's one of the reasons why I've written that Geany has "no real" project support. That's a point that should be discussed too.
Myself and IIRC Enrico thought it would be good to allow other files outside the project to be opened without having to close all the project files first. But if there is a better alternative, feel free to suggest it ;-)
Ok. So how should we visualise a project? If there is only one view of loaded files, a project could be the highest node. All the other files from outside the project could be below a node "Unmanaged" (uhhh, sounds like C# stuff)
[-] Project FooBar [-] src/ main.c foo.h bar.c [-] lib/ xy.c abc.c [-] doc/ README LICENSE manual.txt [-] Unmanaged [-] ~/my-stuff/php index.php foo.php
That's one first thought. Or the project can be part of the file browser. Together with a checkbox "hide unloaded", we have the hierarchical view, and we can see what's in work. I'm not really sure if this is a possible solution.
Forget it. I think I have to try 0.13 (project management) first...
(OT: Generally Geany development proceeds in a kind of evolutionary way
- this seems easier (for me at least) than designing everything at once
and maybe not getting around to implementing it.)
That's why I prefer OSS. ;-)
On Thu, 28 Feb 2008 08:14:22 +0100 Joerg Desch jd.vvd@web.de wrote:
On Wed, 27 Feb 2008 16:24:24 +0000 Nick Treleaven nick.treleaven@btinternet.com wrote:
Myself and IIRC Enrico thought it would be good to allow other files outside the project to be opened without having to close all the project files first. But if there is a better alternative, feel free to suggest it ;-)
Ok. So how should we visualise a project? If there is only one view of loaded files, a project could be the highest node. All the other files from outside the project could be below a node "Unmanaged" (uhhh, sounds like C# stuff)
[-] Project FooBar [-] src/ main.c foo.h bar.c [-] lib/ xy.c abc.c [-] doc/ README LICENSE manual.txt [-] Unmanaged [-] ~/my-stuff/php index.php foo.php
I think this is a good idea for the Documents sidebar tab. (Although personally I'd use 'Other Files' ;-)).
That's one first thought. Or the project can be part of the file browser. Together with a checkbox "hide unloaded", we have the hierarchical view, and we can see what's in work. I'm not really sure if this is a possible solution.
I'm not sure if it's worth doing this. The file browser can still be used to switch to an open file as well as opening files. Maybe it could have a 'Go to Project Base Path' command though.
Regards, Nick
On Wed, 27 Feb 2008 13:29:22 +0100 Joerg Desch jd.vvd@web.de wrote:
[...]
Until Geany has real "project support"
Geany does have real project support ;-) That doesn't mean it's done in the same way as other IDEs though.
Regards, Nick
On Wed, 27 Feb 2008 13:30:56 +0000 Nick Treleaven nick.treleaven@btinternet.com wrote:
On Wed, 27 Feb 2008 13:29:22 +0100 Joerg Desch jd.vvd@web.de wrote:
[...]
Until Geany has real "project support"
Geany does have real project support ;-) That doesn't mean it's done in the same way as other IDEs though.
I only had shorter look at it in Geany 0.12.
So what are projects in Geany?
On Wed, 27 Feb 2008 15:09:51 +0100, Joerg Desch jd.vvd@web.de wrote:
On Wed, 27 Feb 2008 13:30:56 +0000 Nick Treleaven nick.treleaven@btinternet.com wrote:
On Wed, 27 Feb 2008 13:29:22 +0100 Joerg Desch jd.vvd@web.de wrote:
[...]
Until Geany has real "project support"
Geany does have real project support ;-) That doesn't mean it's done in the same way as other IDEs though.
I only had shorter look at it in Geany 0.12.
0.12 is very old :D.
So what are projects in Geany?
First, basic information can be found in the manual as usual: http://geany.uvena.de/manual/0.13/index.html#project-management
New since 0.13 is the ability to open/save project session files.
Regards, Enrico
On Wed, 27 Feb 2008 15:27:24 +0100 Enrico Tröger enrico.troeger@uvena.de wrote:
0.12 is very old :D.
Yes, that's true. 0.12 is the release available in Ubuntu (Gusty) and I haven't had the time to backport a 0.13 for now.
By the way. The official Debian package doesn't have a development package. I think this is a must have to allow people to write plugins. Do you have contact to the Debian folks?
First, basic information can be found in the manual as usual: http://geany.uvena.de/manual/0.13/index.html#project-management
New since 0.13 is the ability to open/save project session files.
Ok, that is one step in the right direction. ;-)
Since my spare time is currently extremely limited, I hadn't have the time to think about what is needed and so I have no feature request ready.
For example, one think I'm still missing is the possibility to easily switch the build rules. I'm using "make RELEASE=*" to build a project, where * is either DEBUG, BETA or FINAL. The Makefile handles these parameter. I don't really like Microsofts VC++, but this is one topic which is well done.
As a long-time Emacs user, there are some other points where I have problems and there are some features I'm still missing. I'll think about them at this weekend (hopefully) and post my thoughts here.
I'm using Geany on Windows and on my Laptop (running Ubuntu Dapper) and I love to work with it. Keep up the good work.
On Thu, 28 Feb 2008 07:59:30 +0100 Joerg Desch jd.vvd@web.de wrote:
By the way. The official Debian package doesn't have a development package. I think this is a must have to allow people to write plugins. Do you have contact to the Debian folks?
Personally I don't, but maybe there is something we can do to help distro maintainers produce a geany-dev (and geany-devel for Fedora) package. I think this would be good to have in time for 1.0. Although because we think the API may change before 1.0*, it's best for plugin developers to work against SVN trunk.
We've started to think about 1.0, but there are still things to be worked out, and of course no timeline (it's done when it's done).
(* API changes: tidying up some things for consistency, and to help us keep the ABI stable after 1.0. We're not sure yet how long the ABI can be kept stable after the 1.0 release. However we should be able to keep the API stable after 1.0 for some time.)
Regards, Nick
On Fri, 29 Feb 2008 17:01:51 +0000, Nick Treleaven nick.treleaven@btinternet.com wrote:
On Thu, 28 Feb 2008 07:59:30 +0100 Joerg Desch jd.vvd@web.de wrote:
By the way. The official Debian package doesn't have a development package. I think this is a must have to allow people to write plugins. Do you have contact to the Debian folks?
The Debian package maintainer is reading this list and as far as I know (Damián, correct me if I'm wrong) a Geany user ;-).
Personally I don't, but maybe there is something we can do to help
And we don't have to. First, as I told, Damián is reading this list. Second, creating a -dev(el) package from a source package is the job of a distro's package maintainer. We (the Geany developers) release/distribute only one source package which can be used to build several other packages from, e.g. geany, geany-dev, geany-plugins or whatever. But this is more or less completely in the responsibility of the package maintainer. The only thing we have to do is to refactor some of the sources so a -dev(el) package can be created in a sane way. A sane way means that only a few headers files are necessary to be used by plugins. At the moment, plugins can use all header files from Geany. This is the easy solution but would require a dev(el) package to include all Geany header files which contain parts of the plugin API. I think this is not what we should do.
Regards, Enrico
On Mon, 3 Mar 2008 14:51:46 +0100 Enrico Tröger enrico.troeger@uvena.de wrote:
On Fri, 29 Feb 2008 17:01:51 +0000, Nick Treleaven nick.treleaven@btinternet.com wrote:
Personally I don't, but maybe there is something we can do to help
And we don't have to. First, as I told, Damián is reading this list. Second, creating a -dev(el) package from a source package is the job of a distro's package maintainer. We (the Geany developers) release/distribute only one source package which can be used to build several other packages from, e.g. geany, geany-dev, geany-plugins or whatever. But this is more or less completely in the responsibility of the package maintainer.
OK. But I think we should install the header files for plugins with the usual 'make install'. This then shows the package maintainer that they could make a -dev package.
Also ideally we would have a pkg-config file for building plugins. I'm not sure if there might be other issues as well, like whether to include config.h, etc.
The only thing we have to do is to refactor some of the sources so a -dev(el) package can be created in a sane way. A sane way means that only a few headers files are necessary to be used by plugins. At the moment, plugins can use all header files from Geany. This is the easy solution but would require a dev(el) package to include all Geany header files which contain parts of the plugin API. I think this is not what we should do.
It depends. I don't think it's really a problem for a -dev package to include most of the headers. Also it's important to keep the modularisation of headers and source in the core.
Regards, Nick
On Tue, 4 Mar 2008 12:18:59 +0000, Nick Treleaven nick.treleaven@btinternet.com wrote:
On Mon, 3 Mar 2008 14:51:46 +0100 Enrico Tröger enrico.troeger@uvena.de wrote:
On Fri, 29 Feb 2008 17:01:51 +0000, Nick Treleaven nick.treleaven@btinternet.com wrote:
Personally I don't, but maybe there is something we can do to help
And we don't have to. First, as I told, Damián is reading this list. Second, creating a -dev(el) package from a source package is the job of a distro's package maintainer. We (the Geany developers) release/distribute only one source package which can be used to build several other packages from, e.g. geany, geany-dev, geany-plugins or whatever. But this is more or less completely in the responsibility of the package maintainer.
OK. But I think we should install the header files for plugins with the usual 'make install'. This then shows the package maintainer that they could make a -dev package.
Sure, this is what I meant below. WE have to install the required headers with "make install" in some usual place($prefix/include/geany).
The only thing we have to do is to refactor some of the sources so a -dev(el) package can be created in a sane way. A sane way means that only a few headers files are necessary to be used by plugins. At the moment, plugins can use all header files from Geany. This is the easy solution but would require a dev(el) package to include all Geany header files which contain parts of the plugin API. I think this is not what we should do.
It depends. I don't think it's really a problem for a -dev package to include most of the headers. Also it's important to keep the modularisation of headers and source in the core.
Hmmm ok. But then we have to install the headers in a subdirectory like "geany". If we do it this way, it shouldn't be much work at all.
Regards, Enrico
On Tue, 4 Mar 2008 14:00:22 +0100 Enrico Tröger enrico.troeger@uvena.de wrote:
On Tue, 4 Mar 2008 12:18:59 +0000, Nick Treleaven nick.treleaven@btinternet.com wrote:
OK. But I think we should install the header files for plugins with the usual 'make install'. This then shows the package maintainer that they could make a -dev package.
Sure, this is what I meant below. WE have to install the required headers with "make install" in some usual place ($prefix/include/geany).
OK, I just thought I'd make it clear ;-)
The only thing we have to do is to refactor some of the sources so a -dev(el) package can be created in a sane way. A sane way means that only a few headers files are necessary to be used by plugins. At the moment, plugins can use all header files from Geany. This is the easy solution but would require a dev(el) package to include all Geany header files which contain parts of the plugin API. I think this is not what we should do.
It depends. I don't think it's really a problem for a -dev package to include most of the headers. Also it's important to keep the modularisation of headers and source in the core.
Hmmm ok. But then we have to install the headers in a subdirectory like "geany". If we do it this way, it shouldn't be much work at all.
Yes, I think using a geany subdirectory is best.
Regards, Nick
On Tue, Mar 4, 2008 at 6:18 AM, Nick Treleaven nick.treleaven@btinternet.com wrote:
I think we should install the header files for plugins with the usual 'make install'.
I agree 100% -- devel package or not, I would be much happier if I could just say:
-I$(PREFIX)/include/geany/
Instead of the current arrangement:
-I$(GEANY_SRC)/src \ -I$(GEANY_SRC)/plugins \ -I$(GEANY_SRC)/tagmanager/include \ -I$(GEANY_SRC)/scintilla/include
- Jeff
On Tue, 4 Mar 2008 16:41:17 -0600, "Jeff Pohlmeyer" yetanothergeek@gmail.com wrote:
On Tue, Mar 4, 2008 at 6:18 AM, Nick Treleaven nick.treleaven@btinternet.com wrote:
I think we should install the header files for plugins with the usual 'make install'.
I agree 100% -- devel package or not, I would be much happier if I could just say:
Hehe. It wasn't really a question of if we do this or not. It was planned since the plugin interface exists. We just delayed this and then forgot it. I'll work on this soon, before 0.14, hopefully.
Regards, Enrico
On Thu, 28 Feb 2008 07:59:30 +0100 Joerg Desch jd.vvd@web.de wrote:
For example, one think I'm still missing is the possibility to easily switch the build rules. I'm using "make RELEASE=*" to build a project, where * is either DEBUG, BETA or FINAL. The Makefile handles these parameter. I don't really like Microsofts VC++, but this is one topic which is well done.
I haven't used MS VC++ (I used to use Delphi years ago), but I'd like some improvements to make building with different options easier. I don't think we'll add any Makefile generation support to the core of Geany, but things like remembering the Build Custom commands would be good, perhaps stored with the project.
(Also related is having a configurable Make command per project and per filetype (e.g. using Bud for D) - this is on the TODO list.)
Regards, Nick
On Feb 29 2008, Nick Treleaven wrote:
On Thu, 28 Feb 2008 07:59:30 +0100 Joerg Desch jd.vvd@web.de wrote:
For example, one think I'm still missing is the possibility to easily switch the build rules. I'm using "make RELEASE=*" to build a project, where * is either DEBUG, BETA or FINAL. The Makefile handles these parameter. I don't really like Microsofts VC++, but this is one topic which is well done.
I haven't used MS VC++ (I used to use Delphi years ago), but I'd like some improvements to make building with different options easier. I don't think we'll add any Makefile generation support to the core of Geany, but things like remembering the Build Custom commands would be good, perhaps stored with the project.
I think that would be an excellent addition, possibly with a selectable list. e.g. the standard build icon calls the currently selected.
(Also related is having a configurable Make command per project and per filetype (e.g. using Bud for D) - this is on the TODO list.)
Regards, Nick _______________________________________________ Geany mailing list Geany@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany
On 01 Mar 2008 09:11:14 +0000 "P.J.G. Long" pjgl2@cam.ac.uk wrote:
On Feb 29 2008, Nick Treleaven wrote:
I haven't used MS VC++ (I used to use Delphi years ago), but I'd like some improvements to make building with different options easier. I don't think we'll add any Makefile generation support to the core of Geany, but things like remembering the Build Custom commands would be good, perhaps stored with the project.
BTW I meant Make Custom (not Build Custom, it doesn't exist ;-)).
I think that would be an excellent addition, possibly with a selectable list. e.g. the standard build icon calls the currently selected.
I'll add it to the TODO list, a selectable menu would be useful. The Make command would do the currently selected action. The current toolbar button is for the Compile command, so probably we also need one for the Make command.
Regards, Nick
On Wed, 27 Feb 2008 11:57:55 +0000, Nick Treleaven nick.treleaven@btinternet.com wrote:
[...]
I was wondering if this functionality already exists in either Geany or in a plugin. If so, I haven't been able to find it. If this
It doesn't exist, at least not in the core (and no plugin authors have responded yet, so probably no plugins do it either).
functionality doesn't already exist, would it be better for me to look into making a plugin for it? I haven't actually opened up the
Personally I think this would be nice to have in the core. @Enrico: what do you think?
Hmmm, improving the document list this way could be nice. But I won't work on this, patches are welcome. Or maybe instead of modifying the code in src/treeviews.c it's maybe easier to write a plugin and in the long-term we could replace the current document list code with the plugin? Anyway, if anyone like to modify the code in the core and send a patch, I don't care ;-). I'd be happy about any kind of progress.
Regards, Enrico
On Wed, 27 Feb 2008 15:20:42 +0100 Enrico Tröger enrico.troeger@uvena.de wrote:
On Wed, 27 Feb 2008 11:57:55 +0000, Nick Treleaven nick.treleaven@btinternet.com wrote:
Personally I think this would be nice to have in the core. @Enrico: what do you think?
Hmmm, improving the document list this way could be nice. But I won't work on this, patches are welcome. Or maybe instead of modifying the code in src/treeviews.c it's maybe easier to write a plugin and in the long-term we could replace the current document list code with the plugin? Anyway, if anyone like to modify the code in the core and send a patch, I don't care ;-). I'd be happy about any kind of progress.
Great. I think it's probably easier and maybe better to change the core.
Regards, Nick