[digiKam-users] Future of digiKam bundles...

classic Classic list List threaded Threaded
86 messages Options
12345
Reply | Threaded
Open this post in threaded view
|

Re: Future of digiKam bundles...

Gilles Caulier-4
Ahh (:=)))

Gilles

Le mar. 26 mai 2020 à 15:08, Brian Morrison <[hidden email]> a écrit :

>
> On Mon, 2020-05-25 at 23:49 +0200, Gilles Caulier wrote:
> > Look like digiKam will be also added to official FlatHub repository
> > soon :
> >
> > https://github.com/flathub/flathub/pull/1544#pullrequestreview-417884061
> >
>
> https://www.xkcd.com/927/
>
> --
>
> Brian
>
>
Reply | Threaded
Open this post in threaded view
|

[digiKam-users] simple crashed middle of face detection

Tóth Csaba
In reply to this post by Brian Morrison
Hello!

In windows 10, the Build date: May 22 2020 (target: RelWithDebInfo)
version is simple crashed in the middle of the face detection.

I started the detection on about 10K+ images (Tiff and JPEG), with
detect all and merge options. the face detection in the settings file is
"3".

In one minute its about 17% the next the whole digikam is vanished. No
error, no logs, nothing.

Any suggestion?

Thanx

Csaba

Reply | Threaded
Open this post in threaded view
|

Re: Future of digiKam bundles...

Gilles Caulier-4
In reply to this post by Gilles Caulier-4
Done !!!

digiKam is now avaialble on FlatHub :

https://flathub.org/apps/details/org.kde.digikam

Best

Gilles Caulier

Le lun. 25 mai 2020 à 17:49, Gilles Caulier <[hidden email]> a écrit :

>
> Look like digiKam will be also added to official FlatHub repository soon :
>
> https://github.com/flathub/flathub/pull/1544#pullrequestreview-417884061
>
> Gilles Caulier
>
> Le lun. 25 mai 2020 à 15:09, Gilles Caulier <[hidden email]> a écrit :
> >
> > Hi,
> >
> > Another important point : the Flatpak do not include yet the
> > application translations files. It's relevant by the missing
> > sunversion executable on the KDE server.
> >
> > And yes, all translations team from KDE project still to use
> > subversion to host i18n data.
> >
> > As whole KDE migrate progressively from an own git/svn servers to
> > gitlab, i read that i18n will also migrate to git in the near future.
> > So wait and see...
> >
> > Best
> >
> > Gilles Caulier
> >
> > Le lun. 25 mai 2020 à 12:04, Gilles Caulier <[hidden email]> a écrit :
> > >
> > > Hi,
> > >
> > > I just updated the Flatpak notice page on digikam source repository :
> > >
> > > https://invent.kde.org/graphics/digikam/-/tree/master/project/bundles/flatpak
> > >
> > > digiKam Flatpak is now compiled with ALL non-deprecated options,
> > > including Web services using KIO. Look like the application resume is
> > > well documented now, with plenty of screenshots.
> > >
> > > By non deprecated, i want mean the 2 ones : Baloo and Akonady
> > > supports. Both make a mess with digiKam (especially Baloo).
> > >
> > > As i read, Flatpak is able to notify users when a new version is
> > > published. I don't yet verified if it work well.
> > >
> > > On Flatpak, it's possible to rate and review the application. So don't
> > > hesitate to promote the application.
> > >
> > > My best
> > >
> > > Gilles Caulier
> > >
> > >
> > > Le dim. 24 mai 2020 à 12:24, Gilles Caulier <[hidden email]> a écrit :
> > > >
> > > > Hi all users,
> > > >
> > > > I would to give some feedback about the digiKam bundles migration advance...
> > > >
> > > > The current files provided by the project are listed below :
> > > >
> > > > - Linux AppImage 64 bits
> > > > - Linux AppImage 32 bits
> > > > - Macos Package installer 64 bits (based on Macports)
> > > > - Windows installer 64 bits (compiled with MXE - MinGW)
> > > > - Windows installer 32 bits (compiled with MXE - MinGW)
> > > >
> > > > Current problems for these bundles are listed below :
> > > >
> > > > - AppImage : not signed, do not support KIO extensions, do not support
> > > > ICU (language extension), not published on official repository.
> > > > - MacOS package : It's not relocatable, even if MacOS support well
> > > > this feature. I don't found the time to finalize yet the install
> > > > relocation support in bash script. Package is not published on MacOS
> > > > store.
> > > > - MXE Windows installer : not signed, not published on Windows store.
> > > > Do not support KIO extension.
> > > >
> > > > But we have a new one starting to work and i working on : FlatPak
> > > >
> > > > This one is signed, published of official repository automatically
> > > > (you can install it on Discover application for ex). It support ICU
> > > > and KIO too... FlatPak is compiled on KDE infrastructure nightly and
> > > > automatically. Only a 64 bits version is supported.
> > > >
> > > > This want mean that AppImage end of life is near. We will still
> > > > publish officially the AppImage until 7.0.0, but later, if FlatPak do
> > > > the job as well, AppImage will be dropped...
> > > >
> > > > For Windows, all the digiKam code compile fine under Microsoft Visual
> > > > C++ compiler. This is the goal to obtain a signed and published
> > > > version on Microsoft store. You can imagine that Microsoft will only
> > > > support the official Windows compiler, and not GCC to permit to sign
> > > > and publish application on the store. Don't forget, Microsoft is well
> > > > Closed Source (:=))))
> > > >
> > > > Microsoft compiler is just the hell. It slow and require a Windows
> > > > operating system. The current cross compilation solution that we use
> > > > work fully under Linux, and compilation time are reduced by 4/5 ! A
> > > > full Linux Workflow is a non virus guaranty !
> > > >
> > > > The Visual C++ workflow is also only available on 64 bits and is
> > > > computed on KDE infrastructure, but the installer compilation is
> > > > broken due to a weird configuration on KDE infrastructure. I currently
> > > > try to found a work around.
> > > >
> > > > Personalty, i don't want to left MXE solution for the moment.
> > > >
> > > > For MacOS, the KDE infrastructure based on Craft compilation framework
> > > > will be a solution to sing and publish a relocatable package for
> > > > Apple. digiKam do not compile yet due to  missing dependencies.
> > > >
> > > > Voilà, i hope to be enough clear with these technical points.
> > > >
> > > > My best
> > > >
> > > > Gilles Caulier
Reply | Threaded
Open this post in threaded view
|

Re: Future of digiKam bundles...

jdd@dodin.org
Le 29/05/2020 à 12:29, Gilles Caulier a écrit :
> Done !!!
>
> digiKam is now avaialble on FlatHub :
>
> https://flathub.org/apps/details/org.kde.digikam
>

thanks :-)

but... it didn't find the config that the 7.0 appimage uses.

is there a way to copy the necessary files from appimage config
(presumably in ~  or some toher place) to the flathub place? (its rather
complicated to rebuild it)

thanks jdd

--
http://dodin.org
Reply | Threaded
Open this post in threaded view
|

Re: Future of digiKam bundles...

Bugzilla from martin.tlustos@gmail.com

 

 

Am Freitag, 29. Mai 2020, 12:45:06 CEST schrieb [hidden email]:

> Le 29/05/2020 à 12:29, Gilles Caulier a écrit :

> > Done !!!

> >

> > digiKam is now avaialble on FlatHub :

> >

> > https://flathub.org/apps/details/org.kde.digikam

> >

>

> thanks :-)

>

> but... it didn't find the config that the 7.0 appimage uses.

I'm not sure, but you might need to activate access to your home directory with flatseal (at least that solved some problem with other flatpaks for me)...

 

Martin

>

> is there a way to copy the necessary files from appimage config

> (presumably in ~  or some toher place) to the flathub place? (its rather

> complicated to rebuild it)

>

> thanks jdd

>

>

 

 

Reply | Threaded
Open this post in threaded view
|

Re: Future of digiKam bundles...

Stuart T Rogers
In reply to this post by jdd@dodin.org
Well I just installed this to try it and on openSUSE it seems I have to
start Discover in order to run Digikam and it is very slow when compared
with my normal RPM starting up. So far I've not found any way to
configure it so that for example it always runs on the same virtual
desktop. Looks like it has not found my original config files as it is
going through its normal first time run screens so I cancelled it.

Not impressed considering it is taking over 400mb on disk and starts
very very slowly. Now this could be partly due to openSUSE
implementation but user friendly it is not!

Stuart


--
Website: https://www.stella-maris.org.uk
or:      https//www.broadstairs.org
Reply | Threaded
Open this post in threaded view
|

Re: Future of digiKam bundles...

NeiNei
In reply to this post by Gilles Caulier-4
Thanks and Congrats :-)

On 29/05/2020 12:29, Gilles Caulier wrote:

> Done !!!
>
> digiKam is now avaialble on FlatHub :
>
> https://flathub.org/apps/details/org.kde.digikam
>
> Best
>
> Gilles Caulier
>
> Le lun. 25 mai 2020 à 17:49, Gilles Caulier <[hidden email]> a écrit :
>> Look like digiKam will be also added to official FlatHub repository soon :
>>
>> https://github.com/flathub/flathub/pull/1544#pullrequestreview-417884061
>>
>> Gilles Caulier
>>
>> Le lun. 25 mai 2020 à 15:09, Gilles Caulier <[hidden email]> a écrit :
>>> Hi,
>>>
>>> Another important point : the Flatpak do not include yet the
>>> application translations files. It's relevant by the missing
>>> sunversion executable on the KDE server.
>>>
>>> And yes, all translations team from KDE project still to use
>>> subversion to host i18n data.
>>>
>>> As whole KDE migrate progressively from an own git/svn servers to
>>> gitlab, i read that i18n will also migrate to git in the near future.
>>> So wait and see...
>>>
>>> Best
>>>
>>> Gilles Caulier
>>>
>>> Le lun. 25 mai 2020 à 12:04, Gilles Caulier <[hidden email]> a écrit :
>>>> Hi,
>>>>
>>>> I just updated the Flatpak notice page on digikam source repository :
>>>>
>>>> https://invent.kde.org/graphics/digikam/-/tree/master/project/bundles/flatpak
>>>>
>>>> digiKam Flatpak is now compiled with ALL non-deprecated options,
>>>> including Web services using KIO. Look like the application resume is
>>>> well documented now, with plenty of screenshots.
>>>>
>>>> By non deprecated, i want mean the 2 ones : Baloo and Akonady
>>>> supports. Both make a mess with digiKam (especially Baloo).
>>>>
>>>> As i read, Flatpak is able to notify users when a new version is
>>>> published. I don't yet verified if it work well.
>>>>
>>>> On Flatpak, it's possible to rate and review the application. So don't
>>>> hesitate to promote the application.
>>>>
>>>> My best
>>>>
>>>> Gilles Caulier
>>>>
>>>>
>>>> Le dim. 24 mai 2020 à 12:24, Gilles Caulier <[hidden email]> a écrit :
>>>>> Hi all users,
>>>>>
>>>>> I would to give some feedback about the digiKam bundles migration advance...
>>>>>
>>>>> The current files provided by the project are listed below :
>>>>>
>>>>> - Linux AppImage 64 bits
>>>>> - Linux AppImage 32 bits
>>>>> - Macos Package installer 64 bits (based on Macports)
>>>>> - Windows installer 64 bits (compiled with MXE - MinGW)
>>>>> - Windows installer 32 bits (compiled with MXE - MinGW)
>>>>>
>>>>> Current problems for these bundles are listed below :
>>>>>
>>>>> - AppImage : not signed, do not support KIO extensions, do not support
>>>>> ICU (language extension), not published on official repository.
>>>>> - MacOS package : It's not relocatable, even if MacOS support well
>>>>> this feature. I don't found the time to finalize yet the install
>>>>> relocation support in bash script. Package is not published on MacOS
>>>>> store.
>>>>> - MXE Windows installer : not signed, not published on Windows store.
>>>>> Do not support KIO extension.
>>>>>
>>>>> But we have a new one starting to work and i working on : FlatPak
>>>>>
>>>>> This one is signed, published of official repository automatically
>>>>> (you can install it on Discover application for ex). It support ICU
>>>>> and KIO too... FlatPak is compiled on KDE infrastructure nightly and
>>>>> automatically. Only a 64 bits version is supported.
>>>>>
>>>>> This want mean that AppImage end of life is near. We will still
>>>>> publish officially the AppImage until 7.0.0, but later, if FlatPak do
>>>>> the job as well, AppImage will be dropped...
>>>>>
>>>>> For Windows, all the digiKam code compile fine under Microsoft Visual
>>>>> C++ compiler. This is the goal to obtain a signed and published
>>>>> version on Microsoft store. You can imagine that Microsoft will only
>>>>> support the official Windows compiler, and not GCC to permit to sign
>>>>> and publish application on the store. Don't forget, Microsoft is well
>>>>> Closed Source (:=))))
>>>>>
>>>>> Microsoft compiler is just the hell. It slow and require a Windows
>>>>> operating system. The current cross compilation solution that we use
>>>>> work fully under Linux, and compilation time are reduced by 4/5 ! A
>>>>> full Linux Workflow is a non virus guaranty !
>>>>>
>>>>> The Visual C++ workflow is also only available on 64 bits and is
>>>>> computed on KDE infrastructure, but the installer compilation is
>>>>> broken due to a weird configuration on KDE infrastructure. I currently
>>>>> try to found a work around.
>>>>>
>>>>> Personalty, i don't want to left MXE solution for the moment.
>>>>>
>>>>> For MacOS, the KDE infrastructure based on Craft compilation framework
>>>>> will be a solution to sing and publish a relocatable package for
>>>>> Apple. digiKam do not compile yet due to  missing dependencies.
>>>>>
>>>>> Voilà, i hope to be enough clear with these technical points.
>>>>>
>>>>> My best
>>>>>
>>>>> Gilles Caulier


Reply | Threaded
Open this post in threaded view
|

Re: Future of digiKam bundles...

jdd@dodin.org
In reply to this post by Stuart T Rogers
Le 29/05/2020 à 13:24, Stuart T Rogers a écrit :
> Well I just installed this to try it and on openSUSE

same for me openSUSE Leap 15.1

  it seems I have to
> start Discover in order to run Digikam

no, I found it in the usual kde menu

  and it is very slow when compared
> with my normal RPM starting up.

the 7.0 beta appimage takes ages to start, not the flathub one :-)

  So far I've not found any way to
> configure it so that for example it always runs on the same virtual
> desktop.

works for me (just tested)

Looks like it has not found my original config files as it is
> going through its normal first time run screens so I cancelled it.

same,

it's my first use of flatpak, looks like flatpak have it's own root, so
it misses lot of my disks...

jdd

--
http://dodin.org
Reply | Threaded
Open this post in threaded view
|

Re: Future of digiKam bundles...

jdd@dodin.org
In reply to this post by Bugzilla from martin.tlustos@gmail.com
Le 29/05/2020 à 13:17, Martin Tlustos a écrit :

> I'm not sure, but you might need to activate access to your home
> directory with flatseal (at least that solved some problem with other
> flatpaks for me)...
>

nothing of that name in my openSUSE :-(

jdd


--
http://dodin.org
Reply | Threaded
Open this post in threaded view
|

Re: Future of digiKam bundles...

woenx
In reply to this post by AndriusWild
First of all, thank you Gilles for all the work.

I have installed digikam in ubuntu using the flatpak command. It seems to
work fine.

However, I have one question. I wanted to re-use the configuration file and
the color schemes from my appimage digikam. I found that the new digikamrc
configuration file is now at ~/.var/app/org.kde.digikam/ (instead of
~/.config/), but I cannot find where the .color files should be placed now
(they used to be at ~/.local/share/digikam/colorschemes)/.

What should be the new path for these files?

Thanks in advance.



--
Sent from: http://digikam.1695700.n4.nabble.com/digikam-users-f1735189.html
Reply | Threaded
Open this post in threaded view
|

Re: Future of digiKam bundles...

jdd@dodin.org
Le 29/05/2020 à 14:17, woenx a écrit :

> However, I have one question. I wanted to re-use the configuration file and
> the color schemes from my appimage digikam. I found that the new digikamrc
> configuration file is now at ~/.var/app/org.kde.digikam/ (instead of
> ~/.config/),

thanks, it solved part of my config problem

for the rest, I had to understand that flatpak is a chrooted
environment, I have to add my disk path with "flatpak override
--filesystem=XXX"

now it works

:-)

jdd


--
http://dodin.org
Reply | Threaded
Open this post in threaded view
|

Re: Future of digiKam bundles...

MarPar
In reply to this post by Gilles Caulier-4
Good news!

On my KDE Neon 18.04 the new digiKam on FlatHub works fine!

Many thanks again for the past, present and future work!

MarPar

Il 29/05/20 12:29, Gilles Caulier ha scritto:

> Done !!!
>
> digiKam is now avaialble on FlatHub :
>
> https://flathub.org/apps/details/org.kde.digikam
>
> Best
>
> Gilles Caulier
>
> Le lun. 25 mai 2020 à 17:49, Gilles Caulier <[hidden email]> a écrit :
>> Look like digiKam will be also added to official FlatHub repository soon :
>>
>> https://github.com/flathub/flathub/pull/1544#pullrequestreview-417884061
>>
>> Gilles Caulier
>>
>> Le lun. 25 mai 2020 à 15:09, Gilles Caulier <[hidden email]> a écrit :
>>> Hi,
>>>
>>> Another important point : the Flatpak do not include yet the
>>> application translations files. It's relevant by the missing
>>> sunversion executable on the KDE server.
>>>
>>> And yes, all translations team from KDE project still to use
>>> subversion to host i18n data.
>>>
>>> As whole KDE migrate progressively from an own git/svn servers to
>>> gitlab, i read that i18n will also migrate to git in the near future.
>>> So wait and see...
>>>
>>> Best
>>>
>>> Gilles Caulier
>>>
>>> Le lun. 25 mai 2020 à 12:04, Gilles Caulier <[hidden email]> a écrit :
>>>> Hi,
>>>>
>>>> I just updated the Flatpak notice page on digikam source repository :
>>>>
>>>> https://invent.kde.org/graphics/digikam/-/tree/master/project/bundles/flatpak
>>>>
>>>> digiKam Flatpak is now compiled with ALL non-deprecated options,
>>>> including Web services using KIO. Look like the application resume is
>>>> well documented now, with plenty of screenshots.
>>>>
>>>> By non deprecated, i want mean the 2 ones : Baloo and Akonady
>>>> supports. Both make a mess with digiKam (especially Baloo).
>>>>
>>>> As i read, Flatpak is able to notify users when a new version is
>>>> published. I don't yet verified if it work well.
>>>>
>>>> On Flatpak, it's possible to rate and review the application. So don't
>>>> hesitate to promote the application.
>>>>
>>>> My best
>>>>
>>>> Gilles Caulier
>>>>
>>>>
>>>> Le dim. 24 mai 2020 à 12:24, Gilles Caulier <[hidden email]> a écrit :
>>>>> Hi all users,
>>>>>
>>>>> I would to give some feedback about the digiKam bundles migration advance...
>>>>>
>>>>> The current files provided by the project are listed below :
>>>>>
>>>>> - Linux AppImage 64 bits
>>>>> - Linux AppImage 32 bits
>>>>> - Macos Package installer 64 bits (based on Macports)
>>>>> - Windows installer 64 bits (compiled with MXE - MinGW)
>>>>> - Windows installer 32 bits (compiled with MXE - MinGW)
>>>>>
>>>>> Current problems for these bundles are listed below :
>>>>>
>>>>> - AppImage : not signed, do not support KIO extensions, do not support
>>>>> ICU (language extension), not published on official repository.
>>>>> - MacOS package : It's not relocatable, even if MacOS support well
>>>>> this feature. I don't found the time to finalize yet the install
>>>>> relocation support in bash script. Package is not published on MacOS
>>>>> store.
>>>>> - MXE Windows installer : not signed, not published on Windows store.
>>>>> Do not support KIO extension.
>>>>>
>>>>> But we have a new one starting to work and i working on : FlatPak
>>>>>
>>>>> This one is signed, published of official repository automatically
>>>>> (you can install it on Discover application for ex). It support ICU
>>>>> and KIO too... FlatPak is compiled on KDE infrastructure nightly and
>>>>> automatically. Only a 64 bits version is supported.
>>>>>
>>>>> This want mean that AppImage end of life is near. We will still
>>>>> publish officially the AppImage until 7.0.0, but later, if FlatPak do
>>>>> the job as well, AppImage will be dropped...
>>>>>
>>>>> For Windows, all the digiKam code compile fine under Microsoft Visual
>>>>> C++ compiler. This is the goal to obtain a signed and published
>>>>> version on Microsoft store. You can imagine that Microsoft will only
>>>>> support the official Windows compiler, and not GCC to permit to sign
>>>>> and publish application on the store. Don't forget, Microsoft is well
>>>>> Closed Source (:=))))
>>>>>
>>>>> Microsoft compiler is just the hell. It slow and require a Windows
>>>>> operating system. The current cross compilation solution that we use
>>>>> work fully under Linux, and compilation time are reduced by 4/5 ! A
>>>>> full Linux Workflow is a non virus guaranty !
>>>>>
>>>>> The Visual C++ workflow is also only available on 64 bits and is
>>>>> computed on KDE infrastructure, but the installer compilation is
>>>>> broken due to a weird configuration on KDE infrastructure. I currently
>>>>> try to found a work around.
>>>>>
>>>>> Personalty, i don't want to left MXE solution for the moment.
>>>>>
>>>>> For MacOS, the KDE infrastructure based on Craft compilation framework
>>>>> will be a solution to sing and publish a relocatable package for
>>>>> Apple. digiKam do not compile yet due to  missing dependencies.
>>>>>
>>>>> Voilà, i hope to be enough clear with these technical points.
>>>>>
>>>>> My best
>>>>>
>>>>> Gilles Caulier
Reply | Threaded
Open this post in threaded view
|

Re: Future of digiKam bundles...

Stuart T Rogers
In reply to this post by jdd@dodin.org
I'll try that directory and copy my config into it and the filesystem
override.

Both those worked OK. However I have no access to GIMP or any other
application from within Digikam, another disadvantage and another
complication. All in all seems far to over complicated for a photo
management program.

As for the menu it seems that the flatpak install has overwritten my
menu item for the RPM installed version of digikam, not a good idea in
my view.

Stuart

On 29/05/2020 14:39, [hidden email] wrote:

> Le 29/05/2020 à 14:17, woenx a écrit :
>
>> However, I have one question. I wanted to re-use the configuration
>> file and
>> the color schemes from my appimage digikam. I found that the new
>> digikamrc
>> configuration file is now at ~/.var/app/org.kde.digikam/ (instead of
>> ~/.config/),
>
> thanks, it solved part of my config problem
>
> for the rest, I had to understand that flatpak is a chrooted
> environment, I have to add my disk path with "flatpak override
> --filesystem=XXX"
>
> now it works
>
> :-)
>
> jdd
>
>

--
Website: https://www.stella-maris.org.uk
or:      https//www.broadstairs.org
Reply | Threaded
Open this post in threaded view
|

Re: Future of digiKam bundles...

Peter Teuben
In reply to this post by Gilles Caulier-4
this is great news, certainly for trying out the beta.

I do have a failure mode.  I have 7 albums in my albumRoot, 4 of those
will get flagged by this version and claim not to exist, eg.

digikam.database: Folder does not exist or is not readable:
"/Photos/albums2"
digikam.database: Folder does not exist or is not readable:
"/a7/teuben/Pictures"

the first one is a true symlink, but the 2nd is a real mounted
directory, so it's not that mount/bind issue I've seen with snaps.   If
I use this digikam4.db, the old digikam 6.4.0 acts worse:  it sees the
albums, but sees 0 photos, so starts this hours long process of
reloading the database. No good for me.


I guess I should try the latest appimage as well?


- peter


On 5/29/20 6:29 AM, Gilles Caulier wrote:

> Done !!!
>
> digiKam is now avaialble on FlatHub :
>
> https://flathub.org/apps/details/org.kde.digikam
>
> Best
>
> Gilles Caulier
>
> Le lun. 25 mai 2020 à 17:49, Gilles Caulier <[hidden email]> a écrit :
>> Look like digiKam will be also added to official FlatHub repository soon :
>>
>> https://github.com/flathub/flathub/pull/1544#pullrequestreview-417884061
>>
>> Gilles Caulier
>>
>> Le lun. 25 mai 2020 à 15:09, Gilles Caulier <[hidden email]> a écrit :
>>> Hi,
>>>
>>> Another important point : the Flatpak do not include yet the
>>> application translations files. It's relevant by the missing
>>> sunversion executable on the KDE server.
>>>
>>> And yes, all translations team from KDE project still to use
>>> subversion to host i18n data.
>>>
>>> As whole KDE migrate progressively from an own git/svn servers to
>>> gitlab, i read that i18n will also migrate to git in the near future.
>>> So wait and see...
>>>
>>> Best
>>>
>>> Gilles Caulier
>>>
>>> Le lun. 25 mai 2020 à 12:04, Gilles Caulier <[hidden email]> a écrit :
>>>> Hi,
>>>>
>>>> I just updated the Flatpak notice page on digikam source repository :
>>>>
>>>> https://invent.kde.org/graphics/digikam/-/tree/master/project/bundles/flatpak
>>>>
>>>> digiKam Flatpak is now compiled with ALL non-deprecated options,
>>>> including Web services using KIO. Look like the application resume is
>>>> well documented now, with plenty of screenshots.
>>>>
>>>> By non deprecated, i want mean the 2 ones : Baloo and Akonady
>>>> supports. Both make a mess with digiKam (especially Baloo).
>>>>
>>>> As i read, Flatpak is able to notify users when a new version is
>>>> published. I don't yet verified if it work well.
>>>>
>>>> On Flatpak, it's possible to rate and review the application. So don't
>>>> hesitate to promote the application.
>>>>
>>>> My best
>>>>
>>>> Gilles Caulier
>>>>
>>>>
>>>> Le dim. 24 mai 2020 à 12:24, Gilles Caulier <[hidden email]> a écrit :
>>>>> Hi all users,
>>>>>
>>>>> I would to give some feedback about the digiKam bundles migration advance...
>>>>>
>>>>> The current files provided by the project are listed below :
>>>>>
>>>>> - Linux AppImage 64 bits
>>>>> - Linux AppImage 32 bits
>>>>> - Macos Package installer 64 bits (based on Macports)
>>>>> - Windows installer 64 bits (compiled with MXE - MinGW)
>>>>> - Windows installer 32 bits (compiled with MXE - MinGW)
>>>>>
>>>>> Current problems for these bundles are listed below :
>>>>>
>>>>> - AppImage : not signed, do not support KIO extensions, do not support
>>>>> ICU (language extension), not published on official repository.
>>>>> - MacOS package : It's not relocatable, even if MacOS support well
>>>>> this feature. I don't found the time to finalize yet the install
>>>>> relocation support in bash script. Package is not published on MacOS
>>>>> store.
>>>>> - MXE Windows installer : not signed, not published on Windows store.
>>>>> Do not support KIO extension.
>>>>>
>>>>> But we have a new one starting to work and i working on : FlatPak
>>>>>
>>>>> This one is signed, published of official repository automatically
>>>>> (you can install it on Discover application for ex). It support ICU
>>>>> and KIO too... FlatPak is compiled on KDE infrastructure nightly and
>>>>> automatically. Only a 64 bits version is supported.
>>>>>
>>>>> This want mean that AppImage end of life is near. We will still
>>>>> publish officially the AppImage until 7.0.0, but later, if FlatPak do
>>>>> the job as well, AppImage will be dropped...
>>>>>
>>>>> For Windows, all the digiKam code compile fine under Microsoft Visual
>>>>> C++ compiler. This is the goal to obtain a signed and published
>>>>> version on Microsoft store. You can imagine that Microsoft will only
>>>>> support the official Windows compiler, and not GCC to permit to sign
>>>>> and publish application on the store. Don't forget, Microsoft is well
>>>>> Closed Source (:=))))
>>>>>
>>>>> Microsoft compiler is just the hell. It slow and require a Windows
>>>>> operating system. The current cross compilation solution that we use
>>>>> work fully under Linux, and compilation time are reduced by 4/5 ! A
>>>>> full Linux Workflow is a non virus guaranty !
>>>>>
>>>>> The Visual C++ workflow is also only available on 64 bits and is
>>>>> computed on KDE infrastructure, but the installer compilation is
>>>>> broken due to a weird configuration on KDE infrastructure. I currently
>>>>> try to found a work around.
>>>>>
>>>>> Personalty, i don't want to left MXE solution for the moment.
>>>>>
>>>>> For MacOS, the KDE infrastructure based on Craft compilation framework
>>>>> will be a solution to sing and publish a relocatable package for
>>>>> Apple. digiKam do not compile yet due to  missing dependencies.
>>>>>
>>>>> Voilà, i hope to be enough clear with these technical points.
>>>>>
>>>>> My best
>>>>>
>>>>> Gilles Caulier
Reply | Threaded
Open this post in threaded view
|

Re: Future of digiKam bundles...

Mica Semrick
Install the application "flatseal" from flathub, then grant digikam access to your extra disks/filesystem location.

On May 29, 2020 10:16:37 AM PDT, Peter Teuben <[hidden email]> wrote:
this is great news, certainly for trying out the beta.

I do have a failure mode.  I have 7 albums in my albumRoot, 4 of those
will get flagged by this version and claim not to exist, eg.

digikam.database: Folder does not exist or is not readable:
"/Photos/albums2"
digikam.database: Folder does not exist or is not readable:
"/a7/teuben/Pictures"

the first one is a true symlink, but the 2nd is a real mounted
directory, so it's not that mount/bind issue I've seen with snaps.   If
I use this digikam4.db, the old digikam 6.4.0 acts worse:  it sees the
albums, but sees 0 photos, so starts this hours long process of
reloading the database. No good for me.


I guess I should try the latest appimage as well?


- peter


On 5/29/20 6:29 AM, Gilles Caulier wrote:
Done !!!

digiKam is now avaialble on FlatHub :

https://flathub.org/apps/details/org.kde.digikam

Best

Gilles Caulier

Le lun. 25 mai 2020 à 17:49, Gilles Caulier <[hidden email]> a écrit :
Look like digiKam will be also added to official FlatHub repository soon :

https://github.com/flathub/flathub/pull/1544#pullrequestreview-417884061

Gilles Caulier

Le lun. 25 mai 2020 à 15:09, Gilles Caulier <[hidden email]> a écrit :
Hi,

Another important point : the Flatpak do not include yet the
application translations files. It's relevant by the missing
sunversion executable on the KDE server.

And yes, all translations team from KDE project still to use
subversion to host i18n data.

As whole KDE migrate progressively from an own git/svn servers to
gitlab, i read that i18n will also migrate to git in the near future.
So wait and see...

Best

Gilles Caulier

Le lun. 25 mai 2020 à 12:04, Gilles Caulier <[hidden email]> a écrit :
Hi,

I just updated the Flatpak notice page on digikam source repository :

https://invent.kde.org/graphics/digikam/-/tree/master/project/bundles/flatpak

digiKam Flatpak is now compiled with ALL non-deprecated options,
including Web services using KIO. Look like the application resume is
well documented now, with plenty of screenshots.

By non deprecated, i want mean the 2 ones : Baloo and Akonady
supports. Both make a mess with digiKam (especially Baloo).

As i read, Flatpak is able to notify users when a new version is
published. I don't yet verified if it work well.

On Flatpak, it's possible to rate and review the application. So don't
hesitate to promote the application.

My best

Gilles Caulier


Le dim. 24 mai 2020 à 12:24, Gilles Caulier <[hidden email]> a écrit :
Hi all users,

I would to give some feedback about the digiKam bundles migration advance...

The current files provided by the project are listed below :

- Linux AppImage 64 bits
- Linux AppImage 32 bits
- Macos Package installer 64 bits (based on Macports)
- Windows installer 64 bits (compiled with MXE - MinGW)
- Windows installer 32 bits (compiled with MXE - MinGW)

Current problems for these bundles are listed below :

- AppImage : not signed, do not support KIO extensions, do not support
ICU (language extension), not published on official repository.
- MacOS package : It's not relocatable, even if MacOS support well
this feature. I don't found the time to finalize yet the install
relocation support in bash script. Package is not published on MacOS
store.
- MXE Windows installer : not signed, not published on Windows store.
Do not support KIO extension.

But we have a new one starting to work and i working on : FlatPak

This one is signed, published of official repository automatically
(you can install it on Discover application for ex). It support ICU
and KIO too... FlatPak is compiled on KDE infrastructure nightly and
automatically. Only a 64 bits version is supported.

This want mean that AppImage end of life is near. We will still
publish officially the AppImage until 7.0.0, but later, if FlatPak do
the job as well, AppImage will be dropped...

For Windows, all the digiKam code compile fine under Microsoft Visual
C++ compiler. This is the goal to obtain a signed and published
version on Microsoft store. You can imagine that Microsoft will only
support the official Windows compiler, and not GCC to permit to sign
and publish application on the store. Don't forget, Microsoft is well
Closed Source (:=))))

Microsoft compiler is just the hell. It slow and require a Windows
operating system. The current cross compilation solution that we use
work fully under Linux, and compilation time are reduced by 4/5 ! A
full Linux Workflow is a non virus guaranty !

The Visual C++ workflow is also only available on 64 bits and is
computed on KDE infrastructure, but the installer compilation is
broken due to a weird configuration on KDE infrastructure. I currently
try to found a work around.

Personalty, i don't want to left MXE solution for the moment.

For MacOS, the KDE infrastructure based on Craft compilation framework
will be a solution to sing and publish a relocatable package for
Apple. digiKam do not compile yet due to missing dependencies.

Voilà, i hope to be enough clear with these technical points.

My best

Gilles Caulier
Reply | Threaded
Open this post in threaded view
|

Re: Future of digiKam bundles...

Peter Teuben

thank you Mica,

 although it makes sense,   this didn't seem to solve the problem.   And of the 3 folders that are visible, one of them is already on another partition.



Here's the start of when I run:    flatpak run org.kde.digikam

Note that the directories

'/var/lib/flatpak/exports/share'
'/home/teuben/.local/share/flatpak/exports/share'

are not in the search path set by the XDG_DATA_DIRS environment variable, so
applications installed by Flatpak may not appear on your desktop until the
session is restarted.

QCommandLineParser: already having an option named "h"
QCommandLineParser: already having an option named "help-all"
QCommandLineParser: already having an option named "v"
KMemoryInfo: Platform identified :  "LINUX"
KMemoryInfo: TotalRam:  16680484864


the "flatpak list" command tells me

Name                                              Application ID                                 Version               Branch           Installation
Flatseal                                          com.github.tchx84.Flatseal                     1.5.3                 stable           system
default                                           org.freedesktop.Platform.GL.default                                  19.08            system
Intel                                             org.freedesktop.Platform.VAAPI.Intel                                 19.08            system
openh264                                          org.freedesktop.Platform.openh264                                    2.0              system
Glimpse                                           org.glimpse_editor.Glimpse                     0.1.2                 stable           system
GNOME Application Platform version 3.36           org.gnome.Platform                                                   3.36             system
Breeze Gtk theme                                  org.gtk.Gtk3theme.Breeze                                             3.22             system
KDE Application Platform                          org.kde.Platform                                                     5.14             system
digiKam                                           org.kde.digikam                                7.0.0-beta3           stable           system



On 5/29/20 7:15 PM, Mica Semrick wrote:
Install the application "flatseal" from flathub, then grant digikam access to your extra disks/filesystem location.

On May 29, 2020 10:16:37 AM PDT, Peter Teuben [hidden email] wrote:
this is great news, certainly for trying out the beta.

I do have a failure mode.  I have 7 albums in my albumRoot, 4 of those 
will get flagged by this version and claim not to exist, eg.

digikam.database: Folder does not exist or is not readable: 
"/Photos/albums2"
digikam.database: Folder does not exist or is not readable: 
"/a7/teuben/Pictures"

the first one is a true symlink, but the 2nd is a real mounted 
directory, so it's not that mount/bind issue I've seen with snaps.   If 
I use this digikam4.db, the old digikam 6.4.0 acts worse:  it sees the 
albums, but sees 0 photos, so starts this hours long process of 
reloading the database. No good for me.


I guess I should try the latest appimage as well?


- peter


On 5/29/20 6:29 AM, Gilles Caulier wrote:
Done !!! digiKam is now avaialble on FlatHub : https://flathub.org/apps/details/org.kde.digikam Best Gilles Caulier Le lun. 25 mai 2020 à 17:49, Gilles Caulier [hidden email] a écrit :
Look like digiKam will be also added to official FlatHub repository soon : https://github.com/flathub/flathub/pull/1544#pullrequestreview-417884061 Gilles Caulier Le lun. 25 mai 2020 à 15:09, Gilles Caulier [hidden email] a écrit :
Hi, Another important point : the Flatpak do not include yet the application translations files. It's relevant by the missing sunversion executable on the KDE server. And yes, all translations team from KDE project still to use subversion to host i18n data. As whole KDE migrate progressively from an own git/svn servers to gitlab, i read that i18n will also migrate to git in the near future. So wait and see... Best Gilles Caulier Le lun. 25 mai 2020 à 12:04, Gilles Caulier [hidden email] a écrit :
Hi, I just updated the Flatpak notice page on digikam source repository : https://invent.kde.org/graphics/digikam/-/tree/master/project/bundles/flatpak digiKam Flatpak is now compiled with ALL non-deprecated options, including Web services using KIO. Look like the application resume is well documented now, with plenty of screenshots. By non deprecated, i want mean the 2 ones : Baloo and Akonady supports. Both make a mess with digiKam (especially Baloo). As i read, Flatpak is able to notify users when a new version is published. I don't yet verified if it work well. On Flatpak, it's possible to rate and review the application. So don't hesitate to promote the application. My best Gilles Caulier Le dim. 24 mai 2020 à 12:24, Gilles Caulier [hidden email] a écrit :
Hi all users, I would to give some feedback about the digiKam bundles migration advance... The current files provided by the project are listed below : - Linux AppImage 64 bits - Linux AppImage 32 bits - Macos Package installer 64 bits (based on Macports) - Windows installer 64 bits (compiled with MXE - MinGW) - Windows installer 32 bits (compiled with MXE - MinGW) Current problems for these bundles are listed below : - AppImage : not signed, do not support KIO extensions, do not support ICU (language extension), not published on official repository. - MacOS package : It's not relocatable, even if MacOS support well this feature. I don't found the time to finalize yet the install relocation support in bash script. Package is not published on MacOS store. - MXE Windows installer : not signed, not published on Windows store. Do not support KIO extension. But we have a new one starting to work and i working on : FlatPak This one is signed, published of official repository automatically (you can install it on Discover application for ex). It support ICU and KIO too... FlatPak is compiled on KDE infrastructure nightly and automatically. Only a 64 bits version is supported. This want mean that AppImage end of life is near. We will still publish officially the AppImage until 7.0.0, but later, if FlatPak do the job as well, AppImage will be dropped... For Windows, all the digiKam code compile fine under Microsoft Visual C++ compiler. This is the goal to obtain a signed and published version on Microsoft store. You can imagine that Microsoft will only support the official Windows compiler, and not GCC to permit to sign and publish application on the store. Don't forget, Microsoft is well Closed Source (:=)))) Microsoft compiler is just the hell. It slow and require a Windows operating system. The current cross compilation solution that we use work fully under Linux, and compilation time are reduced by 4/5 ! A full Linux Workflow is a non virus guaranty ! The Visual C++ workflow is also only available on 64 bits and is computed on KDE infrastructure, but the installer compilation is broken due to a weird configuration on KDE infrastructure. I currently try to found a work around. Personalty, i don't want to left MXE solution for the moment. For MacOS, the KDE infrastructure based on Craft compilation framework will be a solution to sing and publish a relocatable package for Apple. digiKam do not compile yet due to missing dependencies. Voilà, i hope to be enough clear with these technical points. My best Gilles Caulier
Reply | Threaded
Open this post in threaded view
|

Re: Future of digiKam bundles...

JayRutherford
I guess I'll wait for some of these issues to subside before trying the Flatpak version. Flatpak, Appimage, or more fundamental assembles, this is a fantastic piece of software for which I'm very thankful to have.

Best to all,

Jay Rutherford


On Fri, May 29, 2020, at 19:39, Peter Teuben wrote:

thank you Mica,

 although it makes sense,   this didn't seem to solve the problem.   And of the 3 folders that are visible, one of them is already on another partition.



Here's the start of when I run:    flatpak run org.kde.digikam

Note that the directories

'/var/lib/flatpak/exports/share'
'/home/teuben/.local/share/flatpak/exports/share'

are not in the search path set by the XDG_DATA_DIRS environment variable, so
applications installed by Flatpak may not appear on your desktop until the
session is restarted.

QCommandLineParser: already having an option named "h"
QCommandLineParser: already having an option named "help-all"
QCommandLineParser: already having an option named "v"
KMemoryInfo: Platform identified :  "LINUX"
KMemoryInfo: TotalRam:  16680484864


the "flatpak list" command tells me

Name                                              Application ID                                 Version               Branch           Installation
Flatseal                                          com.github.tchx84.Flatseal                     1.5.3                 stable           system
default                                           org.freedesktop.Platform.GL.default                                  19.08            system
Intel                                             org.freedesktop.Platform.VAAPI.Intel                                 19.08            system
openh264                                          org.freedesktop.Platform.openh264                                    2.0              system
Glimpse                                           org.glimpse_editor.Glimpse                     0.1.2                 stable           system
GNOME Application Platform version 3.36           org.gnome.Platform                                                   3.36             system
Breeze Gtk theme                                  org.gtk.Gtk3theme.Breeze                                             3.22             system
KDE Application Platform                          org.kde.Platform                                                     5.14             system
digiKam                                           org.kde.digikam                                7.0.0-beta3           stable           system



On 5/29/20 7:15 PM, Mica Semrick wrote:
Install the application "flatseal" from flathub, then grant digikam access to your extra disks/filesystem location.


On May 29, 2020 10:16:37 AM PDT, Peter Teuben [hidden email] wrote:
this is great news, certainly for trying out the beta. I do have a failure mode.  I have 7 albums in my albumRoot, 4 of those will get flagged by this version and claim not to exist, eg. digikam.database: Folder does not exist or is not readable: "/Photos/albums2" digikam.database: Folder does not exist or is not readable: "/a7/teuben/Pictures" the first one is a true symlink, but the 2nd is a real mounted directory, so it's not that mount/bind issue I've seen with snaps.   If I use this digikam4.db, the old digikam 6.4.0 acts worse:  it sees the albums, but sees 0 photos, so starts this hours long process of reloading the database. No good for me. I guess I should try the latest appimage as well? - peter On 5/29/20 6:29 AM, Gilles Caulier wrote:
Done !!! digiKam is now avaialble on FlatHub : https://flathub.org/apps/details/org.kde.digikam Best Gilles Caulier Le lun. 25 mai 2020 à 17:49, Gilles Caulier [hidden email] a écrit :
Look like digiKam will be also added to official FlatHub repository soon : https://github.com/flathub/flathub/pull/1544#pullrequestreview-417884061 Gilles Caulier Le lun. 25 mai 2020 à 15:09, Gilles Caulier [hidden email] a écrit :
Hi, Another important point : the Flatpak do not include yet the application translations files. It's relevant by the missing sunversion executable on the KDE server. And yes, all translations team from KDE project still to use subversion to host i18n data. As whole KDE migrate progressively from an own git/svn servers to gitlab, i read that i18n will also migrate to git in the near future. So wait and see... Best Gilles Caulier Le lun. 25 mai 2020 à 12:04, Gilles Caulier [hidden email] a écrit :
Hi, I just updated the Flatpak notice page on digikam source repository : https://invent.kde.org/graphics/digikam/-/tree/master/project/bundles/flatpak digiKam Flatpak is now compiled with ALL non-deprecated options, including Web services using KIO. Look like the application resume is well documented now, with plenty of screenshots. By non deprecated, i want mean the 2 ones : Baloo and Akonady supports. Both make a mess with digiKam (especially Baloo). As i read, Flatpak is able to notify users when a new version is published. I don't yet verified if it work well. On Flatpak, it's possible to rate and review the application. So don't hesitate to promote the application. My best Gilles Caulier Le dim. 24 mai 2020 à 12:24, Gilles Caulier [hidden email] a écrit :
Hi all users, I would to give some feedback about the digiKam bundles migration advance... The current files provided by the project are listed below : - Linux AppImage 64 bits - Linux AppImage 32 bits - Macos Package installer 64 bits (based on Macports) - Windows installer 64 bits (compiled with MXE - MinGW) - Windows installer 32 bits (compiled with MXE - MinGW) Current problems for these bundles are listed below : - AppImage : not signed, do not support KIO extensions, do not support ICU (language extension), not published on official repository. - MacOS package : It's not relocatable, even if MacOS support well this feature. I don't found the time to finalize yet the install relocation support in bash script. Package is not published on MacOS store. - MXE Windows installer : not signed, not published on Windows store. Do not support KIO extension. But we have a new one starting to work and i working on : FlatPak This one is signed, published of official repository automatically (you can install it on Discover application for ex). It support ICU and KIO too... FlatPak is compiled on KDE infrastructure nightly and automatically. Only a 64 bits version is supported. This want mean that AppImage end of life is near. We will still publish officially the AppImage until 7.0.0, but later, if FlatPak do the job as well, AppImage will be dropped... For Windows, all the digiKam code compile fine under Microsoft Visual C++ compiler. This is the goal to obtain a signed and published version on Microsoft store. You can imagine that Microsoft will only support the official Windows compiler, and not GCC to permit to sign and publish application on the store. Don't forget, Microsoft is well Closed Source (:=)))) Microsoft compiler is just the hell. It slow and require a Windows operating system. The current cross compilation solution that we use work fully under Linux, and compilation time are reduced by 4/5 ! A full Linux Workflow is a non virus guaranty ! The Visual C++ workflow is also only available on 64 bits and is computed on KDE infrastructure, but the installer compilation is broken due to a weird configuration on KDE infrastructure. I currently try to found a work around. Personalty, i don't want to left MXE solution for the moment. For MacOS, the KDE infrastructure based on Craft compilation framework will be a solution to sing and publish a relocatable package for Apple. digiKam do not compile yet due to missing dependencies. Voilà, i hope to be enough clear with these technical points. My best Gilles Caulier

Reply | Threaded
Open this post in threaded view
|

Re: Future of digiKam bundles...

etrigan63
In reply to this post by Mica Semrick
I used flatseal and it works as advertised. Be aware that for symlinks, you need to grant access to the underlying path, not the symlink. To wit: I have a Pictures directory in my home folder. Inside the pictures directory is a symlink to a Photos folder located on another drive /mnt/data/Photos. In order for the flatpak of digikam to be able to access via the symlink, I had to grant it permission to access the /mnt/data/Photos folder, not the symlink /home/user/Pictures/Photos. I entered the symlink in digikam after that and it worked perfectly. You must do the same if you store the database in another folder as well.
Carlos Echenique Photographer, CE Photographic


On Fri, May 29, 2020 at 7:16 PM Mica Semrick <[hidden email]> wrote:
Install the application "flatseal" from flathub, then grant digikam access to your extra disks/filesystem location.

On May 29, 2020 10:16:37 AM PDT, Peter Teuben <[hidden email]> wrote:
this is great news, certainly for trying out the beta.

I do have a failure mode.  I have 7 albums in my albumRoot, 4 of those
will get flagged by this version and claim not to exist, eg.

digikam.database: Folder does not exist or is not readable:
"/Photos/albums2"
digikam.database: Folder does not exist or is not readable:
"/a7/teuben/Pictures"

the first one is a true symlink, but the 2nd is a real mounted
directory, so it's not that mount/bind issue I've seen with snaps.   If
I use this digikam4.db, the old digikam 6.4.0 acts worse:  it sees the
albums, but sees 0 photos, so starts this hours long process of
reloading the database. No good for me.


I guess I should try the latest appimage as well?


- peter


On 5/29/20 6:29 AM, Gilles Caulier wrote:
Done !!!

digiKam is now avaialble on FlatHub :

https://flathub.org/apps/details/org.kde.digikam

Best

Gilles Caulier

Le lun. 25 mai 2020 à 17:49, Gilles Caulier <[hidden email]> a écrit :
Look like digiKam will be also added to official FlatHub repository soon :

https://github.com/flathub/flathub/pull/1544#pullrequestreview-417884061

Gilles Caulier

Le lun. 25 mai 2020 à 15:09, Gilles Caulier <[hidden email]> a écrit :
Hi,

Another important point : the Flatpak do not include yet the
application translations files. It's relevant by the missing
sunversion executable on the KDE server.

And yes, all translations team from KDE project still to use
subversion to host i18n data.

As whole KDE migrate progressively from an own git/svn servers to
gitlab, i read that i18n will also migrate to git in the near future.
So wait and see...

Best

Gilles Caulier

Le lun. 25 mai 2020 à 12:04, Gilles Caulier <[hidden email]> a écrit :
Hi,

I just updated the Flatpak notice page on digikam source repository :

https://invent.kde.org/graphics/digikam/-/tree/master/project/bundles/flatpak

digiKam Flatpak is now compiled with ALL non-deprecated options,
including Web services using KIO. Look like the application resume is
well documented now, with plenty of screenshots.

By non deprecated, i want mean the 2 ones : Baloo and Akonady
supports. Both make a mess with digiKam (especially Baloo).

As i read, Flatpak is able to notify users when a new version is
published. I don't yet verified if it work well.

On Flatpak, it's possible to rate and review the application. So don't
hesitate to promote the application.

My best

Gilles Caulier


Le dim. 24 mai 2020 à 12:24, Gilles Caulier <[hidden email]> a écrit :
Hi all users,

I would to give some feedback about the digiKam bundles migration advance...

The current files provided by the project are listed below :

- Linux AppImage 64 bits
- Linux AppImage 32 bits
- Macos Package installer 64 bits (based on Macports)
- Windows installer 64 bits (compiled with MXE - MinGW)
- Windows installer 32 bits (compiled with MXE - MinGW)

Current problems for these bundles are listed below :

- AppImage : not signed, do not support KIO extensions, do not support
ICU (language extension), not published on official repository.
- MacOS package : It's not relocatable, even if MacOS support well
this feature. I don't found the time to finalize yet the install
relocation support in bash script. Package is not published on MacOS
store.
- MXE Windows installer : not signed, not published on Windows store.
Do not support KIO extension.

But we have a new one starting to work and i working on : FlatPak

This one is signed, published of official repository automatically
(you can install it on Discover application for ex). It support ICU
and KIO too... FlatPak is compiled on KDE infrastructure nightly and
automatically. Only a 64 bits version is supported.

This want mean that AppImage end of life is near. We will still
publish officially the AppImage until 7.0.0, but later, if FlatPak do
the job as well, AppImage will be dropped...

For Windows, all the digiKam code compile fine under Microsoft Visual
C++ compiler. This is the goal to obtain a signed and published
version on Microsoft store. You can imagine that Microsoft will only
support the official Windows compiler, and not GCC to permit to sign
and publish application on the store. Don't forget, Microsoft is well
Closed Source (:=))))

Microsoft compiler is just the hell. It slow and require a Windows
operating system. The current cross compilation solution that we use
work fully under Linux, and compilation time are reduced by 4/5 ! A
full Linux Workflow is a non virus guaranty !

The Visual C++ workflow is also only available on 64 bits and is
computed on KDE infrastructure, but the installer compilation is
broken due to a weird configuration on KDE infrastructure. I currently
try to found a work around.

Personalty, i don't want to left MXE solution for the moment.

For MacOS, the KDE infrastructure based on Craft compilation framework
will be a solution to sing and publish a relocatable package for
Apple. digiKam do not compile yet due to missing dependencies.

Voilà, i hope to be enough clear with these technical points.

My best

Gilles Caulier
Reply | Threaded
Open this post in threaded view
|

Re: Future of digiKam bundles...

Peter Teuben

I never "appreciated" these issues about both flatpak and snap.   AFAIK appimage doesn't have this. But it really turns me off about this.  

Basically I need to give access to all mount points.  I also heard somewhere you can use mount with the bind option, because this micro-managing my life (e.g. popping in an external drive) is driving one nuts.   This is not the posix file system my grandfather was using, to make up a quote.   I can manage adding a bind option to the /etc/fstab file, but what about my /media links.....

thanks for clarifications, i never expected this mess.


peter



On 5/29/20 8:01 PM, Carlos Echenique wrote:
I used flatseal and it works as advertised. Be aware that for symlinks, you need to grant access to the underlying path, not the symlink. To wit: I have a Pictures directory in my home folder. Inside the pictures directory is a symlink to a Photos folder located on another drive /mnt/data/Photos. In order for the flatpak of digikam to be able to access via the symlink, I had to grant it permission to access the /mnt/data/Photos folder, not the symlink /home/user/Pictures/Photos. I entered the symlink in digikam after that and it worked perfectly. You must do the same if you store the database in another folder as well.
Carlos Echenique Photographer, CE Photographic



On Fri, May 29, 2020 at 7:16 PM Mica Semrick <[hidden email]> wrote:
Install the application "flatseal" from flathub, then grant digikam access to your extra disks/filesystem location.

On May 29, 2020 10:16:37 AM PDT, Peter Teuben <[hidden email]> wrote:
this is great news, certainly for trying out the beta.

I do have a failure mode.  I have 7 albums in my albumRoot, 4 of those 
will get flagged by this version and claim not to exist, eg.

digikam.database: Folder does not exist or is not readable: 
"/Photos/albums2"
digikam.database: Folder does not exist or is not readable: 
"/a7/teuben/Pictures"

the first one is a true symlink, but the 2nd is a real mounted 
directory, so it's not that mount/bind issue I've seen with snaps.   If 
I use this digikam4.db, the old digikam 6.4.0 acts worse:  it sees the 
albums, but sees 0 photos, so starts this hours long process of 
reloading the database. No good for me.


I guess I should try the latest appimage as well?


- peter


On 5/29/20 6:29 AM, Gilles Caulier wrote:
Done !!! digiKam is now avaialble on FlatHub : https://flathub.org/apps/details/org.kde.digikam Best Gilles Caulier Le lun. 25 mai 2020 à 17:49, Gilles Caulier <[hidden email]> a écrit :
Look like digiKam will be also added to official FlatHub repository soon : https://github.com/flathub/flathub/pull/1544#pullrequestreview-417884061 Gilles Caulier Le lun. 25 mai 2020 à 15:09, Gilles Caulier <[hidden email]> a écrit :
Hi, Another important point : the Flatpak do not include yet the application translations files. It's relevant by the missing sunversion executable on the KDE server. And yes, all translations team from KDE project still to use subversion to host i18n data. As whole KDE migrate progressively from an own git/svn servers to gitlab, i read that i18n will also migrate to git in the near future. So wait and see... Best Gilles Caulier Le lun. 25 mai 2020 à 12:04, Gilles Caulier <[hidden email]> a écrit :
Hi, I just updated the Flatpak notice page on digikam source repository : https://invent.kde.org/graphics/digikam/-/tree/master/project/bundles/flatpak digiKam Flatpak is now compiled with ALL non-deprecated options, including Web services using KIO. Look like the application resume is well documented now, with plenty of screenshots. By non deprecated, i want mean the 2 ones : Baloo and Akonady supports. Both make a mess with digiKam (especially Baloo). As i read, Flatpak is able to notify users when a new version is published. I don't yet verified if it work well. On Flatpak, it's possible to rate and review the application. So don't hesitate to promote the application. My best Gilles Caulier Le dim. 24 mai 2020 à 12:24, Gilles Caulier <[hidden email]> a écrit :
Hi all users, I would to give some feedback about the digiKam bundles migration advance... The current files provided by the project are listed below : - Linux AppImage 64 bits - Linux AppImage 32 bits - Macos Package installer 64 bits (based on Macports) - Windows installer 64 bits (compiled with MXE - MinGW) - Windows installer 32 bits (compiled with MXE - MinGW) Current problems for these bundles are listed below : - AppImage : not signed, do not support KIO extensions, do not support ICU (language extension), not published on official repository. - MacOS package : It's not relocatable, even if MacOS support well this feature. I don't found the time to finalize yet the install relocation support in bash script. Package is not published on MacOS store. - MXE Windows installer : not signed, not published on Windows store. Do not support KIO extension. But we have a new one starting to work and i working on : FlatPak This one is signed, published of official repository automatically (you can install it on Discover application for ex). It support ICU and KIO too... FlatPak is compiled on KDE infrastructure nightly and automatically. Only a 64 bits version is supported. This want mean that AppImage end of life is near. We will still publish officially the AppImage until 7.0.0, but later, if FlatPak do the job as well, AppImage will be dropped... For Windows, all the digiKam code compile fine under Microsoft Visual C++ compiler. This is the goal to obtain a signed and published version on Microsoft store. You can imagine that Microsoft will only support the official Windows compiler, and not GCC to permit to sign and publish application on the store. Don't forget, Microsoft is well Closed Source (:=)))) Microsoft compiler is just the hell. It slow and require a Windows operating system. The current cross compilation solution that we use work fully under Linux, and compilation time are reduced by 4/5 ! A full Linux Workflow is a non virus guaranty ! The Visual C++ workflow is also only available on 64 bits and is computed on KDE infrastructure, but the installer compilation is broken due to a weird configuration on KDE infrastructure. I currently try to found a work around. Personalty, i don't want to left MXE solution for the moment. For MacOS, the KDE infrastructure based on Craft compilation framework will be a solution to sing and publish a relocatable package for Apple. digiKam do not compile yet due to missing dependencies. Voilà, i hope to be enough clear with these technical points. My best Gilles Caulier
Reply | Threaded
Open this post in threaded view
|

Re: Future of digiKam bundles...

etrigan63
/media is there by default. If you regularly mount drives under /mnt just add that. You only have to do it once.
Carlos Echenique Photographer, CE Photographic


On Fri, May 29, 2020 at 8:24 PM Peter Teuben <[hidden email]> wrote:

I never "appreciated" these issues about both flatpak and snap.   AFAIK appimage doesn't have this. But it really turns me off about this.  

Basically I need to give access to all mount points.  I also heard somewhere you can use mount with the bind option, because this micro-managing my life (e.g. popping in an external drive) is driving one nuts.   This is not the posix file system my grandfather was using, to make up a quote.   I can manage adding a bind option to the /etc/fstab file, but what about my /media links.....

thanks for clarifications, i never expected this mess.


peter



On 5/29/20 8:01 PM, Carlos Echenique wrote:
I used flatseal and it works as advertised. Be aware that for symlinks, you need to grant access to the underlying path, not the symlink. To wit: I have a Pictures directory in my home folder. Inside the pictures directory is a symlink to a Photos folder located on another drive /mnt/data/Photos. In order for the flatpak of digikam to be able to access via the symlink, I had to grant it permission to access the /mnt/data/Photos folder, not the symlink /home/user/Pictures/Photos. I entered the symlink in digikam after that and it worked perfectly. You must do the same if you store the database in another folder as well.
Carlos Echenique Photographer, CE Photographic



On Fri, May 29, 2020 at 7:16 PM Mica Semrick <[hidden email]> wrote:
Install the application "flatseal" from flathub, then grant digikam access to your extra disks/filesystem location.

On May 29, 2020 10:16:37 AM PDT, Peter Teuben <[hidden email]> wrote:
this is great news, certainly for trying out the beta.

I do have a failure mode.  I have 7 albums in my albumRoot, 4 of those 
will get flagged by this version and claim not to exist, eg.

digikam.database: Folder does not exist or is not readable: 
"/Photos/albums2"
digikam.database: Folder does not exist or is not readable: 
"/a7/teuben/Pictures"

the first one is a true symlink, but the 2nd is a real mounted 
directory, so it's not that mount/bind issue I've seen with snaps.   If 
I use this digikam4.db, the old digikam 6.4.0 acts worse:  it sees the 
albums, but sees 0 photos, so starts this hours long process of 
reloading the database. No good for me.


I guess I should try the latest appimage as well?


- peter


On 5/29/20 6:29 AM, Gilles Caulier wrote:
Done !!! digiKam is now avaialble on FlatHub : https://flathub.org/apps/details/org.kde.digikam Best Gilles Caulier Le lun. 25 mai 2020 à 17:49, Gilles Caulier <[hidden email]> a écrit :
Look like digiKam will be also added to official FlatHub repository soon : https://github.com/flathub/flathub/pull/1544#pullrequestreview-417884061 Gilles Caulier Le lun. 25 mai 2020 à 15:09, Gilles Caulier <[hidden email]> a écrit :
Hi, Another important point : the Flatpak do not include yet the application translations files. It's relevant by the missing sunversion executable on the KDE server. And yes, all translations team from KDE project still to use subversion to host i18n data. As whole KDE migrate progressively from an own git/svn servers to gitlab, i read that i18n will also migrate to git in the near future. So wait and see... Best Gilles Caulier Le lun. 25 mai 2020 à 12:04, Gilles Caulier <[hidden email]> a écrit :
Hi, I just updated the Flatpak notice page on digikam source repository : https://invent.kde.org/graphics/digikam/-/tree/master/project/bundles/flatpak digiKam Flatpak is now compiled with ALL non-deprecated options, including Web services using KIO. Look like the application resume is well documented now, with plenty of screenshots. By non deprecated, i want mean the 2 ones : Baloo and Akonady supports. Both make a mess with digiKam (especially Baloo). As i read, Flatpak is able to notify users when a new version is published. I don't yet verified if it work well. On Flatpak, it's possible to rate and review the application. So don't hesitate to promote the application. My best Gilles Caulier Le dim. 24 mai 2020 à 12:24, Gilles Caulier <[hidden email]> a écrit :
Hi all users, I would to give some feedback about the digiKam bundles migration advance... The current files provided by the project are listed below : - Linux AppImage 64 bits - Linux AppImage 32 bits - Macos Package installer 64 bits (based on Macports) - Windows installer 64 bits (compiled with MXE - MinGW) - Windows installer 32 bits (compiled with MXE - MinGW) Current problems for these bundles are listed below : - AppImage : not signed, do not support KIO extensions, do not support ICU (language extension), not published on official repository. - MacOS package : It's not relocatable, even if MacOS support well this feature. I don't found the time to finalize yet the install relocation support in bash script. Package is not published on MacOS store. - MXE Windows installer : not signed, not published on Windows store. Do not support KIO extension. But we have a new one starting to work and i working on : FlatPak This one is signed, published of official repository automatically (you can install it on Discover application for ex). It support ICU and KIO too... FlatPak is compiled on KDE infrastructure nightly and automatically. Only a 64 bits version is supported. This want mean that AppImage end of life is near. We will still publish officially the AppImage until 7.0.0, but later, if FlatPak do the job as well, AppImage will be dropped... For Windows, all the digiKam code compile fine under Microsoft Visual C++ compiler. This is the goal to obtain a signed and published version on Microsoft store. You can imagine that Microsoft will only support the official Windows compiler, and not GCC to permit to sign and publish application on the store. Don't forget, Microsoft is well Closed Source (:=)))) Microsoft compiler is just the hell. It slow and require a Windows operating system. The current cross compilation solution that we use work fully under Linux, and compilation time are reduced by 4/5 ! A full Linux Workflow is a non virus guaranty ! The Visual C++ workflow is also only available on 64 bits and is computed on KDE infrastructure, but the installer compilation is broken due to a weird configuration on KDE infrastructure. I currently try to found a work around. Personalty, i don't want to left MXE solution for the moment. For MacOS, the KDE infrastructure based on Craft compilation framework will be a solution to sing and publish a relocatable package for Apple. digiKam do not compile yet due to missing dependencies. Voilà, i hope to be enough clear with these technical points. My best Gilles Caulier
12345