Hi again Jiri,
It was a long meeting, continuing into dinner and drinks, but now I'm home and continue my reply to your message. I've turned off the digest-function, there should be no more delay in correspondence.
First though, I'd like to say something; when we talk about differences between projects, I don't see that as something negative - actually the opposite. Differences means the projects can extend each other instead of being just similar. So, if PO (Project Organizer) has functionality that D (Djynn) does not, then that can make D better, and vice versa; should they somehow merge. If you see what I mean?
I can describe the vision of PorjectOrganizer. What I tried to make was a file-aware Geany project (Geany itself doesn't know about the files, it just stores base directory, build options and some common settings for project) in a minimalistic way and reuse as much as possible from Geany itself without duplicating functionality.
Yes, we think the same in many ways :) PO is designed for large or huge projects with hundreds or thousands of files, and D is designed to handle many smaller projects, because that's what I mostly work with. My projects rarely have more than a few hundred source files at most. Workspaces isn't a very important part of D, rather, like in Eclipse, all projects are listed in the tree-view at once and sometimes it becomes too many projects to have in one listing, so the workspaces function makes it possible to organise projects into groups. I may group all PHP-projects into one workspace, and all C projects into one, or my company's projects into one workspace, and my private projects into one etc. you get the point. All in all, D is designed to give quicker access to project's files, so is PO, and if we stick to that as the basic "vision", then anything else is just various "solutions" to the same problem: project file access.
There's a single glob file pattern list per project in ProjectOrganizer defined in project properties. The advantage of a glob pattern over regex is that Geany uses it too and it can be passed to the Find in Files dialog so a pattern defined at a single place in the project config is used for everything.
Well, I see no problem here, why limit to glob or regex? Why not give the choice to use either with a checkbox/radio?
PO mirrors the project directory and filters files; D picks directories and adds as folders in the project tree, each folder can either filter the files in the mirrored directory or pick specific files, naming or organising of files and folders does not have to mirror the file system, but can be moved anyway you like.
You can attach an arbitrary number of "external directories" to a project in ProjectOrganizer and have their files displayed in the sidebar (and get them indexed with the tag manager if needed). It's just not per file but per directory.
Exactly, and PO has some really nice functions for finding in files, which D does not, and D doesn't have indexing of symbols.
- Djynn can have multiple workspaces, ProjectOrganizer just uses Geany's
single "workspace" (basically the "recent projects" list).
Instead of hundreds of files in each project, I have lots and lots of projects and "recent projects" list would not work for me, I need to organise them into groups. So what is useful all depends on how we work.
For me this is sufficient, I find the workspace concept a bit too heavyweight for an editor like Geany. Switching between recent projects using Geany's built-in functionality is nice and simple.
No, it's not heavyweight, in that case I'd say PO's functionality to handle hundreds or thousands of project files is heavyweight for a minimalistic IDE. On the contrary I'd say that unless it makes the program very complicated to use, and eats up lots of CPU or memory, it's lightweight. D is extremely lightweight, it uses very little CPU and memory, and is extremely simple to use. Workspaces organise projects into groups, projects and sessions organise files into groups. It's all about how you work, what you need and find useful, often it's a matter of taste, and mostly of course practicality.
However, if the project open/close methods are added to the API, some workspace manager plugin could be made and it could even coexist with the ProjectOrganizer plugin.
Well, D is coexisting with PO already, so, yes, I see no problem here.
- ProjectOrganizer's project has a single session (like Geany) while Djynn
can have multiple.
Sessions is just a function I need all the time, perhaps you work differently, but for me it's invaluable :) I've only added functionality because that's what I make use of, otherwise it's removed. D had a list of open documents, which was removed when I noticed Addons-plugin has that as a button in the panel; and I use that even more than I use D.
I don't know if I'd ever use more sessions per project so I'm not planning to add it to ProjectOrganizer.
Well, so you admit then that PO is "what you need in Geany", and it's not actually designed for a more general use?
Again, this is quite independent of the ProjectOrganizer functionality and could be done in a separate plugin.
Yes, of course, but I prefer to have the sessions list in the project sidepanel, and D has a configuration for choosing a separate sidepanel of its own or as a tab in the main sidepanel; this was a request in the wishlist that I implemented and later found useful. Again, I see no reason to limit functionality that is useful.
- There's a single project file/definition in ProjectOrganizer, if I
understand correctly there are two in Djynn.
No, there are one per project, one per session, and one for the D plugin configurations. The project configuration-files have their own format and are not conf-files. I've considered using a SQLite3 database instead, which I think would be more elegant in a way, but the current files can be edited in Geany, so that's a plus.
I find the ProjectOrganizer way better in this case.
Yes, that is your privilege of course, we can agree to disagree, I see no problem there.
- Files belonging to a project are defined similarly in both plugins (glob
patterns vs regex), there's a possibility to add files external to the project directory in both plugins.
More or less similar.
In my opinion, both can be extended to become much better. D is limited to what I've had time to include in functionality, and I have some ideas that have yet to be created, but would be practical. I don't really care which of PO or D is better, my consideration is how can either become better.
- In Djynn there is the possibility to add individual files, the tree can
be reorganized by drag and drop. There's no such thing in ProjectOrganizer which basically mirrors the file system structure.
Yes, PO has search functions and indexing of symbols, and D has some additional functionality in the tre-view popup menu. They are different, it's not a bad thing.
Contrary to Djynn, ProjectOrganizer is designed to work for huge projects with thousands of files. When working on such big projects with many collaborators, files and directories get renamed, deleted, added quite often and what you manually add to the project gets invalid in this case. Updating the project every time you make "git pull" is very annoying. For this reason there's no configuration describing how the tree should look
or
what files are in the project - just a directory (plus the external directories) and a glob pattern. I know this might be limiting a bit for you but I'd really like to keep it this way.
Yes, PO is designed for that kind of project management in mind, D isn't. D is designed for smaller projects, like Geany for example. Geany has 99 files in /src, so if I were working on Geany I'd add /src and /plugins to the project as dynamically loaded directories, and would probably add autotools-files in a folder I'd name something like "build", the README, NEWS etc. file would go into a folder too. If those files change, I'd just update the project, but they rarely do so it's not really a problem, it's the /src and /plugins directories that changes more often so they need to load dynamically.
D projects are designed to be worked with, and to be easily changed when the project changes. It's not designed to have all files, but to have the files I work with and need quick access to. If there are thousands of files, usually only a part of them is what I'm working on. Personally I couldn't handle thousands of source files, I'd refuse working on such a project - unless of course I'm assigned to work on a particular part of those files, in which case the D project would only contain the files I'm working on.
Do you think the "vision" of ProjectOrganizer is somehow compatible with your vision of Djynn or is its minimalistic approach too limiting for you?
I use all the functionality of D myself, and anything else has already been removed because I didn't use it. It's a living project that expands with new needs and ideas, and time to realise them. So, yes, removing any functionality of what I already have would be limiting to what I'm used to work with. Fortunately I don't have to.
My impression of what you're writing is that PO is perfect and complete in your opinion, and you see no reason to expand with more functionality, is that correct? On the contrary, for me D is limited by the fact that I don't have time to add more functionality, and would do so otherwise; it's far from complete or perfect. I'd happily add the functionality that PO has already that D is missing, I would consider it enriching the project.
I can't see that we have an agreement Jiri, but it's far from a meaningless conversation.
Cheers, Per
-------------
Hi Thomas,
document_close_all() is useful on its own because there's an important detail: it's transactional. Either all or no documents are closed. As a consequence, if one or more docs spawned a dialog (because of being unsaved) and that dialog is cancelled, then no file is closed.
This is what's done when Geany exits. This is impossible with just doing document_close() in a loop (unless you export document_account_for_unsaved()).
So yes, document_close_all() should be exported.
Having considered that document_close_all() closes all or nothing, it's better to close all with the option to save unsaved files, than nothing happens when switching sessions. Therefore document_close_all() can very well be exported, but I will not use it myself any longer.
Right, Per should do the pull request, since he asks for the function.
Yes, I can do that :-)
Regards, Per
Hi Per,
On Sat, Dec 19, 2015 at 12:43 AM, Per Löwgren per.lowgren@gmail.com wrote:
Hi again Jiri,
It was a long meeting, continuing into dinner and drinks, but now I'm home and continue my reply to your message. I've turned off the digest-function, there should be no more delay in correspondence.
First though, I'd like to say something; when we talk about differences between projects, I don't see that as something negative - actually the opposite. Differences means the projects can extend each other instead of being just similar. So, if PO (Project Organizer) has functionality that D (Djynn) does not, then that can make D better, and vice versa; should they somehow merge. If you see what I mean?
I definitely didn't want to say that PO is "better" or "done" or something like that - sorry if it sounded that way. I just wanted to describe what what were the ideas behind the plugin. Of course you can have a different vision and that's perfectly fine - the two plugins can coexist.
There are basically two options what to do about the plugins:
a. Keep them separate, each doing its project management in a different way. But in this case you should make a pull request to Geany to get the project open/close functions public otherwise nobody will use it because it won't compile with an official Geany release (you said you don't want to make the pull request but I'd suggest to reconsider your decision). I haven't for instance tried your plugin yet just because I'd have to modify Geany first to get your plugin compiled.
b. Find some common subset of the two plugins so there would be a plugins with a core part of the project management functionality and move the rest to a separate plugin(s). This is what I had in my mind when replying to your previous post but I guess our opinions about the core part are pretty different so right now (a) seems like a better option to me.
I can describe the vision of PorjectOrganizer. What I tried to make was a file-aware Geany project (Geany itself doesn't know about the files, it just stores base directory, build options and some common settings for project) in a minimalistic way and reuse as much as possible from Geany itself without duplicating functionality.
Yes, we think the same in many ways :) PO is designed for large or huge projects with hundreds or thousands of files, and D is designed to handle many smaller projects, because that's what I mostly work with. My projects rarely have more than a few hundred source files at most. Workspaces isn't a very important part of D, rather, like in Eclipse, all projects are listed in the tree-view at once and sometimes it becomes too many projects to have in one listing, so the workspaces function makes it possible to organise projects into groups. I may group all PHP-projects into one workspace, and all C projects into one, or my company's projects into one workspace, and my private projects into one etc. you get the point. All in all, D is designed to give quicker access to project's files, so is PO, and if we stick to that as the basic "vision", then anything else is just various "solutions" to the same problem: project file access.
There's a single glob file pattern list per project in ProjectOrganizer defined in project properties. The advantage of a glob pattern over regex is that Geany uses it too and it can be passed to the Find in Files
dialog
so a pattern defined at a single place in the project config is used for everything.
Well, I see no problem here, why limit to glob or regex? Why not give the choice to use either with a checkbox/radio?
Because the patterns from Project->Properties->File Patterns are passed to grep when you select "project" in the "Find in files" dialog and grep doesn't use regex for specifying which files to search using the --include comand-line parameter.
Also the glob patterns are used everywhere else in Geany for file specification so I didn't want to introduce something different.
PO mirrors the project directory and filters files; D picks directories and adds as folders in the project tree, each folder can either filter the files in the mirrored directory or pick specific files, naming or organising of files and folders does not have to mirror the file system, but can be moved anyway you like.
You can attach an arbitrary number of "external directories" to a project in ProjectOrganizer and have their files displayed in the sidebar (and
get
them indexed with the tag manager if needed). It's just not per file but per directory.
Exactly, and PO has some really nice functions for finding in files, which D does not, and D doesn't have indexing of symbols.
- Djynn can have multiple workspaces, ProjectOrganizer just uses Geany's
single "workspace" (basically the "recent projects" list).
Instead of hundreds of files in each project, I have lots and lots of projects and "recent projects" list would not work for me, I need to organise them into groups. So what is useful all depends on how we work.
Sure.
For me this is sufficient, I find the workspace concept a bit too heavyweight for an editor like Geany. Switching between recent projects using Geany's built-in functionality is nice and simple.
No, it's not heavyweight, in that case I'd say PO's functionality to handle hundreds or thousands of project files is heavyweight for a minimalistic IDE. On the contrary I'd say that unless it makes the program very complicated to use, and eats up lots of CPU or memory, it's lightweight. D is extremely lightweight, it uses very little CPU and memory, and is extremely simple to use. Workspaces organise projects into groups, projects and sessions organise files into groups. It's all about how you work, what you need and find useful, often it's a matter of taste, and mostly of course practicality.
OK, "heavyweight" wasn't the best word from me I guess. All the workspaces and sessions thing actually makes sense to me, I'm just not sure I want to add that to PO because this is pretty independent of the rest of PO functionality.
The meaning of "heavyweight" was in terms of the configuration needed to setup or update project. There are no extra config files in PO apart from the Geany project config files. Once you setup the patterns (or just keep the default blank value which is equivalent to * - then there's absolutely no extra configuration, you just create a new Geany project and you are done), there's no configuration needed in the future. If someone from the team gets crazy and reorganizes the whole project directories, you just press the refresh button and the new structure gets reloaded.
However, if the project open/close methods are added to the API, some workspace manager plugin could be made and it could even coexist with the ProjectOrganizer plugin.
Well, D is coexisting with PO already, so, yes, I see no problem here.
Didn't probably express clearly myself here - basically I meant the option (b) from the beginning of the email - i.e. separate workspace/session manager plugin.
- ProjectOrganizer's project has a single session (like Geany) while
Djynn
can have multiple.
Sessions is just a function I need all the time, perhaps you work differently, but for me it's invaluable :) I've only added functionality because that's what I make use of, otherwise it's removed. D had a list of open documents, which was removed when I noticed Addons-plugin has that as a button in the panel; and I use that even more than I use D.
I don't know if I'd ever use more sessions per project so I'm not
planning
to add it to ProjectOrganizer.
Well, so you admit then that PO is "what you need in Geany", and it's not actually designed for a more general use?
Of course I admit it's based on my personal experience and of course it's not meant to be "the one and only true way to do project management". I fully understand your reasons why you do things your way and it's perfectly fine and makes sense.
Again, this is quite independent of the ProjectOrganizer functionality
and
could be done in a separate plugin.
Yes, of course, but I prefer to have the sessions list in the project sidepanel, and D has a configuration for choosing a separate sidepanel of its own or as a tab in the main sidepanel; this was a request in the wishlist that I implemented and later found useful. Again, I see no reason to limit functionality that is useful.
Sure.
- There's a single project file/definition in ProjectOrganizer, if I
understand correctly there are two in Djynn.
No, there are one per project, one per session, and one for the D plugin configurations. The project configuration-files have their own format and are not conf-files. I've considered using a SQLite3 database instead, which I think would be more elegant in a way, but the current files can be edited in Geany, so that's a plus.
Yeah, this is exactly what I meant by "heavyweight" ;-). And SQLite3 config files sound pretty yucky to me - happy you didn't chose this format.
I find the ProjectOrganizer way better in this case.
Yes, that is your privilege of course, we can agree to disagree, I see no problem there.
- Files belonging to a project are defined similarly in both plugins
(glob
patterns vs regex), there's a possibility to add files external to the project directory in both plugins.
More or less similar.
In my opinion, both can be extended to become much better. D is limited to what I've had time to include in functionality, and I have some ideas that have yet to be created, but would be practical. I don't really care which of PO or D is better, my consideration is how can either become better.
Well, my opinion is more isn't always better...
- In Djynn there is the possibility to add individual files, the tree can
be reorganized by drag and drop. There's no such thing in
ProjectOrganizer
which basically mirrors the file system structure.
Yes, PO has search functions and indexing of symbols, and D has some additional functionality in the tre-view popup menu. They are different, it's not a bad thing.
Sure.
Contrary to Djynn, ProjectOrganizer is designed to work for huge projects with thousands of files. When working on such big projects with many collaborators, files and directories get renamed, deleted, added quite often and what you manually add to the project gets invalid in this case. Updating the project every time you make "git pull" is very annoying. For this reason there's no configuration describing how the tree should look
or
what files are in the project - just a directory (plus the external directories) and a glob pattern. I know this might be limiting a bit for you but I'd really like to keep it this way.
Yes, PO is designed for that kind of project management in mind, D isn't. D is designed for smaller projects, like Geany for example. Geany has 99 files in /src, so if I were working on Geany I'd add /src and /plugins to the project as dynamically loaded directories, and would probably add autotools-files in a folder I'd name something like "build", the README, NEWS etc. file would go into a folder too. If those files change, I'd just update the project, but they rarely do so it's not really a problem, it's the /src and /plugins directories that changes more often so they need to load dynamically.
If I'm interested only in C sources, I set *.c *.h as the file pattern in PO and don't have to care in which directories they are - in the sidebar I'll see just the directories containing the sources.
Then there's the indexing thing - even if I don't work on all parts of the project, I often need some function from some other part of the project I'm not working on - by having it indexed I can just Ctrl-click the given function call and get directly to it and learn what it does. It's hard to tell in advance which parts of the project I'll need. Also you get autocompletion for all the symbols from the project.
In fact, for Geany for instance I add full sources of glib and gtk into the external directories so I get autocompletion for all the symbols in gtk and by ctrl-clicking a gtk function I get to its definition with the docstring so I can easily learn what it does.
D projects are designed to be worked with, and to be easily changed when the project changes. It's not designed to have all files, but to have the files I work with and need quick access to. If there are thousands of files, usually only a part of them is what I'm working on. Personally I couldn't handle thousands of source files, I'd refuse working on such a project - unless of course I'm assigned to work on a particular part of those files, in which case the D project would only contain the files I'm working on.
PO projects are designed so you basically don't have to touch them once you make them no matter who makes what changes in the project's file structure.
When I created the plugin I was working on this:
https://en.wikipedia.org/wiki/SCOS_2000
There were something over 2000 C++ source files (plus the same amount of headers), about 100 IDL files for CORBA IPC communication. The whole system consists of about 40 server applications and probably similar number of client applications, all communicating with each other using CORBA. The system has been evolved over 20 years by tens of companies. A lot of fun.
Now when you are working on such a project, you are absolutely lost. If you need to fix a bug, you just don't know which file in which subsystem you'll need to edit. There's no way to "know" what's where because of the project size. You spend most time reading the code and trying to understand what it does. And having it indexed completely helps a lot. Also you need to regularly rebase your work on top of other work made by other companies and you aren't really in control of your sources.
At the time I found Geany the only editor with a reasonable amount of functions to handle a projects of this size. Other editors were either too simple or just kept rescanning all the sources all the time so CPU usage was 100% all the time.
Now of course that's a bit an extreme example but even if you want to start contributing to an existing open source project, you just don't know it and don't know in which subset of files you are interested in and basically want to see the sources, which corresponds to the "*.c" or whatever pattern.
Do you think the "vision" of ProjectOrganizer is somehow compatible with your vision of Djynn or is its minimalistic approach too limiting for
you?
I use all the functionality of D myself, and anything else has already been removed because I didn't use it. It's a living project that expands with new needs and ideas, and time to realise them. So, yes, removing any functionality of what I already have would be limiting to what I'm used to work with. Fortunately I don't have to.
My impression of what you're writing is that PO is perfect and complete in your opinion, and you see no reason to expand with more functionality, is that correct?
Something in between - the current state definitely isn't frozen in any way, on the other hand, I don't want to "overfeature" the plugin. For instance, I could add e.g. file management things to the sidebar like creation/deletion/renaming of the files. On the other hand I believe these features should rather go to the file browser plugin. I think in a similar way regarding the workspaces/sessions as I feel it's something that doesn't quite belong to the plugin. The manual management of the tree is something which I don't want to add because I want to keep the project maintenance-free if its file structure changes.
It's easy to get sw bloated by adding more and more features so I'll always think twice before adding something new. But it doesn't mean no new feature will ever be added to the plugin.
On the contrary, for me D is limited by the fact that I don't have time to add more functionality, and would do so otherwise; it's far from complete or perfect. I'd happily add the functionality that PO has already that D is missing, I would consider it enriching the project.
I can't see that we have an agreement Jiri, but it's far from a meaningless conversation.
No problem at all - I fully understand why you created the plugin and why it works for you. As I said, if I were you, I would just consider making the pull request to make the currently private functions you need public. Your use case makes sense and this way everybody will be able to use your plugin.
Cheers,
Jiri
Hello Colomban!
This particular one is supported for quite some time, see `comment_use_indent`
in Filetypes' settings section http://www.geany.org/manual/#id5 :)
Ok, didn't notice this setting before :-) However, for D (Djynn) I'd still keep the toggle comments function since it behaves differently. It's more of a flavour than additional functionality though. D toggles line comments if lines are selected (or the line at the caret if no selection) (without the tilde), but if text is selected that doesn't start and end with a '\n' that selection is wrapped with a block comment, and if a block comment is selected it toggles to uncommented. There is also a function for inserting Doxygen/Javadoc comments, and a strip comments function.
Cheers Per
------------------------
Hi Jiri!
I definitely didn't want to say that PO is "better" or "done" or something
like that - sorry if it sounded that way. I just wanted to describe what what were the ideas behind the plugin. Of course you can have a different vision and that's perfectly fine - the two plugins can coexist.
Ok, thanks! :-)
There are basically two options what to do about the plugins:
a. Keep them separate, each doing its project management in a different way. But in this case you should make a pull request to Geany to get the project open/close functions public otherwise nobody will use it because it won't compile with an official Geany release (you said you don't want to make the pull request but I'd suggest to reconsider your decision). I haven't for instance tried your plugin yet just because I'd have to modify Geany first to get your plugin compiled.
b. Find some common subset of the two plugins so there would be a plugins with a core part of the project management functionality and move the rest to a separate plugin(s). This is what I had in my mind when replying to your previous post but I guess our opinions about the core part are pretty different so right now (a) seems like a better option to me.
Personally I'd prefer the b-option, because I think it's the most beneficial in most ways. However, and as you say, given that the aims of the projects are in opposite directions, it would be quite difficult to find a common ground.
Seeing that PO works well with libraries such as glib and GTK+, I'll use it in the way you described, which is perfect since I'm working quite a lot with both on many of my projects.
Because the patterns from Project->Properties->File Patterns are passed to grep when you select "project" in the "Find in files" dialog and grep doesn't use regex for specifying which files to search using the --include comand-line parameter.
Also the glob patterns are used everywhere else in Geany for file specification so I didn't want to introduce something different.
Yes, I see. Personally I'm just a fan of regex, and so that made the decision for me ;-) I could change to glob though if it was of vital importance. An alternative would be to default to glob, and if the search string is wrapped in slashes, it's assumed to be regex instead.
OK, "heavyweight" wasn't the best word from me I guess. All the workspaces
and sessions thing actually makes sense to me, I'm just not sure I want to add that to PO because this is pretty independent of the rest of PO functionality.
Np :-)
The meaning of "heavyweight" was in terms of the configuration needed to
setup or update project. There are no extra config files in PO apart from the Geany project config files. Once you setup the patterns (or just keep the default blank value which is equivalent to * - then there's absolutely no extra configuration, you just create a new Geany project and you are done), there's no configuration needed in the future. If someone from the team gets crazy and reorganizes the whole project directories, you just press the refresh button and the new structure gets reloaded.
This same functionality can be accessed in D too, if you define the source directory with a regex pattern instead of glob, at present time. The difference is of course that there is one additional file per project. I don't think reading and parsing one text file per project is much load though. Any changes to the project are immediately written to the project file, and dynamically loaded directories are stored as only the directory and not the files in it. It takes extremely little resources to read and write these files, so the number of files does not account for making it "heavyweight" :-)
Well, my opinion is more isn't always better...
That is very true too! The golden mean is usually a good way, not too much, not too little.
If I'm interested only in C sources, I set *.c *.h as the file pattern in PO and don't have to care in which directories they are - in the sidebar I'll see just the directories containing the sources.
Same in D. With any changes of files, select "Reload workspace" in the popup menu. A function D doesn't have though is to load only files in open folders. At the moment, all files in a directory are loaded; it would be better to add files only when folders are opened.
Then there's the indexing thing - even if I don't work on all parts of the project, I often need some function from some other part of the project I'm not working on - by having it indexed I can just Ctrl-click the given function call and get directly to it and learn what it does. It's hard to tell in advance which parts of the project I'll need. Also you get autocompletion for all the symbols from the project.
A very practical function indeed.
In fact, for Geany for instance I add full sources of glib and gtk into the external directories so I get autocompletion for all the symbols in gtk and by ctrl-clicking a gtk function I get to its definition with the docstring so I can easily learn what it does.
Yes, this is excellent, I will surely use this too!
PO projects are designed so you basically don't have to touch them once you make them no matter who makes what changes in the project's file structure.
When I created the plugin I was working on this:
This is really cool! :-D
There were something over 2000 C++ source files (plus the same amount of headers), about 100 IDL files for CORBA IPC communication. The whole system consists of about 40 server applications and probably similar number of client applications, all communicating with each other using CORBA. The system has been evolved over 20 years by tens of companies. A lot of fun.
Yes, I can't imagine the amount of work to handle such numbers of source files.
Now when you are working on such a project, you are absolutely lost. If you need to fix a bug, you just don't know which file in which subsystem you'll need to edit. There's no way to "know" what's where because of the project size. You spend most time reading the code and trying to understand what it does. And having it indexed completely helps a lot. Also you need to regularly rebase your work on top of other work made by other companies and you aren't really in control of your sources.
At the time I found Geany the only editor with a reasonable amount of functions to handle a projects of this size. Other editors were either too simple or just kept rescanning all the sources all the time so CPU usage was 100% all the time.
Yes, Geany is certainly pure Gold for programmers!
Now of course that's a bit an extreme example but even if you want to start contributing to an existing open source project, you just don't know it and don't know in which subset of files you are interested in and basically want to see the sources, which corresponds to the "*.c" or whatever pattern.
True, PO would be better suited for such projects. D is definitely designed for projects that you know the files in.
I haven't touched Windows since 2007, but when I used to work in Windows there was an editor that extended MinGW, called Dev-C++, with a very simple and practical project manager that also generated makefiles automatically. Dev-C++ became like the blueprint for D when I began working on it. Since I exclusively use CMake for my projects, any autoconfiguration of makefiles becomes useless, and for anyone working with autotools it would be useless too. In fact D is entirely built with CMake, and that's why I've kept it a third party project - Geany, as I've understood, expect all its plugins to build with autotools (or waf, of which I know nothing).
Something in between - the current state definitely isn't frozen in any way, on the other hand, I don't want to "overfeature" the plugin. For instance, I could add e.g. file management things to the sidebar like creation/deletion/renaming of the files. On the other hand I believe these features should rather go to the file browser plugin. I think in a similar way regarding the workspaces/sessions as I feel it's something that doesn't quite belong to the plugin. The manual management of the tree is something which I don't want to add because I want to keep the project maintenance-free if its file structure changes.
Yes, I suppose sessions could be moved to a button similarly to the "Show Document List" button in the toolbar; and that way it could be separated from the project manager - since sessions are actually separate from projects.
Workspaces are part of the project manager however, and it's a concept used by many IDEs, and so not particularly unique to D. It is a very simple and practical feature. Projects in D require very little maintenance, depending on how they are constructed; they can be designed similar to PO, or more specific with picked files - in which case it could cause some maintenance sometimes.
It's easy to get sw bloated by adding more and more features so I'll always think twice before adding something new. But it doesn't mean no new feature will ever be added to the plugin.
It's the same for me, nothing is added that isn't required or useful. When I say "useful" it should be used on a regular basis, and not just that it could be useful, possibly - though it would be quite easy using the file browser instead.
No problem at all - I fully understand why you created the plugin and why it works for you. As I said, if I were you, I would just consider making the pull request to make the currently private functions you need public. Your use case makes sense and this way everybody will be able to use your plugin.
Thank you Jiri for your advice! I will make the pull request and update D. Perhaps you can check it out then. Also, good luck with your work! The space program seems really interesting!
Cheers, Per
Hi Per,
On Sun, Dec 20, 2015 at 10:09 PM, Per Löwgren per.lowgren@gmail.com wrote:
No problem at all - I fully understand why you created the plugin and why it works for you. As I said, if I were you, I would just consider making the pull request to make the currently private functions you need public. Your use case makes sense and this way everybody will be able to use your plugin.
Thank you Jiri for your advice! I will make the pull request and update D. Perhaps you can check it out then.
Sure (but of course it's also up to Colomban and others to decide whether they want it in Geany). Also as others noted, the document_close_all() has a slightly different semantics than just closing documents one by one so it makes sense to make it public too.
Also forgot to mention that when changing API, you should also increment GEANY_API_VERSION in plugindata.h and then require this version of API in your plugin.
Also, good luck with your work! The space program seems really interesting!
Well, I left the job some time ago - but yeah, good luck to anyone who's working on that now :-).
Cheers,
Jiri