I'm using the charts of the WinRTXamlToolkit for an UWP-App.
Using an 720p display or better (e.g. Lumia 640) the chart looks just fine, but using a device with a lower resolution (e.g. Lumia 535 at 960x540), the edges of the chart are cut off.
I've already tried to change several variables of the chart like padding, margin, width or height, but the outer parts of the chart remain cut off.
Whatsoever: changing the scaling of the lower-resolution-device to 125% solves the problem.
Is there a way, to achieve a non-cut-off-chart, without having to set the scaling in device settings on affected devices? The current behaviour forces users to change their overall resolution-scaling just for this one feature.
Example of a cut-off chart
Example of a "normal" chart
Seems like the layout is just unable to fit all the elements so they all get their fair amounts of space and the rest gets clipped off. Of course there's probably some issue with that layout logic of the chart control that might be fixed, but if you want a quick fix - you could set the Width/Height of the chart to fixed values and stuff it in a Viewbox.
Related
I am essentially creating a trading card that must maintain a 2.5x3.5 ratio.
I created the cards background image (with logo's and things that will never change)
I need to create a layout/frame/whatever that will maintain a 2.5x3.5 ratio so I can give it this background image (or image aspectfit) that will never stretch, given that the layouts aspect ratio should never change. This way no matter the size of a phones screen, the height and width size will adjust to fit in any size screen, but the view's aspect will always remain in tact...
The idea is, I will then place labels into this card through Xamarin forms using an API. Name, image, details, etc...
The image of the cards logos will never change, hence the background image, but the labels will change according to character...
Any ideas?
I am using elements of width 1.5 to connect elements. This all looks fine but if the image is dynamically scaled down to show more of the diagram then some of the lines eventually disappear in Firefox but not in Chrome. Is this a problem in the Firefox SVG support, or some difference in default settings that I can change?
Rather than present any code, I can point to an example in a blog-post at: https://parallax-viewpoint.blogspot.com/2018/12/further-travels-of-walking-boots.html. Scroll to the bottom of the post and there's an embedded SVG "family tree" image that uses the JavaScript pan-zoom library to dynamically scale the diagram.
On the default setting, in Firefox, not all lines will show -- probably dependent upon whether they fall on a pixel boundary or not. As the image is gradually scaled up, you will notice that the lines will eventually all show. Contrast this with Chrome where the lines always appear to show.
New information from Firefox support: there is a pronounced "redraw" fluctuation for all transformations (+ or -) from the initial position. The lines are markedly thinner after the redraw, and this suggests some sort of rounding error is occurring.
The suggestion of using double lines (one with non-scaling-stroke and one without) runs into a few issues. If the line elements have stroke-opacity less then 1 then the superposition shows through. Also, with SVG 1.1, it does not appear to be possible to encapsulate the drawing of two lines in a single group/symbol if the line lengths are related but not equal. Unequal lengths are necessary to prevent corner gaps where orthogonal lines don't reach fully into the corners. Using calc() to adjust one length relative to a 100% length doesn't work with line elements because they use pairs of coordinates rather than lengths. I tried using a rect in place of a line but Firefox did not support CSS control over its width/height in order to use calc().
The solution was simply to use opaque lines (stroke-opacity=1.0), suggesting that the disappearance of the lines was due to Firefox's handling of stroke-opacity < 1.0. It may be the case that lines will eventually disappear at minute scales, but the reported problem was specifically that Firefox lost them much earlier than it should, and compared the situation with Chrome (which worked OK).
I have nine images ad I want them to display in a single column on the device. The images should retain their original height and width (that I will set) and the only thing that should change according to the screen height should be the distance between the images.
I'm not really sure how to approach this problem - I tried using a container, but it didn't turn out as I expected. Should I set the constraints programmatically? And if so, how? What should the constraints be if I want the images to be from top to bottom of he screen?
Consider using a stack view:
On iOS, UIStackView provides UIStackViewDistributionEqualSpacing, which I believe will arrange images as you want
On Mac, NSStackView can automatically space images as you describe if the individual image views are all in the same gravity and retain their sizes at a high enough priority (using constraints or content hugging priority)
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.
I need the user to set a number of percentage values which should always add up to 100%. What are standard ways to archieve this? I came up with the following:
1) have a standard slider control for each value you need to set. Moving one slider will automatically adjust all the others so the sum will always come out as 100%. You can fix inidividual sliders with a checkbox displayed next to it. Only the remaining, "free", sliders will be adjustable.
Pro: consists entirely of standard widgets users already know
Con: lots of widgets, lots of screen real estate used, looks ugly when you have lots of sliders and thus low percentage values, normalization to 100% isn't immediately obvious.
2) have a slider control with several sliding knobs.
Pro: normalization is implicit and obvious because the length of the slider is fixed, relative weight is easy to see at a glance
Con: non-standard, knobs can easily overlap each other, knobs aren't easy to fix, no obvious place to put a text/number representation for each interval/percentage
3) display a standard pie chart.
Pro: normalization is implicit and obvious, relative weight is easy to see
Con: non-standard for interactive use, hard to make intuitive slice resizing work, no place to put a text/number representation for each slice
4) ... ?
I'm not happy with either of these hence my question here. Any better ideas? I'm dealing with 3-10 individual percentage values on a rich windows client (i.e. not web).
cheers,
Sören
What about vertical sliders? Like a sound mixer. I think it looks a lot better than a list of 10 horizontal sliders.
Or fixed width bar with several sliders on them, a bit like the gradient control of Photoshop if you know it.
Similar to the timeline idea, how about a slider like the partitioning interface in GParted or similar disk partitioning tools?
You could display the percentage values and actual numbers above the dynamically resizing bars to allow the user to edit them numerically instead of using the sliders if they want to configure it manually.
How about a time line view; (gantt chart) kind of like in Microsoft Expression Blend or in flash where you have multiple layers for each action and each action can be within a range on the scale from 0 to 100.