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...@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.tosc...@tiscali.it > >> <mailto:luigi.tosc...@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 > > > >