RE: Source navigator roadmap, features list, etc.?

RE: Source navigator roadmap, features list, etc.?

[William Gacquer]

or some kind of "extended real file view":

dir          | file           | SN  | VC  |   
------------------------------------------|
a            | toto.c         | yes	| yes |	
a/b          | foo.h          | no  | yes |
z/zz         | albert.txt     | no  | no  |

The SN and VC (version control) columns could be filled with checkboxes.

Of course, this one could be more complete than the one above.
Maybe we could discuss the features that should be included in that kind of
view, if you accept it, of course.

William

-----Original Message-----
From: dave.banham@tde.alstom.com [ mailto:dave.banham@tde.alstom.com ]
Sent: jeudi 5 octobre 2000 09:10
To: sourcenav@sources.redhat.com
Subject: RE: Source navigator roadmap, features list, etc.?





<snip>

>I think that we should have a checkbox on the directory selection dialog
>that says "Live directory". If this is checked, the directory will be
>scanned every time the project is refreshed.

You'd have to implement explicit exclusions too.

Regards
Dave Banham

RE: Source navigator roadmap, features list, etc.?

[dave.banham]

<snip>

>I think that we should have a checkbox on the directory selection dialog
>that says "Live directory". If this is checked, the directory will be
>scanned every time the project is refreshed.

You'd have to implement explicit exclusions too.

Regards
Dave Banham

RE: Source navigator roadmap, features list, etc.?

[leonp]

At 16:02 03/10/2000 -0700, Mo DeJong wrote:
>On Wed, 27 Sep 2000, William Gacquer wrote:
> > 9/ a autoconf/automake project creation as in kdevelop
>
>This one is hard to do in a general way, but we could do
>something like writing a configure.in for the user in the
>same way that we write a Makefile.
As far as I was able to understand the SN was designed for use also 
(mainly?) in Embedded Programming, where you need to have a little bit 
simpler and closer approach to a lot of build process parameters. Absence 
of this simple approach in kdevelop (which is very good IDE!) was the main 
reason that I left my attempts to sufficiently and comfortably integrate 
the embedded projects into it, while one of the main difficulties was this 
autoconf/automake stuff. I shall be very disappointed if this issue will be 
introduced also in SN, which is my only IDE today.

Thanks to Cygnus/RH for the good SW.


Leon Pollak
leonp@plris.com

Re: Source navigator roadmap, features list, etc.?

[Timothy M. Shead]

leonp@plris.com wrote:

> At 16:02 03/10/2000 -0700, Mo DeJong wrote:
> 
>> On Wed, 27 Sep 2000, William Gacquer wrote:
>>  > 9/ a autoconf/automake project creation as in kdevelop
>> 
>> This one is hard to do in a general way, but we could do
>> something like writing a configure.in for the user in the
>> same way that we write a Makefile.
> 
> As far as I was able to understand the SN was designed for use also 
> (mainly?) in Embedded Programming, where you need to have a little bit 
> simpler and closer approach to a lot of build process parameters. 
> Absence of this simple approach in kdevelop (which is very good IDE!) 
> was the main reason that I left my attempts to sufficiently and 
> comfortably integrate the embedded projects into it, while one of the 
> main difficulties was this autoconf/automake stuff. I shall be very 
> disappointed if this issue will be introduced also in SN, which is my 
> only IDE today.

Remember that you can always use external commands to build any way you 
like - I prefer to use my own makefiles, so my "Build Command" is set to 
"make", "Directory" to my top-level project directory, and "Build 
Targets" to "<External Makefile>".  This shouldn't make anyone nervous :)

Timothy M. Shead

Re: Source navigator roadmap, features list, etc.?

[dave.banham]

Syd,
You misunderstand my request. All I would like SN to do is "flag assignments of
function pointers" so that Xref will show the assignment as a reference to the
function symbol being xref'd. Currently it does not, so the only way of finding
such references is with grep.

Regards,
Dave Banham


>On the subject of member functions not being xref'd, I have found that (in C)
>function names used as function pointers (i.e. in call-back
>initialisation) are
>not xref'd. In fact the only way I can find them is to Grep the entire project
>which takes a number of minutes.

This is actually really hard to do.

We could certainly flag assignments of function pointers, but there is no
good static determination of when a function is actually called
dereferencing a function pointer. This requires runtime analysis. And it
could be wrong; the runtime analysis would have to have a reverse table of
addresses to functions. A debugger could do this while the exe is running.

So the only thing we can do is flag assignments of function pointers and
put it in the database.

>Dave Banham
>

Syd Polk       spolk@redhat.com
Engineering Manager +1 415 777 9810 x 241
Red Hat, Inc.

Re: Source navigator roadmap, features list, etc.?

[Syd Polk]

At 08:18 AM 9/29/00 +0100, dave.banham@tde.alstom.com wrote:


>Syd,
>You misunderstand my request. All I would like SN to do is "flag 
>assignments of
>function pointers" so that Xref will show the assignment as a reference to the
>function symbol being xref'd. Currently it does not, so the only way of 
>finding
>such references is with grep.

I agree with you here. Others have asked for what I was talking about.


>Regards,
>Dave Banham
>
>
> >On the subject of member functions not being xref'd, I have found that 
> (in C)
> >function names used as function pointers (i.e. in call-back
> >initialisation) are
> >not xref'd. In fact the only way I can find them is to Grep the entire 
> project
> >which takes a number of minutes.
>
>This is actually really hard to do.
>
>We could certainly flag assignments of function pointers, but there is no
>good static determination of when a function is actually called
>dereferencing a function pointer. This requires runtime analysis. And it
>could be wrong; the runtime analysis would have to have a reverse table of
>addresses to functions. A debugger could do this while the exe is running.
>
>So the only thing we can do is flag assignments of function pointers and
>put it in the database.
>
> >Dave Banham
> >
>
>Syd Polk       spolk@redhat.com
>Engineering Manager +1 415 777 9810 x 241
>Red Hat, Inc.
>

Syd Polk		spolk@redhat.com
Engineering Manager	+1 415 777 9810 x 241
Red Hat, Inc.

Re: Source navigator roadmap, features list, etc.?

[dave.banham]

On the subject of bug reporting, I find that SN's inbuilt crash reporting system
doesn't work very well on my Win NT4 workstation - possibly because it has Lotus
Notes e-mail installed which isn't compatible with anything! If you would like
crash reports to be submitted may I suggest that either a cut & paste option is
provided (so that I can e-mail it to you) or an alternative submission method of
say an HTTP post be provided.

On the subject of member functions not being xref'd, I have found that (in C)
function names used as function pointers (i.e. in call-back initialisation) are
not xref'd. In fact the only way I can find them is to Grep the entire project
which takes a number of minutes.

Dave Banham

Re: Source navigator roadmap, features list, etc.?

[Syd Polk]

At 08:17 AM 9/28/00 +0100, dave.banham@tde.alstom.com wrote:


>On the subject of bug reporting, I find that SN's inbuilt crash reporting 
>system
>doesn't work very well on my Win NT4 workstation - possibly because it has 
>Lotus
>Notes e-mail installed which isn't compatible with anything! If you would like
>crash reports to be submitted may I suggest that either a cut & paste 
>option is
>provided (so that I can e-mail it to you) or an alternative submission 
>method of
>say an HTTP post be provided.
>
>On the subject of member functions not being xref'd, I have found that (in C)
>function names used as function pointers (i.e. in call-back 
>initialisation) are
>not xref'd. In fact the only way I can find them is to Grep the entire project
>which takes a number of minutes.

This is actually really hard to do.

We could certainly flag assignments of function pointers, but there is no 
good static determination of when a function is actually called 
dereferencing a function pointer. This requires runtime analysis. And it 
could be wrong; the runtime analysis would have to have a reverse table of 
addresses to functions. A debugger could do this while the exe is running.

So the only thing we can do is flag assignments of function pointers and 
put it in the database.

>Dave Banham
>

Syd Polk		spolk@redhat.com
Engineering Manager	+1 415 777 9810 x 241
Red Hat, Inc.

Re: Source navigator roadmap, features list, etc.?

[Ben Elliston]

   We could certainly flag assignments of function pointers, but there is
   no good static determination of when a function is actually called
   dereferencing a function pointer. This requires runtime analysis. And
   it could be wrong; the runtime analysis would have to have a reverse
   table of addresses to functions. A debugger could do this while the
   exe is running.

Or worse, the function pointer could be determined by address arithmetic.
As you say, there's only so much that can be done statically.

Ben

Re: Source navigator roadmap, features list, etc.?

[Bruce Stephens]

Ben Elliston <bje@redhat.com> writes:

>    We could certainly flag assignments of function pointers, but there is
>    no good static determination of when a function is actually called
>    dereferencing a function pointer. This requires runtime analysis. And
>    it could be wrong; the runtime analysis would have to have a reverse
>    table of addresses to functions. A debugger could do this while the
>    exe is running.
> 
> Or worse, the function pointer could be determined by address
> arithmetic.  As you say, there's only so much that can be done
> statically.

Of course.  There are inevitably limitations.  

However, whenever a bit of code does something with something which is
a function pointer, then that's worth noting somewhere.

It's possible that it's never called, but it's surely more than likely
that it will be at some point (even though SN won't be able to tell
where it's called).  Not just assignments, either: arguments to
functions ought to be stored somewhere (Tcl_CreateObjCommand and
similar spring to mind).

-- 
Bruce Stephens			Bruce.Stephens@MessagingDirect.com
MessagingDirect(UK) Ltd		<URL: http://www.MessagingDirect.com/ >

RE: Source navigator roadmap, features list, etc.?

[William Gacquer]

Yahoo! The community rules!

More seriously, if I can give you my wishlist...

1/ automatic recognition of new files in the project directories
2/ a better interface with CVS ( why not an integration of tkCVS in SN?)
3/ an expand/collapse button in the project tree view (expansion is the
default but my project is so big that I would prefer a collapse by default)
4/ Drag&Drop with KDE/Gnome (I known, that's Tk's stuff)
5/ a UML-istic class view (even if it's not editable)
6/ clicking on xref-ed objects/functions opens the file where the
object/function is used (by default, it opens the file a function
implementation)
7/ a clever "replace-in-files"
8/ an interface with GNAT (with tkGNAT?)
9/ a autoconf/automake project creation as in kdevelop
10/ a possibility to hide/show all SN-controlled windows
11/ a search-and-replace dialog that can jump directly to the next occurence
by clicking on replace
12/ working real-regular-expressions everywhere
13/ macros
14/ the debugger by default is insight. I want to be able to call DDD
instead (or whatever debugger I like)
15/ themes : editing with SN is like burning my eyes. It is much too hard to
configure a black background with a bright fonts. 
16/ what else?.... uhhh, I am sure I have missed something....


William

-----Original Message-----
From: Syd Polk [ mailto:spolk@redhat.com ]
Sent: mardi 26 septembre 2000 19:41
To: Berek
Cc: sourcenav@sources.redhat.com
Subject: Re: Source navigator roadmap, features list, etc.?


The future is going to be dictated largely by the community. If a lot of
people
in the community want something in, we will make it a priority for
development.

Syd Polk
Engineering Manager

Berek wrote:
> 
> I agree completely. I love SN, but it does have a lot of rough edges in
the
> UI, and it's buggy. I, too, have a lot of suggestions and bug reports and
> would like to know what the future of SN is going to be
> 
> ----- Original Message -----
> From: "Timothee Besset" <timo@qeradiant.com>
> To: <sourcenav@sources.redhat.com>
> Sent: Tuesday, September 26, 2000 01:00
> Subject: Source navigator roadmap, features list, etc.?
> 
> > Is this list the only way to send feature suggestions and bug reports?
> > What are the actual plans of RedHat with source navigator, is it going
> > to evolve a lot more? Because I would have a truckload of improvement
> > suggestions and feature requests. It would be nice if there was a public
> > space somewhere that described who is doing what, maintaining what on
> > this project.
> >
> > I had to move from an MSDev environment to development under linux, and
> > Source Navigator does some things better than MSDev, but it also has
> > some big drawbacks.
> >
> > regards
> >
> > TTimo
> >
> >

Re: Source navigator roadmap, features list, etc.?

[Bruce Stephens]

William Gacquer <wgacquer@ubisoft.fr> writes:

[...]

> 16/ what else?.... uhhh, I am sure I have missed something....

More/better parsers.  Emacs lisp is an obvious one, but more
immediately PHP would be *really* handy.  

Possibly there are significant limitations of many of the existing
parsers, but the one that's really annoying us at the moment is C++:
it seems that often, trying to xref methods gives nothing at all
useful (indeed, often nothing at all).  Presumably this is because the
C++ parser isn't up to the job.

Re: Source navigator roadmap, features list, etc.?

[Berek]

I've experienced the same problem with SN (4.5.1 and 4.5.2). C++ Xref is not
reliable. Often have to fall back on GREP. For me, this is probably the most
serious problem I have with SN.

Also, xref for local variables doesn't seem to work at all. Nor does
locating the declaration of local variables. Yes, I do have "generate
references to local variables" checked in XRef preferences.


----- Original Message -----
From: "Bruce Stephens" <bruce@cenderis.demon.co.uk>
To: <sourcenav@sources.redhat.com>
Sent: Wednesday, September 27, 2000 16:44
Subject: Re: Source navigator roadmap, features list, etc.?


> William Gacquer <wgacquer@ubisoft.fr> writes:
>
> [...]
>
> > 16/ what else?.... uhhh, I am sure I have missed something....
>
> More/better parsers.  Emacs lisp is an obvious one, but more
> immediately PHP would be *really* handy.
>
> Possibly there are significant limitations of many of the existing
> parsers, but the one that's really annoying us at the moment is C++:
> it seems that often, trying to xref methods gives nothing at all
> useful (indeed, often nothing at all).  Presumably this is because the
> C++ parser isn't up to the job.
>

Re: Source navigator roadmap, features list, etc.?

[Syd Polk]

At 12:14 PM 9/28/00 -0400, Berek wrote:
>I've experienced the same problem with SN (4.5.1 and 4.5.2). C++ Xref is not
>reliable. Often have to fall back on GREP. For me, this is probably the most
>serious problem I have with SN.
>
>Also, xref for local variables doesn't seem to work at all. Nor does
>locating the declaration of local variables. Yes, I do have "generate
>references to local variables" checked in XRef preferences.

These are known problems. Hopefully, we can address them soon, or somebody 
in the community can dig into it.


>----- Original Message -----
>From: "Bruce Stephens" <bruce@cenderis.demon.co.uk>
>To: <sourcenav@sources.redhat.com>
>Sent: Wednesday, September 27, 2000 16:44
>Subject: Re: Source navigator roadmap, features list, etc.?
>
>
> > William Gacquer <wgacquer@ubisoft.fr> writes:
> >
> > [...]
> >
> > > 16/ what else?.... uhhh, I am sure I have missed something....
> >
> > More/better parsers.  Emacs lisp is an obvious one, but more
> > immediately PHP would be *really* handy.
> >
> > Possibly there are significant limitations of many of the existing
> > parsers, but the one that's really annoying us at the moment is C++:
> > it seems that often, trying to xref methods gives nothing at all
> > useful (indeed, often nothing at all).  Presumably this is because the
> > C++ parser isn't up to the job.
> >

Syd Polk		spolk@redhat.com
Engineering Manager	+1 415 777 9810 x 241
Red Hat, Inc.

Re: Source navigator roadmap, features list, etc.?

[Syd Polk]

At 09:44 PM 9/27/00 +0100, Bruce Stephens wrote:
>William Gacquer <wgacquer@ubisoft.fr> writes:
>
>[...]
>
> > 16/ what else?.... uhhh, I am sure I have missed something....
>
>More/better parsers.  Emacs lisp is an obvious one, but more
>immediately PHP would be *really* handy.
>
>Possibly there are significant limitations of many of the existing
>parsers, but the one that's really annoying us at the moment is C++:
>it seems that often, trying to xref methods gives nothing at all
>useful (indeed, often nothing at all).  Presumably this is because the
>C++ parser isn't up to the job.

The C++ parser has many bugs; we have not had time to fix them.

We will be putting up a GNATS database soon.

The parser we want the most is a perl parser.


Syd Polk		spolk@redhat.com
Engineering Manager	+1 415 777 9810 x 241
Red Hat, Inc.

RE: Source navigator roadmap, features list, etc.?

[Mo DeJong]

On Wed, 27 Sep 2000, William Gacquer wrote:

> Yahoo! The community rules!
> 
> More seriously, if I can give you my wishlist...
> 
> 1/ automatic recognition of new files in the project directories

Not sure about that one. Perhaps a feature to rescan for new files
would be a good idea, but it should not be automatic.

> 2/ a better interface with CVS ( why not an integration of tkCVS in SN?)

This one is a well known problem that we need to deal with.

> 3/ an expand/collapse button in the project tree view (expansion is the
> default but my project is so big that I would prefer a collapse by default)
> 4/ Drag&Drop with KDE/Gnome (I known, that's Tk's stuff)

What exactly are you itching to drop into SN? Drag and Drop is something
that seems really cool but I find to be less than useful unless it
is very consistent across applications.

> 5/ a UML-istic class view (even if it's not editable)
> 6/ clicking on xref-ed objects/functions opens the file where the
> object/function is used (by default, it opens the file a function
> implementation)

Yup, I looked into this before but I could not fix it without
a redesign.

> 7/ a clever "replace-in-files"
> 8/ an interface with GNAT (with tkGNAT?)
> 9/ a autoconf/automake project creation as in kdevelop

This one is hard to do in a general way, but we could do
something like writing a configure.in for the user in the
same way that we write a Makefile.

> 10/ a possibility to hide/show all SN-controlled windows

This is already implemented, see the Windows->Iconize Project
menu item.

> 11/ a search-and-replace dialog that can jump directly to the next occurence
> by clicking on replace
> 12/ working real-regular-expressions everywhere

The trick will be how the user can tell the system to use
a regexp vs a glob for a given entry box.

Mo DeJong
Red Hat Inc

RE: Source navigator roadmap, features list, etc.?

[Syd Polk]

At 04:02 PM 10/3/00 -0700, Mo DeJong wrote:
>On Wed, 27 Sep 2000, William Gacquer wrote:
>
> > Yahoo! The community rules!
> >
> > More seriously, if I can give you my wishlist...
> >
> > 1/ automatic recognition of new files in the project directories
>
>Not sure about that one. Perhaps a feature to rescan for new files
>would be a good idea, but it should not be automatic.

I think that we should have a checkbox on the directory selection dialog 
that says "Live directory". If this is checked, the directory will be 
scanned every time the project is refreshed.


Syd Polk		spolk@redhat.com
Engineering Manager	+1 415 777 9810 x 241
Red Hat, Inc.

Source navigator roadmap, features list, etc.?

[Timothee Besset]

Is this list the only way to send feature suggestions and bug reports? 
What are the actual plans of RedHat with source navigator, is it going 
to evolve a lot more? Because I would have a truckload of improvement 
suggestions and feature requests. It would be nice if there was a public 
space somewhere that described who is doing what, maintaining what on 
this project.

I had to move from an MSDev environment to development under linux, and 
Source Navigator does some things better than MSDev, but it also has 
some big drawbacks.

regards

TTimo

Re: Source navigator roadmap, features list, etc.?

[Syd Polk]

Timothee Besset wrote:
> 
> Is this list the only way to send feature suggestions and bug reports?
> What are the actual plans of RedHat with source navigator, is it going
> to evolve a lot more? Because I would have a truckload of improvement
> suggestions and feature requests. It would be nice if there was a public
> space somewhere that described who is doing what, maintaining what on
> this project.
> 

Right now, we are busy overhauling the GUI code to use incr Tcl 3.0. After we
get done with that, we will start working on new features. So nobody is
officially doing any new features until we get 5.0 released.

> I had to move from an MSDev environment to development under linux, and
> Source Navigator does some things better than MSDev, but it also has
> some big drawbacks.
> 

Feel free to post suggestions and requests. Better yet, feel free to work on the
code!

> regards
> 
> TTimo

Re: Source navigator roadmap, features list, etc.?

[Berek]

I agree completely. I love SN, but it does have a lot of rough edges in the
UI, and it's buggy. I, too, have a lot of suggestions and bug reports and
would like to know what the future of SN is going to be

----- Original Message -----
From: "Timothee Besset" <timo@qeradiant.com>
To: <sourcenav@sources.redhat.com>
Sent: Tuesday, September 26, 2000 01:00
Subject: Source navigator roadmap, features list, etc.?


> Is this list the only way to send feature suggestions and bug reports?
> What are the actual plans of RedHat with source navigator, is it going
> to evolve a lot more? Because I would have a truckload of improvement
> suggestions and feature requests. It would be nice if there was a public
> space somewhere that described who is doing what, maintaining what on
> this project.
>
> I had to move from an MSDev environment to development under linux, and
> Source Navigator does some things better than MSDev, but it also has
> some big drawbacks.
>
> regards
>
> TTimo
>
>

Re: Source navigator roadmap, features list, etc.?

[Syd Polk]

The future is going to be dictated largely by the community. If a lot of people
in the community want something in, we will make it a priority for development.

Syd Polk
Engineering Manager

Berek wrote:
> 
> I agree completely. I love SN, but it does have a lot of rough edges in the
> UI, and it's buggy. I, too, have a lot of suggestions and bug reports and
> would like to know what the future of SN is going to be
> 
> ----- Original Message -----
> From: "Timothee Besset" <timo@qeradiant.com>
> To: <sourcenav@sources.redhat.com>
> Sent: Tuesday, September 26, 2000 01:00
> Subject: Source navigator roadmap, features list, etc.?
> 
> > Is this list the only way to send feature suggestions and bug reports?
> > What are the actual plans of RedHat with source navigator, is it going
> > to evolve a lot more? Because I would have a truckload of improvement
> > suggestions and feature requests. It would be nice if there was a public
> > space somewhere that described who is doing what, maintaining what on
> > this project.
> >
> > I had to move from an MSDev environment to development under linux, and
> > Source Navigator does some things better than MSDev, but it also has
> > some big drawbacks.
> >
> > regards
> >
> > TTimo
> >
> >

Re: Source navigator roadmap, features list, etc.?

[Ben Elliston]

   I agree completely. I love SN, but it does have a lot of rough edges
   in the UI, and it's buggy. I, too, have a lot of suggestions and bug
   reports and would like to know what the future of SN is going to be

IMHO, it should be a relatively high priority to establish a GNATS bug
reporting database for S-N (as other projects on sources.redhat.com do).  
This will encourage folks to submit bug reports and for us to track them.

Ben

Re: Source navigator roadmap, features list, etc.?

[Mo DeJong]

On Thu, 28 Sep 2000, Ben Elliston wrote:

>    I agree completely. I love SN, but it does have a lot of rough edges
>    in the UI, and it's buggy. I, too, have a lot of suggestions and bug
>    reports and would like to know what the future of SN is going to be
> 
> IMHO, it should be a relatively high priority to establish a GNATS bug
> reporting database for S-N (as other projects on sources.redhat.com do).  
> This will encourage folks to submit bug reports and for us to track them.
> 
> Ben

We already have one, but we do not want to "roll it out" until
5.0 is ready.
 
Mo DeJong
Red Hat Inc