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 * project: a set of files, organised into a directory tree, that may or may not be opened * session: a set of opened documents in the editor
In Geany, a project is the configuration of the project, including editing and building.
I've got what might be a stupid question, but couldn't your plugin integrate with Geany projects the other way around, e.g. your plugin reacts to project open/close rather than making Geany react to your plugin's project open/close?
It's actually a good question, however, opening a project in Djynn means to view the files in that project in the tree-view; while opening a project in Geany means to change configurations according to that project. So, in Djynn, when I want to open a Geany project, I double click on it in the projectmanager tree-view, instead of selecting it in the project menu.
I must admit I didn't try your plugin, but there are a few other plugins enhancing Geany's project support, and AFAIU they do this by listening to Geany project open/close and add their own logic to that.
That's a great idea! I'll see what I can come up with.
Adding `document_close_all()` sounds reasonable indeed. Out of curiosity, why do you need it?
Well, actually, I've found a solution for `document_close_all()`, this works as well: while((doc=document_get_current())!=NULL) document_close(doc);
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.
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:
- Prefix the implementation with GEANY_API_SYMBOL.
- 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.
For the moment I'll disable the project functions, that's ok.
As it usually works, the best presents have to come from yourself, there will be just socks and pyjamas under the Christmas tree :-).
I'd actually need just that, comfy socks and a pyjamas would be really nice, perhaps I'll buy that for myself :-)
If I understand the project part of the plugin (haven't tried it either), it tries to simplify switching between projects and organizing projects into workspaces. In the screenshot here
http://plugins.geany.org/djynn.html
it seems that the second combo serves switching between projects in a workspace so it's the plugin which decides whether a project should be opened/closed rather than Geany. This functionality cannot be done with listening to the signals only so access to project_open()/close() makes sense here.
That's true. Though opening the Geany project could actually trigger the project in the Djynn tree-view opening to visible, and close other project folders.
The other thing is the plugin itself is a bit too "All the stuff I need in Geany" and it would be better break the functionality into individual plugins, or extending existing plugins or adding the functionality
directly
to Geany.
Yes, more or less, I've yet to find a use for base58 encoding, but the rest is used all the time :-) When I began working on Djynn in 2012 it was part of a library (https://code.google.com/p/libamanita/wiki/djynn), and I didn't intend it to be anything more than "what I need in Geany".
I could probably break Djynn into several plugins, but it would become a lot more maintenance work handling many projects instead of one. I'm open to extending existing plugins or adding directly to Geany.
The Project Organizer is an interesting plugin, they are similar, but works very differently. If we can agree on a common "vision", I'd happily contribute to that. 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, 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.
Then there is commenting, encoding and line ordering; that could be broken into three plugins, or preferably one "Extended editing" or something similar; there are no other plugins that suggest merging that I can see.
If there is anything you would add directly to Geany, let me know.
Regards, Per
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.
Thanks,
Steve
On 12/16/2015 08:09 AM, Per Löwgren wrote:
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:
- Prefix the implementation with GEANY_API_SYMBOL.
- 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.
For the moment I'll disable the project functions, that's ok.
Hi Per,
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:
- Prefix the implementation with GEANY_API_SYMBOL.
- 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