RE: Z-ordering

["Gavin Lambert" <gavinl compacsort com>]

Quoth D. R. Evans:
> Sorry, but I can't see how to make that work. Assuming that by "window"
> you mean "[Gtk::]Window":

That's right.

> 1. How does one attach a Window to a particular set of cells in the
> Grid?
> The attach() function seems to take a Widget, and a Widget isn't a
> Window.

Why do you need it to be attached?  You can ask the window manager to open up a dialog window centred on the main window, but the user can then move it somewhere else if they want to.  Unless it's somehow important to hide the content under where the window would appear this shouldn't be an issue.

> 2. (This may be the same question) How does one stop the Window that
> represents A from behaving independently of the Window that holds the
> Grid?
> For example, if the user grabs the main Window (i.e., the one that
> contains the Grid) and moves it, one obviously wants the cells
> represented by A to move along with the rest of the Grid. How does one
> ensure that that happens?

If it's a dialog box, then the user can't move the main window until they've dealt with the dialog (or maybe that depends on which window manager is being used; I'm not quite sure), so this isn't an issue.

If you open it as a sibling modeless window then they can move both independently.  As mentioned above, I'm not sure why this would be a problem.


It does sound a bit like you've got your head stuck in the methods and constraints of a text-based-overlay system -- many of those go out the door when you shift to a full layered windowing system (whether text-based or graphical).

(Or at least your initial description sounded like you were making something dialog-box-like.  If you're wanting something combo-box-like instead then that'd be different -- but someone else would have to help you there, I don't know enough about trying to duplicate that sort of behaviour.)