GNOME Bugzilla – Bug 135205
Text rendered below icon when panel size is 25 to 31
Last modified: 2005-08-15 01:42:55 UTC
The text is shown below and the panel bottom line cuts it. The text should go to right when panle size is < 32 in my case. I'm using vera sans 10 as desktop font.
Created attachment 24692 [details] [review] Use PangoLayout to determine pixel size of the text; tested and works.
Please add PATCH keyword (I'm not really sure about patch, please review before commiting, or letting me commit it).
Moving the priority to high and adding the PATCH keyword because of the patch.
Thanks for the patch i am investigating it right now. However one question, i am not really sure why you remove the gtk_label_new: ___ gtk_box_pack_start (GTK_BOX (gw_applet->box), gw_applet->image, FALSE, FALSE, 0); - gw_applet->label = gtk_label_new("0\302\260F"); + gtk_box_pack_start (GTK_BOX (gw_applet->box), gw_applet->label, FALSE, FALSE, 0);
the line gw_applet->label = gtk_label_new("0\302\260F"); is not removed, just moved above
Doh i overlooked the gtk_label_new that you've added. The patch looks good i am going to commit. Thanks a lot!. If you have time, you might want to check other applets on this behavior as well. Again, thanks. (lol we had a midair submit collision, i saw it before you commented ;))
One small problem, it doesn't work well on vertical panels yet.
You're right. IMO the code should check the panel orientation.
Yep, care to look into that ?
Sorry, but i dunno how to handle it.
I submitted Danilo's patch into CVS. It doesn't fix the complete problem but it fixes the most visible part of it seen most people use horizontal panels anyway. If someone cares to fix this on vertical panels as well that would be great, i am going to look into it this week if no one stands up.
Fixed in CVS head. Thanks for the patch, based the rest of the fix mostly on that!
I looked a bit more into this, and I see here one more problem: panel "normalizes" size upward to the values of 12, 24, 36, 48, 64, 80 and 128 (the relevant code is in gnome-panel/gnome-panel/panel-applet-frame.c). This means that applet receives the size of eg. 36 if vertical panel is 25-36px wide, or if horizontal panel is 25-36px high. So basically, the above "fix" compares the sum of 25+textheight, and with textheight rarely being less than 12px (Pango doesn't return the smallest bounding box, but distance from ascent to descent line), it seems to work. If you try it with a smaller font, you'll see that it doesn't go to the next line even if there's already enough space for that. What we'd need here is guaranteed minimum size of the panel instead (i.e. gnome-panel should round sizes downward, so 25px panel would send out the value of 24), and then this would be simple to fix (I already have a patch in place for this). Actually, perhaps not so simple, because then we'd need to get minimum bounding box of the pango layout instead. I files a separate bug report against gnome-panel under bug 135269.
Just to make myself clear: with your latest changes, it doesn't work correctly for eg. large fonts (text gets cut out for me when using Vera Sans 14) on both horizontal and vertical panels. So, this seems to be currently only a heuristic (which, indeed, works in most common cases), and the solution to go for, provided gnome-panel is not adjusted, is renormalize size one step back (i.e. if we receive 36, then we know that the size is 25-36, so we should normalize it at 25), and use that instead when comparing sizes.
I think it's quite stupid that the panel normalizes the sizes. Especially that it gives bigger sizes of panels that are let's say '25' big. I've filled a bug report for this in gnome-panel. I also encountered problems with other applets because of this normalizing.
Doh you've filled a bug about this as well. I'll mark mine as a duplicate.
Mark explained that there is a reason that panel does normalize and an applet should never use panel sizes. This seems to be because it's silly that a widget knows it's size before hand especially seen there might be a time that applets aren't bound to panels anymore but can also be used on the desktop... I agree with him here but the problem stays. How're we going to determine the space available.
Denis, Mark also suggested use of "size_allocate" signal. You may want to look at the default implementation (at least that's what this document says it is): http://developer.gnome.org/doc/GGAD/sec-widgetindetail.html From there, there's also a link to http://developer.gnome.org/doc/GGAD/sec-containers.html#SEC-SIZENEGOTIATION I don't have the time right now, but I may try using this instead of the "change_size" signal later on. Hope this helps.
I use size allocation in cvs right now. (you might want to check if i am not doing it totally wrong tho) However. It seems that the panel only emits change_size signal when it reaches the normalized sizes.
You may want to try setting up size_allocate signal handler for gw_applet: static void size_allocate_cb(GtkWidget *w, GtkAllocation *allocation) { GWeatherApplet *gw_applet = (GWeatherApplet *)w; place_widgets(gw_applet); return; } in gw_applet_create(): g_signal_connect (G_OBJECT(gw_applet->applet), "size_allocate", G_CALLBACK(size_allocate_cb), gw_applet); Unfortunately, this causes a segfault for me (I suppose it's because of non-reentrancy: signal is received once again while you're in the callback doing place_widgets which recreates the applet boxes, and thus reenters the signal handler), and I don't know how to debug this (how does one attach gdb to applets?). With "fprintf debugging", it seems that weather_info is messed up at the time of second and following runs (I used static variable to track the number of calls), and that is where it segfaults. Since I have no idea how to proceed from this, I pretty much gave up (unless I find some more spare time). If you can get it to work, it would be very nice, and it would probably help with cleaning up other applets.
You can attach gdb to applets by going to console run the applet in gdb and then add the applet from the menu. A new instances will be loaded in the running proces. Thanks for helping out btw!
*** Bug 120823 has been marked as a duplicate of this bug. ***
Should we change the patch status to "obsolete" or "needs work"?
Comment on attachment 24692 [details] [review] Use PangoLayout to determine pixel size of the text; tested and works. Patch labeled as "committed" due to comment 11 as this was included in CVS.
Created attachment 29107 [details] [review] patch to round down panel size The attached patch rounds the "panel_size" down to the lower normalised value. For example if the panel claims to be of size 36 (which actually means anything from 25 to 26) the size used to work out the layout will now be 24. The trade off for doing this is that the panel has to grow to the next normalised size before the applet will split into 2 lines or columns. However, this does completely eliminate (at least with my setup) the problem of the panel chopping off half the temperature text.
Created attachment 29127 [details] [review] patch that makes gweather applet follow the real panel size This patch uses the size_allocate signal to get the *real* panel size, as suggested in bug #135269. This makes the applet follow the panel size consistently, with no need to comparison or rounding to fixed sizes. It follows the suggestion of comment #20, with an added comparison to stop the recursion when the applet is the same size as the panel. Anyway, it works.
It works for me also. The only thing I'd suggest is changing the name of the callback function to size_allocate_cb so it matches the name of the signal. Dennis, okay to commit?
Please commit Gareth! (sorry for my absense lately, real life is taking too much time)
Thanks Vincent, the patch has been commited.