I'm trying to understand how a program is determining the new width/height when resizing it.
One would think it's merely an aspect ratio like 4:3 (which would lead to a 1.333333 ish value) however as you can see in this gif, the divition width/height throws a very different result depending on the window size.
https://gyazo.com/f3d514b9bf51f49899612090868ec140
I have seen many programs behave like this. Any idea what the algorithm is behind this?
Thanks!
A specific window size can be forced by handling the WM_WINDOWPOSCHANGING message. You get to decide the new width and height by any algorithm you desire when the user resizes the window.
The thing that was screwing the ratio width/height was the title, that no matter the new size, was the same height, thus ruining the ratio for every new size, on taking into account the -30 px the ratio now alwasy gives the same value.
Cheers!
Related
Just a straight forward question. I´m trying to make the best possible choice here and there is too much information for a "semi-beginner" like me.
Well, at this point, I´m trying with screen size values for my layout (activity_main.xml (normal, large, small)) and with different densities (xhdpi, xxhdpi, mhdpi) and, if a can say so myself, it is a mess. Do I have to create every possible option to support all screen sizes and densities? Or am I doing something really wrong here? what is the best approach for this?
My layouts are now activity_main(normal_land_xxhdpi) and I have serious doubts about it.
I´m using last version of android studio of course. My app is a single activity with buttons, textview and others. Does not have any fragments or intents whatsoever, and for that reason I think this has to be an easy task, but not for me.
Hope you guys can help. I don't think i need to put any code here, but if needed, i can add it.
If you want to make a responsive UI for every device you need to learn about some things first:
-Difference between PX, DP:
https://developer.android.com/training/multiscreen/screendensities
Here you can understand that dp is a standard measure which android uses to calculate how much pixels, lets say a line, should have to keep the proportions between different screensizes with different densities.
-Resolution, Density and Ratio:
The resolution is how much pixels a screen has over height and width. This pixels can be smaller or bigger, so for instance, if you have a screen A with 10x10 px whose pixels are two times smaller than other screen B with 10 x 10 pixels too, A is two times smaller than B even when both have 10 x 10 px.
For that reason exists the meaning Density, which is how much pixels your screen has for every inch, so you can measure the quality of a screen where most pixels per inch (ppi) is better.
Ratio tells you how much pixels are for height as well as width, for example the ratio of a screen of 1000 x 2000 px is 1:2, a full hd screen of 1920 x 1080 is 16:9 (16 pixels height for every 9 pixels width). A 1:1 ratio is a square screen.
-Standard device's resolutions
You can find the most common measurements on...
https://material.io/resources/devices/
When making a UI, you use the DP measurements. You will realize that even when resolution between screens are different, the DP is the same cause they have different densities.
Now, the right way is going with constraint layout using dp measures to put your views on screen, with correct constraints the content will adapt to other screen sizes
Anyway, you will need to make additional XML for some cases:
-Different orientation
-Different ratio
-Different DP resolution (not px)
For every activity, you need to provide a portrait and landscape design. If other device has different ratio, maybe you will need to adjust the height or width due to the proportions of the screens aren't the same. Finally, even if the ratio is the same, the DP resolution could be different, maybe you designed an activity for a 640x360dp and other device has 853x480dp, which means you will have more vertical space.
You can read more here:
https://developer.android.com/training/multiscreen/screensizes
And learn how to use constraintLayout correctly:
https://developer.android.com/training/constraint-layout?hl=es-419
Note:
Maybe it seems to be so much work for every activity, but you make the first design and then you just need to copy the design to other xml with some qualifiers and change the dp values to adjust the views as you wants (without making from scratch) which is really faster.
I've imported many clips from photoshop into flash and animated them. they are still editable by photoshop though.
Now i realized that the clips are much larger size than i require on runtime. Which leads to my first question :-
Does their original size effect the performance, if i am scaling them half on the rumtime?
And, if it does is there anyway i can shorten the size originally, given that i've already animated them?
Right clicking the image to edit it with photoshop, that does not work because we cant change size there.
It probably does affect performance, but how noticable it is depends on their size and on how many of them are being scaled at the same time. What you do with them during runtime could also affect this.
You can change the size in Photoshop, but it means you will have to enlarge the image again in Flash, since any transformations like scaling will remain after resizing the image in Photoshop.
I have run into a weird necessity to make a certain window in the system of a really big height, one that is larger than my display's resolution. I have written a simple WinAPI program that sets a window size by calling SetWindowPos and I have encountered that if the height is greater than current display's resolution, then it is simply set to be equal to screen height.
This is obviously some Windows trick and I am wondering if there is a way to override that and set an arbitrary size for the window.
You need to implement a message handler for WM_MINMAXINFO.
What are the use cases for defining distances in a web layout for pixels and percentages?
Is there any downside to using pixels with respect to multiple resolutions? Will they scale correctly?
Percentage layout
This is generally referred to as fluid layout. Your elements will take a defined percentage of the total space available to them. This available space is determined by the element's parent.
When using percentage layouts, it's a good idea to specify a min-width and max-width on your design so that it remains usable at very low and high resolutions.
Pros
Scales with screen size, therefore get to use more space if it's available.
Cons
Makes it more difficult to know the exact position of something on screen. As a result, it can make creating precise layouts more difficult.
Can lead to unexpected layouts if child elements are fixed width (i.e. an image) and end up being larger than their fluid width parent.
Pixel layout
This is usually known as fixed layout. Your element will always be the same defined pixel size and will not take available parent space into account.
Pros
Always know an element's exact size.
Creating precise layout is easier.
Cons
You don't scale with resolutions. Your layout will always be the same width, making for wasted space when people have high resolutions.
I'll reply to this one by telling you a true story.
We had a client which wanted a map view, made up of divs.
Suddenly, he decided he wanted zooming as well.
I had to change all those fine-grained pixel positions to percentages.
Causing the wrapping div to change width/height (in pixels) relatively, we got a nice and reasonable zooming effect.
NB: During design phase, I quickly drew up a prototype, I'm going to look it up for you...
Edit: Nope, nothing found, sorry.
For percentages you have to have a base value, so it would be something like an image that has a size set outside of the CSS, if you just use a percentage on a DIV, for example, it wouldn't have anything to base that off of except the actual size it was by its being filled with text, for example, so it would not be practical to use percentages as a way to size it as it would rarely produce the desired output, if you are re-sizing something with a pixel size, such as by using javascript, you could resize by a percentage that would resize the original value (in pixels)
They do different things.
Pixel values always relate to hypothetical pixels on the output device.
Percent values relate to the computed size of the containing block (for block elements) or the containing block's font size (for font sizes).
Em and pt values relate to the current font size.
If you want your item to scale with its container, use percentages. If you want it to scale with font size, use ems. If you don't want it to scale at all, use pixels.
And then there's IE6; whoever 'implemented' CSS in that thing obviously had no idea what the various CSS properties were supposed to do.
Be careful using percentages, webkit browsers don't calculate percentages correctly. It's all because webkit doesn't calculate subpixels correct.
Detailed information about this issue can be read here: Percentage bugs in webkit
I would recommend you to always use pixels to don't have any layout dimensions differences between browsers.
Is there a standard max for the width of the main content area of a web page? I want to maximize screen real estate without affecting usability. I've seen a lot of sites stick to 980px or less. Anyone have any suggestions?
Target either the 800x600 or 1024x768 resolution.
For 800x600 it is around 750px.
For 1024x768 it would be 970px.
I'm assuming you're referring to the wrapper width since you mentioned 980.
The most ideal solution is to not think of pixels at all and instead rely on ems/%s and scaling, be as fluid as possible so your design fits on small mobile devices and your elements heights are not fixed but auto. Example being: http://www.456bereastreet.com/
But if you're stuck with web designers who still think pixel and you know for sure you'll be unable to get them to try making images that are liquid/fluid, I would say shoot for 960 pixels in width so you have enough viewing area in a 1024x768 with scrollbars in IE6/XP, but this really depends on your audience and the majority of your audience's screen resolutions.
Research, such as that referenced here suggests that people have a more difficult time reading long lines of text. That's why I restrict my content width to 800px or so.
You have to first ask the question. Who is my audience?
There's no "standard", especially in this age of PDAs/smartphones/netbooks/smartbooks/kiosks/etc... - while it may sound cliche, the best thing is to design a fluid layout not depending on exact screen size.
The answer may change depending on your intended/anticipated user base, of course (e.g. assume 1024 px screen width leaving you with 980 working px - and consciously decide that you are not interested in supporting anyone with smaller screen resolution).
Another solution is to allow size layout customization by making it into portal-like with user having control of layout of the portlets (ala My Yahoo).
960 is a pretty common standard, and the rationale behind that figure is the fact that fitting on a 1024 pixel wide screen will allow a big majority of your users to see the content without scrolling. See here for one of 100's of sites that give access to browser & user system capabilities statistics for some initial inspiration.
But in the end, it'll up to you to understand the structure of your customer base - if your site targets iPhones, targetting 1024 pixel wide screens may not be your smartest decision.
Not sure about absolute pixel values, but one thing I'd make sure of is that the text columns don't get too wide. There is a number of characters beyond which reading comprehension is impaired.
1000 pixels in width, is what I use which fits into the minimum 1024x768 resolution used these days without a horizontal scroller at the bottom of your browser ....