Bug 462611 - Info on how to get started using KPMcore library is incomplete
Summary: Info on how to get started using KPMcore library is incomplete
Status: REPORTED
Alias: None
Product: partitionmanager
Classification: Applications
Component: general (other bugs)
Version First Reported In: Git
Platform: Debian stable Linux
: NOR normal
Target Milestone: ---
Assignee: Andrius Štikonas
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2022-12-03 20:08 UTC by Ross Boylan
Modified: 2022-12-05 19:50 UTC (History)
0 users

See Also:
Latest Commit:
Version Fixed In:
Sentry Crash Report:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Ross Boylan 2022-12-03 20:08:43 UTC
SUMMARY
Please provide enough information in README.md to use the library.


DETAILS
The Initialization section provides some scraps of code, but not a complete working example.  I have so far been unable to make the transition.  Here are the issues I've encountered:
   1. `Device` not declared in this scope.  Solution: add `#include <core/device.h>`
   2. `backend` not declared in this scope.  I've tried a lot of variations to get it; none have worked.

`CoreBackendManager.h` says
```
  * This is basically a singleton class to give the application access to the currently
  * selected backend and also to manage the available backend plugins.
```
But my latest variation, `QList<Device*> devices = CoreBackendManager()->backend()->scanDevices(false);`, yields
```
build] ../test.cpp: In function ‘int main(int, char**)’:
[build] ../test.cpp:32:49: error: ‘CoreBackendManager::CoreBackendManager()’ is private within this context
[build]    32 |     QList<Device*> devices = CoreBackendManager()->backend()->scanDevices(false);
[build]       |                                                 ^
[build] In file included from ../test.cpp:6:
[build] /usr/include/kpmcore/backend/corebackendmanager.h:34:5: note: declared private here
[build]    34 |     CoreBackendManager();
[build]       |     ^~~~~~~~~~~~~~~~~~
[build] ../test.cpp:32:49: error: ‘CoreBackendManager::~CoreBackendManager()’ is private within this context
[build]    32 |     QList<Device*> devices = CoreBackendManager()->backend()->scanDevices(false);
[build]       |                                                 ^
[build] In file included from ../test.cpp:6:
[build] /usr/include/kpmcore/backend/corebackendmanager.h:35:5: note: declared private here
[build]    35 |     ~CoreBackendManager();
[build]       |     ^
[build] ../test.cpp:32:50: error: base operand of ‘->’ has non-pointer type ‘CoreBackendManager’
[build]    32 |     QList<Device*> devices = CoreBackendManager()->backend()->scanDevices(false);
```

This code gets called after the suggested `initKPMcore`, though since this is a compile-time error that may not matter.

CMAKE PROBLEMS
I had lots of trouble getting the test project to find the right include files with `CMake`, mostly because I overlooked the steps you did document in the `README`.  But one part of the instructions seemed odd, the requirement to explicitly add the include path.  The [tutorial](https://community.kde.org/Guidelines_and_HOWTOs/CMake/Frameworks) says that adding an explicit link target will automatically take care of includes: "This [that is the target_link_libraries declaration] will not only link the tutorial target against the KArchive library, it will set up the include paths properly as well."  Is there a reason that pattern doesn't apply here (I tried; the link declaration alone definitely is insufficient)?

VERSIONS
My test code is running against the development libraries packaged for Debian bullseye, libkpmcore10        20.12.3-2, though I've mostly been looking at the source from git.
Comment 1 Ross Boylan 2022-12-03 20:15:04 UTC
Also, I would expect there to be some master include file, e.g., `#include <KPMcore>` that would get the whole library.  It is unclear if such a file exists, or what it's called.
Comment 2 Andrius Štikonas 2022-12-03 21:11:45 UTC
Yes, documentation needs more work...

This is due to how kpmcore appeared. Initially we had just partitionmanager as application with no library, later Calamares installer started using forked version of partitionmanager but later we managed to separate some bits into a separate library, so that Calamares installer can link to those. Those bits of kpmcore that were useful to Calamares were separated into library but the coupling between application and library is fairly tight and API is not particularly nice.

Have you checked kpmcore/test directory. In particular testlist.cpp should be a fairly self contained example how to get the list of device objects and print some of that info.
Comment 3 Ross Boylan 2022-12-05 17:25:55 UTC
Thanks for the pointer.  That was the last bit I needed, and I can now compile and run.  Qt structures are impenetrable in the debugger, but that's a separate issue.  I'm installing kdevelop and qtcreator now; I think both have helpers for debugging.

So my final tips to get running were
1. Use CoreBackendManager::self()->backend() to get the backend.
2. The app requires the Qt event loop, which can be started with QCoreApplication app(argc, argv);
3. Those require including <backend/corebackend.h> and <QCoreApplication>
Comment 4 Ross Boylan 2022-12-05 17:29:46 UTC
By the way, continuing on your remarks that kpmcore isn't a regular library, when I went to file a bug I noticed there was no entry for it under KDE Frameworks; there is one for partitionmanager under Applications.  This might also be related to why no API documentation appears on the web.
Comment 5 Andrius Štikonas 2022-12-05 19:50:43 UTC
(In reply to Ross Boylan from comment #3)
> Thanks for the pointer.  That was the last bit I needed, and I can now
> compile and run.  Qt structures are impenetrable in the debugger, but that's
> a separate issue.  I'm installing kdevelop and qtcreator now; I think both
> have helpers for debugging.
> 
> So my final tips to get running were
> 1. Use CoreBackendManager::self()->backend() to get the backend.
> 2. The app requires the Qt event loop, which can be started with
> QCoreApplication app(argc, argv);
> 3. Those require including <backend/corebackend.h> and <QCoreApplication>

Maybe I can convince you to update README with the things you discovered? (Or at least mention this useful example in tests directory).