Re: Fwd: Plasma 5.2 bits for kdereview
ModemManagerQt is used by two KDE Applications, Plasma NM and KDE Telepathy. The former uses it to retrieve information about mobile broadband connections (operator and signal quality), unlocking modem's sim card when activating 3G connections, listing available modems in mobile connection wizard when creating 3G connections and, with NetworkManager 0.9.10, Plasma NM also uses MMQt to setup a bluetooth connections (which is process initiated by Bluedevil, so it is a feature indirectly used by Bluedevil too). The later uses MMQt to read/send SMS using a cell phone. Lamarque V. Souza KDE's Network Management maintainer http://planetkde.org/pt-br On Thu, Jan 8, 2015 at 1:04 PM, Sebastian Kügler se...@kde.org wrote: On Wednesday, January 07, 2015 20:31:57 Albert Astals Cid wrote: 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.htm l I said I'm fine with KDE Applications depending on Plasma to improve workpsace integration or something like that. BUT libkscreen and libmm-qt don't seem workpsace-integration-improvement-libs to me but basic libs to access system stuff. libkscreen is mainly for reading and settings X configuration. That's quite workspace-specific. For use-cases typical for apps, there's way easier API (QScreen, for example). libmm-qt ... I dunno, why would an app use it? (I can construct a weird use- case, but in the end, information about modem setup is a system / workspace- specific feature, not something typically done in apps. There are no hard boundaries, much depends on interpretation, but given it's debatable, I think keeping these things together in kde/workspace makes sense. Cheers, -- sebas http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9
Fwd: Plasma 5.2 bits for kdereview
On 6 January 2015 at 15:23, Luigi Toscano 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 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. libkscreen and libmm-qt are already being released with Plasma so this just makes 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? Where would you put them and how would you get them released? Jonathan
Re: Fwd: Plasma 5.2 bits for kdereview
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
Re: Fwd: Plasma 5.2 bits for kdereview
El Dimecres, 7 de gener de 2015, a les 11:57:57, Jonathan Riddell va escriure: On 6 January 2015 at 15:23, Luigi Toscano 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 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. libkscreen and libmm-qt are already being released with Plasma so this just makes 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 I said I'm fine with KDE Applications depending on Plasma to improve workpsace integration or something like that. BUT libkscreen and libmm-qt don't seem workpsace-integration-improvement-libs to me but basic libs to access system stuff. Besides that's my opinion ;) Cheers, Albert What problem does it create to release it with Plasma even if something else wants to use them? Where would you put them and how would you get them released? Jonathan
Fwd: Plasma 5.2 bits for kdereview
On Thu, Jan 1, 2015 at 4:56 PM, Albert Astals Cid aa...@kde.org wrote: El Dimarts, 23 de desembre de 2014, a les 13:17:46, Daniel Vrátil va escriure: On Friday, December 19, 2014 06:46:11 PM Luigi Toscano wrote: Jonathan Riddell ha scritto: Plasma 5.2 is due out next month and there's a few KDE projects which would be good to be included. Please review these for inclusion in kde/workspace.. kscreen and libkscreen maintained by Dan Vrátil. libkscreen is already released with Plasma but isn't in kde/workspace. https://projects.kde.org/projects/extragear/libs/libkscreen https://projects.kde.org/projects/extragear/base/kscreen I disagree with moving libkscreen to kde/workspace. It is a dependency for at least one application (Okular), which has no Framework version for now but it will have it. It would make more sense to have libkscreen in Frameworks, like libnm* AFAIK Okular is using KScreen only to get DPI info, which was not provided by QScreen in Qt 4. In Qt 5 you already have DPI API in QScreen, so you should not need KScreen anymore. It is provided by QX11Info in Qt4, it's just wrong, does QScreen provide it correctly like kscreen does? Theoretically, yes it's correct. QScreen now reports DPI per monitor, not per each X screen which was the QX11Info problem. It's still subject to monitors reporting the wrong DPI, but so is kscreen. The API is a bit questionable. You'll might be told you're on QScreen 0, but will tell you have global co-ordinates that don't actually fit on that screen. You have to look up the correct QScreen, don't trust whatever QWindow will tell you. David Cheers, Albert Dan
Re: Fwd: Plasma 5.2 bits for kdereview
On Donnerstag, 1. Januar 2015 22:01:11 CEST, David Edmundson wrote: You'll might be told you're on QScreen 0, but will tell you have global co-ordinates that don't actually fit on that screen. You have to look up the correct QScreen, don't trust whatever QWindow will tell you. Even after habing acquired a native window handle, resp. having the window mapped and managed? (The WM will usually position it, move it to the current screen etc.) Cheers, Thomas