*** Bug 618662 has been marked as a duplicate of this bug. ***

Looks certainly interesting. Without playing with this, here are some initial impressions from looking at the code for 5 minutes:

- If we do this, we probably want to make sure it can fully supersede GtkFixed (ie implement static positions, I guess)

- I would prefer to not expose the overlay-child struct, and instead make all the knobs available as child properties

- I think you probably want to allow x/y offsets, at least for stuff placed relative to corners ?

- Do we need z ordering ?

- Should the size request be MAX (main, all children) ?

- Why is this a window widget ?

(In reply to comment #2)
> Looks certainly interesting. Without playing with this, here are some initial
> impressions from looking at the code for 5 minutes:
> 
> - If we do this, we probably want to make sure it can fully supersede GtkFixed
> (ie implement static positions, I guess)
Do we really want this? See that while GtkFixed is for placing widgets in static positions GeditOverlay is focused on the main widget/relative widget and having some widgets placed in static positions.

> 
> - I would prefer to not expose the overlay-child struct, and instead make all
> the knobs available as child properties
sure, although the reason for the overlay-child was to make the child have a GdkWindow.

> 
> - I think you probably want to allow x/y offsets, at least for stuff placed
> relative to corners ?
> 
makes sense

> - Do we need z ordering ?

Right now the last one added is the one that will be shown over the others. I do not know about any use case for z reodering, should we add it or wait if somebody request it?
> 
> - Should the size request be MAX (main, all children) ?
Not really, we had it like this before and it is not really what we want. The main widget is the one that should request the size and the other widgets shouldn't request more than the main widget. I.e in epiphany or nautilus you don't want the status widget to be bigger than the main widget.

> 
> - Why is this a window widget ?
Good question, when I made it was easier, so I guess I can change it.

This was discussed in the gtk team recently: 

https://live.gnome.org/GTK%2B/Meetings?action=AttachFile&do=view&target=20110510.txt

Some of the points that were raised:

- It would be good to have some usage guidelines for an overlay container like this (hig...)

- static placement (ie gtkfixed-like) was seen as relatively uninteresting

- for specifying the placement, would be nice to reuse a pair of GtkAlign values 
  (ie start, center, end for each dimension).

So I guess I could give it some time to this, some things:
* Should it be GtkOverlay?
* in relation to GtkAlign, do we manage the z dimension?, do we manage it with something else than GtkAlign? do we manage it at all?

I think I will start next week and with the easy parts first, i.e removing the GdkWindow from it, as commented on #comment2

I don't think we need to manage z, initially.

(In reply to comment #4)
> - for specifying the placement, would be nice to reuse a pair of GtkAlign
> values 
>   (ie start, center, end for each dimension).
>
Actually, I think it would be awesome to use the actual values of gtk_widget_get_halign() and gtk_widget_get_valign(). Otherwise those values won't do anything...

Another thing I wanted to point out:
The overlay currently underallocates the overlayed child if it is bigger than the parent. This can be seen when shrinking nautilus to its minimum size and opening a directory that causes the loading bar to appear.

I'll be working on this on my branch:
https://github.com/nacho/gtk-/tree/overlay

I'll let you know when I get the current commented things ready.

Some review comments:

api:
- should there be api to get/set the relative widget ?
- maybe keep that out of the constructor ?
- what does gtk_container_add do - it would feel more natural to
  me to make this behave like a bin, with only one slot for regular
  children, and treat the overlays as special slots
- maybe keep offsets out of overlay_add ?
- if there's set_offset, there should be get_offset too
- offset interpretation seems inconsistent (I would have expected
  negative offseets for the end alignment case)
- or maybe do without offsets and use widget margins ?

implementation:
- dispose should drop relative_widget ?
- should require relative_widget to be descendent of main_widget ?
- probably need to queue a resize when relative_widget_is set ?
- not sure main_widget should be a property
- gtk_overlay_size_allocate needs to translate the relative_widget
  allocation to overlay->window coordinates, I think ?
- gtk_overlay_remove leaks the child window

(In reply to comment #9)
> Some review comments:
> 
> api:
> - should there be api to get/set the relative widget ?
ok
> - maybe keep that out of the constructor ?
ok
> - what does gtk_container_add do - it would feel more natural to
>   me to make this behave like a bin, with only one slot for regular
>   children, and treat the overlays as special slots
so remove the main_widget from construction and set it with gtk_container_add ?
will make more happy glade indeed
> - maybe keep offsets out of overlay_add ?
ok
> - if there's set_offset, there should be get_offset too
> - offset interpretation seems inconsistent (I would have expected
>   negative offseets for the end alignment case)
> - or maybe do without offsets and use widget margins ?
I will implement this with the margins
> 
> implementation:
> - dispose should drop relative_widget ?
well it is suppose to be a child of main_widget
> - should require relative_widget to be descendent of main_widget ?
yes, that's the idea but not sure how to do it, any way to check this?
or should I just go children by children checking?
> - probably need to queue a resize when relative_widget_is set ?
makes sense, yes
> - not sure main_widget should be a property
if we add it with gtk_container_add doesn't look like so
> - gtk_overlay_size_allocate needs to translate the relative_widget
>   allocation to overlay->window coordinates, I think ?
mmm, not sure about this...

> - gtk_overlay_remove leaks the child window
ok

I will tell about when I get things ready. Thanks for the review

It kinda makes sense to me also, that if we remove the main widget we remove also the other widgets and we set the relative widget to NULL.
What do you think? is this the desired behavior or just set the relative widget to null and we leave the other widgets waiting for another main widget?

I've pushed your branch to git.gnome.org, with a bunch of fixes of mine on top.
I think it is very close to merge-ready now, I'll probably do that over the weekend.