Console Output - Revision history

JHofinger at 15:16, 20 May 2020

2020-05-20T15:16:04Z

← Older revision		Revision as of 15:16, 20 May 2020
Line 6:		Line 6:
	===Windows Encoding===		===Windows Encoding===
	<s>		<s>
	Windows uses the wrong encoding for glib output: https://gitlab.com/inkscape/inkscape/merge_requests/418#note_119199350		Windows uses the wrong encoding for glib output: https://gitlab.com/inkscape/inkscape/-/merge_requests/418#note_119199350

	Possible solutions:		Possible solutions:
Line 14:		Line 14:
	* Ask the GTK people.		* Ask the GTK people.
	** Related glib bug: https://bugzilla.gnome.org/show_bug.cgi?id=782578		** Related glib bug: https://bugzilla.gnome.org/show_bug.cgi?id=782578
	** Bug as GitLab issue: https://gitlab.gnome.org/GNOME/glib/issues/1270		** Bug as GitLab issue: https://gitlab.gnome.org/GNOME/glib/-/issues/1270
	</s>		</s>

	Fixed in glib 2.62, see https://gitlab.gnome.org/GNOME/glib/merge_requests/767		Fixed in glib 2.62, see https://gitlab.gnome.org/GNOME/glib/-/merge_requests/767

	===Glib vs iostreams===		===Glib vs iostreams===

Patrick87: /* Windows Encoding */

2019-06-11T20:08:09Z

Windows Encoding

← Older revision		Revision as of 20:08, 11 June 2019
Line 17:		Line 17:
	</s>		</s>

	Fixed in glib 2.62, see https://gitlab.gnome.org/GNOME/glib/merge_requests/767~~/diffs~~		Fixed in glib 2.62, see https://gitlab.gnome.org/GNOME/glib/merge_requests/767

	===Glib vs iostreams===		===Glib vs iostreams===

Patrick87: /* Windows Encoding */ fixed upstream

2019-06-11T20:03:35Z

Windows Encoding: fixed upstream

← Older revision		Revision as of 20:03, 11 June 2019
Line 5:		Line 5:

	===Windows Encoding===		===Windows Encoding===
			<s>
	Windows uses the wrong encoding for glib output: https://gitlab.com/inkscape/inkscape/merge_requests/418#note_119199350		Windows uses the wrong encoding for glib output: https://gitlab.com/inkscape/inkscape/merge_requests/418#note_119199350

Line 15:		Line 15:
	** Related glib bug: https://bugzilla.gnome.org/show_bug.cgi?id=782578		** Related glib bug: https://bugzilla.gnome.org/show_bug.cgi?id=782578
	** Bug as GitLab issue: https://gitlab.gnome.org/GNOME/glib/issues/1270		** 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/diffs

	===Glib vs iostreams===		===Glib vs iostreams===

Tavmjong: /* Windows Encoding */

2018-11-23T20:59:23Z

Windows Encoding

← Older revision		Revision as of 20:59, 23 November 2018
Line 14:		Line 14:
	* Ask the GTK people.		* Ask the GTK people.
	** Related glib bug: https://bugzilla.gnome.org/show_bug.cgi?id=782578		** Related glib bug: https://bugzilla.gnome.org/show_bug.cgi?id=782578
			** Bug as GitLab issue: https://gitlab.gnome.org/GNOME/glib/issues/1270

	===Glib vs iostreams===		===Glib vs iostreams===

Tavmjong: /* Current Use */

2018-11-23T20:55:22Z

Current Use

← Older revision		Revision as of 20:55, 23 November 2018
Line 23:		Line 23:
	* 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

Patrick87: /* Windows Encoding */ fix comment link and add relevant bug for glib

2018-11-23T18:15:39Z

Windows Encoding: fix comment link and add relevant bug for glib

← Older revision		Revision as of 18:15, 23 November 2018
Line 6:		Line 6:
	===Windows Encoding===		===Windows Encoding===

	Windows uses the wrong encoding for glib output: https://gitlab.com/inkscape/inkscape/~~commit~~/~~408cb49b5559a81ea803df64bf58457a5dd4bf16~~#~~note_119455385~~		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

	===Glib vs iostreams===		===Glib vs iostreams===

Tavmjong: 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..."

2018-11-23T12:49:42Z

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..."

New page

How do we handle console output?

==Issues==

===Windows Encoding===

Windows uses the wrong encoding for glib output: https://gitlab.com/inkscape/inkscape/commit/408cb49b5559a81ea803df64bf58457a5dd4bf16#note_119455385

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.

===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

* 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:

<pre>
// Start redirection
std::stringstream ss;
std::streambuf *sb = std::cout.rdbuf(ss.rdbuf());

// End redirection
std::cout.redbuf(sb);
</pre>

For everything:

<pre>
char huge_string_buf[1000];
freopen("/dev/null", "a", stdout);
setbuf(stdout, huge_string_buf);
</pre>

Buffer could get filled up (shouldn't overflow).