Re: RFC: GbfProjectView widget
- From: Gustavo Giráldez <gustavo giraldez gmx net>
- To: John Palmieri <johnp martianrock com>
- Cc: Gnome Devtools list <gnome-devtools gnome org>
- Subject: Re: RFC: GbfProjectView widget
- Date: 06 Jan 2003 20:01:08 -0300
Hi,
On Mon, 2003-01-06 at 00:45, John Palmieri wrote:
> I haven't compiled it yet but I like the screen shot. One of my biggest
> gripes about the current project widget is that it only shows what is in
> the Makefile.am files. That is to say Makefile.am doesn't even show up
> in the project widget and I edit it extensivly. Another little thing is
> that when I do edit the Makefile.am I have to relaunch Anjuta to see the
> changes in the project widget. It is in development so I don't complain
> :-)
Well, when the automake backend and the anjuta2 project tool are
finished you won't have to edit Makefile.am files. At least that's my
goal ;-)
As for relaunching Anjuta, file monitoring in the backend is in my todo
list, but in the meantime you can close the project and re-open it (i.e.
you don't need to relaunch the application).
> I like how you widget gives a directory view as well as a quicklist of
> targets. Only thing I would suggest is to make the directory view
> another tab or perhaps allow the views to be configurable and allow
One of the principles of the widget was to reduce the number of widgets
while presenting the same information as the old project/target trees.
In fact, what you see are not directories, but target groups. In the
case of the automake backend those are directories, but that might be
different for other backend/build system.
> multipule project views to be docked in Anjuta. Having project views
> that are configurable and filterable would allow a developer to create
> views that matched they type of data they are working with. For
> instance a developer who just wanted to clean up their header files for
> the day could filter on .h extentions and configure the view to show
> them all in one big list.
View filtering is something I think it's a great idea, though I don't
think it should be a priority. Maybe we can get that easily when the
GtkTreeModelFilter (currently EggTreeModelFilter in libegg) is moved to
Gtk. Otherwise we will need to implement it ourselves, and it's
probably a difficult task.
I'm thinking we will need (for the project modification interfaces) some
kind of target/group selectors. Those can be thought of as filtered
views of the project model, so this is another reason we might end up
implementing filtering anyway. Patches are always welcome ;-)
Cheers,
Gustavo
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]