---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/117275/#review55486
---
Ship it!
Ship It!
- David Faure
On April 1, 2014, 10:09
On April 12, 2014, 9:16 a.m., David Faure wrote:
Ship It!
Well, I guess the first diff minimizes the porting effort indeed.
Also: the domain name can only be passed to QCoreApp if this is the main
aboutdata (we also have a KAboutData per plugin).
But yeah, that seems to be missing in
---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/117508/
---
Review request for KDE Frameworks and Alex Merry.
Repository: kio
On April 12, 2014, 9:16 a.m., David Faure wrote:
Ship It!
David Faure wrote:
Well, I guess the first diff minimizes the porting effort indeed.
Also: the domain name can only be passed to QCoreApp if this is the main
aboutdata (we also have a KAboutData per plugin).
---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/117508/#review55490
---
Would it not make sense to put the compatibility stuff in
On April 12, 2014, 10:11 a.m., Alex Merry wrote:
Would it not make sense to put the compatibility stuff in
KIO::Job::addMetaData, rather than the slaves? That way it should maintain
compatibility on both the application and slave side (for slaves shipped
outside KIO).
Although
On April 12, 2014, 9:16 a.m., David Faure wrote:
Ship It!
David Faure wrote:
Well, I guess the first diff minimizes the porting effort indeed.
Also: the domain name can only be passed to QCoreApp if this is the main
aboutdata (we also have a KAboutData per plugin).
On April 12, 2014, 10:11 a.m., Alex Merry wrote:
Would it not make sense to put the compatibility stuff in
KIO::Job::addMetaData, rather than the slaves? That way it should maintain
compatibility on both the application and slave side (for slaves shipped
outside KIO).
Although
On April 12, 2014, 10:11 a.m., Alex Merry wrote:
Would it not make sense to put the compatibility stuff in
KIO::Job::addMetaData, rather than the slaves? That way it should maintain
compatibility on both the application and slave side (for slaves shipped
outside KIO).
Although
On April 12, 2014, 10:11 a.m., Alex Merry wrote:
Would it not make sense to put the compatibility stuff in
KIO::Job::addMetaData, rather than the slaves? That way it should maintain
compatibility on both the application and slave side (for slaves shipped
outside KIO).
Although
---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/117508/#review55496
---
Ship it!
OK, I'm convinced.
- Alex Merry
On April 12,
---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/117016/#review55497
---
This is my preferred solution, and is hopefully only a
---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/117016/#review55498
---
src/kcrash.cpp
---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/117508/#review55499
---
This review has been submitted with commit
---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/117508/
---
(Updated April 12, 2014, 10:51 a.m.)
Status
--
This change has been
---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/117511/
---
Review request for KDE Frameworks, Ivan Čukić and Kevin Krammer.
On April 5, 2014, 8:59 p.m., David Faure wrote:
docs/kbuildsycoca5/man-kbuildsycoca5.8.docbook, line 39
https://git.reviewboard.kde.org/r/117320/diff/1/?file=262293#file262293line39
Users don't know KService... better talk about the desktop file system
configuration cache.
On April 5, 2014, 8:59 p.m., David Faure wrote:
docs/kbuildsycoca5/man-kbuildsycoca5.8.docbook, line 280
https://git.reviewboard.kde.org/r/117320/diff/1/?file=262293#file262293line280
LOL, that was optimistic :)
Alex Merry wrote:
That was copied verbatim from the old file.
---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/117511/#review55504
---
I wonder if this really belongs in kdecoreaddons. I.e. it is
---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/117320/#review55505
---
This review has been submitted with commit
---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/117320/
---
(Updated April 12, 2014, 11:17 a.m.)
Status
--
This change has been
On April 12, 2014, 11:12 a.m., Kevin Krammer wrote:
I wonder if this really belongs in kdecoreaddons. I.e. it is only relevant
for KDE applications porting, right?
IMHO this would fit best in an explicit porting framework
I don't want to put this in kdelibs4support because apps are
Hi,
I just realized that we're not generating the API documentation for Plasma
Framework here [1].
Maybe it would be worth adding?
Aleix
[1] http://api.kde.org/frameworks-api/frameworks5-apidocs/
___
Kde-frameworks-devel mailing list
On 12/04/14 12:48, Aleix Pol wrote:
Hi,
I just realized that we're not generating the API documentation for
Plasma Framework here [1].
Maybe it would be worth adding?
I think it currently just grabs everything in /frameworks on
project.kde.org.
Alex
Just a heads up that I'm planning to move KPluginLoader, KPluginFactory
and kexportplugin.h from KService to KCoreAddons this weekend, as
previously discussed (it's SC, as it will involve putting KCoreAddons
into the link interface of KService).
I have an open review request for KPluginLoader in
On Monday 07 April 2014 21:20:19 Ben Cooksley wrote:
On Mon, Apr 7, 2014 at 9:12 PM, Àlex Fiestas afies...@kde.org wrote:
On Friday 04 April 2014 15:41:07 Martin Gräßlin wrote:
Given that kglobalaccel is only intended for the kde-workspaces anyway my
suggestion is to move it into
El Divendres, 11 d'abril de 2014, a les 01:36:12, Aurélien Gâteau va escriure:
On Thu, Apr 10, 2014, at 14:17, Albert Astals Cid wrote:
Hi, do you think it makes sense to use that postfix?
We are using this currently for stuff like marble and trojita so our
translators know they can't
---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/117475/
---
(Updated April 12, 2014, 6:39 p.m.)
Review request for KDE Frameworks
---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/117330/
---
(Updated April 12, 2014, 6:41 p.m.)
Review request for KDE Frameworks,
---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/117330/#review55538
---
Builds and installs, although I can't get khelpcenter to
---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/117475/#review55539
---
We might not install such desktop files anymore, but I don't
On April 12, 2014, 9:30 p.m., Burkhard Lück wrote:
Builds and installs, although I can't get khelpcenter to display it
(tried `khelpcenter help:blah`,
but that just displays the string There is no documentation available
for /blah.).
Of course khelpcenter help:blah will not
---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/117529/
---
Review request for Documentation and KDE Frameworks.
Repository:
33 matches
Mail list logo
