KIO progress towards tier 1 framework?
Mark
markg85 at gmail.com
Tue Jul 2 19:35:13 UTC 2013
** ahh, so we're continuing in this message after all instead of "KIO
progress towards tier 1 framework? (resend)". **
On Tue, Jul 2, 2013 at 2:06 PM, David Faure <faure at kde.org> wrote:
> Le mardi 2 juillet 2013 13:49:01 Mark a écrit :
>> Hi,
>>
>> When i'm looking in the kdelibs splitting document [1] i only see KIO
>> pop up twice. One to get kbookmarks out of KIO (which is work in
>> progress). Another one with "kio-core" as work in progress.
>
> Right.
>
>> But i can't find any documentation anywhere that gives me a clear view
>> as to how far KIO is on it's way to a tier 1 framework.
>
> Well, as long as there's stuff in kio/kio, we're not done :)
> The goal is very simply to move all this into kiocore and kiowidgets,
> step by step (bottom up).
Awesome!
>
> The current status is that I'm making a delegate factory so that kio jobs
> don't instanciate their own delegates directly (which kills core/gui
> separation). After that we should be able to move much more stuff to kiocore
> (like the actual jobs, and the scheduler).
Do you have any schedule? As in the items to do for kio, the progress
who is doing what, the grand KIO plan? Is there a wiki page with this
just like the frameworks splitting page?
>
>> I'm asking this because i'm getting more and more interested in KIO. I
>> want to get it running on windows, linux and mac as tier 1 framework.
>> Or more specifically, a Qt module.
>
> A tier1 framework is pretty much a "Qt module" from a technical point of view.
> It just doesn't come from qt-project.org
>
> KIO can't be tier1 though: kio core depends on kcoreaddons (for KJob), on
> KConfig and on ki18n.
> (and on kservice for some strange default-user-agent feature, maybe we can
> change that)
which tier is KJob going to be anyway? It's not listed in the
frameworks splitting document.
>
> That makes it tier2 if we can remove the kservice dependency.
> I think tier2 is not too bad, though.
>
>> Starting from August 1st, I'll be
>> trying to get that done so i'm really keen on knowing how far KIO is
>> at this moment in reaching that goal and what needs to be done.
>
> If you want to try compiling staging/kio on all platforms, please do, I'm
> interested in the feedback.
> The buildsystem should be ready for it, so the point is to detect unportable
> constructs in the code.
Well, for linux it compiles just fine. I tried that a few days ago
(last sunday). The thing i got complaints about is undefined reference
to QSaveFile in the libkio library (not kiocore). But i have yet to
look into that in more detail. And yes, that is with Qt 5.2 dev
branch. Other then that, i will try to give you feedback when building
kiocore on mac. I wonder how far that will go considering the
>
>> I don't know it's current state, but my interest is there (has been
>> there for a few years now) and if more people are interested then i'd
>> even like to propose a small KIO Sprint somewhere in August and
>> somewhere in Europe.
>
> A KIO sprint would be small, by definition, I would think :)
> One of the main KIO developers apart from me is Dawit, but he's quite far
> IIRC, I doubt he would be able to come. So if it's just you and me... we can
> chat on IRC or here :)
That will probably do, for now :)
>
> --
> David Faure, faure at kde.org, http://www.davidfaure.fr
> Working on KDE, in particular KDE Frameworks 5
>
> _______________________________________________
> Kde-frameworks-devel mailing list
> Kde-frameworks-devel at kde.org
> https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
More information about the Kde-frameworks-devel
mailing list