Warning: session_start(): open(/tmp/sess_frpnkfkkqif1opm2ln2k1lhv42, O_RDWR) failed: No space left on device (28) in /www/H01/htdocs/lib/base/lib_base.php on line 280
Kde4 style:reverse fonts color if needed openDesktop.org
-
 KDE-Apps.org Applications for the KDE-Desktop 
 GTK-Apps.org Applications using the GTK Toolkit 
 GnomeFiles.org Applications for GNOME 
 MeeGo-Central.org Applications for MeeGo 
 CLI-Apps.org Command Line Applications 
 Qt-Apps.org Free Qt Applications 
 Qt-Prop.org Proprietary Qt Applications 
 Maemo-Apps.org Applications for the Maemo Plattform 
 Java-Apps.org Free Java Applications 
 eyeOS-Apps.org Free eyeOS Applications 
 Wine-Apps.org Wine Applications 
 Server-Apps.org Server Applications 
 apps.ownCloud.com ownCloud Applications 
--
-
 KDE-Look.org Artwork for the KDE-Desktop 
 GNOME-Look.org Artwork for the GNOME-Desktop 
 Xfce-Look.org Artwork for the Xfce-Desktop 
 Box-Look.org Artwork for your Windowmanager 
 E17-Stuff.org Artwork for Enlightenment 
 Beryl-Themes.org Artwork for the Beryl Windowmanager 
 Compiz-Themes.org Artwork for the Compiz Windowmanager 
 EDE-Look.org Themes for your EDE Desktop 
--
-
 Debian-Art.org Stuff for Debian 
 Gentoo-Art.org Artwork for Gentoo Linux 
 SUSE-Art.org Artwork for openSUSE 
 Ubuntu-Art.org Artwork for Ubuntu 
 Kubuntu-Art.org Artwork for Kubuntu 
 LinuxMint-Art.org Artwork for Linux Mint 
 Arch-Stuff.org Art And Stuff for Arch Linux 
 Frugalware-Art.org Themes for Frugalware 
 Fedora-Art.org Artwork for Fedora Linux 
 Mandriva-Art.org Artwork for Mandriva Linux 
--
-
 KDE-Files.org Files for KDE Applications 
 OpenTemplate.org Documents for OpenOffice.org
 GIMPStuff.org Files for GIMP
 InkscapeStuff.org Files for Inkscape
 ScribusStuff.org Files for Scribus
 BlenderStuff.org Textures and Objects for Blender
 VLC-Addons.org Themes and Extensions for VLC
--
-
 KDE-Help.org Support for your KDE Desktop 
 GNOME-Help.org Support for your GNOME Desktop 
 Xfce-Help.org Support for your Xfce Desktop 
--
openDesktop.orgopenDesktop.org:   Applications   Artwork   Linux Distributions   Documents    Linux42.org    OpenSkillz.com   
 
Home
Apps
Artwork
News
Groups
Knowledge
Events
Forum
People
Jobs
Register
Login


-
- Content .- Fans  . 

Kde4 style:reverse fonts color if needed

  

KDE4 Brainstorm

Score 44%
Kde4 style:reverse fonts color if needed
zoom


Kde4 style:reverse fonts color if needed
zoom


Link:  http://
Downloads:  153
Submitted:  Apr 5 2006

Description:

Actually, if in a theme/style the background of something
(toolbar, menubar, menus , statusbar) is dark and the fonts are dark , or it's light and the fonts are white, you'll read nothing (check screen #1, this is the best I could do to keep reading
the kmenu and the kicker icon popups).

Adding a check "per part" (one check for menubar, one for toolbar, etc) to reverse
the font color (negate if you prefer:
Red=255-Red,Green=255-Green,Blue=255-Blue)
might fix this.
As a result all fonts would be highly readable as per screenshot #2.

Here is an example of the algorithm:
(140 is 60% luminosity, 80 is 30% luminosity)
if ( bgcolor.luminosity is less than 140 AND fontcolor.luminosity is less than 80 ) OR (bgcolor.luminosity is more than 115 AND fontcolor.luminosity is more than 175) then
{reverse font color algorithm}.

This would help in darker theme creation.




LicenseGPL
Send to a friend
Subscribe
Other  Content  from mattepiu
Report inappropriate content



-

 hähhh?

 
 by thomas12777 on: Apr 5 2006
 
Score 50%

i see why it can make sense to perform a color check on html items (gee please someone forbid wysiwyMg html editors) but what sense does this make for a style?
if the user wants a specific color scheme he/she should get it (checked black on black? your fault.) and if a style wants to change the background of a specific widget, it should automatically change the foreground as well (e.g. by swapping the palette as you did on your code) - qt3 has here a small bug as the palette function to calculate the foreground from the background fails if you set the background mode to e.g. PaletteForeground, but i guess it's fixed in qt4 and currently a style developer can work around by swapping the palette in the polishment

so: what exactly do you want to gain by separated color defines?


Reply to this

-

 Re: hähhh?

 
 by mattepiu on: Apr 5 2006
 
Score 50%

Check screenshot #1, the color of the font in the statusbar and those in the left panel (favorites, blue background) is always the standard text color.

We could scorporate it but would means lots of fonts color more to define,
instead having this method optional the
problem would be fixed with the same number of user-defined colours as kde 3.5


Reply to this

-

 Re: Re: hähhh?

 
 by thomas12777 on: Apr 5 2006
 
Score 50%

ok, but this is an app or widget bug - nothing about the style.

the problem here is that the developer set the foreground mode to "Text" where it should have been "ButtonText" or "Foreground" - those are different colors, though far often the same (black...)
so if you find such behaviour, you should file a bugreport to KDE and tell them to fix up the widget to please use the proper foreground mode in accordance to the background mode (i.e. Button -> ButtonText, Base -> Text, Background -> Foreground)


Reply to this

-

 Re: Re: Re: hähhh?

 
 by mattepiu on: Apr 5 2006
 
Score 50%

But wouldn't be 2 times as fast to bypass
styles and provide a similar function
within kwin ? Could be optional, and "fix"
every kde style/widget (cause all have
this issue), could be an option more in
kcontrol -> Themes -> Fonts or in
kcontrol -> Themes -> colors.

(sorry for "Themes", I'm using a localized
version of kcontrol)


Reply to this

-

 Re: Re: Re: Re: hähhh?

 
 by thomas12777 on: Apr 6 2006
 
Score 50%

kwin is certainly not related to the colors of a windows content and it's not the styles job to fix every widgets coloring
1. becauses it costs cpu (without any sense)
2. you can never know if a widgets behaviour isn't intended


Reply to this

-
.

 w.y.G.i.w.y.S.

 
 by Maxilys on: Apr 5 2006
 
Score 50%

This is a typical case of WYGIWYS (what you get is what you set). If you set a dark background and a dark font color, that's what you get. User's always right.

Now, imagine the style inverts the font color when needed. With a dark font over a dark background, the style will always invert the color. What the point of setting a dark font in the first place?

If you want to use white fonts, set all your backgrounds to something dark. In the case of your first screenshot, darken the color of the window background and you'll be able to use a really white font. But don't expect miracles, most of the styles can't cope with dark colorschemes.

Check this: (Dark blue background with white font.)

http://home.tele2.fr/mxls/archives/Aerial%20Blue.png

It works this way but if you change the window background to something bright like in your screenshot, a lot of checkboxes are going to be needed in the config dialog... and the result will be the same as if the fonts were set to black. Pointless.

Styles already have a lot of things to cope with. I don't think we should also make them fight against user's colorschemes. And I won't talk about the giant snail of a style you'll get if you add the huge shell of if's implied by your idea. ;-)


(c) MXLS(r)(tm) (Patent pending)
We're living in a free world, ain't we?

Reply to this

-

 Re: w.y.G.i.w.y.S.

 
 by mattepiu on: Apr 5 2006
 
Score 50%

I checked your screen, and you're cheating:
you're using a pale blue for windows background, try to use a pale white and keep dark blue all the rest.....
now you'll see that WYGIWYCS:
What You Get Is What You Can Set
(if you can't set it better, you're getting this crap)


Reply to this

-

 Thumbs up buddy.

 
 by RedShirt on: Apr 6 2006
 
Score 50%

I agree, it is a matter of what you can set. Currently, I am using a black on white approach to my whole desktop, because of the limited option set available of text settings. It may look okay on a window bg, but not the bar, or a menu, or something else. And each time you try to fix it, it breaks the text on something else.

Just try to make a FULLY working black background theme with something like green text, and readable labels and menus. There just aren't even options to configure to do this right.

I am all for better coloring options in general, and some autosensing involved, so long as I can configure what color to display on drak bg, and what on bright, I am all for it. I just don't want pigeonholed into exact colorset options.

Good idea.


Reply to this

-

 Re: Thumbs up buddy.

 
 by Maxilys on: Apr 7 2006
 
Score 50%

Green on black? Like this:

http://home.tele2.fr/mxls/archives/Matrix.png
http://home.tele2.fr/mxls/archives/Matrix2.png

It's possible and usable... but it totally depends on the style. As I said previously, most of the styles can't cope with bright text on a dark background. If the style isn't written with the idea of also supporting dark colorschemes in the mind of the developer, it just won't work.

Instead of rewriting styles to add them more options, it would be much better to rewrite them to support dark colorschemes IMHO. That isn't that hard.


(c) MXLS(r)(tm) (Patent pending)
We're living in a free world, ain't we?

Reply to this

-

 Re: Re: Thumbs up buddy.

 
 by RedShirt on: Apr 7 2006
 
Score 50%

Then let me amend merely usable... to good looking, user friendly, easy on the eyes, and usable beyond the preview screen all the way to menus, theme bars, and other places. Yes the theme being written specifically for dark color schemes help, but having a mixed theme makes this very hard.

Also, in actual use most dark color schemes on most themes don't handle this kind of stuff well, specifically usually menus, sidebars, and other complexly drawn multisetting areas. Just having multiple version of a theme to handle this kind of stuff isn't a fix, it is a workaround.


Reply to this

-

 well

 
 by mattepiu on: Apr 9 2006
 
Score 50%

I asked for this feature just to double the theme choiche, actually there are
themes for bright text on dark background
and themes for dark text on bright background, this "not so big, not so difficult" optional func.
could just render every theme useable with the colour scheme you want.

Is this something bad?


Reply to this

Add commentBack




-



 
 
 Who we are
Contact
More about us
Frequently Asked Questions
Register
Twitter
Blog
Explore
Apps
Artwork
Jobs
Knowledge
Events
People
Updates on identi.ca
Updates on Twitter
Content RSS   
Events RSS   

Participate
Groups
Forum
Add Content
Public API
About openDesktop.org
Legal Notice
Spreadshirt Shop
CafePress Shop
Advertising
Sponsor us
Report Abuse
 

Copyright 2007-2016 openDesktop.org Team  
All rights reserved. openDesktop.org is not liable for any content or goods on this site.
All contributors are responsible for the lawfulness of their uploads.
openDesktop is a trademark of the openDesktop.org Team