Re: qqc2-breeze-style

[Nate Graham]

On 4/12/21 3:26 PM, Carl Schwan wrote:

And I still have the same worries as before. Building a universal theming
system will takes **years** to make in a way that won't feel like a big
regression for our users.


[...]


Anyway, if someone wants to invest a lot of time in creating the unified
theme, I won't stop them and I would happy to be proved wrong about my worries.
But until then I will use the breeze qqc2 style on the desktop too
because it's smoother and less buggy than the desktop style. I would even
argue that we should ship it with our QML applications in Android.


Your concerns are understandable. There is no perfect solution here. All 
the options for unified theming have challenges associated with them, 
but the status quo is painful too. In such situation, I think it's 
better to put our effort into inventing a better future than on 
maintaining a frustrating, unpleasant present. At least when we're 
inventing the future, it's exciting and fun and easy to get people 
interested in helping out.


Nate

Re: qqc2-breeze-style

[Carl Schwan]

Le lundi, avril 12, 2021 10:20 PM, Nate Graham  a écrit :

> [explicitly CCing Noah]
>
> On 3/10/21 8:52 AM, Marco Martin wrote:
>
> > On Wed, Mar 10, 2021 at 4:09 PM Nate Graham n...@kde.org wrote:
> >
> > > People go off an do their own thing in an un-coordinated manner when
> > > there is a significant problem that's not being solved, that problem has
> > > existed for a while without being addressed, and there is no clear
> > > direction or centrally coordinated plan for solving it.
> >
> > yes, that's exactly what happened and is a good warning for the future.
> > Also a good signal that we should start thinking and actually doing 
> > something
> > wrt a good theming story, which we clearly don't have.
> > To me, the most promising approach was the quick prototype Arjen did
> > back at akademy
> > https://invent.kde.org/ahiemstra/qtunifiedstyle
> > whether is something realistic to turn is something actually useful or
> > not remains to be seen.
> > We do have a ton of things to do otherwise, so is not easy to find
> > time for this, but is becoming
> > more and more important
>
> Based on other random conversations since this email thread petered out,
> it seems like we're going to end up considering qqc2-breeze-style to be
> a successful yet temporary stopgap solution from PlaMo, and continue
> using the qqc2-desktop-style theme bridge we currently have--fixing bugs
> and improving performance as needed--until we re-do and unify our whole
> theming system.
>
> On that subject, have we done any further brainstorming? I remember
> being fairly impressed with Arjen's prototype as well. I love the idea
> of finally being able to theme everything consistently, and also the
> possibility of using CSS which is simple, easily writable, and easily
> readable in a diff view without losing your mind :)
>
> As I understand it, here's the latest proposal:
>
> 1.  We make a universal theme of some sort (using CSS, QML, or something
> else; exact format TBD)
>
> 2.  We make a QStyle that is essentially a Kvantum-style theming engine
> that consumes the universal theme and applies it to Widgets-based
> apps
>
> 3.  We make a QQC2 style that consumes the universal theme and applies it
> to QtQuick software, including (optionally) Plasma, without going
> through QPainter or the QStyle at all
>
> 4.  We keep the existing Plasma QQC2 style that knows how to consume
> existing SVG-based Plasma themes, for compatibility's sake
>
> 5.  We add a user-facing setting for apps to allow people to choose
> whether to have:
> -   Their apps use the universal theme
> -   Their apps use a different QStyle, such as Lightly or Kvantum
> 6.  We add a user-facing setting for Plasma to allow people to choose
> whether to have:
> -   Plasma use the same universal style as their apps
> -   Plasma use a different universal style from the one being used for
> their apps
>
> -   Plasma use an SVG-based Plasma 5 theme, which we deprecate in
> Plasma 6 but continue to support
>
> 7.  In Plasma 7, we sunset support for SVG-based Plasma themes as well as
> generic QStyles (including Kvantum!) and only support the new
> universal theme--whatever it is we come up with
>
> Am I representing everything accurately, to the best of everyone else's
> memory?
>
> Nate
>

And I still have the same worries as before. Building a universal theming
system will takes **years** to make in a way that won't feel like a big
regression for our users.

At least for the QML engine, some part like configuring the paddings, margins,
borders will be relatively easy since those can be mapped to QQC2 easily.
That will be more complicated is everything that has to do with animations
Just an example, implementing ripple effects, for example, require js in HTML,
custom shaders in QML and custom c++ code for the animation in QtWidgets.
Trying to abstract that will be hard but not impossible.

Another example of a hard part will be the scrollbars. Currently just looking
at the different qstyle installed on my machine, I can see many completely
behaviors and button placements. Again it's not impossible to solve by
figuring out a good abstraction and adding tons of options. But at the end
we will end up with a list of configuration options that are passed to the
engine and two implementations that should be able to handle **all** the
options required to implement the existing themes.

here for example to support an oxygen style scrollbar (written in scss)

scrollbar {
 border-width: 0;
 item {
color: ...
 }
 top-buttons {
   move-top: {
 display: true;
 icon-name: 
 background: none;

   }
   move-bottom: { display: false }
 }
 item-background {
box-shadow: inner 2px 2px grey;
border-radius: 2px
background-color: ...
&::hover {
  background-color: ...
}
 }
 item {
margin: 2px
width: calc(100% - 4px);
background-color:
&::hover {
  

Re: qqc2-breeze-style

[Noah Davis]

Just chiming in: I agree that qqc2-breeze-style is a stopgap and not
an effective long term solution for our QQC2 theming. I agree that a
new unified theming system would be the ideal solution to arrive at,
but I knew it wasn't being worked on and couldn't be finished in a
timely manner for the release of the KDE PinePhone. I also did not
have the expertise necessary to do it myself. In comparison, making a
new QQC2 style in time for the KDE PinePhone release was a much easier
option and it appears to have been effective.

On Mon, Apr 12, 2021 at 4:20 PM Nate Graham  wrote:
>
> [explicitly CCing Noah]
>
>
> On 3/10/21 8:52 AM, Marco Martin wrote:
> > On Wed, Mar 10, 2021 at 4:09 PM Nate Graham  wrote:
> >>
> >> People go off an do their own thing in an un-coordinated manner when
> >> there is a significant problem that's not being solved, that problem has
> >> existed for a while without being addressed, and there is no clear
> >> direction or centrally coordinated plan for solving it.
> >
> > yes, that's exactly what happened and is a good warning for the future.
> > Also a good signal that we should start thinking and actually doing 
> > something
> > wrt a good theming story, which we clearly don't have.
> > To me, the most promising approach was the quick prototype Arjen did
> > back at akademy
> > https://invent.kde.org/ahiemstra/qtunifiedstyle
> > whether is something realistic to turn is something actually useful or
> > not remains to be seen.
> > We do have a ton of things to do otherwise, so is not easy to find
> > time for this, but is becoming
> > more and more important
> >
>
> Based on other random conversations since this email thread petered out,
> it seems like we're going to end up considering qqc2-breeze-style to be
> a successful yet temporary stopgap solution from PlaMo, and continue
> using the qqc2-desktop-style theme bridge we currently have--fixing bugs
> and improving performance as needed--until we re-do and unify our whole
> theming system.
>
> On that subject, have we done any further brainstorming? I remember
> being fairly impressed with Arjen's prototype as well. I love the idea
> of finally being able to theme everything consistently, and also the
> possibility of using CSS which is simple, easily writable, and easily
> readable in a diff view without losing your mind :)
>
> As I understand it, here's the latest proposal:
>
> 1. We make a universal theme of some sort (using CSS, QML, or something
> else; exact format TBD)
> 2. We make a QStyle that is essentially a Kvantum-style theming engine
> that consumes the universal theme and applies it to Widgets-based
> apps
> 3. We make a QQC2 style that consumes the universal theme and applies it
> to QtQuick software, including (optionally) Plasma, without going
> through QPainter or the QStyle at all
> 4. We keep the existing Plasma QQC2 style that knows how to consume
> existing SVG-based Plasma themes, for compatibility's sake
> 5. We add a user-facing setting for apps to allow people to choose
> whether to have:
> - Their apps use the universal theme
> - Their apps use a different QStyle, such as Lightly or Kvantum
> 6. We add a user-facing setting for Plasma to allow people to choose
> whether to have:
> - Plasma use the same universal style as their apps
> - Plasma use a different universal style from the one being used for
>   their apps
> - Plasma use an SVG-based Plasma 5 theme, which we deprecate in
>   Plasma 6 but continue to support
> 6. In Plasma 7, we sunset support for SVG-based Plasma themes as well as
> generic QStyles (including Kvantum!) and only support the new
> universal theme--whatever it is we come up with
>
>
> Am I representing everything accurately, to the best of everyone else's
> memory?
>
> Nate

Re: qqc2-breeze-style

[Nate Graham]

[explicitly CCing Noah]


On 3/10/21 8:52 AM, Marco Martin wrote:

On Wed, Mar 10, 2021 at 4:09 PM Nate Graham  wrote:


People go off an do their own thing in an un-coordinated manner when
there is a significant problem that's not being solved, that problem has
existed for a while without being addressed, and there is no clear
direction or centrally coordinated plan for solving it.


yes, that's exactly what happened and is a good warning for the future.
Also a good signal that we should start thinking and actually doing something
wrt a good theming story, which we clearly don't have.
To me, the most promising approach was the quick prototype Arjen did
back at akademy
https://invent.kde.org/ahiemstra/qtunifiedstyle
whether is something realistic to turn is something actually useful or
not remains to be seen.
We do have a ton of things to do otherwise, so is not easy to find
time for this, but is becoming
more and more important



Based on other random conversations since this email thread petered out, 
it seems like we're going to end up considering qqc2-breeze-style to be 
a successful yet temporary stopgap solution from PlaMo, and continue 
using the qqc2-desktop-style theme bridge we currently have--fixing bugs 
and improving performance as needed--until we re-do and unify our whole 
theming system.


On that subject, have we done any further brainstorming? I remember 
being fairly impressed with Arjen's prototype as well. I love the idea 
of finally being able to theme everything consistently, and also the 
possibility of using CSS which is simple, easily writable, and easily 
readable in a diff view without losing your mind :)


As I understand it, here's the latest proposal:

1. We make a universal theme of some sort (using CSS, QML, or something
   else; exact format TBD)
2. We make a QStyle that is essentially a Kvantum-style theming engine
   that consumes the universal theme and applies it to Widgets-based
   apps
3. We make a QQC2 style that consumes the universal theme and applies it
   to QtQuick software, including (optionally) Plasma, without going
   through QPainter or the QStyle at all
4. We keep the existing Plasma QQC2 style that knows how to consume
   existing SVG-based Plasma themes, for compatibility's sake
5. We add a user-facing setting for apps to allow people to choose
   whether to have:
   - Their apps use the universal theme
   - Their apps use a different QStyle, such as Lightly or Kvantum
6. We add a user-facing setting for Plasma to allow people to choose
   whether to have:
   - Plasma use the same universal style as their apps
   - Plasma use a different universal style from the one being used for
 their apps
   - Plasma use an SVG-based Plasma 5 theme, which we deprecate in
 Plasma 6 but continue to support
6. In Plasma 7, we sunset support for SVG-based Plasma themes as well as
   generic QStyles (including Kvantum!) and only support the new
   universal theme--whatever it is we come up with


Am I representing everything accurately, to the best of everyone else's 
memory?


Nate

Re: Proposal: move Klipper | Plasma Applet bugs into Plasmashell product

[Nate Graham]

On 4/12/21 12:57 PM, Ben Cooksley wrote:
On Tue, 13 Apr 2021, 6:04 am Nate Graham, Thanks for the explanation. Can I ask you to do your magic to silently

move all bugs in the Klipper product to the Plasmashell | Clipboard
component? Looks like it's about 100 bugs.


We certainly can look into getting that actioned.

Can you please file a ticket for this?

Given how recent this thread is I'd also like to see a little bit more 
time given to allow for those who might have been away over the last 
12-24 hours a chance to respond.


https://phabricator.kde.org/T14360

Nate

Re: Proposal: move Klipper | Plasma Applet bugs into Plasmashell product

[Ben Cooksley]

On Tue, 13 Apr 2021, 6:04 am Nate Graham,  wrote:

> On 4/12/21 11:56 AM, Ben Cooksley wrote:
> > There isn't an exact threshold.
> >
> > The issue is that email providers (such as Google, Outlook.com -
> > Microsoft, Yahoo and GMX) keep track of email servers sending patterns.
> > Should we deviate from these patterns, then their systems will
> > automatically impose restrictions - including at times totally refusing
> > to accept further email.
> >
> > It can also impact on decisions made by their spam filters, which can
> > lead to legitimate email going to spam folders and therefore being
> > missed by people. Depending on the age of the bug, it may also lead to
> > people marking email as spam - which will have an negative impact on the
> > reputation metrics they maintain, and increase the long term risk of
> > email going to the spam folder.
> >
> > This impacts on much more than just Bugzilla, as all KDE.org
> > "transactional" email is sent through one server - so a block against
> > Bugzilla will also block email from Identity, Gitlab and Phabricator
> > among others.
> >
> > It also has spillover implications to our mailing lists (which use a
> > separate server for handling their email) as all actions that take place
> > on Bugzilla lead to an email being sent to the kde-bugs-d...@kde.org
> >  mailing list. Consequently, it will also
> > knock out delivery for those providers used by people subscribed to that
> > list.
> >
> > When we have had these incidents in the past it has sometimes taken
> > several days for the mail queue to drain for all of the involved
> > providers and for email delivery behaviour to totally return to normal.
> > This was very frustrating for the affected contributors at the time, and
> > there was nothing we could do for them except wait - and is therefore
> > something we should avoid.
>
> Thanks for the explanation. Can I ask you to do your magic to silently
> move all bugs in the Klipper product to the Plasmashell | Clipboard
> component? Looks like it's about 100 bugs.
>

We certainly can look into getting that actioned.

Can you please file a ticket for this?

Given how recent this thread is I'd also like to see a little bit more time
given to allow for those who might have been away over the last 12-24 hours
a chance to respond.

Cheers,
Ben


> Nate
>

Re: Proposal: move Klipper | Plasma Applet bugs into Plasmashell product

[Nate Graham]

On 4/12/21 11:56 AM, Ben Cooksley wrote:

There isn't an exact threshold.

The issue is that email providers (such as Google, Outlook.com - 
Microsoft, Yahoo and GMX) keep track of email servers sending patterns.
Should we deviate from these patterns, then their systems will 
automatically impose restrictions - including at times totally refusing 
to accept further email.


It can also impact on decisions made by their spam filters, which can 
lead to legitimate email going to spam folders and therefore being 
missed by people. Depending on the age of the bug, it may also lead to 
people marking email as spam - which will have an negative impact on the 
reputation metrics they maintain, and increase the long term risk of 
email going to the spam folder.


This impacts on much more than just Bugzilla, as all KDE.org 
"transactional" email is sent through one server - so a block against 
Bugzilla will also block email from Identity, Gitlab and Phabricator 
among others.


It also has spillover implications to our mailing lists (which use a 
separate server for handling their email) as all actions that take place 
on Bugzilla lead to an email being sent to the kde-bugs-d...@kde.org 
 mailing list. Consequently, it will also 
knock out delivery for those providers used by people subscribed to that 
list.


When we have had these incidents in the past it has sometimes taken 
several days for the mail queue to drain for all of the involved 
providers and for email delivery behaviour to totally return to normal. 
This was very frustrating for the affected contributors at the time, and 
there was nothing we could do for them except wait - and is therefore 
something we should avoid.


Thanks for the explanation. Can I ask you to do your magic to silently 
move all bugs in the Klipper product to the Plasmashell | Clipboard 
component? Looks like it's about 100 bugs.


Nate

Re: Proposal: move Klipper | Plasma Applet bugs into Plasmashell product

[Ben Cooksley]

On Tue, Apr 13, 2021 at 4:01 AM David Edmundson 
wrote:

> On Mon, Apr 12, 2021 at 4:21 PM Nate Graham  wrote:
> >
> >
> >
> > On 4/12/21 9:15 AM, David Edmundson wrote:
> > > No objections.
> > >
> > > Be sure to CC sysadmins before doing bulk moves.
> >
> > Saying what? Also what qualifies as bulk?
>
> Please move Product blah to blah.
> They have some secret bugzilla that doesn't send 150 emails.
>
> > Also what qualifies as bulk?
>
> I know we get told off if we send too many, I don't know the precise
> threshold.
> I haven't wanted to test and find out!
>

There isn't an exact threshold.

The issue is that email providers (such as Google, Outlook.com - Microsoft,
Yahoo and GMX) keep track of email servers sending patterns.
Should we deviate from these patterns, then their systems will
automatically impose restrictions - including at times totally refusing to
accept further email.

It can also impact on decisions made by their spam filters, which can lead
to legitimate email going to spam folders and therefore being missed by
people. Depending on the age of the bug, it may also lead to people marking
email as spam - which will have an negative impact on the reputation
metrics they maintain, and increase the long term risk of email going to
the spam folder.

This impacts on much more than just Bugzilla, as all KDE.org
"transactional" email is sent through one server - so a block against
Bugzilla will also block email from Identity, Gitlab and Phabricator among
others.

It also has spillover implications to our mailing lists (which use a
separate server for handling their email) as all actions that take place on
Bugzilla lead to an email being sent to the kde-bugs-d...@kde.org mailing
list. Consequently, it will also knock out delivery for those providers
used by people subscribed to that list.

When we have had these incidents in the past it has sometimes taken several
days for the mail queue to drain for all of the involved providers and for
email delivery behaviour to totally return to normal. This was very
frustrating for the affected contributors at the time, and there was
nothing we could do for them except wait - and is therefore something we
should avoid.


> David
>
> > Nate
>

Regards,
Ben

Re: Proposal: move Klipper | Plasma Applet bugs into Plasmashell product

[Harald Sitter]

On Mon, Apr 12, 2021 at 6:01 PM David Edmundson
 wrote:
>
> On Mon, Apr 12, 2021 at 4:21 PM Nate Graham  wrote:
> >
> >
> >
> > On 4/12/21 9:15 AM, David Edmundson wrote:
> > > No objections.
> > >
> > > Be sure to CC sysadmins before doing bulk moves.
> >
> > Saying what? Also what qualifies as bulk?
>
> Please move Product blah to blah.
> They have some secret bugzilla that doesn't send 150 emails.
>
> > Also what qualifies as bulk?
>
> I know we get told off if we send too many, I don't know the precise 
> threshold.
> I haven't wanted to test and find out!

I'm sure moving ALL of anything qualifies as bulk ;)

What with being entirely avoidable noise.

Re: Proposal: move Klipper | Plasma Applet bugs into Plasmashell product

[David Edmundson]

On Mon, Apr 12, 2021 at 4:21 PM Nate Graham  wrote:
>
>
>
> On 4/12/21 9:15 AM, David Edmundson wrote:
> > No objections.
> >
> > Be sure to CC sysadmins before doing bulk moves.
>
> Saying what? Also what qualifies as bulk?

Please move Product blah to blah.
They have some secret bugzilla that doesn't send 150 emails.

> Also what qualifies as bulk?

I know we get told off if we send too many, I don't know the precise threshold.
I haven't wanted to test and find out!

David

> Nate

Re: Proposal: move Klipper | Plasma Applet bugs into Plasmashell product

[Nate Graham]

On 4/12/21 9:15 AM, David Edmundson wrote:

No objections.

Be sure to CC sysadmins before doing bulk moves.


Saying what? Also what qualifies as bulk?

Nate

Re: Proposal: move Klipper | Plasma Applet bugs into Plasmashell product

[David Edmundson]

No objections.

Be sure to CC sysadmins before doing bulk moves.

David

Re: Proposal: move Klipper | Plasma Applet bugs into Plasmashell product

[Nate Graham]

Ping on this. After having triaged all Klipper bugs recently, and given 
that it is basically a Plasma service now, I don't see the advantage of 
having multiple components with the product anymore, or even using a 
separate product at all. I would like to propose moving all Klipper bugs 
into a new "Clipboard" component of the Plasmashell product.


Aye or nay?

Nate


On 8/10/20 12:30 PM, Nate Graham wrote:
Then perhaps all of the bugs (not just applet bugs) could be moved into 
a new 'klipper' component within plasmashell? The distinction between 
common code and the applet itself is somewhat amorphous now because the 
applet is the only UI people see.


Nate


On 8/10/20 11:48 AM, David Edmundson wrote:
Right now the component "plasma-widget" is filled with bugs about 
common klipper code.

If we move the component to plasmashell that's not going to change.

Unless you have a new idea on making it really "applet only" we're 
ultimately just going to spread bug reports out across two places, and 
that's just making life harder for everyone.


David

Monday meeting notes for 12/04/2021

[Marco Martin]

David R
- PresentWindows and HighlightWindowsEffect are now exposed on DBus,
which means the Taskmanager can now also invoke them on Wayland
https://invent.kde.org/plasma/plasma-desktop/-/merge_requests/400
https://invent.kde.org/plasma/kwin/-/merge_requests/812
- Use new async KCModuleData for shorcuts kcm
https://invent.kde.org/plasma/plasma-desktop/-/merge_requests/406
- Added an option to systemmonitor to allow selecting which page to
open on start (needs review)
https://invent.kde.org/plasma/plasma-systemmonitor/-/merge_requests/111

Arjen
- most important thing is that I started working on splitting
ksystemstats out of the ksysguard repo
- there's two MRs for libksysguard, one to move the ksystemstats
library to libksysguard, the other to include the process plugins in
libksysguard
https://invent.kde.org/plasma/libksysguard/-/merge_requests/142
https://invent.kde.org/plasma/libksysguard/-/merge_requests/143
- I also have a work in progress repo with ksystemstats:
https://invent.kde.org/ahiemstra/ksystemstats
- for all three, history should be mostly intact
- luckily there isn't much work in ksystemstats
[DavidRedondo: will port my review to new repo]
- I mostly need to do some cosmetic cleanup stuff like making it reuse
compliant and then it'll be ready

David E
- I want to spend some time to discuss the major 5.18 screw up that
happened last week
- as people weren't around last monday
- so for those not in the loop; 5.18.7 got released, kscreenlocker got
broken after something incompatible was backported
- if you tried to lock the screen, you'd get the black screen + white text
- The timeline was: A bug came in on Thursday, Nate triaged it as VHI
- no-one (including myself) looked at it
- then it got resolved fixed and released on the Saturday
- So, we need to have a discussion on improving our manual testing
after backporting - the cherry-picking in the web UI makes it almost
too easy
- backport of kscreenlocker broke it
- takeaway of discussion was for now just cecking for kscreenlocker
exit code, openqa on lts may be excessive for now

Marco
* Away monday due to national holiday
# Plasma
* user feedback controls in the landing page
https://invent.kde.org/plasma/plasma-desktop/-/merge_requests/413
* Still pending for review: saving applet layout per-resolution:
https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/717
https://invent.kde.org/plasma/plasma-desktop/-/merge_requests/385
# Plasma Mobile
* more work on the horizontal pagination