The colorset enhancement may be calculating relief colors differently. Currently, we use sh and hi (that is evaluated from bg if not given) to do this. Such static colors produce bad results when used for gradient, image or transparent background with a large or medium range of colors.
It would be better to have a boolean flag in colorset that switches off the use of the hi and sh in colorset and evaluates hi and lo using the internal algorithm based on the real-time bg pixel that should be converted to the relief. The problems are clear. This is slower and not very configurable. I wish the gtk color algorithm to be used in this case, not motif's, otherwise it will be not smooth for random gradient/image. Still regardless of problems, this should produce a much nicer result. As for configurability, I think it is good to extend the colorset to have a flag that chooses gtk-based or motif-based calculations. And hiFactor, shFactor that are used in gtk-based (and maybe in motif-based) algorithms. Probably these 3 values may be global for all colorsets to make it easier for the user to define them. Or we may add Colorset * syntax. ---- One more issue to think about. Using numbers for colorsets is ok, but using symbolic names is better yet. Technically it may be implemented using one array (for numeric names) and one hash (for symbolic names). These array and hash have no any correlation. Anyone may choose either numeric or text id for colorset. Like: Colorset CDE4 bla-bla Colorset MENU1 bla-bla Colorset MENU2 bla-bla MenuStyle * MenuColorset MENU1, ActiveColorset MENU2 Preprocessing may be a solution, but this is really not the same as the colorset library managing these ids itself. Regards, Mikhael. -- Visit the official FVWM web page at <URL:http://www.fvwm.org/>. To unsubscribe from the list, send "unsubscribe fvwm-workers" in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
