[Powerdevil] [Bug 361708] System stuck in ac-plugged in mode ignoring Power management rules

[bugzilla_noreply]

https://bugs.kde.org/show_bug.cgi?id=361708

--- Comment #5 from battagli...@gmail.com ---
Finally, I note the problem may result from a discrepancy between upower and
acpi. Note the following terminal results. Both of these are in the state where
the AC is not plugged in, but the tray icon still says discharging (even though
battery panel icon says discharging):

$ acpi -V
Battery 0: Discharging, 50%, 01:55:40 remaining
Battery 0: design capacity 5006 mAh, last full capacity 4092 mAh = 81%
Adapter 0: off-line  <- NOTE HERE
Thermal 0: ok, 40.0 degrees C
Thermal 0: trip point 0 switches to mode hot at temperature 240.0 degrees C
Thermal 1: ok, 35.3 degrees C
Thermal 1: trip point 0 switches to mode hot at temperature 60.0 degrees C
Thermal 2: ok, 0.0 degrees C
Thermal 2: trip point 0 switches to mode hot at temperature 97.0 degrees C
Thermal 3: ok, 38.0 degrees C
Thermal 3: trip point 0 switches to mode hot at temperature 54.0 degrees C
Cooling 0: x86_pkg_temp no state information available
Cooling 1: Processor 0 of 10
Cooling 2: Processor 0 of 10
Cooling 3: intel_powerclamp no state information available
Cooling 4: pch_skylake no state information available
Cooling 5: Processor 0 of 10
Cooling 6: Processor 0 of 10


Note that Adapter 0 is offline. On the other hand, here's upower -u. Note
Adapter 0 (line_power_ADP1) is ONLINE!

~ $ upower -d
Device: /org/freedesktop/UPower/devices/line_power_ADP1
  native-path:  ADP1
  power supply: yes
  updated:  Thu 05 Jul 2018 12:54:02 AM EDT (2262 seconds ago)
  has history:  no
  has statistics:   no
  line-power
warning-level:   none
online:  yes  <- SEE HERE
icon-name:  'ac-adapter-symbolic'

Device: /org/freedesktop/UPower/devices/battery_BAT1
  native-path:  BAT1
  vendor:   SMP
  model:X910527
  serial:   39135
  power supply: yes
  updated:  Thu 05 Jul 2018 01:31:23 AM EDT (21 seconds ago)
  has history:  yes
  has statistics:   yes
  battery
present: yes
rechargeable:yes
state:   discharging
warning-level:   none
energy:  15.547 Wh
energy-empty:0 Wh
energy-full: 31.192 Wh
energy-full-design:  38.152 Wh
energy-rate: 7.507 W
voltage: 7.567 V
time to empty:   2.1 hours
percentage:  49%
capacity:81.7572%
technology:  lithium-ion
icon-name:  'battery-good-symbolic'
  History (charge):
1530768666  49.000  discharging
  History (rate):
1530768683  7.507   discharging
1530768682  18.735  charging
1530768675  7.695   discharging
1530768666  8.580   discharging

Device: /org/freedesktop/UPower/devices/DisplayDevice
  power supply: yes
  updated:  Thu 05 Jul 2018 01:31:23 AM EDT (21 seconds ago)
  has history:  no
  has statistics:   no
  battery
present: yes
state:   discharging
warning-level:   none
energy:  15.547 Wh
energy-full: 31.192 Wh
energy-rate: 7.507 W
time to empty:   2.1 hours
percentage:  49%
icon-name:  'battery-good-symbolic'

Daemon:
  daemon-version:  0.99.4
  on-battery:  no
  lid-is-closed:   no
  lid-is-present:  yes
  critical-action: HybridSleep

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Powerdevil] [Bug 361708] System stuck in ac-plugged in mode ignoring Power management rules

[bugzilla_noreply]

https://bugs.kde.org/show_bug.cgi?id=361708

--- Comment #4 from battagli...@gmail.com ---
Created attachment 113772
  --> https://bugs.kde.org/attachment.cgi?id=113772&action=edit
All charging

One more - now things are plugged in. Note that the tray icon is "charging",
and now the battery icon in the panel dropdown is also "charging." In the
previous screenshot, the battery icon in the panel dropdown was the normal
"discharging" battery.

However, crucially, in both cases, the battery tray icon was charging -- even
though it is only really charging in this one and not the last one. The tray
icon seems to dictate which power management behaviors are followed, so that it
always does AC mode even if discharging.

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Powerdevil] [Bug 361708] System stuck in ac-plugged in mode ignoring Power management rules

[bugzilla_noreply]

https://bugs.kde.org/show_bug.cgi?id=361708

--- Comment #3 from battagli...@gmail.com ---
Created attachment 113771
  --> https://bugs.kde.org/attachment.cgi?id=113771&action=edit
Battery inconsistency

Note the tray icon still has the battery in AC mode, even though it is listed
as "Discharging" in the panel.

More importantly, the power management settings still respond as if the AC were
plugged in. I want it to auto-suspend only if battery is discharging and not
suspend if AC is plugged in. The result here is that it thinks the AC is
plugged in, discharges, and drains the battery.

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Powerdevil] [Bug 361708] System stuck in ac-plugged in mode ignoring Power management rules

[bugzilla_noreply]

https://bugs.kde.org/show_bug.cgi?id=361708

battagli...@gmail.com changed:

   What|Removed |Added

 CC||battagli...@gmail.com

--- Comment #2 from battagli...@gmail.com ---
Same exact issue - on Neon Xenial running Plasma 5.13. `acpi` and `upower` will
show the battery charge/discharge status correctly responding to AC plug on/off
events, but the plasmashell battery icon will remain on "plugged in" mode even
if I unplug.

Strangely, sometimes the battery icon will still say "plugged in," even though
when I click on the battery, it still says "discharging". Screenshot attached
below.

-- 
You are receiving this mail because:
You are the assignee for the bug.

D13870: Correct Folder View sizing and representation switch behavior

[Eike Hein]

This revision was automatically updated to reflect the committed changes.
Closed by commit R119:4ad27c62b5e7: Correct Folder View sizing and 
representation switch behavior (authored by hein).

REPOSITORY
  R119 Plasma Desktop

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D13870?vs=37115&id=37156

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

AFFECTED FILES
  containments/desktop/package/contents/ui/CompactRepresentation.qml
  containments/desktop/package/contents/ui/main.qml

To: hein, mart, broulik, mvourlakos
Cc: plasma-devel, ragreen, Pitel, ZrenBot, lesliezhai, ali-mohamed, 
jensreuterberg, abetts, sebas, apol, mart

Re: Discussion for Virtual Desktops and Activities future

[Michail Vourlakos]

2018-07-04 22:01 GMT+03:00 David Edmundson :

>
> ​Are you (Michail and Ivan) at Akademy?
>
>
unfortunately not David, family matters prevent me from attending

Re: Discussion for Virtual Desktops and Activities future

[Nate Graham]

I used to be of the opinion that having both Activities and Virtual 
Desktops was "too confusing" to users. I've changed my opinion recently, 
because I finally came to understand how they're designed to be used for 
very different things: Virtual Desktops are for window organization 
within the current set of tasks, and Activities are for higher-level 
task and context switching.


Both concepts have merit and are useful, but it's true that the current 
user interfaces for them are rather confusing for a variety of reasons: 
both have similar animated transitions; one has an accessible user 
interface and a keyboard shortcut but the other one doesn't; one can 
have different wallpapers but the other one can't; etc.


I'm willing to experiment with combining them to improve the user 
interface, but I think it's important to keep in mind the different 
reasons *why* people use one or the other (or both), and fluidly support 
all of those use cases without losing any current functionality. So for 
example:


- You should be able to mark a Virtual Desktop as "private"
- Virtual Desktops should be able to have different wallpapers, panel 
settings, recent documents lists, etc.
- I'd like to see a visible-by-default method to switch between Virtual 
Desktops, plus appropriate keyboard shortcuts


In addition to alleviating potential user confusion, combining them 
while keeping current functionality may yield a PR advantage since it 
would represent an opportunity to shift the narrative from "KDE has two 
confusing versions of Virtual Desktops that nobody understands" to "KDE 
Has the best, most feature-filled Virtual Desktops implementation!"


I have no opinions regarding how the two concepts are or ought to be 
implemented on the backend.


Nate



On 07/04/2018 09:57 AM, Michail Vourlakos wrote:



2018-07-03 22:19 GMT+03:00 Eike Hein mailto:h...@kde.org>>:


This is the relevant thread :-)


There are some technical decisions and commit reviews referencing MERGE 
and this is why I proposed this thread.


Proposed technical decisions:

1. Virtual Desktops Ids from integers will be QVariants possibly strings 
I guess
2. An empty Virtual Desktops list will mean to All Desktops even when 
then user has enabled

manually all dekstops records


What are the reasons for [1] to be proposed?

[A] Desktops and Activities will share the same way and code to identify 
themselves and thus it will be easier to maintain

(I cant object to that of course)


[B1] Activities and VDs will be able to be combined. That is the current 
situation so I suppose [1] is just for [A]

(I have no problem with that)

OR

[B2] Activities and VDs will NOT be able to be combined. So the users in 
the future will be able to use

Virtual Desktops OR Activities and never in combination.
(I think that this is what kwayland protocol is trying to support currently.
Even though that would break some user workflows for those users that 
combine VDs and Activities together,
personally I also dont object BUT this must be communicated and prepared 
to all parts

Plasma and VDG that is).

Things to consider for [B2]

[B2.1] How the user will be able to switch between VDs and Actitivities 
easily?
[B2.2] How this dual way of doing things can be presented to the user in 
a way that has meaning in order to

choose what prefers?


P.S. [A] and [B] are just my guesses feel free to correct me

Re: Discussion for Virtual Desktops and Activities future

[David Edmundson]

​Are you (Michail and Ivan) at Akademy?

David

D13881: oxygen-demo : add KMessage preview

[René J . V . Bertin]

rjvbb added a comment.


  A couple of snapshot (with my current KMessageWidget facelift; styles and 
themes switched "on-the-fly"):
  
  Oxygen with the Oxygen theme:
  F6014853: image.png 
  
  Breeze with Breeze-Dark:
  F6014872: image.png 
  
  QtCurve with my Mac OS X Graphite theme:
  F6014843: image.png 

REPOSITORY
  R113 Oxygen Theme

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

To: rjvbb, hpereiradacosta
Cc: broulik, plasma-devel, ragreen, Pitel, ZrenBot, lesliezhai, ali-mohamed, 
jensreuterberg, abetts, sebas, apol, mart

D13881: oxygen-demo : add KMessage preview

[René J . V . Bertin]

rjvbb updated this revision to Diff 37155.
rjvbb added a comment.


  Updated as (hopefully) requested.
  
  I've left the property change event filter, for builds against older than 
5.48.0 (or whatever version D13884  will 
appear in).
  
  There is one side-effect that will exist with older frameworks and not with 
D13884  in place: messages are recreated so 
will reappear if you've closed them. The easy way to prevent that would be to 
disable the close button, should I do that or do we not care about this? I 
can't say I'll lay awake about the detail...

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D13881?vs=37137&id=37155

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

AFFECTED FILES
  kstyle/demo/oxygenframedemowidget.cpp
  kstyle/demo/oxygenframedemowidget.h
  kstyle/demo/ui/oxygenframedemowidget.ui

To: rjvbb, hpereiradacosta
Cc: broulik, plasma-devel, ragreen, Pitel, ZrenBot, lesliezhai, ali-mohamed, 
jensreuterberg, abetts, sebas, apol, mart

D13745: Implement support for virtual desktops on Wayland

[Marco Martin]

mart added a comment.


  In D13745#286500 , @mvourlakos 
wrote:
  
  > In D13745#286491 , @hein wrote:
  >
  > > Michail: Please follow this review, as these API changes might impact 
Latte Dock, too. :)
  >
  >
  > 3. The idea is that Virtual Desktops will get some characteristics from 
Activities or vice versa?
  
  
  this is what i think it will happen (in wayland and only in wayland)
  the virtual desktops from kwin become the "source" for activities, so they 
are kept in sync: 1 activity = 1 desktop (this will probably be configurable to 
be enabled or disabled) that's possible because a window can be in any subset 
of desktops now, just like it could be on any subset of activities on X11.
  So, if you want a window only shown on an activity, or a set of activities, 
you set it on those.
  If you want a window to be there but change its contents depending from the 
activities, you set it on all desktops and use the kactivities api just as 
before
  
  > 4. The features provided from kactivitymanagerd will be dropped? (files 
linked to Activities, Activity icon, etc...) OR Virtual Desktops in Plasma will 
be identified through kactivitymanagerd in the future?
  
  kactivitymanagerd will stay the same, just activities and virtual desktops 
would be the same set, any data, any stats, any linked files remain as now.

REPOSITORY
  R120 Plasma Workspace

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

To: hein, mart, mvourlakos
Cc: zzag, ngraham, abetts, plasma-devel, ragreen, Pitel, ZrenBot, lesliezhai, 
ali-mohamed, jensreuterberg, sebas, apol, mart

Re: Discussion for Virtual Desktops and Activities future

[Michail Vourlakos]

2018-07-03 22:19 GMT+03:00 Eike Hein :

>
> This is the relevant thread :-)
>
>
There are some technical decisions and commit reviews referencing MERGE and
this is why I proposed this thread.

Proposed technical decisions:

1. Virtual Desktops Ids from integers will be QVariants possibly strings I
guess
2. An empty Virtual Desktops list will mean to All Desktops even when then
user has enabled
manually all dekstops records


What are the reasons for [1] to be proposed?

[A] Desktops and Activities will share the same way and code to identify
themselves and thus it will be easier to maintain
(I cant object to that of course)


[B1] Activities and VDs will be able to be combined. That is the current
situation so I suppose [1] is just for [A]
(I have no problem with that)

OR

[B2] Activities and VDs will NOT be able to be combined. So the users in
the future will be able to use
Virtual Desktops OR Activities and never in combination.
(I think that this is what kwayland protocol is trying to support currently.
Even though that would break some user workflows for those users that
combine VDs and Activities together,
personally I also dont object BUT this must be communicated and prepared to
all parts
Plasma and VDG that is).

Things to consider for [B2]

[B2.1] How the user will be able to switch between VDs and Actitivities
easily?
[B2.2] How this dual way of doing things can be presented to the user in a
way that has meaning in order to
choose what prefers?


P.S. [A] and [B] are just my guesses feel free to correct me

D13853: Fix setting primary connector if primary output changed

[Robert Hoffmann]

hoffmannrobert marked an inline comment as done.
hoffmannrobert added a comment.


  Addition to last comment: In the other case, booting with HDMI-2 and 
hotplugging HDMI-3 the problem with primary switching doesn't exist.

REPOSITORY
  R120 Plasma Workspace

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

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

D13853: Fix setting primary connector if primary output changed

[Robert Hoffmann]

hoffmannrobert marked an inline comment as done.
hoffmannrobert added inline comments.

INLINE COMMENTS

> davidedmundson wrote in screenpool.cpp:108
> Either this is a valid case to be in, and this assert doesn't make sense.
> 
> Or we should never be in this case, and the patch doesn't make sense.
> 
> I don't fully understand the background of how we end up in this situation to 
> say which it is.

This is a valid case, and the assert doesn't make sense, it needs to be removed.

In the case described in the test plan, the old primary display ist HDMI-3, the 
new primary is HDMI-2. If HDMI-2 is plugged in and "extend to right" is 
selected in the OSD, the QGuiApplication::screenAdded signal starts 
ShellCorona::addOutput().

This checks, if the new screen is redundant (ShellCorona::isOutputRedundant). 
At this time, both have the same geometry (two equal screens, QRect(0,0 
1920x1080)), so yes, the new screen is considered redundant and not added to 
the screen pool.

There is already some remedy against this wrong assumption:
On the signal QGuiApplication::primaryScreenChanged 
ShellCorona::primaryOutputChanged is called. Here, with 
m_reconsiderOutputsTimer.start() ShellCorona::reconsiderOutputs() is run at a 
later time, which will correct this.

But that's too late for the primary change: before reconsiderOutputs()  is run, 
ScreenPool::setPrimaryConnector( newPrimary->name() ) is called. Here, 
m_idForConnector does not contain this new primary, it only knows "HDMI-3", 
which is still mapped to 0.

If the Q_ASSERT is disabled, m_idForConnector.value(primary (The new primary 
HDMI-2!) ) returns 0, so both HDMI-2 and HDMI-3 are mapped to 0 in 
m_idForConnector, and m_connectorForId[0] is set to "HDMI-2", so the mapping to 
HDMI-3 is lost.

The other case, booting with HDMI-2 and hotplugging HDMI-3 works, because in 
ShellCorona::isOutputRedundant, geometries are different: HDMI-2 has: QRect(0,0 
1920x1080) and HDMI-3: QRect(1920,0 1920x1080), so one doesn't contain the 
other.

REPOSITORY
  R120 Plasma Workspace

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

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

D13881: oxygen-demo : add KMessage preview

[Kai Uwe Broulik]

broulik added a comment.


  D13884  fixes that. It doesn't set a 
custom palette but a custom style sheet on the `QFrame` (where you apparently 
can't style the hyperlink color for labels inside :/)

REPOSITORY
  R113 Oxygen Theme

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

To: rjvbb, hpereiradacosta
Cc: broulik, plasma-devel, ragreen, Pitel, ZrenBot, lesliezhai, ali-mohamed, 
jensreuterberg, abetts, sebas, apol, mart

D13881: oxygen-demo : add KMessage preview

[Hugo Pereira Da Costa]

hpereiradacosta added a comment.


  In D13881#286869 , @broulik wrote:
  
  > > 1/ As far as I know, the widget style has no way to style these widgets. 
Correct ?
  >
  > Yes. I would have preferred if Breeze applied the new flat style to the 
widget instead of changing the look in the class itself.
  
  
  That requires either some hacking in breeze, or declaring a custom primitive 
(as done for kcapacitybar).
  You would still need to implement a "default" rendering in the widget, for 
styles that do not support the custom element. (again as in kcapacitybar)..
  
  > 
  > 
  >> As such I wonder if oxygen-demo is the right place for showing this. Might 
better have a showcase in kwidgetsaddon.
  > 
  > There is, actually.
  
  Concerning the paletteChange business, as far as I understand, as soon as you 
set a custom palette to a widget, you do not recieve the paletteChange events 
from QApp any more (I think. To be confirmed).

REPOSITORY
  R113 Oxygen Theme

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

To: rjvbb, hpereiradacosta
Cc: broulik, plasma-devel, ragreen, Pitel, ZrenBot, lesliezhai, ali-mohamed, 
jensreuterberg, abetts, sebas, apol, mart

D13881: oxygen-demo : add KMessage preview

[Kai Uwe Broulik]

broulik added a comment.


  > 1/ As far as I know, the widget style has no way to style these widgets. 
Correct ?
  
  Yes. I would have preferred if Breeze applied the new flat style to the 
widget instead of changing the look in the class itself.
  
  > As such I wonder if oxygen-demo is the right place for showing this. Might 
better have a showcase in kwidgetsaddon.
  
  There is, actually.

REPOSITORY
  R113 Oxygen Theme

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

To: rjvbb, hpereiradacosta
Cc: broulik, plasma-devel, ragreen, Pitel, ZrenBot, lesliezhai, ali-mohamed, 
jensreuterberg, abetts, sebas, apol, mart

D13881: oxygen-demo : add KMessage preview

[Kai Uwe Broulik]

broulik added inline comments.

INLINE COMMENTS

> rjvbb wrote in oxygenframedemowidget.cpp:90
> That's to catch the event sent to the qApp instance when the theme is changed 
> (to be exact: after KColorSchemeManager sets or changes the 
> `KDE_COLOR_SCHEME_PATH` property.
> 
> Without this, the messages don't adapt to reflect the new colours (even the 
> current implementation mixes the window background into its background 
> colour).

I think you're working around a bug here. `KColorSchemeManager` does

  
qApp->setPalette(KColorScheme::createApplicationPalette(KSharedConfig::openConfig(action->data().toString(;

so the `KMessageWidget` should get a `PaletteChange` event and adjust, if not, 
it's a bug there.

REPOSITORY
  R113 Oxygen Theme

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

To: rjvbb, hpereiradacosta
Cc: broulik, plasma-devel, ragreen, Pitel, ZrenBot, lesliezhai, ali-mohamed, 
jensreuterberg, abetts, sebas, apol, mart

D13881: oxygen-demo : add KMessage preview

[Hugo Pereira Da Costa]

hpereiradacosta added a comment.


  1/ As far as I know, the widget style has no way to style these widgets. 
Correct ? As such I wonder if oxygen-demo is the right place for showing this. 
Might better have a showcase in kwidgetsaddon. 
  (but in fact we also discussed that ultimately oxygen-demo should go 
"elsewhere", like e.g. frameworks-integration/kstyle).
  
  2/ putting these in the Tab of the "Frame" page does not feel like the right 
place to me. (there seem to be no logic behind it) I would give it its own 
page; If you want to keep them in the "Frame" page (why not. They do look like 
frame), then they should be kept outside of the Tab frame. Possibly in a 
separate vlayout. 
  Also, please add an extra "addStretch" below the last messagebox so that they 
stack towards the top rather than being evenly distributed in the layout.

REPOSITORY
  R113 Oxygen Theme

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

To: rjvbb, hpereiradacosta
Cc: broulik, plasma-devel, ragreen, Pitel, ZrenBot, lesliezhai, ali-mohamed, 
jensreuterberg, abetts, sebas, apol, mart

D13881: oxygen-demo : add KMessage preview

[René J . V . Bertin]

rjvbb added inline comments.

INLINE COMMENTS

> broulik wrote in oxygenframedemowidget.cpp:90
> What do you need this for?

That's to catch the event sent to the qApp instance when the theme is changed 
(to be exact: after KColorSchemeManager sets or changes the 
`KDE_COLOR_SCHEME_PATH` property.

Without this, the messages don't adapt to reflect the new colours (even the 
current implementation mixes the window background into its background colour).

REPOSITORY
  R113 Oxygen Theme

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

To: rjvbb, hpereiradacosta
Cc: broulik, plasma-devel, ragreen, Pitel, ZrenBot, lesliezhai, ali-mohamed, 
jensreuterberg, abetts, sebas, apol, mart

D13881: oxygen-demo : add KMessage preview

[Kai Uwe Broulik]

broulik added a comment.


  +1

INLINE COMMENTS

> oxygenframedemowidget.cpp:90
> +{
> +if (event->type() == QEvent::DynamicPropertyChange && obj == qApp) {
> +QDynamicPropertyChangeEvent *e = 
> dynamic_cast(event);

What do you need this for?

REPOSITORY
  R113 Oxygen Theme

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

To: rjvbb, hpereiradacosta
Cc: broulik, plasma-devel, ragreen, Pitel, ZrenBot, lesliezhai, ali-mohamed, 
jensreuterberg, abetts, sebas, apol, mart

D13883: Don't keep transfer div in DOM

[Kai Uwe Broulik]

broulik created this revision.
broulik added reviewers: Plasma, davidedmundson, fvogt.
Restricted Application added a project: Plasma.
Restricted Application added a subscriber: plasma-devel.
broulik requested review of this revision.

REVISION SUMMARY
  This confuses websites. Instead keep a references to it as a variable which 
works just as well

TEST PLAN
  Tested media sessions API still works
  Didn't find the website that supposedly broke by it

REPOSITORY
  R856 Plasma Browser Integration

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

AFFECTED FILES
  extension/content-script.js

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

D13868: [KdePlasma-Addons/POTD/NOAA] Fixed the web address and fetched the picture from new address

[Tagore Chandan Reddy]

tagorechandanreddy updated this revision to Diff 37141.
tagorechandanreddy edited the test plan for this revision.
tagorechandanreddy added a comment.


  Made RegExp changes to simplify.

REPOSITORY
  R114 Plasma Addons

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D13868?vs=37103&id=37141

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

AFFECTED FILES
  dataengines/potd/noaaprovider.cpp
  dataengines/potd/noaaprovider.h

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

D13878: Also intercept creation of video elements

[Kai Uwe Broulik]

broulik updated this revision to Diff 37139.
broulik edited the summary of this revision.
broulik edited the test plan for this revision.
broulik added a comment.
This revision is now accepted and ready to land.


  - Remove child right after adding it, fixes YouTube and other video player 
breakage, also avoids leaking those DOM elements in the `head` element

REPOSITORY
  R856 Plasma Browser Integration

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D13878?vs=37133&id=37139

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

AFFECTED FILES
  extension/content-script.js

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

Re: Discussion for Virtual Desktops and Activities future

[Ivan Čukić]

> I think this is a fair recap so far:

The recap sounds great. 

> When Martin and I started talking about the
> Wayland protocol, we
> were keen to do work that would reusable 
> for either use case. This

I especially like this part. As I said, merging the implementation (at least to 
some extent) is a great idea.


> I think it's a reality that we have users who
> use both together, [...]

Yes, we have users that do that, we have users that only use one or the other, 
and we have users that don't use either.

It is the same with any more advanced feature we have. We give users the 
choice, and the users are smart enough to pick what they need.

We have several launchers, some use multiple ones, some a single one, and some 
don't use a launcher.

> It's also reality that we have critics who
> complain the two are
> redundant and it's all a big mess.

This part I don't care about. I care about users, not critics. Trolls will 
always find something to complain about.

> It's not a surprise to me that the idea of 
> merging them has come up,

I'm not surprised either, the same idea has been popping up every few years.

The problem with it is that the proposals are usually about modelling a 
particular person's view of activities. 

> It does mean
> being willing to take some people's existing 
> workflows away, though.

I'm not willing. It goes against Plasma design principle of 'simple by default, 
powerful when needed'.

I'm all for designing a new UI for all of this (though I'd like to see it based 
on the current one which I find quite pretty :) ) which would communicate 
clearly what activities are for and what VDs are for.

> I also think merging has technical risks, e.g. 

Not only the speed. It would also make problems for the Plasma - the current 
activities design is quite baked in the underlying organisation of the shell. 
What would this change require, and how would it handle different behaviours on 
X11 and Wayland which was mentioned in Phab.

> e.g. the VDG's
> mulled Activity overview/dashboard thingie.

This thing https://cukic.co/2014/07/01/just-a-teaser/ ?

Cheers,
Eike

D13881: oxygen-demo : add KMessage preview

[René J . V . Bertin]

rjvbb created this revision.
rjvbb added a reviewer: hpereiradacosta.
Restricted Application added a project: Plasma.
Restricted Application added a subscriber: plasma-devel.
rjvbb requested review of this revision.

REVISION SUMMARY
  A recent change to the `KMessageWidget` look has caught my interest and made 
me start to experiment with ways to make them integrate better, in particular 
concerning the use of colour (see D13777  
and recent posts on the frameworks-devel ML).
  
  This patch adds a preview of the 4 different KMessageWidget types to what I 
think is the most appropriate existing widget, plus the magic required for 
detecting and reacting to colour theme changes.
  
  This change makes testing a new look across all installed colour themes and 
widget styles much easier. Idem for assessing just how well the current design 
really works, of course.

TEST PLAN
  Works as intended.
  
  Possible improvements:
  
  - add a dedicated frame/tab that could show other, comparable widgets (but 
which?)
  - add a signal to `ColorSchemeChooser` (but is that better than handling the 
QEvent it already triggers?)

REPOSITORY
  R113 Oxygen Theme

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

AFFECTED FILES
  kstyle/demo/oxygenframedemowidget.cpp
  kstyle/demo/oxygenframedemowidget.h

To: rjvbb, hpereiradacosta
Cc: plasma-devel, ragreen, Pitel, ZrenBot, lesliezhai, ali-mohamed, 
jensreuterberg, abetts, sebas, apol, mart

D13878: Also intercept creation of video elements

[Kai Uwe Broulik]

broulik planned changes to this revision.
broulik added a comment.


  it seems the `video` tags accumulate in the DOM, sometimes it creates a new 
player when playing a new song. Also it seems to break YouTube first opening. ..

REPOSITORY
  R856 Plasma Browser Integration

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

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

D13879: Monitor document title

[Kai Uwe Broulik]

broulik created this revision.
broulik added reviewers: Plasma, davidedmundson, fvogt.
Restricted Application added a project: Plasma.
Restricted Application added a subscriber: plasma-devel.
broulik requested review of this revision.

REVISION SUMMARY
  When a website updates its page title dynamically or uses AJAX for page 
navigation, the page title when the player started might be outdated
  
  BUG: 395393

TEST PLAN
  I get proper page title in Spotify now when pressing play, however, when 
pausing it now changes to e.g. "Search" but it's either this, or that, so I'd 
rather have the current page title there. Might also fix some woes on YouTube 
where it uses Ajax page navigation in playlists

REPOSITORY
  R856 Plasma Browser Integration

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

AFFECTED FILES
  extension/content-script.js
  extension/extension.js
  host/mprisplugin.cpp
  host/mprisplugin.h

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

D13878: Also intercept creation of video elements

[Kai Uwe Broulik]

broulik created this revision.
broulik added reviewers: Plasma, davidedmundson, fvogt.
Restricted Application added a project: Plasma.
Restricted Application added a subscriber: plasma-devel.
broulik requested review of this revision.

REVISION SUMMARY
  Spotify web player uses a `video` tag instead of `audio` to play its music.
  We can do this as `` is invisible by default and if a page wants to 
show the player in the page, it has to manually add it to the DOM anyway, but 
we add it before we even return it from `createElement` so the order is correct 
here.
  
  BUG: 395379

TEST PLAN
  Verified that you can `appendChild` the same element to different elements 
and it just moves around instead of e.g. an "already attached to a parent" error
  I can control Spotify Web player now.
  When pressing play from the media controller, the title changes to the album 
name, as Spotify updates the page title only after the player started playing 
and we don't monitor the title tag yet, but this is unrelated to this patch
  Didn't notice anything unusual while casually browsing the web

REPOSITORY
  R856 Plasma Browser Integration

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

AFFECTED FILES
  extension/content-script.js

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

[Powerdevil] [Bug 348529] Turn off screen after lock screen

[Peter]

https://bugs.kde.org/show_bug.cgi?id=348529

Peter  changed:

   What|Removed |Added

 CC||pe...@ceiley.net

--- Comment #16 from Peter  ---
Is this included in any roadmap for a future release?  This is a key feature
for me.

-- 
You are receiving this mail because:
You are the assignee for the bug.