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