Both methods are not documented both and does not seem to behave as I would expect.
mylabel.setFontScale(3f); makes the apparent text 3 times larger (what I'm looking for) but does not center properly when using it with Align.center.
mylabel.setScale(3f); does nothing as far as I could see.
What is the difference between those 2 methods and what one should I use to make my label bigger and properly centered ?
setFontScale() indeed enlarges the font, this is often unwanted since scaling up pixelizes the font.
label.setScale() does work if you are not using a layout actor like a table. When actors go inside a layout then the layout is responsible for setting the sizes and position. For example, you have control over this once you put it inside a table cell.
table.add(myLabel).width(300).height(80).padLeft(100).expandX();
Detailed documentation on working with a table.
This however just sizes the label, not the text inside. You can still do setFontScale(3f) but this will pixelate the font. You have 2 better options:
create a extra bitmap font in Hiero 3 times larger.
Use Gdx.Freetype to import a .ttf and generate fonts on run-time.
Related
Whenever I test these accessibility settings with a larger display size or font size, it seems to almost always break parts of my layout and make it look awful. I really like the feature of autosizing text but these settings being changed seem to making autosizing text useless. Changing the display size also creates issues like weird holes in my table rows for reasons I can't figure out. Weighted views seem to break down in how they should work as well.
I have seen there are a couple of ways to work around these settings and making it so that the user's preferences of these settings do not affect your app. Do you all do this?
I understand the utility of the settings for the users. But, it seems kind of arbitrarily implemented because in order to make the layout work with these settings as a developer you might have to make your text size smaller from the beginning (in order to fit a larger font if user chooses to do this), which would lead to the exact same text size you, as a developer, would have chosen in the first place if you weren't trying to accommodate a larger font size being able to fit. I also believe I have heard that IOS doesn't allow for these accessibility settings to affect third party apps.
I am just curious how you all go about dealing with this. Thanks.
It is possible to ignore the user's preferred font sizing, by using dp instead of sp. Same for display size, if you really want to, you could check the current density and draw something according to that, still sizing things smaller. That's not a good approach. While your layouts will not break that way, the user who prefers a larger font/display sizes will still not be able to use your app, as they need a bigger text size.
There are some different techniques you can use to make layouts scale better:
Use minHeight/minWidth attributes in layouts, instead of hardcoding the sizes of the views.
Check that the constraints in constraint layouts are bound in both directions, not just start.
Allow text views to take up multiple lines, add ellipsis option where user can click through to see more information.
I wrote a blog post covering some of these in a bit more detail: Accessible Text Scaling for Android
Sometimes, however, fixing it for all scenarios will involve rethinking the design.
For iOS, the font settings also affect all third-party apps, it's not just an Android thing.
In general, you should always used scale-independent pixels, especially for a large body of text.
However if your text has to fit into a bounding-box of known size then you should use density independent pixels in order to ensure that the text always fits properly and that all characters are visible regardless of the users' setting.
Actually, Settings font size affects only sizes in sp. So all You need to do - define textSize in dp instead of sp, then settings won't change text size in Your app.
Here's a link to the documentation: Dimensions
I have a very, very, very simple application that I'm working on (been trying my luck at writing an app in Java instead of Unity) and I have a background image that is fullscreen, this image has a lot of design and scales well with every device, and looks great (tested on every resolution we can think of).
However the text doesn't want to stay where it belongs, and that's not permissible. We have a basic setup, similar to this (however with about 6 hours of design work put into it):
and we need text to be centered in the squares at all times. How can we do this? Do we have to manually position and size it for each resolution? That seems like hell.
With a relative layout, if I understand correctly, the boxes will be parents and the text that goes into the boxes will be the children. You can put your TextViews into the boxes and then use things like android:layout_centerVertical or android:layout_centerHorizontal in order to make sure they are centered. Make sure to use sp for your font size so that it scales correctly with the density of the display.
I am writing a game using libgdx, and I borrowed the skin.json (and related files) from a tutorial.
The font being used (default) was scaling in an ugly manner on denser screens, so I generated by own very large font - and in the game itself, I scale it to a reasonable size (basically I use BitmapFont.scale). The font I'm now using is 3 times as large as the previous one.
I changed the reference to which font to use in the skin.json file, and as a result, all my buttons, titles and other things have a massive font being shown.
Is there a way of scaling the font in the .json file? Or anywhere else in the code? Skin doesn't have a setFont() functionality, so I can't create a scaled BitmapFont and assign it)
Libgdx changed this back in April 2015 so that the set answer doesn't work anymore. Took a little bit to find the answer, so I thought I'd leave it here for others since this answer pops up first in Google.
this.getSkin().getFont("default-font").getData().setScale(0.33f,0.33f);
Documentation says that any gets will return a handle to the actual object. So changes will persist.
So I changed the font in skin.json to point to my new font.
Then I used this code
this.getSkin().getFont("default-font").setScale(0.33f, 0.33f);
To scale the 'default-font' (as defined in the skin.json) to the scale I wanted (in my case its 0.33f)
As of 2017 i had to use
skin.getFont("default-font").getData().setScale(0.5f);
for future users.
I've spent many fruitless hours trying to create what I consider to be a very simple GUI. One thing that makes it simple is that I don't even expect it to be resizeable. I want it to display just the way I've laid it out. Simple as that.
There's a JFrame containing two Jpanels of equal width, one above the other. I've got the JPanels behaving themselves finally, and I can slide them around without their enclosed components mysteriously shifting.
But I can't for the life of me get the JFrame to nicely enclose the JPanels. I'm attaching a screen shot showing the layout and the inspector, and another showing how it previews
(Notice that it's chopping off the bottom edge.)
Is there any way to work in a "WYSIWYG mode" in the GUI builder? I don't care about (in fact, I dread) resizeability, at all at this point. I would have thought Absolute Layout would be the right choice for this, but there's still something wrong. (I need an elementary solution, folks -- please don't suggest GridBagLayout!! ;)
EDIT: By restoring some defaults, mainly for MaximumSize, to the JFrame, I got rid of the clipping problem. The right edge was still off by one pixel, and I managed to find which of five (five!) width properties was controlling that. (bounds, max size, min size, preferred size, and width - changing min size fixed that.)
I've already found that you can't completely avoid tweaking properties (e.g. to override "snapping" and achieve pixel-precise positioning). I clearly made trouble for myself at some point by playing with some properties I shouldn't have. The question remains: for non-resizable, WYSIWYG GUI design, is Absolute Layout a reliable choice; and, what properties should I avoid editing?
Is the JFrame showing any better when you actually run than preview? I think this is an OS X specific NB behavior. I did not see this in Win32. For now, you may try adding a JLabel ( spaces as the text content) at the bottom to make sure that space is drawn when the actual JFrame runs.
I have a large component (say width=4000px, height=200px) and would like to be able to see it entirely even on a small screen.
I don't see any easy way to do a wrapping component, my idea is the following :
given a factor (for example 4), the component would be of size 1000x800, by wrapping the child to 4 lines. The size requests would be translated in reverse to reshape the child, and so on. On painting, the component would call the paint(Graphics) of the child 4 times with a correct Graphics argument that would map the wrapped space to the child's space.
However, I can't see how to handle all the events : should I set eventlisteners for every children-generated event (PropertyChange) and for every parent-generated event (Mouse, Key, Resize, ....) ? This seems quite a lot of mapping, and I'd be happy to ear of an easier way of doing that...
I haven't looked too much at the JViewport implementation, but maybe this could help me don't you think?
thanks for your suggestions!
Frederic.
Edited to answer some of the comments that suggest to redesign the component :
Allow me to disagree here : making a component is one job, showing it is another. If I want to show it with scroll bars, I use a Scroll-Pane, whereas if I want to show it split in 4 lines, I want to use a similar solution.
I am the designer of the component in question (and had sharp words with myself, as suggested, but it lead me nowhere :-) ). I actually added "line-wrapping code" in it but it appears (really quickly!) that adding point space conversion, painting management in the codes of the component itself makes it really really messy, which is the reason why I imagine that a specialized component is a really a better solution.
Furthermore, making a custom component lets me reuse it far more easily as a "wrapper" for any other component.
Imagine if you had to recreate a JScollPane-like functionality every-time you use a JScollPane, dealing with scroll position, buffered painting and everything inside your own components : hopefully you don't have to!
You're approaching this the wrong way. It's the contents of the component, not the component itself you should be thinking about. If you want it to be 1000x800, make it that size. If the component has content - e.g. text or other components - calculate their positions appropriately. (You probably won't be able to use the standard layouts, and may end up writing your own). You'll probablky need to recalculate the layout if the component's width changes.
Don't call paint 4 times. If you've calculated the layout of the component, it's children or text, correctly then paint should just work.
In response to the comment: wrapping a histogram, in the sense of inserting arbitrary line breaks, is not likely to be useful. With graphical components the 'breaker' won't know exactly where to insert the breaks; you will also lose any information attached to the Y axis. Much better solutions would be to simply shrink the histogram in the horizontal direction until it fits the screen width, or to draw four histograms one under the other, duplicating the Y axis information for each. Alternatively allow horizontal scrolling over the whole histogram; or change the axes so the histogram is drawn horizontally. If none of the above work, perhaps because you have many hundreds of histogram bars, maybe a more interactive approach where you amalgamate some of your histogram bars together to give an overview, and allow the user to 'drill down' into the plot to get at the more detailed information.
If the issue is that you can't modify the original component, and it draws a fixed size image, then your best bet may be to call 'paint(Graphics)' on it four times with appropriate transforms and clipRects on the Graphics to draw the four parts 'stacked'. But frankly you may be as well off throwing away the original component. Histograms are not that hard to draw, and there are plenty of free plotting packages to help you. And be very rude to the designer of the original component if you meet them.
You don't mention scrolling. Put it on it's own pane and then put that pane into a scrolling panel.