Question about goal of Windows/Mac frameworks

[Christoph Cullmann]

Hi,

> Hello,
> 
> On Wednesday 21 October 2015 21:06:02 Christoph Cullmann wrote:
>> >> > 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.
>> 
>> [...]
>> >> 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.
> 
> Good news then. :-)
> 
>> 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.
> 
> Yes, but still, thanks to your moves we're not that far off it seems. That's
> good.
Yeah, but I think I only fixed the "simple" thingies.
The heavy things are still around, like KIO :=)

> 
>> > 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
> 
> Of course the problem is as usual, who will step up and do it? :-)
I am willing to spend more time fixing issues I see for KWrite/Kate, as time permits,
which will produce more fixes for many frameworks I guess, as Kate uses a lot of them.
(fortunately or unfortunately :=))

> 
>> > 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.
> 
> My concern there is more the fact that this kind of "short term" or
> "temporary" solutions tend to become permanent. As long as it is causing pain
> you can hope someone will look at it and try to fix it... and indeed, see what
> you achieved! ;-)
> But if you put in place something short term lifting the immediate pain,
> people will learn to live with it and it'll stay. I hope we'll avoid that.
At the moment my biggest concern is, that we stay in the status quo:

Frameworks as in our git master branch are more or less "not usable" on non linux/xdg conform systems
(beside pure functional tier1 or so) and all people that do use them on other systems
hack happy away using patches for Qt/frameworks/applications floating around
on github/macports/mingw/.... or just fork and shrink the frameworks locally.

Given we want to broaden our scope away from the "pure Linux/X11(Wayland) Desktop" country,
that makes me a bit sad. But I see progress in the right direction and interest by
people to help out.

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