Re: Review Request 111093: PolKit Actions KCM: do not crash if policies could not be read

[Commit Hook]

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

(Updated Sept. 24, 2013, 4:42 p.m.)


Status
--

This change has been marked as submitted.


Review request for kde-workspace and Polkit KDE Configuration.


Description
---

The referenced bug describes a crash in the System Settings - System 
Administration - Actions Policy module.  The first time that an action is 
clicked on, an attempt is made to read the current system policy settings via 
ActionWidget::reloadPKLAs().  Internally this checks the authorisation for the 
org.kde.polkitkde1.readauthorizations action.  If this action is not allowed, 
or the authorization fails, then a DBus error is returned - but never checked.  
There is then a crash (via qFatal) when an attempt is made to read from the 
invalid returned QDBusArgument.

Unless the user made a mistake (e.g. typing the root password incorrectly), 
this indicates a system configuration problem.  However, even if the fix needs 
to be elsewhere, systemsettings should not just crash with no indication of 
where the problem lies.

This change checks and reports the DBus error if one is returned.  Nothing can 
be done within this module if this is the case, but at least there is a 
diagnostic message.  The widget is left disabled, but will try the 
authorization again if another action is selected.


This addresses bug 300050.
http://bugs.kde.org/show_bug.cgi?id=300050


Diffs
-

  polkitactions/ActionWidget.h ca83bf5 
  polkitactions/ActionWidget.cpp c5785c0 

Diff: http://git.reviewboard.kde.org/r/111093/diff/


Testing
---

With the default policy in place for org.kde.polkit1.readauthorizations (active 
session = auth_admin, inactive session = no), run 'kcmshell4 
kcm_polkitactions'.  Expand the tree and click on any action.  In the password 
dialogue, either cancel or enter an incorrect password.  Check that there is no 
crash and that the message box is displayed.

Click on another action, correctly enter the password and observe that there is 
no message and policies are displayed as expected.


Thanks,

Jonathan Marten

Re: Review Request 111093: PolKit Actions KCM: do not crash if policies could not be read

[Commit Hook]

---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/111093/#review40711
---


This review has been submitted with commit 
9ad726f709161853932a89205f3f1e0f3f7291ce by Jonathan Marten to branch master.

- Commit Hook


On Sept. 18, 2013, 8:37 a.m., Jonathan Marten wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/111093/
> ---
> 
> (Updated Sept. 18, 2013, 8:37 a.m.)
> 
> 
> Review request for kde-workspace and Polkit KDE Configuration.
> 
> 
> Description
> ---
> 
> The referenced bug describes a crash in the System Settings - System 
> Administration - Actions Policy module.  The first time that an action is 
> clicked on, an attempt is made to read the current system policy settings via 
> ActionWidget::reloadPKLAs().  Internally this checks the authorisation for 
> the org.kde.polkitkde1.readauthorizations action.  If this action is not 
> allowed, or the authorization fails, then a DBus error is returned - but 
> never checked.  There is then a crash (via qFatal) when an attempt is made to 
> read from the invalid returned QDBusArgument.
> 
> Unless the user made a mistake (e.g. typing the root password incorrectly), 
> this indicates a system configuration problem.  However, even if the fix 
> needs to be elsewhere, systemsettings should not just crash with no 
> indication of where the problem lies.
> 
> This change checks and reports the DBus error if one is returned.  Nothing 
> can be done within this module if this is the case, but at least there is a 
> diagnostic message.  The widget is left disabled, but will try the 
> authorization again if another action is selected.
> 
> 
> This addresses bug 300050.
> http://bugs.kde.org/show_bug.cgi?id=300050
> 
> 
> Diffs
> -
> 
>   polkitactions/ActionWidget.h ca83bf5 
>   polkitactions/ActionWidget.cpp c5785c0 
> 
> Diff: http://git.reviewboard.kde.org/r/111093/diff/
> 
> 
> Testing
> ---
> 
> With the default policy in place for org.kde.polkit1.readauthorizations 
> (active session = auth_admin, inactive session = no), run 'kcmshell4 
> kcm_polkitactions'.  Expand the tree and click on any action.  In the 
> password dialogue, either cancel or enter an incorrect password.  Check that 
> there is no crash and that the message box is displayed.
> 
> Click on another action, correctly enter the password and observe that there 
> is no message and policies are displayed as expected.
> 
> 
> Thanks,
> 
> Jonathan Marten
> 
>

Re: Review Request 112756: KLinkItemSelectionModel: Do not change current index of mapped model if the mapped one is invalid

[Commit Hook]

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

(Updated Sept. 24, 2013, 3:42 p.m.)


Status
--

This change has been marked as submitted.


Review request for kdelibs and Stephen Kelly.


Description
---

I noticed Gwenview keyboard navigation broke with the latest 
KLinkItemSelectionModel changes: in browse mode, in a folder which contains 
both folders and images, something like this:

dir1 dir2 img1 img2

if img1 is selected, pressing the left arrow makes dir1 selected instead of 
dir2.

This can be explain as so: given the following 
model A with content: 
0. dir1
1. dir2
2. img1
3. img2

model B a proxy model on A with content:
0. img1
1. img2


AView and BView, views on each models and a KLinkItemSelectionModel to link 
selections between AView and BView.

Setting current index in AView to row 1, which does not exist in BView, 
currently causes KLinkItemSelectionModel to set BView current index to invalid, 
which in turns cause KLinkItemSelectionModel to set AView current index to 
invalid.

Patch in this request prevents invalid indexes from being propagated. I am not 
sure it is the best behavior though: maybe we don't want to propagate invalid 
indexes, unless the original index is invalid itself? If I set current index of 
AView to invalid, maybe BView current index should become invalid as well? I am 
happy to implement this alternate behavior if you think it's better.


Diffs
-

  kdeui/itemviews/klinkitemselectionmodel.cpp be8395f 
  kdeui/tests/klinkitemselectionmodeltest.cpp 91540fd 

Diff: http://git.reviewboard.kde.org/r/112756/diff/


Testing
---

Existing test case has been extended to test behavior in case of invalid 
indexes. Gwenview keyboard behavior is not broken anymore.


Thanks,

Aurélien Gâteau

Re: Review Request 112880: Added KColorSchemeToken class.

[Denis Kuplyakov]

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

(Updated Sept. 24, 2013, 4:08 p.m.)


Review request for KDE Frameworks and kdelibs.


Changes
---

Fixed includes


Description
---

It is wrapper to access KColorScheme's methods from QML code.
Also added Q_GADGET to KColorScheme to enable Q_ENUMS using, to make them 
accessible from QML code.

As it will be accepted, QML-clone of KgPopupItem will be posted for review to 
libkdegames, as it uses it to access KDE's color theme.

More info:
* search for "KDE theme colors API for QML" thread at kdelibs and kdegames 
mailinglists *

NEED TO FIX:
I can't include it like #include  at KReversi's code, only 
"kcolorschemetoken.h". Maybe I've missed something?


Diffs (updated)
-

  includes/CMakeLists.txt cdf0143 
  includes/KColorSchemeToken PRE-CREATION 
  kdeui/CMakeLists.txt b439e04 
  kdeui/colors/kcolorscheme.h 17570fd 
  kdeui/colors/kcolorscheme.cpp a6650ac 
  kdeui/colors/kcolorschemetoken.h PRE-CREATION 
  kdeui/colors/kcolorschemetoken.cpp PRE-CREATION 

Diff: http://git.reviewboard.kde.org/r/112880/diff/


Testing
---

I've tested it with KReversi's deniskup/gsoc2013/newdesign branch.


Thanks,

Denis Kuplyakov

Re: Review Request 112756: KLinkItemSelectionModel: Do not change current index of mapped model if the mapped one is invalid

[Commit Hook]

---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/112756/#review40708
---


This review has been submitted with commit 
dfcf2ffb1a934cf7dc48f71cf66f59e969abc116 by Aurélien Gâteau to branch KDE/4.11.

- Commit Hook


On Sept. 16, 2013, 1:56 p.m., Aurélien Gâteau wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/112756/
> ---
> 
> (Updated Sept. 16, 2013, 1:56 p.m.)
> 
> 
> Review request for kdelibs and Stephen Kelly.
> 
> 
> Description
> ---
> 
> I noticed Gwenview keyboard navigation broke with the latest 
> KLinkItemSelectionModel changes: in browse mode, in a folder which contains 
> both folders and images, something like this:
> 
> dir1 dir2 img1 img2
> 
> if img1 is selected, pressing the left arrow makes dir1 selected instead of 
> dir2.
> 
> This can be explain as so: given the following 
> model A with content: 
> 0. dir1
> 1. dir2
> 2. img1
> 3. img2
> 
> model B a proxy model on A with content:
> 0. img1
> 1. img2
> 
> 
> AView and BView, views on each models and a KLinkItemSelectionModel to link 
> selections between AView and BView.
> 
> Setting current index in AView to row 1, which does not exist in BView, 
> currently causes KLinkItemSelectionModel to set BView current index to 
> invalid, which in turns cause KLinkItemSelectionModel to set AView current 
> index to invalid.
> 
> Patch in this request prevents invalid indexes from being propagated. I am 
> not sure it is the best behavior though: maybe we don't want to propagate 
> invalid indexes, unless the original index is invalid itself? If I set 
> current index of AView to invalid, maybe BView current index should become 
> invalid as well? I am happy to implement this alternate behavior if you think 
> it's better.
> 
> 
> Diffs
> -
> 
>   kdeui/itemviews/klinkitemselectionmodel.cpp be8395f 
>   kdeui/tests/klinkitemselectionmodeltest.cpp 91540fd 
> 
> Diff: http://git.reviewboard.kde.org/r/112756/diff/
> 
> 
> Testing
> ---
> 
> Existing test case has been extended to test behavior in case of invalid 
> indexes. Gwenview keyboard behavior is not broken anymore.
> 
> 
> Thanks,
> 
> Aurélien Gâteau
> 
>

Re: Review Request 112575: KMenuedit documentation - improve introduction chapter and add use case section

[Julien Borderie]

---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/112575/#review40706
---

Ship it!


Ship It!

- Julien Borderie


On Sept. 21, 2013, 3:41 p.m., Burkhard Lück wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/112575/
> ---
> 
> (Updated Sept. 21, 2013, 3:41 p.m.)
> 
> 
> Review request for Documentation, kde-workspace and Julien Borderie.
> 
> 
> Description
> ---
> 
> improve introduction and add use cases (add, remove, hide entry, transfer 
> menu modifications)
> as requested on http://lists.kde.org/?l=kde-doc-english&m=137817779023377&w=2
> 
> 
> Diffs
> -
> 
>   doc/kmenuedit/index.docbook f62b55a 
> 
> Diff: http://git.reviewboard.kde.org/r/112575/diff/
> 
> 
> Testing
> ---
> 
> ebn, spellcheck, build + installed
> 
> 
> Thanks,
> 
> Burkhard Lück
> 
>

KF5 Update Meeting Minutes 2013-w39

[Kevin Ottens]

Hello everyone,

This is the minutes of the Week 39 KF5 meeting. As usual it has been held on 
#kde-devel at 4pm Paris time.

Were present: afiestas, agateau, apol, d_ed, dfaure, mck182, mgraesslin, 
sebas, shadeslayer, teo, vHanda, wojtask9 and myself.

Announcement:
 * I will be away next week, afiestas will be running the meetings in the 
meantime.

Topics discussed:
 * mck182 has been working on the printing support, all the planned features 
are upstream now, still a few bugs but he's working on them;
 * he also has some KTextWidgets work in the pipe, and would like to bring 
kregexpedit into frameworks;

 * afiestas moved KIO::NetAccess to KDE4Support;
 * he moved KPixmapSequencer moved to KWidgetsAddons;
 * he's also working on moving KIconThemes and XmlGui to their final place;

 * agateau moved ItemViews to tier1;
 * he also fixed kguiaddons standalone build;
 * and he's preparing kconfigwidgets move;
 * he'll also do the prep work to have superbuild supported as a requirement 
to mark a split as done;

 * apol is working on splitting KParts, dnssd and KDEWebKit;
 * he's also cleaning up the cmake files;

 * d_ed has been working on shortcut overrides on the Qt side, it's almost 
done now;
 * he's also split kutils in staging;
 * he's also tackling some of the TODOs in code which got overlooked;

 * dfaure finished porting away from KSSLCertificate and deprecated most of 
kio/kssl;
 * he did some reviews too;
 * the KIO split up still needs to be completed;

 * mgraesslin spent time writing unit tests for NETRootInfo and NETWinInfo;
 * he's also porting to XCB datatypes instead of XLib ones as he goes;
 * he moved KModifierKeyInfo to kwindowsystem;

 * sebas got his KPluginFactory code merged, porting docs are pending;
 * he's working on the plugin installation;
 * and he's trying to find a solution for porting our xembed based systemtray 
items;

 * shadeslayer is still looking into the queued dialog support for 
KJobUiDelegate;

 * teo is finalizing his work on KEncodingFileDialog;
 * after that KFileDialog will get to its final home;
 * he also plans to use the mime filter API of QFileDialog in our calls;

 * vHanda is completing his work to move the kio tests at the right place;
 * he's also cleaning up the nepomuk uses;

 * wojtask9 is working on the script to produce the framework graph;
 * he's also working on KStyle;

 * ervin is reviewing, reviewing and reviewing;
 * he's also trying to plan the splitting of KDE4Attic, there's a chance of 
releasing without it.

If you got questions, feel free to ask.

Regards.
-- 
Kévin Ottens, http://ervin.ipsquad.net

Sponsored by KDAB to work on KDE Frameworks
KDAB - proud supporter of KDE, http://www.kdab.com



signature.asc
Description: This is a digitally signed message part.

Re: Review Request 112756: KLinkItemSelectionModel: Do not change current index of mapped model if the mapped one is invalid

[Stephen Kelly]

---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/112756/#review40705
---

Ship it!


Ship It!

- Stephen Kelly


On Sept. 16, 2013, 1:56 p.m., Aurélien Gâteau wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/112756/
> ---
> 
> (Updated Sept. 16, 2013, 1:56 p.m.)
> 
> 
> Review request for kdelibs and Stephen Kelly.
> 
> 
> Description
> ---
> 
> I noticed Gwenview keyboard navigation broke with the latest 
> KLinkItemSelectionModel changes: in browse mode, in a folder which contains 
> both folders and images, something like this:
> 
> dir1 dir2 img1 img2
> 
> if img1 is selected, pressing the left arrow makes dir1 selected instead of 
> dir2.
> 
> This can be explain as so: given the following 
> model A with content: 
> 0. dir1
> 1. dir2
> 2. img1
> 3. img2
> 
> model B a proxy model on A with content:
> 0. img1
> 1. img2
> 
> 
> AView and BView, views on each models and a KLinkItemSelectionModel to link 
> selections between AView and BView.
> 
> Setting current index in AView to row 1, which does not exist in BView, 
> currently causes KLinkItemSelectionModel to set BView current index to 
> invalid, which in turns cause KLinkItemSelectionModel to set AView current 
> index to invalid.
> 
> Patch in this request prevents invalid indexes from being propagated. I am 
> not sure it is the best behavior though: maybe we don't want to propagate 
> invalid indexes, unless the original index is invalid itself? If I set 
> current index of AView to invalid, maybe BView current index should become 
> invalid as well? I am happy to implement this alternate behavior if you think 
> it's better.
> 
> 
> Diffs
> -
> 
>   kdeui/itemviews/klinkitemselectionmodel.cpp be8395f 
>   kdeui/tests/klinkitemselectionmodeltest.cpp 91540fd 
> 
> Diff: http://git.reviewboard.kde.org/r/112756/diff/
> 
> 
> Testing
> ---
> 
> Existing test case has been extended to test behavior in case of invalid 
> indexes. Gwenview keyboard behavior is not broken anymore.
> 
> 
> Thanks,
> 
> Aurélien Gâteau
> 
>

Re: Review Request 112816: Do not use internal headers in kcolorutilsdemo

[Sune Vuorela]

> On Sept. 24, 2013, 2:23 p.m., Sune Vuorela wrote:
> > tier1/kguiaddons/src/lib/colors/kcolorutils.cpp, line 42
> > 
> >
> > My initial reaction is that it could return a bool wether or not things 
> > went okay, given there is a 'path that does nothing' in the code. Besides 
> > that, everything looks great.
> 
> Aurélien Gâteau wrote:
> I wrote it this way to be consistent with QColor::get*() methods. I think 
> users of such code are going to be used to QColor API, so it makes more sense 
> this way, what do you think?

I'm convinced.


- Sune


---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/112816/#review40692
---


On Sept. 24, 2013, 2:19 p.m., Aurélien Gâteau wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/112816/
> ---
> 
> (Updated Sept. 24, 2013, 2:19 p.m.)
> 
> 
> Review request for KDE Frameworks and kdelibs.
> 
> 
> Description
> ---
> 
> This is a two-commit patch:
> 
> 1. Add a KColorUtils::getHcy() method
> 
> 2. In kcolorutils demo: use KColorUtils::getHcy() instead of the internal 
> KColorSpaces::KHCY
> 
> This is a required first step to make kconfigwidgets build standalone
> 
> 
> Diffs
> -
> 
>   staging/kconfigwidgets/tests/kcolorutilsdemo.cpp 940569e 
>   tier1/kguiaddons/src/lib/colors/kcolorutils.h c20c6f7 
>   tier1/kguiaddons/src/lib/colors/kcolorutils.cpp 9212bba 
> 
> Diff: http://git.reviewboard.kde.org/r/112816/diff/
> 
> 
> Testing
> ---
> 
> kcolorutilsdemo still works.
> 
> 
> Thanks,
> 
> Aurélien Gâteau
> 
>

Re: Review Request 112816: Do not use internal headers in kcolorutilsdemo

[Aurélien Gâteau]

> On Sept. 24, 2013, 4:23 p.m., Sune Vuorela wrote:
> > tier1/kguiaddons/src/lib/colors/kcolorutils.cpp, line 42
> > 
> >
> > My initial reaction is that it could return a bool wether or not things 
> > went okay, given there is a 'path that does nothing' in the code. Besides 
> > that, everything looks great.

I wrote it this way to be consistent with QColor::get*() methods. I think users 
of such code are going to be used to QColor API, so it makes more sense this 
way, what do you think?


- Aurélien


---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/112816/#review40692
---


On Sept. 24, 2013, 4:19 p.m., Aurélien Gâteau wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/112816/
> ---
> 
> (Updated Sept. 24, 2013, 4:19 p.m.)
> 
> 
> Review request for KDE Frameworks and kdelibs.
> 
> 
> Description
> ---
> 
> This is a two-commit patch:
> 
> 1. Add a KColorUtils::getHcy() method
> 
> 2. In kcolorutils demo: use KColorUtils::getHcy() instead of the internal 
> KColorSpaces::KHCY
> 
> This is a required first step to make kconfigwidgets build standalone
> 
> 
> Diffs
> -
> 
>   staging/kconfigwidgets/tests/kcolorutilsdemo.cpp 940569e 
>   tier1/kguiaddons/src/lib/colors/kcolorutils.h c20c6f7 
>   tier1/kguiaddons/src/lib/colors/kcolorutils.cpp 9212bba 
> 
> Diff: http://git.reviewboard.kde.org/r/112816/diff/
> 
> 
> Testing
> ---
> 
> kcolorutilsdemo still works.
> 
> 
> Thanks,
> 
> Aurélien Gâteau
> 
>

Re: Review Request 112816: Do not use internal headers in kcolorutilsdemo

[Kevin Ottens]

---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/112816/#review40694
---


Probably we'll need an extra patch on top of this one so that KColorSpaces 
become private, no need to export it anymore imo.

- Kevin Ottens


On Sept. 24, 2013, 2:19 p.m., Aurélien Gâteau wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/112816/
> ---
> 
> (Updated Sept. 24, 2013, 2:19 p.m.)
> 
> 
> Review request for KDE Frameworks and kdelibs.
> 
> 
> Description
> ---
> 
> This is a two-commit patch:
> 
> 1. Add a KColorUtils::getHcy() method
> 
> 2. In kcolorutils demo: use KColorUtils::getHcy() instead of the internal 
> KColorSpaces::KHCY
> 
> This is a required first step to make kconfigwidgets build standalone
> 
> 
> Diffs
> -
> 
>   staging/kconfigwidgets/tests/kcolorutilsdemo.cpp 940569e 
>   tier1/kguiaddons/src/lib/colors/kcolorutils.h c20c6f7 
>   tier1/kguiaddons/src/lib/colors/kcolorutils.cpp 9212bba 
> 
> Diff: http://git.reviewboard.kde.org/r/112816/diff/
> 
> 
> Testing
> ---
> 
> kcolorutilsdemo still works.
> 
> 
> Thanks,
> 
> Aurélien Gâteau
> 
>

Re: Review Request 112816: Do not use internal headers in kcolorutilsdemo

[Sune Vuorela]

---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/112816/#review40692
---



tier1/kguiaddons/src/lib/colors/kcolorutils.cpp


My initial reaction is that it could return a bool wether or not things 
went okay, given there is a 'path that does nothing' in the code. Besides that, 
everything looks great.


- Sune Vuorela


On Sept. 24, 2013, 2:19 p.m., Aurélien Gâteau wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/112816/
> ---
> 
> (Updated Sept. 24, 2013, 2:19 p.m.)
> 
> 
> Review request for KDE Frameworks and kdelibs.
> 
> 
> Description
> ---
> 
> This is a two-commit patch:
> 
> 1. Add a KColorUtils::getHcy() method
> 
> 2. In kcolorutils demo: use KColorUtils::getHcy() instead of the internal 
> KColorSpaces::KHCY
> 
> This is a required first step to make kconfigwidgets build standalone
> 
> 
> Diffs
> -
> 
>   staging/kconfigwidgets/tests/kcolorutilsdemo.cpp 940569e 
>   tier1/kguiaddons/src/lib/colors/kcolorutils.h c20c6f7 
>   tier1/kguiaddons/src/lib/colors/kcolorutils.cpp 9212bba 
> 
> Diff: http://git.reviewboard.kde.org/r/112816/diff/
> 
> 
> Testing
> ---
> 
> kcolorutilsdemo still works.
> 
> 
> Thanks,
> 
> Aurélien Gâteau
> 
>

Re: Review Request 112816: Do not use internal headers in kcolorutilsdemo

[Kevin Ottens]

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

(Updated Sept. 24, 2013, 2:19 p.m.)


Review request for KDE Frameworks and kdelibs.


Changes
---

Aimed at the frameworks branch.


Description
---

This is a two-commit patch:

1. Add a KColorUtils::getHcy() method

2. In kcolorutils demo: use KColorUtils::getHcy() instead of the internal 
KColorSpaces::KHCY

This is a required first step to make kconfigwidgets build standalone


Diffs
-

  staging/kconfigwidgets/tests/kcolorutilsdemo.cpp 940569e 
  tier1/kguiaddons/src/lib/colors/kcolorutils.h c20c6f7 
  tier1/kguiaddons/src/lib/colors/kcolorutils.cpp 9212bba 

Diff: http://git.reviewboard.kde.org/r/112816/diff/


Testing
---

kcolorutilsdemo still works.


Thanks,

Aurélien Gâteau

Re: Re: kde-workspace master becomes Qt5-based

[Martin Gräßlin]

On Tuesday 24 September 2013 13:51:57 Albert Astals Cid wrote:
> El Dimarts, 24 de setembre de 2013, a les 11:34:45, Martin Gräßlin va
> 
> escriure:
> > On Thursday 19 September 2013 19:30:52 Sebastian Kügler wrote:
> > > Hi all,
> > > 
> > > We're planning to merge the frameworks-scratch branch of kde-workspace
> > > into
> > > master next Monday. That means if you're building your Plasma yourself
> > > from
> > > Git (and you're not yet ready for Plasma2 ;)), you should switch to the
> > > KDE/4.11 branch. The build will fail otherwise, so you will notice.
> > > 
> > > This was a public service announcement. (And you can ask questions
> > > here.)
> > 
> > Follow-up: frameworks-scratch got just merged into master.
> > 
> > Please do not push into the frameworks-scratch branch any more!
> 
> Can this be blocked more efficiently in the git repo instead of relying on
> people to do the right thing?
Ben already did that. Which means kudos to our awesome sysadmins!

Cheers
Martin

signature.asc
Description: This is a digitally signed message part.

Re: kde-workspace master becomes Qt5-based

[Albert Astals Cid]

El Dimarts, 24 de setembre de 2013, a les 11:34:45, Martin Gräßlin va 
escriure:
> On Thursday 19 September 2013 19:30:52 Sebastian Kügler wrote:
> > Hi all,
> > 
> > We're planning to merge the frameworks-scratch branch of kde-workspace
> > into
> > master next Monday. That means if you're building your Plasma yourself
> > from
> > Git (and you're not yet ready for Plasma2 ;)), you should switch to the
> > KDE/4.11 branch. The build will fail otherwise, so you will notice.
> > 
> > This was a public service announcement. (And you can ask questions here.)
> 
> Follow-up: frameworks-scratch got just merged into master.
> 
> Please do not push into the frameworks-scratch branch any more!

Can this be blocked more efficiently in the git repo instead of relying on 
people to do the right thing?

Cheers,
  Albert

> 
> Cheers
> Martin

Re: kde-workspace master becomes Qt5-based

[Martin Gräßlin]

On Thursday 19 September 2013 19:30:52 Sebastian Kügler wrote:
> Hi all,
> 
> We're planning to merge the frameworks-scratch branch of kde-workspace into
> master next Monday. That means if you're building your Plasma yourself from
> Git (and you're not yet ready for Plasma2 ;)), you should switch to the
> KDE/4.11 branch. The build will fail otherwise, so you will notice.
> 
> This was a public service announcement. (And you can ask questions here.)
Follow-up: frameworks-scratch got just merged into master.

Please do not push into the frameworks-scratch branch any more!

Cheers
Martin

signature.asc
Description: This is a digitally signed message part.