from:"i.Dark_Templar"

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

i.Dark_Templar  changed:

   What|Removed |Added

  Latest Commit||4700608e8a8ef59b5f3af51267d
   ||59ba35cffb395

--- Comment #6 from i.Dark_Templar  ---
(In reply to Kai Uwe Broulik from comment #3)
> Can confirm with Audacious in WinAmp mode. I can see the model not updating
> in GammaRay, so bug is in XWindowTasksModel, not the taskmanager applet.

Thanks for pointing this out. I've looked into diff in related file between
v5.20.5 and v5.21.5. There wasn't much of changes. Reverting commit
4700608e8a8ef59b5f3af51267d59ba35cffb395 fixed issue for me. There were some
revert conflicts due to reformatting of code. Not sure if issue is in that code
or if it just unveils a bug in another place.

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

[plasmashell] [Bug 438222] Regression: taskbar doesn't update title of window under specific conditions

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

--- Comment #5 from i.Dark_Templar  ---
Yes, I've tried downgrading Plasma to 5.20.5 while keeping kde-frameworks at
5.82.0, and it worked for me.

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

[plasmashell] [Bug 438222] Regression: taskbar doesn't update title of window under specific conditions

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

--- Comment #2 from i.Dark_Templar  ---
For me it reproduces always with Audacious in described scenario.

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

[plasmashell] [Bug 438222] New: Regression: taskbar doesn't update title of window under specific conditions

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

Bug ID: 438222
   Summary: Regression: taskbar doesn't update title of window
under specific conditions
   Product: plasmashell
   Version: 5.21.5
  Platform: Gentoo Packages
OS: Linux
Status: REPORTED
  Severity: normal
  Priority: NOR
 Component: Panel
  Assignee: plasma-b...@kde.org
  Reporter: idarktemp...@mail.ru
  Target Milestone: 1.0

Created attachment 139089
  --> https://bugs.kde.org/attachment.cgi?id=139089=edit
screenshot.png

SUMMARY
After upgrading to Plasma/X11 5.21.5 I've noticed that title of Audacious
player on taskbar doesn't update when next audio file is playing.

STEPS TO REPRODUCE
1. Use Audacious with Qt5 classic winamp-like interface. Tested this with
Audacious 4.1.
2. Ensure there are only 2 windows of Audacious are present: main window and
playlist window.
3. Start playing audio file in Audacious. If it's first song, title of
Audacious might be updated to reflect name of audio file.
4. Make Audacious play another audio file or pause/stop playing. Any way is
fine: using 'next track', 'previous track', 'pause' or 'stop' buttons, clicking
on another audio file in playlist or just waiting until current audio file is
finished and next one is started.

OBSERVED RESULT
Title of Audacious on task panel doesn't update.

EXPECTED RESULT
Title of Audacious on task panel should update to reflect name of current track
or state of playback.

SOFTWARE/OS VERSIONS
Linux/KDE Plasma: Plasma/X11
(available in About System)
KDE Plasma Version:  5.21.5
KDE Frameworks Version: 5.82.0
Qt Version: 5.15.2

ADDITIONAL INFORMATION
It worked fine with KDE Plasma 5.20.5. Downgrading fixes this issue for me.

Attaching screenshot with Audacious and part of tasks panel. Name of audio file
in main window and playlist window doesn't match name of audio file on tasks
panel in the bottom of screenshot.

Running "xprop" on main Audacious window shows correct window name. When
switching to different window via "alt+tab" key combination, correct window
name is displayed in task manager.

If Audacious has only one window, i.e. there is main window and no playlist
window, it updates name fine.

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

[kwin] [Bug 415286] KWin compositing makes Proton fullscreen games freeze after alt + tab

2021-05-04 Thread i.Dark_Templar

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

i.Dark_Templar  changed:

   What|Removed |Added

 CC||idarktemp...@mail.ru

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

[plasmashell] [Bug 431946] After upgrade to KDE Plasma 5.20.5, unexpectedly new apps are pinned to Task Manager

2021-01-25 Thread i.Dark_Templar

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

--- Comment #4 from i.Dark_Templar  ---
(In reply to Nate Graham from comment #3)
> Ah yes, the old issue where changing the defaults only affects people who
> had not changed anything in the past. :/
> 
> Unfortunately we don't have a generic way to say "this change should affect
> everyone" or "this change should only affect new users".
> 

My bug is exactly about this: next time something like this is implemented it'd
be good to have some way to separate those two cases, and for existing users at
least ask them. Like, "we have this new shiny feature. Want to try it out?".

> However in this case, it was intentional: we wanted people to get new pinned
> icons if they previously had not customized anything. I understand that you
> might disagree, but there's no way to change it back at this point since
> it's already happened. :)

Of course, I didn't intend to wait for next KDE release to remove components
unneeded for me, and do it for me specifically :) I did it on my own after
reporting bug.

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

[Oxygen] [Bug 431962] New: invalid/placeholder icon for "Applications" menu in systemsettings with oxygen icon theme

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

Bug ID: 431962
   Summary: invalid/placeholder icon for "Applications" menu in
systemsettings with oxygen icon theme
   Product: Oxygen
   Version: 5.20.5
  Platform: Gentoo Packages
OS: Linux
Status: REPORTED
  Severity: normal
  Priority: NOR
 Component: icons
  Assignee: n...@oxygen-icons.org
  Reporter: idarktemp...@mail.ru
  Target Milestone: ---

Created attachment 135075
  --> https://bugs.kde.org/attachment.cgi?id=135075=edit
systemsettings_icon.png

SUMMARY
I've noticed that icon of "Applications" menu in systemsettings changed. I
remember it being different one, and new one looks like some placeholder icon.
Icon changed after some upgrade, but I don't know which one caused this issue
synce I don't use systemsettings often.

STEPS TO REPRODUCE
1. Switch to oxygen icons theme
2. Open main window of systemsettings

OBSERVED RESULT
Invalid/placeholder icon like one on attached screenshot in icon view or no
icon at all in sidebar view.

EXPECTED RESULT
Recognizable icon for applications menu.

SOFTWARE/OS VERSIONS
Linux/KDE Plasma: 5.4.80-gentoo-r1
(available in About System)
KDE Applications Version: 20.08.3
KDE Plasma Version: 5.20.5
KDE Frameworks Version: 5.77.0
Qt Version: 5.15.2

ADDITIONAL INFORMATION
It looks like issue appears both in icon and sidebar views.

It looks like default application for this menu was changed some time ago:
https://invent.kde.org/plasma/systemsettings/-/commit/bd07ce4b7caabfaf2d7659c9807bd41e51e99a2f

Breeze icons theme has new icon, thus bug doesn't reproduce with breeze icons
theme:
https://invent.kde.org/frameworks/breeze-icons/-/blob/master/icons/categories/32/applications-all.svg

On the other hand, oxygen icons theme doesn't have such icon:
https://invent.kde.org/frameworks/oxygen-icons5/-/tree/master/128x128/categories

But it has old icon, which was displayed in systemsettings before icon
disappeared:
https://invent.kde.org/frameworks/oxygen-icons5/-/blob/master/128x128/apps/preferences-desktop-default-applications.png

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

[plasmashell] [Bug 431946] After upgrade to KDE Plasma 5.20.5, unexpectedly new apps are pinned to Task Manager

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

--- Comment #2 from i.Dark_Templar  ---
I didn't reset my settings before, during or after upgrade. I didn't remove or
add/readd panels. But I had no pinned applications since I prefer traditional
task panel icons which don't disappear when an instance of application is
started.

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

[plasmashell] [Bug 383202] System tray icon's context menu isn't updated properly in plasma/x11

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

--- Comment #13 from i.Dark_Templar  ---
Updated to plasma-workspace 5.20.5. Bug is still present. Attached application
still reproduces issue. Linked patch still fixes issue, although it had to be
rebased again.

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

[plasmashell] [Bug 431946] New: After upgrade to KDE Plasma 5.20.5, unexpectedly new icons appear on main panel

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

Bug ID: 431946
   Summary: After upgrade to KDE Plasma 5.20.5, unexpectedly new
icons appear on main panel
   Product: plasmashell
   Version: 5.20.5
  Platform: Gentoo Packages
OS: Linux
Status: REPORTED
  Severity: normal
  Priority: NOR
 Component: Panel
  Assignee: plasma-b...@kde.org
  Reporter: idarktemp...@mail.ru
  Target Milestone: 1.0

Created attachment 135065
  --> https://bugs.kde.org/attachment.cgi?id=135065=edit
taskbar.png

SUMMARY
After upgrade to KDE Plasma 5.20.5, new items are added without user's input.

STEPS TO REPRODUCE
1. Have KDE Plasma 5.19.5 installed
2. Following items are at the start of main panel: menu, removable devices,
konsole, browser, taskbar, tray, clock
3. Upgrade to KDE Plasma 5.20.5

OBSERVED RESULT
After browser new items are added to main panel: system settings, discover and
browser. But there is even no discover installed.

EXPECTED RESULT
No new icons on main panel.

SOFTWARE/OS VERSIONS
Linux/KDE Plasma: 5.4.80-gentoo-r1
(available in About System)
KDE Applications Version: 20.08.3
KDE Plasma Version: 5.20.5
KDE Frameworks Version: 5.77.0
Qt Version: 5.15.2

ADDITIONAL INFORMATION
Not sure if bug component is correctly selected. Please reassign if it's wrong.

I think it's a regression from 86329ca1ae
(https://invent.kde.org/plasma/plasma-desktop/-/commit/86329ca1ae): KDE
shouldn't silently corrupt user's configuration by such changes. It's ok to
change default configuration, but it should at least ask before modifying
user's settings, if touch it at all.

Attached is a cropped image with additional added items. Browser is hidden
since it's running, file manager too.

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

[plasmashell] [Bug 383202] System tray icon's context menu isn't updated properly in plasma/x11

2020-11-09 Thread i.Dark_Templar

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

--- Comment #10 from i.Dark_Templar  ---
(In reply to Nate Graham from comment #9)
> Is this still happening for you in Plasma 5.20--or even better, with current
> git master? A lot of fixes related to this have landed recently.

I'll check it when Plasma 5.20.X gets marked stable in Gentoo amd64. Currently
5.19.5 is stable there.

There's also attached test which should reproduce issue.

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

[plasmashell] [Bug 354802] Desktop Icon position gets scrambled sometimes on reboot.

2020-10-12 Thread i.Dark_Templar

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

--- Comment #139 from i.Dark_Templar  ---
(In reply to Nick Stefanov from comment #134)

(In reply to Nate Graham from comment #135)

I'm not KDE dev, so I don't know their priorities, but I guess one important
point might be missing: issue might not reproduce at all or often enough for
devs or people willing/capable to debug and/or fix it. I guess that bug happens
often for Nick Stefanov, but doesn't happen at all for Nate Graham. For me,
after I created first patch and later used fix by Eike Hein, similar issue
reproduced only once, which I mentioned in
https://bugs.kde.org/show_bug.cgi?id=354802#c107. That is hitting issue once in
almost two years, and on average I'm logging into KDE X11 session around once a
day. If I include times when I do it more than once a day, I can say that I
logged into KDE over 1000 times since applying a patch. 1/1000 reproduction
rate - bug practically never reproduces for me anymore on it's own. There is
just not enough information to reproduce it at least somewhat reliably, I
guess.

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

[frameworks-kio] [Bug 423756] kio: cgroup creation race condition

2020-07-04 Thread i.Dark_Templar

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

--- Comment #2 from i.Dark_Templar  ---
(In reply to David Edmundson from comment #1)
> There is a theoretical race, yes. 
> 
> The landed patch was a somewhat "lite" and invasive version of introducing
> the concept.
> 
> What you describe is how systemd-run does it.
> 
> But there's a much simpler solution, we can just use
> startTransientService(execLine) instead of startTransientScope(somePid) then
> it all becomes someone else's problem.
> 
> See:
> 
> https://invent.kde.org/frameworks/kio/-/merge_requests/71

I've looked a bit at this merge request and it looks like it should fix this
issue. And it should also allow to implement later something like
CgroupV2ProcessRunner for systems with no systemd.

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

[konqueror] [Bug 422522] konqueror: when preload is activated, konqueror doesn't quit and it's restored as blank window on next login

2020-07-03 Thread i.Dark_Templar

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

--- Comment #2 from i.Dark_Templar  ---
(In reply to Christoph Feck from comment #1)
> Could you please check if the commit for bug 388333 also fixes this issue?
> You need Konqueror version 20.04.1 (which is unrelated to Plasma version).

I've updated to konqueror 20.04.2, which includes mentioned fix AFAIK, and it
didn't fix this issue for me.

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

[frameworks-kio] [Bug 423758] New: kio feature request: cgroups support not depending on systemd

2020-07-01 Thread i.Dark_Templar

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

Bug ID: 423758
   Summary: kio feature request: cgroups support not depending on
systemd
   Product: frameworks-kio
   Version: git master
  Platform: Other
OS: Linux
Status: REPORTED
  Severity: normal
  Priority: NOR
 Component: general
  Assignee: kio-bugs-n...@kde.org
  Reporter: idarktemp...@mail.ru
CC: kdelibs-b...@kde.org
  Target Milestone: ---

SUMMARY
There are Linux systems with cgroups support with no systemd present. It'd be
great if cgroup support in kio could be extended to support such systems since
it needs rework anyway due to bug 423756 and there's not much reasons to make
this feature systemd-dependent. It might be necessary to create or use some
helper with setuid or capabilities for cgroup creation and population though.

STEPS TO REPRODUCE
1. Use Linux system with cgroups support but without systemd.

OBSERVED RESULT
Cgroups aren't utilized by kio when no systemd present or running.

EXPECTED RESULT
Cgroups should be utilized if they're present even if no systemd is present and
running.

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

[frameworks-kio] [Bug 423756] New: kio: cgroup creation race condition

2020-07-01 Thread i.Dark_Templar

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

Bug ID: 423756
Summary: kio: cgroup creation race condition
Product: frameworks-kio
Version: git master
Platform: Other
OS: Linux
Status: REPORTED
Severity: normal
Priority: NOR
Component: general
Assignee: kio-bugs-n...@kde.org
Reporter: idarktemp...@mail.ru
CC: kdelibs-b...@kde.org
Target Milestone: ---

SUMMARY
Since cgroup is created in kio after process startup, there is a race condition
present if started process forks and starts some children before cgroup
creation is processed.

Currently, situation sometimes, depending on various circumstances, may be
following:
1. kio starts new process via KProcessRunner class.
2. Started process runs and forks, creating one or more children.
3. kio creates new cgroup and puts started process to this new cgroup. All
children created by started process stay in current cgroup.

STEPS TO REPRODUCE
1. Try starting via KProcessRunner class applications which fork soon after
launch.
Modern firefox, for example.
If application forks and parent exits, it's even better.

OBSERVED RESULT
Sometimes created cgroup would contain only parent process without any it's
children. If parent process quits, it may result even into an empty cgroup.
Children of launched process would be left in the cgroup of parent of launched
process. Should not be reliably reproducible.

EXPECTED RESULT
Cgroup should contain both started process and all it's children reliably.

ADDITIONAL INFORMATION
I did not try reproducing it.

Currently, cgroup created when process is already running, and if this process
creates some children fast, it may lead to described issue. Here's the link to
code:

https://invent.kde.org/frameworks/kio/-/blob/8d6b306f585920230acecd19903325f6f0387b8e/src/gui/kprocessrunner.cpp#L226

Function 'registerCGroup()' is called in 'KProcessRunner::slotProcessStarted()'
slot, which is invoked after process started, within some undetermined
timeframe.

In my opinion, proper way to start process in new cgroup in order to fix this
issue looks like following:
1. KProcessRunner forks.
2. Fork sets up cgroup, puts itself into it, waits until it's confirmed that OS
finished moving it into new cgroup. Optionally between forking and setting up
cgroup, it may exec into some helper which would setup cgroup.
3. Fork (or helper used to setup cgroup, if one is used) execs into the new
process. Since it's already running in new cgroup before exec, when new process
is started it's already contained in new cgroup, and even if first thing it
does is fork() call, all children would be contained in that new cgroup as
well, without any race conditions.

AFAIK, systemd-run actually setups cgroup and reliably puts requested process
and all it's children into newly created cgroup, but I might be wrong. Not sure
which interfaces are available from systemd via dbus or some library for
starting process similarly to systemd-run.

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

[plasmashell] [Bug 354802] Desktop Icon position gets scrambled sometimes on reboot.

2020-06-19 Thread i.Dark_Templar

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

--- Comment #107 from i.Dark_Templar  ---
Today first time since I made my patch and later switched to upstream patch,
some issue happened on my system which lead to partial desktop settings reset.
Not sure what caused it. I did a series of logouts and logins back to same user
while debugging different issue, and after one of logins some settings were
reset.

Following settings were reset for me:
desktop wallpaper
desktop icons size
all desktop icon positions

Following settings were left intact:
desktop panels configuration

Since I don't use desktop widgets I have no idea if they'd be reset as well.

I've tried doing a bit more of similar logouts and logins but was unable to
reproduce it once more.

OS: Gentoo Linux
Session: X11
Plasma: 5.18.5
KDE Frameworks: 5.70.0
KDE Applications: 19.12.3
Qt: 5.14.2

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

[konqueror] [Bug 422522] New: konqueror: when preload is activated, konqueror doesn't quit and it's restored as blank window on next login

2020-06-06 Thread i.Dark_Templar

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

Bug ID: 422522
   Summary: konqueror: when preload is activated, konqueror
doesn't quit and it's restored as blank window on next
login
   Product: konqueror
   Version: 5.0.97
  Platform: Gentoo Packages
OS: Linux
Status: REPORTED
  Severity: normal
  Priority: NOR
 Component: general
  Assignee: konq-b...@kde.org
  Reporter: idarktemp...@mail.ru
  Target Milestone: ---

Created attachment 129098
  --> https://bugs.kde.org/attachment.cgi?id=129098=edit
konqueror-quit.log

SUMMARY
If "preload" option is active, which is a default setting AFAIK, and user
session is configured to restore previous session on login, on login konqueror
window might be unexpectedly restored if last time konqueror was used and
closed. Reproduced on Linux/X11 with KDE desktop.

STEPS TO REPRODUCE
1. go to "system settings" -> "Startup and Shutdown" -> "Desktop Session" ->
select to "Restore previous session" on login and apply.
2. run "konqueror", go to menu "Settings" -> "Configure Konqueror..." ->
"Performance", ensure that "Preload an instance after desktop startup" is
unchecked while "Always try to have one preloaded instance" is checked.
3. If "Always try to have one preloaded instance" wasn't checked, it might be
necessary to close and reopen konqueror.
4. Close konqueror.
5. Logout of desktop session
6. Login back to same session, restoring last session

OBSERVED RESULT
On login, konqueror with blank window is restored. Since all konqueror windows
were closed, it's unexpected to have it restored. Furthermore, between steps 4
and 5, after konqueror window is closed, konqueror process doesn't quit and
continues to exist.

EXPECTED RESULT
Either konqueror must quit when last window is closed, or it must not be
restored when saved session is restored if no konqueror windows were visible in
last session, or such restored windows must be invisible when restored too.

SOFTWARE/OS VERSIONS
Linux/KDE Plasma: 
(available in About System)
KDE Plasma Version: 19.12.3
KDE Frameworks Version: 5.70.0
Qt Version: 5.14.2

ADDITIONAL INFORMATION
It looks like unsetting "Preload an instance after desktop startup" prevents
issue from appearing.

Attached file contains part of gdb output for watching
QCoreApplicationPrivate::quitLockRef from start of konqueror till last window
is closed. Application didn't quit since one QEventLoopLockerPrivate wasn't
destroyed with last window. After tracking creation and destruction of each
QEventLoopLockerPrivate instance, it turned out it was an instance of
KonqMainWindow created by preload with following backtrace:

#0  0x75bdb4b4 in QCoreApplicationPrivate::ref
(this=this@entry=0x555774b0) at
/usr/lib/gcc/x86_64-pc-linux-gnu/9.3.0/include/g++-v9/bits/atomic_base.h:318
#1  0x75bd9d94 in QEventLoopLockerPrivate::QEventLoopLockerPrivate
(app=0x555774b0, this=0x55dde3f0)
at
/var/tmp/portage/dev-qt/qtcore-5.14.2/work/qtbase-everywhere-src-5.14.2/src/corelib/kernel/qeventloop.cpp:367
#2  QEventLoopLocker::QEventLoopLocker (this=0x55cffaa8)
at
/var/tmp/portage/dev-qt/qtcore-5.14.2/work/qtbase-everywhere-src-5.14.2/src/corelib/kernel/qeventloop.cpp:428
#3  0x773689de in KMainWindowPrivate::KMainWindowPrivate
(this=0x55cffa40) at /usr/include/qt5/QtCore/qarraydata.h:257
#4  KXmlGuiWindowPrivate::KXmlGuiWindowPrivate (this=0x55cffa40) at
/var/tmp/portage/kde-frameworks/kxmlgui-5.70.0/work/kxmlgui-5.70.0/src/kxmlguiwindow.cpp:62
#5  KXmlGuiWindow::KXmlGuiWindow (this=0x55d17c70,
__vtt_parm=0x77f74730 , parent=0x0, f=...,
__in_chrg=)
at
/var/tmp/portage/kde-frameworks/kxmlgui-5.70.0/work/kxmlgui-5.70.0/src/kxmlguiwindow.cpp:83
#6  0x779430e5 in KParts::MainWindow::MainWindow (this=0x55d17c70,
__vtt_parm=0x77f74728 , parent=,
f=...,
__in_chrg=) at
/var/tmp/portage/kde-frameworks/kparts-5.70.0/work/kparts-5.70.0/src/mainwindow.cpp:67
#7  0x77f0f3bd in KonqMainWindow::KonqMainWindow (this=0x55d17c70,
initialURL=..., __in_chrg=, __vtt_parm=)
at /usr/include/qt5/QtCore/qflags.h:119
#8  0x77f18823 in ::operator() (__closure=)
at
/var/tmp/portage/kde-apps/konqueror-19.12.3/work/konqueror-19.12.3/src/konqmainwindowfactory.cpp:49
#9  QtPrivate::FunctorCall, QtPrivate::List<>, void,
ensurePreloadedWindow():: >::call (f=..., arg=)
at /usr/include/qt5/QtCore/qobjectdefs_impl.h:146
#10 QtPrivate::Functor,
0>::call, void> (f=..., arg=)
at /usr/include/qt5/QtCore/qobjectdefs_impl.h:256
#11 QtPrivate::QFunctorSlotObject, 0,
QtPrivate::List<>, void>::impl(int, QtPrivate::QSlotObjectBase *, QObject *,
void **, bool *) (
which=, this_=, r=,
a=, ret=) at
/usr/include/qt5/QtCore/qobjectdefs_impl.h:443
#12 0x75c11802 in QtPrivate::QSlotObjectBase::call (a=0x7fffd270,
r=, this=)
at

[dolphin] [Bug 419360] dolphin shows exit confirmation dialog on session logout with qt >= 5.14.0

2020-03-29 Thread i.Dark_Templar

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

i.Dark_Templar  changed:

   What|Removed |Added

Summary|dolphin show exit   |dolphin shows exit
   |confirmation dialog on  |confirmation dialog on
   |session logout with qt >=   |session logout with qt >=
   |5.14.0  |5.14.0

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

[dolphin] [Bug 419360] New: dolphin show exit confirmation dialog on session logout with qt >= 5.14.0

2020-03-29 Thread i.Dark_Templar

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

Bug ID: 419360
   Summary: dolphin show exit confirmation dialog on session
logout with qt >= 5.14.0
   Product: dolphin
   Version: 19.12.3
  Platform: Gentoo Packages
OS: Linux
Status: REPORTED
  Severity: normal
  Priority: NOR
 Component: general
  Assignee: dolphin-bugs-n...@kde.org
  Reporter: idarktemp...@mail.ru
CC: kfm-de...@kde.org
  Target Milestone: ---

Created attachment 127076
  --> https://bugs.kde.org/attachment.cgi?id=127076=edit
some information from gdb

After upgrade from Qt-5.13.2 to Qt-5.14.1 on KDE session shutdown dolphin
started asking to confirm if I want to quit while multiple tabs are open. It
didn't ask for such confirmation with Qt-5.13.2 on session logout. And current
session is saved successfully with no regards which button was pressed in this
dialog or if any button was pressed at all.

STEPS TO REPRODUCE
1. Open at least 2 tabs in dolphin
2. Ensure that confirmation to close dolphin window with multiple open tabs is
enabled
3. Ensure that qt-5.14.1 or newer is used
4. Ensure that previous session restoring is selected in session management
configuration of KDE
4. Logout from KDE session

OBSERVED RESULT
Dolphin asks to confirm closing window on session logout. If you wait too long,
it'll just eventually crash, but on next start session would be restored.

EXPECTED RESULT
Dolphin should silently save current session and restore it next time

SOFTWARE/OS VERSIONS
Linux/KDE Plasma: Gentoo Linux with kernel 4.14.166
(available in About System)
KDE Plasma Version: 5.17.5
KDE Frameworks Version: 5.67.0
Qt Version: 5.14.1
Dolphin Version: 19.12.3

ADDITIONAL INFORMATION
While bug appears in dolphin 19.12.3 for me, I guess it'd appear in other
versions too when Qt >= 5.14.0 is used.

I suspect that it's related to following Qt change but I didn't confirm it:
https://code.qt.io/cgit/qt/qtbase.git/commit/?id=1b6db184947

Attached file contains a bit of information I could obtain using gdb. It looks
like dolphin receives two close events on session logout. In first one
'QGuiApplication::isSavingSession()' returns true and dolphin silently saves
information about current session. In second one
'QGuiApplication::isSavingSession()' returns false and it triggers displaying
confirmation dialog.

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

[plasmashell] [Bug 383202] System tray icon's context menu isn't updated properly in plasma/x11

2019-10-17 Thread i.Dark_Templar

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

--- Comment #7 from i.Dark_Templar  ---
I don't think it's a bug in Qt because, as I wrote in original comment, it
didn't reproduce with LXQt desktop for me, and LXQt is based on Qt mostly, and
my patch for KDE, while it might have downsides or things to improve, fixes
this bug.

I'm using KDE with linked patch since reporting this bug and it works fine for
me all the time.

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

[konsole] [Bug 410497] Main window recreation on settings change

2019-08-02 Thread i.Dark_Templar

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

--- Comment #2 from i.Dark_Templar  ---
(In reply to Mariusz Glebocki from comment #1)
> The fix waits for review:
> https://invent.kde.org/kde/konsole/merge_requests/16

Thanks! I've rebuilt konsole with this patch and it fixes issue for me.

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

[konsole] [Bug 410495] Tab bar has line artifact if new tab button is enabled

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

--- Comment #2 from i.Dark_Templar  ---
it happens only if 'Oxygen' Look and Feel theme is used. If I switch to Breeze
or Breeze Dark, issue disappears.

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

[konsole] [Bug 410495] Tab bar has line artifact if new tab button is enabled

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

--- Comment #1 from i.Dark_Templar  ---
I've just noticed while trying different settings that if I select 'On the tab
bar' in 'Close Tab button' combobox in same menu, I see the line on the
appearing button too.

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

[konsole] [Bug 410497] New: Main window recreation on settings change

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

Bug ID: 410497
   Summary: Main window recreation on settings change
   Product: konsole
   Version: 19.04.3
  Platform: Gentoo Packages
OS: Linux
Status: REPORTED
  Severity: normal
  Priority: NOR
 Component: general
  Assignee: konsole-de...@kde.org
  Reporter: idarktemp...@mail.ru
  Target Milestone: ---

SUMMARY
After upgrade to konsole-19.04.3, when I'm changing and applying settings, main
konsole window is recreated, and if it overlaps with settings window, settings
window may be partially or fully hidden.

STEPS TO REPRODUCE
1. Start Konsole
2. Maximize Konsole window
3. Open 'Settings' -> 'Configure Konsole...' menu. Ensure that this window is
placed above Konsole window if you have multiple screens/desktops/etc.
4. Open 'TabBar' tab and toggle 'Show New Tab button' setting. Any other
settings instead of this one may be changed.
5. Click 'Apply' button.

OBSERVED RESULT
Settings window is hidden by recreated Konsole window.

EXPECTED RESULT
Visibility of settings window shouldn't be changed.

SOFTWARE/OS VERSIONS
Linux/KDE Plasma: Linux 4.14.132-gentoo x86_64
(available in About System)
KDE Plasma Version: 5.15.5
KDE Frameworks Version: 5.60.0
Qt Version: 5.12.3

ADDITIONAL INFORMATION
I'm not sure if it's regression from 18.12.3 or some earlier version.

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

[konsole] [Bug 410495] New: Tab bar has line artifact if new tab button is enabled