Re: Review Request 127896: make dbus optional on osx: kauth

2016-05-21 Thread David Edmundson 

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




src/CMakeLists.txt (line 32)


In theory - nothing in KAuth should be using DBus outside of the helpers.
(and that autotest that uses the helper)

You should be able to make this change unconditionally - and move finding 
DBus to src/ConfigureChecks cmake

Then we can change those autotests to use the right backend depending on 
which backend get built - which is more semantically correct.

Otherwise we still have a problem that I can manually select the fake 
backend via KAUTH_HELPER_BACKEND_NAME, yet still end up using a test requiring 
DBus for something that isn't being built.


- David Edmundson


On May 20, 2016, 9:13 p.m., Nick Shaforostoff wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/127896/
> ---
> 
> (Updated May 20, 2016, 9:13 p.m.)
> 
> 
> Review request for KDE Software on Mac OS X, KDE Frameworks, David Edmundson, 
> and Martin Gräßlin.
> 
> 
> Repository: kauth
> 
> 
> Description
> ---
> 
> this is the first patch to make kde frameworks build (and then work) without 
> dbus.
> 
> this will allow homebrew users use precompiled vanilla Qt to build kde apps 
> on osx. as dbus is not a common service in osx world, kde apps on osx should 
> use native means for interprocess communication instead -- this will make 
> them better citizens in osx ecosystem.
> 
> 
> Diffs
> -
> 
>   CMakeLists.txt 48dc2d9 
>   autotests/BackendsManager.cpp 59675b3 
>   autotests/CMakeLists.txt b53d760 
>   autotests/HelperTest.cpp 8050a06 
>   src/CMakeLists.txt 1b6930d 
>   src/ConfigureChecks.cmake d46761a 
> 
> Diff: https://git.reviewboard.kde.org/r/127896/diff/
> 
> 
> Testing
> ---
> 
> compiles fine on osx, compiles fine on linux, tests on linux still pass.
> 
> 
> Thanks,
> 
> Nick Shaforostoff
> 
>

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

Re: Review Request 121218: Allow using new style connect syntax with KStandardAction::create()

2016-05-21 Thread David Faure 


> On April 5, 2015, 2:26 p.m., David Faure wrote:
> > Well, +1 for the idea. But I wonder what the apidox will look like, the 
> > macro+template probably don't make it work.
> > 
> > Also missing @since 5.10.
> > 
> > Ship it from me once the apidox issue is resolved.
> 
> Gleb Popov wrote:
> What apidox issue is being talked about? If it is about 
> `KSTANDARDACTION_WITH_NEW_STYLE_CONNECT`, then i was able to make it work 
> with some simple Doxyfile options.
> 
> See `save()` overload for example: 
> http://arrowd.name/html/namespace_k_standard_action.html#abd0ad3c1f3ee5c9d2ff068a06c8a6ac1
>  and 
> http://arrowd.name/html/namespace_k_standard_action.html#a92c0df356ef011d4a7ae9a844d4a0bc7
> 
> If this is OK, i can document all new connects with `@since@` too. Can 
> this be commited then?

Well that's ugly docs :) You should use #ifdef DOXYGEN_SHOULD_SKIP_THIS around 
the enable_if and in the #else use the readable version (QAction *, IIUC) so 
that doxygen sees something cleaner and readable by the developer using this 
API.

But actually I don't even understand the use of enable_if here. How can a 
pointer-to-function or a lambda be ambiguous with const char * ?


- David


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


On Dec. 24, 2014, 1:23 p.m., Alex Richardson wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/121218/
> ---
> 
> (Updated Dec. 24, 2014, 1:23 p.m.)
> 
> 
> Review request for KDE Frameworks, David Faure and Nicolás Alvarez.
> 
> 
> Repository: kconfigwidgets
> 
> 
> Description
> ---
> 
> Not sure if MSVC has the necessary type_traits working, but can't test that 
> now since it don't have a Windows machine available.
> 
> 
> Diffs
> -
> 
>   autotests/kstandardactiontest.h 0008d281c0353e872feb7483c75762a0012a7b76 
>   autotests/kstandardactiontest.cpp 09ae35db05467d61b8baf50fac70c6228e324492 
>   src/kstandardaction.h d511778b7a24b1ec2e546949dab21f1ec2fea96f 
>   src/kstandardaction.cpp e5bea7965032355501b4c238e37abcc0f883c0b7 
> 
> Diff: https://git.reviewboard.kde.org/r/121218/diff/
> 
> 
> Testing
> ---
> 
> The newly added unit test passes
> 
> 
> Thanks,
> 
> Alex Richardson
> 
>

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

Re: LGPL for Breeze QStyle and qtquickcontrols?

2016-05-21 Thread Jaroslaw Staniek 
On 18 May 2016 at 17:51, Martin Graesslin  wrote:

> On Wednesday, May 18, 2016 12:41:49 PM CEST Jaroslaw Staniek wrote:
> > On 17 May 2016 at 20:38, Martin Graesslin  wrote:
> > > On Tuesday, May 17, 2016 6:23:10 PM CEST Jaroslaw Staniek wrote:
> > > > > If you show me why it needs to be a framework and I agree with it,
> > > > > I might be willing to consider to allow to relicense the code I
> wrote
> > >
> > > for
> > >
> > > > > it.
> > > >
> > > > There's no request to make it framework from me. LGPLing Breeze does
> not
> > > > automatically add obligation to create and maintain a framweork.
> > >
> > > Especially
> > >
> > > > that there are not widely declared use cases. It's just a way to get
> the
> > > > same what was legal in the times of Oxygen and KDElibs 4.
> > >
> > > Yes exactly! If you would present me reasons why it should become a
> > > framework
> > > I might see a need for it to have it LGPL. That is something I
> currently
> > > don't
> > > see. Thus I don't see a reason to change it to LGPL.
> >
> > But there's no rule in KDE that LGPL code needs to form frameworks.
> > No need to switch the topic... Adding a framework is a lot of
> > responsibility I am aware of and I don't request more work from others.
> > We had an agreement within KDE organization that there's not even rule
> > that​ KDE projects have to use C++ or Qt. People can implement things in
> > HTML or C# or Java. Unless licenses stay against it but I see no reason
> why
> > would be that.
> >
> > > Similar I don't relicense KWin to LGPL, just because there might be a
> > > reason
> > > later on.  When we split out code from KWin to KWayland we did the
> > > relicense
> > > as needed.
> >
> > ​You see​, authors have the benefit of re-licensing when _they_ need.
> > I am not the author and have to face unusual extensive testing of my
> > reasoning.
>
> You are asking me as a copyright holder whether I agree to a relicense. You
> have to convince me. To me the default licence is GPLv3+. Everything else
> means an exception to my personal view. You have to provide really good
> reasons to make me agree that this is needed.
>
> So far I have not seen them. It is more a wishy-washy about you want to use
> some code. That's not a reasoning. Explain why you need it and explain it
> that
> makes sense with our overall KDE vision about
> ​​
> applications not being part of
> Plasma and depending on Plasma. Especially: how do you want to achieve it
> without making applications depend on Plasma, which is nothing we want.
> Copy
> code? No way, for that I'm not going to agree to relicense.
>
>
​Martin,​
"​Depending on plasma"​ is a term at the level of deployment. It addresses
requirements that may be important to someone but not to the entire
mankind. Not every software title is developed by operating in the scope of
term that you're referring to. I am sharing examples below.

With all due respect I don't want to even discuss using licenses as a
tool/weapon to dictate deployment, scope of use, etc. And whether all
desktop applications that use Breeze style and icons to display something
(not necessarily QWidgets) must be part of Plasma -- which so far isn't
official component/subsystem of Windows or OS X. So how a KDE app on
Windows has to be part of Plasma is not clear to me.

Then the KDE Vision and copying, good that you're asking because there's
some exercise. The KDE Vision is orthogonal to something even stronger than
copying: _forking_ projects, even without "convincing" or explaining
original authors. And these projects can be part of KDE exactly the way the
original is.

So Plasma (design and icons - SVG code) has been copied multiple times
already out of KDE, what includes a copy for GTK+ apps and LibreOffice
apps. The Breeze style has been copied to the LGPLized GTK+ style. I don't
need to add that none of such apps mention Plasma or even KDE. And most
users of popular KDE apps such as Krita wouldn't even know what _kind_ of
term Plasma is if we ask them. You know, most of these users are on
Windows. I am not trying to devalue Plasma by saying this but to show that
in the entire population there are various interests.

Then, creating an Android or iOS package is ultimately also copying.
Creating Windows/Mac installers of pro apps is very interesting exercise in
copying and picking versions of components that are needed and work
together. Suddenly you become developer and packager, something not very
often practices on Linux. Copying happens not for just copying but it's
possible in extreme cases as a way to circumvent improper license choice,
when other styles (in fact _libraries_ of drawing routines!) are LGPL, this
one is not.

So we, in KDE, lack LGPL style code for our de-facto official look and feel.

That's a paradox, at the moment _non-KDE_ projects have actually more
freedom than KDE contributors to use the current _KDE's_ major desktop
visual identity. That price for

Re: Review Request 127984: Always update the Trader parser from y/l sources

2016-05-21 Thread Michael Pyne 

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


Ship it!




Ship It!

- Michael Pyne


On May 21, 2016, 1:50 p.m., Pino Toscano wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/127984/
> ---
> 
> (Updated May 21, 2016, 1:50 p.m.)
> 
> 
> Review request for KDE Frameworks.
> 
> 
> Repository: kservice
> 
> 
> Description
> ---
> 
> Add Flex and Bison as required build dependencies, and use them to always 
> regenerate at build time the Trader parser. This ensures that the parser does 
> not rot, and there is no more need to rely on autogenerated sources added 
> statically among the others.
> 
> Second commit: remove old generated files of Trader parser, and the helper 
> regen.sh script.
> 
> 
> Diffs
> -
> 
>   CMakeLists.txt 7f9d4f03510c66f230e5c189e92d90a31beb2cf2 
>   src/CMakeLists.txt cdcf88532cb8d7aba0cf7fbd24086d7f5905b6da 
>   src/services/lex.c c811f67fc89a1a1ad0aef0de2feeba00ebd5d057 
>   src/services/regen.sh c2af52b92767ca2dd0d1abe19eb6cf50642b5096 
>   src/services/yacc.h 070ffa4bc895683b4a5b7502a031679c7d70c74a 
>   src/services/yacc.c 675650a8d787c5d7e66ef5e2cf97bdeb65660f4b 
> 
> Diff: https://git.reviewboard.kde.org/r/127984/diff/
> 
> 
> Testing
> ---
> 
> Builds fine with flex 2.6.0 and bison 3.0.4; `make test` passes too.
> 
> 
> Thanks,
> 
> Pino Toscano
> 
>

___
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

2016-05-21 Thread Michael Pyne 

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


Ship it!




Well I'm not the Maintainer of All Frameworks but your plan sounds acceptable 
so I'd say to go for it and we'll just pick up the pieces if there ends up 
being breakage, we just need to be careful to either get everything done in 
time to have time to resolve issues that might arise before KF5 5.23.

- Michael Pyne


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 127835: KHTML: Try again to fix Coverity memory leak in CSS background property

2016-05-21 Thread Michael Pyne 


> On May 21, 2016, 1:56 p.m., Andrea Iacovitti wrote:
> > src/css/cssparser.cpp, lines 2143-2158
> > 
> >
> > If value->length() is 0 we should not return true because we failed to 
> > parse the value.
> > Testcase: right now with your change applyed the following invalid css 
> > declaration "background: left left" will lead to a crash.
> > 
> > That said, here, value->length() should never be zero: if we are 
> > executing this part of code it means we successfully parsed values (did not 
> > exit from the while loop through the "goto failed" condition).
> > However this actually doesn't happen because of a bug i just found 
> > involving parsing background-position when in shorthand property, i have a 
> > fix and will commit it soon.
> >  
> > Afterwards, something like this code:
> > 
> > //assert(value->length());
> > if (value->length() == 1) {
> > // Downgrade single-element lists to simple value
> > retValue1 = value->item(0);
> > if (value2->length()) {
> > retValue2 = value2->item(0);
> > } else {
> > delete value2;
> > }
> > } else {
> > retValue1 = value;
> > if (value2->length()) {
> > retValue2 = value2;
> > } else {
> > delete value2;
> > }
> > }
> > return true;
> > 
> > should be ok, but i don't know if it will make coverity happy.

Coverity was more annoyed that we'd leak currValue2 in some possible edge 
cases, so the reorganized code with that fix applied should still make Coverity 
happy I think. I'll look at revising the patch and then also testing with the 
testcase you provided on Bugzilla.


- Michael


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


On May 18, 2016, 10:06 p.m., Michael Pyne wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/127835/
> ---
> 
> (Updated May 18, 2016, 10:06 p.m.)
> 
> 
> Review request for KDE Frameworks, Andrea Iacovitti and Bernd Buschinski.
> 
> 
> Repository: khtml
> 
> 
> Description
> ---
> 
> In KHTML commit b52325eb49 I attempted to fix a Coverity error (CID 257928) 
> indicating that the CSS background property parser could sometimes leak 
> `CSSValueImpl` objects.
> 
> Coverity shows that the leak is still possible (and I think it's correct, 
> even with my change, in situations where the first return value is upgraded 
> to a list while the second return value remains unset).
> 
> Because of that I'm trying a different approach to fix the leak by factoring 
> out the code that promotes a saved return value into a value-list when 
> needed, in the hopes that simpler code will be more correct.
> 
> Note for reviewers that, as far as I can see, the idea in the current code is 
> that there's 3 levels of values, for 2 separate return values:
> 
> 1. "currValue", the value found during this pass through the main loop
> 2. "value", the saved return value when it's still only a single value 
> (assigned from currValue)
> 3. "values", the saved return value when it's now a list of values (assigned 
> from value and/or currValue)
> 
> Similar concepts apply to currValue2/value2/values2. I am unsure why there's 
> a distinction between a single value and a value list in the return value -- 
> it may be that this distinction is unneeded.
> 
> 
> Diffs
> -
> 
>   src/css/cssparser.cpp 6684f4c 
> 
> Diff: https://git.reviewboard.kde.org/r/127835/diff/
> 
> 
> Testing
> ---
> 
> The updated code compiles without warnings in cssparser.cpp, and runs fine in 
> Konqueror.
> 
> To test I tried going to the MDN site on the CSS background properties 
> (including background-position in particular, since that's the only CSS 
> property that requires the second value/return value). I then used the DOM 
> Inspector tool to manually verify that the CSS background properties were 
> properly read, that the examples rendered as before, etc.
> 
> The Acid3 test makes it to 92/100, but I'm pretty sure it was only at 92/100 
> before this change as well. ;)
> 
> 
> 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 127896: make dbus optional on osx: kauth

2016-05-21 Thread René J . V . Bertin 


> On May 21, 2016, 10:20 p.m., Kåre Särs wrote:
> > CMakeLists.txt, line 12
> > 
> >
> > Why is this not: option(DISABLE_DBUS "Remove..." OFF) ?
> > 
> > For the rest I'm happy :)

Idem.

Isn't there a guideline against negative options? IOW, wouldn't it be better to 
have something like

`option(INCLUDE_DBUS_SUPPORT "Include support for using DBus to ..." ON)`

so that you don't have to test on `NOT FOO` everywhere?

(I know it's common practice to use shortcuts like "--disable-dbus" to indicate 
"disable support for dbus", but we can just as well use an option name that's 
semantically correct, no? :) )


- René J.V.


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


On May 20, 2016, 11:13 p.m., Nick Shaforostoff wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/127896/
> ---
> 
> (Updated May 20, 2016, 11:13 p.m.)
> 
> 
> Review request for KDE Software on Mac OS X, KDE Frameworks, David Edmundson, 
> and Martin Gräßlin.
> 
> 
> Repository: kauth
> 
> 
> Description
> ---
> 
> this is the first patch to make kde frameworks build (and then work) without 
> dbus.
> 
> this will allow homebrew users use precompiled vanilla Qt to build kde apps 
> on osx. as dbus is not a common service in osx world, kde apps on osx should 
> use native means for interprocess communication instead -- this will make 
> them better citizens in osx ecosystem.
> 
> 
> Diffs
> -
> 
>   CMakeLists.txt 48dc2d9 
>   autotests/BackendsManager.cpp 59675b3 
>   autotests/CMakeLists.txt b53d760 
>   autotests/HelperTest.cpp 8050a06 
>   src/CMakeLists.txt 1b6930d 
>   src/ConfigureChecks.cmake d46761a 
> 
> Diff: https://git.reviewboard.kde.org/r/127896/diff/
> 
> 
> Testing
> ---
> 
> compiles fine on osx, compiles fine on linux, tests on linux still pass.
> 
> 
> Thanks,
> 
> Nick Shaforostoff
> 
>

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

Re: Review Request 127896: make dbus optional on osx: kauth

2016-05-21 Thread Kåre Särs 

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




CMakeLists.txt (line 12)


Why is this not: option(DISABLE_DBUS "Remove..." OFF) ?

For the rest I'm happy :)


- Kåre Särs


On May 20, 2016, 9:13 p.m., Nick Shaforostoff wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/127896/
> ---
> 
> (Updated May 20, 2016, 9:13 p.m.)
> 
> 
> Review request for KDE Software on Mac OS X, KDE Frameworks, David Edmundson, 
> and Martin Gräßlin.
> 
> 
> Repository: kauth
> 
> 
> Description
> ---
> 
> this is the first patch to make kde frameworks build (and then work) without 
> dbus.
> 
> this will allow homebrew users use precompiled vanilla Qt to build kde apps 
> on osx. as dbus is not a common service in osx world, kde apps on osx should 
> use native means for interprocess communication instead -- this will make 
> them better citizens in osx ecosystem.
> 
> 
> Diffs
> -
> 
>   CMakeLists.txt 48dc2d9 
>   autotests/BackendsManager.cpp 59675b3 
>   autotests/CMakeLists.txt b53d760 
>   autotests/HelperTest.cpp 8050a06 
>   src/CMakeLists.txt 1b6930d 
>   src/ConfigureChecks.cmake d46761a 
> 
> Diff: https://git.reviewboard.kde.org/r/127896/diff/
> 
> 
> Testing
> ---
> 
> compiles fine on osx, compiles fine on linux, tests on linux still pass.
> 
> 
> Thanks,
> 
> Nick Shaforostoff
> 
>

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

Jenkins-kde-ci: kdelibs4support master kf5-qt5 » Linux,gcc - Build # 42 - Fixed!

2016-05-21 Thread no-reply 

GENERAL INFO

BUILD SUCCESS
Build URL: 
https://build.kde.org/job/kdelibs4support%20master%20kf5-qt5/PLATFORM=Linux,compiler=gcc/42/
Project: PLATFORM=Linux,compiler=gcc
Date of build: Sat, 21 May 2016 16:02:54 +
Build duration: 5 min 29 sec

CHANGE SET
Revision 5a000948121a1105c3385b5a44017a6a82f7c82d by Albert Astals Cid: 
(Compile++)
  change: edit src/kdecore/kdatetimeparser.cpp


JUNIT RESULTS

Name: (root) Failed: 0 test(s), Passed: 39 test(s), Skipped: 0 test(s), Total: 
39 test(s)

COBERTURA RESULTS

Cobertura Coverage Report
  PACKAGES 4/7 (57%)FILES 161/269 (60%)CLASSES 161/269 (60%)LINE 21707/42765 
(51%)CONDITIONAL 14666/36445 (40%)

By packages
  
autotests
FILES 64/64 (100%)CLASSES 64/64 (100%)LINE 11531/11780 
(98%)CONDITIONAL 8481/16820 (50%)
src.kdecore
FILES 75/94 (80%)CLASSES 75/94 (80%)LINE 9221/16840 
(55%)CONDITIONAL 5722/11781 (49%)
src.kdeui
FILES 18/70 (26%)CLASSES 18/70 (26%)LINE 939/9816 
(10%)CONDITIONAL 460/5673 (8%)
src.kio
FILES 4/27 (15%)CLASSES 4/27 (15%)LINE 16/2396 (1%)CONDITIONAL 
3/1226 (0%)
src.kparts
FILES 0/1 (0%)CLASSES 0/1 (0%)LINE 0/26 (0%)CONDITIONAL 0/14 
(0%)
src.kssl
FILES 0/8 (0%)CLASSES 0/8 (0%)LINE 0/1708 (0%)CONDITIONAL 0/836 
(0%)
src.solid
FILES 0/5 (0%)CLASSES 0/5 (0%)LINE 0/199 (0%)CONDITIONAL 0/95 
(0%)___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Jenkins-kde-ci: kdelibs4support master kf5-qt5 » Linux,gcc - Build # 42 - Fixed!

2016-05-21 Thread no-reply 

GENERAL INFO

BUILD SUCCESS
Build URL: 
https://build.kde.org/job/kdelibs4support%20master%20kf5-qt5/PLATFORM=Linux,compiler=gcc/42/
Project: PLATFORM=Linux,compiler=gcc
Date of build: Sat, 21 May 2016 16:02:54 +
Build duration: 5 min 29 sec

CHANGE SET
Revision 5a000948121a1105c3385b5a44017a6a82f7c82d by Albert Astals Cid: 
(Compile++)
  change: edit src/kdecore/kdatetimeparser.cpp


JUNIT RESULTS

Name: (root) Failed: 0 test(s), Passed: 39 test(s), Skipped: 0 test(s), Total: 
39 test(s)

COBERTURA RESULTS

Cobertura Coverage Report
  PACKAGES 4/7 (57%)FILES 161/269 (60%)CLASSES 161/269 (60%)LINE 21707/42765 
(51%)CONDITIONAL 14666/36445 (40%)

By packages
  
autotests
FILES 64/64 (100%)CLASSES 64/64 (100%)LINE 11531/11780 
(98%)CONDITIONAL 8481/16820 (50%)
src.kdecore
FILES 75/94 (80%)CLASSES 75/94 (80%)LINE 9221/16840 
(55%)CONDITIONAL 5722/11781 (49%)
src.kdeui
FILES 18/70 (26%)CLASSES 18/70 (26%)LINE 939/9816 
(10%)CONDITIONAL 460/5673 (8%)
src.kio
FILES 4/27 (15%)CLASSES 4/27 (15%)LINE 16/2396 (1%)CONDITIONAL 
3/1226 (0%)
src.kparts
FILES 0/1 (0%)CLASSES 0/1 (0%)LINE 0/26 (0%)CONDITIONAL 0/14 
(0%)
src.kssl
FILES 0/8 (0%)CLASSES 0/8 (0%)LINE 0/1708 (0%)CONDITIONAL 0/836 
(0%)
src.solid
FILES 0/5 (0%)CLASSES 0/5 (0%)LINE 0/199 (0%)CONDITIONAL 0/95 
(0%)___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Jenkins-kde-ci: kdelibs4support master stable-kf5-qt5 » Linux,gcc - Build # 39 - Still unstable!

2016-05-21 Thread no-reply 

GENERAL INFO

BUILD UNSTABLE
Build URL: 
https://build.kde.org/job/kdelibs4support%20master%20stable-kf5-qt5/PLATFORM=Linux,compiler=gcc/39/
Project: PLATFORM=Linux,compiler=gcc
Date of build: Sat, 21 May 2016 16:02:54 +
Build duration: 3 min 55 sec

CHANGE SET
Revision 5a000948121a1105c3385b5a44017a6a82f7c82d by Albert Astals Cid: 
(Compile++)
  change: edit src/kdecore/kdatetimeparser.cpp


JUNIT RESULTS

Name: (root) Failed: 1 test(s), Passed: 38 test(s), Skipped: 0 test(s), Total: 
39 test(s)Failed: TestSuite.globalcleanuptest

COBERTURA RESULTS

Cobertura Coverage Report
  PACKAGES 4/7 (57%)FILES 160/268 (60%)CLASSES 160/268 (60%)LINE 21694/42752 
(51%)CONDITIONAL 14666/36445 (40%)

By packages
  
autotests
FILES 63/63 (100%)CLASSES 63/63 (100%)LINE 11519/11768 
(98%)CONDITIONAL 8481/16820 (50%)
src.kdecore
FILES 75/94 (80%)CLASSES 75/94 (80%)LINE 9221/16840 
(55%)CONDITIONAL 5722/11781 (49%)
src.kdeui
FILES 18/70 (26%)CLASSES 18/70 (26%)LINE 938/9815 
(10%)CONDITIONAL 460/5673 (8%)
src.kio
FILES 4/27 (15%)CLASSES 4/27 (15%)LINE 16/2396 (1%)CONDITIONAL 
3/1226 (0%)
src.kparts
FILES 0/1 (0%)CLASSES 0/1 (0%)LINE 0/26 (0%)CONDITIONAL 0/14 
(0%)
src.kssl
FILES 0/8 (0%)CLASSES 0/8 (0%)LINE 0/1708 (0%)CONDITIONAL 0/836 
(0%)
src.solid
FILES 0/5 (0%)CLASSES 0/5 (0%)LINE 0/199 (0%)CONDITIONAL 0/95 
(0%)___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Jenkins-kde-ci: kdelibs4support master stable-kf5-qt5 » Linux,gcc - Build # 38 - Failure!

2016-05-21 Thread no-reply 

GENERAL INFO

BUILD FAILURE
Build URL: 
https://build.kde.org/job/kdelibs4support%20master%20stable-kf5-qt5/PLATFORM=Linux,compiler=gcc/38/
Project: PLATFORM=Linux,compiler=gcc
Date of build: Sat, 21 May 2016 15:54:30 +
Build duration: 1 min 38 sec

CHANGE SET
Revision 0dbeca8c6b45fd2316213d850d062c5379c77aeb by Albert Astals Cid: (Warn 
about KDateTimeParser::parseDateUnicode not being implemented)
  change: edit src/kdecore/kdatetimeparser.cpp
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Jenkins-kde-ci: kdelibs4support master kf5-qt5 » Linux,gcc - Build # 41 - Failure!

2016-05-21 Thread no-reply 

GENERAL INFO

BUILD FAILURE
Build URL: 
https://build.kde.org/job/kdelibs4support%20master%20kf5-qt5/PLATFORM=Linux,compiler=gcc/41/
Project: PLATFORM=Linux,compiler=gcc
Date of build: Sat, 21 May 2016 15:54:29 +
Build duration: 1 min 58 sec

CHANGE SET
Revision 0dbeca8c6b45fd2316213d850d062c5379c77aeb by Albert Astals Cid: (Warn 
about KDateTimeParser::parseDateUnicode not being implemented)
  change: edit src/kdecore/kdatetimeparser.cpp
___
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

2016-05-21 Thread 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: Review Request 127835: KHTML: Try again to fix Coverity memory leak in CSS background property

2016-05-21 Thread Andrea Iacovitti 

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




src/css/cssparser.cpp (lines 2120 - 2134)


If value->length() is 0 we should not return true because we failed to 
parse the value.
Testcase: right now with your change applyed the following invalid css 
declaration "background: left left" will lead to a crash.

That said, here, value->length() should never be zero: if we are executing 
this part of code it means we successfully parsed values (did not exit from the 
while loop through the "goto failed" condition).
However this actually doesn't happen because of a bug i just found 
involving parsing background-position when in shorthand property, i have a fix 
and will commit it soon.
 
Afterwards, something like this code:

//assert(value->length());
if (value->length() == 1) {
// Downgrade single-element lists to simple value
retValue1 = value->item(0);
if (value2->length()) {
retValue2 = value2->item(0);
} else {
delete value2;
}
} else {
retValue1 = value;
if (value2->length()) {
retValue2 = value2;
} else {
delete value2;
}
}
return true;

should be ok, but i don't know if it will make coverity happy.


- Andrea Iacovitti


On Mag. 18, 2016, 10:06 p.m., Michael Pyne wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/127835/
> ---
> 
> (Updated Mag. 18, 2016, 10:06 p.m.)
> 
> 
> Review request for KDE Frameworks, Andrea Iacovitti and Bernd Buschinski.
> 
> 
> Repository: khtml
> 
> 
> Description
> ---
> 
> In KHTML commit b52325eb49 I attempted to fix a Coverity error (CID 257928) 
> indicating that the CSS background property parser could sometimes leak 
> `CSSValueImpl` objects.
> 
> Coverity shows that the leak is still possible (and I think it's correct, 
> even with my change, in situations where the first return value is upgraded 
> to a list while the second return value remains unset).
> 
> Because of that I'm trying a different approach to fix the leak by factoring 
> out the code that promotes a saved return value into a value-list when 
> needed, in the hopes that simpler code will be more correct.
> 
> Note for reviewers that, as far as I can see, the idea in the current code is 
> that there's 3 levels of values, for 2 separate return values:
> 
> 1. "currValue", the value found during this pass through the main loop
> 2. "value", the saved return value when it's still only a single value 
> (assigned from currValue)
> 3. "values", the saved return value when it's now a list of values (assigned 
> from value and/or currValue)
> 
> Similar concepts apply to currValue2/value2/values2. I am unsure why there's 
> a distinction between a single value and a value list in the return value -- 
> it may be that this distinction is unneeded.
> 
> 
> Diffs
> -
> 
>   src/css/cssparser.cpp 6684f4c 
> 
> Diff: https://git.reviewboard.kde.org/r/127835/diff/
> 
> 
> Testing
> ---
> 
> The updated code compiles without warnings in cssparser.cpp, and runs fine in 
> Konqueror.
> 
> To test I tried going to the MDN site on the CSS background properties 
> (including background-position in particular, since that's the only CSS 
> property that requires the second value/return value). I then used the DOM 
> Inspector tool to manually verify that the CSS background properties were 
> properly read, that the examples rendered as before, etc.
> 
> The Acid3 test makes it to 92/100, but I'm pretty sure it was only at 92/100 
> before this change as well. ;)
> 
> 
> Thanks,
> 
> Michael Pyne
> 
>

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

Review Request 127984: Always update the Trader parser from y/l sources

2016-05-21 Thread Pino Toscano 

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

Review request for KDE Frameworks.


Repository: kservice


Description
---

Add Flex and Bison as required build dependencies, and use them to always 
regenerate at build time the Trader parser. This ensures that the parser does 
not rot, and there is no more need to rely on autogenerated sources added 
statically among the others.

Second commit: remove old generated files of Trader parser, and the helper 
regen.sh script.


Diffs
-

  CMakeLists.txt 7f9d4f03510c66f230e5c189e92d90a31beb2cf2 
  src/CMakeLists.txt cdcf88532cb8d7aba0cf7fbd24086d7f5905b6da 
  src/services/lex.c c811f67fc89a1a1ad0aef0de2feeba00ebd5d057 
  src/services/regen.sh c2af52b92767ca2dd0d1abe19eb6cf50642b5096 
  src/services/yacc.h 070ffa4bc895683b4a5b7502a031679c7d70c74a 
  src/services/yacc.c 675650a8d787c5d7e66ef5e2cf97bdeb65660f4b 

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


Testing
---

Builds fine with flex 2.6.0 and bison 3.0.4; `make test` passes too.


Thanks,

Pino Toscano

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

Re: Review Request 127972: Always update the Predicate parser from y/l sources

2016-05-21 Thread Pino Toscano 


> On May 20, 2016, 11:21 p.m., René J.V. Bertin wrote:
> > I've done some testing with Solid 5.20.0 .The patch applies cleanly, but 
> > I'm getting the error below. I'd write that down to using the older Solid 
> > version if it weren't for that fact I'm quite sure I've seen this kind of 
> > error before:
> > 
> > ```
> >  [ 30%] [BISON][SolidParser] Building parser with bison 3.0.4
> >  cd 
> > /opt/local/var/macports/build/_opt_local_site-ports_kf5_KF5-Frameworks/kf5-solid/work/solid-5.20.0/src/solid
> >  && /opt/local/bin/bison -p Solid -d -b predicate_parser -d -o 
> > /opt/local/var/macports/build/_opt_local_site-ports_kf5_KF5-Frameworks/kf5-solid/work/build/src/solid/predicate_parser.c
> >  devices/predicate_parser.y
> >  ...
> >  make[2]: Entering directory 
> > `/opt/local/var/macports/build/_opt_local_site-ports_kf5_KF5-Frameworks/kf5-solid/work/build'
> >  [ 31%] Building C object 
> > src/solid/CMakeFiles/KF5Solid_static.dir/predicate_parser.c.o
> >  cd 
> > /opt/local/var/macports/build/_opt_local_site-ports_kf5_KF5-Frameworks/kf5-solid/work/build/src/solid
> >  && 
> > /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang
> >   -DQT_CORE_LIB -DQT_DBUS_LIB -DQT_GUI_LIB -DQT_MAC_USE_COCOA 
> > -DQT_NO_CAST_TO_ASCII -DQT_NO_DEBUG -DQT_NO_SIGNALS_SLOTS_KEYWORDS 
> > -DQT_NO_URL_CAST_FROM_STRING -DQT_QSP_XDG_LIB -DQT_USE_FAST_OPERATOR_PLUS 
> > -DQT_USE_QSTRINGBUILDER -DQT_WIDGETS_LIB -DQT_XML_LIB -D_DARWIN_C_SOURCE 
> > -D_LARGEFILE64_SOURCE 
> > -I/opt/local/var/macports/build/_opt_local_site-ports_kf5_KF5-Frameworks/kf5-solid/work/build/src/solid
> >  
> > -I/opt/local/var/macports/build/_opt_local_site-ports_kf5_KF5-Frameworks/kf5-solid/work/solid-5.20.0/src/solid
> >  
> > -I/opt/local/var/macports/build/_opt_local_site-ports_kf5_KF5-Frameworks/kf5-solid/work/solid-5.20.0/src/solid/devices
> >  
> > -I/opt/local/var/macports/build/_opt_local_site-ports_kf5_KF5-Frameworks/kf5-solid/work/solid-5.20.0/src/solid/devices/frontend
> >  -I/opt/local/var/macports/build/_
 
opt_local_site-ports_kf5_KF5-Frameworks/kf5-solid/work/solid-5.20.0/src/solid/..
 
-I/opt/local/var/macports/build/_opt_local_site-ports_kf5_KF5-Frameworks/kf5-solid/work/build/src/solid/..
 -iframework /opt/local/libexec/qt5/Library/Frameworks -isystem 
/opt/local/libexec/qt5/Library/Frameworks/QtCore.framework/Headers -isystem 
/opt/local/share/qt5/mkspecs/macx-clang -isystem 
/opt/local/libexec/qt5/Library/Frameworks/QtQspXDG.framework/Headers -isystem 
/opt/local/libexec/qt5/Library/Frameworks/QtDBus.framework/Headers -isystem 
/opt/local/libexec/qt5/Library/Frameworks/QtXml.framework/Headers -isystem 
/opt/local/libexec/qt5/Library/Frameworks/QtWidgets.framework/Headers -isystem 
/opt/local/libexec/qt5/Library/Frameworks/QtGui.framework/Headers -isystem 
/System/Library/Frameworks/OpenGL.framework/Headers  -O3 -march=native -g 
-DNDEBUG -DQT_USE_EXTSTANDARDPATHS -DQT_EXTSTANDARDPATHS_XDG_DEFAULT=true  
-std=iso9899:1990 -fno-common -Wall -Wextra -Wcast-align -Wchar-subscripts 
-Wformat-secur
 ity -Wno-long-long -Wpointer-arith -Wundef -Wmissing-format-attribute 
-Wwrite-strings -Werror=implicit-function-declaration -arch x86_64 
-mmacosx-version-min=10.9 -fvisibility=hidden   -DSOLID_STATIC_DEFINE=1 -fPIC 
-o CMakeFiles/KF5Solid_static.dir/predicate_parser.c.o   -c 
/opt/local/var/macports/build/_opt_local_site-ports_kf5_KF5-Frameworks/kf5-solid/work/build/src/solid/predicate_parser.c
> >  
> > /opt/local/var/macports/build/_opt_local_site-ports_kf5_KF5-Frameworks/kf5-solid/work/build/src/solid/predicate_parser.c:1206:30:
> >  error: too few arguments to function call, expected 2, have 1
> >yychar = yylex ();
> > ~ ^
> >  devices/predicate_parser.y:13:1: note: 'Solidlex' declared here
> >  int Solidlex( YYSTYPE *yylval, yyscan_t scanner );
> >  ^
> >  devices/predicate_parser.y:96:17: error: too many arguments to function 
> > call, expected 0, have 1
> >  Solidparse( scanner );
> >  ~~  ^~~
> >  
> > /opt/local/var/macports/build/_opt_local_site-ports_kf5_KF5-Frameworks/kf5-solid/work/build/src/solid/predicate_parser.c:1036:1:
> >  note: 'Solidparse' declared here
> >  int
> >  ^
> >  2 errors generated.
> >  make[2]: *** 
> > [src/solid/CMakeFiles/KF5Solid_static.dir/predicate_parser.c.o] Error 1
> >  make[2]: Leaving directory 
> > `/opt/local/var/macports/build/_opt_local_site-ports_kf5_KF5-Frameworks/kf5-solid/work/build'
> >  make[1]: *** [src/solid/CMakeFiles/KF5Solid_static.dir/all] Error 2
> >  make[1]: Leaving directory 
> > `/opt/local/var/macports/build/_opt_local_site-ports_kf5_KF5-Frameworks/kf5-solid/work/build'
> >  make: *** [all] Error 2
> >  make: Leaving directory 
> > `/opt/local/var/macports/build/_opt_local_site-ports_kf5_KF5-Frameworks/kf5-solid/work/build'
> > ```
> 
> René J.V. Bertin wrote:
> False alarm, builds fine with 5.22.0
> 
> Pino Toscano wrote:
> Oh sorry, forgot to mention that you

Re: Review Request 127972: Always update the Predicate parser from y/l sources

2016-05-21 Thread René J . V . Bertin 


> On May 21, 2016, 1:21 a.m., René J.V. Bertin wrote:
> > I've done some testing with Solid 5.20.0 .The patch applies cleanly, but 
> > I'm getting the error below. I'd write that down to using the older Solid 
> > version if it weren't for that fact I'm quite sure I've seen this kind of 
> > error before:
> > 
> > ```
> >  [ 30%] [BISON][SolidParser] Building parser with bison 3.0.4
> >  cd 
> > /opt/local/var/macports/build/_opt_local_site-ports_kf5_KF5-Frameworks/kf5-solid/work/solid-5.20.0/src/solid
> >  && /opt/local/bin/bison -p Solid -d -b predicate_parser -d -o 
> > /opt/local/var/macports/build/_opt_local_site-ports_kf5_KF5-Frameworks/kf5-solid/work/build/src/solid/predicate_parser.c
> >  devices/predicate_parser.y
> >  ...
> >  make[2]: Entering directory 
> > `/opt/local/var/macports/build/_opt_local_site-ports_kf5_KF5-Frameworks/kf5-solid/work/build'
> >  [ 31%] Building C object 
> > src/solid/CMakeFiles/KF5Solid_static.dir/predicate_parser.c.o
> >  cd 
> > /opt/local/var/macports/build/_opt_local_site-ports_kf5_KF5-Frameworks/kf5-solid/work/build/src/solid
> >  && 
> > /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang
> >   -DQT_CORE_LIB -DQT_DBUS_LIB -DQT_GUI_LIB -DQT_MAC_USE_COCOA 
> > -DQT_NO_CAST_TO_ASCII -DQT_NO_DEBUG -DQT_NO_SIGNALS_SLOTS_KEYWORDS 
> > -DQT_NO_URL_CAST_FROM_STRING -DQT_QSP_XDG_LIB -DQT_USE_FAST_OPERATOR_PLUS 
> > -DQT_USE_QSTRINGBUILDER -DQT_WIDGETS_LIB -DQT_XML_LIB -D_DARWIN_C_SOURCE 
> > -D_LARGEFILE64_SOURCE 
> > -I/opt/local/var/macports/build/_opt_local_site-ports_kf5_KF5-Frameworks/kf5-solid/work/build/src/solid
> >  
> > -I/opt/local/var/macports/build/_opt_local_site-ports_kf5_KF5-Frameworks/kf5-solid/work/solid-5.20.0/src/solid
> >  
> > -I/opt/local/var/macports/build/_opt_local_site-ports_kf5_KF5-Frameworks/kf5-solid/work/solid-5.20.0/src/solid/devices
> >  
> > -I/opt/local/var/macports/build/_opt_local_site-ports_kf5_KF5-Frameworks/kf5-solid/work/solid-5.20.0/src/solid/devices/frontend
> >  -I/opt/local/var/macports/build/_
 
opt_local_site-ports_kf5_KF5-Frameworks/kf5-solid/work/solid-5.20.0/src/solid/..
 
-I/opt/local/var/macports/build/_opt_local_site-ports_kf5_KF5-Frameworks/kf5-solid/work/build/src/solid/..
 -iframework /opt/local/libexec/qt5/Library/Frameworks -isystem 
/opt/local/libexec/qt5/Library/Frameworks/QtCore.framework/Headers -isystem 
/opt/local/share/qt5/mkspecs/macx-clang -isystem 
/opt/local/libexec/qt5/Library/Frameworks/QtQspXDG.framework/Headers -isystem 
/opt/local/libexec/qt5/Library/Frameworks/QtDBus.framework/Headers -isystem 
/opt/local/libexec/qt5/Library/Frameworks/QtXml.framework/Headers -isystem 
/opt/local/libexec/qt5/Library/Frameworks/QtWidgets.framework/Headers -isystem 
/opt/local/libexec/qt5/Library/Frameworks/QtGui.framework/Headers -isystem 
/System/Library/Frameworks/OpenGL.framework/Headers  -O3 -march=native -g 
-DNDEBUG -DQT_USE_EXTSTANDARDPATHS -DQT_EXTSTANDARDPATHS_XDG_DEFAULT=true  
-std=iso9899:1990 -fno-common -Wall -Wextra -Wcast-align -Wchar-subscripts 
-Wformat-secur
 ity -Wno-long-long -Wpointer-arith -Wundef -Wmissing-format-attribute 
-Wwrite-strings -Werror=implicit-function-declaration -arch x86_64 
-mmacosx-version-min=10.9 -fvisibility=hidden   -DSOLID_STATIC_DEFINE=1 -fPIC 
-o CMakeFiles/KF5Solid_static.dir/predicate_parser.c.o   -c 
/opt/local/var/macports/build/_opt_local_site-ports_kf5_KF5-Frameworks/kf5-solid/work/build/src/solid/predicate_parser.c
> >  
> > /opt/local/var/macports/build/_opt_local_site-ports_kf5_KF5-Frameworks/kf5-solid/work/build/src/solid/predicate_parser.c:1206:30:
> >  error: too few arguments to function call, expected 2, have 1
> >yychar = yylex ();
> > ~ ^
> >  devices/predicate_parser.y:13:1: note: 'Solidlex' declared here
> >  int Solidlex( YYSTYPE *yylval, yyscan_t scanner );
> >  ^
> >  devices/predicate_parser.y:96:17: error: too many arguments to function 
> > call, expected 0, have 1
> >  Solidparse( scanner );
> >  ~~  ^~~
> >  
> > /opt/local/var/macports/build/_opt_local_site-ports_kf5_KF5-Frameworks/kf5-solid/work/build/src/solid/predicate_parser.c:1036:1:
> >  note: 'Solidparse' declared here
> >  int
> >  ^
> >  2 errors generated.
> >  make[2]: *** 
> > [src/solid/CMakeFiles/KF5Solid_static.dir/predicate_parser.c.o] Error 1
> >  make[2]: Leaving directory 
> > `/opt/local/var/macports/build/_opt_local_site-ports_kf5_KF5-Frameworks/kf5-solid/work/build'
> >  make[1]: *** [src/solid/CMakeFiles/KF5Solid_static.dir/all] Error 2
> >  make[1]: Leaving directory 
> > `/opt/local/var/macports/build/_opt_local_site-ports_kf5_KF5-Frameworks/kf5-solid/work/build'
> >  make: *** [all] Error 2
> >  make: Leaving directory 
> > `/opt/local/var/macports/build/_opt_local_site-ports_kf5_KF5-Frameworks/kf5-solid/work/build'
> > ```
> 
> René J.V. Bertin wrote:
> False alarm, builds fine with 5.22.0
> 
> Pino Toscano wrote:
> Oh sorry, forgot to mention that you need

Re: Review Request 126610: kwidgetitemdelegate: properly cleanup widgets on index removal

2016-05-21 Thread Pino Toscano 


> On March 28, 2016, 5:14 p.m., Stephen Kelly wrote:
> > Do you still have the sample application you made to test/verify this? I'd 
> > like to try it and it should probably be committed too.

No I don't :-/ I remember it was just removing indexes with associated widgets.


- Pino


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


On March 28, 2016, 1:41 p.m., Pino Toscano wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/126610/
> ---
> 
> (Updated March 28, 2016, 1:41 p.m.)
> 
> 
> Review request for KDE Frameworks, David Edmundson and Stephen Kelly.
> 
> 
> Repository: kitemviews
> 
> 
> Description
> ---
> 
> When indexes are removed and their widgets deleted, the event filter on each 
> widget is not removed, leading to the "you should not delete widgets 
> manually"-alike warning.
> 
> Add an helper forgetAbout() function which performs all the actions done 
> per-widget before deleting each, additionally removing also the event filter.
> 
> 
> Diffs
> -
> 
>   src/kwidgetitemdelegate.cpp 779dc2a8a57148fb37f1f5a7194bc9656cb305a4 
>   src/kwidgetitemdelegatepool.cpp e916dddad8be56bb803e241da43d8cbe7a171ec3 
>   src/kwidgetitemdelegatepool_p.h 401fe193b0954d6c7c721503d4657b7f08e9fd2e 
> 
> Diff: https://git.reviewboard.kde.org/r/126610/diff/
> 
> 
> Testing
> ---
> 
> A sample application with widgets for items in the model, removing indexes: 
> no more warning at removal time.
> 
> 
> Thanks,
> 
> Pino Toscano
> 
>

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