[digiKam-users] appimage

[Mica Semrick]

If you put all your appimages in one folder, like ~/Applications, you can either add that to your path, or you can create .desktop files for each application. That will get them recognized by most launchers.

Some appimages check for their own .desktop file and make one for you if it doesn't exist. This is how the gimp appimages works.

-m

On August 18, 2018 11:33:34 AM PDT, Jono pollard <jono.pollard at gmail.com> wrote:
>All I can say is that at least flatpack easily integrates into the rest
>of
>the system. Appimage is more like windows or mac where you can just run
>a
>program from where ever. Which can obviously be convenient but it's a
>nightmare when literally every other program is well integrated into
>the
>system. You guys do whatever you like, I'm just letting you know as a
>user
>what the experience is like. And it ain't ideal. I think sometimes devs
>forget that regular people are going to be using the stuff they spend
>so
>much time and effort on. Thought I'd offer a little feedback. Like I
>said
>previously, I am a big fan of the software in general and appreciate
>what
>you guys do.
>
>Jono
>
>On Sat, Aug 18, 2018 at 10:13 AM, Gilles Caulier
><caulier.gilles at gmail.com>
>wrote:
>
>> Flat pack vs AppImage : this is a good question
>>
>> 2 years ago I was contacted by the AppImage Lead developer to propose
>a
>> digikam bundle
>>
>> I this tile I was already take a look to the bundles for Linux.
>Flatpack
>> was not really documented and AppImage very well. With the help of
>> AppImage, the Rita team which already provide an AppImage bundle I
>created
>> a first version in 3 weeks with the minimum features. Since this time
>I
>> create a lots of bash scripts to create the bundles with a good
>> documentation. This include also windows with a cross compilation
>through
>> mixe, and macOS using Mac ports.
>>
>> Flatpack is more mature now and more secure from the start to send
>box the
>> application better than AppImage.
>> AppImage has now the same concept, so there is no more advantage to
>use
>> flatpack.
>>
>> So I will not investigate to create a flatpack version of DK. If
>someone
>> want to do it, no problem, but I maintain the AppImage and my time is
>> limited
>>
>> Other important point : keep provide a bundle factory including
>AppImage,
>> windows installer and Mac package
>> This use step by step the craft framework. This can be fine for small
>> applications, but for digikam we need something we’ll customized.
>>
>> https://binary-factory.kde.org/
>>
>> Perhaps, in the future, we will use this service, but for the moment,
>the
>> do scripts do the job well since a very long time, where craft
>framework
>> still under development ( I receive the mails from the team)
>>
>> Voilà for this story. Packaging is complex job and take a while, but
>a
>> complex application badly packaged cannot work properly and finally,
>users
>> will report the application as completely bugous.
>>
>> Gilles caulier
>>
>>
>> Le sam. 18 août 2018 à 17:22, <digikam at 911networks.com> a écrit :
>>
>>> On Sat, 18 Aug 2018 14:35:12 +0200
>>> Gilles Caulier <caulier.gilles at gmail.com> wrote:
>>>
>>> > So to resume :
>>> >
>>> > 1/ I support AppImage
>>> > 2/ I will continuous to support AppImage in the future.
>>> > 3/ If you don't like AppImage, ask to your packagers to update and
>>> > support digiKam application natively in your system, because we
>>> > (digiKam team) don't it instead.
>>>
>>> I like the principle of appimage. It allows me to use DK. Currently,
>>> I'm on xfce. It makes my life simple.
>>>
>>> Question to Gilles:
>>>
>>> appimage vs flatpak.
>>>
>>> More and more are using flatpak to include everything. My son, in
>>> academia/bioinfomatics requires that people send their software in
>>> "flatpaks" which is becoming quite well accepted in academia.
>>>
>>> BTW, Isn't GIMP also using flatpak with Redhat supporting the
>project?
>>>
>>> --
>>> sknahT
>>>
>>> vyS
>>>
>> --
>> Send with Gmail Mobile
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/digikam-users/attachments/20180818/afa85029/attachment.html>