I have a custom Bin, and I wish to divide its space into two columns of equal width separated by a VSeparator. I've tried using both a Table and an HBox, but it doesn't do the trick. I don't know how to tell gtk to divide the space evenly no matter what the contents of the two columns. Setting homogeneous to true works, but that also causes the VSeparator to get way too much space.
Related
I would like to add vertical blank space between two lines in a Modelica component GUI. I have (in this case), six similar looking parameters/comments within a group on a tab that I would like to visually break into two plus four by using a little space after the second one (essentially a blank line, but ideally I would have some control over the gap space).
I can put the last four in a separate group with no name, which gives a line in between the two/four. This is better than nothing, but not really what I want. I tried using groupImage, but it locates the image relative to whole group, so if it's smaller than the six entries, it doesn't affect them at all; and if it's larger, it introduces uniform spacing between all the entries, rather than just between 2/3.
A tree map can consist of the larger boxes and inside differing sizes of smaller boxes. Nothing I do in the shelf allows me to set two different measures sizes. I want my larger boxes to be proportional to my Total Population and the smaller boxes inside each to be proportional to my Utilization %. The three images I attached are my visualizations as well as one I found online that does exactly what I am trying to do.
In Tableau, you can only use one set of size per sheet.
I am struggling to get my grid to reliably display its column widths evenly when using api.sizeColumnsToFit().
I have configured my grid to resize the columns when the parent div/browser window resizes:
this.gridOptions = <GridOptions>{
onModelUpdated: () => {
this.gridOptions.api.sizeColumnsToFit();
},
onGridSizeChanged: () => {
this.gridOptions.api.sizeColumnsToFit();
}
};
This works, but the resulting column widths are more often than not uneven. Please see the first and second day of the month for week 13 below:
Any suggestions to make this more reliable will be very welcome.
Here is a plnkr with a possible solution for you. In essence here is what you could do:
var windowWidth = document.querySelector('#myGrid').offsetWidth - 170 - 17,
// calculate the window width minus any columns you don't want to size for
and a little magic number for the vertical scrollbar (17 was for chrome on mac)
sizableColumns = gridOptions.columnApi.getColumnState().map(e=>e.colId).filter(e=>e!='athlete'),
// get the colId of only the columns that you want to resize
sizableColumnWidth = Math.floor(windowWidth/sizableColumns.length);
// calculate the width of each column by dividing the available width by the number of columns
sizableColumns.forEach(e=>gridOptions.columnApi.setColumnWidth(e,sizableColumnWidth))
// iterate through the columns you want to resize and set their new column width
However, I think that you might be better off by considering how many users are going to be resizing their browser windows... not only that but resizing their windows slowly multiple times. Check these posts:
http://davidgoss.co/2014/04/15/users-do-resize-their-browser-windows-take-2/
https://medium.com/#stephenkeable/do-users-resize-their-browser-windows-or-is-it-just-developers-and-designers-e1635cbae1e1
Both of these posts indicate that roughly 2% of desktop users are resizing their browsers. And a much smaller portion will be resizing their browsers slowly multiple times. Perhaps you simply tell these <1% to not resize their browsers like they do, or allow for the columns to be manually sized so that if they do notice this odd behavior they can resize the columns themselves.
Technical Note:
Your reported behavior is happening because the algorithm to size the columns to fit is quite sophisticated. It takes into account the relative sizes of all the columns and widens them appropriately, so if you had 4 columns sized 100, 200, 100; and you resized the window, then the middle column will still appear as twice the size of the others.
The algorithm is also placing whatever is leftover in pixels to the first column so if you have 9 columns and 100px to fit it into, 8 columns would be sized at 11 px and one would be sized at 12. That way the columns will truly "fit" and not leave a few pixels not filled by columns (like my suggested option)
I would like to have a text box rescale with the level of magnification, such that one unit of text is always assigned one unit of horizontal axis-length. The text width should not change but rather the spacing between characters.
For instance, if the x-axis displayed [0:50], fifty characters should be displayed, one at each integer position. If the magnification was increased such that the display comprised only [0:10], only ten characters would be displayed, again placing one character at each integer position along the horizontal axis.
Finally, the text would ideally not display when the magnification level was below some threshold determined by the number of characters that can be legibly printed along a horizontal line spanning the extent of the axes.
I have tried using the text object, but it doesn't seem to have the relevant properties to allow such dynamic behavior. I have instead considered breaking the N-length string into N unit-length strings and placing each at a defined x-position, but I'm having trouble figuring out how to display only those relevant at the prevailing zoom level (there is some spill-over of characters beyond the bounds of the axis). In contrast, with this approach, all the characters appear as a jumble at zoom levels so low that the number of characters printed cannot be reasonably accommodated.
Thus, I inquire whether another solution besides printing a series of unit-length strings might be advised and, if not, how the twin problems of text spill-over and text overlap can be resolved at high and low zoom, respectively (the first might be done by somehow preventing printing of information outside the axes; the second seems to require some dynamic magnification-aware means of suppressing text output at or above a certain x-axis extent).
I'm using FreeType2 for font rendering, and I need to get a global bounding box for all fonts, so I can align them in a nice grid. I call FT_Set_Char_Size followed by extracting the global bounds using
int pixels_x = ::FT_MulFix((face->bbox.xMax - face->bbox.xMin), face->size->metrics.x_scale );
int pixels_y = ::FT_MulFix((face->bbox.yMax - face->bbOx.yMin), face->size->metrics.y_scale );
return Size (pixels_x / 64, pixels_y / 64);
which works, but it's quite a bit too large. I also tried to compute using doubles (as described in the FreeType2 tutorial), but the results are practically the same. Even using just face->bbox.xMax results in bounding boxes which are too wide. Am I doing the right thing, or is there simply some huge glyph in my font (Arial.ttf in this case?) Any way to check which glyph is supposedly that big?
Why not calculate the min/max from the characters that you are using in the string that you want to align? Just loop through the characters and store the maximum and minimum from the characters that you are using. You can store these values after you rendered them so you don't need to look it up every time you render the glyphs.
I have a similar problem using freetype to render a bunch of text elements that will appear in a grid. Not all of the text elements are the same size, and I need to prerender them before I know where they would be laid out. The different sizes were the biggest problem when the heights changed, such as for letters with descending portions (like "j" or "Q").
I ended up using the height that is on the face (kind of like you did with the bbox). But like you mentioned, that value was much to big. It's supposed to be the baseline to baseline distance, but it appeared to be about twice that distance. So, I took the easy way out and divided the reported height by 2 and used that as a general height value. Most likely, the height is too big because there are some characters in the font that go way high or way low.
I suppose a better way might be to loop through all the characters expected to be used, get their glyph metrics and store the largest height found. But that doesn't seem all that robust either.
Your code is right.
It's not too large.
Because there are so many special symbols that is vary large than ascii charater. . view special big symbol
it's easy to traverse all unicode charcode, to find those large symbol.
if you only need ascii, my hack method is
FT_MulFix(face_->units_per_EM, face_->size->metrics.x_scale ) >> 6
FT_MulFix(face_->units_per_EM, face_->size->metrics.y_scale ) >> 6