I'm currently in a tmux window (v1.9a) with six panes, arranged in 2 columns and 3 rows. I built this window with % (5x), then M-5 for the arrangement. q shows the following numbering:
0 | 1
2 | 3
4 | 5
The setup works well for the most part, but when switching panes with the arrow keys, tmux seems to group the rows and remember the last pane.
Example: I'm in pane 3, I press C-b, Up, Left, to get to Pane 0. Now I press C-b, Down, to get to Pane 2, but it brings me to 3, since that's the last pane I was in on that row.
Is there some "absolute down" mapping I could create? Or a "remember pane" setting I could disable?
Related
To simplify data entry in the field, i.e. using tablets, I would like to create buttons in a spread sheet that will add or subtract values to or from the selected cell. Using spin buttons is not an option, as I would have to add hundreds of these buttons. This answer shows exactly what I'm looking for, i.e. a single set of floating buttons that will move relative to the selected cell.
Unfortunately, VBA-macros will not run in an android environment, so I need to find a solution in a StarBasic based software, e.g. LibreOffice. I'm aware that questions related to porting VBA to SB are not very popular, but my programming experience is solely limited to R and I'm at a loss on how to solve this. I've boiled down the VBA-code to the bare essentials:
Sub Worksheet_SelectionChange(ByVal Target As Range)
With ActiveSheet.CommandButton
.Left = Target.Offset(, 2).Left
.Top = Target.Offset(0).Top
End With
End Sub
Sub CommandButton_Click()
ActiveCell.Value = ActiveCell.Value + 1
End Sub
Any help in porting, or creating a new SB-macro from scratch will be much (!) appreciated.
I still ask you to try the scrollbar again. Just please change your attitude to it - take it not as a control, in which you need to move the slider to the right and left, but as a set of four buttons. Don't move, just tap
In my example, the properties of the control "Large change" set to 10, this is the default. You can change this to 5.
My macro has Const MAX_STEP = 20. You can change this to 10.
And you get buttons to only having +/- 1, +/- 5 and +/- 10
If the size of the control is not large enough to get into the necessary parts with your finger, then change the oSBar.setSize() in the code to your liking. Or just increase the zoom of the leaf, as I did when I was recording the GIF.
I have a typical FastReport report with a table inside of a MasterData band. The table is pretty lengthy and narrow, so I'm thinking about splitting it in half and placing the lower half next to the upper half like so:
A A D
B B E
C -> C F
D
E
F
There's a catch - rows on the table are 1-3 lines tall.
I have tried using MasterData.Columns property. Two problems with it are: it splits the table by-row, making it AB CD EF, which is not acceptable, also it does not account for row heights, so if for example row A is taller than others, then there's unwanted gap after D on the second column (despite the StretchMode = smMaxHeight).
My FastReport version is 4.7.
FastReport has two ways to make a column report.
You already discovered one of them "band columns" - this method prints band from left to right and then down.
The second way is a page columns.
With Page column FR prints band till the end of the page and then moves to next column. I think this method exactly what you are looking for.
To make a page columns just double click on the page in the report designer, select other options tab and set the number of columns you want to print.
Consider the following python script
#!/usr/bin/env python
from Tkinter import Tk, Label
width = SOME_VALUE_HERE
root = Tk()
label1 = Label(root, text='1 columns wide')
label2 = Label(root, text='%i columns wide' % width)
label1.grid()
label2.grid(row=0,column=1,columnspan=width)
root.mainloop()
When I run this, no matter what value is set for 'SOME_VALUE_HERE', both labels take up half the window, regardless of whether or not Grid.columnconfigure is called, or the sticky parameter is used in grid().
Unless I've overlooked something, I would have thought that setting the columnspan would force the second label to be 'SOME_VALUE_HERE' times as wide as the first.
Have I misunderstood how grid works? How would I go about achieving this behavior?
By default, empty grid column are zero width, so you described the following table. Grid geometry manager will by default try to optimize the screen real estate used by your application. It will integrate all the constraint and produce the fittest layout.
+---------------+---------------++++
| 0 | 1 |||| <-- 2,3,4 empty, 0 width
+---------------+---------------++++
| 1 column wide | 4 column wide |
+---------------+---------------++++
To provide strict proportional column width, you have to use the uniform option of columnconfigure. uniform takes an arbitrary value to designate the group of the column that share these proportions, and the weight argument is used to properly handle widget resizing.
label1.grid(row=0, column=0)
label2.grid(row=0,column=1, columnspan=width)
for i in range(width+1):
root.grid_columnconfigure(i, weight=1, uniform="foo")
Note that with only these two labels, you could achieve the same layout by adjusting the width of column 1. Differences will occur still while you populate column 2,3,4...
label2.grid(row=0,column=1) #no columnspan
root.grid_columnconfigure(0, weight=1, uniform="foo")
root.grid_columnconfigure(1, weight=width, uniform="foo")
When you put something in column 1 with a columnspan of two (or more) that means it will be in column 1 and column 2 (etc). However, if there is nothing controlling the width of a column, that column will have a width of zero. You need to force column 2 to have a widtheither by putting something in there, giving it a minsize, or forcing uniform columns.
When I look at your code, I can't guess how wide you think column 2 should be, and neither can the computer.
I had a similar problem only to discover that the elements are limited by the widest widget. We can safely say that Tkinter is configured to make your app uniform in that it should be a regular repeating square/triangular structure. Solution to override default options.
With the Tkinter's automatic optimization in mind, play with the width and height of largest widget (grid box) and relate the other boxes to it proportionally.
Using the above method use columnspan to adjust the width.
Configure the widths by use of columnconfigure()
Not sure how to describe this exactly but here goes:
I have a 3 column design, and there is a list of items in each of the columns.
I need to have:
1) Each column's list items must aligned so that the left side of each word lines up
2) Each list itself must be centered within its column. (This of course means that list items on their own won't necessarily be dead center inside their respective column)
I would prefer a CSS solution without javascript/jQuery.
I have an example of bootstrap code that I am working on here to help explain what doesn't work for me:
http://bootply.com/112003
The first row is what happens when the text is centered within each column. Condition 2 passes, condition 1 fails.
The second row is what happens when I divide up each of the three colums into 3 subcolumns. Condition 1 passes, but condition 2 fails. This is subtle. While each list item is in the center subcolumn, overall the list isn't in the dead center of that column. (Imagine the list is one item if that helps think about the problem.)
Thanks to anyone who can try to help me out. This one is driving me a little bit crazy :)
I have found something NOT funny with rectangles:
Lets say, given are values of left, top, right and bottom coordinates and all those coordinates are intended to be inclusive.
So, calculating the width goes like:
width = right - left + 1
So far, so logical. But!
A width of zero (which makes sense, sometimes) would have to be stored as:
right = left - 1
which makes problems, when it comes to the following operations:
Sorting the rectangle coordinates (to make it go left to right, top to bottom)
Looping
Ok, of course those things can be handled with extra code for the special case of Width == 0, but, seriously, is there no better solution, no standard pattern or best practice to handle this?
Edit:
For the time being I have abandoned the "sorting" of the coordinates in my code and replaced it with an assertion stating that the rectangle must be left -> right, up -> down, but seriously...
To address this problem, most graphics libraries will draw rectangles from the left coordinate up to but not including the right coordinate. So if left=10 and right=20, then the ten pixels 10 through 19 will be drawn.
You can think of this as the pixel coordinate referring not to the lit-up portion, but the grid lines between pixels.
+---+---+---+
| | | |
+---+---+---+
| | | |
+---+---+---+
^ ^ ^ ^
0 1 2 3
It's important to distinguish between coordinates and pixels. You can think of the coordinate system as being an invisible grid which runs between pixels. Thinking of coordinates this way if you define a rect as { 0, 3, 0, 5 }, then you get 3 pixels by 5 pixels as expected.
| | | | | |
0 -x--+--+--+--+--x-
| | | | | |
1 -+--+--+--+--+--+-
| | | | | | <- pixels are rectangular areas between coordinate grid
2 -+--+--+--+--+--+-
| | | | | |
3 -x--+--+--+--+--x-
| | | | | |
0 1 2 3 4 5
If the edges (left, right, top, bottom) are inclusive then, by definition, the width (and height) of the rectangle cannot be 0. By "including" the side (which is a pixel), you're saying that it has to be at least 1 pixel wide.
Saying that
all those coordinates are intended to be inclusive
means that there actually are two distinct rectangles, one within another. That's where you get caught: when you write
width = right - left + 1
it really means:
inner_width = outer_right - outer_left + thickness
where thickness is the distance between corresponding sides of inner and outer rectangles.
So, to deal with the problem in abstract mathematical sense, you have to consider two rectangles instead of one.
Of course you can find a workaround for this, but what really is the problem here is going out of scope.
Your scope is a rectangle, and even if a width of zero would come in handy : there is no such thing as a rectangle with width zero.
Normally all functions have contracts and a predcondition of a functions that says docalculation(par_rectangle) is that par_rectangle in fact is a rectangle.
If you need a retangle-like object wich can be width zero, you first need to define it waterproof, and never just assert that rules for rectangles will apply on your definiton.