Hi Jiri,
> I have written some notes below how Djynn's project management differs from
> ProjectOrganizer and some rationale for why I went that way. In my opinion
> the core functionality is quite similar.
>
> On Wed, Dec 16, 2015 at 4:09 PM, Per L?wgren <per.lowgren@gmail.com> wrote:
>
> > Hello,
> >
> > I reply to all of your posts in one message. Hope that's ok.
> >
> > Basically, the terminology Djynn use is:
> > * workspace: a set of projects
> >
>
> There's nothing like that in ProjectOrganizer - as I didn't want to
> duplicate functionality which is already in Geany, I just kept things
> simple in this respect so switching between projects is done using Geany's
> standard project opening functionality and recent projects. Maybe we could
> increase the number of the shown recent projects so it's easier to open
> projects for people with many projects.
>
>
> > * project: a set of files, organised into a directory tree, that may or
> > may not be opened
> >
>
> This is the same in ProjectOrganizer. Moreover, ProjectOrganizer stores its
> config into the standard Geany project file so there's a single project
> file. I believe there are two project files in your case the Djynn one and
> the Geany one and this "two-project" thing makes things a bit confusing for
> users. Did you know you can store your config options into the Geany
> project file using the API?
>
>
> > * session: a set of opened documents in the editor
> >
>
> This is how it's in Geany too, there's just a single session per project -
> on project opening your previous session is restored.
>
>
> >
> > In Geany, a project is the configuration of the project, including editing
> > and building.
> >
>
> Since ProjectOrganizer is an extension of Geany project, there's no
> distinction between Geany project and ProjectOrganizer project - they are
> one.
>
>
> In answer to your question: The session manager; it switches between
> > sessions, and stores many sessions. When switching between sessions, all
> > opened documents are stored in the present session's file; then all opened
> > documents are closed; then the documents in the next session are opened.
> >
>
> ProjectOrganizer does basically nothing with sessions and uses Geany's
> session management.
>
>
> >
> >
> > > Sounds like reasonable usage, I think you can just open Geany pull
> > request
> > > to make these public. To make a function public, you just need to:
> > >
> > > 1. Prefix the implementation with GEANY_API_SYMBOL.
> > > 2. Add some user-visible API documentation with a docstring (see other
> > API
> > > functions in the code to have an idea how it should look)
> > > 3. Move the function declarations above GEANY_PRIVATE in the header.
> > >
> > > That's about it.
> >
> > That would work on my computer, but not on Launchpad, or for anyone else.
> >
>
> Here I meant you could make a pull request to Geany so it can be merged to
> Geany and available for everyone in the next release.
>
> The Project Organizer is an interesting plugin, they are similar, but works
> > very differently.
> >
>
> I don't think it's so different, IMO the only big extra things in Djynn are
> the workspace management and session management.
>
> If we can agree on a common "vision", I'd happily contribute to that.
> >
>
> 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.
>
>
> > Djynn has regex pattern add files on a per directory basis, i.e. you can
> > add a directory and tell to search files according to pattern, and recurse
> > into subfolders,
> >
>
> 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.
>
> but you can still have fixed files added too; e.g. you can add files from
> > the project source directory, and also add `~/.config/project/file.conf`
> > etc.
> >
>
> 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.
>
> To sum up the differences:
>
> * Djynn can have multiple workspaces, ProjectOrganizer just uses Geany's
> single "workspace" (basically the "recent projects" list).
>
> 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.
>
> 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.
>
> * ProjectOrganizer's project has a single session (like Geany) while Djynn
> can have multiple.
>
> I don't know if I'd ever use more sessions per project so I'm not planning
> to add it to ProjectOrganizer.
>
> Again, this is quite independent of the ProjectOrganizer functionality and
> could be done in a separate plugin.
>
> * There's a single project file/definition in ProjectOrganizer, if I
> understand correctly there are two in Djynn.
>
> I find the ProjectOrganizer way better in this case.
>
> * 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 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.
>
> 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.
>
> Do you think the "vision" of ProjectOrganizer is somehow compatible with
> your vision of Djynn or is its minimalistic approach too limiting for you?
>
> Cheers,
>
> Jiri
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <http://lists.geany.org/pipermail/devel/attachments/20151217/7191fd2a/attachment-0001.html>
>
> ------------------------------
>
> Message: 2
> Date: Thu, 17 Dec 2015 11:45:37 +0100
> From: Thomas Martitz <kugel@rockbox.org>
> To: devel@lists.geany.org
> Subject: Re: [Geany-Devel] Devel Digest, Vol 93, Issue 2
> Message-ID: <56729251.2060008@rockbox.org>
> Content-Type: text/plain; charset=UTF-8; format=flowed
>
> Am 15.12.2015 um 14:38 schrieb Ji?? Techet:
> >
> >
> >     I can probably find an alternative workaround for
> >     document_close_all, e.g. iterate document_index(0) until it
> >     returns NULL, and call document_close; so I think should be ok too.
> >
> >
> > Yep, it should be pretty easy to do this manually so the question is
> > whether extra API is needed.
>
> 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.
>
> >
> >
> >     Anyway, I'm sure document_close_all could be used by many plugins,
> >     but filetypes_detect_from_document is not needed. The project
> >     functions would be much appreciated. That's all on my xmas wishlist :)
> >
> >
> > As it usually works, the best presents have to come from yourself,
> > there will be just socks and pyjamas under the Christmas tree :-).
> >
>
> Right, Per should do the pull request, since he asks for the function.
>
>
> ------------------------------
>
> Message: 3
> Date: Thu, 17 Dec 2015 22:48:13 +0100
> From: Per L?wgren <per.lowgren@gmail.com>
> To: devel@lists.geany.org
> Subject: Re: [Geany-Devel] Devel Digest, Vol 93, Issue 4
> Message-ID:
>         <CANN0RWKLCVegm2Wh-izxbFLSpvwnS7-DkQ1MFLzpuZ+HYnsqVw@mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> > What they were suggesting would work for others and not just your own
> > computer.
> > What was meant here is to:
> >
> >  1. /Fork geany on github./
> >  2. Modify geany's code to add GEANY_API_SYMBOL to the functions you
> >     want made public.
> >  3. Add API documentation
> >  4. Move the function declarations above GEANY_PRIVATE in the header.
> >  5. /Commit the changes to your fork on github./
> >  6. /Create a "pull request" from /_/within github's web interface/_/,
> >     requesting pulling the changes in to the core product./
> >
> > That way, everyone benefits :-)
> >
> > I've been considering doing this myself to get some functionality back
> > for my plugins since they fixed the symbols for linux.
>
>
> Hi Steve,
>
> Thank you for the input!
>
> At the moment I think I'll keep my plugin third party and stick with the
> public API as it is. There is one plugin for managing projects already, and
> seems superfluous with another. I keep the plugin publicly available
> because it's there and might as well be :-)
>
> Regards,
> Per
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <http://lists.geany.org/pipermail/devel/attachments/20151217/f67b31a4/attachment-0001.html>
>
> ------------------------------
>
> Subject: Digest Footer
>
> _______________________________________________
> Devel mailing list
> Devel@lists.geany.org
> https://lists.geany.org/cgi-bin/mailman/listinfo/devel
>
>
> ------------------------------
>
> End of Devel Digest, Vol 93, Issue 5
> ************************************