GNOME Bugzilla – Bug 682343
Close buttons overlap the screen edge
Last modified: 2012-09-01 11:24:33 UTC
Created attachment 221977 [details] screenshot See the attached screenshot - the new notification close buttons get clipped by the screen edge. Ideally there should always be some padding between the close button and the edge of the screen.
Created attachment 223111 [details] [review] boxpointer: Use the -arrow-rise as padding instead of a magic number
The problem with this bug is that padding is set from the boxpointer edge, and we use the same padding value for all boxpointers, whether they include padding or not. Also, in some cases, we want to keep the padding between a boxpointer and the screen edge to a minimum, such as in the case of iBus candidate choosers. Having the extra padding necessary to accommodate a close button would be unwelcome here. A solution to bug 680077 could possibly help with this.
Review of attachment 223111 [details] [review]: LG.
(In reply to comment #2) > The problem with this bug is that padding is set from the boxpointer edge, and > we use the same padding value for all boxpointers, whether they include padding > or not. We used to use the same padding value for all boxpointers -- hardcoded value of 10. What I am trying to do with this patch is to change it and make it use the -arrow-rise value, which is actually different for the keyboard-subkeys, popup-menu-boxpointer, summary-boxpointer classes. But yes, your point about the padding being set from the box edge and not from the close button is valid. However, I did not want to over-engineer things since using the -arrow-rise instead of a magic number "fixes" things in this case, and the comments in the code indicate that this should have been done in the first place anyway. > Also, in some cases, we want to keep the padding between a boxpointer and the > screen edge to a minimum, such as in the case of iBus candidate choosers. > Having the extra padding necessary to accommodate a close button would be > unwelcome here. The boxpointers for the candidate window use the popupmenu-boxpointer class, which has a -arrow-rise value of 11px, not too far from the earlier hard coded padding of 10. The summary items use the summary-boxpointer class, which has a much higher value of 18. So, what I am arguing is that this does not make things worse than they already were, but has the nice side-effect of fixing the overlapping close buttons.
commit 43caace1b6918890fd9b5893ffd2cf34406089a5 Author: Debarshi Ray <debarshir@gnome.org> Date: Sat Sep 1 00:49:14 2012 +0200 boxpointer: Use the -arrow-rise as padding instead of a magic number This makes sense if we want to follow what the following comment says: // We also want to keep it onscreen, and separated from the // edge by the same distance as the main part of the box is // separated from its sourceActor Using a magic number violates the "separated from the edge ... separated from its sourceActor" part. https://bugzilla.gnome.org/show_bug.cgi?id=682343