See
http://build.kde.org/job/kwindowsystem_master_qt5/Variation=All,label=LINBUILDER/changes
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
See
http://build.kde.org/job/kwindowsystem_master_qt5/Variation=All,label=LINBUILDER/40/
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/117353/
---
Review request for KDE Frameworks and Eike Hein.
Repository:
Hello,
On Thursday 03 April 2014 09:50:24 Jos Poortvliet wrote:
On Wednesday 19 March 2014 10:41:15 Ben Cooksley wrote:
On Wed, Mar 19, 2014 at 7:15 AM, Kevin Ottens er...@kde.org wrote:
Hello,
Hi,
On Monday 17 March 2014 22:53:25 Mario Fux KDE ML wrote:
Am Montag, 17. März
ahoy,
I just wanted to ask whether it is still mandatory to have a
KAboutData instance set to have classes such as KConfigShared work in
a convenient fashion (e.g. KConfigShared::openConfig() will open the
applications config as long as qapp::applicationName is set).
In my particular case the
On 03/04/14 09:34, Harald Sitter wrote:
ahoy,
I just wanted to ask whether it is still mandatory to have a
KAboutData instance set to have classes such as KConfigShared work in
a convenient fashion (e.g. KConfigShared::openConfig() will open the
applications config as long as
On Thu, Apr 3, 2014 at 12:30 PM, Alex Merry alex.me...@kde.org wrote:
On 03/04/14 09:34, Harald Sitter wrote:
ahoy,
I just wanted to ask whether it is still mandatory to have a
KAboutData instance set to have classes such as KConfigShared work in
a convenient fashion (e.g.
---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/117342/#review54920
---
Ship it!
Thanks
- Burkhard Lück
On April 2, 2014, 11:03
---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/117341/#review54924
---
Ship it!
Thanks
- Burkhard Lück
On April 2, 2014, 10:02
On Thu, Feb 27, 2014 at 5:15 PM, John Layt jl...@kde.org wrote:
Hi,
I've been reviewing KUnitConversion (KUC for short) and doing some small
clean-ups, and I'm slowly coming to the conclusion I'm not a fan of the
api.
However it is used in a few places, so rather than try rewrite the api in
---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/117304/
---
(Updated April 3, 2014, 12:17 p.m.)
Review request for KDE Frameworks
On Wednesday, April 02, 2014 07:07:27 PM Kevin Ottens wrote:
On Wednesday 02 April 2014 18:48:24 Aleix Pol wrote:
- with bugzilla integration (additionally to the previous ones):
KF5::XmlRpcClient KF5::Wallet KF5::WebKit KF5::ConfigWidgets
KF5::WidgetsAddons KF5::JobWidgets KF5::Completion
---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/117342/#review54962
---
This review has been submitted with commit
---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/117342/
---
(Updated April 3, 2014, 9:30 p.m.)
Status
--
This change has been
---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/117341/
---
(Updated April 3, 2014, 9:31 p.m.)
Status
--
This change has been
---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/117341/#review54963
---
This review has been submitted with commit
On 02/04/14 18:07, Kevin Ottens wrote:
KF5::WindowSystem
That's only for KStartupInfo right?
Pretty sure that doesn't work, either.
QX11Info should probably get a startupId() method. That's vaguely on my
to-do list somewhere...
Alex
___
On Wednesday 19 March 2014 10:41:15 Ben Cooksley wrote:
On Wed, Mar 19, 2014 at 7:15 AM, Kevin Ottens er...@kde.org wrote:
Hello,
Hi,
On Monday 17 March 2014 22:53:25 Mario Fux KDE ML wrote:
Am Montag, 17. März 2014, 18.15:09 schrieb Kevin Ottens:
Porting Aids:
* kde4support
Hi,
I would like to make libmm-qt and libnm-qt as KDE frameworks, they are based
only on Qt, so they could be in Tier 1. I've already started (you can see
framework branches) and I would like to ask to a few questions.
1) How to name them? Until now we named them ModemManagerQt and
Hi all,
1) I do not see a real need to rename (again) ModemManagerQt and
NetworkManagerQt. They are named that way to indicate they depend only on
Qt and not on any library created by KDE, so they are tier1 since the
beginning. I am not familiar with KF5's library naming conventions but I
would
On Thursday 03 of April 2014 12:52 Lamarque Souza wrote:
Hi all,
1) I do not see a real need to rename (again) ModemManagerQt and
NetworkManagerQt. They are named that way to indicate they depend only on
Qt and not on any library created by KDE, so they are tier1 since the
beginning. I am
Well, NetworkManagerQt and ModemManagerQt are Qt only libraries since the
beginning. They are not meant to depend on any KDE libraries as I said, so
they are not meant to be merged to KF5. I looked the branches frameworks
and you basically did just that (make them depend on KF5). I think we
should
Hello,
On Thursday 03 April 2014 16:47:38 Jan Grulich wrote:
1) How to name them? Until now we named them ModemManagerQt and
NetworkManagerQt, but if we add KF5 prefix, it would be maybe better to name
it only ModemManager/NetworkManager (with KF5 prefix), but there is a
problem, if you will
23 matches
Mail list logo
