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