[KDE/Mac] Question about goal of Windows/Mac frameworks

[Jeremy Whiting]

Christoph.

I have had similar goals for a while, but haven't reached the point
that I was having much success yet in that regard. One thing to keep
in mind when developing installers, Qt Installer Framework. I did a
quick test with attica on OS X I can put on reviewboard to see what
you think. I added a few lines to CMakeLists.txt to make it so you can
do make package, and it uses CPack and Qt Installer Framework to
create an installer application which can be used to download both
attica and attica-devel packages for OSX. I bet we could put together
a "meta" package for at least KF5 and maybe more which would consist
of a CMakeLists.txt and a bunch of git clones beneath it could be used
to create one OSX or Windows installer that could then be used to
download applications and all their dependencies. I wasn't sure how to
add dependency information to the result of CPack's QIFW generator,
but it should be doable.

The result of all of that would be one tool for OS X and a similar one
for Windows that work exactly like the Qt online installers. Qt's
online installers are meant for developers though, not end users, so
we may need to improve QIF itself to make the resulting installer more
user friendly, we'll see. I meant to blog about all of this a week or
so ago, but haven't gotten around to it. What do you think of the idea
in general though?

thanks,
Jeremy

On Tue, Oct 20, 2015 at 12:04 PM, Christoph Cullmann
<cullmann at absint.com> wrote:
> Hi,
>
>> Hi,
>> With my Android hat on I very much welcome the initiative. Android is
>> more limited in this regard, as you will mostly always want to have
>> split packages there and it's how we've been working since the
>> beginning.
>>
>> I think that for us Qt is a safe base in general. relying on other 3rd
>> parties makes things a bit more complex. (e.g. dbus or gstreamer) It's
>> always arguable that it is possible to run, but then it can be a
>> burden. While on Linux it's preferable to leverage on the system
>> infrastructure, we can't expect these to be available elsewhere.
>>
>> I can agree to the 3 goals you mentioned, but they feel fuzzy:
>> 1) Fully agreed
> 1) Stock Qt
>
>> 2) What's Global stuff? This could be phrased as: "Frameworks should
>> only require resources that can be located with QStandardPaths and can
>> be distributed in bundles."
> Badly phrased, yes, I think 2) is more like:
>
> 2) Can be self-contained shipped in an application bundle (self-installer/mac app bundle).
>
>> 3) non-existing stuff? really? Let's rephrase it as: "Frameworks will
>> only be advertised as available on a platform if they are just require
>> Qt or other available dependencies on the platform". For example,
>> requiring libssh could be an acceptable dependency.
>>
>> Regarding dbus especifically, I see the problem in 2). You can bundle
>> it, but then if it's already ran by another process the other one will
>> have to be used, which is where the dbus mess starts.
> Yeah, 3) is perhaps more like:
>
> 3) Frameworks shall require only libraries shipped with the target operating system
> per default (which is quiet well defined on Win/Mac, but not that well defined on Linux).
>
> That additional stuff might be useful/recommended is clear, IMHO, like you can have
> nice git integration if you have libgit2 for KTextEditor, but it works without.
>
> Greetings
> Christoph
>
> --
> ----------------------------- Dr.-Ing. Christoph Cullmann ---------
> AbsInt Angewandte Informatik GmbH      Email: cullmann at AbsInt.com
> Science Park 1                         Tel:   +49-681-38360-22
> 66123 Saarbrücken                      Fax:   +49-681-38360-20
> GERMANY                                WWW:   http://www.AbsInt.com
> --------------------------------------------------------------------
> Geschäftsführung: Dr.-Ing. Christian Ferdinand
> Eingetragen im Handelsregister des Amtsgerichts Saarbrücken, HRB 11234
> _______________________________________________
> Kde-frameworks-devel mailing list
> Kde-frameworks-devel at kde.org
> https://mail.kde.org/mailman/listinfo/kde-frameworks-devel