How is it possible to render a rectangle with the background color of selections in GTK+3. I cannot find any API to do that:
static gboolean draw_callback (GtkWidget *widget, cairo_t *cr, gpointer data)
{
auto state=reinterpret_cast<State*>(data);
auto width = gtk_widget_get_allocated_width (widget);
auto height = gtk_widget_get_allocated_height (widget);
auto context = gtk_widget_get_style_context (widget);
gtk_render_background(context,cr,0,0,width,height);
cairo_rectangle(cr,0,height*(1.0 - state->max),width,height*(state->max - state->min));
cairo_set_source_rgb(cr, 0.05,0.6,0.15); //What color should be used here?
cairo_fill (cr);
cairo_set_source_rgb(cr,0.01,0.3,0.07); //And here
auto mid=height*(1.0 - 0.5*(state->min + state->max));
cairo_move_to(cr,0, mid);
cairo_line_to(cr,width,mid);
cairo_stroke(cr);
return FALSE;
}
Use gtk_render_frame() and gtk_render_background(), and set up the GtkStyleContext you obtain from the GtkWidget instance with the CSS state you want to replicate.
If you want to adhere to the theme, then you cannot draw yourself; and CSS does not have "colors": each CSS state can have multiple layers that include images, gradients, and complex blend modes.
Well, here is my hack:
ColorRGBA get_ambient_color(GtkWidget* widget)
{
auto surface=cairo_image_surface_create(CAIRO_FORMAT_ARGB32,4,4);
auto cr=cairo_create(surface);
while(widge!=NULL)
{
auto context=gtk_widget_get_style_context(widget));
gtk_render_background(context,cr,0,0,1,1);
cairo_surface_flush(surface);
auto content=cairo_image_surface_get_data(surface);
if(content[3]==255)
{
auto ret=ColorRGBA{content[2]/255.0f,content[1]/255.0f,content[0]/255.0f,content[3]/255.0f};
cairo_destroy(cr);
cairo_surface_destroy(surface);
return ret;
}
// Surface is not opaque yet. Continue to parent container.
widget_handle=gtk_widget_get_parent(GTK_WIDGET(widget_handle));
}
cairo_destroy(cr);
cairo_surface_destroy(surface);
return ColorRGBA{1.0f,1.0f,1.0f,1.0f};
}
It seams that I have failed to convince people, why you need the ambient colour, so here are two use-cases:
Determine if we are using a dark/light theme. For some applications, this is sufficient. Querying the state only works if the theme supports dark/light modes. This proves the actual result.
Use as input colour for simulating global illumination. The shading of widgets should be affected by the ambient, hence the name. Another good name would be get_average_background. Themers: please don't use gradients with high contrast.
Case 1: A plot
Now you say that the colour of cursors and function graphs should be themable. That is simply not possible: The user of this plot widget can add as many curves and cursors as he wishes, and the easiest way to differentiate them is to use distinct colours.
What about curve and cursor lightness? If the background is dark, then the curve should be light and vice versa. And what background should be chosen? Ideally, something close the the background of the parent widget, but if the theme is regular, white for light, and black for dark would work. Do you notice that the curves are darker in the second figure?
Case 2: A checkbox that looks like a metallic toggle switch button
With the following technique, I have created a switch that looks exactly as if it were rendered through the Cycles path tracer. This is implemented in Gtk+2, but the algorithm is the same.
The two input images
The code
GtkAllocation alloc;
gtk_widget_get_allocation(widget,&alloc);
auto width=alloc.width;
auto context=CairoContext( gdk_cairo_create(gtk_widget_get_window(widget)) );
auto w_in=cairo_image_surface_get_width(light);
auto h_in=cairo_image_surface_get_height(light);
// Render direct lighting
auto surf_temp=CairoSurface( cairo_image_surface_create(CAIRO_FORMAT_ARGB32,w_in,h_in) );
auto context_temp=CairoContext( cairo_create(surf_temp) );
cairo_set_source_surface(context_temp,light,0,0);
cairo_set_operator(context_temp,CAIRO_OPERATOR_OVER);
cairo_paint(context_temp);
//Render ambient reflections
auto surf_temp_2=CairoSurface( cairo_image_surface_create(CAIRO_FORMAT_ARGB32,w_in,h_in) );
auto context_temp_2=CairoContext( cairo_create(surf_temp_2) );
cairo_set_source_surface(context_temp_2,background,0,0);
cairo_set_operator(context_temp_2,CAIRO_OPERATOR_OVER);
cairo_paint(context_temp_2);
cairo_set_operator(context_temp_2,CAIRO_OPERATOR_MULTIPLY);
//Multiply reflections with the background color
cairo_set_source_rgb(context_temp_2, color_bg.r, color_bg.g, color_bg.b);
cairo_rectangle(context_temp_2, 0, 0, w_in, h_in);
cairo_mask_surface(context_temp_2,surf_temp,0,0);
//Add the results
cairo_set_source_surface(context_temp,surf_temp_2,0,0);
cairo_set_operator(context_temp,CAIRO_OPERATOR_ADD);
cairo_mask_surface(context_temp,surf_temp,0,0);
//Scale and move things into place
auto s=static_cast<double>(width)/static_cast<double>(w_in);
cairo_translate(context,alloc.x,alloc.y);
cairo_scale(context,s,s);
cairo_set_source_surface(context,surf_temp,0,0);
cairo_set_operator(context,CAIRO_OPERATOR_OVER);
cairo_paint(context);
Thoughts
The first example boils down to a light/dark query which is currently missing. Maybe querying colours is not required for this to work, but then there has to be an API controlling the shape and blending mode when rendering the background. For example, to render the ambient reflection, I use multiply rather than over. Also, gtk_render_background appears to be a no-op, since GtkDrawingArea has zero opacity (that's why I needed the loop). To be useful, it must use the background as it appears on screen, not the background of the current widget.
I am trying to create an interface where two labels share a space, similar to an html table with two columns would: there is a distance between the two and when the window is resized they both resize and stay the same size, keeping the distance between them and filling up the available space.
e.g. | 10px to edge | label1 (50%) | 5px spacing | label2 (50%) | 10px to edge |
If the window is resized the margins and the spacing should stay the same while the two labels should evenly distribute the available space between themselves.
After multiple attempts (e.g. putting them in a custom view takes care of the margins) I cannot figure out the correct layout constraints to make this happen.
I had the same problem until I read your problem. Because I read your problem, I gave myself another try:
You can resolve it by going into the storyboard. Then, you select both labels. After that, you add the following constraints:
Now the labels resize correctly. The trick here is to edit the constraints of both labels together. Otherwise the Equal Widths choice isn't available.
I have a label which has border around, it was set by this function:
this->setStyleSheet("border: 1px solid black");
but when I wanned to change position of the label I had to also give width and height of the border but where do I get it from?
In fact the parameters might be obtained via this->style(); that returns a pointer to QStyleSheetStyle... then via renderRule() one could get QRenderRule that stores all the structures required. The only problem is that those methods are private and intended for internal use.
So the simplest way is to use RegExp:
QRegExp regexp(".*border: *(\\d+)px.*");
if (regexp.indexIn(btn->styleSheet()) >= 0)
qDebug() << regexp.cap(1);
In XAML, you can define a size property (such a length or width) in "*" units, in which * represents a part of the remaining space.
So, if I have a parent element that is 1000px wide, and it has 2 children, which are both defined as being 1* wide, they will be 500px each. If one is defined as 3*, and the other as 1*, then one will be 750px, the other 250px.
If there is a third element, and the widths of the 3 are defined as "100px", "" "2" respectively, then the widths of the 3 will be 100px, 300px, 600px.
Is there a CSS equivalent of this, or should I just simulate it using calc()?
Flexible box layout model does that with an OK support matrix (no IE)
It does exactly what you're after, e.g. for your scenario 3:
<div class="box">
<div>un</div><div>deux</div><div>trois</div>
</div>
.box {
width: 1000px;
display: box;
box-orient: horizontal;
}
.box > div:nth-child(1){ width:100px; }
.box > div:nth-child(2){ box-flex: 1; }
.box > div:nth-child(3){ box-flex: 2; }
Fiddle'd from html5rocks example
Although ratios aren't supported in CSS, percentages are. This means you can't really specify "the rest of the width", but you can normally get what you want.
For example, your first example of 1000px with 1* could be achieved by assigning `width: 50%'. Your second example would be 75% and 25%.
Your third example is a bit more complicated, mixing fixed px values and percentage values won't work. What you can do is use some clever margins to get the overall result.
I have created a JS Fiddle to illustrate the third example.
This question already has answers here:
The border-radius property and border-collapse:collapse don't mix. How can I use border-radius to create a collapsed table with rounded corners?
(27 answers)
Closed 9 years ago.
This works
div {
-moz-border-radius: 5px 5px 0 0;
border:1px solid #000;
margin:30px;
}
This does not work
table {
-moz-border-radius: 5px 5px 0 0;
border:1px solid #000;
margin:30px;
}
Does anyone know how to use -moz and -webkit to work on tables?
5.6. Effect on Tables
The ‘border-radius’ properties do
apply to ‘table’ and ‘inline-table’
elements. When ‘border-collapse’ is
‘collapse’, the UA may apply the
border-radius properties to ‘table’
and ‘inline-table’ elements, but is
not required to. In this case not only
must the border radii of adjacent
corners not intersect, but the
horizontal and vertical radii of a
single corner may not extend past the
boundaries of the cell at that corner
(i.e. the cell's other corners must
not be affected by this corner's
border-radius). If the computed values
of the border radii would cause this
effect, then the used values of all
the border radii of the table must be
reduced by the same factor so that the
radii neither intersect nor extend
past the boundaries of their
respective corner cells.
The effect of border-radius on
internal table elements is undefined
in CSS3 Backgrounds and Borders, but
may be defined in a future
specification. CSS3 UAs should ignore
border-radius properties applied to
internal table elements when
‘border-collapse’ is ‘collapse’.