Plotting/GUI CLI should they be separate or combined?

[zerothi]

We need to figure out whether we need two CLI for plotting and for GUI handling.

I am starting to more advocate one CLI for both.

sgui ase
sgui matplotlib/plot
sgui plotly

something like this.

Since we are in doubt of the placement of individual functionality, users will without a doubt also!! :)

Please chip in here! ;)
@pfebrer96 @jonaslb

Originally posted by @zerothi in #221 (comment)

[jonaslb]

I haven't really dived much into the visualization/plotting module of Pol, so my insight there is a bit limited.
But in the end I think plotting graphs is quite different from viewing/editing geometries so in that sense I guess it would make sense to have them be separate clis.

Also it's true (Nick's comment) that the editing features in ase gui are very limited. I suppose it's more for getting a quick look at a structure in a gui that can give more or less all the geometry information one needs (which is quite often nice imo). Also it's pure python so it has no dependencies (other than ase).

[pfebrer]

But in the end I think plotting graphs is quite different from viewing/editing geometries so in that sense I guess it would make sense to have them be separate clis.

I have the same opinion. I would do splot struct.bands when I want to get a quick plot of a bands file, no need for a GUI. In the current implementation of splot in the viz module you can also pass the settings as --arguments and even use the presets that you have previously defined for yourself, as well as saving the plot or writing it to an image. So I would say that is about all the functionality you would need for just getting quick plots without the overhead of a GUI (quick doesn't mean simple and bad, they can be as beautiful and complex as the presets you have defined).

[zerothi]

But what about end-users who don't really know the difference?

I am a bit worried that users will confuse the two.
Could we perhaps have a middle ground sdisplay or sview, or something similar? Since all the functionality is passed down to sub-parsers I don't think we need two cli's.

My point being that while matplotlib plots are minor, they still do provide some level of interaction (change of limits etc.) so in that respect it may be considered a GUI.

Would you be very much against having sgui as the cli for everything?

[pfebrer]

Ok, I understand that it is hard to objectively draw a hard line between what is a GUI and what is not. The main problem is probably that we leave in a very nice era where plots themselves are interactive :)

The problem with sdisplay is that I don't see how a user would expect sdisplay to open a GUI that manages multiple plots and tabs (in the case of the viz.plotly GUI).

Probably one of the problems here is that we are trying to unify a very diverse set of functionalities in the case of the GUIs. For plots, splot or sdisplay is good for all engines of plotting, since in the end they all do the same but using different software. On the other hand, the viz.plotly GUI is focused on allowing you to manage multiple plots given the files that you have in your filesystem, while the ase gui focuses on modifying structures and the (future) blender gui will also focus mainly on modifying structures (and may have other features).

[zerothi]

Ok, I understand that it is hard to objectively draw a hard line between what is a GUI and what is not. The main problem is probably that we leave in a very nice era where plots themselves are interactive :)

The problem with sdisplay is that I don't see how a user would expect sdisplay to open a GUI that manages multiple plots and tabs (in the case of the viz.plotly GUI).

Probably one of the problems here is that we are trying to unify a very diverse set of functionalities in the case of the GUIs. For plots, splot or sdisplay is good for all engines of plotting, since in the end they all do the same but using different software. On the other hand, the viz.plotly GUI is focused on allowing you to manage multiple plots given the files that you have in your filesystem, while the ase gui focuses on modifying structures and the (future) blender gui will also focus mainly on modifying structures (and may have other features).

This makes me think that sgui should be used for everything ;)

[zerothi]

Alternatively the command sisl could be used to dispatch any functionality?

sisl geometry/geom siesta.XV siesta.fdf
sisl plotly RUN.fdf
sisl blender Rho.grid.nc
sisl ase RUN.fdf

or the likes?

[pfebrer]

By the way:

Would you be very much against having sgui as the cli for everything?

In my opinion it is not intuitive that sgui struct.bands will give you a bands plot. Maybe you could sgui plot struct.bands, but then you are making the process of quick plotting more complicated.

I would say that the main difference between gui and plot is in the timeframes (as weird as it sounds). One should be prepared to use much more of their time when they type sgui than when they type splot.

[zerothi]

Would you be very much against having sgui as the cli for everything?

In my opinion it is not intuitive that sgui struct.bands will give you a bands plot. Maybe you could sgui plot struct.bands, but then you are making the process of quick plotting more complicated.

In this case users would have to do sgui plot struct.bands
Agreed that sgui struct.bands shouldn't be favoured.

I would say that the main difference between gui and plot is in the timeframes (as weird as it sounds). One should be prepared to use much more of their time when they type sgui than when they type splot.

hmm, users could just do alias splot='sgui plot' and then not need to worry about anything? I am just more concerned that adding too many CLI's is confusing, if sgui plot is used alot, there are easy ways around that. Having this described in the documentation for the sgui would be absolutely fine to show how easy it is.

[pfebrer]

hmm, users could just do alias splot='sgui plot' and then not need to worry about anything? I am just more concerned that adding too many CLI's is confusing, if sgui plot is used alot, there are easy ways around that. Having this described in the documentation for the sgui would be absolutely fine to show how easy it is.

Ok, maybe we could provide a way to switch on/off the shortcuts (e.g. splot, sgeom) within sisl so that users don't need to do it themselves? Believe it or not, not everyone knows that they can define an alias or where to define it. And this is even more difficult to handle if sisl is inside an environment and you need to have the commands only when the environment is activated. Would it be possible to handle this from sisl?

[zerothi]

Ok, maybe we could provide a way to switch on/off the shortcuts (e.g. splot, sgeom) within sisl so that users don't need to do it themselves? Believe it or not, not everyone knows that they can define an alias or where to define it. And this is even more difficult to handle if sisl is inside an environment and you need to have the commands only when the environment is activated. Would it be possible to handle this from sisl?

Hmm... how should we then decide whether they should be present or not.
Perhaps it would be ok to have sgui and splot where splot is just sgui matplotlib/plot?

[pfebrer]

I don't know, I think this could be up to the users. By default they could be all turned off. And just something like sisl.create_cli_shortcut("splot", "sisl plot"). So in reality it would be just allowing users to create and manage aliases without having to know how to do that in the environment. Is it possible to do this?

[pfebrer]

The main problem is that users will not know how to set aliases in the environment and therefore most won't do it. (I don't know how to do it)

[pfebrer]

I don't know, I think this could be up to the users.

I retract myself, it's probably better to have consistent shortcuts accross sisl instalations. Sorry hahaha

[zerothi]

Hmm, we could do that, it would requires us to hook into the setuptools method for creating cli's I think.

Hmm, I am not a fan of this (lots of work for very little).

To create an alias, simply do this:

echo "alias splot='sgui plot'" >> $HOME/.bashrc

and done ;) next time you have a shell, you have this command.

For instance I have a shorthand:

alias cds='cd $HOME/path/to/sisl'

This lets me do cds anywhere and easily go to the sisl code repository.

[pfebrer]

Yes, what I mean is how to activate/deactivate aliases depending on the python environment you are in. I.e. I only want splot if I'm in my sisl environment.