Re: Review Request 120573: [OS X] make KDE's trash use the OS X trash

2014-10-14 Thread René J . V . Bertin

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

(Updated Oct. 14, 2014, 10:38 a.m.)


Review request for KDE Software on Mac OS X, KDE Runtime and David Faure.


Repository: kde-runtime


Description
---

KDE on OS X does not handle the desktop session (no Plasma) nor can it rely 
on XDG to obtain the proper paths to use for something like the trash. As a 
result, all applications that propose to move things they manage to the 
wastebin (Dolphin, but also digiKam) will store those items in a place that has 
no particular meaning on OS X, and that will thus tend to fill up.

OS X stores trash in one of several locations. Files trashed from the boot 
volume (and/or the volume containing $HOME, I don't actually know that) end up 
in `~/.Trash`. Files deleted from other volumes end up in 
`/Volumes/volName/.Trashes/uid`, where volName is the volume name (regardless 
whether it's an external or a remote drive; only mounted NFS shares are handled 
differently) and uid the numerical user id. Permissions on `.Trashes` are the 
same as those expected by KDE.

The kio_trash kioslave appears to support several actual trash directory 
locations, just like OS X. `TrashImpl::init()` creates a standard trash in 
`~/.local/share/Trash` (at least under OS X) but also 
`TrashImpl::trashForMountPoint()` that is used in cases I have not yet 
encountered.

On OS X, my modified `TrashImpl::init()` sets the standard trash directory to 
`~/.Trash/KDE.trash` and will create the `files` and `info` subdirectories as 
required, because they will of course be deleted when the user empties the OS X 
trash. `TrashImpl::fileRemoved()` has been modified to call a new function, 
`deleteEmptyTrashInfraStructure` to delete the KDE trash's internal 
infrastructure when the wastebin is empty so that OS X also sees the trash as 
emptied. (Since implementing `deleteEmptyTrashInfraStructure` this feature 
actually works, as expected as far as I can tell).

Remains to be done:
- determine in what cases `trashForMountPoint()` is used, and finish the 
modifications for it to use `/.Trashes/uid/KDE.trash`


Diffs
-

  kioslave/trash/trashimpl.h bc68723 
  kioslave/trash/trashimpl.cpp 30ee05b 

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


Testing
---

On OS X 10.6.8 with kdelibs and kde-runtime git/4.14, using Dolphin. Tested 
actions are
- move items to wastebin from $HOME and a directory on a different volume
- restore items to both places
- empty wastebin through Dolphin
- empty OS X trashcan


Thanks,

René J.V. Bertin



Re: Review Request 120554: Initial frameworks port of kompare

2014-10-14 Thread Aleix Pol Gonzalez

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



komparepart/kompare_part.cpp
https://git.reviewboard.kde.org/r/120554/#comment47661

You probably want to use qCDebug for those debug statements.

Or just remove them if it's not useful.



komparepart/kompare_part.cpp
https://git.reviewboard.kde.org/r/120554/#comment47662

qWarning()



komparepart/kompare_part.cpp
https://git.reviewboard.kde.org/r/120554/#comment47663

no need for toString, also the  endl thing is a KDE3 thing, maybe this 
can be dropped for good now. :)



komparepart/kompareprefdlg.cpp
https://git.reviewboard.kde.org/r/120554/#comment47664

a good example of one that can be removed.


Most comments are regarding qDebug usage. I would suggest just to move it into 
a frameworks branch as well. 

+1 all in all.

- Aleix Pol Gonzalez


On Oct. 13, 2014, 11:46 p.m., Jeremy Whiting wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://git.reviewboard.kde.org/r/120554/
 ---
 
 (Updated Oct. 13, 2014, 11:46 p.m.)
 
 
 Review request for kdelibs and Vavelin Kevin.
 
 
 Repository: kompare
 
 
 Description
 ---
 
 I spent a bit of time porting kompare to kf5. It builds and runs and compares 
 files and folders but I'm pretty sure I missed something. 
 
 I'll reread my changes also but wanted to get this out there to be played 
 with also.
 
 
 Diffs
 -
 
   CMakeLists.txt 86e4504ad3ae06519cbfaaf35781238f5f234857 
   doc/CMakeLists.txt 06d898738aabdfc947e89de848e2fbe903d5e6cc 
   interfaces/CMakeLists.txt 4bb0c6c53e8b995f1c7350cd02268e2e05ddb38a 
   interfaces/kompareinterface.h a28d209b058fb06cc970e6ba3538ace721319be5 
   kompare_shell.h de099ffbcc92a22a4374ad6cfca0bccc6b0e97bc 
   kompare_shell.cpp 9d22085780fbbffcb9b480cbb16c30e73c0ba71e 
   komparenavtreepart/CMakeLists.txt da52bc7d0d9f032d80f6f2257dbbed1f6fb0e81a 
   komparenavtreepart/komparenavtreepart.h 
 eb08329be477febe93b4ca7a8c787656abbfc68f 
   komparenavtreepart/komparenavtreepart.cpp 
 d3bdc93ddaf28e026b7c1847b8d4f6dbc46125ee 
   komparepart/CMakeLists.txt ee83458a3034c3fb873629d650efe5668955900b 
   komparepart/kompare_part.h 0c4d3dd40ca32e07b2402280539d03f15cfc 
   komparepart/kompare_part.cpp 08df1dc0985391908eb81da9c4cfdd0836cd4b23 
   komparepart/kompareconnectwidget.h 03eb746c24dc3899b64d3907ae21e0de656e369f 
   komparepart/kompareconnectwidget.cpp 
 2a8cb920280f2b42ab09e7962a441529b8cdfc0c 
   komparepart/komparelistview.cpp b2935c917541984532814d301b6a7f5bdd661c72 
   komparepart/kompareprefdlg.cpp 0b18696acf270cf5a0351312aa3ffe13eff9b9e6 
   komparepart/komparesaveoptionswidget.h 
 9c49815b1b95b9448eb5fccda35e4c7c7fb1e2f1 
   komparepart/komparesaveoptionswidget.cpp 
 06530d85159305fc1330f495a1c52b0155e45e37 
   komparepart/komparesplitter.h 11a344f29f46d68ca5418c770bd5e502d527e0fe 
   komparepart/komparesplitter.cpp 2848f881992bae0b0e7141c1f6c47a2239211844 
   komparepart/kompareview.h 93ea0644a590c56e600e466a69bf227dc93328b1 
   kompareurldialog.cpp 561dd4518dda0be64198beff56e986da4294fe2b 
   libdialogpages/CMakeLists.txt 22906650d1f0f8fb0b5d8d3d272f09d44bf7408c 
   libdialogpages/diffpage.cpp 94221ca8badbd1773ff48071fd558bd111750e47 
   libdialogpages/filespage.cpp 417fbd12b0f7622da23d0da0e934476d142df149 
   libdialogpages/pagebase.cpp 4aa33d7d5b8eb6779bb96e5533d0f11235c30aac 
   libdialogpages/viewpage.cpp e26d72843587cf4ed60f0d7dcde51ec4f19aad29 
   libdialogpages/viewsettings.h 305e934815175c0fc60c8a045070e48f7b932935 
   main.cpp ac68e2421c1f02460e732eb4dc7f79036df9db2e 
   pics/CMakeLists.txt 512f6e8cad202bc592c08531654754bd311fcb5e 
   pics/hi128-app-kompare.png  
   pics/hi16-app-kompare.png  
   pics/hi22-app-kompare.png  
   pics/hi32-app-kompare.png  
   pics/hi48-app-kompare.png  
   pics/hisc-app-kompare.svgz  
 
 Diff: https://git.reviewboard.kde.org/r/120554/diff/
 
 
 Testing
 ---
 
 It builds, runs and seems to wok ok comparing files and folders. The 
 QFileDialog it uses wasn't showing files I expected to see though, may need 
 to play with the filters etc.
 
 Also ported from KGlobal::ref() and KGlobal::unref() to QEventLoopLocker, 
 though quitting one window closes all windows, not sure if that's expected or 
 not.
 
 
 Thanks,
 
 Jeremy Whiting
 




Review Request 120580: [OS X] make KWalletD::connectToScreenSaver a stub function

2014-10-14 Thread René J . V . Bertin

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

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


Repository: kde-runtime


Description
---

OS X doesn't use an X11-based screensaver, and KDE/OS X is not based on X11.
Until now, kwalletd was built with a MacPorts patch that simply excluded the 
connectToScreenSaver function from kwalletd.cpp as well as from kwalletd.h 
because the moc preprocessor doesn't respect the `#ifdef Q_WS_X11` conditional 
around the function prototype.

This patch removes the conditional code from the header (leaving it only around 
the `*screensaver` instance variable, and makes the function a stub on OS X.

I'd be interested to know the reason for connecting to the screensaver. If it's 
for idle timing I might be able to port replacement functionality already 
committed to ktimetracker for that purpose.


Diffs
-

  kwalletd/kwalletd.cpp 62fe2b6 

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


Testing
---

on OS X 10.6.8 .


Thanks,

René J.V. Bertin



Re: Review Request 120580: [OS X] make KWalletD::connectToScreenSaver a stub function

2014-10-14 Thread René J . V . Bertin

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

(Updated Oct. 14, 2014, 1:58 p.m.)


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


Repository: kde-runtime


Description
---

OS X doesn't use an X11-based screensaver, and KDE/OS X is not based on X11.
Until now, kwalletd was built with a MacPorts patch that simply excluded the 
connectToScreenSaver function from kwalletd.cpp as well as from kwalletd.h 
because the moc preprocessor doesn't respect the `#ifdef Q_WS_X11` conditional 
around the function prototype.

This patch removes the conditional code from the header (leaving it only around 
the `*screensaver` instance variable, and makes the function a stub on OS X.

I'd be interested to know the reason for connecting to the screensaver. If it's 
for idle timing I might be able to port replacement functionality already 
committed to ktimetracker for that purpose.


Diffs (updated)
-

  kwalletd/kwalletd.h 98651a5 
  kwalletd/kwalletd.cpp 62fe2b6 

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


Testing
---

on OS X 10.6.8 .


Thanks,

René J.V. Bertin



Re: Review Request 120573: [OS X] make KDE's trash use the OS X trash

2014-10-14 Thread René J . V . Bertin

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

(Updated Oct. 14, 2014, 1:59 p.m.)


Review request for KDE Software on Mac OS X, KDE Runtime and David Faure.


Changes
---

Adds an indication that the wastebin uses an OS X backend to kcm_trash


Repository: kde-runtime


Description
---

KDE on OS X does not handle the desktop session (no Plasma) nor can it rely 
on XDG to obtain the proper paths to use for something like the trash. As a 
result, all applications that propose to move things they manage to the 
wastebin (Dolphin, but also digiKam) will store those items in a place that has 
no particular meaning on OS X, and that will thus tend to fill up.

OS X stores trash in one of several locations. Files trashed from the boot 
volume (and/or the volume containing $HOME, I don't actually know that) end up 
in `~/.Trash`. Files deleted from other volumes end up in 
`/Volumes/volName/.Trashes/uid`, where volName is the volume name (regardless 
whether it's an external or a remote drive; only mounted NFS shares are handled 
differently) and uid the numerical user id. Permissions on `.Trashes` are the 
same as those expected by KDE.

The kio_trash kioslave appears to support several actual trash directory 
locations, just like OS X. `TrashImpl::init()` creates a standard trash in 
`~/.local/share/Trash` (at least under OS X) but also 
`TrashImpl::trashForMountPoint()` that is used in cases I have not yet 
encountered.

On OS X, my modified `TrashImpl::init()` sets the standard trash directory to 
`~/.Trash/KDE.trash` and will create the `files` and `info` subdirectories as 
required, because they will of course be deleted when the user empties the OS X 
trash. `TrashImpl::fileRemoved()` has been modified to call a new function, 
`deleteEmptyTrashInfraStructure` to delete the KDE trash's internal 
infrastructure when the wastebin is empty so that OS X also sees the trash as 
emptied. (Since implementing `deleteEmptyTrashInfraStructure` this feature 
actually works, as expected as far as I can tell).

Remains to be done:
- determine in what cases `trashForMountPoint()` is used, and finish the 
modifications for it to use `/.Trashes/uid/KDE.trash`


Diffs (updated)
-

  kioslave/trash/kcmtrash.cpp f4811fd 
  kioslave/trash/trashimpl.h bc68723 
  kioslave/trash/trashimpl.cpp 30ee05b 

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


Testing
---

On OS X 10.6.8 with kdelibs and kde-runtime git/4.14, using Dolphin. Tested 
actions are
- move items to wastebin from $HOME and a directory on a different volume
- restore items to both places
- empty wastebin through Dolphin
- empty OS X trashcan


Thanks,

René J.V. Bertin



Gwenview maintainership

2014-10-14 Thread Aurélien Gâteau
For the past few months, I haven't been doing any work on KDE projects,
and I don't see this changing for now. It's time for me to step down
from the projects I maintain. This includes Gwenview. Awesome David
Edmundson did the grunt work of porting it to KDE Frameworks 5 (Thanks
again David!), but he already has too much on his plate: he can't take
over Gwenview.

I am therefore looking for a new maintainer. If you are interested,
please get in touch. I would be more than happy to guide you through the
code to get you started. Some parts of Gwenview user interface (as well
as inner plumbing) are getting a bit dated, so it would be wonderful if
you could get in touch with the VDG to give Gwenview the visual refresh
it deserves.

Aurélien


Re: Review Request 120287: [OS X] make kde-workspace build

2014-10-14 Thread Martin Gräßlin

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


I'm not understanding the changes in Plasma Netbook. Why do you want the 
Netbook shell on OSX while on the other side you disabled the desktop shell? 
AFAIK you cannot replace the shell of OSX, so having Netbook sounds pretty 
useless to me.

- Martin Gräßlin


On Oct. 14, 2014, 6:06 p.m., René J.V. Bertin wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://git.reviewboard.kde.org/r/120287/
 ---
 
 (Updated Oct. 14, 2014, 6:06 p.m.)
 
 
 Review request for KDE Software on Mac OS X and kde-workspace.
 
 
 Repository: kde-workspace
 
 
 Description
 ---
 
 A few rather straightforward patches to make the relevant bits of KDE4's 
 kde-workspace build and function on OS X.
 The main interest is having the systemsettings control panel to control the 
 various relevant KDE settings among which desktop search, fonts, colours and 
 even style.
 The oxygen style builds and looks good but shows some updating glitches due 
 to compositing.
 
 I'm submitting this patch partly in hope it may be useful in bringing 
 kf5-workspace to OS X, one day.
 
 
 Diffs
 -
 
   CMakeLists.txt df8a1f7 
   kcontrol/CMakeLists.txt fc666b1 
   kcontrol/krdb/krdb.cpp 36fc99c 
   kcontrol/style/CMakeLists.txt d832b20 
   libs/CMakeLists.txt c0576fe 
   plasma/CMakeLists.txt 199dbb0 
   plasma/generic/shells/plasma-windowed/plasmaapp.cpp dbdff47 
   plasma/netbook/CMakeLists.txt 1eff685 
   plasma/netbook/containments/CMakeLists.txt c96a688 
   plasma/desktop/CMakeLists.txt 2de78dd 
   plasma/desktop/applets/CMakeLists.txt 6f80cec 
   plasma/generic/CMakeLists.txt cfaf14f 
   plasma/generic/applets/CMakeLists.txt 2b888ee 
   plasma/generic/dataengines/CMakeLists.txt d240683 
   plasma/generic/runners/CMakeLists.txt 6831ac0 
   plasma/generic/shells/plasma-windowed/CMakeLists.txt 86b7770 
   plasma/generic/shells/plasma-windowed/Info.plist.template PRE-CREATION 
 
 Diff: https://git.reviewboard.kde.org/r/120287/diff/
 
 
 Testing
 ---
 
 On OS X 10.6.8 and 10.9.4 with KDE/MacPorts (4.12.5 and more recently kdelibs 
 git/master, 4.14.1).
 
 
 File Attachments
 
 
 copy of the diff file saved locally, which had no tabs when I uploaded it. 
 Checksum: 3989cdd46af3c891e570974d66c330403dcd41c4ee5e17a372fa385080cbabd1 
   
 https://git.reviewboard.kde.org/media/uploaded/files/2014/09/20/b212730f-6258-4277-851c-226bc0673aa1__patchreview-20140920.patch
 
 
 Thanks,
 
 René J.V. Bertin
 




Re: Review Request 120287: [OS X] make kde-workspace build

2014-10-14 Thread Martin Gräßlin


 On Okt. 14, 2014, 6:38 nachm., Martin Gräßlin wrote:
  I'm not understanding the changes in Plasma Netbook. Why do you want the 
  Netbook shell on OSX while on the other side you disabled the desktop 
  shell? AFAIK you cannot replace the shell of OSX, so having Netbook sounds 
  pretty useless to me.
 
 René J.V. Bertin wrote:
 The point is not to have the shell, but to have access to plasmoids via 
 plasma-windowed (or plasmoid-viewer if that application is still around and 
 functional).
 I've tried to explain that I have made a rather coarse selection 
 (everything also included in MS Windows builds and that actually builds) 
 rather than hand-picking only those components that would have a potential 
 use. Doing so I indeed noticed that the desktop shell was excluded on Win32 
 but not the netbook shell. It didn't take me long to realise that the netbook 
 shell is different enough from the usual desktop paradigm to be of interest 
 to some users, to the extent that it can be made to function in a rooted, 
 normal window of course.
 I am of course open to feedback concerning the components that can be 
 removed from the build without effect on components that do have a use.
 
 If I may think aloud a little bit:
 Netbook or Desktop shells ... they open (fullscreen) windows in practice, 
 right? If so, there could be an (academic?) interest in supporting them but 
 with a regular window, allowing the user to set up a sort of MDI version of a 
 desktop shell with goodies that would give a more coherent experience than 
 running those same goodies individually on the OS X desktop. One could also 
 think of a shell that only serves to host panels and widgets, not unlike 
 Yahoo! Widgets (http://en.wikipedia.org/wiki/Yahoo!_Widgets)

 Netbook or Desktop shells ... they open (fullscreen) windows in practice, 
 right?

no, they open desktop windows.

 If so, there could be an (academic?) interest in supporting them but with a 
 regular window

no, that's what plasma-windowed is for. And I'm certainly not giving a +1 for 
the rather big changes to netbook shell if the only need is on an academic 
scale ;-)


- Martin


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


On Okt. 14, 2014, 6:06 nachm., René J.V. Bertin wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://git.reviewboard.kde.org/r/120287/
 ---
 
 (Updated Okt. 14, 2014, 6:06 nachm.)
 
 
 Review request for KDE Software on Mac OS X and kde-workspace.
 
 
 Repository: kde-workspace
 
 
 Description
 ---
 
 A few rather straightforward patches to make the relevant bits of KDE4's 
 kde-workspace build and function on OS X.
 The main interest is having the systemsettings control panel to control the 
 various relevant KDE settings among which desktop search, fonts, colours and 
 even style.
 The oxygen style builds and looks good but shows some updating glitches due 
 to compositing.
 
 I'm submitting this patch partly in hope it may be useful in bringing 
 kf5-workspace to OS X, one day.
 
 
 Diffs
 -
 
   CMakeLists.txt df8a1f7 
   kcontrol/CMakeLists.txt fc666b1 
   kcontrol/krdb/krdb.cpp 36fc99c 
   kcontrol/style/CMakeLists.txt d832b20 
   libs/CMakeLists.txt c0576fe 
   plasma/CMakeLists.txt 199dbb0 
   plasma/generic/shells/plasma-windowed/plasmaapp.cpp dbdff47 
   plasma/netbook/CMakeLists.txt 1eff685 
   plasma/netbook/containments/CMakeLists.txt c96a688 
   plasma/desktop/CMakeLists.txt 2de78dd 
   plasma/desktop/applets/CMakeLists.txt 6f80cec 
   plasma/generic/CMakeLists.txt cfaf14f 
   plasma/generic/applets/CMakeLists.txt 2b888ee 
   plasma/generic/dataengines/CMakeLists.txt d240683 
   plasma/generic/runners/CMakeLists.txt 6831ac0 
   plasma/generic/shells/plasma-windowed/CMakeLists.txt 86b7770 
   plasma/generic/shells/plasma-windowed/Info.plist.template PRE-CREATION 
 
 Diff: https://git.reviewboard.kde.org/r/120287/diff/
 
 
 Testing
 ---
 
 On OS X 10.6.8 and 10.9.4 with KDE/MacPorts (4.12.5 and more recently kdelibs 
 git/master, 4.14.1).
 
 
 File Attachments
 
 
 copy of the diff file saved locally, which had no tabs when I uploaded it. 
 Checksum: 3989cdd46af3c891e570974d66c330403dcd41c4ee5e17a372fa385080cbabd1 
   
 https://git.reviewboard.kde.org/media/uploaded/files/2014/09/20/b212730f-6258-4277-851c-226bc0673aa1__patchreview-20140920.patch
 
 
 Thanks,
 
 René J.V. Bertin
 




Re: Review Request 120287: [OS X] make kde-workspace build

2014-10-14 Thread René J . V . Bertin


 On Oct. 14, 2014, 6:38 p.m., Martin Gräßlin wrote:
  I'm not understanding the changes in Plasma Netbook. Why do you want the 
  Netbook shell on OSX while on the other side you disabled the desktop 
  shell? AFAIK you cannot replace the shell of OSX, so having Netbook sounds 
  pretty useless to me.
 
 René J.V. Bertin wrote:
 The point is not to have the shell, but to have access to plasmoids via 
 plasma-windowed (or plasmoid-viewer if that application is still around and 
 functional).
 I've tried to explain that I have made a rather coarse selection 
 (everything also included in MS Windows builds and that actually builds) 
 rather than hand-picking only those components that would have a potential 
 use. Doing so I indeed noticed that the desktop shell was excluded on Win32 
 but not the netbook shell. It didn't take me long to realise that the netbook 
 shell is different enough from the usual desktop paradigm to be of interest 
 to some users, to the extent that it can be made to function in a rooted, 
 normal window of course.
 I am of course open to feedback concerning the components that can be 
 removed from the build without effect on components that do have a use.
 
 If I may think aloud a little bit:
 Netbook or Desktop shells ... they open (fullscreen) windows in practice, 
 right? If so, there could be an (academic?) interest in supporting them but 
 with a regular window, allowing the user to set up a sort of MDI version of a 
 desktop shell with goodies that would give a more coherent experience than 
 running those same goodies individually on the OS X desktop. One could also 
 think of a shell that only serves to host panels and widgets, not unlike 
 Yahoo! Widgets (http://en.wikipedia.org/wiki/Yahoo!_Widgets)
 
 Martin Gräßlin wrote:
  Netbook or Desktop shells ... they open (fullscreen) windows in 
 practice, right?
 
 no, they open desktop windows.
 
  If so, there could be an (academic?) interest in supporting them but 
 with a regular window
 
 no, that's what plasma-windowed is for. And I'm certainly not giving a +1 
 for the rather big changes to netbook shell if the only need is on an 
 academic scale ;-)

I wasn't about to start hacking to pursue any of these ideas, and certainly not 
in KDE4. We'll see if and when we get to KF5 on OS X but in the meantime the 
thought is out there. In case there are KDE developers outside of the kde-mac 
kernel who'd appreciate to see part of the power of a KDE desktop available 
beyond Linux and other Unix/X11 systems.

Now that you mention plasma-windowed: I *would* like to get that utility to be 
able to run in multiple instances! Whatever good reasons there might be on *n*x 
for it to be a KUniqueApplication, on OS X there's a good reason for it not to 
be ...


- René J.V.


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


On Oct. 14, 2014, 6:06 p.m., René J.V. Bertin wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://git.reviewboard.kde.org/r/120287/
 ---
 
 (Updated Oct. 14, 2014, 6:06 p.m.)
 
 
 Review request for KDE Software on Mac OS X and kde-workspace.
 
 
 Repository: kde-workspace
 
 
 Description
 ---
 
 A few rather straightforward patches to make the relevant bits of KDE4's 
 kde-workspace build and function on OS X.
 The main interest is having the systemsettings control panel to control the 
 various relevant KDE settings among which desktop search, fonts, colours and 
 even style.
 The oxygen style builds and looks good but shows some updating glitches due 
 to compositing.
 
 I'm submitting this patch partly in hope it may be useful in bringing 
 kf5-workspace to OS X, one day.
 
 
 Diffs
 -
 
   CMakeLists.txt df8a1f7 
   kcontrol/CMakeLists.txt fc666b1 
   kcontrol/krdb/krdb.cpp 36fc99c 
   kcontrol/style/CMakeLists.txt d832b20 
   libs/CMakeLists.txt c0576fe 
   plasma/CMakeLists.txt 199dbb0 
   plasma/generic/shells/plasma-windowed/plasmaapp.cpp dbdff47 
   plasma/netbook/CMakeLists.txt 1eff685 
   plasma/netbook/containments/CMakeLists.txt c96a688 
   plasma/desktop/CMakeLists.txt 2de78dd 
   plasma/desktop/applets/CMakeLists.txt 6f80cec 
   plasma/generic/CMakeLists.txt cfaf14f 
   plasma/generic/applets/CMakeLists.txt 2b888ee 
   plasma/generic/dataengines/CMakeLists.txt d240683 
   plasma/generic/runners/CMakeLists.txt 6831ac0 
   plasma/generic/shells/plasma-windowed/CMakeLists.txt 86b7770 
   plasma/generic/shells/plasma-windowed/Info.plist.template PRE-CREATION 
 
 Diff: https://git.reviewboard.kde.org/r/120287/diff/
 
 
 Testing
 ---
 
 On OS X 10.6.8 and 10.9.4 with KDE/MacPorts (4.12.5 and more recently kdelibs 
 

Re: Review Request 120580: [OS X] make KWalletD::connectToScreenSaver a stub function

2014-10-14 Thread Thomas Lübking

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

Ship it!


I don't know the code at all, but the #ifdef'd Q_SLOT declaration is pointless 
and adding a slot is ABI stable, so this is fine to push. (Maybe wait 24h to 
see whether someone more familiar with the code shows up)

- Thomas Lübking


On Okt. 14, 2014, 11:58 vorm., René J.V. Bertin wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://git.reviewboard.kde.org/r/120580/
 ---
 
 (Updated Okt. 14, 2014, 11:58 vorm.)
 
 
 Review request for KDE Software on Mac OS X and KDE Runtime.
 
 
 Repository: kde-runtime
 
 
 Description
 ---
 
 OS X doesn't use an X11-based screensaver, and KDE/OS X is not based on X11.
 Until now, kwalletd was built with a MacPorts patch that simply excluded the 
 connectToScreenSaver function from kwalletd.cpp as well as from kwalletd.h 
 because the moc preprocessor doesn't respect the `#ifdef Q_WS_X11` 
 conditional around the function prototype.
 
 This patch removes the conditional code from the header (leaving it only 
 around the `*screensaver` instance variable, and makes the function a stub on 
 OS X.
 
 I'd be interested to know the reason for connecting to the screensaver. If 
 it's for idle timing I might be able to port replacement functionality 
 already committed to ktimetracker for that purpose.
 
 
 Diffs
 -
 
   kwalletd/kwalletd.h 98651a5 
   kwalletd/kwalletd.cpp 62fe2b6 
 
 Diff: https://git.reviewboard.kde.org/r/120580/diff/
 
 
 Testing
 ---
 
 on OS X 10.6.8 .
 
 
 Thanks,
 
 René J.V. Bertin
 




Re: Gwenview maintainership

2014-10-14 Thread Lukáš Tinkl

Dne 14.10.2014 v 17:51 Aurélien Gâteau napsal(a):

For the past few months, I haven't been doing any work on KDE projects,
and I don't see this changing for now. It's time for me to step down
from the projects I maintain. This includes Gwenview. Awesome David
Edmundson did the grunt work of porting it to KDE Frameworks 5 (Thanks
again David!), but he already has too much on his plate: he can't take
over Gwenview.

I am therefore looking for a new maintainer. If you are interested,
please get in touch. I would be more than happy to guide you through the
code to get you started. Some parts of Gwenview user interface (as well
as inner plumbing) are getting a bit dated, so it would be wonderful if
you could get in touch with the VDG to give Gwenview the visual refresh
it deserves.

Aurélien



Hi,
as I did quite some fixes recently, I'd be happy to take over the 
maintainership from you. Thanks for all the hard work, Gwenview is fun 
to hack on!


--
Lukáš Tinkl lu...@kde.org


Re: Review Request 120573: [OS X] make KDE's trash use the OS X trash

2014-10-14 Thread René J . V . Bertin


 On Oct. 14, 2014, 9:35 p.m., Thomas Lübking wrote:
  kioslave/trash/kcmtrash.cpp, line 220
  https://git.reviewboard.kde.org/r/120573/diff/6/?file=318518#file318518line220
 
  don't know about the exotic OS policy on this, but changes to i18n 
  strings need to happen for new minors only (unless you get an exception), 
  ie. for 4.15

Would it be better if I made this a regular string, with something like a // 
TODO: internationalise ?


 On Oct. 14, 2014, 9:35 p.m., Thomas Lübking wrote:
  kioslave/trash/trashimpl.cpp, line 816
  https://git.reviewboard.kde.org/r/120573/diff/6/?file=318520#file318520line816
 
  I don't understand why this cleanup is required on osx, but not other 
  systems?

On other systems, there's only a single trash at a time, and it's rendered to 
the user via kde-runtime. 
Here we're putting that KDE wastebin inside another one - think of it as an 
ashtray inside a larger garbage can. KDE only knows the ashtray, but OS X sees 
the whole garbage ... so in order to play nice KDE has to get rid of the 
ashtray too, each time it empties it.

I noticed that there's a win32 backend which seems to use a native API 
interfaced to TrashImpl. I presume that something similar could be done on OS X 
(haven't checked) and it's almost certain that I could replace the `files + 
info` infrastructure by something that uses extended file attributes (resource 
forks no longer exist...) but TBH I'd rather use the simpler route implemented 
here. Besides, suppose a user does go into the Finder's Trash to restore a 
binned file, any trash info stored as a file attribute will remain attached, 
which isn't very proper.


- René J.V.


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


On Oct. 14, 2014, 1:59 p.m., René J.V. Bertin wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://git.reviewboard.kde.org/r/120573/
 ---
 
 (Updated Oct. 14, 2014, 1:59 p.m.)
 
 
 Review request for KDE Software on Mac OS X, KDE Runtime and David Faure.
 
 
 Repository: kde-runtime
 
 
 Description
 ---
 
 KDE on OS X does not handle the desktop session (no Plasma) nor can it rely 
 on XDG to obtain the proper paths to use for something like the trash. As a 
 result, all applications that propose to move things they manage to the 
 wastebin (Dolphin, but also digiKam) will store those items in a place that 
 has no particular meaning on OS X, and that will thus tend to fill up.
 
 OS X stores trash in one of several locations. Files trashed from the boot 
 volume (and/or the volume containing $HOME, I don't actually know that) end 
 up in `~/.Trash`. Files deleted from other volumes end up in 
 `/Volumes/volName/.Trashes/uid`, where volName is the volume name (regardless 
 whether it's an external or a remote drive; only mounted NFS shares are 
 handled differently) and uid the numerical user id. Permissions on `.Trashes` 
 are the same as those expected by KDE.
 
 The kio_trash kioslave appears to support several actual trash directory 
 locations, just like OS X. `TrashImpl::init()` creates a standard trash in 
 `~/.local/share/Trash` (at least under OS X) but also 
 `TrashImpl::trashForMountPoint()` that is used in cases I have not yet 
 encountered.
 
 On OS X, my modified `TrashImpl::init()` sets the standard trash directory to 
 `~/.Trash/KDE.trash` and will create the `files` and `info` subdirectories as 
 required, because they will of course be deleted when the user empties the OS 
 X trash. `TrashImpl::fileRemoved()` has been modified to call a new function, 
 `deleteEmptyTrashInfraStructure` to delete the KDE trash's internal 
 infrastructure when the wastebin is empty so that OS X also sees the trash as 
 emptied. (Since implementing `deleteEmptyTrashInfraStructure` this feature 
 actually works, as expected as far as I can tell).
 
 Remains to be done:
 - determine in what cases `trashForMountPoint()` is used, and finish the 
 modifications for it to use `/.Trashes/uid/KDE.trash`
 
 
 Diffs
 -
 
   kioslave/trash/kcmtrash.cpp f4811fd 
   kioslave/trash/trashimpl.h bc68723 
   kioslave/trash/trashimpl.cpp 30ee05b 
 
 Diff: https://git.reviewboard.kde.org/r/120573/diff/
 
 
 Testing
 ---
 
 On OS X 10.6.8 with kdelibs and kde-runtime git/4.14, using Dolphin. Tested 
 actions are
 - move items to wastebin from $HOME and a directory on a different volume
 - restore items to both places
 - empty wastebin through Dolphin
 - empty OS X trashcan
 
 
 Thanks,
 
 René J.V. Bertin
 




Re: Gwenview maintainership

2014-10-14 Thread Burkhard Lück
Am Dienstag, 14. Oktober 2014, 22:10:19 schrieb Lukáš Tinkl:
 Dne 14.10.2014 v 17:51 Aurélien Gâteau napsal(a):
  For the past few months, I haven't been doing any work on KDE projects,
  and I don't see this changing for now. It's time for me to step down
  from the projects I maintain. This includes Gwenview. Awesome David
  Edmundson did the grunt work of porting it to KDE Frameworks 5 (Thanks
  again David!), but he already has too much on his plate: he can't take
  over Gwenview.
  
  I am therefore looking for a new maintainer. If you are interested,
  please get in touch. I would be more than happy to guide you through the
  code to get you started. Some parts of Gwenview user interface (as well
  as inner plumbing) are getting a bit dated, so it would be wonderful if
  you could get in touch with the VDG to give Gwenview the visual refresh
  it deserves.
  
  Aurélien
 
 Hi,
 as I did quite some fixes recently, I'd be happy to take over the
 maintainership from you. Thanks for all the hard work, Gwenview is fun
 to hack on!

And it is fun to use / important for my daily use cases

So thanks to Aurélien + Lukáš

-- 
Burkhard Lück



Re: Review Request 120554: Initial frameworks port of kompare

2014-10-14 Thread Jeremy Whiting

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

(Updated Oct. 14, 2014, 2:53 p.m.)


Review request for kdelibs and Vavelin Kevin.


Changes
---

Updated quit to call close() which deletes the QEventLoopLocker for us. All 
file-quit operations now close just the window chosen. Not sure if 
QEventLoopLocker is even needed anymore tbh.


Repository: kompare


Description
---

I spent a bit of time porting kompare to kf5. It builds and runs and compares 
files and folders but I'm pretty sure I missed something. 

I'll reread my changes also but wanted to get this out there to be played with 
also.


Diffs (updated)
-

  libdialogpages/viewpage.cpp e26d72843587cf4ed60f0d7dcde51ec4f19aad29 
  libdialogpages/viewsettings.h 305e934815175c0fc60c8a045070e48f7b932935 
  main.cpp ac68e2421c1f02460e732eb4dc7f79036df9db2e 
  pics/CMakeLists.txt 512f6e8cad202bc592c08531654754bd311fcb5e 
  pics/hi128-app-kompare.png  
  pics/hi16-app-kompare.png  
  pics/hi22-app-kompare.png  
  pics/hi32-app-kompare.png  
  pics/hi48-app-kompare.png  
  pics/hisc-app-kompare.svgz  
  libdialogpages/pagebase.cpp 4aa33d7d5b8eb6779bb96e5533d0f11235c30aac 
  libdialogpages/filespage.cpp 417fbd12b0f7622da23d0da0e934476d142df149 
  libdialogpages/CMakeLists.txt 22906650d1f0f8fb0b5d8d3d272f09d44bf7408c 
  libdialogpages/diffpage.cpp 94221ca8badbd1773ff48071fd558bd111750e47 
  komparepart/komparesaveoptionswidget.cpp 
06530d85159305fc1330f495a1c52b0155e45e37 
  komparepart/komparesplitter.h 11a344f29f46d68ca5418c770bd5e502d527e0fe 
  komparepart/komparesplitter.cpp 2848f881992bae0b0e7141c1f6c47a2239211844 
  komparepart/kompareview.h 93ea0644a590c56e600e466a69bf227dc93328b1 
  kompareurldialog.cpp 561dd4518dda0be64198beff56e986da4294fe2b 
  komparenavtreepart/CMakeLists.txt da52bc7d0d9f032d80f6f2257dbbed1f6fb0e81a 
  komparenavtreepart/komparenavtreepart.h 
eb08329be477febe93b4ca7a8c787656abbfc68f 
  komparenavtreepart/komparenavtreepart.cpp 
d3bdc93ddaf28e026b7c1847b8d4f6dbc46125ee 
  komparepart/CMakeLists.txt ee83458a3034c3fb873629d650efe5668955900b 
  komparepart/kompare_part.h 0c4d3dd40ca32e07b2402280539d03f15cfc 
  komparepart/kompare_part.cpp 08df1dc0985391908eb81da9c4cfdd0836cd4b23 
  komparepart/kompareconnectwidget.h 03eb746c24dc3899b64d3907ae21e0de656e369f 
  komparepart/kompareconnectwidget.cpp 2a8cb920280f2b42ab09e7962a441529b8cdfc0c 
  komparepart/komparelistview.cpp b2935c917541984532814d301b6a7f5bdd661c72 
  komparepart/kompareprefdlg.cpp 0b18696acf270cf5a0351312aa3ffe13eff9b9e6 
  komparepart/komparesaveoptionswidget.h 
9c49815b1b95b9448eb5fccda35e4c7c7fb1e2f1 
  kompare_shell.h de099ffbcc92a22a4374ad6cfca0bccc6b0e97bc 
  kompare_shell.cpp 9d22085780fbbffcb9b480cbb16c30e73c0ba71e 
  CMakeLists.txt 86e4504ad3ae06519cbfaaf35781238f5f234857 
  doc/CMakeLists.txt 06d898738aabdfc947e89de848e2fbe903d5e6cc 
  interfaces/CMakeLists.txt 4bb0c6c53e8b995f1c7350cd02268e2e05ddb38a 
  interfaces/kompareinterface.h a28d209b058fb06cc970e6ba3538ace721319be5 

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


Testing
---

It builds, runs and seems to wok ok comparing files and folders. The 
QFileDialog it uses wasn't showing files I expected to see though, may need to 
play with the filters etc.

Also ported from KGlobal::ref() and KGlobal::unref() to QEventLoopLocker, 
though quitting one window closes all windows, not sure if that's expected or 
not.


Thanks,

Jeremy Whiting



Re: Review Request 120573: [OS X] make KDE's trash use the OS X trash

2014-10-14 Thread David Faure

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


Nice! Just some comments.


kioslave/trash/trashimpl.cpp
https://git.reviewboard.kde.org/r/120573/#comment47678

Shouldn't this return false like the other blocks?

And then I would swap the if and else blocks, removing the '!' in the 
condition... so that all if() blocks follow the same pattern.

I see that the code below tries to cope with the case where we couldn't 
create KDE.trash ... but then we shouldn't set any error code, if we fallback 
to another solution.

However I'm not sure I understand why this could happen though. Why 
wouldn't we be able to create KDE.trash but we would be able to create 
info? Well, this would be the case if KDE.trash existed already and was owned 
by another user, but then the same could happen with info...



kioslave/trash/trashimpl.cpp
https://git.reviewboard.kde.org/r/120573/#comment47679

this comment doesn't match the code in the macro, which merely concatenates 
two strings, it doesn't check anything nor create anything.

On that note, macros expanding to code are not great... functions are much 
better.

Or in this case, it's a two-liner used twice, I would just inline 
(duplicate) the code.



kioslave/trash/trashimpl.cpp
https://git.reviewboard.kde.org/r/120573/#comment47680

same as above, why do we want this fallback?



kioslave/trash/trashimpl.cpp
https://git.reviewboard.kde.org/r/120573/#comment47681

Minor: I'd put it.value() into a const QString trashDir local variable, to 
avoid repeating it 4 times, and to improve readability.



kioslave/trash/trashimpl.cpp
https://git.reviewboard.kde.org/r/120573/#comment47682

deleteEmptyTrashInfraStructure is implemented on all OSes, but only called 
on Mac, which seems a bit inconsistent.

I looked at the trash spec again, and given the special permissions 
required on trash dirs in other partitions (DIR/.Trash or DIR/.Trash-$uid), I 
would feel safer if we didn't delete trash infrastructure.
So I would make the entire method OSX only.

BTW you should use Q_OS_OSX instead of Q_OS_MAC. iOS for sure doesn't work 
this way.



kioslave/trash/trashimpl.cpp
https://git.reviewboard.kde.org/r/120573/#comment47686

Damn, if only we had known, we could have made the XDG spec closer to the 
OSX implementation just by adding es :-)



kioslave/trash/trashimpl.cpp
https://git.reviewboard.kde.org/r/120573/#comment47683

Not much reason to have an ifdef mac around a kDebug.

Remove it all, or enable the kDebug everywhere.



kioslave/trash/trashimpl.cpp
https://git.reviewboard.kde.org/r/120573/#comment47684

same



kioslave/trash/trashimpl.cpp
https://git.reviewboard.kde.org/r/120573/#comment47685

such a debug statement is more useful if it prints out the input to the 
method, i.e. topdir.


- David Faure


On Oct. 14, 2014, 11:59 a.m., René J.V. Bertin wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://git.reviewboard.kde.org/r/120573/
 ---
 
 (Updated Oct. 14, 2014, 11:59 a.m.)
 
 
 Review request for KDE Software on Mac OS X, KDE Runtime and David Faure.
 
 
 Repository: kde-runtime
 
 
 Description
 ---
 
 KDE on OS X does not handle the desktop session (no Plasma) nor can it rely 
 on XDG to obtain the proper paths to use for something like the trash. As a 
 result, all applications that propose to move things they manage to the 
 wastebin (Dolphin, but also digiKam) will store those items in a place that 
 has no particular meaning on OS X, and that will thus tend to fill up.
 
 OS X stores trash in one of several locations. Files trashed from the boot 
 volume (and/or the volume containing $HOME, I don't actually know that) end 
 up in `~/.Trash`. Files deleted from other volumes end up in 
 `/Volumes/volName/.Trashes/uid`, where volName is the volume name (regardless 
 whether it's an external or a remote drive; only mounted NFS shares are 
 handled differently) and uid the numerical user id. Permissions on `.Trashes` 
 are the same as those expected by KDE.
 
 The kio_trash kioslave appears to support several actual trash directory 
 locations, just like OS X. `TrashImpl::init()` creates a standard trash in 
 `~/.local/share/Trash` (at least under OS X) but also 
 `TrashImpl::trashForMountPoint()` that is used in cases I have not yet 
 encountered.
 
 On OS X, my modified `TrashImpl::init()` sets the standard trash directory to 
 `~/.Trash/KDE.trash` and will create the `files` and `info` subdirectories as 
 required, because they will of course be deleted when the user empties the OS 
 X trash. `TrashImpl::fileRemoved()` has been 

Re: Review Request 120573: [OS X] make KDE's trash use the OS X trash

2014-10-14 Thread David Faure


 On Oct. 14, 2014, 7:35 p.m., Thomas Lübking wrote:
  kioslave/trash/kcmtrash.cpp, line 220
  https://git.reviewboard.kde.org/r/120573/diff/6/?file=318518#file318518line220
 
  don't know about the exotic OS policy on this, but changes to i18n 
  strings need to happen for new minors only (unless you get an exception), 
  ie. for 4.15
 
 René J.V. Bertin wrote:
 Would it be better if I made this a regular string, with something like 
 a // TODO: internationalise ?

No that's worse, it doesn't even leave a chance for the translators to 
translate it.

Since this is mac only I wouldn't worry too much about it though.


- David


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


On Oct. 14, 2014, 11:59 a.m., René J.V. Bertin wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://git.reviewboard.kde.org/r/120573/
 ---
 
 (Updated Oct. 14, 2014, 11:59 a.m.)
 
 
 Review request for KDE Software on Mac OS X, KDE Runtime and David Faure.
 
 
 Repository: kde-runtime
 
 
 Description
 ---
 
 KDE on OS X does not handle the desktop session (no Plasma) nor can it rely 
 on XDG to obtain the proper paths to use for something like the trash. As a 
 result, all applications that propose to move things they manage to the 
 wastebin (Dolphin, but also digiKam) will store those items in a place that 
 has no particular meaning on OS X, and that will thus tend to fill up.
 
 OS X stores trash in one of several locations. Files trashed from the boot 
 volume (and/or the volume containing $HOME, I don't actually know that) end 
 up in `~/.Trash`. Files deleted from other volumes end up in 
 `/Volumes/volName/.Trashes/uid`, where volName is the volume name (regardless 
 whether it's an external or a remote drive; only mounted NFS shares are 
 handled differently) and uid the numerical user id. Permissions on `.Trashes` 
 are the same as those expected by KDE.
 
 The kio_trash kioslave appears to support several actual trash directory 
 locations, just like OS X. `TrashImpl::init()` creates a standard trash in 
 `~/.local/share/Trash` (at least under OS X) but also 
 `TrashImpl::trashForMountPoint()` that is used in cases I have not yet 
 encountered.
 
 On OS X, my modified `TrashImpl::init()` sets the standard trash directory to 
 `~/.Trash/KDE.trash` and will create the `files` and `info` subdirectories as 
 required, because they will of course be deleted when the user empties the OS 
 X trash. `TrashImpl::fileRemoved()` has been modified to call a new function, 
 `deleteEmptyTrashInfraStructure` to delete the KDE trash's internal 
 infrastructure when the wastebin is empty so that OS X also sees the trash as 
 emptied. (Since implementing `deleteEmptyTrashInfraStructure` this feature 
 actually works, as expected as far as I can tell).
 
 Remains to be done:
 - determine in what cases `trashForMountPoint()` is used, and finish the 
 modifications for it to use `/.Trashes/uid/KDE.trash`
 
 
 Diffs
 -
 
   kioslave/trash/kcmtrash.cpp f4811fd 
   kioslave/trash/trashimpl.h bc68723 
   kioslave/trash/trashimpl.cpp 30ee05b 
 
 Diff: https://git.reviewboard.kde.org/r/120573/diff/
 
 
 Testing
 ---
 
 On OS X 10.6.8 with kdelibs and kde-runtime git/4.14, using Dolphin. Tested 
 actions are
 - move items to wastebin from $HOME and a directory on a different volume
 - restore items to both places
 - empty wastebin through Dolphin
 - empty OS X trashcan
 
 
 Thanks,
 
 René J.V. Bertin
 




[UPDATE] kdepimlibs Coverity Scan Report, Oct 14 2014

2014-10-14 Thread Allen Winter
Howdy,

Attached is the Coverity Scan report for kdepimlibs 4.14 as of today.
You might feel like fixing some of the issues.

I filtered out the QtCore and (deprecated) kcal library from this report.

Let me know if you find false positives or stuff we can ignore (like in test 
programs).

CID
Type
Impact
Category
File
Function

1245732
Uninitialized scalar variable
High
Uninitialized variables
/data/mykde/src/KDE/kdepimlibs/kalarmcal/kaevent.cpp
readAlarms

1167377
Non-virtual destructor
High
Resource leaks
/data/mykde/src/KDE/kdepimlibs/kldap/ldapurl.cpp
~LdapUrl

1167326
Resource leak
High
Resource leaks
/data/mykde/src/KDE/kdepimlibs/kalarmcal/kacalendar.cpp
operator -

1167325
Resource leak
High
Resource leaks
/data/mykde/src/KDE/kdepimlibs/akonadi/attributefactory.cpp
operator -

1167324
Resource leak
High
Resource leaks
/data/mykde/src/KDE/kdepimlibs/akonadi/typepluginloader.cpp
operator -

1167323
Resource leak
High
Resource leaks
/data/mykde/src/KDE/kdepimlibs/kabc/address.cpp
operator -

1167322
Resource leak
High
Resource leaks
/data/mykde/src/KDE/kdepimlibs/kabc/picture.cpp
s_sharedEmpty

1167321
Resource leak
High
Resource leaks
/data/mykde/src/KDE/kdepimlibs/kalarmcal/kaevent.cpp
operator -

1167320
Resource leak
High
Resource leaks
/data/mykde/src/KDE/kdepimlibs/kmime/tests/auto/headertest.cpp
testContentTypeHeader

1167319
Resource leak
High
Resource leaks
/data/mykde/src/KDE/kdepimlibs/kimap/acl.cpp
operator -

1167318
Out-of-bounds write
High
Memory - corruptions
/data/mykde/src/KDE/kdepimlibs/kmime/kmime_codecs.h
write

1165782
Resource leak
High
Resource leaks
/data/mykde/src/KDE/kdepimlibs/akonadi/erroroverlay.cpp
operator -

258582
Uninitialized scalar variable
High
Uninitialized variables
/data/mykde/src/KDE/kdepimlibs/kxmlrpcclient/query.cpp
parseMessageResponse

258579
Uninitialized scalar variable
High
Uninitialized variables
/data/mykde/src/KDE/kdepimlibs/akonadi/tests/entitytreemodeltest.cpp
getExpectedSignal

258028
Resource leak
High
Resource leaks
/data/mykde/src/KDE/kdepimlibs/mailtransport/tests/attributetest.cpp
testRegistrar

258026
Resource leak
High
Resource leaks
/data/mykde/src/KDE/kdepimlibs/kmime/tests/auto/headertest.cpp
testIdentHeader

258024
Resource leak
High
Resource leaks
/data/mykde/src/KDE/kdepimlibs/kcalcore/tests/testalarm.cpp
testAssignment

258023
Resource leak
High
Resource leaks
/data/mykde/src/KDE/kdepimlibs/kpimidentities/signature.cpp
d_func

258021
Resource leak
High
Resource leaks
/data/mykde/src/KDE/kdepimlibs/akonadi/tests/testrunner/config.cpp
globalConfig

258018
Resource leak
High
Resource leaks
/data/mykde/src/KDE/kdepimlibs/akonadi/tests/collectionattributetest.cpp
testDefaultAttributes

258017
Resource leak
High
Resource leaks
/data/mykde/src/KDE/kdepimlibs/akonadi/tests/attributefactorytest.cpp
testRegisteredAttribute

258016
Resource leak
High
Resource leaks
/data/mykde/src/KDE/kdepimlibs/akonadi/tests/attributefactorytest.cpp
testUnknownAttribute

258014
Resource leak
High
Resource leaks
/data/mykde/src/KDE/kdepimlibs/akonadi/item.cpp
dummyPayload

258012
Resource leak
High
Resource leaks
/data/mykde/src/KDE/kdepimlibs/akonadi/contact/tests/contactmetadataattributetest.cpp
clone

257959
Resource leak
High
Resource leaks
/data/mykde/src/KDE/kdepimlibs/akonadi/item.cpp
typeInfoToMetaTypeIdMap

257387
Resource leak in object
High
Resource leaks
/data/mykde/src/KDE/kdepimlibs/akonadi/entitylistview.cpp
Private

257385
Resource leak in object
High
Resource leaks
/data/mykde/src/KDE/kdepimlibs/akonadi/entitytreeview.cpp
Private

256376
Buffer not null terminated
High
Memory - illegal accesses
/data/mykde/src/KDE/kdepimlibs/kcalcore/versit/vobject.c
writeGroup

254961
Resource leak
High
Resource leaks
/data/mykde/src/KDE/kdepimlibs/kcalcore/tests/testcalfilter.cpp
testValidity

1245734
Uninitialized scalar field
Medium
Uninitialized members
/data/mykde/src/KDE/kdepimlibs/akonadi/tests/etmpopulationtest.cpp
ModelSignalSpy

1245733
Uninitialized pointer field
Medium
Uninitialized members
/data/mykde/src/KDE/kdepimlibs/akonadi/itemsync.cpp
ItemSync

1193546
Uninitialized pointer field
Medium
Uninitialized members
/data/mykde/src/KDE/kdepimlibs/akonadi/tageditwidget.cpp
Private

1193544
Uninitialized pointer field
Medium
Uninitialized members
/data/mykde/src/KDE/kdepimlibs/kcalcore/compat.h
Compat32PrereleaseVersions

1193543
Uninitialized pointer field
Medium
Uninitialized members
/data/mykde/src/KDE/kdepimlibs/kcalcore/compat.h
CompatOutlook9

1193542
Uninitialized pointer field
Medium
Uninitialized members
/data/mykde/src/KDE/kdepimlibs/kcalcore/compat.h
CompatPre31

1193541
Uninitialized pointer field
Medium
Uninitialized members
/data/mykde/src/KDE/kdepimlibs/kcalcore/compat.h
CompatPre32

1193540
Uninitialized pointer field
Medium
Uninitialized members
/data/mykde/src/KDE/kdepimlibs/kcalcore/compat.h
CompatPre34

1193539
Uninitialized pointer field
Medium
Uninitialized members
/data/mykde/src/KDE/kdepimlibs/kcalcore/compat.h
CompatPre35