Plasma 5.2 bits for kdereview

[Jonathan Riddell]

On Thu, Jan 08, 2015 at 07:33:58AM -0200, Lamarque Souza wrote:
>    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.

It's doubtful if they'll ever be ready for Frameworks which has strict
quality requirements.  Setting up yet another place to put them just
means yet another person has to work out the release management bits
and the distros need to package them separately.  I don't see any
problem it solves and I do see extra work by not just making them
officially part of Plasma.

Jonathan


> 
>    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.A  Some KF5 modules may
>      not be appropriate on other desktops, may clash with modules on other
>      desktops or may add to the facilities there.A  And some things are
>      definitely
>      not specific to Plasma.A  Some examples:
> 
>      A  A - Several of the modules based on kded already have their
>      equivalents
>      A  A  A  on other desktops (e.g. power management).A  Others, such as
>      A  A  A  kbuildsycoca are needed to run KDE apps.A  It is hard to know
>      A  A  A  exactly which modules belong in each category on Apple OS X.
>      A  A - I don't think Windows has anything like Baloo or KWallet, but
>      Apple
>      A  A  A  OS X certainly has, and has had for years.A  We, on the KDE-Mac
>      list,
>      A  A  A  are starting to integrate KWallet and Apple's Keychain app, but
>      Baloo
>      A  A  A  is still an unknown quantity, esp. re how hard-wired it is into
>      KDE apps.
>      A  A - Dr Konqi is required by every KDE app on every platform, but its
>      source
>      A  A  A  code has currently (temporarily I am told) been placed in a
>      Plasma5
>      A  A  A  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:
>      >>
>      >>A  A  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>
>      >>>
>      >>
>      >>A  A  That's the same point as baloo, discussed on
>      kde-frameworks-devel right
>      >>A  A  now, then.
>      >>
>      >>A  A  I still disagree, from a logical point of view those libraries
>      could be needed
>      >>A  A  both for Applications and Plasma "products". As you said they
>      are not
>      >>A  A  frameworks, and I still think we need to investigate how to
>      place this kind of
>      >>A  A  libraries. If you don't want to depend on libraries on
>      extragear-libs, maybe a
>      >>A  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
>      >