D26227: Port to QRandomGenerator

[Laurent Montel]

This revision was automatically updated to reflect the committed changes.
Closed by commit R283:20980f54fb4a: Port to QRandomGenerator (authored by 
mlaurent).

REPOSITORY
  R283 KAuth

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D26227?vs=72192&id=72282

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

AFFECTED FILES
  autotests/HelperTest.cpp

To: mlaurent, dfaure, apol
Cc: kde-frameworks-devel, LeGast00n, GB_2, michaelh, ngraham, bruns

D26043: Add edit mode menu item to desktop widget context menu

[Björn Feber]

GB_2 added a comment.


  Ping.

REPOSITORY
  R242 Plasma Framework (Library)

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

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

D25877: [KColorschemeManager] Add option to reenable following global theme

[Alexander Semke]

asemke added inline comments.

INLINE COMMENTS

> davidre wrote in kcolorschememanager.h:130
> I thought it would be nice to have as a convenience function if an 
> application has changed the scheme to easily go back to the system color 
> scheme. I don't know if it should be a slot. I put it there because 
> activateScheme is here.

I think the only communication channel with KColorSchemeManager is via the menu 
created in createSchemeSelectionMenu(). Setting back the default scheme will 
also be done via this menu. I don't see why an application would need such a 
helper function - there is simply no other handling of the color schemes in the 
applications except of that menu.

Also, if somebody would still need such a helper function, he/she could use 
activateScheme(QModelIndex()) instead of followSystemScheme(). activateScheme() 
exists already and an empty QModelIndex() could be interpreted as the default 
color scheme.

REPOSITORY
  R265 KConfigWidgets

BRANCH
  systemthem (branched from master)

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

To: davidre, #frameworks, ngraham
Cc: asemke, kossebau, ngraham, kde-frameworks-devel, LeGast00n, GB_2, michaelh, 
bruns

D26245: Set SYSCONFDIR to /etc when CMAKE_INSTALL_SYSCONFDIR is etc relative to /usr

[Piotr Wójcik]

pwojcik added inline comments.

INLINE COMMENTS

> apol wrote in KDEInstallDirs.cmake:376
> Why's /opt special?

/usr is single special case, but any subdirectory of /opt/ is special by 
GNUInstallDirs.cmake, following Filesystem Hierarchy Standard.

REPOSITORY
  R240 Extra CMake Modules

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

To: pwojcik, kossebau, alexmerry
Cc: apol, kde-frameworks-devel, kde-buildsystem, LeGast00n, GB_2, bencreasy, 
michaelh, ngraham, bruns

D26245: Set SYSCONFDIR to /etc when CMAKE_INSTALL_SYSCONFDIR is etc relative to /usr

[Friedrich W. H. Kossebau]

kossebau added a comment.


  (Just remember that using KDE_INSTALL_KNSRCDIR though needs at least 
KNewStuffCore from KF 5.57 (hint was missing in API dox, proposing D26248 
 to fix that).)
  
  Myself also need to reserve time to look closer at it, hoping to sneak in in 
the next days or week 1 of 2020
  
  Please see to add a unit test also covering this, so this special case is 
covered.

INLINE COMMENTS

> pwojcik wrote in KDEInstallDirs.cmake:376
> /usr is single special case, but any subdirectory of /opt/ is special by 
> GNUInstallDirs.cmake, following Filesystem Hierarchy Standard.

Ideally gets a small explaining comment in the code, as this is not directly 
obvious.

REPOSITORY
  R240 Extra CMake Modules

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

To: pwojcik, kossebau, alexmerry
Cc: apol, kde-frameworks-devel, kde-buildsystem, LeGast00n, GB_2, bencreasy, 
michaelh, ngraham, bruns

D26043: Add edit mode menu item to desktop widget context menu

[Nathaniel Graham]

ngraham 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/D26043

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

D24932: Add button to open the folder in filelight to view more details

[Pino Toscano]

pino added inline comments.

INLINE COMMENTS

> kpropertiesdialog.cpp:1453
> +// Open the current folder in filelight
> +KRun::run(QStringLiteral("/usr/bin/filelight"), { properties->url() }, 
> properties->window(), QStringLiteral("Filelight"), 
> QStringLiteral("filelight"));
> +}

please do not hardcode the path to filelight... other than breaking on systems 
where filelight is installed in a prefix different than /usr, this breaks on 
Mac and Windows (and not only).

REPOSITORY
  R241 KIO

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

To: shubham, ngraham, #frameworks
Cc: pino, kde-frameworks-devel, #frameworks, LeGast00n, GB_2, michaelh, 
ngraham, bruns

Re: Exemptions to try KF "grow" vs. consistent experience (Re: Submitting Grantlee as a KF5 Framework)

[Albert Astals Cid]

El divendres, 27 de desembre de 2019, a les 11:03:25 CET, Volker Krause va 
escriure:
> On Thursday, 26 December 2019 19:25:09 CET Albert Astals Cid wrote:
> > El dimarts, 24 de desembre de 2019, a les 13:05:23 CET, Friedrich W. H. 
> Kossebau va escriure:
> > > Am Montag, 23. Dezember 2019, 09:57:57 CET schrieb Volker Krause:
> > > > On Sunday, 22 December 2019 09:46:02 CET Dominik Haumann wrote:
> > > > > Hi all,
> > > > > 
> > > > > in any case, maybe the discussed points should go to the KF6
> > > > > workboard?
> > > > > https://phabricator.kde.org/project/view/310/
> > > > > 
> > > > > I indeed believe that consistency in the KF5 world is an important
> > > > > feature,
> > > > > so Friedrich does have a point here. Other framework additions had to
> > > > > adapt
> > > > > as well (what comes to my mind is renaming of KQuickCharts or
> > > > > KCalendarCore).
> > > > 
> > > > There is one important difference between KCalendarCore/KQuickCharts/etc
> > > > and Grantlee/QKeychain/etc though. The former had no previous release
> > > > promising a public API and therefore only KDE-internal users. The
> > > > latter have such releases and guarantees, and a significant
> > > > KDE-external user base. That's what makes me consider a transitional
> > > > pragmatic exemption from certain conventions, if we assume it would
> > > > help to grow our external user base, and thus the pool of potential
> > > > contributors.
> > > 
> > > Having to make exemptions shows a principal design flaw though: if the
> > > idea is to pull in more libraries into KF, incl. some with previous
> > > releases & thus existing userbase hoping on longer-term stable ABI, the
> > > same will also happen in the KF6 series. And even for the currently
> > > discussed two libs Grantlee & QKeychain it means at least 1 1/2 years &
> > > longer (assuming KF 6.0.0 is coming then, and see how long kdelibs4
> > > survived) for being just "exemptions". It's rather that the "exemptions"
> > > become part of the rules that way.
> > Which kind of exceptions are we speaking about?
> > 
> > ABI stability? or?
> 
> The opposite actually :) It's about keeping existing API/ABI of frameworks 
> with a significant (KDE external) user base when joining KF5, until the next 
> major release, even if that means making compromises regarding e.g. our 
> naming 
> conventions.

Can you give an example here of the naming conventions that are being broken?

Is this about the 

**
a) include dirs below subdir KF5/
b) CMake modules with KF5 prefix
c) CMake imported target in KF5 namespace
**

stuff?

We can fix that by simply doing it both ways, no? I.e. doing it the "right KF5 
way" but still keeping the old way for a while for compat.

Cheers,
  Albert

> 
> Regards,
> Volker
> 

Re: CMake config & target challenges on moving to KF5 namespace; dir structure & API dox (Re: Submitting Grantlee as a KF5 Framework)

[Stephen Kelly]

On 22/12/2019 16:08, Stephen Kelly wrote:


On 21/12/2019 23:55, Friedrich W. H. Kossebau wrote:
Perhaps joining the "Release Service" (formerly known as "KDE 
Applications")

is a better place then, it also contains a set of libraries already.
That would serve the purpose of having releases happening regularly.



The goals of making Grantlee a Framework are:

* Make more frequent releases which don't depend on me

* Make it more easy for others to contribute to development


I think at the point that renaming happens, the name Grantlee will 
disappear, and we'll have two libraries (KF5::TextDocument and 
KF5::TextTemplates or so in CMake and probably removing the C++ 
namespace).


I think all of that should be done together and I don't think that 
should be done until compatibility is broken to become Qt6-based (KF6).



My conclusion from reading this thread is that this is the way forward:

* Grantlee does not become a KF5 framework. I'll continue to make 
releases from github if needed based on Qt 5. We can consider 
re-evaluating that in the future.


* For KF6, I will submit two separate Tier 1 frameworks, in two 
different repos, what I here called ktextdocument/KF6::TextDocument and 
ktexttemplate/KF6::TextTemplate


The two libraries are independent. Having them in the same KF* repo 
doesn't make sense.


Thanks,

Stephen.

Re: CMake config & target challenges on moving to KF5 namespace; dir structure & API dox (Re: Submitting Grantlee as a KF5 Framework)

[Friedrich W. H. Kossebau]

Hi Stephen,

Am Sonntag, 29. Dezember 2019, 00:10:50 CET schrieb Stephen Kelly:
> On 22/12/2019 16:08, Stephen Kelly wrote:
> > On 21/12/2019 23:55, Friedrich W. H. Kossebau wrote:
> >> Perhaps joining the "Release Service" (formerly known as "KDE
> >> Applications")
> >> is a better place then, it also contains a set of libraries already.
> >> That would serve the purpose of having releases happening regularly.
> > 
> > The goals of making Grantlee a Framework are:
> > 
> > * Make more frequent releases which don't depend on me
> > 
> > * Make it more easy for others to contribute to development
> > 
> > 
> > I think at the point that renaming happens, the name Grantlee will
> > disappear, and we'll have two libraries (KF5::TextDocument and
> > KF5::TextTemplates or so in CMake and probably removing the C++
> > namespace).
> > 
> > I think all of that should be done together and I don't think that
> > should be done until compatibility is broken to become Qt6-based (KF6).
> 
> My conclusion from reading this thread is that this is the way forward:
> 
> * Grantlee does not become a KF5 framework. I'll continue to make
> releases from github if needed based on Qt 5. We can consider
> re-evaluating that in the future.

Not becoming a KF5 module should not stop you/us making Grantlee a project now 
developed in the KDE community. Given your two goals cited above, making 
Grantlee hosted on KDE resources and releasing it as part of the "release 
service" should satisfy your goals already now.

And it would allow to make Grantlee already now move as close enough as 
possible to KF standards, besides the naming ones. So that at KF6 time only 
those things are left to do both on producer & consumer side which are about 
ABI breakage.

Why are you proposing to do a step back instead to the old state, which 
everyone including you considered not that satisfying?

I hope my personal objections raised about it becoming an official KF module 
already now have not arrived with you as objection in general. On the 
opposite, I agree with the ideas behind this move. I have just strict feeling 
about KF as a product itself when it comes to consumer as well as cross-module 
ontributor experience.
So please be aware that I would be sad if you decided to have Grantlee go back 
to lonely cowboy mode :)

Cheers
Friedrich

D26265: Fix crash on non-unix based systems

[Shubham]

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

REVISION SUMMARY
  Depends upon D24932 

REPOSITORY
  R241 KIO

BRANCH
  fix

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

AFFECTED FILES
  src/widgets/kpropertiesdialog.cpp

To: shubham, ngraham, pino
Cc: kde-frameworks-devel, LeGast00n, GB_2, michaelh, ngraham, bruns

D24932: Add button to open the folder in filelight to view more details

[Shubham]

shubham added a comment.


  @pino @ngraham Fixed here https://phabricator.kde.org/D26265.

REPOSITORY
  R241 KIO

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

To: shubham, ngraham, #frameworks
Cc: pino, kde-frameworks-devel, #frameworks, LeGast00n, GB_2, michaelh, 
ngraham, bruns

D26265: Fix crash on non-unix based systems

[Nathaniel Graham]

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


  Thanks!

REPOSITORY
  R241 KIO

BRANCH
  fix

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

To: shubham, ngraham, pino
Cc: kde-frameworks-devel, LeGast00n, GB_2, michaelh, ngraham, bruns