Configuration Instance + Visual Style Tutorials

[Gomango999]

As suggested by @iosonofabio, I've added a tutorial for using igraph's configuration instance in order to set default plotting techniques, as well as a tutorial for using dictionary unpacking in order to set the same visual style across multiple graphs. I believe these two tutorials complement each other nicely.

I do have one question though: For the configuration instance, I've currently set config["general.verbose"] = True since I wanted to show off something other than just the plotting settings. The documentation states that this will cause some functions to print progress bars or other extra output. Is there an example of a function I could use to demonstrate this difference?

[vtraag]

There are a number of functions that display a progress bar, these are all functions that have IGRAPH_PROGRESS in them in the C core. I don't have a full list, but at least (edge) betweenness, closeness, maximal_cliques, components, flow, forestfire, a few layouts. We should probably expand that if the progress bar will be used more frequently.

I'm not sure if it will immediately show a progress bar when setting config["general.verbose"] = True, that didn't work for me at least. If you launch an ipython shell through the igraph command line, you do get a progress bar

@ntamas we probably want to make available progress bars more generally? There are also some packages that provide progress bar functionality (e.g. tqdm). Shall we open a separate issue for that?

[ntamas]

The general.verbose setting is used only if you launch igraph via its command-line shell; see the documentation of the igraph.app.shell module. This is to prevent igraph from printing random output to the console if a third-party app happens to use igraph for some calculations but it has no intention to show the progress to the user. In other words, the behaviour of igraph as a library when used by a third party must not be dependent on a user-settable configuration file; the configuration must take effect only if the user expresses their intention to launch igraph in an interactive environment.

So, in igraph.app.shell:main, we have this:

if config["verbose"]: if shell.supports_progress_bar(): set_progress_handler(shell.get_progress_handler()) if shell.supports_status_messages(): set_status_handler(shell.get_status_handler())

This is what turns on the progress bars, but note that it looks at the configuration parameter only at startup, so if you set general.verbose in the config, then you need to save the config and then restart the shell to see the progress bars.

@vtraag I'm not sure what you mean; do we want to add a function that the user can invoke in the shell to switch the progress bar to use tqdm?

[vtraag]

@vtraag I'm not sure what you mean; do we want to add a function that the user can invoke in the shell to switch the progress bar to use tqdm?

Many people will probably use Jupyter notebooks for their analysis, which are now not properly supported with any progressbar, I believe. Instead of having to code up something ourselves, simply supporting tqdm directly, by hooking it into our progress handler might work well. Perhaps this indeed warrants a separate issue, so that others can also share their thoughts there.

[Gomango999]

I've made the changes, and rebased. I've also removed ig.config["general.verbose"] = True from the tutorial for now, since these examples are intended to demonstrate igraph's use as a library, and hence general.verbose does nothing.

[ntamas]

@vtraag Ah, okay, I understand now. I believe this should be discussed in a separate issue. I didn't know that tqdm supports IPython natively. This also ties into @szhorvat 's idea about nested progress bar support in the C core (i.e. ifd an igraph algorithm calls another one, and both of them support progress bars, the progress bar of the inner algorithm shouldn't "overwrite" the outer one). I wonder whether tqdm has support for multiple progress bars. There's also ipynb as an alternative.

Furthermore, it seems like there are multiple Jupyter-like environments now; besides the stock Jupyter notebook, there's also a VS Code extension that lets you use Jupyter notebooks inside VS Code, plus there's Google Colab, and maybe others. It would be great if we could pick a solution that works in as many platforms as possible.

[iosonofabio]

Alright, the progress bar discussion is interesting but not really the topic of this PR. I'll open a separate issue and refer here. I've simplified some wording, I'll merge now.