Re: Icons missing

[Albert Astals Cid]

El Sunday 06 December 2015, a les 13:56:19, Thorsten Zachmann va escriure:
> Hello all,
> 
> I use a separate user for running calligra. I use ssh -X to login from my
> normal desktop user to my kde running user. However when I start any
> kde application  I have no icons. 

You are not using any desktop environment thus the Qt defaults to the generic 
Unix icon theme, i.e. hicolor.

Blame Linux for not having a cross desktop environment way to define what is 
the icon theme to use.

Cheers,
  Albert

> With strace I can see it searches for
> icons in the hicolor folder instead of breeze.
> With the help of David Faure I found out the the icons are shown as expected
> when I call
> 
> export KDE_FULL_SESSION=true
> 
> before starting the application.
> 
> I think using an application via ssh -X is used quite often and it should
> work out of the box with the need of setting any special export. Maybe you
> have an idea on how the behaviour can be improved.
> 
> Please CC me as I'm not subscribed to the list.
> 
> Thorsten Zachmann
> ___
> Kde-frameworks-devel mailing list
> Kde-frameworks-devel@kde.org
> https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

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

Re: Review Request 126555: Remove unused variable in KConfigPrivate

[Albert Astals Cid]

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

Ship it!


Ship It!

- Albert Astals Cid


On des. 29, 2015, 5:20 a.m., Matthew Dawson wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/126555/
> ---
> 
> (Updated des. 29, 2015, 5:20 a.m.)
> 
> 
> Review request for KDE Frameworks and Matthew Dawson.
> 
> 
> Repository: kconfig
> 
> 
> Description
> ---
> 
> This seems to be left over from KDE 3.5 times, and isn't referenced anywhere
> in the code.  Since its a private header, just remove.
> 
> Found by Coverity, issue 1175531.
> 
> 
> Diffs
> -
> 
>   src/core/kconfig_p.h b93c8167bbab1d0403493505a5639524b4737f3c 
> 
> Diff: https://git.reviewboard.kde.org/r/126555/diff/
> 
> 
> Testing
> ---
> 
> Compiles, test run.  Grepped source code for references, none found.
> 
> 
> Thanks,
> 
> Matthew Dawson
> 
>

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

Re: Review Request 125536: Remove unused variable warnings

[Albert Astals Cid]

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


ping?

- Albert Astals Cid


On oct. 5, 2015, 10:41 p.m., Albert Astals Cid wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/125536/
> ---
> 
> (Updated oct. 5, 2015, 10:41 p.m.)
> 
> 
> Review request for KDE Frameworks.
> 
> 
> Repository: karchive
> 
> 
> Description
> ---
> 
> Remove unused zip mime
> In k7zip i've opted for commenting instead of reverting since these magic 
> values may be hard to get again if needed and whoever sees it may not realize 
> it was part of the history and git log it
> 
> 
> Diffs
> -
> 
>   src/k7zip.cpp 64c6b52 
>   src/ktar.cpp 49a6791 
> 
> Diff: https://git.reviewboard.kde.org/r/125536/diff/
> 
> 
> Testing
> ---
> 
> clang compiles without warnings
> 
> 
> Thanks,
> 
> Albert Astals Cid
> 
>

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

Re: Review Request 126403: Get rid of QApplication dependency

[Albert Astals Cid]

> On gen. 4, 2016, 7:42 a.m., Martin Gräßlin wrote:
> > anyone tested this on an "affected system"?

I have not, I thought you had made it clear in the past you thought it was a 
bad idea since it was all supposed to be widget based anyway.


- Albert


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


On gen. 2, 2016, 9:57 a.m., Thomas Lübking wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/126403/
> ---
> 
> (Updated gen. 2, 2016, 9:57 a.m.)
> 
> 
> Review request for KDE Frameworks, kwin and Albert Astals Cid.
> 
> 
> Bugs: 354811
> https://bugs.kde.org/show_bug.cgi?id=354811
> 
> 
> Repository: kwindowsystem
> 
> 
> Description
> ---
> 
> summarized, alternative to https://git.reviewboard.kde.org/r/126397/
> 
> NOTICE: this compiles but is otherwise *completely* untested!
> 
> 
> Diffs
> -
> 
>   src/platforms/xcb/kwindowsystem.cpp 9d28704 
> 
> Diff: https://git.reviewboard.kde.org/r/126403/diff/
> 
> 
> Testing
> ---
> 
> no, not the least. esp. not on the bug.
> 
> 
> Thanks,
> 
> Thomas Lübking
> 
>

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

Re: Review Request 126403: Get rid of QApplication dependency

[Albert Astals Cid]

> On gen. 4, 2016, 7:42 a.m., Martin Gräßlin wrote:
> > anyone tested this on an "affected system"?
> 
> Albert Astals Cid wrote:
> I have not, I thought you had made it clear in the past you thought it 
> was a bad idea since it was all supposed to be widget based anyway.
> 
> Thomas Lübking wrote:
> We're trying to resolve this ;-)
> 
> KWindowSystem could otherwise never be used by QGuiApplication's
> As bonus, we can probably unlink Qt6Widgets in "it's certainly not called 
> KF6 - that would be far too simple" :-P
> (I'm not sure whether we can/should that right now - while you should 
> explicitly link stuff you need, we don't live in a should-land)
> 
> => If you can, give it a try (compiz isn't provided by my distro)

I can be your tester if you tell me what to test.


- Albert


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


On gen. 2, 2016, 9:57 a.m., Thomas Lübking wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/126403/
> -----------
> 
> (Updated gen. 2, 2016, 9:57 a.m.)
> 
> 
> Review request for KDE Frameworks, kwin and Albert Astals Cid.
> 
> 
> Bugs: 354811
> https://bugs.kde.org/show_bug.cgi?id=354811
> 
> 
> Repository: kwindowsystem
> 
> 
> Description
> ---
> 
> summarized, alternative to https://git.reviewboard.kde.org/r/126397/
> 
> NOTICE: this compiles but is otherwise *completely* untested!
> 
> 
> Diffs
> -
> 
>   src/platforms/xcb/kwindowsystem.cpp 9d28704 
> 
> Diff: https://git.reviewboard.kde.org/r/126403/diff/
> 
> 
> Testing
> ---
> 
> no, not the least. esp. not on the bug.
> 
> 
> Thanks,
> 
> Thomas Lübking
> 
>

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

Re: Review Request 126403: Get rid of QApplication dependency

[Albert Astals Cid]

> On gen. 4, 2016, 7:42 a.m., Martin Gräßlin wrote:
> > anyone tested this on an "affected system"?
> 
> Albert Astals Cid wrote:
> I have not, I thought you had made it clear in the past you thought it 
> was a bad idea since it was all supposed to be widget based anyway.
> 
> Thomas Lübking wrote:
> We're trying to resolve this ;-)
> 
> KWindowSystem could otherwise never be used by QGuiApplication's
> As bonus, we can probably unlink Qt6Widgets in "it's certainly not called 
> KF6 - that would be far too simple" :-P
> (I'm not sure whether we can/should that right now - while you should 
> explicitly link stuff you need, we don't live in a should-land)
>     
> => If you can, give it a try (compiz isn't provided by my distro)
> 
> Albert Astals Cid wrote:
> I can be your tester if you tell me what to test.
> 
> Thomas Lübking wrote:
> Make kscreenlocker_greet crash when using compiz as WM, see bug #354811

Running /usr/lib/x86_64-linux-gnu/libexec/kscreenlocker_greet on Ubuntu Xenial 
under Unity7 crashes before applying this patch to kwindowsystem and seems to 
work fine after applying the patch.


- Albert


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


On gen. 2, 2016, 9:57 a.m., Thomas Lübking wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/126403/
> ---------------
> 
> (Updated gen. 2, 2016, 9:57 a.m.)
> 
> 
> Review request for KDE Frameworks, kwin and Albert Astals Cid.
> 
> 
> Bugs: 354811
> https://bugs.kde.org/show_bug.cgi?id=354811
> 
> 
> Repository: kwindowsystem
> 
> 
> Description
> ---
> 
> summarized, alternative to https://git.reviewboard.kde.org/r/126397/
> 
> NOTICE: this compiles but is otherwise *completely* untested!
> 
> 
> Diffs
> -
> 
>   src/platforms/xcb/kwindowsystem.cpp 9d28704 
> 
> Diff: https://git.reviewboard.kde.org/r/126403/diff/
> 
> 
> Testing
> ---
> 
> no, not the least. esp. not on the bug.
> 
> 
> Thanks,
> 
> Thomas Lübking
> 
>

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

Re: Draft split for qpt plugin from frameworkintegration

[Albert Astals Cid]

El Friday 18 December 2015, a les 10:03:39, Martin Graesslin va escriure:
> On Thursday, December 17, 2015 5:48:47 PM CET Martin Graesslin wrote:
> > On Thursday, December 17, 2015 4:32:48 PM CET Aleix Pol wrote:
> > > On Wed, Dec 16, 2015 at 4:12 PM, Martin Graesslin 
> > 
> > wrote:
> > > > Hi all,
> > > > 
> > > > following up on [1] I have prepared a split of frameworkintegration to
> > > > move
> > > > the QPT plugin into a dedicated repository. You can find it in [2].
> > > > Please
> > > > have a look at the split repo to verify that it looks fine. If
> > > > everything
> > > > is OK, I'll request a new repo from sysadmins.
> > > > 
> > > > Some general notes
> > > > * new repo name: plasma-integration
> > > > * new plugin name: PlasmaDesktopPlatformTheme
> > > > * new src folder name: src/plasma-desktop-platformtheme
> > > > 
> > > > Explaining the name changes:
> > > > The plugin is renamed to not conflict on install with the existing
> > > > plugin
> > > > from frameworkintegration and also incorporating future changes Marco
> > > > pointed out: we need a different QPT plugin for mobile.
> > > > 
> > > > How to remove the plugin from frameworkintegration:
> > > > After the split we cannot remove it from frameworkintegration yet as
> > > > that
> > > > would break setups on the next framework release. Given that I plan to
> > > > only
> > > > phase it out: Introduce a cmake option to build and install it, which
> > > > defaults to true till at least Plasma 5.6 is released. Afterward
> > > > swapping
> > > > the default to false, with a big fat warning and keeping it like that
> > > > for
> > > > at least half a year. Then remove it. We don't provide any guarantees
> > > > for
> > > > it, so we can remove it, but I want to keep the impact small.
> > > > 
> > > > Cheers
> > > > Martin
> > > > 
> > > > [1] https://mail.kde.org/pipermail/kde-frameworks-devel/2015-December/
> > > > 029234.html
> > > > [2] kde:scratch/graesslin/platform-integration
> > > > (https://quickgit.kde.org/?
> > > > p=scratch%2Fgraesslin%2Fplasma-integration.git )
> > > 
> > > I have my doubts that we want a different QPT for desktop and mobile.
> > > If we want to provide any convergence we need to strive to have the
> > > same on both platforms.
> > 
> > Good point! Marco is right: we need different presets whether it's desktop
> > or mobile. You're right that different plugins would result in making
> > switching impossible. Sounds like the plugin would have to learn to switch
> > at runtime.
> > 
> > Given that feedback I'm considering to not rename the directory.
> 
> pushed a new variant without the rename of the source folder and the plugin
> renamed to KDEPlasmaPlatformTheme.

Can you guys please have a look at the Messages.sh? We have now two codebases 
(Which i guess are different at this point?) creating the same 
frameworksintegration5.pot file

Cheers,
  Albert

> 
> Cheers
> Martin

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

Re: Review Request 125682: Pre-fill translator information for KAboutApplicationDialog

[Albert Astals Cid]

> On gen. 20, 2016, 12:02 p.m., Lorenzo Porta wrote:
> > src/kmainwindow.cpp, lines 213-214
> > <https://git.reviewboard.kde.org/r/125682/diff/3/?file=411972#file411972line213>
> >
> > These don't work because a null domain return nothing. You must replace 
> > Q_NULLPTR with KLocalizedString::applicationDomain()

Wrong
if (resolvedDomain.isEmpty()) {
resolvedDomain = s->applicationDomain;
}
in KLocalizedStringPrivate::toString


- Albert


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


On oct. 22, 2015, 12:31 a.m., Michael Pyne wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/125682/
> ---
> 
> (Updated oct. 22, 2015, 12:31 a.m.)
> 
> 
> Review request for KDE Frameworks, Localization and Translation (l10n) and 
> Albert Astals Cid.
> 
> 
> Bugs: 345320
> https://bugs.kde.org/show_bug.cgi?id=345320
> 
> 
> Repository: kxmlgui
> 
> 
> Description
> ---
> 
> KAboutData has a placeholder for information regarding who translated the 
> running KDE-based application (KAboutData::translators()). However it relies 
> on the application developer to call KAboutData::setTranslator() since 
> KCoreAddons (a Tier 1 framework) cannot use KI18n directly. Instead the Qt 
> translation infrastructure is used where translations are unavoidable, but 
> that is not compatible with KF5's i18n. This (IIUC) gives different behavior 
> than KDE4, where KAboutData could (and did!) directly pull the translated 
> list of translators, so application authors didn't have to do anything 
> special for their about dialog to have the list of translators.
> 
> For the majority of our applications we can make the ::setTranslator() call 
> on the application developer's behalf, as recommended by Albert on 
> kdeframeworks-devel, and by doing so from KMainWindow (a relatively central 
> location for KF5-using applications) we can use KI18n and get the 
> accurately-translated message. Feeding the already-translated information 
> into KAboutData should work to form the list of translators for later use by 
> KAboutApplicationDialog, or other accessors of that information.
> 
> This patch implements all that. I avoided using a global startup method as 
> suggested by Albert (since the Qt docs suggest that this startup would happen 
> *before* the GUI starts up, and I want to make sure KI18n is available); 
> KMainWindow seems the next best option, and even non-KXmlGuiWindow users 
> might use this. There are probably other good alternatives too (maybe even 
> the platform plugin?).
> 
> 
> Diffs
> -
> 
>   src/kmainwindow.h 11dcfca 
>   src/kmainwindow.cpp 7c86841 
> 
> Diff: https://git.reviewboard.kde.org/r/125682/diff/
> 
> 
> Testing
> ---
> 
> Compiled, apps all still work.
> 
> I find it hard to test whether the translators actually show up or not 
> though, as I do not use translated KF5 apps.
> 
> 
> Thanks,
> 
> Michael Pyne
> 
>

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

KMenu aboutToShowContextMenu KF5 porting options: None. Do we care?

[Albert Astals Cid]

In the kdelibs4 world one could connect to KMenu aboutToShowContextMenu signal 
to add more entries to the submenu that appears when right clicking on a menu 
entry.

Nowadays KMenu is gone in apps that do not use kdelibs4support so we can't use 
that.

We still have a default menu that appears when right clicking on a menu entry 
that shows configure shortcuts and add to menu bar options, but that is hidden 
deep in kmenumenuhandler_p.cpp in kxmlgui and exporting that to users is 
probably not going to be trivial (or I couldn't find one in 30 min).

In Okular we used this signal to add the "Rename bookmark" to existing 
bookamrks of the given file, see http://i.imgur.com/UkUVWZx.png

Looking at lxr, Okular seems to be the only one using this feature.

Talking with Aleix yesterday he was arguing that is kind of a hidden feature 
(though there's bug reports to make it do more things) and that it would be 
probably be easier to just drop it in the KF5 port than trying to expose this 
feature again.

I'm asking for more opinions on whether it makes sense for us to think of an 
API to make the context menu on menu entries extensible or we think it's 
better to not have it and I just drop the feature.

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

Re: KMenu aboutToShowContextMenu KF5 porting options: None. Do we care?

[Albert Astals Cid]

El Monday 01 February 2016, a les 08:39:22, David Faure va escriure:
> On Monday 01 February 2016 00:43:27 Albert Astals Cid wrote:
> > In the kdelibs4 world one could connect to KMenu aboutToShowContextMenu
> > signal to add more entries to the submenu that appears when right
> > clicking on a menu entry.
> > 
> > Nowadays KMenu is gone in apps that do not use kdelibs4support so we can't
> > use that.
> > 
> > We still have a default menu that appears when right clicking on a menu
> > entry that shows configure shortcuts and add to menu bar options, but
> > that is hidden deep in kmenumenuhandler_p.cpp in kxmlgui and exporting
> > that to users is probably not going to be trivial (or I couldn't find one
> > in 30 min).
> > 
> > In Okular we used this signal to add the "Rename bookmark" to existing
> > bookamrks of the given file, see http://i.imgur.com/UkUVWZx.png
> > 
> > Looking at lxr, Okular seems to be the only one using this feature.
> > 
> > Talking with Aleix yesterday he was arguing that is kind of a hidden
> > feature (though there's bug reports to make it do more things) and that
> > it would be probably be easier to just drop it in the KF5 port than
> > trying to expose this feature again.
> > 
> > I'm asking for more opinions on whether it makes sense for us to think of
> > an API to make the context menu on menu entries extensible or we think
> > it's better to not have it and I just drop the feature.
> 
> Konqueror (both 4 and 5) has this feature too (with 6 items in the
> contextmenu), it is actually implemented in the kbookmarks framework (so
> not using kdelibs4support), see the class KonqBookmarkContextMenu.
> 
> Looks like all you need is
> m_parentMenu->setContextMenuPolicy(Qt::CustomContextMenu);
> connect(m_parentMenu, &QWidget::customContextMenuRequested, this,
> &KBookmarkMenu::slotCustomContextMenu);

But by doing that i "loose" the default kxmlgui actions, no?

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

Re: Review Request 126948: Simplify attica plugin look-up and initialization

[Albert Astals Cid]

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


Ship it!




Having custom lib loading code is not a good idea when there's libraries that 
do that for you.

- Albert Astals Cid


On Feb. 1, 2016, 7:37 p.m., Aleix Pol Gonzalez wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/126948/
> ---
> 
> (Updated Feb. 1, 2016, 7:37 p.m.)
> 
> 
> Review request for KDE Frameworks.
> 
> 
> Repository: attica
> 
> 
> Description
> ---
> 
> Just use QPluginLoader instead of doing it locally (and with an awkward 
> blocking QProcess call)
> 
> 
> Diffs
> -
> 
>   src/providermanager.cpp 0536a1f 
> 
> Diff: https://git.reviewboard.kde.org/r/126948/diff/
> 
> 
> Testing
> ---
> 
> Test still passes, initializing attica still finds the right plugin on my 
> system.
> 
> 
> 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 127031: Add function to get runtime frameworks version information

[Albert Astals Cid]

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




src/lib/kcoreaddons.h (line 29)
<https://git.reviewboard.kde.org/r/127031/#comment62921>

Documntation is missing

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

Or am i overthinking this?


- Albert Astals Cid


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

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

Re: KActivities repository split

[Albert Astals Cid]

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

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

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

Re: Review Request 127091: Fix IconItem regression in 5.19

[Albert Astals Cid]

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



Is this testable at all?

- Albert Astals Cid


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

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

Re: KActivities repository split

[Albert Astals Cid]

El Thursday 18 February 2016, a les 12:30:59, Ivan Čukić va escriure:
> Hi Albert,
> 
> What schedule kio-extras have?

kio-extras gets released with KDE Applications.

Cheers,
  Albert

> 
> Cheerio,
> Ivan
> 
> p.s. I'm thinking more and more that kactivities-workspace repository
> might be a better solution ...
> 
> --
> KDE, ivan.cu...@kde.org, http://cukic.co/
> gpg key id: 850B6F76
> ___
> Kde-frameworks-devel mailing list
> Kde-frameworks-devel@kde.org
> https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

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

Re: Review Request 127093: Drop KDocTools requirement

[Albert Astals Cid]

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



Why is suddenty documentation less important than the rest? Do you even get a 
hint saying you must install kdoctools to get documetnation or it silently 
skips it?

- Albert Astals Cid


On Feb. 18, 2016, 10:34 p.m., Aleix Pol Gonzalez wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/127093/
> ---
> 
> (Updated Feb. 18, 2016, 10:34 p.m.)
> 
> 
> Review request for KDE Frameworks and Alex Merry.
> 
> 
> Repository: kdesignerplugin
> 
> 
> Description
> ---
> 
> Like in many other frameworks.
> 
> 
> Diffs
> -
> 
>   CMakeLists.txt bbec850 
> 
> Diff: https://git.reviewboard.kde.org/r/127093/diff/
> 
> 
> Testing
> ---
> 
> Builds with and without kdoctools.
> 
> 
> Thanks,
> 
> Aleix Pol Gonzalez
> 
>

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

Re: Review Request 125536: Remove unused variable warnings

[Albert Astals Cid]

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

(Updated Feb. 19, 2016, 12:16 a.m.)


Status
--

This change has been discarded.


Review request for KDE Frameworks.


Repository: karchive


Description
---

Remove unused zip mime
In k7zip i've opted for commenting instead of reverting since these magic 
values may be hard to get again if needed and whoever sees it may not realize 
it was part of the history and git log it


Diffs
-

  src/k7zip.cpp 64c6b52 
  src/ktar.cpp 49a6791 

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


Testing
---

clang compiles without warnings


Thanks,

Albert Astals Cid

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

Re: Review Request 127136: XmlGui: Use non native Language name as fallback in KSwitchlangaugeDialog

[Albert Astals Cid]

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



I'd prefer if you could fix this at the Qt level, why would nativeLanguageName 
ever return empty?

- Albert Astals Cid


On Feb. 22, 2016, 9:52 a.m., Andre Heinecke wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/127136/
> ---
> 
> (Updated Feb. 22, 2016, 9:52 a.m.)
> 
> 
> Review request for KDE Frameworks.
> 
> 
> Repository: kxmlgui
> 
> 
> Description
> ---
> 
> While packaging Kleopatra's translations for Gpg4win I've noticed that there 
> were blank entries in the Switchlanguagedialog.
> Apperantly QLocale::nativeLanguageName can return an Empty string (Qt 5.5 on 
> Windows).
> 
> This patch handles this and uses the non native QLocale::languageToString as 
> a fallback. The idea is that a non native Name is better then no name (and a 
> blank entry in the dialog) at all.
> 
> Ideally every language would have a native name but until this is the case I 
> think this fallback makes sense.
> 
> 
> Diffs
> -
> 
>   src/kswitchlanguagedialog_p.cpp 039daea 
> 
> Diff: https://git.reviewboard.kde.org/r/127136/diff/
> 
> 
> Testing
> ---
> 
> See attached screenshots of Kleopatra's switchlanguage dialog before and 
> after the patch. Low German is an example where the native name was empty.
> 
> 
> File Attachments
> 
> 
> Dialog before the patch
>   
> https://git.reviewboard.kde.org/media/uploaded/files/2016/02/22/a6a31417-1ad6-432e-bee9-65a367fac28d__languages_before.png
> Dialog after the patch
>   
> https://git.reviewboard.kde.org/media/uploaded/files/2016/02/22/762062c5-ff18-47da-aeb0-93b16ca28883__languages_after.png
> 
> 
> Thanks,
> 
> Andre Heinecke
> 
>

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

Re: Review Request 127136: XmlGui: Use non native Language name as fallback in KSwitchlangaugeDialog

[Albert Astals Cid]

> On feb. 22, 2016, 9:55 a.m., Albert Astals Cid wrote:
> > I'd prefer if you could fix this at the Qt level, why would 
> > nativeLanguageName ever return empty?
> 
> Andre Heinecke wrote:
> I've just checked. It's a Windows thing. qlocale_win calls windows API 
> getLocaleInfo(LOCALE_SNATIVELANGUAGENAME) ( 
> https://msdn.microsoft.com/en-us/library/windows/desktop/dd373863%28v=vs.85%29.aspx
>  ). So Qt Developers would probably (and rightly) say "This is a Windows bug" 
> and Indeed this might be fixed at some point in the far Future in Windows.
> 
> But my Observation is Qt does not (and for Windows apparently can not) 
> guarantee that QLocale::nativeLanguageName is not Empty. So KXmlGui should 
> try to handle this. As I don't know how this is for other platforms and it 
> only adds a tiny overhead I also don't think this should be Ifdefed for 
> Windows.

well, reading the documentation of the function never mentions it can be empty, 
and given all languages probably have a way to call themselves I as an api user 
find it surprising it returns empty. 

sure I can agree it is a Windows bug, but why workaround it in every single 
call to nativeLanguageName instead of inside Qt code? 

I mean, we probably even have this problem in other KDE code.

And sure, Qt takes a while to update/release so temporarily we may want this 
workaround committed so our users get the fix earlier but I would really 
appreciate if you could create a MR for Qt that either documents that 
nativeLanguageName can return empty or one that makes sure it is not empty by 
doing the same fallback we do here.


- Albert


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


On feb. 22, 2016, 9:52 a.m., Andre Heinecke wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/127136/
> ---
> 
> (Updated feb. 22, 2016, 9:52 a.m.)
> 
> 
> Review request for KDE Frameworks.
> 
> 
> Repository: kxmlgui
> 
> 
> Description
> ---
> 
> While packaging Kleopatra's translations for Gpg4win I've noticed that there 
> were blank entries in the Switchlanguagedialog.
> Apperantly QLocale::nativeLanguageName can return an Empty string (Qt 5.5 on 
> Windows).
> 
> This patch handles this and uses the non native QLocale::languageToString as 
> a fallback. The idea is that a non native Name is better then no name (and a 
> blank entry in the dialog) at all.
> 
> Ideally every language would have a native name but until this is the case I 
> think this fallback makes sense.
> 
> 
> Diffs
> -
> 
>   src/kswitchlanguagedialog_p.cpp 039daea 
> 
> Diff: https://git.reviewboard.kde.org/r/127136/diff/
> 
> 
> Testing
> ---
> 
> See attached screenshots of Kleopatra's switchlanguage dialog before and 
> after the patch. Low German is an example where the native name was empty.
> 
> 
> File Attachments
> 
> 
> Dialog before the patch
>   
> https://git.reviewboard.kde.org/media/uploaded/files/2016/02/22/a6a31417-1ad6-432e-bee9-65a367fac28d__languages_before.png
> Dialog after the patch
>   
> https://git.reviewboard.kde.org/media/uploaded/files/2016/02/22/762062c5-ff18-47da-aeb0-93b16ca28883__languages_after.png
> 
> 
> Thanks,
> 
> Andre Heinecke
> 
>

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

Re: Review Request 127136: XmlGui: Use non native Language name as fallback in KSwitchlangaugeDialog

[Albert Astals Cid]

> On Feb. 22, 2016, 9:55 a.m., Albert Astals Cid wrote:
> > I'd prefer if you could fix this at the Qt level, why would 
> > nativeLanguageName ever return empty?
> 
> Andre Heinecke wrote:
> I've just checked. It's a Windows thing. qlocale_win calls windows API 
> getLocaleInfo(LOCALE_SNATIVELANGUAGENAME) ( 
> https://msdn.microsoft.com/en-us/library/windows/desktop/dd373863%28v=vs.85%29.aspx
>  ). So Qt Developers would probably (and rightly) say "This is a Windows bug" 
> and Indeed this might be fixed at some point in the far Future in Windows.
> 
> But my Observation is Qt does not (and for Windows apparently can not) 
> guarantee that QLocale::nativeLanguageName is not Empty. So KXmlGui should 
> try to handle this. As I don't know how this is for other platforms and it 
> only adds a tiny overhead I also don't think this should be Ifdefed for 
> Windows.
> 
> Albert Astals Cid wrote:
> well, reading the documentation of the function never mentions it can be 
> empty, and given all languages probably have a way to call themselves I as an 
> api user find it surprising it returns empty. 
> 
> sure I can agree it is a Windows bug, but why workaround it in every 
> single call to nativeLanguageName instead of inside Qt code? 
> 
> I mean, we probably even have this problem in other KDE code.
> 
> And sure, Qt takes a while to update/release so temporarily we may want 
> this workaround committed so our users get the fix earlier but I would really 
> appreciate if you could create a MR for Qt that either documents that 
> nativeLanguageName can return empty or one that makes sure it is not empty by 
> doing the same fallback we do here.
> 
> Andre Heinecke wrote:
> I'm not a qt contributor and this issue is not important enough to me to 
> spend the time with this. I'm pretty unwilling to work more on this. It would 
> be easier just dropping the exotic languages for which this problem exists. 
> (Although I really love the Plattdeutsch localisation of Kleopatra ;-) )
> As a compromoise I've reported a bug 
> https://bugreports.qt.io/browse/QTBUG-51323 and mentioned this in the patch.
> 
> The only other usages of nativeLanguageName in frameworks are sonnet and 
> kconfigwidgets/klanguagebutton.

Ok, any chance I can convince you to propose patches for those uses of 
nativeLanguageName too?

I guess you can commit this xmlgui patch, i'm not the maintainer though, so i'd 
say wait a few days in case anyone else has a comment and i not commit.


- Albert


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


On Feb. 23, 2016, 3:16 p.m., Andre Heinecke wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/127136/
> ---
> 
> (Updated Feb. 23, 2016, 3:16 p.m.)
> 
> 
> Review request for KDE Frameworks.
> 
> 
> Repository: kxmlgui
> 
> 
> Description
> ---
> 
> While packaging Kleopatra's translations for Gpg4win I've noticed that there 
> were blank entries in the Switchlanguagedialog.
> Apperantly QLocale::nativeLanguageName can return an Empty string (Qt 5.5 on 
> Windows).
> 
> This patch handles this and uses the non native QLocale::languageToString as 
> a fallback. The idea is that a non native Name is better then no name (and a 
> blank entry in the dialog) at all.
> 
> Ideally every language would have a native name but until this is the case I 
> think this fallback makes sense.
> 
> 
> Diffs
> -
> 
>   src/kswitchlanguagedialog_p.cpp 039daea 
> 
> Diff: https://git.reviewboard.kde.org/r/127136/diff/
> 
> 
> Testing
> ---
> 
> See attached screenshots of Kleopatra's switchlanguage dialog before and 
> after the patch. Low German is an example where the native name was empty.
> 
> 
> File Attachments
> 
> 
> Dialog before the patch
>   
> https://git.reviewboard.kde.org/media/uploaded/files/2016/02/22/a6a31417-1ad6-432e-bee9-65a367fac28d__languages_before.png
> Dialog after the patch
>   
> https://git.reviewboard.kde.org/media/uploaded/files/2016/02/22/762062c5-ff18-47da-aeb0-93b16ca28883__languages_after.png
> 
> 
> Thanks,
> 
> Andre Heinecke
> 
>

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

Re: QString -> QStringLiteral conversions might make applications crash on exit

[Albert Astals Cid]

El Friday 26 February 2016, a les 01:37:57, Frank Reininghaus va escriure:
> Hi everyone,
> 
> sorry if most of you know about this already, but since it seems that
> QStringLiterals are being introduced everywhere right now, I think
> that it is important to raise awareness about the fact that this might
> be more dangerous that it seems at first sight.
> 
> QStringLiteral has the nice property that it stores the string data in
> read-only memory and avoids heap allocations when it is used to
> construct a QString. The QString, and any copies that are made, just
> contain a pointer to read-only data. There is a very nice overview by
> Olivier at
> 
> https://woboq.com/blog/qstringliteral.html
> 
> However, QString is still a non-POD type, even if it has been
> constructed with QStringLiteral (or copied from such a QString), so
> its destructor is being run, which accesses the read-only data, then
> finds out that it's been made with QStringLiteral, such that no
> refcount updates and deallocations are needed.
> 
> This becomes a problem if the read-only data that the QString refers
> to are not there any more, which can happen if the QString was stored
> in a global static object from one library, and the QStringLiteral is
> from another library, which might have been unloaded before the global
> static object was destroyed.
> 
> I believe that this is just what happens right now with a global
> static KIconLoader from kicontnkhemes and a QStringLiteral from
> frameworkintegration:
> 
> https://bugs.kde.org/show_bug.cgi?id=359758
> 
> If my analysis is wrong, please let me know!

If you know what commit causes it I'd say you have two options:
 * Find exactly which of the changes in the patch is causing the problem, add 
a test case that crashes and then commit the smallest change that fixes the 
crash
 * Revert the commit and CC the person that did the commit asking him to be 
more careful.

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

Re: CMake Error when building attica

[Albert Astals Cid]

Works here, cc'ing the build-system and frameworks lists in case someone gets 
an idea of what may be wrong from the log.

Cheers,
  Albert

El Monday 29 February 2016, a les 22:26:49, Nilesh Kokane va escriure:
> Hello,
> 
> While building attica-5.19.0 cmake threw the following error.
> 
> -- 
> 
> CMake Error at /usr/local/share/ECM/modules/ECMPackageConfigHelpers.cmake:95
> (file):
>   file RELATIVE_PATH must be passed a full path to the file:
> Call Stack (most recent call first):
>   CMakeLists.txt:55 (ecm_configure_package_config_file)
> 
> 
> -- 
> -- The following REQUIRED packages have been found:
> 
>  * ECM (required version >= 5.19.0) , Extra CMake Modules. ,
> 
>  * Qt5Core
>  * Qt5Network
>  * Qt5 (required version >= 5.3.0)
> 
> -- Configuring incomplete, errors occurred!
> See also
> "/home/nilesh/development/lfs/attica-5.19.0/build/CMakeFiles/CMakeOutput.lo
> g". See also
> "/home/nilesh/development/lfs/attica-5.19.0/build/CMakeFiles/CMakeError.log
> ".
> 
> 
> My input switch to cmake is
> 
>   cmake -DCMAKE_INSTALL_PREFIX=$KF5_PREFIX  \
>   -DCMAKE_BUILD_TYPE=Release\
> ..
> 
> $echo $KF5_PREFIX
> /opt/kf5
> 
> 
> But thats not the case with attica-5.18.0 ,it builds successfully.
> I've updated ECM and cmake.
> 
> Am I missing something?
> 
> Please spare me if this is not the rite mailing list for this.
> 
> 
> 
>  Nilesh Kokane

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

Re: Qt5 version of qimageblitz

[Albert Astals Cid]

El Sunday 06 March 2016, a les 08:38:14, Boudhayan Gupta va escriure:
> On 6 March 2016 at 01:26, Martin Koller  wrote:
> > Who is in charge of the old SVN repos ?
> > Who is in charge of qimageblitz ?
> 
> I asked around on IRC and it seems QIB is "community maintained" and
> as such doesn't have a maintainer.
> 
> You should just be able to file a sysadmin ticket to get it migrated
> from SVN to Git.

It was my understanding that qimageblitz is actually not something we want to 
port to Qt5 and we should just try to use Qt's own stuff for this.

If qimageblitz gets ported to Qt5 it should basically be a Tier 0 frameworks 
so CC'ing the frameworks devel list.

Cheers,
  Albert

> 
> -- Boudhayan Gupta

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

Re: Qt5 version of qimageblitz

[Albert Astals Cid]

El Tuesday 08 March 2016, a les 17:55:30, Ben Cooksley va escriure:
> On Tue, Mar 8, 2016 at 8:11 AM, Martin Koller  wrote:
> > On Sunday 06 March 2016 08:38:14 Boudhayan Gupta wrote:
> >> On 6 March 2016 at 01:26, Martin Koller  wrote:
> >> > Who is in charge of the old SVN repos ?
> >> > Who is in charge of qimageblitz ?
> >> 
> >> I asked around on IRC and it seems QIB is "community maintained" and
> >> as such doesn't have a maintainer.
> >> 
> >> You should just be able to file a sysadmin ticket to get it migrated
> >> from SVN to Git.
> > 
> > I started to create a sysadmin ticket, but I don't know
> > - "Initial maintainer identity user names, separated by ;"
> 
> Not sure how this can be clearer
> Username in this case is the same as the one in kde-common/accounts.
> 
> > - "Intended location on projects.kde.org, "
> 
> This is the location in the legacy tree.

I guess for that we need to decide if it should be a framework first or not.

Cheers,
  Albert

> 
> Cheers,
> Ben
> 
> > --
> > Best regards/Schöne Grüße
> > 
> > Martin
> > A: Because it breaks the logical sequence of discussion
> > Q: Why is top posting bad?
> > 
> > ()  ascii ribbon campaign - against html e-mail
> > /\- against proprietary attachments
> > 
> > Geschenkideen, Accessoires, Seifen, Kulinarisches: www.lillehus.at

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

Re: Raising Qt requirement to Qt 5.4

[Albert Astals Cid]

El dimecres, 16 de març de 2016, a les 13:13:36 CET, Martin Graesslin va 
escriure:
> Hi all,
> 
> with todays release of Qt 5.6 I suggest that we raise the minimum Qt version
> requirement to 5.4. This would mean the latest three releases are
> supported.
> 
> The important new features in Qt 5.4 in my opinion for frameworks
> development are:
> * QSignalSpy(const QObject *object, PointerToMemberFunction signal)
> * Q_LOGGING_CATEGORY(name, string, msgType)
> 
> Which are already used in many frameworks and currently ifdefed.
> 
> Opinions?

Is there anything else? These two seem "nice to have" but nothing that would 
hinder development of the frameworks.

Cheers,
  Albert

> 
> Best Regards
> Martin


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

Re: Review Request 127398: Add unit tests for KNotification and fix a whole bunch of issues uncovered thanks to them

[Albert Astals Cid]

> On March 18, 2016, 5:20 a.m., Anthony Fieroni wrote:
> > src/knotification.cpp, line 63
> > 
> >
> > ref can't be UINT_MAX, but id can, no? Negative rage will brake all, 
> > it's this possible, maybe not. Counters it's not good idea to be signed.
> 
> Martin Klapetek wrote:
> Yes...if your application will emit more than 32767 notifications in its 
> lifetime. At which point the application is probalby broken.

Is it? I don't use KTP, but assuming KTP sends Knotifications and assuming you 
get like 1 chat notification per minute (not crazy imho) get say around 500 
notifications per day, so in 66 days you'd go over the limit. Sure it's 
corner-case-y but i would not call it impossible nor the app being broken


- Albert


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


On March 16, 2016, 8:23 p.m., Martin Klapetek wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/127398/
> ---
> 
> (Updated March 16, 2016, 8:23 p.m.)
> 
> 
> Review request for KDE Frameworks.
> 
> 
> Repository: knotifications
> 
> 
> Description
> ---
> 
> Adds basic set of unit tests including fake notifications server.
> 
> This helped uncover and fix these issues:
> 
> * Calling close() on KNotification that was not "sent" would not emit 
> closed() and would not delete it
> * Closing a notification can delete the KNotification object prematurely
> * Invoking an action leads to unnecessary dbus roundtrip
> * Invoking an action would fail to properly close and delete the 
> KNotification object
> 
> 
> Diffs
> -
> 
>   CMakeLists.txt 6d09051 
>   autotests/CMakeLists.txt PRE-CREATION 
>   autotests/fake_notifications_server.h PRE-CREATION 
>   autotests/fake_notifications_server.cpp PRE-CREATION 
>   autotests/knotification_test.cpp PRE-CREATION 
>   autotests/knotifications5/qttest.notifyrc PRE-CREATION 
>   autotests/qtest_dbus.h PRE-CREATION 
>   src/knotification.cpp 17b0be2 
>   src/knotificationmanager.cpp e80d48c 
>   src/knotificationplugin.cpp acf964c 
>   src/notifybypopup.cpp b9489c1 
> 
> Diff: https://git.reviewboard.kde.org/r/127398/diff/
> 
> 
> Testing
> ---
> 
> Unit tests all pass.
> 
> 
> Thanks,
> 
> Martin Klapetek
> 
>

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

Re: Review Request 127398: Add unit tests for KNotification and fix a whole bunch of issues uncovered thanks to them

[Albert Astals Cid]

> On March 18, 2016, 5:20 a.m., Anthony Fieroni wrote:
> > src/knotification.cpp, line 63
> > <https://git.reviewboard.kde.org/r/127398/diff/1/?file=453383#file453383line63>
> >
> > ref can't be UINT_MAX, but id can, no? Negative rage will brake all, 
> > it's this possible, maybe not. Counters it's not good idea to be signed.
> 
> Martin Klapetek wrote:
> Yes...if your application will emit more than 32767 notifications in its 
> lifetime. At which point the application is probalby broken.
> 
> Albert Astals Cid wrote:
> Is it? I don't use KTP, but assuming KTP sends Knotifications and 
> assuming you get like 1 chat notification per minute (not crazy imho) get say 
> around 500 notifications per day, so in 66 days you'd go over the limit. Sure 
> it's corner-case-y but i would not call it impossible nor the app being broken
> 
> Martin Klapetek wrote:
> This wouldn't actually break in the KTp case (in normal KNotification 
> usage, the id is not really needed), however this code (going back to 2009) 
> apparently chose real-life pragmatism over such corner cases.
> 
> To expand on that, the id uses values -1 and -2 to indicate "invalid" and 
> "about to be deleted" states. I can either introduce some bool/enum making 
> every "if (..)" twice as complicated, or start the counter from 2, reserving 
> 0 and 1. Tbh given this wasn't a problem for the past 7 years, I don't think 
> the code needs to be more complex making special assumptions for highly 
> unlikely corner cases.

ok, a bug to fix/discuss later in time :)


- Albert


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


On March 16, 2016, 8:23 p.m., Martin Klapetek wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/127398/
> ---
> 
> (Updated March 16, 2016, 8:23 p.m.)
> 
> 
> Review request for KDE Frameworks.
> 
> 
> Repository: knotifications
> 
> 
> Description
> ---
> 
> Adds basic set of unit tests including fake notifications server.
> 
> This helped uncover and fix these issues:
> 
> * Calling close() on KNotification that was not "sent" would not emit 
> closed() and would not delete it
> * Closing a notification can delete the KNotification object prematurely
> * Invoking an action leads to unnecessary dbus roundtrip
> * Invoking an action would fail to properly close and delete the 
> KNotification object
> 
> 
> Diffs
> -
> 
>   CMakeLists.txt 6d09051 
>   autotests/CMakeLists.txt PRE-CREATION 
>   autotests/fake_notifications_server.h PRE-CREATION 
>   autotests/fake_notifications_server.cpp PRE-CREATION 
>   autotests/knotification_test.cpp PRE-CREATION 
>   autotests/knotifications5/qttest.notifyrc PRE-CREATION 
>   autotests/qtest_dbus.h PRE-CREATION 
>   src/knotification.cpp 17b0be2 
>   src/knotificationmanager.cpp e80d48c 
>   src/knotificationplugin.cpp acf964c 
>   src/notifybypopup.cpp b9489c1 
> 
> Diff: https://git.reviewboard.kde.org/r/127398/diff/
> 
> 
> Testing
> ---
> 
> Unit tests all pass.
> 
> 
> Thanks,
> 
> Martin Klapetek
> 
>

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

Re: Raising Qt requirement to Qt 5.4

[Albert Astals Cid]

El diumenge, 20 de març de 2016, a les 10:12:14 CET, David Faure va escriure:
> On Friday 18 March 2016 20:16:05 Ivan Čukić wrote:
> > Hi all,
> > 
> > IIRC, the last time we talked about this we decided (I'll try to find
> > the e-mail thread when I get back home, IIRC the conclusion was by
> > dfaure) on KF5 always support the two last versions of Qt. This was
> > decided so that we do not need to have threads like these every time
> > we want to increase the Qt version.
> 
> *Three* last versions.
> 
> Which is why we can drop 5.3 now that 5.6 is out
>  => we support 5.4, 5.5 and 5.6.

Is this documented in some wiki so we don't have to rely on people's memories 
or someone digging up the corresponding email thread?

Cheers,
  Albert

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

Review Request 127501: Improve TCPSlaveBase::isConnected

[Albert Astals Cid]

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

Review request for KDE Frameworks.


Repository: kio


Description
---

Qt sockets returns ConnectedState even when error is set to 
RemoteHostClosedError after a write operation.

So make ::isConnected also check for RemoteHostClosedError.

This has the consequence that we have to create/delete the socket since Qt 
sockets have no way to reset their error state so if we want to reuse the slave 
to connect again it will never work with the same socket since it will always 
say RemoteHostClosedError.

I need this for https://git.reviewboard.kde.org/r/127502/


Diffs
-

  src/core/tcpslavebase.cpp b9be69d 

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


Testing
---

Seesms to work fine and the pop3 bugfix i have also works fine.


Thanks,

Albert Astals Cid

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

Re: Review Request 127501: Improve TCPSlaveBase::isConnected

[Albert Astals Cid]

> On March 27, 2016, 10:03 a.m., David Faure wrote:
> > Given how the socket API works, you should only call error() after a call 
> > that returns false (e.g. waitForConnected, etc.). As you found out, calling 
> > error() at random points in time doesn't give useful information, you get 
> > the last error that was ever set, even after 10 successful calls following 
> > the call that had an error.
> > 
> > Calling setError ourselves is a workaround, which doesn't fit with the Qt 
> > socket API (there is no "No error" error code).
> > UnknownSocketError *means* error, it doesn't mean no error.
> > 
> > It seems to me (from the description, I didn't read the code attentively) 
> > that the right solution is to actually disconnect after a 
> > RemoteHostClosedError. Then the state won't be ConnectedState anymore, and 
> > isConnected() will work as intended :-)

But it won't, even if you disconnect, the error will still be 
RemoteHostClosedError given that Qt does not reset the error after 
disconnectFromHost (since there's basically no way to mark "no error"), so if 
we reconnect after disconnection we will still have RemoteHostClosedError if we 
ask for the error even if it's not true for this session. Of you mean this in 
connection with the above hack?


- Albert


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


On March 26, 2016, 5:29 p.m., Albert Astals Cid wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/127501/
> ---
> 
> (Updated March 26, 2016, 5:29 p.m.)
> 
> 
> Review request for KDE Frameworks.
> 
> 
> Repository: kio
> 
> 
> Description
> ---
> 
> Qt sockets returns ConnectedState even when error is set to 
> RemoteHostClosedError after a write operation.
> 
> So make ::isConnected also check for RemoteHostClosedError.
> 
> This has the consequence that we have to create/delete the socket since Qt 
> sockets have no way to reset their error state so if we want to reuse the 
> slave to connect again it will never work with the same socket since it will 
> always say RemoteHostClosedError.
> 
> I need this for https://git.reviewboard.kde.org/r/127502/
> 
> 
> Diffs
> -
> 
>   src/core/tcpslavebase.cpp b9be69d 
> 
> Diff: https://git.reviewboard.kde.org/r/127501/diff/
> 
> 
> Testing
> ---
> 
> Seesms to work fine and the pop3 bugfix i have also works fine.
> 
> 
> Thanks,
> 
> Albert Astals Cid
> 
>

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

Re: Review Request 127501: Improve TCPSlaveBase::isConnected

[Albert Astals Cid]

> On March 27, 2016, 10:03 a.m., David Faure wrote:
> > Given how the socket API works, you should only call error() after a call 
> > that returns false (e.g. waitForConnected, etc.). As you found out, calling 
> > error() at random points in time doesn't give useful information, you get 
> > the last error that was ever set, even after 10 successful calls following 
> > the call that had an error.
> > 
> > Calling setError ourselves is a workaround, which doesn't fit with the Qt 
> > socket API (there is no "No error" error code).
> > UnknownSocketError *means* error, it doesn't mean no error.
> > 
> > It seems to me (from the description, I didn't read the code attentively) 
> > that the right solution is to actually disconnect after a 
> > RemoteHostClosedError. Then the state won't be ConnectedState anymore, and 
> > isConnected() will work as intended :-)
> 
> Albert Astals Cid wrote:
> But it won't, even if you disconnect, the error will still be 
> RemoteHostClosedError given that Qt does not reset the error after 
> disconnectFromHost (since there's basically no way to mark "no error"), so if 
> we reconnect after disconnection we will still have RemoteHostClosedError if 
> we ask for the error even if it's not true for this session. Of you mean this 
> in connection with the above hack?
> 
> Andreas Hartmetz wrote:
> Yeah, what happens here is working around two API mistakes in QTcpSocket: 
> that there is no proper "no error" code, and that the error isn't cleared 
> when starting a new connection. Apart from settings that may reasonably be 
> persistent like e.g. proxy or buffer size settings, a new connection should 
> behave exactly the same as deleting and recreating the socket. Otherwise the 
> API effectively requires you to delete and recreate a socket to get a clean 
> state, which isn't very nice in such a widely used API. (I sometimes do this 
> in internal interfaces, it's a nice technique to avoid errors in reset and 
> clean up code paths - but it causes a little overhead and more work for 
> consumers)
> Since the check here is for a specific error code, UnknownError works as 
> a code that isn't that specific one. And if we hack the error code reset, we 
> have what we need. I consider that self defense against bad API, not a real 
> hack.
> 
> David Faure wrote:
> My suggestion is about using the API the way it was intended to be used: 
> never calling error() unless a QAbstractSocket method returns false. So 
> definitely not calling error() in isConnected(), but only after specific API 
> calls that return false.
> 
> Albert: if we disconnect, then state() == ConnectedState will be false, 
> and therefore isConnected will return false, as intended.
> No need to call error() in that method.
> 
> Andreas Hartmetz wrote:
> There does seem to be a way to check whether the socket error is for the 
> current connection, sort of... check if the errorString() is empty. That one 
> is cleared on close() and AFAICS also set each time a socket error occurs. It 
> is also never set on its own - every error is a socket error in 
> QAbstractSocket.
> So QAbstractSocket does support lazy error checks, it's just a bit 
> strange.

Andreas, that doesn't work, see the code of QIODevice::errorString

if (d->errorString.isEmpty()) {
#ifdef QT_NO_QOBJECT
return QLatin1String(QT_TRANSLATE_NOOP(QIODevice, "Unknown error"));
#else
    return tr("Unknown error");
#endif
}


- Albert


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


On March 26, 2016, 5:29 p.m., Albert Astals Cid wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/127501/
> ---
> 
> (Updated March 26, 2016, 5:29 p.m.)
> 
> 
> Review request for KDE Frameworks.
> 
> 
> Repository: kio
> 
> 
> Description
> ---
> 
> Qt sockets returns ConnectedState even when error is set to 
> RemoteHostClosedError after a write operation.
> 
> So make ::isConnected also check for RemoteHostClosedError.
> 
> This has the consequence that we have to create/delete the socket since Qt 
> sockets have no way to reset their error state so if we want to reuse the 
> slave to connec

Re: Review Request 127501: Improve TCPSlaveBase::isConnected

[Albert Astals Cid]

> On March 27, 2016, 10:03 a.m., David Faure wrote:
> > Given how the socket API works, you should only call error() after a call 
> > that returns false (e.g. waitForConnected, etc.). As you found out, calling 
> > error() at random points in time doesn't give useful information, you get 
> > the last error that was ever set, even after 10 successful calls following 
> > the call that had an error.
> > 
> > Calling setError ourselves is a workaround, which doesn't fit with the Qt 
> > socket API (there is no "No error" error code).
> > UnknownSocketError *means* error, it doesn't mean no error.
> > 
> > It seems to me (from the description, I didn't read the code attentively) 
> > that the right solution is to actually disconnect after a 
> > RemoteHostClosedError. Then the state won't be ConnectedState anymore, and 
> > isConnected() will work as intended :-)
> 
> Albert Astals Cid wrote:
> But it won't, even if you disconnect, the error will still be 
> RemoteHostClosedError given that Qt does not reset the error after 
> disconnectFromHost (since there's basically no way to mark "no error"), so if 
> we reconnect after disconnection we will still have RemoteHostClosedError if 
> we ask for the error even if it's not true for this session. Of you mean this 
> in connection with the above hack?
> 
> Andreas Hartmetz wrote:
> Yeah, what happens here is working around two API mistakes in QTcpSocket: 
> that there is no proper "no error" code, and that the error isn't cleared 
> when starting a new connection. Apart from settings that may reasonably be 
> persistent like e.g. proxy or buffer size settings, a new connection should 
> behave exactly the same as deleting and recreating the socket. Otherwise the 
> API effectively requires you to delete and recreate a socket to get a clean 
> state, which isn't very nice in such a widely used API. (I sometimes do this 
> in internal interfaces, it's a nice technique to avoid errors in reset and 
> clean up code paths - but it causes a little overhead and more work for 
> consumers)
> Since the check here is for a specific error code, UnknownError works as 
> a code that isn't that specific one. And if we hack the error code reset, we 
> have what we need. I consider that self defense against bad API, not a real 
> hack.
> 
> David Faure wrote:
> My suggestion is about using the API the way it was intended to be used: 
> never calling error() unless a QAbstractSocket method returns false. So 
> definitely not calling error() in isConnected(), but only after specific API 
> calls that return false.
> 
> Albert: if we disconnect, then state() == ConnectedState will be false, 
> and therefore isConnected will return false, as intended.
> No need to call error() in that method.
> 
> Andreas Hartmetz wrote:
> There does seem to be a way to check whether the socket error is for the 
> current connection, sort of... check if the errorString() is empty. That one 
> is cleared on close() and AFAICS also set each time a socket error occurs. It 
> is also never set on its own - every error is a socket error in 
> QAbstractSocket.
> So QAbstractSocket does support lazy error checks, it's just a bit 
> strange.
> 
> Albert Astals Cid wrote:
> Andreas, that doesn't work, see the code of QIODevice::errorString
> 
> if (d->errorString.isEmpty()) {
> #ifdef QT_NO_QOBJECT
> return QLatin1String(QT_TRANSLATE_NOOP(QIODevice, "Unknown 
> error"));
> #else
> return tr("Unknown error");
> #endif
> }

> My suggestion is about using the API the way it was intended to be used: 
> never calling error() unless a QAbstractSocket method returns false. So 
> definitely not calling error() in isConnected(), but only after specific API 
> calls that return false.

You can not do that, there's no API call that will return false in this case, 
socket.write returns a valid number of bytes, waitForBytesWritten returns true, 
but if you ask for the error after that, it has been set to 
RemoteHostClosedError, you may argue that is a bug in Qt and that calling 
waitForBytesWritten should properly return false if the calls to 
QAbstractSocketPrivate::canReadNotification, 
QAbstractSocketPrivate::readFromSocket and QNativeSocketEngine::read end up 
setting an error.

> Albert: if we disconnect, then state() == ConnectedState will be false, and 
> therefore isConnected will return false, as intended. No need to call error() 
> in that method.

Yes, we could do that and it would fix isConnected for the first time, 

Re: Review Request 127501: Improve TCPSlaveBase::isConnected

[Albert Astals Cid]

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

(Updated March 31, 2016, 8:01 p.m.)


Status
--

This change has been discarded.


Review request for KDE Frameworks.


Repository: kio


Description
---

Qt sockets returns ConnectedState even when error is set to 
RemoteHostClosedError after a write operation.

So make ::isConnected also check for RemoteHostClosedError.

This has the consequence that we have to create/delete the socket since Qt 
sockets have no way to reset their error state so if we want to reuse the slave 
to connect again it will never work with the same socket since it will always 
say RemoteHostClosedError.

I need this for https://git.reviewboard.kde.org/r/127502/


Diffs
-

  src/core/tcpslavebase.cpp b9be69d 

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


Testing
---

Seesms to work fine and the pop3 bugfix i have also works fine.


Thanks,

Albert Astals Cid

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

Re: Review Request 127501: Improve TCPSlaveBase::isConnected

[Albert Astals Cid]

> On March 27, 2016, 10:03 a.m., David Faure wrote:
> > Given how the socket API works, you should only call error() after a call 
> > that returns false (e.g. waitForConnected, etc.). As you found out, calling 
> > error() at random points in time doesn't give useful information, you get 
> > the last error that was ever set, even after 10 successful calls following 
> > the call that had an error.
> > 
> > Calling setError ourselves is a workaround, which doesn't fit with the Qt 
> > socket API (there is no "No error" error code).
> > UnknownSocketError *means* error, it doesn't mean no error.
> > 
> > It seems to me (from the description, I didn't read the code attentively) 
> > that the right solution is to actually disconnect after a 
> > RemoteHostClosedError. Then the state won't be ConnectedState anymore, and 
> > isConnected() will work as intended :-)
> 
> Albert Astals Cid wrote:
> But it won't, even if you disconnect, the error will still be 
> RemoteHostClosedError given that Qt does not reset the error after 
> disconnectFromHost (since there's basically no way to mark "no error"), so if 
> we reconnect after disconnection we will still have RemoteHostClosedError if 
> we ask for the error even if it's not true for this session. Of you mean this 
> in connection with the above hack?
> 
> Andreas Hartmetz wrote:
> Yeah, what happens here is working around two API mistakes in QTcpSocket: 
> that there is no proper "no error" code, and that the error isn't cleared 
> when starting a new connection. Apart from settings that may reasonably be 
> persistent like e.g. proxy or buffer size settings, a new connection should 
> behave exactly the same as deleting and recreating the socket. Otherwise the 
> API effectively requires you to delete and recreate a socket to get a clean 
> state, which isn't very nice in such a widely used API. (I sometimes do this 
> in internal interfaces, it's a nice technique to avoid errors in reset and 
> clean up code paths - but it causes a little overhead and more work for 
> consumers)
> Since the check here is for a specific error code, UnknownError works as 
> a code that isn't that specific one. And if we hack the error code reset, we 
> have what we need. I consider that self defense against bad API, not a real 
> hack.
> 
> David Faure wrote:
> My suggestion is about using the API the way it was intended to be used: 
> never calling error() unless a QAbstractSocket method returns false. So 
> definitely not calling error() in isConnected(), but only after specific API 
> calls that return false.
> 
> Albert: if we disconnect, then state() == ConnectedState will be false, 
> and therefore isConnected will return false, as intended.
> No need to call error() in that method.
> 
> Andreas Hartmetz wrote:
> There does seem to be a way to check whether the socket error is for the 
> current connection, sort of... check if the errorString() is empty. That one 
> is cleared on close() and AFAICS also set each time a socket error occurs. It 
> is also never set on its own - every error is a socket error in 
> QAbstractSocket.
> So QAbstractSocket does support lazy error checks, it's just a bit 
> strange.
> 
> Albert Astals Cid wrote:
> Andreas, that doesn't work, see the code of QIODevice::errorString
> 
> if (d->errorString.isEmpty()) {
> #ifdef QT_NO_QOBJECT
> return QLatin1String(QT_TRANSLATE_NOOP(QIODevice, "Unknown 
> error"));
> #else
> return tr("Unknown error");
> #endif
> }
> 
> Albert Astals Cid wrote:
> > My suggestion is about using the API the way it was intended to be 
> used: never calling error() unless a QAbstractSocket method returns false. So 
> definitely not calling error() in isConnected(), but only after specific API 
> calls that return false.
> 
> You can not do that, there's no API call that will return false in this 
> case, socket.write returns a valid number of bytes, waitForBytesWritten 
> returns true, but if you ask for the error after that, it has been set to 
> RemoteHostClosedError, you may argue that is a bug in Qt and that calling 
> waitForBytesWritten should properly return false if the calls to 
> QAbstractSocketPrivate::canReadNotification, 
> QAbstractSocketPrivate::readFromSocket and QNativeSocketEngine::read end up 
> setting an error.
> 
> > Albert: if we disconnect, then state() == ConnectedState will be false, 
> and therefore isConnected will return false, as intende

Re: Review Request 127632: Prioritize correct extension per theme

[Albert Astals Cid]

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



I'm unconvinced, actually the spec mentions order to be "Changed search order 
to png, svg, xpm"

- Albert Astals Cid


On April 10, 2016, 11:05 p.m., Aleix Pol Gonzalez wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/127632/
> ---
> 
> (Updated April 10, 2016, 11:05 p.m.)
> 
> 
> Review request for KDE Frameworks and Christoph Feck.
> 
> 
> Repository: kiconthemes
> 
> 
> Description
> ---
> 
> Usually themes will have 1 kind of extension (2 tops) it doesn't make sense 
> to bindly use an extensions vector that is statically defined.
> 
> Prioritizes the extensions that work, so it will find the icons sooner.
> 
> 
> Diffs
> -
> 
>   src/kiconloader.cpp 37528ad 
>   src/kicontheme.h 3190665 
>   src/kicontheme.cpp e7e003b 
> 
> Diff: https://git.reviewboard.kde.org/r/127632/diff/
> 
> 
> Testing
> ---
> 
> Builds and tests still pass.
> Also reducess faulty disk accesses to its 45%. Note that by this metric, it's 
> almost as good as the RR #127236, but with a much smaller memory impact, 
> since we're not caching all the icon names (which was specially bad as it was 
> per-process).
> ```
> $ strace kwrite |& grep ENOENT | wc -l
> 4699
> $ strace kwrite |& grep ENOENT | wc -l
> 2119
> ```
> 
> 
> 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 127632: Prioritize correct extension per theme

[Albert Astals Cid]

> On April 11, 2016, 10:44 p.m., Albert Astals Cid wrote:
> > I'm unconvinced, actually the spec mentions order to be "Changed search 
> > order to png, svg, xpm"

https://specifications.freedesktop.org/icon-theme-spec/icon-theme-spec-latest.html


- Albert


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


On April 10, 2016, 11:05 p.m., Aleix Pol Gonzalez wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/127632/
> ---
> 
> (Updated April 10, 2016, 11:05 p.m.)
> 
> 
> Review request for KDE Frameworks and Christoph Feck.
> 
> 
> Repository: kiconthemes
> 
> 
> Description
> ---
> 
> Usually themes will have 1 kind of extension (2 tops) it doesn't make sense 
> to bindly use an extensions vector that is statically defined.
> 
> Prioritizes the extensions that work, so it will find the icons sooner.
> 
> 
> Diffs
> -
> 
>   src/kiconloader.cpp 37528ad 
>   src/kicontheme.h 3190665 
>   src/kicontheme.cpp e7e003b 
> 
> Diff: https://git.reviewboard.kde.org/r/127632/diff/
> 
> 
> Testing
> ---
> 
> Builds and tests still pass.
> Also reducess faulty disk accesses to its 45%. Note that by this metric, it's 
> almost as good as the RR #127236, but with a much smaller memory impact, 
> since we're not caching all the icon names (which was specially bad as it was 
> per-process).
> ```
> $ strace kwrite |& grep ENOENT | wc -l
> 4699
> $ strace kwrite |& grep ENOENT | wc -l
> 2119
> ```
> 
> 
> 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 127632: Prioritize correct extension per theme

[Albert Astals Cid]

> On April 11, 2016, 10:44 p.m., Albert Astals Cid wrote:
> > I'm unconvinced, actually the spec mentions order to be "Changed search 
> > order to png, svg, xpm"
> 
> Albert Astals Cid wrote:
> 
> https://specifications.freedesktop.org/icon-theme-spec/icon-theme-spec-latest.html
> 
> Aleix Pol Gonzalez wrote:
> I see, I didn't know that. Still, I believe we should adopt the patch for 
> better performance.
> 
> This will be a problem only if there's some icons that are in svg (or 
> xpm) and not in png, but the rest do have png.

Honestly i'd prefer adding an extension to the .desktop of the icon theme 
called X-KDE-Extensions that lists the order in which extensions are checked 
and that for our themes we just set to svg. But if other people think adhering 
to the spec is not important i can live with it too.


- Albert


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


On April 11, 2016, 11:17 p.m., Aleix Pol Gonzalez wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/127632/
> ---
> 
> (Updated April 11, 2016, 11:17 p.m.)
> 
> 
> Review request for KDE Frameworks and Christoph Feck.
> 
> 
> Repository: kiconthemes
> 
> 
> Description
> ---
> 
> Usually themes will have 1 kind of extension (2 tops) it doesn't make sense 
> to bindly use an extensions vector that is statically defined.
> 
> Prioritizes the extensions that work, so it will find the icons sooner.
> 
> 
> Diffs
> -
> 
>   src/kiconloader.cpp 37528ad 
>   src/kicontheme.h 3190665 
>   src/kicontheme.cpp e7e003b 
> 
> Diff: https://git.reviewboard.kde.org/r/127632/diff/
> 
> 
> Testing
> ---
> 
> Builds and tests still pass.
> Also reducess faulty disk accesses to its 45%. Note that by this metric, it's 
> almost as good as the RR #127236, but with a much smaller memory impact, 
> since we're not caching all the icon names (which was specially bad as it was 
> per-process).
> ```
> $ strace kwrite |& grep ENOENT | wc -l
> 4699
> $ strace kwrite |& grep ENOENT | wc -l
> 2119
> ```
> 
> 
> Thanks,
> 
> Aleix Pol Gonzalez
> 
>

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

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

[Albert Astals Cid]

El dilluns, 25 d’abril de 2016, a les 9:05:58 CEST, Ben Cooksley va escriure:
> On Sun, Apr 24, 2016 at 11:46 AM, Michael Pyne  wrote:
> > On Sat, April 23, 2016 13:09:00 Ben Cooksley wrote:
> >> On Sat, Apr 23, 2016 at 1:04 PM, Daniel Vrátil  wrote:
> >> > any chance to get this patch into our Qt build on the CI since it has
> >> > been
> >> > integrated upstream now? As it affects all tests that interact with
> >> > DBus
> >> > it
> >> > would be nice to resolve this on the CI.
> >> 
> >> We'll need upstream to update qt5.git (I think that's still required
> >> for changes to fully flow through) I think.
> >> We could try to hack the patch in, but then we'll end up having to
> >> undo that in a few weeks time.
> > 
> > If we're talking about Qt commit 1b9d082b, that appears to already be in
> > the 5.6 branch (though not dev). I'm not sure which the CI uses though,
> > if it's not 5.6 or less then it is probably more work than its worth to
> > try to downgrade (something I've run into too much myself).
> 
> The CI system uses the 5.6 branch, from qt5.git.
> I've now triggered a build, but as qt5.git hasn't been updated since
> our last build I have no idea whether this will pull the relevant
> commit in.

Is there any special reason we inflict ourselves the pain of using qt5.git 
instead of the standalone repos?

Cheers,
  Albert

> 
> > Regards,
> > 
> >  - Michael Pyne
> 
> Cheers,
> Ben
> ___
> Kde-frameworks-devel mailing list
> Kde-frameworks-devel@kde.org
> https://mail.kde.org/mailman/listinfo/kde-frameworks-devel


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

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

[Albert Astals Cid]

I object.
a) I already told you, don't use something nobody else uses, use the separate 
reposb) Not going to happen, but why would it matter at all?

More reasons for it: c) ASAN does not check for things in the library being 
broken or not since it only works on code compiled with ASAN, so the crashes 
are not in the library, they are in your code (if they are because of the 
library being broken or not that's not important, *your* code is the one that 
is going to crash)
 d) Hiding your head in the sand and saying "this is not my fault it's Qt's 
fault" is not going to fix the fact that your code is crashing
 e) We've uncovered bugs that otherwise would have bitten us and nobody would 
have bothered fixing because they would be hardly reproducible, both in our 
code and in Qt's code, that is a *good* thing, not a bad thing.

Let's not move backwards.

Cheers,  Albert

  De: Ben Cooksley 
 Para: Martin Graesslin  
CC: Scarlett Clark ; "kde-frameworks-devel@kde.org" 

 Enviado: Lunes 25 de abril de 2016 9:14
 Asunto: Re: Jenkins-kde-ci: kdbusaddons master kf5-qt5 » Linux, gcc - Build # 
11 - Still Unstable!
   
On Mon, Apr 25, 2016 at 5:59 PM, Martin Graesslin  wrote:
> On Saturday, April 23, 2016 8:48:17 PM CEST Ben Cooksley wrote:
>> On Sat, Apr 23, 2016 at 8:35 PM, Martin Graesslin 
> wrote:
>> > On Saturday, April 23, 2016 1:09:00 PM CEST Ben Cooksley wrote:
>> >> On Sat, Apr 23, 2016 at 1:04 PM, Daniel Vrátil  wrote:
>> >> > On Saturday, April 23, 2016 1:44:16 AM CEST Ben Cooksley wrote:
>> >> >> On Fri, Apr 22, 2016 at 11:11 PM, David Faure  wrote:
>> >> >> > On Thursday 21 April 2016 14:57:52 no-re...@kde.org wrote:
>> >> >> >> GENERAL INFO
>> >> >> >>
>> >> >> >> BUILD UNSTABLE
>> >> >> >> Build URL:
>> >> >> >> https://build.kde.org/job/kdbusaddons%20master%20kf5-qt5/PLATFORM=L
>> >> >> >> inu
>> >> >> >> x,
>> >> >> >> compiler=gcc/11/>
>> >> >> >
>> >> >> > Wow, ASAN detected a real bug in Qt here.
>> >> >> >
>> >> >> > Fixed in https://codereview.qt-project.org/156728
>> >> >>
>> >> >> As this issue essentially breaks any test on the CI system that
>> >> >> depends on Qt I suggest all developers affected by this indicate this
>> >> >> on the relevant reviews.
>> >> >
>> >> > Hey guys,
>> >>
>> >> Hi David,
>> >>
>> >> > any chance to get this patch into our Qt build on the CI since it has
>> >> > been
>> >> > integrated upstream now? As it affects all tests that interact with
>> >> > DBus
>> >> > it
>> >> > would be nice to resolve this on the CI.
>> >>
>> >> We'll need upstream to update qt5.git (I think that's still required
>> >> for changes to fully flow through) I think.
>> >> We could try to hack the patch in, but then we'll end up having to
>> >> undo that in a few weeks time.
>> >
>> > Could we disable that ASAN check please[1]? I have two of my projects
>> > failing due to the DBus problem and one further failing due to a similar
>> > problem in QQuickStyleItem [2]. It's nice that we find errors, but I
>> > rather not have my tests fail due to errors in Qt.
>>
>> That would just cover up the issue.
>
> Yes it would and that's exactly what I want.
>
> To me the CI is currently producing false positives. It started to break from
> one moment to the other. It costs time to look into why it started to fail. It
> means that till that problem is fixed in Qt I cannot trust the CI system. It
> results in nobody noticing real breakage, because the build is broken anyway.
>
> Then there is the problem of responsibility: I look at the output, I have no
> idea why that thing is broken, I have no idea how to build a minimal example
> which would reproduce it, even less on how to fix it. That's just a really bad
> situation to have a CI which can be trusted.
>
> In summary: I don't want spend time to investigate false positives. If an
> option results in false positives, I think that we should disable it.

Understandable.

>
> Of course Qt should get those bugs fixed, but for that Qt should enable ASAN 
> on
> their CI system. If we get libraries which are free of ASAN problems, then we
> can enable it on our side. But false positives are just bad.

Based on this i'm going to assume Qt is not ASAN compliant, and will
therefore be disabling ASAN for all KDE projects across the entire KDE
CI system in 24 hours unless nobody objects.

Objectors can be expected to place pressure on the appropriate
processes within the Qt Project to:
a) Get the necessary changes flowed through into qt5.git so we can
pick them up (the existing process is painfully slow)
b) Get their CI system to check for ASAN issues.

>
> Cheers
> Martin

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


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

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

[Albert Astals Cid]

El dilluns, 25 d’abril de 2016, a les 19:14:00 CEST, Ben Cooksley va escriure:
> On Mon, Apr 25, 2016 at 5:59 PM, Martin Graesslin  
wrote:
> > On Saturday, April 23, 2016 8:48:17 PM CEST Ben Cooksley wrote:
> >> On Sat, Apr 23, 2016 at 8:35 PM, Martin Graesslin 
> > 
> > wrote:
> >> > On Saturday, April 23, 2016 1:09:00 PM CEST Ben Cooksley wrote:
> >> >> On Sat, Apr 23, 2016 at 1:04 PM, Daniel Vrátil  
wrote:
> >> >> > On Saturday, April 23, 2016 1:44:16 AM CEST Ben Cooksley wrote:
> >> >> >> On Fri, Apr 22, 2016 at 11:11 PM, David Faure  
wrote:
> >> >> >> > On Thursday 21 April 2016 14:57:52 no-re...@kde.org wrote:
> >> >> >> >> GENERAL INFO
> >> >> >> >> 
> >> >> >> >> BUILD UNSTABLE
> >> >> >> >> Build URL:
> >> >> >> >> https://build.kde.org/job/kdbusaddons%20master%20kf5-qt5/PLATFOR
> >> >> >> >> M=L
> >> >> >> >> inu
> >> >> >> >> x,
> >> >> >> >> compiler=gcc/11/>
> >> >> >> > 
> >> >> >> > Wow, ASAN detected a real bug in Qt here.
> >> >> >> > 
> >> >> >> > Fixed in https://codereview.qt-project.org/156728
> >> >> >> 
> >> >> >> As this issue essentially breaks any test on the CI system that
> >> >> >> depends on Qt I suggest all developers affected by this indicate
> >> >> >> this
> >> >> >> on the relevant reviews.
> >> >> > 
> >> >> > Hey guys,
> >> >> 
> >> >> Hi David,
> >> >> 
> >> >> > any chance to get this patch into our Qt build on the CI since it
> >> >> > has
> >> >> > been
> >> >> > integrated upstream now? As it affects all tests that interact with
> >> >> > DBus
> >> >> > it
> >> >> > would be nice to resolve this on the CI.
> >> >> 
> >> >> We'll need upstream to update qt5.git (I think that's still required
> >> >> for changes to fully flow through) I think.
> >> >> We could try to hack the patch in, but then we'll end up having to
> >> >> undo that in a few weeks time.
> >> > 
> >> > Could we disable that ASAN check please[1]? I have two of my projects
> >> > failing due to the DBus problem and one further failing due to a
> >> > similar
> >> > problem in QQuickStyleItem [2]. It's nice that we find errors, but I
> >> > rather not have my tests fail due to errors in Qt.
> >> 
> >> That would just cover up the issue.
> > 
> > Yes it would and that's exactly what I want.
> > 
> > To me the CI is currently producing false positives. It started to break
> > from one moment to the other. It costs time to look into why it started
> > to fail. It means that till that problem is fixed in Qt I cannot trust
> > the CI system. It results in nobody noticing real breakage, because the
> > build is broken anyway.
> > 
> > Then there is the problem of responsibility: I look at the output, I have
> > no idea why that thing is broken, I have no idea how to build a minimal
> > example which would reproduce it, even less on how to fix it. That's just
> > a really bad situation to have a CI which can be trusted.
> > 
> > In summary: I don't want spend time to investigate false positives. If an
> > option results in false positives, I think that we should disable it.
> 
> Understandable.
> 
> > Of course Qt should get those bugs fixed, but for that Qt should enable
> > ASAN on their CI system. If we get libraries which are free of ASAN
> > problems, then we can enable it on our side. But false positives are just
> > bad.
> 
> Based on this i'm going to assume Qt is not ASAN compliant, and will
> therefore be disabling ASAN for all KDE projects across the entire KDE
> CI system in 24 hours unless nobody objects.

Instead of an axe let's be more precise and disable the check that's giving us 
problems

https://phabricator.kde.org/D1489

And reenable it in a month.

Cheers,
  Albert

> 
> Objectors can be expected to place pressure on the appropriate
> processes within the Qt Project to:
> a) Get the necessary changes flowed through into qt5.git so we can
> pick them up (the existing process is painfully slow)
> b) Get their CI system to check for ASAN issues.
> 
> > Cheers
> > Martin
> 
> Regards,
> Ben
> ___
> Kde-frameworks-devel mailing list
> Kde-frameworks-devel@kde.org
> https://mail.kde.org/mailman/listinfo/kde-frameworks-devel


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

Re: Review Request 127747: Create a new script that generate the documentation for all projects following the syntax I proposed

[Albert Astals Cid]

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




metainfo.yaml (line 13)
<https://git.reviewboard.kde.org/r/127747/#comment64416>

This is already in line 3, doesn't seem like a good idea to duplicate the 
information.


- Albert Astals Cid


On April 25, 2016, 9:49 p.m., Olivier Churlaud wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/127747/
> ---
> 
> (Updated April 25, 2016, 9:49 p.m.)
> 
> 
> Review request for KDE Frameworks, Albert Astals Cid, Alex Merry, Aurélien 
> Gâteau, and Allen Winter.
> 
> 
> Repository: kapidox
> 
> 
> Description
> ---
> 
> Keep in mind that it should not plainly replace kgenframeworks but be used by 
> all KDE projects. So in this proposition, the Frameworks are just one project 
> in others.
> 
> The code can be tested directly by checking the branch 
> `olivier/generate_all_repos`.
> 
> This MUST NOT be merged in master, because it will break the currents scripts 
> (see commit 3643dded7cf14a5634879e8e6e34be8840143d7e).
> 
> 
> Diffs
> -
> 
>   konqi_frameworks.png PRE-CREATION 
>   metainfo.yaml 4ff17c8 
>   metainfo_syntax.md PRE-CREATION 
>   src/kapidox/data/htmlresource/default_product.png PRE-CREATION 
>   src/kapidox/data/htmlresource/kde.css b864ef5 
>   src/kapidox/data/templates/doxygen2.html PRE-CREATION 
>   src/kapidox/data/templates/frontpage.html PRE-CREATION 
>   src/kapidox/data/templates/libinfo.html PRE-CREATION 
>   src/kapidox/data/templates/maintainers.html PRE-CREATION 
>   src/kapidox/data/templates/subgroup.html PRE-CREATION 
>   src/kapidox/generator.py 5b8ae40 
>   src/newkapidox.py PRE-CREATION 
>   src/notes PRE-CREATION 
> 
> Diff: https://git.reviewboard.kde.org/r/127747/diff/
> 
> 
> Testing
> ---
> 
> Tested on various scenario cases.
> 
> 
> File Attachments
> 
> 
> This is an example of what I generated. (Threadweaver is duplicated and 
> modified to test different scenarios)
>   
> https://git.reviewboard.kde.org/media/uploaded/files/2016/04/25/2e4549e4-7c17-416c-9a72-b82d3bba18b3__doc.tar.gz
> 
> 
> Thanks,
> 
> Olivier Churlaud
> 
>

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

Re: Review Request 127632: Prioritize correct extension per theme

[Albert Astals Cid]

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




src/kicontheme.h (line 173)
<https://git.reviewboard.kde.org/r/127632/#comment64430>

@since missing



src/kicontheme.cpp (line 407)
<https://git.reviewboard.kde.org/r/127632/#comment64431>

constBegin + constEnd + const_iterator (or auto?)


- Albert Astals Cid


On April 26, 2016, 7:12 p.m., Aleix Pol Gonzalez wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/127632/
> ---
> 
> (Updated April 26, 2016, 7:12 p.m.)
> 
> 
> Review request for KDE Frameworks, Andreas Kainz and Christoph Feck.
> 
> 
> Repository: kiconthemes
> 
> 
> Description
> ---
> 
> Usually themes will have 1 kind of extension (2 tops) it doesn't make sense 
> to bindly use an extensions vector that is statically defined.
> 
> Prioritizes the extensions that work, so it will find the icons sooner.
> 
> 
> Diffs
> -
> 
>   src/kiconengine.h 5b9badb 
>   src/kiconloader.cpp 37528ad 
>   src/kicontheme.h 3190665 
>   src/kicontheme.cpp e7e003b 
> 
> Diff: https://git.reviewboard.kde.org/r/127632/diff/
> 
> 
> Testing
> ---
> 
> Builds and tests still pass.
> Also reducess faulty disk accesses to its 45%. Note that by this metric, it's 
> almost as good as the RR #127236, but with a much smaller memory impact, 
> since we're not caching all the icon names (which was specially bad as it was 
> per-process).
> ```
> $ strace kwrite |& grep ENOENT | wc -l
> 4699
> $ strace kwrite |& grep ENOENT | wc -l
> 2119
> ```
> 
> 
> 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 127632: Prioritize correct extension per theme

[Albert Astals Cid]

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


Ship it!




Ship It!

- Albert Astals Cid


On April 26, 2016, 8:51 p.m., Aleix Pol Gonzalez wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/127632/
> ---
> 
> (Updated April 26, 2016, 8:51 p.m.)
> 
> 
> Review request for KDE Frameworks, Andreas Kainz and Christoph Feck.
> 
> 
> Repository: kiconthemes
> 
> 
> Description
> ---
> 
> Usually themes will have 1 kind of extension (2 tops) it doesn't make sense 
> to bindly use an extensions vector that is statically defined.
> 
> Prioritizes the extensions that work, so it will find the icons sooner.
> 
> 
> Diffs
> -
> 
>   src/kiconengine.h 5b9badb 
>   src/kiconloader.cpp 37528ad 
>   src/kicontheme.h 3190665 
>   src/kicontheme.cpp e7e003b 
> 
> Diff: https://git.reviewboard.kde.org/r/127632/diff/
> 
> 
> Testing
> ---
> 
> Builds and tests still pass.
> Also reducess faulty disk accesses to its 45%. Note that by this metric, it's 
> almost as good as the RR #127236, but with a much smaller memory impact, 
> since we're not caching all the icon names (which was specially bad as it was 
> per-process).
> ```
> $ strace kwrite |& grep ENOENT | wc -l
> 4699
> $ strace kwrite |& grep ENOENT | wc -l
> 2119
> ```
> 
> 
> 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 127770: Increase maximum string length in KSycoca database

[Albert Astals Cid]

> On April 27, 2016, 8:36 p.m., David Faure wrote:
> > src/sycoca/ksycocautils.cpp, line 39
> > 
> >
> > Variable-length arrays are invalid C++.
> > 
> > gcc might accept it, but -pedantic won't, and other compilers might not.
> > 
> > See e.g. 
> > http://stackoverflow.com/questions/1887097/variable-length-arrays-in-c 
> > (which is about C++, the '+'s got removed from the URL)
> > 
> > You can use an enum value to factorize the 8192. I think "static const 
> > int" won't do, if I read http://en.cppreference.com/w/cpp/language/array 
> > correctly.

I'm not sure if it's up to standard or not but both g++ and clang++ compile 
https://paste.kde.org/pfrytc0no with -pendantic

I wouldn't call it "variable-length" since the length is known at compile time.

Also 
http://stackoverflow.com/questions/1327806/do-all-c-compilers-allow-using-a-static-const-int-class-member-variable-as-an
 seems to say it's fine.


- Albert


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


On April 27, 2016, 8:44 p.m., Jos van den Oever wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/127770/
> ---
> 
> (Updated April 27, 2016, 8:44 p.m.)
> 
> 
> Review request for KDE Frameworks and David Faure.
> 
> 
> Repository: kservice
> 
> 
> Description
> ---
> 
> The code for reading and writing of strings in KSycoca is not symmetrical. 
> Strings of any length can be written, but only strings of less than 8192 
> bytes may be read. This limit is set in KSycocaUtilsPrivate::read. The limit 
> is probably there to avoid out-of-memory situations.
> 
> On my system I have a lot of XDG data dirs. The length of the environment 
> variable is currently 4092 bytes. KSycocaBuild saves that as UTF-16 which 
> needs 8184 bytes. KBuildSycoca save that without complaint but complains when 
> reading it.
> 
> 
> The simplest solution here is to simply increase the magic number 8192 to 
> e.g. 65528. This is just a temporary buffer.
> 
> Or we just check the size of the whole cache file (e.g. < 100M) and remove 
> all other limits. That would simplify
> 
>KSycocaUtilsPrivate::read(*str, header.prefixes);
> 
> to
> 
>*str >> header.prefixes;
> 
> This patch chooses the first option.
> 
> 
> Diffs
> -
> 
>   src/sycoca/ksycocautils.cpp 1ba75e8 
> 
> Diff: https://git.reviewboard.kde.org/r/127770/diff/
> 
> 
> Testing
> ---
> 
> Ran unit tests on KService. All but one of the previously failing tests on 
> NixOS is now fixed.
> 
> 
> Thanks,
> 
> Jos van den Oever
> 
>

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

Re: Review Request 127765: RFC: Cache global config files

[Albert Astals Cid]

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



Question: Do we care if the contents of those files changes on runtime? I.e. do 
we want to get the updated values?

- Albert Astals Cid


On April 27, 2016, 4:14 p.m., Aleix Pol Gonzalez wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/127765/
> ---
> 
> (Updated April 27, 2016, 4:14 p.m.)
> 
> 
> Review request for KDE Frameworks and Matthew Dawson.
> 
> 
> Repository: kconfig
> 
> 
> Description
> ---
> 
> A next step for my little quest is improving KConfig impact upon start.
> 
> In callgrind terms, 20% of dolphin's startup time is KConfig and 15% is 
> parsing global files, which is essentially loading kdeglobals 70 times. This 
> of course also means that kdeglobals is scattered 70 times in each 
> application's memory space.
> 
> To improve such situation, here's an attempt to cache these. I'm not an 
> expert in KConfig, so feedback is really appreciated 
> [[1]](http://i1.kym-cdn.com/photos/images/facebook/000/234/765/b7e.jpg)
> 
> 
> Diffs
> -
> 
>   src/core/kconfig.cpp ad52da9 
> 
> Diff: https://git.reviewboard.kde.org/r/127765/diff/
> 
> 
> Testing
> ---
> 
> Tests pass, KConfig becomes 6% of dolphin at load.
> 
> 
> Thanks,
> 
> Aleix Pol Gonzalez
> 
>

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

Review Request 127777: Make KTipDialog use the domain of the application when translating the tips

[Albert Astals Cid]

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

Review request for KDE Frameworks and Chusslove Illich.


Repository: kconfigwidgets


Description
---

Makes no sense to use ::tr() here, we need to use i18n that is what the rest of 
the framework (and hence the app) uses.

The biggest question is if we want to allow passing a domain as parameter to 
showXTip in case someone has more esoteric use cases.


Diffs
-

  src/ktipdialog.cpp e6a70af 

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


Testing
---

kig tips now show translated.


Thanks,

Albert Astals Cid

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

Re: Review Request 127777: Make KTipDialog use the domain of the application when translating the tips

[Albert Astals Cid]

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

(Updated April 28, 2016, 10:43 p.m.)


Status
--

This change has been marked as submitted.


Review request for KDE Frameworks and Chusslove Illich.


Changes
---

Submitted with commit 2ffec51692eae1dad4db816dc462a23a11d0d169 by Albert Astals 
Cid to branch master.


Repository: kconfigwidgets


Description
---

Makes no sense to use ::tr() here, we need to use i18n that is what the rest of 
the framework (and hence the app) uses.

The biggest question is if we want to allow passing a domain as parameter to 
showXTip in case someone has more esoteric use cases.


Diffs
-

  src/ktipdialog.cpp e6a70af 

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


Testing
---

kig tips now show translated.


Thanks,

Albert Astals Cid

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

Review Request 127784: Add a small note to the documentation on how tips are i18n'ed

[Albert Astals Cid]

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

Review request for KDE Frameworks and Chusslove Illich.


Repository: kconfigwidgets


Description
---

See Summary.


Diffs
-

  src/ktipdialog.h b18ef96 

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


Testing
---


Thanks,

Albert Astals Cid

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

Re: Review Request 127763: Reduce memory usage footprint

[Albert Astals Cid]

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


Ship it!




Ship It!

- Albert Astals Cid


On April 28, 2016, 12:39 p.m., Aleix Pol Gonzalez wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/127763/
> ---
> 
> (Updated April 28, 2016, 12:39 p.m.)
> 
> 
> Review request for KDE Frameworks and Christoph Feck.
> 
> 
> Repository: kiconthemes
> 
> 
> Description
> ---
> 
> Leverages the implicitly shared nature of QString by only constructing the 
> paths when it's strictly necessary. It souldn't show a big performance impact 
> since the generated paths were only intermediate in most cases after all.
> 
> This is especially important now that plasma has several KIconLoader 
> instances at the same time, but it should have an impact on every application 
> using kiconthemes (or under the plasma-integration effects).
> 
> 
> Diffs
> -
> 
>   src/kicontheme.cpp 735ecf7 
> 
> Diff: https://git.reviewboard.kde.org/r/127763/diff/
> 
> 
> Testing
> ---
> 
> Tests still pass, apps still work.
> 
> Starting and closing dolphin under callgrind showed 1640M instructions, now 
> 1466M(10% improvement).
> 
> 
> File Attachments
> 
> 
> after
>   
> https://git.reviewboard.kde.org/media/uploaded/files/2016/04/28/3f9b64d7-58e0-454b-9774-6ec86aa7f0c3__heaptrack.dolphin.16572-after.gz
> before
>   
> https://git.reviewboard.kde.org/media/uploaded/files/2016/04/28/6229961c-bf00-4959-9fc1-9effa63b2b34__heaptrack.dolphin.16861-before.gz
> 
> 
> 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 127784: Add a small note to the documentation on how tips are i18n'ed

[Albert Astals Cid]

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

(Updated April 28, 2016, 10:53 p.m.)


Status
--

This change has been marked as submitted.


Review request for KDE Frameworks and Chusslove Illich.


Changes
---

Submitted with commit 778e3fdd9597e50b3a4ebe7740224b6711a7b71a by Albert Astals 
Cid to branch master.


Repository: kconfigwidgets


Description
---

See Summary.


Diffs
-

  src/ktipdialog.h b18ef96 

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


Testing
---


Thanks,

Albert Astals Cid

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

Re: Review Request 127788: Fix leak in KNS::Engine

[Albert Astals Cid]

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


Fix it, then Ship it!





src/core/engine.cpp (line 155)
<https://git.reviewboard.kde.org/r/127788/#comment64498>

I'd add a
delete m_atticaProviderManager;
prior to this line just in case.


- Albert Astals Cid


On April 29, 2016, 12:45 p.m., Aleix Pol Gonzalez wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/127788/
> ---
> 
> (Updated April 29, 2016, 12:45 p.m.)
> 
> 
> Review request for KDE Frameworks and Jeremy Whiting.
> 
> 
> Repository: knewstuff
> 
> 
> Description
> ---
> 
> A local variable was shadowing the actual variable declaration.
> 
> 
> Diffs
> -
> 
>   src/core/engine.cpp c8d0579 
> 
> Diff: https://git.reviewboard.kde.org/r/127788/diff/
> 
> 
> Testing
> ---
> 
> 
> 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 127655: Fix KAboutData::applicationData() to sync to current Q*Application metadata

[Albert Astals Cid]

> On April 29, 2016, 3:15 a.m., Michael Pyne wrote:
> > I think I disagree with the idea of overwriting KAboutData properties if 
> > they are already set by the user. Alex, any thoughts?
> > 
> > In the event the KAboutData doesn't already exist I think automatically 
> > setting it up makes sense, and QCoreApplication is a good source. But I 
> > would rather flag property conflicts than to break ties when developer 
> > selects two different values for same property, as that's change in 
> > behavior might break other parts of code that rely on KAboutData not 
> > changing values.
> > 
> > Would this partial solution be OK for the problem you're running into?

> I think I disagree with the idea of overwriting KAboutData properties if they 
> are already set by the user. Alex, any thoughts?

I agree with Michael, it seems strage it overwriting what you may have set in 
setAboutData.


- Albert


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


On April 28, 2016, 1:04 a.m., Friedrich W. H. Kossebau wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/127655/
> ---
> 
> (Updated April 28, 2016, 1:04 a.m.)
> 
> 
> Review request for KDE Frameworks, Alex Richardson and Michael Pyne.
> 
> 
> Repository: kcoreaddons
> 
> 
> Description
> ---
> 
> KAboutData is passed as values on getting and setting the "applicationData",
> and it only makes sense to have its properties be a transparent access
> to the actual mirrored Q*Application metadata.
> 
> Even more as there is code in KF5 (e.g. KXMLGUI) which relies on 
> KAboutData::applicationData(),
> without requiring the user to use KAboutData::setApplicationData().
> 
> 
> Diffs
> -
> 
>   autotests/kaboutdatatest.cpp f31e7f3 
>   src/lib/kaboutdata.h 97c0f2b 
>   src/lib/kaboutdata.cpp ceb0c06 
> 
> Diff: https://git.reviewboard.kde.org/r/127655/diff/
> 
> 
> Testing
> ---
> 
> Added autotests pass.
> 
> 
> Thanks,
> 
> Friedrich W. H. Kossebau
> 
>

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

Re: Review Request 127808: Minor speedup of KMountPoint::probablySlow()

[Albert Astals Cid]

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


Ship it!




Ship It!

- Albert Astals Cid


On May 1, 2016, 7:50 p.m., Dominik Haumann wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/127808/
> ---
> 
> (Updated May 1, 2016, 7:50 p.m.)
> 
> 
> Review request for KDE Frameworks.
> 
> 
> Repository: kio
> 
> 
> Description
> ---
> 
> Use lazy evaluation instead of comparing all filesystem types first, and then 
> returning true/false.
> 
> 
> Diffs
> -
> 
>   src/core/kmountpoint.cpp 5feb3a8 
> 
> Diff: https://git.reviewboard.kde.org/r/127808/diff/
> 
> 
> Testing
> ---
> 
> Compiles.
> 
> 
> Thanks,
> 
> Dominik Haumann
> 
>

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

Re: Find out whether a file is a remote file or not

[Albert Astals Cid]

El diumenge, 1 de maig de 2016, a les 19:12:11 CEST, Dominik Haumann va 
escriure:
> On Sun, May 1, 2016 at 6:28 PM, Dominik Haumann  wrote:
> > Hi all,
> > 
> > do we have a mechanism in KDE to find out whether a file is a truly
> > local file, or a remote file?
> > 
> > With remote file I mean e.g. a sshfs mounted location that appears in
> > the file system, which integrates seamlessly into the local
> > filesystem, but in truth, it is not a local file.
> > 
> > As initial start, I'd consider local disks and plugged in USB sticks
> > local, everything else remote.
> > 
> > In Kate, we typically backup local files, and maybe "worse", by
> > default create swap files for local files. But given that remotely
> > mounted filesystem also appear as local files, this leads to a
> > potential bottleneck.
> > 
> > BUG: https://bugs.kde.org/show_bug.cgi?id=362288
> > 
> > CC: Vishesh, since maybe baloo also had to solve these issues
> 
> What I have found:
> 
> KIO contains [1] KMountPoint::probablySlow(), and it's returning true
> for nfs, cifs, and some others, but not for e.g. sshfs, see [2]. So
> this is not exactly what I want, or at least, it would need extension.
> 
> PS: The implementation of [2] could be much faster, given it first
> computes all bools, and only then checks them.
> 
> Anyways, using this, it would look similar to this:
> 
> KMountPoint::List mountedDeviceList = KMountPoint::currentMountPoints();
> KMountPoint::Ptr mountPoint =
> mountedDeviceList->findByDevice(kateDocument()->url());
> if (mountPoint && mountPoint->isProbablySlow()) {
> // disalbe swap file and backups
> }
> 
> Is that the suggested solution, or is there a better way?

See https://marc.info/?l=kde-core-devel&m=138530914325647&w=2 for a similar 
question i made years ago, the answer was "we can probably do much better", 
but then noone stepped up to do that "much better" solution.

Cheers,
  Albert

> 
> Cheers,
> Dominik
> 
> [1]
> http://api.kde.org/frameworks-api/apidox-frameworks/frameworks5-apidocs/kio
> /html/classKMountPoint.html#a338731f8ed1c8b02b317da32857aa198 [2]
> http://api.kde.org/frameworks-api/apidox-frameworks/frameworks5-apidocs/kio
> /html/kmountpoint_8cpp_source.html#l00535
> ___
> Kde-frameworks-devel mailing list
> Kde-frameworks-devel@kde.org
> https://mail.kde.org/mailman/listinfo/kde-frameworks-devel


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

Re: Review Request 127655: Fix KAboutData::applicationData() to sync to current Q*Application metadata

[Albert Astals Cid]

> On April 29, 2016, 3:15 a.m., Michael Pyne wrote:
> > I think I disagree with the idea of overwriting KAboutData properties if 
> > they are already set by the user. Alex, any thoughts?
> > 
> > In the event the KAboutData doesn't already exist I think automatically 
> > setting it up makes sense, and QCoreApplication is a good source. But I 
> > would rather flag property conflicts than to break ties when developer 
> > selects two different values for same property, as that's change in 
> > behavior might break other parts of code that rely on KAboutData not 
> > changing values.
> > 
> > Would this partial solution be OK for the problem you're running into?
> 
> Albert Astals Cid wrote:
> > I think I disagree with the idea of overwriting KAboutData properties 
> if they are already set by the user. Alex, any thoughts?
> 
> I agree with Michael, it seems strage it overwriting what you may have 
> set in setAboutData.
> 
> Friedrich W. H. Kossebau wrote:
> Hm. Would it not be more strange if one cannot be sure that 
> KAboutData::applicationData().displayName() matches 
> app->applicationDisplayName()? And similar for the other shared/mapped 
> application metadata properties? Why would I rather expect the original 
> property of the KAboutData value to be kept, than it being updated to its 
> counterpart in the Q*Application metadata, if changed by the Qt-API 
> afterwards?
> Surprised to see you expecting things to be different :)
> 
> Not that I expect it to happen a lot in real world code that the metadata 
> of applications is set/reset by independent code snippets (and thus a mixture 
> of KAboutData-using and Q*Application::setX-using), where random orders of 
> writing and reading the data can happen. But if it happens, should not both 
> Q*Application::setX and KAboutData::setApplicationData be equi-mighty, and 
> both be acting on the same effective properties when it comes to metadata 
> about the application instance, where it makes sense and is defined as such?
> 
> Or, why should KAboutData::setApplicationData be allowed to overrule any 
> already set QApplication metadata (which makes sense to everyone), but not 
> the other way around? :) Why should KAboutData::setApplicationData be 
> write-through, but KAboutData::applicationData not be read-through?
> 
> Like it is now, if I would want to use metadata of the application, I 
> cannot rely on KAboutData::applicationData alone, I also have to separately 
> read things by Q*Application::x, to be sure to really have the values also 
> used by other Qt-only parts of the code. Which renders the duplicates of 
> those Q*Application properties in KAboutData useless, no?
> I would expect more code to be broken if it relies only on 
> KAboutData::applicationData() than code which expects any properties to keep 
> their values, even if getting out-of-sync with the Qt application metadata.
> 
> For the bug which motivated me to write this patch, agreeing on 
> initialising at least the global KAboutData instance to current Q*Application 
> data should be fine, so will change the patch to that now. But well, I think 
> this initial patch should be the way to go and yield less surprising 
> behaviour :)

> Would it not be more strange if one cannot be sure that 
> KAboutData::applicationData().displayName() matches 
> app->applicationDisplayName()?

To me, no.

> Why would I rather expect the original property of the KAboutData value to be 
> kept, than it being updated to its counterpart in the Q*Application metadata, 
> if changed by the Qt-API afterwards?

Why should they match? You're basically arguing for
a->setX("BOO")
b->setY("LALA")
a->x() => should return "LALA"

That's the most strange API ever.

> Or, why should KAboutData::setApplicationData be allowed to overrule any 
> already set QApplication metadata (which makes sense to everyone), but not 
> the other way around?

I don't think it makes sense either. If we're to fix this assymetry, I would 
much rather prefer a patch that doesn't overwrite QCoreApplication version, 
name and organization domain if they have already been set.

I am not the maintainer of this framework though, so wait for a more qualified 
opinion.


- Albert


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


On April 28, 2016, 1:04 a.m., Friedrich W. H. Kossebau wrote:
> 
> ---
> This

Re: Review Request 127813: Process paths just once

[Albert Astals Cid]

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




src/core/kconfiggroup.cpp (line 439)
<https://git.reviewboard.kde.org/r/127813/#comment64555>

Are we sure we want this to be static?


- Albert Astals Cid


On May 2, 2016, 4:32 p.m., Aleix Pol Gonzalez wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/127813/
> ---
> 
> (Updated May 2, 2016, 4:32 p.m.)
> 
> 
> Review request for KDE Frameworks and Matthew Dawson.
> 
> 
> Repository: kconfig
> 
> 
> Description
> ---
> 
> Just process every home path once, as the 3 alternatives will probably just 
> be the same.
> Don't drop the file: prefix twice in every run.
> 
> 
> Diffs
> -
> 
>   src/core/kconfiggroup.cpp 39d2441 
> 
> Diff: https://git.reviewboard.kde.org/r/127813/diff/
> 
> 
> Testing
> ---
> 
> Tests pass, apps 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 127817: Don't make KIconThemes depend on Oxygen

[Albert Astals Cid]

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



+1 would i'd like someone else opinion.

- Albert Astals Cid


On May 2, 2016, 11:09 p.m., Aleix Pol Gonzalez wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/127817/
> ---
> 
> (Updated May 2, 2016, 11:09 p.m.)
> 
> 
> Review request for KDE Frameworks.
> 
> 
> Repository: kiconthemes
> 
> 
> Description
> ---
> 
> We were using oxygen as the default theme, this meant that oxygen was 
> processed by every application. This was fixed in the past by changing this 
> setting to `breeze`, but this only brought new kinds of problems (e.g. review 
> 127232).
> 
> See bug 336739, bug 360664.
> 
> By just using hicolor, we don't make the application fetch `oxygen` for 
> little reason.
> 
> 
> Diffs
> -
> 
>   src/kiconloader.cpp 6ce7ecdc0b9c38647994c750e77980fbf9b6fdd4 
>   src/kicontheme.cpp f8c0a37754848a74e42bba5866aa4ce0998bce7c 
> 
> Diff: https://git.reviewboard.kde.org/r/127817/diff/
> 
> 
> Testing
> ---
> 
> On dolphin:
> This has an improvement on callgrind 1556M/1185M instructions (30% 
> improvement).
> KIconLoader allocations correspond to 3.8% instead of 4.8%, going down by: 
> 535K/509K
> 
> 
> 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 127655: Fix KAboutData::applicationData() to init from current Q*Application metadata

[Albert Astals Cid]

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


Fix it, then Ship it!





src/lib/kaboutdata.cpp (line 46)
<https://git.reviewboard.kde.org/r/127655/#comment64592>

5.4 is now the minimum supported version of KDE Frameowkrs 5


- Albert Astals Cid


On May 4, 2016, 9:41 p.m., Friedrich W. H. Kossebau wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/127655/
> ---
> 
> (Updated May 4, 2016, 9:41 p.m.)
> 
> 
> Review request for KDE Frameworks, Alex Richardson and Michael Pyne.
> 
> 
> Repository: kcoreaddons
> 
> 
> Description
> ---
> 
> There is code in e.g. KXMLGUI which relies on KAboutData::applicationData(), 
> without requiring the user to use KAboutData::setApplicationData(). So better 
> be complete when initializing the data from the Q*Application metadata.
> 
> Also
> - warn if there is no Q*App instance yet to set properties in 
> KAboutData::setApplicationData
> - check and warn if KAboutData::applicationData is out-of-sync with qapp data
> - remove bogus check for empty display name, as the method defaults to 
> componentname
> - unit tests 
> KAboutDataTest::testSetOfQApplicationData/testPickupOfQApplicationData
> 
> 
> Diffs
> -
> 
>   autotests/CMakeLists.txt a7a6752 
>   autotests/kaboutdataapplicationdatatest.cpp PRE-CREATION 
>   src/lib/kaboutdata.h 97c0f2b 
>   src/lib/kaboutdata.cpp ceb0c06 
> 
> Diff: https://git.reviewboard.kde.org/r/127655/diff/
> 
> 
> Testing
> ---
> 
> Added autotests pass.
> 
> 
> Thanks,
> 
> Friedrich W. H. Kossebau
> 
>

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

Re: Review Request 127813: Process paths just once

[Albert Astals Cid]

> On May 2, 2016, 8:21 p.m., Albert Astals Cid wrote:
> > src/core/kconfiggroup.cpp, line 442
> > <https://git.reviewboard.kde.org/r/127813/diff/1/?file=462322#file462322line442>
> >
> > Are we sure we want this to be static?
> 
> Aleix Pol Gonzalez wrote:
> I'm not sure, my impression is that it's better if we only fetch this 
> once, but I can easily be convinced otherwise.

My rationale is that the old code adapted to the new values if they changed, if 
it doesn't really give us much having it static (which i think it's not a huge 
win) preserving the same behaviour looks like a good thing.


- Albert


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


On May 2, 2016, 4:32 p.m., Aleix Pol Gonzalez wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/127813/
> ---
> 
> (Updated May 2, 2016, 4:32 p.m.)
> 
> 
> Review request for KDE Frameworks and Matthew Dawson.
> 
> 
> Repository: kconfig
> 
> 
> Description
> ---
> 
> Just process every home path once, as the 3 alternatives will probably just 
> be the same.
> Don't drop the file: prefix twice in every run.
> 
> 
> Diffs
> -
> 
>   src/core/kconfiggroup.cpp 39d2441 
> 
> Diff: https://git.reviewboard.kde.org/r/127813/diff/
> 
> 
> Testing
> ---
> 
> Tests pass, apps 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 127833: KWallet: More Coverity fixes, and include Qt headers for endianness check.

[Albert Astals Cid]

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



-1


src/runtime/kwalletd/main.cpp (line 97)
<https://git.reviewboard.kde.org/r/127833/#comment64597>

See REVIEW: 126681 (commit 901c27ca7cb05cca1a960747b280d40cd7707158) it 
seems this fixes things. So not a good idea reverting it, probably a different 
fix needed.


- Albert Astals Cid


On May 4, 2016, 11:03 p.m., Michael Pyne wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/127833/
> ---
> 
> (Updated May 4, 2016, 11:03 p.m.)
> 
> 
> Review request for KDE Frameworks.
> 
> 
> Repository: kwallet
> 
> 
> Description
> ---
> 
> This is a collection of minor fixes:
> 
> An uninit variable usage was noted by Coverity (CID 1289177) for a CBC crypto 
> function, though it only happens for encryption lengths that would not be hit 
> in practice. I troubleshot this in December but forgot to make a RR, but IIRC 
> the lengths that would cause problems are 7 bytes or less -- but it's still 
> better to fix.
> 
> The other Coverity fix is to avoid a needless dup(2) of an opened socket 
> since it's immediately turned into a FILE* object anyways (CID 1353007). This 
> avoids a minor resource leak of a file descriptor.
> 
> Finally, some of the ciphers use Qt checks for endianness, and need to 
> actually include the header that does this instead of relying on other parts 
> of the code incidentally pulling in the needed #includes.
> 
> 
> Diffs
> -
> 
>   src/runtime/kwalletd/backend/blowfish.cc a375148 
>   src/runtime/kwalletd/backend/cbc.cc 4c13466 
>   src/runtime/kwalletd/backend/sha1.cc 9d98b79 
>   src/runtime/kwalletd/main.cpp 90c60d8 
> 
> Diff: https://git.reviewboard.kde.org/r/127833/diff/
> 
> 
> Testing
> ---
> 
> Everything still compiles -- I'm limited in my ability to test since I'm 
> still using KDE4's KWallet (as the KF5 stuff seems to require polkit to 
> actually work, which isn't possible with a homedir install like mine).
> 
> 
> Thanks,
> 
> Michael Pyne
> 
>

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

Re: Review Request 127747: Create a new script that generate the documentation for all projects following the syntax I proposed

[Albert Astals Cid]

> On April 28, 2016, 8:02 a.m., Olivier Churlaud wrote:
> > Any other feedback? What should I do?
> 
> Allen Winter wrote:
> I suppose I need to find the time to test this out on the actual 
> api.kde.org machine.  can I run it on the old KDE4 kdelibs KDE/4.14 branch?
> 
> Olivier Churlaud wrote:
> Sadly enough it won't work if you don't set all the metadata.yml files.
> 
> I attached a big zip file to the review containing what I generated. Else 
> you can test on some cases by reading what is on the file metainfo-syntax.md.

I can't download the files, can you?


- Albert


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


On April 25, 2016, 9:49 p.m., Olivier Churlaud wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/127747/
> ---
> 
> (Updated April 25, 2016, 9:49 p.m.)
> 
> 
> Review request for KDE Frameworks, Albert Astals Cid, Alex Merry, Aurélien 
> Gâteau, and Allen Winter.
> 
> 
> Repository: kapidox
> 
> 
> Description
> ---
> 
> Keep in mind that it should not plainly replace kgenframeworks but be used by 
> all KDE projects. So in this proposition, the Frameworks are just one project 
> in others.
> 
> The code can be tested directly by checking the branch 
> `olivier/generate_all_repos`.
> 
> This MUST NOT be merged in master, because it will break the currents scripts 
> (see commit 3643dded7cf14a5634879e8e6e34be8840143d7e).
> 
> 
> Diffs
> -
> 
>   konqi_frameworks.png PRE-CREATION 
>   metainfo.yaml 4ff17c8 
>   metainfo_syntax.md PRE-CREATION 
>   src/kapidox/data/htmlresource/default_product.png PRE-CREATION 
>   src/kapidox/data/htmlresource/kde.css b864ef5 
>   src/kapidox/data/templates/doxygen2.html PRE-CREATION 
>   src/kapidox/data/templates/frontpage.html PRE-CREATION 
>   src/kapidox/data/templates/libinfo.html PRE-CREATION 
>   src/kapidox/data/templates/maintainers.html PRE-CREATION 
>   src/kapidox/data/templates/subgroup.html PRE-CREATION 
>   src/kapidox/generator.py 5b8ae40 
>   src/newkapidox.py PRE-CREATION 
>   src/notes PRE-CREATION 
> 
> Diff: https://git.reviewboard.kde.org/r/127747/diff/
> 
> 
> Testing
> ---
> 
> Tested on various scenario cases.
> 
> 
> File Attachments
> 
> 
> This is an example of what I generated. (Threadweaver is duplicated and 
> modified to test different scenarios)
>   
> https://git.reviewboard.kde.org/media/uploaded/files/2016/04/25/2e4549e4-7c17-416c-9a72-b82d3bba18b3__doc.tar.gz
> 
> 
> Thanks,
> 
> Olivier Churlaud
> 
>

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

Re: Review Request 127817: Don't make KIconThemes depend on Oxygen

[Albert Astals Cid]

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


Ship it!




Ok, if noone else wants to review, ship it (wait for 5.22 to be out) and we'll 
see if it makes people unhappy :D

- Albert Astals Cid


On May 2, 2016, 11:09 p.m., Aleix Pol Gonzalez wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/127817/
> ---
> 
> (Updated May 2, 2016, 11:09 p.m.)
> 
> 
> Review request for KDE Frameworks.
> 
> 
> Repository: kiconthemes
> 
> 
> Description
> ---
> 
> We were using oxygen as the default theme, this meant that oxygen was 
> processed by every application. This was fixed in the past by changing this 
> setting to `breeze`, but this only brought new kinds of problems (e.g. review 
> 127232).
> 
> See bug 336739, bug 360664.
> 
> By just using hicolor, we don't make the application fetch `oxygen` for 
> little reason.
> 
> 
> Diffs
> -
> 
>   src/kiconloader.cpp 6ce7ecdc0b9c38647994c750e77980fbf9b6fdd4 
>   src/kicontheme.cpp f8c0a37754848a74e42bba5866aa4ce0998bce7c 
> 
> Diff: https://git.reviewboard.kde.org/r/127817/diff/
> 
> 
> Testing
> ---
> 
> On dolphin:
> This has an improvement on callgrind 1556M/1185M instructions (30% 
> improvement).
> KIconLoader allocations correspond to 3.8% instead of 4.8%, going down by: 
> 535K/509K
> 
> 
> 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 127929: K4TimeZoneWidget: flag images not displayed because of incorrect path

[Albert Astals Cid]

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


Ship it!




Ship It!

- Albert Astals Cid


On May 15, 2016, 1:59 p.m., Jonathan Marten wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/127929/
> ---
> 
> (Updated May 15, 2016, 1:59 p.m.)
> 
> 
> Review request for KDE Frameworks.
> 
> 
> Repository: kdelibs4support
> 
> 
> Description
> ---
> 
> In KDE4 this widget displayed the appropriate country flag at the start of 
> the continent/city column.  This no longer happens because the path used to 
> find the flag image files is incorrect: it is still using the old 
> share/locale/l10n/CC/flag.png location.  In KF5 this is now 
> share/kf5/locale/countries/CC/flag.png.  This change corrects the path and 
> comment.
> 
> 
> Diffs
> -
> 
>   src/kdeui/k4timezonewidget.cpp 70ff79f 
> 
> Diff: https://git.reviewboard.kde.org/r/127929/diff/
> 
> 
> Testing
> ---
> 
> Built kdelibs4support with this change, checked correct display of flag 
> column in dialogue.
> 
> 
> Thanks,
> 
> Jonathan Marten
> 
>

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

Re: Review Request 127865: Check size of unix domain socket path before copying to it.

[Albert Astals Cid]

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


Ship it!




Ship It!

- Albert Astals Cid


On May 8, 2016, 2:03 a.m., Michael Pyne wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/127865/
> ---
> 
> (Updated May 8, 2016, 2:03 a.m.)
> 
> 
> Review request for KDE Frameworks.
> 
> 
> Repository: kcrash
> 
> 
> Description
> ---
> 
> Although we don't seem to run across this in practice, Coverity warns about 
> filling in sockaddr_un::sun_path's buffer without checking the source 
> string's length (CID 1175514), and the Linux unix(7) manpage notes that some 
> implementations use as few as 92 bytes for this buffer.
> 
> 
> Diffs
> -
> 
>   src/kcrash.cpp 7d3b8a2 
> 
> Diff: https://git.reviewboard.kde.org/r/127865/diff/
> 
> 
> Testing
> ---
> 
> Compiles w/out warnings, kcrashtest passes.
> 
> 
> Thanks,
> 
> Michael Pyne
> 
>

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

Re: Review Request 127817: Don't make KIconThemes depend on Oxygen

[Albert Astals Cid]

> On May 17, 2016, 12:29 p.m., Wolfgang Bauer wrote:
> > Sorry for coming late, I'm not subscribed to the list (and I'm not a 
> > maintainer either), just noticed the commit.
> > 
> > I have nothing against the patch per se, and it apparently won't cause the 
> > wrong fallback to breeze either as reported in bug#360664.
> > 
> > But: Won't we hit the same old problem again that applications won't find 
> > their oxygen icons (where they might have installed them in the first 
> > place) any more?
> > Which was the reason why the previous patch to change the default to breeze 
> > got reverted.
> > 
> > See https://bugs.kde.org/show_bug.cgi?id=336739#c9, and the discussion in 
> > https://mail.kde.org/pipermail/kde-frameworks-devel/2015-October/027900.html.
> > 
> > At least kdenlive still seems to be affected according to 
> > http://bugzilla.opensuse.org/show_bug.cgi?id=975387...
> > 
> > Sorry if I'm misunderstanding something here, just wanted to raise a 
> > concern for the sake of good...
> 
> Aleix Pol Gonzalez wrote:
> Then maybe Breeze should inherit Oxygen? Or just be extended to have such 
> icons. KIconThemes it's the wrong place to enforce these.
> 
> Wolfgang Bauer wrote:
> It's not about Breeze. AFAIK Breeze does inherit from Oxygen.
> The problem is that users can select other themes that don't inherit from 
> Oxygen.
> 
> I do agree that KIconThemes is the wrong place for this, but the problem 
> won't be solved by ignoring it either

If apps install the icon into oxygen, the apps need to be fixed to install 
their icon to hicolor


- Albert


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


On May 17, 2016, 10:23 a.m., Aleix Pol Gonzalez wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/127817/
> ---
> 
> (Updated May 17, 2016, 10:23 a.m.)
> 
> 
> Review request for KDE Frameworks.
> 
> 
> Repository: kiconthemes
> 
> 
> Description
> ---
> 
> We were using oxygen as the default theme, this meant that oxygen was 
> processed by every application. This was fixed in the past by changing this 
> setting to `breeze`, but this only brought new kinds of problems (e.g. review 
> 127232).
> 
> See bug 336739, bug 360664.
> 
> By just using hicolor, we don't make the application fetch `oxygen` for 
> little reason.
> 
> 
> Diffs
> -
> 
>   src/kiconloader.cpp 6ce7ecdc0b9c38647994c750e77980fbf9b6fdd4 
>   src/kicontheme.cpp f8c0a37754848a74e42bba5866aa4ce0998bce7c 
> 
> Diff: https://git.reviewboard.kde.org/r/127817/diff/
> 
> 
> Testing
> ---
> 
> On dolphin:
> This has an improvement on callgrind 1556M/1185M instructions (30% 
> improvement).
> KIconLoader allocations correspond to 3.8% instead of 4.8%, going down by: 
> 535K/509K
> 
> 
> Thanks,
> 
> Aleix Pol Gonzalez
> 
>

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

Review Request 127973: Fix window in which the file containing the X11 cookie has the wrong permissions

[Albert Astals Cid]

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

Review request for KDE Frameworks and David Faure.


Repository: kinit


Description
---

if someone is very fast can watch the file between the open and the 
setPermissions


Diffs
-

  src/kdeinit/kinit.cpp 19e38b8 

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


Testing
---

works


Thanks,

Albert Astals Cid

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

Re: Review Request 127973: Fix race in which the file containing the X11 cookie has the wrong permissions

[Albert Astals Cid]

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

(Updated May 19, 2016, 11:38 p.m.)


Review request for KDE Frameworks and David Faure.


Summary (updated)
-

Fix race in which the file containing the X11 cookie has the wrong permissions


Repository: kinit


Description
---

if someone is very fast can watch the file between the open and the 
setPermissions


Diffs
-

  src/kdeinit/kinit.cpp 19e38b8 

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


Testing
---

works


Thanks,

Albert Astals Cid

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

Re: Review Request 127973: Fix race in which the file containing the X11 cookie has the wrong permissions

[Albert Astals Cid]

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



https://codereview.qt-project.org/#/c/159689/ would fix it too

- Albert Astals Cid


On May 19, 2016, 11:38 p.m., Albert Astals Cid wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/127973/
> ---
> 
> (Updated May 19, 2016, 11:38 p.m.)
> 
> 
> Review request for KDE Frameworks and David Faure.
> 
> 
> Repository: kinit
> 
> 
> Description
> ---
> 
> if someone is very fast can watch the file between the open and the 
> setPermissions
> 
> 
> Diffs
> -
> 
>   src/kdeinit/kinit.cpp 19e38b8 
> 
> Diff: https://git.reviewboard.kde.org/r/127973/diff/
> 
> 
> Testing
> ---
> 
> works
> 
> 
> Thanks,
> 
> Albert Astals Cid
> 
>

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

Re: Review Request 127973: Fix race in which the file containing the X11 cookie has the wrong permissions

[Albert Astals Cid]

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

(Updated May 21, 2016, 3:49 p.m.)


Status
--

This change has been marked as submitted.


Review request for KDE Frameworks and David Faure.


Changes
---

Submitted with commit 72f3702dbe6cf15c06dc13da2c99c864e9022a58 by Albert Astals 
Cid to branch master.


Repository: kinit


Description
---

if someone is very fast can watch the file between the open and the 
setPermissions


Diffs
-

  src/kdeinit/kinit.cpp 19e38b8 

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


Testing
---

works


Thanks,

Albert Astals Cid

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

Re: HAVE_X11 usage in KIO/core

[Albert Astals Cid]

El Divendres, 7 de febrer de 2014, a les 15:25:42, Kevin Krammer va escriure:
> On Friday, 2014-02-07, 09:51:27, Martin Gräßlin wrote:
> > On Friday 07 February 2014 09:38:41 Kevin Krammer wrote:
> > > On Friday, 2014-02-07, 08:53:54, Martin Gräßlin wrote:
> > > > I'm wondering what to do about it. The best would be to use
> > > > QGuiApplication::platformName, but it's a core app. Also finding X11
> > > > in
> > > > CMakeLists to get the HAVE_X11 defined looks very wrong to me and not
> > > > future safe (Wayland).
> > > 
> > > My guess is that platform() in this context means operating system, not
> > > windowing/display system.
> > 
> > See the comment I pasted, it's explicitly saying it's the windowing system
> > and not the OS...
> 
> Ah, didn't see that. Does it actually make sense?
> 
> If yes than this obviously has be to be done at runtime, at least for
> platforms with multiple UI systems:
> 
> #if  defined(Q_OS_MAC)
> return QL1S("Macintosh")
> #elfi defined(Q_OS_WINDOWS)
>   return QL1S("Windows")
> #else
> const QVariant platformName = qApp ? qApp->property("platformName") :
> QVariant();
> if (platformName.isValid()) {
> const QString name = platformName.toString();
> if (!name.isEmpty())
> return name;
> }
> #endif
> return QL1S("Unknown");


Sincerely, just drop it.

We will change from sending 

Mozilla/5.0 (compatible; Konqueror/4.0; Linux; X11; i686; en_US) KHTML/4.0.1 
(like Gecko)

to

Mozilla/5.0 (compatible; Konqueror/4.0; Linux; i686; en_US) KHTML/4.0.1 (like 
Gecko)

will anyone ever care?

Cheers,
  Albert

> 
> Cheers,
> Kevin

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

Re: kf5 alpha 1 : modules, versions

[Albert Astals Cid]

El Dissabte, 8 de febrer de 2014, a les 16:32:04, David Faure va escriure:
> On Saturday 08 February 2014 14:13:40 Ivan Čukić wrote:
> > On Saturday, 8. February 2014. 12.58.53 David Faure wrote:
> > > Also, kactivities is the only framework that still uses a branch named
> > > "frameworks".
> > > 
> > > Can we switch to master = kf5 and KDE/4.13 for the current master,
> > > assuming
> > > a 4.13 release of it is planned? [otherwise what do we do with master?]
> > 
> > I wanted that, but got a frowny face from Albert:
> > 
> > "Personally I'd suggest against it since seems that even if we dicussed
> > for
> > that happening to kde-workspace people did not get the memo and got angry,
> > "
> Well, that was before we had tools to abstract branch names, like kde-build-
> metadata/logical-module-structure.
> These days such changes are a lot more transparent, which puts the matter to
> rest (I was one of the unhappy people when things started to get
> inconsistent).

Good that this has been now resolved.

Cheers,
  Albert

> Since then, kdelibs got splitted, so as I said, KF5 stuff is "master" in
> more and more places - and especially all of the frameworks themselves.

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

Re: Review Request 115485: Porting KTranscript from KJS to QtScript

[Albert Astals Cid]

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


Do you have any idea at why the shutdown crash may be happening?


src/ktranscript.cpp
<https://git.reviewboard.kde.org/r/115485/#comment35076>

Kill the qdebug (and the one a bit below)? 


- Albert Astals Cid


On Feb. 16, 2014, 4:02 p.m., Kevin Krammer wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/115485/
> ---
> 
> (Updated Feb. 16, 2014, 4:02 p.m.)
> 
> 
> Review request for KDE Frameworks and Chusslove Illich.
> 
> 
> Repository: ki18n
> 
> 
> Description
> ---
> 
> Attempt at replacing the KJS dependency with a QtScript, i.e. making ki18n a 
> tier1 framework.
> Needs more testing and likely fixing
> 
> 
> Diffs
> -
> 
>   CMakeLists.txt 3e099d5 
>   src/CMakeLists.txt 9e3ce9f 
>   src/ktranscript.cpp c922e91 
> 
> Diff: https://git.reviewboard.kde.org/r/115485/diff/
> 
> 
> Testing
> ---
> 
> Unittest runs, but the test script is very minimal and would need to be 
> extendedb by someone who understands the scripting requirements.
> There is also a weird crash at test shutdown, in QThreadStorage. As far as I 
> can tell I did not change anything related to threads though.
> 
> 
> Thanks,
> 
> Kevin Krammer
> 
>

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

Re: Review Request 115832: Print the diff to stdout on comparison failure

[Albert Astals Cid]

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



autotests/kconfig_compiler/kconfigcompiler_test.cpp
<https://git.reviewboard.kde.org/r/115832/#comment35163>

Remove the m_diff variable from the .h?


- Albert Astals Cid


On Feb. 17, 2014, 3:49 p.m., Alexander Richardson wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/115832/
> ---
> 
> (Updated Feb. 17, 2014, 3:49 p.m.)
> 
> 
> Review request for KDE Frameworks.
> 
> 
> Repository: kconfig
> 
> 
> Description
> ---
> 
> Print the diff to stdout on comparison failure
> 
> Previously the output of diff -u was written to a file when the
> generated file did not match the expectations. Having the output printed
> to stdout makes it easier to see the exact error without having to know
> that a diff exists in a certain file somewhere in the build directory.
> 
> 
> Diffs
> -
> 
>   autotests/kconfig_compiler/kconfigcompiler_test.cpp 
> 48192f5ea8293a3bab010818511ceda4530dede3 
> 
> Diff: https://git.reviewboard.kde.org/r/115832/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Alexander Richardson
> 
>

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

Re: [sprinter] runners: activities runner ported to Sprinter

[Albert Astals Cid]

El Dimarts, 18 de febrer de 2014, a les 18:32:01, Aaron Seigo va escriure:
> Git commit be5ad03baf3fe327018742a114051377f8eea3c5 by Aaron Seigo.
> Committed on 18/02/2014 at 18:30.
> Pushed by aseigo into branch 'master'.
> 
> activities runner ported to Sprinter
> 
> can't fully test this one as the kactivities daemon changed its dbus
> services between 4.x and 5.x which means this becomes version specific
> and i am still running this in a 4.x desktop shell
> 
> why these kids of breakages? no clue.

It seems to me that Aaron wanted to ask this list but somehow ended up writing 
something in a commit log.

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

Re: DocBookXML 4.5, the plan

[Albert Astals Cid]

El Dissabte, 22 de febrer de 2014, a les 16:52:38, Luigi Toscano va escriure:
> Hi all,
> these are the steps of plan for bumping the default DocBook XML version to
> 4.5 while keeping the compatibility on the old 4.2-based when kde4support
> is used:
> 
> 1) commit rename/changes of FindDocBookXML (RR 115876 and 115879);
> 
> 2) kde4support: copy files FindDocBookXML, catalog.xml, kdex.dtd to
> kde4support (with history, help or script from Alex Merry needed :) from
> kdoctools, remove the old compatibility variables, do not install kdex.dtd
> and catalog.xml for now, rename catalog.xml as catalog4.xml and remove the
> old content (leave only the definition of 4.2-based DTD).
> 
> 3a) kdoctools: change the default DTD by renaming kdex.dtd and bumping
> DocBookXML version number to 4.5;
> 3b) kde4support: install catalog4.xml and kdex.dtd from kde4support
> 3c) other modules: fix the documentation of all ported modules to use the
> new DTD (4.5-based) (temporary breakages in Jenkins are possible).
> 
> My question is: given the strict time before alpha2, do I need to sent out a
> RR for every step above (especially 3c), or can I just go and do the
> changes if you think the plan is fine?

I'm not a huge part of the frameworks team, so feel free to ignore me, but 
sometimes i feel we're overdoing the review thing, i've seen changes that seem 
trivial to me and that seem to originate from the person that knows most of 
the code posted to reviewboard. And that's fine if there's people reivewing it 
in a timely manner but for some not so well known/reviewed places it can stall 
the flow a bit so personally I wouldn't mind if some things just are commited 
directly.

But as said, that's just my kind of outside opinion :)

Cheers,
  Albert

> 
> Ciao

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

Re: Figuring out kde-runtime: localization

[Albert Astals Cid]

El Divendres, 21 de febrer de 2014, a les 13:17:58, Aleix Pol va escriure:
> Hi,
> Going through the information we have in kde-runtime [1] we found there are
> two subdirectories related to localization (localization and l10n) that we
> couldn't find a correct place to move to.

Who is we?

Why are you asking the documentation list about this?

> 
> Can anybody give us a hand and help us figure those out?
> - localization: has plenty of information regarding different currencies.

Yes, used in kcurrencycode.cpp at least (which by the way says "see KLocale", 
which is weird in the kunitconversion framework), I guess you could move it to 
the kunitconversion framework

> - l10n: has information about different countries.

Yes, the existance of those entry.desktop files is checked by 
./kio/src/core/global.cpp
./kconfigwidgets/src/klanguagebutton.cpp
./kxmlgui/src/khelpmenu.cpp
./kde4support/src/kdecore/klocale_kde.cpp

If you want to deprecate those files you'll have to fix kio, kconfigwidgets 
and kxmlgui to use whatever localization system KF5 is planning to use and 
then move these files to kde4support.

> Should these go to KI18n?

What do those files have to do with translations of strings?

> Qt?
> Anybody has plans for those?

Cheers,
  Albert

> 
> Aleix
> 
> [1] http://community.kde.org/Frameworks/Epics/New_Runtime_Organization

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

Re: Figuring out kde-runtime: localization

[Albert Astals Cid]

El Diumenge, 23 de febrer de 2014, a les 17:26:23, John Layt va escriure:
> On 21 February 2014 13:17, Aleix Pol  wrote:
> > Hi,
> > Going through the information we have in kde-runtime [1] we found there
> > are
> > two subdirectories related to localization (localization and l10n) that we
> > couldn't find a correct place to move to.
> > 
> > Can anybody give us a hand and help us figure those out?
> > - localization: has plenty of information regarding different currencies.
> > - l10n: has information about different countries.
> > 
> > Should these go to KI18n? Qt?
> > Anybody has plans for those?
> > 
> > Aleix
> > 
> > [1] http://community.kde.org/Frameworks/Epics/New_Runtime_Organization
> 
> The l10n directory holds the locale config files for each country.
> These files get used by KLocale.  The localization directory holds the
> currency config files used by KLocale and KCurrencyCode, as they
> couldn't go into l10n/ without messing up existing code, and the
> long-term plan was to move l10n/ into localization/ as a country/
> sub-directory.
> 
> In KF5 both KLocale and KCurrencyCode are in kde4support 

KCurrencyCode is in kunitconversion.

Cheers,
  Albert

> and have
> mostly been replaced by using QLocale.  As such both l10n and
> localization are only required if kde4support is installed and used.
> I assume the files must now be moved into kde4support?  Will we also
> need to think about what happens with parallel installs with KDE4?
> 
> As Albert points out, there looks to be a couple of other places the
> files are used in KF5 code that will need porting to QLocale instead,
> or if they are only appropriate with KLocale then moving to
> kde4support.  I'll try have a look later today.
> 
> I have a separate email about locale configuration in Plasma Next that
> I'll post on the Plasma list a bit later.
> 
> John.
> ___
> Kde-frameworks-devel mailing list
> Kde-frameworks-devel@kde.org
> https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

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

Re: Review Request 115959: Resurrect KConfigDialog::setHelp (used to come from KDialog). Move KHelpClient down from kxmlgui, for use in KConfigDialog.

[Albert Astals Cid]

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



src/khelpclient.cpp
<https://git.reviewboard.kde.org/r/115959/#comment35626>

Just curious, who is doing this "call setApplicationName() with the name of 
the desktop file" thing? I know KApplication did it but we're now not 
recommending to use it. Or is this something every app developer has to do? Is 
it documented somewhere?



src/khelpclient.cpp
<https://git.reviewboard.kde.org/r/115959/#comment35624>

url is always help:/ isn't it? Not sure i understand the comment


- Albert Astals Cid


On Feb. 23, 2014, 11 a.m., David Faure wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/115959/
> ---
> 
> (Updated Feb. 23, 2014, 11 a.m.)
> 
> 
> Review request for KDE Frameworks and Albert Astals Cid.
> 
> 
> Repository: kconfigwidgets
> 
> 
> Description
> ---
> 
> 3 commits:
> 
> 
> Unittest: make errors readable
> 
> --
> 
> Resurrect KConfigDialog::setHelp (used to come from KDialog).
> 
> It controls the default behavior of showHelp(), which is implemented
> using KHelpClient.
> 
> REVIEW: 115959
> 
> --
> 
> Move KHelpClient down from kxmlgui, for use in KConfigDialog.
> 
> 
> Diffs
> -
> 
>   autotests/kconfigdialog_unittest.cpp 
> e5322c1782c2a68c15451777066e28a9b7afea23 
>   src/CMakeLists.txt 7da7fba0c15153d6dee381c2b8f282e9837eae36 
>   src/kconfigdialog.h b06efc588c772ed655d581a0e021d92af5e0e280 
>   src/kconfigdialog.cpp 8db48e23f614530cef11a23a182b50d905327405 
>   src/khelpclient.h PRE-CREATION 
>   src/khelpclient.cpp PRE-CREATION 
> 
> Diff: https://git.reviewboard.kde.org/r/115959/diff/
> 
> 
> Testing
> ---
> 
> Compiled all of KF5.
> 
> 
> Thanks,
> 
> David Faure
> 
>

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

Re: Review Request 116103: Make KI18N a public dependency of KIO since public installed headers of KIO requires it

[Albert Astals Cid]

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


have you tried removing the include?

- Albert Astals Cid


On Feb. 26, 2014, 9:44 p.m., Matthieu Gallien wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/116103/
> ---
> 
> (Updated Feb. 26, 2014, 9:44 p.m.)
> 
> 
> Review request for KDE Frameworks.
> 
> 
> Repository: kio
> 
> 
> Description
> ---
> 
> include/KF5/KIOCore/kio/slavebase.h is including headers from KI18N and is 
> publically installed.
> 
> 
> Diffs
> -
> 
>   KF5KIOConfig.cmake.in 3a947b7 
>   src/core/CMakeLists.txt d897e37 
> 
> Diff: https://git.reviewboard.kde.org/r/116103/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Matthieu Gallien
> 
>

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

Re: Review Request 116103: Make KI18N a public dependency of KIO since public installed headers of KIO requires it

[Albert Astals Cid]

> On Feb. 26, 2014, 9:57 p.m., Albert Astals Cid wrote:
> > have you tried removing the include?

Ignore me, there's i18n calls in there :D


- Albert


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


On Feb. 26, 2014, 9:44 p.m., Matthieu Gallien wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/116103/
> ---
> 
> (Updated Feb. 26, 2014, 9:44 p.m.)
> 
> 
> Review request for KDE Frameworks.
> 
> 
> Repository: kio
> 
> 
> Description
> ---
> 
> include/KF5/KIOCore/kio/slavebase.h is including headers from KI18N and is 
> publically installed.
> 
> 
> Diffs
> -
> 
>   KF5KIOConfig.cmake.in 3a947b7 
>   src/core/CMakeLists.txt d897e37 
> 
> Diff: https://git.reviewboard.kde.org/r/116103/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Matthieu Gallien
> 
>

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

Re: Review Request 116103: Make KI18N a public dependency of KIO since public installed headers of KIO requires it

[Albert Astals Cid]

> On Feb. 26, 2014, 9:57 p.m., Albert Astals Cid wrote:
> > have you tried removing the include?
> 
> Albert Astals Cid wrote:
> Ignore me, there's i18n calls in there :D
> 
> Alex Merry wrote:
> However, I wonder if those calls should really be in the header.  I have 
> no idea what catalogue they will use at runtime; I suspect it will depend on 
> whether code that includes the header defined TRANSLATION_DOMAIN and where, 
> exactly, they do so.
> 
> A better solution (SC but not BC) is probably to create overloaded 
> methods and put those calls in the cpp file.
> 
> Aurélien Gâteau wrote:
> May I suggest this instead:
> 
> diff --git a/src/core/slavebase.cpp b/src/core/slavebase.cpp
> index 1236ad5..2002cdf 100644
> --- a/src/core/slavebase.cpp
> +++ b/src/core/slavebase.cpp
> @@ -968,9 +968,11 @@ int SlaveBase::messageBox(MessageBoxType type, const 
> QString &text, const QStrin
>  }
>  
>  int SlaveBase::messageBox(const QString &text, MessageBoxType type, 
> const QString &caption,
> -  const QString &buttonYes, const QString 
> &buttonNo,
> +  const QString &_buttonYes, const QString 
> &_buttonNo,
>const QString &dontAskAgainName)
>  {
> +QString buttonYes = _buttonYes.isEmpty() ? i18n("&Yes") : _buttonYes;
> +QString buttonNo = _buttonNo.isEmpty() ? i18n("&No") : _buttonNo;
>  //qDebug() << "messageBox " << type << " " << text << " - " << 
> caption << buttonYes << buttonNo;
>  KIO_DATA << (qint32)type << text << caption << buttonYes << buttonNo 
> << dontAskAgainName;
>  send(INF_MESSAGEBOX, data);
> diff --git a/src/core/slavebase.h b/src/core/slavebase.h
> index 86f1506..0922893 100644
> --- a/src/core/slavebase.h
> +++ b/src/core/slavebase.h
> @@ -24,7 +24,6 @@
>  #include 
>  #include 
>  #include "job_base.h" // for KIO::JobFlags
> -#include 
>  
>  #include 
>  #include 
> @@ -277,8 +276,8 @@ public:
>   */
>  int messageBox(MessageBoxType type, const QString &text,
> const QString &caption = QString(),
> -   const QString &buttonYes = i18n("&Yes"),
> -   const QString &buttonNo = i18n("&No"));
> +   const QString &buttonYes = QString(),
> +   const QString &buttonNo = QString());
>  
>  /**
>   * Call this to show a message box from the slave
> @@ -297,8 +296,8 @@ public:
>   */
>  int messageBox(const QString &text, MessageBoxType type,
> const QString &caption = QString(),
> -   const QString &buttonYes = i18n("&Yes"),
> -   const QString &buttonNo = i18n("&No"),
> +   const QString &buttonYes = QString(),
> +   const QString &buttonNo = QString(),
> const QString &dontAskAgainName = QString());
>  
>  /**
>
> 
> Matthieu Gallien wrote:
> Aurélien, do you want me to update the review request or do you do it 
> directly yourself ?

If we go Aurélien's way i'd document that QString() means Yes/No and not an 
empty string in there (which is actually be runtime incompatible with kde4.x 
but i think that's fair and not much people would be passing "" there to get a 
button with no text)

Moreover we could go with isNull instead of isEmpty so that actually passing "" 
does give you an empty button and QString() gives you yes/no.


- Albert


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


On Feb. 26, 2014, 9:44 p.m., Matthieu Gallien wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/116103/
> ---
> 
> (Updated Feb. 26, 2014, 9:44 p.m.)
> 
> 
> Review request for KDE Frameworks.
> 
> 
> Repository: kio
> 
> 
> Description
> ---
> 
> include/KF5/KIOCore/kio/slavebase.h is including headers from KI18N and is 
> publically installed.
> 
> 
> Diffs
> -
> 
>   KF5KIOConfig.cmake.in 3a947b7 
>   src/core/CMakeLists.txt d897e37 
> 
> Diff: https://git.reviewboard.kde.org/r/116103/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Matthieu Gallien
> 
>

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

Re: KActivities frameworks soon to become master

[Albert Astals Cid]

El Dijous, 27 de febrer de 2014, a les 11:23:59, Ivan Čukić va escriure:
> Hi all,
> 
> Now that the 4.13 has been branched out, KActivities will stop using the
> frameworks branch, and master will become the 'new black'.
> 
> There is only a question of how to proceed.
> 
> - Is it wiser just to ask the admins to move rename the branches (removing
> the old master) and blacklist the frameworks branch?

Personally i'd just merge framewoks to master and then blacklist framewoks

> - Should anything apart from the relevant file in kdesrc-build be changed?

kde:kde-build-metadata probably needs some updating too

> - Who are interested parties that this should be communicated to?

I'd go with kde-devel and release-team in addition to the current CC'ers.

Cheers,
  Albert

> 
> 
> Cheerio,
> Ivan
> 
> --
> While you were hanging yourself on someone else's words
> Dying to believe in what you heard
> I was staring straight into the shining sun

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

Re: Review Request 115959: Resurrect KConfigDialog::setHelp (used to come from KDialog). Move KHelpClient down from kxmlgui, for use in KConfigDialog.

[Albert Astals Cid]

> On Feb. 24, 2014, 9:22 p.m., Albert Astals Cid wrote:
> > src/khelpclient.cpp, line 76
> > <https://git.reviewboard.kde.org/r/115959/diff/2/?file=245608#file245608line76>
> >
> > url is always help:/ isn't it? Not sure i understand the comment
> 
> David Faure wrote:
> ? Not sure I understand *your* comment :-)
> 
> 
> QUrl url;
> if (!docPath.isEmpty()) {
> url = 
> QUrl(QLatin1String("help:/")).resolved(QUrl::fromUserInput(docPath));
> } else {
> url = 
> QUrl(QString::fromLatin1("help:/%1/index.html").arg(appname));
> }
> 
> if (!anchor.isEmpty()) {
> QUrlQuery query(url);
> query.addQueryItem(QString::fromLatin1("anchor"), anchor);
> url.setQuery(query);
> }
> 
> How is this "always help:/" ? There much stuff after that, in the path 
> and possibly in the query.
>

I mean "starts always with help:/", sorry. And if it always starts with help, 
the comment
// launch khelpcenter, or a browser for URIs not handled by khelpcenter
is a bit weird, since it's always the same kind of URIs, no?


- Albert


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


On Feb. 23, 2014, 11 a.m., David Faure wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/115959/
> ---
> 
> (Updated Feb. 23, 2014, 11 a.m.)
> 
> 
> Review request for KDE Frameworks and Albert Astals Cid.
> 
> 
> Repository: kconfigwidgets
> 
> 
> Description
> ---
> 
> 3 commits:
> 
> 
> Unittest: make errors readable
> 
> --
> 
> Resurrect KConfigDialog::setHelp (used to come from KDialog).
> 
> It controls the default behavior of showHelp(), which is implemented
> using KHelpClient.
> 
> REVIEW: 115959
> 
> --
> 
> Move KHelpClient down from kxmlgui, for use in KConfigDialog.
> 
> 
> Diffs
> -
> 
>   autotests/kconfigdialog_unittest.cpp 
> e5322c1782c2a68c15451777066e28a9b7afea23 
>   src/CMakeLists.txt 7da7fba0c15153d6dee381c2b8f282e9837eae36 
>   src/kconfigdialog.h b06efc588c772ed655d581a0e021d92af5e0e280 
>   src/kconfigdialog.cpp 8db48e23f614530cef11a23a182b50d905327405 
>   src/khelpclient.h PRE-CREATION 
>   src/khelpclient.cpp PRE-CREATION 
> 
> Diff: https://git.reviewboard.kde.org/r/115959/diff/
> 
> 
> Testing
> ---
> 
> Compiled all of KF5.
> 
> 
> Thanks,
> 
> David Faure
> 
>

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

Re: Binary incompatible changes

[Albert Astals Cid]

El Dissabte, 1 de març de 2014, a les 16:06:24, David Faure va escriure:
> On Saturday 01 March 2014 16:03:52 David Faure wrote:
> > So yeah, it's doable, but quite painful. I wish we could script this, but
> > "wait for CI" is hard to script...
> 
> Oh, and if one doesn't have the rights for "Build Now" on build.kde.org, one
> cannot fix things after messing up the push order.
> 
> Overall, the ideal solution would be if jenkins could notice that it needs
> to rebuild both A and B, and B depends on A (which it knows), so it needs
> to build A before B, rather than building B on top of an outdated A...

Right, but then if you need to build okular, you end up building 

polkit-qt-1 - Branch master
kdegraphics-mobipocket - Branch master
strigiutils - Branch master
poppler - Branch master
kactivities - Branch KDE/4.13
akonadi - Branch master
automoc - Branch master
plasma-mobile - Branch master
grantlee - Branch master
phonon - Branch master
kdepimlibs - Branch master
kdesupport-svn - Branch master
kdelibs - Branch master
qt - Branch 4.8
qca - Branch master
libkexiv2 - Branch master
soprano - Branch master
libstreams - Branch master
qjson - Branch master
nepomuk-core - Branch master
libdbusmenu-qt - Branch master
strigidaemon - Branch master
libstreamanalyzer - Branch master
shared-desktop-ontologies - Branch master
prison - Branch master
strigiclient - Branch master
cmake - Branch master
attica - Branch qt4
kde-workspace - Branch KDE/4.11

Every time someone commits to okular, which may a bit too much, no?

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

Re: Binary incompatible changes

[Albert Astals Cid]

El Dissabte, 1 de març de 2014, a les 16:53:28, David Faure va escriure:
> On Saturday 01 March 2014 16:39:56 Albert Astals Cid wrote:
> > Every time someone commits to okular, which may a bit too much, no?
> 
> This is not what I suggested.
> 
> I suggested: if A and B are both marked as "dirty" because a commit was just
> pushed to them, then look at whether one depends on the other, and rebuild
> in this order.
> 
> If A isn't "dirty", i.e. no commits for a long time, don't rebuild A.
> (where "A" is any okular dependency, in your example)

Ah, agreed, that makes sense. Anyone knows if it's possible?

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

Re: kjsembed tier (Re: Build failed in Jenkins: kjsembed_master_qt5 #27)

[Albert Astals Cid]

El Dissabte, 1 de març de 2014, a les 23:23:27, David Faure va escriure:
> On Saturday 01 March 2014 22:36:24 tsdg...@yahoo.es wrote:
> > The script solution has a big problem with l10n, so let's not go there
> > please.
> 
> I don't understand this. While compiling kjsembed, the translations are not
> available, are they? I fail to see the difference between converting docbook
> to man (for the english version, the only one that is in the kjsembed git
> repo) during compile time and committing that man page to git instead (in
> addition to the docbook source, of course!).

Ah sure, no different for translations then, the problem would be the 
occasional people changing the generated file instead of the souce file and the 
special casing for kjsembed.

Cheers,
  Albert

> 
> Translations come from the docbook file being cut into a po file and
> translated po files becoming docbook files in the l10n repo, right? This
> wouldn't change at all.

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

Re: KDNSSD merge

[Albert Astals Cid]

El Diumenge, 2 de març de 2014, a les 11:39:15, David Faure va escriure:
> On Saturday 01 March 2014 10:27:08 Alex Merry wrote:
> > On 01/03/14 09:55, David Faure wrote:
> > > On Tuesday 25 February 2014 20:37:28 Alex Merry wrote:
> > >> I've had a look at the kdnssd repositoy, and it contains two related
> > >> bits of code: the zeroconf ioslave and a kded/KDirWatch module to
> > >> notify
> > >> KIO about changes to available services.
> > >> 
> > >> These two obviously belong together; the question is where?  They can
> > >> go
> > >> in kdnssd-framework, making it depend on KIO, or they can go in KIO,
> > >> making it (optionally) depend on KDNSSD.
> > > 
> > > I don't like the idea of adding yet another dependency to KIO.
> > > 
> > > How about we put the kioslave which depends on kio+kdnssd into some
> > > tier4
> > > framework? After all it's not API, it's just some integration plugin,
> > > which is exactly what defines tier4.
> > 
> > Do we want a kioslaves framework (somewhat similar to the kimageplugins
> > framework)?
> 
> I think that would make sense -- we have a whole bunch of kioslaves in
> kde-runtime that we don't know where to put (lots of "??" in the
> New_Runtime_Organization epic).
> 
> I don't think we want all of these into the kio framework, that would make
> it depend on libsmbclient, libssh and all sorts of other libs.
> 
> Kevin, do you agree on a kioslaves.git repo, tier4?
> 
> > >> Also, what happens to the old repo, which is part of kdenetwork, and
> > >> hence KDE SC?
> > > 
> > > Nothing? Just like kdelibs.
> > 
> > Well, except we don't have a framework called "kdelibs", so there's no
> > name clash.  My question was: if we rename kdnssd-framework to kdnssd,
> > what happens to the existing kdnssd framework.
> 
> Ah, now I see.
> 
> > I suggested in another email that we also rename that.
> 
> ... to zeroconf-ioslave, right. That would be OK with me, but indeed this
> requires approval from release-team since it affects 4.x releases.

I wasn't following the discussion. Can anyone summarize how 4.x are releases 
affected?

Thanks!

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

Re: KDNSSD merge

[Albert Astals Cid]

El Diumenge, 2 de març de 2014, a les 21:32:58, Matthew Dawson va escriure:
> On March 3, 2014 12:51:10 AM Albert Astals Cid wrote:
> > I wasn't following the discussion. Can anyone summarize how 4.x are
> > releases affected?
> > 
> > Thanks!
> > 
> > Albert
> 
> The kdnssd repository in the kdenetwork module would be renamed to zeroconf-
> ioslave, and the kdnssd-framework repository would be renamed kdnssd.  The
> effect to 4.x is the kdenetwork module rename.

You guys already did that to kwallet and it didn't seem to be a blocker back 
then (kwallet tarball name is different in 4.12.3 vs 4.12.2)

Cheers,
  Albert

> 
> To maintain continuity in most packagers' setup, it was discussed that
> zeroconf-ioslave would still produce a kdnssd tarball.  Whether the tarball
> retains the same name or not wasn't decided, it was mostly left to what
> would be easiest for the release team and packagers.

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

Re: Binary incompatible changes

[Albert Astals Cid]

El Dimarts, 4 de març de 2014, a les 21:34:12, Ben Cooksley va escriure:
> On Tue, Mar 4, 2014 at 9:30 PM, David Faure  wrote:
> > On Tuesday 04 March 2014 12:08:07 Ben Cooksley wrote:
> >>  On Sun, Mar 2, 2014 at 5:03 AM, Albert Astals Cid  wrote:
> >> > El Dissabte, 1 de març de 2014, a les 16:53:28, David Faure va 
escriure:
> >> >> On Saturday 01 March 2014 16:39:56 Albert Astals Cid wrote:
> >> >> > Every time someone commits to okular, which may a bit too much, no?
> >> >> 
> >> >> This is not what I suggested.
> >> >> 
> >> >> I suggested: if A and B are both marked as "dirty" because a commit
> >> >> was
> >> >> just pushed to them, then look at whether one depends on the other,
> >> >> and
> >> >> rebuild in this order.
> >> >> 
> >> >> If A isn't "dirty", i.e. no commits for a long time, don't rebuild A.
> >> >> (where "A" is any okular dependency, in your example)
> >> > 
> >> > Ah, agreed, that makes sense. Anyone knows if it's possible?
> >> 
> >> This should be facilitated by the following Jenkins plugin.
> >> https://wiki.jenkins-ci.org/display/JENKINS/Build+Blocker+Plugin
> >> 
> >> However that means that someone will need to reconfigure all jobs to
> >> include the dependency metadata - so we will probably want to script
> >> it I imagine.
> > 
> > I'm a big fan of scripting (and I can write scripts for any change you'd
> > like to see made to a bunch of files) -- but I thought you said jenkins
> > jobs could not be modified in config files and had to be modified in the
> > GUI?
> Jenkins has an Web API which can be used, as well as a Java client to
> help interact with it.
> In terms of modifying the configuration files on disk - they're XML
> based data, and i'm not sure if we can get Jenkins to reparse them
> short of restarting it completely.

You can just update the xml via the Java api with
http://build.kde.org/cli/command/get-job
and
http://build.kde.org/cli/command/update-job

Cheers,
  Albert

> 
> > --
> > David Faure, fa...@kde.org, http://www.davidfaure.fr
> > Working on KDE, in particular KDE Frameworks 5
> 
> Thanks,
> Ben
> ___
> Kde-frameworks-devel mailing list
> Kde-frameworks-devel@kde.org
> https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

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

Re: Plasma Next - Translations KCM - What Languages?

[Albert Astals Cid]

El Divendres, 14 de març de 2014, a les 22:34:27, Chusslove Illich va 
escriure:
> > [: John Layt :]
> > Or do we list all languages regardless of whether they are installed or
> > not (probably way too many)?
> 
> I would rather go this way, have this finished once and for all. I would
> only try to clearly present it not as "you will get this language when you
> choose it" but as "this is the list of your preferred languages, you get
> first there is".

Is this really usable? I could choose three languages just to see i still get 
my text in english and then say "this is crap, KDE is not translated to any 
language" without realizing i actually have to install those languages 
translations.

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

Re: RFC on framework localization

[Albert Astals Cid]

El Divendres, 14 de març de 2014, a les 03:48:49, Aurélien Gâteau va escriure:
> Hi,
> 
> I started working on ensuring frameworks can be correctly localized and
> have some questions.
> 
> # Messages.sh place
> 
> I noticed some frameworks already have Messages.sh files in there. Most
> of them are in src/. Some are in subdirs of src/ (kio, plasma-framework,
> solid, kwallet, kactivities, kde4support). Are we OK with src/ being the
> default place, but then its up to the framework maintainer to adjust
> based on the framework needs?
> 
> I already updated the framework template in kde:kdeexamples to put a
> Messages.sh in src/.
> 
> # No translations
> 
> Some frameworks have no translatable strings. I think in this case there
> should not be any Messages.sh file. Is it OK for everybody?

Do we want to to guarantee they will keep having no translatable strings in 
future releases? How do we do it? Or just add a Messages.sh if they have 
translatable strings in the future?

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

Re: Plasma Next - Translations KCM - What Languages?

[Albert Astals Cid]

El Diumenge, 16 de març de 2014, a les 15:49:02, Chusslove Illich va escriure:
> >>> [: John Layt :]
> >>> Or do we list all languages regardless of whether they are installed or
> >>> not (probably way too many)?
> >> 
> >> [: Chusslove Illich :]
> >> I would rather go this way, have this finished once and for all. I would
> >> only try to clearly present it not as "you will get this language when
> >> you choose it" but as "this is the list of your preferred languages, you
> >> get first there is".
> > 
> > [: Albert Astals Cid :]
> > Is this really usable? I could choose three languages just to see i still
> > get my text in english and then say "this is crap, KDE is not translated
> > to any language" without realizing i actually have to install those
> > languages translations.
> 
> With standard Gettext approach it was always like this: user language
> selection are preferred languages, not necessarily available. The user sets
> LANG for the locale and the single main language, and possibly LANGUAGES for
> special order of preference. In GUI context, the login manager lets user
> chose one of the locales and that's it. If some translation is available
> but not installed, no hand-holding.
> 
> With the intention being that the KCM now controls LANGUAGES, 

Is that happening?

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

Re: RFC on framework localization

[Albert Astals Cid]

El Dilluns, 17 de març de 2014, a les 08:25:59, Aurélien Gâteau va escriure:
> On Sat, Mar 15, 2014, at 8:52, Albert Astals Cid wrote:
> > El Divendres, 14 de març de 2014, a les 03:48:49, Aurélien Gâteau va
> > 
> > escriure:
> > > Hi,
> > > 
> > > I started working on ensuring frameworks can be correctly localized and
> > > have some questions.
> > > 
> > > # Messages.sh place
> > > 
> > > I noticed some frameworks already have Messages.sh files in there. Most
> > > of them are in src/. Some are in subdirs of src/ (kio, plasma-framework,
> > > solid, kwallet, kactivities, kde4support). Are we OK with src/ being the
> > > default place, but then its up to the framework maintainer to adjust
> > > based on the framework needs?
> > > 
> > > I already updated the framework template in kde:kdeexamples to put a
> > > Messages.sh in src/.
> > > 
> > > # No translations
> > > 
> > > Some frameworks have no translatable strings. I think in this case there
> > > should not be any Messages.sh file. Is it OK for everybody?
> > 
> > Do we want to to guarantee they will keep having no translatable strings
> > in
> > future releases? How do we do it? Or just add a Messages.sh if they have
> > translatable strings in the future?
> 
> You are right, it feels safer to add a Messages.sh by default.

But if you do that you also need to add the code to load the catalog (for the 
non ki18n based ones since ki18n will do it automatically).

No?

Cheers,
  Albert

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

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

Re: Handling of frameworks using Qt-based translations

[Albert Astals Cid]

El Dijous, 20 de març de 2014, a les 07:06:58, Aurélien Gâteau va escriure:
> On Tue, Mar 18, 2014, at 9:49, Aurélien Gâteau wrote:
> 
> On Tue, Mar 18, 2014, at 9:07, Aleix Pol wrote:
> 
> On Tue, Mar 18, 2014 at 4:12 PM, Aurélien Gâteau <[1]agat...@kde.org>
> wrote:
> 
> On Tue, Mar 18, 2014, at 6:20, Aleix Pol wrote:
> 
> On Tue, Mar 18, 2014 at 2:05 PM, Aurélien Gâteau <[2]agat...@kde.org>
> wrote:
> 
> Hi,
> 
> 
> I started working on how to handle Qt based translations, and make it
> as
> 
> simple as possible to work with for framework maintainers as well as
> 
> framework users.
> 
> 
> I picked KBookmarks as my guinea pig and got to the point where
> 
> kbookmarkdialogtest shows a translated dialog.
> 
> 
> Here is how it currently works. All of this is liberally inspired from
> 
> the way Trojita works:
> 
> 
> # String extraction
> 
> 
> I created a src/Messages.sh which contains the following:
> 
> 
> lupdate -silent -recursive . -ts $podir/tmp.ts
> 
> lconvert $podir/tmp.ts --sort-contexts --output-format pot -o
> 
> $podir/kbookmarks5.pot
> 
> rm $podir/tmp.ts
> 
> 
> # String compilation
> 
> 
> I modified the toplevel CMakeLists.txt, adding these lines:
> 
> 
> if (EXISTS ${CMAKE_CURRENT_SOURCE_DIR}/po)
> 
> include(${CMAKE_CURRENT_SOURCE_DIR}/QmSupport.cmake)
> 
> qm_setup(kbookmarks5 po)
> 
> endif()
> 
> 
> I created a QmSupport.cmake file, which exposes a qm_setup() function.
> 
> This function does three things:
> 
> 1. Create a "qm" target which turns all .po into .qm files.
> 
> 
> 2. Call install(FILES...) on the generated qm files, installing them in
> 
> share/${name}/locale, where ${name} is the firt argument of qm_setup().
> 
> 
> 3. Generate a "${name}_translation.h" which contain two inline
> functions
> 
> to make it easy to load the translations.
> 
> Using the translation is then just a matter of including
> 
> ${name}_translation.h and calling ${name}_installTranslator(). If more
> 
> control is needed, ${name}_installTranslator() also accepts an optional
> 
> argument: the language. For even finer control, the .h also contains a
> 
> ${name}_createTranslator() function, which returns a QTranslator loaded
> 
> with strings for the right language.
> 
> 
> # Questions
> 
> 
> Does this approach sounds sane to you?
> 
> 
> I think QmSupport.cmake should go to extra-cmake-modules. Any
> 
> objections?
> 
> 
> Right now qm_setup() is very inflexible: it installs files and creates
> 
> the _translation.h file based on the name argument, meaning in my
> 
> example it creates share/kbookmarks5/locale/kbookmarks5_*.qm and
> 
> include/kbookmarks5_translation.h, which contains the functions
> 
> kbookmarks5_createTranslator and kbookmarks5_installTranslator.
> 
> 
> I think we want to be able to customize the install dir of the
> 
> _translation.h file because some frameworks install header files in a
> 
> subdir, others do not.
> 
> 
> Should we also be able to customize the install data dir for qm files,
> 
> as well as the prefix of the function names from _translation.h? I am
> 
> tempted to default to ${PROJECT_NAME} for the prefix of the function
> 
> names, its lowercase version for the install data dir and add an
> 
> optional PROJECT_NAME argument to qm_setup(). Opinions?
> 
> 
> I am attaching the diff of the current state. I do not intend to commit
> 
> it as is since po files are not supposed to be in the framework
> 
> repository, but it should make it easy for you to try it if you are
> 
> interested.
> 
> 
> Aurélien
> 
> 
> ___
> 
> Kde-frameworks-devel mailing list
> 
> [3]Kde-frameworks-devel@kde.org
> 
> [4]https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
> 
> 
> 
> Hi Aurélien,
> Wouldn't it make sense that the library called the createTranslation
> itself, instead of expecting the application to call it? I can easily
> see applications forgetting it.
> Maybe using Q_COREAPP_STARTUP_FUNCTION?
> 
> 
> That could work, but would remove the ability to change the language
> later (Some Qt apps like to let the user use a different language than
> the system one for some reason). Not sure we care about this. It
> certainly sounds more foolproof. On the other hand, you already *must*
> load translations yourself if you are using any Qt standard dialog,
> otherwise it won't be translated either.
> 
> Aurélien
> 
> 
> ___
> 
> Kde-frameworks-devel mailing list
> 
> [5]Kde-frameworks-devel@kde.org
> 
> [6]https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
> 
> 
> Well, for KI18n changing the language at run-time is not possible.
> 
> Maybe we can set it up magically for general use and still install the
> createTranslation thing in case the application likes to do it
> specifically?
> 
> 
> That is right. Let's keep it simple then and not provide a feature
> which is not supported by KI18n-powered frameworks.
> 
> This means we need to add a generated .cpp file

Re: Final kde-runtime splitting plan

[Albert Astals Cid]

El Dimarts, 25 de març de 2014, a les 16:18:22, Àlex Fiestas va escriure:
> Hi there
> 
> Today Aleix and I are starting to split kde-runtime so we have gone through
> all the components again making sure that everything has a suitable
> destination. The result is this [1] wiki.
> 
> Please, check that you are ok with the destination of each component and
> also check the things that have been targeted as **REMOVE** should be
> really removed (we believe so).

Can you give a rationale of why we're removing the following things?

kfile4
kio_cgi
kio settings

Cheers,
  Albert

> 
> Cheers !
> [1] http://community.kde.org/Frameworks/Epics/New_Runtime_Organization

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

Re: Final kde-runtime splitting plan

[Albert Astals Cid]

El Dimecres, 26 de març de 2014, a les 11:42:01, Àlex Fiestas va escriure:
> On Tuesday 25 March 2014 20:00:51 Albert Astals Cid wrote:
> > Can you give a rationale of why we're removing the following things?
> > 
> > kfile4
> 
> kfile4 is only useful to test a library that is right now on kde4support.
> Maybe we can move it there if you want.

Wouldn't hurt. What do others think?

> > kio_cgi
> 
> Who needs to execute a cgi script without a web server? If you do then we
> can move it its own repo, I really don't want to see distributions shipping
> this kio in a package such of "kioslaves-extras" since it really doesn't
> offer anything useful for most of our user base.

Well you can't know it offers anything useful, and at the end it's a few lines 
of code that doesn't seem to need lots of maintainance, so why kill them?

> 
> > kio settings
> 
> Browsing the settings in the file browser does not seem like a really
> convenient thing to have, and of course it adds more code to maintain.
> If you want to keep it that's fine but then please become maintainer and
> tell us where to move it (maybe kioslave-extra?).

Same as kio_cgi, I don't see why you want to kill something "that works" and 
that you have no objective way to know if people are using or not.

Cheers,
  Albert

> 
> Cheers!

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

Re: Move KDED out of frameworks?

[Albert Astals Cid]

El Divendres, 28 de març de 2014, a les 20:55:02, Boudewijn Rempt va escriure:
> On Fri, 28 Mar 2014, Kevin Krammer wrote:
> > The D-Bus session/user daemon is also something that needs to be treated
> > in a platform specific way as a dependency.
> > E.g. on Windows there could be a D-Bus installer that applications bundle
> > and run if necessary, very much like Games bunlding an DirectX installer.
> Oh no, I never would do that... It would still cost me many hours of my
> life dealing with it, and it would still give my users no advantage at
> all. There just isn't any reason an application like Krita would need an
> ipc solution -- and any library that insists on coming with one is just
> not going to make the cut.
> 
> (Heck, it's just like sycoca... That thing has cost me weeks of my life,
> all totted up, and has not delivered anything useful at all.)

That's a really not helpful nor constructive sentence.

Cheers,
  Albert

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

Review Request 117194: Remove weird comment

[Albert Astals Cid]

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

Review request for KDE Frameworks.


Repository: kbookmarks


Description
---

No idea what this comment is about and it also makes lupdate unhappy

./src
/home/scripty/prod/git-unstable/frameworks_kbookmarks/src/kbookmark.h:99: 
Discarding unconsumed meta data


Diffs
-

  src/kbookmark.h 2307ca9 

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


Testing
---


Thanks,

Albert Astals Cid

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

Does KKeyserver QT_TR_NOOP work?

[Albert Astals Cid]

Running lupdate complains so I'm not sure it does

/home/scripty/prod/git-
unstable/frameworks_kwindowsystem/src/kkeyserver_x11.cpp:88: Class 
'KKeyServer' lacks Q_OBJECT macro

Note that KKeyServer is not a class...

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

Does sonnet tr() work?

[Albert Astals Cid]

/home/scripty/prod/git-
unstable/frameworks_sonnet/src/ui/spellcheckdecorator.cpp:35: Ignoring 
definition of undeclared qualified class
/home/scripty/prod/git-
unstable/frameworks_sonnet/src/ui/spellcheckdecorator.cpp:137: Qualifying with 
unknown namespace/class ::SpellCheckDecorator

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