<nephele_xmpp>
Skipp_OSX, Now I am if you still are
<Skipp_OSX>
heyo but I figured it out
<nephele_xmpp>
Okay :D
<Skipp_OSX>
wanted to ask about comparing Brightness's
Nasina has quit [Read error: Connection reset by peer]
<nephele_xmpp>
Should be "easy" with the rgb_color Brightness function, ever since that was replaced. But you can also do this with HSL manually, but will give somewhat different results I'd asusme
<Skipp_OSX>
so my question is basically, is closer to 255 brighter or less bright?
<nephele_xmpp>
iirc this should behave the same as the individual color channels, so 255 is most bright
<nephele_xmpp>
IK checks for > 127 for Light and <= 127 for dark
<nephele_xmpp>
Oh, I actually documented this :D
<nephele_xmpp>
But not in the actuall Brightness function.. Darn
<Skipp_OSX>
yeah but I have to use a different value
<nephele_xmpp>
why should the value need to be different?
<Skipp_OSX>
because we want the color to be White on Desktop, not black
<nephele_xmpp>
Yeah, but I don't see why that should influence the threshold? :)
<nephele_xmpp>
What problem were you facing?
<nephele_xmpp>
could be that the Contrast() function would be a better fit potentially
<nephele_xmpp>
I'll document the brightness value beeing higher -> more white
<Skipp_OSX>
higher is more White got it
<nephele_xmpp>
(or brighter anyhow)
<nephele_xmpp>
the new alghorythm is based on color perception of brightness, so it doesn't treat all color channels equally like the old one did
<Skipp_OSX>
yeah I get that, just the 127 doesn't work bc Desktop has to be different
dalme has quit []
<nephele_xmpp>
I don't understand why it wouldn't
<Skipp_OSX>
bc the calculation yields black text on default Desktop background
<nephele_xmpp>
The default background does seem to be light, yeah. But if this is unsatisfactory (instead of changing the value); try this: Use your prefered rendering, in this case white text on light blue background and then check with the Contrast() function if this is enough. If it is not enough Contrast then fall back to the more contrasting version, i.e black text on the blue bg
<nephele_xmpp>
You can also take into account, if you want, what Document color or panel color has been set to determine if the user, generally, prefers a dark or a light UI. though with these string labels I don't think it is too bad in either case (the "big" not dark thing is clearly the desktop color here, and not the string labels)
<nephele_xmpp>
I already have some code in tracker for this i think, let me check
<Skipp_OSX>
here's what I got SetHighColor(LowColor().Brightness() >= kDefaultDesktopBrightness ? kWhite : kBlack); where kDefaultDesktopBrightness = roundf(97.5638406378); or 98
<Skipp_OSX>
so instead of using 127 I'm using 98
<Skipp_OSX>
which is the Brightness() calculation for (52, 102, 152)
<nephele_xmpp>
you have it backwards though. You need to pick a contrasting color
<nephele_xmpp>
if background >= 127 pick black else pick white
<Skipp_OSX>
well I guess it would be if background >= 98 instead then
<nephele_xmpp>
Why? This should behave consistently, if we have to optimize for this specific color that is currently set we are probably doing something wrong
<nephele_xmpp>
Do the same here: have a bias for the color you *usually* want, use Contrast() to verify it is readable enough: bam, done. If it is not readable enough then pick the other color
<Skipp_OSX>
ok except I don't get the bam part, I was trying to but couldn't figure out what a good value was and I don't understand how he did either.
<Skipp_OSX>
I don't care what the value is really as long as the text is white by default.
<nephele_xmpp>
try say, a contrast of 90. See if that is still good and readable. Also keep in mind that tracker has (and in my opinion should enable by default) Text shadows, so your contrast requirement is smaller than in a normal app
<nephele_xmpp>
so this example: if (rgb_color::Contrast(desktopColor, kWhite) > 90) return kWhite; else return kBlack
<nephele_xmpp>
then we have it weighted to prefer kWhite, only using kBlack if the contrast is really too bad
<Skipp_OSX>
okI get the contrast part, just not the 90 part
<nephele_xmpp>
Play around with that value. It is subjective based on your eyesight, brightness perception, appearence of text shadows... your font etc. We should pick a "safe" value that for most people gives good enough contast to compfortably read this
<nephele_xmpp>
Aslong as, with that value, you can confidently say "yeah, the contrast is fine" I don't think we have a problem :)
<Skipp_OSX>
ok I pick 98 then
<nephele_xmpp>
I wouldn't, because I doubt this is the cutoff point you asume ;)
<nephele_xmpp>
would a *very slightly* brighter desktop background mandate we use black now?
<nephele_xmpp>
or would you still prefer white?
<Skipp_OSX>
not in my testing, no
<nephele_xmpp>
so if somewhat brighter with white color is still good then you can lower the value a bit
<Skipp_OSX>
well I figured the default value is 127 so 98 is already past the edge
<nephele_xmpp>
no, this is a different context
<nephele_xmpp>
Contrast does not return absolute brightness
<nephele_xmpp>
just the difference of brightness between these two colors
<Skipp_OSX>
so is higher values more contrast or less?
<nephele_xmpp>
higher value is more contrast
<Skipp_OSX>
yeah I see in the code, but I assume higher means more yeah ok
<nephele_xmpp>
pick the lowest number where your artistic intention is preserved, and the contrast is compfortable :)
<Skipp_OSX>
ok
<Skipp_OSX>
if your desktop bg is white it's easy, black easy, but it's hard to say what is best for different colors
<nephele_xmpp>
yeah. But i figure this is a value we can experiment with, so no biggy.
<nephele_xmpp>
Ideally the haiku api will eventually give some context aswell like the uhm color contrast ratios used in Web Development, maybe as constants or so
<Skipp_OSX>
if (direct && selected && poseView->IsDesktopView()) drawView->SetLowColor(InvertColor(poseView->HighColor())); else drawView->SetLowColor(poseView->LowColor());
<Skipp_OSX>
so that only works if Desktop color is exactly black or white otherwise you'd get funky colors
<Skipp_OSX>
Desktop TEXT color that is
<nephele_xmpp>
why? what are you trying to do there?
<nephele_xmpp>
do you want to make desktop text colors configurable?
<nephele_xmpp>
(is this about selection drawings?)
<Skipp_OSX>
invert the color to show the selection box behind the text
<Skipp_OSX>
yes you got it
HaikuUser has joined #haiku
HaikuUser has quit []
<nephele_xmpp>
why do you want to "invert" it, if the operation only works properly to switch black and white? what is the intent behind the operation?
<nephele_xmpp>
use something like the text color, but in a different brightness?
<Skipp_OSX>
to select the box, so I'm calling InvertRect() again to invert a second time and then you get back to where you started only you have white text on top of black instead of white text on top of transparent
<nephele_xmpp>
Why not draw a black box and re-draw the text? :)
<nephele_xmpp>
anyhow, this seems like an optimiazion that works fine if you really only have black and white
mmu_man has quit [Ping timeout: 480 seconds]
<nephele_xmpp>
(and i wonder if this already gave problems before with anti-aliasing on lcd?)
<Skipp_OSX>
... that's a good point...
<Skipp_OSX>
ok well the answer is that we draw the text before we draw the box
<Skipp_OSX>
well, invert
<Skipp_OSX>
but I suppose we don't have to do that...
x10z has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
Nasina has joined #haiku
HaikuUser has joined #haiku
HaikuUser2 has joined #haiku
Nasina has quit [Read error: Connection reset by peer]
hotdogs has joined #haiku
HaikuUser has quit []
HaikuUser2 has quit []
<hotdogs>
what da
hotdogs has quit []
bjorkint0sh has quit [Remote host closed the connection]
<nephele>
Begasus[m]: new quaternion version is broken
<nipos>
nephele: You mentioned me in your patch https://review.haiku-os.org/c/haiku/+/8878 The change looks good by itself,but I don't understand what speaks against my original change and what yours solves better.I had some special-casing for dark mode that yours doesn't have.
mmu_man has quit [Ping timeout: 480 seconds]
<nephele>
nipos: easier to ask on the review tool for such, but the tl;dr: The original code would try and "lower" the colors, and then use them to draw the gradient. My new code is trying to instead pick colors around the specified color to get a gradient more matching with the picked color
<nephele>
looking at your gradient changes it shifts the colors up a bit compared to light mode, but still makes all color stops lighter, so it's trying to solve a different problem
<nephele>
my main problem I am trying to solve is that Control colors are not used by most controls, and where they are used (buttons) it's tinted heavily, and i want to get a rendering more matching the specified color
<nephele>
so that we can then adjust the other controls to properly use this color (instead of the panel color) and get a more consistent rendering
<nipos>
Ah ok,that makes sense
<nephele>
Anyhow, added you as reviewer since I wanted your input, in specific if the code does match mostly what you expect and such, if this is enough, or if more adjustments are needed for the dark mode (assuming this change is accepted, and the bevel is seperately changed)
<nipos>
I'll try
nephele has quit [Quit: Vision[]: i've been blurred!]
Core3075 has joined #haiku
jpelczar has quit [Read error: Connection reset by peer]
nephele has joined #haiku
<x512[m]>
<PriyanshuGupta[m]> "priyanshu@Bobo:~/home/haikuwork..." <- Colon on last line?
<nekobot>
• humdingerb (85459c32): BeGeistert 031 blog: fix picture link
Core3075 has quit [Ping timeout: 480 seconds]
<nephele>
nipos: by the way
<nephele>
I assume you know how to properly make gradients in css? :)
<nephele>
if you want to take a shot at it, and have time, maybe fixing the background gradient of our main page would be cool. iirc it uses an image or something, and if you zoom in it immidiently breaks
<nephele>
also, no dark mode adjust
smalltalkman__ has joined #haiku
<nipos>
Yes,I could do that.
<nephele>
I should get a harddrive and fix the background of image documents in haikuwebkit heh
<nipos>
Will have a look at the site soon
<nipos>
While verifying your change,I found another (independent) dark mode issue that I'll try to fix first.
<nephele>
where?
<nipos>
Your change looks good,but the little arrow in dropdowns doesn't become white in dark mode and is barely visible with the now darker background.I'll try to make it use text color instead of hardcoded black
<nephele>
ah yes, also the black devider is not visible
<nephele>
Assuming you talk about comboboxes
<nipos>
Yes
<nephele>
Very cool, in any case, whacking all those dark mode issues :)
nephele_xmpp has joined #haiku
bjorkintosh has quit [Remote host closed the connection]
bjorkintosh has joined #haiku
<nephele>
scrollbar arrows are also black when they should be white :)
<nephele>
disabled scrollbars in dark mode are too bright also
<nephele>
though maybe that is just my impression
<nipos>
I think you're right,making the scrollbar arrows white would be better
<nephele>
What do we need to support efivars?
Nasina has joined #haiku
BrunoSpr has joined #haiku
<nephele>
the cgit of the linux kernel has dark mode
<nephele>
how can we get this
dalme has joined #haiku
x10z has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
<nipos>
The more difficult thing is finding where the dropdown arrow is drawn in Haiku.The color change will be trivial,but I can't locate the thing in the source
mmu_man has joined #haiku
<nephele>
Figure out where HaikuControlLook::DrawArrowShape is called from, i guess?
<nipos>
MenuItem.cpp seems to be about the submenu arrows,all others don't have anything to do at all.
<nephele_xmpp>
those colors are a bit hard to read on nikisoft
<nephele_xmpp>
also the scrollbar is the wrong color. presumeably no :root { color-scheme: dark light; } directive
<nipos>
Maybe.The dark theme on that page is a quick&dirty thing,as I thought it's better than not having one at all but I also didn't want to invest a lot of time in the site.
<nephele_xmpp>
fFontsMenuField = new BMenuField("fonts", label, fFontsMenu);
<nephele_xmpp>
so this control is a BMenuField
<nipos>
Yes
<nipos>
But the MenuField.cpp doesn't seem to draw an arrow anywhere
mmu_man has quit [Ping timeout: 480 seconds]
<nipos>
It calls BMenuBar somewhere,but MenuBar.cpp also doesn't draw an arrow,or at least I don't see it
<nephele>
There was some wierd distinction where this functionality (of a combobox) is provided by two different classes, and one of them ought to be deprecated... but i can't recall anymore
<nephele>
maybe PulkoMandy or waddlesplash have some hints herew
<nipos>
Fixing the scrollbar arrow colors first should be easier
<nephele>
DrawMenuFieldFrame
<nephele>
that's the only function that makes sense to me
<nephele>
but that also "only" calls the function for a button
<nipos>
Not sure,it also doesn't draw an arrow there,but it's worth a try
<nipos>
Oh wait no
<nipos>
I already tried changing the fMenuBar->LowColor(), LowColor() to fMenuBar->HighColor(), HighColor() in MenuField.cpp line 1112,that only resulted in a white border around the whole Combobox,but no change inside it
<nipos>
(that's where the function is called)
mmu_man has joined #haiku
<nephele>
ugh, trying to read the linux efi stuff to figure out what it does under the hook, but this is like a jungle to me :(
<nipos>
What do you try to find out there?Maybe have a look at the BSDs instead,their code quality seems better in most cases
<nephele>
how to set efivars under the hood, how to read them and such
<nephele>
so we can read them and offer "Reboot to <OS>" in the shutdown menu
<nipos>
Haiku is probably the last OS to be mostly free from corporate influence.
<nephele>
Everything is "influenced" by corporations. FreeBSD takes code sponsored by netflix that helps them, but it is bsd2 regardless. Haiku takes money from Google for GSOC and such
<nephele>
> /* Make sure this construct works -- I think it will fail */
<nephele>
nice :D
<nipos>
lol
<nephele>
so libefivar uses a fd called /dev/efi and calls ioctls on it. One step closer (and about what i expected for a userspace interface)
jpelczar has quit [Read error: Connection reset by peer]
<nephele>
yes, because efivar is more specific. I will check where /dev/efi is implemented
zardshard has joined #haiku
<nephele>
like: the efi file descriptor ioctl only provides basic operations of add this, replace this or something. and the whole "is this a guid"? validation seems to happen in userspace
<nephele>
there is also efi runtime services, that is probably also implemented somewhere. though i have no clue what those are usefull for
<nipos>
The other one may also be interesting probably,but not related to /dev/efi
<nephele>
:)
mmu_man has joined #haiku
<nipos>
The number of opened Grok tabs is starting to get confusing
BrunoSpr has quit [Quit: Vision[]: Ich wurde eingeweicht!]
<nephele>
heh. Thanks for you help ;)
<nipos>
No problem :)
<nipos>
Btw,the AmazonBot seems to also like Grok.Found out today that my Grok instance crashed so often recently because the AmazonBot hammered it with thousands of requests.It's now banned.
bbjimmy has joined #haiku
Core8793 has quit [Ping timeout: 480 seconds]
<nephele>
why? how am i supposed to know about sales on your grok then?
<nipos>
They're still sending tons of requests,but Nginx is now directly responding Error 403 instead of forwarding it to OpenGrok which gets overloaded by that amount of traffic
<nephele>
You are beeing so nice, i would just not respond
<nipos>
if (user agent matches) {return 403;} is the simplest thing to do
<nephele>
waddlesplash: do we have any efi runtime service support already?
<nephele>
nipos: i suppose so, but i would firewall them off based on their ip. However, on the site it sais they respect robots.txt. Seems like a simpler solution?
<nipos>
I'm actually having a rather big list of bots I don't want to access my server,but didn't know until today that Amazon runs such an active bot that accidentally DDoSes stuff
<nephele>
if you don't care about search engines just block all in robots.txt i'd say
<nephele>
then you only need to play whack-a-mole with the rude bots ;)
<nipos>
I allow most search engines,but not AI nonsense and also not Google because they're simply an awful company
<nipos>
Also,not all AI crawlers respect robots.txt so the Nginx config is the safer solution (at least as long as they don't start using normal browser user agents)
<nephele>
personally, i don't think indexing grok makes sense, because grok is a search engine
<nipos>
Yeah,I think the same.The same Nginx User Agent Firewall thingy is used for the whole server,however,not just Grok
<nephele>
maybe add a robots.txt to prevent indexing grok for everyone then
<nipos>
I don't care as long as they don't DDoS me.Problem solved for now by banning the AmazonBot
<nephele>
for a color variable that is used by all programms from the IK, should i declare this as "const" or as "static" or both?
<nephele>
that is, a thing that shouldn't be modified, and does not need to be present severall times
<phschafft>
extern const?
<nephele>
what does extern do?
<phschafft>
static limits the symbol to the current scope (e.g. the function of the control block you're in)
<phschafft>
const tells the compiler that it is constant and cannot be modified.
<nephele>
ah okay. then const should be enough.
<phschafft>
extern tells the compiler that you only want the symbol, the object itself is defined seomwhere else.
<phschafft>
all three of them have an effect on where in memory the object is.
<phschafft>
and how linkage of all of them work.
<phschafft>
if you use const also try to have the value be constant as well, otherwise you will not get runtime access protection.
<nephele>
I'm trying to "clean up" an api detail, lots of programms independently define kBlack = { 0, 0, 0, 255 } So I'm just trying to add a gBlack and gWhite so this is consitent, and no suprises if this is defined somewhere else
<phschafft>
and if it's a complex object (anything not atomic) also make sure all parts are constant, again, otherwise no protection (in this case you can loose runtime and compile time protection, e.g. if you declare the outer object const but not the inner. then writing to the inner is valid as per what you declared)
<phschafft>
which object file does that go into? the main program or any libs?
<nephele>
What do you mean?
<nephele>
I'm working on InterfaceDefs.h in the interface kit, which is compiled into libbe.so const rgb_color gBlack = make_color(0, 0, 0);
<phschafft>
if you replace one of the declares in prog.c to exclude the value you get a random value.
Core9762 is now known as jpelczar
<phschafft>
if you remove the value and add extern you get the value from the lib.
<phschafft>
so what you want in the header is something like: extern const rgb_color gBlack;
bjorkintosh has quit [Remote host closed the connection]
bjorkintosh has joined #haiku
<nephele>
and then where is it supposed to be declared?
<phschafft>
and in the file that implements that, and only in that one code file: const rgb_color gBlack = make_color(0, 0, 0);
<phschafft>
that is the declaration. you mean the definition.
<phschafft>
the definition, again, is in *one* *code* file, the one that implements this.
<phschafft>
and everyone else only has the declaration with extern
<nephele>
so the corresponding .cpp file that happens to not be #included?
<phschafft>
yes.
<phschafft>
that way it will end up in libbe.so
<nephele>
what is the constexpr inline that jpelczar mentioned?
<phschafft>
think of it like this: if you want it to only exist once, then there should only ever be one '=' the compiler is reading about it. ;)
<phschafft>
that is some C++ construct.
<nephele>
Well, this is C++ code, yeah?
<phschafft>
some newer C also seems to have it.
<phschafft>
nephele: but I'm a C guy ;)
<nephele>
pfft
<phschafft>
I *think* and jpelczar may correct me here. that it basically enforce compile time constant values.
<nephele>
It's a different language :)
<phschafft>
but C++ allows for C code to be used within.
<phschafft>
so if that holds true for C it will hold true for C++ (beside some of the strange edge cases of C++)
<phschafft>
also you talked about a InterfaceDefs.h, not a InterfaceDefs.hpp ;)
<nephele>
*shrug*
<phschafft>
and if you want it to be truely C++ then you would have them instances of a proper C++ class ;)
<nephele>
Complain to, I think, Be Inc, for having named it that
<nephele>
Why?
<phschafft>
my point is just that it doesn't matter if you use the more C-ish or the more C++-ish keyword that are both doing the same job. ;)
<phschafft>
the compiler will be happy with both.
<nephele>
It does matter in a different sense: code readability
<nephele>
it's a tad annoying having to wrangle two files for this. All the other "values" of constant #defines are in that file directly, and you don't have to check the .cpp file for them
<phschafft>
nephele: because then you would not waste your global name space but put it as static members of that class.
<phschafft>
and my Understanding that C++'s prime directive is to make stuff object oriented, it's clearly more C++-ish to have them objects. ;)
<nephele>
phschafft: Wenn du nur einen Hammer hast ist alles ein Nagel? :P
<phschafft>
nephele: sure, you can have the values in the header file. no problem with that. just understand that it means that every user of the header (everyone who includes it) has their own copy of the values. Just as for the others that you say are in that header file.
<nephele>
for #defines I don't see how, aren't those simply discarded if not used?
<phschafft>
nephele: even as a C guy I was *very much* confused when I noticed that rgb_color is a struct not a class.
<phschafft>
so taking all langauge rivalry aside I still think it would have been much better to have it as a class/the C++ way.
<nephele>
I don't know why phschafft. but rgb_color is also a tad "icky" in that is only supports 8bit colors, and not 10bit colors or 12bits :) So maybe this shall be redesigned later
<phschafft>
nephele: if you declare it as static const then those symbols are also discarded if unused.
<nephele>
what pager does git use. Why can't i scroll with the mousewheel when i can scoll in less
<phschafft>
if you figure out how to solve that in a way that doesn't break any of the very view features (g)it has, report back to me! ;)
<nephele>
> git diff --color=always | diff-so-fancy | less --use-color
<nephele>
this works
<nephele>
ugh
<nephele>
gonna install execlineb and write me a script that redirects git status + git diff -> diff so fancy both to less .-.
<jmairboeck>
phschafft: struct and class are exactly the same thing, except for the default access level of the members (public for struct, private for class)
HaikuUser has joined #haiku
HaikuUser has quit []
<jmairboeck>
except for Visual C++ (Microsoft's compiler) where they are differently mangled, but that's a bit stupid
<phschafft>
jmairboeck: I don't say that you can't upgrade struct into a class if you use a memory model for classes that is compatible (which is no problem at all).
<phschafft>
however my point is not which keyword is used. but how the different tools are used.
<phschafft>
I would expect a colour value to have some methods to ask it things. which is absent in structs.
<jmairboeck>
they are the same thing, it all comes down to what members they have
Core3394 has joined #haiku
<jmairboeck>
structs can have member fuctions, constructors, destructors, base classes (or structs) as well
<phschafft>
yes, yes. but by that definition classes are completly useless feature of C++ as you can have all that with structs. ;)
<phschafft>
so hey, convert all classes to structs in Haiku! ;)
<jmairboeck>
class Foo : public Bar { public: Foo(); ... }; is the same as struct Foo : Bar { Foo(); };
<Core3394>
class and struct is the same thing for the compiler
<jmairboeck>
that wouldn't even break any ABI or so, because we are not using MSVC
Core3394 is now known as Core8230
Core8230 is now known as jpelczar__
jpelczar has quit [Ping timeout: 480 seconds]
<phschafft>
again, by that definition the class keyword in C++ is redundant.
<phschafft>
however all this has nothing to do with nephele's problem at hand.
<jpelczar__>
one of solutions might be static const(expr) and export the symbols in another cpp file if you really need them exported for ABI compat
<jmairboeck>
you can absolutely add member functions to rgb_color, for example, as long as none of them are virtual, because that would cause a vtable to be generated and thus change the memory layout
<jpelczar__>
as for constructors, I would not recomment defining any in case rgb_color is ever used as part of union or any C structure as this would cause generation of implicing constuctors in "parent" objects. non virtual methods are 100% safe
<nephele>
jpelczar___: Haiku has a coding sprint in brussels now after fosdem
<jpelczar__>
i
<jpelczar__>
I have air plane at 8pm
<jpelczar__>
I wish I found out before booking :(
<nephele>
ow :(
<nephele>
well, maybe we can ping them if they are still around if you want to talk with them
<nephele>
Begasus[m]: are you folks still at fosdem or already left?
<nephele>
Yes, that's fine. I need to fix your whitespace things anyway. So might aswell make a follow up to your change
<nephele>
I'll remove the underscore function and implement the public HasSystemColors instead
<Skipp_OSX>
thanks
<Skipp_OSX>
just make sure to consider read-only tint for BTextView as well as B_NO_TINT in the cases of view and low
<Skipp_OSX>
I think you get it
<nephele>
I think BTextView should use Parent colors by default (also for the text) if you have styling disables
<Skipp_OSX>
naah
<nephele>
why not? :)
<nephele>
You can set your own color after construction if you want
diver has quit [Quit: Leaving.]
<Skipp_OSX>
it uses document colors is why
<Skipp_OSX>
so parent would be panel, no good
<nephele>
doesn't it use the parents background color right now?
<Skipp_OSX>
nope
<nephele>
if not then yes, okay. It should pick document color fg per default for the text
<Skipp_OSX>
I don't think so
B2IA has quit [Ping timeout: 480 seconds]
<nephele>
Skipp_OSX: I'm just guessing how we should do live color update however
<nephele>
if styling is disabled, and no color was ever applied, we should do auto-updates
<nephele>
but if styling is enabled i think this should be up to the caller
<Skipp_OSX>
right, isn't that how it works?
<nephele>
Does it auto-update colors now?
<Skipp_OSX>
it uses document colors, with or without a tint
<Skipp_OSX>
yeah it does
<nephele>
Okay, that should be fine then
<Skipp_OSX>
+1
<Skipp_OSX>
well... except for the text color...
<nephele>
that is what i ment, yes
<Skipp_OSX>
yeah that doesn't get auto-updated right now, perhaps it should.
<nephele>
that is also the only thing that is affected by the styling setting
<Skipp_OSX>
BTextView does just use HighUIColor for drawing text bc you can have differently styled text
<nephele>
your AdoptSystemColor commit mentions -> Does not alter text color.
<nephele>
I think it should
<nephele>
It should if you have styling disabled
<Skipp_OSX>
yeah, see above, SetTextColorAndFont() or whatever it's called
<Skipp_OSX>
I see, in that case it should but it currently doesn't I think.
<Skipp_OSX>
it sets the high ui color, just never actually uses it.
<nephele>
I'll check in a bit on how to properly solve this, so the common case of "just add a BTextView and dumb text" works
<Skipp_OSX>
k
<nephele>
and leave the complex path for callers who enable styling
<Skipp_OSX>
hopefully we can get all the colors patched up by beta6
<nephele>
I'm quite happy with the progress we are making, when i started with Haiku dark mode was a bit "yeah it kinda works if you modify all these colors manually, except <50 items>". We are almost at a Works out of the box experience at this point
B2IA has joined #haiku
<Skipp_OSX>
yes it is much improved from how it was
x10z has joined #haiku
<nephele>
I've not found where most colors don't use control anyhow
<nephele>
Adding AdoptSystemColors to BControl didn't seem to "do" much
<nephele>
I think the BPopUpMenu and parent class should use Control collor, and BSpinner, for a start
<nephele>
also Scrollbars and scrollbar end caps
<nephele>
> Too many errors to list here
<nephele>
Uh oh... gcc2, i was not looking forward to this
<Skipp_OSX>
correct, not much does, needs fixing, you gotta update the color to match panel first
<nephele>
It shouldn't match panel anymore
<Skipp_OSX>
why not?
<Skipp_OSX>
I mean it never did technically
<nephele>
check my other patch to modify the gradient for Glossy gradients in HaikuControlLook
<Skipp_OSX>
but effectively it has since all the elements that should be using control background are using panel background or are tinted to match
* Skipp_OSX
angerly -2's chang
<nephele>
with a more true-to-the-color gradient it starts looking bad. so now we can make control color a bit lighter to get closer to the previous rendering ;)
<Skipp_OSX>
the one that adjusts the tints?
<Skipp_OSX>
yeah the current gradients are no good in dark mode, not enough contrast too much shine
<Skipp_OSX>
Start by changing B_CONTROL_BACKGROUND_COLOR to match B_PANEL_BACKGROUND_COLOR, then remove that tint from BButton, then you may go buck wild making everything use B_CONTROL_ colors
<nephele>
> I'm saying change the default control color so you DON'T have to tint it.
x10z has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
<nephele>
So we are on the same page :)
<Skipp_OSX>
yes, if you understand we are.
<nephele>
I already removed the tint from BButton in that patchset
x10z has joined #haiku
<Skipp_OSX>
like I said, change the default color first, then all your tint numbers will change
x10z has quit []
<nephele>
There is only one tint color to change. Just remove this
<Skipp_OSX>
mmmm I think that's correct
<nephele>
if it's only used by BButton anyway? :)
<Skipp_OSX>
not 100% sure there may be other cases lurking
<nephele>
we can argue about the right colors later, since this makes some stuff more closer to each other this will change rendering anywaya
<Skipp_OSX>
it's only used by BButton in our sources, but not in the totality of all BeOS/Haiku software
<nephele>
currently BButton and Scrollbar are different to each other because of this mismatch, but afterwards this doesn't need to be the case
<nephele>
and if there is any "artistic" tinting it should be done internally in ControlLook
<Skipp_OSX>
yep, and slider thumb should use control loo
<Skipp_OSX>
*too
<nephele>
yeah
<nephele>
anyway, i'm not *too* worried about the default colors. But more about the color generation code that spits out colors. That is where we should define how control color should behave, anyhow
<Skipp_OSX>
yeah but I am
<Skipp_OSX>
I just don't don't want you to adjust a bunch of tints off the wrong color
<nephele>
the default colors should be adjusted to whatever the generation code outputs for the default panel color once we are happy with this
<Skipp_OSX>
change the default color now
<Skipp_OSX>
first I mean
<nephele>
I'm not testing with any default colors, so not sure how that would help with the dev :/
<Skipp_OSX>
:/
<Skipp_OSX>
push the Defaults button!
<Skipp_OSX>
we do need to implement savable color schemes...
<nephele>
Yeah but, I work on dark mode, because light mode frequently hurts my eyes... :)
<nephele>
No we don't. Just use themeManager, or copy the file somewhere else
<Skipp_OSX>
ok but for testing you'll have to deal with the eye strain
<Skipp_OSX>
yeah would be nice if was built in
diver has joined #haiku
<Begasus[m]>
> I talked I think to pulkomandy
<Begasus[m]>
> yesterday morning (I was in glowing silver jacket)
<Begasus[m]>
so that was you :)
<Skipp_OSX>
not too much to ask to save your color scheme to a flattened BMessage and unpack it
<Begasus[m]>
back home, finaly some coffee! :)
<nephele>
I do not. Since control color is then "self-contained" it doesn't matter if the new default is different or not
<Begasus[m]>
nephele_xmpp: you mentioned qauterion is broken?
<nephele>
we develop this, and have to adjust rendering in comparison to each other
<Begasus[m]>
running it now
<nephele>
Begasus[m]: in dark mode I get a white timeline
<nephele>
this was a problem in the past at some point, but kitsune fixed this afterwards, so i have no clue what is gone wrong now
<Begasus[m]>
ah right, doesn't follow dark mode (system) correctly
<nephele>
yeah but this used to work Begasus[m]
<Begasus[m]>
maybe could poke kitsune on what has changed
<nephele>
kitsune said nothing changed
<Begasus[m]>
he's in neochat room mostly
<Begasus[m]>
ah you already talked to him
<Begasus[m]>
back then it worked for both Qt versions?
<nephele>
Skipp_OSX: I'm not talking about eye strain, I'm talking about physical pain :P
<nephele>
as in, can't turn on the lights because that hurts too much pain. Not that I have that every day but it is a bag reason why I use dark mode. And even in light mode i use a "muted" one
<scanty>
Begasus[m]: KMail finally works on my sytem! i'm going to see if my e-mail works with it
<Skipp_OSX>
eye strain is physical pain
<Begasus[m]>
oh whoot, haven''t checked there for a long time scanty !
<nephele>
This isn't eye straing, it's sensory input processing. I have the same with sound where sometimes everything is too loud and causes pain.
<Skipp_OSX>
I find it hard to believe that our default colors cause sensory input processing issues.
<nephele>
Heh, but anyway. I recognize this is a non-issue for "most" people. It just isn't for me
<nephele>
take for example looking into the sun, that causes direct pain for people usually. I have this with less intense colors/light. Doesn't really help that Computer screens are emissive, and not reflective, like a book
<nephele>
white sunlight is also "neutral" in such a sense
<Skipp_OSX>
additive vs. subtractive colors
<nephele>
anyway, Dark mode helps a lot for this. And OLED helps even more, if properly configured ;)
<Skipp_OSX>
well, you'll have to muddle through somehow if you want to fix the colors, then you can go back to dark mode
<nephele>
Luckily I have people to review patches if i screw up
<nephele>
But for what looks "good" in light mode you'll really have to step up, because I simply don'
<nephele>
t know, i don't use it
<nephele>
or anyone else really, for one patch for invalid colors humdinger tested colors for example
B2IA has quit [Quit: Vision[]: i've been blurred!]
jpelczar has joined #haiku
jpelczar__ has quit [Read error: Connection reset by peer]
jpelczar_ has joined #haiku
B2IA has joined #haiku
HaikuUser has joined #haiku
HaikuUser is now known as ehlo1
jpelczar has quit [Ping timeout: 480 seconds]
<ehlo1>
Hi nephele: I've updated https://dev.haiku-os.org/ticket/17800#no3 with a linux dmesg and the haiku syslog. Not familar with trac, so I don't know how to cc you on the ticket
Nasina has quit [Read error: Connection reset by peer]
<nephele>
hi ehlo1, i asked you to add it to new ticket if this is a different device, which it is in this case. The fix and cause may be different. CCing me was in relation to that, when you create a new ticket you can simply fill out the cc field :)
<ehlo1>
Oops :) Wiill open a new ticket. Apologies
Nasina has joined #haiku
<nephele>
no problem :)
mmu_man has joined #haiku
ehlo1 has quit [Quit: Vision[]: i've been blurred!]
<Skipp_OSX>
The point of inheritance in this case is to provide an interface.
<Skipp_OSX>
"BControl is an abstract class for views that draw control devices on the screen." although that's not strictly true, it's not actually an abstract class, you're supposed to think of it as if it were one.
<Skipp_OSX>
It provides a basic implementation what you're supposed to replace with your own to do the thing you want to do. BControl provides the hooks for you to hook into.
<x512[m]>
Also unlike BeOS, Haiku now support transparent views, so it is not required to draw control background color.
<Skipp_OSX>
You can change the control color though, so it's meant to be independent.
HaikuUser has joined #haiku
Habbie has joined #haiku
HaikuUser has quit []
<Habbie>
i met Begasus[m] and PulkoMandy and depending on how much attention mmu_man was paying during eating his fries, him too ;)
<x512[m]>
Not using transparent background is probably even makes drawing slower because of multiple background drawing vs single drawing in a root view.
<Skipp_OSX>
I just addressed that though, it's meant to be independent, not transparent.
<nephele_xmpp>
Habbie: Cool!
<Habbie>
and! i got a haiku r1beta1 CD
<Habbie>
this will be very helpful in installing it on my chromebook
Nasina has quit [Read error: Connection reset by peer]
Nasina has joined #haiku
illwieckz_ has joined #haiku
hightower3 has joined #haiku
mmu_man has quit [Ping timeout: 480 seconds]
HaikuUser has joined #haiku
HaikuUser has quit []
x10z has joined #haiku
<nephele_xmpp>
doubtfull, it’s liike a 4 step process to update to beta5 from itt, and i didnt document it
<nephele_xmpp>
Skipp_OSX: what do you want to use other colors for?
<Skipp_OSX>
for example used in Gravity screen savers
<Habbie>
nephele_xmpp, sorry, bad joke. it doesn't even have a CD drive :)
<Skipp_OSX>
Spider too
<nephele_xmpp>
Skipp_OSX: yeah but almost all semantiic colors “ a blue” “a red” need to be adjusted for which background they are. going to be used against, which text color will be used etc
<Skipp_OSX>
nah, gRed is 255, 0, 0 255 anything else is not gRed
<Skipp_OSX>
you can use your own red color sure, but as far as providing system colors, we should provide the basic ones.
MisthaLu has quit [Quit: Leaving]
<Skipp_OSX>
I use kRed for example in my color pickers as the default color, although you haven't seen that patch set yet but it's getting very close now.
<nephele_xmpp>
No, i don’t think so. Because when i made the patch for gBlack i found severall apps using diifferent constants for exactly thhe same color names
<nephele_xmpp>
black and white is unambigious in this context
<Skipp_OSX>
so is red, blue and green at least
<Skipp_OSX>
the rest are web colors that use 127 which is also pretty standard/univesal.
<Skipp_OSX>
like I said, if you don't want to include fuchsia or whatever, that's fine.
<nephele_xmpp>
I dunno. I think those constants are not usefull unless you want to do something very specific
<Skipp_OSX>
well, some are useful for YMCK specifically yellow, magenta (which it calls fuchsia annoyingly) cyan and black.
<Skipp_OSX>
navy, tell, olive, green (which is really not green) orange, maroon and purple are debatable.
x10z has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
<nephele_xmpp>
don’t see how that color model is relevant unless you want to specifically print stuff. Anyhow, i think the utility of constants like this is not high. An api to get standard colors adjusted would be neat though
<Skipp_OSX>
yeah well, I mean, you're supposed to be able to print stuff on Haiku
<Skipp_OSX>
You're stuck in a subtractive color model paradigm that's your problem
x10z has joined #haiku
<Skipp_OSX>
meaning red + green + blue = black, but magenta + cyan + yellow = white
<nephele_xmpp>
I know you can. And it doesn’t matter still, because this is all UI code
jpelczar_ has quit [Quit: CoreIRC for Android - www.coreirc.com]
<nephele_xmpp>
you *can* print with it, if you want, but we don’t have any way to proppagate those colors instead of rgb_color, instead it just converts at the last step
mmu_man has joined #haiku
<nephele_xmpp>
anyhow to simplify such things i usually go and check what common patterns are in apps and how to improve these to make them easier
<nephele_xmpp>
but with any colors that aren’t white or black it’s recently always either isLight()? hardcoded: hardcoded2
<nephele_xmpp>
or adjusting the color to properly fit
x10z has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
<Skipp_OSX>
the ones at the bottom should all be considered optional/questionable
<Skipp_OSX>
Stop at purple and leave out maroon, navy and teal I'd be ok with that
<Skipp_OSX>
orange is also questionable apparently there is a hot debate on the Internet about what the "true" orange color should be, but they have standardized on 255, 165, 0
<nephele_xmpp>
I still disagree, if you want to add these semantic colors that is cool by me, but do it with an api that can return values based on your lightness you need
<nephele_xmpp>
hardcoding constants is just stupid for these
mmu_man has quit [Ping timeout: 480 seconds]
<nephele_xmpp>
especially 8bit based ones, when we ideally should run on 10bit or 12bit color depth displays in the future
<x512[m]>
Printing is currently implemented by recording BPicture and converting it to BPF or printer/specific format. BPicture use regular RGB colors.
<Skipp_OSX>
My Out of Gamut control in Colors! is awaiting proper CMYK support be added to Haiku
x10z has joined #haiku
<Skipp_OSX>
I implemented Web Safe, and the interface for Out of Gamut but no implementation is yet available for it.
Nasina has quit [Remote host closed the connection]
<x512[m]>
BPF -> PDF
<Skipp_OSX>
I started looking into it and I went cross-eyed.
<x512[m]>
CMYK support is non R1 feature anyway.
<Skipp_OSX>
color profiles are not easy.
<Skipp_OSX>
true, but can I just have the color constants for R1?
Nasina has joined #haiku
<Skipp_OSX>
don't we have an hsv_color now?
<x512[m]>
How if everything is hardcoded to rgb_color?
<Skipp_OSX>
it's not, not _everything_ just 99%
<x512[m]>
Including BPicture commands that are used for printing.
<Skipp_OSX>
app server does not support ymck correct
<nephele_xmpp>
hsl_color, not hsv
<Skipp_OSX>
...
<Skipp_OSX>
can I get a type constant for that anyway? Like B_RGB_COLOR_TYPE but for hsl
<Skipp_OSX>
I'd like to implement support for it in Colors!
<nephele_xmpp>
I don’t understand what you want?
<Skipp_OSX>
Add a value for it to TypeConstants.h
<nephele_xmpp>
for what purpose?
<Skipp_OSX>
to read hsl_color values in messages into Colors! and send them back
<nephele_xmpp>
Nothing, and i mean notthing, accepts hsl colors
<nephele_xmpp>
just convert them to rgb and send them away
<Skipp_OSX>
and they never will with that attitude!
<Skipp_OSX>
yeah that's what I'm currently doing
<nephele_xmpp>
Skipp_OSX: I think we might need a more expressive class for this, for specific colors, and for semantic colors. I think it is unreasonable to add support for every color system everywhere in the api
<Skipp_OSX>
Like I said, limit to the colors you deem appropriate. I'd just like a few basic colors.
<Skipp_OSX>
If you don't implement them, I'll continue to use my own k versions.
<nephele_xmpp>
I think gWhite and gBlack are apropriate, and not more in that api space for now
<Skipp_OSX>
not even red, green, blue?
<nephele_xmpp>
not even those have agreed upon definitions in apps we already ship
mattlacey has joined #haiku
<Skipp_OSX>
that's also true for white and black, we use different shades, so what?
<nephele_xmpp>
no we don’t, all cases I removed have been exactly 0 or exactly 255
<nephele_xmpp>
and I don’t see any more instances of those
<Skipp_OSX>
ok but also for red, green, blue the same right?
<Skipp_OSX>
Icon-O-Matic has a non (0, 0, 0) black color
<nephele_xmpp>
I’ve seen severall conflicitting definitions for red
<Skipp_OSX>
gRed is always 255, 0, 0 though
<Skipp_OSX>
app devs are free to create their own red, unless you're saying they are already making their own gRed?
<nephele_xmpp>
I don’t see that, i only see pure black in Icon-O-Mattic
<nephele_xmpp>
they already make their own kRed
<nephele_xmpp>
with conflicting definitions
<x512[m]>
Skipp_OSX: Colors! may define its own clipboard type.
<Skipp_OSX>
not using drag and drop for this, message passing interface
<Skipp_OSX>
Colors! 3.0 you are not privy to the new version yet.
<Skipp_OSX>
(in development, almost finished)
Anarchos has joined #haiku
x10z has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
x10z has joined #haiku
<nephele_xmpp>
are you moving more color pickers to libshared?
<nephele_xmpp>
I really want someoen to replace that ugly 3 bar picker in appearence
hotdogs has quit [Quit: Vision[]: i've been blurred!]
<Skipp_OSX>
add-ons, yeah
mmu_man has joined #haiku
Nasina has quit [Read error: Connection reset by peer]
<x512[m]>
Skipp_OSX: Doesn't it conflict with previous/next tab shortcut?
mattlacey has quit [Ping timeout: 480 seconds]
<Skipp_OSX>
I check for conflicts with app shortcuts and don't add the shortcut if so
Anarchos has quit [Quit: Vision[]: i've been blurred!]
<Skipp_OSX>
We were doing that before, the same system is expanded to the new shortcuts.
HaikuUser has joined #haiku
<HaikuUser>
hello
HaikuUser is now known as mikezt
Nasina has quit [Read error: Connection reset by peer]
<waddlesplash>
Skipp_OSX: but are tab switching shortcuts handled that way? admittedly I have not checked
<waddlesplash>
also don't forget to close the tickets when you push changes
<Skipp_OSX>
I like to leave a grace period before closing tickets
<Skipp_OSX>
all shortcuts in BTextView are handled that way, yes.
<waddlesplash>
I don't think any grace period makes sense. just close the tickets and reopen if there's a problem later.
<nephele_xmpp>
I don’t understand that. I also leave tickets open when users reported them to wait if it is fixed in their eyes too.
<waddlesplash>
okay but then at least comment on the ticket
<waddlesplash>
right now the tickets have not been changed at all
Nasina has joined #haiku
<waddlesplash>
anyway, bbl
<nephele_xmpp>
Skipp_OSX: can you pick up the documentation par from 8877 to your changeset? I can then abandon it (the part that mentions the color functions are reimplemented for controls)
<Skipp_OSX>
sure thing
jmairboeck has quit [Quit: Konversation terminated!]
x10z has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
x10z has joined #haiku
<Skipp_OSX>
I commented but did not close either ticket.
<Skipp_OSX>
7078 because of missing function key shortcut support and 9913 because of still being blocked by 9431 and X512 not giving me the green light on my fix for that one.
<x512[m]>
Skipp_OSX: previous/next tab is a global app_server SAT behavior shortcut.
<Skipp_OSX>
can you please green light my change so that I may use word wise naviation in stack groups?
<Skipp_OSX>
I know you're going to say no...
Nasina has quit [Read error: Connection reset by peer]
Nasina has joined #haiku
x10z has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
<x512[m]>
Skipp_OSX: > I also wanted the ability to have shortcuts for the function keys (F1-F12.)
<x512[m]>
What is a problem with my patch that add uint32 key code argument?
<Skipp_OSX>
Well firstly it doesn't currently work for function keys, secondly we want to do it a different way by patching the char parameter of BMenuItem. See the recent devel mailing list discussion for more details.
<Skipp_OSX>
Thirdly you have still not given me an example of a function key shortcut to test with and nobody seems like like F2 to rename in Tracker.
<x512[m]>
Using char for that is probably bad idea.
<Skipp_OSX>
It was a bad idea for sure.
<x512[m]>
It should be B_FUNCTION_KEY and key code.
<Skipp_OSX>
those conflict with existing shortcuts, B_TAB, B_ENTER/B_RETURN, B_BACKSPACE, B_INSERT
<x512[m]>
Why it will conflict?
<Skipp_OSX>
because 0x08 for example is both B_F7_KEY and B_BACKSPACE
Babaj has joined #haiku
<x512[m]>
Shortcut char will be the same B_FUNCTION_KEY.
<Skipp_OSX>
It would work with B_FUNCTION_KEY_BASE + B_F7_KEY like you had it.
<x512[m]>
And actual key code provided in a separate argument.
<Skipp_OSX>
yeah I get it, but we don't want to do it that way I don't think
<Skipp_OSX>
Personally I think we should simply take up the remaining spots in the control characters with B_F1 through BF12, there is a contiguous block of unused codes.
<Skipp_OSX>
We just have to define new constants.
<PulkoMandy>
we should not do that
<Skipp_OSX>
why not?
<PulkoMandy>
functions keys are not ASCII, should not be ASCII, should not pretend to fit in ASCII
* Habbie
waves at PulkoMandy
<Skipp_OSX>
neither is B_TAB, B_ENTER, etc.
<PulkoMandy>
they are raw key codes, pretending otherwise will just cause confusion and bugs
<Skipp_OSX>
no no no, we define new constants, don't use those.
<Skipp_OSX>
the key code is B_F1_KEY, we make a new B_F1 with no _KEY
JigyasuRajput[m] has joined #haiku
AlienSoldier has joined #haiku
<nephele_xmpp>
Skipp_OSX: i think you have it backwards with the control color. It isn’t used tinted to look like Panel colors now. The butttons and PopupMenu etc don’t looke the same.
<nephele_xmpp>
Button tints a bit in the direction maybe, but i am removing those tints. so if anything we should check what the color is *after* that tinting is removed, and also the defaultt colors do not matter if the color generation code does not match this.
<Skipp_OSX>
There's a gradient but it basically matches
<nephele_xmpp>
It does not, it makes all color steps much lighter
<nephele_xmpp>
My patch fixes that
<nephele_xmpp>
but it also makes control which incorrectly used panel color before… look too much like the panels they are in
<Skipp_OSX>
Look all I want is to make the default 216, 216, 216, and then you can fixup the gradients on top of that to look any way you want.
<Skipp_OSX>
Right so we make it 216 and then adjust the values in your patch to make the color steps lighter again, great.
<nephele_xmpp>
No, that is backwards. I will change the color to match the rendering, not tint the buttons to match some random color
<Skipp_OSX>
You're changing it for HaikuControlLook, but this is a change for _all_ control looks.
<Skipp_OSX>
even future ones not yet written.
<nephele_xmpp>
Indeed! HaikuControlLook should make a rendering more matching to the actual color
<nephele_xmpp>
And not make it much lighter for no reason
<Skipp_OSX>
Can't you adjust the tints to make it the color you want in HaikuControlLook on top of 216?
<nephele_xmpp>
No, that makes no sense to do
<Skipp_OSX>
but can you do it?
<nephele_xmpp>
I fixed the gradient-> now i need to fix the color
<Skipp_OSX>
ug
<nephele_xmpp>
but you are suggesting to hardcode the color to a value that makes it look terrible
<nephele_xmpp>
*Or* I tint every control in IK, which I won’t do
<Skipp_OSX>
well, it makes it match panel
<nephele_xmpp>
yes, it shouldn’t and it right now doesn't
<Skipp_OSX>
that's true, right now it doesn't
<Skipp_OSX>
but it SHOULD
<nephele_xmpp>
No
Babaj has quit [Quit: Leaving]
<Skipp_OSX>
So then why are we tinting it to match in BButton?
<nephele_xmpp>
We are not
<nephele_xmpp>
The colors are not matching
<Skipp_OSX>
Can you test my patch and see?
<Skipp_OSX>
Buttons should come out the same or very similar to now once the tint is taken off
<nephele_xmpp>
I don’t see why? I’d rather continue developing my changeset properly without beeing tied to this arbitrary value for the *input* to the control color calculation
<nephele_xmpp>
I’d had hoped to do smaller patches, but i guess I have to do a big one if every cleanup is bad because “this changes the rendering”. Indeed it does, but that is the point
<Skipp_OSX>
specifically "To maintain the identical appearance as before, the default control background color is tinted to match the default panel background color."
<nephele_xmpp>
> As the color has a gradient applied anyway, no one will notice a
<nephele_xmpp>
difference while playing with custom control colors.
<nephele_xmpp>
What you fail to see here is that this is a HaikuControlLook specific hack
<nephele_xmpp>
it does *NOT* match, it only looks mostly similar
<nephele_xmpp>
And with the gradient change it will even more not match.
<Skipp_OSX>
I fail to realize? I didn't do that patch, looncraz did
<nephele_xmpp>
You brought it up?
<Skipp_OSX>
ok but make it match that's fine, I don't want to ruin that I support your work, I'm trying to support it.
<Skipp_OSX>
looncraz failed to realize
<Skipp_OSX>
all I did was adjust the tint to make his hack work in both light and dark modes
<nephele_xmpp>
Well okay, I think your patch is fine apart from changing the color, that at this time makes no sense to me
<Skipp_OSX>
well it does make sense, can you test it?
<nephele_xmpp>
I already have the patch to make the gradient match the color more closely, and once the other controls use the right color we can compare 1:1 with beta5 to decide what color we want for controls, and what the automatic color code should generate
<Skipp_OSX>
you can't recalculate the tints?
<Skipp_OSX>
see this is what I didn't want to happen
<nephele_xmpp>
tints in interface kit are wrong becausse that removes the agency from the control look, and in the haiku control look itself I don’t want to use tints based on the base color because the controls as HaikuControlLook draws them are supposed to look the same and not different, and tinting in any direction kind of undermines that
<nephele_xmpp>
> see this is what I didn't want to happen
<nephele_xmpp>
don’t quite understand what you mean?
Nasina has quit [Read error: Connection reset by peer]
Nasina has joined #haiku
<Skipp_OSX>
which is why I asked you to change the base color before...
<Skipp_OSX>
otherwise we'll reintroduce #12568
<Skipp_OSX>
I'll have to fixup BeControlLook although it looks like I may have to do that anyway for dark mode
<nephele_xmpp>
#12568 is back once you set any color in the automatic mode not matching that ting. The fix is wrong
<nephele_xmpp>
Flat buttons should draw their background with the parent color
Nasina has quit [Remote host closed the connection]
Nasina has joined #haiku
<Skipp_OSX>
can you make it work off of untinted 245, 245, 245?
<Skipp_OSX>
We could keep the button color the same, remove the tint from BButton I suppose
<nephele_xmpp>
anyhow, why are you worried about that now? we are in the nightly cycle so i don’t think it’s too important if stuff is a bit broken intermitendly. I can take a look at a better fix for that issue though, I’ve seen that for years but always assumed it was intentional how it looked :P
<Skipp_OSX>
this has been a _long_ time coming
<nephele_xmpp>
in BButton::AttachedToWindow() it should be able to check if it is “flat” style and then draw with the parent color, no?
<nephele_xmpp>
for the background
<Skipp_OSX>
it could tint it I suppose
<nephele_xmpp>
or well, just check that in the Draw method I think
<Skipp_OSX>
That's basically what it's doing already minus the check for flat style bit
<nephele_xmpp>
Why tint? if the parent is a panel just use the parents low color in Draw instead?
<Skipp_OSX>
because buttons have those color constants assigned.
<Skipp_OSX>
Fix up in the Draw() code wouldn't work for different decorators
<nephele_xmpp>
yes but a “flat” style buttton is not visible as a button other than in Hover
<nephele_xmpp>
why? is flat button style specific to HaikuControlLook?
<nephele_xmpp>
I thought this is mainly for “Toolbar” types of items
<Skipp_OSX>
we draw everything in a control look
<Skipp_OSX>
I thought so anyway
<nephele_xmpp>
Yeah, but i mean. A different control look also has to check for flat vs non-flat button
<nephele_xmpp>
because this is an api difference
<nephele_xmpp>
so basically parent color for flat color; control color for flat button hover and normal
<Skipp_OSX>
yeah it's in the control look, flat vs. non-flat I think
<Skipp_OSX>
but the base color is also passed in, which is currently tinted and that's the problem
<Skipp_OSX>
or the fix for the problem idk
<nephele_xmpp>
Yeah, so I would use Parent color for flat & not hovered butttons. and control color (untinted) for the rest
<Skipp_OSX>
no access to that in control look
<Skipp_OSX>
all you get is a single base color
<nephele_xmpp>
Yes, but in the IK that calls the controllook
<nephele_xmpp>
that’s the logic i would use there to call it. The only other option would be to change the signature and send the parent color as a second color and let the controllook decide if it likes flat buttons.
<Skipp_OSX>
it could work, but I don't want to do that, I'd rather it use 216 all the time
<Skipp_OSX>
I'm not convinced there is a problem with your code at all
<Skipp_OSX>
because the color you're getting in HaikuControlLook should be the same as before
<nephele_xmpp>
:/ . we are not in the domain of hardcoded colors anymore. Any solution trying to match up the two colors is wrong and can’t work.
<nephele_xmpp>
A solution working only for default colors is not good enough :)
<nephele_xmpp>
and if we need to change the signature for the controllook function we can do that too
x10z has joined #haiku
mmu_man has quit [Ping timeout: 480 seconds]
mikezt has quit [Quit: ret]
<Skipp_OSX>
but I'm saying your tints should work identically to before, please test it and let me know.
Nasina has quit [Remote host closed the connection]
Nasina has joined #haiku
mmu_man has joined #haiku
<nephele_xmpp>
They definetely won’t. because I’m not using default panel colors
xet7 has quit [Remote host closed the connection]
wicknix_ has quit [Ping timeout: 480 seconds]
jnn is now known as jn
<Skipp_OSX>
are you using the passed in base color?
<Skipp_OSX>
you're using B_CONTROL_BACKGROUND_COLOR aren't you?