Move krunner also to plasma bundle? (was: Re: plasma-framework, kactivities and kactivities-stats: please consider proper de-KF-ication now)

[Friedrich W. H. Kossebau]

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

plasma-framework, kactivities and kactivities-stats: please consider proper de-KF-ication now

[Friedrich W. H. Kossebau]

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

Developer setups for user D-Bus service files?

[Friedrich W. H. Kossebau]

Hi,

(plasma-devel as CC: for heads-up, please reply only to kde-devel to keep 
discussion in one place)

at least with systemd controlled start (but possibly also before) of the 
session D-Bus (based on what I understood so far, please correct me) for a 
user is not possible just by editing their user's config files to control 
where the session D-Bus instance is looking at, e.g. to find user-deployed D-
Bus service files.

Anything is configured by things only an admin can modify.

Which brings some challenges for installing D-Bus service files when 
installing user-built things into a user-selected prefix, like in case of 
usual KDE developer setups (e.g. ~/kde/usr as used in documentation):

a) typically the D-Bus session will not see those and thus be unable to start 
any service described in them, thus things being broken

b) there is no option to override any service files already found in system 
dirs before, D-Bus does a first-found-rules approach

While for a) in typical distribution setups as user one can deploy D-Bus 
service files to ~/.local/share (like when session D-Bus is configured with 
 which results in XDG_DATA_ROOT dir being 
checked, which in the system usually is not set (remember, user configs are 
not read here), thus resolves to default ~/.local/share), this does not help 
with b) in case one wants to work on an app/service also installed to the 
system, as the D-Bus service files hard-code the binary path.


YOUR INPUT NEEDED
So, what standard approach should we take as developers here? Ideally we all 
do something similar, so any issues hit are more easy to understand/reproduce 
when we discuss them.

The goal should be to add the recommended approach to the developer 
documentation and make any build tools (like kdesrc-build) also deal with that 
as much as possible.

No own proposal here, only found out about the challenge now (even if it seems 
as old as D-Bus is).

Cheers
Friedrich

Moving plasma-frameworks & krunner to Plasma release set for *6? (was: Re: KF6 meeting notes 2021-04-17)

[Friedrich W. H. Kossebau]

(cc: plasma-devel for heads-up, not subscribed there, please re: only to kfd)

Am Samstag, 17. April 2021, 16:11:24 CEST schrieb Luigi Toscano:
> Several "needs input" tasks are related to Plasma.
> Maybe it would be better to focus on Plasma next time and involve Plasma
> people, and find out which tasks are really blockers for KF 6.0 and which
> are not. In fact several Plasma items are not really blockers for KF6.
> 
> In the worst case, the first plasma-frameworks release could be delayed
> until Plasma 6 is closer to be ready. Other frameworks don't depend on it
> (just one dependency in KRunner, but it is deprecated, to be removed at
> branching time). Maybe frameworksintegration? (to be checked)

It seems these days the only real user of plasma-frameworks & krunner 
libraries is the Plasma shell itself, with other applications only providing 
plugins/extensions and only targeting Plasma again. IIRC Amarok was the only 
other project ever making use of Plasmoid technology, but not sure that still 
works even. For KRunner, which also seems to have been once designed for 
other, non-shell purposes, I am not aware of anything else.

And with there being strong development coupling when it comes to evolvement 
of features, perhaps it makes sense to move those two modules from the product 
KDE Frameworks to the product Plasma and its release cycle for Plasma 6?
After all there are already a few Plasma-specific libraries released as part 
of the Plasma set, so those two would not be at odds there.

Just a random thought from a non-Plasma contributor having seen what seems at 
sometimes struggles to get changes into plasma-frameworks & krunner in time 
for new Plasma major versions and being backward-compatible to older Plasma 
versions.

Not sure if such a change, if wanted, would be doable already now for Plasma 5 
even, at least without creating major headaches for any stakeholders?

Cheers
Friedrich

Re: Relicensing Plasma Browser Integration Host to GPLv3+

[Friedrich W. H. Kossebau]

Hi,

Am Dienstag, 5. Januar 2021, 23:29:38 CET schrieb Kai Uwe Broulik:
> I've noticed that the licensing of Plasma Browser Integration is all
> over the place, some parts seem to be resembling an MIT-style license,
> probably carried over all the way from when it was just a proof of
> concept we didn't care much about.
> 
> To clean up that mess, I'd like to relicense the host (all code in
> plasma-browser-integration/host) to GPLv3+ to match the newer host code
> and extension code.
> 
> According to git log the following people (and myself) touched that folder:
> 
> David Edmundson
> Fabian Vogt
> Laurent Montel
> Friedrich W. H. Kossebau
> Matthijs Tijink
> 
> Are you fine with this, or have any other comments?

Fine with me.

Only touched build system/cmake code though, which is rather trivial and, if 
actually properly licensed, should be some BSD one?

Cheers
Friedrich

D26992: [SystemTray] Use unified data model everywhere

[Friedrich W. H. Kossebau]

kossebau added inline comments.

INLINE COMMENTS

> kmaterka wrote in systemtray.h:100
> Oh, OK, now I remember, sorry for misinforming you...
> 
> I haven't had any problems with this, it "Just Worked" :) Maybe it should 
> return just plain QObject*, I'm not experienced in this area, what do you 
> think?

I guess if this works and no-one reported errors, it should be fine.

Also not fully experienced, but hit some issues elsewhere and now trying to 
understand the magic. Though right now confused by what I read in the docs, 
what I see in existing code and what my tweak & see experiments deliver (with 
different result each time, meh).

So ignore for now. I have this on my list, and if I ever understood things 
fully and then would see some issue here, I will come back to this and ping you 
:)

REPOSITORY
  R120 Plasma Workspace

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

To: kmaterka, #plasma_workspaces, #plasma, davidedmundson, ngraham, broulik
Cc: kossebau, plasma-devel, Orage, LeGast00n, The-Feren-OS-Dev, cblack, 
jraleigh, zachus, fbampaloukas, ragreen, ZrenBot, ngraham, himcesjf, 
lesliezhai, ali-mohamed, jensreuterberg, abetts, sebas, apol, ahiemstra, mart

D26992: [SystemTray] Use unified data model everywhere

[Friedrich W. H. Kossebau]

kossebau added inline comments.

INLINE COMMENTS

> kmaterka wrote in systemtray.h:100
> I don't know, this code was there before my changes, I've just done some 
> refactoring here.

Thanks for your reply. Okay, so seems you did not hit anything related.

Thing is, you added
``
Q_INVOKABLE Plasma::Service *serviceForSource(const QString );

  here, whereas the JavaScript code before was calling serviceForSource() on a 
Plasma::DataSource class, which does not return the type "Plasma::Service *", 
but "QObject *", cmp. its method definition

Q_INVOKABLE QObject *serviceForSource(const QString );

  and the JavaScript engine for a plain QObject simply exposes any Q_INVOKABLEs 
and slot methods, that's why no extra registration would be needed (AFAIK).
  
  So still a mystery to me why this here seems to work, too bad :)

REPOSITORY
  R120 Plasma Workspace

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

To: kmaterka, #plasma_workspaces, #plasma, davidedmundson, ngraham, broulik
Cc: kossebau, plasma-devel, Orage, LeGast00n, The-Feren-OS-Dev, cblack, 
jraleigh, zachus, fbampaloukas, ragreen, ZrenBot, ngraham, himcesjf, 
lesliezhai, ali-mohamed, jensreuterberg, abetts, sebas, apol, ahiemstra, mart

D26992: [SystemTray] Use unified data model everywhere

[Friedrich W. H. Kossebau]

kossebau added inline comments.

INLINE COMMENTS

> systemtray.h:100
>   */
> -Q_INVOKABLE void reorderItemAfter(QQuickItem* after, QQuickItem* before);
> -
> -Q_INVOKABLE bool isSystemTrayApplet(const QString );
> +Q_INVOKABLE Plasma::Service *serviceForSource(const QString );
>  

Hi. Seeing this code, I have a question: from what I understood so far, for 
this method to be useable from the JavaScript inside QML, the type 
"Plasma::Service *" needs to be registered with at least

  qRegisterMetaType("Plasma::Service*");

or

  qRegisterMetaType();

Yet I have not found any code in Plasma related projects which calls this.

The module org.kde.plasma.core only has code to register the unnamespaced type 
name ""Service*" (indirectly via 
`qmlRegisterInterface("Service");` which internally calls the 
equivalent of `qRegisterMetaType("Service*");`.

And the namespace in the registered type name string seems important, things 
broke elsewhere if the type signature used in the Q_INVOKABLE was different WRT 
namespace compared to the registered type name string.

Do you remember anything related or would have some insights?

REPOSITORY
  R120 Plasma Workspace

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

To: kmaterka, #plasma_workspaces, #plasma, davidedmundson, ngraham, broulik
Cc: kossebau, plasma-devel, Orage, LeGast00n, The-Feren-OS-Dev, cblack, 
jraleigh, zachus, fbampaloukas, ragreen, ZrenBot, ngraham, himcesjf, 
lesliezhai, ali-mohamed, jensreuterberg, abetts, sebas, apol, ahiemstra, mart

D22778: Restore option to create a Qt Designer plugin

[Friedrich W. H. Kossebau]

kossebau abandoned this revision.
kossebau added a comment.


  Rebased/Updated as 
https://invent.kde.org/plasma/libksysguard/-/merge_requests/10

REPOSITORY
  R111 KSysguard Library

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

To: kossebau, #plasma, davidedmundson, mart
Cc: plasma-devel, Orage, LeGast00n, The-Feren-OS-Dev, cblack, jraleigh, zachus, 
fbampaloukas, ragreen, ZrenBot, ngraham, himcesjf, lesliezhai, ali-mohamed, 
jensreuterberg, abetts, sebas, apol, ahiemstra, mart

D12459: [Icon KCM] Port to new design

[Friedrich W. H. Kossebau]

kossebau added inline comments.

INLINE COMMENTS

> main.cpp:393
> +for (int i = 0; i < KIconLoader::LastGroup; i++) {
> +KIconLoader::emitChange(KIconLoader::Group(i));
> +

Is KIconLoader::emitChange also for kde4 apps only? Asking as KIconLoader of 
KIconThemes seems to have this as part of normal API, without any deprecation 
notes, and e.g. the respective client-side signal is used in KXmlGui and other 
places.

What would be the Qt5/KF5 way otherwise?

REPOSITORY
  R119 Plasma Desktop

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

To: broulik, #plasma, #vdg, hein
Cc: kossebau, lueck, schwarzer, hein, zzag, abetts, ngraham, plasma-devel, 
Orage, LeGast00n, The-Feren-OS-Dev, cblack, jraleigh, zachus, fbampaloukas, 
ragreen, ZrenBot, himcesjf, lesliezhai, ali-mohamed, jensreuterberg, sebas, 
apol, ahiemstra, mart

D29144: [applets/weather] Improve UX for selecting a weather station

[Friedrich W. H. Kossebau]

kossebau resigned from this revision.
kossebau added a comment.


  No time left over for Plasma currently,  sorry,

REPOSITORY
  R114 Plasma Addons

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

To: ngraham, #vdg, #plasma, broulik
Cc: plasma-devel, Orage, LeGast00n, The-Feren-OS-Dev, cblack, jraleigh, zachus, 
fbampaloukas, ragreen, ZrenBot, ngraham, himcesjf, lesliezhai, ali-mohamed, 
jensreuterberg, abetts, sebas, apol, ahiemstra, mart

Re: Fwd: KDE CI: Administration » Dependency Build Plasma stable-kf5-qt5 FreeBSDQt5.14 - Build # 8 - Still Failing!

[Friedrich W. H. Kossebau]

Am Sonntag, 19. April 2020, 21:13:01 CEST schrieb Ben Cooksley:
> Hi all,
> 
> Another breakage in Qt?

Should be fixed now (restarted build now completed), with similar traps also 
removed for the future, thanks to David Faure for the work done and Ade for 
the root detecting investigations.

Seems Qt changed for Qt 5.14.1 -> 5.14.2 some wrappers around QSet-related API 
from
#if QT_VERSION < QT_VERSION_CHECK(6,0,0)
to
#if QT_DEPRECATED_SINCE(5, 14) && QT_VERSION < QT_VERSION_CHECK(6,0,0)
and by that stronger rules some projects no longer saw code they saw before, 
thus had started to fail.

Cheers
Friedrich

Re: Fwd: KDE CI: Administration » Dependency Build Plasma stable-kf5-qt5 FreeBSDQt5.14 - Build # 7 - Still Failing!

[Friedrich W. H. Kossebau]

Am Samstag, 18. April 2020, 16:26:57 CEST schrieb David Faure:
> On Saturday, April 18, 2020 7:09:25 AM CEST Ben Cooksley wrote:
> > Hi all,
> > 
> > Please see below - any ideas as to why KHelpCenter no longer successfully
> > builds?
> > 
> > It doesn't look like KHelpCenter has changed...
> 
> No, Qt has.

My question though is why. This would be a ABI-breaking change, no?
And khelpcenter nowhere disables deprecated Qt API, from what I can tell.

Does something smuggle in e.g. via CMake config file compile flags a 
QT_DISABLE_DEPRECATED_BEFORE=0x050e00 perhaps? Or is something flawed with the 
Qt packages on FreeBSD side?

Cheers
Friedrich

D28134: Add ColorUtils

[Friedrich W. H. Kossebau]

kossebau added a comment.


  Seems to no be compatible with Qt 5.12, see failing on CI: 
https://build.kde.org/view/Failing/job/Frameworks/job/kirigami/job/kf5-qt5%20SUSEQt5.12/lastFailedBuild/console

REPOSITORY
  R169 Kirigami

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

To: cblack, #plasma, mart, davidedmundson
Cc: kossebau, fvogt, davidedmundson, plasma-devel, fbampaloukas, GB_2, domson, 
dkardarakos, ngraham, apol, ahiemstra, mart

D28360: cmake: make xsettingsd check an option

[Friedrich W. H. Kossebau]

kossebau added a comment.


  Yes, I would just do a patch for the 'PURPOSE' text, mentioning "Required" or 
"Optional" (whatever you decide on), based on previously discussions with 
packagers on similar cases.

REPOSITORY
  R99 KDE Gtk Configuration Tool

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

To: eszlari, gikari
Cc: rikmills, kossebau, ngraham, plasma-devel, Orage, LeGast00n, 
The-Feren-OS-Dev, cblack, jraleigh, zachus, fbampaloukas, GB_2, ragreen, 
ZrenBot, himcesjf, lesliezhai, ali-mohamed, jensreuterberg, abetts, sebas, 
apol, ahiemstra, mart

D28360: cmake: make xsettingsd check an option

[Friedrich W. H. Kossebau]

kossebau added a comment.


  Sadly Cmake does not have separate "RUNTIME-OPTIONAL" & "RUNTIME-REQUIRED" so 
far. Previously that was solved by noting the required vs. optional in the 
purpose text, so the info still arrived with packagers.
  Just "REQUIRED" means, it is required for the build. Could be even a 
build-only requirement.
  
  So "RUNTIME" is the right type here, with the hint to be a required 
dependency done in the "PURPOSE" text:
  
set_package_properties(XSettingsd PROPERTIES
DESCRIPTION "XSettingsd daemon"
TYPE RUNTIME
PURPOSE "Required to have GTK Config kded module to apply settings to 
GTK applications on the fly"
)

REPOSITORY
  R99 KDE Gtk Configuration Tool

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

To: eszlari, gikari
Cc: rikmills, kossebau, ngraham, plasma-devel, Orage, LeGast00n, 
The-Feren-OS-Dev, cblack, jraleigh, zachus, fbampaloukas, GB_2, ragreen, 
ZrenBot, himcesjf, lesliezhai, ali-mohamed, jensreuterberg, abetts, sebas, 
apol, ahiemstra, mart

D28360: cmake: make xsettingsd check an option

[Friedrich W. H. Kossebau]

kossebau added a comment.


  See how it is done across KDE repos here:
  
https://lxr.kde.org/search?_filestring=CMakeLists.txt&_string=TYPE+RUNTIME&_casesensitive=1
  
  There should be no reason the same works here as well.

REPOSITORY
  R99 KDE Gtk Configuration Tool

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

To: eszlari, gikari
Cc: kossebau, ngraham, plasma-devel, Orage, LeGast00n, The-Feren-OS-Dev, 
cblack, jraleigh, zachus, fbampaloukas, GB_2, ragreen, ZrenBot, himcesjf, 
lesliezhai, ali-mohamed, jensreuterberg, abetts, sebas, apol, ahiemstra, mart

D28360: cmake: make xsettingsd check an option

[Friedrich W. H. Kossebau]

kossebau added a comment.


  In D28360#636615 , @eszlari wrote:
  
  > In D28360#636610 , @kossebau 
wrote:
  >
  > > Can you tell which packagers missed that this is a required runtime 
dependency?
  >
  >
  > https://packages.ubuntu.com/focal/kde-config-gtk-style
  >  
https://src.fedoraproject.org/rpms/kde-gtk-config/blob/master/f/kde-gtk-config.spec
  >  
https://gitweb.gentoo.org/repo/gentoo.git/tree/kde-plasma/kde-gtk-config/kde-gtk-config-5.18.3.ebuild
  
  
  Okay, that is quite a few. Though, I wonder why they missed it. The current 
addition to RUNTIME dependency was only added post 5.18, right? And no-one told 
the  packagers explicitly otherwise by the usual ways (like in release 
announcement). They do read the cmake log though, and usually ask for that 
listing as RUNTIME dependency.
  
  So the current state with those packages might not be a reason for the 
proposed noisy approach.
  
  >> Edit: The proposed solution to make it simply required only forces 
packagers to add that and all what it pulls in as build-time dependency to 
their package creation, even if not needed for the package creation itself at 
all, which is not something packagers like (wastes resources on package build 
servers).
  > 
  > But they don't have to! They can just compile with
  > 
  >   cmake -DENABLE_XSETTINGSD=OFF ...
  
  They can, but `ENABLE_XSETTINGSD` needs extra work, makes things more 
complex, and the term is also misleading (does it enable support for the 
demon?). One has to know detais.
  
  All in all, this is an unusual approach. Best talk to packagers what they 
prefer and expect, instead of more complex code based on assumption of how 
packagers operate. Done that before myself, and pure listing as RUNTIME dep 
always worked out :)

REPOSITORY
  R99 KDE Gtk Configuration Tool

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

To: eszlari, gikari
Cc: kossebau, ngraham, plasma-devel, Orage, LeGast00n, The-Feren-OS-Dev, 
cblack, jraleigh, zachus, fbampaloukas, GB_2, ragreen, ZrenBot, himcesjf, 
lesliezhai, ali-mohamed, jensreuterberg, abetts, sebas, apol, ahiemstra, mart

D28360: cmake: make xsettingsd check an option

[Friedrich W. H. Kossebau]

kossebau added a comment.


  Can you tell which packagers missed that this is a required runtime 
dependency?
  
  Noting runtime dependencies as done so far here, by not having it required 
and tagging it as "RUNTIME" is a pattern everywhere else in KDE code, so the 
proposed patch or just setting it to required would be not following existing 
practices, thus better avoided.

REPOSITORY
  R99 KDE Gtk Configuration Tool

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

To: eszlari, gikari
Cc: kossebau, ngraham, plasma-devel, Orage, LeGast00n, The-Feren-OS-Dev, 
cblack, jraleigh, zachus, fbampaloukas, GB_2, ragreen, ZrenBot, himcesjf, 
lesliezhai, ali-mohamed, jensreuterberg, abetts, sebas, apol, ahiemstra, mart

D28330: Color icons in titlebar if possible

[Friedrich W. H. Kossebau]

kossebau added a comment.


  With cross-casting I meant the type of cast where the types involved are not 
in same inheritance branch

INLINE COMMENTS

> davidre wrote in breezebutton.cpp:148
> I don't think it can fail. decoration() is a QPointer 
> (https://api.kde.org/kdecoration/html/classKDecoration2_1_1DecorationButton.html)
>  do you mean that with cross-cast?

Looking at the rest of the code, it always tests for decoration() resolving to 
an existing  `Decoration` pointer. 
While I would have expected it might be ensured that decoration always is of 
type `Breeze::Decoration`, but `Button::create(...)` takes a 
`KDecoration2::Decoration`, so at least by code in this class this is not 
ensured.

Now, `Button::paint(...)` already has half the check ealier, by the

  if (!decoration()) return;

But this does not ensure we have a `Breeze::Decoration` type.

And QPointer only ensures that the pointer is updated if the object is deleted 
elsewhere. It still can be nullptr, and possibly this is done here as the 
decoration object is not owned by us, so something might delete it behind the 
button's back.

So IMHO this logic might need another check by someone who can tell if the 
right type can be still assumed (which ideally then should be reflected in the 
API, so it is clear no other type could be present.

> breezebutton.cpp:151
>  decoration()->client().data()->icon().paint(painter, 
> iconRect.toRect());
> -
> +KIconLoader::global()->resetPalette();
>  

Assumes there is no other custom palette set before we set ours here. Does that 
assumption hold? Or could KWin & Co do mess with that palette as well?

REPOSITORY
  R31 Breeze

BRANCH
  icons (branched from master)

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

To: davidre, #plasma, #vdg, ngraham
Cc: kossebau, ngraham, plasma-devel, Orage, LeGast00n, The-Feren-OS-Dev, 
cblack, jraleigh, zachus, fbampaloukas, GB_2, ragreen, ZrenBot, himcesjf, 
lesliezhai, ali-mohamed, jensreuterberg, abetts, sebas, apol, ahiemstra, mart

D28330: Color icons in titlebar if possible

[Friedrich W. H. Kossebau]

kossebau added inline comments.

INLINE COMMENTS

> breezebutton.cpp:148
> +QPalette palette = decoration()->client().data()->palette();
> +palette.setColor(QPalette::Foreground, 
> qobject_cast(decoration())->fontColor());
> +KIconLoader::global()->setCustomPalette(palette);

Is there a chance the cast could fail?
Otherwise also use a static_cast, given you do not check the result, is faster 
(or is it a cross-cast?).

REPOSITORY
  R31 Breeze

BRANCH
  icons (branched from master)

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

To: davidre, #plasma, #vdg, ngraham
Cc: kossebau, ngraham, plasma-devel, Orage, LeGast00n, The-Feren-OS-Dev, 
cblack, jraleigh, zachus, fbampaloukas, GB_2, ragreen, ZrenBot, himcesjf, 
lesliezhai, ali-mohamed, jensreuterberg, abetts, sebas, apol, ahiemstra, mart

D28262: [applets/analog-clock] Optional minute hand

[Friedrich W. H. Kossebau]

kossebau resigned from this revision.
kossebau added a comment.


  Resigning, due to currently not having time for Plasma development.

REPOSITORY
  R120 Plasma Workspace

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

To: aloiseau, #vdg, #plasma
Cc: ngraham, aloiseau, plasma-devel, Orage, LeGast00n, The-Feren-OS-Dev, 
cblack, jraleigh, zachus, fbampaloukas, GB_2, ragreen, ZrenBot, himcesjf, 
lesliezhai, ali-mohamed, jensreuterberg, abetts, sebas, apol, ahiemstra, mart

D28142: Display PID & signal numbers unlocalized

[Friedrich W. H. Kossebau]

This revision was automatically updated to reflect the committed changes.
Closed by commit R871:af4cd7a4cf5f: Display PID  signal numbers 
unlocalized (authored by kossebau).

REPOSITORY
  R871 DrKonqi

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D28142?vs=78022=78116

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

AFFECTED FILES
  src/drkonqidialog.cpp

To: kossebau, #plasma, sitter
Cc: plasma-devel, Orage, LeGast00n, The-Feren-OS-Dev, cblack, jraleigh, zachus, 
fbampaloukas, GB_2, ragreen, ZrenBot, ngraham, himcesjf, lesliezhai, 
ali-mohamed, jensreuterberg, abetts, sebas, apol, ahiemstra, mart

D28142: Display PID & signal numbers unlocalized

[Friedrich W. H. Kossebau]

kossebau added a comment.


  Not tested though, somehow my setup prevents my custom drkonqi to show up. So 
far I just know it tells and should work in theory.

REPOSITORY
  R871 DrKonqi

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

To: kossebau, #plasma, sitter
Cc: plasma-devel, Orage, LeGast00n, The-Feren-OS-Dev, cblack, jraleigh, zachus, 
fbampaloukas, GB_2, ragreen, ZrenBot, ngraham, himcesjf, lesliezhai, 
ali-mohamed, jensreuterberg, abetts, sebas, apol, ahiemstra, mart

D28142: Display PID & signal numbers unlocalized

[Friedrich W. H. Kossebau]

kossebau created this revision.
kossebau added reviewers: Plasma, sitter.
Herald added a project: Plasma.
Herald added a subscriber: plasma-devel.
kossebau requested review of this revision.

REVISION SUMMARY
  These are less numbers, but more identifiers in the system.

REPOSITORY
  R871 DrKonqi

BRANCH
  fixpiddisplay

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

AFFECTED FILES
  src/drkonqidialog.cpp

To: kossebau, #plasma, sitter
Cc: plasma-devel, Orage, LeGast00n, The-Feren-OS-Dev, cblack, jraleigh, zachus, 
fbampaloukas, GB_2, ragreen, ZrenBot, ngraham, himcesjf, lesliezhai, 
ali-mohamed, jensreuterberg, abetts, sebas, apol, ahiemstra, mart

Re: 2 kirigami fixes for a point release

[Friedrich W. H. Kossebau]

Sorry, no time to rewrite to make this short.

Am Mittwoch, 12. Februar 2020, 21:59:32 CET schrieb Nate Graham:
> [+ frameworks and plasma mailing lists]
> 
> On 2020-02-12 11:31, Albert Astals Cid wrote:
> > El dimecres, 12 de febrer de 2020, a les 15:37:09 CET, Nate Graham va 
escriure:
> >> On another note, I have to admit I'm starting to doubt how well our LTS
> >> Plasma product works without a corresponding LTS frameworks release to
> >> support it. We can fix bugs in software that uses the Plasma release
> >> schedule till the cows come home, but if the bug is in Frameworks, users
> >> are stuck with it forever since LTS distros don't typically ship new
> >> Frameworks releases.

Yes, this has been questioned a few times. Also seeing Plasma LTS used 
together with a non-LTS Qt is a bit strange.
But somehow it seems there has not been enough pain for those using the Plasma 
LTS to change something. Possibly because distributions simply backport 
important bug fixes for KF themselves, kind of maintaining their own KF LTS 
version of the KF version they pinpointed to when they froze the ingredients 
to their OS. Because they are used to do this for other projects as well, and 
so miss this could be done in cooperation with upstream.

IMHO distributions using Plasma LTS, Plasma team & other stakeholders should 
team up here and maintain a matching LTS branch of Frameworks together at the 
central KDE repos together. Well, and a version also satisfying other clients 
of KF, like non-workspace applications from KDE.

It's not a reason to change normal KF release cycle.

BTW, we release our software in variants of GPL. We give distributions lots of 
rights by that license to do with the source code what they like, not what 
pleases us as authors. So we want to do cooperation here, not get into any 
form of commandeering them, as it starts sounding elsewhere in this thread.

If unsatisfied with the quality, make Plasma a trademark and hand it out only 
to distributions which are complying with the standards the Plasma team is 
fine with ;) 
Oh, look, an iceweasel is running over there... ;)

> >> Yes yes, they should, and all that--but they don't.
> >> 
> >> It seems like we either need to:
> >> - Work on convincing these distros to ship Frameworks versions in a
> >> rolling manner to their LTS users
> >> - Provide an LTS Frameworks product that can receive bugfixes and get
> >> point releases, to support the Plasma LTS product
> >> - Stop misleadingly offering a Plasma LTS product, since everything in
> >> it that comes from Frameworks isn't actually LTS
> > 
> > This should not matter, Plasma LTS is built on *lots* of other libraries
> > that are not LTS either.
> > 
> > If it matters is because the quality of KF5 releases are not good, that's
> > what should be fixed IMHO.
> Yes, the Frameworks 5.67 release was indeed was quite buggy and
> regression-filled from a Plasma perspective :(
> 
> However buggy releases are the proximate cause, not the root cause. We
> have to ask: what causes buggy releases?
> 
> I would argue that bugginess is baked into the Frameworks product by
> virtue of its very fast one-month release cycle and lack of beta
> periods, as there are for apps and Plasma. No matter how diligent patch
> review is, regressions always sneak in; that's why QA and beta-testing
> exist.

This assumes the master branch of KF modules serves the purpose of beta 
testing. My understanding is: it does not. And could not be, for the very 
reason you gave, too little time and too few testers.

The master branch's purpose is mainly to collect all changes for the next 
release, and serve as reference when merging dependent changes across multiple 
repos for CI. It should be in the state of "always releaseable".

Which also means patches going in should have seen a beta period by the people 
doing the patches _before_ merging them, and be well understood in their 
potential side-effects. Yes, this also means that for cross-repo/products 
developer should have first done some testing for some time with locally 
patched variants of all affected repos, if unsure about their changes (say, 
removing an unused variable is well understood in effect scope and does not 
need lots of testingi).
But by default crowd-sourcing the QA to fellow developers also working against 
current master and wanting to test-drive their own changes is not the way to 
go. For one they do not know they should test certain things and thus might 
not even get close to things, thus not do any testing, or it will conflict 
with their own work, when they cannot be sure it was their own change or 
someone else's which breaks things, wasting efforts in finding causes.

Needing longer beta test phases also hints that some product is not well 
understood or designed, and things fall apart easily. That needs fixing of the 
product itself, to become reliably maintainable and expandable.

Looking at the reasoning for the recent requests for KF 

Re: 2 kirigami fixes for a point release

[Friedrich W. H. Kossebau]

Am Dienstag, 18. Februar 2020, 04:03:05 CET schrieb Nate Graham:
> On 2020-02-16 14:43, Albert Astals Cid wrote:
> > Maybe i explain myself wrongly, i'm not blaming distros at all.
> > 
> > They made a decision, we/I may agree with them or not, that's *my/our*
> > problem, what I was disagreeing is to us having to do extra work because
> > someone elses (the distros) decision.
> We already do this: it's called the Plasma LTS product. :-) It's been
> specifically created to cater to various distros' desires for an
> extended-support product they can ship to users of their own LTS releases.
> 
> However all the autotests in the world will not resolve the fundamental
> incompatibility between the Plasma LTS product, which is built around
> the release model of extended, ongoing bugfix releases, and Frameworks,
> which is built around a rolling release model with no bugfix releases at
> all.

For one, distribution seem to be just fine with that. And it should be them to 
complain if they cannot make use of Plasma LTS to create a product endorsed by 
their distribution/operating system flavour users. Why would the package and 
use Plasma otherwise, if not to create a usable product.
They simply create their own KF LTS, by backporting patches which they define  
important enough to the version of KF they use. Like they do for all the other 
software where they pinpointed to a certain version and where upstream does 
not do a matching LTS, starting with the Linux kernel.

And as said before, the Plasma team could just maintain some LTS version of KF 
next to the normal master release branch and the normal releases. That branch 
could then even be synced with the release schedule pf Plasma LTS, incl. the 
lifespan,

Is there a list of Plasma LTS usages in distributions which are horrible 
because of important fixes to KF not being backported? Or is this more a 
theoretical problem you are afraid of seeing the current quality hick-up?

Cheers
Friedrich

D27036: KApiDox: add "Plasma Workspaces Libraries" group info

[Friedrich W. H. Kossebau]

kossebau resigned from this revision.
kossebau added a comment.


  Good. So stepping out here :)

REPOSITORY
  R129 Window Decoration Library

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

To: davidedmundson, #plasma
Cc: plasma-devel, Orage, LeGast00n, The-Feren-OS-Dev, jraleigh, zachus, 
fbampaloukas, GB_2, ragreen, ZrenBot, ngraham, alexeymin, himcesjf, lesliezhai, 
ali-mohamed, jensreuterberg, abetts, sebas, apol, ahiemstra, mart

D27036: KApiDox: add "Plasma Workspaces Libraries" group info

[Friedrich W. H. Kossebau]

kossebau created this revision.
kossebau added reviewers: Plasma, davidedmundson.
Herald added a project: Plasma.
Herald added a subscriber: plasma-devel.
kossebau requested review of this revision.

REVISION SUMMARY
  Here the initial patch to get a plasma subcategory on api.kde.org started,
  as thought about by David E. in D26894 .
  Though this will need some further thinking what the concept of that
  subcategory is. And how to help people with the naming clashes when it comes
  to Plasma-the-workspace vs. Plasma-the-lib.
  
  All that naming and descriptions have to be sorted out by you Plasma people,
  I just can get you started here with this :)
  
  So please someone commandeer this patch immediately, I have to pass on here
  given no own resources to work on this.
  
  And while there might be some people working on a successor for api.kde.org
  generation, those naming and grouping concepts are orthogonal, you will need
  to have an idea about this in any case, I think.

TEST PLAN
  cd ~
  mkdir plasmadox
  cd plasmadox
  ~/path/to/kapidox/src/kapidox_generate ~/path/to/kdecoration/
  firefox index.html &
  
  To update after editing the metainfo.yaml:
  rm * -r
  ~/path/to/kapidox/src/kapidox_generate ~/path/to/kdecoration/
  *reload in firefox*

REPOSITORY
  R129 Window Decoration Library

BRANCH
  addplasmaapigroup

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

AFFECTED FILES
  docs/plasma.svg
  metainfo.yaml

To: kossebau, #plasma, davidedmundson
Cc: plasma-devel, Orage, LeGast00n, The-Feren-OS-Dev, jraleigh, zachus, 
fbampaloukas, GB_2, ragreen, ZrenBot, ngraham, alexeymin, himcesjf, lesliezhai, 
ali-mohamed, jensreuterberg, abetts, sebas, apol, ahiemstra, mart

D26894: Enable publication of API dox on api.kde.org

[Friedrich W. H. Kossebau]

kossebau added a comment.


  For KDEPIM, the definition is in the akonadi repo: 
https://phabricator.kde.org/source/akonadi/browse/master/metainfo.yaml

REPOSITORY
  R129 Window Decoration Library

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

To: kossebau, #kwin, graesslin, zzag
Cc: davidedmundson, zzag, plasma-devel, Orage, LeGast00n, The-Feren-OS-Dev, 
jraleigh, zachus, fbampaloukas, GB_2, ragreen, ZrenBot, ngraham, alexeymin, 
himcesjf, lesliezhai, ali-mohamed, jensreuterberg, abetts, sebas, apol, 
ahiemstra, mart

D26894: Enable publication of API dox on api.kde.org

[Friedrich W. H. Kossebau]

kossebau added a comment.


  In D26894#602388 , @davidedmundson 
wrote:
  
  > Go for it.
  >
  > > If so, this change should trigger addition of KDecoration on api.kde.org, 
similar like KAsync is currently at the toplevel.
  >
  > If we could make a plasma subcategory, that would be great. We have some 
other potential libs to add. There's a lot of QML plugins and scripting hooks 
that we should be exposing properly.
  
  
  For such a Plasma subcategory, by the current design of kapidox as I know it, 
this needs to have one KDE repo to have a metainfo.yaml file which describes 
such a group of projects.
  KApidox itself hacks this in for KDE Frameworks by having the group 
information for that in its own metainfo.yaml, which works as it is official 
part of Frameworks as well, cmp. 
https://phabricator.kde.org/source/kapidox/browse/master/metainfo.yaml
  
  No instant proposal where Plasma could define its group, it should be some 
repo central to plasma.
  
  No time myself to care for this, sorry. But might be an interesting thing to 
play with for a beginner, things are mostly documented.

REPOSITORY
  R129 Window Decoration Library

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

To: kossebau, #kwin, graesslin, zzag
Cc: davidedmundson, zzag, plasma-devel, Orage, LeGast00n, The-Feren-OS-Dev, 
jraleigh, zachus, fbampaloukas, GB_2, ragreen, ZrenBot, ngraham, alexeymin, 
himcesjf, lesliezhai, ali-mohamed, jensreuterberg, abetts, sebas, apol, 
ahiemstra, mart

D26894: Enable publication of API dox on api.kde.org

[Friedrich W. H. Kossebau]

This revision was automatically updated to reflect the committed changes.
Closed by commit R129:e08b848015f5: Enable publication of API dox on 
api.kde.org (authored by kossebau).

REPOSITORY
  R129 Window Decoration Library

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D26894?vs=74558=74560

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

AFFECTED FILES
  README.md
  metainfo.yaml

To: kossebau, #kwin, graesslin, zzag
Cc: zzag, plasma-devel, Orage, LeGast00n, The-Feren-OS-Dev, jraleigh, zachus, 
fbampaloukas, GB_2, ragreen, ZrenBot, ngraham, alexeymin, himcesjf, lesliezhai, 
ali-mohamed, jensreuterberg, abetts, sebas, apol, ahiemstra, mart

D26894: Enable publication of API dox on api.kde.org

[Friedrich W. H. Kossebau]

kossebau added a comment.


  So, with only positive feedback so far I would be going to merge this on 31st 
Jan. Or earlier, if you tell me :)

REPOSITORY
  R129 Window Decoration Library

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

To: kossebau, #kwin, graesslin
Cc: zzag, plasma-devel, Orage, LeGast00n, The-Feren-OS-Dev, jraleigh, zachus, 
fbampaloukas, GB_2, ragreen, ZrenBot, ngraham, alexeymin, himcesjf, lesliezhai, 
ali-mohamed, jensreuterberg, abetts, sebas, apol, ahiemstra, mart

D26894: Enable publication of API dox on api.kde.org

[Friedrich W. H. Kossebau]

kossebau updated this revision to Diff 74558.
kossebau added a comment.


  keep Martin noted as maintainer, given no official step-down
  rebase to latest master

REPOSITORY
  R129 Window Decoration Library

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D26894?vs=74305=74558

BRANCH
  addtoapikdeorg

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

AFFECTED FILES
  README.md
  metainfo.yaml

To: kossebau, #kwin, graesslin
Cc: zzag, plasma-devel, Orage, LeGast00n, The-Feren-OS-Dev, jraleigh, zachus, 
fbampaloukas, GB_2, ragreen, ZrenBot, ngraham, alexeymin, himcesjf, lesliezhai, 
ali-mohamed, jensreuterberg, abetts, sebas, apol, ahiemstra, mart

D26894: Enable publication of API dox on api.kde.org

[Friedrich W. H. Kossebau]

kossebau added a comment.


  I stumbled over that metainfo.yaml file and was wondering whether this would 
not be a lib that wants to be covered an api.kde.org.
  So, is kdecoration still a non-deprecated lib? If so, this change should 
trigger addition of KDecoration on api.kde.org, similar like KAsync is 
currently at the toplevel.

REPOSITORY
  R129 Window Decoration Library

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

To: kossebau, #kwin
Cc: plasma-devel, Orage, LeGast00n, The-Feren-OS-Dev, jraleigh, zachus, 
fbampaloukas, GB_2, ragreen, ZrenBot, ngraham, alexeymin, himcesjf, lesliezhai, 
ali-mohamed, jensreuterberg, abetts, sebas, apol, ahiemstra, mart

D26894: Enable publication of API dox on api.kde.org

[Friedrich W. H. Kossebau]

kossebau created this revision.
kossebau added a reviewer: KWin.
Herald added a project: Plasma.
Herald added a subscriber: plasma-devel.
kossebau requested review of this revision.

REPOSITORY
  R129 Window Decoration Library

BRANCH
  addtoapikdeorg

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

AFFECTED FILES
  README.md
  metainfo.yaml

To: kossebau, #kwin
Cc: plasma-devel, Orage, LeGast00n, The-Feren-OS-Dev, jraleigh, zachus, 
fbampaloukas, GB_2, ragreen, ZrenBot, ngraham, alexeymin, himcesjf, lesliezhai, 
ali-mohamed, jensreuterberg, abetts, sebas, apol, ahiemstra, mart

D25984: Load translations

[Friedrich W. H. Kossebau]

kossebau added a comment.


  In D25984#578306 , @kossebau wrote:
  
  > Hm, though now I am confused why calling this from 
`KirigamiPlugin::initializeEngine` fixes things for you, the static struct 
constructor of that startup hook technology in the lib should be invoked before 
during loading, no?
  
  
  Looking at the ECM generated code, that one sees to do the catalog loading in 
the main thread, and if not in the main thread already using a timer event to 
trigger the loading there.
  While the plugin is loaded in another thread (called "QQmlThread" by what my 
debug output told me).
  
INIT CATALOG HOOKUP QThread(0x564b8c8c6fb0, name = "QQmlThread")
INIT ENGINE QThread(0x564b8c3a28d0)
LOADING FROM CATALOG HOOKUP QThread(0x564b8c3a28d0)
  
  Which explains to me why your patch then fixes things.
  
  No idea/proposal about/for a proper solution, but at least my curiousity is 
satisfied for now for what is broken here :/

REPOSITORY
  R169 Kirigami

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

To: broulik, #kirigami, #frameworks, kossebau, aacid, sitter
Cc: davidedmundson, plasma-devel, fbampaloukas, GB_2, domson, dkardarakos, 
ngraham, apol, ahiemstra, mart, hein

D25984: Load translations

[Friedrich W. H. Kossebau]

kossebau added a comment.


  Hm, though now I am confused why calling this from 
`KirigamiPlugin::initializeEngine` fixes things for you, the static struct 
constructor of that startup hook technology in the lib should be invoked before 
during loading, no?
  
  Time to go playing with the actual code myself.

REPOSITORY
  R169 Kirigami

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

To: broulik, #kirigami, #frameworks, kossebau, aacid, sitter
Cc: davidedmundson, plasma-devel, fbampaloukas, GB_2, domson, dkardarakos, 
ngraham, apol, ahiemstra, mart, hein

D25984: Load translations

[Friedrich W. H. Kossebau]

kossebau added a comment.


  In D25984#578299 , @broulik wrote:
  
  > Ok, so turns out, it does call it when the plugin is loaded, but the 
translations are only installed *after* the QML has loaded and processed.
  
  
  Uh, okay, that seems like things need indeed another approach. Actually, any 
librarries using the hook and linked to only from qml plugins would then be 
prone to fail?

REPOSITORY
  R169 Kirigami

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

To: broulik, #kirigami, #frameworks, kossebau, aacid, sitter
Cc: davidedmundson, plasma-devel, fbampaloukas, GB_2, domson, dkardarakos, 
ngraham, apol, ahiemstra, mart, hein

D25984: Load translations

[Friedrich W. H. Kossebau]

kossebau added a comment.


  In D25984#578298 , @broulik wrote:
  
  > Well, whatever it is, it doesn't work. My search field isn't translated and 
I put breakpoints and I only get it load translations for kcoreaddons and 
kjobwidgets.
  
  
  Okay. Which app did you test with? Does it link kcoreaddons? Would poke then 
as well a bit, as I happen to have a related rant blog post lying around ;) ).

REPOSITORY
  R169 Kirigami

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

To: broulik, #kirigami, #frameworks, kossebau, aacid, sitter
Cc: plasma-devel, fbampaloukas, GB_2, domson, dkardarakos, ngraham, apol, 
ahiemstra, davidedmundson, mart, hein

D25984: Load translations

[Friedrich W. H. Kossebau]

kossebau added a comment.


  In D25984#578296 , @broulik wrote:
  
  > We don't link against Kirigami, so the startup routine stuff doesn't apply?
  
  
  `Q_COREAPP_STARTUP_FUNCTION` generates a static struct in the compiled code, 
whose constructor will be invoked on loading the lib which bundles that obect 
code, and the constructor does the registration call (which then also cares for 
directly executing the method if already passed QApp construction phase). See 
below for how exactly.
  
  So at least to what I "know" being loaded in a lib only later at runtime 
still should result in the call being triggered, as also at that time any 
static objects will be constructed/init during lib load.
  
  > And we're way after the QCoreApp constructor at this point.
  
  Yes, but that is something `qAddPreRoutine` deals with, by in that case then 
also executing the method itself:
  
void qAddPreRoutine(QtStartUpFunction p)
{
QStartUpFuncList *list = preRList();
if (!list)
return;
if (QCoreApplication::instance())
p();
// Due to C++11 parallel dynamic initialization, this can be called
// from multiple threads.
QMutexLocker locker();
list->prepend(p); // in case QCoreApplication is re-created, see 
qt_call_pre_routines
}
  
  See how `qAddPreRoutine` code is generated  by `Q_COREAPP_STARTUP_FUNCTION`:
  
#define Q_COREAPP_STARTUP_FUNCTION(AFUNC) \
static void AFUNC ## _ctor_function() {  \
qAddPreRoutine(AFUNC);\
} \
Q_CONSTRUCTOR_FUNCTION(AFUNC ## _ctor_function)
  
  with `Q_CONSTRUCTOR_FUNCTION` being:
  
#ifndef Q_CONSTRUCTOR_FUNCTION
# define Q_CONSTRUCTOR_FUNCTION0(AFUNC) \
namespace { \
static const struct AFUNC ## _ctor_class_ { \
inline AFUNC ## _ctor_class_() { AFUNC(); } \
} AFUNC ## _ctor_instance_; \
}
# define Q_CONSTRUCTOR_FUNCTION(AFUNC) Q_CONSTRUCTOR_FUNCTION0(AFUNC)
#endif

REPOSITORY
  R169 Kirigami

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

To: broulik, #kirigami, #frameworks, kossebau, aacid, sitter
Cc: plasma-devel, fbampaloukas, GB_2, domson, dkardarakos, ngraham, apol, 
ahiemstra, davidedmundson, mart, hein

D25984: Load translations

[Friedrich W. H. Kossebau]

kossebau added a comment.


  In D25984#578291 , @broulik wrote:
  
  > Qt docs say "Adds a global function that will be called from the 
QCoreApplication constructor. " but when we at runtime somewhere load a QML 
plugin we're too late with that.
  
  
  Q_COREAPP_STARTUP_FUNCTION creates code using qAddPreRoutine(), which does 
directly execute the registered method though when the QApp already exists, as 
I tried to hint before, and has since Qt 5.6 at least. (see the above link :) 
). The API dox is missing to define that, indeed, but thinking about it one 
would expect it to happen.
  
  Things might fail though if there is static linking involved perhaps with the 
plugins somehow?

REPOSITORY
  R169 Kirigami

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

To: broulik, #kirigami, #frameworks, kossebau, aacid, sitter
Cc: plasma-devel, fbampaloukas, GB_2, domson, dkardarakos, ngraham, apol, 
ahiemstra, davidedmundson, mart, hein

D25984: Load translations

[Friedrich W. H. Kossebau]

kossebau added a comment.


  > The ECM QM Loader uses Q_COREAPP_STARTUP_FUNCTION which doesn't work for 
things loaded as plugins like QML modules.
  
  Curious, where it exactly does it fail to work? Q_COREAPP_STARTUP_FUNCTION 
being nvoked during lib loading after the QApp instance exists still should 
result in the startup function to be executed from what I remember and just 
looked at again in the code 
(https://code.woboq.org/qt5/qtbase/src/corelib/kernel/qcoreapplication.cpp.html#286),
 see the
  
if (QCoreApplication::instance())
p();
  
  So, what am I missing? :)

REPOSITORY
  R169 Kirigami

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

To: broulik, #kirigami, #frameworks, kossebau, aacid, sitter
Cc: plasma-devel, fbampaloukas, GB_2, domson, dkardarakos, ngraham, apol, 
ahiemstra, davidedmundson, mart, hein

D23005: Fix typo in name of installed CMake Config: Deskop->Desktop

[Friedrich W. H. Kossebau]

This revision was automatically updated to reflect the committed changes.
Closed by commit R858:8b0372d2932e: Fix typo in name of installed CMake Config: 
Deskop-Desktop (authored by kossebau).

REPOSITORY
  R858 Qt Quick Controls 2: Desktop Style

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D23005?vs=70633=70894

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

AFFECTED FILES
  CMakeLists.txt
  KF5QQC2DesktopStyleConfig.cmake.in

To: kossebau, mart, broulik, davidedmundson, apol
Cc: apol, plasma-devel, LeGast00n, The-Feren-OS-Dev, jraleigh, fbampaloukas, 
GB_2, ragreen, ZrenBot, ngraham, alexeymin, himcesjf, lesliezhai, ali-mohamed, 
jensreuterberg, abetts, sebas, ahiemstra, mart

D23005: Fix typo in name of installed CMake Config: Deskop->Desktop

[Friedrich W. H. Kossebau]

kossebau added a comment.


  Np other opinion? Would then go with this in the next days...

REPOSITORY
  R858 Qt Quick Controls 2: Desktop Style

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

To: kossebau, mart, broulik
Cc: apol, plasma-devel, LeGast00n, The-Feren-OS-Dev, jraleigh, fbampaloukas, 
GB_2, ragreen, ZrenBot, ngraham, alexeymin, himcesjf, lesliezhai, ali-mohamed, 
jensreuterberg, abetts, sebas, ahiemstra, mart

D12685: Fix calendar view: hide unused start/end time labels in day events list

[Friedrich W. H. Kossebau]

kossebau abandoned this revision.
kossebau added a comment.


  Sadly lost track of this, and no plans to pick this up again in the 
foreseeable future given other stuff to do, so discarding now to clean up the 
todo stack.

REPOSITORY
  R120 Plasma Workspace

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

To: kossebau, #vdg, #plasma, dvratil
Cc: abetts, mart, plasma-devel, LeGast00n, The-Feren-OS-Dev, jraleigh, 
fbampaloukas, GB_2, ragreen, ZrenBot, ngraham, alexeymin, himcesjf, lesliezhai, 
ali-mohamed, jensreuterberg, sebas, apol, ahiemstra

D23005: Fix typo in name of installed CMake Config: Deskop->Desktop

[Friedrich W. H. Kossebau]

kossebau updated this revision to Diff 70633.
kossebau added a comment.


  - keep old CMake Config files installed
  - no longer create unused version.h file

REPOSITORY
  R858 Qt Quick Controls 2: Desktop Style

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D23005?vs=63296=70633

BRANCH
  fixcmakeconfigname

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

AFFECTED FILES
  CMakeLists.txt
  KF5QQC2DesktopStyleConfig.cmake.in

To: kossebau, mart, broulik
Cc: apol, plasma-devel, LeGast00n, The-Feren-OS-Dev, jraleigh, fbampaloukas, 
GB_2, ragreen, ZrenBot, ngraham, alexeymin, himcesjf, lesliezhai, ali-mohamed, 
jensreuterberg, abetts, sebas, ahiemstra, mart

D23005: Fix typo in name of installed CMake Config: Deskop->Desktop

[Friedrich W. H. Kossebau]

kossebau added a comment.


  Something to consider in time for Plasma 5.18, post 5.17.5 and before 5.17.90)

REPOSITORY
  R858 Qt Quick Controls 2: Desktop Style

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

To: kossebau, mart, broulik
Cc: plasma-devel, LeGast00n, The-Feren-OS-Dev, jraleigh, fbampaloukas, GB_2, 
ragreen, ZrenBot, ngraham, alexeymin, himcesjf, lesliezhai, ali-mohamed, 
jensreuterberg, abetts, sebas, apol, ahiemstra, mart

D22778: Restore option to create a Qt Designer plugin

[Friedrich W. H. Kossebau]

kossebau updated this revision to Diff 70584.
kossebau added a comment.


  Update to latest master

REPOSITORY
  R111 KSysguard Library

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D22778?vs=62646=70584

BRANCH
  readdoptiontogeneratedesignerplugin

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

AFFECTED FILES
  CMakeLists.txt
  lsofui/CMakeLists.txt
  lsofui/designer/CMakeLists.txt
  lsofui/ksysguardlsof.widgets
  processui/CMakeLists.txt
  processui/designer/CMakeLists.txt
  processui/ksysguard.widgets
  signalplotter/CMakeLists.txt
  signalplotter/designer/CMakeLists.txt
  signalplotter/ksignalplotter.widgets

To: kossebau, #plasma, davidedmundson, mart
Cc: plasma-devel, LeGast00n, The-Feren-OS-Dev, jraleigh, fbampaloukas, GB_2, 
ragreen, ZrenBot, ngraham, alexeymin, himcesjf, lesliezhai, ali-mohamed, 
jensreuterberg, abetts, sebas, apol, ahiemstra, mart

D25488: kwayland-integration: fix compilation with no-deprecated build of kwindowsystem

[Friedrich W. H. Kossebau]

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


  For a backport, one could perhaps do this after the includes:
  
#fndef KWINDOWSYSTEM_BUILD_DEPRECATED_SINCE
#ifndef KWINDOWSYSTEM_NO_DEPRECATED
#define KWINDOWSYSTEM_BUILD_DEPRECATED_SINCE(x, y) 1
#else
#define KWINDOWSYSTEM_BUILD_DEPRECATED_SINCE(x, y) 0
#endif
#endif
  
  Otherwise seems fine with me from pure patch reading.

REPOSITORY
  R130 Frameworks integration plugin using KWayland

BRANCH
  master

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

To: dfaure, kossebau, jriddell, davidedmundson
Cc: plasma-devel, LeGast00n, The-Feren-OS-Dev, jraleigh, fbampaloukas, GB_2, 
ragreen, ZrenBot, ngraham, alexeymin, himcesjf, lesliezhai, ali-mohamed, 
jensreuterberg, abetts, sebas, apol, ahiemstra, mart

D25082: [applets/weather] Reduce label minimum width to accommodate narrow vertical panels

[Friedrich W. H. Kossebau]

kossebau resigned from this revision.
kossebau added a comment.


  Sorry, currently no time for Plasma available: see also 
https://mail.kde.org/pipermail/plasma-devel/2019-October/105088.html

REPOSITORY
  R114 Plasma Addons

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

To: ngraham, #vdg, #plasma
Cc: plasma-devel, LeGast00n, The-Feren-OS-Dev, jraleigh, fbampaloukas, GB_2, 
ragreen, ZrenBot, ngraham, alexeymin, himcesjf, lesliezhai, ali-mohamed, 
jensreuterberg, abetts, sebas, apol, ahiemstra, mart

D18961: [WIP] [weather] Migrate nativeInterface config to plasmoid.configuration.*

[Friedrich W. H. Kossebau]

kossebau resigned from this revision.
kossebau added a comment.


  Still sorry for having stalled this effort. Stepping down as maintainer of 
the weather applet now, so also resigning here. Might be the chance to pick 
this up and just move on :)

REPOSITORY
  R114 Plasma Addons

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

To: Zren
Cc: plasma-devel, LeGast00n, The-Feren-OS-Dev, jraleigh, fbampaloukas, GB_2, 
ragreen, ZrenBot, ngraham, alexeymin, himcesjf, lesliezhai, ali-mohamed, 
jensreuterberg, abetts, sebas, apol, ahiemstra, mart

D12944: [weather applet] Show a note why "Show temperature" is disabled

[Friedrich W. H. Kossebau]

kossebau abandoned this revision.
kossebau added a comment.


  No time to care for this more, someone else needs to take over if 
needed/wanted,

REPOSITORY
  R114 Plasma Addons

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

To: kossebau, #plasma
Cc: mart, ngraham, plasma-devel, LeGast00n, The-Feren-OS-Dev, jraleigh, 
fbampaloukas, GB_2, ragreen, ZrenBot, alexeymin, himcesjf, lesliezhai, 
ali-mohamed, jensreuterberg, abetts, sebas, apol, ahiemstra

Re: Weather applet/dataengine: passing on maintainer baton

[Friedrich W. H. Kossebau]

Am Dienstag, 22. Oktober 2019, 00:42:01 CEST schrieb Friedrich W. H. Kossebau:
> * https://bugs.kde.org/buglist.cgi?
> bug_status=__open__=Weather_id=1672869=plasmashell
> (though I remember some more open?)

Indeed. Seems there are 2x components for the Plasma widget, once with 
plasmashell (which I found on my quick search before) and once with kdeplasma-
addons, which has the (sadly) longer list of open bugs I remembered:
https://bugs.kde.org/buglist.cgi?
bug_status=__open__=weather_id=1672882=kdeplasma-addons

Someone(tm) should merge that... /me out 8)

Cheers
Friedrich

Weather applet/dataengine: passing on maintainer baton

[Friedrich W. H. Kossebau]

Hi,

3 and 1/2 years after I adopted the code for the weather applet in kdeplasma-
addons and the respective weather dataengine in plasma-workspace, to make it 
live on in Plasma5 era instead of being moved into the attic*, I feel there 
are too many other things now which have more of my interest, and I am 
slacking in giving the attention when needed, as I could just again see with 
the windy conditions icons patches.

* 
https://frinring.wordpress.com/2016/03/02/will-the-addons-weather-widget-be-revived-for-plasma-5-6/

This includes also any WIP patches of mine to add multi-city support, some 
integration with krunner, integration with the Plasma calendar, a general 
environment/weather report demon or a revival of a Plasma weather wallpaper, 
which have been bitrotting for > 1 year now, with all forecast models 
delivering a 0.0 % chance of any activity in the near future.

I think I am leaving the code in good shape (modern, simple code base, with 
some documentation added, only a few bug reports open*), so it will not fall 
apart the next minute after I turned my back. Besides, I sense there are other 
people around to look after it some more now with me no longer standing by 
(and perhaps even in the way).

* https://bugs.kde.org/buglist.cgi?
bug_status=__open__=Weather_id=1672869=plasmashell
(though I remember some more open?)

So hereby I drop the (in-official) maintainer bacon into the hands of Plasma 
release managers, so they can pass it on as needed/wanted.
Thanks also all for the support I had while working on the applet & dataengine 
code, I never felt alone or lost.

Cheers
Friedrich

D24749: Fix build with older glibc: link there to librt for clock_gettime

[Friedrich W. H. Kossebau]

This revision was automatically updated to reflect the committed changes.
Closed by commit R111:3cd40fede73e: Fix build with older glibc: link there to 
librt for clock_gettime (authored by kossebau).

REPOSITORY
  R111 KSysguard Library

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D24749?vs=68211=68421

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

AFFECTED FILES
  processcore/CMakeLists.txt

To: kossebau, #plasma, davidedmundson, mart
Cc: plasma-devel, LeGast00n, The-Feren-OS-Dev, jraleigh, fbampaloukas, GB_2, 
ragreen, ZrenBot, ngraham, alexeymin, himcesjf, lesliezhai, ali-mohamed, 
jensreuterberg, abetts, sebas, apol, ahiemstra, mart

D24758: [KEditFileType] Add a desktop file

[Friedrich W. H. Kossebau]

kossebau added inline comments.

INLINE COMMENTS

> meven wrote in CMakeLists.txt:57
> We have a bunch of apps to update, I used this because I found it in krusader 
> code

Yes, due to having no proper cmake deprecation warnings there are still some 
with old code. But lots of porting already happened :)

Perhaps KDE_INSTALL_DIRS_NO_DEPRECATED should be started to be enforced on CI :)

REPOSITORY
  R126 KDE CLI Utilities

BRANCH
  master

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

To: meven, broulik, ngraham
Cc: kossebau, plasma-devel, LeGast00n, The-Feren-OS-Dev, jraleigh, 
fbampaloukas, GB_2, ragreen, ZrenBot, ngraham, alexeymin, himcesjf, lesliezhai, 
ali-mohamed, jensreuterberg, abetts, sebas, apol, ahiemstra, mart

D24758: [KEditFileType] Add a desktop file

[Friedrich W. H. Kossebau]

kossebau added inline comments.

INLINE COMMENTS

> CMakeLists.txt:57
>  install( FILES filetypes.desktop  DESTINATION  ${KDE_INSTALL_KSERVICES5DIR} )
> +install(PROGRAMS org.kde.keditfiletype.desktop DESTINATION 
> ${XDG_APPS_INSTALL_DIR} )

KDE_INSTALL_APPDIR, please. XDG_APPS_INSTALL_DIR is deprecated, cmp. 
https://api.kde.org/ecm/kde-module/KDEInstallDirs.html

REPOSITORY
  R126 KDE CLI Utilities

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

To: meven, broulik, ngraham
Cc: kossebau, plasma-devel, LeGast00n, The-Feren-OS-Dev, jraleigh, 
fbampaloukas, GB_2, ragreen, ZrenBot, ngraham, alexeymin, himcesjf, lesliezhai, 
ali-mohamed, jensreuterberg, abetts, sebas, apol, ahiemstra, mart

D24749: Fix build with older glibc: link there to librt for clock_gettime

[Friedrich W. H. Kossebau]

kossebau created this revision.
kossebau added a reviewer: Plasma.
Herald added a project: Plasma.
Herald added a subscriber: plasma-devel.
kossebau requested review of this revision.

REVISION SUMMARY
  Only since glibc version 2.17 -lrt is no longer needed
  
  See same fix done for processui in bb556d8cea2fb77e66970ebc02303becd1c8e8e3 


REPOSITORY
  R111 KSysguard Library

BRANCH
  linkrt

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

AFFECTED FILES
  processcore/CMakeLists.txt

To: kossebau, #plasma
Cc: plasma-devel, LeGast00n, The-Feren-OS-Dev, jraleigh, fbampaloukas, GB_2, 
ragreen, ZrenBot, ngraham, alexeymin, himcesjf, lesliezhai, ali-mohamed, 
jensreuterberg, abetts, sebas, apol, ahiemstra, mart

D24483: [Weather data engine] Handle windy conditions in NOAA backend

[Friedrich W. H. Kossebau]

kossebau added a comment.


  In D24483#544263 , @ngraham wrote:
  
  > To me it makes conceptual sense to display windiness when it's not 
including other severe weather conditions. In those cases, you care more about 
the other conditions than the fact that it's also windy.
  
  
  Different people care about different aspects, and different things are 
severe to them. Someone with a garden might not care about wind, but about 
precipitation. Someone driving a truck will care about wind, but not about rain 
or cloudyness. People commuting by bicycle will care for both. And so on.
  
  > For example if the wind accompanies rain or a storm, the fact that it's 
windy is not very interesting; what you're focusing on is the fact that it's a 
storm! If there's a tornado, of course it's also windy... 
  >  but what you need to be focusing on is the tornado! (this is also a 
condition we don't currently handle)
  
  Yes, chance of tornado, sandstorms, glaze, etc, are something someone (tm) 
should care for one day. But...
  
  > So I would probably favor showing a "windy" icon when it's only windy, or a 
"windy and cloudy" icon when the wind is accompanies by cloudiness as well.
  
  Sounds like you imply sunny with "windy" :) And cloudy is usually not a 
severe condition, unless one is out to watch the stars or pulling solar 
electricity, or? Sunny rather would be severe, e.g. putting human skin into 
danger.
  
  So far I had considered the main condition icon to be a hint to a typical 
pattern of weather, roughly represented by the icon. And not being the place to 
also hint to chances of potential exteme conditions, that would be a separate 
thing (to be done).
  
  And by what I understand the "it's windy" having not deeply researched 
things, it means here "as usual for this type of year here, so we will not 
explitily mention it, but additionally windy".

REPOSITORY
  R120 Plasma Workspace

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

To: ngraham, kossebau, #plasma
Cc: spstarr, plasma-devel, #vdg, LeGast00n, The-Feren-OS-Dev, jraleigh, 
fbampaloukas, GB_2, ragreen, ZrenBot, ngraham, alexeymin, himcesjf, lesliezhai, 
ali-mohamed, jensreuterberg, abetts, sebas, apol, ahiemstra, mart

D24483: [Weather data engine] Handle windy conditions in NOAA backend

[Friedrich W. H. Kossebau]

kossebau added a comment.


  In D24483#544189 , @ngraham wrote:
  
  > Where I live (in the desert), we often have days that are very windy with 
no clouds or rain, especially in the springtime. On such days, the data engine 
always falls back to `IonInterface::NotAvailable`, which is not accurate; a 
forecast //is// available, but we're not handling it.
  
  
  Not disputing that this should be handled.
  
  > Since this new condition is at the end of the conditional, it won't be 
triggered unless it really is windy with no other conditions.
  
  Yes, still curious what this general condition description implies for the 
other conditions, as it also might affect the icon to be done, so what is 
iconic for "weather-wind".
  
  Someone might do an icon showing fast-moving clouds, which would then not be 
matching the windy days as you described.
  
  > I agree that the proposed icon is not very good. I would be okay with 
delaying this until we have a real `weather-wind` icon if you would prefer.
  
  Yes, I would first like to see a narrowing definition what the weather-wind 
icon should be about, as people living in different climatic zones might have 
totally diferent associations. I would have never thought about wind in deserts 
:)
  
  So seems "wind" here could be meant as: moving airmasses also near ground, 
otherwise usual weather conditions in the given area/time of year, thus not 
mentioned?

REPOSITORY
  R120 Plasma Workspace

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

To: ngraham, kossebau, #plasma
Cc: spstarr, plasma-devel, #vdg, LeGast00n, The-Feren-OS-Dev, jraleigh, 
fbampaloukas, GB_2, ragreen, ZrenBot, ngraham, alexeymin, himcesjf, lesliezhai, 
ali-mohamed, jensreuterberg, abetts, sebas, apol, ahiemstra, mart

D24483: [Weather data engine] Handle windy conditions in NOAA backend

[Friedrich W. H. Kossebau]

kossebau added a comment.


  Disclaimer: nowhere a meteorologist myself, kitchen talk quality at best :)
  
  I have to tell I have no idea how "wind" actually matches the category and 
what general cloud/sky conditions could be derived. Where I have lived, wind as 
in: fast moving air masses with resulting air turbulence near the ground has 
been happening with clear sky, cloudy sky, overcast & all kinds of 
precipitation or not. I cannot remember wind to have been the main weather 
property describing the overall condition, unless perhaps being a storm, which 
then usually implies very cloudy sky.
  So for me wind always has been its own separate category, reported next to 
cloudiness and precipitation which both would be used to describe the main 
condition.
  
  The proposed placeholder icon also would not have matched my immediate idea 
if someone said "a windy day" where I would have rather expected a mix of 
clouds and sun. Actually fog would rather be seen with no wind usually?
  
  Do we have a definition what NOAA means when they talk about "windy day", so 
there is an idea what overall condition properties would be mapped onto this 
term instead of any of the others?

REPOSITORY
  R120 Plasma Workspace

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

To: ngraham, kossebau, #plasma
Cc: plasma-devel, #vdg, LeGast00n, The-Feren-OS-Dev, jraleigh, fbampaloukas, 
GB_2, ragreen, ZrenBot, ngraham, alexeymin, himcesjf, lesliezhai, ali-mohamed, 
jensreuterberg, abetts, sebas, apol, ahiemstra, mart

D23840: Enable HiDPI rendering for systemmonitor

[Friedrich W. H. Kossebau]

kossebau added a comment.


  And attributes in general are better set before the application instance is 
created. Some attributes even need that, so defaulting to it is better,

REPOSITORY
  R120 Plasma Workspace

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

To: guoyunhe, #plasma, ngraham
Cc: kossebau, broulik, plasma-devel, LeGast00n, The-Feren-OS-Dev, jraleigh, 
fbampaloukas, GB_2, ragreen, Pitel, ZrenBot, himcesjf, lesliezhai, ali-mohamed, 
jensreuterberg, abetts, sebas, apol, mart

D23840: Enable HiDPI rendering for systemmonitor

[Friedrich W. H. Kossebau]

kossebau added a comment.


  Does this compile? What compiler are you using? At least it does not on CI: 
https://build.kde.org/view/Failing/job/Plasma/job/plasma-workspace/
  
  When calling a static method of a class using the "::", one rather needs to 
use the classname, not the name of an instance of the class.  Or use a ".", but 
that blurs the fact it is a static method, so not recommended.
  
  Please do a fix up :)

REPOSITORY
  R120 Plasma Workspace

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

To: guoyunhe, #plasma, ngraham
Cc: kossebau, broulik, plasma-devel, LeGast00n, The-Feren-OS-Dev, jraleigh, 
fbampaloukas, GB_2, ragreen, Pitel, ZrenBot, himcesjf, lesliezhai, ali-mohamed, 
jensreuterberg, abetts, sebas, apol, mart

D23575: plasnoidviewer: restore support for --list & --list-themes

[Friedrich W. H. Kossebau]

kossebau abandoned this revision.
kossebau added a comment.


  Seems this whole implementation is not useful, as there is dedicated KPackage 
API to use instead (and which then could be used also from KDevelop itself) as 
well as is the question if this feature is wanted to be restored like this.
  
  Idea of this code dump was to help @apol on his plans to unbreak the Plasmoid 
launcher support in KDevelop, as I had this patch around locally from older 
times.
  So without being useful as is, and myself having other TODO things with more 
interest/priority, so will then dump the dump. :)

INLINE COMMENTS

> apol wrote in main.cpp:89
> QDir::NoDotAndDotDot.
> 
> Also you can use entryInfoList and avoid constructing the path inside.

Nice, was not aware of this flag. The place where I copied the code from and 
others I remember can be improved then as well.

> apol wrote in main.cpp:120
> qDebug? Or remove altogether.

Remove altogether?
But the whole idea of the method here is to get a list of the themes on stdout, 
to serve the "--list". Not sure what you mean here.

REPOSITORY
  R118 Plasma SDK

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

To: kossebau, #plasma, apol
Cc: plasma-devel, LeGast00n, The-Feren-OS-Dev, jraleigh, fbampaloukas, GB_2, 
ragreen, Pitel, ZrenBot, himcesjf, lesliezhai, ali-mohamed, jensreuterberg, 
abetts, sebas, apol, mart

D23575: plasnoidviewer: restore support for --list & --list-themes

[Friedrich W. H. Kossebau]

kossebau added a comment.


  [09:29]  kpackagetool5 --g --list --type Plasma/Applet for plasmoids
  [09:30]  kpackagetool5 --g --list --type Plasma/Theme for themes
  [09:31]  bshah: instinctively for me it makes sense to have one 
tool to remember when developing applets. I readded that code to plasnoidviewer 
instead of adding it to kdevelop directly, as I sometimes wishes I could easily 
query applets as well, if I was unsure about the applet id I wanted to test
  [09:32]  bshah: kpackagetool5 also only gives me the ids, where 
ideally we would also have the display names to show. can kpackagetool5 output 
those as well?
  [09:32]  (right now kdevelop only shows the ids as well, but I 
would do a follow-up patch to improive that)
  
  So if this should not be readded to plasmoidviewer, it might be. I just found 
it useful to have one tool name to remember and convenience methods, instead of 
yet another tool with more complicated query arguments to remmeber and assemble.
  
  And if KDevelop should rather use kpackagetool5, it might be better to not do 
this via programm exectution of another process and parsing of stdout, but 
instead directly using kpackage library and getting direct access to data 
structures wanted. But that needs to be done by someone interested in the 
plasmoid launcher plugin, which I am not.

REPOSITORY
  R118 Plasma SDK

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

To: kossebau, #plasma, apol
Cc: plasma-devel, LeGast00n, The-Feren-OS-Dev, jraleigh, fbampaloukas, GB_2, 
ragreen, Pitel, ZrenBot, himcesjf, lesliezhai, ali-mohamed, jensreuterberg, 
abetts, sebas, apol, mart

D23575: plasnoidviewer: restore support for --list & --list-themes

[Friedrich W. H. Kossebau]

kossebau created this revision.
kossebau added reviewers: Plasma, apol.
Herald added a project: Plasma.
Herald added a subscriber: plasma-devel.
kossebau requested review of this revision.

REVISION SUMMARY
  Got dropped during porting to Qt5 (last commit cleaning up dead code
  was f458c1bd6263064fabe9a2ad20b5ad0da4e8dd9a), but at least the
  plasmoid launcher plugin from kdevelop relies on those parameters
  when querying for possible values, as well as might users prefer to
  query the available/seen applets & themes as well.

TEST PLAN
  Config UI for plasmoid launcher in KDevelop shows again the list of
  available applets as well as themes. Calling manually from cmdl also lists
  expected applets resp. themes.

REPOSITORY
  R118 Plasma SDK

BRANCH
  restoreplasmoidviewerargslist_listthemes

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

AFFECTED FILES
  plasmoidviewer/main.cpp

To: kossebau, #plasma, apol
Cc: plasma-devel, LeGast00n, The-Feren-OS-Dev, jraleigh, fbampaloukas, GB_2, 
ragreen, Pitel, ZrenBot, himcesjf, lesliezhai, ali-mohamed, jensreuterberg, 
abetts, sebas, apol, mart

D23417: libtaskmanager: fix launch url for startup info with pathless desktop file

[Friedrich W. H. Kossebau]

This revision was automatically updated to reflect the committed changes.
Closed by commit R120:4f309328ee00: libtaskmanager: fix launch url for startup 
info with pathless desktop file (authored by kossebau).

CHANGED PRIOR TO COMMIT
  https://phabricator.kde.org/D23417?vs=64529=64665#toc

REPOSITORY
  R120 Plasma Workspace

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D23417?vs=64529=64665

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

AFFECTED FILES
  libtaskmanager/startuptasksmodel.cpp

To: kossebau, hein, broulik, #plasma, davidedmundson
Cc: davidedmundson, plasma-devel, LeGast00n, The-Feren-OS-Dev, jraleigh, 
fbampaloukas, GB_2, ragreen, Pitel, ZrenBot, himcesjf, lesliezhai, ali-mohamed, 
jensreuterberg, abetts, sebas, apol, mart

D23417: libtaskmanager: fix launch url for startup info with pathless desktop file

[Friedrich W. H. Kossebau]

kossebau created this revision.
kossebau added a reviewer: hein.
Herald added a project: Plasma.
Herald added a subscriber: plasma-devel.
kossebau requested review of this revision.

REVISION SUMMARY
  Also drop checking if the suffix exists, the code is only reached
  because this condition has been checked before
  
  Seen while browsing code, no app known to me which would set a non-absolute
  desktop file.

REPOSITORY
  R120 Plasma Workspace

BRANCH
  fixsuffixchopping

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

AFFECTED FILES
  libtaskmanager/startuptasksmodel.cpp

To: kossebau, hein
Cc: plasma-devel, LeGast00n, The-Feren-OS-Dev, jraleigh, fbampaloukas, GB_2, 
ragreen, Pitel, ZrenBot, himcesjf, lesliezhai, ali-mohamed, jensreuterberg, 
abetts, sebas, apol, mart

D23307: [weather] [envcan] Add additional current condition icon mappings

[Friedrich W. H. Kossebau]

kossebau accepted this revision.
kossebau added a comment.


  Can you push this to the 5.16 branch? No new string for translators, so 
should be fine to improve for stable.

REPOSITORY
  R120 Plasma Workspace

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

To: spstarr, #plasma, ngraham, kossebau
Cc: ngraham, plasma-devel, LeGast00n, The-Feren-OS-Dev, jraleigh, fbampaloukas, 
GB_2, ragreen, Pitel, ZrenBot, himcesjf, lesliezhai, ali-mohamed, 
jensreuterberg, abetts, sebas, apol, mart

D23325: Use non-deprecated .metainfo.xml filename extension

[Friedrich W. H. Kossebau]

kossebau added a comment.


  I assume you also change the cmake install command in app/CMakeLists.txt in 
the final patch, though :)

REPOSITORY
  R124 System Settings

BRANCH
  appdata-to-metainfo (branched from Plasma/5.16)

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

To: ngraham, kossebau, apol
Cc: plasma-devel, LeGast00n, The-Feren-OS-Dev, jraleigh, fbampaloukas, GB_2, 
ragreen, Pitel, ZrenBot, himcesjf, lesliezhai, ali-mohamed, jensreuterberg, 
abetts, sebas, apol, mart

D23306: Add AppStream metadata file

[Friedrich W. H. Kossebau]

kossebau added a comment.


  @ngraham You used the "appdata.xml" file suffix here. I noticed yesterday 
when reading the spec that it now declares that as legacy suffix:
  
  > While desktop-application metadata is commonly stored in 
/usr/share/metainfo/%{id}.metainfo.xml (with a .metainfo.xml extension), using 
a .appdata.xml extension is also permitted for this component type for legacy 
compatibility.
  
  From 
https://www.freedesktop.org/software/appstream/docs/sect-Metadata-Application.html
  
  Given Plasma targets newer system, perhaps it makes sense to start right away 
with a metainfo.xml suffix?

REPOSITORY
  R124 System Settings

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

To: ngraham, apol, mak, #plasma
Cc: kossebau, plasma-devel, LeGast00n, The-Feren-OS-Dev, jraleigh, 
fbampaloukas, GB_2, ragreen, Pitel, ZrenBot, himcesjf, lesliezhai, ali-mohamed, 
jensreuterberg, abetts, sebas, apol, mart

D23306: Add AppStream metadata file

[Friedrich W. H. Kossebau]

kossebau added a comment.


  Hi @mak, so seems we appdata content creators are still unsure what to do, 
allow me to put the last question of last night again to your attention:
  
  In D23306#515666 , @kossebau wrote:
  
  > In D23306#515662 , @mak wrote:
  >
  > > > - if there are two desktop files referenced by  where one 
has the ignore entry set, will this overrule the "Data will only be fetched 
from a desktop file if one  tag is present" rules above?
  > >
  > > No. A `launchable` tag always beats whatever was defined in the 
desktop-entry file itself, so if there is one launchable tag, the .desktop 
entry file will be taken into consideration no matter what was defined in it 
(to e.g. merge in category information). Any equivalent data in the metainfo 
file beats that of the desktop-entry file though. If there are multiple 
`launchable` entries, the generator has no idea which .desktop file to read, so 
rather than reading any and getting information wrong, it will read none 
(requiring the metainfo author to add all data they want in there explicitly).
  > >  This could maybe be made smarter, but tbh this case is so rare that just 
making the metainfo files more complete in such events seems like the better 
approach.
  >
  >
  > So, in our case here, `systemsettings.desktop` actually means there is 
no need to add `X-AppStream-Ignore=true` to "kdesystemsettings.desktop" ? 
Because the generators would ignore it already due to a `` present 
and pointing to the other desktop file?

REPOSITORY
  R124 System Settings

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

To: ngraham, apol, mak, #plasma
Cc: kossebau, plasma-devel, LeGast00n, The-Feren-OS-Dev, jraleigh, 
fbampaloukas, GB_2, ragreen, Pitel, ZrenBot, himcesjf, lesliezhai, ali-mohamed, 
jensreuterberg, abetts, sebas, apol, mart

D23306: Add AppStream metadata file

[Friedrich W. H. Kossebau]

kossebau added inline comments.

INLINE COMMENTS

> kdesystemsettings.desktop:163
>  X-DBUS-ServiceName=org.kde.systemsettings
> +# Otherwise Discover and other software centers show two System Settings 
> entries
> +X-AppStream-Ignore=true

For what I understood from "No. A launchable tag always beats whatever was 
defined in the desktop-entry file itself, so if there is one launchable tag, 
the .desktop entry file will be taken into consideration no matter what was 
defined in it (to e.g. merge in category information).  If there are multiple 
launchable entries, the generator has no idea which .desktop file to read, so 
rather than reading any and getting information wrong, it will read none 
(requiring the metainfo author to add all data they want in there explicitly)." 
this is not needed here or rather without effect, given there the appdata file 
has one  entry pointing to the other desktop file.

REPOSITORY
  R124 System Settings

BRANCH
  add-appdata-file (branched from master)

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

To: ngraham, apol, mak, #plasma
Cc: kossebau, plasma-devel, LeGast00n, The-Feren-OS-Dev, jraleigh, 
fbampaloukas, GB_2, ragreen, Pitel, ZrenBot, himcesjf, lesliezhai, ali-mohamed, 
jensreuterberg, abetts, sebas, apol, mart

D23306: Add AppStream metadata file

[Friedrich W. H. Kossebau]

kossebau added a comment.


  In D23306#515662 , @mak wrote:
  
  > In D23306#515616 , @kossebau 
wrote:
  >
  > > Thanks! Though reading it, leaves open questions with me:
  > >
  > > - what is meant by "referenced"? only via ?
  >
  >
  > In modern metainfo files yes, only via `launchable`. However, if a 
component `id` has a .desktop suffix, as was required in the past, and a 
matching .desktop file is found, that also counts as referenced and the 
desktop-entry file will be read.
  
  
  As developer trying to write metainfo files, I would welcome this logic also 
documented n the docs. The current content of the docs is confusing to me at 
least.
  
  >> - if there are two desktop files referenced by  where one has 
the ignore entry set, will this overrule the "Data will only be fetched from a 
desktop file if one  tag is present" rules above?
  > 
  > No. A `launchable` tag always beats whatever was defined in the 
desktop-entry file itself, so if there is one launchable tag, the .desktop 
entry file will be taken into consideration no matter what was defined in it 
(to e.g. merge in category information). Any equivalent data in the metainfo 
file beats that of the desktop-entry file though. If there are multiple 
`launchable` entries, the generator has no idea which .desktop file to read, so 
rather than reading any and getting information wrong, it will read none 
(requiring the metainfo author to add all data they want in there explicitly).
  >  This could maybe be made smarter, but tbh this case is so rare that just 
making the metainfo files more complete in such events seems like the better 
approach.
  
  So, in our case here, `systemsettings.desktop` actually means there is 
no need to add `X-AppStream-Ignore=true` to "kdesystemsettings.desktop" ? 
Because the generators would ignore it already due to a `` present 
and pointing to the other desktop file?

REPOSITORY
  R124 System Settings

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

To: ngraham, apol, mak, #plasma
Cc: kossebau, plasma-devel, LeGast00n, The-Feren-OS-Dev, jraleigh, 
fbampaloukas, GB_2, ragreen, Pitel, ZrenBot, himcesjf, lesliezhai, ali-mohamed, 
jensreuterberg, abetts, sebas, apol, mart

D23306: Add AppStream metadata file

[Friedrich W. H. Kossebau]

kossebau added a comment.


  In D23306#515609 , @mak wrote:
  
  > @kossebau How to hide .desktop files from AppStream is now more visible in 
https://www.freedesktop.org/software/appstream/docs/sect-Metadata-Application.html#spec-appdata-introduction
 as a hint.
  
  
  Thanks! Though reading it, leaves open questions with me:
  
  - what is meant by "referenced"? only via ?
  - if there are two desktop files referenced by  where one has the 
ignore entry set, will this overrule the "Data will only be fetched from a 
desktop file if one  tag is present" rules above?

REPOSITORY
  R124 System Settings

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

To: ngraham, apol, mak, #plasma
Cc: kossebau, plasma-devel, LeGast00n, The-Feren-OS-Dev, jraleigh, 
fbampaloukas, GB_2, ragreen, Pitel, ZrenBot, himcesjf, lesliezhai, ali-mohamed, 
jensreuterberg, abetts, sebas, apol, mart

D23306: Add AppStream metadata file

[Friedrich W. H. Kossebau]

kossebau added a comment.


  @mak: tnanks for the hint. will also see to use X-AppStream-Ignore for 
kdevelop then. any chance we can see this trick documented on 
https://www.freedesktop.org/software/appstream/docs/sect-Metadata-Application.html
 , please? :)

REPOSITORY
  R124 System Settings

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

To: ngraham, apol, mak, #plasma
Cc: kossebau, plasma-devel, LeGast00n, The-Feren-OS-Dev, jraleigh, 
fbampaloukas, GB_2, ragreen, Pitel, ZrenBot, himcesjf, lesliezhai, ali-mohamed, 
jensreuterberg, abetts, sebas, apol, mart

D23302: Stop installing two desktop files

[Friedrich W. H. Kossebau]

kossebau added a comment.


  As KDevelop is affected similar, because we want two different entries to 
appear in the system application menu, can someone tell where appstream defines 
that there shall be only one menu desltop file per application? Why do those 
installers even look at the menu entry defining desktop files, should they not 
use the appdata files to model their world of application entities?
  
  Can't the "world of appstream installers and checkers" not be adapted to the 
actual real world?

REPOSITORY
  R124 System Settings

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

To: ngraham, apol, #plasma
Cc: kossebau, plasma-devel, LeGast00n, The-Feren-OS-Dev, jraleigh, 
fbampaloukas, GB_2, ragreen, Pitel, ZrenBot, himcesjf, lesliezhai, ali-mohamed, 
jensreuterberg, abetts, sebas, apol, mart

D23005: Fix typo in name of installed CMake Config: Deskop->Desktop

[Friedrich W. H. Kossebau]

kossebau added a comment.


  Only current user known is plasma-desktop, from 
R119:737b114c2fa5bf0b01951eeb2eef22ce7fcdcfa1 
 No 
other hits seen on internet
  
  No idea what is the most simple approach here, given KF releases are 
branchless, and Plasma has branches, and there are rolling distributions and 
non-rolling distributions, thus combining old KF and new Plasma, as well as new 
KF and new Plasma.
  
  Perhaps install backward-compat version, and drop once Plasma 5.16 is no 
longer released due to Plasma 5.17 ?

REPOSITORY
  R858 Qt Quick Controls 2: Desktop Style

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

To: kossebau, mart, broulik
Cc: plasma-devel, LeGast00n, jraleigh, fbampaloukas, GB_2, ragreen, Pitel, 
ZrenBot, himcesjf, lesliezhai, ali-mohamed, jensreuterberg, abetts, sebas, 
apol, mart

D23005: Fix typo in name of installed CMake Config: Deskop->Desktop

[Friedrich W. H. Kossebau]

kossebau created this revision.
kossebau added reviewers: mart, broulik.
Herald added a project: Plasma.
Herald added a subscriber: plasma-devel.
kossebau requested review of this revision.

REPOSITORY
  R858 Qt Quick Controls 2: Desktop Style

BRANCH
  fixcmakeconfigname

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

AFFECTED FILES
  CMakeLists.txt
  KF5QQC2DeskopStyleConfig.cmake.in
  KF5QQC2DesktopStyleConfig.cmake.in

To: kossebau, mart, broulik
Cc: plasma-devel, LeGast00n, jraleigh, fbampaloukas, GB_2, ragreen, Pitel, 
ZrenBot, himcesjf, lesliezhai, ali-mohamed, jensreuterberg, abetts, sebas, 
apol, mart

D22778: [WIP] Restore option to create a Qt Designer plugin

[Friedrich W. H. Kossebau]

kossebau updated this revision to Diff 62646.
kossebau added a comment.


  also port the other two plugins

REPOSITORY
  R111 KSysguard Library

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D22778?vs=62645=62646

BRANCH
  readdoptiontogeneratedesignerplugin

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

AFFECTED FILES
  CMakeLists.txt
  lsofui/CMakeLists.txt
  lsofui/designer/CMakeLists.txt
  lsofui/ksysguardlsof.widgets
  processui/CMakeLists.txt
  processui/designer/CMakeLists.txt
  processui/ksysguard.widgets
  signalplotter/CMakeLists.txt
  signalplotter/designer/CMakeLists.txt
  signalplotter/ksignalplotter.widgets

To: kossebau
Cc: plasma-devel, LeGast00n, jraleigh, fbampaloukas, GB_2, ragreen, Pitel, 
ZrenBot, himcesjf, lesliezhai, ali-mohamed, jensreuterberg, abetts, sebas, 
apol, mart

D22778: [WIP] Restore option to create a Qt Designer plugin

[Friedrich W. H. Kossebau]

kossebau created this revision.
Herald added a project: Plasma.
Herald added a subscriber: plasma-devel.
kossebau requested review of this revision.

REVISION SUMMARY
  Had been missing out the port to Qt5/KF5 so far
  Using ECMAddQtDesignerPlugin reduces added dependencies to QtUIPlugin
  Option allows to disable feature where not needed

REPOSITORY
  R111 KSysguard Library

BRANCH
  readdoptiontogeneratedesignerplugin

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

AFFECTED FILES
  CMakeLists.txt
  processui/CMakeLists.txt
  processui/designer/CMakeLists.txt
  processui/ksysguard.widgets

To: kossebau
Cc: plasma-devel, LeGast00n, jraleigh, fbampaloukas, GB_2, ragreen, Pitel, 
ZrenBot, himcesjf, lesliezhai, ali-mohamed, jensreuterberg, abetts, sebas, 
apol, mart

D11234: [DrKonqi] Show debug button when KDevelop session is running

[Friedrich W. H. Kossebau]

kossebau added a comment.


  Ping?

REPOSITORY
  R871 DrKonqi

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

To: croick, #plasma_workspaces, apol, mwolff, #kdevelop, sitter
Cc: kossebau, plasma-devel, LeGast00n, jraleigh, fbampaloukas, GB_2, ragreen, 
Pitel, ZrenBot, himcesjf, lesliezhai, ali-mohamed, jensreuterberg, abetts, 
sebas, apol, mart

D21784: Remove accidentally slipped back traces of cmake code for Plasma style

[Friedrich W. H. Kossebau]

This revision was automatically updated to reflect the committed changes.
Closed by commit R169:89b9f8768ee4: Remove accidentally slipped back traces of 
cmake code for Plasma style (authored by kossebau).

REPOSITORY
  R169 Kirigami

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D21784?vs=59739=60133

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

AFFECTED FILES
  src/CMakeLists.txt

To: kossebau, mart
Cc: plasma-devel, fbampaloukas, domson, dkardarakos, apol, davidedmundson, 
mart, hein

D21803: PanelView: align setting of masks with how it's done for dialogs/tooltips

[Friedrich W. H. Kossebau]

This revision was automatically updated to reflect the committed changes.
Closed by commit R120:f65a0eee09da: PanelView: align setting of masks with how 
its done for dialogs/tooltips (authored by kossebau).

REPOSITORY
  R120 Plasma Workspace

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D21803?vs=59800=59882

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

AFFECTED FILES
  shell/panelview.cpp
  shell/panelview.h

To: kossebau, #plasma, hein
Cc: hein, plasma-devel, LeGast00n, jraleigh, GB_2, ragreen, Pitel, ZrenBot, 
himcesjf, lesliezhai, ali-mohamed, jensreuterberg, abetts, sebas, apol, mart

D21803: PanelView: align setting of masks with how it's done for dialogs/tooltips

[Friedrich W. H. Kossebau]

kossebau updated this revision to Diff 59800.
kossebau added a comment.


  for completeness also remove mask for m_backgroundHints == 
Plasma::Types::NoBackground

REPOSITORY
  R120 Plasma Workspace

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D21803?vs=59798=59800

BRANCH
  alignpanelmaskhandlingtodialog

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

AFFECTED FILES
  shell/panelview.cpp
  shell/panelview.h

To: kossebau, #plasma
Cc: plasma-devel, LeGast00n, jraleigh, GB_2, ragreen, Pitel, ZrenBot, himcesjf, 
lesliezhai, ali-mohamed, jensreuterberg, abetts, sebas, apol, mart

D21803: PanelView: align setting of masks with how it's done for dialogs/tooltips

[Friedrich W. H. Kossebau]

kossebau added a comment.


  Compare with DialogPrivate::updateTheme(): 
https://phabricator.kde.org/source/plasma-framework/browse/master/src/plasmaquick/dialog.cpp$229

REPOSITORY
  R120 Plasma Workspace

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

To: kossebau, #plasma
Cc: plasma-devel, LeGast00n, jraleigh, GB_2, ragreen, Pitel, ZrenBot, himcesjf, 
lesliezhai, ali-mohamed, jensreuterberg, abetts, sebas, apol, mart

D21803: PanelView: align setting of masks with how it's done for dialogs/tooltips

[Friedrich W. H. Kossebau]

kossebau created this revision.
kossebau added a reviewer: Plasma.
Herald added a project: Plasma.
Herald added a subscriber: plasma-devel.
kossebau requested review of this revision.

REVISION SUMMARY
  With Plasma dialogs & tooltips the mask is only set on the widget itself
  if compositing is off. Instead is the mask explicitly passed for the
  KWindowEffects.
  The recent changes to fix the blurbehind & contrast mask with panels
  instead turned to always set the mask on the widget. For some reason
  yet to be understood this can sometimes result in an offset by a pixel
  between the mask used for painting and the mask used for the window effects.
  
  Aligning the mask setting code with the one for dialogs & tooltips makes
  the symptom go away for now, and also delivers consistency.
  
  CCBBUG: 406380

TEST PLAN
  Using different themes, including Adapta & Arc Dark, a gap can no longer
  been seen. Only with compositing turned off, which is old behaviour due to
  the real bug yet to understand completly.
  Resizing panels or changing screen resolution also works without breaking
  rendering or panel contents interaction.

REPOSITORY
  R120 Plasma Workspace

BRANCH
  alignpanelmaskhandlingtodialog

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

AFFECTED FILES
  shell/panelview.cpp
  shell/panelview.h

To: kossebau, #plasma
Cc: plasma-devel, LeGast00n, jraleigh, GB_2, ragreen, Pitel, ZrenBot, himcesjf, 
lesliezhai, ali-mohamed, jensreuterberg, abetts, sebas, apol, mart

D21802: move various properties away from qapp and to kaboutdata

[Friedrich W. H. Kossebau]

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


  I would leave out the explicit setting of otherwise default values, but 
people's preferences differ :)

INLINE COMMENTS

> main.cpp:78
>   i18n("(C) 2000-2018, The DrKonqi Authors"));
> +aboutData.setOrganizationDomain(QByteArrayLiteral("kde.org"));
> +aboutData.setDesktopFileName(QStringLiteral("org.kde.drkonqi"));

That is the default (in case no homepage is given)., other places then do not 
set it explicitly, for consistency might also do this here.

> main.cpp:79
> +aboutData.setOrganizationDomain(QByteArrayLiteral("kde.org"));
> +aboutData.setDesktopFileName(QStringLiteral("org.kde.drkonqi"));
>  aboutData.addAuthor(i18nc("@info:credit","Hans Petter Bieker"), 
> QString(),

This also is the implicit value, composed from (default) organization domain 
and the component name (as defined in the API docs contract). Other places also 
do not set it explicitly, so one might also not do this here.

REPOSITORY
  R871 DrKonqi

BRANCH
  Plasma/5.16

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

To: sitter, kossebau
Cc: plasma-devel, LeGast00n, ericadams, jraleigh, GB_2, ragreen, Pitel, 
ZrenBot, himcesjf, lesliezhai, ali-mohamed, jensreuterberg, abetts, sebas, 
apol, mart

D21799: actually set kaboutdata as application aboutdata

[Friedrich W. H. Kossebau]

kossebau added inline comments.

INLINE COMMENTS

> main.cpp:89
>   QStringLiteral("sp...@kde.org"));
> +KAboutData::setApplicationData(aboutData);
>  qa.setWindowIcon(QIcon::fromTheme(QStringLiteral("tools-report-bug"), 
> qa.windowIcon()));

This is partially redundant though with all the QCoreApplication::set* above, 
as well as qa.setDesktopFileName below. Those should be removed then for clean 
code.

REPOSITORY
  R871 DrKonqi

BRANCH
  Plasma/5.16

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

To: sitter, #plasma, davidedmundson
Cc: kossebau, plasma-devel, LeGast00n, ericadams, jraleigh, GB_2, ragreen, 
Pitel, ZrenBot, himcesjf, lesliezhai, ali-mohamed, jensreuterberg, abetts, 
sebas, apol, mart

D21784: Remove accidentally slipped back traces of cmake code for Plasma style

[Friedrich W. H. Kossebau]

kossebau created this revision.
kossebau added a reviewer: mart.
Herald added a project: Kirigami.
Herald added a subscriber: plasma-devel.
kossebau requested review of this revision.

REVISION SUMMARY
  Removed in e914e6323277f7963334897410bd9b7f8341f2ed 
,
  accidentally added back in 8c34dde112e7166dd0ba116022a70586a7c5ade6 


REPOSITORY
  R169 Kirigami

BRANCH
  removedeadcmakecode

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

AFFECTED FILES
  src/CMakeLists.txt

To: kossebau, mart
Cc: plasma-devel, domson, dkardarakos, apol, davidedmundson, mart, hein

D20898: WIP: [kcms/desktoptheme] Switch knsrc to "Plasma 5 Theme" category

[Friedrich W. H. Kossebau]

kossebau abandoned this revision.
kossebau added a comment.


  There is no agreement that splitting off a separate category is the way to 
move forward, so discarding.

REPOSITORY
  R119 Plasma Desktop

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

To: kossebau, #plasma, apol, leinir, mart
Cc: plasma-devel, jraleigh, GB_2, ragreen, Pitel, ZrenBot, himcesjf, 
lesliezhai, ali-mohamed, jensreuterberg, abetts, sebas, apol, mart

D21097: Handle apps which set the desktopFileName property with filename suffix

[Friedrich W. H. Kossebau]

This revision was automatically updated to reflect the committed changes.
Closed by commit R135:0e50f23c4c43: Handle apps which set the desktopFileName 
property with filename suffix (authored by kossebau).

REPOSITORY
  R135 Integration for Qt applications in Plasma

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D21097?vs=57805=58132

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

AFFECTED FILES
  src/platformtheme/x11integration.cpp

To: kossebau, #plasma, broulik, davidedmundson
Cc: ngraham, plasma-devel, jraleigh, GB_2, ragreen, Pitel, ZrenBot, lesliezhai, 
ali-mohamed, jensreuterberg, abetts, sebas, apol, mart

D21226: search for a default wallpaper in lookandfeel

[Friedrich W. H. Kossebau]

kossebau added a comment.


  BTW, there is also still code in place to support Plasma Themes defining a 
default wallpaper (or even deploy some more). Though the default & the further 
are not listed in the Image wallpaper config, also is the config not offering 
any hint about the default or to reset to using any default.
  
  Has this been considered already? Only noticed recently, but did not want to 
create a new theme work can for me :)
  
  Given lookandfeel also allows to set Plasma Theme, should the default 
wallpaper image really be duplicated as another property also with the 
LookAndFeel theme?

REPOSITORY
  R120 Plasma Workspace

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

To: mart, #plasma
Cc: kossebau, davidedmundson, plasma-devel, jraleigh, GB_2, ragreen, Pitel, 
ZrenBot, lesliezhai, ali-mohamed, jensreuterberg, abetts, sebas, apol, mart

Re: Review Request: plasma-thunderbolt

[Friedrich W. H. Kossebau]

Am Mittwoch, 15. Mai 2019, 15:27:07 CEST schrieb Daniel Vrátil:
> Thus I'd kindly ask you to take one more look at the codebase [1] and let me
> know if there are any more issues to fix, or if we can proceed to include
> this in the next Plasma release.

Pushed some small fixes to toplevel CMakeLists.txt

Other things seen on quick look at code (also not tested runtime):
* kded misses a Messages.sh file.
* no COPYRIGHT license files in the repo
* kde_enable_exceptions() duplicated a few times, perhaps only do in subdirs 
where needed or use of kde_target_enable_exceptions() if fitting
* libkbolt being a private library could be reflected in the libname, also get  
   
install(TARGETS kbolt ${KDE_INSTALL_TARGETS_DEFAULT_ARGS} LIBRARY 
NAMELINK_SKIP)

Cheers
Friedrich

D14147: Port from GConf to GSettings

[Friedrich W. H. Kossebau]

kossebau added a comment.


  In D14147#443705 , @kossebau wrote:
  
  > Seems this patch sadly broke the build on FreeBSD: 
https://build.kde.org/job/Plasma/view/Everything/job/plasma-pa/job/kf5-qt5%20FreeBSDQt5.12/18/
  
  
  Solved for now with fba8f7327aaf9869f2873068842970cabb1c8a0b 


REPOSITORY
  R115 Plasma Audio Volume Applet

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

To: nicolasfella, drosca, davidedmundson
Cc: fvogt, kossebau, ngraham, pino, lbeltrame, evpokp, rikmills, broulik, 
asturmlechner, plasma-devel, jraleigh, GB_2, ragreen, Pitel, ZrenBot, 
lesliezhai, ali-mohamed, jensreuterberg, abetts, sebas, apol, mart

D14147: Port from GConf to GSettings

[Friedrich W. H. Kossebau]

kossebau added inline comments.

INLINE COMMENTS

> FindGIO.cmake:20
> +include(UsePkgConfig)
> +pkgconfig(gio-2.0 _LibGIOIncDir _LibGIOLinkDir _LibGIOLinkFlags 
> _LibGIOCflags)
> +endif(NOT WIN32)

It seems `_LibGIOLinkFlags`, `_LibGIOLinkDir` & `_LibGIOCflags` are not 
propagated  into the build. So if e.g. the libraries are not in default lib 
dir, linking will fail, cmp. 
https://build.kde.org/view/Failing/job/Plasma/job/plasma-pa/job/kf5-qt5%20FreeBSDQt5.12/18/

Please give this another look & also compare with other pkgconfig() using Find' 
macros.

REPOSITORY
  R115 Plasma Audio Volume Applet

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

To: nicolasfella, drosca, davidedmundson
Cc: fvogt, kossebau, ngraham, pino, lbeltrame, evpokp, rikmills, broulik, 
asturmlechner, plasma-devel, jraleigh, GB_2, ragreen, Pitel, ZrenBot, 
lesliezhai, ali-mohamed, jensreuterberg, abetts, sebas, apol, mart

D21176: PanelView: update mask on window on change of panelMask property

[Friedrich W. H. Kossebau]

This revision was automatically updated to reflect the committed changes.
Closed by commit R120:f8d5e1a24e97: PanelView: update mask on window on change 
of panelMask property (authored by kossebau).

REPOSITORY
  R120 Plasma Workspace

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D21176?vs=57974=58090

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

AFFECTED FILES
  shell/panelview.cpp
  shell/panelview.h

To: kossebau, #plasma, mart
Cc: plasma-devel, jraleigh, GB_2, ragreen, Pitel, ZrenBot, lesliezhai, 
ali-mohamed, jensreuterberg, abetts, sebas, apol, mart

D21176: PanelView: update mask on window on change of panelMask property

[Friedrich W. H. Kossebau]

kossebau updated this revision to Diff 57974.
kossebau added a comment.


  keep old code for KF 5.58 compat

REPOSITORY
  R120 Plasma Workspace

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D21176?vs=57965=57974

BRANCH
  updatepanelmaskonchange

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

AFFECTED FILES
  shell/panelview.cpp
  shell/panelview.h

To: kossebau, #plasma
Cc: plasma-devel, jraleigh, GB_2, ragreen, Pitel, ZrenBot, lesliezhai, 
ali-mohamed, jensreuterberg, abetts, sebas, apol, mart

D21176: PanelView: update mask on window on change of panelMask property

[Friedrich W. H. Kossebau]

kossebau created this revision.
kossebau added a reviewer: Plasma.
Herald added a project: Plasma.
Herald added a subscriber: plasma-devel.
kossebau requested review of this revision.

REPOSITORY
  R120 Plasma Workspace

BRANCH
  updatepanelmaskonchange

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

AFFECTED FILES
  shell/panelview.cpp
  shell/panelview.h

To: kossebau, #plasma
Cc: plasma-devel, jraleigh, GB_2, ragreen, Pitel, ZrenBot, lesliezhai, 
ali-mohamed, jensreuterberg, abetts, sebas, apol, mart