I am using a plugin that prints useful info in some grid (see picture below). However, due to the resolution of my laptop (2880x1620) I see nothing - the row height is too small. Is there a way how to increase this row height? I do not want to decrease font size as that would be almost unreadable.
Related
The column header text showed properly when I first installed workbench 6.3. (on Win 10).
I recently set something... think increased the font size, and the titles increased, however it looks like this (screen shot below).
How do I increase the height to fit the increased font size?
Apparently, I can't even get it back to previous state. Tried reducing the fonts size, it doesn't seem to work.
I am implementing a container which algins its children in a row and does kind of a linebreak when there is no horizontal space left. Thus, the required height depends on the available width. For larger widths, more content fits in one line and less lines are needed leading to less height. For smaller widths, less content fits in one line and more height is needed.
I subclassed the container and implemented the needed logic. The minimum width of the container is set to the minimum width of the widest child which would display one extreme case where there are stacked lines, some of them with only a single child inside them.
The problem is as follows: The window displaying the container has a very large height, for some cases even larger than my monitor. I am able to resize the window except that I cannot decrease the width. It turns out that the documentation for height-for width geometry management says:
Next, the toplevel will use the minimum width to query for the minimum height contextual to that width using gtk_widget_get_preferred_height_for_width()[...]. The minimum height for the minimum width is normally used to set the minimum size constraint on the toplevel (unless gtk_window_set_geometry_hints() is explicitly used instead).
Thus, the behaviour is expected as the window uses the height for the minimum width as its minimum height leading to the previously mentioned extreme case. This seems to be counterintuitive as in my case and an example used in the documentation (textflow in labels) the height will be maximal when the width is minimal vice versa. Only when actually allocating the available space, gtk considers to assign smaller heights when a larger width allows that. Even when using high widths in the window's default size and size request only the minimum width of the container is considered to derive the required height of the window.
The documentation already somehow contains a workaround, namely the geometry hints. But this seems to be a verbose and static way of sizing the window when the default width of the window together with the height-for-width-function could theoretically be used to easily determine the size of everything. The size-allocation already works as intended, only the size-negotiation cancels the benefits the height-for-width function could bring here. Is there any nice way of implementing the functionality required to fix the window sizing?
It seems as there is no intended workaround for this problem the way I searched for. The gtk size negotiation goes from bottom to top when requesting sizes and top to bottom when allocating. Thus, my container has no way of knowing how much width its parent could assign to it.
I solved the problem by adding a property which defines the minimum of children per row. This can be used to increase the minimum width and therefore decrease the minimum height. I only use it for the minimum width calculation while actually ignoring it doing the real size allocation which only is a minor detail I will document.
This documentation will be part of the code example I will provide as an answer to my old post which was about implementing a FlowBox with the behaviour described above.
I'm using GTK3+ (3.22) on Ubuntu server 18 (beta2) / x11 / openbox. Language is C. I'm porting an embedded application from GTK2 which did not seem to do dynamic resizing of label widgets when the text content reached a certain limit.
On GTK3 the label (and button) widgets now seem to resize when the text content is close to the maximum size that can be displayed.
In the case of a button widget placed into a FIXED container on a window. I have tried the following...
The gtk_widget_set_size_request seems only to set a default or minimum, not a max:
gtk_widget_set_size_request( GTK_WIDGET( GuiBottomFarLeftButton ) , GuiBottomButtonWidth , GuiBottomButtonHeight );
I have tried gtk_widget_size_allocate but that doesn't seem to limit the maximum size.
GtkAllocation gtkallocTestSize = { GuiBottomButtonFarLeftX , GuiBottomButtonY , GuiBottomButtonWidth , GuiBottomButtonHeight};
gtk_widget_size_allocate( GTK_WIDGET( GuiBottomFarLeftButton ) , >kallocTestSize );
There does not appear to be a gtk_widget_... function that limits the maximum size or sizing behavior that I can find. So far I have not found a way to limit the maximum size of a specific widget. I would settle for a way to limit the maximum width as the vertical size of the controls seems to behave as it did under GTK2 in the application I'm working on. In most cases the resizing is only effecting the layout by 10 to 20 pixels but this creates a really bad user experience.
Is there a way to disable the resizing on a widget or limit it's maximum size? Or some other work around that actually functions on latest GTK3+ (3.22)?
UX is a hard balance of optimisation. In general you should not assume that the gtk2 behaviour is what you want to replicate. The body of knowledge re: UX has increased since then and changes are in general positive. You will either be clipping text, decreasing font sizes or oversizing widgets. You can't have it all.
Scrolled windows help in many cases but obviously not for buttons and labels. In this case it is best to keep text short and use tooltips for anything that needs a more lengthy explanation.
I'm trying to create MATLAB figures to put into a paper. The paper has very specific sizing instructions for figures that I'm having trouble matching in MATLAB. The figures need to be no greater than 3.5" width, >300 DPI, with 8pt font.
In my code, I use the following to try to set the parameters:
set(gcf,'PaperUnits','inches');
set(gcf,'PaperPosition',[0 0 3.5 3.5]);
xlabel('x-axis label','FontSize',8);ylabel('y-axis label','FontSize',8);
set(gca,'FontSize',8);
print('-djpeg','-r300','filename.jpg')
This should be giving me a 300 DPI, 3.5"x3.5" JPEG image with an 8pt font size. However, when I import the image into Word, it becomes 6.5" x 6.5" and the font size is larger than Word's 8pt font. Even if I resize the image, the font size is still too large, though it should maintain the same DPI. Are the FontSize and PaperPosition parameters not working as I expect they should or is Word doing something strange for importing?
The font size issue was caused due to differing fonts used in MATLAB and Word. Once I learned about set(gca,'FontName'), the font size seemed to be correct when the image was manually resized to 3.5" x 3.5".
The image size issue seemed to be related to saving it as a JPEG. Once I swapped to PNG, the image was the correct size by default. Looking into the JPEG properties, it had the correct number of pixels for a DPI of 300 at 3.5", the sole issue was that it would have to be manually resized. Thanks for the comments that led me to finding a solution.
I need to include many images of unknown origin in a report. I have no idea what the images might be: portrait or landscape fotos, large or small, or even something with an atypical shape, like a 400x80 logo.
I'd like to scale down images with the following rule: proportionally downscale until the larger side is 200. And resulting image shouldn't take more space than needed (i.e. 1000x600 should be downscaled to 200x120, not to 200x200), so that there are no unneeded blank margins around non-square images.
Is what I need possible with JasperReports?
EDIT:
To clarify: "real size" mode is almost what I need. However, I don't see a way to limit height of resulting image. As a result, if the image I want to print is a portrait foto (or has even larger height compared to width), generated PDF looks ugly; in this case I would prefer to somehow downscale it to a smaller width.
I solved the Problem of resizing images of various sizes to a fixed size with "RetainShape" by writing an ImageResizer, based on the idea of the ImageTransformer from https://stackoverflow.com/a/39320863/8957103 , using https://github.com/rkalla/imgscalr for scaling the image.