Problems with new GDB toolbar

Problems with new GDB toolbar

[Kim F. Storm]

Hi Nick,

The new GDB toolbar is awesome -- IMO, it's the first real
"killer app" which shows that a toolbar really can be useful!

However, I find some of the new icon a bit confusing, and I
notices some minor problems with it.

After first starting gdb, the first icon I clicked on
(to get things going) was the [Go] icon.  It resulted in
a the following error:

  gud-format-command: Wrong type argument: stringp, nil


Well, I started the program with the [Run] icon, and now wanted to
install a breakpoint in the code... so I clicked on the [Stop] icon.

It didn't work, so I did C-c C-z to stop the program...

I used C-c C-b to set the breakpoint, and then clicked on [Go]
to continue exection...  and it removed the breakpoint.

Ok, now a small bell rang, and I took the time to look at the tooltips;
[Stop] means "Set Breakpoint" and [Go] means "Clear breakpoint"...  

IMO, the [Stop] button should send a stop signal to the process, and
the [Go] button should do the equivalent of "continue". 

And then you should add new buttons for Set and Clear breakpoint;
I would recommend a "red bullet" (with no text) to set a breakpoint,
and the same "red bullet" with an "X" over it to clear the breakpoint.

Also, most of the icons (except [Run]) should be "shaded" when the
program isn't running.  Also, the [Run] tooltip should be changed to
"Restart program" when the program is running.

Finally, when the gud buffer exists, the GDB toolbar seems to be used
as the default toolbar for modes which uses the default toolbar.
That's pretty annoying.

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: Problems with new GDB toolbar

[Miles Bader]

On Sun, Nov 17, 2002 at 11:48:18PM +0100, Kim F. Storm wrote:
> And then you should add new buttons for Set and Clear breakpoint;
> I would recommend a "red bullet" (with no text) to set a breakpoint,
> and the same "red bullet" with an "X" over it to clear the breakpoint.

The GUI debugger I use at work generally uses a red `stopsign' (octagonal
thing; the shape of stopsigns in the U.S.) to represent breakpoints in the UI
(in the margin by breakpoint'd lines, etc).  Is that what you mean by `red
bullet'?  I can't imagine you mean the kind that gets shot from a gun...

-Miles

-- 
P.S.  All information contained in the above letter is false,
      for reasons of military security.

Problems with new GDB toolbar

[Nick Roberts]

Kim F. Storm writes:

 > However, I find some of the new icon a bit confusing, and I
 > notices some minor problems with it.

 I agree entirely. I don't pretend they're all ideal. Some have
 been taken from the Insight debugger by Cygnus/RedHat. I've
 made up the others myself. They're meant to be a starting point
 and I will feed back opinion on this mailing list to the
 graphic designer(s) who might provide new ones.
 
 > After first starting gdb, the first icon I clicked on
 > (to get things going) was the [Go] icon.  It resulted in
 > a the following error:
 > 
 >   gud-format-command: Wrong type argument: stringp, nil
 > 

 I can see the ambiguity. My reasoning was that the gdb command is `run' not
 `go'. And that `go' being the opposite of `stop' gave a reasonable pair of
 icons for the tasks of removing/setting breakpoints.

 > Well, I started the program with the [Run] icon, and now wanted to
 > install a breakpoint in the code... so I clicked on the [Stop] icon.

 Stopping execution is exactly what the Insight debugger uses it for. But I
 didn't. :-)

 > It didn't work, so I did C-c C-z to stop the program...
 >
 > I used C-c C-b to set the breakpoint, and then clicked on [Go]
 > to continue exection...  and it removed the breakpoint.
 >
 > Ok, now a small bell rang, and I took the time to look at the tooltips;
 > [Stop] means "Set Breakpoint" and [Go] means "Clear breakpoint"...  

 I do think that the tooltips should be the first thing to look for with a new
 set of icons.

 > IMO, the [Stop] button should send a stop signal to the process, 

 That sounds sensible.

 > and the [Go] button should do the equivalent of "continue". 

 I prefer the current button for "continue". It seems intuitive and is part of
 a set controlling execution.

 > And then you should add new buttons for Set and Clear breakpoint;
 > I would recommend a "red bullet" (with no text) to set a breakpoint,
 > and the same "red bullet" with an "X" over it to clear the breakpoint.

 This metaphor is a bit lost on me but I have seen it before.

 > Also, most of the icons (except [Run]) should be "shaded" when the
 > program isn't running.  Also, the [Run] tooltip should be changed to
 > "Restart program" when the program is running.

 I don't think this can be done in gud.el. However, I think it can in
 gdb-ui.el in which gdb is started with the command `gdba'. This is the file
 which I've put most work into and has got a lot more new features (like
 breakpoint icons in the margin, stack frames etc).

 > Finally, when the gud buffer exists, the GDB toolbar seems to be used
 > as the default toolbar for modes which uses the default toolbar.
 > That's pretty annoying.

 I don't know what the default toolbar is but I can't get the GDB toolbar in
 any buffer that has gud-minor-mode set to nil. Even a buffer in fundamental
 mode seems to have its own toolbar. Can you explain ?

Nick

Re: Problems with new GDB toolbar

[Alan Shutko]

Nick Roberts <nick@nick.uklinux.net> writes:

> This is the file which I've put most work into and has got a lot
> more new features (like breakpoint icons in the margin

Is there any reason they're in the margin, not in the fringe?

-- 
Alan Shutko <ats@acm.org> - In a variety of flavors!
The best cure for the nations economy would be economy.

Re: Problems with new GDB toolbar

[Nick Roberts]

 > > This is the file which I've put most work into and has got a lot
 > > more new features (like breakpoint icons in the margin
 > 
 > Is there any reason they're in the margin, not in the fringe?
 > 

I've put them in the margin because, as Kim Storm says, it can be done in lisp
while putting them in the fringe requires changing the c code. Perhaps I could
turn the question around :

Is there any reason why I should put the breakpoint icons in the fringe and
not the margin ?

Nick

Re: Problems with new GDB toolbar

[Alan Shutko]

storm@cua.dk (Kim F. Storm) writes:

> In any case, I think the display margin is the proper place for the
> gdb icons.

Ok, for now that makes sense.  But are you saying that the display
margin should always be the proper place, once it's technically
feasible?

-- 
Alan Shutko <ats@acm.org> - In a variety of flavors!
Liberal Rule: Arguments are lost only to bigots.

Re: Problems with new GDB toolbar

[Kim F. Storm]

Alan Shutko <ats@acm.org> writes:

> Nick Roberts <nick@nick.uklinux.net> writes:
> 
> > This is the file which I've put most work into and has got a lot
> > more new features (like breakpoint icons in the margin
> 
> Is there any reason they're in the margin, not in the fringe?

The fridge does not support user defined icons!  I have some
plans to implement this, but I haven't had time to do it yet.

One problem is that the "arrow" is in the fringe; if we want to put
user-defined icons in the fringe, we would need a way to display the
arrow on top of those icons... 

In any case, I think the display margin is the proper place for the
gdb icons.

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: Problems with new GDB toolbar

[Kim F. Storm]

Alan Shutko <ats@acm.org> writes:

> storm@cua.dk (Kim F. Storm) writes:
> 
> > In any case, I think the display margin is the proper place for the
> > gdb icons.
> 
> Ok, for now that makes sense.  But are you saying that the display
> margin should always be the proper place, once it's technically
> feasible?

I have no strong opinion here; but using the display margin is the
most versatile for this purpose and could be expanded to provide
more information, e.g. breakpoint numbers.

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: Problems with new GDB toolbar

[Miles Bader]

storm@cua.dk (Kim F. Storm) writes:
> One problem is that the "arrow" is in the fringe; if we want to put
> user-defined icons in the fringe, we would need a way to display the
> arrow on top of those icons... 

The GUI debugger I previously mentioned does this by having an icon for
exactly that case, which shows both the arrow and the breakpoint symbol
combined.  To make this work, the breakpoint icon is a `fat' shape (a
stopsign shape), and the arrow is thinner than the emacs arrow (more
like a real arrow, not just a triangle), so that overlaying them works
pretty well.

[I think the emacs fringe-arrow could do with some change anyway; the
current one is pretty ugly...]

-Miles
-- 
The secret to creativity is knowing how to hide your sources.
  --Albert Einstein

Re: Problems with new GDB toolbar

[Alan Shutko]

Nick Roberts <nick@nick.uklinux.net> writes:

> Is there any reason why I should put the breakpoint icons in the
> fringe and not the margin ?

The fringe is always there (in the default config, at least).  But
it's hardly ever used.  It's a bit annoying to have that space there,
but unused while a breakpoint icon shoves everything over.

Of more immediate concern, I noticed that the GUD variable value
tooltips don't seem to work in M-x gdba.  They don't show the
variable value, but rather a bunch of other junk.  I'm guessing the
parsing doesn't work with the --annotate flag to gdb.  Has anyone
taken a look at that yet?

-- 
Alan Shutko <ats@acm.org> - In a variety of flavors!
Conscience is God's presence in man. - Emanuel Swedenborg

Re: Problems with new GDB toolbar

[Nick Roberts]

Alan Shutko writes:

 > Of more immediate concern, I noticed that the GUD variable value
 > tooltips don't seem to work in M-x gdba.  They don't show the
 > variable value, but rather a bunch of other junk.  I'm guessing the
 > parsing doesn't work with the --annotate flag to gdb.  Has anyone
 > taken a look at that yet?

That's right gdb-ui.el and tooltip.el both have their own process filter
function. The one in gdb-ui.el filters out the annotations (`the junk') while
the one in tooltip.el doesn't. If may be a simple fix but I'll have to
understand tooltip.el first.

More generally, my changes to gud.el are fairly minor (adding the toolbar and
accomodating gdb-ui.el) so it should still be pretty robust. gdb-ui.el, on
the other hand, is much less mature, and there are probably many things
that don't work properly.

Nick

Re: Problems with new GDB toolbar

[Richard Stallman]

    > Is there any reason why I should put the breakpoint icons in the
    > fringe and not the margin ?

    The fringe is always there (in the default config, at least).  But
    it's hardly ever used.  It's a bit annoying to have that space there,
    but unused while a breakpoint icon shoves everything over.

We want to put the fringes inside the display margins.
Once that is done, it would be better to put these icons in the
fringe to keep them closer to the text.