Firefox or cairo-dock were certainly not targetted or affected by the
related patches.
This only affects Qt applications directly, so if that indeed triggered
something, either the session crashes on logout or the mentioned
applications used some timer based self-quitting (and are thus no more
(In reply to Storm Engineer from comment #58)
> The following do NOT get restored:
> - Firefox
https://forum.kde.org/viewtopic.php?f=111=131515
> Isn't Chrome using Qt tho?
No. And as mentioned, Qt (vlc) still *is* broken itr.
It by this patch just got the *option* to not act brokenly.
Every
FYI, on windows, window management is completely done by the clients (so a
client knows that this is gonna be a drag and can avoid the self-raise)
The WM_TAKE_FOCUS protocol (despite the focus has really nothing to do with the
stack order) pointed that direction (and sucks terribly because of
Well, "shrug, I don't care then" - Qt seems to be dropping desktop
support anyway, so it probably doesn't really matter.
For principal reasins I'd however object " proven to be not broken by being
around for over 10 years":
It wasn't "broken" because one major client class (KDE) simply replaced
Please file a review request (attaching the frameworks group), the bug is
assigned to Seli and I'm not sure anybody but us reads it.
I can already say that it lacks a QT_VERSION test.
About the Qt side, one might want to consider using a Qt::ApplicationAttribute
instead?
So, looking into the Qt sources a bit more it seems that
a) Session management is FUBAR in Qt5 and actually was likewise FU in Qt4 -
adding the proposed flag will only restore the completely FU condition of Qt4,
ie. allow clients (KDE) to workaround the brokeness ...
b) this actually *only*
(In reply to Alexey Chernov from comment #23)
> Comments like this clearly don't help
Seriously, you asked for breaking clients because that's what you'd "like" to
do - what did you expect to hear? That's simply not an acceptable stance.
> Never mentioned minor update or particular version.
How exactly did you try the kwrite crashing workaround? Just by sending a
zombie closeEvent?
Do you still have a backtrace?
(Let's say it's legit for a leaf widget to assume that the close event
it doesn't ignore() will cause a close with all implications on future
user interaction, data
For a KMainWindow solution, one should not require a nasty global
eventfilter on the application - handling KMainWindow::closeEvent()
should be sufficient, but there might be an additional pitfall on modal
windows (ie. if there's already a save dialog, we might have to
forcefully activate that to
(In reply to Alexey Chernov from comment #30)
> The same way commercial customers or applications would be affected with API
> changes.
How an ABI styable API extension could affect anyone is frankly beyond
me - I doubt it will help to resolve the problem but there's really no
problem with it.
(In reply to Andreas Hartmetz from comment #27)
> We can, however, implement a workaround in KDE (and then fix our stuff when
> something breaks):
> [...]
> Now which repository should that go in? It would be ugly to copy and paste
> the necessary code around - it should be roughly ten lines.
Fun fact (though you likely already know) - KApplication::commitData(.)
*did* send a fake close event to everything but KMainWindow ...
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1446865
Title:
> 5. I completely don't like the proposed way to preserve the compatibility
> with (4) and make
> the use case of broken session management client implementation legal and
> default, but
> also try to allow proper-written apps to still survive somehow, adding some
> strange
> workarounds to
(In reply to Alexey Chernov from comment #25)
> According to what?
According to "This is not fixed in years and each and every session management
code was ported as "#if 0""
If there was some relevant interest, it would be fixed long time, since it's
really not that hard.
> > Loosing your data
Git commit 9977edac12d6bec56f8d9cf7f97529177ca842eb by Thomas Lübking.
Committed on 15/01/2016 at 21:02.
Pushed by luebking into branch 'Plasma/5.5'.
fix font preview colors
the image format was hardcoded to ARGB32_Premultiplied, but that's not
generally correct, notably not on 24bit servers
Yes, is. Stunning.
The xft image is RGB32 here, may depend on whether it's set to
translucent (though there ARGB32 instead of pre-multiplied is used)
We need this patch tested on all possible GPUs (notably intel/sna!)
diff --git a/kcms/kfontinst/lib/FcEngine.cpp
Thanks everyone, but the test I mostly wait for is that on intel/sna (I
assume the format was hardcoded because it worked on that driver and I
don't want to break it - it's too common)
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://git.reviewboard.kde.org/r/126713/
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1437260
Title:
Plasma5 Font Preview is not visible
To manage notifications about this bug go to:
(In reply to hamelg from comment #52)
> Testing again the new patch. It's still ok but i am in 24bits. How can i do
> to test 30/32bits depth ?
You can't - that's a server thing.
Seems the image just has a degenerated alpha channel on SNA but not on UXA (and
most other drivers) - what could
Thanks a lot. Risking to be a complete PITA, mind testing this patch and
notably watching on whether you're on 32bit depth and whether a format
is found (and it's the correct one ;-)
diff --git a/kcms/kfontinst/lib/FcEngine.cpp b/kcms/kfontinst/lib/FcEngine.cpp
index 19b7206..6026753 100644
---
You need to get the sources of plasma-desktop, apply the patch (patch
-p1 < path/to/patch.diff) and rebuild at least kcms/kfontinst.
If you've no experience with compilation, you can ask your distro to pre-pick
the patch (ask implies the answer may be "no")
There's no schedule on when this patch
Sure it's this bug?
Can you provide screenshots of UXA and SNA rendered fonts?
--
You received this bug notification because you are a member of Kubuntu
Bugs, which is subscribed to plasma-desktop in Ubuntu.
https://bugs.launchpad.net/bugs/1437260
Title:
Plasma5 Font Preview is not visible
Resp. this one (the ARGB32 translucency handling is uncritical, it's
applied to the preconverted image. This should be the single point of
failure)
diff --git a/kcms/kfontinst/lib/FcEngine.cpp b/kcms/kfontinst/lib/FcEngine.cpp
index 19b7206..012a9d5 100644
--- a/kcms/kfontinst/lib/FcEngine.cpp
a) @Martin K., wtf happened to Craig, is he fine? (pm me in doubt)
b) in any case this is apparently unmaintained bitrot - and that's
neither an "excuse" nor a "reason" for the bug - it's an "explanation"
c) it /is/ a hell lot of rather opaque code, but as mentioned most of it seems
to go into
(In reply to Martin Klapetek from comment #33)
> But I'm thinking we could just add brand new font rendering
> widget to the kcm that replaces the old one and leave everything
> else in place (including the bitrotted code).
Hummm... that kicked something in my brains.
The view isn't only
not kde4, qt4.
it's - very likely - due to combined xcb and xlib usage and on top of that
happens in xinout2.
none of that used in qt4.
closing seems required. sorry.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
bug #353587 won't fix with any KDE release, it's a bug in XLib.
And please stop commenting on *this* bug, see comment #154
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1440210
Title:
KWin crashes
(In reply to Andreas Hartmetz from comment #18)
> How should that be done, sending close events and expecting applications to
> save their state in response, but not close windows or the application?
QCloseEvent ce;
QApplication::sendEvent(window, );
You only want to emit the event, the widget
The typical fail will be the "there are 5 tabs open, close/cancel"
dialogs.
Afaiu this was added because of some MS Windows behavior and even if
not, one has to assume that clients simply rely on window "save your
work first!" protection to be in place and not somewhen been killed by
the SM (what
Andreas, the Qt patch kills the ability to cancel the logout process
(when the process or user prevents closing a window), I'm not sure it
will be accepted and if, you probably will have caused a feature
breakage. See comment #8. Instead of actually closing, the system likely
wants to ask whether
Yes, my concern is that status quo for several/many applications is that
they do no connect to saveStateRequest() or commitDataRequest() and
*only* perform interaction on window close events (since this is the
regular case *during* the session)
Stripping this mechanism will cause a behavioral
KWin is not responsible for restarting applications.
This bug was *only* about not restoring window manager attributes (position,
virtual desktop, etc.) on session restorage.
There're fundamental bugs in Qt5 that prevent (both, correct and entire)
restoring of Qt5 applications, see
*
IPORTANT NOTICE:
*this* bug entry has long tiem turned a completely poinless mess of various
"something does not work" reports on contradicting problem descriptions - often
not even KWin related (plasmashell hangs for corrupted cache and whatnot issues)
=> I'll now close it as WONTFIX. Please
See eg. http://forums.fedoraforum.org/archive/index.php/t-247253.html
Please notice that nouveau has nowhere production quality reg. OpenGL - Plasma
5 with its pleathora of GL contexts is likely just "too much".
Unless you've a very strong reason (unsupported HW) resort to the nvidia blob.
If you've a specific error, please file a new bug and log the errors
there.
*This* bug is meanwhile a mess of random "somthing doesn't work" reports
(full /var, corrupted plasma theme caches, whatnot else) and can thus
never be treated nor fixed.
--
You received this bug notification because
https://git.reviewboard.kde.org/r/125658/
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/252002
Title:
YaKuake 2.9.3 does not allow the menu key to be used as a shortcut
To manage notifications
Git commit 3b690ae01b31faaddaa38ca6ef5425ef68f7546c by Thomas Lübking.
Committed on 19/10/2015 at 19:20.
Pushed by luebking into branch 'master'.
Do not treat the context menu button as modifier
It's not and not treated as such by Qt either.
In addition suck context events while recording
(so it
*** Bug 353916 has been marked as a duplicate of this bug. ***
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/252002
Title:
YaKuake 2.9.3 does not allow the menu key to be used as a shortcut
To
This is *not* a bug in KWin, but nevertheless see bug #256242 for a vast
discussion on the matter (also briefly covering kglobalaccel)
The basic problem here is that kglobalaccel operates on head-unaware
dbus and only runs on one head.
--
You received this bug notification because you are a
That sounds like a stalled kwin process.
Please file a new bug and there attach the output of
qdbus org.kde.KWin /KWin supportInformation
(obtain it while the compositor is running "ok" - you can toggle the
compositor anytime with SHIFT+Alt+F12)
Also, if possible obtain and attach a
that's still unspecific, because it's not clear wheter a (all) clients
do not repaint or are entirely stalled or the compositor doesn't update
or is stalled.
if shift+alt+f12 works only the compositor doesn't update, if not, it
either doesn't respond or the issue is in the clients
(In reply to EMR_Kde from comment #128)
> > Be reminded that this bug will *never* fix since it turned into a random
> > "something doesn't work" report mess.
> Which is why I stopped using KDE, opting for LxQT.
Because KDE users sometimes flood a bug with so many unrelated "I have a
problem as
If you can move to another VT it's unlikely required to reboot the system.
First try to suspend the compositor (SHIFT+Alt+F12), notably if *everything*
hangs (visually, you can actually inspect the condition of random processes
from the other VT)
If that "helps", resume it (same shortcut),
(In reply to SinClaus from comment #129)
> At the morning screen is blank (screensaver), mouse move open desktop as a
> picture. SHIFT+Alt+F12 doesn't work, qdbus answers
> "Error: org.freedesktop.DBus.Error.NoReply
> Did not receive a reply. Possible causes include: the remote application did
>
The original bug was *not* about the plasmashell process, but the entire
session (unless suspending the compositor what in return made everything
but the plasmashell desktop responsive at least, I suspect an intel
driver issue, but we never figured it. Notably Ruchir stated that
"Alt+Tab" would
The script API didn't change (for KWin 5, no promises for 6 =) and the
stock scripts of course access the workspace object.
How did you install the script, does it show up in kcmshell5
kwinscripts and is it present in ~/.local/share/kwin/scripts/ ?
Did you verify the warning is from the kwin_x11
Please notice that while this bug is now a random collection of
unrelated problems, issues with the plasmashell process are misreported
here for sure, so please file a bug against plasmashell.
I doubt that any of the konsole output is relevant, but if it
systematically happens after resuming from
And after those few seconds?
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1440210
Title:
KWin crashes multiple times a day and often has to be restarted
manually.
To manage notifications about
sounds af if first kwin and later on, random clients get stalled (or the x
event queue turns garbage)
can you please try:
export KWIN_USE_INTEL_SWAP_EVENT=0 # only affects intel IGPs
export KWIN_EXPLICIT_SYNC=0 # most likely candidate on nvidia GPUs
export KWIN_USE_BUFFER_AGE=0 # well, you
(In reply to Sergio from comment #65)
Session restorage has nothing to do with single/multiuser questions. It's
about session restarts, not about multiple sessions.
True. But if you have a single monitor and a single keyboard to share
between multiple users, you have people stopping and
(In reply to David Lang from comment #67)
Thomas, if you start lots of sessions without anyone logging out, you
quickly run out of system resources for all the running apps.
Risking a little OT, which?
RAM? = https://wiki.archlinux.org/index.php/Swap
The only actual problem can, as mentioned,
(In reply to Robert Kaiser from comment #68)
Hrm, if Qt5-based apps (like the KDE apps) don't start up by default and
only old KDE4 ones do, that's an argument for not updating yet at all,
sadly. Are there bugs filed for that?
None that I could find, but I found
(In reply to David Lang from comment #70)
only if you only do this by looking at what's running at the time you
shutdown.
Nothing is tracked or something.
There's a session protocol and clients can support it and call for a restart or
not.
They can notably define *how* they want to be
(In reply to Sergio from comment #60)
KDE web page that KDE development mainly focuses on single user workflows
Session restorage has nothing to do with single/multiuser questions.
It's about session restarts, not about multiple sessions.
- if wily's qt 5.4.2 contains the same fixes that are in
nvidia 352.09 - other font rendering is ok.
Craig, the preview seems to use its own rasterizer implementation (and
there's xft in the code ;-)
I wonder whether that's either necessary and feasible (given that Qt5
exclusively rasterizes internally now) - or one should just
QPainter::drawText()
(In reply to Ian Newton from comment #102)
With ... KDE 4.14.9
Whatever you spotted is likely unrelated.
This bug is reported on KDE 5, the stale lockfile issue is a Qt5 problem and
Haswell (your chip) isn't nearly similar to ironlake (while they may of course
have similar driver bugs)
In
Git commit 3442664609284ea201d50f6da27222c706a75c8e by Thomas Lübking.
Committed on 17/06/2015 at 22:18.
Pushed by luebking into branch 'master'.
port session management to KF5
REVIEW: 123580
M +1-2main.cpp
M +3-0main.h
M +5-4main_x11.cpp
M +55 -31 sm.cpp
M +0
(In reply to Alexander Potashev from comment #100)
I don't get why discussing it on the forum is better than on this bug tracker?
Because, assuming there's an issue w/ your OpenGL setup (which causes
invocation of the software rasterizer) this has by 99.9% chance nothing to do
with this bug
That's interesting, stalls on an error in libxinput:
Thread 1 (Thread 0x7f4f6011a7c0 (LWP 21858)):
#0 0x7f4f582f254f in pthread_cond_wait () from /lib64/libpthread.so.0
#1 0x7f4f5b27a2e5 in _XReply () from /usr/lib64/libX11.so.6
#2 0x7f4f5b27cc11 in _XSeqSyncFunction () from
~/.cache/ is a red herring to this bug (at least estimating from the
initial report, and notably the two backtraces we have, yours w/ an
error in xinput and Martins apparently hanging in the xcb event reader)
- it's just that there was a popular bug in that direction that caused
random freezes and
*** Bug 348566 has been marked as a duplicate of this bug. ***
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1446865
Title:
kwin does not remember on which desktop to open windows on session
This is rather unrelated - although this bug has become a general I
perceive a problem dumpster anyway.
The original report actually sounds a lot like related to bug #340294
The we have some reports which are likely related to the stale lock file bugs
in KConfig Qt:
(In reply to Daniele Orlandi from comment #44)
Despite nobody here really cares about those flags you're of course absolutely
right:
If, as you pointed out, the whole session management is broken, it really
doesn't matter whether KWin restores the window attributes in this
disfunctional
Ensure to show all processes, it may be a system process.
(As alternative, just run top in konsole...)
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1440210
Title:
KWin crashes multiple times a day
(In reply to Turbo from comment #83)
Simple things like using Dolphin can generate random -and very heavy- CPU
spikes on every core.
The crucial question is in which process, if it causes spikes in dolphin,
that's a dolphin issue.
There's however also bug #312919 about high cpu load caused by
It's not the same bug, but related - session management somewhat
largely changed and was not or not sufficiently ported (I ran pretty
much through the code yesterday and then figured that for some reason
the sessionKey() changes _very_ early during the application start, so
right now kwin reloads
That said, I started to look into it last night.
Ivan, how far have your efforts gone so far?
Otherwise I think I can have a patch by the end of the week.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
Did you figure which shit in particular, for there're now actually
several completely unrelated issues (affecting different parts of the
software stack; kernel, kio, kwin) mentioned here, so your comment,
though not very informative, might be misadressed.
--
You received this bug notification
(In reply to truf from comment #78)
No any hotkeys helped.
If that include SHIFT+Alt+F12, it's not the compositor freeze (this bug
originally)
Eventually I damaged the system (by doing hard reset every freeze)
Due to journaling filesystems, that is rather unlikely, but you may have left
stale
*** Bug 339562 has been marked as a duplicate of this bug. ***
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1440210
Title:
KWin crashes multiple times a day and often has to be restarted
Stupid question, does this
starting plasma with compositing disabled works as expected, ie plasma
starts, but freezes start to happen shortly after this.
imply the freezes also occur *without* any compositing?
About
though alt+f2 (to bring up krunner) is not working
can you (w/ suspended
For pot. culprits, check
netstat -nxp | grep dbus
(do NOT post that list anywhere unrevisited!!)
overall, I doubt that you encounter /this/ bug.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
Matteo Sebasitan encounter sth. around https://codereview.qt-
project.org/#/c/110346/ or https://git.reviewboard.kde.org/r/122549/
Totally unrelated to this bug.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
export KWIN_USE_INTEL_SWAP_EVENT=0
export KWIN_EXPLICIT_SYNC=0
export KWIN_USE_BUFFER_AGE=0
export LIBGL_DRI3_DISABLE=1
kwin_x11 --replace
In case that works, please figure (unset FOO_BAR) which variable does it.
Can you obtain supportInformation while the compositor is up? (try sleep 30;
qdbus
Please notice that comments #44-#51 focus on something (upstream) that
looks like a stalled nouveau driver, impacting even input.
This bug is originally about insufficient repaint events.
See comment #24, comment #34 (it's now kwin_x11 --replace ;-) which
does however not resolve for comment #41
*** Bug 345605 has been marked as a duplicate of this bug. ***
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/637629
Title:
drkonqi crashed with signal 7 in pthread_mutex_timedlock()
To manage
(In reply to Murz from comment #10)
Maybe we can extend it via auto move focus to any new LibreOffice window
created?
To get an idea what you're talking about: do you rather encounter bug #340915 ?
(being -likely- https://bugs.documentfoundation.org/show_bug.cgi?id=75471)
The issue overthere
(In reply to Thomas Pfeiffer from comment #13)
(In reply to Martin Gräßlin from comment #11)
I'd say two groups of behavior:
* might change during life time of window (e.g. maximize)
* might not change during life time of window (e.g. quick help)
If, however, the windeco _can_ know
(In reply to Thomas Pfeiffer from comment #8)
Users who - for whatever reason - place
exotic buttons like the ?-button between more common ones (like close or
minimize) may find it irritating that the more common buttons jump around
between windows which have the exotic buttons and those who
Linking in HIG:
@Thomas P (or anyone you'd like to consult ;-)
The core question is what to do with disabled titlebar buttons (eg. if
a window cannot be maximized)
- show the disabled button
- hide the disabled button
- replace the disabled button with a gap
One may simply argue that Plastik
Can you please explain how you take a snapshot of the ksnapshot save
dialog if the ksnapshot that shoots the save dialog of ksnapshot is not
another ksnapshot than the ksnapshot with the save dialog that you shot?
IOW, your illustrative shots contain a ksnapshot window w/ a modal dialog.
The
[I cannot reproduce this, however]
Actually, ksnapshot should take the screenshot before mapping any window.
Together with the shoots on save, this however sonds a bit like ksnapshot
would trigger continuous shots.
kcmshell4 kwincompositing - is the screenshot effect enabled?
--
You received
(In reply to S from comment #53)
Yes it is. Should it be?
Yes, but please try turning it off - we need to figure whether ksnapshot keeps
requesting shots or the kwin effect keeps saving them.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to
That would imply that ksnapshot issues the shot before having (successfully)
closed the window.
That would hoever be very weird, since you'd need to click to trigger the shot
unless there's a minimum of 1s delay.
KSnapshot still disappears immediately and w/o delay or animation when
triggering
Yes.
Please notice that I only _assume_ that ksnapshot shoots continuously (4 times
would be sufficient for the behavior as well)
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1252235
Title:
KWin's off the hook then and that very particular copy of ksnapshot (0.8.2 on
4.14.2 here) seems to take screenshots continuously.
That's not related to this very bug but a fresh and new one.
(This bug played on the animations when showing/hiding ksnapshot what cause
ghosts of it to remain on
http://kde-look.org/content/show.php?content=167372
The script only applies to transient dialogs and unminimizes the main
window as well to ensure context.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
For general discussion on the topic of modal dialogs aligning to the
mapping state of their leader, please see bug #339635
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1369424
Title:
LibreOffice
The behavior is deliberate (manage.cpp:~465 // If a dialog is shown for
minimized window, minimize it too) and likely intended to prevent the
user from interruptions of minimized windows (the WM cannot decide
whether this is spontanous or required) until the user moves focus to
this window again.
*** Bug 338717 has been marked as a duplicate of this bug. ***
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/637629
Title:
drkonqi crashed with signal 7 in pthread_mutex_timedlock()
To manage
iow it was NOT fixed by 10.1 rc3?
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1283820
Title:
content of windows (and desktop) appear black when using kwin, but not
with kwin_gles - intel
You're very much likely not using a compositor (if you do, you can skip
reading here), thus claws has to repaint the area that is exposed by the
ksnapshot withdrawal and it apparently needs some time for this (more
that the few ms that ksnapshot afair delays anyway)
- try with another GTK+ style
see bug #330794
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1267977
Title:
Extreme jerkiness with kwin compositing on Nvidia binary driver after
upgrading to 4.11.5.
To manage notifications
the fade effect runs 600ms at normal speed (non-linear, we're cheating
because of another issue)
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1252235
Title:
Ksnapshot captures its window if
hotfix:
https://git.reviewboard.kde.org/r/114146/
Random note, KWindowSystem::compositingActive() only tests whether
*some* compositor (xcompmgr, mutter, e17 ...) is running - not that
kwin is running.
With the hotfix there's no need to wait a lot for kwin (test for the
screenshot effect dbus
(In reply to comment #28)
When we destroy the Deleted we send a client
message to the window.
Which is not generally supposed to be there or still the drawable that it was
when it was unmaped (re-used. i think mozilla apps do that)
In KSnapshot we add an x11 event filter and delay the
Git commit f215bfb502461f2c2b281d023b0a92b2464422d7 by Thomas Lübking.
Committed on 28/07/2013 at 19:44.
Pushed by luebking into branch 'KDE/4.11'.
write back unsupported (kwin-intel) unredirection
to have a minimal hint on this does not work
REVIEW: 111772
M +3-0kwin/options.cpp
(In reply to comment #207)
- What's the problem with unredirected fullscreen unmanaged window? It could
cause flicker once, nothing more.
It could flicker often, but the problem of course magnifies when you suspend
compositing (because things like present windows etc. won't work either)
-
(In reply to comment #198)
Then add big red label in KCM:
kde-workspace is frozen. - not before summer 2014 (iff at all)
For me it NEVER crashed KWin or anything.
Lucky for you. Yet bugzilla suggests there's a problem.
Look at only the plain dupes of this one and feel free to search through
(In reply to comment #203)
And most old games are using SDL 1
Even if, that's irrelevant.
Actually that would make the solution *extremely* simple: have SDL1 tag the
window as _NET_WM_BYPASS_COMPOSITOR, 1 - problem solved.
which does override_redirect.
You are aware that override_redirect
1 - 100 of 138 matches
Mail list logo
