Interactive console output gets mixed with all other log entries (and possibly gets filtered away)
As it stands right now, various different commands all use different log helpers for the script log sink. Some use verbose, and some use note. This could be confusing for some users should they change the logger verbosity filter, as they may not see help for commands.
As commands are sometimes used in maps and other scripts, it might be a good idea to implement an interface that defines a "command sender", where there is a command sender for human input, and one for script input. Commands originating from the human sender would be sent directly to the console (i.e. not via the logger), while the commands originating from "robot" sources, such as the engine, other commands, or maps would be handled via the logger. As a bonus, this means that commands do not know about the logger and are expected to use a concrete and dedicated interface for output, this also means that when debugging, commands need not show up in debugging logs (which are at the moment, extremely verbose as they are, with around 65.656K lines of text for a single sink on VV verbosity).
Log|libcore|libdoomsday: Interactive script output bypasses filtering
When the user enters commands in the console, and the commands produce
output, it is better to allow these entries to bypass the chosen
filters. Log entries created during execution of console commands
whose source is either "console" or "cmdline" are now flagged as
Interactive, and LogFilter allows these to pass in the Script domain.
This is not a perfect solution, though, because not all console
commands (yet) use SCR when printing output.
#1 Updated by skyjake almost 7 years ago
- Tracker changed from Feature to Bug
- Subject changed from Don't use the logging facilities to display command help to Interactive console output gets mixed with all other log entries (and possibly gets filtered away)
- Assignee set to skyjake
I agree this is a legitimate problem, however I have some thoughts about the appropriate way to handle this.
It is certainly true that interactive console output should be treated differently, however there is no need to bypass the usual logging mechanism. For every thread that submits log entries, there is a thread-specific Log object that maintains the "log section" context information (see
LOG_AS macro). When executing a console command via the prompt widget, this thread-specific state should be used to flag all log entries as "interactive" — the reasoning being, any output generated as a result of an interactive command being executed should be shown to the user.
Another aspect to consider is that in a multiuser setup, where you have more than one client (i.e., shell) connected to a server, the interactive output of each client should not be seen by any other client. Currently the facilities for this exist only in partial form, for actual Shell users, but because the interactive output is not segregated, all command output is seen by all connected Shell users no matter who issues the commands. This could also be solved with thread-specific Log state, so that when executing interactive commands issued by a specific shell user, those would only be ultimately sent to the issuer.
Note that the current console backend (in libdoomsday) is considered obsolete and will be replaced with a Doomsday Script based solution. Also in the future, all interactive console sessions should be handled with libshell classes so there's no functional difference when accessing the console from the Shell utility or via the client itself.
#2 Updated by skyjake over 6 years ago
- Status changed from New to Resolved
- Target version set to 2.0 – Home UI & Packages
- % Done changed from 0 to 100
I'm marking this issue as done because the basic mechanism has been implemented. Individual console commands whose output hasn't been updated to use
SCR should still be updated later.