Re: [Cgdb-devel] CGDB 1.0 Proposal

[Bob R. <bo...@br...>]

Hi,

On Wed, Aug 13, 2003 at 09:41:06PM -0400, Mike Mueller wrote:
> Hi Everyone,
>=20
> Just wanted to get this discussion going.  In the next week or two,=20
> we should really identify what exactly CGDB version 1.0 will do. =20
> The idea is that this should be doable in a matter of a couple=20
> months, that it'll be fully documented, and basically feature=20
> complete.  Advanced features can be left for a possible second=20
> revision, but we want to keep things simple right now.
>=20
> I've got a list of features here, and I'm hoping Bob will add=20
> anything that I've missed.  If any of you have feedback and/or=20
> additional suggestions, please send them.  I'll maintain an updated=20
> copy of this proposal, and it'll go on our web site when it's done.
>=20

What you have here is great! A few suggestions, to add to the proposal.
They are actually not exactly 1.0 features. They are more on what is and
is not acceptable to add to cgdb.

   1. testing should be a key component in CGDB/TGDB.
      TGDB is poorly tested. It does have a testsuite, but it basically
      is a sanity checking device. For *every* new feature we add to
      either tool, we need to add a testsuite entry. I don't know how
      we are going to do this, but it will help with regressions.

   2. Documentation is also very important. CGDB/TGDB need to=20
      support 2 different types of documentation.=20
         a) Internal, describing algorithms, design decisions, interfaces .=
..
            For the internal we could use doxygen ( of course ). If
            anyone recommends anything else, please bring it up.
         b) External, user manuals, HOWTO's, FAQ's, ...
            For external, we should probably use the GNU documentation
            standard.=20
            http://gnu.ghks.de/software/texinfo/texinfo.html
            I would defiantly be up to picking a different standard if
            anyone can suggest it.

   3. License and copy write issues.
      CGDB/TGDB should clearly have stated with it, its license.
      I personally think CGDB and TGDB should be under the GPL and all=20
      the files that make them up marked accordingly.

      I think we should somehow retain the copy write to all patches
      received. Any opinions?

   4. Coding standards.=20
      For this we can go two different routes. Pick a coding standard or
      don't. I prefer to have one. I don't really care which one it is,
      I would like to hear someone else's opinion on this topic.

      I only know of 2 coding standards. The Linux kernel, and GNU's.

   5. Patch approval mailing list.
      I think all patches should be mailed in, and one of us can apply
      the patch. This way, we can make sure that the ChangeLog is done
      correct, the coding standard is correct, and none of us are
      getting lazy.


I understand that many of these ideas seem like overhead, but in the
end, there will be a good product thats well rounded, instead of just
another free software project.

So, if you think that some of these are too much for a small project,
and that its overboard, let me know.



Ok, on to the proposal, I like what you have here, I think under each
of your categories, we should give good examples of what we want to work
and what we don't expect to work.
> Proposal:
>=20
> The CGDB GUI should have the following features:
>=20
>    - Configurable:
>      o Config file containing :ex commands
         - Put any command here that you can type in the status bar.
         - Commands that don't make sense because cgdb is not
           initialized will be ignored.
>      o Key bindings for any :ex commands
         - This will be a separate library. It should be able to read a
         config file in ~/.cgdb ( for example .cgdbkb ) that the user
         could edit. The user would be able to put a key sequence and a
         function name that that key sequence would call. For example,
         the default behavior of 'j' in CGDB is to move down a line. So
         cgdb will export a function called move_down_line. The user
         could change the default by doing

         map j move_up_line=20

         also, the library would be smart enough to turn 5j into move
         line down 5 times. It would also be able to understand things
         like <F5> <CR>. Obviously I am doing something much like vim.
         The library could do it however it wants.

         Phew...
>      o Color schemes
         - Color schemes are sensitive. They are directly related to the
           lexical analyzer of each language. We need to come up with a
           set of different kind of tokens that the color schemes will
           work with.
         - Color schemes seem like a shortcut to
            :set STRING_LITERAL=3DBLUE
            :set CHAR_LITERAL=3DRED
            ...

       o Border schemes
         - Many terminals do not support nice borders. CGDB needs to be
           able to show the user what is necessary without any special
           terminal characters. Although they are nice, they should not
           be necessary or hard coded.

>=20
>    - Robust source viewer:
>      o Fast syntax highlighting
>      o Regular expression searching
>      o Token identification (for displaying data)
       o A movable cursor.
         - The cursor should be able to move around the screen. Instead
           of just be on a line.=20
         - The user should be able to perform actions on the token under
           the cursor.=20
           example.=20
               a) Hit the '*' key to search for the next occurance of the
               word under the cursor.
               b) Perform one of CGDB's macro's substituting some special
               sequence for the word under the cursor. ( In order to
               print the word under the cursor )
               c) Maybe in a generic way you should be able to access
               the N'th word under the cursor. This would be helpful for
               macro's.
>      o Assembly view (source, asm, and mixed modes)
       o Perform actions like :set wrap
>      o Hyperlinking (for viewing help files)
>=20
>    - Windowing system:
>      o Arbitrary number of source windows
>      o Bindable to currently executing source
>      o Resizable.  Movable?
>      o Inferior process window (tty)
>=20
>    - Macro support (vim-style)
>=20
>    - Support reloading a new inferior program (gdb 'file' command)
>=20

The TGDB library is actually pretty simple. You covered most of it. Here
is a little more detail.

> The TGDB library should have the following features:
>=20
>    - GDB Interfaces
>      o Annotate 2
>      o GDB/MI
       o Make general design to allow easy plug/play.
         - Annotate 1
         - Annotate 3
>=20
>    - Support for advanced GUI features
>      o Reloading new inferior application
>      o Providing a TTY for the inferior window
>      o Providing assembly instruction as well as file:line info
>   =20
>    - Well-thought out API that will never change
       o Giving to the front end the proper callbacks and data=20
       structures.
         - The front end will get a 'struct breakpoint' structure.
           Instead of a char * with some data in it.
         - Callbacks will be put into place instead of a receiving all
           commands at once.
       o TGDB will be context driven. So multiple instances should work
       in the same program.
       o TGDB will be able to handle signals, or it will be able to
       receive the signals from the main application.
>=20
> I know I'm missing some things, so hopefully Bob can fill them in. =20
> Let me know what you guys think!  When we have this figured out=20
> completely, we can more accurately slap version numbers on our=20
> releases.  As well, it's important to get CGDB more solid-looking,=20
> so that when people do use it, they get a good impression. =20
> Documentation is going to be very important for this, as we've=20
> already seen sites describing CGDB as poorly documented.
>=20
> I'm excited to get working on it again!
>=20
> Mike

Well I can't wait to get working on it either. We have a long way to go!
Once we get all this down, maybe we can make some decisions.

Thanks,
Bob Rossi