| karmavil[m] | Hi. I have a question. The message bellow looks more like an issue report but is not:... (full message at <https://libera.ems.host/_matrix/media/v3/download/libera.chat/9ab1a86cc306904256fabca866a0961acff3e8fc>) | 03:19 |
|---|---|---|
| * karmavil[m] uploaded an image: (278KiB) < https://libera.ems.host/_matrix/media/v3/download/matrix.org/ukdxrVhVctpbARSCBxAkCGjJ/Screenshot%20from%202023-06-28%2020-55-28.png > | 03:19 | |
| * karmavil[m] uploaded an image: (236KiB) < https://libera.ems.host/_matrix/media/v3/download/matrix.org/NqLumppsLfYZDFMoHmOLTVQG/Screenshot%20from%202023-06-28%2023-28-42.png > | 03:20 | |
| karmavil[m] | Let me know what do you think about having an option to format the output like that. I understand the project has other priorities, not this one | 03:22 |
| karmavil[m] | And [related to the last comment](https://github.com/MirServer/ubuntu-frame/issues/143#issuecomment-161165533) I think it might be true. I have set one of the monitors with `orientation: right` (vertical) and the output showed that it didn't detect the orientation correctly. I would even adventure to guess that it's not detecting the properties of the second monitor but instead replicating the values of the main monitor | 03:52 |
| karmavil[m] | * the output on the screenshot below it has | 04:14 |
| karmavil[m] | Ok forget about it, I should better make somme external auxiliary tool for that. | 06:35 |
| karmavil[m] | I will remove those messages to avoid you the pain of going through those long messages | 06:35 |
| karmavil[m] | Mm maybe not. I will leave them there to emphasize my point | 06:37 |
| RAOF | So, you should be able to filter out by severity. | 07:00 |
| RAOF | (critical, error, warning, info, debug) | 07:00 |
| RAOF | It would not be a bad idea (or particularly difficult) to add a journalctl log target with more structured logging. | 07:01 |
| karmavil[m] | That's nice. Thank you I didn't thought about journalctl I will how it goes. But either way with that, grep or sid I'm pretty sure lot of the people trying out mir would like to avoid having to dig in filtering outputs. It's part of the job thought but I don't know.. I don't feel myself capable of touching the sources of mir right now so meanwhile I will be reading logs 🙂 | 07:57 |
| karmavil[m] | * I will see how it | 07:57 |
| RAOF | My general principle with logs is: it's easiest to debug stuff if the relevant information is in the logs when you hit it, so logs should be nice and verbose :) | 08:05 |
| alan_g[m] | <karmavil[m]> "That's nice. Thank you I didn'..." <- There's a GLog example in the demo-server (GlogLogger) that could be used as a template | 08:06 |
| karmavil[m] | <RAOF> "My general principle with logs..." <- I agree. But it makes it hard at the beginning. I will actually think that there is a lot to learn from them, like it's the perfect entry point to understand how mir works | 08:10 |
| karmavil[m] | * I agree. But it makes it hard at the beginning. I actually think that there is a lot to learn from them, like it's the perfect entry point to understand how mir works | 08:11 |
| alan_g[m] | I agree too. Any filtering should be in the log reader. (Which the default of dumping as console text doesn't facilitate very well) | 08:29 |
| karmavil[m] | Yeap. I'm still not clear if there is log file somewhere. But I'm going to start simple. Like pasting the log from the output. | 08:37 |
| karmavil[m] | I took a look at journalctl and it adds the date and time in top of the date and time. It's like an those readers of memory (hexadecimal adresses things) having the final message in a fraction of the screen. Nevertheless journalctl could be the source of the logs. | 08:37 |
| karmavil[m] | Alright thank you for the suggestions | 08:37 |
| karmavil[m] | s/an// | 08:39 |
| karmavil[m] | s/an//, s/adresses/addresses/ | 08:39 |
| === tortoise_ is now known as tortoise | ||
| karmavil[m] | Not the suggestion, the solution :D | 08:58 |
| alan_g[m] | How does running a DnD test driven by virtual pointer hang Miriway? | 14:15 |
| alan_g[m] | ...and the answer is that dispatching input events on the Wayland thread is not a great idea as it can hang both the input thread and the Wayland thread | 15:55 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!
