Question about goal of Windows/Mac frameworks

[Kevin Ottens]

Hello,

On Wednesday 21 October 2015 09:26:35 Christoph Cullmann wrote:
> Hi,
> 
> > Hello,
> > 
> > On Wednesday 21 October 2015 08:13:42 Christoph Cullmann wrote:
> >> > On Tuesday 20 October 2015 19:49:54 Aleix Pol wrote:
> >> >> 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.
> >> > 
> >> > Isn't it a rephrased definition of Tier 1?
> >> > 
> >> > Tier 1 frameworks are supposed to depend only on Qt and platform
> >> > libraries.
> >> 
> >> Yeah, wrong again :/
> >> Including other frameworks, I meant.
> >> 
> >> But beside that, perhaps 3) is not even needed given 2) says "Can be
> >> self-contained shipped in an application bundle (self-installer/mac app
> >> bundle)." That more or less implies you only have "reasonable"
> >> dependencies that can be bundled, too.
> > 
> > I'm not sure that's helping. What is "reasonable"? :-)
> 
> ;=) 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.

> But lets look at some concrete example, the dependencies for KWrite/Kate (at
> the moment, without optional stuff):
> 
> build_framework extra-cmake-modules
> build_framework kconfig
> build_framework kguiaddons
> build_framework ki18n
> build_framework kitemviews
> build_framework sonnet
> build_framework kwindowsystem
> build_framework kwidgetsaddons
> build_framework kcompletion
> build_framework kdbusaddons
> build_framework karchive
> build_framework kcoreaddons
> build_framework kjobwidgets
> build_framework kcrash
> build_framework kservice
> build_framework kcodecs
> build_framework kauth
> build_framework kconfigwidgets
> build_framework kiconthemes
> build_framework ktextwidgets
> build_framework kglobalaccel
> build_framework kxmlgui
> build_framework kbookmarks
> build_framework solid
> build_framework kio
> build_framework kparts
> build_framework ktexteditor
> 
> Even with all these frameworks (even very high tier ones), ATM, all stuff is
> self-contained bundleable inside the final KWrite/Kate bundle/installer
> (even with some reasonable size, between 20-30 MB of target zip file).
> 
> Only some stuff has "feature regressions", like kglobalaccel (no global
> daemon support as requires dbus), kio (no wallet and other stuff as
> requires dbus, ATM no working slaves as .protocol files not found without
> Qt hacks to standardpaths).
> 
> All other stuff is now more or less just deployable by having the
> .dll/.so/.dylib in the bundle, given I put all stuff in .qrc files there (I
> just missed some small pics/files in some frameworks ATM, need to fix that
> ;=) Even kxmlgui ;=)
> 
> 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.

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.

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

Regards.

[*] http://ervin.ipsquad.net/slides/talks/fisl2014-kde-frameworks/#/13
-- 
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/0cc79dae/attachment.sig>