Re: Review Request 126087: Move the i18n context from KDeclarative

[Aleix Pol Gonzalez]

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

(Updated Nov. 23, 2015, 12:54 p.m.)


Review request for KDE Frameworks, Chusslove Illich and Marco Martin.


Changes
---

Address milian's issues.


Repository: ki18n


Description
---

The only way to use `i18n*()` so far in QML is by depending on all 
KDeclarative. This patch moves the necessary bits there so it can be adopted by 
an application or framework just by offering the needed bits within KI18n.
This is done by offering an object with methods that map to the `i18n*()` C++ 
counter-parts.


Diffs (updated)
-

  autotests/CMakeLists.txt 1cf0f7a 
  autotests/ki18ndeclarativetest.cpp PRE-CREATION 
  autotests/test.qml PRE-CREATION 
  docs/programmers-guide.md 13a5f9d 
  src/CMakeLists.txt 818595e 
  src/klocalizedcontext.h PRE-CREATION 
  src/klocalizedcontext.cpp PRE-CREATION 

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


Testing
---

Ported KDeclarative, everything still seems to work.


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 126087: Move the i18n context from KDeclarative

[Aleix Pol Gonzalez]

> On Nov. 22, 2015, 7:51 p.m., Milian Wolff wrote:
> > src/klocalizedcontext.h, line 59
> > 
> >
> > virtual

It already is, I'll mark it as override.


> On Nov. 22, 2015, 7:51 p.m., Milian Wolff wrote:
> > src/klocalizedcontext.h, line 132
> > 
> >
> > are we sure we'll never add anything else? i.e. is pimpling a safer 
> > choice?

Good point.


- Aleix


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


On Nov. 20, 2015, 3:03 p.m., Aleix Pol Gonzalez wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/126087/
> ---
> 
> (Updated Nov. 20, 2015, 3:03 p.m.)
> 
> 
> Review request for KDE Frameworks, Chusslove Illich and Marco Martin.
> 
> 
> Repository: ki18n
> 
> 
> Description
> ---
> 
> The only way to use `i18n*()` so far in QML is by depending on all 
> KDeclarative. This patch moves the necessary bits there so it can be adopted 
> by an application or framework just by offering the needed bits within KI18n.
> This is done by offering an object with methods that map to the `i18n*()` C++ 
> counter-parts.
> 
> 
> Diffs
> -
> 
>   autotests/CMakeLists.txt 1cf0f7a 
>   autotests/ki18ndeclarativetest.cpp PRE-CREATION 
>   autotests/test.qml PRE-CREATION 
>   docs/programmers-guide.md 13a5f9d 
>   src/CMakeLists.txt 818595e 
>   src/klocalizedcontext.h PRE-CREATION 
>   src/klocalizedcontext.cpp PRE-CREATION 
> 
> Diff: https://git.reviewboard.kde.org/r/126087/diff/
> 
> 
> Testing
> ---
> 
> Ported KDeclarative, everything still seems to work.
> 
> 
> Thanks,
> 
> Aleix Pol Gonzalez
> 
>

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

[kf5-]gpgmepp

[René J . V . Bertin]

Hi,

Quick question: gpgmepp is a dependency for kwallet, albeit an optional one 
(still not without importance I guess). Why is it part of "applications" and 
not of "frameworks"?

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

kdeinit5 on OS X

[René J . V . Bertin]

Hi,

Preparing a MacPorts port for kf5-kinit, I see the following in kdeinit's CMake 
file:

add_executable(kdeinit5 ${kdeinit_SRCS})
if (APPLE)   
  # this has to be GUI on OSX because it launches GUI apps and need a quartz 
context
  set_target_properties(kdeinit5 PROPERTIES MACOSX_BUNDLE_INFO_PLIST 
${CMAKE_CURRENT_SOURCE_DIR}/Info.plist.template)
  set_target_properties(kdeinit5 PROPERTIES MACOSX_BUNDLE_GUI_IDENTIFIER 
"org.kde.kdeinit5")
  set_target_properties(kdeinit5 PROPERTIES MACOSX_BUNDLE_BUNDLE_NAME "KDE 
Init")
else ()   
  ecm_mark_nongui_executable(kdeinit5)
endif ()  


Has that been verified? AFAIK, the only thing mark_nongui_exec does on OS X is 
to build the application as a regular executable, instead of as an app bundle. 
And also AFAIK, this makes no difference on what the resulting application can 
do.

Hence my question: has anyone verified whether the app bundle nature is 
required? Kdeinit4 was built like that, and as a result wasn't found by the 
library function (KToolInvocation::startKdeinit()) that is supposed to start 
things like klauncher through kdeinit4. I see the KF5 version uses 
QSP::findExecutable(), and its documentation is mute about whether that 
function is able to find a BundleExec on OS X.

If not: what possibilities do I have to verify this myself when I am only just 
at the point where I could build and install kf5-kinit itself? (I see a lot of 
leftover Q_OS_MAC tokens, suggesting the code hasn't been verified beyond 
whether it builds.)

NB: if kdeinit5 indeed has to be built as an app bundle its executable isn't 
found because of that a wrapper script might be required, like the one I wrote 
for KDE4:

#!/bin/sh

if [ "${TERM}" != "" ] ;then
 # launched from a terminal session; do not use LaunchServices:
 exec @KDEAPPDIR@/kdeinit5.app/Contents/MacOS/kdeinit5 "$@"
else
 exec open -W -a @KDEAPPDIR@/kdeinit5.app --args "$@"
fi


R

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

Re: Review Request 126087: Move the i18n context from KDeclarative

[Chusslove Illich]

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



src/klocalizedcontext.cpp (line 76)


Style wise, shouldn't this conditional also use braces?



src/klocalizedcontext.cpp (line 79)


If this happens, all subsequent substitutions will use placeholders shifted 
back by one, so the message will be messed up more than necessary. Better 
substitute something, e.g. "???".


- Chusslove Illich


On Нов. 23, 2015, 12:54 по п., Aleix Pol Gonzalez wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/126087/
> ---
> 
> (Updated Нов. 23, 2015, 12:54 по п.)
> 
> 
> Review request for KDE Frameworks, Chusslove Illich and Marco Martin.
> 
> 
> Repository: ki18n
> 
> 
> Description
> ---
> 
> The only way to use `i18n*()` so far in QML is by depending on all 
> KDeclarative. This patch moves the necessary bits there so it can be adopted 
> by an application or framework just by offering the needed bits within KI18n.
> This is done by offering an object with methods that map to the `i18n*()` C++ 
> counter-parts.
> 
> 
> Diffs
> -
> 
>   autotests/CMakeLists.txt 1cf0f7a 
>   autotests/ki18ndeclarativetest.cpp PRE-CREATION 
>   autotests/test.qml PRE-CREATION 
>   docs/programmers-guide.md 13a5f9d 
>   src/CMakeLists.txt 818595e 
>   src/klocalizedcontext.h PRE-CREATION 
>   src/klocalizedcontext.cpp PRE-CREATION 
> 
> Diff: https://git.reviewboard.kde.org/r/126087/diff/
> 
> 
> Testing
> ---
> 
> Ported KDeclarative, everything still seems to work.
> 
> 
> 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 126087: Move the i18n context from KDeclarative

[Aleix Pol Gonzalez]

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

(Updated Nov. 23, 2015, 1:52 p.m.)


Review request for KDE Frameworks, Chusslove Illich and Marco Martin.


Changes
---

Address ilic's comments.


Repository: ki18n


Description
---

The only way to use `i18n*()` so far in QML is by depending on all 
KDeclarative. This patch moves the necessary bits there so it can be adopted by 
an application or framework just by offering the needed bits within KI18n.
This is done by offering an object with methods that map to the `i18n*()` C++ 
counter-parts.


Diffs (updated)
-

  autotests/CMakeLists.txt 1cf0f7a 
  src/klocalizedcontext.h PRE-CREATION 
  src/CMakeLists.txt 818595e 
  docs/programmers-guide.md 13a5f9d 
  autotests/ki18ndeclarativetest.cpp PRE-CREATION 
  autotests/test.qml PRE-CREATION 
  src/klocalizedcontext.cpp PRE-CREATION 

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


Testing
---

Ported KDeclarative, everything still seems to work.


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 126131: Don't delete gl texture twice in thumbnail

[David Edmundson]

> On Nov. 23, 2015, 7:13 a.m., Martin Gräßlin wrote:
> > are you sure it means that? I mean I did read the documentation when 
> > writing that code and did deliberately wrote the code like that. So I'm a 
> > little bit surprised that I got it exactly the other way around.

How do you interpret:
"The texture object owns the texture id and will delete the GL texture when the 
texture object is deleted." ?


Docs aside, relevant Qt code is:

QSGTexture *QSGEngine::createTextureFromId(uint id, const QSize &size, 
CreateTextureOptions options) const
{
Q_D(const QSGEngine);
if (d->sgRenderContext->isValid()) {
QSGPlainTexture *texture = new QSGPlainTexture();
texture->setTextureId(id);
texture->setHasAlphaChannel(options & TextureHasAlphaChannel);
texture->setOwnsTexture(options & TextureOwnsGLTexture);
texture->setTextureSize(size);
return texture;
}
return 0;
}


QSGPlainTexture::~QSGPlainTexture()
if (m_texture_id && m_owns_texture && QOpenGLContext::currentContext())
QOpenGLContext::currentContext()->functions()->glDeleteTextures(1, 
&m_texture_id);


- David


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


On Nov. 22, 2015, 1:57 a.m., David Edmundson wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/126131/
> ---
> 
> (Updated Nov. 22, 2015, 1:57 a.m.)
> 
> 
> Review request for KDE Frameworks and Plasma.
> 
> 
> Repository: plasma-framework
> 
> 
> Description
> ---
> 
> The QSGTextures are created with
> 
> window()->createTextureFromId(m_texture, QSize(w,h),
> QuickWindow::TextureOwnsGLTexture));
> 
> this means we don't want to be deleting textures ourselves too, it will
> be deleted when we delete the QSGTexture, which is a scoped pointer
> inside our QSGNode.
> 
> BUG: 355644
> REVIEW:
> 
> 
> Diffs
> -
> 
>   src/declarativeimports/core/windowthumbnail.cpp 
> 2b09657e8ce6bd1cca1acc323d5955b2f1a1efb2 
> 
> Diff: https://git.reviewboard.kde.org/r/126131/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: Review Request 126087: Move the i18n context from KDeclarative

[Chusslove Illich]

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

Ship it!


Ship It!

- Chusslove Illich


On Нов. 23, 2015, 1:52 по п., Aleix Pol Gonzalez wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/126087/
> ---
> 
> (Updated Нов. 23, 2015, 1:52 по п.)
> 
> 
> Review request for KDE Frameworks, Chusslove Illich and Marco Martin.
> 
> 
> Repository: ki18n
> 
> 
> Description
> ---
> 
> The only way to use `i18n*()` so far in QML is by depending on all 
> KDeclarative. This patch moves the necessary bits there so it can be adopted 
> by an application or framework just by offering the needed bits within KI18n.
> This is done by offering an object with methods that map to the `i18n*()` C++ 
> counter-parts.
> 
> 
> Diffs
> -
> 
>   autotests/CMakeLists.txt 1cf0f7a 
>   src/klocalizedcontext.h PRE-CREATION 
>   src/CMakeLists.txt 818595e 
>   docs/programmers-guide.md 13a5f9d 
>   autotests/ki18ndeclarativetest.cpp PRE-CREATION 
>   autotests/test.qml PRE-CREATION 
>   src/klocalizedcontext.cpp PRE-CREATION 
> 
> Diff: https://git.reviewboard.kde.org/r/126087/diff/
> 
> 
> Testing
> ---
> 
> Ported KDeclarative, everything still seems to work.
> 
> 
> 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 126131: Don't delete gl texture twice in thumbnail

[Martin Gräßlin]

> On Nov. 23, 2015, 8:13 a.m., Martin Gräßlin wrote:
> > are you sure it means that? I mean I did read the documentation when 
> > writing that code and did deliberately wrote the code like that. So I'm a 
> > little bit surprised that I got it exactly the other way around.
> 
> David Edmundson wrote:
> How do you interpret:
> "The texture object owns the texture id and will delete the GL texture 
> when the texture object is deleted." ?
> 
> 
> Docs aside, relevant Qt code is:
> 
> QSGTexture *QSGEngine::createTextureFromId(uint id, const QSize &size, 
> CreateTextureOptions options) const
> {
> Q_D(const QSGEngine);
> if (d->sgRenderContext->isValid()) {
> QSGPlainTexture *texture = new QSGPlainTexture();
> texture->setTextureId(id);
> texture->setHasAlphaChannel(options & TextureHasAlphaChannel);
> texture->setOwnsTexture(options & TextureOwnsGLTexture);
> texture->setTextureSize(size);
> return texture;
> }
> return 0;
> }
> 
> 
> QSGPlainTexture::~QSGPlainTexture()
> if (m_texture_id && m_owns_texture && 
> QOpenGLContext::currentContext())
> 
> QOpenGLContext::currentContext()->functions()->glDeleteTextures(1, 
> &m_texture_id);

given the code in plasma-framework, I'm quite certain that I didn't want Qt to 
take over ownership of it. So I think we should turn it around and make our 
code do what was intended. I just checked and we do proper cleanup handling. 
discardPixmap is called from the dtor, so if we do cleanup, why should Qt?


- Martin


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


On Nov. 22, 2015, 2:57 a.m., David Edmundson wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/126131/
> ---
> 
> (Updated Nov. 22, 2015, 2:57 a.m.)
> 
> 
> Review request for KDE Frameworks and Plasma.
> 
> 
> Repository: plasma-framework
> 
> 
> Description
> ---
> 
> The QSGTextures are created with
> 
> window()->createTextureFromId(m_texture, QSize(w,h),
> QuickWindow::TextureOwnsGLTexture));
> 
> this means we don't want to be deleting textures ourselves too, it will
> be deleted when we delete the QSGTexture, which is a scoped pointer
> inside our QSGNode.
> 
> BUG: 355644
> REVIEW:
> 
> 
> Diffs
> -
> 
>   src/declarativeimports/core/windowthumbnail.cpp 
> 2b09657e8ce6bd1cca1acc323d5955b2f1a1efb2 
> 
> Diff: https://git.reviewboard.kde.org/r/126131/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: Review Request 126131: Don't delete gl texture twice in thumbnail

[David Edmundson]

> On Nov. 23, 2015, 7:13 a.m., Martin Gräßlin wrote:
> > are you sure it means that? I mean I did read the documentation when 
> > writing that code and did deliberately wrote the code like that. So I'm a 
> > little bit surprised that I got it exactly the other way around.
> 
> David Edmundson wrote:
> How do you interpret:
> "The texture object owns the texture id and will delete the GL texture 
> when the texture object is deleted." ?
> 
> 
> Docs aside, relevant Qt code is:
> 
> QSGTexture *QSGEngine::createTextureFromId(uint id, const QSize &size, 
> CreateTextureOptions options) const
> {
> Q_D(const QSGEngine);
> if (d->sgRenderContext->isValid()) {
> QSGPlainTexture *texture = new QSGPlainTexture();
> texture->setTextureId(id);
> texture->setHasAlphaChannel(options & TextureHasAlphaChannel);
> texture->setOwnsTexture(options & TextureOwnsGLTexture);
> texture->setTextureSize(size);
> return texture;
> }
> return 0;
> }
> 
> 
> QSGPlainTexture::~QSGPlainTexture()
> if (m_texture_id && m_owns_texture && 
> QOpenGLContext::currentContext())
> 
> QOpenGLContext::currentContext()->functions()->glDeleteTextures(1, 
> &m_texture_id);
> 
> Martin Gräßlin wrote:
> given the code in plasma-framework, I'm quite certain that I didn't want 
> Qt to take over ownership of it. So I think we should turn it around and make 
> our code do what was intended. I just checked and we do proper cleanup 
> handling. discardPixmap is called from the dtor, so if we do cleanup, why 
> should Qt?

>why should Qt?

Because you told it to :P


but sure, that works too. Will make new RR.


- David


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


On Nov. 22, 2015, 1:57 a.m., David Edmundson wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/126131/
> ---
> 
> (Updated Nov. 22, 2015, 1:57 a.m.)
> 
> 
> Review request for KDE Frameworks and Plasma.
> 
> 
> Repository: plasma-framework
> 
> 
> Description
> ---
> 
> The QSGTextures are created with
> 
> window()->createTextureFromId(m_texture, QSize(w,h),
> QuickWindow::TextureOwnsGLTexture));
> 
> this means we don't want to be deleting textures ourselves too, it will
> be deleted when we delete the QSGTexture, which is a scoped pointer
> inside our QSGNode.
> 
> BUG: 355644
> REVIEW:
> 
> 
> Diffs
> -
> 
>   src/declarativeimports/core/windowthumbnail.cpp 
> 2b09657e8ce6bd1cca1acc323d5955b2f1a1efb2 
> 
> Diff: https://git.reviewboard.kde.org/r/126131/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: Review Request 126088: Port KDeclarative to use KI18n directly, rather than adding its own bindings

[Aleix Pol Gonzalez]

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


Bump!

- Aleix Pol Gonzalez


On Nov. 16, 2015, 1:57 p.m., Aleix Pol Gonzalez wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/126088/
> ---
> 
> (Updated Nov. 16, 2015, 1:57 p.m.)
> 
> 
> Review request for KDE Frameworks.
> 
> 
> Repository: kdeclarative
> 
> 
> Description
> ---
> 
> `i18n*()` bindings were moved upstream to ki18n so they can be used by a 
> wider audience.
> 
> 
> Diffs
> -
> 
>   src/kdeclarative/CMakeLists.txt ce12546 
>   src/kdeclarative/kdeclarative.cpp 820250d 
>   src/kdeclarative/private/kdeclarative_p.h 0e48ca3 
>   src/kdeclarative/private/rootcontext.cpp d88b566 
>   src/kdeclarative/private/rootcontext_p.h 94df09f 
> 
> Diff: https://git.reviewboard.kde.org/r/126088/diff/
> 
> 
> Testing
> ---
> 
> Tests still pass, apps still work, plasma still works as well.
> 
> 
> 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 126087: Move the i18n context from KDeclarative

[Aleix Pol Gonzalez]

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

(Updated Nov. 23, 2015, 2:33 p.m.)


Status
--

This change has been marked as submitted.


Review request for KDE Frameworks, Chusslove Illich and Marco Martin.


Changes
---

Submitted with commit 369509cc41d82b5b14f329c1ba9d40289ea672e5 by Aleix Pol to 
branch master.


Repository: ki18n


Description
---

The only way to use `i18n*()` so far in QML is by depending on all 
KDeclarative. This patch moves the necessary bits there so it can be adopted by 
an application or framework just by offering the needed bits within KI18n.
This is done by offering an object with methods that map to the `i18n*()` C++ 
counter-parts.


Diffs
-

  autotests/CMakeLists.txt 1cf0f7a 
  src/klocalizedcontext.h PRE-CREATION 
  src/CMakeLists.txt 818595e 
  docs/programmers-guide.md 13a5f9d 
  autotests/ki18ndeclarativetest.cpp PRE-CREATION 
  autotests/test.qml PRE-CREATION 
  src/klocalizedcontext.cpp PRE-CREATION 

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


Testing
---

Ported KDeclarative, everything still seems to work.


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 125974: Make KTar KCompressionDevice-friendly

[Romário Rios]

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

(Updated Nov. 23, 2015, 2:57 p.m.)


Status
--

This change has been discarded.


Review request for KDE Frameworks and Aleix Pol Gonzalez.


Repository: karchive


Description
---

Up until now, since at least 5.12, decompressing some data coming directly from 
a QIODevice by using KCompressionDevice because this is a sequential device, 
and KTar and KArchive used to use QIODevice::seek and pos and some places, 
which made the decompression fail. This patch makes KTar sequential-friendly by 
replacing the calls to seek and pos with read and a simple counter, 
respectively.


Diffs
-

  src/karchive.cpp 0ece37c 
  src/ktar.cpp 824395e 

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


Testing
---

Makes the tests from review #125941 pass


Thanks,

Romário Rios

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

Jenkins-kde-ci: ki18n master stable-kf5-qt5 » Linux,gcc - Build # 29 - Unstable!

[no-reply]

GENERAL INFO

BUILD UNSTABLE
Build URL: 
https://build.kde.org/job/ki18n%20master%20stable-kf5-qt5/PLATFORM=Linux,compiler=gcc/29/
Project: PLATFORM=Linux,compiler=gcc
Date of build: Mon, 23 Nov 2015 14:33:25 +
Build duration: 1 min 34 sec

CHANGE SET
Revision 369509cc41d82b5b14f329c1ba9d40289ea672e5 by aleixpol: (Move the i18n 
context from KDeclarative)
  change: add autotests/test.qml
  change: edit docs/programmers-guide.md
  change: edit autotests/CMakeLists.txt
  change: edit src/CMakeLists.txt
  change: add src/klocalizedcontext.h
  change: add src/klocalizedcontext.cpp
  change: add autotests/ki18ndeclarativetest.cpp


JUNIT RESULTS

Name: (root) Failed: 1 test(s), Passed: 3 test(s), Skipped: 0 test(s), Total: 4 
test(s)Failed: TestSuite.ki18n-declarativetest

COBERTURA RESULTS

Cobertura Coverage Report
  PACKAGES 2/2 (100%)FILES 15/19 (79%)CLASSES 15/19 (79%)LINE 1756/2949 
(60%)CONDITIONAL 850/1338 (64%)

By packages
  
autotests
FILES 7/7 (100%)CLASSES 7/7 (100%)LINE 373/442 (84%)CONDITIONAL 
163/324 (50%)
src
FILES 8/12 (67%)CLASSES 8/12 (67%)LINE 1383/2507 
(55%)CONDITIONAL 687/1014 (68%)___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Jenkins-kde-ci: ki18n master kf5-qt5 » Linux,gcc - Build # 24 - Unstable!

[no-reply]

GENERAL INFO

BUILD UNSTABLE
Build URL: 
https://build.kde.org/job/ki18n%20master%20kf5-qt5/PLATFORM=Linux,compiler=gcc/24/
Project: PLATFORM=Linux,compiler=gcc
Date of build: Mon, 23 Nov 2015 14:33:25 +
Build duration: 1 min 26 sec

CHANGE SET
Revision 369509cc41d82b5b14f329c1ba9d40289ea672e5 by aleixpol: (Move the i18n 
context from KDeclarative)
  change: edit docs/programmers-guide.md
  change: add autotests/test.qml
  change: add src/klocalizedcontext.h
  change: add src/klocalizedcontext.cpp
  change: add autotests/ki18ndeclarativetest.cpp
  change: edit autotests/CMakeLists.txt
  change: edit src/CMakeLists.txt


JUNIT RESULTS

Name: (root) Failed: 1 test(s), Passed: 3 test(s), Skipped: 0 test(s), Total: 4 
test(s)Failed: TestSuite.ki18n-declarativetest

COBERTURA RESULTS

Cobertura Coverage Report
  PACKAGES 2/2 (100%)FILES 15/19 (79%)CLASSES 15/19 (79%)LINE 1756/2949 
(60%)CONDITIONAL 850/1338 (64%)

By packages
  
autotests
FILES 7/7 (100%)CLASSES 7/7 (100%)LINE 373/442 (84%)CONDITIONAL 
163/324 (50%)
src
FILES 8/12 (67%)CLASSES 8/12 (67%)LINE 1383/2507 
(55%)CONDITIONAL 687/1014 (68%)___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Jenkins-kde-ci: ki18n master stable-kf5-qt5 » Linux,gcc - Build # 30 - Still Unstable!

[no-reply]

GENERAL INFO

BUILD UNSTABLE
Build URL: 
https://build.kde.org/job/ki18n%20master%20stable-kf5-qt5/PLATFORM=Linux,compiler=gcc/30/
Project: PLATFORM=Linux,compiler=gcc
Date of build: Mon, 23 Nov 2015 15:25:28 +
Build duration: 1 min 33 sec

CHANGE SET
Revision 8688c200d099ac4474d4151d32e29dbcb76e71f4 by aleixpol: (Fix @since 
statement in the documentation)
  change: edit src/klocalizedcontext.h


JUNIT RESULTS

Name: (root) Failed: 1 test(s), Passed: 3 test(s), Skipped: 0 test(s), Total: 4 
test(s)Failed: TestSuite.ki18n-declarativetest

COBERTURA RESULTS

Cobertura Coverage Report
  PACKAGES 2/2 (100%)FILES 15/19 (79%)CLASSES 15/19 (79%)LINE 1756/2949 
(60%)CONDITIONAL 850/1338 (64%)

By packages
  
autotests
FILES 7/7 (100%)CLASSES 7/7 (100%)LINE 373/442 (84%)CONDITIONAL 
163/324 (50%)
src
FILES 8/12 (67%)CLASSES 8/12 (67%)LINE 1383/2507 
(55%)CONDITIONAL 687/1014 (68%)___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Jenkins-kde-ci: ki18n master kf5-qt5 » Linux,gcc - Build # 25 - Still Unstable!

[no-reply]

GENERAL INFO

BUILD UNSTABLE
Build URL: 
https://build.kde.org/job/ki18n%20master%20kf5-qt5/PLATFORM=Linux,compiler=gcc/25/
Project: PLATFORM=Linux,compiler=gcc
Date of build: Mon, 23 Nov 2015 15:26:55 +
Build duration: 1 min 27 sec

CHANGE SET
Revision 8688c200d099ac4474d4151d32e29dbcb76e71f4 by aleixpol: (Fix @since 
statement in the documentation)
  change: edit src/klocalizedcontext.h


JUNIT RESULTS

Name: (root) Failed: 1 test(s), Passed: 3 test(s), Skipped: 0 test(s), Total: 4 
test(s)Failed: TestSuite.ki18n-declarativetest

COBERTURA RESULTS

Cobertura Coverage Report
  PACKAGES 2/2 (100%)FILES 15/19 (79%)CLASSES 15/19 (79%)LINE 1756/2949 
(60%)CONDITIONAL 850/1338 (64%)

By packages
  
autotests
FILES 7/7 (100%)CLASSES 7/7 (100%)LINE 373/442 (84%)CONDITIONAL 
163/324 (50%)
src
FILES 8/12 (67%)CLASSES 8/12 (67%)LINE 1383/2507 
(55%)CONDITIONAL 687/1014 (68%)___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Review Request 125974: Make KTar KCompressionDevice-friendly

[Luiz Romário Santana Rios]

2015-11-21 21:02 GMT-03:00 David Faure :
>
> This is an automatically generated e-mail. To reply, visit: 
> https://git.reviewboard.kde.org/r/125974/
>
> On November 7th, 2015, 9:25 a.m. UTC, David Faure wrote:
>
> BTW why create a KTar on top of a KCompressionDevice? KTar is able to handle 
> compression automatically all by itself... and that's exactly the case where 
> it will use a tempfile for the uncompressed data, making seeking work. This 
> patch is unnecessary if you use KTar the intended way: if the filename 
> doesn't end with .gz or .bz2, specify the mimetype explicitly in the KTar 
> constructor.
>
> On November 21st, 2015, 7:11 p.m. UTC, Romário Rios wrote:
>
> KCompressionDevice is supposed to be used when you want to extract data from 
> a QIODevice directly instead of a file -- KTar only handles compression 
> automatically if you pass it a filename. ATM, KCompressionDevice doesn't seem 
> to work properly with many QIODevices -- not even with QBuffer.
>
> KCompressionDevice should certainly work on top of a QBuffer. I just 
> committed a unittest that shows it working (but of course there might be a 
> bug in some other way to use it, feel free to show me in which case it 
> doesn't work).

Please take a look at my patch from the #125941 review request:
https://git.reviewboard.kde.org/r/125941/diff/2#2
It seems none of the test*BufferedNetworkReplyDevice tests work.

>
> Also, it's not true that KTar only handles compression if given a filename. 
> You can also pass it a mimetype like application/x-gzip and then it will use 
> compression.

What I meant was that, besides the QIODevice * constructor, KTar only
has a constructor taking a filename and (optionally) a mimetype.

>
>
> - David
>
>
> On November 6th, 2015, 2:52 a.m. UTC, Romário Rios wrote:
>
> Review request for KDE Frameworks and Aleix Pol Gonzalez.
> By Romário Rios.
>
> Updated Nov. 6, 2015, 2:52 a.m.
>
> Repository: karchive
>
> Description
>
> Up until now, since at least 5.12, decompressing some data coming directly 
> from a QIODevice by using KCompressionDevice because this is a sequential 
> device, and KTar and KArchive used to use QIODevice::seek and pos and some 
> places, which made the decompression fail. This patch makes KTar 
> sequential-friendly by replacing the calls to seek and pos with read and a 
> simple counter, respectively.
>
> Testing
>
> Makes the tests from review #125941 pass
>
> Diffs
>
> src/karchive.cpp (0ece37c)
> src/ktar.cpp (824395e)
>
> View Diff




-- 
Luiz Romário Santana Rios
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Failure while executing KTar::open while using KCompressionDevice as the device

[Luiz Romário Santana Rios]

2015-11-02 14:53 GMT-03:00 Luiz Romário Santana Rios :
> Hello,
>
> I'm trying to decompress a XZ archive downloaded using
> QNetworkAccessManager, so, according to the documents, I have to pass
> the QNetworkReply pointer to a KCompressionDevice and, then, use it as
> Ktar's device like this:
>
> https://gist.github.com/anonymous/b8fb686367f518a7dbb5
>
> The problem is that KTar::open() fails and returns false. The file I'm
> trying to extract has the following structure more or less:
> /root
> /root/dir
> /root/dir/file1
> /root/dir/file2
> ...
>
> So, as far as I've seen, the code runs normally when entering /root
> and /root/dir, but, pretty high in the stack, at
> KXzFilter::uncompress(), the call to lzma_code returns
> LZMA_FORMAT_ERROR while trying to uncompress file1 (or file2, I'm not
> sure). Here's the call stack:
>
> https://gist.github.com/anonymous/9ea380cfe48daadb5971
>
> Is this a bug? If it's a bug, how can I proceed to fix it?
>
> Thanks for the attention.
>
> --
> Luiz Romário Santana Rios

After some discussion in a review request
(https://git.reviewboard.kde.org/r/125974/), I found out that the
problem is that QNetworkReply is a sequential device. This, as I
understand it, is only a problem because KCompressionDevice is able to
open any file it wants in any sequence; after all, tars are
serializable, which means there's no need to seek back to extract a
stream of data. Knowing that, I can think of two solutions:

- Make KCompressionDevice check if the device it is receiving is
sequential. If it is, remove the ability to open any file and just
ensure KTar::copyTo() works properly.
- Check if the device passed to KCompressionDevice is sequential and
make it invalid if it is; create a new KSequentialCompressionDevice
class which only extracts the data from a sequential QIODevice and
does not have the ability to extract individual files in any order
like KCompressionDevice.

In short: either limit the functionalities of KCompressionDevice if
the device is sequential or forbid sequential devs in
KCompressionDevice and create a new class to handle them. If
KCompressionDevice relies too much on the device being sequential, the
second option is the way to go.

What do you think?

Cheers,

-- 
Luiz Romário Santana Rios
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

about QSP::RuntimeLocation and XDG_RUNTIME_DIR on OS X/MacPorts

[René J . V . Bertin]

Hi,

Freedesktop/XDG-compliant applications may use a user-specific location for 
runtime "stuff" like sockets. On Linux, this location usually is something like 
/run/user/uid. It is typically defined globally through the XDG_RUNTIME_DIR 
env. 
variable, with a fallback if that variable doesn't exist.

I'm not certain if MacPorts has some kind of policy for handling this 
particular 
location. The only beginning of an answer I have for now is the presence of a 
few ~/.cache/keyring-X directories, which may correspond to the similarly 
named keyring directories in /run/user/uid on my Linux rig.

Context: Qt5's QStandardPaths::RuntimeLocation return value. It defaults to 
~/Library/Application Support, which I think is fine for "Apple native mode" 
but 
not for an XDG-compliant mode like the one I intend to provide.
Alternatives I see:
- $TMPDIR/runtime-username (calculated using the QSP RuntimeLocation code used 
on other Unix hosts)
- ~/.cache (to align with what Gnome *may* use).

I tend to prefer the 1st alternative to stick closest to what happens on Linux, 
but only if Qt5-based and non-Qt5-based applications and libraries need NOT 
agree on the location.

Thoughts?
Thanks,
René

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

Re: Failure while executing KTar::open while using KCompressionDevice as the device

[Aleix Pol]

On Mon, Nov 23, 2015 at 4:54 PM, Luiz Romário Santana Rios
 wrote:
> 2015-11-02 14:53 GMT-03:00 Luiz Romário Santana Rios :
>> Hello,
>>
>> I'm trying to decompress a XZ archive downloaded using
>> QNetworkAccessManager, so, according to the documents, I have to pass
>> the QNetworkReply pointer to a KCompressionDevice and, then, use it as
>> Ktar's device like this:
>>
>> https://gist.github.com/anonymous/b8fb686367f518a7dbb5
>>
>> The problem is that KTar::open() fails and returns false. The file I'm
>> trying to extract has the following structure more or less:
>> /root
>> /root/dir
>> /root/dir/file1
>> /root/dir/file2
>> ...
>>
>> So, as far as I've seen, the code runs normally when entering /root
>> and /root/dir, but, pretty high in the stack, at
>> KXzFilter::uncompress(), the call to lzma_code returns
>> LZMA_FORMAT_ERROR while trying to uncompress file1 (or file2, I'm not
>> sure). Here's the call stack:
>>
>> https://gist.github.com/anonymous/9ea380cfe48daadb5971
>>
>> Is this a bug? If it's a bug, how can I proceed to fix it?
>>
>> Thanks for the attention.
>>
>> --
>> Luiz Romário Santana Rios
>
> After some discussion in a review request
> (https://git.reviewboard.kde.org/r/125974/), I found out that the
> problem is that QNetworkReply is a sequential device. This, as I
> understand it, is only a problem because KCompressionDevice is able to
> open any file it wants in any sequence; after all, tars are
> serializable, which means there's no need to seek back to extract a
> stream of data. Knowing that, I can think of two solutions:
>
> - Make KCompressionDevice check if the device it is receiving is
> sequential. If it is, remove the ability to open any file and just
> ensure KTar::copyTo() works properly.
> - Check if the device passed to KCompressionDevice is sequential and
> make it invalid if it is; create a new KSequentialCompressionDevice
> class which only extracts the data from a sequential QIODevice and
> does not have the ability to extract individual files in any order
> like KCompressionDevice.
>
> In short: either limit the functionalities of KCompressionDevice if
> the device is sequential or forbid sequential devs in
> KCompressionDevice and create a new class to handle them. If
> KCompressionDevice relies too much on the device being sequential, the
> second option is the way to go.
>
> What do you think?

I don't think you want to do something like:
if (dev->isSequiential()) {
   new KCopyCompressionDevice;
   //do stuff
} else {
   new KCompressionDevice;
   //do essentially the same stuff
}

We aren't adding any semantics by offering a new class. I'd say that
KCompressionDevice should either take it all or just assert on
isSequential and expect the users to actually implement it on the app
side.

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

Re: kdeinit5 on OS X

[Aleix Pol]

On Mon, Nov 23, 2015 at 1:29 PM, René J.V.  wrote:
> Hi,
>
> Preparing a MacPorts port for kf5-kinit, I see the following in kdeinit's 
> CMake file:
>
> add_executable(kdeinit5 ${kdeinit_SRCS})
> if (APPLE)
>   # this has to be GUI on OSX because it launches GUI apps and need a quartz 
> context
>   set_target_properties(kdeinit5 PROPERTIES MACOSX_BUNDLE_INFO_PLIST 
> ${CMAKE_CURRENT_SOURCE_DIR}/Info.plist.template)
>   set_target_properties(kdeinit5 PROPERTIES MACOSX_BUNDLE_GUI_IDENTIFIER 
> "org.kde.kdeinit5")
>   set_target_properties(kdeinit5 PROPERTIES MACOSX_BUNDLE_BUNDLE_NAME "KDE 
> Init")
> else ()
>   ecm_mark_nongui_executable(kdeinit5)
> endif ()
>
>
> Has that been verified? AFAIK, the only thing mark_nongui_exec does on OS X 
> is to build the application as a regular executable, instead of as an app 
> bundle. And also AFAIK, this makes no difference on what the resulting 
> application can do.
>
> Hence my question: has anyone verified whether the app bundle nature is 
> required? Kdeinit4 was built like that, and as a result wasn't found by the 
> library function (KToolInvocation::startKdeinit()) that is supposed to start 
> things like klauncher through kdeinit4. I see the KF5 version uses 
> QSP::findExecutable(), and its documentation is mute about whether that 
> function is able to find a BundleExec on OS X.
>
> If not: what possibilities do I have to verify this myself when I am only 
> just at the point where I could build and install kf5-kinit itself? (I see a 
> lot of leftover Q_OS_MAC tokens, suggesting the code hasn't been verified 
> beyond whether it builds.)
>
> NB: if kdeinit5 indeed has to be built as an app bundle its executable isn't 
> found because of that a wrapper script might be required, like the one I 
> wrote for KDE4:
>
> #!/bin/sh
>
> if [ "${TERM}" != "" ] ;then
>  # launched from a terminal session; do not use LaunchServices:
>  exec @KDEAPPDIR@/kdeinit5.app/Contents/MacOS/kdeinit5 "$@"
> else
>  exec open -W -a @KDEAPPDIR@/kdeinit5.app --args "$@"
> fi

I also don't see why you'd want kdeinit in a bundle. But then I'm not
very knowledgeable about OS X. Maybe ask kde-...@kde.org?

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

Re: Jenkins-kde-ci: ki18n master kf5-qt5 » Linux,gcc - Build # 25 - Still Unstable!

[Aleix Pol]

On Mon, Nov 23, 2015 at 4:38 PM,   wrote:
>
> GENERAL INFO
>
> BUILD UNSTABLE
> Build URL: 
> https://build.kde.org/job/ki18n%20master%20kf5-qt5/PLATFORM=Linux,compiler=gcc/25/
> Project: PLATFORM=Linux,compiler=gcc
> Date of build: Mon, 23 Nov 2015 15:26:55 +
> Build duration: 1 min 27 sec
>
> CHANGE SET
> Revision 8688c200d099ac4474d4151d32e29dbcb76e71f4 by aleixpol: (Fix @since 
> statement in the documentation)
>   change: edit src/klocalizedcontext.h
>
>
> JUNIT RESULTS
>
> Name: (root) Failed: 1 test(s), Passed: 3 test(s), Skipped: 0 test(s), Total: 
> 4 test(s)Failed: TestSuite.ki18n-declarativetest
>
> COBERTURA RESULTS
>
> Cobertura Coverage Report
>   PACKAGES 2/2 (100%)FILES 15/19 (79%)CLASSES 15/19 (79%)LINE 1756/2949 
> (60%)CONDITIONAL 850/1338 (64%)
>
> By packages
>
> autotests
> FILES 7/7 (100%)CLASSES 7/7 (100%)LINE 373/442 
> (84%)CONDITIONAL 163/324 (50%)
> src
> FILES 8/12 (67%)CLASSES 8/12 (67%)LINE 1383/2507 
> (55%)CONDITIONAL 687/1014 (68%)
> ___
> Kde-frameworks-devel mailing list
> Kde-frameworks-devel@kde.org
> https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
>

Hi,
I cannot reproduce this issue. Would it be possible to get a backtrace
to figure something out?

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

Re: kdeinit5 on OS X

[René J . V . Bertin]

Aleix Pol wrote:


> I also don't see why you'd want kdeinit in a bundle. But then I'm not

There used to be a time when a connection to the windowserver indeed required 
(or was much easier to get, or worked better) if the application lived in an 
appbundle, and there *may* still be conditions under which that's preferable. A 
requirement to start an application through LaunchServices would be one, but I 
don't think that applies here

> very knowledgeable about OS X. Maybe ask kde-...@kde.org?

I'm rather certain that the people on kde-mac don't have a lot more experience 
with KF5 than I have, but you're right I should have cross-posted.

R.

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

Re: Review Request 125640: Remove special handling when service is already registered

[Martin Klapetek]

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

(Updated Nov. 23, 2015, 8:23 p.m.)


Status
--

This change has been marked as submitted.


Review request for KDE Frameworks.


Changes
---

Submitted with commit ef7e90d73971dce9f3bceef2a66f4c07689d4e5f by Martin 
Klapetek to branch master.


Repository: kwallet


Description
---

As pointed out in https://git.reviewboard.kde.org/r/125483/ the special 
handling is useless here. If the service is registered, it will call Activate 
and KDBusService will just exit, even with the NoExitOnFailure flag; it would 
never reach the "if (!dbusUniqueInstance.isRegistered()) {".

Furthermore, without the NoExitOnFailure flag, it would exit right from 
KDBusService, rendering this whole if-block kinda useless.


Diffs
-

  src/runtime/kwalletd/main.cpp fbab58d 

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


Testing
---


Thanks,

Martin Klapetek

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

Re: Jenkins-kde-ci: ki18n master kf5-qt5 » Linux, gcc - Build # 25 - Still Unstable!

[Albert Astals Cid]

El Monday 23 November 2015, a les 18:49:29, Aleix Pol va escriure:
> On Mon, Nov 23, 2015 at 4:38 PM,   wrote:
> > GENERAL INFO
> > 
> > BUILD UNSTABLE
> > Build URL:
> > https://build.kde.org/job/ki18n%20master%20kf5-qt5/PLATFORM=Linux,compile
> > r=gcc/25/ Project: PLATFORM=Linux,compiler=gcc
> > Date of build: Mon, 23 Nov 2015 15:26:55 +
> > Build duration: 1 min 27 sec
> > 
> > CHANGE SET
> > Revision 8688c200d099ac4474d4151d32e29dbcb76e71f4 by aleixpol: (Fix @since
> > statement in the documentation)> 
> >   change: edit src/klocalizedcontext.h
> > 
> > JUNIT RESULTS
> > 
> > Name: (root) Failed: 1 test(s), Passed: 3 test(s), Skipped: 0 test(s),
> > Total: 4 test(s)Failed: TestSuite.ki18n-declarativetest
> > 
> > COBERTURA RESULTS
> > 
> > Cobertura Coverage Report
> > 
> >   PACKAGES 2/2 (100%)FILES 15/19 (79%)CLASSES 15/19 (79%)LINE 1756/2949
> >   (60%)CONDITIONAL 850/1338 (64%)> 
> > By packages
> > 
> > autotests
> > 
> > FILES 7/7 (100%)CLASSES 7/7 (100%)LINE 373/442
> > (84%)CONDITIONAL 163/324 (50%)> 
> > src
> > 
> > FILES 8/12 (67%)CLASSES 8/12 (67%)LINE 1383/2507
> > (55%)CONDITIONAL 687/1014 (68%)> 
> > ___
> > Kde-frameworks-devel mailing list
> > Kde-frameworks-devel@kde.org
> > https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
> 
> Hi,
> I cannot reproduce this issue. Would it be possible to get a backtrace
> to figure something out?

Here it is.

#0  0x7551c267 in raise () from /lib/x86_64-linux-gnu/libc.so.6
#1  0x7551deca in abort () from /lib/x86_64-linux-gnu/libc.so.6
#2  0x75e7be2e in qt_message_fatal (context=..., message=...) at 
global/qlogging.cpp:1578
#3  0x75e7815c in QMessageLogger::fatal (this=0x7fffbdd0, 
msg=0x7620d2c8 "ASSERT: \"%s\" in file %s, line %d") at 
global/qlogging.cpp:781
#4  0x75e7104b in qt_assert (assertion=0x76209f88 "size == 0 || 
offset < 0 || size_t(offset) >= sizeof(QArrayData)", file=0x76209f48 
"../../include/QtCore/../../src/corelib/tools/qarraydata.h", line=54) at 
global/qglobal.cpp:2966
#5  0x75e59108 in QArrayData::data (this=0x76442c70 ) at 
../../include/QtCore/../../src/corelib/tools/qarraydata.h:53
#6  0x75e5916c in QTypedArrayData::data 
(this=0x76442c70 ) at 
../../include/QtCore/../../src/corelib/tools/qarraydata.h:199
#7  0x75e59151 in QString::constData (this=0x60b0a5f0) at 
../../include/QtCore/../../src/corelib/tools/qstring.h:865
#8  0x75f69b75 in QString::toUtf8_helper (str=...) at 
tools/qstring.cpp:4453
#9  0x764f7fcb in QString::toUtf8() const & (this=0x60b0a5f0) at 
/srv/jenkins/install/ubuntu/x86_64/g++/kf5-qt5/qt5/inst/include/QtCore/qstring.h:508
#10 0x76548e20 in KLocalizedContext::i18n (this=0x7fffd200, 
message=..., param1=..., param2=..., param3=..., param4=..., param5=..., 
param6=..., param7=..., param8=..., param9=..., param10=...)
at /home/jenkins/builds/ki18n/kf5-qt5/src/klocalizedcontext.cpp:134
#11 0x7655283a in KLocalizedContext::qt_static_metacall 
(_o=0x7fffd200, _c=QMetaObject::InvokeMetaMethod, _id=11, 
_a=0x7fffc330) at 
/home/jenkins/builds/ki18n/kf5-qt5/build/src/moc_klocalizedcontext.cpp:490
#12 0x7657945a in KLocalizedContext::qt_metacall (this=0x7fffd200, 
_c=QMetaObject::InvokeMetaMethod, _id=11, _a=0x7fffc330) at 
/home/jenkins/builds/ki18n/kf5-qt5/build/src/moc_klocalizedcontext.cpp:882
#13 0x760da837 in QMetaObject::metacall (object=0x7fffd200, 
cl=QMetaObject::InvokeMetaMethod, idx=16, argv=0x7fffc330) at 
kernel/qmetaobject.cpp:296
#14 0x76c145e5 in QQmlObjectOrGadget::metacall (this=0x7fffc830, 
type=QMetaObject::InvokeMetaMethod, index=16, argv=0x7fffc330) at 
qml/qqmlpropertycache.cpp:1689
#15 0x76b5d5ad in CallMethod (object=..., index=16, returnType=10, 
argCount=1, argTypes=0x60415df4, engine=0x6191b380, 
callArgs=0x7fffee98f078) at jsruntime/qv4qobjectwrapper.cpp:1155
#16 0x76b5e0ab in CallPrecise (object=..., data=..., 
engine=0x6191b380, callArgs=0x7fffee98f078) at 
jsruntime/qv4qobjectwrapper.cpp:1404
#17 0x76b5e475 in CallOverloaded (object=..., data=..., 
engine=0x6191b380, callArgs=0x7fffee98f078, propertyCache=0x61101580) 
at jsruntime/qv4qobjectwrapper.cpp:1477
#18 0x76b609a7 in QV4::QObjectMethod::callInternal 
(this=0x7fffee98f0d0, callData=0x7fffee98f078) at 
jsruntime/qv4qobjectwrapper.cpp:1895
#19 0x76b60361 in QV4::QObjectMethod::call (m=0x7fffee98f0d0, 
callData=0x7fffee98f078) at jsruntime/qv4qobjectwrapper.cpp:1828
#20 0x76a207ae in QV4::Object::call (this=0x7fffee98f0d0, 
d=0x7fffee98f078) at 
../../include/QtQml/5.5.1/QtQml/private/../../../../../src/qml/jsruntime/qv4object_p.h:305
#21 0x76b7e4e3 in QV4::Runtime::callActivationProperty 
(engine=0x6190

OS X : org.kde.klauncher5 was not provided by any .service files

[René J . V . Bertin]

Hi,

It looks I'm getting stuck with my efforts to get a working KF5 frameworks 
install into /opt/local; I hope this is not because I already have my KDE4 
install in there.

After installing kf5-kinit and kf5-kded, kded5 shows the following error:
klauncher not running... launching kdeinit
"KLauncher could not be reached via D-Bus. Error when calling 
kdeinit_exec_wait:\nThe name org.kde.klauncher5 was not provided by any 
.service files\n"
kdeinit5: Communication error with launcher. Exiting!

I have:
/opt/local/share/dbus-1/interfaces/kf5_org.kde.KLauncher.xml
/opt/local/share/dbus-1/interfaces/org.kde.KLauncher.xml

As a reminder, when I try to start kglobalaccel5, it also fails with the message
"No such object path '/org/kde/kglobalaccel"

while I have the files
/opt/local/share/dbus-1/services/org.kde.kglobalaccel.service
/opt/local/share/dbus-1/interfaces/kf5_org.kde.KGlobalAccel.xml
/opt/local/share/dbus-1/interfaces/kf5_org.kde.kglobalaccel.Component.xml
/opt/local/share/dbus-1/interfaces/org.kde.KGlobalAccel.xml
/opt/local/share/dbus-1/interfaces/org.kde.kglobalaccel.Component.xml

I only see "org.kde.XXX' references in the CMake files and in the source, so 
where do the "kf5_org.kde.XXX" files come from -- not because I have KDE4 
equivalents installed I hope?
How is kdeinit_exec_wait supposed to find org.kde.klauncher5 if there's no file 
with that name, nor any *.KLauncher.service file?

There there's also a crash in kdeinit5 because (from the looks of it) it does 
an exec-after-fork, which is allowed only in very specific conditions on OS X. 
It's possible that one was already solved once for kdeinit4, I haven't yet had 
the time to check that out.

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

Review Request 126152: Fly away from QString::isNull() in favor of isEmpty()

[Aleix Pol Gonzalez]

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

Review request for KDE Frameworks and Chusslove Illich.


Repository: ki18n


Description
---

They don't work and it's a pointless distinction really.


Diffs
-

  src/klocalizedcontext.cpp 2b6bcf6 

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


Testing
---

Fixes the test. Actually I started getting the same crash as build.kde.org as 
soon as I started adding qDebugs...


Thanks,

Aleix Pol Gonzalez

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

Re: [kf5-]gpgmepp

[Daniel Vrátil]

On Monday, November 23, 2015 1:09:25 PM CET René J.V. Bertin wrote:
> Hi,
> 
> Quick question: gpgmepp is a dependency for kwallet, albeit an optional one
> (still not without importance I guess). Why is it part of "applications"
> and not of "frameworks"?

It was split from kdepimlibs, and we are somewhat slow at pushing stuff from 
PIM to Frameworks. Additionally there's a hope that we could upstream it to 
GpgME - they are interested in maintaining the C++ bindings, so that would 
mean even less work for us - for that reason gpgmepp was not pushed to 
Frameworks.

Andre is the current maintainer of GpgME++, he might new what the current 
situation is.

Cheers,
Dan

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


-- 
Daniel Vrátil
www.dvratil.cz | dvra...@kde.org
IRC: dvratil on Freenode (#kde, #kontact, #akonadi, #fedora-kde)

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