Question about goal of Windows/Mac frameworks

[Kevin Ottens]

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.

> > 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? :-)

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

Regards.
-- 
Kévin Ottens, http://ervin.ipsquad.net

KDAB - proud supporter of KDE, http://www.kdab.com

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20151021/5bf0e091/attachment.sig>