Re: Fwd: PVS-Studio KDE analysis

2014-10-02 Thread Ben Cooksley
On Thu, Oct 2, 2014 at 1:25 PM, Christoph Feck christ...@maxiom.de wrote:
 On Wednesday 01 October 2014 23:35:50 Ben Cooksley wrote:

 On Tue, Sep 30, 2014 at 7:12 AM, Boris Egorov ego...@linux.com wrote:

  On 09/29/2014 11:55 PM, Ivan Čukić wrote:

  If the report is not separated into components, then I'd guess

  kde-devel is the right place for it.

 

  Looks like report was not separated, just one huge archive

  (probably can't be attached to mail due to its size). Svyatoslav

  (guy who made analysis) told me he will send it tomorrow to me

  or to kde-devel or to any better place which appears here.



 Would it be possible to provide some size estimates on this file?

 If it is too large to email I can arrange for it to be hosted by a

 KDE server.



 Sorry for being late, but I already received these log files from Boris via
 mail (thanks Boris!)



 613 Kbytes compressed as 7-Zip; decompressed about 24 Mbytes.



 While they are ASCII, they are in an odd format, not really human readable;
 requires someone hacking a script to convert those to XHTML format.



 Unfortunately, the mail does not state if we are allowed to publish the
 analyzer results on a public web site.



 Ben, assuming this is the case, to which address can I forward the archive
 for hosting on KDE site?

I'll grant you access to a KDE server in a bit.

Boris, can we expect these analyses to be provided on a regular basis?
(This will help to plan where to host the analysis results).




 --

 Christoph Feck

 http://kdepepo.wordpress.com/

 KDE Quality Team



Thanks,
Ben


Review Request 120460: [kio] Imported the filenamesearch ioslave from Dolphin

2014-10-02 Thread Emmanuel Pescosta

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

Review request for kde-workspace.


Repository: kio-extras


Description
---

The filenamesearch ioslave lists all files/folders which match with the given 
search query.

Made some small adjustments:
* Ported the ioslave to Qt5/KF5
* Got rid of cleanup() and member variables
* Use lambda function validators instead of some weird if + assert things in 
searchDirectory/contentContainsPattern
* Immediately return when the search string is empty
 
https://projects.kde.org/projects/kde/applications/kde-baseapps/repository/revisions/frameworks/show/dolphin/src/search


Diffs
-

  filenamesearch/kio_filenamesearch.h PRE-CREATION 
  filenamesearch/kio_filenamesearch.cpp PRE-CREATION 
  CMakeLists.txt 2036392 
  filenamesearch/CMakeLists.txt PRE-CREATION 
  filenamesearch/filenamesearch.protocol PRE-CREATION 

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


Testing
---

Compiles.


Thanks,

Emmanuel Pescosta



Re: Fwd: PVS-Studio KDE analysis

2014-10-02 Thread Ben Cooksley
On Thu, Oct 2, 2014 at 9:34 PM, Boris Egorov ego...@linux.com wrote:


 On 10/02/2014 03:27 PM, Ben Cooksley wrote:

 Boris, can we expect these analyses to be provided on a regular basis?
 (This will help to plan where to host the analysis results).


 Thanks,
 Ben


 I don't think so. PVS-Studio does such analyses for a long time, but
 only sometimes they repeat analysis for some project. They interested in
 money, in customers.

Okay, can you confirm whether we're allowed to publish this publicly or not?


 --
 Best regards,
 Boris Egorov

Thanks,
Ben


Re: Review Request 120418: kio_webdav: Added 'copyFromFile' support

2014-10-02 Thread Dawit Alemayehu

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

(Updated Oct. 2, 2014, 12:47 p.m.)


Status
--

This change has been marked as submitted.


Review request for kdelibs.


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


Repository: kdelibs


Description
---

This patch adds support for 'copyFromFile' which not only improve performance 
of copying files from local filesystem to a webdav server, but also fixes the 
bug reported in bug #334192.


Diffs
-

  kioslave/http/http.h c447b69 
  kioslave/http/http.cpp 7e2bca7 
  kioslave/http/webdav.protocol c0fbd11 

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


Testing
---

Copy file from local directory to a webdav server.


Thanks,

Dawit Alemayehu



Re: Review Request 120355: [OS X] prevent a crash when opening konqueror's Help menu

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


 On Sept. 26, 2014, 7:40 p.m., René J.V. Bertin wrote:
  changing this patch to prevent just the call to 
  invalidateBuffer_resizeHelper (and setting isResize=false when that 
  function cannot be called) shows something in place of the menu's title 
  exactly once. All other times the menu is opened, empty space is shown.
 
 Thomas Lübking wrote:
 No idea why you want to manipulate the resize flag, try just:
 
 diff --git a/src/gui/kernel/qwidget_mac.mm b/src/gui/kernel/qwidget_mac.mm
 index f58a755..d6a2741 100644
 --- a/src/gui/kernel/qwidget_mac.mm
 +++ b/src/gui/kernel/qwidget_mac.mm
 @@ -4619,7 +4619,7 @@ void QWidgetPrivate::setGeometry_sys_helper(int x, 
 int y, int w, int h, bool isM
  
  setWSGeometry(false, oldRect);
  
 -if (isResize  QApplicationPrivate::graphicsSystem())
 +if (isResize  QApplicationPrivate::graphicsSystem()  
 q-parentWidget())
  invalidateBuffer_resizeHelper(oldp, olds);
  }
 
 Thomas Lübking wrote:
 blast.
 
 ```diff
 diff --git a/src/gui/kernel/qwidget_mac.mm b/src/gui/kernel/qwidget_mac.mm
 index f58a755..d6a2741 100644
 --- a/src/gui/kernel/qwidget_mac.mm
 +++ b/src/gui/kernel/qwidget_mac.mm
 @@ -4619,7 +4619,7 @@ void QWidgetPrivate::setGeometry_sys_helper(int x, 
 int y, int w, int h, bool isM
  
  setWSGeometry(false, oldRect);
  
 -if (isResize  QApplicationPrivate::graphicsSystem())
 +if (isResize  QApplicationPrivate::graphicsSystem()  
 q-parentWidget())
  invalidateBuffer_resizeHelper(oldp, olds);
  }
 ```
 
 René J.V. Bertin wrote:
 let's say that I unset isResize so that the rest of the function can 
 finish in a slightly more appropriate fashion. I don't think it'd do to let 
 it behave as if the resize helper did its job when that function hasn't been 
 called.
 
 Thomas Lübking wrote:
 It did the resize in a reasonable fashion - at worst i't required to 
 follow the function with isRealWindow, ie. have qt_mac_update_sizer() called, 
 but the resize event very most likely needs to be sent.
 
 René J.V. Bertin wrote:
 Thomas, I thought I'd make a pure Qt example to add to a bug report on 
 qt-projects.org, so I copied over `KMenu::addTitle` and the minimum required 
 stuff from `KMenuPrivate` into a Qt example (systray):
 
 ```C++
 class KMenuPrivate
   : public QObject
 {
  public:
   KMenuPrivate (QMenu *_parent)
   {
parent = _parent;
   }
 
   /**
  * @internal
  *
  * This event filter which is installed
  * on the title of the menu, which is a QToolButton. This will
  * prevent clicks (what would change down and focus properties on
  * the title) on the title of the menu.
  *
  * @author Rafael Fernández López eresli...@kde.org
  */
   bool eventFilter(QObject *object, QEvent *event)
   {
if (event-type() == QEvent::Paint ||
  event-type() == QEvent::KeyPress ||
  event-type() == QEvent::KeyRelease) {
 qDebug()  Menu  parent  parent-title()  
 rejecting event  event  for  object  object-objectName();
 return false;
}
 
event-accept();
return true;
   }
 
   QMenu *parent;
 };
 
 QAction* qMenuAddTitle(QMenu *menu, const QIcon icon, const QString 
 text, QAction* before=NULL)
 {
  QAction *buttonAction = new QAction(menu);
  QFont font = buttonAction-font();
  font.setBold(true);
  buttonAction-setFont(font);
  buttonAction-setText(text);
  buttonAction-setIcon(icon);
 
  QWidgetAction *action = new QWidgetAction(menu);
  action-setObjectName(KMENU_TITLE);
  QToolButton *titleButton = new QToolButton(menu);
  titleButton-installEventFilter(new KMenuPrivate(menu)); // prevent 
 clicks on the title of the menu
  titleButton-setDefaultAction(buttonAction);
  titleButton-setDown(true); // prevent hover style changes in some 
 styles
  titleButton-setToolButtonStyle(Qt::ToolButtonTextBesideIcon);
  action-setDefaultWidget(titleButton);
 
  menu-insertAction(before, action);
  return action;
 }
 
 //...
 
 void Window::addActions( QMenu *menu )
 {
  qMenuAddTitle(menu, QIcon(), Window actions);
  menu-addAction(minimizeAction);
  menu-addAction(maximizeAction);
  menu-addAction(restoreAction);
 //   menu-addSeparator();
  qMenuAddTitle(menu, QIcon(), Lethal action);
  menu-addAction(quitAction);
 }
 
 

Re: Review Request 120355: [OS X] prevent a crash when opening konqueror's Help menu

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

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

(Updated Oct. 2, 2014, 7:10 p.m.)


Review request for KDE Base Apps, KDE Software on Mac OS X, kdelibs, and Qt KDE.


Repository: kde-baseapps


Description
---

Mac OS X cannot handle the formatting used for title menu items when it applies 
to items in the toplevel menu bar. An application calling KMenu::addTitle on 
such a menu item will crash immediately, somewhere deep in Qt.

This patch works around that crash by emulating the addTitle effect.

Curiously, the addTitle call that causes the crash when clicking on the Help 
menu concerns a submenu of an item of the Tools menu...


Diffs
-

  konq-plugins/uachanger/uachangerplugin.cpp 5e2d094 

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


Testing
---

OS X 10.6.8 with kdelibs 4.14.1


File Attachments (updated)


patch for qwidget_mac.mm
  
https://git.reviewboard.kde.org/media/uploaded/files/2014/09/26/b5c2dd92-33db-4225-9750-d10e13f0f835__prevent_addTitleRelated_crash.patch
with the Qt patch
  
https://git.reviewboard.kde.org/media/uploaded/files/2014/09/26/96f4fbfa-854e-4596-9f5f-d82f98a06955__Screen_shot_2014-09-26_at_19.16.20.png
with the addTitle emulation patch
  
https://git.reviewboard.kde.org/media/uploaded/files/2014/09/26/5ddf4a63-b3bb-415a-815a-c06eb7a5c7f2__Screen_shot_2014-09-26_at_19.19.40.png
Blimey, instead of a crash I get almost the intended addTitle effect! And yes, 
the Quit action has been moved by Qt...
  
https://git.reviewboard.kde.org/media/uploaded/files/2014/10/02/d9f45b6f-f4dd-4ba8-93f9-efa798695f3f__Screen_shot_2014-10-02_at_19.05.34.png


Thanks,

René J.V. Bertin



10000 lines change in kdeplasma-addons 4.14 branch

2014-10-02 Thread Albert Astals Cid
Hi Weng, I have been just told you just merged your 
  origin/xuetianweng/kimpanel-ibus-1.5
into
  KDE/4.14
in the kdeplasma-addons repo

That brings 
  27 files changed, 10677 insertions(+), 1424 deletions(-)

Has this been discussed anywhere? Because honestly this seems quite a big 
change for a stable branch.

Cheers,
  Albert


Re: 10000 lines change in kdeplasma-addons 4.14 branch

2014-10-02 Thread Weng Xuetian
Hi,
Sorry for all the trouble.

Sho on irc asked me that he want to test the ibus 1.5 support easier so I
get it merged for kde4. Unfortunately there's no further kdeplamsa-addons
for kde4 and I didn't finish this before 4.14, so it's also either leave it
broken in kde4 or add a usable version.

This change doesn't break old things but fix a never supported version for
ibus, and the old support is also kept in a different directory. So there
is no actual code deletion, and doesn't change the behavior for old version
of ibus 1.4.

The line number looks huge for following reason:
1. The ibus upstream changed quite a lot and made that ibus support must
parse a gtk key string. It's not possible to use gtk for just a keystring
parse so I was forced to copy some gdk key string parsing code here. In
this part of code there is a hardcoded key symbol to string table which is
unfortunately huge.
2. The old supporting code is also kept but moved, and new code is also
based on those code.

For i18n, there is no new string should be introduced.

In summary, this change doesn't break on old version, and introduce a fix
of supoort for new version which is never supported before.


On Thu, Oct 2, 2014 at 3:52 PM, Albert Astals Cid aa...@kde.org wrote:

 Hi Weng, I have been just told you just merged your
   origin/xuetianweng/kimpanel-ibus-1.5
 into
   KDE/4.14
 in the kdeplasma-addons repo

 That brings
   27 files changed, 10677 insertions(+), 1424 deletions(-)

 Has this been discussed anywhere? Because honestly this seems quite a big
 change for a stable branch.

 Cheers,
   Albert



Moving repositories in the module structure

2014-10-02 Thread Ben Cooksley
Hi all,

It seems there has been a recent outbreak of repository moves which
have been extremely poorly co-ordinated by those doing the requests.

In addition, it is actually a requirement that modules moving from
Extragear into (what was at least) the SC need to re-transit through
KDE Review.It is also considered proper practice to at least inform
the translation, documentation and release  teams in advance you
intend to make these moves - something which has also been neglected.

For all further repository structure moves - please ensure you have
received the appropriate consent from the above mentioned teams, and
have announced them on the appropriate mailing lists in advance.

@Plasma team: plasma-de...@kde.org does not constitute an appropriate
mailing list, as it is not a community wide development mailing list.
Only kde-devel and kde-core-devel qualify for this.

Thanks,
Ben Cooksley
KDE Sysadmin


Re: 10000 lines change in kdeplasma-addons 4.14 branch

2014-10-02 Thread Albert Astals Cid
El Dijous, 2 d'octubre de 2014, a les 16:41:38, Weng Xuetian va escriure:
 Hi,
 Sorry for all the trouble.
 
 Sho on irc asked me that he want to test the ibus 1.5 support easier so I
 get it merged for kde4. Unfortunately there's no further kdeplamsa-addons
 for kde4 and I didn't finish this before 4.14, so it's also either leave it
 broken in kde4 or add a usable version.

With my release team hat on, i would have really welcome a you asking *before* 
you do such a big commit in a stable branch.

It is not my fault Plasma people decided to not have any more kdeplasma 
feature releases, a new feature in a stable branch is a new feature in a 
stable branch and it needs an exception.

With your explanation i don't think we should reject the exception, but 
seriously, some communication never hurts.

Please everyone understand that we have stable branches for a reason, and 
adding 10K lines in them is usually not the reason.

For me we can leave this as it is, but please  next time you need to commit 
such a big chunk of code to a stable branch talk to people on a mailing list 
and ideally the release team.

Now let's all go back to do amazing work :)

Cheers,
  Albert


Re: Moving repositories in the module structure

2014-10-02 Thread Aleix Pol
On Thu, Oct 2, 2014 at 11:34 PM, Ben Cooksley bcooks...@kde.org wrote:

 Hi all,

 It seems there has been a recent outbreak of repository moves which
 have been extremely poorly co-ordinated by those doing the requests.

 In addition, it is actually a requirement that modules moving from
 Extragear into (what was at least) the SC need to re-transit through
 KDE Review.It is also considered proper practice to at least inform
 the translation, documentation and release  teams in advance you
 intend to make these moves - something which has also been neglected.

 For all further repository structure moves - please ensure you have
 received the appropriate consent from the above mentioned teams, and
 have announced them on the appropriate mailing lists in advance.

 @Plasma team: plasma-de...@kde.org does not constitute an appropriate
 mailing list, as it is not a community wide development mailing list.
 Only kde-devel and kde-core-devel qualify for this.

 Thanks,
 Ben Cooksley
 KDE Sysadmin


My apologies, I shouldn't have rushed into doing such moves and send
e-mails to all the interested parties.

If someone considers it appropriate, I can roll some of the changes back.
Aleix


Re: Moving repositories in the module structure

2014-10-02 Thread Albert Astals Cid
El Divendres, 3 d'octubre de 2014, a les 00:04:42, Aleix Pol va escriure:
 On Thu, Oct 2, 2014 at 11:34 PM, Ben Cooksley bcooks...@kde.org wrote:
  Hi all,
  
  It seems there has been a recent outbreak of repository moves which
  have been extremely poorly co-ordinated by those doing the requests.
  
  In addition, it is actually a requirement that modules moving from
  Extragear into (what was at least) the SC need to re-transit through
  KDE Review.It is also considered proper practice to at least inform
  the translation, documentation and release  teams in advance you
  intend to make these moves - something which has also been neglected.
  
  For all further repository structure moves - please ensure you have
  received the appropriate consent from the above mentioned teams, and
  have announced them on the appropriate mailing lists in advance.
  
  @Plasma team: plasma-de...@kde.org does not constitute an appropriate
  mailing list, as it is not a community wide development mailing list.
  Only kde-devel and kde-core-devel qualify for this.
  
  Thanks,
  Ben Cooksley
  KDE Sysadmin
 
 My apologies, I shouldn't have rushed into doing such moves and send
 e-mails to all the interested parties.
 
 If someone considers it appropriate, I can roll some of the changes back.

Maybe you should explain the changes so people is aware of them :)

Cheers,
  Albert

 Aleix



Re: Moving repositories in the module structure

2014-10-02 Thread Aleix Pol
On Fri, Oct 3, 2014 at 1:52 AM, Albert Astals Cid aa...@kde.org wrote:

 El Divendres, 3 d'octubre de 2014, a les 00:04:42, Aleix Pol va escriure:
  On Thu, Oct 2, 2014 at 11:34 PM, Ben Cooksley bcooks...@kde.org wrote:
   Hi all,
  
   It seems there has been a recent outbreak of repository moves which
   have been extremely poorly co-ordinated by those doing the requests.
  
   In addition, it is actually a requirement that modules moving from
   Extragear into (what was at least) the SC need to re-transit through
   KDE Review.It is also considered proper practice to at least inform
   the translation, documentation and release  teams in advance you
   intend to make these moves - something which has also been neglected.
  
   For all further repository structure moves - please ensure you have
   received the appropriate consent from the above mentioned teams, and
   have announced them on the appropriate mailing lists in advance.
  
   @Plasma team: plasma-de...@kde.org does not constitute an appropriate
   mailing list, as it is not a community wide development mailing list.
   Only kde-devel and kde-core-devel qualify for this.
  
   Thanks,
   Ben Cooksley
   KDE Sysadmin
 
  My apologies, I shouldn't have rushed into doing such moves and send
  e-mails to all the interested parties.
 
  If someone considers it appropriate, I can roll some of the changes back.

 Maybe you should explain the changes so people is aware of them :)

 Cheers,
   Albert

  Aleix


Changes:
- kde-gtk-config was moved from extragear/base to kde/workspace.
- muon was moved from extragear/sysadmin to kde/workspace.

That is, only projects.kde.org structure change.

The reasoning is that this way they will be released together with Plasma
Workspace. As they've been used they don't really make sense outside Plasma
(especially the first) and we want to make sure that distros know these
components are designed to work together with Plasma.

I didn't notify kde-core-devel because it didn't occur to me that the
community would have an opinion regarding whether it's me who releases the
packages or Jonathan (who has been doing the Plasma packages).

Cheers!
Aleix


Re: Fwd: PVS-Studio KDE analysis

2014-10-02 Thread Christoph Feck
On Friday 03 October 2014 02:53:37 Boris Egorov wrote:
 On 10/02/2014 04:45 PM, Ben Cooksley wrote:
  Okay, can you confirm whether we're allowed to publish this
  publicly or not?
  
  Thanks,
  Ben
 
 Svyatoslav said yes, we're allowed to do this.

Okey :) The RAW log files can be downloaded here:

http://developer.kde.org/~cfeck/

Would be nice if someone hacks a script to format them to readable 
pages.

Thanks Svyatoslav and Boris!

-- 
Christoph Feck
http://kdepepo.wordpress.com/
KDE Quality Team