Difference between revisions of "Console Output"
(Created page with " How do we handle console output? ==Issues== ===Windows Encoding=== Windows uses the wrong encoding for glib output: https://gitlab.com/inkscape/inkscape/commit/408cb49b555...") |
|||
(5 intermediate revisions by 2 users not shown) | |||
Line 5: | Line 5: | ||
===Windows Encoding=== | ===Windows Encoding=== | ||
<s> | |||
Windows uses the wrong encoding for glib output: https://gitlab.com/inkscape/inkscape/ | Windows uses the wrong encoding for glib output: https://gitlab.com/inkscape/inkscape/-/merge_requests/418#note_119199350 | ||
Possible solutions: | Possible solutions: | ||
Line 13: | Line 13: | ||
* Use g_log_set_handler as done in ui/dialog/messages.cpp | * Use g_log_set_handler as done in ui/dialog/messages.cpp | ||
* Ask the GTK people. | * Ask the GTK people. | ||
** Related glib bug: https://bugzilla.gnome.org/show_bug.cgi?id=782578 | |||
** Bug as GitLab issue: https://gitlab.gnome.org/GNOME/glib/-/issues/1270 | |||
</s> | |||
Fixed in glib 2.62, see https://gitlab.gnome.org/GNOME/glib/-/merge_requests/767 | |||
===Glib vs iostreams=== | ===Glib vs iostreams=== | ||
Line 22: | Line 27: | ||
* std::cout: 976 | * std::cout: 976 | ||
* std::cerr: 361 | * std::cerr: 361 | ||
* printf: 439 | |||
* sprintf: 285 | |||
* fprintf: 122 | |||
* snprintf: 47 | |||
* g_print: 137 | |||
* g_printerr: 12 | |||
* g_strdup_printf: 331 | |||
* g_snprintf: 24 | |||
* g_log/g_logv: 23 | * g_log/g_logv: 23 |
Latest revision as of 15:16, 20 May 2020
How do we handle console output?
Issues
Windows Encoding
Windows uses the wrong encoding for glib output: https://gitlab.com/inkscape/inkscape/-/merge_requests/418#note_119199350
Possible solutions:
- Give up on g_log (g_message, etc.). This would be a major effort and doubtful we can do it in a time for 1.0.
- Use g_set_print_handler as described in https://stackoverflow.com/questions/43927373/force-utf-8-encoding-in-glibs-g-print
- Use g_log_set_handler as done in ui/dialog/messages.cpp
- Ask the GTK people.
- Related glib bug: https://bugzilla.gnome.org/show_bug.cgi?id=782578
- Bug as GitLab issue: https://gitlab.gnome.org/GNOME/glib/-/issues/1270
Fixed in glib 2.62, see https://gitlab.gnome.org/GNOME/glib/-/merge_requests/767
Glib vs iostreams
Mix of glib output functions and std::cout/std::cerr. In principle mixing the two can cause problems but in practice it does not as by default std::cout/std::cerr are synced with stdio (std::sync_with_stdio).
Current Use
- std::cout: 976
- std::cerr: 361
- printf: 439
- sprintf: 285
- fprintf: 122
- snprintf: 47
- g_print: 137
- g_printerr: 12
- g_strdup_printf: 331
- g_snprintf: 24
- g_log/g_logv: 23
- g_message: 312
- g_warning: 470
- g_critical: 47
- g_info: 72
- g_debug: 4
Message dialog
Our message dialog can intercept g_log, etc. and redirect it to the dialog. This is done through g_log_set_handler if "Capture log messages" is checked. As we intercept everything, we could just intercept stdout/stderr as a comment in the message code suggests. How do actually do this is not clear.
For std::cout only:
// Start redirection std::stringstream ss; std::streambuf *sb = std::cout.rdbuf(ss.rdbuf()); // End redirection std::cout.redbuf(sb);
For everything:
char huge_string_buf[1000]; freopen("/dev/null", "a", stdout); setbuf(stdout, huge_string_buf);
Buffer could get filled up (shouldn't overflow).