[filelight] [Bug 406030] New: hard links multiply counted in usage totals
https://bugs.kde.org/show_bug.cgi?id=406030 Bug ID: 406030 Summary: hard links multiply counted in usage totals Product: filelight Version: unspecified Platform: Mint (Ubuntu based) OS: Linux Status: REPORTED Severity: minor Priority: NOR Component: general Assignee: martin.sandsm...@kde.org Reporter: cont...@ericlevy.name Target Milestone: --- SUMMARY Each hard link contributes to disk usage total even when duplicating same inode. STEPS TO REPRODUCE 1. Create a directory. 2. Copy a large file into the new directory. 3. Create several hard links to the file, within the same directory. 4. Scan directory in Filelight. OBSERVED RESULT Disk usage total is file size times number of links. EXPECTED RESULT Disk usage total is file size. SOFTWARE/OS VERSIONS Filelight: 17.12.3 Linux/KDE Plasma: Mint 19.1 Cinnamon KDE Frameworks Version: 5.44.0 Qt Version: 5.9.5 (built against 5.9.5) -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 404317] no CLI support for stdout export
https://bugs.kde.org/show_bug.cgi?id=404317 --- Comment #4 from brainchild --- I agree that it is a wish. I just hope that given the high benefit and low difficulty, it is not a forgotten wish. You are making a painting application, and facilitating conversion to a standard exchange or display format facilitates distribution of the paintings that artists create with that painting application. A studio painter requires paint, paintbrushes, canvas, and other source materials, as well as packaging materials, to allow shipping out finished paintings, in order to be a successful painter. Writing a scaled PNG outfile file, without creating intermediary artifacts, makes it easier to build web pages, publications, applications, and other larger works for which Krita documents are among the source material, and such support makes Krita a more useful and prolific tool. Thanks very much for considering the request. (For reference, from the man page of Inkscape, various formats can be specified by CLI switch for headless conversion, and '-' is accepted as a filename, representing standard output. Simple selections and manipulations are also supported.) -e, --export-png=FILENAME -a, --export-area=x0:y0:x1:y1 -C, --export-area-page -D, --export-area-drawing --export-area-snap -i, --export-id=ID -j, --export-id-only -t, --export-use-hints -b, --export-background=COLOR -y, --export-background-opacity=VALUE -d, --export-dpi=DPI -w, --export-width=WIDTH -h, --export-height=HEIGHT -P, --export-ps=FILENAME -E, --export-eps=FILENAME -A, --export-pdf=FILENAME -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 404317] no CLI support for stdout export
https://bugs.kde.org/show_bug.cgi?id=404317 --- Comment #2 from brainchild --- I am afraid that the purpose of the request may have been lost in your response. No part of the request had the intention, or would have the effect, of competing with ImageMagick. The purpose of this request, as is the purpose largely of standard input and output generally, is to facilitate interoperation of applications to achieve an effect that neither application fully supports in isolation. If you look at the example, you see that Krita is used to achieve an effect that ImageMagick cannot achieve, that is, to read a Krita file; whereas ImageMagick is used to create an effect that Krita cannot achieve, that is, command-line image processing. Together, through the pipe, the two applications do achieve this effect. Intermediary files are generally an option, but often create other issues, such as managing their deletion and finding a location to place them, in the case of scripts. If Krita did offer the full suite of processing capabilities via command line, then the pipe with ImageMagick might be unnecessary. As you correctly say, however, such is not the purpose of Krita. Krita should, however, permit easy interoperation with other tools via pipes, and my request that Krita open standard output instead of a physical file is hardly a tall order. Since no tool currently exists, to my knowledge, other than Krita, that can read a Krita file, the requested feature effectively augments not duplicates the current utility of ImageMagick, such as in the case of producing a JPEG file to half the scale of an existing Krita file. I understand that "feature request" might be a better classification than "bug" for this issue, but I ask you to take it seriously, given the low difficulty of implementation and the considerable utility of use. Given the prevalence and usefulness of support for standard output, I am inclined to suggest that the request is closer to a missing feature than to merely a nice-to-have. Please consider not giving it a classification so low that it is unlikely to be noticed. Thank you for reviewing the clarification, and for taking the time to understand the rationale. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 404317] New: no CLI support for stdout export
https://bugs.kde.org/show_bug.cgi?id=404317 Bug ID: 404317 Summary: no CLI support for stdout export Product: krita Version: unspecified Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: General Assignee: krita-bugs-n...@kde.org Reporter: cont...@ericlevy.name Target Milestone: --- SUMMARY Krita supports a command-line --export switch for automated conversion to standard formats, but only for physical files. OBSERVED RESULT No support is documented for writing to standard out, and using either /dev/stdout (Linux version) or a dash in the argument list causes the application to exit silently without any error or output. EXPECTED RESULT A dash can be used to indicate standard output for filename. A mechanism to specify format is needed, as it cannot be inferred from any filename, though this support should exist separately anyway, to support cases of nonstandard extensions. Numerous use cases can be easily imagined for processing conversion output directly by another tool. Avoiding temporary files is extremely convenient, and is largely the purpose of standard output and standard input support by the OS. Example: % krita foo.kra --export -export-filename png:- | convert - -trim +repage -resize 50% foo.jpg As no third-party tools currently support conversion from Krita format, adding such a feature would improve usability where automation is required. ADDITIONAL INFORMATION Though not worth separate reports, two further observations present. During conversion, the application loads the graphics layer, even if not to open any window, and prints substantial diagnostic and informational output to standard error. Ideally, file conversion can occur with optimal efficiency, and in any environment, even headless. Bypassing the graphics layer, and behaving as though a CLI-only tool, whenever the command invocation does not require graphics, is best. Further, scripting support is best served by eliminating console output except for errors or essential warnings. -- You are receiving this mail because: You are watching all bug changes.
