Re: plasma-framework, kactivities and kactivities-stats: please consider proper de-KF-ication now
Hi, +1 to what Carl said. Right now my Elisa barely needs any time to read my music library, presumably because Baloo already has it indexed. It'll be quite a shame if apps did their own indexing, wasting time and power. The effects (of removing Baloo support) are even more pronounced if we consider that a majority of Elisa users are running Plasma as well. (Citation needed, I know, but IMO it's not such a risky assumption.) Regards, Shantanu On Sun, Nov 5, 2023, 11:53 PM Carl Schwan wrote: > On Sunday, November 5, 2023 6:01:38 PM CET Nate Graham wrote: > > On 11/5/23 07:42, Kevin Ottens wrote: > > > I was clumsily advocating for this Akademy 2021 or 2022 (can't remember > > > which). > > > > > > This way it's clearer to application authors when they tie themselves > to a > > > given workspace or not. > > > > > > Also, isn't Elisa able to work without Baloo? It even seems to do the > > > right > > > thing if I trust its CMakeLists.txt. It has Baloo as a recommended but > > > optional dependency, and disable it altogether for Win32 builds. > > > > Yes, Elisa also includes an internal indexer, for use on Windows and > > Android, or on *Nix when Baloo isn't installed or is disabled. > > > > I think the original idea for the app was to delegate all the indexing > > heavy lifting to Baloo to avoid internal complication, but clearly this > > has not worked out in practice, since to be truly cross-platform, it > > can't assume that Baloo is present and active and does need its own > > indexer. So maybe the best course of action is actually to remove Baloo > > support entirely and always use the internal indexer, so that we don't > > have two different code paths. > > > > Nate > > I do not belive this is a good idea. Mostly because it means we would then > have an indexer in Baloo and one indexer in Elisa running at the same time > and > doing something similar which is wasteful. It becomes even more of an > issue > when other apps like Peruse or Arianna start doing the same and use their > own > indexer instead of Baloo on Plasma. > > This defeat the point of having a general purpose indexer in Plasma. > > Cheers, > Carl > > > >
[Powerdevil] [Bug 357456] While using "When laptop lid closed: Lock screen" setting, screen is not also turned off, which wastes power
https://bugs.kde.org/show_bug.cgi?id=357456 Natalie Clarius changed: What|Removed |Added See Also||https://bugs.kde.org/show_b ||ug.cgi?id=423174 -- You are receiving this mail because: You are the assignee for the bug.
[Powerdevil] [Bug 357456] While using "When laptop lid closed: Lock screen" setting, screen is not also turned off, which wastes power
https://bugs.kde.org/show_bug.cgi?id=357456 --- Comment #7 from Natalie Clarius --- Not the exact same thing you're requesting but FWIW, in Plasma 6.0 you'll be able configure the screen to automatically turn off after a certain time when the screen is locked. -- You are receiving this mail because: You are the assignee for the bug.
Re: plasma-framework, kactivities and kactivities-stats: please consider proper de-KF-ication now
On Sunday, November 5, 2023 6:01:38 PM CET Nate Graham wrote: > On 11/5/23 07:42, Kevin Ottens wrote: > > I was clumsily advocating for this Akademy 2021 or 2022 (can't remember > > which). > > > > This way it's clearer to application authors when they tie themselves to a > > given workspace or not. > > > > Also, isn't Elisa able to work without Baloo? It even seems to do the > > right > > thing if I trust its CMakeLists.txt. It has Baloo as a recommended but > > optional dependency, and disable it altogether for Win32 builds. > > Yes, Elisa also includes an internal indexer, for use on Windows and > Android, or on *Nix when Baloo isn't installed or is disabled. > > I think the original idea for the app was to delegate all the indexing > heavy lifting to Baloo to avoid internal complication, but clearly this > has not worked out in practice, since to be truly cross-platform, it > can't assume that Baloo is present and active and does need its own > indexer. So maybe the best course of action is actually to remove Baloo > support entirely and always use the internal indexer, so that we don't > have two different code paths. > > Nate I do not belive this is a good idea. Mostly because it means we would then have an indexer in Baloo and one indexer in Elisa running at the same time and doing something similar which is wasteful. It becomes even more of an issue when other apps like Peruse or Arianna start doing the same and use their own indexer instead of Baloo on Plasma. This defeat the point of having a general purpose indexer in Plasma. Cheers, Carl
Re: Move krunner also to plasma bundle?
Heyho, I discussed with David Edmundson that it might be a good idea to move the milou QML bits to plasma-workspace. That allows easier codesharing for some KFileItemActions integrations that Kai (and I in an abandoned patch) have been working on. Though, this has the same issues regarding the KWin overview effect. Regarding Friedrichs points: In KF5, KRunner has had a large dependency tree, including plasma-frameworks in its public header. The model has been moved from Milou to KRunner in KF6. This makes KRunner more useful (without having to implement a model oneself) for consumers. Due to the model move, there should no longer be many issues of synchronizing changes, because logic like sorting is now in one place. I do not think that is it makes sense to differentiate between stable plugin APIs and other, unstable APIs. Maybe one non-plugin relevant API is the model, but that only exposes stuff from the plugin API (like QueryMatch properties). Regards Alex On 11/5/23 18:17, Nate Graham wrote: On 11/5/23 10:12, Nate Graham wrote:> +1, it's an integral part of Plasma and I would support moving it there. And Milou is already there. For that matter, I'd also support moving both Milou and what's currently in the KRunner framework just into plasma-workspace for simplicity since it's a required dependency anyway. Nate ...Though on second thought, putting it in plasma-workspace would probably not be ideal since then it would be harder to use KWin (which embeds KRunner in the Overview effect) without Plasma. So maybe a separate repo in Plasma would be better. Heck, maybe we could merge the KRunner framework into the Milou repo and rename it have a name that's at least tangentially related to its content. :) Nate
Re: plasma-framework, kactivities and kactivities-stats: please consider proper de-KF-ication now
On 2023-11-05 18:01, Nate Graham wrote: On 11/5/23 07:42, Kevin Ottens wrote: I was clumsily advocating for this Akademy 2021 or 2022 (can't remember which). This way it's clearer to application authors when they tie themselves to a given workspace or not. Also, isn't Elisa able to work without Baloo? It even seems to do the right thing if I trust its CMakeLists.txt. It has Baloo as a recommended but optional dependency, and disable it altogether for Win32 builds. Yes, Elisa also includes an internal indexer, for use on Windows and Android, or on *Nix when Baloo isn't installed or is disabled. I think the original idea for the app was to delegate all the indexing heavy lifting to Baloo to avoid internal complication, but clearly this has not worked out in practice, since to be truly cross-platform, it can't assume that Baloo is present and active and does need its own indexer. So maybe the best course of action is actually to remove Baloo support entirely and always use the internal indexer, so that we don't have two different code paths. Hi, sounds for me a lot easier to test with just one variant. And one would always use the variant Windows uses. Greetings Christoph Nate
Re: Move krunner also to plasma bundle?
On 11/5/23 10:12, Nate Graham wrote:> +1, it's an integral part of Plasma and I would support moving it there. And Milou is already there. For that matter, I'd also support moving both Milou and what's currently in the KRunner framework just into plasma-workspace for simplicity since it's a required dependency anyway. Nate ...Though on second thought, putting it in plasma-workspace would probably not be ideal since then it would be harder to use KWin (which embeds KRunner in the Overview effect) without Plasma. So maybe a separate repo in Plasma would be better. Heck, maybe we could merge the KRunner framework into the Milou repo and rename it have a name that's at least tangentially related to its content. :) Nate
Re: Move krunner also to plasma bundle?
On 11/5/23 07:43, Friedrich W. H. Kossebau wrote: While at it: would KRunner not also be a good candidate to bundle with Plasma instead of KF? (to repeat some old record :P) AFAIK the only programs hosting KRunner plugins are Plasma ones, everyone else just provides plugins. So similar to Plasma-Frameworks. Bundling KRunner libraries with Plasma would allow to develop the search/query system in-sync, and plugin developers would just expect the plugin API to be stable. Cheers Friedrich +1, it's an integral part of Plasma and I would support moving it there. And Milou is already there. For that matter, I'd also support moving both Milou and what's currently in the KRunner framework just into plasma-workspace for simplicity since it's a required dependency anyway. Nate
Re: plasma-framework, kactivities and kactivities-stats: please consider proper de-KF-ication now
On 11/5/23 07:42, Kevin Ottens wrote: I was clumsily advocating for this Akademy 2021 or 2022 (can't remember which). This way it's clearer to application authors when they tie themselves to a given workspace or not. Also, isn't Elisa able to work without Baloo? It even seems to do the right thing if I trust its CMakeLists.txt. It has Baloo as a recommended but optional dependency, and disable it altogether for Win32 builds. Yes, Elisa also includes an internal indexer, for use on Windows and Android, or on *Nix when Baloo isn't installed or is disabled. I think the original idea for the app was to delegate all the indexing heavy lifting to Baloo to avoid internal complication, but clearly this has not worked out in practice, since to be truly cross-platform, it can't assume that Baloo is present and active and does need its own indexer. So maybe the best course of action is actually to remove Baloo support entirely and always use the internal indexer, so that we don't have two different code paths. Nate
Move krunner also to plasma bundle? (was: Re: plasma-framework, kactivities and kactivities-stats: please consider proper de-KF-ication now)
Am Sonntag, 5. November 2023, 15:32:21 CET schrieb christ...@cullmann.io: > On 2023-11-05 15:11, Nate Graham wrote: > > On 11/5/23 07:09, christ...@cullmann.io wrote: > >> if we are atm moving stuff, might it make sense to move Baloo, too, > >> given it only > >> is usable with the daemon inside Plasma more or less, too? > >> > >> Greetings > >> Christoph > > > > Baloo is linked by some apps, e.g. Elisa, and I wouldn't like to make > > them haul in Plasma stuff. > > Hi, > > some applications link to kactivities, too. > I think it just makes it more clear that this will just work with > Plasma. > > But I can live with the status quo, too, just thought it would be > cleaner. While at it: would KRunner not also be a good candidate to bundle with Plasma instead of KF? (to repeat some old record :P) AFAIK the only programs hosting KRunner plugins are Plasma ones, everyone else just provides plugins. So similar to Plasma-Frameworks. Bundling KRunner libraries with Plasma would allow to develop the search/query system in-sync, and plugin developers would just expect the plugin API to be stable. Cheers Friedrich
Re: plasma-framework, kactivities and kactivities-stats: please consider proper de-KF-ication now
Hello, On Sunday, 5 November 2023 15:32:21 CET christ...@cullmann.io wrote: > On 2023-11-05 15:11, Nate Graham wrote: > > Baloo is linked by some apps, e.g. Elisa, and I wouldn't like to make > > them haul in Plasma stuff. > > some applications link to kactivities, too. > I think it just makes it more clear that this will just work with > Plasma. > > But I can live with the status quo, too, just thought it would be > cleaner. Yes, I think it'd make sense to have a clearer and cleaner separation between KDE Frameworks dependencies which can work outside of a Plasma sessions and libraries which require Plasma runtime components. I was clumsily advocating for this Akademy 2021 or 2022 (can't remember which). This way it's clearer to application authors when they tie themselves to a given workspace or not. Also, isn't Elisa able to work without Baloo? It even seems to do the right thing if I trust its CMakeLists.txt. It has Baloo as a recommended but optional dependency, and disable it altogether for Win32 builds. Regards. -- Kevin Ottens, http://ervin.ipsquad.net enioka Haute Couture - proud supporting member of KDE https://hc.enioka.com/en signature.asc Description: This is a digitally signed message part.
Re: plasma-framework, kactivities and kactivities-stats: please consider proper de-KF-ication now
On 2023-11-05 15:11, Nate Graham wrote: On 11/5/23 07:09, christ...@cullmann.io wrote: On 2023-11-05 12:59, Friedrich W. H. Kossebau wrote: Hi, with plasma-framework, kactivities and kactivities entering the Plasma product bundle, I assume they also will adapt to Plasma versioning. Hi, if we are atm moving stuff, might it make sense to move Baloo, too, given it only is usable with the daemon inside Plasma more or less, too? Greetings Christoph Baloo is linked by some apps, e.g. Elisa, and I wouldn't like to make them haul in Plasma stuff. Hi, some applications link to kactivities, too. I think it just makes it more clear that this will just work with Plasma. But I can live with the status quo, too, just thought it would be cleaner. Greetings Christoph Nate
Re: plasma-framework, kactivities and kactivities-stats: please consider proper de-KF-ication now
On 11/5/23 07:09, christ...@cullmann.io wrote: On 2023-11-05 12:59, Friedrich W. H. Kossebau wrote: Hi, with plasma-framework, kactivities and kactivities entering the Plasma product bundle, I assume they also will adapt to Plasma versioning. Hi, if we are atm moving stuff, might it make sense to move Baloo, too, given it only is usable with the daemon inside Plasma more or less, too? Greetings Christoph Baloo is linked by some apps, e.g. Elisa, and I wouldn't like to make them haul in Plasma stuff. Nate
Re: plasma-framework, kactivities and kactivities-stats: please consider proper de-KF-ication now
On 2023-11-05 12:59, Friedrich W. H. Kossebau wrote:
Hi,
with plasma-framework, kactivities and kactivities entering the Plasma
product
bundle, I assume they also will adapt to Plasma versioning.
Hi,
if we are atm moving stuff, might it make sense to move Baloo, too,
given it only
is usable with the daemon inside Plasma more or less, too?
Greetings
Christoph
Without any de-KF-ication though this will break things though for
building
consumers soonish. Example
--- 8< ---
find_package(KF6 ${KF_MIN_VERSION} REQUIRED COMPONENTS
CoreAddons
Plasma
)
--- 8< ---
* KF6_VERSION will be set by FindKF6.cmake to min component version, so
that
of KF6Plasma
* when setting KF_MIN_VERSION one will only think about KF versions,
not
Plasma versions
Asking people to always know about that trap and remember to always
only do
e.g.
--- 8< ---
find_package(KF6CoreAddons ${KF_MIN_VERSION} REQUIRED)
find_package(KF6Plasma ${PLASMA_MIN_VERSION} REQUIRED)
--- 8< ---
yields rather strange pattern code.
Or think of things like libcolorcorrect/LibColorCorrectConfig.cmake.in:
--- 8< ---
find_dependency(KF6Plasma "@KF6_MIN_VERSION@")
--- 8< ---
Looks fine on first sight, does it? Just, no longer is now.
So not best developer experience here.
Thus, to make it clear to everyone that those 3 libraries are now from
another
product bundle, with own versioning and other own rules, please do not
forget
to adapt
* naming: library names, CMake package names, CMake target names
* version variable setting (PLASMA_MIN_VERSION needed now in consumers)
* documentation: metainfo.yaml entries, references to KDE Frameworks
And yes, while at it some other Plasma bundle things might want to be
unmessy
here as well, e.g. libkscreen :)
Cheers
Friedrich
plasma-framework, kactivities and kactivities-stats: please consider proper de-KF-ication now
Hi,
with plasma-framework, kactivities and kactivities entering the Plasma product
bundle, I assume they also will adapt to Plasma versioning.
Without any de-KF-ication though this will break things though for building
consumers soonish. Example
--- 8< ---
find_package(KF6 ${KF_MIN_VERSION} REQUIRED COMPONENTS
CoreAddons
Plasma
)
--- 8< ---
* KF6_VERSION will be set by FindKF6.cmake to min component version, so that
of KF6Plasma
* when setting KF_MIN_VERSION one will only think about KF versions, not
Plasma versions
Asking people to always know about that trap and remember to always only do
e.g.
--- 8< ---
find_package(KF6CoreAddons ${KF_MIN_VERSION} REQUIRED)
find_package(KF6Plasma ${PLASMA_MIN_VERSION} REQUIRED)
--- 8< ---
yields rather strange pattern code.
Or think of things like libcolorcorrect/LibColorCorrectConfig.cmake.in:
--- 8< ---
find_dependency(KF6Plasma "@KF6_MIN_VERSION@")
--- 8< ---
Looks fine on first sight, does it? Just, no longer is now.
So not best developer experience here.
Thus, to make it clear to everyone that those 3 libraries are now from another
product bundle, with own versioning and other own rules, please do not forget
to adapt
* naming: library names, CMake package names, CMake target names
* version variable setting (PLASMA_MIN_VERSION needed now in consumers)
* documentation: metainfo.yaml entries, references to KDE Frameworks
And yes, while at it some other Plasma bundle things might want to be unmessy
here as well, e.g. libkscreen :)
Cheers
Friedrich
