[prev in list] [next in list] [prev in thread] [next in thread]
List: kde-core-devel
Subject: Re: Plasma 5.2 bits for kdereview
From: Lamarque Souza <lamarque () kde ! org>
Date: 2015-01-08 9:33:58
Message-ID: CABc+Zu5H55jWd5Th0X45XXLmaLQBNny_DG=bKXPY1OyfA4uAxw () mail ! gmail ! com
[Download RAW message or body]
Hi all,
Regarding ModemManagerQt, libbluedevil, libkscreen and baloo, they are
supposed to be frameworks stuff (not sure about baloo) but they are not
ready yet. Why not created a frameworks-next group to include them there
until they are ready to move to frameworks (being it KF5 or even KF6 in the
future)? The Linux kernel has such a thing and it seems to work for them.
Lamarque V. Souza
KDE's Network Management maintainer
http://planetkde.org/pt-br
On Thu, Jan 8, 2015 at 4:39 AM, Ian Wadham <iandw.au@gmail.com> wrote:
> Hi guys,
>
> This discussion is about technology unfamiliar to me, so please excuse
> me if I top-post and speak off topic.
>
> All I want to say is please be aware of other platforms in your
> discussions.
> I refer to Windows, Apple OS X and Linux/Unix desktops other than Plasma.
>
> Those desktops may not be a good fit for background processes that are
> needed to support KDE apps on any given desktop. Some KF5 modules may
> not be appropriate on other desktops, may clash with modules on other
> desktops or may add to the facilities there. And some things are
> definitely
> not specific to Plasma. Some examples:
>
> - Several of the modules based on kded already have their equivalents
> on other desktops (e.g. power management). Others, such as
> kbuildsycoca are needed to run KDE apps. It is hard to know
> exactly which modules belong in each category on Apple OS X.
> - I don't think Windows has anything like Baloo or KWallet, but Apple
> OS X certainly has, and has had for years. We, on the KDE-Mac list,
> are starting to integrate KWallet and Apple's Keychain app, but Baloo
> is still an unknown quantity, esp. re how hard-wired it is into KDE
> apps.
> - Dr Konqi is required by every KDE app on every platform, but its
> source
> code has currently (temporarily I am told) been placed in a Plasma5
> repository.
>
> Thanks in advance for listening,
> Cheers, Ian W.
>
> On 08/01/2015, at 10:20 AM, Luigi Toscano wrote:
> > Jonathan Riddell ha scritto:
> >> On 6 January 2015 at 15:23, Luigi Toscano <luigi.toscano@tiscali.it
> >> <mailto:luigi.toscano@tiscali.it>> wrote:
> >>
> >> Jonathan Riddell ha scritto:
> >>> Updates on this..
> >>>
> >>> I plan to ask for Bluedevil and libbluedevil, libkscreen and kscreen,
> >>> libmm-qt and ksshaskpass to be moved. I see some comments that the
> >>> libraries may be used outside of Plasma but there's no problem with
> >>> that happening, they don't quality for frameworks and they already get
> >>> released with Plasma so it's just an update in projects.kde.org <
> http://projects.kde.org>
> >>>
> >>
> >> That's the same point as baloo, discussed on kde-frameworks-devel
> right
> >> now, then.
> >>
> >> I still disagree, from a logical point of view those libraries could
> be needed
> >> both for Applications and Plasma "products". As you said they are not
> >> frameworks, and I still think we need to investigate how to place
> this kind of
> >> libraries. If you don't want to depend on libraries on
> extragear-libs, maybe a
> >> new module? Again, it's the same as the baloo placement problem IMHO.
> >>
> >>
> >> Neither libkscreen nor libbluedevil not libmm-qt are used by anything
> outside
> >> Plasma currently.
> > But they could be in the future, they are general libraries and other
> desktops
> > or applications could look at them.
> >
> >>
> >> libkscreen and libmm-qt are already being released with Plasma so this
> just
> >> makes projects.kde.org <http://projects.kde.org> match reality.
> >>
> >> Albert has said he's fine with KDE Applications depending on Plasma (I
> think)
> >>
> http://mail.kde.org/pipermail/kde-frameworks-devel/2015-January/021332.html
> >>
> >> What problem does it create to release it with Plasma even if something
> else
> >> wants to use them?
> >
> > My thoughts:
> > - logical issue: Plasma is a product (even if a bit special) at the same
> level
> > of other applications when looking at the general picture and having
> general
> > libraries (not desktop-specific libraries or components like polkit-qt,
> etc)
> > there just does not seem the right placement. A shared place for
> libraries is
> > then needed; see below.
> > - communication problems. We are trying to detach the different pieces
> of work
> > produced by the KDE community and having software dependending on "the
> > desktop" is going in the opposite way IMHO
> >>
> >> Where would you put them and how would you get them released?
> >
> > As I wrote, we miss something in the layer of "libraries based on
> Frameworks
> > which are not Frameworks but used by other programs", and we are a bit
> > incoherent. On one side we have some pure Qt libraries as "kdesupport",
> see
> > attica or phonon. Why not libmm-qt, which I suspect is pure Qt? On the
> other
> > side, kdesupport is not suited for libraries
> > Extragear-libs still means "stuff which have its own regular release
> > schedule", so I would go with that, unless people think that
> Applications and
> > Plasma can't depend on extragear-libs libraries, but then I would say
> that we
> > need another group. For now Baloo, which is a similar status, decided to
> go on
> > its own route, and it's in a special namespace which is not exactly the
> best
> > choice IMHO, because that name (kdelibs) has a special and defined
> meaning.
> >
> > (having this thread called "plasma something" probably means that some
> > non-plasma-but-core people are not checking it and this does not help.
> Or not?
> > Please speak up!).
> >
> > Ciao
> > --
> > Luigi
> >
>
>
[Attachment #3 (text/html)]
<div dir="ltr"><div>Hi all,<br><br></div>Regarding ModemManagerQt, libbluedevil, \
libkscreen and baloo, they are supposed to be frameworks stuff (not sure about baloo) \
but they are not ready yet. Why not created a frameworks-next group to include them \
there until they are ready to move to frameworks (being it KF5 or even KF6 in the \
future)? The Linux kernel has such a thing and it seems to work for \
them.<br></div><div class="gmail_extra"><br clear="all"><div><div \
class="gmail_signature"><div dir="ltr"> <p style="margin:0px">Lamarque V. Souza</p>
<p style="margin:0px">KDE's Network Management maintainer</p>
<p style="margin:0px"><a href="http://planetkde.org/pt-br" \
target="_blank">http://planetkde.org/pt-br</a></p></div></div></div> <br><div \
class="gmail_quote">On Thu, Jan 8, 2015 at 4:39 AM, Ian Wadham <span dir="ltr"><<a \
href="mailto:iandw.au@gmail.com" target="_blank">iandw.au@gmail.com</a>></span> \
wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px \
#ccc solid;padding-left:1ex">Hi guys,<br> <br>
This discussion is about technology unfamiliar to me, so please excuse<br>
me if I top-post and speak off topic.<br>
<br>
All I want to say is please be aware of other platforms in your discussions.<br>
I refer to Windows, Apple OS X and Linux/Unix desktops other than Plasma.<br>
<br>
Those desktops may not be a good fit for background processes that are<br>
needed to support KDE apps on any given desktop. Some KF5 modules may<br>
not be appropriate on other desktops, may clash with modules on other<br>
desktops or may add to the facilities there. And some things are definitely<br>
not specific to Plasma. Some examples:<br>
<br>
- Several of the modules based on kded already have their equivalents<br>
on other desktops (e.g. power management). Others, such as<br>
kbuildsycoca are needed to run KDE apps. It is hard to know<br>
exactly which modules belong in each category on Apple OS X.<br>
- I don't think Windows has anything like Baloo or KWallet, but Apple<br>
OS X certainly has, and has had for years. We, on the KDE-Mac list,<br>
are starting to integrate KWallet and Apple's Keychain app, but \
Baloo<br>
is still an unknown quantity, esp. re how hard-wired it is into KDE \
apps.<br>
- Dr Konqi is required by every KDE app on every platform, but its source<br>
code has currently (temporarily I am told) been placed in a Plasma5<br>
repository.<br>
<br>
Thanks in advance for listening,<br>
Cheers, Ian W.<br>
<div class="HOEnZb"><div class="h5"><br>
On 08/01/2015, at 10:20 AM, Luigi Toscano wrote:<br>
> Jonathan Riddell ha scritto:<br>
>> On 6 January 2015 at 15:23, Luigi Toscano <<a \
href="mailto:luigi.toscano@tiscali.it">luigi.toscano@tiscali.it</a><br> >> \
<mailto:<a href="mailto:luigi.toscano@tiscali.it">luigi.toscano@tiscali.it</a>>> \
wrote:<br> >><br>
>> Jonathan Riddell ha scritto:<br>
>>> Updates on this..<br>
>>><br>
>>> I plan to ask for Bluedevil and libbluedevil, libkscreen and \
kscreen,<br> >>> libmm-qt and ksshaskpass to be moved. I see some comments \
that the<br> >>> libraries may be used outside of Plasma but there's no \
problem with<br> >>> that happening, they don't quality for frameworks \
and they already get<br> >>> released with Plasma so it's just an update \
in <a href="http://projects.kde.org" target="_blank">projects.kde.org</a> <<a \
href="http://projects.kde.org" target="_blank">http://projects.kde.org</a>><br> \
>>><br> >><br>
>> That's the same point as baloo, discussed on kde-frameworks-devel \
right<br> >> now, then.<br>
>><br>
>> I still disagree, from a logical point of view those libraries could be \
needed<br> >> both for Applications and Plasma "products". As \
you said they are not<br> >> frameworks, and I still think we need to \
investigate how to place this kind of<br> >> libraries. If you don't \
want to depend on libraries on extragear-libs, maybe a<br> >> new module? \
Again, it's the same as the baloo placement problem IMHO.<br> >><br>
>><br>
>> Neither libkscreen nor libbluedevil not libmm-qt are used by anything \
outside<br> >> Plasma currently.<br>
> But they could be in the future, they are general libraries and other \
desktops<br> > or applications could look at them.<br>
><br>
>><br>
>> libkscreen and libmm-qt are already being released with Plasma so this \
just<br> >> makes <a href="http://projects.kde.org" \
target="_blank">projects.kde.org</a> <<a href="http://projects.kde.org" \
target="_blank">http://projects.kde.org</a>> match reality.<br> >><br>
>> Albert has said he's fine with KDE Applications depending on Plasma (I \
think)<br> >> <a \
href="http://mail.kde.org/pipermail/kde-frameworks-devel/2015-January/021332.html" \
target="_blank">http://mail.kde.org/pipermail/kde-frameworks-devel/2015-January/021332.html</a><br>
>><br>
>> What problem does it create to release it with Plasma even if something \
else<br> >> wants to use them?<br>
><br>
> My thoughts:<br>
> - logical issue: Plasma is a product (even if a bit special) at the same \
level<br> > of other applications when looking at the general picture and having \
general<br> > libraries (not desktop-specific libraries or components like \
polkit-qt, etc)<br> > there just does not seem the right placement. A shared place \
for libraries is<br> > then needed; see below.<br>
> - communication problems. We are trying to detach the different pieces of \
work<br> > produced by the KDE community and having software dependending on \
"the<br> > desktop" is going in the opposite way IMHO<br>
>><br>
>> Where would you put them and how would you get them released?<br>
><br>
> As I wrote, we miss something in the layer of "libraries based on \
Frameworks<br> > which are not Frameworks but used by other programs", and we \
are a bit<br> > incoherent. On one side we have some pure Qt libraries as \
"kdesupport", see<br> > attica or phonon. Why not libmm-qt, which I \
suspect is pure Qt? On the other<br> > side, kdesupport is not suited for \
libraries<br> > Extragear-libs still means "stuff which have its own regular \
release<br> > schedule", so I would go with that, unless people think that \
Applications and<br> > Plasma can't depend on extragear-libs libraries, but \
then I would say that we<br> > need another group. For now Baloo, which is a \
similar status, decided to go on<br> > its own route, and it's in a special \
namespace which is not exactly the best<br> > choice IMHO, because that name \
(kdelibs) has a special and defined meaning.<br> ><br>
> (having this thread called "plasma something" probably means that \
some<br> > non-plasma-but-core people are not checking it and this does not help. \
Or not?<br> > Please speak up!).<br>
><br>
> Ciao<br>
> --<br>
> Luigi<br>
><br>
<br>
</div></div></blockquote></div><br></div>
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic