GNOME Bugzilla – Bug 315043
Anjuta should be able to manage multiple open projects
Last modified: 2009-11-23 21:54:45 UTC
Please describe the problem: People are often confronted with developing a library and developing an application that uses that library. Please provide either the eclipse style way (we have a list of projects which can be opened or closed) or the visual studio way (we have a 'solution' - i'd rather call it 'project session' which depends on some projects which are opened altogether). If you need more information, just feel free to ask. This is blocking me to use anjuta. This way all we could easily have a stable gnome installed and a set of some unstable libraries in our project folder, they can be build and installed automatically with _build and _install folders - which is what make distcheck does too - and anjuta could set paths like PATH, LD_LIBRARY_PATH, PKG_CONFIG_PATH, etc. automatically to what is specified within a projects dependencies on other projects. Steps to reproduce: Actual results: Expected results: Does this happen every time? Other information:
While it's unlikely to happen soon this might be a real good enhancement
To be able to do manage multiple projects I thought of a notebook which holds the gnome-build project views. It is not easily possible to arrange multiple projects in one GtkTreeView because gnome-build derives from GtkTreeModel to manage a project. The notebook page always shows the active project, e.g. the one all project operations ("Build project", "CVS: update") operate on. Changing the notebook tab will change the active project and change the file-view root directory. Later there could a submenu "Active project->", too. I have attached a screen shot from a early version. It is no mockup but it is too unstable to already provide a patch. I would like people (esspecially, Sven and Philip) to tell me if they like the way I want to support this. Regards, Johannnes
Created attachment 69969 [details] Screenshot
1. Vertical labels are evil (see HIG for more information) 2. Please hide the tabs at all and put a combo box over the tree 3. Why not create a tree model that merges other tree models - I'm just developing such a tree model for an application, I will show you the code once it's ready.
(In reply to comment #4) > 1. Vertical labels are evil (see HIG for more information) Yes, but they do not use that much space... > 2. Please hide the tabs at all and put a combo box over the tree Yes, this is a good option! > 3. Why not create a tree model that merges other tree models - I'm just > developing such a tree model for an application, I will show you the code once > it's ready. This will confuse the user because in reality, only one project open, the others are just shown and get active when you bring them in front.
Created attachment 69979 [details] Improved Screenshot Improved version with changes the things Sven commented on! This looks quite stable here in the moment and might go into CVS soon!
(In reply to comment #6) > This looks quite stable here in the moment and might go into CVS soon! really a nice enhancements i don't see the time to use it..
(In reply to comment #6) > Created an attachment (id=69979) [edit] > Improved Screenshot > > Improved version with changes the things Sven commented on! > > This looks quite stable here in the moment and might go into CVS soon! > How different is it from switching the projects from recent menu (which is also available at the toolbar). Does it cache the project data in memory? Also do you have a 'meta project' to group the projects -- 'solution' or 'workspace', or you have to open them one by one everytime?
The projects are cashed in memory, the only thing which really changes is "project_root_uri". Each project has it's own GbfProject instance. I thought about how to organize multi-open projects in the recent menu ('workspace'). Anyway, I did not come to a complete conclusion here. In the moment you have to open them one by one and only the last opened is reopened on restart. Most of the stuff works now but I have to do some work on the default-profile plugin to avoid reloading when the user opens the same project twice.
I have though about this for long but I don't think it is a good idea in the current project direction. To many things depend on the philosophie of having a single project. It is still possible to open two instances of anjuta in case you need to.