D27238: Add an option to dynamic-break inside words

[Christoph Cullmann]

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


  Ok, happy with that, thanks!

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

To: eudoxos, cullmann
Cc: dhaumann, cullmann, kwrite-devel, kde-frameworks-devel, cent, rrosch, 
LeGast00n, cblack, szutmael, GB_2, domson, michaelh, ngraham, bruns, demsking, 
head7, kfunk, sars

D27238: Add an option to dynamic-break inside words

[Christoph Cullmann]

This revision was automatically updated to reflect the committed changes.
Closed by commit R39:0a08d45f2b56: Add an option to dynamic-break inside words 
(authored by cullmann).

REPOSITORY
  R39 KTextEditor

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D27238?vs=75509&id=75514

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

AFFECTED FILES
  src/dialogs/katedialogs.cpp
  src/dialogs/textareaappearanceconfigwidget.ui
  src/render/katerenderer.cpp
  src/utils/kateconfig.cpp
  src/utils/kateconfig.h

To: eudoxos, cullmann
Cc: dhaumann, cullmann, kwrite-devel, kde-frameworks-devel, cent, rrosch, 
LeGast00n, cblack, szutmael, GB_2, domson, michaelh, ngraham, bruns, demsking, 
head7, kfunk, sars

D27328: Drop qmake pri file generation & installation, currently broken

[Jan Grulich]

jgrulich added a comment.


  Looking at some other frameworks, they basically have same code to generate 
pri files, are they all broken?
  
  For example: https://cgit.kde.org/bluez-qt.git/tree/src/CMakeLists.txt#n195

REPOSITORY
  R282 NetworkManagerQt

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

To: kossebau, jgrulich
Cc: kde-frameworks-devel, LeGast00n, cblack, GB_2, michaelh, ngraham, bruns

D27332: try to fix issue with ispellchecker on windows

[Christoph Cullmann]

cullmann updated this revision to Diff 75516.
cullmann added a comment.


  any cleanup crashs silently

REPOSITORY
  R246 Sonnet

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D27332?vs=75513&id=75516

BRANCH
  arcpatch-D27332

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

AFFECTED FILES
  src/plugins/ispellchecker/ispellcheckerclient.cpp
  src/plugins/ispellchecker/ispellcheckerdict.cpp

To: cullmann, #frameworks, vonreth
Cc: kde-frameworks-devel, LeGast00n, cblack, GB_2, michaelh, ngraham, bruns

D27332: try to fix issue with ispellchecker on windows

[Christoph Cullmann]

cullmann updated this revision to Diff 75527.
cullmann added a comment.


  sonnet cleanup for the dictionaries seems to be too late
  
  try what happen if we leak them, too

REPOSITORY
  R246 Sonnet

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D27332?vs=75516&id=75527

BRANCH
  arcpatch-D27332

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

AFFECTED FILES
  src/plugins/ispellchecker/ispellcheckerclient.cpp
  src/plugins/ispellchecker/ispellcheckerclient.h
  src/plugins/ispellchecker/ispellcheckerdict.cpp
  src/plugins/ispellchecker/ispellcheckerdict.h

To: cullmann, #frameworks, vonreth
Cc: kde-frameworks-devel, LeGast00n, cblack, GB_2, michaelh, ngraham, bruns

D27332: try to fix issue with ispellchecker on windows

[Christoph Cullmann]

cullmann updated this revision to Diff 75532.
cullmann added a comment.


  fix argument to create spell checker

REPOSITORY
  R246 Sonnet

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D27332?vs=75527&id=75532

BRANCH
  arcpatch-D27332

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

AFFECTED FILES
  src/plugins/ispellchecker/ispellcheckerclient.cpp
  src/plugins/ispellchecker/ispellcheckerclient.h
  src/plugins/ispellchecker/ispellcheckerdict.cpp
  src/plugins/ispellchecker/ispellcheckerdict.h

To: cullmann, #frameworks, vonreth
Cc: kde-frameworks-devel, LeGast00n, cblack, GB_2, michaelh, ngraham, bruns

D27285: Add left/right indent fill (as opposed to left-only), extend indent lines to broken lines

[eudoxos]

eudoxos updated this revision to Diff 75533.
eudoxos added a comment.


  Rename config keys as per discussion under D27238 


REPOSITORY
  R39 KTextEditor

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D27285?vs=75440&id=75533

BRANCH
  dynwrap-marker

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

AFFECTED FILES
  src/dialogs/katedialogs.cpp
  src/dialogs/textareaappearanceconfigwidget.ui
  src/render/katelinelayout.cpp
  src/render/katelinelayout.h
  src/render/katerenderer.cpp
  src/utils/kateconfig.cpp
  src/utils/kateconfig.h

To: eudoxos, #vdg
Cc: kwrite-devel, kde-frameworks-devel, rrosch, LeGast00n, cblack, GB_2, 
domson, michaelh, ngraham, bruns, demsking, cullmann, sars, dhaumann

D27285: Add left/right indent fill (as opposed to left-only), extend indent lines to broken lines

[eudoxos]

eudoxos added a comment.


  This is the current dialogue, with two new options at the bottom (the circle 
had horizontal spring before an unrelated option, I think it was there by 
accident...?!).
  
  F8099358: image.png 

REPOSITORY
  R39 KTextEditor

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

To: eudoxos, #vdg
Cc: kwrite-devel, kde-frameworks-devel, rrosch, LeGast00n, cblack, GB_2, 
domson, michaelh, ngraham, bruns, demsking, cullmann, sars, dhaumann

D27332: try to fix issue with ispellchecker on windows

[Christoph Cullmann]

cullmann updated this revision to Diff 75534.
cullmann added a comment.


  add missing include for windows

REPOSITORY
  R246 Sonnet

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D27332?vs=75532&id=75534

BRANCH
  arcpatch-D27332

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

AFFECTED FILES
  src/plugins/ispellchecker/ispellcheckerclient.cpp
  src/plugins/ispellchecker/ispellcheckerclient.h
  src/plugins/ispellchecker/ispellcheckerdict.cpp
  src/plugins/ispellchecker/ispellcheckerdict.h

To: cullmann, #frameworks, vonreth
Cc: kde-frameworks-devel, LeGast00n, cblack, GB_2, michaelh, ngraham, bruns

D27342: Add setNotifyFunction to KPropertySkeletonItem

[Benjamin Port]

bport created this revision.
bport added reviewers: ervin, meven, crossi.
Herald added a project: Frameworks.
Herald added a subscriber: kde-frameworks-devel.
bport requested review of this revision.

REVISION SUMMARY
  This function will be called when the property value change

REPOSITORY
  R237 KConfig

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

AFFECTED FILES
  src/core/kcoreconfigskeleton.cpp
  src/core/kcoreconfigskeleton.h
  src/core/kcoreconfigskeleton_p.h

To: bport, ervin, meven, crossi
Cc: kde-frameworks-devel, LeGast00n, cblack, GB_2, michaelh, ngraham, bruns

D27332: try to fix issue with ispellchecker on windows

[Christoph Cullmann]

cullmann updated this revision to Diff 75536.
cullmann added a comment.


  adapt api to used QMap

REPOSITORY
  R246 Sonnet

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D27332?vs=75534&id=75536

BRANCH
  arcpatch-D27332

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

AFFECTED FILES
  src/plugins/ispellchecker/ispellcheckerclient.cpp
  src/plugins/ispellchecker/ispellcheckerclient.h
  src/plugins/ispellchecker/ispellcheckerdict.cpp
  src/plugins/ispellchecker/ispellcheckerdict.h

To: cullmann, #frameworks, vonreth
Cc: kde-frameworks-devel, LeGast00n, cblack, GB_2, michaelh, ngraham, bruns

D27342: Add setNotifyFunction to KPropertySkeletonItem

[Kevin Ottens]

ervin requested changes to this revision.
ervin added inline comments.
This revision now requires changes to proceed.

INLINE COMMENTS

> kcoreconfigskeleton.h:297
>  void swapDefault() override;
> +/**
> + * Set a function called when property change

Add an empty line before

> kcoreconfigskeleton.h:298
> +/**
> + * Set a function called when property change
> + * @since 5.68

"Set a notify function, it will be invoked when the value of the property 
changes."

REPOSITORY
  R237 KConfig

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

To: bport, ervin, meven, crossi
Cc: kde-frameworks-devel, LeGast00n, cblack, GB_2, michaelh, ngraham, bruns

D27332: try to fix issue with ispellchecker on windows

[Christoph Cullmann]

cullmann added a comment.


  Ok, tested on Win10 => This solves the issue.
  
  I see no proper way to cleanup this without thinking more about how sonnet 
does cache the dictionaries internally.
  It just cleans up "too late" with a global static.
  
  Given sonnet anyways will keep all stuff loaded until program exit, doing the 
same in the backend doesn't look that bad for me as an workaround.
  
  I tried it with
  
  https://binary-factory.kde.org/job/Kate_Release_win64/782/
  
  > this is the first version that doesn't always crash ;=)
  =

REPOSITORY
  R246 Sonnet

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

To: cullmann, #frameworks, vonreth
Cc: kde-frameworks-devel, LeGast00n, cblack, GB_2, michaelh, ngraham, bruns

D27342: Add setNotifyFunction to KPropertySkeletonItem

[Benjamin Port]

bport updated this revision to Diff 75540.
bport added a comment.


  Fix doc

REPOSITORY
  R237 KConfig

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D27342?vs=75535&id=75540

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

AFFECTED FILES
  src/core/kcoreconfigskeleton.cpp
  src/core/kcoreconfigskeleton.h
  src/core/kcoreconfigskeleton_p.h

To: bport, ervin, meven, crossi
Cc: kde-frameworks-devel, LeGast00n, cblack, GB_2, michaelh, ngraham, bruns

D27342: Add setNotifyFunction to KPropertySkeletonItem

[Benjamin Port]

bport marked 2 inline comments as done.

REPOSITORY
  R237 KConfig

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

To: bport, ervin, meven, crossi
Cc: kde-frameworks-devel, LeGast00n, cblack, GB_2, michaelh, ngraham, bruns

D27342: Add setNotifyFunction to KPropertySkeletonItem

[Kevin Ottens]

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

REPOSITORY
  R237 KConfig

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

To: bport, ervin, meven, crossi
Cc: kde-frameworks-devel, LeGast00n, cblack, GB_2, michaelh, ngraham, bruns

D27342: Add setNotifyFunction to KPropertySkeletonItem

[Benjamin Port]

This revision was automatically updated to reflect the committed changes.
Closed by commit R237:059a4feee45b: Add setNotifyFunction to 
KPropertySkeletonItem (authored by bport).

REPOSITORY
  R237 KConfig

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D27342?vs=75540&id=75542

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

AFFECTED FILES
  src/core/kcoreconfigskeleton.cpp
  src/core/kcoreconfigskeleton.h
  src/core/kcoreconfigskeleton_p.h

To: bport, ervin, meven, crossi
Cc: kde-frameworks-devel, LeGast00n, cblack, GB_2, michaelh, ngraham, bruns

D27343: Makefile highlight: fix variable names in "else" conditionals

[Nibaldo González]

nibags created this revision.
nibags added reviewers: Framework: Syntax Highlighting, dhaumann, cullmann.
Herald added projects: Kate, Frameworks.
Herald added subscribers: kde-frameworks-devel, kwrite-devel.
nibags requested review of this revision.

REVISION SUMMARY
  BUG: 417379
  
  Allow highlighting variables in "else" conditionals, for example: `else ifdef 
foo` or `else ifeq (bar, foo)`.
  
  Previously, these (bar and foo) were highlighted as "Error".

REPOSITORY
  R216 Syntax Highlighting

BRANCH
  fix-makefile

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

AFFECTED FILES
  autotests/folding/Makefile.fold
  autotests/html/Makefile.html
  autotests/input/Makefile
  autotests/reference/Makefile.ref
  data/syntax/makefile.xml

To: nibags, #framework_syntax_highlighting, dhaumann, cullmann
Cc: kwrite-devel, kde-frameworks-devel, rrosch, LeGast00n, cblack, GB_2, 
domson, michaelh, ngraham, bruns, demsking, cullmann, sars, dhaumann

D27343: Makefile highlight: fix variable names in "else" conditionals

[Nibaldo González]

nibags edited the summary of this revision.

REPOSITORY
  R216 Syntax Highlighting

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

To: nibags, #framework_syntax_highlighting, dhaumann, cullmann
Cc: kwrite-devel, kde-frameworks-devel, rrosch, LeGast00n, cblack, GB_2, 
domson, michaelh, ngraham, bruns, demsking, cullmann, sars, dhaumann

D27343: Makefile highlight: fix variable names in "else" conditionals

[Christoph Cullmann]

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


  Thanks for the fix!

REPOSITORY
  R216 Syntax Highlighting

BRANCH
  fix-makefile

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

To: nibags, #framework_syntax_highlighting, dhaumann, cullmann
Cc: kwrite-devel, kde-frameworks-devel, rrosch, LeGast00n, cblack, GB_2, 
domson, michaelh, ngraham, bruns, demsking, cullmann, sars, dhaumann

D27343: Makefile highlight: fix variable names in "else" conditionals

[Christoph Cullmann]

This revision was automatically updated to reflect the committed changes.
Closed by commit R216:86e132a3a829: Makefile highlight: fix variable names in 
"else" conditionals (authored by nibags, committed by cullmann).

REPOSITORY
  R216 Syntax Highlighting

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D27343?vs=75543&id=75544

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

AFFECTED FILES
  autotests/folding/Makefile.fold
  autotests/html/Makefile.html
  autotests/input/Makefile
  autotests/reference/Makefile.ref
  data/syntax/makefile.xml

To: nibags, #framework_syntax_highlighting, dhaumann, cullmann
Cc: kwrite-devel, kde-frameworks-devel, rrosch, LeGast00n, cblack, GB_2, 
domson, michaelh, ngraham, bruns, demsking, cullmann, sars, dhaumann

D27279: Port away from QWidget

[Aleksei Nikiforov]

alnikiforov added a comment.


  I've tested this patch in it's current form, and powerdevil no longer crashes 
for me on launch too. How can I reproduce crash in resume on idle? Can it be 
done in virtual machine?

REPOSITORY
  R274 KIdleTime

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

To: broulik, #frameworks, davidedmundson
Cc: alnikiforov, davidedmundson, kde-frameworks-devel, LeGast00n, cblack, GB_2, 
michaelh, ngraham, bruns

D27279: Port away from QWidget

[Kai Uwe Broulik]

broulik added a comment.


  > How can I reproduce crash in resume on idle?
  
  For me I set screen turn off to 1 minute, waited for the screen to fade to 
black, waited a bit more, got curious why it didn't actually turn it off, 
wiggled the mouse, and then found it crashed.
  You might need to toggle the compositor on/off (Alt+Shift+F12) when it fades 
to black to remove the layer since it is stuck at this point.

REPOSITORY
  R274 KIdleTime

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

To: broulik, #frameworks, davidedmundson
Cc: alnikiforov, davidedmundson, kde-frameworks-devel, LeGast00n, cblack, GB_2, 
michaelh, ngraham, bruns

D27059: KConfigSkeletonItem : allow to set a KconfigGroup to read and write items in nested groups

[Kevin Ottens]

ervin added a comment.


  LGTM, giving a couple more days for @dfaure to react to it though.

REPOSITORY
  R237 KConfig

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

To: crossi, ervin, dfaure, #frameworks
Cc: kde-frameworks-devel, LeGast00n, cblack, GB_2, michaelh, ngraham, bruns

D26877: Simplify calls to whitespace() and use it in more places.

[Kevin Ottens]

ervin added a comment.


  In D26877#604672 , @dfaure wrote:
  
  > I don't like it either. It doesn't "read" well.
  >  Looking at cout or qDebug it's much more common to `[the usual stream] << 
[some modifier] << some more stuff`.
  
  
  Yep, that's what made me jump in fact, it feels unusual. :-)
  
  > Maybe it can be solved with naming though.
  >  indentedStream() << ... 
  >  ?
  
  Not bad, it's a good compromise.

REPOSITORY
  R237 KConfig

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

To: tcanabrava, dfaure, ervin
Cc: ervin, kde-frameworks-devel, LeGast00n, cblack, GB_2, michaelh, ngraham, 
bruns

D20507: Update Japanese holidays

[Ryunosuke Toda]

Herald added a project: Frameworks.
Herald added a subscriber: kde-frameworks-devel.

REPOSITORY
  R175 KHolidays

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

To: nhiga, #kde_pim, dvratil
Cc: kde-frameworks-devel, ryunosuke, dvratil, kde-pim, LeGast00n, cblack, 
fbampaloukas, GB_2, dcaliste, michaelh, ngraham, bruns, dvasin, rodsevich, 
winterz, vkrause, mlaurent, knauss

D27133: kconfig_compiler : generate kconfig settings with subgroup

[Kevin Ottens]

ervin added a comment.


  @dfaure, any opinion on the separator character? It came from me checking 
which character is forbidden in group names, and it seems that only "group 
separator" is, so it started a bit like a joke with "I wonder if we'd need to 
patch KConfigSkeleton at all for subgroups if we pass that in a name", turns 
out we don't really and seeing how it look in the XML is... meh.
  
  I see two ways out: modifying the schema to be able to specify subgroups in 
the XML or hijacking a different character that no one use in the wild (which 
would mean looking at every single kcfg out there... not easy).

REPOSITORY
  R237 KConfig

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

To: crossi, ervin, dfaure, #frameworks
Cc: meven, kde-frameworks-devel, LeGast00n, cblack, GB_2, michaelh, ngraham, 
bruns

D27210: add KDEconnect Icons

[Albert Vaca Cintora]

albertvaka added a comment.


  Hey, thanks for working on this!
  
  A "brand" re-design is something that we could really use. One of the things 
that I would like to change from the current icon/logo, though (and that this 
new one doesn't change), is the fact that there is a mobile phone in it.
  
  You can use KDE Connect between two computers, or between two phones 
(although it's not the main development focus at the moment). So I think a more 
generic icon that embodies "syncing" without any specific device would suit us 
better, IMO. Plus I find a bit weird to have a phone app whose icon is... a 
phone.

REPOSITORY
  R266 Breeze Icons

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

To: mbruchert, #vdg, #kde_connect
Cc: albertvaka, nicolasfella, kde-frameworks-devel, LeGast00n, cblack, GB_2, 
michaelh, ngraham, bruns

D27279: Port away from QWidget

[Aleksei Nikiforov]

alnikiforov added a comment.


  I've managed to reproduce it and take a backtrace. It's an infinite 
recursion. Eventually stack's end is reached, although it takes some time to do 
it. Here's a piece of backtrace I got:
  
#460 0x764dcbec in KIdleTimePrivate::_k_resumingFromIdle 
(this=) at /usr/src/debug/kidletime-5.66.0/src/kidletime.cpp:244
#461 0x76e14143 in QMetaObject::activate (sender=0x50aa40, 
signalOffset=, local_signal_index=, 
argv=)
at kernel/qobject.cpp:3803
#462 0x77f4e9c4 in PowerDevil::Core::onResumingFromIdle 
(this=0x7fffe400cd30) at 
/usr/src/debug/powerdevil-5.17.5/daemon/powerdevilcore.cpp:820
#463 0x77f89055 in PowerDevil::Core::qt_static_metacall 
(_o=, _c=, _id=, _a=)
at 
/usr/src/debug/powerdevil-5.17.5/BUILD/daemon/powerdevilcore_autogen/EWIEGA46WW/moc_powerdevilcore.cpp:229
#464 0x76e14143 in QMetaObject::activate (sender=0x50cac0, 
signalOffset=, local_signal_index=, 
argv=)
at kernel/qobject.cpp:3803
#465 0x764dcbec in KIdleTimePrivate::_k_resumingFromIdle 
(this=) at /usr/src/debug/kidletime-5.66.0/src/kidletime.cpp:244
#466 0x76e14143 in QMetaObject::activate (sender=0x50aa40, 
signalOffset=, local_signal_index=, 
argv=)
at kernel/qobject.cpp:3803
#467 0x77f4e9c4 in PowerDevil::Core::onResumingFromIdle 
(this=0x7fffe400cd30) at 
/usr/src/debug/powerdevil-5.17.5/daemon/powerdevilcore.cpp:820
#468 0x77f89055 in PowerDevil::Core::qt_static_metacall 
(_o=, _c=, _id=, _a=)
at 
/usr/src/debug/powerdevil-5.17.5/BUILD/daemon/powerdevilcore_autogen/EWIEGA46WW/moc_powerdevilcore.cpp:229
#469 0x76e14143 in QMetaObject::activate (sender=0x50cac0, 
signalOffset=, local_signal_index=, 
argv=)
at kernel/qobject.cpp:3803
#470 0x764dcbec in KIdleTimePrivate::_k_resumingFromIdle 
(this=) at /usr/src/debug/kidletime-5.66.0/src/kidletime.cpp:244
#471 0x76e14143 in QMetaObject::activate (sender=0x50aa40, 
signalOffset=, local_signal_index=, 
argv=)
at kernel/qobject.cpp:3803
#472 0x77f4e9c4 in PowerDevil::Core::onResumingFromIdle 
(this=0x7fffe400cd30) at 
/usr/src/debug/powerdevil-5.17.5/daemon/powerdevilcore.cpp:820
#473 0x77f89055 in PowerDevil::Core::qt_static_metacall 
(_o=, _c=, _id=, _a=)
at 
/usr/src/debug/powerdevil-5.17.5/BUILD/daemon/powerdevilcore_autogen/EWIEGA46WW/moc_powerdevilcore.cpp:229
#474 0x76e14143 in QMetaObject::activate (sender=0x50cac0, 
signalOffset=, local_signal_index=, 
argv=)
at kernel/qobject.cpp:3803

REPOSITORY
  R274 KIdleTime

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

To: broulik, #frameworks, davidedmundson
Cc: alnikiforov, davidedmundson, kde-frameworks-devel, LeGast00n, cblack, GB_2, 
michaelh, ngraham, bruns

D27328: Drop qmake pri file generation & installation, currently broken

[Friedrich W. H. Kossebau]

kossebau added a comment.


  In D27328#610115 , @jgrulich wrote:
  
  > Looking at some other frameworks, they basically have same code to generate 
pri files, are they all broken?
  >
  > For example: https://cgit.kde.org/bluez-qt.git/tree/src/CMakeLists.txt#n195
  
  
  They are only broken if they miss a library they have in their public 
interface, for all of which there should be a qmake module mentioned in the 
`DEPS` argument (unless transitively covered, like `core` being already brought 
in by `gui`).
  
  Bluez-qt looks fine by a quick look at what is `PUBLIC` argument in the 
`target_link_libraries(KF5BluezQt)` call, Seems it does all cals via D-Bus and 
not have any libbluez in its publc interface.
  
  Yet there surely are more case of broken `ecm_generate_pri_file` calls. Seems 
many people just copy-paste-replaced the call, not checking the result :) While 
looking at this patch here, I e.g. came by prison having an even more broken 
call, in thei case though can be fixed, as again only other libraries are in 
the public interface for which there also is a qmake module pri file.

REPOSITORY
  R282 NetworkManagerQt

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

To: kossebau, jgrulich
Cc: kde-frameworks-devel, LeGast00n, cblack, GB_2, michaelh, ngraham, bruns

D27350: Port away from Title and towards level 1 Heading

[Nathaniel Graham]

ngraham created this revision.
ngraham added a reviewer: Plasma.
Herald added a project: Frameworks.
Herald added a subscriber: kde-frameworks-devel.
ngraham requested review of this revision.

REVISION SUMMARY
  `Title` is deprecated.

TEST PLAN
  No visual changes anywhere; level 1 Heading is identical in appearance

REPOSITORY
  R242 Plasma Framework (Library)

BRANCH
  port-away-from-title (branched from master)

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

AFFECTED FILES
  examples/applets/bugreport/contents/ui/main.qml
  examples/applets/testcomponents/contents/ui/DialogContent.qml
  examples/applets/testcomponents/contents/ui/DialogsPage.qml
  examples/applets/testcomponents/contents/ui/DragPage.qml
  examples/applets/testcomponents/contents/ui/IconsPage.qml
  examples/applets/testcomponents/contents/ui/MousePage.qml
  examples/applets/testcomponents/contents/ui/ThemePage.qml
  examples/applets/testtheme/contents/ui/FontTest.qml
  examples/applets/testtheme/contents/ui/ScalePage.qml
  examples/applets/testtheme/contents/ui/UnitsPage.qml
  examples/applets/widgetgallery/contents/ui/Typography.qml
  examples/developerguide/basic/contents/ui/main.qml
  src/declarativeimports/plasmaextracomponents/qml/Heading.qml
  src/declarativeimports/plasmaextracomponents/qml/Paragraph.qml
  templates/plasma-wallpaper-with-qml-extension/package/contents/ui/main.qml
  templates/plasma-wallpaper/package/contents/ui/main.qml

To: ngraham, #plasma
Cc: kde-frameworks-devel, LeGast00n, cblack, GB_2, michaelh, ngraham, bruns

D27351: call smb_cutime on the correct url to actually set mtime properly

[Harald Sitter]

sitter created this revision.
sitter added a reviewer: ngraham.
Herald added projects: Dolphin, Frameworks.
Herald added subscribers: kfm-devel, kde-frameworks-devel.
sitter requested review of this revision.

REVISION SUMMARY
  since the introduction of partial resume dstUrl would can be the .part url
  whereas dstOrigUrl is the final destination url.
  
  i.e.
  we called smbc_utime on smb://foo/bar.part rather than smb://foo/bar
  
  BUG: 356651
  FIXED-IN: 19.12.3

TEST PLAN
  moving file to smb retains mtime

REPOSITORY
  R320 KIO Extras

BRANCH
  bug356651

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

AFFECTED FILES
  smb/kio_smb_dir.cpp

To: sitter, ngraham
Cc: kde-frameworks-devel, kfm-devel, pberestov, iasensio, fprice, LeGast00n, 
cblack, MrPepe, fbampaloukas, alexde, GB_2, Codezela, feverfew, meven, 
michaelh, spoorun, navarromorales, firef, ngraham, andrebarros, bruns, 
emmanuelp, mikesomov

D27352: retain atime properly

[Harald Sitter]

sitter created this revision.
sitter added a reviewer: ngraham.
Herald added projects: Dolphin, Frameworks.
Herald added subscribers: kfm-devel, kde-frameworks-devel.
sitter requested review of this revision.

REVISION SUMMARY
  this was broken since forever I guess. when the .part resume tech was
  added it didn't correctly retain the access time. it was trying to
  get the atime of 'file', but 'file' when resuming refers to the .part which
  was deleted prior to the mtime adjustment so the QFileInfo(file).lastRead
  would produce an Invalid QDateTime which then results in us setting random
  nonesense as access time on the file.
  instead simply use dstFile. it is the path of the actual final destination
  file of which the atime is **actually** the one we want to preserve here
  considering we've literally just accessed that file by copying it ^^
  
  BUG: 410624
  FIXED-IN: 19.12.3

TEST PLAN
  copy file form smb to local has sound atime

REPOSITORY
  R320 KIO Extras

BRANCH
  bug410624

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

AFFECTED FILES
  smb/kio_smb_dir.cpp

To: sitter, ngraham
Cc: kde-frameworks-devel, kfm-devel, pberestov, iasensio, fprice, LeGast00n, 
cblack, MrPepe, fbampaloukas, alexde, GB_2, Codezela, feverfew, meven, 
michaelh, spoorun, navarromorales, firef, ngraham, andrebarros, bruns, 
emmanuelp, mikesomov

D26858: Provide an implementation for the tablet interface

[Aleix Pol Gonzalez]

apol updated this revision to Diff 75561.
apol added a comment.


  rebase on master

REPOSITORY
  R127 KWayland

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D26858?vs=74473&id=75561

BRANCH
  arcpatch-D26858

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

AFFECTED FILES
  CMakeLists.txt
  autotests/server/CMakeLists.txt
  autotests/server/test_tablet_interface.cpp
  src/server/CMakeLists.txt
  src/server/display.cpp
  src/server/display.h
  src/server/tablet_interface.cpp
  src/server/tablet_interface.h

To: apol, #kwin, #frameworks, zzag
Cc: davidedmundson, zzag, kde-frameworks-devel, LeGast00n, cblack, GB_2, 
michaelh, ngraham, bruns

D27352: retain atime properly

[Méven Car]

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

REPOSITORY
  R320 KIO Extras

BRANCH
  bug410624

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

To: sitter, ngraham, meven
Cc: kde-frameworks-devel, kfm-devel, pberestov, iasensio, fprice, LeGast00n, 
cblack, MrPepe, fbampaloukas, alexde, GB_2, Codezela, feverfew, meven, 
michaelh, spoorun, navarromorales, firef, ngraham, andrebarros, bruns, 
emmanuelp, mikesomov

D27352: retain atime properly

[Nathaniel Graham]

ngraham added a comment.


  So when I copy a file from my samba share to my desktop, the accessed time of 
the copied file on my machine should match the accessed time of the version on 
the server? If so, it doesn't seem to work for me; the accessed time is reset 
to the time when the file was copied.

REPOSITORY
  R320 KIO Extras

BRANCH
  bug410624

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

To: sitter, ngraham, meven
Cc: kde-frameworks-devel, kfm-devel, pberestov, iasensio, fprice, LeGast00n, 
cblack, MrPepe, fbampaloukas, alexde, GB_2, Codezela, feverfew, meven, 
michaelh, spoorun, navarromorales, firef, ngraham, andrebarros, bruns, 
emmanuelp, mikesomov

D26858: Provide an implementation for the tablet interface

[Aleix Pol Gonzalez]

apol added a comment.


  In D26858#605869 , @davidedmundson 
wrote:
  
  > Feedback from some testing:
  >
  > - we're adding the same tool a bunch of times when a new client is created
  > - sometimes we fail to enter the surface leaving the cursor "stuck" (with 
gtk3-demo)
  >
  >   I'll see if I can spot why.
  >
  > FWIW, Qt have a tablet test at qtbase/examples/widgets/widgets/tablet 
though that means compiling 5.15 to get the  qtwayland tablet  integration
  
  
  It looks stuck because we're not emulating mouse over them.
  
  We'll need to set up some infrastructure in KWin to do that properly.
  Before you look into it, we can't use Cursor::setPos() because it actually 
moves the mouse pointer and spawns a ton of unwanted events.

REPOSITORY
  R127 KWayland

BRANCH
  arcpatch-D26858

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

To: apol, #kwin, #frameworks, zzag
Cc: davidedmundson, zzag, kde-frameworks-devel, LeGast00n, cblack, GB_2, 
michaelh, ngraham, bruns

D26858: Provide an implementation for the tablet interface

[Aleix Pol Gonzalez]

apol updated this revision to Diff 75564.
apol added a comment.


  Only call destruction if it was an owned tablet, this way we don't crash.

REPOSITORY
  R127 KWayland

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D26858?vs=75561&id=75564

BRANCH
  arcpatch-D26858

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

AFFECTED FILES
  CMakeLists.txt
  autotests/server/CMakeLists.txt
  autotests/server/test_tablet_interface.cpp
  src/server/CMakeLists.txt
  src/server/display.cpp
  src/server/display.h
  src/server/tablet_interface.cpp
  src/server/tablet_interface.h

To: apol, #kwin, #frameworks, zzag
Cc: davidedmundson, zzag, kde-frameworks-devel, LeGast00n, cblack, GB_2, 
michaelh, ngraham, bruns

D27351: call smb_cutime on the correct url to actually set mtime properly

[Nathaniel Graham]

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


  It works! Fantastic!

REPOSITORY
  R320 KIO Extras

BRANCH
  bug356651

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

To: sitter, ngraham
Cc: kde-frameworks-devel, kfm-devel, pberestov, iasensio, fprice, LeGast00n, 
cblack, MrPepe, fbampaloukas, alexde, GB_2, Codezela, feverfew, meven, 
michaelh, spoorun, navarromorales, firef, ngraham, andrebarros, bruns, 
emmanuelp, mikesomov

D25010: [StatJob] Use A QFlag to specify the details returned by StatJob

[Méven Car]

meven updated this revision to Diff 75566.
meven marked 3 inline comments as done.
meven added a comment.


  Add a test for setDetails(KIO::StatDetails), fix comment, add a 
KIOCORE_ENABLE_DEPRECATED_SINCE

REPOSITORY
  R241 KIO

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D25010?vs=75304&id=75566

BRANCH
  arcpatch-D25010

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

AFFECTED FILES
  autotests/jobremotetest.cpp
  autotests/jobtest.cpp
  autotests/jobtest.h
  src/core/CMakeLists.txt
  src/core/copyjob.cpp
  src/core/deletejob.cpp
  src/core/directorysizejob.cpp
  src/core/global.h
  src/core/statjob.cpp
  src/core/statjob.h
  src/filewidgets/kdiroperator.cpp
  src/ioslaves/file/file.cpp
  src/ioslaves/file/file.h
  src/ioslaves/file/file_unix.cpp
  src/widgets/krun.cpp
  src/widgets/paste.cpp
  tests/kioslavetest.cpp
  tests/listjobtest.cpp

To: meven, #frameworks, dfaure, kossebau
Cc: kde-frameworks-devel, LeGast00n, cblack, GB_2, michaelh, ngraham, bruns

D25010: [StatJob] Use A QFlag to specify the details returned by StatJob

[Méven Car]

meven updated this revision to Diff 75567.
meven marked an inline comment as done.
meven added a comment.


  Make setDetails(KIO::StatDetail detail) compile only when deprecated since 
5.68 is enabled

REPOSITORY
  R241 KIO

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D25010?vs=75566&id=75567

BRANCH
  arcpatch-D25010

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

AFFECTED FILES
  autotests/jobremotetest.cpp
  autotests/jobtest.cpp
  autotests/jobtest.h
  src/core/CMakeLists.txt
  src/core/copyjob.cpp
  src/core/deletejob.cpp
  src/core/directorysizejob.cpp
  src/core/global.h
  src/core/statjob.cpp
  src/core/statjob.h
  src/filewidgets/kdiroperator.cpp
  src/ioslaves/file/file.cpp
  src/ioslaves/file/file.h
  src/ioslaves/file/file_unix.cpp
  src/widgets/krun.cpp
  src/widgets/paste.cpp
  tests/kioslavetest.cpp
  tests/listjobtest.cpp

To: meven, #frameworks, dfaure, kossebau
Cc: kde-frameworks-devel, LeGast00n, cblack, GB_2, michaelh, ngraham, bruns

KDE CI: Frameworks » kwindowsystem » kf5-qt5 SUSEQt5.12 - Build # 91 - Fixed!

[CI System]

BUILD SUCCESS
 Build URL
https://build.kde.org/job/Frameworks/job/kwindowsystem/job/kf5-qt5%20SUSEQt5.12/91/
 Project:
kf5-qt5 SUSEQt5.12
 Date of build:
Wed, 12 Feb 2020 17:47:19 +
 Build duration:
5 min 7 sec and counting
   BUILD ARTIFACTS
  acc/KF5WindowSystem-5.68.0.xmllogs/KF5WindowSystem/5.68.0/log.txt
   JUnit Tests
  Name: (root) Failed: 0 test(s), Passed: 1 test(s), Skipped: 0 test(s), Total: 1 test(s)Name: projectroot Failed: 0 test(s), Passed: 13 test(s), Skipped: 0 test(s), Total: 13 test(s)
   Cobertura Report
  
   Project Coverage Summary
  
   Name
  PackagesFilesClassesLinesConditionalsCobertura Coverage Report67%
(4/6)79%
(44/56)79%
(44/56)74%
(7271/9881)54%
(3537/6505)Coverage Breakdown by Package
Name
   FilesClassesLinesConditionalsautotests88%
(15/17)88%
(15/17)97%
(3076/3162)53%
(1291/2458)autotests.helper100%
(1/1)100%
(1/1)70%
(7/10)50%
(3/6)src86%
(12/14)86%
(12/14)53%
(820/1534)42%
(301/718)src.platforms.wayland0%
(0/2)0%
(0/2)0%
(0/70)100%
(0/0)src.platforms.xcb94%
(16/17)94%
(16/17)70%
(3368/4827)59%
(1942/3277)tests0%
(0/5)0%
(0/5)0%
(0/278)0%
(0/46)

D27352: retain atime properly

[Harald Sitter]

sitter added a comment.


  No, the access time is always the current time, the modified time should not 
change.

REPOSITORY
  R320 KIO Extras

BRANCH
  bug410624

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

To: sitter, ngraham, meven
Cc: kde-frameworks-devel, kfm-devel, pberestov, iasensio, fprice, LeGast00n, 
cblack, MrPepe, fbampaloukas, alexde, GB_2, Codezela, feverfew, meven, 
michaelh, spoorun, navarromorales, firef, ngraham, andrebarros, bruns, 
emmanuelp, mikesomov

Fwd: DBus on Windows - failing Jenkins builds

[Johnny Jazeix]

Hi,

sorry for the direct forward.

TLDR: Notifications uses dbus. On Windows and Mac, there is no dbus so
classes using dbus are not compiled. But KStatusNotifierItem still
uses dbus internally and this causes link error.
Is there a clean and easy way to bypass dbus calls for Windows?

Johnny


-- Forwarded message -
De : Ben Cooksley 
Date: mer. 12 févr. 2020 à 10:17
Subject: Re: DBus on Windows - failing Jenkins builds
To: KDE on Windows 


On Mon, Feb 3, 2020 at 8:15 PM Johnny Jazeix  wrote:
>
> Thank you Hannah for the addition,
>
> It now affects also skrooge and kwordquiz :/ (maybe more soon when
> they will be compiled again).
>
> I can try to find some time during the month and take a look to add
> these ifdef, if nobody fixes it before.

Another option is to raise this on KDE Frameworks Devel, as someone
there may know of an easy way to shortcut the D-Bus code in KSNI.

Cheers,
Ben

>
> Johnny
>
> Le dim. 2 févr. 2020 à 12:46, Hannah von Reth  a écrit :
> >
> > I had another look.
> > It looks like we need to add a couple of ifdefs to 
> > https://github.com/KDE/knotifications/blob/master/src/kstatusnotifieritem.cpp
> > There is no point in using dbus on Windows or mac here, as there is no 
> > desktop service that could receive it
> >
> >
> > On 01.02.20 18:36, Ben Cooksley wrote:
> >
> > On Sun, Feb 2, 2020 at 1:53 AM Johnny Jazeix  wrote:
> >
> > The applications link to KF5Notifications.lib library, the issue is
> > that this one does not compile KStatusNotifierItem class because it's
> > in a conditional if in the CMakeLists.txt of KF5Notifications.
> >
> > Which is the correct behaviour as we want a version without D-Bus.
> >
> > Unfortunately though that means every KDE application that wants to
> > provide a system tray icon will fail to compile, as we use KSNI for
> > that. For systems that don't mind having dbus around at runtime, it
> > isn't an issue as KSNI will fallback to QSystemTrayIcon. We of course
> > don't want DBus at all (even at runtime), so it seems to me that the
> > necessary fix is for KSNI on Windows to skip all the DBus stuff and
> > just provide it's wrapper functionality.
> >
> > The same should probably apply on macOS.
> >
> > Thoughts?
> >
> > Cheers,
> > Ben
> >
> > Le sam. 1 févr. 2020 à 13:15, Hannah von Reth  a écrit :
> >
> > Directly linking to KStatusNotifierItem sounds wrong.
> >
> > It should probably use the normal knotifications api.
> >
> >
> > Cheers,
> >
> > Hannah
> >
> >
> > On 01.02.20 12:49, Johnny Jazeix wrote:
> >
> > Le sam. 1 févr. 2020 à 09:57, Ben Cooksley  a écrit :
> >
> > On Sat, Feb 1, 2020 at 9:51 PM Johnny Jazeix  wrote:
> >
> > Hi,
> >
> > Hi Johnny,
> >
> > There are some builds in Jenkins that fail because of unresolved
> > external symbol of KStatusNotifierItem class (and let's be fair, I
> > don't like failing Jenkins).
> > After digging a bit, it is due to the fact that KNotifications is
> > built without dbus support:
> > https://cgit.kde.org/knotifications.git/tree/CMakeLists.txt#n42
> > meaning kstatusnotifieritem.cpp is not compiled:
> > https://cgit.kde.org/knotifications.git/tree/src/CMakeLists.txt#n24
> >
> > Aha. I had seen a few of these KSNI symbol failures, so it's nice to
> > know why they're occurring.
> >
> > However dependencies (drkonqi and ruqola if I'm not wrong), don't have
> > a condition on Windows for DBus use and directly use the
> > KStatusNotifierItem class.
> >
> > I'm not sure on the support of DBus on Windows and what is the right
> > direction to go:
> > * either enable dbus on KNotifications for Windows (if it is supported).
> > * or disable dbus on Windows on programs that uses it (drkonqi and ruqola)..
> >
> > Given that D-Bus doesn't really belong on Windows, doesn't bring us
> > much in the way of benefits there (as users are using just a single
> > application in many cases), and has tended to cause false positives
> > with anti-malware products, i'd suggest we follow the path of
> > disabling dbus support.
> >
> > Of course that brings up the question of whether KSNI should exist at
> > all on Windows. If memory serves it provides support for system tray
> > icons, in which case it probably should just wrap around the
> > appropriate Qt classes (for which I think fallback code already
> > exists?) and not compile any of the D-Bus stuff.
> >
> > Thoughts?
> >
> > It may be something to discuss on kde-devel (or directly with the
> > corresponding teams) because I don't know much about the use of the
> > library in the applications.
> >
> > KStatusNotifierItem is not used a lot on drkonqi:
> > https://github.com/KDE/drkonqi/search?q=statusnotifier&unscoped_q=statusnotifier
> > so it should not be complicated to bypass it on Windows but it seems
> > to require more efforts for ruqola.
> >
> > Johnny
> >
> >
> > Johnny
> >
> > Do you have any input on this?
> >
> > Johnny
> >
> > Cheers,
> > Ben

T12641: Refactor KFileProtocol::copy

[Méven Car]

meven added a comment.


  @dfaure does this makes sense to you ?

TASK DETAIL
  https://phabricator.kde.org/T12641

To: meven
Cc: apol, dfaure, #frameworks, #dolphin, ognarb, broulik, meven, pberestov, 
iasensio, fprice, LeGast00n, cblack, MrPepe, fbampaloukas, alexde, GB_2, 
Codezela, feverfew, michaelh, spoorun, navarromorales, firef, ngraham, 
andrebarros, bruns, emmanuelp, mikesomov

D27352: retain atime properly

[Nathaniel Graham]

ngraham added a comment.


  The modified time changes too. Am I testing this right?
  
  F8100051: vokoscreenNG-2020-02-12_11-52-33.mp4 


REPOSITORY
  R320 KIO Extras

BRANCH
  bug410624

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

To: sitter, ngraham, meven
Cc: kde-frameworks-devel, kfm-devel, pberestov, iasensio, fprice, LeGast00n, 
cblack, MrPepe, fbampaloukas, alexde, GB_2, Codezela, feverfew, meven, 
michaelh, spoorun, navarromorales, firef, ngraham, andrebarros, bruns, 
emmanuelp, mikesomov

D27354: Remove hardcoded colors

[Niccolò Venerandi]

niccolove created this revision.
Herald added a project: Frameworks.
Herald added a subscriber: kde-frameworks-devel.
niccolove requested review of this revision.

REVISION SUMMARY
  Fixes 
https://www.reddit.com/r/kde/comments/f2mxd3/517_seeing_weird_white_corners_on_my_autohiding/
  
  BUG:417511

REPOSITORY
  R242 Plasma Framework (Library)

BRANCH
  master

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

AFFECTED FILES
  src/desktoptheme/breeze/translucent/widgets/panel-background.svg
  src/desktoptheme/breeze/widgets/panel-background.svg

To: niccolove
Cc: kde-frameworks-devel, LeGast00n, cblack, GB_2, michaelh, ngraham, bruns

D27354: Remove hardcoded colors

[Niccolò Venerandi]

niccolove added a reviewer: ndavis.

REPOSITORY
  R242 Plasma Framework (Library)

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

To: niccolove, ndavis
Cc: kde-frameworks-devel, LeGast00n, cblack, GB_2, michaelh, ngraham, bruns

KDE CI: Frameworks » kiconthemes » kf5-qt5 WindowsMSVCQt5.14 - Build # 6 - Unstable!

[CI System]

BUILD UNSTABLE
 Build URL
https://build.kde.org/job/Frameworks/job/kiconthemes/job/kf5-qt5%20WindowsMSVCQt5.14/6/
 Project:
kf5-qt5 WindowsMSVCQt5.14
 Date of build:
Wed, 12 Feb 2020 19:29:40 +
 Build duration:
14 min and counting
   JUnit Tests
  Name: projectroot Failed: 2 test(s), Passed: 5 test(s), Skipped: 0 test(s), Total: 7 test(s)Failed: projectroot.autotests.kicondialog_unittestFailed: projectroot.autotests.kiconloader_unittest

KDE CI: Frameworks » kpackage » kf5-qt5 FreeBSDQt5.13 - Build # 56 - Still Unstable!

[CI System]

BUILD UNSTABLE
 Build URL
https://build.kde.org/job/Frameworks/job/kpackage/job/kf5-qt5%20FreeBSDQt5.13/56/
 Project:
kf5-qt5 FreeBSDQt5.13
 Date of build:
Wed, 12 Feb 2020 20:13:40 +
 Build duration:
1 min 14 sec and counting
   JUnit Tests
  Name: projectroot Failed: 1 test(s), Passed: 10 test(s), Skipped: 0 test(s), Total: 11 test(s)Failed: projectroot.autotests.plasma_packagestructuretest

D27352: retain atime properly

[Harald Sitter]

sitter added a comment.


  I think I tried with moving. Currently not at home to check.

REPOSITORY
  R320 KIO Extras

BRANCH
  bug410624

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

To: sitter, ngraham, meven
Cc: kde-frameworks-devel, kfm-devel, pberestov, iasensio, fprice, LeGast00n, 
cblack, MrPepe, fbampaloukas, alexde, GB_2, Codezela, feverfew, meven, 
michaelh, spoorun, navarromorales, firef, ngraham, andrebarros, bruns, 
emmanuelp, mikesomov

D27354: Remove hardcoded colors

[Noah Davis]

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

REPOSITORY
  R242 Plasma Framework (Library)

BRANCH
  master

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

To: niccolove, ndavis
Cc: kde-frameworks-devel, LeGast00n, cblack, GB_2, michaelh, ngraham, bruns

D27246: add buho icon

[Noah Davis]

ndavis requested changes to this revision.
ndavis added a comment.
This revision now requires changes to proceed.


  the shadow on the folded corners needs to be changed. diagonal shadows only 
go down and to the right

REPOSITORY
  R266 Breeze Icons

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

To: mbruchert, camiloh, #vdg, ndavis
Cc: ndavis, kde-frameworks-devel, LeGast00n, cblack, GB_2, michaelh, ngraham, 
bruns

D27355: Make kstatusnotifieritem available without dbus

[Hannah von Reth]

vonreth created this revision.
Herald added a project: Frameworks.
Herald added a subscriber: kde-frameworks-devel.
vonreth requested review of this revision.

REPOSITORY
  R289 KNotifications

BRANCH
  master

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

AFFECTED FILES
  CMakeLists.txt
  src/CMakeLists.txt
  src/kstatusnotifieritem.cpp
  src/kstatusnotifieritemprivate_p.h

To: vonreth
Cc: kde-frameworks-devel, LeGast00n, cblack, GB_2, michaelh, ngraham, bruns

D27355: POC: Make kstatusnotifieritem available without dbus

[Hannah von Reth]

vonreth retitled this revision from "Make kstatusnotifieritem available without 
dbus" to "POC: Make kstatusnotifieritem available without dbus".
vonreth edited the summary of this revision.
vonreth added reviewers: bcooksley, jjazeix.

REPOSITORY
  R289 KNotifications

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

To: vonreth, bcooksley, jjazeix
Cc: kde-frameworks-devel, LeGast00n, cblack, GB_2, michaelh, ngraham, bruns

D27355: POC: Make kstatusnotifieritem available without dbus

[Hannah von Reth]

vonreth added a comment.


  While preparing this I discovered that we should also review the locations 
where if MAC is used, as thats not the only platform that should use the 
systray icon

REPOSITORY
  R289 KNotifications

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

To: vonreth, bcooksley, jjazeix
Cc: kde-frameworks-devel, LeGast00n, cblack, GB_2, michaelh, ngraham, bruns

Re: 2 kirigami fixes for a point release

[Nate Graham]

[+ frameworks and plasma mailing lists]


On 2020-02-12 11:31, Albert Astals Cid wrote:

El dimecres, 12 de febrer de 2020, a les 15:37:09 CET, Nate Graham va escriure:

Personally I think it would be nice to have
86f988434cd657e77cc9429e78f7290ce6b5713d since otherwise LTS Plasma
users will be hitting it for the next few years.

---

On another note, I have to admit I'm starting to doubt how well our LTS
Plasma product works without a corresponding LTS frameworks release to
support it. We can fix bugs in software that uses the Plasma release
schedule till the cows come home, but if the bug is in Frameworks, users
are stuck with it forever since LTS distros don't typically ship new
Frameworks releases.

Yes yes, they should, and all that--but they don't.

It seems like we either need to:
- Work on convincing these distros to ship Frameworks versions in a
rolling manner to their LTS users
- Provide an LTS Frameworks product that can receive bugfixes and get
point releases, to support the Plasma LTS product
- Stop misleadingly offering a Plasma LTS product, since everything in
it that comes from Frameworks isn't actually LTS


This should not matter, Plasma LTS is built on *lots* of other libraries that 
are not LTS either.

If it matters is because the quality of KF5 releases are not good, that's what 
should be fixed IMHO.


Yes, the Frameworks 5.67 release was indeed was quite buggy and 
regression-filled from a Plasma perspective :(


However buggy releases are the proximate cause, not the root cause. We 
have to ask: what causes buggy releases?


I would argue that bugginess is baked into the Frameworks product by 
virtue of its very fast one-month release cycle and lack of beta 
periods, as there are for apps and Plasma. No matter how diligent patch 
review is, regressions always sneak in; that's why QA and beta-testing 
exist.


However because Frameworks has no explicit beta period, the only people 
performing QA are those who live on master all the time. The amount of 
time for these people to catch regressions can be as short as one day, 
for changes committed right before tagging. Even for commits at the very 
beginning of a Frameworks release cycle, there will be a maximum of one 
month before they ship to users. There simply isn't enough time to 
provide adequate QA for Frameworks releases, and the pool of people 
doing it is too small.


Making users be the QA is mostly okay for rolling release distros whose 
users are willing to take on that role: regressions get found and fixed 
in the next version and users receive the fixes in one month. But this 
model breaks down for LTS release distros that freeze on a specific 
frameworks version. If the version they've frozen on is buggy, that's 
it. It's buggy forever, unless their we make point releases or their 
already overworked packagers go out of the way to search for and 
backport fixes.


The Frameworks release model just doesn't fit for discrete release 
distros, especially for the LTS releases. Sometimes it works out better 
than other times, but it is a fundamental incompatibility when the 
product wants customers to ship new releases continuously, but the 
customers want the product frozen to one version with only safe bugfixes 
shipped after that.


Personally I think a lengthier release cycle and discrete beta periods 
would really help Frameworks, even in the absence of interest in 
creating a product more aligned to our LTS-using customers.


Nate

KDE CI: Frameworks » kwayland » kf5-qt5 FreeBSDQt5.13 - Build # 54 - Still Unstable!

[CI System]

BUILD UNSTABLE
 Build URL
https://build.kde.org/job/Frameworks/job/kwayland/job/kf5-qt5%20FreeBSDQt5.13/54/
 Project:
kf5-qt5 FreeBSDQt5.13
 Date of build:
Wed, 12 Feb 2020 22:56:47 +
 Build duration:
6 min 28 sec and counting
   JUnit Tests
  Name: projectroot.autotests Failed: 13 test(s), Passed: 29 test(s), Skipped: 0 test(s), Total: 42 test(s)Failed: projectroot.autotests.client.kwayland_testCompositorFailed: projectroot.autotests.client.kwayland_testDataDeviceFailed: projectroot.autotests.client.kwayland_testDataSourceFailed: projectroot.autotests.client.kwayland_testIdleFailed: projectroot.autotests.client.kwayland_testRegionFailed: projectroot.autotests.client.kwayland_testShmPoolFailed: projectroot.autotests.client.kwayland_testSubCompositorFailed: projectroot.autotests.client.kwayland_testSubSurfaceFailed: projectroot.autotests.client.kwayland_testWaylandConnectionThreadFailed: projectroot.autotests.client.kwayland_testWaylandRegistryFailed: projectroot.autotests.client.kwayland_testWaylandShellFailed: projectroot.autotests.client.kwayland_testWaylandSurfaceFailed: projectroot.autotests.server.kwayland_testWaylandServerDisplay

D27285: Add left/right indent fill (as opposed to left-only), extend indent lines to broken lines

[Dominik Haumann]

dhaumann added a comment.


  No offense meant, but even with the screenshots I still have no idea what 
this is about :)
  
  Can you add a before/after screenshot so we can see the visual difference?
  
  Also, the "fill left" and "fill right" wording is new, and not intuitively 
understandable for me.
  
  Can we do better?

REPOSITORY
  R39 KTextEditor

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

To: eudoxos, #vdg
Cc: dhaumann, kwrite-devel, kde-frameworks-devel, rrosch, LeGast00n, cblack, 
GB_2, domson, michaelh, ngraham, bruns, demsking, cullmann, sars

KDE CI: Frameworks » kwayland » kf5-qt5 SUSEQt5.13 - Build # 60 - Unstable!

[CI System]

BUILD UNSTABLE
 Build URL
https://build.kde.org/job/Frameworks/job/kwayland/job/kf5-qt5%20SUSEQt5.13/60/
 Project:
kf5-qt5 SUSEQt5.13
 Date of build:
Wed, 12 Feb 2020 22:56:47 +
 Build duration:
10 min and counting
   BUILD ARTIFACTS
  abi-compatibility-results.yamlacc/KF5Wayland-5.68.0.xmlcompat_reports/KF5Wayland_compat_report.htmllogs/KF5Wayland/5.68.0/log.txt
   JUnit Tests
  Name: (root) Failed: 0 test(s), Passed: 1 test(s), Skipped: 0 test(s), Total: 1 test(s)Name: projectroot.autotests Failed: 1 test(s), Passed: 45 test(s), Skipped: 0 test(s), Total: 46 test(s)Failed: projectroot.autotests.client.kwayland_testRemoteAccess
   Cobertura Report
  
   Project Coverage Summary
  
   Name
  PackagesFilesClassesLinesConditionalsCobertura Coverage Report63%
(5/8)90%
(241/269)90%
(241/269)85%
(27287/32236)53%
(11002/20685)Coverage Breakdown by Package
Name
   FilesClassesLinesConditionalsautotests.client100%
(43/43)100%
(43/43)99%
(12514/12599)50%
(6585/13087)autotests.server100%
(5/5)100%
(5/5)99%
(373/376)49%
(177/360)src.client96%
(73/76)96%
(73/76)85%
(6339/7471)65%
(1838/2836)src.compat100%
(2/2)100%
(2/2)100%
(81/81)100%
(0/0)src.server95%
(118/124)95%
(118/124)84%
(7980/9510)64%
(2402/3771)src.tools0%
(0/2)0%
(0/2)0%
(0/785)0%
(0/302)src.tools.testserver0%
(0/3)0%
(0/3)0%
(0/119)0%
(0/14)tests0%
(0/14)0%
(0/14)0%
(0/1295)0%
(0/315)

D27218: Add icon for org.kde.Ikona

[Carson Black]

cblack updated this revision to Diff 75577.
cblack added a comment.


  Adjust style

REPOSITORY
  R266 Breeze Icons

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D27218?vs=75506&id=75577

BRANCH
  ikona-icon (branched from master)

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

AFFECTED FILES
  icons-dark/apps/48/org.kde.Ikona.svg
  icons/apps/48/org.kde.Ikona.svg

To: cblack, #vdg
Cc: ndavis, kde-frameworks-devel, LeGast00n, cblack, GB_2, michaelh, ngraham, 
bruns

D27218: Add icon for org.kde.Ikona

[Noah Davis]

ndavis added a comment.


  please update the test plan before landing though

REPOSITORY
  R266 Breeze Icons

BRANCH
  ikona-icon (branched from master)

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

To: cblack, #vdg, ndavis
Cc: ndavis, kde-frameworks-devel, LeGast00n, cblack, GB_2, michaelh, ngraham, 
bruns

D27218: Add icon for org.kde.Ikona

[Noah Davis]

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

REPOSITORY
  R266 Breeze Icons

BRANCH
  ikona-icon (branched from master)

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

To: cblack, #vdg, ndavis
Cc: ndavis, kde-frameworks-devel, LeGast00n, cblack, GB_2, michaelh, ngraham, 
bruns

D27218: Add icon for org.kde.Ikona

[Carson Black]

cblack edited the test plan for this revision.

REPOSITORY
  R266 Breeze Icons

BRANCH
  ikona-icon (branched from master)

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

To: cblack, #vdg, ndavis
Cc: ndavis, kde-frameworks-devel, LeGast00n, cblack, GB_2, michaelh, ngraham, 
bruns

D27218: Add icon for org.kde.Ikona

[Carson Black]

This revision was automatically updated to reflect the committed changes.
Closed by commit R266:96cf15e1905d: Add icon for org.kde.Ikona (authored by 
cblack).

REPOSITORY
  R266 Breeze Icons

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D27218?vs=75577&id=75578

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

AFFECTED FILES
  icons-dark/apps/48/org.kde.Ikona.svg
  icons/apps/48/org.kde.Ikona.svg

To: cblack, #vdg, ndavis
Cc: ndavis, kde-frameworks-devel, LeGast00n, cblack, GB_2, michaelh, ngraham, 
bruns

D27355: POC: Make kstatusnotifieritem available without dbus

[Ben Cooksley]

bcooksley added inline comments.

INLINE COMMENTS

> kstatusnotifieritem.cpp:48
> +
> +#include 
>  #include 

New header?

> kstatusnotifieritem.cpp:617
>  void KStatusNotifierItem::showMessage(const QString &title, const QString 
> &message, const QString &icon, int timeout)
>  {
>  #ifdef Q_OS_MACOS

Won't this mean that showMessage() is a no-op on Windows systems without D-Bus?
I would have thought that systemTrayIcon->showMessage() should be used here as 
well?

> kstatusnotifieritem.cpp:888
>  {
> +bool useLegacy = false;
> +#ifdef QT_DBUS_LIB

From my reading of the setLegacySystemTrayEnabled() won't setting it to false 
explicitly disable any form of system tray icon?

REPOSITORY
  R289 KNotifications

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

To: vonreth, bcooksley, jjazeix
Cc: kde-frameworks-devel, LeGast00n, cblack, GB_2, michaelh, ngraham, bruns

Re: 2 kirigami fixes for a point release

[Kevin Ottens]

Hello,

Since I'm not on release-team I'm discovering this just now.

On Wednesday, 12 February 2020 21:59:32 CET Nate Graham wrote:
> [+ frameworks and plasma mailing lists]
> 
> On 2020-02-12 11:31, Albert Astals Cid wrote:
> > El dimecres, 12 de febrer de 2020, a les 15:37:09 CET, Nate Graham va 
escriure:
> >> Personally I think it would be nice to have
> >> 86f988434cd657e77cc9429e78f7290ce6b5713d since otherwise LTS Plasma
> >> users will be hitting it for the next few years.
> >> 
> >> ---
> >> 
> >> On another note, I have to admit I'm starting to doubt how well our LTS
> >> Plasma product works without a corresponding LTS frameworks release to
> >> support it. We can fix bugs in software that uses the Plasma release
> >> schedule till the cows come home, but if the bug is in Frameworks, users
> >> are stuck with it forever since LTS distros don't typically ship new
> >> Frameworks releases.
> >> 
> >> Yes yes, they should, and all that--but they don't.
> >> 
> >> It seems like we either need to:
> >> - Work on convincing these distros to ship Frameworks versions in a
> >> rolling manner to their LTS users
> >> - Provide an LTS Frameworks product that can receive bugfixes and get
> >> point releases, to support the Plasma LTS product
> >> - Stop misleadingly offering a Plasma LTS product, since everything in
> >> it that comes from Frameworks isn't actually LTS
> > 
> > This should not matter, Plasma LTS is built on *lots* of other libraries
> > that are not LTS either.
> > 
> > If it matters is because the quality of KF5 releases are not good, that's
> > what should be fixed IMHO.
> Yes, the Frameworks 5.67 release was indeed was quite buggy and
> regression-filled from a Plasma perspective :(
> 
> However buggy releases are the proximate cause, not the root cause. We
> have to ask: what causes buggy releases?

Well, I'd first ask, which parts of frameworks are buggy in 5.67? Which are 
the affected frameworks? If we're talking about a couple in a set of 80, I'd 
first ask what those have in common that the others don't?

I'd look at all that before blaming and overhauling the release model of KF 
which served us well for the past years.

Sorry if there are obvious answers to the questions above, again, I just 
stepped in. ;-)

Regards.
-- 
Kevin Ottens, http://ervin.ipsquad.net

enioka Haute Couture - proud patron of KDE, https://hc.enioka.com/en

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

D27355: POC: Make kstatusnotifieritem available without dbus

[Johnny Jazeix]

jjazeix added a comment.


  thank you!
  I did the same but way worse.
  I think we can at least push this fix to remove all failing jobs then clean 
it up?

INLINE COMMENTS

> CMakeLists.txt:94
>  if (NOT WIN32 AND NOT ANDROID)
>  find_package(Qt5 ${REQUIRED_QT_VERSION} CONFIG REQUIRED DBus)
>  find_package(Canberra)

this is not the aim of this diff, but I looked at the code, I found this line 
was duplicated from line 43

REPOSITORY
  R289 KNotifications

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

To: vonreth, bcooksley, jjazeix
Cc: kde-frameworks-devel, LeGast00n, cblack, GB_2, michaelh, ngraham, bruns

Re: 2 kirigami fixes for a point release

[Ben Cooksley]

On Thu, Feb 13, 2020 at 10:00 AM Nate Graham  wrote:
>
> [+ frameworks and plasma mailing lists]
>
>
> On 2020-02-12 11:31, Albert Astals Cid wrote:
> > El dimecres, 12 de febrer de 2020, a les 15:37:09 CET, Nate Graham va 
> > escriure:
> >> Personally I think it would be nice to have
> >> 86f988434cd657e77cc9429e78f7290ce6b5713d since otherwise LTS Plasma
> >> users will be hitting it for the next few years.
> >>
> >> ---
> >>
> >> On another note, I have to admit I'm starting to doubt how well our LTS
> >> Plasma product works without a corresponding LTS frameworks release to
> >> support it. We can fix bugs in software that uses the Plasma release
> >> schedule till the cows come home, but if the bug is in Frameworks, users
> >> are stuck with it forever since LTS distros don't typically ship new
> >> Frameworks releases.
> >>
> >> Yes yes, they should, and all that--but they don't.
> >>
> >> It seems like we either need to:
> >> - Work on convincing these distros to ship Frameworks versions in a
> >> rolling manner to their LTS users

Can we please have a list of the offending distributions?

> >> - Provide an LTS Frameworks product that can receive bugfixes and get
> >> point releases, to support the Plasma LTS product
> >> - Stop misleadingly offering a Plasma LTS product, since everything in
> >> it that comes from Frameworks isn't actually LTS
> >
> > This should not matter, Plasma LTS is built on *lots* of other libraries 
> > that are not LTS either.
> >
> > If it matters is because the quality of KF5 releases are not good, that's 
> > what should be fixed IMHO.
>
> Yes, the Frameworks 5.67 release was indeed was quite buggy and
> regression-filled from a Plasma perspective :(

Looking at the respin requests I see the following Frameworks as being
problematic:

- Kirigami
- QQC2 Desktop Style

This is only a small number of Frameworks.

>
> However buggy releases are the proximate cause, not the root cause. We
> have to ask: what causes buggy releases?

Part of the issue here is that Plasma has been known to add API to
Frameworks and then immediately, without any delay, start using it
(pretty much always breaking CI in the process)

This means that other changes are likely being pushed into Frameworks
by Plasma with very little delay as well.

Consequently this means stuff is landing in Framework repositories up
to the very moment it is released - a release that the next version of
Plasma (LTS) then depends on.

A better way of approaching this would be to freeze the Frameworks
version you are going to require API wise at an earlier point in the
Plasma development cycle. This would allow for a full Frameworks
release cycle to pass where bugs encountered during the lead up to the
Plasma release can be fixed.

This version of Frameworks would then be the one that Plasma hard depends on.

>
> I would argue that bugginess is baked into the Frameworks product by
> virtue of its very fast one-month release cycle and lack of beta
> periods, as there are for apps and Plasma. No matter how diligent patch
> review is, regressions always sneak in; that's why QA and beta-testing
> exist.
>
> However because Frameworks has no explicit beta period, the only people
> performing QA are those who live on master all the time. The amount of
> time for these people to catch regressions can be as short as one day,
> for changes committed right before tagging. Even for commits at the very
> beginning of a Frameworks release cycle, there will be a maximum of one
> month before they ship to users. There simply isn't enough time to
> provide adequate QA for Frameworks releases, and the pool of people
> doing it is too small.
>

Changes with the potential to have an impact like that shouldn't be
going in a day or two before the tagging/release.

> Making users be the QA is mostly okay for rolling release distros whose
> users are willing to take on that role: regressions get found and fixed
> in the next version and users receive the fixes in one month. But this
> model breaks down for LTS release distros that freeze on a specific
> frameworks version. If the version they've frozen on is buggy, that's
> it. It's buggy forever, unless their we make point releases or their
> already overworked packagers go out of the way to search for and
> backport fixes.
>
> The Frameworks release model just doesn't fit for discrete release
> distros, especially for the LTS releases. Sometimes it works out better
> than other times, but it is a fundamental incompatibility when the
> product wants customers to ship new releases continuously, but the
> customers want the product frozen to one version with only safe bugfixes
> shipped after that.
>
> Personally I think a lengthier release cycle and discrete beta periods
> would really help Frameworks, even in the absence of interest in
> creating a product more aligned to our LTS-using customers.
>
> Nate

Regards,
Ben

Re: 2 kirigami fixes for a point release

[Kai Uwe Broulik]

Hi,

> We have to ask: what causes buggy releases?

People rushing things in at the last minute, even better if unreviewed. 
Plasma 5.18 was a prime example of this. Every single time there's drama 
on Beta tagging day for some last minute change that should go in. To 
remedy this I wanted Beta feature freeze to be super strict, and even 
had release people do a "soft feature freeze" even before that.


To minimize potential Frameworks dependency problems I would even go as 
far as put Feature freeze on same date as Frameworks tagging date so 
that no new stuff goes in that could require a Framework change, like 
the wallpaper JPG vs PNG situation.


But did people care about all of this? Nope. We had a wallpaper contest 
that was explicitly scheduled to go in even after the Beta. This is 
unacceptable and next time we do this I will flat out revert a wallpaper 
change after the beta.


Next is this pointless scroll bar visual change. Why did that have to go 
in a day before the Beta, and - surprise - cause problems all over the 
stack which require a bunch of Frameworks fixes?


Another topic was the KUserFeedback KCM. There had been substantial 
changes also on release date and this is a feature that must be spot-on 
and work 120% from day one. The KNewStuffQuick stuff was a substantial 
change even after Beta freeze...


I think you're getting the picture. The problem isn't the release cycle 
of Frameworks, it's a lack of discipline, and I'm quite sad about that.


Cheers
Kai Uwe