I think this is a great start :)
Why is it called logviewer and not dataviewer?

I like the tools folder, where we could collect useful tools like this!

🌟 definitely interested!

Why is it called logviewer and not dataviewer?

Sounds right to me, DataViewer, or showing my Igor roots, DataBrowser :)
Logs to me are automatic, usually chronological data collection, which we don't have yet but we will!

I like the tools folder, where we could collect useful tools like this!

👍 @peendebak what would it take to make this user-friendly? I guess the biggest thing maybe would be to handle any arbitrary data set, not just amplitude... It would be awesome to build this into either DataSet or QtPlot and MatPlot so that here and anywhere else we could just say "plot this dataset" and it makes a reasonable plot of all the data it finds, making subplots as needed.

I'll change the name to DataViewer, that sounds better. Some things do be done to make it more usable:

• Automatically plot any dataset. But which array should we plot? I think the following might work: if there is a field defaultplot in the .metadata of the DataArray then plot this array, otherwise plot the first array in the DataArray .
• Make the data storage format universal. Right now I assume all recordings are in the GNUplot format and have the format [data]/[time]/xxx.dat. I think the [date]/[time] part is good, but I suspect that for other data formats (e.g. hfd5) it will be something like [data]/[time].bin
• Automatically update the view if a new dataset is recorded. This requires callbacks from the qcodes framework.

• at least 80 % tested

I like this, good job! 🌷
But do we want to stick to qt based backends, the web-browser is mature enough to be used as a backend, which wins us a zero-overhead install and more portability (qt does not run on mobile) ?

👍 @peendebak this looks awesome, this makes me very happy !

@giulioungaretti I do not think qt (pyqtgraph) is a heavy requirement for a data browser. Using the web-browser is possible, but I find that if does not work well when doing research (I have no control over any web-based interface).

@giulioungaretti How do we test such a thing? I need at least datasets to be plotted I guess. Is it ok to add datasets for testing to the repository?

@alexcjohnson I renamed the thing to DataViewer.

Now any 1D or 2D dataset can be plotted. By default amplitude is selected, but this can be changed in the DataViewer. As a fallback the first parameter is plotted.

@ everyone somehow I feel like this should be in a different repo like qcodes/tools
ofc not important now, but let me know what you think.

@peendebak testing:

• having data is perfectly fine for now (they should sit on qcodes/data), however if they are too big (more than 10mb say) then it's really annoying
• there are more fancy options (like git annex or submodules) but a bit tedious to maintain
• one can also jut generate them on the fly with test SetUp and TearDown (which is usually a better idea, but also takes more time)

So, up to you all are fine for me.

BUT, if you have data then it's not unit tests, but integration tests, which are two different beasts

Ideally one has both, unit testing every function and then integration testing the whole thing.
I usually have an hard time doing unit testing when my functions do more than one "conceptual" step at once but YMMV.

Unfortunately I won't be able to give hands-on suggestion before 1st june 🎅

@giulioungaretti
I think we need basic datasets in the repo, so a newcomer can chek if stuff works with the examples. Just as in the examples folder for the notebook 'load-old-data' thing.
But it should not change with every new commit! So what we did there is have a basic dataset, but gitignore it, so there is one version in the repo and not every commit updates a new dataset, unless something crucial changes (i.e. metadata snapshot).

I do not think qt (pyqtgraph) is a heavy requirement for a data browser. Using the web-browser is possible, but I find that if does not work well when doing research (I have no control over any web-based interface).

I have one computer here that I've tried several times to get Qt working on, and somehow still cannot... so even if in this case I'm just doing something dumb, I guarantee that this will not be a straightforward dependency for all users. While it's heavier from the perspective of the code we have to write (Python + HTML + Javascript), I think eventually we should make all of these features available through a web-based interface. That doesn't mean we need to take out Qt - I see great value in supporting multiple platforms. I just don't want it to be a base requirement.

@ everyone somehow I feel like this should be in a different repo like qcodes/tools

Perhaps once we get to greater core stability (at the very least after we start semver in earnest with the core) we could do that. In the short term it seems easier to keep it all together for coordinated changes. Also from a user perspective it's nice if qcodes can all be installed and updated as a single package... which may be fine from an end-user perspective (setup.py will take care of it all), but as developer-users it seems easier to keep one repo up to date than several, since they'll all be used as a unit. But perhaps it's just that I don't really understand how that workflow would look, I'm happy to be shown better ways!

having data is perfectly fine for now (they should sit on qcodes/data), however if they are too big (more than 10mb say) then it's really annoying

If they are just in service of testing, I would prefer to keep them in qcodes/tests/data or something. But yes, lets keep them small.

@alexcjohnson I totally agree, in one way the best requirement is no requirement at all :D
I am not super duper in love with web browsers but it's a fact that they are now performing enough and most of all ubiquitous (in their modern versions that is).

The ultimate goal is tho have a backend that is frontend agnostic, but offers just enough api that gluing a web browser and or qt is really easy.
But @peendebak I see what you mean, as in you can tweak qt stuff because you know python but not necessarily web based stuff, or did I mis understand ?
Note that in the long run qt can also bite (read memory/speed and not so tiny detail, licensing. )

Lastly, one could also start dreaming out native GUI, either by using electron (http://electron.atom.io/) or some other wizardy ( react native, etcetc).

@alexcjohnson I actually though the opposite, that it's nicer to develop if all the components (that are somehow independent) are sitting in their own repo. But yes, let's wait before we reach version > 0.x!

@alexcjohnson whopsi, that's what I meant.

I will just put this here for reference. I developed a 1d and 2d dataset plotting tool which is located at https://github.com/Rubenknex/qtplot. It is based on pyqt as I did not have experience with interactive websites and just thought that this would be faster/more stable.

This might be something to build on when making a data visualization application.

Current coverage is 82.82% (diff: 100%)

No coverage report found for master at b8ecc75.

Powered by Codecov. Last update b8ecc75...6f73462

Here is an overview of what got changed by this pull request:

Issues
======
- Added 2

See the complete overview on Codacy

Here is an overview of what got changed by this pull request:

Issues
======
- Added 2

See the complete overview on Codacy