I want to the corners to be rounded and hover for a QPushButton in Qt designer. Changing the style sheet has no effect. What am doing wrong?
QPushButton#pushButton_3{
background: rgb(170, 170, 255);
border: 2px solid rgb(0, 170, 255);
border-style: outset;
border-width: 2px;
border-radius: 20px;
color: white;
}
QPushButton:hover#pushButton_3{
background-color: rgb(0, 255, 255);
border: 2px solid (0, 255, 255);
}
This is what I get when the above style sheet is set:
TL;DR
Use smaller values for border-radius, usually half of a standard font size (2 <= radius <= 10).
Further explanation
The QSS border radius must have a reasonable value.
The private QStyleSheetStyle normalizes the border radius (or, better, all four border radii) based on the bounding rect of the widget, which includes the border size(s).
Whenever any border radius exceeds the size related to its corner, all radius are ignored.
For instance, if the rectangle of a widget has height 10, the sum of its top-left and bottom-left radii must be equal or less than 10, otherwise the left corner will be squared.
Note that widgets normally consider the border only for their size hint, not their minimum size hint, and that behavior also can change depending on the current style.
A button is normally created using the current style's pixelMetric() and fontMetrics(), and since a pretty standard height of a button is ~30 pixels, considering the above, the border-radius specified is excessive: the sum of any corner component is always greater than the widget height, so the radii are ignored, and the border will be squared.
So, how to set a proper border radius?
The easy answer is: use "small" values, normally no more than twice or four times the border width.
The actual answer is more complex, as we need to consider that widgets often have some displayed text, and any modern OS supports both font scaling and high DPI screens.
QSS support various types of lengths other than the standard px:
px: pixels (normally, physical pixels, AFAIK, the actual value depends on the OS and their implementation of High DPI);
pt: the size of one point (based on the screen DPI, AFAIK, only used for text properties and ignored for widget/border sizes);
em: the em width of the font (based on the displayed font);
ex: the x-height of the font (as above);
If you want to properly support any modern OS, you probably need to use any of the last two values, and that's another reason for which is important to set a global style sheet for the application: as long as the app is created, you can know the default (or imported) fonts, and eventually set a main style sheet with formatted widths or sizes based on the current device pixel ratios and font metrics.
Related
I would like to animate an SVG stroke color change from say, red to green.
Is this possible?
I have managed to do so with the "fill" property, but for some reason i cannot do it with stroke.
One solution would be something along the lines of:
.velocity({
strokeRed: 0,
strokeGreen: 255,
strokeBlue: 0
});
My understanding is that linear 1s should the default timing, perhaps adding a named easing will enable that,
.velocity({
strokeRed: 0,
strokeGreen: 255,
strokeBlue: 0
}, "easeInSine");
Also, you can simply use "stroke", but note that stroke requires a hex value, unlike those listed above which can either be unitless or a percent.
Is there a particular color operation I'm not seeing where you can invert colors? I'm seeing lots of color methods but could not see a way to do this.
reference:
http://lesscss.org/
There are multiple interpretation of inverting color.
You want a color with the opposite hue:
spin(#color, 180)
You want a color that the sum with current one is white:
#fff - #color
Unfortunately there's no invert() function in Less.
I think Less function spin() can be very helpful as xiaoyi's answer highlights. Use it on "colorful" colors like red or blue (spin(red, 180)) and we get the inverted color but we don't really get the same result on very dark or light colors since there's not much hue to rotate. For instance spin(#000011, 180) compiles into color #111100, which is also very dark.
I wanted to set the color of paragraphs to black if the background is light and set it to white if the background is dark. Here's how I do it with if(), boolean() and luma():
#bkg-color: #001;
#is-bg-dark: boolean(luma(#bkg-color) > 50%);
.container {
background-color: #bkg-color;
}
p {
color: if(#is-bg-dark, black, white);
}
Read more about Less functions such as boolean().
I don't think there is a specific function to invert colors, but what you could do is set your colors as variables. e.g.:
#color1: #666;
#color2: #fff;
body {
background-color: #color1;
color: #color2;
}
h1 {
color: #color2;
}
Then, simply make an alternate stylesheet with the inverted colors set to the variables used in the primary stylesheet. As long as you use the variables throughout the css, those color will be inverted.
Why do my texture's edges contain unwanted colored lines? Texture looks shifted by a part of a pixel.
Texture2ds can be seen as shifted or misplaced sometimes when you're not drawing the whole texture, but just a part of it via SourceRect parameter and the texture's position (Vector2) has nonintegral coordinates. It may look like undesired texels showing at its edges.
If you have a texture with 1px purple border, the actual image can appear with sligthly purple edges. You can avoid that by making the texture coordinates integral.
If this code causes trouble…
Texture.Position.X = 4.9876f; // 4.9876f is an example of actual value
Texture.Position.Y = 5.1234f;
…try adding a cast:
Texture.Position.X = (int)4.9876f;
Texture.Position.Y = (int)5.1234f;
Is it real to make line with 1px weight in SVG or raphaeljs?
The follow code
var p = Paper.path("M1 1 L50 1");
p.attr("stroke", "#D7D7D7");
p.attr("stroke-width", "1");
p.attr("opacity", 0.5);
draw line which looks like 2px or 3px. Any alternative?
When SVG lines lie at their apparently correct coordinates they actually lie inbetween pixels, so when you state M1 1 L50 1 it paints half a pixel on the top and the other half in the bottom of the pixel, making it look like a thick, semitransparent line.
To solve this problem you need to either paint at half pixels, or translate your elements half a pixel, ie. element.translate(0.5, 0.5)
You can see the blurry and sharp lines here:
http://jsfiddle.net/k8AKy/
You should also use the Paper.renderfix() function since you do not know which browser your users will be using.
From the documentation
Fixes the issue of Firefox and IE9 regarding subpixel rendering. If
paper is dependant on other elements after reflow it could shift half
pixel which cause for lines to lost their crispness. This method fixes
the issue.
This links take you point what's going wrong with integer coordinates and why +0.5 was fixed edge blurring (with nice pictures!!):
http://diveintohtml5.info/canvas.html#pixel-madness
http://kilianvalkhof.com/2010/design/the-problem-with-svg-and-canvas/
Compare:
with +0.5:
You can avoid +0.5 by:
SVG_Area.setAttribute("viewBox", "0.5 0.5 " + width + " " + height);
or by wrapper:
function fiXY(x) { return parseInt(x) + 0.5; }
var rect = document.createElementNS(SVGobj.svgNS, "rect");
rect.setAttribute("x", fiXY(x));
rect.setAttribute("y", fiXY(y));
or by:
SVG_Area.setAttribute("shape-rendering", "crispEdges");
which effect on all shapes in you SVG image....
http://jsfiddle.net/jBgqW/
I've painted the background with fillRect and fillStyle set to rgb(255,0,0) but when I iterate through the pixels and set some random color and value of the alpha pixel to 0 everything becomes white. I've assumed that when the pixel is transparent it should blend with the previously painted background color or does it always default to white.
I hope that it's just my wrong way of using the canvas.
Can anyone explain why the background isn't red in this case and how do i use the alpha pixel properly? I would like to know if this has something to do with the alpha premultiplication.
When using globalAlpha, the pixel colors are calculated with the current rgba values and the new values.
However, in this case you're setting the values manually and therefore doing no calculations. You're just setting the rgba values yourself, which means that the alpha channel is not used for calculating but is just altered without further use. The previous color (red) is basically overwritten in a 'brute force' way - instead of rgba(255, 0, 0, 255), it's now just rgba(128, 53, 82, 0). The original red color has simply been thrown away.
As a result, an alpha of 0 represents complete transparency, so you see the colors of the parent element.
This can be confirmed if you change the body background color: http://jsfiddle.net/jBgqW/2/.
This is somewhat thread necromancy, but I've just faced this problem and have a solution to it, if not for the original poster then for people like me coming from google.
As noted, putImageData directly replaces pixels rather than alpha blends, but that also means it preserves your alpha data. You can then redraw that image with alpha blending using drawImage.
To give an example, lets says we have a canvas that is 200 by 100 pixels and a 100 by 100 imageData object.
// our canvas
var canvas = document.getElementById("mycanvas");
var ctx = canvas.getContext("2d");
// our imageData, created in whatever fashion, with alpha as appropriate...
var data = /* ... */
// lets make the right half of our canvas blue
ctx.fillStyle="blue";
ctx.rect(100, 0, 100, 100);
ctx.fill();
// now draw our image data to the left (white) half, pixels are replaced
ctx.putImageData(data, 0, 0, 100, 100);
// now the magic, draw the canvas to itself with clipping
ctx.drawImage(canvas, 100, 0, 100, 100, 100, 0, 100, 100);
Voila. The right half of the image is now your image data blended with the blue background, rendered with hardware assistance.