Re: Solid/PowerManagement deprecation

[Martin Graesslin]

On Wednesday, February 10, 2016 3:55:51 PM CET Aleix Pol wrote:
> Hi,
> I've been looking in the last days what applications and uses make our
> software stick to KDELibs4Support.
> 
> My impression is that the big missing thing is Solid/PowerManagement.
> 
> Is anyone looking into the issue?

I replaced the usage in kscreenlocker (suspend/hibernate) with new written 
code which does nice async dbus. From the start I considered that this code 
could become the base for a new lib, so it has the right licence, etc. Commit 
is at:

http://commits.kde.org/kscreenlocker/a04768901ac13985dd673bbb45f2bf98d9a52903

But overall I don't know what is really needed from a PowerManagement API.

> Should we look into un-deprecating it?

given the very sync-dbus state of the API, I would not recommend to.

Cheers
Martin

signature.asc
Description: This is a digitally signed message part.
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Review Request 127031: Add function to get runtime frameworks version information

[Aleix Pol Gonzalez]

> On Feb. 10, 2016, 11:14 p.m., Albert Astals Cid wrote:
> > src/lib/kcoreaddons.h, line 29
> > 
> >
> > Documntation is missing
> > 
> > Also "technically" one could mix and max versions even if we don't do 
> > it nor support it, but maybe we could call it just version() so it would be 
> > KCoreAddons::version() which give us a clear indication that in a world of 
> > mix & match this may b different frm KXMLGUI::version() (if it existed)
> > 
> > Or am i overthinking this?
> 
> David Edmundson wrote:
> I did consider putting it in ECM so it was in every module, but it seemed 
> over complex especially as some frameworks have multiple libs.
> Also I can't imagine a situation where you'd really want to show more 
> than one text label.
> 
> I'll do the rename though, that's a good compromise.

Nope, we can't have a different version of KCoreAddons and KXMLGUI. (although I 
also prefer `::version()`).

+1 for docs.


- Aleix


---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/127031/#review92245
---


On Feb. 11, 2016, 1:53 a.m., David Edmundson wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/127031/
> ---
> 
> (Updated Feb. 11, 2016, 1:53 a.m.)
> 
> 
> Review request for KDE Frameworks.
> 
> 
> Repository: kcoreaddons
> 
> 
> Description
> ---
> 
> Adds a method similar to qVersion() that returns a string of the
> frameworks version being run. This differs from the header file which
> can only provide the version this app is compiled against.
> 
> The intended usage is in drkonqi system information.
> 
> 
> Diffs
> -
> 
>   src/lib/CMakeLists.txt a36eed26a281baf9ef1064dfb9aed3c394c52604 
>   src/lib/kcoreaddons.h PRE-CREATION 
>   src/lib/kcoreaddons.cpp PRE-CREATION 
> 
> Diff: https://git.reviewboard.kde.org/r/127031/diff/
> 
> 
> Testing
> ---
> 
> See https://git.reviewboard.kde.org/r/127032/
> 
> 
> Thanks,
> 
> David Edmundson
> 
>

___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Review Request 127031: Add function to get runtime frameworks version information

[David Edmundson]

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/127031/
---

(Updated Feb. 11, 2016, 12:53 a.m.)


Review request for KDE Frameworks.


Repository: kcoreaddons


Description
---

Adds a method similar to qVersion() that returns a string of the
frameworks version being run. This differs from the header file which
can only provide the version this app is compiled against.

The intended usage is in drkonqi system information.


Diffs (updated)
-

  src/lib/CMakeLists.txt a36eed26a281baf9ef1064dfb9aed3c394c52604 
  src/lib/kcoreaddons.h PRE-CREATION 
  src/lib/kcoreaddons.cpp PRE-CREATION 

Diff: https://git.reviewboard.kde.org/r/127031/diff/


Testing
---

See https://git.reviewboard.kde.org/r/127032/


Thanks,

David Edmundson

___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Review Request 127031: Add function to get runtime frameworks version information

[David Edmundson]

> On Feb. 10, 2016, 10:14 p.m., Albert Astals Cid wrote:
> > src/lib/kcoreaddons.h, line 29
> > 
> >
> > Documntation is missing
> > 
> > Also "technically" one could mix and max versions even if we don't do 
> > it nor support it, but maybe we could call it just version() so it would be 
> > KCoreAddons::version() which give us a clear indication that in a world of 
> > mix & match this may b different frm KXMLGUI::version() (if it existed)
> > 
> > Or am i overthinking this?

I did consider putting it in ECM so it was in every module, but it seemed over 
complex especially as some frameworks have multiple libs.
Also I can't imagine a situation where you'd really want to show more than one 
text label.

I'll do the rename though, that's a good compromise.


- David


---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/127031/#review92245
---


On Feb. 10, 2016, 5:10 p.m., David Edmundson wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/127031/
> ---
> 
> (Updated Feb. 10, 2016, 5:10 p.m.)
> 
> 
> Review request for KDE Frameworks.
> 
> 
> Repository: kcoreaddons
> 
> 
> Description
> ---
> 
> Adds a method similar to qVersion() that returns a string of the
> frameworks version being run. This differs from the header file which
> can only provide the version this app is compiled against.
> 
> The intended usage is in drkonqi system information.
> 
> 
> Diffs
> -
> 
>   src/lib/CMakeLists.txt a36eed26a281baf9ef1064dfb9aed3c394c52604 
>   src/lib/kcoreaddons.h PRE-CREATION 
>   src/lib/kcoreaddons.cpp PRE-CREATION 
> 
> Diff: https://git.reviewboard.kde.org/r/127031/diff/
> 
> 
> Testing
> ---
> 
> See https://git.reviewboard.kde.org/r/127032/
> 
> 
> Thanks,
> 
> David Edmundson
> 
>

___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Review Request 127031: Add function to get runtime frameworks version information

[Albert Astals Cid]

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/127031/#review92245
---




src/lib/kcoreaddons.h (line 29)


Documntation is missing

Also "technically" one could mix and max versions even if we don't do it 
nor support it, but maybe we could call it just version() so it would be 
KCoreAddons::version() which give us a clear indication that in a world of mix 
& match this may b different frm KXMLGUI::version() (if it existed)

Or am i overthinking this?


- Albert Astals Cid


On Feb. 10, 2016, 5:10 p.m., David Edmundson wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/127031/
> ---
> 
> (Updated Feb. 10, 2016, 5:10 p.m.)
> 
> 
> Review request for KDE Frameworks.
> 
> 
> Repository: kcoreaddons
> 
> 
> Description
> ---
> 
> Adds a method similar to qVersion() that returns a string of the
> frameworks version being run. This differs from the header file which
> can only provide the version this app is compiled against.
> 
> The intended usage is in drkonqi system information.
> 
> 
> Diffs
> -
> 
>   src/lib/CMakeLists.txt a36eed26a281baf9ef1064dfb9aed3c394c52604 
>   src/lib/kcoreaddons.h PRE-CREATION 
>   src/lib/kcoreaddons.cpp PRE-CREATION 
> 
> Diff: https://git.reviewboard.kde.org/r/127031/diff/
> 
> 
> Testing
> ---
> 
> See https://git.reviewboard.kde.org/r/127032/
> 
> 
> Thanks,
> 
> David Edmundson
> 
>

___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Review Request 127033: Add /../share/hunspell/ to dictionary search path

[Kåre Särs]

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/127033/
---

Review request for KDE Frameworks, Laurent Montel and Martin Tobias Holmedahl 
Sandsmark.


Repository: sonnet


Description
---

The default search path for hunspell dictionaries is /usr/share/hunspell/, but 
that is not a very common directory on windows ;)

For Windows and Mac there are some extra search paths defined in side #ifdefs, 
but they are hardcoded to the LibreOffice dictionary directories. Unfortunately 
the extra Windows path points to a 32bit LibreOffice 5 on a 64 bit Windows 
directory. This patch adds /../share/hunspell/ to the search path in 
case the default is not found. 

If wanted I can add a CMake define for specifying the path relative to the 
application directory.


Diffs
-

  src/core/guesslanguage.cpp e8deb90 
  src/plugins/hunspell/hunspellclient.cpp 3da7219 
  src/plugins/hunspell/hunspelldict.cpp bc5c314 

Diff: https://git.reviewboard.kde.org/r/127033/diff/


Testing
---

Compiled Sonnet and Kate on Windows and got spelling to work :)

It is now possible to add dictionaries to a relocatable /../share/hunspell/ and get spelling to work without depending on 
LibreOffice installation on Windows.


Thanks,

Kåre Särs

___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Review Request 127031: Add function to get runtime frameworks version information

[Martin Klapetek]

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/127031/#review92237
---



+1

- Martin Klapetek


On Feb. 10, 2016, 6:10 p.m., David Edmundson wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/127031/
> ---
> 
> (Updated Feb. 10, 2016, 6:10 p.m.)
> 
> 
> Review request for KDE Frameworks.
> 
> 
> Repository: kcoreaddons
> 
> 
> Description
> ---
> 
> Adds a method similar to qVersion() that returns a string of the
> frameworks version being run. This differs from the header file which
> can only provide the version this app is compiled against.
> 
> The intended usage is in drkonqi system information.
> 
> 
> Diffs
> -
> 
>   src/lib/CMakeLists.txt a36eed26a281baf9ef1064dfb9aed3c394c52604 
>   src/lib/kcoreaddons.h PRE-CREATION 
>   src/lib/kcoreaddons.cpp PRE-CREATION 
> 
> Diff: https://git.reviewboard.kde.org/r/127031/diff/
> 
> 
> Testing
> ---
> 
> See https://git.reviewboard.kde.org/r/127032/
> 
> 
> Thanks,
> 
> David Edmundson
> 
>

___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Review Request 127031: Add function to get runtime frameworks version information

[David Edmundson]

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/127031/
---

Review request for KDE Frameworks.


Repository: kcoreaddons


Description
---

Adds a method similar to qVersion() that returns a string of the
frameworks version being run. This differs from the header file which
can only provide the version this app is compiled against.

The intended usage is in drkonqi system information.


Diffs
-

  src/lib/CMakeLists.txt a36eed26a281baf9ef1064dfb9aed3c394c52604 
  src/lib/kcoreaddons.h PRE-CREATION 
  src/lib/kcoreaddons.cpp PRE-CREATION 

Diff: https://git.reviewboard.kde.org/r/127031/diff/


Testing
---

See https://git.reviewboard.kde.org/r/127032/


Thanks,

David Edmundson

___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Review Request 126650: [WIP] Add PM/ScreenSaver Inhibition capabilities to KIdleTime

[Martin Klapetek]

> On Feb. 10, 2016, 4:19 p.m., Aleix Pol Gonzalez wrote:
> > Are we convinced that KIdleTime is the best place to put this?
> > 
> > KIdleTime definition is:
> > > KIdleTime is a singleton reporting information on idle time. It is useful 
> > > not only for finding out about the current idle time of the PC, but also 
> > > for getting notified upon idle time events, such as custom timeouts, or 
> > > user activity.
> > 
> > Which I'm not sure is the same.
> > 
> > Furthermore, KIdleTime is supposed to be crossplatform.

> KIdleTime definition is:

Nowhere it says that the definition cannot be updated though. Disabling what 
happens when user is idle is directly related to "idle time detection".


- Martin


---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/126650/#review92227
---


On Jan. 26, 2016, 7:13 p.m., Martin Klapetek wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/126650/
> ---
> 
> (Updated Jan. 26, 2016, 7:13 p.m.)
> 
> 
> Review request for KDE Frameworks and Kai Uwe Broulik.
> 
> 
> Repository: kidletime
> 
> 
> Description
> ---
> 
> This is a work-in-progress, but I'm putting it up for a feedback now
> as most people are gone for the day when I wake up :)
> 
> ---
> 
> After some discussion in https://git.reviewboard.kde.org/r/126627/
> and then with Kai Uwe Broulik, I've added a PM/ScreenSaver inhibition
> capabilities to KIdleItem.
> 
> We decided with Kai that we want simple stuff, encapsulated away for
> the client as much as possible. So the Inhibition class has a static
> "constructors" which make the usage as easy as follows:
> 
> KIdleTime::Inhibition::createInhibition(KIdleTime::Inhibition::InhibitScreen, 
> QStringLiteral("Playing Movie"), mainWindow);
> 
> That call would return an Inhibition* object which has methods to set
> the inhibition type and reason and to activate/deactivate the inhibition.
> The static method above would activate() on the Inhibition right away;
> this allows a simple fire-and-forget usage. The Inhibition object can
> be parented to any other object; the inhibition will be deactivated when
> the Inhibition object is destroyed. The user can also keep the pointer
> around and call deactivate() whenever actually needed.
> 
> The inhibition itself first looks for Solid and if present, it uses the
> Solid interface. If not present, it goes for the FDO interfaces.
> 
> It comes with an autotest.
> 
> 
> Diffs
> -
> 
>   CMakeLists.txt ed5dc0c 
>   autotests/CMakeLists.txt PRE-CREATION 
>   autotests/fakePMServer.h PRE-CREATION 
>   autotests/fakePMServer.cpp PRE-CREATION 
>   autotests/inhibition_test.cpp PRE-CREATION 
>   autotests/qtest_dbus.h PRE-CREATION 
>   src/CMakeLists.txt 23e5e29 
>   src/inhibition.h PRE-CREATION 
>   src/inhibition.cpp PRE-CREATION 
> 
> Diff: https://git.reviewboard.kde.org/r/126650/diff/
> 
> 
> Testing
> ---
> 
> Everything works as expected, plus there's an autotest.
> 
> 
> Thanks,
> 
> Martin Klapetek
> 
>

___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Review Request 126650: [WIP] Add PM/ScreenSaver Inhibition capabilities to KIdleTime

[Aleix Pol Gonzalez]

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/126650/#review92227
---



Are we convinced that KIdleTime is the best place to put this?

KIdleTime definition is:
> KIdleTime is a singleton reporting information on idle time. It is useful not 
> only for finding out about the current idle time of the PC, but also for 
> getting notified upon idle time events, such as custom timeouts, or user 
> activity.

Which I'm not sure is the same.

Furthermore, KIdleTime is supposed to be crossplatform.


src/inhibition.cpp (line 38)


move all as initializers?



src/inhibition.cpp (line 61)


A bunch of these can be marked as const.



src/inhibition.cpp (line 94)


If this has to be cross-platform, dbus usage should be abstracted out. On 
Windows/OS X one won't find a dbus interface with this information.


- Aleix Pol Gonzalez


On Jan. 26, 2016, 7:13 p.m., Martin Klapetek wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/126650/
> ---
> 
> (Updated Jan. 26, 2016, 7:13 p.m.)
> 
> 
> Review request for KDE Frameworks and Kai Uwe Broulik.
> 
> 
> Repository: kidletime
> 
> 
> Description
> ---
> 
> This is a work-in-progress, but I'm putting it up for a feedback now
> as most people are gone for the day when I wake up :)
> 
> ---
> 
> After some discussion in https://git.reviewboard.kde.org/r/126627/
> and then with Kai Uwe Broulik, I've added a PM/ScreenSaver inhibition
> capabilities to KIdleItem.
> 
> We decided with Kai that we want simple stuff, encapsulated away for
> the client as much as possible. So the Inhibition class has a static
> "constructors" which make the usage as easy as follows:
> 
> KIdleTime::Inhibition::createInhibition(KIdleTime::Inhibition::InhibitScreen, 
> QStringLiteral("Playing Movie"), mainWindow);
> 
> That call would return an Inhibition* object which has methods to set
> the inhibition type and reason and to activate/deactivate the inhibition.
> The static method above would activate() on the Inhibition right away;
> this allows a simple fire-and-forget usage. The Inhibition object can
> be parented to any other object; the inhibition will be deactivated when
> the Inhibition object is destroyed. The user can also keep the pointer
> around and call deactivate() whenever actually needed.
> 
> The inhibition itself first looks for Solid and if present, it uses the
> Solid interface. If not present, it goes for the FDO interfaces.
> 
> It comes with an autotest.
> 
> 
> Diffs
> -
> 
>   CMakeLists.txt ed5dc0c 
>   autotests/CMakeLists.txt PRE-CREATION 
>   autotests/fakePMServer.h PRE-CREATION 
>   autotests/fakePMServer.cpp PRE-CREATION 
>   autotests/inhibition_test.cpp PRE-CREATION 
>   autotests/qtest_dbus.h PRE-CREATION 
>   src/CMakeLists.txt 23e5e29 
>   src/inhibition.h PRE-CREATION 
>   src/inhibition.cpp PRE-CREATION 
> 
> Diff: https://git.reviewboard.kde.org/r/126650/diff/
> 
> 
> Testing
> ---
> 
> Everything works as expected, plus there's an autotest.
> 
> 
> Thanks,
> 
> Martin Klapetek
> 
>

___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Solid/PowerManagement deprecation

[Jan Grulich]

Hi,

If I remember correctly there was an attempt by Lukáš Tinkl to create a new 
library 
replacing Solid/PowerManagement, see [1]. I don't know whether it's finished or 
not, 
but I guess he doesn't have time anymore since he joined Canonical and started 
working on something else.

[1] - https://quickgit.kde.org/?p=solid-power.git[1] 

Regards,
Jan
-- 
Jan Grulich 
Software Engineer, Desktop team
Red Hat Czech
On Wednesday 10 of February 2016 15:55:51 Aleix Pol wrote:
> Hi,
> I've been looking in the last days what applications and uses make our
> software stick to KDELibs4Support.
> 
> My impression is that the big missing thing is Solid/PowerManagement.
> 
> Is anyone looking into the issue? Should we look into un-deprecating it?
> 
> Aleix
> ___
> Plasma-devel mailing list
> plasma-de...@kde.org
> https://mail.kde.org/mailman/listinfo/plasma-devel



[1] https://quickgit.kde.org/?p=solid-power.git
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Solid/PowerManagement deprecation

[Martin Klapetek]

On Wed, Feb 10, 2016 at 9:55 AM, Aleix Pol  wrote:

> Hi,
> I've been looking in the last days what applications and uses make our
> software stick to KDELibs4Support.
>
> My impression is that the big missing thing is Solid/PowerManagement.
>
> Is anyone looking into the issue? Should we look into un-deprecating it?
>

Yes; a replacement for the inhibition functions is being done
at https://git.reviewboard.kde.org/r/126650/

Cheers
-- 
Martin Klapetek | KDE Developer
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Solid/PowerManagement deprecation

[Aleix Pol]

Hi,
I've been looking in the last days what applications and uses make our
software stick to KDELibs4Support.

My impression is that the big missing thing is Solid/PowerManagement.

Is anyone looking into the issue? Should we look into un-deprecating it?

Aleix
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Review Request 127029: Fix chromium/wine apps not being added to the menu for some distributions.

[David Edmundson]

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/127029/
---

(Updated Feb. 10, 2016, 2:07 p.m.)


Review request for KDE Frameworks.


Repository: kservice


Description (updated)
---

xdg-menu install installs local .menu files into .config/menus
/applications-merged/

kservice merges local menus from
.config/menus/$APPLICATIONS_MENU_NAME-merged where applications_menu_name
is a cmake variable of where to install the base menu.

In most cases it works as $APPLICATIONS_MENU_NAME is "applications"
by default. However some special distributions rename it.

The specification does say you should derive this folder from the menu
you're loading, so we're half following it.
However, there's an overriding clause that if you're loading an
application menu (i.e kde-applications.menu) the default merge directory
must be "applications-merged" instead.[1]

BUG: 213972

[1]https://specifications.freedesktop.org/menu-spec/menu-spec-
latest.html


Diffs
-

  src/sycoca/vfolder_menu.cpp d3e31c3a8c98506b8cd6c4964f61d0245d22d152 

Diff: https://git.reviewboard.kde.org/r/127029/diff/


Testing
---


Thanks,

David Edmundson

___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Review Request 127029: Fix chromium/wine apps not being added to the menu for some distributions.

[David Edmundson]

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/127029/
---

Review request for KDE Frameworks.


Repository: kservice


Description
---

xdg-menu install installs local .menu files into .config/menus
/applications-merged/

kservice merges local menus from
.config/menus/$APPLICATIONS_MENU_NAME.menu where applications_menu_name
is a cmake variable of where to install the base menu.

In most cases it works as $APPLICATIONS_MENU_NAME is "applications"
by default. However some special distributions rename it.

The specification does say you should derive this folder from the menu
you're loading, so we're half following it.
However, there's an overriding clause that if you're loading an
application menu (i.e kde-applications.menu) the default merge directory
must be "applications-merged" instead.[1]

BUG: 213972

[1]https://specifications.freedesktop.org/menu-spec/menu-spec-
latest.html


Diffs
-

  src/sycoca/vfolder_menu.cpp d3e31c3a8c98506b8cd6c4964f61d0245d22d152 

Diff: https://git.reviewboard.kde.org/r/127029/diff/


Testing
---


Thanks,

David Edmundson

___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel