Re: RFC: GbfProjectView widget

[Jeroen Zwartepoorte <jeroen xs4all nl>]

Hi Gustavo,

On Mon, 2003-01-06 at 03: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.

I like the approach of only 1 view for both the sources and targets. Is
it possible yet to remove a shortcut btw? The test program you sent me
yesterday didn't allow this afaict.

Looks fine to me otherwise,

Jeroen