Status of the KDE Runtime module splitting

[Aleix Pol]

On Tue, Apr 8, 2014 at 7:52 AM, Kevin Ottens <ervin at kde.org> wrote:

> Hello,
>
> On Monday 07 April 2014 18:57:25 Aleix Pol wrote:
> > We started the discussion of splitting some time where we somewhat agreed
> > on a splitting plan [1]. I've been working during the last week on it,
> and
> > decided I'd send an e-mail with some update on the status. Most things
> that
> > haven't been done yet, are because I don't really know what to do with
> > them, especially because I could really use some feedback from the
> > respective KF5 maintainers.
>
> I thought you got feedback on some of those, but let's repeat.
>
> > - DrKonqi: Is a huge dependency for KCrash but then a major feature
> there.
>
> "Or we keep drkonqi out and have it provided by the workspace. If not
> available then kcrash could provide a default very basic one. Sounds like
> something for 5.1 though."
>
> What I meant there, is drkonqi goes with the workspace today. And we'll
> make
> kcrash properly portable (and usable outside of our workspace) after 5.0.
>

Ok, to Plasma Workspace it goes, somebody will care about it at some point.


>
> > - KGlobalAccelD: Again, huge dependency for the KGlobalAccel daemon but
> > also a must to have it working.
>
> Ben's words, I merely sent a +1:
> "If this is such a problem, then kglobalaccel (the framework) should
> gain backends for Windows, Mac, Other DE, etc. integration and
> kglobalacceld is merely the implementation used in a Plasma workspace."
>
> So kglobalacceld goes with the workspace. And just like KCrash we'll make
> it
> more portable after 5.0.
> I also wrote:
> "As a matter of fact we should probably make KXmlGui be able to treat
> KGlobalAccel as optional if the daemon isn't available at runtime."
>
> If possible that would be nice to have that done before 5.0 though.
>
>
Ok, to Plasma Workspace it goes, somebody will care about it at some point.



>  > - l10n, localization: it was decided in this mailing list it would go to
> > kde4support when some development happens. Otherwise it should go to
> > KUnitConversion because it's only used there. besides KDE4Support.
>
> No opinion, no idea, not sure I see the problem in fact. :-)
>
> > - solid-networkstatus: Alex is doing this one, it's pending on this
> review
> > [2].
> > - attica-kde, kurifilter-plugins, KWindowsAddons,
> solid-deviceautomounter:
> > I need to request the directory, but they need to go into a separate
> > directory and that's it.
>
> Apart from KWindowsAddons I'm not sure I see the point of separate
> repositories for everything.
>

Well, I hardly see features that extend KIO such as kurifilter-plugins as
something even related to the workspace.

I can see it having application outside the workspaces, that is on windows
or Android applications.


>
> > - kioslaves, kioslaves-extra: I'm waiting to get the respositories, the
> > sysadmin team seems to have some concerns. Discussing it at the moment
> > (when the time zones let us).
>
> I agree there's one repository too many. But that's clearly workspace
> stuff to
> me.
>

Fair enough. We can merge kioslaves and kioslaves-extra, I would say.


>
> > - doc: I plan to do it after the rest is sorted out.
>
> What kind of feedback are you expecting here?
>
> Cheers.
> --
> Kévin Ottens, http://ervin.ipsquad.net
>
> KDAB - proud supporter of KDE, http://www.kdab.com
>
>
> _______________________________________________
> Kde-frameworks-devel mailing list
> Kde-frameworks-devel at kde.org
> https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
>
>
Aleix
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20140408/eb36e258/attachment-0001.html>