aboutsummaryrefslogtreecommitdiff
path: root/gdb/python/lib
diff options
context:
space:
mode:
authorAndrew Burgess <aburgess@redhat.com>2022-01-31 12:13:38 +0000
committerAndrew Burgess <aburgess@redhat.com>2022-04-03 15:31:46 +0100
commit44aad371013c6275bae2ee580d26b0d44de2b228 (patch)
tree3b7714d4b6c7bc2c29a79c8ca3d730f14d6d2061 /gdb/python/lib
parent7421ccda7640f53d4096a51402ae28daa6c816c0 (diff)
downloadbinutils-44aad371013c6275bae2ee580d26b0d44de2b228.zip
binutils-44aad371013c6275bae2ee580d26b0d44de2b228.tar.gz
binutils-44aad371013c6275bae2ee580d26b0d44de2b228.tar.bz2
gdb/tui: add left_boxed_p and right_boxed_p member functions
When I initially saw this code in tui_layout_split::apply, I assumed that this must be a bug: /* Two adjacent boxed windows will share a border, making a bit more size available. */ if (i > 0 && m_splits[i - 1].layout->bottom_boxed_p () && m_splits[i].layout->top_boxed_p ()) ... After all, the apply might be laying out a horizontal layout, right? So checking bottom_boxed_p and top_boxed_p is clearly wrong. Well, it turns on, that due to the implementations of these things, bottom_boxed_p is equivalent to an imagined right_boxed_p, and top_boxed_p is equivalent to an imagined left_boxed_p. In this commit I've renamed both top_boxed_p and bottom_boxed_p to first_edge_has_border_p and last_edge_has_border_p respectively, and extended the comments in tui_layout_base to mention that these methods handle both horizontal and vertical layouts. Now, hopefully, the code shouldn't look like it only applies for vertical layouts. There should be no user visible changes after this commit.
Diffstat (limited to 'gdb/python/lib')
0 files changed, 0 insertions, 0 deletions