Hi Per, On Sat, Dec 19, 2015 at 12:43 AM, Per Löwgren <per.lowg...@gmail.com> wrote:
> 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 definitely didn't want to say that PO is "better" or "done" or something like that - sorry if it sounded that way. I just wanted to describe what what were the ideas behind the plugin. Of course you can have a different vision and that's perfectly fine - the two plugins can coexist. There are basically two options what to do about the plugins: a. Keep them separate, each doing its project management in a different way. But in this case you should make a pull request to Geany to get the project open/close functions public otherwise nobody will use it because it won't compile with an official Geany release (you said you don't want to make the pull request but I'd suggest to reconsider your decision). I haven't for instance tried your plugin yet just because I'd have to modify Geany first to get your plugin compiled. b. Find some common subset of the two plugins so there would be a plugins with a core part of the project management functionality and move the rest to a separate plugin(s). This is what I had in my mind when replying to your previous post but I guess our opinions about the core part are pretty different so right now (a) seems like a better option to me. > > 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? > Because the patterns from Project->Properties->File Patterns are passed to grep when you select "project" in the "Find in files" dialog and grep doesn't use regex for specifying which files to search using the --include comand-line parameter. Also the glob patterns are used everywhere else in Geany for file specification so I didn't want to introduce something different. > > 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. > Sure. > > > > > 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. > OK, "heavyweight" wasn't the best word from me I guess. All the workspaces and sessions thing actually makes sense to me, I'm just not sure I want to add that to PO because this is pretty independent of the rest of PO functionality. The meaning of "heavyweight" was in terms of the configuration needed to setup or update project. There are no extra config files in PO apart from the Geany project config files. Once you setup the patterns (or just keep the default blank value which is equivalent to * - then there's absolutely no extra configuration, you just create a new Geany project and you are done), there's no configuration needed in the future. If someone from the team gets crazy and reorganizes the whole project directories, you just press the refresh button and the new structure gets reloaded. > > > > 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. > Didn't probably express clearly myself here - basically I meant the option (b) from the beginning of the email - i.e. separate workspace/session manager plugin. > > > * 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? > Of course I admit it's based on my personal experience and of course it's not meant to be "the one and only true way to do project management". I fully understand your reasons why you do things your way and it's perfectly fine and makes sense. > > > > > 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. > Sure. > > > > > * 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. > Yeah, this is exactly what I meant by "heavyweight" ;-). And SQLite3 config files sound pretty yucky to me - happy you didn't chose this format. > > > > 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. > Well, my opinion is more isn't always 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. > Sure. > > > > > 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. > If I'm interested only in C sources, I set *.c *.h as the file pattern in PO and don't have to care in which directories they are - in the sidebar I'll see just the directories containing the sources. Then there's the indexing thing - even if I don't work on all parts of the project, I often need some function from some other part of the project I'm not working on - by having it indexed I can just Ctrl-click the given function call and get directly to it and learn what it does. It's hard to tell in advance which parts of the project I'll need. Also you get autocompletion for all the symbols from the project. In fact, for Geany for instance I add full sources of glib and gtk into the external directories so I get autocompletion for all the symbols in gtk and by ctrl-clicking a gtk function I get to its definition with the docstring so I can easily learn what it does. > > 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. > PO projects are designed so you basically don't have to touch them once you make them no matter who makes what changes in the project's file structure. When I created the plugin I was working on this: https://en.wikipedia.org/wiki/SCOS_2000 There were something over 2000 C++ source files (plus the same amount of headers), about 100 IDL files for CORBA IPC communication. The whole system consists of about 40 server applications and probably similar number of client applications, all communicating with each other using CORBA. The system has been evolved over 20 years by tens of companies. A lot of fun. Now when you are working on such a project, you are absolutely lost. If you need to fix a bug, you just don't know which file in which subsystem you'll need to edit. There's no way to "know" what's where because of the project size. You spend most time reading the code and trying to understand what it does. And having it indexed completely helps a lot. Also you need to regularly rebase your work on top of other work made by other companies and you aren't really in control of your sources. At the time I found Geany the only editor with a reasonable amount of functions to handle a projects of this size. Other editors were either too simple or just kept rescanning all the sources all the time so CPU usage was 100% all the time. Now of course that's a bit an extreme example but even if you want to start contributing to an existing open source project, you just don't know it and don't know in which subset of files you are interested in and basically want to see the sources, which corresponds to the "*.c" or whatever pattern. > > > > > 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? > Something in between - the current state definitely isn't frozen in any way, on the other hand, I don't want to "overfeature" the plugin. For instance, I could add e.g. file management things to the sidebar like creation/deletion/renaming of the files. On the other hand I believe these features should rather go to the file browser plugin. I think in a similar way regarding the workspaces/sessions as I feel it's something that doesn't quite belong to the plugin. The manual management of the tree is something which I don't want to add because I want to keep the project maintenance-free if its file structure changes. It's easy to get sw bloated by adding more and more features so I'll always think twice before adding something new. But it doesn't mean no new feature will ever be added to the plugin. > 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. > No problem at all - I fully understand why you created the plugin and why it works for you. As I said, if I were you, I would just consider making the pull request to make the currently private functions you need public. Your use case makes sense and this way everybody will be able to use your plugin. Cheers, Jiri
_______________________________________________ Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
