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 135269 - gnome-panel rounds applet size upwards
gnome-panel rounds applet size upwards
Status: RESOLVED NOTABUG
Product: gnome-panel
Classification: Other
Component: panel
2.5.x
Other Linux
: Normal normal
: ---
Assigned To: Panel Maintainers
Panel Maintainers
: 135411 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2004-02-24 08:15 UTC by Danilo Segan
Modified: 2004-12-22 21:47 UTC
See Also:
GNOME target: ---
GNOME version: 2.5/2.6



Description Danilo Segan 2004-02-24 08:15:21 UTC
The problem seems to be in gnome-panel/gnome-panel/panel-applet-frame.c.

This is where applet size is normalized *upward* to values of 12, 24, 36,
48, 64, 80 and 128. This means that applets will receieve value of "36" if
panel size is 25px.  I believe it would be better to normalize downward,
i.e. make this size a guaranteed space that *is* available.  If I'm not
clear, the patch below would fix that.

--- panel-applet-frame.c.~1.116.~       Fri Jan 23 11:17:34 2004
+++ panel-applet-frame.c        Tue Feb 24 09:07:18 2004
@@ -397,12 +397,12 @@
        /* Normalise the size to the constants defined in
         * the IDL.
         */
-       size = size <= PANEL_SIZE_XX_SMALL ? PANEL_SIZE_XX_SMALL :
-              size <= PANEL_SIZE_X_SMALL  ? PANEL_SIZE_X_SMALL  :
-              size <= PANEL_SIZE_SMALL    ? PANEL_SIZE_SMALL    :
-              size <= PANEL_SIZE_MEDIUM   ? PANEL_SIZE_MEDIUM   :
-              size <= PANEL_SIZE_LARGE    ? PANEL_SIZE_LARGE    :
-              size <= PANEL_SIZE_X_LARGE  ? PANEL_SIZE_X_LARGE  :
PANEL_SIZE_XX_LARGE;
+        size = size >= PANEL_SIZE_XX_LARGE ? PANEL_SIZE_XX_LARGE :
+              size >= PANEL_SIZE_X_LARGE  ? PANEL_SIZE_X_LARGE  :
+              size >= PANEL_SIZE_LARGE    ? PANEL_SIZE_LARGE    :
+              size >= PANEL_SIZE_MEDIUM   ? PANEL_SIZE_MEDIUM   :
+              size >= PANEL_SIZE_SMALL    ? PANEL_SIZE_SMALL    :
+              size >= PANEL_SIZE_X_SMALL  ? PANEL_SIZE_X_SMALL  :
PANEL_SIZE_XX_SMALL;
                 
        bonobo_pbclient_set_short (frame->priv->property_bag, 
                                   PROPERTY_SIZE,

Please see bug which demonstrates the problem with gweather applet:
http://bugzilla.gnome.org/show_bug.cgi?id=135205


Also, is there any particular reason why this kind of behaviour was chosen
in the first place (I don't want to have this changed if it might damage
something)?  Did I miss any place where this size bigger than real applet
size is actually useful (not taking into account some possible workarounds
employed in some applets -- basically, applets would need to go one
"normalization step" back, from x_small to xx_small, etc.)?
Comment 1 Mark McLoughlin 2004-02-24 08:23:46 UTC
The reported "size" is not what you think it is. Its only a hint. Not
a very useful one and something that wouldn't exist if I had a chance
to design this API again.

What you want is to respect the size allocated to the applet. You
probably also want to set the EXPAND_MINOR flag so the applet will be
allocated the full with of the panel.

I know the libpanel-applet docs aren't very good, but they do have
something on this - at least in CVS:

From panel_applet_get_size():
"
Note: The return value is <emphasis>not an integer value
specifying the pixel size of the panel.</emphasis> Do not
use this value to calculate the size of the applet. Use it
only as a hint by which to decide the applet's layout.
"
Comment 2 Danilo Segan 2004-02-24 09:05:27 UTC
Thanks for the explanation (and tips) Mark.  (Though, I'd still prefer
it if this hint presented *minimum available size* one can be sure
about -- I cannot imagine a layout problem where the current hint of
"you have at most this much space, but you could have some hardcoded
value [12/16/48] less" would be more useful).
Comment 3 Mark McLoughlin 2004-02-24 09:11:15 UTC
Danilo: just don't use this API, its not useful. The numbers aren't
supposed to represent *anything* anymore, just the "small", "medium",
"large" identifiers etc.
Comment 4 Danilo Segan 2004-02-24 09:33:44 UTC
I'm not using it for anything new, it's the problem that many applets
in gnome-applets are currently using it (modemlights seems to do so as
well, since it gets screwed up when panel size is 25-35), and I was
trying to fix some of those bugs.
Comment 5 Mark McLoughlin 2004-02-24 09:40:20 UTC
The fix is to make them not use it :-)

Sorry, that's the only sensible approach to take ... :/
Comment 6 Dennis Smit 2004-02-25 17:41:14 UTC
*** Bug 135411 has been marked as a duplicate of this bug. ***
Comment 7 Dennis Smit 2004-02-25 17:43:19 UTC
Mark could you give a suggestion how we should check for panel sizes ?

We >NEED< the exact panel size for quite a few applets for alignment of
their widgets. Using the panel_applet_get_size and the size signal
doesn't work because of the size normalisation. I really think that
these should return the REAL panel size. Or atleast we need something
that gives us the panel size.
Comment 8 Mark McLoughlin 2004-02-25 17:46:49 UTC
as I said above - size_allocate and EXPAND_MINOR are your friends.

This is NOTABUG. Don't re-open it.
Comment 9 Dennis Smit 2004-02-28 11:54:05 UTC
Mark, i am now retrieving the applet size by using the 
allocation however another problem popped up. It seems that
the panel only emits change_size signal on the normalized
values.