Plasma 5.2 bits for kdereview
lamarque at kde.org
Thu Jan 8 09:33:58 GMT 2015
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
On Thu, Jan 8, 2015 at 4:39 AM, Ian Wadham <iandw.au at 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
> 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
> 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
> - Dr Konqi is required by every KDE app on every platform, but its
> code has currently (temporarily I am told) been placed in a Plasma5
> 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 at tiscali.it
> >> <mailto:luigi.toscano at 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 <
> >> That's the same point as baloo, discussed on kde-frameworks-devel
> >> 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
> >> Plasma currently.
> > But they could be in the future, they are general libraries and other
> > or applications could look at them.
> >> libkscreen and libmm-qt are already being released with Plasma so this
> >> makes projects.kde.org <http://projects.kde.org> match reality.
> >> Albert has said he's fine with KDE Applications depending on Plasma (I
> >> What problem does it create to release it with Plasma even if something
> >> wants to use them?
> > My thoughts:
> > - logical issue: Plasma is a product (even if a bit special) at the same
> > of other applications when looking at the general picture and having
> > libraries (not desktop-specific libraries or components like polkit-qt,
> > 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
> > 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",
> > attica or phonon. Why not libmm-qt, which I suspect is pure Qt? On the
> > 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
> > choice IMHO, because that name (kdelibs) has a special and defined
> > (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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the kde-core-devel