[prev in list] [next in list] [prev in thread] [next in thread]
List: kde-frameworks-devel
Subject: Re: Status of the KDE Runtime module splitting
From: Aleix Pol <aleixpol () kde ! org>
Date: 2014-04-08 10:07:44
Message-ID: CACcA1Rpuz0xEkHsynWuyk-=CRBfn5b-=3r0RyrzqT6HX1jY-2w () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
On Tue, Apr 8, 2014 at 7:52 AM, Kevin Ottens <ervin@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 agre=
ed
> > 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=C3=A9vin 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
[Attachment #5 (text/html)]
<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Tue, Apr 8, 2014 \
at 7:52 AM, Kevin Ottens <span dir="ltr"><<a href="mailto:ervin@kde.org" \
target="_blank">ervin@kde.org</a>></span> wrote:<br><blockquote \
class="gmail_quote" style="margin:0px 0px 0px \
0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
Hello,<br>
<div class=""><br>
On Monday 07 April 2014 18:57:25 Aleix Pol wrote:<br>
> We started the discussion of splitting some time where we somewhat agreed<br>
> on a splitting plan [1]. I've been working during the last week on it, \
and<br> > decided I'd send an e-mail with some update on the status. Most \
things that<br> > haven't been done yet, are because I don't really know \
what to do with<br> > them, especially because I could really use some feedback \
from the<br> > respective KF5 maintainers.<br>
<br>
</div>I thought you got feedback on some of those, but let's repeat.<br>
<div class=""><br>
> - DrKonqi: Is a huge dependency for KCrash but then a major feature there.<br>
<br>
</div>"Or we keep drkonqi out and have it provided by the workspace. If not<br>
available then kcrash could provide a default very basic one. Sounds like<br>
something for 5.1 though."<br>
<br>
What I meant there, is drkonqi goes with the workspace today. And we'll make<br>
kcrash properly portable (and usable outside of our workspace) after \
5.0.<br></blockquote><div><br></div><div>Ok, to Plasma Workspace it goes, somebody \
will care about it at some point.</div><div> </div><blockquote class="gmail_quote" \
style="margin:0px 0px 0px \
0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div class=""><br>
> - KGlobalAccelD: Again, huge dependency for the KGlobalAccel daemon but<br>
> also a must to have it working.<br>
<br>
</div>Ben's words, I merely sent a +1:<br>
"If this is such a problem, then kglobalaccel (the framework) should<br>
gain backends for Windows, Mac, Other DE, etc. integration and<br>
kglobalacceld is merely the implementation used in a Plasma workspace."<br>
<br>
So kglobalacceld goes with the workspace. And just like KCrash we'll make it<br>
more portable after 5.0.<br>
I also wrote:<br>
"As a matter of fact we should probably make KXmlGui be able to treat<br>
KGlobalAccel as optional if the daemon isn't available at runtime."<br>
<br>
If possible that would be nice to have that done before 5.0 though.<br>
<div class=""><br></div></blockquote><div><br></div><div>Ok, to Plasma Workspace it \
goes, somebody will care about it at some point.<br></div><div><br></div><div> \
</div><blockquote class="gmail_quote" style="margin:0px 0px 0px \
0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div class="">
> - l10n, localization: it was decided in this mailing list it would go to<br>
> kde4support when some development happens. Otherwise it should go to<br>
> KUnitConversion because it's only used there. besides KDE4Support.<br>
<br>
</div>No opinion, no idea, not sure I see the problem in fact. :-)<br>
<div class=""><br>
> - solid-networkstatus: Alex is doing this one, it's pending on this \
review<br> > [2].<br>
> - attica-kde, kurifilter-plugins, KWindowsAddons, solid-deviceautomounter:<br>
> I need to request the directory, but they need to go into a separate<br>
> directory and that's it.<br>
<br>
</div>Apart from KWindowsAddons I'm not sure I see the point of separate<br>
repositories for everything.<br></blockquote><div><br></div><div>Well, I hardly see \
features that extend KIO such as kurifilter-plugins as something even related to the \
workspace.</div><div><br></div><div>I can see it having application outside the \
workspaces, that is on windows or Android applications.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px \
0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div class=""><br>
> - kioslaves, kioslaves-extra: I'm waiting to get the respositories, the<br>
> sysadmin team seems to have some concerns. Discussing it at the moment<br>
> (when the time zones let us).<br>
<br>
</div>I agree there's one repository too many. But that's clearly workspace \
stuff to<br> me.<br></blockquote><div><br></div><div>Fair enough. We can merge \
kioslaves and kioslaves-extra, I would say.</div><div> </div><blockquote \
class="gmail_quote" style="margin:0px 0px 0px \
0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div class=""><br>
> - doc: I plan to do it after the rest is sorted out.<br>
<br>
</div>What kind of feedback are you expecting here?<br>
<br>
Cheers.<br>
<span class=""><font color="#888888">--<br>
Kévin Ottens, <a href="http://ervin.ipsquad.net" \
target="_blank">http://ervin.ipsquad.net</a><br> <br>
KDAB - proud supporter of KDE, <a href="http://www.kdab.com" \
target="_blank">http://www.kdab.com</a><br> <br>
</font></span><br>_______________________________________________<br>
Kde-frameworks-devel mailing list<br>
<a href="mailto:Kde-frameworks-devel@kde.org">Kde-frameworks-devel@kde.org</a><br>
<a href="https://mail.kde.org/mailman/listinfo/kde-frameworks-devel" \
target="_blank">https://mail.kde.org/mailman/listinfo/kde-frameworks-devel</a><br> \
<br></blockquote></div><br></div><div class="gmail_extra">Aleix</div></div>
_______________________________________________
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic