Hi Paul, Paul Wise <[email protected]> writes: > On Mon, Dec 7, 2015 at 3:58 PM, Ole Streicher wrote: >> At least for astronomy, most of the packages are part of some framework: >> Python, GDL, (ESO-) CPL etc. They usually have their user interface >> through the framework, which is more or less independent of the packages >> packages. For example, the CPL framework has ~12 plugins, and two user >> interfaces: one command line (esorex) and two Python (python-cpl). The >> Python interface is "import cpl; recipe = cpl.Recipe('muse_bias'). IMO >> it does not make any sense to screen-shoot this somehow, and also not >> the command line interface. Or do you have an other idea here? > > Screenshots of typical uses of command-line interfaces are useful IMO.
I was just browsing among several screenshots of command line tools. Apart from a few which have a quite simple, visible output (like reformat), many have just a screenshot of the manpage -- this shows that there is no really useful screenshot of the program itself possible. But if we consider a manpage having useful information here: why don't we include its information directly in the package metadata? Especially for science data, the command line usually just takes some input files, processes them and creates an output file. What you *see* there has nothing to do with the "usage" of the program itself -- sometimes (if the program creates images) one could use such an image (I did this for astrometry.net), but the program output itself is uninteresting. And, you see absolutely nothing on the iconic view (f.e. on packages.d.o, or the blends tasks pages). > For Python code, less so since Python is rarely written interactively > (I guess), but you seem to indicate that is common, so maybe they are > useful. For (many) scientists, Python is used heavily for interactive sessions. There are ipython and jupyter-notebook especially for that (the latter even with inline graphics). However, for a typical use the link to a tutorial is much more helpful than a screenshot to get a first impression. >>> Debtags are definitely not obsoleted by AppStream. >> >> Then, I didn't uderstand you right here. > > They are completely unrelated, I'm sorry if I gave the impression that > they were. The https://wiki.debian.org/Debtags/FAQ states: | What are future plans and perspectives? | debtags is rather mature, and not much is expected to happen besides | regular maintenance. | If you are looking for exciting new work you can look at the | Appstream project. And I must say that I don't see a real-world use for them. For example, the Blends package lists I am currently working on (wich is the origin of all the discussion here) would be a perfect place to use this information, or at least to display them in a nice form so that a user could benefit from them. However: I have no other idea than just to create a line "Tags" and plainly list them. Horribly useless. Andreas' Tasks pages also hide them in some tooltip; and they appear there as well just as plain tags. In packages.d.o they are at least on the main page, but also just as a plain list. I doubt this gives anything to a non-geek end user. Let's take two of my packages: esorex and astrometry.net. The first one has debtags, the second hasn't. Can you point me to a /any/ place in the Debian ecosystem where esorex benefits from its debtags, while astrometry.net doesn't? Could you specify a use case that is currently solved with the Debtags? And, for some reason they are maintained completely separate from the package (as is screenshots.d.o, BTW). When I create a package, I cannot just put them in d/control (or have a nice debian-helper for the trivial ones), there are no Lintian checks for them ("A package linked to the KDE libs should have the uitoolkit::qt tag"), I have no maintainers control over them (everyone can change/remove them), the debtags editor is ugly etc. This all is -- for a "matured" infrastructure -- not really overwhelming. > Personally I'd be motivated to correct the mistake, no matter the > circumstances. In the past I had the debtags creation integrated somehow in my package creation workflow -- although this was hard: I could not create my package and, while everything is still fresh, create the tags, but I had to wait until the package passed NEW. This may take some weeks or even months; I am then already busy with other stuff, have to mentally go back to the old package to create the tags. I did this for a while, but then I realized that some of the tags got lost without that I can see a reason -- then it starts to feel like a Don Quichotte fight. Screenshots are similar: As long as I am working on the package creation, I am quite close to the package; it would be easy to create a screenshot and include it in the package itself. But this is not the way to go; I even can't include the screenshot at this stage (since it is not in Debian then). I have to wait until the package is accepted, and even then I cannot always upload a screenshot (f.e. for python-yt it is impossible). And, screenshots get lost without a reason. How shall I "correct" this when the program is not of my daily use? But if your motivation is high, feel free to help creating screenshots and debtags :-) My isn't anymore :-( Best regards Ole
