gdb-ui, dedicated windows

gdb-ui, dedicated windows

[David Hansen]

Hello,

when `gdb-many-windows' is nil some windows (e.g. the window displaying
the stack buffer) are dedicated.

This may make sense with `gdb-many-windows' set to t but I find it
pretty annoying with a nil value.  I just looked at a long stack trace
displayed in the only window of the frame.

When I hit RET to jump to the interesting source Emacs popped up a new
frame.  IMHO it's very bad behavior to pop up a frame unless explicitly
asked to do so.

Do these windows have to be dedicated?

Another smaller annoyance: IMHO the separate IO buffer shouldn't be in a
dedicated window even if `gdb-many-windows' is t.  It just takes to much
space and makes it hard to look at two source files at the same time.

BTW, how about some key bindings to move around / display the gdb-ui
windows?

David

Re: gdb-ui, dedicated windows

[Nick Roberts]

 > when `gdb-many-windows' is nil some windows (e.g. the window displaying
 > the stack buffer) are dedicated.
 > 
 > This may make sense with `gdb-many-windows' set to t but I find it
 > pretty annoying with a nil value.  I just looked at a long stack trace
 > displayed in the only window of the frame.

Dedicating windows gives some control over window configuration.  Even if
gdb-many-windows is nil the user might choose to display buffers manually
that give a similar configuration to when it is t.

 > When I hit RET to jump to the interesting source Emacs popped up a new
 > frame.  IMHO it's very bad behavior to pop up a frame unless explicitly
 > asked to do so.

I use gdb-many-windows with a nil value and often just display the stack trace
in a separate frame (via the menubar) and I don't see this.  There must be
other factors like pop-up-frames being t, or the GUD and/or source buffer
killed or not being visible etc.

In order for me to accommodate your pattern of use, you need to provide a
recipe that illustrates the problem.

 > Do these windows have to be dedicated?

Not making them dedicated might fix your specific problem but would surely
cause others.  Currently window placement relies on heuristics and it will
probably always be possible to find a usage pattern where gdb-ui has annoying
behaviour.

It is this kind of problem, inspired by examining ECB, that has led to some
people to look at the concept of window groups, as discussed earlier this
year on the mailing list.

 > Another smaller annoyance: IMHO the separate IO buffer shouldn't be in a
 > dedicated window even if `gdb-many-windows' is t.  It just takes to much
 > space and makes it hard to look at two source files at the same time.

If it takes up too much room why use a separate buffer?  If you need a
separate buffer, why not put it in another frame?


 > BTW, how about some key bindings to move around / display the gdb-ui
 > windows?

It would be nice to be able to move the buffers around like views in Eclipse
but that would be a substantial task.  Emacs 23 has tabs in the header line
of some buffers.  Do you have any concrete ideas?


-- 
Nick                                           http://www.inet.net.nz/~nickrob

Re: gdb-ui, dedicated windows

[David Hansen]

On Sat, 5 Jul 2008 22:02:29 +1200 Nick Roberts wrote:

>  > when `gdb-many-windows' is nil some windows (e.g. the window displaying
>  > the stack buffer) are dedicated.
>  > 
>  > This may make sense with `gdb-many-windows' set to t but I find it
>  > pretty annoying with a nil value.  I just looked at a long stack trace
>  > displayed in the only window of the frame.
>
> Dedicating windows gives some control over window configuration.  Even if
> gdb-many-windows is nil the user might choose to display buffers manually
> that give a similar configuration to when it is t.

Well, if it is nil, the user obviously wants to control windows as he
wants, at least that's the reason why I toggle off many windows from
time to time.

>  > When I hit RET to jump to the interesting source Emacs popped up a new
>  > frame.  IMHO it's very bad behavior to pop up a frame unless explicitly
>  > asked to do so.
>
> I use gdb-many-windows with a nil value and often just display the stack trace
> in a separate frame (via the menubar) and I don't see this.  There must be
> other factors like pop-up-frames being t, or the GUD and/or source buffer
> killed or not being visible etc.

I use two frames, one for GNUS and one for everything else.
`pop-up-frames' is nil.

> In order for me to accommodate your pattern of use, you need to provide a
> recipe that illustrates the problem.

In this case only one window was displayed (the stack trace).  No other
emacs frame on the "virtual desktop" (or whatever this is called).

>  > Do these windows have to be dedicated?
>
> Not making them dedicated might fix your specific problem but would surely
> cause others.  Currently window placement relies on heuristics and it will
> probably always be possible to find a usage pattern where gdb-ui has annoying
> behaviour.

But why does gdb-ui wants to manage windows in the first place (if "many
windows" is nil)?  I don't quite see what it wants to achieve with it and
what can't be done with the usual functions (switch-to, display, ...).

> It is this kind of problem, inspired by examining ECB, that has led to some
> people to look at the concept of window groups, as discussed earlier this
> year on the mailing list.

See above.

>  > Another smaller annoyance: IMHO the separate IO buffer shouldn't be in a
>  > dedicated window even if `gdb-many-windows' is t.  It just takes to much
>  > space and makes it hard to look at two source files at the same time.
>
> If it takes up too much room why use a separate buffer?  If you need a
> separate buffer, why not put it in another frame?

Another frame uses the same space (even some pixels more for the
decoration!).  I'm just used to Emacs keys for switching windows.  Even
though my window manager behaves very similar it's just not the same...

But as I said, that's not a real problem for me, I stopped using a
separate IO buffer and don't miss it much.

>  > BTW, how about some key bindings to move around / display the gdb-ui
>  > windows?
>
> It would be nice to be able to move the buffers around like views in Eclipse
> but that would be a substantial task.  Emacs 23 has tabs in the header line
> of some buffers.  Do you have any concrete ideas?

At the time I use window-number.el (found on the emacswiki).  It's a
little minor mode that puts a number in the mode line and you can switch
windows via C-x C-j <n>.

It's very nice for gdb-ui with many windows but I think mnemonic
bindings would be better than numbers (I rarely use C-x C-j <n> outside
of gdb-ui).  There must be some C-c C- binding free...

David

Re: gdb-ui, dedicated windows

[Nick Roberts]

 > > Dedicating windows gives some control over window configuration.  Even if
 > > gdb-many-windows is nil the user might choose to display buffers manually
 > > that give a similar configuration to when it is t.
 > 
 > Well, if it is nil, the user obviously wants to control windows as he
 > wants, at least that's the reason why I toggle off many windows from
 > time to time.

He probably knows which buffers he wants in which windows but I'm not sure if
he knows how to put them there. 


 > > In order for me to accommodate your pattern of use, you need to provide a
 > > recipe that illustrates the problem.
 > 
 > In this case only one window was displayed (the stack trace).  No other
 > emacs frame on the "virtual desktop" (or whatever this is called).

I still can't reproduce this, or Miles' problem whrere gdb-ui will hide the gdb
buffer as a side-effect of popping up the source buffer (which may be a
consequence of the GUD buffer _not_ being in a dedicated window.


 > >  > Do these windows have to be dedicated?
 > >
 > > Not making them dedicated might fix your specific problem but would surely
 > > cause others.  Currently window placement relies on heuristics and it will
 > > probably always be possible to find a usage pattern where gdb-ui has annoying
 > > behaviour.
 > 
 > But why does gdb-ui wants to manage windows in the first place (if "many
 > windows" is nil)?  I don't quite see what it wants to achieve with it and
 > what can't be done with the usual functions (switch-to, display, ...).

OK, I've just tried using gdb-ui without making windows dedicated and not
noticed any degradation in performance.  Maybe dedicating the windows is
historical and isn't needed now windows are split more readily.  It's really
just evolved from my arbitrary personal use.  If you want to submit a patch and
others, e.g., Miles, think it's an improvement, I'll be happy to install
it.

-- 
Nick                                           http://www.inet.net.nz/~nickrob

Re: gdb-ui, dedicated windows

[Miles Bader]

Nick Roberts <nickrob@snap.net.nz> writes:
> I still can't reproduce this, or Miles' problem whrere gdb-ui will hide the gdb
> buffer as a side-effect of popping up the source buffer (which may be a
> consequence of the GUD buffer _not_ being in a dedicated window.
...
> OK, I've just tried using gdb-ui without making windows dedicated and not
> noticed any degradation in performance.  Maybe dedicating the windows is
> historical and isn't needed now windows are split more readily.  It's really
> just evolved from my arbitrary personal use.  If you want to submit a patch and
> others, e.g., Miles, think it's an improvement, I'll be happy to install
> it.

I'm not sure what's going on really -- the window doesn't seem to be
dedicated.  I'm not sure if I am using the same setup as other people, I
just say "M-x gdb" to invoke gdb, and get, initially, just a single
*gud...* buffer.

Anyway the problem is when the frame contains only a single window, with
the *gud...* buffer; if I do M-: (window-dedicated-p (selected-window)),
the result is nil.  So, at that point, if I type in, e.g., "up RET" to
the gdb prompt, naturally it tries to display the source code of the
new frame -- but the source-code buffer _replaces_ the *gud...* buffer
in the single window, instead of splitting the frame!

It _doesn't_ seem to happen if use "emacs -Q", so I guess it's some
setting, but I'm not sure what (I don't set any gud- or gdb- variables,
and the same/special-foo variables all seem normal).

The "immediate" cause seems to be that in the variable
`gdb-source-window' is different; in my normal (non-"-Q") emacs,
gdb-source-window seems to often point to the actual window being used
to display the *gud...* buffer; I guess this causes the problem.

-Miles

-- 
Electricity, n. The cause of all natural phenomena not known to be caused by
something else.

Re: gdb-ui, dedicated windows

[Miles Bader]

I wrote:
>> I still can't reproduce this, or Miles' problem whrere gdb-ui will hide the gdb
>> buffer as a side-effect of popping up the source buffer (which may be a
>> consequence of the GUD buffer _not_ being in a dedicated window.
> ...
>> OK, I've just tried using gdb-ui without making windows dedicated and not
>> noticed any degradation in performance.  Maybe dedicating the windows is
>> historical and isn't needed now windows are split more readily.  It's really
>> just evolved from my arbitrary personal use.  If you want to submit a patch and
>> others, e.g., Miles, think it's an improvement, I'll be happy to install
>> it.
>
> I'm not sure what's going on really -- the window doesn't seem to be
> dedicated.  I'm not sure if I am using the same setup as other people, I
> just say "M-x gdb" to invoke gdb, and get, initially, just a single
> *gud...* buffer.

Ah, actually I can reproduce it with "emacs -Q":

  (1) start a gdb session in emacs, and hit a breakpoint or something so
      that gdb pops up the source in another window (splitting the frame)

  (2) Switch to the source window with "C-x o"

  (3) Delete the other [*gud...*] window with "C-x 1"

  (4) Switch back to the *gud...* buffer using "C-x b *gud...* RET"

  (5) Try to pop up the source buffer again using a gdb command, e.g.,
      just "frame RET".

*bang*, *gdb...* buffer disappears, source buffer is only ting
displayed... :-(

-Miles

-- 
Carefully crafted initial estimates reward you not only with
reduced computational effort, but also with understanding and
increased self-esteem.         -- Numerical methods in C,
  Chapter 9. "Root Finding and Nonlinear Sets of Equations"

Re: gdb-ui, dedicated windows

[Nick Roberts]

 > Ah, actually I can reproduce it with "emacs -Q":
 > 
 >   (1) start a gdb session in emacs, and hit a breakpoint or something so
 >       that gdb pops up the source in another window (splitting the frame)
 > 
 >   (2) Switch to the source window with "C-x o"
 > 
 >   (3) Delete the other [*gud...*] window with "C-x 1"
 > 
 >   (4) Switch back to the *gud...* buffer using "C-x b *gud...* RET"
 > 
 >   (5) Try to pop up the source buffer again using a gdb command, e.g.,
 >       just "frame RET".
 > 
 > *bang*, *gdb...* buffer disappears, source buffer is only ting
 > displayed... :-(

OK.  When you do (4) you put the GUD buffer in the window that
gdb-source-window points to.  So when you do 'f' gdb-ui thinks the source
should go there.

I'm not sure what I can do as commands like switch-to-buffer are built-in.
Maybe some kind of hook in window-size-change-functions to keep gdb-ui
up-to-date.  Or perhaps having window groups would make it impossible to switch
the source buffer for the GUD buffer if they were assigned to different groups.

-- 
Nick                                           http://www.inet.net.nz/~nickrob

Re: gdb-ui, dedicated windows

[Miles Bader]

Nick Roberts <nickrob@snap.net.nz> writes:
>  >   (4) Switch back to the *gud...* buffer using "C-x b *gud...* RET"
>  > 
>  >   (5) Try to pop up the source buffer again using a gdb command, e.g.,
>  >       just "frame RET".
>  > 
>  > *bang*, *gdb...* buffer disappears, source buffer is only ting
>  > displayed... :-(
>
> OK.  When you do (4) you put the GUD buffer in the window that
> gdb-source-window points to.  So when you do 'f' gdb-ui thinks the source
> should go there.
>
> I'm not sure what I can do as commands like switch-to-buffer are built-in.
> Maybe some kind of hook in window-size-change-functions to keep gdb-ui
> up-to-date.  Or perhaps having window groups would make it impossible to switch
> the source buffer for the GUD buffer if they were assigned to different groups.

gud/gdb-ui shouldn't be storing window references like that and assuming
the associated buffer hasn't been changed by the user, because that's an
assumption that doesn't hold in emacs.

Perhaps that code is left over from the "old" gdb-ui which used
dedicated windows?

A possible fix would be to store the buffer gdb puts in that window,
and when deciding whether to re-use that window or, also verify that the
same buffer is there (and don't re-use the window if not).

-Miles

-- 
Acquaintance, n. A person whom we know well enough to borrow from, but not
well enough to lend to.

Re: gdb-ui, dedicated windows

[Nick Roberts]

 > gud/gdb-ui shouldn't be storing window references like that and assuming
 > the associated buffer hasn't been changed by the user, because that's an
 > assumption that doesn't hold in emacs.
 > 
 > Perhaps that code is left over from the "old" gdb-ui which used
 > dedicated windows?
 > 
 > A possible fix would be to store the buffer gdb puts in that window,
 > and when deciding whether to re-use that window or, also verify that the
 > same buffer is there (and don't re-use the window if not).

gdb-ui _does_ store the (source) buffer it puts in the window.  That's why when
you replace it with the GUD buffer using switch-to-buffer (not part of gdb-ui)
it gets confused.

It could verify that the same buffer is there but the contents of the source
window change every time the program being debugged stops in a frame that is in
a different file and gdb-ui must allow for this.  If the current window shows
the previous frame and execution is continued (from the tool bar, say) so that
it stops in another frame in a different file, then it's probably appropriate
to replace the entire window with one displaying the new file.

I'm not saying it that can't be done but it's probably more productive to
discuss these ideas with actual code.


-- 
Nick                                           http://www.inet.net.nz/~nickrob

Re: gdb-ui, dedicated windows

[Miles Bader]

Nick Roberts <nickrob@snap.net.nz> writes:
>  > A possible fix would be to store the buffer gdb puts in that window,
>  > and when deciding whether to re-use that window or, also verify that the
>  > same buffer is there (and don't re-use the window if not).
>
> gdb-ui _does_ store the (source) buffer it puts in the window.  That's why when
> you replace it with the GUD buffer using switch-to-buffer (not part of gdb-ui)
> it gets confused.
>
> It could verify that the same buffer is there but the contents of the source
> window change every time the program being debugged stops in a frame that is in
> a different file and gdb-ui must allow for this.

Why is this a problem?  In such cases, the source buffer should get
changed via gdb-display-source-buffer, which will update the associated
source-file, right?

In other words, it seems that as long as gud is the one doing the
updating of the source window, everything will remain consistent, and it
will keep using that window.  It would only be if some external agent
changes what's displayed in that window that the state would become
inconsistent -- and in that case, it's probably the right thing to do to
pop up a new window (which will become the new source window).

Anyway, I can make the obvious change and see if it feels funny.

-Miles

-- 
Optimist, n. A proponent of the doctrine that black is white.

Re: gdb-ui, dedicated windows

[Nick Roberts]

 > > It could verify that the same buffer is there but the contents of the
 > > source window change every time the program being debugged stops in a
 > > frame that is in a different file and gdb-ui must allow for this.
 > 
 > Why is this a problem?  In such cases, the source buffer should get
 > changed via gdb-display-source-buffer, which will update the associated
 > source-file, right?

It needs to distinguish between cases when it is appropriate to replace the
entire window with one displaying the new file, as described previously
and when it isn't, as in your example.

 > In other words, it seems that as long as gud is the one doing the
 > updating of the source window, everything will remain consistent, and it
 > will keep using that window.  It would only be if some external agent
 > changes what's displayed in that window that the state would become
 > inconsistent -- and in that case, it's probably the right thing to do to
 > pop up a new window (which will become the new source window).
 > 
 > Anyway, I can make the obvious change and see if it feels funny.

Sure.  If there are problems it can easily be reverted.  It might be a good
idea to start by not making the windows dedicated then perhaps David Hansen
can say if that cures his use case. 

-- 
Nick                                           http://www.inet.net.nz/~nickrob

Re: gdb-ui, dedicated windows

[Miles Bader]

Nick Roberts <nickrob@snap.net.nz> writes:
>  > Anyway, I can make the obvious change and see if it feels funny.
>
> Sure.  If there are problems it can easily be reverted.  It might be a good
> idea to start by not making the windows dedicated then perhaps David Hansen
> can say if that cures his use case. 

At least in my case, the windows _aren't_ dedicated.

I'm not using the 57-window gdb-ui variant, I'm just using M-x gdb RET.

[That's may be part of what's going on actually -- the current mechanism
feels like it was written expecting the windows to be dedicated.]

-Miles

-- 
It wasn't the Exxon Valdez captain's driving that caused the Alaskan oil spill.
It was yours.  [Greenpeace advertisement, New York Times, 25 February 1990]

Re: gdb-ui, dedicated windows

[Miles Bader]

Nick Roberts <nickrob@snap.net.nz> writes:
>  Currently window placement relies on heuristics and it will
> probably always be possible to find a usage pattern where gdb-ui has annoying
> behaviour.

The one which hits me a lot is that often gdb-ui will _hide the gdb
buffer_ as a side-effect of popping up the source buffer... :-(

-Miles

-- 
Acquaintance, n. A person whom we know well enough to borrow from, but not
well enough to lend to.

Re: gdb-ui, dedicated windows

[Tom Tromey]

>> Another smaller annoyance: IMHO the separate IO buffer shouldn't be in a
>> dedicated window even if `gdb-many-windows' is t.  It just takes to much
>> space and makes it hard to look at two source files at the same time.

Nick> If it takes up too much room why use a separate buffer?  If you need a
Nick> separate buffer, why not put it in another frame?

The effect I would like is to have a single, screen-filling "gdb UI"
frame show up when I start debugging, and have it go away when I
finish debugging.  And, I'd like to be able to arrange the windows in
this frame the way I like.

The "one frame" approach is vaguely reminiscent of an Eclipse
perspective.  FWIW I think it is reasonable for some people to want
multiple frames and some to want a single frame.

To achieve this, a few changes are needed.  First, Emacs needs a new
way to maximize a frame so it doesn't overshadow the panel.  Second,
gdb-ui needs some window layout code.

>> BTW, how about some key bindings to move around / display the gdb-ui
>> windows?

Nick> It would be nice to be able to move the buffers around like
Nick> views in Eclipse but that would be a substantial task.  Emacs 23
Nick> has tabs in the header line of some buffers.  Do you have any
Nick> concrete ideas?

A while back I wrote the appended.  It isn't perfect, but the idea is
that you can rearrange the windows by hand, then save the state.
Then, next time, M-x gdb-frame-restore-windows will use this window
layout instead of the built-in one.

A few unimplemented refinements: have gdb-ui do this automatically,
save the window configuration, and allow multiple "source" windows w/
LRU replacement.

Tom

;;; gdb-frame.el --- new frame for gdb

;; Copyright (C) 2007 Tom Tromey <tromey@redhat.com>

;; Author: Tom Tromey <tromey@redhat.com>
;; Created: 15 Sep 2007
;; Version: 0.1
;; Keywords: tools

;; This file is not (yet) part of GNU Emacs.
;; However, it is distributed under the same license.

;; GNU Emacs is free software; you can redistribute it and/or modify
;; it under the terms of the GNU General Public License as published by
;; the Free Software Foundation; either version 2, or (at your option)
;; any later version.

;; GNU Emacs is distributed in the hope that it will be useful,
;; but WITHOUT ANY WARRANTY; without even the implied warranty of
;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
;; GNU General Public License for more details.

;; You should have received a copy of the GNU General Public License
;; along with GNU Emacs; see the file COPYING.  If not, write to the
;; Free Software Foundation, Inc., 51 Franklin Street, Fifth Floor,
;; Boston, MA 02110-1301, USA.

;;; Commentary:

;;; Code:

(defvar gdb-application-frame nil)

(defun gdb-get-application-frame ()
  (unless (frame-live-p gdb-application-frame)
    (setq gdb-application-frame
	  (make-frame '((title . "Emacs - GDB")
			(tool-bar-lines . 1)
			(height . 55)
			(width . 183)))))
  (raise-frame gdb-application-frame)
  (select-frame-set-input-focus gdb-application-frame)
  gdb-application-frame)

(defun tjt-gdba (command-line)
  (interactive (list (gud-query-cmdline 'gdba)))
  (when (and (eq window-system 'x) gdb-many-windows)
    (gdb-get-application-frame))
  (gdba command-line))

(defvar gdb-frame-saved-windows nil)

(defun gdb--restore-windows-mapper (window-symbol window)
  (if (eq window-symbol 'gdb-source-window)
      ;; Assumes just one source window in the tree.
      (setq gdb-source-window window)
    (set-window-buffer window (gdb-get-buffer window-symbol))))

(defun gdb--restore-windows (parent-window tree map-fn)
  (let* ((vertical (nth 0 tree))
	 (edges (nth 1 tree))
	 (window-spec (nthcdr 2 tree)))
    (while window-spec
      (let* ((elt (car window-spec))
	     next-window)
	(if (cdr window-spec)
	    (setq next-window
		  ;; 'elt' here works for both the vector children and
		  ;; the list children.
		  (split-window parent-window (elt elt 1) (not vertical))))
	(if (vectorp elt)
	    (funcall map-fn (elt elt 0) parent-window)
	  (gdb--restore-windows parent-window elt map-fn))
	(setq parent-window next-window)
	(setq window-spec (cdr window-spec))))))

(defun gdb-frame-restore-windows ()
  (interactive)
  ;; Don't bother if we just had a single window.
  (delete-other-windows)
  (unless (symbolp gdb-frame-saved-windows)
    (gdb--restore-windows (selected-window) gdb-frame-saved-windows
			  #'gdb--restore-windows-mapper)))

(defun gdb--save-window-mapper (alist window)
  (if (eq window gdb-source-window)
      'gdb-source-window
    (or (cdr (assq (window-buffer window) alist))
	'gdb-source-window)))

(defun gdb--rewrite-window-tree (tree horizontal map-fn)
  (if (windowp tree)
      ;; Rewrite the window according to the mapper.
      ;; Also check for the source window.
      ;; If we don't understand what we have, assume it is the source.
      (let ((size (if horizontal
		      (window-height tree)
		    (window-width tree))))
	(vector (funcall map-fn tree) size))
    (append (list (nth 0 tree)
		  (let ((sizes (nth 1 tree)))
		    (if (nth 0 tree)
			(- (nth 2 sizes) (nth 0 sizes))
		      (- (nth 3 sizes) (nth 1 sizes)))))
	    (mapcar (lambda (item)
		      (gdb--rewrite-window-tree item (nth 0 tree) map-fn))
		    (nthcdr 2 tree)))))

(defun gdb-frame-save-windows ()
  (interactive)
  (let ((buffer-map
	 ;; Map buffers to symbolic buffer names.
	 (delq nil
	       (mapcar (lambda (elt)
			 (let ((buffer (gdb-get-buffer (car elt))))
			   (if buffer
			       (cons buffer (car elt))
			     nil)))
		       gdb-buffer-rules-assoc)))
	;; Use 'car' to avoid the minibuffer window here.
	(tree (car (window-tree))))
    (setq gdb-frame-saved-windows
	  (gdb--rewrite-window-tree tree
				    (if (consp tree) (nth 0 tree) nil)
				    (lambda (window)
				      (gdb--save-window-mapper buffer-map
							       window))))))

;;; gdb-frame.el ends here

Re: gdb-ui, dedicated windows

[Nick Roberts]

Tom Tromey writes:
 > >> Another smaller annoyance: IMHO the separate IO buffer shouldn't be in a
 > >> dedicated window even if `gdb-many-windows' is t.  It just takes to much
 > >> space and makes it hard to look at two source files at the same time.
 > 
 > Nick> If it takes up too much room why use a separate buffer?  If you need a
 > Nick> separate buffer, why not put it in another frame?
 > 
 > The effect I would like is to have a single, screen-filling "gdb UI"
 > frame show up when I start debugging, and have it go away when I
 > finish debugging.  And, I'd like to be able to arrange the windows in
 > this frame the way I like.

Killing the GUD buffer kills the associated buffers.  Maybe that's not obvious
but it is mentioned in the manual.

 > The "one frame" approach is vaguely reminiscent of an Eclipse
 > perspective.  FWIW I think it is reasonable for some people to want
 > multiple frames and some to want a single frame.
 > 
 > To achieve this, a few changes are needed.  First, Emacs needs a new
 > way to maximize a frame so it doesn't overshadow the panel.  Second,
 > gdb-ui needs some window layout code.

I'm not sure what you mean.  Emacs appears maximise a frame like any other
application and the (Gnome) planel always remains visible for me.

 > >> BTW, how about some key bindings to move around / display the gdb-ui
 > >> windows?
 > 
 > Nick> It would be nice to be able to move the buffers around like
 > Nick> views in Eclipse but that would be a substantial task.  Emacs 23
 > Nick> has tabs in the header line of some buffers.  Do you have any
 > Nick> concrete ideas?
 > 
 > A while back I wrote the appended.  It isn't perfect, but the idea is
 > that you can rearrange the windows by hand, then save the state.
 > Then, next time, M-x gdb-frame-restore-windows will use this window
 > layout instead of the built-in one.

Yes it would be nice to have something like this, although I generally don't
want to start with the same window arrangement that I finished with in the
previous sessiion.  Whenever possible I recompile and stay in the same session
and that way I keep breakpoints, command history etc.


 > A few unimplemented refinements: have gdb-ui do this automatically,
 > save the window configuration, and allow multiple "source" windows w/
 > LRU replacement.

For the source window I think this would need to save the source buffer and use
gdb-display-source-buffer.

-- 
Nick                                           http://www.inet.net.nz/~nickrob

Re: gdb-ui, dedicated windows

[Tom Tromey]

>>>>> "Nick" == Nick Roberts <nickrob@snap.net.nz> writes:

Tom> To achieve this, a few changes are needed.  First, Emacs needs a
Tom> new way to maximize a frame so it doesn't overshadow the panel.

Nick> I'm not sure what you mean.  Emacs appears maximise a frame like
Nick> any other application and the (Gnome) planel always remains
Nick> visible for me.

Try:

(modify-frame-parameters nil '((fullscreen . fullboth)))

For me this covers the whole screen.  I reported this last year
sometime ... Emacs needs a new fullscreen mode that respects the fd.o
standard here.  (It needs the current mode for presentation apps.)

Nick> Yes it would be nice to have something like this, although I
Nick> generally don't want to start with the same window arrangement
Nick> that I finished with in the previous sessiion.  Whenever
Nick> possible I recompile and stay in the same session and that way I
Nick> keep breakpoints, command history etc.

Different strokes...

Tom

Re: gdb-ui, dedicated windows

[tomas]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Mon, Jul 07, 2008 at 08:40:59AM -0600, Tom Tromey wrote:

[...]

> (modify-frame-parameters nil '((fullscreen . fullboth)))
> 
> For me this covers the whole screen.  I reported this last year
> sometime ... Emacs needs a new fullscreen mode that respects the fd.o
> standard here.  (It needs the current mode for presentation apps.)

Yes, pleeeease :-)

- -- tomás
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFIckDPBcgs9XrR2kYRAhwlAJ9ubOYK1OmEudl1RUwstGFTBEP7mACfXfj/
VbsvyskLlvLLshSu/zOM4xQ=
=FPG0
-----END PGP SIGNATURE-----

Re: gdb-ui, dedicated windows

[David Hansen]

On Mon, 07 Jul 2008 08:40:59 -0600 Tom Tromey wrote:

>>>>>> "Nick" == Nick Roberts <nickrob@snap.net.nz> writes:
>
> Tom> To achieve this, a few changes are needed.  First, Emacs needs a
> Tom> new way to maximize a frame so it doesn't overshadow the panel.
>
> Nick> I'm not sure what you mean.  Emacs appears maximise a frame like
> Nick> any other application and the (Gnome) planel always remains
> Nick> visible for me.
>
> Try:
>
> (modify-frame-parameters nil '((fullscreen . fullboth)))
>
> For me this covers the whole screen.  I reported this last year
> sometime ... Emacs needs a new fullscreen mode that respects the fd.o
> standard here.  (It needs the current mode for presentation apps.)

Just a bit curious, isn't it the window managers job to put the window
into full screen?  At least that's the way I do it.  But I don't have a
panel or stuff, so maybe these problems don't exits here at all.

David

Re: gdb-ui, dedicated windows

[Lennart Borgman (gmail)]

David Hansen wrote:
> On Mon, 07 Jul 2008 08:40:59 -0600 Tom Tromey wrote:
> 
>>>>>>> "Nick" == Nick Roberts <nickrob@snap.net.nz> writes:
>> Tom> To achieve this, a few changes are needed.  First, Emacs needs a
>> Tom> new way to maximize a frame so it doesn't overshadow the panel.
>>
>> Nick> I'm not sure what you mean.  Emacs appears maximise a frame like
>> Nick> any other application and the (Gnome) planel always remains
>> Nick> visible for me.
>>
>> Try:
>>
>> (modify-frame-parameters nil '((fullscreen . fullboth)))
>>
>> For me this covers the whole screen.  I reported this last year
>> sometime ... Emacs needs a new fullscreen mode that respects the fd.o
>> standard here.  (It needs the current mode for presentation apps.)
> 
> Just a bit curious, isn't it the window managers job to put the window
> into full screen?  At least that's the way I do it.  But I don't have a
> panel or stuff, so maybe these problems don't exits here at all.


Yes, I think at least on w32 it is the window manager's job.

Re: gdb-ui, dedicated windows

[Tom Tromey]

>>>>> "David" == David Hansen <david.hansen@gmx.net> writes:

David> Just a bit curious, isn't it the window managers job to put the window
David> into full screen?  At least that's the way I do it.  But I don't have a
David> panel or stuff, so maybe these problems don't exits here at all.

It is nice to be able to do it programmatically as well.  AIUI, both
Gnome and KDE conform to a spec that enables this possibility for
client apps.

Tom

Re: gdb-ui, dedicated windows

[Lennart Borgman (gmail)]

Tom Tromey wrote:
>>>>>> "David" == David Hansen <david.hansen@gmx.net> writes:
> 
> David> Just a bit curious, isn't it the window managers job to put the window
> David> into full screen?  At least that's the way I do it.  But I don't have a
> David> panel or stuff, so maybe these problems don't exits here at all.
> 
> It is nice to be able to do it programmatically as well.  AIUI, both
> Gnome and KDE conform to a spec that enables this possibility for
> client apps.


That is of course possible on w32 too. You tell the window manager to 
maximize the window. The window manager knows the correct size and 
position for a maximized window.

Re: gdb-ui, dedicated windows

[Stephen J. Turnbull]

David Hansen writes:

 > Just a bit curious, isn't it the window managers job to put the window
 > into full screen?

It is, in fact if you are running a window manager under X11 it's the
only way to do it.  The window manager will simply clip the client's
window to what it has decided to allow.

The problem is that there are many options regarding what "maximize"
means:

1.  Is it in response to the user (eg, clicking a maximize button on
    the frame) or the client (eg, obeying a "start me maximized"
    resource)?
2.  Which dimensions are maximized (horizontal, vertical, both)?
3.  Are window decorations maintained for the maximized window?
4.  Are window and session manager widgets (panel, taskbar, etc)
    allowed to be covered?

Distinction (1) is essential to usability; you need to be able to do
both.  Many users don't care so much about flexibility in areas (2),
(3), and (4), but others do.  One of the projects of freedesktop.org
(somebody referred to that as "fd.o") is to provide a standard
protocol for any client and window manager that allows all of these
parameters to be set in a flexible way.

Re: gdb-ui, dedicated windows

[Lennart Borgman (gmail)]

Stephen J. Turnbull wrote:
> David Hansen writes:
> 
>  > Just a bit curious, isn't it the window managers job to put the window
>  > into full screen?
> 
> It is, in fact if you are running a window manager under X11 it's the
> only way to do it.  The window manager will simply clip the client's
> window to what it has decided to allow.
> 
> The problem is that there are many options regarding what "maximize"
> means:
> 
> 1.  Is it in response to the user (eg, clicking a maximize button on
>     the frame) or the client (eg, obeying a "start me maximized"
>     resource)?
> 2.  Which dimensions are maximized (horizontal, vertical, both)?
> 3.  Are window decorations maintained for the maximized window?
> 4.  Are window and session manager widgets (panel, taskbar, etc)
>     allowed to be covered?
> 
> Distinction (1) is essential to usability; you need to be able to do
> both.  Many users don't care so much about flexibility in areas (2),
> (3), and (4), but others do.  One of the projects of freedesktop.org
> (somebody referred to that as "fd.o") is to provide a standard
> protocol for any client and window manager that allows all of these
> parameters to be set in a flexible way.


Another essential thing is the placement of the maximized window.

Re: gdb-ui, dedicated windows

[James Cloos]

>>>>> "Tom" == Tom Tromey <tromey@redhat.com> writes:

Tom> (modify-frame-parameters nil '((fullscreen . fullboth)))

Tom> For me this covers the whole screen.

For icewm: _NET_WM_STATE(ATOM) is set to:

_NET_WM_STATE_MAXIMIZED_VERT,
_NET_WM_STATE_MAXIMIZED_HORZ

for a window (frame in Emacs terminology) which does not occlude the
panel.  For a fully maximized window, it is set to:

_NET_WM_STATE_FULLSCREEN,
_NET_WM_STATE_MAXIMIZED_VERT,
_NET_WM_STATE_MAXIMIZED_HORZ

and the _WIN_LAYER(CARDINAL) is increased to layer the window on top
of the panel.

I beleive that is the standardized, window manager independent behaviour.

The typical terminology is 'Maximized' for the former behaviour and 'Full
Screen' for the latter.

-JimC
-- 
James Cloos <cloos@jhcloos.com>         OpenPGP: 1024D/ED7DAEA6