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.lowg...@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 <ku...@rockbox.org> > To: devel@lists.geany.org > Subject: Re: [Geany-Devel] Devel Digest, Vol 93, Issue 2 > Message-ID: <56729251.2060...@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.lowg...@gmail.com> > To: devel@lists.geany.org > Subject: Re: [Geany-Devel] Devel Digest, Vol 93, Issue 4 > Message-ID: > < cann0rwklcvegm2wh-izxbflspvwns7-dkq1mflzpuz+hyns...@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 > ************************************
_______________________________________________ Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
