-
Notifications
You must be signed in to change notification settings - Fork 206
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
#42 added color option to ConsoleOutLoggerFactoryAdapter #43
Conversation
Hold off merging for now. I've just realised this implementation is flawed. I'll update the PR later. |
OK, I've replaced the commit. I think it's all good to go now, although the Sliverlight An alternative approach would be to introduce a |
{ | ||
var originalColor = Console.ForegroundColor; | ||
ConsoleColor color = originalColor; | ||
colors.TryGetValue(level, out color); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If the level
isn't found, color
will become default(ConsoleColor)
, which is black. Based on the values in colors
, I think we're assuming a dark (black?) background, so that's perhaps not ideal. Maybe better to detect the missing value and fall back to originalColor
?
While I'm griping, no love for people with light-coloured backgrounds? 😉
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Does TryGetValue()
specifically assign default(T)
if the key is not found? I guess it might at least. I'll change it to be immune to that.
Light backgrounds - it crossed my mind too but for now I just went with replicating the default behaviour of the NLog ColoredConsoleTarget
with regard to the chosen foreground colors as well as not altering the background color. I guess something clever to detect the lightness of the background and switch to a dark foreground scheme could be added later.
That's how I read the docs. And, yup. Look:
|
Yeah. I was just having a little fun with you on that one. Sorry. |
Has anyone had a chance to look at this PR? I'm happy to re-visit if required. |
@adamralph I'll take a look at it this week and let you know -- thanks for the contribution and sorry for the delayed response! |
😢 |
Hang tight -- this weekend is "common.logging weekend" for me so I'll get this in shortly (promise). I've been traveling ridiculously-much for work the past ~30 days. |
😃 Sure, no probs. I know how it is... |
Per your comment ...
...could you re-jigger your PR to use this approach? Now that I've restructured the relationships betw the PCL assemblies and the non-PCL assemblies (so that there's no longer any dependency betw. the two) your suggestion here re: the 'cleaner' way to approach this is actually much more appropriate. Thanks again for the contribution! |
Actually, scratch that -- I'll actually do this myself since its relatively straightforward to accomplish in short order.... |
Just FYI, since its the Common.Logging.Portable project that forms the basis for the Silverlight support and ConsoleOutLogger only exists in Common.Logging, I was able to remove all of the IFDEFs from the PR before merging it. Simplicity achieved! |
😂 thanks! |
Sorry, just realized that I'm wrong -- there's been so much restructuring of the code here lately that I failed to realize that the ConsoleOutLogger does in fact also appear in the Silverlight project so I've added your IFDEFs back in -- so much for simplicty :-/ |
Completed with implementation for setting useColor via NameValueCollection or web.config |
fixes #42 using the 'new constructor for
ConsoleOutLoggerFactoryAdapter
' solution