Project Manager - Basic Specification

  • Chris Wilson

    Chris Wilson - 2004-04-20

    OK, so before I go to bed (it's now just gone 2.30am here in the UK and I need to be on-site at 9am) I'll just give you the basics of what I have in mind and how I propose going about adding the project manager to DrPython:

    - In a similar way to the current bookmarks implementation, the project manager will allow source code files and folders to be added and represented as a tree structure. This will enable organisation of source code independent of the directory structure and physical location of the files.
    - Each project may have its own preferences file which will be applied in the same way as "update" in the preferences dialog when the project is loaded. By default, the system wide preferences will be pointed to, but if any project specific changes are required, a new copy of the preferences file will be made automatically and this will be pointed to and modified rather than the main system one. A flag in the project settings (see below) will allow system wide preference to be used instead. Having project based preferences will allow the user to specify different encoding, and even different line-endings for the entire project. I can't imagine there being a need to specify these for specific files.
    - For each file the project manager will maintain a loaded/visible flag, current cursor position, the code-folding state and any codemarks. This will allow the exact state of the workspace to be recalled when the project is reloaded, and I hope to extend the use of codemarks to allow notes and "to-do" items to be associated with each file.
    - All settings (except the preferences which will be stored in a separate file as they are currently and referenced by the project file) will be stored in a single Dr Python Project File (.dpf) and new Load and Save Project menu items and shortcuts will be added.
    - Clicking on a source file in the project manager will either auto-select the tab if the file is already open, or load the file into a new tab.
    - I propose storing codemarks as part of a project. Upon starting DrPython, a default blank project will be loaded and as files are loaded/created/edited, all relevant data will be updated.
    - When a new file is loaded using the standard menu option, the user will be given the option to add it to the project or just edit it independently.
    - When a file which is part of the project is saved using "Save as..." from the file menu, the user will be given the option to update the reference in the project or keep the reference to the original file.
    - When the user exits DrPython, they will be given the option to save the current project and warned that if they don't, any codemarks etc. will be lost.
    - Each project will have it's own default folder (bookmark) to simplify adding multiple files.
    - The project file will store the proposed codemarks for each source file, and I hope to extend the proposed codemarks to allow notes and "to-do" items to be implemented using this feature.
    - There will be project wide information such as version number, author, own-preferences flag etc. as well as a free-format notes feature. This notes area could be used to store a specification for the overall project as well as general notes about its implementation and current state. At some point in the future I'd like to extended this to allow date/time based notes to be entered. This would allow a version/change history to be manually built by the user.
    - Initially I'll implement the project manager in a separate dialog (with sub-dialogs as required) but it would be almost essential for it to be part of the main MDI interface, and so the proposed new resizeable panes feature will be very important.

    I'm going to spend tomorrow evening looking through the existing CVS code in detail to get myself in the right frame of mind for extending DrPython. Assuming I get time, and there are no major disagreements on how this should be implemented, I'll probably start coding right away. I'd hope to get a basic version together in a couple of days, and a more polished version ready to drop into the CVS tree by the end of the week.

    Please let me have your thoughts on this ASAP so I don't waste any time.

    • Daniel Pozmanter

      This looks very good.  My thoughts:

      When updating a reference (Save As) there should be 3 options:  Switch (Now the link points to this file instead), Add to the Project, Do Not Add to the Project.

      I would advise storing and loading very specific preferences, rather than all of them.

      Also, I may not get to codemarks/resizable for a bit.

      The user should be able to "just use DrPython" w/o using projects.  All of this reminder stuff should only occur if a project has been loaded.

    • Chris Wilson

      Chris Wilson - 2004-04-20

      The three options for "Save as..." seems like a good idea.

      There are two main reasons for allowing *ALL* preferences to be changed for a specific project. Firstly, it's easier, as the editing dialog etc. are already in place and could be used with only very minor tweaking. Secondly, this would allow you to load a project into DrPython on another PC and immediately be using your own preferences rather than those on the new PC. This is a "two birds with one stone" thing, as I always end up taking a copy of my preferences file with me when I'm working on other PCs, and this would save me having to do that. Unticking the "Use Project Preferences" project option  would then allow you to use the preferences on the PC.

      Regarding allowing the user to "just use DrPython". I've always had it in mind that an empty project would always be loaded and the user could just ignore it if they wanted to code individual files. As we are proposing various user prompts relating to the Project Manager, I'd suggest adding and "Enable Project Manager" option in preferences, and simply not displaying the dialog/pane and related user prompts/messages if this isn't ticked. Behind the scenes, the empty project should still be available and updated so it could still be used to store things like codemarks etc.

    • Daniel Pozmanter

      How about an option (in prefs) to save your prefs in project files (In fact, it would be good to specify what gets saved in a project file via prefs).

      In terms of Just using DrPython:

      Once a project is open, DrPython can behave in the way you specify.  However if no project is currently open, dont check to see if the user wants to save the project, etc.

      I agree the project should be availible behind the scenes.  But does anything need to be constantly updated?  Couldn't DrPython just grab the necessary data when saving a project?

    • Chris Wilson

      Chris Wilson - 2004-04-20

      An option to specify whether the system stores its preferences in a common file or project would be a good idea, and keep things nice and simple.

      The reason for having the project open and updated whether it's being used or not, is that it is always up-to-date. If we don't do this, then there will be two ways of updating the project - on the fly, and all-at-once, and therefore two separate bits of code. The performance hit of minor changes as they happen is almost non-existent, but generating all the required data would be noticeable.

      From the users point of view, I suppose the default could be to have the project manager hidden until they select "New Project", but have an option in preferences to say whether the project manager (and therefore a blank project) is shown on start-up or not.

      Don't worry, I'd certainly never add features that change the way DrPython works unless the users wants them to. After an upgrade the user experience should be, as far as possible, the same unless they specifically enable new features. Simply hiding the project manager by default will achieve this goal.

      I could see the project manager as becoming a kind of central repository for quite a range of application wide data, and this would simplify the addition of new features which require/use stored data by giving them a logical place to store things.

    • Daniel Pozmanter

      Let's get this puppy started.

    • Chris Wilson

      Chris Wilson - 2004-06-03

      OK, after an extended period of intense work with absolutely no time for play, I'm back.

      Sorry to talk through the whole project manager/to-do list proposals and then just vanish without a word, or more importantly doing anything about them.

      I'll be able to start working on these (if you guys still want me to) this weekend, and most of next week I should be free in the evenings as well.

      I'll dig out and finish the basic specification I had a month or so ago, and post it here this evening. Let me know how you'd like to proceed. I'm still very keen to implement these features.

      I'll pull down the latest CVS version tonight and have a look to see how it all fits together with the plug-in and multi-pane features now in place.

    • Daniel Pozmanter

      Glad to have you back.

      Here's the plan.

      The pane work is not completely done (I want to write a function that adds a panel to a specific pane, and handles situations where that pane is already in use).  I will try to get this done ASAP.

      The one addition to the project manager specification is that in allow the user to specify installed plugin indexes, and to load them when the project is open.

      I have moved the code for updating file status to the tabs.  Should we make the main frame title reflect the status of the project, or keep it the way it is (or have it be static?).

      Aside from this, stuff should pretty much be ready to go.  Codemarks are not yet implemented.  I am not sure whether or not I want to implement it as a built-in or as a plugin.

    • Daniel Pozmanter

      I was thinking that the project manager should be implemented as a plugin.

      What thoughts?


Log in to post a comment.