Re: RFC: GbfProjectView widget



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



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]