https://bugs.documentfoundation.org/show_bug.cgi?id=108670
--- Comment #15 from Tamás Zolnai <zolnaitamas2...@gmail.com> --- (In reply to Ekansh Jha from comment #14) > (In reply to Tamás Zolnai from comment #13) > > (In reply to Tamás Zolnai from comment #11) > > > (In reply to Heiko Tietze from comment #10) > > > > The active color shows how the object is defined currently. Meaning > > > > when you > > > > have a shape the #729fcf is effective and works properly. When you come > > > > from > > > > an undefined state, meaning no color or a different type of filling is > > > > set, > > > > it could indeed be crossed out and the RGB/Hex values could be cleared. > > > > > > > > Don't remember why this wasn't implemented correctly. Do you remember, > > > > Jay? > > > > > > I'm not sure any crossed-out thing is implemented anywhere in the code. > > > Also > > > clearing the RGB/Hex values might be tricky, since this kind of number > > > fields always show someting. So from that point it's not an easy hack. > > > > > > @ Ekansh Jha, I suggest you to find another easy hack for hacking. I'll > > > remove this one from the easy hack list. > > > > @ Ekansh Jha: Sorry for that, I expected to have the same "No fill" behavior > Please don't be > > what we already have in other cases (e.g. character highlighting), but it's > > OK, if UX guys, want something different. > btw Thank you for informing early. A very similar issue is bug 111769. There the new color is set someting wrong when the dialog initialized. -- You are receiving this mail because: You are on the CC list for the bug. _______________________________________________ Libreoffice-ux-advise mailing list Libreoffice-ux-advise@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/libreoffice-ux-advise
