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: cullm...@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 _______________________________________________ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel