Sync log level in gui and core - #8885

I need to have a think about this, I'm not quite sure I understand why this is necessary and what problem it solves.

Two problems
1 when removing the -d switch from core the lowest settings can show now is INFO. to keep the setting the same in the core we need to allow the gui to also have levels of Fatal , Error and Warning.
2. if you just let it show Fatal the gui does not work correct as we listen for messages at the Info Level . I was going to move them to PRINT but making them their own IPC allows me to re add the time stamp back into the message w/o forcing it for all other print messages.

3. see the linked bug / feature report

Using a special IPC log level to force the GUI to keep working at low verbosity is the wrong fix, because it turns human-oriented logs into a control channel and tightens coupling; #8889 is a UI problem that can be solved in the GUI with a clear warning or confirm step when choosing verbose levels, while the Core should stay decoupled and expose state via a proper event stream instead (for example messages over Qt local serverwith events like Connecting, Connected, Disconnected, PeerFingerprint) that the GUI can subscribe to independent of log level; keep logs for people, send state over real IPC, and ship the UI warning now with a follow-up to add structured events and most importantly... we must remove all GUI log scraping (this is the correct fix).

The second point can be undone when we have better IPC Until then gui has to see these messages.

Yes I plan to remove this when we have working IPC. can just revert the commit even that is why its its own commit so we can remove it later easily

Using a special IPC log level to force the GUI to keep working at low verbosity is the wrong fix, because it turns human-oriented logs into a control channel and tightens coupling;

We already are using the log messages but they are printed at INFO meaning if you set the level higher (i.e Note or Fatal ) the gui stops working correctly. I have not changed how it works just that you cant filter the messages now in the gui while being able to filter with the same levels you can from the cli

This blocks me removing the args until we have IPC this is what we need todo do. Proper IPC its blocked by our core apps not having a QEvent loop , that is blocked by having Args and making our own 'App' class removing the args lets me remove the whole run , runInnter stuff that gets us closer to one event loop not ours + Qts

Yes I plan to remove this when we have working IPC.

Got it, not sure if we have an issue already, but I raised this so we don't forget:

• Core IPC messages (revert IPC log level commit) #8898

This blocks me removing the args until we have IPC this is what we need todo do. Proper IPC its blocked by our core apps not having a QEvent loop , that is blocked by having Args and making our own 'App' class removing the args lets me remove the whole run , runInnter stuff that gets us closer to one event loop not ours + Qts

Makes sense.

Our Debug level is weird.. also you can see we still get some INFO lines in FATAL around start up / shutdown i suspect these messages are before the level is set in the new instance of the core.

deskflow-core: /home/nick/Projects/deskflow/src/lib/base/Log.cpp:295: void Log::output(LogLevel, const char*): Assertion `static
_cast(priority) >= -1 && static_cast(priority) < g_numPriority' failed.

I Just Fixed this i missed that assert.