Hi JP, I've just committed the patches to gnome-build and anjuta2 I sent last week, which implement the GbfProjectView widget, and modify anjuta2's project tool to use it. Apart from the new files in gnome-build (gbf-project-view.[ch], gbf-project-model.[ch] and test-project-view.c) I removed default-icon.[ch] (which should have been removed when the icon API moved to gdl) and the old widgets gbf-project-tree.[ch] and gbf-target-tree.[ch]. Full patches are attached. Regards, Gustavo On Sun, 2003-01-05 at 23:27, Gustavo Giráldez wrote: > Hi all, > > The attached files are the implementation of a new widget for the > gnome-build module. It's based on the ideas and work started by Dave > some time ago. > > The widget, GbfProjectView, is intended to replace the current > GbfProjectTree and GbfTargetTree widgets. In contrast with these two, > it presents a model of the targets in a gnome-build project (GbfProject) > in a hierarchical way. This is, it has the same information as the > GbfTargetTree (targets and its sources), but they are arranged in a tree > (resembling the structure of the files in the filesystem). > > Since the changes introduced by these patches are quite important, I'm > asking for the general opinion of the people in the list, and the > maintainers in particular, before committing, since the old widgets will > be replaced. > > The reason for the new approach is two-fold: > > 1) The actual implementation of the automake backend generates targets > for all files in the project directory. That is, not only programs and > libraries, but any file that participates in the package (scripts, built > sources, installed data files, etc.). This behavior bloats the > GbfTargetTree, which was originally meant to be a quick list to access > the important files. The new widget overcomes this difficulties by: a) > presenting the targets organized hierarchically, and b) by providing a > configurable shortcut area (before the normal tree of targets), where > the user can drag the targets she needs quick access to. > > 2) The new widget combines the good aspects of both the old widgets: the > GbfTargetTree provides visual information about how the files are > grouped to generate a given target, but since it's a non-organized flat > list, it becomes useless (a medium sized project can easily have more > than 20 targets); the GbfProjectTree presents files in an organized way, > but gives no information on what files generate which target (i.e. > program or library) and hence there's no easy way to modify such > relationship. > > Besides these two practical (usability?) reasons, the new widget > actually works better than the old ones: > > - Model updating is incremental (this could be done in the old widgets > too, but currently when they receive the "project-updated" signal, the > clear the model and re-read it completely) > - Add and remove source work in the patched project manager for anjuta2 > (which of course can be done for the other widgets :-) > - Drag and drop interfaces are already implemented, and it should be > easy to extend them to, for example, add a source by dragging a file > from a nautilus window > > So, what do you people think? I think it's a much better approach at > presenting the project to the user and interacting with it, but someone > can prove me wrong, and I'm open to new ideas and suggestions. If > people agree and once the maintainers give me green light to commit, > I'll continue to add functionality to the project manager. > > Thanks, > Gustavo >
Attachment:
anjuta2.patch.gz
Description: GNU Zip compressed data
Attachment:
gnome-build.patch.gz
Description: GNU Zip compressed data