Ian Martin said the following at 11/03/2011 03:14 AM : > My understanding is that Gtkmm is based on the idea of not defining > widget relationships absolutely, on the basis that when you change > screen resolution/ output device/ window size you want to retain the > relative relationships between widgets. One option is a second window > (either a Gtk::Window or a Gtk::Dialog); it will popup in front of your > main window, but defining the window location is only able to be done in > relative terms; it's a guide for the Window manager, not a method > internal to gtkmm. OK, so that sounds like the suggestion of using a Window is not the correct way forward. > > You're talking about effectively replacing widgets, though, so a second > window won't achieve the effect you want. You could use hide() and > show() on your primary widget and its replacement; the two widgets would > need to be guaranteed to be the same size for any window shape, but with > some intelligent packing it should work OK. Alternatively, if you want I'm not quite following you (specifically I'm not sure what you mean by "primary widget", nor the bit about widgets being the same size: in the example I gave of what I need to do, widget A is not the same size as any other widget, so I'm not sure how your procedure applies to the problem at hand). Suppose that we're at this point in the process (as a reminder I'll copy part of the example of what I'm trying to do at the end of this e-mail): +---------------------+ | 00011112223333333333| | 00011112223333333333| | 00011112224444444444| | 55511112226667888888| | 55511112226667888888| | 55511112226667888888| | 55511112226667888888| | 99999999999999999999| +---------------------+ In my e-mail <4EB17FB9 6050906 gmail com> I was thinking that a Grid was the correct container for this, but after experimenting it seems that a Table is a bit easier to work with, although fundamentally I don't think there's any relevant difference. So I start with a Table container that contains 10 Widgets (they happen to be TextAreas, but I don't suppose that matters). The 10 Widgets are laid out as in the above diagram. I create another TextArea (Widget A) that looks like this: AAAAAAAA AAAAAAAA AAAAAAAA AAAAAAAA and then execute hide() for this Widget. Now I attach it to location (5, 3) in the Table. At this point, all looks great: I still see only the Widgets 0 through 9. Now I execute show() for Widget A and... nothing happens. It does not appear. If I execute hide() for some of the other widgets then Widget A can be exposed... but then there are blank pieces on the screen, which isn't the needed behaviour. > an absolute relationship between widgets, you need a drawing widget. If > you go that way, a Gtk::Layout has the methods you want. I looked at Gtk::Layout (I'd looked at it before as well) and I don't see anything especially useful about it. It's scrollable, but I don't need that. Other than that it doesn't seem to have any member functions that provide any different behaviour than the Table I've been trying to use. Which member functions do you have in mind? I think I'm still missing something obvious. So I'm sorry to ask for a bit more detail as to how you would implement this, but I'm afraid I have to, since I still don't see the trick. Doc Here is a reminder of the simple example that demonstrates what I'm trying to do: > Now I put some widgets in it. I'll number the cells to indicate which > widget is occupying that cell: > > +---------------------+ > | 00011112223333333333| > | 00011112223333333333| > | 00011112224444444444| > | 55511112226667888888| > | 55511112226667888888| > | 55511112226667888888| > | 55511112226667888888| > | 99999999999999999999| > +---------------------+ > > Now, the user presses some key combination which means that I need to > display a pre-existing but undisplayed widget A "in front": > > +---------------------+ > | 00011112223333333333| > | 00011112223333333333| > | 00011AAAAAAAA4444444| > | 55511AAAAAAAA7888888| > | 55511AAAAAAAA7888888| > | 55511AAAAAAAA7888888| > | 55511112226667888888| > | 99999999999999999999| > +---------------------+ > > Widget A receives keystrokes for a while and then receives a keystroke > that tells it to disappear (although it continues to exist and will be > logically updated, although the results of such updates are no longer > visible on the physical screen until the next time it is displayed), > so that the situation returns to: > > +---------------------+ > | 00011112223333333333| > | 00011112223333333333| > | 00011112224444444444| > | 55511112226667888888| > | 55511112226667888888| > | 55511112226667888888| > | 55511112226667888888| > | 99999999999999999999| > +---------------------+ -- Web: http://www.sff.net/people/N7DR
Attachment:
signature.asc
Description: OpenPGP digital signature