[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-bugs-dist
Subject:    [plasmashell] [Bug 372963] plasmashell does not handle changes of the primary screen
From:       Jan-Matthias Braun <bugzilla_noreply () kde ! org>
Date:       2016-11-27 11:11:28
Message-ID: bug-372963-17878-eQIBBTbC7R () http ! bugs ! kde ! org/
[Download RAW message or body]

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

--- Comment #4 from Jan-Matthias Braun <jan_braun@gmx.net> ---
Hi!

I will try to dig through this, slowly... Right now I am trying to understand
what happens in removeDesktop to trigger the Q_ASSERT in hopes that I find a
good indication of what goes against expectations when the primary display
switches away from the disconnected screen.

So. In my case, when removing DP-0, removeDesktop is called with
    DesktopView: 0x19e2fd0
    desktopView->screenToFollow()->name() is LVDS-0
[Comment: This seems reasonable, as the view on LVDS-0 is going to be replaced
by the one from DP-0. On the other hand, removeDesktop was called by
screenRemoved, where I would have expected the QScreen for DP-0 to be removed.
Thus I am assuming now a mixup in the screen numbering, when the logical screen
order is modified in terms of the primary screen. But as I have no clue of the
underlying APIs, what they should do etc. pp., this is just a wild guess.]

In the end, this situation leads to (after mapping via the ScreenPool)
    idx = 0

Now, I cannot say much on panels, as I don't use one for like 10 years. Thus I
will ignore the next loop.

Of course, the desktop view associated to idx via m_desktopViewforId now
doesn't match the method parameter. Still, I don't what should happen in this
case, e.g., should the primary view be transferred from the disconnected screen
to the still available, or should the first view reconfigure itself to take on
the contents of the other screen. Thus, I don't know if the assert is wrong.
But as stated above, my intuition is, that the screen numbering in the internal
representations mixes up.

Hope this helps,

Jan

-- 
You are receiving this mail because:
You are watching all bug changes.=
[prev in list] [next in list] [prev in thread] [next in thread]