[kwalletmanager] [Bug 368314] kwalletmanager: "Export as XML..." produces empty file

[Kiril Vladimiroff via KDE Bugzilla]

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

Kiril Vladimiroff  changed:

   What|Removed |Added

 CC||ki...@vladimiroff.org

-- 
You are receiving this mail because:
You are watching all bug changes.

[digikam] [Bug 303848] BQM LensCorrection tool : doesn't work when 'use metadata' option is turned on

[Kiril Vladimiroff via KDE Bugzilla]

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

Kiril Vladimiroff  changed:

   What|Removed |Added

 CC||ki...@vladimiroff.org

--- Comment #18 from Kiril Vladimiroff  ---
I have the same issue with digiKam 5.0.0. The lens auto-correction can't
determine the subject distance (camera and lens are detected correctly) and
instead of assuming default value like the image editor (i.e. 0.0) it fails
completely.

Is there a way to work-around this?

-- 
You are receiving this mail because:
You are watching all bug changes.

[plasmashell] [Bug 351897] Plasma Shell freezes/hangs on file operations

[Kiril Vladimiroff via KDE Bugzilla]

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

Kiril Vladimiroff  changed:

   What|Removed |Added

 CC||ki...@vladimiroff.org

-- 
You are receiving this mail because:
You are watching all bug changes.

[kscreenlocker] [Bug 361008] "Require password after locking" setting is not respected in plasma 5.6

[Kiril Vladimiroff via KDE Bugzilla]

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

--- Comment #5 from Kiril Vladimiroff  ---
Uhm... this is happening under X11 session. Could this still be related?

-- 
You are receiving this mail because:
You are watching all bug changes.

[kscreenlocker] [Bug 361008] "Require password after locking" setting is not respected in plasma 5.6

[Kiril Vladimiroff via KDE Bugzilla]

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

Kiril Vladimiroff  changed:

   What|Removed |Added

 CC||ki...@vladimiroff.org

--- Comment #3 from Kiril Vladimiroff  ---
I suffer the same issue on Plasma 5.6  using Qt 5.6.0 (Arch's official
packages).

At first I though it might be a purely configuration issue in System Settings.
However even after deleting my `~/.config/kscreenlockerrc` file and tweaking
settings I got the same contents there.

--> cat ~/.config/kscreenlockerrc
[Daemon]
LockGrace=15
Timeout=1

[Greeter]
Theme=org.kde.breeze.desktop

It requires password immediately after locking. I'm sure it's the Lock screen's
settings performing the locking, because suspending session settings inside
"Power Management" -> "Energe Saving" are set to way more than a minute.

Also, I can confirm that this was working smoothly on the same machine with
Plasma 5.5.x.

@Martin, I would love to help by providing more information about my setup here
and everything else that might help debugging this.

-- 
You are receiving this mail because:
You are watching all bug changes.

[frameworks-kcmutils] [Bug 349631] There is no possibility to configure my touchscreen

[Kiril Vladimiroff via KDE Bugzilla]

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

Kiril Vladimiroff  changed:

   What|Removed |Added

 CC||ki...@vladimiroff.org

-- 
You are receiving this mail because:
You are watching all bug changes.

[kwin] [Bug 359567] Compositor suspend when specific application is started

[Kiril Vladimiroff via KDE Bugzilla]

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

--- Comment #16 from Kiril Vladimiroff  ---
Okay, I will be able to try this tomorrow and report if the issue is fixed.

> But if it's this https://aur.archlinux.org/packages/spotify/ , I could just 
> test it myself (the CEF thingy is somehow statically linked? I don't see 
> relevant deps)

Yes, this is the package that I'm using. If it's packaging issue, I will
contact the package owner with a fix.

-- 
You are receiving this mail because:
You are watching all bug changes.

[kwin] [Bug 359567] Compositor suspend when specific application is started

[Kiril Vladimiroff via KDE Bugzilla]

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

--- Comment #14 from Kiril Vladimiroff  ---
> a) Does that "Football Manager 2016" client never sport (pun intended)
> a WM_CLASS hint, or did you set it empty manually (because it also
> adds WM_CLASS late)?

It doesn't detect it. Even now when I try to create a new rule for it, I
get these lines via the "Detect window properties" button:

wmclass=
wmclasscomplete=false
wmclassmatch=1

> b) The pretty much means CEF is setting WM_CLASS after the map
> request, what's rather an icccm violation
>
> Strictly spoken though, it must be set as long as the window is
> withdrawn, maybe they keep it that state until it gets actually mapped
> (while that's not helpful ;-)
>
> => We might have to sync after mapping the window and before applying
> the rules? Can you try a patch (for kwin) - doesn't make sense to
> relax things here if the client sets WM_CLASS some seconds later.

I'm currently running a KWin from an offical Arch Linux package, but I
could try applying a patch and compiling kwin, as long as I can apply it
on top of the 5.5.4 tag.

-- 
You are receiving this mail because:
You are watching all bug changes.

[kwin] [Bug 359567] Compositor suspend when specific application is started

[Kiril Vladimiroff via KDE Bugzilla]

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

Kiril Vladimiroff  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |INVALID

--- Comment #12 from Kiril Vladimiroff  ---
Thomas, you're right. I'm manually blocking the compositor and then complaining
why it blocked.

http://i.lvme.me/sgl679d.jpg

-- 
You are receiving this mail because:
You are watching all bug changes.

[kwin] [Bug 359567] Compositor suspend when specific application is started

[Kiril Vladimiroff via KDE Bugzilla]

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

--- Comment #10 from Kiril Vladimiroff  ---
Created attachment 97297
  --> https://bugs.kde.org/attachment.cgi?id=97297=edit
~/.config/kwinrulesrc

No, but I use rules for sending particular windows to exact desktops and
Spotify is one of them. What I've tried is to force-fully disable blocking
composition for Spotify. (i.e. blockcompositing=false and
blockcompositingrule=2), but it doesn't seem to change anything.

I assume it doesn't help, because this option applies too late, since
compositor is getting suspended before the actual appearance of the window and
compositor is already suspended.

-- 
You are receiving this mail because:
You are watching all bug changes.

[kwin] [Bug 359567] Compositor suspend when specific application is started

[Kiril Vladimiroff via KDE Bugzilla]

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

--- Comment #8 from Kiril Vladimiroff  ---
5.19.0

-- 
You are receiving this mail because:
You are watching all bug changes.

[kwin] [Bug 359567] Compositor suspend when specific application is started

[Kiril Vladimiroff via KDE Bugzilla]

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

--- Comment #6 from Kiril Vladimiroff  ---
Created attachment 97296
  --> https://bugs.kde.org/attachment.cgi?id=97296=edit
xprop output when clicking the Steam's login window

-- 
You are receiving this mail because:
You are watching all bug changes.

[kwin] [Bug 359567] Compositor suspend when specific application is started

[Kiril Vladimiroff via KDE Bugzilla]

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

--- Comment #5 from Kiril Vladimiroff  ---
I knew that Spotify is using Chromium now, but I've ruled out Chromium
to be responsible for this, because suspend doesn't happen when I start
Chromium, Chrome or some Chrome app (like SlackDeck for example).

However, I've just learned that Spotify is NOT a Chromium app, but uses
Chromium Embedded Framework[1]. According to what I've been able to find
the Steam client for Linux is also using CEF.

Starting Steam involves updating (if not already up-to-date), logging in
(if not already), before showing the actual client. The first two
windows cause exactly the same issue:

1. Start Steam for the first time since weeks (i.e. it's not up-to-date)
2. Starts updating, showing a small window it a progress bar.
3. Composite goes to suspend.
4. I resume it with a shortcut.
5. Update is complete and login window is being showed.
6. Composite goes to suspend.
7. I resume it with a shortcut.
8. Successful login leads to opening the actual client window, *without*
   suspending the compositor.

Once updated, if I simply start it (i.e. already logged in and
up-to-date) it goes directly to step 8 and everything is fine. However
if I log out, stop the client and try starting it again (i.e. still
up-to-date, so steps 2, 3, 4 are omitted), the compositor gets suspended
because of the login window.

I will attach the output from xprop when clicking on the Steam's login
window. Could it be that something in CEF is causing this?

[1] https://en.wikipedia.org/wiki/Chromium_Embedded_Framework

-- 
You are receiving this mail because:
You are watching all bug changes.

[kwin] [Bug 359567] Compositor suspend when specific application is started

[Kiril Vladimiroff via KDE Bugzilla]

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

--- Comment #4 from Kiril Vladimiroff  ---
Created attachment 97295
  --> https://bugs.kde.org/attachment.cgi?id=97295=edit
xprop output when clicking the spotify window

Sure. However this is the output *after* the compositor is already suspended,
because it happens before the actual appearance of Spotify's window.

-- 
You are receiving this mail because:
You are watching all bug changes.

[kwin] [Bug 359567] Compositor suspend when specific application is started

[Kiril Vladimiroff via KDE Bugzilla]

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

--- Comment #2 from Kiril Vladimiroff  ---
Forgot the mention that I can always reproduce this regardless of the "OpenGL
interface" (i.e. EGL or GLX). The attached log is with EGL, though.

-- 
You are receiving this mail because:
You are watching all bug changes.

[kwin] [Bug 359567] Compositor suspend when specific application is started

[Kiril Vladimiroff via KDE Bugzilla]

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

--- Comment #1 from Kiril Vladimiroff  ---
Created attachment 97294
  --> https://bugs.kde.org/attachment.cgi?id=97294=edit
KWin output when Spotify is being started and stopped

-- 
You are receiving this mail because:
You are watching all bug changes.

[kwin] [Bug 359567] New: Compositor suspend when specific application is started

[Kiril Vladimiroff via KDE Bugzilla]

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

Bug ID: 359567
   Summary: Compositor suspend when specific application is
started
   Product: kwin
   Version: 5.5.4
  Platform: Archlinux Packages
OS: Linux
Status: UNCONFIRMED
  Severity: normal
  Priority: NOR
 Component: compositing
  Assignee: kwin-bugs-n...@kde.org
  Reporter: ki...@vladimiroff.org

I'm going to use Spotify as an example here, because it's the only application
I can *always* reproduce this with. It sometimes happens with LibreOffice
applications, but haven't figured the pattern, yet.

Reproducible: Always

Steps to Reproduce:
1. Make sure compositor is enabled and working.
2. Start Spotify.


Actual Results:  
Right after starting Spotify compositor is getting suspended. When I stop the
application compositor resumes by itself. However, I'm able to resume it with
my "Suspend compositing" shortcut and it works.

Expected Results:  
Compositor shouldn't suspend when specific applications are being started, when
the option "Suspend compositor for full screen windows" is disabled or the
application is not on full screen.

I've annotated the attached log of `kwin_x11 --replace` with when Spotify was
started and stopped using lines starting with `###`.

-- 
You are receiving this mail because:
You are watching all bug changes.

[okular] [Bug 356359] Can't open documents with non-ascii filenames

[Kiril Vladimiroff via KDE Bugzilla]

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

--- Comment #10 from Kiril Vladimiroff  ---
Not sure it's only due to the changed value of LANGUAGE. These settings should
only modify LANGUAGE and LC_* env vars, as far as I get it, but I may be wrong.

However, I'm 100% positive that that manipulating Regional settings can cause
this bug, i.e. Okular is able to open document with non-ascii filenames,
depending on specific regional formats settings.

-- 
You are receiving this mail because:
You are watching all bug changes.

[okular] [Bug 356359] Can't open documents with non-ascii filenames

[Kiril Vladimiroff via KDE Bugzilla]

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

--- Comment #6 from Kiril Vladimiroff  ---
Dolphin: 15.08.3
KDE Frameworks: 5.16

-- 
You are receiving this mail because:
You are watching all bug changes.

[okular] [Bug 356359] Can't open documents with non-ascii filenames

[Kiril Vladimiroff via KDE Bugzilla]

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

--- Comment #4 from Kiril Vladimiroff  ---
While writing the bug report I didn't think there's a difference in how I
"open" documents. After I found out that this assumption is wrong, I've
described that in comment #2:

> After trying to get this one confirmed by other users in #kde, several folks
> there helped finding out that this issue occurs only when okular is invoked
> by other application like  Dolphin, Firefox (when pdf is downloaded), KMail
> (when pdf file is received as an attachment), xdg-open, etc. If I use
> kde-open the issue is the same, but the encoding seems to be different
> (still not utf8, though), because the error is "Could not open
> /home/kiril/desktop/???.pdf". Notice the question marks, instead of ...
> those other funny symbols.
> 
> However, if I simply execute "okular име.pdf" the file simply opens and
> everything's fine. So, it looks like this issue is not in Okular in
> particular, but it's the only place where I suffer from it.

-- 
You are receiving this mail because:
You are watching all bug changes.

[okular] [Bug 356359] New: Can't open documents with non-ascii filenames

[Kiril Vladimiroff via KDE Bugzilla]

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

Bug ID: 356359
   Summary: Can't open documents with non-ascii filenames
   Product: okular
   Version: 0.23.0
  Platform: Archlinux Packages
OS: Linux
Status: UNCONFIRMED
  Severity: normal
  Priority: NOR
 Component: general
  Assignee: okular-de...@kde.org
  Reporter: ki...@vladimiroff.org

When I try to open a document named "име.pdf" I get the following error: "Could
not open /home/kiril/име.pdf" (see the attached screenshot). When I rename
the file using only ascii symbols, everything's fine.  Even though my locales
are strictly en_US.UTF8, it seems like Okular doesn't respect that.

Output from the command "locale":   
LANG=en_US.UTF-8
LC_CTYPE="en_US.UTF-8"
LC_NUMERIC="en_US.UTF-8"
LC_TIME="en_US.UTF-8"
LC_COLLATE="en_US.UTF-8"
LC_MONETARY="en_US.UTF-8"
LC_MESSAGES="en_US.UTF-8"
LC_PAPER="en_US.UTF-8"
LC_NAME="en_US.UTF-8"
LC_ADDRESS="en_US.UTF-8"
LC_TELEPHONE="en_US.UTF-8"
LC_MEASUREMENT="en_US.UTF-8"
LC_IDENTIFICATION="en_US.UTF-8"
LC_ALL=en_US.UTF-8

P.S.: I'm assuming this is an issue in Okular, because everything else in
cyrillic works just fine in other KDE applications (Plasma, Dolphin, Gwenview,
etc.).

Reproducible: Always

Steps to Reproduce:
1. Open a regular .pdf document with ascii-only symbols in its name with Okular
2. Rename it by using cyrillic symbols, like "тест.pdf" for example
3. Try to open it again with Okular

Actual Results:  
You get an error similar to "Could not open /home/.../.../ÑеÑÑ.pdf"

Expected Results:  
Document should simply be opened, regardless of the non-ascii symbols in its
name.

-- 
You are receiving this mail because:
You are watching all bug changes.

[okular] [Bug 356359] Can't open documents with non-ascii filenames

[Kiril Vladimiroff via KDE Bugzilla]

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

--- Comment #1 from Kiril Vladimiroff  ---
Created attachment 95922
  --> https://bugs.kde.org/attachment.cgi?id=95922=edit
Could not open /home/kiril/име.pdf

-- 
You are receiving this mail because:
You are watching all bug changes.

[okular] [Bug 356359] Can't open documents with non-ascii filenames

[Kiril Vladimiroff via KDE Bugzilla]

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

--- Comment #2 from Kiril Vladimiroff  ---
After trying to get this one confirmed by other users in #kde, several folks
there helped finding out that this issue occurs only when okular is invoked by
other application like  Dolphin, Firefox (when pdf is downloaded), KMail (when
pdf file is received as an attachment), xdg-open, etc. If I use kde-open the
issue is the same, but the encoding seems to be different (still not utf8,
though), because the error is "Could not open /home/kiril/desktop/???.pdf".
Notice the question marks, instead of ... those other funny symbols.

However, if I simply execute "okular име.pdf" the file simply opens and
everything's fine. So, it looks like this issue is not in Okular in particular,
but it's the only place where I suffer from it.

-- 
You are receiving this mail because:
You are watching all bug changes.