Re: Review Request 127094: Don't use up 16K of /dev/urandom to seed rand() in KRandom

[Michael Pyne]

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

(Updated Feb. 16, 2016, 9:04 p.m.)


Status
--

This change has been marked as submitted.


Review request for KDE Frameworks.


Changes
---

Submitted with commit 47fd753a9a7e19a446896362528f69f76fd03029 by Michael Pyne 
to branch master.


Bugs: 359485
https://bugs.kde.org/show_bug.cgi?id=359485


Repository: kcoreaddons


Description
---

A bug reporter notes that KRandom reads 16K from /dev/urandom when seeding its 
RNG (which is just the libc RNG). This is because we simply use QFile, which 
buffers by default, the fix is to avoid buffering the output of this special 
file.

While the effect of reading the extra 16K-4 bytes should not be severe (I would 
not expect a modern OS to return bytes that utilize raw entropy) there's no 
reason to do it wrong either.


Diffs
-

  src/lib/randomness/krandom.cpp da78388 

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


Testing
---

Compiles and installs, applications still seem to run.


Thanks,

Michael Pyne

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

Re: Review Request 127094: Don't use up 16K of /dev/urandom to seed rand() in KRandom

[Aleix Pol Gonzalez]

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


Ship it!




Ship It!

- Aleix Pol Gonzalez


On Feb. 17, 2016, 4:26 a.m., Michael Pyne wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/127094/
> ---
> 
> (Updated Feb. 17, 2016, 4:26 a.m.)
> 
> 
> Review request for KDE Frameworks.
> 
> 
> Bugs: 359485
> https://bugs.kde.org/show_bug.cgi?id=359485
> 
> 
> Repository: kcoreaddons
> 
> 
> Description
> ---
> 
> A bug reporter notes that KRandom reads 16K from /dev/urandom when seeding 
> its RNG (which is just the libc RNG). This is because we simply use QFile, 
> which buffers by default, the fix is to avoid buffering the output of this 
> special file.
> 
> While the effect of reading the extra 16K-4 bytes should not be severe (I 
> would not expect a modern OS to return bytes that utilize raw entropy) 
> there's no reason to do it wrong either.
> 
> 
> Diffs
> -
> 
>   src/lib/randomness/krandom.cpp da78388 
> 
> Diff: https://git.reviewboard.kde.org/r/127094/diff/
> 
> 
> Testing
> ---
> 
> Compiles and installs, applications still seem to run.
> 
> 
> Thanks,
> 
> Michael Pyne
> 
>

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

Re: libkonq release? I'm missing the favicons interface

[Robby Stephenson]

On Tue, Feb 16, 2016 at 5:00 PM, David Faure  wrote:

> I'm curious though, what's the use case for a large favicon? In KDE4 the
> only
> time I see this is when using Alt+Tab and with konqueror windows open (and
> that
> looks a bit weird because other apps have a much bigger icon than konq's,
> but
> that's an unrelated issue I guess). I guess your app has another use for
> large
> icons with a favicon, I'm just curious what it is, and whether the
> text-html icon
> as the main icon is the best icon to have. This is an opportunity to
> rethink this
> if we want to ;)
>

Tellico searches a number of API end points, including some like SRU or
z39.50 that could be any server at all. Many are also http servers and
provide a favicon. In the configuration dialog for those sources, I chose
to put a 64x64 icon next to all the specific data options and the favicon
overlay fits the bill. I agree - it's an odd case, and as for whether
text/html is the best icon, well, probably better than any other option.

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

Review Request 127094: Don't use up 16K of /dev/urandom to seed rand() in KRandom

[Michael Pyne]

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

Review request for KDE Frameworks.


Bugs: 359485
https://bugs.kde.org/show_bug.cgi?id=359485


Repository: kcoreaddons


Description
---

A bug reporter notes that KRandom reads 16K from /dev/urandom when seeding its 
RNG (which is just the libc RNG). This is because we simply use QFile, which 
buffers by default, the fix is to avoid buffering the output of this special 
file.

While the effect of reading the extra 16K-4 bytes should not be severe (I would 
not expect a modern OS to return bytes that utilize raw entropy) there's no 
reason to do it wrong either.


Diffs
-

  src/lib/randomness/krandom.cpp da78388 

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


Testing
---

Compiles and installs, applications still seem to run.


Thanks,

Michael Pyne

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

Re: File dialog filters

[Frederik Schwarzer]

Am Dienstag, 16. Februar 2016, 18:27:23 schrieb Christian Dávid:

Hi,

> I noticed that in KMyMoney the filter strings for file dialogs are
> created "by hand", e.g. i18n("C++ sources (*.cpp *.cxx *.c++);;All
> files (*)"). So each of them must be translated. Alternatively
> something like
> 
> QMimeDatabase db;
> db.mimeTypeForName("text/x-c++src").filterString()

Just a guess but many application might not succeed in finding their 
MIME type in the db. They could provide an XML file for that, but this 
is quite a hassle compared to just writing a few characters. Also how 
can several mime types be represented? Like your example "C++ 
sources;;Allfiles".

>From the docs: "If the MIME type database cannot be found on the 
system, as is the case on most Windows, OS X, and iOS systems, Qt will 
use its own copy of it."
While this does not sound too bad, it at least gives the impression of 
a not too well working process.


> could be used to create these string lowering the burden on the
> translators and resulting in consistent translations for all
> mimetypes.

Thank you for thinking about the translators. :)

I did not know about QMimeDatabase until now. On my system I have 930 
MIME types in the db. Just for you to compare with yours.

To me this looks like a nice way to have unified strings for file 
types and I would also like to know if there are things speaking 
against using it.

Regards,
Frederik

Re: Review Request 126291: initial implementation of a platform plugin for OS X (WIP)

[René J . V . Bertin]

> On Feb. 15, 2016, 8:42 a.m., Martin Gräßlin wrote:
> > Thanks for contributing the code, I'm very happy to see this happening! 
> > Sorry, that I cannot provide a good review as I'm not really into the OSX 
> > API, thus my review here might look a little bit nitpicky.
> > 
> > General comment: maybe rename the directory from "osx" to "cocoa"? After 
> > all it's more about the windowing system than the operating system.
> 
> René J.V. Bertin wrote:
> Nitpickyness is no problem here.
> 
> I have nothing against renaming the subdirectory, but it'd be something 
> I'd want to leave to the end, for convenience on my end. Also, we'd probably 
> want to remain consistent, or work toward consistency. Currently there are no 
> "cocoa" backend/plugin directories; 3 frameworks use "osx" and another uses 
> "mac". There is also the question to what extent "cocoa" still is and will 
> remain the most appropriate term in this context ... and there is the issue 
> of iOS where some frameworks might be deployed and which might or might not 
> require specific adaptations. (And I'm probably hardly more "into" the iOS 
> APIs as you are into the OS X APIs.)
> 
> Martin Gräßlin wrote:
> sure, we can think about a more general approach to the naming. Having 
> that standardized over all framework might make sense (assuming we never care 
> about the difference between operating system and windowing system or it's 
> always windowing system).

On systems (platforms) where there is no choice of windowing and/or rendering 
system one could settle for a single term (question is, which ...).
Another approach would be to follow Qt's QPA naming, as far as that's relevant. 
That would have the benefit that the name choice would be standardised all the 
way up to the `-platform` argument available to the end user (on platforms 
supporting multiple QPAs).
It would also fit in with messages like
`org.kde.kwindowsystem: Loaded plugin 
"/Volumes/Debian/MP9/share/qt5/plugins/kf5/org.kde.kwindowsystem.platforms/KF5WindowSystemCocoaPlugin.so"
 for platform "cocoa"`


> On Feb. 15, 2016, 8:42 a.m., Martin Gräßlin wrote:
> > src/platforms/osx/kwindowsystem_macobjc.mm, line 89
> > 
> >
> > Why is the define needed? Doesn't it make more sense to just not build 
> > the OSX backend if COCOA is disabled?
> 
> René J.V. Bertin wrote:
> That would require knowing the answer to that question in the CMake file; 
> I'd have to look into that. Is it trivial to do the equivalent of an `#ifdef 
> TOKEN` in a CMake file?
> 
> Martin Gräßlin wrote:
> That should be defined in the cmake config for Qt5Gui. At least where I 
> needed similar things in the past it was defined.

I cannot find any variable/flag that indicates against what SDK Qt has been 
built, sadly.


> On Feb. 15, 2016, 8:42 a.m., Martin Gräßlin wrote:
> > src/platforms/osx/kwindowsystem_macobjc.mm, lines 331-342
> > 
> >
> > why support setting the current desktop if the number of desktops is 
> > hardcoded to 1?
> 
> René J.V. Bertin wrote:
> Is there an accepted way to include a kind of scrapbook with code 
> snippets that might be useful or "kinda work"?
> 
> Martin Gräßlin wrote:
> good question. I don't know of one.

This will need some more testing, but rather than hardcoding the number of 
desktops to 1 one could adapt the number when more desktops are discovered (= 
the max. observed "current desktop number").
KWindowSystem::numberOfDesktops() can change at runtime anyway, can't it?


- René J.V.


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


On Feb. 14, 2016, 5:44 p.m., René J.V. Bertin wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/126291/
> ---
> 
> (Updated Feb. 14, 2016, 5:44 p.m.)
> 
> 
> Review request for KDE Software on Mac OS X and KDE Frameworks.
> 
> 
> Repository: kwindowsystem
> 
> 
> Description
> ---
> 
> KWindowSystem has been lacking a platform plugin for OS X. This RR presents a 
> "backport" of the modified KDE4 KWindowSystem implementation that has been 
> used in the MacPorts kdelibs4 port for the last 2 or 3 (or more) years.
> 
> I have made some initial steps to remove deprecated Carbon API calls, but 
> this is clearly a work in progress.
> 
> Open questions include
> - is there any justification to run an event handler (or Cocoa observer) to 
> keep track of running applications, possibly even listing all their open 
> windows?
> - is there any use for the Qt event listener framework (cf. 

Re: Review Request 126291: initial implementation of a platform plugin for OS X (WIP)

[René J . V . Bertin]

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

(Updated Feb. 17, 2016, 12:23 a.m.)


Review request for KDE Software on Mac OS X and KDE Frameworks.


Repository: kwindowsystem


Description
---

KWindowSystem has been lacking a platform plugin for OS X. This RR presents a 
"backport" of the modified KDE4 KWindowSystem implementation that has been used 
in the MacPorts kdelibs4 port for the last 2 or 3 (or more) years.

I have made some initial steps to remove deprecated Carbon API calls, but this 
is clearly a work in progress.

Open questions include
- is there any justification to run an event handler (or Cocoa observer) to 
keep track of running applications, possibly even listing all their open 
windows?
- is there any use for the Qt event listener framework (cf. the NETEventFilter 
in the X11 plugin)? I haven't yet had time to try to figure out what this 
"could be good for", and am very open to suggestions in this departments.
- one application for such an event filter would be a listener that catches the 
opening and closing of all windows by the running process, and keeps track of 
their `WId`s. A new method could then be added (to `KWindowInfo`?) to 
distinguish `WId`s created by the running application from "foreign" ones 
(useful also on Wayland and MS Windows).

`KWindowSystem::setMainWindow` should become a front for payload provided by 
the plugins. I'll leave that to the regular/official maintainer(s) of this 
framework.

This code could probably do with *lots* of comments; I'll try to add them as 
questions about this or that bit of code arise.


Diffs (updated)
-

  src/debug_p.h 5ef8996 
  src/debug_p.cpp 72abfb7 
  src/kwindowsystem.cpp 407a67d 
  src/platforms/osx/CMakeLists.txt 4fc3347 
  src/platforms/osx/SCRAPBOOK PRE-CREATION 
  src/platforms/osx/cocoa.json PRE-CREATION 
  src/platforms/osx/kkeyserver.cpp 3ddb921 
  src/platforms/osx/kwindowinfo.cpp e8555bb 
  src/platforms/osx/kwindowinfo.mm PRE-CREATION 
  src/platforms/osx/kwindowinfo_mac_p.h c8f307e 
  src/platforms/osx/kwindowinfo_p_cocoa.h PRE-CREATION 
  src/platforms/osx/kwindowsystem.cpp 1758829 
  src/platforms/osx/kwindowsystem_mac_p.h PRE-CREATION 
  src/platforms/osx/kwindowsystem_macobjc.mm PRE-CREATION 
  src/platforms/osx/kwindowsystem_p_cocoa.h PRE-CREATION 
  src/platforms/osx/plugin.h PRE-CREATION 
  src/platforms/osx/plugin.cpp PRE-CREATION 

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


Testing
---

On OS X 10.9.5 with Qt 5.5.1 and frameworks 5.16.0 .


Thanks,

René J.V. Bertin

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

Re: libkonq release? I'm missing the favicons interface

[David Faure]

On Monday 15 February 2016 20:09:40 Robby Stephenson wrote:
> On Sat, Feb 6, 2016 at 10:21 AM, David Faure  wrote:
> 
> > Unaware of this discussion (no time to read kde-devel), I have done exactly
> > this during January. KIO (starting from 5.19) now has a KIOGui library
> > with a
> > FavIconRequestJob, which removes the dependency on the kded module
> > provided by libkonq (I'll kill it soon, since it wasn't released).
> > KIO::favIconForUrl(), which you mention in your mail, now uses the cache
> > where FavIconRequestJob stores icons. Please port tellico to
> > FavIconRequestJob and report any problems to me (or on the
> > kde-frameworks-devel list, or in bugzilla).
> 
> 
> FavIconRequestJob works great. I do see a behavioral regression in
> KIconLoader::loadIcon(). In KDE4, the favicon icon name started with
> "favicons/" and KIconLoader would use it as an overlay for a larger pixmap.
> The code in KIconLoader::loadIcon() checks that the icon name starts with
> "favicons/". With the current state, the icon name is an absolute path so
> the overlay doesn't work.

Ah that's interesting.

I changed the favicon code so that it returns an absolute path because I can't
rely on the startsWith("favicons/") hacks in KIconLoader anymore, I want the
icon returned by FavIconRequestJob to be loadable using QIcon, whichever
icon engine is being used behind the scenes.

I realized that this also improves the konqueror bookmarks XBEL file because
it now contains full paths instead of kde-specific favicons/foo.png which surely
must have created interoperability problems when trying to open such XBEL
files in other browsers or bookmark apps.

I had forgotten about that overlay-on-top-of-text-html-icon special rendering
in KIconLoader (when the icon is bigger than 22x22). If we want to keep this,
probably the best thing to do would be for FavIconRequestJob to have a new
method that returns a QIcon, with an internal icon engine that does this 
overlaying
on request when loading a large enough icon.
I'm curious though, what's the use case for a large favicon? In KDE4 the only
time I see this is when using Alt+Tab and with konqueror windows open (and that
looks a bit weird because other apps have a much bigger icon than konq's, but
that's an unrelated issue I guess). I guess your app has another use for large
icons with a favicon, I'm just curious what it is, and whether the text-html 
icon
as the main icon is the best icon to have. This is an opportunity to rethink 
this
if we want to ;)

> Thanks again for FavIconRequestJob in 5.19, David.

My pleasure.

-- 
David Faure, fa...@kde.org, http://www.davidfaure.fr
Working on KDE Frameworks 5

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

Re: Review Request 127091: Fix IconItem regression in 5.19

[Daniel Vrátil]

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

(Updated Feb. 16, 2016, 3:16 p.m.)


Status
--

This change has been marked as submitted.


Review request for KDE Frameworks, Plasma and David Edmundson.


Changes
---

Submitted with commit 525bf2d377c21b41971a72d694a507bf2af0ada6 by Dan Vrátil to 
branch master.


Bugs: 359388
http://bugs.kde.org/show_bug.cgi?id=359388


Repository: plasma-framework


Description
---

Fix sni-qt icons (or generally any non-theme icons) not showing in systray 
after 5184ac94. The fallback code was assuming that the name always comes from 
QIcon::iconTheme icon.


Diffs
-

  src/declarativeimports/core/iconitem.cpp 1d7921a 

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


Testing
---

I can see sni-qt apps icons in Plasma systray again.


Thanks,

Daniel Vrátil

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

Re: Review Request 127091: Fix IconItem regression in 5.19

[Albert Astals Cid]

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



Is this testable at all?

- Albert Astals Cid


On Feb. 16, 2016, 4:52 p.m., Daniel Vrátil wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/127091/
> ---
> 
> (Updated Feb. 16, 2016, 4:52 p.m.)
> 
> 
> Review request for KDE Frameworks, Plasma and David Edmundson.
> 
> 
> Bugs: 359388
> http://bugs.kde.org/show_bug.cgi?id=359388
> 
> 
> Repository: plasma-framework
> 
> 
> Description
> ---
> 
> Fix sni-qt icons (or generally any non-theme icons) not showing in systray 
> after 5184ac94. The fallback code was assuming that the name always comes 
> from QIcon::iconTheme icon.
> 
> 
> Diffs
> -
> 
>   src/declarativeimports/core/iconitem.cpp 1d7921a 
> 
> Diff: https://git.reviewboard.kde.org/r/127091/diff/
> 
> 
> Testing
> ---
> 
> I can see sni-qt apps icons in Plasma systray again.
> 
> 
> Thanks,
> 
> Daniel Vrátil
> 
>

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

Re: KActivities repository split

[Albert Astals Cid]

El Tuesday 16 February 2016, a les 13:31:40, Ivan Čukić va escriure:
> Hi everyone,
> 
> As previously announced, KActivities has been split into a few
> separate repositories. This mail is mostly intended to notify our dear
> packagers of the change, and the plan for the transition period.
> 
> KActivities framework 5.19 (as released a few days ago) contains
> everything that it used to, this is about the next version - 5.20.
> 
> This is the former setup:
> --
> 
> Everything was contained in kde:kactivities, and distributions used to
> split it into different packages.
> 
> 
> This is the setup now:
> ---
> 
> - kde:kactivities - contains the framework and QML includes, it will
> soon become a tier1 integration framework
> - kde:kactivitymanagerd - contains the activities service and its plugins
> - kde:kactivities-stats - the (first-to-be-released-with-5.20)
> framework for getting the usage statistics collected by the activities
> service
> 
> - KIO module from kde:kactivities will be moved to kio-extras
> - KCM module will be moved to plasma-desktop/kcms
> - fileitem plugin will also need a new home (any ideas?)
> 
> 
> The release schedules:
> -
> 
> kde:kactivities and kde:kactivities-stats will follow kde frameworks
> release schedule, other components will follow Plasma's release
> schedule.

Minor correction, kio-extras does not follow Plasma's release schedule.

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

Re: KActivities repository split

[Albert Astals Cid]

El Tuesday 16 February 2016, a les 13:31:40, Ivan Čukić va escriure:
> Hi everyone,
> 
> As previously announced, KActivities has been split into a few
> separate repositories. This mail is mostly intended to notify our dear
> packagers of the change, and the plan for the transition period.
> 
> KActivities framework 5.19 (as released a few days ago) contains
> everything that it used to, this is about the next version - 5.20.
> 
> This is the former setup:
> --
> 
> Everything was contained in kde:kactivities, and distributions used to
> split it into different packages.
> 
> 
> This is the setup now:
> ---
> 
> - kde:kactivities - contains the framework and QML includes, it will
> soon become a tier1 integration framework
> - kde:kactivitymanagerd - contains the activities service and its plugins
> - kde:kactivities-stats - the (first-to-be-released-with-5.20)
> framework for getting the usage statistics collected by the activities
> service
> 
> - KIO module from kde:kactivities will be moved to kio-extras
> - KCM module will be moved to plasma-desktop/kcms
> - fileitem plugin will also need a new home (any ideas?)
> 
> 
> The release schedules:
> -
> 
> kde:kactivities and kde:kactivities-stats will follow kde frameworks
> release schedule, other components will follow Plasma's release
> schedule.

Minor correction, kio-extras does not follow Plasma's release schedule.

Cheers,
 Albert

Re: Review Request 127091: Fix IconItem regression in 5.19

[Milian Wolff]

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


Ship it!




Ship It!

- Milian Wolff


On Feb. 16, 2016, 4:52 p.m., Daniel Vrátil wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/127091/
> ---
> 
> (Updated Feb. 16, 2016, 4:52 p.m.)
> 
> 
> Review request for KDE Frameworks, Plasma and David Edmundson.
> 
> 
> Bugs: 359388
> http://bugs.kde.org/show_bug.cgi?id=359388
> 
> 
> Repository: plasma-framework
> 
> 
> Description
> ---
> 
> Fix sni-qt icons (or generally any non-theme icons) not showing in systray 
> after 5184ac94. The fallback code was assuming that the name always comes 
> from QIcon::iconTheme icon.
> 
> 
> Diffs
> -
> 
>   src/declarativeimports/core/iconitem.cpp 1d7921a 
> 
> Diff: https://git.reviewboard.kde.org/r/127091/diff/
> 
> 
> Testing
> ---
> 
> I can see sni-qt apps icons in Plasma systray again.
> 
> 
> Thanks,
> 
> Daniel Vrátil
> 
>

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

File dialog filters

[Christian Dávid]

Hi,

I noticed that in KMyMoney the filter strings for file dialogs are created "by 
hand", e.g. i18n("C++ sources (*.cpp *.cxx *.c++);;All files (*)"). So each of 
them must be translated. Alternatively something like

QMimeDatabase db;
db.mimeTypeForName("text/x-c++src").filterString()

could be used to create these string lowering the burden on the translators 
and resulting in consistent translations for all mimetypes.

Do we have a policy regarding this? Are there any drawbacks? Can it happen 
that the mimetype database does not include all files on some systems?

I know there is QFileDialog::setMimeTypeFilters() where the mimetype can be 
set directly, but this does not work with the static functions.

Greetings
Christian

License of the Breeze style

[Александр Волков]

Hi.

I've noticed that the Breeze style is released under GPL-2+ license:
https://quickgit.kde.org/?p=breeze.git=blob=35961704333df1ddd85e307f674a0728501c8946=9920983f869b3e3654c97ea4b623c0f4e8c8fae7=kstyle%2Fbreeze.h

Why not LGPL? It's a library after all.

BR,
Alexander.

Re: Review Request 127091: Fix IconItem regression in 5.19

[David Rosca]

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




src/declarativeimports/core/iconitem.cpp (line 151)


I was just about to send the same fix!

You can also check here for source.canConver(), but that's just a 
cosmetic change.

Otherwise, +1 from me.


- David Rosca


On Feb. 16, 2016, 4:52 p.m., Daniel Vrátil wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/127091/
> ---
> 
> (Updated Feb. 16, 2016, 4:52 p.m.)
> 
> 
> Review request for KDE Frameworks, Plasma and David Edmundson.
> 
> 
> Bugs: 359388
> http://bugs.kde.org/show_bug.cgi?id=359388
> 
> 
> Repository: plasma-framework
> 
> 
> Description
> ---
> 
> Fix sni-qt icons (or generally any non-theme icons) not showing in systray 
> after 5184ac94. The fallback code was assuming that the name always comes 
> from QIcon::iconTheme icon.
> 
> 
> Diffs
> -
> 
>   src/declarativeimports/core/iconitem.cpp 1d7921a 
> 
> Diff: https://git.reviewboard.kde.org/r/127091/diff/
> 
> 
> Testing
> ---
> 
> I can see sni-qt apps icons in Plasma systray again.
> 
> 
> Thanks,
> 
> Daniel Vrátil
> 
>

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

Review Request 127091: Fix IconItem regression in 5.19

[Daniel Vrátil]

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

Review request for KDE Frameworks, Plasma and David Edmundson.


Bugs: 359388
http://bugs.kde.org/show_bug.cgi?id=359388


Repository: plasma-framework


Description
---

Fix sni-qt icons (or generally any non-theme icons) not showing in systray 
after 5184ac94. The fallback code was assuming that the name always comes from 
QIcon::iconTheme icon.


Diffs
-

  src/declarativeimports/core/iconitem.cpp 1d7921a 

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


Testing
---

I can see sni-qt apps icons in Plasma systray again.


Thanks,

Daniel Vrátil

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

Jenkins-kde-ci: kwindowsystem master kf5-qt5 » Linux,All,gcc - Build # 62 - Unstable!

[no-reply]

GENERAL INFO

BUILD UNSTABLE
Build URL: 
https://build.kde.org/job/kwindowsystem%20master%20kf5-qt5/PLATFORM=Linux,Variation=All,compiler=gcc/62/
Project: PLATFORM=Linux,Variation=All,compiler=gcc
Date of build: Tue, 16 Feb 2016 13:09:26 +
Build duration: 2 min 13 sec

CHANGE SET
Revision 2a5b7943a020f2154049d28a33216149b6220d53 by thomas.luebking: (support 
_NET_WM_BYPASS_COMPOSITOR)
  change: edit src/netwm_def.h
  change: edit src/platforms/xcb/atoms_p.h
  change: edit src/platforms/xcb/netwm.cpp


JUNIT RESULTS

Name: (root) Failed: 1 test(s), Passed: 9 test(s), Skipped: 0 test(s), Total: 
10 test(s)Failed: TestSuite.kwindowsystem-netrootinfotestwm

COBERTURA RESULTS

Cobertura Coverage Report
  PACKAGES 3/4 (75%)FILES 40/46 (87%)CLASSES 40/46 (87%)LINE 6477/8807 
(74%)CONDITIONAL 3543/5482 (65%)

By packages
  
autotests
FILES 13/13 (100%)CLASSES 13/13 (100%)LINE 2737/2846 
(96%)CONDITIONAL 1452/2731 (53%)
src
FILES 13/15 (87%)CLASSES 13/15 (87%)LINE 751/1406 
(53%)CONDITIONAL 307/462 (66%)
src.platforms.wayland
FILES 0/2 (0%)CLASSES 0/2 (0%)LINE 0/89 (0%)CONDITIONAL 0/0 
(100%)
src.platforms.xcb
FILES 14/16 (88%)CLASSES 14/16 (88%)LINE 2989/4466 
(67%)CONDITIONAL 1784/2289 (78%)___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Jenkins-kde-ci: kwindowsystem master stable-kf5-qt5 » Linux,All,gcc - Build # 59 - Still Unstable!

[no-reply]

GENERAL INFO

BUILD UNSTABLE
Build URL: 
https://build.kde.org/job/kwindowsystem%20master%20stable-kf5-qt5/PLATFORM=Linux,Variation=All,compiler=gcc/59/
Project: PLATFORM=Linux,Variation=All,compiler=gcc
Date of build: Tue, 16 Feb 2016 13:09:26 +
Build duration: 2 min 16 sec

CHANGE SET
Revision 2a5b7943a020f2154049d28a33216149b6220d53 by thomas.luebking: (support 
_NET_WM_BYPASS_COMPOSITOR)
  change: edit src/platforms/xcb/netwm.cpp
  change: edit src/netwm_def.h
  change: edit src/platforms/xcb/atoms_p.h


JUNIT RESULTS

Name: (root) Failed: 1 test(s), Passed: 9 test(s), Skipped: 0 test(s), Total: 
10 test(s)Failed: TestSuite.kwindowsystem-netrootinfotestwm

COBERTURA RESULTS

Cobertura Coverage Report
  PACKAGES 3/4 (75%)FILES 40/46 (87%)CLASSES 40/46 (87%)LINE 6477/8813 
(73%)CONDITIONAL 3541/5482 (65%)

By packages
  
autotests
FILES 13/13 (100%)CLASSES 13/13 (100%)LINE 2736/2846 
(96%)CONDITIONAL 1450/2731 (53%)
src
FILES 13/15 (87%)CLASSES 13/15 (87%)LINE 750/1407 
(53%)CONDITIONAL 308/462 (67%)
src.platforms.wayland
FILES 0/2 (0%)CLASSES 0/2 (0%)LINE 0/89 (0%)CONDITIONAL 0/0 
(100%)
src.platforms.xcb
FILES 14/16 (88%)CLASSES 14/16 (88%)LINE 2991/4471 
(67%)CONDITIONAL 1783/2289 (78%)___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Review Request 127090: Clean KWalletQuery cmake file

[Aleix Pol Gonzalez]

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

Review request for KDE Frameworks and Valentin Rusu.


Repository: kwallet


Description
---

I saw it didn't build because I needed a build with KDocTools, ended up 
cleaning a bit more.


Diffs
-

  src/runtime/kwallet-query/CMakeLists.txt 42b4687 
  src/runtime/kwallet-query/src/main.cpp c19cb29 

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


Testing
---

Built with and without KDocTools.


Thanks,

Aleix Pol Gonzalez

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

Re: Review Request 127088: Let KDocTools stay optional on KPackage

[Aleix Pol Gonzalez]

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

(Updated Feb. 16, 2016, 3:19 p.m.)


Status
--

This change has been marked as submitted.


Review request for KDE Frameworks and Plasma.


Changes
---

Submitted with commit c72f315c70e873ad444203b59c27a3f664b8c858 by Aleix Pol to 
branch master.


Repository: kpackage


Description
---

As most other frameworks do.


Diffs
-

  CMakeLists.txt cdd4a26 

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


Testing
---

Builds


Thanks,

Aleix Pol Gonzalez

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

Re: Review Request 127088: Let KDocTools stay optional on KPackage

[Marco Martin]

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


Ship it!




Ship It!

- Marco Martin


On Feb. 16, 2016, 2:18 p.m., Aleix Pol Gonzalez wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/127088/
> ---
> 
> (Updated Feb. 16, 2016, 2:18 p.m.)
> 
> 
> Review request for KDE Frameworks and Plasma.
> 
> 
> Repository: kpackage
> 
> 
> Description
> ---
> 
> As most other frameworks do.
> 
> 
> Diffs
> -
> 
>   CMakeLists.txt cdd4a26 
> 
> Diff: https://git.reviewboard.kde.org/r/127088/diff/
> 
> 
> Testing
> ---
> 
> Builds
> 
> 
> Thanks,
> 
> Aleix Pol Gonzalez
> 
>

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

Review Request 127088: Let KDocTools stay optional on KPackage

[Aleix Pol Gonzalez]

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

Review request for KDE Frameworks and Plasma.


Repository: kpackage


Description
---

As most other frameworks do.


Diffs
-

  CMakeLists.txt cdd4a26 

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


Testing
---

Builds


Thanks,

Aleix Pol Gonzalez

___
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. 16, 2016, 1:40 p.m.)


Status
--

This change has been marked as submitted.


Review request for KDE Frameworks.


Changes
---

Submitted with commit eb561bab855b90ed2277d846cce2a099c4075dfb by David 
Edmundson to branch master.


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-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

Re: KActivities repository split

[Luigi Toscano]

Ivan Čukić ha scritto:
> Hi everyone,
> 
> As previously announced, KActivities has been split into a few
> separate repositories. This mail is mostly intended to notify our dear
> packagers of the change, and the plan for the transition period.
> 
> KActivities framework 5.19 (as released a few days ago) contains
> everything that it used to, this is about the next version - 5.20.
> 
> This is the former setup:
> --
> 
> Everything was contained in kde:kactivities, and distributions used to
> split it into different packages.
> 
> 
> This is the setup now:
> ---
> 
> - kde:kactivities - contains the framework and QML includes, it will
> soon become a tier1 integration framework
> - kde:kactivitymanagerd - contains the activities service and its plugins
> - kde:kactivities-stats - the (first-to-be-released-with-5.20)
> framework for getting the usage statistics collected by the activities
> service
> 
> - KIO module from kde:kactivities will be moved to kio-extras
> - KCM module will be moved to plasma-desktop/kcms
> - fileitem plugin will also need a new home (any ideas?)

Can you please also describe how this affects translations? How translations
files (and desktop files, which are sources for translations too) are moved
around, so that we can move them around

(you can follow up to kde-i18n-doc@ only for this part).

Also, see below:
> 
> 
> The release schedules:
> -
> 
> kde:kactivities and kde:kactivities-stats will follow kde frameworks
> release schedule, other components will follow Plasma's release
> schedule.
> 
> How to handle this transition is explained below.
> 
> 
> Dependencies:
> -
> 
> - kde:kactivities has a optional runtime, but *strongly* recommended
> dependency on kde:kactivitymanagerd (on Plasma distributions)
> - kde:kactivities-stats is not used by anyone at the moment (plasma
> has had an internal copy with a different soname for some time now,
> and it will keep that internal copy until plasma 5.7). Plasma 5.7 will
> depend on kactivities and kactivities-stats.
> 
> 
> The transition period:
> -
> 
> The situation with kde:kactivitymanagerd is clear, when making 5.20
> packages of kde:kactivities, please make the kde:kactivitymanagerd
> package to be a hard requirement (alternatively, make plasma-workspace
> require kde:kactivitymanagerd, and make it to be just an optional
> dependency for kde:kactivities).
> 
> The potential problem is with the additional modules like KCM, KIO and
> the FileItem plugin for Dolphin. If the user updates to kf5.20 before
> updating to plasma 5.6 (which will be released after kf5.20, but will
> not depend on kf5.20) these components will be missing, along with the
> features they provide.
> 
> Therefore, as a one-off, we are going to release kcm+kio+fileitem
> plugin as a tarball called kactivities-workspace-5.5 (alternatively,
> is is also available as a git repository at
> kde:scratch/ivan/kactivities-workspace).
> 
> We will also release kactivitymanagerd 5.5 before kf5.20 so that a
> package can be created on time for the update.
> 
> To recap, we are going to make these two releases out of schedule:
> - kactivitymanagerd-5.5 that will contain the activities service
> needed for the upgrade to kf5.20
> - kactivities-workspace-5.5 that will contain workspace plugins (KIO,
> KCM, FileItem) for the period between the upgrade to kf5.20 and
> upgrade to plasma 5.6.

Please don't forget translations for those special tarballs.

Ciao
-- 
Luigi

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

Re: KActivities repository split

[Luigi Toscano]

Ivan Čukić ha scritto:
> Hi everyone,
> 
> As previously announced, KActivities has been split into a few
> separate repositories. This mail is mostly intended to notify our dear
> packagers of the change, and the plan for the transition period.
> 
> KActivities framework 5.19 (as released a few days ago) contains
> everything that it used to, this is about the next version - 5.20.
> 
> This is the former setup:
> --
> 
> Everything was contained in kde:kactivities, and distributions used to
> split it into different packages.
> 
> 
> This is the setup now:
> ---
> 
> - kde:kactivities - contains the framework and QML includes, it will
> soon become a tier1 integration framework
> - kde:kactivitymanagerd - contains the activities service and its plugins
> - kde:kactivities-stats - the (first-to-be-released-with-5.20)
> framework for getting the usage statistics collected by the activities
> service
> 
> - KIO module from kde:kactivities will be moved to kio-extras
> - KCM module will be moved to plasma-desktop/kcms
> - fileitem plugin will also need a new home (any ideas?)

Can you please also describe how this affects translations? How translations
files (and desktop files, which are sources for translations too) are moved
around, so that we can move them around

(you can follow up to kde-i18n-doc@ only for this part).

Also, see below:
> 
> 
> The release schedules:
> -
> 
> kde:kactivities and kde:kactivities-stats will follow kde frameworks
> release schedule, other components will follow Plasma's release
> schedule.
> 
> How to handle this transition is explained below.
> 
> 
> Dependencies:
> -
> 
> - kde:kactivities has a optional runtime, but *strongly* recommended
> dependency on kde:kactivitymanagerd (on Plasma distributions)
> - kde:kactivities-stats is not used by anyone at the moment (plasma
> has had an internal copy with a different soname for some time now,
> and it will keep that internal copy until plasma 5.7). Plasma 5.7 will
> depend on kactivities and kactivities-stats.
> 
> 
> The transition period:
> -
> 
> The situation with kde:kactivitymanagerd is clear, when making 5.20
> packages of kde:kactivities, please make the kde:kactivitymanagerd
> package to be a hard requirement (alternatively, make plasma-workspace
> require kde:kactivitymanagerd, and make it to be just an optional
> dependency for kde:kactivities).
> 
> The potential problem is with the additional modules like KCM, KIO and
> the FileItem plugin for Dolphin. If the user updates to kf5.20 before
> updating to plasma 5.6 (which will be released after kf5.20, but will
> not depend on kf5.20) these components will be missing, along with the
> features they provide.
> 
> Therefore, as a one-off, we are going to release kcm+kio+fileitem
> plugin as a tarball called kactivities-workspace-5.5 (alternatively,
> is is also available as a git repository at
> kde:scratch/ivan/kactivities-workspace).
> 
> We will also release kactivitymanagerd 5.5 before kf5.20 so that a
> package can be created on time for the update.
> 
> To recap, we are going to make these two releases out of schedule:
> - kactivitymanagerd-5.5 that will contain the activities service
> needed for the upgrade to kf5.20
> - kactivities-workspace-5.5 that will contain workspace plugins (KIO,
> KCM, FileItem) for the period between the upgrade to kf5.20 and
> upgrade to plasma 5.6.

Please don't forget translations for those special tarballs.

Ciao
-- 
Luigi

KActivities repository split

[Ivan Čukić]

Hi everyone,

As previously announced, KActivities has been split into a few
separate repositories. This mail is mostly intended to notify our dear
packagers of the change, and the plan for the transition period.

KActivities framework 5.19 (as released a few days ago) contains
everything that it used to, this is about the next version - 5.20.

This is the former setup:
--

Everything was contained in kde:kactivities, and distributions used to
split it into different packages.


This is the setup now:
---

- kde:kactivities - contains the framework and QML includes, it will
soon become a tier1 integration framework
- kde:kactivitymanagerd - contains the activities service and its plugins
- kde:kactivities-stats - the (first-to-be-released-with-5.20)
framework for getting the usage statistics collected by the activities
service

- KIO module from kde:kactivities will be moved to kio-extras
- KCM module will be moved to plasma-desktop/kcms
- fileitem plugin will also need a new home (any ideas?)


The release schedules:
-

kde:kactivities and kde:kactivities-stats will follow kde frameworks
release schedule, other components will follow Plasma's release
schedule.

How to handle this transition is explained below.


Dependencies:
-

- kde:kactivities has a optional runtime, but *strongly* recommended
dependency on kde:kactivitymanagerd (on Plasma distributions)
- kde:kactivities-stats is not used by anyone at the moment (plasma
has had an internal copy with a different soname for some time now,
and it will keep that internal copy until plasma 5.7). Plasma 5.7 will
depend on kactivities and kactivities-stats.


The transition period:
-

The situation with kde:kactivitymanagerd is clear, when making 5.20
packages of kde:kactivities, please make the kde:kactivitymanagerd
package to be a hard requirement (alternatively, make plasma-workspace
require kde:kactivitymanagerd, and make it to be just an optional
dependency for kde:kactivities).

The potential problem is with the additional modules like KCM, KIO and
the FileItem plugin for Dolphin. If the user updates to kf5.20 before
updating to plasma 5.6 (which will be released after kf5.20, but will
not depend on kf5.20) these components will be missing, along with the
features they provide.

Therefore, as a one-off, we are going to release kcm+kio+fileitem
plugin as a tarball called kactivities-workspace-5.5 (alternatively,
is is also available as a git repository at
kde:scratch/ivan/kactivities-workspace).

We will also release kactivitymanagerd 5.5 before kf5.20 so that a
package can be created on time for the update.

To recap, we are going to make these two releases out of schedule:
- kactivitymanagerd-5.5 that will contain the activities service
needed for the upgrade to kf5.20
- kactivities-workspace-5.5 that will contain workspace plugins (KIO,
KCM, FileItem) for the period between the upgrade to kf5.20 and
upgrade to plasma 5.6.

Cheerio,
Ivan

--
KDE, ivan.cu...@kde.org, http://cukic.co/
gpg key id: 850B6F76
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

KActivities repository split

[Ivan Čukić]

Hi everyone,

As previously announced, KActivities has been split into a few
separate repositories. This mail is mostly intended to notify our dear
packagers of the change, and the plan for the transition period.

KActivities framework 5.19 (as released a few days ago) contains
everything that it used to, this is about the next version - 5.20.

This is the former setup:
--

Everything was contained in kde:kactivities, and distributions used to
split it into different packages.


This is the setup now:
---

- kde:kactivities - contains the framework and QML includes, it will
soon become a tier1 integration framework
- kde:kactivitymanagerd - contains the activities service and its plugins
- kde:kactivities-stats - the (first-to-be-released-with-5.20)
framework for getting the usage statistics collected by the activities
service

- KIO module from kde:kactivities will be moved to kio-extras
- KCM module will be moved to plasma-desktop/kcms
- fileitem plugin will also need a new home (any ideas?)


The release schedules:
-

kde:kactivities and kde:kactivities-stats will follow kde frameworks
release schedule, other components will follow Plasma's release
schedule.

How to handle this transition is explained below.


Dependencies:
-

- kde:kactivities has a optional runtime, but *strongly* recommended
dependency on kde:kactivitymanagerd (on Plasma distributions)
- kde:kactivities-stats is not used by anyone at the moment (plasma
has had an internal copy with a different soname for some time now,
and it will keep that internal copy until plasma 5.7). Plasma 5.7 will
depend on kactivities and kactivities-stats.


The transition period:
-

The situation with kde:kactivitymanagerd is clear, when making 5.20
packages of kde:kactivities, please make the kde:kactivitymanagerd
package to be a hard requirement (alternatively, make plasma-workspace
require kde:kactivitymanagerd, and make it to be just an optional
dependency for kde:kactivities).

The potential problem is with the additional modules like KCM, KIO and
the FileItem plugin for Dolphin. If the user updates to kf5.20 before
updating to plasma 5.6 (which will be released after kf5.20, but will
not depend on kf5.20) these components will be missing, along with the
features they provide.

Therefore, as a one-off, we are going to release kcm+kio+fileitem
plugin as a tarball called kactivities-workspace-5.5 (alternatively,
is is also available as a git repository at
kde:scratch/ivan/kactivities-workspace).

We will also release kactivitymanagerd 5.5 before kf5.20 so that a
package can be created on time for the update.

To recap, we are going to make these two releases out of schedule:
- kactivitymanagerd-5.5 that will contain the activities service
needed for the upgrade to kf5.20
- kactivities-workspace-5.5 that will contain workspace plugins (KIO,
KCM, FileItem) for the period between the upgrade to kf5.20 and
upgrade to plasma 5.6.

Cheerio,
Ivan

--
KDE, ivan.cu...@kde.org, http://cukic.co/
gpg key id: 850B6F76