KDE CI: Frameworks » kunitconversion » kf5-qt5 FreeBSDQt5.13 - Build # 4 - Fixed!

[CI System]

BUILD SUCCESS
 Build URL
https://build.kde.org/job/Frameworks/job/kunitconversion/job/kf5-qt5%20FreeBSDQt5.13/4/
 Project:
kf5-qt5 FreeBSDQt5.13
 Date of build:
Wed, 17 Jul 2019 02:04:05 +
 Build duration:
2 hr 15 min and counting
   JUnit Tests
  Name: projectroot Failed: 0 test(s), Passed: 3 test(s), Skipped: 0 test(s), Total: 3 test(s)

D20181: Add Binary Data units (bits, kilobytes, kibibytes ... yottabytes)

[Nathaniel Graham]

ngraham added a comment.


  Very nice first patch, too. May it be the first of many! :)

REPOSITORY
  R292 KUnitConversion

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

To: JJRcop, broulik, #plasma, ngraham
Cc: abetts, cfeck, apol, aacid, ngraham, kde-frameworks-devel, LeGast00n, 
sbergeron, michaelh, bruns

D20181: Add Binary Data units (bits, kilobytes, kibibytes ... yottabytes)

[Nathaniel Graham]

This revision was automatically updated to reflect the committed changes.
Closed by commit R292:6c193856f9f4: Add Binary Data units (bits, kilobytes, 
kibibytes ... yottabytes) (authored by JJRcop, committed by ngraham).

REPOSITORY
  R292 KUnitConversion

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D20181?vs=61883&id=61886

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

AFFECTED FILES
  README.md
  src/CMakeLists.txt
  src/binary_data.cpp
  src/binary_data_p.h
  src/converter.cpp
  src/unit.h

To: JJRcop, broulik, #plasma, ngraham
Cc: abetts, cfeck, apol, aacid, ngraham, kde-frameworks-devel, LeGast00n, 
sbergeron, michaelh, bruns

D20181: Add Binary Data units (bits, kilobytes, kibibytes ... yottabytes)

[Nathaniel Graham]

ngraham accepted this revision.
ngraham added a comment.


  Thanks for your patience here!

REPOSITORY
  R292 KUnitConversion

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

To: JJRcop, broulik, #plasma, ngraham
Cc: abetts, cfeck, apol, aacid, ngraham, kde-frameworks-devel, LeGast00n, 
sbergeron, michaelh, bruns

D20181: Add Binary Data units (bits, kilobytes, kibibytes ... yottabytes)

[Nathaniel Graham]

ngraham edited the summary of this revision.

REPOSITORY
  R292 KUnitConversion

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

To: JJRcop, broulik, #plasma, ngraham
Cc: abetts, cfeck, apol, aacid, ngraham, kde-frameworks-devel, LeGast00n, 
sbergeron, michaelh, bruns

Re: New framework: KCalCore

[Aleix Pol]

On Tue, Jul 16, 2019 at 6:10 PM Volker Krause  wrote:
>
> On Monday, 15 July 2019 18:43:42 CEST Aleix Pol wrote:
> > On Fri, Jul 12, 2019 at 9:03 PM Allen Winter  wrote:
> > > On Friday, July 12, 2019 12:23:58 PM EDT Volker Krause wrote:
> > > > With the 19.08 release approaching (and thus the deadline for
> > > > incompatible
> > > > changes if we go ahead with this plan), I'd like to raise this again for
> > > > getting to a decision :)
> > > >
> > > > Summary of what happened in the past weeks:
> > > > - the Person/Attendee slicing issue was fixed by making both independent
> > > > types - several "leaf" types were turned into implicitly shared value
> > > > types rather than being used heap-allocated inside shared pointers
> > > > - the dependency on the Akonadi supertrait.h header file was removed
> > > > - the virtual_hook usage in the incidence de/serialization code was
> > > > replaced by new virtual methods
> > > >
> > > > Unless I missed something, the remaining unaddressed feedback is down
> > > > to:
> > > > - Rename KCalCore to something else. I'm ok with executing the rename,
> > > > but
> > > > somebody needs to tell me the new name :)
> > >
> > > I don't remember the reason for changing the name.
> > > I vote for not changing the name. KCalCore is as good as any, imo
> > >
> > > > - Alexander P's fundamental objections to the current KCalCore API
> > > >
> > > > How do we proceed?
> > > >
> > > > Thanks,
> > > > Volker
> > > >
> > > > On Sunday, 7 April 2019 14:45:09 CEST Volker Krause wrote:
> > > > > Hi,
> > > > >
> > > > > I'd like to propose KCalCore for review to move from KDE PIM to KF5.
> > > > >
> > > > > KCalCore is an implementation of the iCalendar standard based on
> > > > > libical,
> > > > > covering the data model, input/output and the rather complex
> > > > > recurrence
> > > > > algorithms defined in that standard. It's used outside of KDE PIM as
> > > > > well,
> > > > > e.g. by Zanshin or the Plasma Mobile calendar app.
> > > > >
> > > > > KCalCore depends on Qt and libical only, making it a Tier 1 functional
> > > > > framework.
> > > > >
> > > > > KCalCore used to be part of part of kdepimlibs in the KDE4 era, so
> > > > > it's well prepared for complying with the API and ABI guarantees.
> > > > >
> > > > > I'd suggest the same timeline as proposed for KContacts [1]. During
> > > > > the PIM
> > > > > sprint we did a number of fixes and cleanups as part of the review for
> > > > > KF5
> > > > > that make 19.08 the earliest release after which we can switch as
> > > > > well, so
> > > > > we are looking at a switch in Sep/Oct this year.
> >
> > If you don't remember, just scroll up a bit. :P
> >
> > I went through the thread and that's what we said:
> > - It's a framework to understand the ical format, this is not conveyed
> > by the current name
> > - The Core postfix doesn't add anything and we are already using it
> > for differentiating different framework targets (e.g. KF5::ConfigCore
> > and KF5::ConfigGui)
>
> "Core" had exactly the same meaning here when the widget parts were split out
> during the Nokia times. Less relevant today probably.
>
> > I see KCal, KCalendar, KiCalendar, KiCal, KCalendarEvents,
> > KCalendarIncidences being suggested. It's not going to be me who
> > chooses one though.
>
> If those are the options I'd vote for KCal or KCalendar, KiCal is too close to
> KiCad IMHO, and the rest is just unnecessarily long. Anyway, let's please have
> a quick decision on this, it's going to be a large change, so I'd like to get
> this in ASAP.
>
> Thanks,
> Volker

I tend to agree. If so I'd suggest KCalendar. Following KContacts
(which should possibly be KVCards, but we assume vcards are the one
and only format ever for contacts).

Aleix

D20181: Add Binary Data units (bits, kilobytes, kibibytes ... yottabytes)

[Jonathan Rubenstein]

JJRcop updated this revision to Diff 61883.
JJRcop added a comment.


  Updated @since to 5.61. @ngraham

REPOSITORY
  R292 KUnitConversion

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D20181?vs=61526&id=61883

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

AFFECTED FILES
  README.md
  src/CMakeLists.txt
  src/binary_data.cpp
  src/binary_data_p.h
  src/converter.cpp
  src/unit.h

To: JJRcop, broulik, #plasma, ngraham
Cc: abetts, cfeck, apol, aacid, ngraham, kde-frameworks-devel, LeGast00n, 
sbergeron, michaelh, bruns

D19986: Install .desktop file for kded5

[René J . V . Bertin]

rjvbb added a comment.


  It seems to me there's a way to tell the translators that a string shouldn't 
be translated. Why not use that, or put a name that doesn't require translation 
(like `name=kded5.desktop`)?
  
  NB: I replaced "SystemService" with "Service" in my copy, and haven't seen 
that other warning at all.

REPOSITORY
  R297 KDED

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

To: davidedmundson, ivan
Cc: rjvbb, dfaure, kde-frameworks-devel, LeGast00n, sbergeron, michaelh, 
ngraham, bruns

D16882: [KDevelop/Shell] prevent duplicate added contextmenu actions

[Friedrich W. H. Kossebau]

kossebau added a comment.


  In D16882#494867 , @rjvbb wrote:
  
  > I could try your solution, of course, but what annoys me is that it comes 
months after I worked on mine.
  
  
  I think we all share the feeling that this should have already been handled 
the first time completely to end and now be a thing of the past, given we all 
once spent time on it before and would prefer not to have spent more :)
  
  > It would help if you had a specific critique on my solution other than "it 
doesn't use this or that signal" (or, what I kind of sense, "it comes from 
you").
  
  I made some respective comment in D22424#494708 
 while you asked.
  
  To emphasize once more, I was about to give your proposed patch a go as it 
worked by what I tested, but trying to understand the problem fixed with this 
patch with proper depth to give you a proper review, I played around and then 
found that the approach one would have done initially (as everyone seems to 
have tried) still might work out, if one simply connects to the abouttohide 
signal of the currently passed context menu, instead of assuming a static one 
per view. The current clean-only-on-next-show code always has felt rather messy 
to me. And so I simply proposed what arose by accident from my experiments 
around the phenomenon as an alternative solution, to compare & perhaps inspire 
for more elegant solution.
  
  > No disrespect intended, but your description in D22424 
 isn't that easy to read either (it felt 
like reading German, for some inexplicable reason ;) ).
  
  Yes, rereading I see how this was rather a memory dump trying to still get 
something written after having spent some hours on it, before falling into the 
bed. Will see to update a bit.
  
  > You claim that
  > 
  >> For some yet to explore internal reason, if there is a plugin with a
  >>  "ktexteditor_popup" menu to merge in, then the QMenu object instance is 
the
  >>  same across all KTextEditor::View instances, otherwise each view has its
  >>  own.
  > 
  > but I have never seen any proof that the context QMenu instance is ever NOT 
the same. On the contrary, it makes perfect sense that it is always the same 
because there can only be a single context menu.
  
  I saw this from all the debug output I had added, comparing pointers of the 
context menu object handed in. Ideally indeed I would have also spent more time 
in kxmlgui code to find the code culprit for this to reason why this happens, 
but my test log showed consistent results for the different settings (ctags 
plugin enabled, not enabled)., so I stayed with just the observed behaviour 
from that black box kxmlgui, as it showed what cases one has to deal with in 
released versions of kxmlgui.
  
  > I'm not saying we shouldn't rely on the aboutToHide signal if this signal 
can indeed be relied on. But it would be good to do things properly and get to 
the bottom of the shared-or-not context QMenu instance question. It looks like 
your new `QPointer` is an acknowledgement to the fact that it can at 
least be a unique instance; if it always is it could (and maybe should) be 
moved to a central, shared structure and accessed from there.
  
  The idea behind the `QPointer` member is rather to be able to have 
access to any last added-to context menu to remove any persistent actions from 
it (those not created on-the-fly but owned by plugins and only shared for the 
context menu), in the very case any action triggered from the context menu 
results in the deletion of the textdocument object while the menu is still open
  
  > Maybe the KTextEditor framework should simply provide a method to get a 
pointer to the current context menu?!
  
  The problem is at least that the API of KTextEditor::View allows to set a 
custom menu per view instance. If we go with the assumption that only one 
context menu can be active globally at the same time (which might be true in 
case of popup menus at least), KTextEditor could perhaps help and track this 
internally and expose access.
  For our use-case though reliable "abouttoshow" & "abouttohide" signals (with 
ktexteditor ensuring reliability by all means) might be more helpful, so we do 
not have to do all the extra tracking work on our side.

REPOSITORY
  R32 KDevelop

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

To: rjvbb, #kdevelop, kossebau, mwolff
Cc: mwolff, egospodinova, kossebau, kde-frameworks-devel, kdevelop-devel, 
hmitonneau, christiant, glebaccon, domson, antismap, iodelay, alexeymin, 
geetamc, Pilzschaf, akshaydeo, surgenight, arrowd

D20181: Add Binary Data units (bits, kilobytes, kibibytes ... yottabytes)

[Albert Astals Cid]

aacid added a comment.


  Ok, you will need  to update your @since when landing this

REPOSITORY
  R292 KUnitConversion

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

To: JJRcop, broulik, #plasma, ngraham
Cc: abetts, cfeck, apol, aacid, ngraham, kde-frameworks-devel, LeGast00n, 
sbergeron, michaelh, bruns

D21002: Remove kde4 migration agent completely

[Albert Astals Cid]

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


  i guess 🤷

REPOSITORY
  R311 KWallet

BRANCH
  master

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

To: bruns, #frameworks, cfeck, ngraham, aacid
Cc: aacid, lbeltrame, kde-frameworks-devel, damjang, LeGast00n, sbergeron, 
michaelh, ngraham, bruns

D19986: Install .desktop file for kded5

[David Edmundson]

davidedmundson added a comment.


  Sorry, I missed your message.

INLINE COMMENTS

> dfaure wrote in org.kde.kded5.desktop:4
> What does SystemService mean?
> 
> I'm seeing a warning from the kservice framework:
> The desktop entry file "/share/applications/org.kde.kded5.desktop"  
> has Type= "SystemService"  instead of "Application" or "Service".
> 
> Would it be ok to use Service instead, or does SystemService have a special 
> meaning on wayland?

> Would it be ok to use Service instead, or does SystemService have a special 
> meaning on wayland?

From the POV of the bug we're fixing, sure.
SystemService means nothing, it's an invalid type.

The reason I used an invalid type is to suppress a different warning about not 
having a name/comment, and I didn't want to make translators do any work for 
something that is never shown.

REPOSITORY
  R297 KDED

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

To: davidedmundson, ivan
Cc: rjvbb, dfaure, kde-frameworks-devel, LeGast00n, sbergeron, michaelh, 
ngraham, bruns

D22477: With auto completion don't show completions that don't match from beginning of typed word

[Sven Brauch]

brauch added a comment.


  Also here, looks good to me, but I would wait for feedback from somebody else 
in addition. Thank you for working on this!

REPOSITORY
  R39 KTextEditor

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

To: ahmadsamir, #ktexteditor, cullmann, dhaumann, #kdevelop, kossebau, mwolff, 
kfunk
Cc: brauch, kwrite-devel, kde-frameworks-devel, LeGast00n, sbergeron, domson, 
michaelh, ngraham, bruns, demsking, cullmann, sars, dhaumann

D22477: With auto completion don't show completions that don't match from beginning of typed word

[Sven Brauch]

brauch added inline comments.

INLINE COMMENTS

> brauch wrote in katecompletionmodel.cpp:2029
> Maybe you want to set the flag here too?

Actually no, probably not. ;)

REPOSITORY
  R39 KTextEditor

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

To: ahmadsamir, #ktexteditor, cullmann, dhaumann, #kdevelop, kossebau, mwolff, 
kfunk
Cc: brauch, kwrite-devel, kde-frameworks-devel, LeGast00n, sbergeron, domson, 
michaelh, ngraham, bruns, demsking, cullmann, sars, dhaumann

D22477: With auto completion don't show completions that don't match from beginning of typed word

[Sven Brauch]

brauch added inline comments.

INLINE COMMENTS

> katecompletionmodel.cpp:2029
>  if (matchesAbbreviation(m_nameColumn, match, 
> model->matchCaseSensitivity())) {
>  matchCompletion = AbbreviationMatch;
>  }

Maybe you want to set the flag here too?

REPOSITORY
  R39 KTextEditor

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

To: ahmadsamir, #ktexteditor, cullmann, dhaumann, #kdevelop, kossebau, mwolff, 
kfunk
Cc: brauch, kwrite-devel, kde-frameworks-devel, LeGast00n, sbergeron, domson, 
michaelh, ngraham, bruns, demsking, cullmann, sars, dhaumann

D22488: invoke QIcon::setFallbackThemeName a bit later

[Albert Astals Cid]

aacid added a comment.


  I don't think this is going to work.
  
  Who is going to create a KIconTheme when running Okular on gnome shell?
  
  From what i can see we do create one in okular/part.cpp:386 because we happen 
to call KParts::Part::iconLoader() there, but that's too late, there has been 
already 4 calls to QIcon::fromTheme at that stage.

REPOSITORY
  R302 KIconThemes

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

To: mart, #frameworks, #plasma
Cc: aacid, mlaurent, broulik, kde-frameworks-devel, LeGast00n, sbergeron, 
michaelh, ngraham, bruns

Re: kdewebkit tarball gone missing?!

[Albert Astals Cid]

El dimarts, 16 de juliol de 2019, a les 19:30:52 CEST, René J.V. Bertin va 
escriure:
> Hi,
> 
> A few days ago I downloaded the 5.60.0 kdewebkit tarball from its usual 
> location on downloads.kde.org (= among the other FW tarballs), today it 
> appears to be gone?
> 
> Has it moved or is this an error?

Moved

https://download.kde.org/stable/frameworks/5.60/portingAids/

Cheers,
  Albert

> 
> Thanks,
> R.
> 

D22500: Make keyword completion model return HideListIfAutomaticInvocation by default

[Sven Brauch]

brauch added a comment.


  Independent of anything else I think this is a very sensible change, and 
seems like an oversight / bug.
  
  One of the more core kate guys should approve, but +1 from me.

REPOSITORY
  R39 KTextEditor

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

To: ahmadsamir, #ktexteditor, #kdevelop, cullmann, dhaumann, brauch
Cc: kde-frameworks-devel, kwrite-devel, LeGast00n, sbergeron, domson, michaelh, 
ngraham, bruns, demsking, cullmann, sars, dhaumann

D22477: With auto completion don't show completions that don't match from beginning of typed word

[Ahmad Samir]

ahmadsamir added a comment.


  In D22477#496214 , @brauch wrote:
  
  > I'm not sure if this solves the right problem.
  >
  > Where I notice this issue a lot is when typing "return". The keyword 
completion suggests "return", and when I want a newline, I complete the 
"return" first. This doesn't affect C++ (because of the trailing ";"), but it 
does affect other languages.
  >
  > I think this is pretty much the same issue. Maybe it should be solved by 
hiding the completion window if it was not explicitly invoked if there is any 
entry matching what you currently typed?
  >
  > Then typing Foo would not have the completion window open at all in the 
described case (thus solving your problem, as well as mine), and if you still 
wanted to complete BarFoo, you would press Ctrl+Space.
  
  
  
  
  In D22477#496214 , @brauch wrote:
  
  > I'm not sure if this solves the right problem.
  >
  > Where I notice this issue a lot is when typing "return". The keyword 
completion suggests "return", and when I want a newline, I complete the 
"return" first. This doesn't affect C++ (because of the trailing ";"), but it 
does affect other languages.
  >
  > I think this is pretty much the same issue. Maybe it should be solved by 
hiding the completion window if it was not explicitly invoked if there is any 
entry matching what you currently typed?
  
  
  Great idea. Done.
  
  > Then typing Foo would not have the completion window open at all in the 
described case (thus solving your problem, as well as mine), and if you still 
wanted to complete BarFoo, you would press Ctrl+Space.
  
  https://phabricator.kde.org/D22500

REPOSITORY
  R39 KTextEditor

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

To: ahmadsamir, #ktexteditor, cullmann, dhaumann, #kdevelop, kossebau, mwolff, 
kfunk
Cc: brauch, kwrite-devel, kde-frameworks-devel, LeGast00n, sbergeron, domson, 
michaelh, ngraham, bruns, demsking, cullmann, sars, dhaumann

D22477: With auto completion don't show completions that don't match from beginning of typed word

[Ahmad Samir]

ahmadsamir updated this revision to Diff 61882.
ahmadsamir edited the summary of this revision.
ahmadsamir added a comment.


  Take 2

REPOSITORY
  R39 KTextEditor

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D22477?vs=61881&id=61882

BRANCH
  less-trigger-happy-completions (branched from master)

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

AFFECTED FILES
  src/completion/katecompletionmodel.cpp
  src/completion/katecompletionmodel.h

To: ahmadsamir, #ktexteditor, cullmann, dhaumann, #kdevelop, kossebau, mwolff, 
kfunk
Cc: brauch, kwrite-devel, kde-frameworks-devel, LeGast00n, sbergeron, domson, 
michaelh, ngraham, bruns, demsking, cullmann, sars, dhaumann

D22477: With auto completion don't show completions that don't match from beginning of typed word

[Ahmad Samir]

ahmadsamir updated this revision to Diff 61881.
ahmadsamir retitled this revision from "Add a config to only show completions 
matching word beginning" to "With auto completion don't show completions that 
don't match from beginning of typed word".
ahmadsamir edited the summary of this revision.
ahmadsamir edited the test plan for this revision.
ahmadsamir added a comment.


  Ver-bloody-batim

REPOSITORY
  R39 KTextEditor

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D22477?vs=61879&id=61881

BRANCH
  less-trigger-happy-completions (branched from master)

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

AFFECTED FILES
  src/completion/katecompletionmodel.cpp
  src/completion/katecompletionmodel.h

To: ahmadsamir, #ktexteditor, cullmann, dhaumann, #kdevelop, kossebau, mwolff, 
kfunk
Cc: brauch, kwrite-devel, kde-frameworks-devel, LeGast00n, sbergeron, domson, 
michaelh, ngraham, bruns, demsking, cullmann, sars, dhaumann

D22500: Make keyword completion model return HideListIfAutomaticInvocation by default

[Ahmad Samir]

ahmadsamir created this revision.
ahmadsamir added reviewers: KTextEditor, KDevelop, cullmann, dhaumann, brauch.
Herald added projects: Kate, Frameworks.
ahmadsamir requested review of this revision.

REVISION SUMMARY
  Change KateKeywordCompletionModel::matchingItem to return
  HideListIfAutomaticInvocation so that the completions menu is hidden for
  typed keywords, e.g. typing "return" the menu get auto hidden.

TEST PLAN
  - Enable keyword completion in kate
  - Open a file and change the mode to a language where return is a keyword say 
C++
  - Type "return", check that when the word is fully typed the completions menu 
is hidden

REPOSITORY
  R39 KTextEditor

BRANCH
  ahmad/keyword-auto-completion (branched from master)

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

AFFECTED FILES
  src/completion/katekeywordcompletion.cpp

To: ahmadsamir, #ktexteditor, #kdevelop, cullmann, dhaumann, brauch
Cc: kde-frameworks-devel, kwrite-devel, LeGast00n, sbergeron, domson, michaelh, 
ngraham, bruns, demsking, cullmann, sars, dhaumann

D22477: Add a config to only show completions matching word beginning

[Ahmad Samir]

ahmadsamir updated this revision to Diff 61879.
ahmadsamir added a comment.


  Change the diff altogether to not show the menu with "ContainsMatch"

REPOSITORY
  R39 KTextEditor

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D22477?vs=61807&id=61879

BRANCH
  less-trigger-happy-completions (branched from master)

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

AFFECTED FILES
  src/completion/katecompletionmodel.cpp
  src/completion/katecompletionmodel.h

To: ahmadsamir, #ktexteditor, cullmann, dhaumann, #kdevelop, kossebau, mwolff, 
kfunk
Cc: brauch, kwrite-devel, kde-frameworks-devel, LeGast00n, sbergeron, domson, 
michaelh, ngraham, bruns, demsking, cullmann, sars, dhaumann

D19986: Install .desktop file for kded5

[René J . V . Bertin]

rjvbb added inline comments.

INLINE COMMENTS

> dfaure wrote in org.kde.kded5.desktop:4
> What does SystemService mean?
> 
> I'm seeing a warning from the kservice framework:
> The desktop entry file "/share/applications/org.kde.kded5.desktop"  
> has Type= "SystemService"  instead of "Application" or "Service".
> 
> Would it be ok to use Service instead, or does SystemService have a special 
> meaning on wayland?

I'm seeing this too whenever I start an application (from a commandline) after 
installing something and before the automatic kbuildsycoca5 invocation had a 
chance to occur.

Not very happy about that...

REPOSITORY
  R297 KDED

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

To: davidedmundson, ivan
Cc: rjvbb, dfaure, kde-frameworks-devel, LeGast00n, sbergeron, michaelh, 
ngraham, bruns

D22083: introduce concept of header and footer for kpageview

[Nathaniel Graham]

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


  Lovely. Looks perfect in Dolphin, Kate, Konsole, Okular, Gwenview, and Kile.
  
  Ark and Spectacle also need to be adapted, like kcmshell. Anything not using 
KPageView properly will need some adjustment, I guess. It's probably good that 
we're doing this because it provides a good opportunity to fix them and unify 
things.

REPOSITORY
  R236 KWidgetsAddons

BRANCH
  mart/pageviewfooter

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

To: mart, #plasma, #frameworks, #vdg, ngraham
Cc: hpereiradacosta, cfeck, ndavis, ngraham, kde-frameworks-devel, LeGast00n, 
sbergeron, michaelh, bruns

D21672: [PowerStateMonitor] Be conservative when determining power state

[Nathaniel Graham]

ngraham added a comment.


  > Let's not argue but investigate and fix why this seemingly innocent patch 
caused the behavior described.

REPOSITORY
  R293 Baloo

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

To: bruns, #baloo, ngraham, astippich, poboiko
Cc: broulik, romangg, kde-frameworks-devel, #baloo, LeGast00n, sbergeron, 
fbampaloukas, domson, ashaposhnikov, michaelh, astippich, spoorun, ngraham, 
bruns, abrahams

D22488: invoke QIcon::setFallbackThemeName a bit later

[Nathaniel Graham]

ngraham edited the summary of this revision.

REPOSITORY
  R302 KIconThemes

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

To: mart, #frameworks, #plasma
Cc: mlaurent, broulik, kde-frameworks-devel, LeGast00n, sbergeron, michaelh, 
ngraham, bruns

kdewebkit tarball gone missing?!

[René J . V . Bertin]

Hi,

A few days ago I downloaded the 5.60.0 kdewebkit tarball from its usual 
location on downloads.kde.org (= among the other FW tarballs), today it appears 
to be gone?

Has it moved or is this an error?

Thanks,
R.

Re: New framework: KContacts

[Volker Krause]

On Saturday, 6 April 2019 18:01:09 CEST Volker Krause wrote:
> Hi,
> 
> I'd like to propose KContacts for review to move from KDE PIM to KF5.
> 
> KContacts is essentially an implementation of the vCard standard, covering
> the data model as well as parsing and creating of vCard files. As the
> recent CI issue showed it's used outside of KDE PIM as well, therefore we
> would particularly benefit from the KF5 stability guarantees.
> 
> KContacts depends on KConfig, KCodecs, KCoreAddons and KI18n, making it a
> Tier 2 functional framework.
> 
> KContacts used to be part of kdelibs during the 2 and 3 era under the name
> "kabc", and part of kdepimlibs in the 4 era, so it's very well prepared for
> complying with the API and ABI guarantees.
> 
> To have a smooth as possible transition the proposed timeline would be:
> - complete the review and possibly required adjustments before the 19.08
> freeze
> - do one final release as part of KDE PIM with 19.08, with the final ABI and
> library name for KF5
> - after 19.08 (so Sep or Oct 2019), release it with KF5, which will then be
> a drop-in replacement for the KDE PIM release.
> 
> This approach has already successfully been used for KHolidays and
> Syndication.
> 
> We did a review at the currently ongoing PIM sprint, which resulted in
> removal of some ancient unused cruft (D20270, D20273, D20274, D20275,
> D20276) which did technically change the ABI, therefore the transition
> after 19.08 rather than 19.04.

With the 19.08 deadline approaching I'd also like to raise this again for a 
decision :)

I'm not aware of any unaddressed feedback, main changes in the meantime:
- a number of duplicated or string-based code in applications using this was 
upstreamed into KContacts with proper API
- several types got Q_GADGET/Q_PROPERTY annotations for direct use in QML or 
Grantlee (now used directly by KAddressBook's display and printing code)
- custom fields for messaging addresses are now converted to standard Impp 
fields, improving e.g. compatibility with Nextcloud and removing error-prone 
application code

Thanks,
Volker



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

Re: New framework: KCalCore

[Volker Krause]

On Monday, 15 July 2019 18:43:42 CEST Aleix Pol wrote:
> On Fri, Jul 12, 2019 at 9:03 PM Allen Winter  wrote:
> > On Friday, July 12, 2019 12:23:58 PM EDT Volker Krause wrote:
> > > With the 19.08 release approaching (and thus the deadline for
> > > incompatible
> > > changes if we go ahead with this plan), I'd like to raise this again for
> > > getting to a decision :)
> > > 
> > > Summary of what happened in the past weeks:
> > > - the Person/Attendee slicing issue was fixed by making both independent
> > > types - several "leaf" types were turned into implicitly shared value
> > > types rather than being used heap-allocated inside shared pointers
> > > - the dependency on the Akonadi supertrait.h header file was removed
> > > - the virtual_hook usage in the incidence de/serialization code was
> > > replaced by new virtual methods
> > > 
> > > Unless I missed something, the remaining unaddressed feedback is down
> > > to:
> > > - Rename KCalCore to something else. I'm ok with executing the rename,
> > > but
> > > somebody needs to tell me the new name :)
> > 
> > I don't remember the reason for changing the name.
> > I vote for not changing the name. KCalCore is as good as any, imo
> > 
> > > - Alexander P's fundamental objections to the current KCalCore API
> > > 
> > > How do we proceed?
> > > 
> > > Thanks,
> > > Volker
> > > 
> > > On Sunday, 7 April 2019 14:45:09 CEST Volker Krause wrote:
> > > > Hi,
> > > > 
> > > > I'd like to propose KCalCore for review to move from KDE PIM to KF5.
> > > > 
> > > > KCalCore is an implementation of the iCalendar standard based on
> > > > libical,
> > > > covering the data model, input/output and the rather complex
> > > > recurrence
> > > > algorithms defined in that standard. It's used outside of KDE PIM as
> > > > well,
> > > > e.g. by Zanshin or the Plasma Mobile calendar app.
> > > > 
> > > > KCalCore depends on Qt and libical only, making it a Tier 1 functional
> > > > framework.
> > > > 
> > > > KCalCore used to be part of part of kdepimlibs in the KDE4 era, so
> > > > it's well prepared for complying with the API and ABI guarantees.
> > > > 
> > > > I'd suggest the same timeline as proposed for KContacts [1]. During
> > > > the PIM
> > > > sprint we did a number of fixes and cleanups as part of the review for
> > > > KF5
> > > > that make 19.08 the earliest release after which we can switch as
> > > > well, so
> > > > we are looking at a switch in Sep/Oct this year.
> 
> If you don't remember, just scroll up a bit. :P
> 
> I went through the thread and that's what we said:
> - It's a framework to understand the ical format, this is not conveyed
> by the current name
> - The Core postfix doesn't add anything and we are already using it
> for differentiating different framework targets (e.g. KF5::ConfigCore
> and KF5::ConfigGui)

"Core" had exactly the same meaning here when the widget parts were split out 
during the Nokia times. Less relevant today probably.

> I see KCal, KCalendar, KiCalendar, KiCal, KCalendarEvents,
> KCalendarIncidences being suggested. It's not going to be me who
> chooses one though. 

If those are the options I'd vote for KCal or KCalendar, KiCal is too close to 
KiCad IMHO, and the rest is just unnecessarily long. Anyway, let's please have 
a quick decision on this, it's going to be a large change, so I'd like to get 
this in ASAP.

Thanks,
Volker

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

D22144: Add kio recentlyused:/ to access KactivitytStats data

[Nathaniel Graham]

ngraham added a comment.


  So interestingly enough, accessing `recentlyused:/` in Dolphin's URL 
navigator works great, but doing `recentlyused:/?limit=100` causes it to crash 
on an assert:
  
$ dolphin
org.kde.kactivities.lib.core: Setting the title:  ""
ASSERT: "!name.isEmpty()" in file 
/home/nate/kde/src/kio/src/core/kcoredirlister.cpp, line 1209
Aborted (core dumped)
  
  Here's the full backtrace:
  
(gdb) bt
#0  0x77972755 in raise () from /usr/lib/libc.so.6
#1  0x7795d851 in abort () from /usr/lib/libc.so.6
#2  0x74ef08b6 in QMessageLogger::fatal(char const*, ...) const ()
   from /usr/lib/libQt5Core.so.5
#3  0x74eefce2 in qt_assert(char const*, char const*, int) ()
   from /usr/lib/libQt5Core.so.5
#4  0x770fff73 in KCoreDirListerCache::slotEntries (
this=0x771c2c80 <(anonymous 
namespace)::Q_QGS_kDirListerCache::innerFunction()::holder>, 
job=0x55d5f300, entries=...)
at /home/nate/kde/src/kio/src/core/kcoredirlister.cpp:1209
#5  0x7711ee53 in QtPrivate::FunctorCall, QtPrivate::List const&>, void, void 
(KCoreDirListerCache::*)(KIO::Job*, QList const&)>::call (f=
(void (KCoreDirListerCache::*)(KCoreDirListerCache * const, KIO::Job *, 
const QList &)) 0x770ff6cc 
 const&)>, 
o=0x771c2c80 <(anonymous 
namespace)::Q_QGS_kDirListerCache::innerFunction()::holder>, 
arg=0x7fffcd90) at /usr/include/qt/QtCore/qobjectdefs_impl.h:152
#6  0x7711d6c7 in QtPrivate::FunctionPointer 
const&)>::call const&>, void> 
(f=
(void (KCoreDirListerCache::*)(KCoreDirListerCache * const, KIO::Job *, 
const QList &)) 0x770ff6cc 
 const&)>, 
o=0x771c2c80 <(anonymous 
namespace)::Q_QGS_kDirListerCache::innerFunction()::holder>, 
arg=0x7fffcd90) at /usr/include/qt/QtCore/qobjectdefs_impl.h:185
#7  0x7711a752 in QtPrivate::QSlotObject const&), 
QtPrivate::List const&>, void>::impl (which=1, 
this_=0x55d67c30, 
r=0x771c2c80 <(anonymous 
namespace)::Q_QGS_kDirListerCache::innerFunction()::holder>, a=0x7fffcd90, 
ret=0x0) at /usr/include/qt/QtCore/qobjectdefs_impl.h:414
#8  0x75124b70 in QMetaObject::activate(QObject*, int, int, void**) 
()
   from /usr/lib/libQt5Core.so.5
#9  0x770a6670 in KIO::ListJob::entries (this=0x55d5f300, 
_t1=0x55d5f300, _t2=...)
at 
/home/nate/kde/build/kio/src/core/KF5KIOCore_autogen/include/moc_listjob.cpp:237
#10 0x770a520d in KIO::ListJobPrivate::slotListEntries 
(this=0x55b42750, 
list=...) at /home/nate/kde/src/kio/src/core/listjob.cpp:154
#11 0x770a5d6a in KIO::ListJobPrivateoperator()(const KIO::UDSEntryList &) const 
(__closure=0x55d6de80, list=...)
at /home/nate/kde/src/kio/src/core/listjob.cpp:288
#12 0x770a72ca in QtPrivate::FunctorCall, 
QtPrivate::List&>, void, 
KIO::ListJobPrivate::start(KIO::Slave*):: 
>::call(KIO::ListJobPrivate:: &, void **)
(f=..., arg=0x7fffd090) at 
/usr/include/qt/QtCore/qobjectdefs_impl.h:146
#13 0x770a714f in 
QtPrivate::Functor, 1>::call const&>, 
void>(KIO::ListJobPrivate:: &, void *, void **) 
(f=..., 
arg=0x7fffd090) at /usr/include/qt/QtCore/qobjectdefs_impl.h:256

REPOSITORY
  R320 KIO Extras

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

To: meven, ivan, #frameworks, ngraham
Cc: elvisangelaccio, kde-frameworks-devel, kfm-devel, aprcela, fprice, 
LeGast00n, sbergeron, fbampaloukas, alexde, feverfew, meven, michaelh, spoorun, 
navarromorales, firef, ngraham, andrebarros, bruns, emmanuelp, mikesomov

D22144: Add kio recentlyused:/ to access KactivitytStats data

[Nathaniel Graham]

ngraham added a comment.


  Aha, that was the fix that made it work for me! Thanks a bunch. I will 
conduct a more thorough review soon.

REPOSITORY
  R320 KIO Extras

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

To: meven, ivan, #frameworks, ngraham
Cc: elvisangelaccio, kde-frameworks-devel, kfm-devel, aprcela, fprice, 
LeGast00n, sbergeron, fbampaloukas, alexde, feverfew, meven, michaelh, spoorun, 
navarromorales, firef, ngraham, andrebarros, bruns, emmanuelp, mikesomov

D22488: invoke QIcon::setFallbackThemeName a bit later

[Laurent Montel]

mlaurent added a comment.


  will it fix this bug "https://bugs.kde.org/show_bug.cgi?id=407600"; ?

REPOSITORY
  R302 KIconThemes

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

To: mart, #frameworks, #plasma
Cc: mlaurent, broulik, kde-frameworks-devel, LeGast00n, sbergeron, michaelh, 
ngraham, bruns

D22144: Add kio recentlyused:/ to access KactivitytStats data

[Méven Car]

meven added a comment.


  @ngraham I just fixed an issue in the recentlyused.json file, this should 
work much easier.
  
  I encounter some instabilities with kactivitiymanagerd.

REPOSITORY
  R320 KIO Extras

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

To: meven, ivan, #frameworks, ngraham
Cc: elvisangelaccio, kde-frameworks-devel, kfm-devel, aprcela, fprice, 
LeGast00n, sbergeron, fbampaloukas, alexde, feverfew, meven, michaelh, spoorun, 
navarromorales, firef, ngraham, andrebarros, bruns, emmanuelp, mikesomov

D22144: Add kio recentlyused:/ to access KactivitytStats data

[Méven Car]

meven updated this revision to Diff 61860.
meven added a comment.


  Fix json file

REPOSITORY
  R320 KIO Extras

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D22144?vs=60886&id=61860

BRANCH
  arcpatch-D22144

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

AFFECTED FILES
  CMakeLists.txt
  kio-extras.categories
  recentlyused/CMakeLists.txt
  recentlyused/recentlyused.cpp
  recentlyused/recentlyused.h
  recentlyused/recentlyused.json

To: meven, ivan, #frameworks, ngraham
Cc: elvisangelaccio, kde-frameworks-devel, kfm-devel, aprcela, fprice, 
LeGast00n, sbergeron, fbampaloukas, alexde, feverfew, meven, michaelh, spoorun, 
navarromorales, firef, ngraham, andrebarros, bruns, emmanuelp, mikesomov

D22339: Make sure solid backends are reentrant

[Stefan Brüns]

bruns added a comment.


  I would have preferred this to only land when D22333 
 had been addressed fully, I assumed this 
required no further notice.
  
  So from a pure technical view, this indeed seems to be correct, but from an 
architectural view this seems less than ideal (to put it mildly).
  
  One obvious issue is the multiple instantiation and initialization, i.e. when 
the UDisks2 backend is used from different threads each one has to introspect 
udisks itself, which seems wasteful for me.
  
  I will extend this thought in D22333 , 
can we move any further discussion there?

REPOSITORY
  R245 Solid

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

To: apol, #frameworks, davidedmundson, bruns
Cc: lbeltrame, bruns, kde-frameworks-devel, LeGast00n, sbergeron, michaelh, 
ngraham

D22419: Fix cant enter directory error on Android FTP servers

[Albert Astals Cid]

aacid added a comment.


  Why is uppercase only better compatibility if the spec clearly says that case 
doesn't matter ?

REPOSITORY
  R241 KIO

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

To: nxiss7, #frameworks
Cc: aacid, svuorela, kde-frameworks-devel, LeGast00n, sbergeron, michaelh, 
ngraham, bruns

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

[CI System]

BUILD UNSTABLE
 Build URL
https://build.kde.org/job/Frameworks/job/kpackage/job/kf5-qt5%20FreeBSDQt5.13/5/
 Project:
kf5-qt5 FreeBSDQt5.13
 Date of build:
Tue, 16 Jul 2019 11:55:01 +
 Build duration:
1 hr 25 min 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

D22488: invoke QIcon::setFallbackThemeName a bit later

[Marco Martin]

mart updated this revision to Diff 61857.
mart added a comment.


  - nitialize

REPOSITORY
  R302 KIconThemes

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D22488?vs=61855&id=61857

BRANCH
  phab/qqcicons

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

AFFECTED FILES
  src/kicontheme.cpp

To: mart, #frameworks, #plasma
Cc: broulik, kde-frameworks-devel, LeGast00n, sbergeron, michaelh, ngraham, 
bruns

D22488: invoke QIcon::setFallbackThemeName a bit later

[Marco Martin]

mart edited the summary of this revision.

REPOSITORY
  R302 KIconThemes

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

To: mart, #frameworks, #plasma
Cc: broulik, kde-frameworks-devel, LeGast00n, sbergeron, michaelh, ngraham, 
bruns

D22488: invoke QIcon::setFallbackThemeName a bit later

[Marco Martin]

mart marked an inline comment as done.

REPOSITORY
  R302 KIconThemes

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

To: mart, #frameworks, #plasma
Cc: broulik, kde-frameworks-devel, LeGast00n, sbergeron, michaelh, ngraham, 
bruns

D22488: invoke QIcon::setFallbackThemeName a bit later

[Marco Martin]

mart updated this revision to Diff 61855.
mart added a comment.


  - use a local static

REPOSITORY
  R302 KIconThemes

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D22488?vs=61854&id=61855

BRANCH
  phab/qqcicons

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

AFFECTED FILES
  src/kicontheme.cpp

To: mart, #frameworks, #plasma
Cc: broulik, kde-frameworks-devel, LeGast00n, sbergeron, michaelh, ngraham, 
bruns

D22488: invoke QIcon::setFallbackThemeName a bit later

[Kai Uwe Broulik]

broulik added inline comments.

INLINE COMMENTS

> kicontheme.cpp:267
> +#if QT_VERSION >= QT_VERSION_CHECK(5, 12, 0)
> +if (!d->fallbackThemeInitialized) {
> +QIcon::setFallbackThemeName(QStringLiteral("breeze"));

I guess you can just do a

  static s_fallbackThemeInitialized = false;
  if (!s_fallbackThemeInitialized) {
  ...
  }

REPOSITORY
  R302 KIconThemes

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

To: mart, #frameworks, #plasma
Cc: broulik, kde-frameworks-devel, LeGast00n, sbergeron, michaelh, ngraham, 
bruns

D22339: Make sure solid backends are reentrant

[Aleix Pol Gonzalez]

apol added a comment.


  In D22339#495116 , @lbeltrame 
wrote:
  
  > Why was this committed when changes were requested? Wasn't that the whole 
point of having reviews?
  
  
  Sorry, I thought all doubts had been resolved. No changes were requested.

REPOSITORY
  R245 Solid

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

To: apol, #frameworks, davidedmundson, bruns
Cc: lbeltrame, bruns, kde-frameworks-devel, LeGast00n, sbergeron, michaelh, 
ngraham

D22488: invoke QIcon::setFallbackThemeName a bit later

[Marco Martin]

mart created this revision.
mart added reviewers: Frameworks, Plasma.
Herald added a project: Frameworks.
Herald added a subscriber: kde-frameworks-devel.
mart requested review of this revision.

REVISION SUMMARY
  invoking QIcon::setFallbackThemeName at QCoreApplication ctor
  with Q_COREAPP_STARTUP_FUNCTION breaks the internal status of
  QIconLoader as it instantiates it before the QPlatformTheme,
  but QIconLoader depends from QPlatformTheme to be already instantiated
  otherwise it won't load correctly, thus breaking icon loading
  in QtQuickControls2 styles, such as Material and Fusion
  see https://bugreports.qt.io/browse/QTBUG-74252

TEST PLAN
  icons load correctly in material,
  and the fallback to breeze works with gnome themes

REPOSITORY
  R302 KIconThemes

BRANCH
  phab/qqcicons

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

AFFECTED FILES
  src/kicontheme.cpp

To: mart, #frameworks, #plasma
Cc: kde-frameworks-devel, LeGast00n, sbergeron, michaelh, ngraham, bruns

D22487: Offer metadata.json when requesting the package metadata

[David Edmundson]

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

REPOSITORY
  R290 KPackage

BRANCH
  master

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

To: apol, #frameworks, davidedmundson
Cc: kde-frameworks-devel, LeGast00n, sbergeron, michaelh, ngraham, bruns

Re: kbuildsycoca global in a modern world

[David Edmundson]

In profiling, I've seen parsing desktop files is expensive. Even something
like KProtocolInfo registers highly in most application logs.

Parts of plasma do various complex lookups of application desktop files. We
definitely need some cache in some form of those desktop files for use from
within plasma. Ksycoca works well.

Whether it needs to be global or cover as much as it does is still
debatable.

David


>
>

D22487: Offer metadata.json when requesting the package metadata

[Aleix Pol Gonzalez]

apol created this revision.
apol added a reviewer: Frameworks.
apol added a project: Frameworks.
apol requested review of this revision.

REVISION SUMMARY
  Otherwise we'd end up using the slow path when using
  Package::metadata().

TEST PLAN
  metadata still gets loaded but using the faster path.

REPOSITORY
  R290 KPackage

BRANCH
  master

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

AFFECTED FILES
  src/kpackage/package.cpp

To: apol, #frameworks
Cc: kde-frameworks-devel, LeGast00n, sbergeron, michaelh, ngraham, bruns

D22475: Use metadata.json when creating the metadata from KPackage::metadata()

[Aleix Pol Gonzalez]

apol added a comment.


  In D22475#496132 , @davidedmundson 
wrote:
  
  > That was less than 5 hours from posting to give up on a review!
  >
  > We're not in a rush.
  
  
  Ugh yeah, I didn't mean to land the patch. >.<

REPOSITORY
  R290 KPackage

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

To: apol, #frameworks
Cc: davidedmundson, kde-frameworks-devel, LeGast00n, sbergeron, michaelh, 
ngraham, bruns

D22419: Fix cant enter directory error on Android FTP servers

[NXiss7]

nxiss7 added a comment.


  Instead of sending another command, should we refactor all FTP commands to 
upper case for better compatibility (as suggested by muesli) ?

REPOSITORY
  R241 KIO

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

To: nxiss7, #frameworks
Cc: svuorela, kde-frameworks-devel, LeGast00n, sbergeron, michaelh, ngraham, 
bruns

D21672: [PowerStateMonitor] Be conservative when determining power state

[Roman Gilg]

romangg added a comment.


  The bug report was online for two weeks and it was categorized as Baloo bug. 
You had more than enough time to notice it.
  
  I hoped I wouldn't need to waste any more time on this issue besides the time 
I already had to spent for working around this bug for two weeks, but now I had 
to setup baloo compilation myself, had to git bisect it and had to inform you. 
And now above all this unnecessary shit I have to deal with your ego being 
damaged when I reverted one isolated three lines patch of yours. Good news for 
you: the revert didn't fix the problem after reboot what I noticed now after I 
did one. Just when I restart baloo there is no more spam. So you can try to 
find the right solution now or you can continue being angry for no reason 
whatsoever.
  
  Because guess what: you can revert the revert at any time or even better hand 
in a patch to fix the whole issue after all.

REPOSITORY
  R293 Baloo

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

To: bruns, #baloo, ngraham, astippich, poboiko
Cc: broulik, romangg, kde-frameworks-devel, #baloo, LeGast00n, sbergeron, 
fbampaloukas, domson, ashaposhnikov, michaelh, astippich, spoorun, ngraham, 
bruns, abrahams

kbuildsycoca global in a modern world

[Harald Sitter]

Hey!

I was wondering if kbuildsycoca's global code still has a reason to exist.

The way I read the code a local kbuildsycoca would only reuse the
global sycoca iff languages, prefixes and signatures are a match.
But prefixes are not ever the same in any "default" or even reasonable scenario.
Specifically, prefixes are essentially
QStandardPaths::GenericDataLocation paths and those include at least
one user-specific directory on every single platform documented for
QSP. On linuxy systems this is even a very important path as (e.g.)
application desktop files edited by kmenuedit are stored in
XDG_DATA_HOME, so not including that would break overrides or custom
software installs. Additionally bundle software such as flatpak can do
user-specific software installation which means it also injects paths
into XDG_DATA_DIRS.

So, as far as I can tell the prefix constraint is always false and
with that the global cache is not ever used. That leads me to the
questions:

Do we still need the global cache feature at all?

How would we even go about repairing this? We can't just ignore XDG_DATA_HOME.

Thoughts?

HS

D21672: [PowerStateMonitor] Be conservative when determining power state

[Stefan Brüns]

bruns added a comment.


  In D21672#496232 , @broulik wrote:
  
  > > Why don't you notify the relevant people first
  >
  > He kinda did by writing a bug report, but let's not argue but investigate 
and fix why this seemingly innocent patch caused the behavior described.
  
  
  He set me as assignee today and then submitted the reversion **3** minutes 
later.

REPOSITORY
  R293 Baloo

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

To: bruns, #baloo, ngraham, astippich, poboiko
Cc: broulik, romangg, kde-frameworks-devel, #baloo, LeGast00n, sbergeron, 
fbampaloukas, domson, ashaposhnikov, michaelh, astippich, spoorun, ngraham, 
bruns, abrahams

D21672: [PowerStateMonitor] Be conservative when determining power state

[Kai Uwe Broulik]

broulik added a comment.


  > Why don't you notify the relevant people first
  
  He kinda did by writing a bug report, but let's not argue but investigate and 
fix why this seemingly innocent patch caused the behavior described.

REPOSITORY
  R293 Baloo

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

To: bruns, #baloo, ngraham, astippich, poboiko
Cc: broulik, romangg, kde-frameworks-devel, #baloo, LeGast00n, sbergeron, 
fbampaloukas, domson, ashaposhnikov, michaelh, astippich, spoorun, ngraham, 
bruns, abrahams

D21672: [PowerStateMonitor] Be conservative when determining power state

[Stefan Brüns]

bruns added a comment.


  In D21672#496217 , @romangg wrote:
  
  > Reverted by d6d86cb86c 
 on 
master. See https://bugs.kde.org/show_bug.cgi?id=409405 for more info. Possibly 
a critical problem in released 5.60 @bruns.
  
  
  Why don't you notify the relevant people first and **then** submit a 
**review**.
  
  Just reverting a commit without reasoning, without review is just wrong.

REPOSITORY
  R293 Baloo

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

To: bruns, #baloo, ngraham, astippich, poboiko
Cc: romangg, kde-frameworks-devel, #baloo, LeGast00n, sbergeron, fbampaloukas, 
domson, ashaposhnikov, michaelh, astippich, spoorun, ngraham, bruns, abrahams

D22419: Fix cant enter directory error on Android FTP servers

[Ben Cooksley]

bcooksley changed the visibility from "All Users" to "Public (No Login 
Required)".

REPOSITORY
  R241 KIO

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

To: nxiss7, #frameworks
Cc: svuorela, kde-frameworks-devel, LeGast00n, sbergeron, michaelh, ngraham, 
bruns

D22083: introduce concept of header and footer for kpageview

[Marco Martin]

mart added a comment.


  this makes it look almost pixel perfect
  F7031708: Screenshot_20190716_115035.png 

  
  tough  introduces a behavior change: moves the responsibility of adding 
margins from the outer layout to the internal one, making some users look 
weird. here kcmshell not adapted
  F7031712: Screenshot_20190716_115148.png 


REPOSITORY
  R236 KWidgetsAddons

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

To: mart, #plasma, #frameworks, #vdg
Cc: hpereiradacosta, cfeck, ndavis, ngraham, kde-frameworks-devel, LeGast00n, 
sbergeron, michaelh, bruns

D22083: introduce concept of header and footer for kpageview

[Marco Martin]

mart updated this revision to Diff 61844.
mart added a comment.


  - introduce concept of header and footer for kpageview
  - adress code style comments
  - use rowspan and colspan to add margins in the right places

REPOSITORY
  R236 KWidgetsAddons

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D22083?vs=61207&id=61844

BRANCH
  mart/pageviewfooter

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

AFFECTED FILES
  src/kpagedialog.cpp
  src/kpagedialog_p.h
  src/kpageview.cpp
  src/kpageview.h
  src/kpageview_p.h

To: mart, #plasma, #frameworks, #vdg
Cc: hpereiradacosta, cfeck, ndavis, ngraham, kde-frameworks-devel, LeGast00n, 
sbergeron, michaelh, bruns

D21672: [PowerStateMonitor] Be conservative when determining power state

[Roman Gilg]

romangg added a comment.


  Reverted by d6d86cb86c 
 on 
master. See https://bugs.kde.org/show_bug.cgi?id=409405 for more info. Possibly 
a critical problem in released 5.60 @bruns.

REPOSITORY
  R293 Baloo

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

To: bruns, #baloo, ngraham, astippich, poboiko
Cc: romangg, kde-frameworks-devel, #baloo, LeGast00n, sbergeron, fbampaloukas, 
domson, ashaposhnikov, michaelh, astippich, spoorun, ngraham, bruns, abrahams

D22477: Add a config to only show completions matching word beginning

[Sven Brauch]

brauch added a comment.


  I'm not sure if this solves the right problem.
  
  Where I notice this issue a lot is when typing "return". The keyword 
completion suggests "return", and when I want a newline, I complete the 
"return" first. This doesn't affect C++ (because of the trailing ";"), but it 
does affect other languages.
  
  I think this is pretty much the same issue. Maybe it should be solved by 
hiding the completion window if it was not explicitly invoked if there is any 
entry matching what you currently typed?
  
  Then typing Foo would not have the completion window open at all in the 
described case (thus solving your problem, as well as mine), and if you still 
wanted to complete BarFoo, you would press Ctrl+Space.

REPOSITORY
  R39 KTextEditor

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

To: ahmadsamir, #ktexteditor, cullmann, dhaumann, #kdevelop, kossebau, mwolff, 
kfunk
Cc: brauch, kwrite-devel, kde-frameworks-devel, LeGast00n, sbergeron, domson, 
michaelh, ngraham, bruns, demsking, cullmann, sars, dhaumann

D22477: Add a config to only show completions matching word beginning

[Ahmad Samir]

ahmadsamir added a comment.


  In D22477#496059 , @kossebau wrote:
  
  > Default is `false,` so does not change behaviour unless someone toggles the 
switch, right?
  >
  > I would rename the option to `WordCompletionMatchFromWordStartOnly` though, 
as from what I can tell completion often only does from start, and matching 
also in the word is an extra feature. Edit: as in, reading 
`WordCompletionMatchFromWordStart`in the code triggered with me "yes, what 
else? MatchFromEnd?"
  
  
  Noted. Thought I most likely didn't add "only" because the config name was 
becoming rather too long, but you have a point.
  
  > Actually, perhaps that whole option could/should be even an enum for 3 
cases:
  >  a) from full word start
  >  b) from subword start (CamelCase, _) 
  >  c) match anywhere in word.
  >  I vaguely remember some cases where I got annoyed by cross-subword hits 
accidentally creating a match.
  
  a and b are already in the MatchType enum, StartsWithMatch and ContainsMatch 
respectively, the new config is overriding the current behaviour where if 
there's no StartsWithMatch, it goes to the ContainsMatch route. As for c, I 
think that would be too many completions, the accuracy would be blown to bits...

REPOSITORY
  R39 KTextEditor

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

To: ahmadsamir, #ktexteditor, cullmann, dhaumann, #kdevelop, kossebau, mwolff, 
kfunk
Cc: kwrite-devel, kde-frameworks-devel, LeGast00n, sbergeron, domson, michaelh, 
ngraham, bruns, demsking, cullmann, sars, dhaumann

D21659: add .vscode to .gitignore

[Vlad Zagorodniy]

zzag added a comment.


  Heh, I usually put .vscode and compile_commands.json (for clangd) in 
.git/info/exclude.

REPOSITORY
  R289 KNotifications

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

To: brute4s99, broulik, nicolasfella
Cc: zzag, kde-frameworks-devel, LeGast00n, sbergeron, michaelh, ngraham, bruns