SN452 Installation

SN452 Installation

[Rouviere, Stephane]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 968 bytes --]

Hello,

First, Thanks to SN team for their great work !!

I am trying to use SN452.
But, when I try to compile it, I have the following error:

../../../SN452-source/snavigator/hyper/dbsym.c: In function `setflags':
../../../SN452-source/snavigator/hyper/dbsym.c:365: warning: subscript has
type `char'
../../../SN452-source/snavigator/hyper/dbsym.c: In function
`glob_nocase_pattern':
../../../SN452-source/snavigator/hyper/dbsym.c:489: warning: subscript has
type `char'
../../../SN452-source/snavigator/hyper/dbsym.c:496: warning: subscript has
type `char'
../../../SN452-source/snavigator/hyper/dbsym.c: In function `setinfo':
../../../SN452-source/snavigator/hyper/dbsym.c:2382: warning: subscript has
type `char'
../../../SN452-source/snavigator/hyper/dbsym.c: In function `GetOpenMode':
../../../SN452-source/snavigator/hyper/dbsym.c:2523: warning: subscript has
type `char'
gmake: *** [dbsym.o] Error 1

Could someone help me ?
Thanks in advance 

Stéphane

Re: SN452 Installation

[Bruce Stephens]

"Rouviere, Stephane" <stephane.rouviere@intel.com> writes:

[...]

> I am trying to use SN452.
> But, when I try to compile it, I have the following error:
> 
> ../../../SN452-source/snavigator/hyper/dbsym.c: In function `setflags':
> ../../../SN452-source/snavigator/hyper/dbsym.c:365: warning: subscript has
> type `char'
> ../../../SN452-source/snavigator/hyper/dbsym.c: In function
> `glob_nocase_pattern':
> ../../../SN452-source/snavigator/hyper/dbsym.c:489: warning: subscript has
> type `char'
> ../../../SN452-source/snavigator/hyper/dbsym.c:496: warning: subscript has
> type `char'
> ../../../SN452-source/snavigator/hyper/dbsym.c: In function `setinfo':
> ../../../SN452-source/snavigator/hyper/dbsym.c:2382: warning: subscript has
> type `char'
> ../../../SN452-source/snavigator/hyper/dbsym.c: In function `GetOpenMode':
> ../../../SN452-source/snavigator/hyper/dbsym.c:2523: warning: subscript has
> type `char'
> gmake: *** [dbsym.o] Error 1

Those are all warnings.  Is there an actual error somewhere?  What's
the compiler, and compile line?

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

Re: SN452 Installation

[Syd Polk]

At 01:21 PM 9/15/00 +0100, Bruce Stephens wrote:
>"Rouviere, Stephane" <stephane.rouviere@intel.com> writes:
>
>[...]
>
> > I am trying to use SN452.
> > But, when I try to compile it, I have the following error:
> >
> > ../../../SN452-source/snavigator/hyper/dbsym.c: In function `setflags':
> > ../../../SN452-source/snavigator/hyper/dbsym.c:365: warning: subscript has
> > type `char'
> > ../../../SN452-source/snavigator/hyper/dbsym.c: In function
> > `glob_nocase_pattern':
> > ../../../SN452-source/snavigator/hyper/dbsym.c:489: warning: subscript has
> > type `char'
> > ../../../SN452-source/snavigator/hyper/dbsym.c:496: warning: subscript has
> > type `char'
> > ../../../SN452-source/snavigator/hyper/dbsym.c: In function `setinfo':
> > ../../../SN452-source/snavigator/hyper/dbsym.c:2382: warning: subscript has
> > type `char'
> > ../../../SN452-source/snavigator/hyper/dbsym.c: In function `GetOpenMode':
> > ../../../SN452-source/snavigator/hyper/dbsym.c:2523: warning: subscript has
> > type `char'
> > gmake: *** [dbsym.o] Error 1
>
>Those are all warnings.  Is there an actual error somewhere?  What's
>the compiler, and compile line?

Better yet, what is the operating system?

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

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

Getting started with tcl

[Thomas Heller]

I'm trying to understand how SN starts 'make'.
Since I'm an absolute beginner to tcl, can
someone please explain the following line
(from share/gui/multimake.tcl, method ExecMake):

  set ret [catch {@@set make_fd [@@open "| $make_cmd" r]} msg]

I can decipher most of it, but what do all the @'s mean?
Is this standard tcl? I did not find something like
this in the Ousterhout book...

Thomas Heller

Re: Getting started with tcl

[Bruce Stephens]

Thomas Heller <thomas.heller@ion-tof.com> writes:

> I'm trying to understand how SN starts 'make'.
> Since I'm an absolute beginner to tcl, can
> someone please explain the following line
> (from share/gui/multimake.tcl, method ExecMake):
> 
>   set ret [catch {@@set make_fd [@@open "| $make_cmd" r]} msg]
> 
> I can decipher most of it, but what do all the @'s mean?
> Is this standard tcl? I did not find something like
> this in the Ousterhout book...

Normally it would mean nothing: @@set would simply refer to a command
called "@@set".  However, the ChangeLog in itcl suggests that things
have been changed so that @@ means the same as ::.  

So try thinking of it in those terms.  Ousterhout's book is
unfortunately too old to cover namespaces; however, the namespace(n)
manpage describes it.  Anyway, namespaces work sufficiently obviously
that they shouldn't be surprising.

I don't know why they'd have changed things in this way.

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

Re: Getting started with tcl

[Syd Polk]

At 05:40 PM 8/3/00 +0100, Bruce Stephens wrote:
>Thomas Heller <thomas.heller@ion-tof.com> writes:
>
> > I'm trying to understand how SN starts 'make'.
> > Since I'm an absolute beginner to tcl, can
> > someone please explain the following line
> > (from share/gui/multimake.tcl, method ExecMake):
> >
> >   set ret [catch {@@set make_fd [@@open "| $make_cmd" r]} msg]
> >
> > I can decipher most of it, but what do all the @'s mean?
> > Is this standard tcl? I did not find something like
> > this in the Ousterhout book...
>
>Normally it would mean nothing: @@set would simply refer to a command
>called "@@set".  However, the ChangeLog in itcl suggests that things
>have been changed so that @@ means the same as ::.

@@ in incr Tcl 1.5 commands does mean the same as ::.

>So try thinking of it in those terms.  Ousterhout's book is
>unfortunately too old to cover namespaces; however, the namespace(n)
>manpage describes it.  Anyway, namespaces work sufficiently obviously
>that they shouldn't be surprising.
>
>I don't know why they'd have changed things in this way.

This is an evil Cygnus-local hack to get namespaces to work in incr Tcl 
1.5. This will go away once we put a snapshot of SN 5.0 on the web. 
Hopefully, in September.
Syd Polk		spolk@redhat.com
Engineering Manager	+1 415 777 9810 x 241
Red Hat, Inc.

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.

SN Printing Under WIN/NT

[Berek]

Lot's of problems printing hierarchy and cross reference charts under NT. I
have SN installed on 1/2 dozen PC's. Some use Postscript drivers, others
PCL, some use both. All have same results printing on 1/2 dozen networked
printers. Basically, printing is garbled: letters, symbols, and lines
overlaying each other. Have to resort to doing NT alt-print screen and
pasting into MS Word, then printing from Word.

In Class view, C++ class members that are "private" have symbol (transparent
diamond) for "public". Private members should have no symbol at all. Both
public and private have the public symbol.

I'm concerned about comments made by SN Development (Syd Polk?) about
priority given to Perl parser. I know of more than 1/2 dozen companies in my
area that have been forced to scale back use of SN because of many problems
with C++ parser: 3Com, Lucent, Cienna, Concord Communications, Broadband
Access Systems, Cisco, Fidelity... Unless C++ parsing bugs are fixed, SN
cannot be relied upon as a development tool. We desparately need accurate
cross references. Those of us that us SN are forced to fall back on grep's.
Please review your priorities.

Tx
Steve Dow

----- Original Message -----
From: "Syd Polk" <spolk@redhat.com>
To: <sourcenav@sources.redhat.com>
Sent: Wednesday, October 04, 2000 13:27
Subject: RE: Source navigator roadmap, features list, etc.?


> 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.
>
>
>
>

Re: SN Printing Under WIN/NT

[Mo DeJong]

> I'm concerned about comments made by SN Development (Syd Polk?) about
> priority given to Perl parser.

Syd was talking about a possible contribution from someone in
the net community. We are not going to write a perl parser unless
someone contracts with us to write it.

> I know of more than 1/2 dozen companies in my
> area that have been forced to scale back use of SN because of many problems
> with C++ parser: 3Com, Lucent, Cienna, Concord Communications, Broadband
> Access Systems, Cisco, Fidelity... Unless C++ parsing bugs are fixed, SN
> cannot be relied upon as a development tool.

Humm, if all of these companies are having problems why have they
not contacted us about a support/development contract to improve
the C++ parser support?

> We desparately need accurate
> cross references. Those of us that us SN are forced to fall back on grep's.
> Please review your priorities.

Our current priority is Source-Navigator 5.0. If your company needs
some particular feature, you have the following options:

1. Implement it yourself
2. Contract with us to implement it
3. Hire someone else to do it

cheers
Mo DeJong
Red Hat Inc

Re: SN Printing Under WIN/NT

[Paul Selormey]

Hello Mo DeJong,

> > [...]
> Humm, if all of these companies are having problems why have they
> not contacted us about a support/development contract to improve
> the C++ parser support?

Please how much will it cost to contract you. I think many here will help to
contribute that amount which will give us a good parser for C/C++ in parser
and Java where possible.

> Our current priority is Source-Navigator 5.0. If your company needs
> some particular feature, you have the following options:

We have heard much about this, but it is not building on the current
existing codes?
What is new here? since no one seems to know what is going on except the
RedHat
staff.

> 1. Implement it yourself
> 2. Contract with us to implement it
> 3. Hire someone else to do it

Now, tell me SN used to be a commercial product. Was the principle the same
too?
If you buy it and it does not work the way you expect, then implement it
yourself, pay
us more to implement it and asked somebody to do it for you :-)

It sounds interesting though.
Best regards,
Paul.

Re: SN Printing Under WIN/NT

[Mo DeJong]

On Thu, 5 Oct 2000, Paul Selormey wrote:

> Hello Mo DeJong,
> 
> > > [...]
> > Humm, if all of these companies are having problems why have they
> > not contacted us about a support/development contract to improve
> > the C++ parser support?
> 
> Please how much will it cost to contract you. I think many here will help to
> contribute that amount which will give us a good parser for C/C++ in parser
> and Java where possible.

The cost naturally depends on what you want fixed and how long
it takes to fix the problem. When you give away free software,
you need to charge for support and services to make ends meet.

> > Our current priority is Source-Navigator 5.0. If your company needs
> > some particular feature, you have the following options:
> 
> We have heard much about this, but it is not building on the current
> existing codes?

Source-Navigator 5.0 includes a large Itcl upgrade (1.5 -> 3.0)
but it is not a "start from scratch" rewrite like mozilla or
anything.

> What is new here? since no one seems to know what is going on except the
> RedHat
> staff.

We have purposely tried to add no new features for 5.0. We are
upgrading the core technologies we depend on (Tcl/Tk/Itcl),
but we are not adding a bunch of new user visible features.
I am not sure what you mean by "no one seems to know what is going on",
we have explained this on the list a number of times.

> > 1. Implement it yourself
> > 2. Contract with us to implement it
> > 3. Hire someone else to do it
> 
> Now, tell me SN used to be a commercial product. Was the principle the same
> too?
> If you buy it and it does not work the way you expect, then implement it
> yourself, pay
> us more to implement it and asked somebody to do it for you :-)

With a closed source product, you do not have the option to
fix it yourself or hire someone else to do it. You are at the
mercy of the vendor. This is one of the critical diffs of
an open vs closed code.

We are not saying that you have to fix the code yourself, but
you do have the freedom to do so. Would you buy a car that
could only be serviced at the dealer? That said, we think
people will recognize the logic of contracting with us to fix
problems or add new features, since we already know the code base.

cheers
Mo DeJong
Red Hat Inc

Re: SN Printing Under WIN/NT

[Syd Polk]

At 04:26 PM 10/4/00 -0400, Berek wrote:
>Lot's of problems printing hierarchy and cross reference charts under NT. I
>have SN installed on 1/2 dozen PC's. Some use Postscript drivers, others
>PCL, some use both. All have same results printing on 1/2 dozen networked
>printers. Basically, printing is garbled: letters, symbols, and lines
>overlaying each other. Have to resort to doing NT alt-print screen and
>pasting into MS Word, then printing from Word.

The real problem is that there are no font preferences that just apply to 
printing, and the fonts for screen and printing don't match very well. We 
need to do some work at some point cleaning this up, as well as an overall 
preferences rewrite.


>In Class view, C++ class members that are "private" have symbol (transparent
>diamond) for "public". Private members should have no symbol at all. Both
>public and private have the public symbol.
>
>I'm concerned about comments made by SN Development (Syd Polk?) about
>priority given to Perl parser. I know of more than 1/2 dozen companies in my
>area that have been forced to scale back use of SN because of many problems
>with C++ parser: 3Com, Lucent, Cienna, Concord Communications, Broadband
>Access Systems, Cisco, Fidelity... Unless C++ parsing bugs are fixed, SN
>cannot be relied upon as a development tool. We desparately need accurate
>cross references. Those of us that us SN are forced to fall back on grep's.
>Please review your priorities.

C++ parser is a high priority; we use it internally.

Thanks for your feedback; it really is appreciated.

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

Re: SN Printing Under WIN/NT

[Berek]

Thank you [smile]. I really love SN. If you guys manage to clean up the C++
parser so that it's as reliable as a compiler (the closer to 100%, the
better off we'll be...we absolutely have to have accurate xrefs), this
product will be a developer's "dream come true".

----- Original Message -----
From: "Syd Polk" <spolk@redhat.com>
To: "Berek" <berek@usa.net>; <sourcenav@sources.redhat.com>
Sent: Thursday, October 05, 2000 15:08
Subject: Re: SN Printing Under WIN/NT


> At 04:26 PM 10/4/00 -0400, Berek wrote:
> >Lot's of problems printing hierarchy and cross reference charts under NT.
I
> >have SN installed on 1/2 dozen PC's. Some use Postscript drivers, others
> >PCL, some use both. All have same results printing on 1/2 dozen networked
> >printers. Basically, printing is garbled: letters, symbols, and lines
> >overlaying each other. Have to resort to doing NT alt-print screen and
> >pasting into MS Word, then printing from Word.
>
> The real problem is that there are no font preferences that just apply to
> printing, and the fonts for screen and printing don't match very well. We
> need to do some work at some point cleaning this up, as well as an overall
> preferences rewrite.
>
>
> >In Class view, C++ class members that are "private" have symbol
(transparent
> >diamond) for "public". Private members should have no symbol at all. Both
> >public and private have the public symbol.
> >
> >I'm concerned about comments made by SN Development (Syd Polk?) about
> >priority given to Perl parser. I know of more than 1/2 dozen companies in
my
> >area that have been forced to scale back use of SN because of many
problems
> >with C++ parser: 3Com, Lucent, Cienna, Concord Communications, Broadband
> >Access Systems, Cisco, Fidelity... Unless C++ parsing bugs are fixed, SN
> >cannot be relied upon as a development tool. We desparately need accurate
> >cross references. Those of us that us SN are forced to fall back on
grep's.
> >Please review your priorities.
>
> C++ parser is a high priority; we use it internally.
>
> Thanks for your feedback; it really is appreciated.
>
> Syd Polk spolk@redhat.com
> Engineering Manager +1 415 777 9810 x 241
> Red Hat, Inc.
>
>
>
>
>

future plans

[Simone Contini]

Hi,

	Source Navigator is very Cool!! thank you for it! I'd like to know
how i can read about future plans and if the projects will take advantages
of GTK/GNOME.

thank you

Simone Contini
Games & Tools Programmer
Florence - Italy

Email: s.contini@fol.it
WWW: http://3dfx4ever.oltrelinux.com/
     http://scontini.xoasis.com/

ICQ # : 25879128

Re: future plans

[Syd Polk]

At 12:55 PM 11/20/00 +0100, Simone Contini wrote:
>Hi,
>
>         Source Navigator is very Cool!! thank you for it! I'd like to know
>how i can read about future plans and if the projects will take advantages
>of GTK/GNOME.

We are in the process of evaluating our future strategy.

However, it is highly unlikely we will ever do Source-Navigator in GTK or 
GNOME. We might add the capability of communicating with the GTK/GNOME 
desktop services, but these would be Tcl/Tk modifications.


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

Re: future plans

[Mo DeJong]

On Mon, 20 Nov 2000, Simone Contini wrote:

> Hi,
> 
> 	Source Navigator is very Cool!! thank you for it! I'd like to know
> how i can read about future plans and if the projects will take advantages
> of GTK/GNOME.

What features from Gtk or Gnome do you see as a "must have".
The ability to do themes might be neat, but I don't see it
as a critical component of a good IDE. Gnome has some
configuration management stuff that might be handy if we
needed it, but I don't think we do. If you have specific
things you were thinking of, I would like to hear them.
Keep in mind, that we can't depend on a Gnome feature
because SN need to run under Windows too.

Mo DeJong
Red Hat Inc

Re: future plans

[Timothee Besset]

When can we expect an update to SN?

The most important feature (imo) would be auto-completion.
Auto-completion of symbols, listing the members when accessing a struct 
with -> or .
Displaying the definition of the functions in a tooltip box when the 
mouse comes over them
Displaying possible commentaries that are typed before struct 
definitions or function definitons
Maybe even a window that would sit somewhere on your workspade and 
update to the class definition or inheritance of the class you are 
working in (well yeah, stuff you can get already, but it's not 
implemented in a very efficient way)

I'm also lacking some docs or tips, maybe some of the stuff I want is 
there already.
The behaviour of the windows is weird. If the file as been edited it 
would open a new window, but if not it would change the edit view. I 
didn't find the shortcuts to switch between editor views (like Alt+TAB 
on MSVC).
I'm free to develop on win32 or linux. I prefer linux because on win98 
my app kills the GDI resources and I have to reboot quite often. But I'm 
strongly tempted to go back to win32 cause I don't feel as efficient 
with sourcenav as I can be with MSDev

Hope this helps..

TTimo

Mo DeJong wrote:

> On Mon, 20 Nov 2000, Simone Contini wrote:
> 
>> Hi,
>> 
>> 	Source Navigator is very Cool!! thank you for it! I'd like to know
>> how i can read about future plans and if the projects will take advantages
>> of GTK/GNOME.
> 
> 
> What features from Gtk or Gnome do you see as a "must have".
> The ability to do themes might be neat, but I don't see it
> as a critical component of a good IDE. Gnome has some
> configuration management stuff that might be handy if we
> needed it, but I don't think we do. If you have specific
> things you were thinking of, I would like to hear them.
> Keep in mind, that we can't depend on a Gnome feature
> because SN need to run under Windows too.
> 
> Mo DeJong
> Red Hat Inc
> 
> 
> 

Re: future plans

[Mo DeJong]

On Mon, 20 Nov 2000, Timothee Besset wrote:

> When can we expect an update to SN?

What kind of "update" were you looking for? We are working on
getting a snapshot of 5.0 out sometime soon, but that will
not even be alpha quality. It would be a "hackers only"
pre-release.

> The most important feature (imo) would be auto-completion.
> Auto-completion of symbols, listing the members when accessing a struct 
> with -> or .

That would be neat. Are you willing to work on implementing
this feature?

> Displaying the definition of the functions in a tooltip box when the 
> mouse comes over them

This should be trivial, perhaps a day or two to implement
and test.

> Displaying possible commentaries that are typed before struct 
> definitions or function definitons

Not sure what you mean by this.

> Maybe even a window that would sit somewhere on your workspade and 
> update to the class definition or inheritance of the class you are 
> working in (well yeah, stuff you can get already, but it's not 
> implemented in a very efficient way)

Is it so hard to switch to the Hier window or the class viewer?

> I'm also lacking some docs or tips, maybe some of the stuff I want is 
> there already.
> The behaviour of the windows is weird. If the file as been edited it 
> would open a new window, but if not it would change the edit view. I 
> didn't find the shortcuts to switch between editor views (like Alt+TAB 
> on MSVC).
> I'm free to develop on win32 or linux. I prefer linux because on win98 
> my app kills the GDI resources and I have to reboot quite often. But I'm 
> strongly tempted to go back to win32 cause I don't feel as efficient 
> with sourcenav as I can be with MSDev

Well, feelings are a tricky thing. They might be good or they
might have nothing to do with reality. When it comes to a GUI,
folks start to get "bad feelings" over little things like
a window taking too long to redraw. Don't forget that you
do have the source, you can adapt it to better suite your
"feelings". When was the last time you were able to reprogram
MSDev to get around something you did not like?

Mo DeJong
Red Hat Inc

Re: future plans

[Tom Tromey]

>>>>> "Mo" == Mo DeJong <mdejong@cygnus.com> writes:

Mo> What features from Gtk or Gnome do you see as a "must have".
Mo> The ability to do themes might be neat, but I don't see it
Mo> as a critical component of a good IDE. Gnome has some
Mo> configuration management stuff that might be handy if we
Mo> needed it, but I don't think we do.

Themes are nice, but they are just candy.  Most people would rather
have a tool that works well than one that conforms to their
environment.  (Well, most people would prefer both, I'd imagine...)

The config code is nice, and will get much nicer (with GConf), but
unless you want network transparency and the use of weird back ends it
isn't very important.

There are two more important things that Gnome has that S-N currently
can't do:

* Drag and drop
* Session management

Both of these can be written as Tcl extensions though.

The D&D protocol is (I believe) well-documented and in use by a few
groups (both Gnome and KDE at least).  (I know you've argued against
D&D before, but I've never understood your argument.)

Gnome's session management is just XSMP.  There is an (ugly) X library
to help you do this; Gnome just wraps it with a nicer API.  (At some
point session management and configuration storage might tie together
somehow.  That would be harder to emulate.)

Gnome also has some other things, like the ability to play sounds in
response to certain events (activate a button widget, get a beep).
This is along the lines of themability though -- not deeply important.


The really important Gnome stuff comes later: componentization of
everything.  Maybe it will be possible to use this from Tcl, too, with
some work.  I don't know.

Maybe components aren't important for an IDE.  I think they could be
used though.  For instance the debugger gui could be plugged in to S-N
somehow.

Tom

Re: future plans

[Syd Polk]

>There are two more important things that Gnome has that S-N currently
>can't do:
>
>* Drag and drop
>* Session management
>
>Both of these can be written as Tcl extensions though.
>
>The D&D protocol is (I believe) well-documented and in use by a few
>groups (both Gnome and KDE at least).  (I know you've argued against
>D&D before, but I've never understood your argument.)

I don't remember arguing against the idea of drag-and-drop. It is a great 
feature which I would love to have.


>Gnome's session management is just XSMP.  There is an (ugly) X library
>to help you do this; Gnome just wraps it with a nicer API.  (At some
>point session management and configuration storage might tie together
>somehow.  That would be harder to emulate.)

I don't know what "session management" means.

>Gnome also has some other things, like the ability to play sounds in
>response to certain events (activate a button widget, get a beep).
>This is along the lines of themability though -- not deeply important.
>
>
>The really important Gnome stuff comes later: componentization of
>everything.  Maybe it will be possible to use this from Tcl, too, with
>some work.  I don't know.
>
>Maybe components aren't important for an IDE.  I think they could be
>used though.  For instance the debugger gui could be plugged in to S-N
>somehow.

The problem is, of course, that this is a major rewrite of something. 
Either Tk has to be fitted with it, or we have to rewrite the entire GUI in 
GNOME. I would rather not spend several man-years doing the latter.


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

Re: future plans

[Mo DeJong]

On Tue, 21 Nov 2000, Syd Polk wrote:

> 
> >There are two more important things that Gnome has that S-N currently
> >can't do:
> >
> >* Drag and drop
> >* Session management
> >
> >Both of these can be written as Tcl extensions though.
> >
> >The D&D protocol is (I believe) well-documented and in use by a few
> >groups (both Gnome and KDE at least).  (I know you've argued against
> >D&D before, but I've never understood your argument.)
> 
> I don't remember arguing against the idea of drag-and-drop. It is a great 
> feature which I would love to have.

Syd, I think he was talking about me. It is true, I have seen
some drag and drop interfaces that are just stupid and a
waste of time. On the other hand, I have seen some good
uses of drag and drop too. For example, on the Mac you
can drag a URL out of the web browser and put it on the
desktop. It turns into a click-able thingy that will open
up the web browser at the given URL later. Sure, it is
just a bookmark but it was a reasonable interface.

I have also seen some stupid uses of drap and drop,
where it just gets in the way instead of helping. One
thing that might be handy in SN is to drag a set of new
files into the symbol browser, that could add the given
files to the project. Of course, we already provide a
way to add a directory or set of files to the project
so I don't think anyone is going to be beating down
the door for that feature.

> >Gnome's session management is just XSMP.  There is an (ugly) X library
> >to help you do this; Gnome just wraps it with a nicer API.  (At some
> >point session management and configuration storage might tie together
> >somehow.  That would be harder to emulate.)
> 
> I don't know what "session management" means.

Well, for starters SN could open up with the windows in the
same place and open on the same tools as when it shut down.
Some folks really like this sort of interface, others
could not care less.

Mo DeJong
Red Hat Inc

Re: future plans

[Tom Tromey]

>> Gnome's session management is just XSMP.  There is an (ugly) X library
>> to help you do this; Gnome just wraps it with a nicer API.  (At some
>> point session management and configuration storage might tie together
>> somehow.  That would be harder to emulate.)

Syd> I don't know what "session management" means.

When you log out, Gnome can save the state of all applications (all
those which support session management) and then later restart the
session where you left off.

The idea is applications will remember what documents were open,
cursor positions, etc.

Tom

Re: future plans

[Bruce Stephens]

Tom Tromey <tromey@cygnus.com> writes:

> >> Gnome's session management is just XSMP.  There is an (ugly) X library
> >> to help you do this; Gnome just wraps it with a nicer API.  (At some
> >> point session management and configuration storage might tie together
> >> somehow.  That would be harder to emulate.)
> 
> Syd> I don't know what "session management" means.
> 
> When you log out, Gnome can save the state of all applications (all
> those which support session management) and then later restart the
> session where you left off.
> 
> The idea is applications will remember what documents were open,
> cursor positions, etc.

I don't think this requires anything that Tk doesn't already have,
does it?  Can't an application just use "wm protocol <win>
WM_SAVE_YOURSELF" and do something to save its state?  Hmm, I guess
there's a bit more to it than that: to restore, it would need to be
able to identify an instance of information, but overall it shouldn't
be *that* much more.

Re: future plans

[Tom Tromey]

>>>>> "Bruce" == Bruce Stephens <bruce@cenderis.demon.co.uk> writes:

Bruce> I don't think this requires anything that Tk doesn't already
Bruce> have, does it?  Can't an application just use "wm protocol
Bruce> <win> WM_SAVE_YOURSELF" and do something to save its state?

Gnome can already interface with applications that use this method,
via a proxy.

However, XSMP has more sophisticated facilities than those available
via the old ICCCM session management protocol.

Tom

Re: future plans

[Syd Polk]

At 01:40 PM 11/21/00 -0700, Tom Tromey wrote:
> >> Gnome's session management is just XSMP.  There is an (ugly) X library
> >> to help you do this; Gnome just wraps it with a nicer API.  (At some
> >> point session management and configuration storage might tie together
> >> somehow.  That would be harder to emulate.)
>
>Syd> I don't know what "session management" means.
>
>When you log out, Gnome can save the state of all applications (all
>those which support session management) and then later restart the
>session where you left off.
>
>The idea is applications will remember what documents were open,
>cursor positions, etc.
>
>Tom

Source-Navigator does this, to a limited extent. It's buggy as all get out.


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

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/ >

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