On Fri, Aug 01, 2003 at 07:02:29AM +0300, Martin Vermeer spake thusly: ... > One remaining problem: the place where the colour is used in > insets/insetbranch.C where we have > > setBackgroundColor(lc.getFromGUIName(color)); > > 'color' being the string name. So, an LColor is being generated. Can > the colour picker handle that (i.e. add a legit LColor and name to the > database, where the above will find it) for an arbitrary RGB triplet? > I seem to remember this mentioned somewhere.
Having analyzed this proble a little further, it looks pretty bad. The
need by setBackgroundColor for an LColor can be traced back to
fillRectangle in Painter and in XPainter, which calls XFillRectangle
that takes a Graphics Context as argument... produced by (file
ColorHandler.C)
LyXColorHandler::getGCForeground(LColor::color c)
!
Do I really have to start tinkering with this deep stuff, e.g.,
define a LyXColorHandler::getGCForeground() that takes an RGB
argument? It would shortcircuit part of the code and
would call XAllocColor directly.
Am I on a wild goose chase?
Martin
...and what about this getGCForeground routine... I wonder if it is
perhaps unnecessarily complex. Especially as I have the following
Questions:
1) shouldn't the statement at ColorHandler:C:118 be
val.foreground = ccol.pixel;
rather than the presumably cut'npasted
val.foreground = xcol.pixel;
?
2) Does the ccol conditional block contribute anything?
3) Does the manual traversal of the colour space after that contribute
anything, i.e., do a better job than XAllocColor itself?
Why not use XAllocColor directly as it was made for this?
- M.
pgp00000.pgp
Description: PGP signature
