Plasma 5.2 bits for kdereview

[Lamarque Souza]

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 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
> 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 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 <
> 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
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20150108/150299ac/attachment.htm>