Question about goal of Windows/Mac frameworks

[Kevin Ottens]

Hello,

On Friday 23 October 2015 16:35:36 Luigi Toscano wrote:
> On Wednesday 21 of October 2015 20:09:33 Kevin Ottens wrote:
> > 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);
> 
> Do you mean that a Framework is mature only if it's tier1?

No, I might have been unclear indeed. The point I'm trying to make is that it 
gives a *direction* toward a framework improvement. A framework is mature when 
it reached it's optimum place which is generally closer to the bottom right 
(in the matrix I posted the last time) than from where it started.

That kind of thinking and investigation per framework takes time and as such 
we tend to not do it. For sure we didn't do it systematically, and I think 
ideally that would be needed.

> Is KIO non mature (and it won't probably ever be)?

Difficult to answer without digging deeper into its current state since I 
didn't look into it for a while now, but I would say it's close to be but not 
yet.
I'm saying this mostly because I assume KIO could become Tier 2, could hardly 
be something else than of type Solution though, and it's not there yet. If my 
assumption is wrong then it's already at the right place, end of story.

> I see some functions being so complex that in order to lower the tier for a
> framework one of the two should happen:
> 1) remove functionalities

Yes, there's remove and remove though. :-)

We always assumed everything is used by everyone or required by everyone, 
might not be true and so could be removed (it's the most difficult to find).
It could be some convenience API that allows our applications to spare two 
lines of code... is it really worth it to carry extra dependencies and 
complexity in the frameworks for that? Perhaps not.
It could be some automated behavior which makes sense only if the application 
links to a combination of frameworks but not if the application links to a 
single framework. In such case probably one of the soft dependencies tricks we 
used in the past could apply. It's a Schrodinger features. :-) 

It's all removal to some extent, but it's far from black and white.

> 2) put code in Qt.

Or in a framework of a lower tier. For instance something which is Tier 3 and 
which could be improved to become Tier 2 might require some code be put in a 
Tier 1 framework.

> Even 2) would be quite hard, and I wonder what would happen if all the
> relevant code would end up in Qt

Well, we'd have put quite some work into it then. :-)

It's doable, we did it in the past, there's probably more we could do, but it 
clearly requires getting out of our comfort zone. Can't have it all I guess. 
:-)

> (yeah, almost "kdelibs merged into Qt"! and maybe someone on some
> forum/known website would start screaming about a bloated Qt without
> thinking about the situation, but I'm digressing).

We don't need to get even close to a kdelibs merged into Qt. Quite a lot of 
things wouldn't apply to something like Qt. But clearly we have some internal 
or lower level mechanisms used at plenty of places, those would make sense in 
Qt.

> My take: it is simply not possible (not before maybe Qt 7) to reduce the
> level of some frameworks, without them being "immature".

For the record, this kind of thinking is not really to my taste because it 
opens the door to build up excuses for our own behavior: "oh well, it's not 
possible, why bother anyway..."

For sure, we have way more opportunities to improve ourselves and our 
frameworks first before even starting to perceive limits really out of our 
control.

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/20151024/cdc123d2/attachment.sig>