On Tue, Apr 8, 2014 at 7:52 AM, Kevin Ottens <er...@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@kde.org > https://mail.kde.org/mailman/listinfo/kde-frameworks-devel > > Aleix
_______________________________________________ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
