awesome

Welcome to awesome bug tracking system.
Tasklist

FS#926 - Remove 1px border to make scrollbars more easily clickable

Attached to Project: awesome
Opened by Jeff Turner (jefft) - Saturday, 17 September 2011, 05:58 GMT
Last edited by Uli Schlachter (psychon) - Saturday, 17 September 2011, 10:51 GMT
Task Type Feature Request
Category Core
Status Unconfirmed   Reopened
Assigned To No-one
Operating System Linux
Severity Low
Priority Normal
Reported Version 3.4.10
Due in Version Undecided
Due Date Undecided
Percent Complete 0%
Votes 0
Private No

Details

To the right of scrollbars, there is a 1px border. It seems to have no purpose in a tiling WM and prevents me from being able to just yank the mouse to the edge of the screen and click on the scrollbar in a maximized application.

If this border is the WM's doing, I suggest getting rid of it.
This task depends upon

Comment by Jeff Turner (jefft) - Saturday, 17 September 2011, 10:04 GMT
You know how users sometimes abuse bug trackers by asking "How do I.." questions that should really be asked in forums? This is an example of an opposite abuse: developers treating valid bug reports as questions to be answered, and closing them at the first workaround.

In this case there is a clear usability problem, which happens to be in the default theme. If the default theme is considered part of the project, then this is indeed a bug, and the correct solution would be to fix the theme. Providing a workaround does not fix the problem for anyone except the reporter. Closing bugs because there is a workaround is simply robbing the project of feedback. See also Joel Spolsky's "Fix everything two ways" point at http://www.joelonsoftware.com/articles/customerservice.html

Of course it's your prerogative how you use/abuse this bug tracker, so feel free to ignore the above.

Thank you for the suggested workaround; unfortunately it doesn't actually work (at least in 3.4.9).
Comment by Uli Schlachter (psychon) - Saturday, 17 September 2011, 10:55 GMT
Hm, it really should work (tm), no idea what might be wrong.
Well, ok, let's try something else:
How are you fullscreening the client? If you have the default config keybindings: Are you using "fullscreen" (mod+f) or "maximized" (mod+m)? Fullscreen should remove all window border automatically (at least it does so in git/master, not sure about the 3.4 branch).

The difference between fullscreen and maximized is that fullscreen covers the *full* screen, while maximized leaves the wibox (tasklist etc) visible.

In my own config I have some stuff which tries to remove borders if a single client is covering everything...
Comment by Jeff Turner (jefft) - Saturday, 17 September 2011, 12:42 GMT
Testing some more, I think the problem is client-specific. I am using the /etc/xdg/awesome/rc.lua that Ubuntu provides, and one of their changes vs. git/master is to set the terminal to gnome-terminal instead of 'xterm'. gnome-terminal has the 1px border. Of the other apps I've tested:
- Chrome doesn't have a border maximized or fullscreen.
- nautilus doesn't have a border maximized or fullscreen.
- urxvt and xterm (specifically 'xterm -sb -rightbar') have a border maximized, but not fullscreen.
- firefox has the border maximized and fullscreen.

So I don't know; can the WM do anything about this? Or is this one of those typical screwed up Linux/X situations where nobody can agree on a standard behaviour, and each library does things differently?
Comment by Uli Schlachter (psychon) - Saturday, 17 September 2011, 12:59 GMT
There is a border width option that the WM can influence. Running "xwininfo" in a terminal and clicking on a window will tell you the value for that option ("Border width:").
Comment by Jeff Turner (jefft) - Saturday, 17 September 2011, 13:56 GMT
That's interesting; the problem is not the border, which is 0, but the window width, which varies by application, sometimes 1080 and sometimes 1078:

[jturner@jturner-desktop ~ ]$ xwininfo

xwininfo: Please select the window about which you
would like information by clicking the
mouse in that window.

xwininfo: Window id: 0x80001c "Terminal"

Absolute upper-left X: 0
Absolute upper-left Y: 28
Relative upper-left X: 0
Relative upper-left Y: 28
Width: 1078
Height: 1891
Depth: 24
Visual: 0x21
Visual Class: TrueColor
Border width: 0
Class: InputOutput
Colormap: 0x20 (installed)
Bit Gravity State: NorthWestGravity
Window Gravity State: NorthWestGravity
Backing Store State: NotUseful
Save Under State: no
Map State: IsViewable
Override Redirect State: no
Corners: +0+28 -2+28 -2-1 +0-1
-geometry 106x98+0-1

[jturner@jturner-desktop ~ ]$ xwininfo

xwininfo: Please select the window about which you
would like information by clicking the
mouse in that window.

xwininfo: Window id: 0xe00047 "New Tab - Google Chrome"

Absolute upper-left X: 0
Absolute upper-left Y: 28
Relative upper-left X: 0
Relative upper-left Y: 28
Width: 1080
Height: 946
Depth: 24
Visual: 0x21
Visual Class: TrueColor
Border width: 0
Class: InputOutput
Colormap: 0x20 (installed)
Bit Gravity State: NorthWestGravity
Window Gravity State: NorthWestGravity
Backing Store State: NotUseful
Save Under State: no
Map State: IsViewable
Override Redirect State: no
Corners: +0+28 -0+28 -0-946 +0-946
-geometry 1080x946+0+28


Additionally I found that Firefox's width is 1080 but its 1px border to the right of the scrollbar is theme-dependant:

https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/125734
Comment by Gregor Best (farhaven) - Sunday, 18 September 2011, 08:46 GMT
Does it work if you tell awesome to ignore client window size hints (There should be a line in the manage hook along the lines of honor_size_hints, commenting that out should do the trick)? If that's the case, you could either live with e.g. terminals being resized to funky sizes (such as the "terminal" area of them being something and a half letters high) or add a rule that tells awesome to only ignore gnome-terminal via the callback= mechanism.
Comment by Jeff Turner (jefft) - Sunday, 18 September 2011, 23:23 GMT
Thanks, Gregor, size_hints_honor (following the FAQ advice[1]) did remove the border for urxvt and xterm. It didn't for gnome-terminal (see attached blown-up screenshot) or firefox, but I suspect their borders are set in the application or GTK, not the window manager.

[1] http://awesome.naquadah.org/wiki/FAQ#How_to_remove_gaps_between_windows.3F
Comment by Jeff Turner (jefft) - Monday, 19 September 2011, 00:14 GMT
Sorry, it does actually fix gnome-terminal too, despite the visible border. So in summary, getting easily clickable scrollbars requires setting theme.border_width = "0" in the theme, and size_hints_honor = false in the properties section of awful.rules.rules in rc.lua.

I don't suppose these these are changes that can be made in the default configuration?
Comment by Uli Schlachter (psychon) - Monday, 19 September 2011, 07:00 GMT
size_hints_honor = false is an ICCCM violation (and some clients, e.g. urxvt handle it badly) and border_width = 0 makes it harder to see which client has the input focus since that's indicated by the border color.

But fullscreen clients already should be ignoring size hints and a border doesnt really make sense for them either, so that can be done only while the client is fullscreen'd (in fact, I thought we were already doing so...)
Comment by Gregor Best (farhaven) - Monday, 19 September 2011, 08:39 GMT
Maybe we could add a rule for gnome-terminal to the default config. That way, new users see how to escape the '-' character in the class name, they see how callbacks work and they see how one can set simple window properties with rules.

Loading...