Logging utilities about ktx HOT 6 CLOSED

I really wanted to go for simplicity and as little overhead as possible. Customized logging functions could easily introduce concurrency bugs when done wrong. Instead of refactoring current logging mechanism, I decided to make it possible to extend Logger with customized tags - an example of logger that includes current time was added to the README file.

Anyway, I'm guessing most people will be fine with the usual Logger and static logging methods (as they are already more flexible and efficient than the usual LibGDX logging), and others can easily modify the way their logs are displayed.

from ktx.

@kotcrab Anything else? We could add custom trace/warn levels that work on top of LibGDX debug and info/error, but I'm not sure if that's necessary (especially since we would likely have to introduce new logging level variables).

from ktx.

Well this is a wrapper over libGDX API, I don't think we should add custom levels. I would expect a way to customize output message, eg. prepend time or date, otherwise people will probably still create their own wrappers, and maybe add some control to disable log levels (e.g. only show error messages).

from ktx.

The thing is - since Logger methods are inlined, I'm not sure if an interface or complex logging logic would work in this case. We're going for minimal overhead, after all.

I might create another Logger implementation that adds dates before/after the logging tag, but I'm not sure if full control over log structure is easily achievable.

Log level disabling is handled by the LibGDX itself. You can globally turn on and off the levels that you do or do not need.

from ktx.

Message formatting can be simply achieved as changeable global method.

//logger file
var formatLogMessage: (String) -> String = { it }

//app class
fun myAppInit() {
  formatLogMessage = { getTimestamp() + it  }
}

The same could be done for default log level tags, although I'm not sure if that would be good practice or not.

from ktx.

Adds the overhead of calling another method (formatLogMessage), even if you don't want an alternate formatting. Doesn't really matter that much, as logs are usually more important for development time, but still.

Imho a complex, customizable logger (that still uses inlining) would be a more lightweight solution, although it could be a pain to refactor your application to switch from one to the other. I have to think about it.

from ktx.