More profound project management

[GoogleCodeExporter]

I think that the lightweight model of the file browser suits a lot of peoples 
need in a very simple and intuitive fashion. Yet, there are use-cases, for 
which more 'real' project management may be valuable.

Whether this should be sort of an extension of the file browser, a new tool, or 
integrated with IEP, I do not yet know. 

This issue is related to issue 179.

Ideas are very welcome.

Original issue reported on code.google.com by almar.klein@gmail.com on 6 Mar 2013 at 11:13

[GoogleCodeExporter]

So, as I've stated earlier I've got a couple of ideas related to the project 
manager. Again noting that I'm relatively new in this.

The project manager must indeed be lightweight and not resembling too much 
anything in "serious" IDEs (no insult intended) like Eclipse and Eric. I think 
it can be somewhat of a whiteboard, accepting several kinds of information 
(preferably through drag & drop):
- Selected information from the workspace - if you have a special variable that 
you want to keep handy, or some other important piece of information
- Selected files from the file browser; the question is how to treat those 
files considering project-type files and special folders are annoying features 
of the above; I suggest using files in-place, but allowing for an "append to 
project" option which will copy the files to a special folder (which again is 
not opened by default but rather by choice) or to the home folder of the 
project file.
- Other needed files such as picture, external libraries etc. These could be 
managed in folders by the project manager, but would also be available in the 
"whiteboard".
- Keeps a Project Settings file in the same directory of the first *.py module 
(+ a default settings file for general use in the home directory of the 
program) with workspace settings (filters etc.), GUI settings (including theme, 
visible modules and frame sizes), whiteboard contents, session information and 
open shells (basically - "workspace").
- Possible integration with flowchart programs such as VUE and Xmind, or 
something else that can help visualise program structure, flow of control etc.

So the process would be this:
1. One has a whiteboard frame (module frame) open
2. Can work on a any file (or just form the editor, without saving) while 
ignoring it completely.
3. Can use the whiteboard While editing any kind of file and the contents 
remain the same.
4. Can choose "create project" which will create a project file in the 
currently chosen directory or in the default directory. When loading a project 
file IEP changes both visually and functionally and the whiteboard contents are 
replaced.
5. Can switch between *open* projects through a scrolling list above the 
whiteboard. "Default" project is always the first value in the list and is 
automatically chosen when all other projects are closed.
6. Can always load a project file from disk - this and the above guarantee 
minimum clutter in the program itself - you open projects like you open any 
other file, and you manage them through the disk / file browser and not through 
a special GUI.
7. If d & ding file to the whiteboard, they are used in place with absolute or 
relative references as per a setting (in program setting) and their location is 
saved in the project file.
8. Files can be "appended" to project, in which case a local copy is used.
9. The minimum usage scenario is the "default" project, when you basically work 
as you do today, just have a flexible whiteboard.
10. Middle-of-the-road setting is one project file and one *.py in the same 
directory (whatever than can be), with references to any other file being used. 
These two can be moved as needed, as long as they remain coupled.
11. Maximum usage scenario is a folder with one project file, various *.py and 
auxiliary files, and a hierarchy of subfolders as needed. The whole folder can 
be moved as needed.

Original comment by zaha...@gmail.com on 17 Mar 2013 at 10:58

[GoogleCodeExporter]

You touch on some interesting ideas, but I don't think that I understand what 
you mean by 'whiteboard'. Can you expand on that?

Original comment by almar.klein@gmail.com on 19 Mar 2013 at 11:10

[GoogleCodeExporter]

Well, I used the term to describe a degree of flexibility, but actually the 
right term would be a "bin".
In general a "whiteboard", as the one used in classrooms and offices, is a good 
metaphor for some apps like OneNote - you can place on and in it all sorts of 
items as if it was an infinite board - text, images and screen captures, audio 
files and recordings, geometric shapes and drawings, and you can move them 
around, resize and delete them, in a manner that's relatively intuitive and 
flowing.
Now, since I wasn't really meaning that, it is a slightly misleading term. I 
was thinking of a smaller number of item types: Files of all sorts, folders (to 
sort files), some pre-set fields for text (such as "favourite variables"), and 
possibly extensions to helper programs such as VUE and Xmind (charts, diagrams 
etc.), with the ability to move or sort them such that that little space 
(assuming the Editor takes the most screen space) would provide a lot of 
functionality and do so without much effort. It could do so with a lot less 
flexibility than a true "whiteboard", but it should be as easy to use.

Original comment by zaha...@gmail.com on 19 Mar 2013 at 3:24

[GoogleCodeExporter]

As part of migrating our code repositories from Googlecode
to Bitbucket, all IEP issues are now tracked at 
https://bitbucket.org/iep-project/iep/issues

To view this issue, use this link (with X replaced by the issue number):
https://bitbucket.org/iep-project/iep/issue/X

Issues on Bitbucket can be created by anyone. Commenting on issues requires 
login via Bitbucket, Google, Twitter or Github.

Original comment by almar.klein@gmail.com on 11 Jun 2013 at 2:40

• Changed state: Moved