D6473: Crash when replacing new lines with spaces

[John Salatas]

jsalatas added a comment.


  In https://phabricator.kde.org/D6473#124300, @dhaumann wrote:
  
  > So the question is: Why is the cursor not updated? If we can answer this, 
we may be able to either find that this patch is correct, or that the root of 
the real issue lies somewhere else...
  
  
  H. I need to go through that again and let you know

REPOSITORY
  R39 KTextEditor

REVISION DETAIL
  https://phabricator.kde.org/D6473

To: jsalatas, #ktexteditor
Cc: dhaumann, kfunk, ltoscano, kwrite-devel, #frameworks

D6473: Crash when replacing new lines with spaces

[Dominik Haumann]

dhaumann added a comment.


  ...thining a bit more about this: What I dislike is the fact that we don't 
seem to understand why it crashes in the first place, right? The problem is 
that the cursor of the view is not updated, so it is behind the document end in 
an invalid line. And moving the cursor up will again put it into an invalid 
line, which crashes.
  
  So the question is: Why is the cursor not updated? If we can answer this, we 
may be able to either find that this patch is correct, or that the root of the 
real issue lies somewhere else...

REPOSITORY
  R39 KTextEditor

REVISION DETAIL
  https://phabricator.kde.org/D6473

To: jsalatas, #ktexteditor
Cc: dhaumann, kfunk, ltoscano, kwrite-devel, #frameworks

D6473: Crash when replacing new lines with spaces

[Dominik Haumann]

dhaumann added a comment.


  I'm not an expert in the search code - in general your fix looks sane (had a 
look into the KateRegExp class). A unit test indeed would be helpful, since it 
will allow us to not break the search code again.

REPOSITORY
  R39 KTextEditor

REVISION DETAIL
  https://phabricator.kde.org/D6473

To: jsalatas, #ktexteditor
Cc: dhaumann, kfunk, ltoscano, kwrite-devel, #frameworks

D6473: Crash when replacing new lines with spaces

[John Salatas]

jsalatas added a comment.


  In https://phabricator.kde.org/D6473#124287, @kfunk wrote:
  
  > Could you add a test in e.g. autotests/src/searchbar_test.cpp?
  
  
  Sure! will do it later...

REPOSITORY
  R39 KTextEditor

REVISION DETAIL
  https://phabricator.kde.org/D6473

To: jsalatas, #ktexteditor
Cc: kfunk, ltoscano, kwrite-devel, #frameworks

D6473: Crash when replacing new lines with spaces

[Kevin Funk]

kfunk added a comment.


  Could you add a test in e.g. autotests/src/searchbar_test.cpp?

REPOSITORY
  R39 KTextEditor

REVISION DETAIL
  https://phabricator.kde.org/D6473

To: jsalatas, #ktexteditor
Cc: kfunk, ltoscano, kwrite-devel, #frameworks

D5034: Add support for x-gvfs style options in fstab

[Stefan Brüns]

bruns added inline comments.

INLINE COMMENTS

> fstabstorageaccess.cpp:48
>  
> +const QStringList  = FstabHandling::options(device->device());
> +// GVFS by default doesn't show devices outside of /media, $HOME (and 
> some other locations)

Another useless use of const QList&, FstabHandling returns a detached list.
Even if it were not detached, contains() would not detach.

> fstabstorageaccess.cpp:52
> +// only x-gvfs-hide is honored here.
> +m_isIgnored = options.contains(QLatin1String("comment=x-gvfs-hide"));
> +

According to the linked udisk2 documentation, this should be a plain 
"x-gvfs-hide", scrap the "comment=".

REPOSITORY
  R245 Solid

REVISION DETAIL
  https://phabricator.kde.org/D5034

To: broulik, #plasma, dhaumann, dfaure
Cc: bruns, dhaumann, plasma-devel, #frameworks, ZrenBot, progwolff, lesliezhai, 
ali-mohamed, jensreuterberg, abetts, sebas, apol, mart, lukas

D6604: add a metainfo.yaml to make ECM a proper framework

[Harald Sitter]

sitter added a comment.


  In https://phabricator.kde.org/D6604#124228, @ochurlaud wrote:
  
  > At the time I thought about merging it but we would have to re-document 
everything in doxygen , which would be completely different from what upstream 
cmake does.
  >
  > The ECM page is already linked from the left menu. Does it make sense to 
have it in frameworks? It's more a prerequisite for the framework no?
  >
  > Anyway, a link would work though being suboptimal.
  
  
  The metainfo.yaml is a prerequisite for frameworks I think, yeah. If we could 
add a property to the yaml `generateApiDox: false` to prevent doxification of 
ECM that would also work all be it more work I suppose.
  
  BUT
  In a way, I am thinking that for consistency's sake it is actually nicer if 
ECM is listed alongside the other frameworks on 
https://api.kde.org/frameworks/index.html even if it then only links to the 
cmake documentation. It is, at the very least, more discoverable this way.

REPOSITORY
  R240 Extra CMake Modules

REVISION DETAIL
  https://phabricator.kde.org/D6604

To: sitter, ochurlaud, dfaure, skelly
Cc: #frameworks, #build_system

D6473: Crash when replacing new lines with spaces

[John Salatas]

jsalatas added a comment.


  ping?
  
  :)

REPOSITORY
  R39 KTextEditor

REVISION DETAIL
  https://phabricator.kde.org/D6473

To: jsalatas, #ktexteditor
Cc: ltoscano, kwrite-devel, #frameworks

D4377: Fix Python dependency in test scripts for KFileMetaData (bug 375472)

[Matthieu Gallien]

mgallien accepted this revision.
mgallien added a comment.
This revision is now accepted and ready to land.


  I tested on Debian with python2 (the version for /usr/bin/python ) . It 
works. Please ship your patch. Thanks for your work and sorry for the delay 
from my side.

REPOSITORY
  R286 KFileMetaData

REVISION DETAIL
  https://phabricator.kde.org/D4377

To: awilcox, mgallien
Cc: #frameworks

D6604: add a metainfo.yaml to make ECM a proper framework

[Olivier Churlaud]

ochurlaud added a comment.


  At the time I thought about merging it but we would have to read document 
everything in doxygen , which would be completely different from what upstream 
cmake does.
  
  The ECM page is already linked from the left menu. Does it make sense to have 
it in frameworks? It's more a prerequisite for the framework no?
  
  Anyway, a link would work though being suboptimal.

REPOSITORY
  R240 Extra CMake Modules

REVISION DETAIL
  https://phabricator.kde.org/D6604

To: sitter, ochurlaud, dfaure, skelly
Cc: #frameworks, #build_system

D6631: Fix compilation with strict libc (such as musl)

[Michael Pyne]

mpyne created this revision.
Restricted Application added a project: Plasma.
Restricted Application added a subscriber: plasma-devel.

REVISION SUMMARY
  Many of the functions we use implicitly are not part of the C standard
  library so we have to specific that we're pulling from POSIX, X/Open,
  BSD, or whatever standard we're using before we can rely on the
  definition being available.
  

  
  There's plenty of room for refactoring here since I mostly stopped at
  just getting the functions being called to show up from their includes,
  although I did replace rindex with strrchr since the latter is
  standardized, and replaced `uint` with `unsigned` rather than trying to 
figure out
  what header includes those.

TEST PLAN
  Now compiles against musl libc
  Still compiles against glibc.

REPOSITORY
  R111 KSysguard Library

REVISION DETAIL
  https://phabricator.kde.org/D6631

AFFECTED FILES
  ksysguardd/Command.c
  ksysguardd/Linux/ProcessList.c
  ksysguardd/Linux/diskstat.c
  ksysguardd/Linux/netstat.c
  ksysguardd/Linux/softraid.c
  ksysguardd/PWUIDCache.c
  ksysguardd/conf.c
  ksysguardd/ksysguardd.c

To: mpyne, #plasma, #frameworks
Cc: plasma-devel, ZrenBot, progwolff, lesliezhai, ali-mohamed, jensreuterberg, 
abetts, sebas, apol, mart, lukas

D6604: add a metainfo.yaml to make ECM a proper framework

[David Faure]

dfaure added a comment.


  Please add a README.md too, with the same syntax as in the other frameworks.

REPOSITORY
  R240 Extra CMake Modules

REVISION DETAIL
  https://phabricator.kde.org/D6604

To: sitter, ochurlaud, dfaure, skelly
Cc: #frameworks, #build_system

D5209: Load translations from KPackage files if bundled

[Luigi Toscano]

ltoscano added a comment.


  In https://phabricator.kde.org/D5209#124129, @davidedmundson wrote:
  
  > contents/locale/fr/org.kde.blahblah.po
  >
  > which is the same as KDE4.
  
  
  I guess you mean
  contents/locale/fr/org.kde.blahblah.**mo**
  ?

REPOSITORY
  R242 Plasma Framework (Library)

REVISION DETAIL
  https://phabricator.kde.org/D5209

To: davidedmundson, #plasma, mart
Cc: ltoscano, Zren, plasma-devel, #frameworks, ZrenBot, progwolff, lesliezhai, 
ali-mohamed, jensreuterberg, abetts, sebas, apol, mart, lukas

D5209: Load translations from KPackage files if bundled

[David Edmundson]

davidedmundson added a comment.


  contents/locale/fr/org.kde.blahblah.po
  
  which is the same as KDE4.

REPOSITORY
  R242 Plasma Framework (Library)

REVISION DETAIL
  https://phabricator.kde.org/D5209

To: davidedmundson, #plasma, mart
Cc: Zren, plasma-devel, #frameworks, ZrenBot, progwolff, lesliezhai, 
ali-mohamed, jensreuterberg, abetts, sebas, apol, mart, lukas

D5209: Load translations from KPackage files if bundled

[Chris Holland]

Zren added a comment.


  Oh awesome. Just found out about this. So this would be added in Frameworks 
5.37 then?
  
  Does this mean:
  
  1. 
`digitalclock.plasmoid/translations/plasma_applet_org.kde.plasma.digitalclock.po`
  2. 
`digitalclock.plasmoid/contents/translations/plasma_applet_org.kde.plasma.digitalclock.po`
  3. 
`digitalclock.plasmoid/translations/fr/LC_MESSAGES/plasma_applet_org.kde.plasma.digitalclock.po`
  4. 
`digitalclock.plasmoid/contents/translations/fr/LC_MESSAGES/plasma_applet_org.kde.plasma.digitalclock.po`
  
  So adding the domain will load `.po` files too? Or do they need to be `.mo` 
files?

REPOSITORY
  R242 Plasma Framework (Library)

REVISION DETAIL
  https://phabricator.kde.org/D5209

To: davidedmundson, #plasma, mart
Cc: Zren, plasma-devel, #frameworks, ZrenBot, progwolff, lesliezhai, 
ali-mohamed, jensreuterberg, abetts, sebas, apol, mart, lukas

D5208: Allow loading i18n catalogs from arbitrary locations

[David Edmundson]

This revision was automatically updated to reflect the committed changes.
Closed by commit R249:4c95ac8bb47f: Allow loading i18n catalogs from arbitrary 
locations (authored by davidedmundson).

REPOSITORY
  R249 KI18n

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D5208?vs=12962=16509

REVISION DETAIL
  https://phabricator.kde.org/D5208

AFFECTED FILES
  autotests/klocalizedstringtest.cpp
  autotests/klocalizedstringtest.h
  autotests/po/fr/ki18n-test2.po
  src/kcatalog.cpp
  src/kcatalog_p.h
  src/klocalizedstring.cpp
  src/klocalizedstring.h

To: davidedmundson, #frameworks, ilic
Cc: ilic

D5209: Load translations from KPackage files if bundled

[David Edmundson]

This revision was automatically updated to reflect the committed changes.
Closed by commit R242:3a0f61b5591d: Load translations from KPackage files if 
bundled (authored by davidedmundson).

REPOSITORY
  R242 Plasma Framework (Library)

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D5209?vs=12891=16510

REVISION DETAIL
  https://phabricator.kde.org/D5209

AFFECTED FILES
  src/plasma/pluginloader.cpp

To: davidedmundson, #plasma, mart
Cc: plasma-devel, #frameworks, ZrenBot, progwolff, lesliezhai, ali-mohamed, 
jensreuterberg, abetts, sebas, apol, mart, lukas

Re: kaboutlicense api extension ::spdxId()?

[Sebastian Kügler]

On dinsdag 11 juli 2017 13:41:17 CEST Harald Sitter wrote:
> I was wondering if anyone had an opinion on extending kaboutlicense
> with a ::spdxId() instance method returning the license's spdx id [1].
> 
> Use case at hand is kpackagetool, which maps X-KDE-PluginInfo-License
> of (e.g.) plasma applets to appstream metadata. Appstream however uses
> the standardized spdx identifiers so we need a conversion table
> somewhere. And here I am thinking why not kaboutlicense itself.
> 
> QString KAboutLicense::spdxId() const
> {
> switch (d->_licenseKey) {
> case KAboutLicense::File:
> return QStringLiteral("");
> case KAboutLicense::GPL_V2:
> return QStringLiteral("GPL-2.0");
>...
> }
> 
> [1] https://spdx.org/licenses/

This would make sense and allow 3rd party tools using SPDX keys to make sense 
of X-KDE-PluginInfo-License keys, indeed. I think it's useful.

> (on a side node: it may be useful to switch our plugininfos to spdx
> ids by default at some point in the future, our current format is not
> only deficient in the lack of standardization but also doesn't cover
> 'and later' qualification at all)

It does parse "and later", it's indicated by the + sign, but it's not 
reflected in the enum, GPLv2+ would be mapped to GPLv2, so you're right, our 
current system is lacking in that regard (but could be extended, although I 
don't know what would break then.

Cheers,
-- 
sebas

http://www.kde.org | http://vizZzion.org

D6624: do not crash qaccessible by causing a resize in a resize event

[Harald Sitter]

sitter added a comment.


  In https://phabricator.kde.org/D6624#124077, @cfeck wrote:
  
  > Reading your description on the referenced QTBUG, does it help to use a 
compare with previous m_columns in KCharSelectItemModel ::setColumnCount() 
before doing the emit dance?
  
  
  It probably does. To me, that would seem a bit too close to the cause though. 
If tomorrow another bit of the resizing calculation starts causing a re-layout 
it would crash again. That said, I think adding an `if` would be handy either 
way, what with saving a bunch of cpu cycles.

REPOSITORY
  R236 KWidgetsAddons

REVISION DETAIL
  https://phabricator.kde.org/D6624

To: sitter, gladhorn
Cc: cfeck, anthonyfieroni, #frameworks

kaboutlicense api extension ::spdxId()?

[Harald Sitter]

Hola

I was wondering if anyone had an opinion on extending kaboutlicense
with a ::spdxId() instance method returning the license's spdx id [1].

Use case at hand is kpackagetool, which maps X-KDE-PluginInfo-License
of (e.g.) plasma applets to appstream metadata. Appstream however uses
the standardized spdx identifiers so we need a conversion table
somewhere. And here I am thinking why not kaboutlicense itself.

QString KAboutLicense::spdxId() const
{
switch (d->_licenseKey) {
case KAboutLicense::File:
return QStringLiteral("");
case KAboutLicense::GPL_V2:
return QStringLiteral("GPL-2.0");
   ...
}

[1] https://spdx.org/licenses/

(on a side node: it may be useful to switch our plugininfos to spdx
ids by default at some point in the future, our current format is not
only deficient in the lack of standardization but also doesn't cover
'and later' qualification at all)

KDE CI: Frameworks kirigami kf5-qt5 XenialQt5.7 - Build # 14 - Still Unstable!

[no-reply]

BUILD UNSTABLE
 Build URL
https://build.kde.org/job/Frameworks%20kirigami%20kf5-qt5%20XenialQt5.7/14/
 Project:
Frameworks kirigami kf5-qt5 XenialQt5.7
 Date of build:
Tue, 11 Jul 2017 11:31:05 +
 Build duration:
50 sec and counting
   JUnit Tests
  Name: (root) Failed: 1 test(s), Passed: 1 test(s), Skipped: 0 test(s), Total: 2 test(s)Failed: TestSuite.qmltests
   Cobertura Report
  
   Project Coverage Summary
  
   Name
  Cobertura Coverage Report

build.log
Description: Binary data

KDE CI: Frameworks kirigami kf5-qt5 FreeBSDQt5.7 - Build # 13 - Still Unstable!

[no-reply]

BUILD UNSTABLE
 Build URL
https://build.kde.org/job/Frameworks%20kirigami%20kf5-qt5%20FreeBSDQt5.7/13/
 Project:
Frameworks kirigami kf5-qt5 FreeBSDQt5.7
 Date of build:
Tue, 11 Jul 2017 11:31:05 +
 Build duration:
52 sec and counting
   JUnit Tests
  Name: (root) Failed: 1 test(s), Passed: 0 test(s), Skipped: 0 test(s), Total: 1 test(s)Failed: TestSuite.qmltests

build.log
Description: Binary data

D6624: do not crash qaccessible by causing a resize in a resize event

[Christoph Feck]

cfeck added a comment.


  Reading your description on the referenced QTBUG, does it help to use a 
compare with previous m_columns in KCharSelectItemModel ::setColumnCount() 
before doing the emit dance?

REPOSITORY
  R236 KWidgetsAddons

REVISION DETAIL
  https://phabricator.kde.org/D6624

To: sitter, gladhorn
Cc: cfeck, anthonyfieroni, #frameworks

D6624: do not crash qaccessible by causing a resize in a resize event

[Harald Sitter]

sitter added inline comments.

INLINE COMMENTS

> anthonyfieroni wrote in kcharselect.cpp:251
> QSignalBlocker blockResize(this) ?

Block inhibits signal emission/slot calling. That is not what we want. We want 
the signals to run, just not on the same call chain as the resize event.

REPOSITORY
  R236 KWidgetsAddons

REVISION DETAIL
  https://phabricator.kde.org/D6624

To: sitter, gladhorn
Cc: anthonyfieroni, #frameworks

D6624: do not crash qaccessible by causing a resize in a resize event

[Anthony Fieroni]

anthonyfieroni added inline comments.

INLINE COMMENTS

> kcharselect.cpp:251
> +connect(timer, ::timeout, [&,timer]() {
> +d->_k_resizeCells();
> +timer->deleteLater();

QSignalBlocker blockResize(this) ?

REPOSITORY
  R236 KWidgetsAddons

REVISION DETAIL
  https://phabricator.kde.org/D6624

To: sitter, gladhorn
Cc: anthonyfieroni, #frameworks

D6606: Support SVG too

[Wolfgang Bauer]

This revision was automatically updated to reflect the committed changes.
Closed by commit R313:ed5c039f2d19: Support SVG too (authored by wbauer).

CHANGED PRIOR TO COMMIT
  https://phabricator.kde.org/D6606?vs=16448=16505#toc

REPOSITORY
  R313 KHtml

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D6606?vs=16448=16505

REVISION DETAIL
  https://phabricator.kde.org/D6606

AFFECTED FILES
  src/imload/decoders/qimageioloader.cpp

To: wbauer, dfaure
Cc: #frameworks

D6624: do not crash qaccessible by causing a resize in a resize event

[Harald Sitter]

sitter added a comment.


  FWIW, this is a bit of workaround. Not having kcharselect crash for just 
about every search is well worth it though.
  Also, I am not sure I particularly like the qtimer code. It does beat having 
to pass `const char *` method names to `invokeMethod` and turning the private 
into a qobject. With the lambda the resize call at least gets checked by the 
compiler ¯\_(ツ)_/¯

REPOSITORY
  R236 KWidgetsAddons

REVISION DETAIL
  https://phabricator.kde.org/D6624

To: sitter, gladhorn
Cc: #frameworks

D6624: do not crash qaccessible by causing a resize in a resize event

[Harald Sitter]

sitter created this revision.
Restricted Application added a project: Frameworks.
Restricted Application added a subscriber: Frameworks.

REVISION SUMMARY
  When enabling accessibility qaccessible will automatically add a11y support
  constructs to core qt types such as qtableview.
  Unfortunately for qtableview specifically a change of the layout/size will
  discard the accessible objects modeling the individual cells in our table.
  Combined with the way we control layout through the model [I am not sure
  why we do this to begin with] this can result in call chains where
  qaccessible triggers a resizeEvent which we'll handle by rejiggering
  our model to get a new layout, resulting in qaccessible deleting the
  object which originally caused the event and ending in a segfault.
  
  To prevent this problem we delay the rejiggering of our model by running
  the call through the eventloop (i.e. the resize is executed once the stack
  unwinds again to the event loop).
  
  CHANGELOG: Fixed a crash when searching with accessibility support enabled
  BUG: 374933
  
  Also see https://bugreports.qt.io/browse/QTBUG-58153

TEST PLAN
  spent a good while searching and copy pasting and all that fun stuff. no more 
crashing.

REPOSITORY
  R236 KWidgetsAddons

BRANCH
  master

REVISION DETAIL
  https://phabricator.kde.org/D6624

AFFECTED FILES
  src/kcharselect.cpp

To: sitter, gladhorn
Cc: #frameworks

KDE CI: Frameworks kirigami kf5-qt5 FreeBSDQt5.7 - Build # 12 - Still Unstable!

[no-reply]

BUILD UNSTABLE
 Build URL
https://build.kde.org/job/Frameworks%20kirigami%20kf5-qt5%20FreeBSDQt5.7/12/
 Project:
Frameworks kirigami kf5-qt5 FreeBSDQt5.7
 Date of build:
Tue, 11 Jul 2017 10:31:01 +
 Build duration:
26 sec and counting
   JUnit Tests
  Name: (root) Failed: 1 test(s), Passed: 0 test(s), Skipped: 0 test(s), Total: 1 test(s)Failed: TestSuite.qmltests

build.log
Description: Binary data

KDE CI: Frameworks kirigami kf5-qt5 XenialQt5.7 - Build # 13 - Still Unstable!

[no-reply]

BUILD UNSTABLE
 Build URL
https://build.kde.org/job/Frameworks%20kirigami%20kf5-qt5%20XenialQt5.7/13/
 Project:
Frameworks kirigami kf5-qt5 XenialQt5.7
 Date of build:
Tue, 11 Jul 2017 10:31:01 +
 Build duration:
58 sec and counting
   JUnit Tests
  Name: (root) Failed: 1 test(s), Passed: 1 test(s), Skipped: 0 test(s), Total: 2 test(s)Failed: TestSuite.qmltests
   Cobertura Report
  
   Project Coverage Summary
  
   Name
  Cobertura Coverage Report

build.log
Description: Binary data

D6608: [PlasmaComponents Menu] Don't crash on null action

[Kai Uwe Broulik]

This revision was automatically updated to reflect the committed changes.
Closed by commit R242:21f954d94dc5: [PlasmaComponents Menu] Don't crash on null 
action (authored by broulik).

REPOSITORY
  R242 Plasma Framework (Library)

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D6608?vs=16491=16501

REVISION DETAIL
  https://phabricator.kde.org/D6608

AFFECTED FILES
  src/declarativeimports/plasmacomponents/qmenuitem.cpp
  tests/components/menu.qml

To: broulik, #plasma, davidedmundson
Cc: anthonyfieroni, davidedmundson, plasma-devel, #frameworks, ZrenBot, 
progwolff, lesliezhai, ali-mohamed, jensreuterberg, abetts, sebas, apol, mart, 
lukas

KDE CI: Frameworks kirigami kf5-qt5 XenialQt5.7 - Build # 12 - Still Unstable!

[no-reply]

BUILD UNSTABLE
 Build URL
https://build.kde.org/job/Frameworks%20kirigami%20kf5-qt5%20XenialQt5.7/12/
 Project:
Frameworks kirigami kf5-qt5 XenialQt5.7
 Date of build:
Tue, 11 Jul 2017 10:20:06 +
 Build duration:
1 min 9 sec and counting
   JUnit Tests
  Name: (root) Failed: 1 test(s), Passed: 1 test(s), Skipped: 0 test(s), Total: 2 test(s)Failed: TestSuite.qmltests
   Cobertura Report
  
   Project Coverage Summary
  
   Name
  Cobertura Coverage Report

build.log
Description: Binary data

KDE CI: Frameworks kirigami kf5-qt5 FreeBSDQt5.7 - Build # 11 - Still Unstable!

[no-reply]

BUILD UNSTABLE
 Build URL
https://build.kde.org/job/Frameworks%20kirigami%20kf5-qt5%20FreeBSDQt5.7/11/
 Project:
Frameworks kirigami kf5-qt5 FreeBSDQt5.7
 Date of build:
Tue, 11 Jul 2017 10:20:06 +
 Build duration:
33 sec and counting
   JUnit Tests
  Name: (root) Failed: 1 test(s), Passed: 0 test(s), Skipped: 0 test(s), Total: 1 test(s)Failed: TestSuite.qmltests

build.log
Description: Binary data

D6604: add a metainfo.yaml to make ECM a proper framework

[Harald Sitter]

sitter added a comment.


  Good point on trying it locally.
  
  So, as one could expect this adds ECM as a product
  
  F3808791: Screenshot_20170711_120142.png 

  
  Unfortunately given we have no actual documentation (outside the cmake 
documentation) this leads to a fairly useless page
  
  F3808793: Screenshot_20170711_120148.png 

  
  Am I right in assuming that the way to fix this is to write a mainpage which 
links to https://api.kde.org/ecm/ for the actual cmake documentation?

REPOSITORY
  R240 Extra CMake Modules

REVISION DETAIL
  https://phabricator.kde.org/D6604

To: sitter, ochurlaud, dfaure, skelly
Cc: #frameworks, #build_system

D6608: [PlasmaComponents Menu] Don't crash on null action

[David Edmundson]

davidedmundson accepted this revision.
This revision is now accepted and ready to land.

REPOSITORY
  R242 Plasma Framework (Library)

REVISION DETAIL
  https://phabricator.kde.org/D6608

To: broulik, #plasma, davidedmundson
Cc: anthonyfieroni, davidedmundson, plasma-devel, #frameworks, ZrenBot, 
progwolff, lesliezhai, ali-mohamed, jensreuterberg, abetts, sebas, apol, mart, 
lukas

D6608: [PlasmaComponents Menu] Don't crash on null action

[Kai Uwe Broulik]

broulik updated this revision to Diff 16491.
broulik added a comment.


  When assigning an action, match the item's visibility and enabled

REPOSITORY
  R242 Plasma Framework (Library)

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D6608?vs=16452=16491

REVISION DETAIL
  https://phabricator.kde.org/D6608

AFFECTED FILES
  src/declarativeimports/plasmacomponents/qmenuitem.cpp
  tests/components/menu.qml

To: broulik, #plasma, davidedmundson
Cc: anthonyfieroni, davidedmundson, plasma-devel, #frameworks, ZrenBot, 
progwolff, lesliezhai, ali-mohamed, jensreuterberg, abetts, sebas, apol, mart, 
lukas