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