KDE Dependancy Mess

Hi,

I do humbly request someone in charge to finally fix KDE dependency mess. Please read full rationale and explanation.

The following applications are a complete inconsistent mess:
- gwenview
- digikam:
a) digikam
b) showphoto
-sddm
-screen/system locking

1st rationale:
where is a showphoto where you can create HDR pic from photos with different exposure? Nowhere. It hinds behind digikam. What if I don't want my Home folder polluted with databases and complete copies what I already have in my Pictures folder? I can't find showphoto in my package manager anywhere. When I install digikam, there it is in the menu.

2nd rationale:
You must decide what renders photos/pictures. It is either qt5-imageformats or imagemagick. Decide which one in the whole plasma. Gwenview uses qt5-imageformats, but showphoto uses imagemagick. This way when you have jpeg2000/jp2 (from 20 years ago) your default photoviewer ie gwenview cannot display them. But showphoto can. Clicking in Dolphin on jp2 gives us gwenview popup with error.

3rd rationale:
imagemagick IS NOT A SYSTEM LIBRARY. First when you install imagemagick you are faced with absolute wrong and messed up software:
a) imagemagick adds itself to bash with e.g. the following commands: compare, display. What if I do already have an alias "compare" or "display" what if system library uses compare or display. It will revoke imagemagick? WTF?
b) imagemagick wiki is ****. Sorry its ****. Its neither $ imagemagick display nor $ magick display to display photos. Its just hidden option $ display as if imagemagick
was a sytem library. No it isn't. Imagemagick is just a photo display manipulation library without GUI.

4th rationale:
Because of the above imagemagick was forked into grahpicsmagic. All is done via one command 'gm'. That's it. No messing with your bash, no messing with your aliases and no pretending to be a system library. Beautiful.

From the graphicsmagick official website we learn:

Image processing is multi-threaded using OpenMP (read about OpenMP in GraphicsMagick) so that CPU-bound tasks scale linearly as processor cores are added. OpenMP support requires compilation with GCC 4.2 (or later), or use of any C compiler supporting at least the OpenMP 2.0 specification.

Important: qt5-imagformats is using too much CPU- to test open your library photo with gwenview and htop. Press space bar on the keyboard quckly multiple times to browsw through the photos and see for yourself as your CPU spikes to 80%. Not good. Not good at all.

GraphicsMagick provides a powerful command line utility gm, which may be used to access all GraphicsMagick functions. Gm uses a consistent set of options (see options documentation). GraphicsMagick provides access to major commands via a single executable command-line program; for example, to use the "convert" sub-command, type gm convert .... The available commands are as follows: http://www.graphicsmagick.org/utilities.html )

GraphicsMagick is the swiss army knife of image processing. Comprised of 267K physical lines (according to David A. Wheeler's SLOCCount) of source code in the base package (or 1,225K including 3rd party libraries) it provides a robust and efficient collection of tools and libraries which support reading, writing, and manipulating an image in over 89 major formats including important formats like DPX, GIF, JPEG, JPEG-2000, PNG, PDF, PNM, TIFF, and WebP.


Summery what is expected:
Make KDE software compilation dependant only on one display engine:
1. Make Dolphin display thumbnails via grahpicsmagic not via qt5-imageformats (or ffmpeg)
2. Substitute imagemagick as dependancy and enginge in digikam/shophoto to better graphicsmagick (Phoronix uses graphicsmagick for test not imagemagick)
3. Make other KDE software use graphicsmagic as display engine (e.g. gwenview uses incomplete qt5-imageformats that cant display for example jpeg2000/jp2)
4. Use the same graphicsmagick libarary for SDDM as well as for Screen/sytem locking

Using just graphicsmagick you will end up with a lean non-messy system. We will have only one have only one engine/display library for everything i.e. code correct, non-messy graphicsmagic. Soon we will have avif compression everywhere and one library to support is awesome. You can contribute to this libary too. No need for stupid or missing qt5-webengine plugins where they are nowhere to find and broken plasma apps (vide avif or jp2).

Thank you, I hope you understand the above.

PS. Avif is amazing. Its simply awesome !!! (12bit-pq rocks, amazing quality and ridiculosly small file size. I love it...)

PS2. Teach the idiots from varous distros not to use lightdm (another display libary missing webp for example....) and use sddm (...).

Great first post! I really hope I am the only one demotivated by the style of your writing, so someone else will answer. Also, If you are so well-informed, why don't you help fixing those issues? By the way, my digikam doesn't need the imagemagick dependency, it is purely optional.