Desde hace un par de días está disponible para su descarga Digikam 5.0, nueva versión de este programa de software libre, que nos permite catalogar y editar nuestras fotos digitales.
Han sido dos años de trabajo, en los que se ha reemplazado la mayor parte de su código escrito en Qt 4 sustituyéndolo por las bibliotecas más modernas de Qt 5. Con ello se facilita la introducción a nuevas plataformas y el disponer de las últimas herramientas de desarrollo.
Digikam ha estado ligado tradicionalmente al escritorio KDE, lo que en algunos momentos ha dificultado su portabilidad a otros sistemas como Windows y OS X.
En esta edición 5.0 se ha trabajado para disminuir esas dependencias, eliminando el 80% de ellas (aún así, si lo instaláis en GNOME o Xfce, de un par de docenas de programas KDE no os salva nadie).
Se han introducido nuevas características como:
- La capacidad de recuperar archivos que hayan sido borrados por accidente de nuestras colecciones (ahora disponemos de una especie de papelera virtual)
- Nuevo panel de preferencias, que facilita la gestión de etiquetas, comentarios, fechas, ratings…
- Sincronización de los metadatos de la imagen con los de la base de datos (en segundo plano y sin mayor dolor, utilizando la Lazy Synchronization tool)
- Mejora el rendimiento de la aplicación al eliminar KIO-slaves. Se ha desarrollado una solución multi-hilo para consultar la base de datos, que es mucho más rápida.
- Nueva interfaz para configurar la base de datos (MySQL/MariaDB).
- Se ha portado los Kipi-plugins a Qt5. Estamos hablando de complementos que extienden las capacidades del programa: exportar imágenes a servicios online, editar metadatos, remover el color rojo de los ojos, tratar imágenes en lotes, convertir raw a otros formatos, etc. Ahora será más fácil migrarlos a otros sistemas operativos, además de Linux.
- Se mejora el reconocimiento facial en las imágenes, ahora integrado plenamente en Digikan.
Si queréis saber más de esta nueva versión de Digikam 5.0, toda la información en su página web.
Es una de las razones por las que nunca instalo ningún programa de KDE. Cuando vas a instalar uno que es en plan chorra y te das cuenta de que te quiere instalar 400 MB y doscientas cincuenta mil historias dices ¿cómo? Va a ser que no. Es una pena, porque si no pasara esto los programas de KDE los usaría mucha más gente.
Eso era así en el pasado, pero ahora la situación es muy distinta gracias a la modularización de las bibliotecas de KDE (ver detalles en https://dot.kde.org/2013/09/25/frameworks-5). Hoy en día, un programa desarrollado por la comunidad KDE no debería arrastrar más de unos pocos MB en dependencias (excepto en el caso de programas muy grandes como Digikam).
¿Tú ves normal que para instalar el Kalarm, que es un programa sencillo para poner una hora y que suene la alarma, que pida semejante burrada? 248 MB en disco y te instala lo siguiente:
Se instalarán los siguientes paquetes: libkf5notifications-data, libkf5kiowidgets5, libkf5gapi-data, libkf5akonadicore-bin, libkf5kdelibs4support5, libkf5kdelibs4support-data, libkf5config-data, libkf5attica5, kdepim-runtime, akonadi-server, libkf5gravatar5, libqt5svg5, kinit, libkf5calendarsupport5, libkf5i18n-data, libkf5coreaddons-data, libdbusmenu-qt5, libkf5itemviews5, libkwalletbackend5-5, libkf5package5, libkf5package-data, libkf5codecs5, libkf5kiofilewidgets5, libkf5globalaccel5, libkf5calendarutils5, libkf5gapicontacts5, libkf5dbusaddons5, libkf5itemmodels5, libkf5calendarcore5, libkf5configwidgets-data, libkf5bookmarks-data, libkf5service-bin, libkf5gapidrive5, libkf5declarative5, libkf5gapicore5, libkf5akonadimime5, libkf5codecs-data, libkf5widgetsaddons-data, libboost-thread1.58.0, libkf5configcore5, libkf5messagecomposer5, libkf5notifyconfig-data, libkf5jobwidgets5, libkf5wallet-bin, libkf5kdepimdbusinterfaces5, libaio1, libpolkit-qt5-1-1, akonadi-backend-mysql, libkf5kdgantt2-5, libkf5quickaddons5, libkf5coreaddons5, libkf5globalaccel-data, libkf5contacts-data, libkf5textwidgets-data, libkf5akonadisearchpim5, libkf5holidays5, libkf5bookmarks5, kio, libkf5gpgmepp-pthread5, libkf5notifyconfig5, libgrantlee-templates5, libkf5incidenceeditorsng5, libkf5configwidgets5, libkf5configgui5, libkf5service5, libkf5completion5, libkf5kcmutils5, libkf5completion-data, libkf5wallet-data, kdepimlibs-kio-plugins, libkf5newstuff5, libxerces-c3.1, libkf5eventviews5, libkf5dbusaddons-data, mysql-client-core-5.7, libkf5gapitasks5, libkf5wallet5, libkf5contacts5, libkf5messageviewer5, libkf5newstuff-data, libkf5pimcommon5, libkf5xmlgui5, libkf5gapicalendar5, libkf5templateparser5, libkf5textwidgets5, libkf5imap5, libkf5declarative-data, libkf5pimtextedit5, libkf5guiaddons5, libkf5akonadicalendar5, libkf5solid5-data, libkf5sonnetcore5, libkf5ldap5, libqt5script5, libkf5emoticons5, libkf5akonadicontact5, libkf5akonadiprivate5, libkf5kiontlm5, libkf5tnef5, libkf5akonadiwidgets5, libkf5identitymanagement5, libkolab1, libkf5qgpgme5, libkf5libkleo5, libkf5windowsystem5, libfam0, libkf5webkit5, libkf5service-data, libphonon4qt5-4, libkf5kcmutils-data, libkf5iconthemes-data, libkf5jobwidgets-data, libkf5widgetsaddons5, libqt5xmlpatterns5, libkf5emoticons-data, libkf5sonnetui5, libkf5libkdepim5, libkf5auth-data, libkf5akonadicore5, libkf5sendlater5, libkf5itemviews-data, libkf5iconthemes5, libkf5auth5, libkf5windowsystem-data, libkf5parts-data, libkf5mailtransport-data, kdepimlibs-data, libkf5messagecore5, libkf5mailcommon5, libkf5xmlgui-data, libkf5solid5, libkf5mailtransport5, libkf5parts5, libkf5gpgmepp5, libkf5mailimporter5, libkf5crash5, libkf5mime5, libkf5kiocore5, libkf5archive5, mysql-server-core-5.7, libkf5akonadinotes5, libkolabxml1v5, libkf5akonadiagentbase5, libkf5notifications5, libkf5alarmcalendar5, libgrantlee-textdocument5, libkf5holidays-data, libkf5sonnet5-data, libkf5mbox5, libkf5followupreminder5, libkf5i18n5, libqt5sql5-mysql
¿Estamos locos?
Pero si se da el mismo caso cuando quieres instalar una aplicacion gtk si estas usando puro qt, toca instalar sepetecientas cosas ademas de los estilos para que no se vea horrible… Ahorita mismo estoy usando gtk pero recuerdo que hace tiempo cuando usaba qt trataba de evitar instalar cualquier aplicacion gtk y usaba alternativas en qt asi que no entiendo la queja es lo mismo para ambos lados.
No es ninguna queja. Es en referencia a lo que dice el artículo, que en esta versión de Digikam están tratando de que no haya esa dependencia y que a la hora de instalarla en otros entornos no se tenga que instalar tantísima cosa. Y yo he dicho que por eso no instalo cosas de KDE fuera de KDE. ¿Que al contrario ocurre también? No digo que no, tampoco sé si es al mismo nivel y pide tanto. Pero estamos hablando de una aplicación de KDE y de instalarla fuera de éste.
Igual, si estas usando un entorno gtk para que quieres kalarm? Yo por ejemplo si uso kde no instalo aplicaciones gtk a menos que sea necesario como por ejemplo Inkscape o libreoffice, ya que no existe nada comparable escrito en qt. Lo mismo me pasa cuando uso gnome o xfce: tengo que instalar programas kde o qt como scribus, krita, digikam, natron, kdenlive, etc., bien porque no hay nada gtk a la altura o bien porque me siento mas cómodo con una aplicación específica independientemente de la integración con el entorno. En suma que salvo aplicaciones profesionales y/o semiprofesionales no tiene sentido instalar utilidades que ya te brinda el entorno (y de nuevo si ya tienes gnome-clocks que está tan bien diseñada para que quieres kalarm?).
Dios… era un ejemplo macho. ¿Qué más da Kalarm que otro? He puesto ese porque era uno de los que sabía que pedían una barbaridad para lo que es. Y el porqué de instalar un programa de KDE en entorno GTK, ¿por qué no? Puede que haya algún programa que sí te interese por algo en concreto. Yo no veo que sea tan raro que uses KDE y quieras algo de Gnome y al revés. Además el artículo viene a decir eso. Que le han metido un meneo al programa para poder usarse en cualquier entorno.
Pero si yo coincido con el tema de las dependencias (mejor dicho no es que yo coincida es un problema bastante conocido que se está tratando de solucionar modularización mediante). Es solo que precisamente ese ejemplo -y otros de aplicaciones similares que se puedan dar- me pareció poco pertinente en un punto a que considero poco probable que alguien que usa un entorno diferente a kde estaría interesado en aplicaciones que cualquier entorno puede proveer, y que si hablamos de aplicaciones profesionales necesarias para una actividad profesional por ejemplo, cualquiera estaría dispuesto a gastarse 200/300 MB con los ordenadores de hoy. Y aun así, ahí sí que vale la pena invertir tiempo en reducir las dependencias, fundamentalmente porque son aplicaciones que trascienden el entorno kde. Pero el comentario no iba en plan de crítica, sino en función de que aplicaciones vale la pena hacer «menos kde», y esta, digikam, es claramente una, imho.
No sé si lo veo como «normal» pero sí como algo común. ¿Haz calculado cuánto espacio utilizas con el JRE de Java (en mi caso tengo instaladas 3 versiones para distintas aplicaciones)? ¿O con el intérprete de Python o Perl? ¿O con GTK?
Si el espacio en disco es una limitación importante para ti, entonces tendrás que elegir un framework y utilizar sólo aplicaciones basadas en él. Pero al menos para mí, gastar 250 MB en una aplicación útil no es una exageración; más aún considerando que la próxima aplicación Qt que utilices requerirá bastante menos espacio.
Con KDE Frameworks se ha hecho un gran esfuerzo para modularizar las dependencias de las aplicaciones (de ahí el listado gigante de paquetes a instalar que publicaste). Pero si el desarrollador decide utilizar un gran número de bibliotecas en su aplicación, entonces el resultado final seguirá siendo una instalación de algunos cientos de MB.
No es por el espacio. Es por el hecho de tener tantísimas librerías y dependencias. Mientras más haya, y de entornos diferentes, más probabilidades tienes de cargarte el sistema operativo en alguna actualización.
Prefiero usar gthumb