Plasma 5.2 bits for kdereview

[Ian Wadham]

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
>