After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 92333 - gtk_plug_size_allocate() called three times when adding applet to panel
gtk_plug_size_allocate() called three times when adding applet to panel
Status: RESOLVED FIXED
Product: gnome-panel
Classification: Other
Component: libpanel-applet
unspecified
Other All
: Normal major
: ---
Assigned To: Panel Maintainers
Panel Maintainers
Depends on:
Blocks:
 
 
Reported: 2002-09-02 15:07 UTC by padraig.obriain
Modified: 2015-08-22 23:17 UTC
See Also:
GNOME target: ---
GNOME version: 2.9/2.10


Attachments
Stack traces when gtk_plug_size_allocate is called (26.87 KB, text/plain)
2002-09-02 15:07 UTC, padraig.obriain
Details

Description padraig.obriain 2002-09-02 15:07:06 UTC
gtk_plug_size_allocate() is called three times when applet (I tried it with
InBox Monitor but I expect that it would be the same for all applets).

The first time and third times it is called the allocation width is 45 and
the second time it is called the allocation width is 1.
Comment 1 padraig.obriain 2002-09-02 15:07:57 UTC
Created attachment 10859 [details]
Stack traces when gtk_plug_size_allocate is called
Comment 2 Luis Villa 2002-09-03 21:32:08 UTC
Is this related to bug 91999?
Comment 3 padraig.obriain 2002-09-04 08:15:24 UTC
This bug complains about what seems like redundant size allocations
when adding one applet to a panel. I have not looked at what happens
when adding more than one applet to a panel.

Bug 91999 proposes a way to reduce the cost of loading icons for menus
by doing all the image setting together.

It is posible thyat a similar technique could be used to address this
bug but I am not familiar enough with the code to evaluate that.
Comment 4 Mark McLoughlin 2002-09-12 03:29:45 UTC
Uggh. Well spotted Padraig.

Michael: you were looking into bonobo plug/socket size allocations
issues recently weren't you ? Does this ring any bells ?
Comment 5 Mark McLoughlin 2002-09-12 03:34:01 UTC
Michael: oh and is this related to #88499 - Federico's problems with
bonobo plug/socket size allocation with the eog control ?
Comment 6 Michael Meeks 2002-09-12 08:24:59 UTC
Not really; I'm waiting on a reply from Owen about how to proceed
here. My size_allocate change was only for in-proc, and essentially
ensures that we have the right size before being mapped which is
rather useful.

Owen: I'm talking about the "Re: Our size allocation issues" thread on
gtk-devel, 2 things really:

a) Should we be doing the plug/socket association at hierarchy-changed
time instead of realize time ?

and

b) If you make the (given) mods to testsocket/plug to simply realize
instead of 'show' the plug before associating, the plug is never shown
- I assume that's a bug, since you seemed to suggest that this is what
XEmbed was dsigned for ?

And finally - getting a size allocation of 1x1 is a relatively
'normal' thing, you need to avoid doing expensive layout / scaling for
anything < 2x2.
Comment 7 Mark McLoughlin 2002-09-13 04:59:41 UTC
Michael: this *is* an in-proc applet ...
Comment 8 Michael Meeks 2002-09-16 12:48:34 UTC
Well; there are several possible fixes;

Ultimately plain gtksocket gives you 3 size allocates;

a )from the 'toplevel' GtkPlug (inherited from GtkWindow), when it is 
shown.

Again - this is due to a bug in GtkPlug that means you have to show it
instead of just realizing it to associate it with a GtkSocket.
Comment 9 Michael Meeks 2002-09-16 12:53:28 UTC
Hit 'enter' and get a half cocked bug submission ...

b) Probably from the code to ensure that we do a correct size_request
during the GtkWindow's

size_request, size_allocate, realize, map 'show' sequence.

Since we associated plug/socket at 'realize' time - we have to do a
fresh size_allocate' in the realize step if we want any chance of an
in-proc plug to be the right size at map time.

Again - I'm waiting on Owen to see if we can do this better - at
hierarchy-changed time; Owen ?

c) No idea where this size_allocate is coming from, quite probably if
by the time we do b) size_allocation has not happened, then it can
happen later; however - quite why we should have an invalid size
request at realize time is unclear, unless there is some non-GtkWindow
parent or something.

Ultimately the solution is to get an answer from Owen on points a), b)
and c) will sort itself out I hope.

Owen ?

Of course - in the meantime, we could probably not propagate
size_allocates of < 1x1 in the in-proc bonobo workaround; that might
seem to provide a temporary 'As good as Gtk+ solution"; Federico ?
Comment 10 Owen Taylor 2002-09-16 18:23:38 UTC
I don't have time to look at this at the moment, sorry.
Comment 11 Vincent Untz 2002-11-07 18:05:17 UTC
Owen: did you find time to look at this ?
Comment 12 Owen Taylor 2002-11-07 19:42:59 UTC
No.
Comment 13 Luis Villa 2002-11-07 19:45:09 UTC
Apologies for the spam- I'm removing 'bugsquad' from some keywords via the web
interface. This is a one-time only thing before I re-add bugsquad via the SQL
interface, which will generate no mail. Apologies again.
Comment 14 Kjartan Maraas 2003-10-26 18:06:17 UTC
Have any of the fixes in the GtkPlug/Socket area the last year changed
the status of this bug?
Comment 15 padraig.obriain 2003-10-28 10:15:44 UTC
The only change is that InBox monitor is now an out-of-process applet.
However I can reproduce the problem with Clock applet, which is an
in-process applet.
Comment 16 Kjartan Maraas 2003-11-02 12:06:51 UTC
Removing bouncing address from Cc:
Comment 17 Michael Meeks 2003-11-05 09:52:09 UTC
Again, this is ultimately a bug in GtkPlug/GtkSocket. We try to do as
much setup as possible before the thing is mapped - and it's just
unfortunate that this gives 3 size allocates.

Why 3 size allocates is really a problem is beyond me.
Comment 18 Owen Taylor 2003-11-05 15:23:59 UTC
It might be nice if someone filed a GTK+ bug report with:

A) Non-bonobo, non-panel test case (take testsocket from the
   GTK+ distribution, add appropriate print statements)

B) A detailed analysis of when/why the size allocations occur.

Comment 19 padraig.obriain 2003-11-06 10:38:30 UTC
I cannot reproduce this problem using just GTK.

I had a quick look at the stack trace and I find it stranage that
gtk_plug_size_allocate is being called in gnome-panel when an
out-of-process applet is being added. I would have expected the plug
to be in the applet process.
Comment 20 Kjartan Maraas 2005-01-06 10:47:43 UTC
Is this still the same?
Comment 21 Sebastian 2015-08-22 23:17:49 UTC
gtk_plug_size_allocate was removed in GTK+3 commit: fe7bc84. So this can be considered as resolved.

See bug: https://bugzilla.gnome.org/show_bug.cgi?id=747553