dogamak / xcbars

Bar library created with rust and xcb.
Apache License 2.0
1 stars 1 forks source link

Change bg color/fg color for component #23

Closed chrisduerr closed 5 years ago

chrisduerr commented 7 years ago

I think being able to change bg color and fg color on a per component basis is very important.

I'm not quite sure how complicated this would be to implement, but I looking at the other issues this seems like a basic problem that should be tackled.

Not every component might need this. But at least the text-based ones probably do.

chrisduerr commented 7 years ago

@dogamak In an attempt to see how to do this I tried changin the colors in the paint method to randomly generated values (https://github.com/dogamak/xcbars/blob/master/src/item_state.rs#L157-L167). However they didn't change every redraw. I expected this to blink randomly with funny colors. Can you explain why this is not the case?

dogamak commented 7 years ago

So you are generating a new color every time .paint() is called, and yet the color doesn't change when the component has an update? Seems strange.

chrisduerr commented 7 years ago

Yeah exactly my thought. I changed both colors. And I am printing the values in the console and they are clearly changing every time it's called. Very different values too. But it doesn't change the colors from the initial values. And I am not entirely sure why this is.

dogamak commented 7 years ago

Ah, but this function renders to the pixmap specific to the component. It is later copied to the window in Bar::draw_item, so maybe paint is called more frequently than draw_item for some reason?

FYI components were called items at some point before I pushed to github, so that's why there's still some functions using "item". I know.. I should rename them..

chrisduerr commented 7 years ago

That would kinda indicate an inefficiency, right? But no that's not the case. Every time the color changes I am getting one or two redraw calls.

This is how my current terminal output is looking:

-- 2 -- RED: 239, GREEN: 191, BLUE: 213
-- 2 -- DRAWING ITEM!
-- 0 -- RED: 127, GREEN: 66, BLUE: 190
-- 0 -- DRAWING ITEM!
-- 1 -- RED: 243, GREEN: 163, BLUE: 161
-- 1 -- DRAWING ITEM!
-- 1 -- DRAWING ITEM!
-- 0 -- RED: 64, GREEN: 155, BLUE: 182
-- 0 -- DRAWING ITEM!
-- 1 -- RED: 74, GREEN: 41, BLUE: 145
-- 1 -- DRAWING ITEM!
-- 1 -- DRAWING ITEM!
-- 0 -- RED: 109, GREEN: 230, BLUE: 137
-- 0 -- DRAWING ITEM!

Numbers at the beginning are the item IDs.

So there are multiple redraw events after a single paint, but never the other way around. If anything those draw_item calls might be too many? Not sure why sometimes it's doing it twice.

dogamak commented 7 years ago

What slot is the component number 1 in?

chrisduerr commented 7 years ago

It's left, middle, right. So component 1 is in the center slot.

chrisduerr commented 7 years ago

@dogamak Is it worth looking into giving text components different bg and fg colors right now or is this likely gonna be affected by #20 anyways and I should wait?

dogamak commented 7 years ago

It is definitely going to be affected, but to what degree.. I don't know. It'd probably be wise to refrain from touching anything component rendering related until #20 is resolved.

chrisduerr commented 7 years ago

Oh okay then I'm not gonna do that for now. I don't think I would be able to give those Components a fg/bg color property without changing quite a lot anyways. Because the struct is just for creating a component that sends out strings.