Cache of .rc files / KXMLGui?

[gregor.mi.sw]

Hi,

I am working on .rc files used by KXMLGUI on Kate originally build with kdesrc-build and installed 
in a directory in my home directory which is separeted from the system-wide KDE installation.


Now, even after system restart, when I start /usr/bin/kate, some of the menu changes of the 
development version appear in the menu. Is there a kind of menu cache that has gotten affected? If 
yes, can it be cleared?


Gregor

Re: New contributor seeking guidance

[gregor.mi.sw]

Hi Remya,

first, I reordered your email to add new messages at the bottom. See below, 
there is my reply.



On 01.11.2018 13:16, Remya Krishnan wrote:
 > Hi all,
 > First of all, thanks for responding. I unknowingly subscribed for digest 
mode but found the
reply in
 > public mailing list archive: 
https://marc.info/?l=kde-devel=154091462602641=2
 > <https://marc.info/?l=kde-devel=154091462602641=2>
 > I would like to work on https://bugs.kde.org/show_bug.cgi?id=359084.
 > <https://bugs.kde.org/show_bug.cgi?id=359084>
 > If anyone could give me some guidance to start with, I would appreciate 
it.  :)
 >
 > With Regards,
 > Remya Krishnan,
 > GitHub <https://github.com/krishremya>|FOSS@Amrita 
<https://amfoss.in/accounts/165/>
 > Amrita University <https://www.amrita.edu/campus/amritapuri>
 >

Hi,

you would like to work on this KTurtle-Theme-Bug 
(https://bugs.kde.org/show_bug.cgi?id=359084).

I am not into themeing myself but a a good start would be download and 
build KTurtle on your
machine, e.g. by following this guide:
https://community.kde.org/Guidelines_and_HOWTOs/Build_from_source

While it is building, you could investigate the source code of the editor 
componenent for places
that deal with colors and come back to us with specific questions.

Gregor



On 03.11.2018 18:30, Remya Krishnan wrote:
> Hi all,
>
> Thanks for the pointers. I have the following patch 
https://paste.kde.org/pphxfykd4 which fixes bug
> https://bugs.kde.org/show_bug.cgi?id=359084
> I'd like someone to review the same to see if the patch is acceptable. What 
should I do next ?
> With Regards,
> Remya Krishnan,
> GitHub <https://github.com/krishremya>|FOSS@Amrita 
<https://amfoss.in/accounts/165/>
> Amrita University <https://www.amrita.edu/campus/amritapuri>
>
> On Sat, Nov 3, 2018 at 5:58 PM gregor.mi.sw mailto:codestr...@posteo.org>>
> wrote:


1. Congratulations! :)

2. Did you check if your code also works with a non-dark theme?

3. Now comes the part that every new contributor has to go through: Sign up for an KDE identity and 
get familiar with the Phabricator patch review system. It is all explained here: 
https://community.kde.org/Infrastructure/Phabricator


4. Push your patch there and/or come back to us for questions.

Gregor

Re: New contributor seeking guidance

[gregor.mi.sw]

On 01.11.2018 13:16, Remya Krishnan wrote:

Hi all,
First of all, thanks for responding. I unknowingly subscribed for digest mode but found the reply in 
public mailing list archive: https://marc.info/?l=kde-devel=154091462602641=2


I would like to work on https://bugs.kde.org/show_bug.cgi?id=359084.

If anyone could give me some guidance to start with, I would appreciate it.  :)

With Regards,
Remya Krishnan,
GitHub |FOSS@Amrita 

Amrita University 



Hi,

you would like to work on this KTurtle-Theme-Bug 
(https://bugs.kde.org/show_bug.cgi?id=359084).

I am not into themeing myself but a a good start would be download and build KTurtle on your 
machine, e.g. by following this guide: https://community.kde.org/Guidelines_and_HOWTOs/Build_from_source


While it is building, you could investigate the source code of the editor componenent for places 
that deal with colors and come back to us with specific questions.


Gregor

Re:Getting Started With KDE

[gregor.mi.sw]

 > Amazing what search engines can do these days!

This is ironic speech, isn't it? Such thing does not help to provide a
warm welcome but rathers scares people off. Search engines can yield
conflicting results and the question of the new guy is perfectly valid.

Maybe an apology could be issued... :-)

Gregor

Am 30.10.2018 09:39 schrieb Ilya Bizyaev: 

> Hello!
> 
> When working on open source projects, you shouldn't expect to always be 
> guided by someone.
> 
> A quick Google search for "KDE get involved" gives me this awesome article: 
> https://community.kde.org/Get_Involved
> 
> Then, assuming I need a simple task to start with, I google "KDE junior 
> jobs", and get a link to https://community.kde.org/KDE/Junior_Jobs
> 
> Amazing what search engines can do these days!
> 
> Hope this helps.
> 
> Cheers,
> Ilya.
> 
>  On Вт, 30 окт 2018 04:51:21 +0300 jinxi...@usc.edu wrote 
> 
>> To whom it may concern, 
>> 
>> Hello, I am a student new to KDE community. I want to get involved with KDE 
>> development to hone my programming skills and make contribution to KDE. But 
>> I don't know what work I can do and where do I start. Could anyone give me 
>> some guidance? It would be better if we can discuss directly. Thank you all! 
>> 
>> Yours, 
>> Alex
 

Re: kdesrc-build: PolkitQt5-1

[gregor.mi.sw]

On 16.05.2018 10:53, Christophe Giboudeaux wrote:

Hi,

On mercredi 16 mai 2018 05:17:02 CEST Michael Pyne wrote:


The only thing that comes to mind is the possibility of using the
"CMAKE_MODULE_PATH" setting as well.

 From looking at the kdesrc-build code, we set CMAKE_MODULE_PATH for Qt
modules, but don't also do the same (by default) for the module being
built.

For the majority of KDE code this shouldn't matter, as CMAKE_MODULE_PATH
is used for the "Module" mode of CMake's find_package(), which most code
no longer uses. Instead we use "Config" mode for most find_package()
calls (which uses CMAKE_PREFIX_PATH).  See the find_package
documentation for details. [1]

CMake will use "Module" mode by default for find_package() calls that
use the "simplified" syntax and for which it can find matching CMake
modules. In the right setup that means it's possible for CMake to find
different packages depending only on whether the find_package() call
uses a simplified or complex syntax, which could explain why some
modules found the wrong module and some did not.

To confirm this, you could try exporting CMAKE_MODULE_PATH to something
like "$HOME/kde/usr/lib64/cmake" manually, before running kdesrc-build
for kauth.  Though I'm planning just to modify kdesrc-build to set the
variable regardless just in case.


CMAKE_MODULE_PATH ? really ? exporting it should be considered bad practice.
CMake will ignore it anyway.

The only way to tell CMake where to find stuff is CMAKE_PREFIX_PATH and
nothing else.


Hmm, do you have an idea then why CMake fails to do so correctly in some cases 
like the KAuth module?

Gregor

Re: kdesrc-build: PolkitQt5-1

[gregor.mi.sw]

On 16.05.2018 05:17, Michael Pyne wrote:

On Tue, May 15, 2018 at 10:33:17AM +0200, gregor.mi.sw wrote:

Hello Michael,

I just started a full rebuild and closely watched the CMakeCache.txt files. 
There is one finding.

$ # no special env var setup
$ kdesrc-build --include-dependencies ksysguard kinfocenter kdevelop

...

Building polkit-qt-1 from  (9/86)
  No source update, but the build directory doesn't exist
  Updating polkit-qt-1 (to branch master)
  Source update complete for polkit-qt-1: no files affected
  Preparing build system for polkit-qt-1.
  Running cmake...
  Compiling... succeeded (after 19 seconds)
  Installing.. succeeded (after 0 seconds)

Building kauth from frameworks (10/86)
  No source update, but the build directory doesn't exist
  Updating kauth (to branch master)
  Source update complete for kauth: no files affected
  Preparing build system for kauth.
  Running cmake...
  Compiling... succeeded (after 52 seconds)
  Installing.. succeeded (after 0 seconds)
...


In /home/gregor/kde/build/frameworks/kauth/CMakeCache.txt I have those lines:

...
//The directory containing a CMake configuration file for KF5CoreAddons.
KF5CoreAddons_DIR:PATH=/home/gregor/kde/usr/lib64/cmake/KF5CoreAddons

//The directory containing a CMake configuration file for PolkitQt5-1.
PolkitQt5-1_DIR:PATH=/usr/lib64/cmake/PolkitQt5-1
...

which means KF5CoreAddons was found at the correct place whereas for 
PolkitQt5-1, it picked up the
wrong location. I checke, those files are present:

/home/gregor/kde/usr/lib64/cmake/PolkitQt5-1/PolkitQt5-1Config.cmake
/home/gregor/kde/usr/lib64/cmake/PolkitQt5-1/PolkitQt5-1ConfigVersion.cmake
/home/gregor/kde/usr/lib64/cmake/PolkitQt5-1/PolkitQt5-1Targets-debug.cmake
/home/gregor/kde/usr/lib64/cmake/PolkitQt5-1/PolkitQt5-1Targets.cmake

Any idea?


The only thing that comes to mind is the possibility of using the
"CMAKE_MODULE_PATH" setting as well.

 From looking at the kdesrc-build code, we set CMAKE_MODULE_PATH for Qt
modules, but don't also do the same (by default) for the module being
built.

For the majority of KDE code this shouldn't matter, as CMAKE_MODULE_PATH
is used for the "Module" mode of CMake's find_package(), which most code
no longer uses. Instead we use "Config" mode for most find_package()
calls (which uses CMAKE_PREFIX_PATH).  See the find_package
documentation for details. [1]

CMake will use "Module" mode by default for find_package() calls that
use the "simplified" syntax and for which it can find matching CMake
modules. In the right setup that means it's possible for CMake to find
different packages depending only on whether the find_package() call
uses a simplified or complex syntax, which could explain why some
modules found the wrong module and some did not.

To confirm this, you could try exporting CMAKE_MODULE_PATH to something
like "$HOME/kde/usr/lib64/cmake" manually, before running kdesrc-build
for kauth.  Though I'm planning just to modify kdesrc-build to set the
variable regardless just in case.

To avoid --refresh-build you can call "kdesrc-build --reconfigure kauth"
to re-run CMake first without deleting the build directory.

[1] https://cmake.org/cmake/help/latest/command/find_package.html

Regards,
  - Michael Pyne



Sadly, the test was negative...

$ sudo zypper install libpolkit-qt5-1-devel

$ kdesrc-build --reconfigure kauth

### /home/gregor/kde/build/frameworks/kauth/CMakeCache.txt
--- Problems 
PolkitQt5-1_DIR:PATH=/usr/lib64/cmake/PolkitQt5-1
-

$ export CMAKE_MODULE_PATH=$HOME/kde/usr/lib64/cmake

$ kdesrc-build --reconfigure kauth

Same problem:

### /home/gregor/kde/build/frameworks/kauth/CMakeCache.txt
--- Problems 
PolkitQt5-1_DIR:PATH=/usr/lib64/cmake/PolkitQt5-1
-

Removing the system devel package helps again:

$ sudo zypper remove libpolkit-qt5-1-devel

$ kdesrc-build --reconfigure kauth

### /home/gregor/kde/build/frameworks/kauth/CMakeCache.txt
OK

Gregor

Re: kdesrc-build: PolkitQt5-1, KF5WindowSystem etc.

[gregor.mi.sw]

On 15.05.2018 11:12, gregor.mi.sw wrote:

Text below...

On 15.05.2018 10:33, gregor.mi.sw wrote:

Hello Michael,

I just started a full rebuild and closely watched the CMakeCache.txt files. 
There is one finding.

$ # no special env var setup
$ kdesrc-build --include-dependencies ksysguard kinfocenter kdevelop

...

Building polkit-qt-1 from  (9/86)
 No source update, but the build directory doesn't exist
 Updating polkit-qt-1 (to branch master)
 Source update complete for polkit-qt-1: no files affected
 Preparing build system for polkit-qt-1.
 Running cmake...
 Compiling... succeeded (after 19 seconds)
 Installing.. succeeded (after 0 seconds)

Building kauth from frameworks (10/86)
 No source update, but the build directory doesn't exist
 Updating kauth (to branch master)
 Source update complete for kauth: no files affected
 Preparing build system for kauth.
 Running cmake...
 Compiling... succeeded (after 52 seconds)
 Installing.. succeeded (after 0 seconds)
...


In /home/gregor/kde/build/frameworks/kauth/CMakeCache.txt I have those lines:

...
//The directory containing a CMake configuration file for KF5CoreAddons.
KF5CoreAddons_DIR:PATH=/home/gregor/kde/usr/lib64/cmake/KF5CoreAddons

//The directory containing a CMake configuration file for PolkitQt5-1.
PolkitQt5-1_DIR:PATH=/usr/lib64/cmake/PolkitQt5-1
...

which means KF5CoreAddons was found at the correct place whereas for PolkitQt5-1, it picked up the 
wrong location. I checke, those files are present:


/home/gregor/kde/usr/lib64/cmake/PolkitQt5-1/PolkitQt5-1Config.cmake
/home/gregor/kde/usr/lib64/cmake/PolkitQt5-1/PolkitQt5-1ConfigVersion.cmake
/home/gregor/kde/usr/lib64/cmake/PolkitQt5-1/PolkitQt5-1Targets-debug.cmake
/home/gregor/kde/usr/lib64/cmake/PolkitQt5-1/PolkitQt5-1Targets.cmake

Any idea?

Gregor



At this stage

Building kactivities from frameworks (33/86)
     No source update, but the build directory doesn't exist
     Updating kactivities (to branch master)
     Source update complete for kactivities: no files affected
     Preparing build system for kactivities.
     Running cmake...
     Compiling... succeeded (after 1 minute, and 1 second)
     Installing.. succeeded (after 0 seconds)

I got another offender: wrong location of KF5WindowSystem in KActivities:

$ dev-kf5-check-builddirs

Result
--
/home/gregor/kde/build/frameworks/kactivities/
/home/gregor/kde/build/frameworks/kauth/

Details
---
### - /home/gregor/kde/build/frameworks/kactivities/CMakeCache.txt --
KF5WindowSystem_DIR:PATH=/usr/lib64/cmake/KF5WindowSystem

### - /home/gregor/kde/build/frameworks/kauth/CMakeCache.txt --
PolkitQt5-1_DIR:PATH=/usr/lib64/cmake/PolkitQt5-1

Gregor


Additionally to the first results above, here are more findings.

Probably because the system-wide PolkitQt5-1 instead the local one is found, it explains the error 
when installing libksysguard, see


/home/gregor/kde/src/log/2018-05-15-14/libksysguard/install.log:

-- Installing: 
/usr/share/polkit-1/actions/org.kde.ksysguard.processlisthelper.policy
CMake Error at processcore/cmake_install.cmake:120 (file):
file INSTALL cannot copy file

"/home/gregor/kde/build/kde/workspace/libksysguard/processcore/org.kde.ksysguard.processlisthelper.policy"
to
"/usr/share/polkit-1/actions/org.kde.ksysguard.processlisthelper.policy".
Call Stack (most recent call first):
cmake_install.cmake:77 (include)

It also shows that KDevelop finds the wrong KF5Declarative. This is why its compilation fails. I 
find it strange that only a few modules have problems with finding the correct cmake file locations.


Gregor




Result Overview
---
/home/gregor/kde/build/frameworks/kimageformats/
/home/gregor/kde/build/kde/kdesdk/libkomparediff2/
/home/gregor/kde/build/kde/workspace/kinfocenter/
/home/gregor/kde/build/kde/workspace/libksysguard/
/home/gregor/kde/build/kde/workspace/ksysguard/
/home/gregor/kde/build/kde/kdenetwork/kio-extras/
/home/gregor/kde/build/extragear/kdevelop/kdevelop/
/home/gregor/kde/build/extragear/utils/okteta/

Details sorted by create date
-
### /home/gregor/kde/build/frameworks/extra-cmake-modules/CMakeCache.txt
OK

### /home/gregor/kde/build/frameworks/attica/CMakeCache.txt
OK

### /home/gregor/kde/build/frameworks/kconfig/CMakeCache.txt
OK

### /home/gregor/kde/build/frameworks/kwindowsystem/CMakeCache.txt
OK

### /home/gregor/kde/build/frameworks/kcoreaddons/CMakeCache.txt
OK

### /home/gregor/kde/build/frameworks/kdbusaddons/CMakeCache.txt
OK

### /home/gregor/kde/build/frameworks/ki18n/CMakeCache.txt
OK

### /home/gregor/kde/build/frameworks/kguiaddons/CMakeCache.txt
OK

### /home/gregor/kde/build/kdesupport/polkit-qt-1/CMakeCache.txt
OK

### /home/gregor/kde/build/frameworks/kcodecs/CMakeCache.txt
OK

### /home/gregor/kde/build

Re: kdesrc-build: PolkitQt5-1

[gregor.mi.sw]

Text below...

On 15.05.2018 10:33, gregor.mi.sw wrote:

Hello Michael,

I just started a full rebuild and closely watched the CMakeCache.txt files. 
There is one finding.

$ # no special env var setup
$ kdesrc-build --include-dependencies ksysguard kinfocenter kdevelop

...

Building polkit-qt-1 from  (9/86)
     No source update, but the build directory doesn't exist
     Updating polkit-qt-1 (to branch master)
     Source update complete for polkit-qt-1: no files affected
     Preparing build system for polkit-qt-1.
     Running cmake...
     Compiling... succeeded (after 19 seconds)
     Installing.. succeeded (after 0 seconds)

Building kauth from frameworks (10/86)
     No source update, but the build directory doesn't exist
     Updating kauth (to branch master)
     Source update complete for kauth: no files affected
     Preparing build system for kauth.
     Running cmake...
     Compiling... succeeded (after 52 seconds)
     Installing.. succeeded (after 0 seconds)
...


In /home/gregor/kde/build/frameworks/kauth/CMakeCache.txt I have those lines:

...
//The directory containing a CMake configuration file for KF5CoreAddons.
KF5CoreAddons_DIR:PATH=/home/gregor/kde/usr/lib64/cmake/KF5CoreAddons

//The directory containing a CMake configuration file for PolkitQt5-1.
PolkitQt5-1_DIR:PATH=/usr/lib64/cmake/PolkitQt5-1
...

which means KF5CoreAddons was found at the correct place whereas for PolkitQt5-1, it picked up the 
wrong location. I checke, those files are present:


/home/gregor/kde/usr/lib64/cmake/PolkitQt5-1/PolkitQt5-1Config.cmake
/home/gregor/kde/usr/lib64/cmake/PolkitQt5-1/PolkitQt5-1ConfigVersion.cmake
/home/gregor/kde/usr/lib64/cmake/PolkitQt5-1/PolkitQt5-1Targets-debug.cmake
/home/gregor/kde/usr/lib64/cmake/PolkitQt5-1/PolkitQt5-1Targets.cmake

Any idea?

Gregor



At this stage

Building kactivities from frameworks (33/86)
No source update, but the build directory doesn't exist
Updating kactivities (to branch master)
Source update complete for kactivities: no files affected
Preparing build system for kactivities.
Running cmake...
Compiling... succeeded (after 1 minute, and 1 second)
Installing.. succeeded (after 0 seconds)

I got another offender: wrong location of KF5WindowSystem in KActivities:

$ dev-kf5-check-builddirs

Result
--
/home/gregor/kde/build/frameworks/kactivities/
/home/gregor/kde/build/frameworks/kauth/

Details
---
### - /home/gregor/kde/build/frameworks/kactivities/CMakeCache.txt --
KF5WindowSystem_DIR:PATH=/usr/lib64/cmake/KF5WindowSystem

### - /home/gregor/kde/build/frameworks/kauth/CMakeCache.txt --
PolkitQt5-1_DIR:PATH=/usr/lib64/cmake/PolkitQt5-1

Gregor

kdesrc-build: PolkitQt5-1

[gregor.mi.sw]

Hello Michael,

I just started a full rebuild and closely watched the CMakeCache.txt files. 
There is one finding.

$ # no special env var setup
$ kdesrc-build --include-dependencies ksysguard kinfocenter kdevelop

...

Building polkit-qt-1 from  (9/86)
No source update, but the build directory doesn't exist
Updating polkit-qt-1 (to branch master)
Source update complete for polkit-qt-1: no files affected
Preparing build system for polkit-qt-1.
Running cmake...
Compiling... succeeded (after 19 seconds)
Installing.. succeeded (after 0 seconds)

Building kauth from frameworks (10/86)
No source update, but the build directory doesn't exist
Updating kauth (to branch master)
Source update complete for kauth: no files affected
Preparing build system for kauth.
Running cmake...
Compiling... succeeded (after 52 seconds)
Installing.. succeeded (after 0 seconds)
...


In /home/gregor/kde/build/frameworks/kauth/CMakeCache.txt I have those lines:

...
//The directory containing a CMake configuration file for KF5CoreAddons.
KF5CoreAddons_DIR:PATH=/home/gregor/kde/usr/lib64/cmake/KF5CoreAddons

//The directory containing a CMake configuration file for PolkitQt5-1.
PolkitQt5-1_DIR:PATH=/usr/lib64/cmake/PolkitQt5-1
...

which means KF5CoreAddons was found at the correct place whereas for PolkitQt5-1, it picked up the 
wrong location. I checke, those files are present:


/home/gregor/kde/usr/lib64/cmake/PolkitQt5-1/PolkitQt5-1Config.cmake
/home/gregor/kde/usr/lib64/cmake/PolkitQt5-1/PolkitQt5-1ConfigVersion.cmake
/home/gregor/kde/usr/lib64/cmake/PolkitQt5-1/PolkitQt5-1Targets-debug.cmake
/home/gregor/kde/usr/lib64/cmake/PolkitQt5-1/PolkitQt5-1Targets.cmake

Any idea?

Gregor

Re: kdesrc-build / details

[gregor.mi.sw]

Answer below...

On 15.05.2018 03:06, Michael Pyne wrote:

On Sat, May 12, 2018 at 02:23:47PM +0200, gregor.mi.sw wrote:

On 10.05.2018 02:22, Michael Pyne wrote:

On Wed, May 09, 2018 at 01:12:10PM +0200, gregor.mi.sw wrote:

Am 09.05.2018 08:19 schrieb Ben Cooksley:

On Wed, May 9, 2018 at 9:28 AM, gregor.mi.sw <codestr...@posteo.org>
wrote:

On 08.05.2018 23:15, Milian Wolff wrote:

On Dienstag, 8. Mai 2018 22:40:39 CEST gregor.mi.sw wrote:


Hello,

I have a question regarding kdesrc-build and CMake.

I setup the build environment variables and ran kdesrc-build and got
a
compiler error kinfocenter.

Now it shows the correct (local) path for solid (but not the other
ones).
Is
there an environment variable or something I have to set to tell
Cmake to
always look for local modules first?


This is all sort of odd.

Regarding the difficulty finding CMake packages, kdesrc-build sets
CMAKE_PREFIX_PATH already, based on your chosen install location (set by
'prefix' or the compatibility 'kdedir' option).

If you're installing to /usr or /usr/local then maybe that is why CMake
is finding system libraries?  Roman Gilg actually recently submitted a
patch to fix this (https://phabricator.kde.org/D12739), if that's what
the problem is.


Try CMAKE_PREFIX_PATH. See e.g. this old blog post on the matter:

https://blogs.kde.org/2008/12/12/how-get-cmake-find-what-you-want-it



Thanks for the hint. The variable was already set:

CMAKE_PREFIX_PATH=/home/gregor/kde/usr:

In the blog post, it is said, that CMAKE_PREFIX_PATH is searched
_first_. I
find it strange that I had to uninstall the system-wide devel package
in
order to have cmake pick up the library in /home/gregor/kde/usr. And
for the
other libraries it still uses /usr. Any idea how to investigate this
further?


If you have previously run CMake without setting CMAKE_PREFIX_PATH you
will need to remove your build directory first, otherwise it will
reuse modules it has already found.


Hello Ben, I already removed the build dir (forgot to mention that). I
assume that it should be sufficient to delete the build dir of the
application that should be configured
(/home/gregor/kde/src/build/kde/workspace/kinfocenter/) and not also
those of the imported libraries (KF5Service, KF5Solid, KF5Wayland etc.).
I wonder if there is maybe an additional (global) cmake cache or a
special behaviour of kdesrc-build.


There's no special behavior for kdesrc-build here (though there is a
cache, default .kdesrc-build-data in the same directory as your
kdesrc-buildrc).

However the CMake package to find when a CMake module config file is
loaded is based on the CMake paths when the module config file was
*installed*.  So all imported libraries would have be reinstalled to
fully fix the paths.


I assume "be reinstalled" also means "be rebuild" because otherwise wrong 
precompiled files would be
installed again, right?


Yes, that's right.


I've had these problems over the years and I've almost always found it
easier just to remove the CMake module config files entirely before
reinstalling to force it to be regenerated.


Do you mean those files: /home/gregor/kde/usr/lib64/cmake/* or another 
location? Why only the CMake
module config files if a complete rebuild is required (--refresh-build)?


If your path is like mine then yes.  In my case, they are files at 
~/kde-5/lib64/cmake/*.

For instance if I run ~/kde-5/lib64/cmake/KF5I18n/*Config*.cmake I get:

~/kde-5/lib64/cmake/KF5I18n/KF5I18nConfig.cmake
~/kde-5/lib64/cmake/KF5I18n/KF5I18nConfigVersion.cmake

and these files refer to other CMake metadata within the same directory.

Other CMake modules trying to find KF5::I18n will, if CMake finds these
*Config.cmake files in its search path first, end up using the metadata
embedded in these files to pull in KF5::I18n and its dependencies.

So if CMake finds a system set of *Config.cmake files it will end up
pulling in other dependencies from the system and potentially end up
linking against the wrong libraries.


I still have some hope I can save this total re-compilation which takes at 
least 1 hour for me to
reach applications like kinfocenter. Spordically, I want to code during the 
week after work in the
evening and I find myself struggeling to get the dependencies build ready. And 
when it is ready, the
time for this day is over :-). And a few days/weeks later a similar story. If I 
don't code every day
this setup time is a major obstacle to reach a point where productive coding is 
possible. Thanks for
clarifying some of the build details which makes it easier to better figure out 
when a complete
rebuild is necessary.


I see you've already added some wishlist items, and I'd just ask to keep
them coming.  kdesrc-build is very streamlined in the way *I* use it
(user-local install, no system KDE to speak of anymore) but I want it to
be productive for everyone, especially those without much time to
develop (this describes my case as well :( ).

In fact kd

Re: kdesrc-build / build-dir

[gregor.mi.sw]

Thanks for explanations. See inline.

On 15.05.2018 02:50, Michael Pyne wrote:

On Sun, May 13, 2018 at 10:32:29AM +0200, gregor.mi.sw wrote:

Regarding the difficulty finding CMake packages, kdesrc-build sets
CMAKE_PREFIX_PATH already, based on your chosen install location (set by
'prefix' or the compatibility 'kdedir' option).


I looked that up in
https://docs.kde.org/trunk5/en/extragear-utils/kdesrc-build/conf-options-table.html.
 I have
questions to that:

- If you say "compatibility option" do you also mean kdedir is deprecated? At 
least the
documentation does not say so.


I say "deprecated" in the sense that this variable used to do more (e.g.
set the KDEDIR and KDEDIRS environment variable as they were used back
with KDE 3). As kdesrc-build started to support non-KDE modules I saw
that we needed to support a more generic option to specify where to
install modules.

That option, "prefix", also works for KDE-based modules if "kdedir" is
not set so you can use it alone if you want.

I don't intend on removing "kdedir" however, so it's not deprecated in
the sense that the option will stop working (as others have been removed
from time to time).


- So, the prefix option sets CMAKE_PREFIX_PATH. Does this imply I don't have to 
export
CMAKE_PREFIX_PATH on the bash prior to running kdesrc-build? What if I do 
anyway... will this result
in different builds?


You shouldn't have to, at least in most situations.  kdesrc-build will
set CMAKE_PREFIX_PATH to the configured prefix for each module.

If you have separate prefixes that you use (e.g. a separate prefix for
KDE "support" modules, Qt, KF5, Plasma, etc.) then you may have to
manually set CMAKE_PREFIX_PATH.

It should not hurt to set CMAKE_PREFIX_PATH, as long as it is alright if
the path that kdesrc-build adds is found first by CMake when CMake runs
during the build.


This is my current .kdesrc-buildrc file:

global
  branch-group kf5-qt5
  qtdir /usr
  kdedir ~/kde/usr  # should this be replaced by prefix?

It's more generic to use prefix but you don't /have/ to.  I set both of
the options myself because I don't like having to refer back to the
source code to figure out how the defaults work each time.


Ok, I also try to set both variables.


  source-dir ~/kde/src
  build-dir build   # would ../build also be ok?

../build should work but I'd recommend ~/kde/build for clarity.


Ah, that's much better. I was misleaded by this comment by thinking only 
relative paths are possible:

# Directory to build KDE into before installing
# relative to source-dir by default

Gregor

Re: kdesrc-build: cmake should take local (instead of system-wide) cmake modules

[gregor.mi.sw]

Regarding the difficulty finding CMake packages, kdesrc-build sets
CMAKE_PREFIX_PATH already, based on your chosen install location (set by
'prefix' or the compatibility 'kdedir' option).


I looked that up in 
https://docs.kde.org/trunk5/en/extragear-utils/kdesrc-build/conf-options-table.html. I have 
questions to that:


- If you say "compatibility option" do you also mean kdedir is deprecated? At least the 
documentation does not say so.


- So, the prefix option sets CMAKE_PREFIX_PATH. Does this imply I don't have to export 
CMAKE_PREFIX_PATH on the bash prior to running kdesrc-build? What if I do anyway... will this result 
in different builds?


This is my current .kdesrc-buildrc file:

global
branch-group kf5-qt5
qtdir /usr
kdedir ~/kde/usr  # should this be replaced by prefix?
source-dir ~/kde/src
build-dir build   # would ../build also be ok?
make-options -j4
svn-server svn+ssh://s...@svn.kde.org/home/kde
end global

include /home/gregor/kde/src/kdesrc-build/kf5-frameworks-build-include
include /home/gregor/kde/src/kdesrc-build/kf5-workspace-build-include
include /home/gregor/kde/src/kdesrc-build/kf5-applications-build-include

I also filed two wish reports regarding those questions:

- https://bugs.kde.org/show_bug.cgi?id=394195 ("Warn if current environment variables do not match 
with the build of other modules")
- https://bugs.kde.org/show_bug.cgi?id=394196 ("Option to print all needed environment variables for 
manual cmake/build")


Gregor

Re: kdesrc-build: cmake should take local (instead of system-wide) cmake modules

[gregor.mi.sw]

On 09.05.2018 13:12, gregor.mi.sw wrote:



Am 09.05.2018 08:19 schrieb Ben Cooksley:

On Wed, May 9, 2018 at 9:28 AM, gregor.mi.sw <codestr...@posteo.org> wrote:



On 08.05.2018 23:15, Milian Wolff wrote:


On Dienstag, 8. Mai 2018 22:40:39 CEST gregor.mi.sw wrote:


Hello,

I have a question regarding kdesrc-build and CMake.

I setup the build environment variables and ran kdesrc-build and got a
compiler error kinfocenter.

I investigated
/home/gregor/kde/src/build/kde/workspace/kinfocenter/CMakeCache.txt and
found the following lines

  //The directory containing a CMake configuration file for
KF5Service.
  KF5Service_DIR:PATH=/usr/lib64/cmake/KF5Service

  //The directory containing a CMake configuration file for KF5Solid.
  KF5Solid_DIR:PATH=/usr/lib64/cmake/KF5Solid

  //The directory containing a CMake configuration file for
KF5Wayland.
  KF5Wayland_DIR:PATH=/usr/lib64/cmake/KF5Wayland

The directories of the needed KF5 frameworks point to the system wide
installed ones.

I removed the system-wide devel package for solid (because it caused the
compiler error) and ran kdesrc-build again:

  //The directory containing a CMake configuration file for
KF5Service.
  KF5Service_DIR:PATH=/usr/lib64/cmake/KF5Service

  //The directory containing a CMake configuration file for KF5Solid.
  KF5Solid_DIR:PATH=/home/gregor/kde/usr/lib64/cmake/KF5Solid

  //The directory containing a CMake configuration file for
KF5Wayland.
  KF5Wayland_DIR:PATH=/usr/lib64/cmake/KF5Wayland

Now it shows the correct (local) path for solid (but not the other ones).
Is
there an environment variable or something I have to set to tell Cmake to
always look for local modules first?



Try CMAKE_PREFIX_PATH. See e.g. this old blog post on the matter:

https://blogs.kde.org/2008/12/12/how-get-cmake-find-what-you-want-it



Thanks for the hint. The variable was already set:

CMAKE_PREFIX_PATH=/home/gregor/kde/usr:

In the blog post, it is said, that CMAKE_PREFIX_PATH is searched _first_. I
find it strange that I had to uninstall the system-wide devel package in
order to have cmake pick up the library in /home/gregor/kde/usr. And for the
other libraries it still uses /usr. Any idea how to investigate this
further?


If you have previously run CMake without setting CMAKE_PREFIX_PATH you
will need to remove your build directory first, otherwise it will
reuse modules it has already found.


Hello Ben, I already removed the build dir (forgot to mention that). I assume that it should be 
sufficient to delete the build dir of the application that should be configured 
(/home/gregor/kde/src/build/kde/workspace/kinfocenter/) and not also those of the imported libraries 
(KF5Service, KF5Solid, KF5Wayland etc.). I wonder if there is maybe an additional (global) cmake 
cache or a special behaviour of kdesrc-build.


Gregor



Today, I opened the CMakeCache.txt again in Kate, deleted it and ran

$ cmake /home/gregor/kde/src/kde/workspace/kinfocenter/

with CMAKE_PREFIX_PATH set to "/home/gregor/kde/usr:"

With Kate I made a diff between the previous (which did not work) and current 
(now works) file:

https://ibb.co/bOznrJ (left: old/not working, right: new/compiles)

Noteworthy differences:
OLD (wrong paths)   NEW (correct paths)
CMAKE_INSTALL_PREFIX:PATH=/home/gregor/kde/usr  
CMAKE_INSTALL_PREFIX:PATH=/usr/local
CMAKE_PREFIX_PATH:UNINITIALIZED=/usrnothing
ECM_DIR:PATH=/usr/share/ECM/cmake   
ECM_DIR:PATH=/home/gregor/kde/usr/share/ECM/cmake

The interesting thing is that
1. Although the CMAKE_PREFIX_PATH was set as environment variable, it is not explicitly mentioned in 
the CMakeCache.txt but the ECM_DIR:PATH is now correct.
2. The CMAKE_INSTALL_PREFIX in the new version points to /usr/local which I assume is normally set 
by kdesrc-build to the correct location.


So the manual cmake works.

Then, I tried again with kdesrc-build and although CMAKE_PREFIX_PATH was still exported correctly 
(/home/gregor/kde/usr), in the CMakeCache.txt there is the lines


//No help, variable specified on the command line.
CMAKE_PREFIX_PATH:UNINITIALIZED=/usr

and

ECM_DIR:PATH=/usr/share/ECM/cmake

which I assume makes the KF5 framework modules to be found in the wrong 
(system) directory.

I would be interested how the CMakeCache.txt of a healthy kdesrc-build would 
look like.

Gregor

Re: kdesrc-build: cmake should take local (instead of system-wide) cmake modules

[gregor.mi.sw]

Am 09.05.2018 08:19 schrieb Ben Cooksley:
On Wed, May 9, 2018 at 9:28 AM, gregor.mi.sw <codestr...@posteo.org> 
wrote:



On 08.05.2018 23:15, Milian Wolff wrote:


On Dienstag, 8. Mai 2018 22:40:39 CEST gregor.mi.sw wrote:


Hello,

I have a question regarding kdesrc-build and CMake.

I setup the build environment variables and ran kdesrc-build and got 
a

compiler error kinfocenter.

I investigated
/home/gregor/kde/src/build/kde/workspace/kinfocenter/CMakeCache.txt 
and

found the following lines

  //The directory containing a CMake configuration file for
KF5Service.
  KF5Service_DIR:PATH=/usr/lib64/cmake/KF5Service

  //The directory containing a CMake configuration file for 
KF5Solid.

  KF5Solid_DIR:PATH=/usr/lib64/cmake/KF5Solid

  //The directory containing a CMake configuration file for
KF5Wayland.
  KF5Wayland_DIR:PATH=/usr/lib64/cmake/KF5Wayland

The directories of the needed KF5 frameworks point to the system 
wide

installed ones.

I removed the system-wide devel package for solid (because it caused 
the

compiler error) and ran kdesrc-build again:

  //The directory containing a CMake configuration file for
KF5Service.
  KF5Service_DIR:PATH=/usr/lib64/cmake/KF5Service

  //The directory containing a CMake configuration file for 
KF5Solid.

  KF5Solid_DIR:PATH=/home/gregor/kde/usr/lib64/cmake/KF5Solid

  //The directory containing a CMake configuration file for
KF5Wayland.
  KF5Wayland_DIR:PATH=/usr/lib64/cmake/KF5Wayland

Now it shows the correct (local) path for solid (but not the other 
ones).

Is
there an environment variable or something I have to set to tell 
Cmake to

always look for local modules first?



Try CMAKE_PREFIX_PATH. See e.g. this old blog post on the matter:

https://blogs.kde.org/2008/12/12/how-get-cmake-find-what-you-want-it



Thanks for the hint. The variable was already set:

CMAKE_PREFIX_PATH=/home/gregor/kde/usr:

In the blog post, it is said, that CMAKE_PREFIX_PATH is searched 
_first_. I
find it strange that I had to uninstall the system-wide devel package 
in
order to have cmake pick up the library in /home/gregor/kde/usr. And 
for the

other libraries it still uses /usr. Any idea how to investigate this
further?


If you have previously run CMake without setting CMAKE_PREFIX_PATH you
will need to remove your build directory first, otherwise it will
reuse modules it has already found.


Hello Ben, I already removed the build dir (forgot to mention that). I 
assume that it should be sufficient to delete the build dir of the 
application that should be configured 
(/home/gregor/kde/src/build/kde/workspace/kinfocenter/) and not also 
those of the imported libraries (KF5Service, KF5Solid, KF5Wayland etc.). 
I wonder if there is maybe an additional (global) cmake cache or a 
special behaviour of kdesrc-build.


Gregor

Re: kdesrc-build: cmake should take local (instead of system-wide) cmake modules

[gregor.mi.sw]

On 08.05.2018 23:15, Milian Wolff wrote:

On Dienstag, 8. Mai 2018 22:40:39 CEST gregor.mi.sw wrote:

Hello,

I have a question regarding kdesrc-build and CMake.

I setup the build environment variables and ran kdesrc-build and got a
compiler error kinfocenter.

I investigated
/home/gregor/kde/src/build/kde/workspace/kinfocenter/CMakeCache.txt and
found the following lines

  //The directory containing a CMake configuration file for KF5Service.
  KF5Service_DIR:PATH=/usr/lib64/cmake/KF5Service

  //The directory containing a CMake configuration file for KF5Solid.
  KF5Solid_DIR:PATH=/usr/lib64/cmake/KF5Solid

  //The directory containing a CMake configuration file for KF5Wayland.
  KF5Wayland_DIR:PATH=/usr/lib64/cmake/KF5Wayland

The directories of the needed KF5 frameworks point to the system wide
installed ones.

I removed the system-wide devel package for solid (because it caused the
compiler error) and ran kdesrc-build again:

  //The directory containing a CMake configuration file for KF5Service.
  KF5Service_DIR:PATH=/usr/lib64/cmake/KF5Service

  //The directory containing a CMake configuration file for KF5Solid.
  KF5Solid_DIR:PATH=/home/gregor/kde/usr/lib64/cmake/KF5Solid

  //The directory containing a CMake configuration file for KF5Wayland.
  KF5Wayland_DIR:PATH=/usr/lib64/cmake/KF5Wayland

Now it shows the correct (local) path for solid (but not the other ones). Is
there an environment variable or something I have to set to tell Cmake to
always look for local modules first?


Try CMAKE_PREFIX_PATH. See e.g. this old blog post on the matter:

https://blogs.kde.org/2008/12/12/how-get-cmake-find-what-you-want-it


Thanks for the hint. The variable was already set:

CMAKE_PREFIX_PATH=/home/gregor/kde/usr:

In the blog post, it is said, that CMAKE_PREFIX_PATH is searched _first_. I find it strange that I 
had to uninstall the system-wide devel package in order to have cmake pick up the library in 
/home/gregor/kde/usr. And for the other libraries it still uses /usr. Any idea how to investigate 
this further?


Gregor

kdesrc-build: cmake should take local (instead of system-wide) cmake modules

[gregor.mi.sw]

Hello,

I have a question regarding kdesrc-build and CMake.

I setup the build environment variables and ran kdesrc-build and got a compiler 
error kinfocenter.

I investigated /home/gregor/kde/src/build/kde/workspace/kinfocenter/CMakeCache.txt and found the 
following lines


//The directory containing a CMake configuration file for KF5Service.
KF5Service_DIR:PATH=/usr/lib64/cmake/KF5Service

//The directory containing a CMake configuration file for KF5Solid.
KF5Solid_DIR:PATH=/usr/lib64/cmake/KF5Solid

//The directory containing a CMake configuration file for KF5Wayland.
KF5Wayland_DIR:PATH=/usr/lib64/cmake/KF5Wayland

The directories of the needed KF5 frameworks point to the system wide installed 
ones.

I removed the system-wide devel package for solid (because it caused the compiler error) and ran 
kdesrc-build again:


//The directory containing a CMake configuration file for KF5Service.
KF5Service_DIR:PATH=/usr/lib64/cmake/KF5Service

//The directory containing a CMake configuration file for KF5Solid.
KF5Solid_DIR:PATH=/home/gregor/kde/usr/lib64/cmake/KF5Solid

//The directory containing a CMake configuration file for KF5Wayland.
KF5Wayland_DIR:PATH=/usr/lib64/cmake/KF5Wayland

Now it shows the correct (local) path for solid (but not the other ones). Is there an environment 
variable or something I have to set to tell Cmake to always look for local modules first?


Gregor

Re: [spectacle] new feature: draw tool / Ksnip

[gregor.mi.sw]

On 25.10.2017 11:43, Cunha, Andre wrote:
> Hi all,
> 
> *Not sure if this is the right mail list to request new features*
> 
> It would be nice to see a feature inside spectacle to draw basic 
> rectangles/circles over an image.
> 
> This feature may not fulfill the main reason to use spectacle, but it would 
> save a lot of time
> avoiding to open an image editor + editing the picture there.
> 

Hello,

have a look at this program:

- https://www.linux-apps.com/p/1156408/ - Ksnip
- https://github.com/DamirPorobic/ksnip - Source Code, written in Qt

The image editor is the best I have seen so far in an up-to-date Qt screenshot 
tool.

Gregor

Re: [spectacle] new feature: draw tool

[gregor.mi.sw]

Hi,

> > Hi all,
> >
> > *Not sure if this is the right mail list to request new features*

This wish was already filed here: https://bugs.kde.org/show_bug.cgi?id=268260

> >
> > It would be nice to see a feature inside spectacle to draw basic
> > rectangles/circles over an image.
> >
> > This feature may not fulfill the main reason to use spectacle, but it 
> would
> > save a lot of time avoiding to open an image editor + editing the 
> picture
> > there.
> 
> This can be accomplished conveniently already in Spectacle:
> 
> Export Image -> Kolourpaint, editor window appears, start drawing.

In my view, Kolourpaint and the other tools available in the Export image... 
menu are just not the
right tools for effective screenshot editing.

> Embedding drawing tools in Spectacle itself would save a few seconds at 
> most,
> I can't see how it would be worth the added complexity.

I also don't think that one should embed this feature into Spectacle.


> +1, open image with already exists.
> the point that I feel he's right is that we need a *easy* application to do 
> quick-edditing.

+2. When it comes to screenshot editing, the FLOSS program Greenshot for Windows
(http://getgreenshot.org/) has a built-in image editor that sets a high 
standard. In my day work on
Windows, I use this regularly. So, I still feel quite handicapped with the 
Spectacle/Kolourpaint way
of annotating screenshots.

Compared to Kolourpaint et al, in the Greenshot Editor, all elements 
(rectangles, circles, text
etc.) are separate objects that can be adjusted after having them drawn. You 
can adjust position,
color, line width etc. There are also special-purpose elements like a yellow 
text marker or a blurry
rectancle to mask sensitive data.

Three years ago (2014), I thought it would be a good idea to extract the 
Greenshot editor image
editor features into a separate Linux program that can be used by all kinds of 
screenshot programs
like Spectacle. To honour the original program and because it was created under 
the KDE community, I
called it "Kreenshot Editor". It is Qt/C++ based. I wonder though, if Qt/Python 
would have also been
a better choice when it comes to establish a faster development pace.

I also tried to design this image editor as a resuable component, so that in 
long-term, one could
show basic drawing features directly for the Spectacle image preview.

At some point I got stuck and my focus was drawn elsewhere. Here is the website 
and link to the
current source code:

http://feinstaub.github.io/kreenshot-editor/index.htm#!index.md. Including some 
screenshots :-)

Gregor

Easy, encrypted transfer of larger files over third party server

[gregor.mi.sw]

Hello,

since the day I started to use email, every now and then I would like to send 
someone a large file
(big or several images, large presentation, audio or video file) that does not 
fit in an email or
vice-versa.

Nowadays, there are plenty of free online storages and transfer services (e.g.
https://wetransfer.com/, DropBox etc.). If I don't know the owner of those 
services, from a privacy
standpoint they all cannot be trusted.

I would like to hear your opinion on the following idea:

Why not having a local program for the sender and receiver that automatically 
does local encryption
before uploading to a storage server and decryption upon receiving and then 
deleting from the remote
storage server? The idea is to have a stable local user interface while the 
storage server (let's
call it "exchange point") can be easily replaced when needed.  The assumed 
exchange point
capabilities should be minimal (list files, upload file, download file, delete 
file).

(The exchange point could even be an IMAP email server (with shared 
credentials) which means the
local program should know about maximum email attachment file sizes and split 
the file accordingly
without bothering the user. Or a local network drive.)

The basic workflow for two new users A and B would be:

User A: Installs the program, setups an exchange point, sends B the 
configuration to the exchange
point, uploads the file
User B: Installs the program, imports the configuration, downloads the file.

Once the exchange point configuration is shared, sending further files is only 
a matter of selecting
the user and dropping the file. Since the program would have a CLI it could be 
integrated in other
chat or email programs.

About two years ago, I started to develop a program that should do exactly 
that. It's called "asr -
async send receive" (Code: https://cgit.kde.org/scratch/gregormi/asr.git/tree/, 
some thoughts about
it: https://github.com/feinstaub/feinstaub.github.io/blob/master/asr/index.md, 
"async" because
sender and receiver should not be required to be online at the same time). Due 
to lack of dedicated
time the development also came to a stop two years ago before I could refine 
the CLI and add a
usable GUI.

I am aware of this good new feature in NextCloud:
https://nextcloud.com/blog/nextcloud-introducing-native-integrated-end-to-end-encryption/.
 But this
would restrict online storage servers to those which have NextCloud installed.

>From the server side's perspective, this could be a security nightmare because 
>one way of using a
service like Dropbox as exchange point is to share the account credentials 
between sender and
receiver. From the user's perspective, in case the used account is shut off, 
one can switch easily
to another exchange point.

Target users: users who want to securely exchange files but without the 
knowledge or resources of
how to setup an own online server.

I wonder if it makes sense to you to further pursue this idea. Are or were 
there maybe similar
approaches? Or existing online services that also do encryption in trustable 
fashion and have a CLI?

Thanks for your feedback.

Gregor

Re: Suggestion to Remove KFloppy and hold back K3b

[gregor.mi.sw]

On 22.02.2017 23:17, Emmanuel Pescosta wrote:
> 2017-02-22 22:42 GMT+01:00 Martin Steigerwald  >:
> 
> I wonder whether it makes sense to make it a more generic format tool 
> that can
> also format USB sticks. Then it may make sense to give it a more generic 
> name.
> 
> 
> This sounds like a good idea!
> 
> ... and a great opportunity for Dolphin. Maybe we can integrate it nicely 
> into Dolphin
> e.g. by providing context  menu actions for removable/floppy devices, so that 
> a user
> can easily format her pen drive.
> 
> Cheers,
> Emmanuel

Great idea :). For some time now I am looking for an intuitive tool which I can 
show novice users to format an USB stick or external harddrive.

Gregor