Top |
const gchar * | gtex_post_processor_get_name_from_type () |
gboolean | gtex_post_processor_get_type_from_name () |
void | gtex_post_processor_process_async () |
void | gtex_post_processor_process_finish () |
void | gtex_post_processor_start () |
void | gtex_post_processor_process_line () |
void | gtex_post_processor_end () |
const GList * | gtex_post_processor_get_messages () |
GQueue * | gtex_post_processor_take_messages () |
GObject ╰── GtexPostProcessor ├── GtexPostProcessorAllOutput ├── GtexPostProcessorLatex ╰── GtexPostProcessorLatexmk
When running a build tool, a post-processor is used to filter the output to display only the relevant messages. The output can come from the stdout/stderr of a build job command, or the contents of a log file, etc. In this application only the former is currently used, but it would be more robust to read the LaTeX log file.
For the no-output post-processor type, you should not need to create a GtexPostProcessor object, since the result is empty.
The implementations sometimes assume that a post-processor can be used at most one time.
const gchar *
gtex_post_processor_get_name_from_type
(GtexPostProcessorType type
);
gboolean gtex_post_processor_get_type_from_name (const gchar *name
,GtexPostProcessorType *type
);
void gtex_post_processor_process_async (GtexPostProcessor *pp
,GFile *file
,GInputStream *stream
,GCancellable *cancellable
,GAsyncReadyCallback callback
,gpointer user_data
);
Asynchronously process an input stream. The input stream can for example come from the output of a command launched with GSubprocess, or it can be the input stream of a file (e.g. the LaTeX log file), etc.
callback
will be called when the operation is finished. You can then call
gtex_post_processor_process_finish()
.
pp |
a post-processor. |
|
file |
the GFile on which the build tool is run. |
|
stream |
the input stream to process. |
|
cancellable |
a GCancellable. |
|
callback |
the callback to call when the operation is finished. |
|
user_data |
the data to pass to the callback. |
void gtex_post_processor_process_finish (GtexPostProcessor *pp
,GAsyncResult *result
,gboolean succeeded
);
Finishes an operation started with gtex_post_processor_process_async()
.
After calling this function, you can get the filtered messages with
gtex_post_processor_get_messages()
.
pp |
a post-processor. |
|
result |
a GAsyncResult. |
|
succeeded |
whether the subprocess has succeeded. |
void gtex_post_processor_start (GtexPostProcessor *pp
,GFile *file
);
Manually starts the post-processor.
Not needed if you use gtex_post_processor_process_async()
.
void gtex_post_processor_process_line (GtexPostProcessor *pp
,gchar *line
);
Manually processes a line. This function takes ownership of line
. Free with
g_free()
if you don't reuse the content.
Not needed if you use gtex_post_processor_process_async()
.
void gtex_post_processor_end (GtexPostProcessor *pp
,gboolean succeeded
);
Manually ends the processing.
Not needed if you use gtex_post_processor_process_async()
.
const GList * gtex_post_processor_get_messages (GtexPostProcessor *pp
,gboolean show_details
);
Gets the filtered messages. Call this function only after calling
gtex_post_processor_process_finish()
or gtex_post_processor_end()
.
Another solution would have been to pass the GtexBuildView to the post-processor, so the filtered messages can directly be outputed to the build view as they come. But some post-processors don't know what to output directly. The latexmk post-processor can have a simplified output with only the LaTeX messages, in which case the detailed messages are also available, but this can be known only when all the stream has been processed.
Obviously if the build view is passed to the post-processor, the latexmk post-processor can output its messages only at the end. But another reason to not pass the build view is for the unit tests. It is easier for the unit tests to check the returned GList than analyzing a GtkTreeView. Of course it would be possible to keep also the messages in a GList and have this function only for the unit tests, but it takes more memory (unless a custom GtkTreeModel is implemented), or another function is needed to configure whether a GList is kept in memory or not... It becomes a little too complicated, and doesn't really worth the effort as most users use latexmk.
The current solution is "good enough". And "good enough" is... "good enough".
pp |
a post-processor. |
|
show_details |
whether to show the details. Has no effect if
“has-details” is |
GQueue *
gtex_post_processor_take_messages (GtexPostProcessor *pp
);
Takes ownership of all the messages. Since GQueue is not reference counted,
pp
is emptied and is thus useless after calling this function.
[skip]
the tree of filtered messages, or NULL
.
Element types: GtexBuildMsg.
[transfer full][nullable]
“has-details”
property“has-details” gboolean
Owner: GtexPostProcessor
Flags: Read / Write / Construct
Default value: FALSE