Question about goal of Windows/Mac frameworks

[Aleix Pol]

On Tue, Oct 20, 2015 at 4:49 PM, Christoph Cullmann <cullmann at absint.com> wrote:
> Hi,
>
> after some patching, we got around to a state that allows to e.g. use KWrite
> on Windows or Mac with stock frameworks master and stock Qt 5.5, without any additional
> patches and no stuff like dbus running. (as standalone installer/bundles)
>
> To have KIO working, one needs to teach it how to find the .protocol files, like
> ATM done by some patches to Qt by the Windows folks (or we avoid that by embedding that
> info in the slaves in the plugin meta data), for icons you need to set the icon lookup
> path + theme hardcoded.
>
> My question: What is the actual goal for frameworks on non-linux like (or non-xdg conform)
> or whatever called operating systems?
>
> My personal current goal is to have them in at state that allows:
>
> 1) use stock Qt as base
> 2) have frameworks in a state that allows them to be used in application standalone installer/app-bundle without global stuff required
> 3) avoid the use of non-existing stuff like the dbus session bus
>
> For the "make it easy to bundle" I patched some frameworks to support stuff inside qt resources.
> (xmlgui for ui files, kconfig for global default config files)
>
> That works only, if the applications bundle their ui files in resources, too, otherwise, they just won't be found
> and the applications break, unless you patch again Qt to look in non-standard locations.
>
> For the "non-dbus" I made some stuff bit more "failure safe", if no bus is around, on cost of features.
> (like for kio, no instant segfault anymore, just no working dbus related stuff)
>
> Here the applications need a bit care, too, like not exit, if they can't register on the bus.
>
> Is that just my personal goal or is that what we want to have as frameworks goal on such operating systems?
> Would that make the stuff more usable for Krita for example?
>
> Greetings
> Christoph

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
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."
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.

Aleix