Question about goal of Windows/Mac frameworks

[Christoph Cullmann]

Hi,

> Hello,
> 
> On Wednesday 21 October 2015 09:26:35 Christoph Cullmann wrote:
>> Hi,

<snip>

>> ;=) Yeah, fluffy, e.g. I would call dbus "non-reasonable", as it requires
>> some daemon to be running, even if we would have per application install
>> daemons. I would call stuff reasonable that is available if you add some
>> dynlib to your application bundle.
> 
> So yeah, confirms to me the hypothesis I was having of: runtime deps.
> 
>> > I suspect it has something to do with runtime dependencies? If not, what
>> > is unreasonable in kxmlgui dependencies? (as it seems to be the main
>> > culprit)
>> 
>> kxmlgui was just an example to show that there is potential to reduce the
>> dependencies. e.g. you have kglobalaccel, which is not that useful on
>> Windows/Mac, given you have there normally no dbus to have it working.
>> The same for kauth, which you only need because of KCM inside
>> kconfigwidgets, which close to zero applications will use that require
>> kxmlgui.
> 
> Again, very much tied to runtime dependencies.
> 
>> > If it is linked to runtime dependencies, I think you ought to not only
>> > look at the Tier but also the Type. Only frameworks of the "functional"
>> > type have no such dependencies.
>> 
>> Perhaps.
> 
> At that point it looks *very* likely it's about the runtime dependencies and
> so that's the Type of the framework which conveys that.

Yes, that's true, that is more or less all about runtime deps.

> 
>> But lets look at some concrete example, the dependencies for KWrite/Kate (at
>> the moment, without optional stuff):
>> 

<snip>

>> I would like to fix the remaining regressions, e.g. have the io slaves
>> working without Qt hacks and have some generic way to bundle e.g. the
>> Breeze icon set in the bundle without having to take care in the
>> application about too much stuff.
> 
> Right, that's another point where we need some effort: tooling to help create
> this kind of bundles.

Yeah, ATM I think that is even not that much work.

With my latest 

https://quickgit.kde.org/?p=kate.git&a=blob&f=mac.txt

I can have a self contained KWrite or Kate on Mac with all stuff working beside
KIO slaves + any DBus related things. That should work for any other "simple"
KDE application just the same.

Neither to frameworks or kate/kwrite any patches or compile time switches are needed,
you just need a patched macdeployqt, but the patch should go upstream, I hope:

https://bugreports.qt.io/browse/QTBUG-48836

For Windows, that is even "easier" as you can just copy together the .dll's there without
complex otool hacking ;)

To automate this to e.g. let the CI spill out .dmg files should be easy.

Still, a lot of fine tuning is needed. ATM the deployment will just move all plugins inside,
leading to stuff like WebKit in my .dmg file which is not needed. And one needs to solve
the KIO stuff, without resorting to patch Qt.

> 
> Anyway, to get back to the thing which prompted my involvement in that thread.
> No, we're not pretending stuff is available easily on every platform. We even
> put in place mechanisms to communicate how painful it is for a third party to
> embark something: Tiers and Types. This discussion also confirms to me that
> people generally somewhat know about the tier, but not the type.
> 
> For bundling, the closer you are to the bottom right corner[*] the easier, the
> further away of that corner the more problems you should expect.
> 
> And then, three areas of efforts which we are missing right now in Frameworks:
> - systematically try to reduce the tier and type of our frameworks (the
> maturity direction I was talking about);
> - for the frameworks of type "integration" more systematically make sure they
> work on other platforms than Linux (e.g. wouldn't it be nice if kglobalaccel
> would work without D-Bus on Windows using platform facilities?);
> - create tooling to help people to create Windows or Mac bundles for their
> applications.
+1 for that

> 
> To me, if the community manages to tackle those three challenges, it will be a
> higher path forward than playing with build time knobs which might lead to
> feature loss or API changes (which I already mentioned I consider as a lesser
> path).
Still, the first thing to have is to make it easy for people to actually
compile the stuff and improve it on non-linux machines.
And for that, perhaps, some more low level buildsystem knobs might be needed in the short term.
But perhaps nothing is needed, lets see.

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