<table><tr><td style="">mart added a comment.</td><a style="text-decoration: none; padding: 4px 8px; margin: 0 8px 8px; float: right; color: #464C5C; font-weight: bold; border-radius: 3px; background-color: #F7F7F9; background-image: linear-gradient(to bottom,#fff,#f1f0f1); display: inline-block; border: 1px solid rgba(71,87,120,.2);" href="https://phabricator.kde.org/D2218" rel="noreferrer">View Revision</a></tr></table><br /><div><div><blockquote style="border-left: 3px solid #8C98B8;
color: #6B748C;
font-style: italic;
margin: 4px 0 12px 0;
padding: 8px 12px;
background-color: #F8F9FC;">
<div style="font-style: normal;
padding-bottom: 4px;">In <a href="https://phabricator.kde.org/D2218#41550" style="background-color: #e7e7e7;
border-color: #e7e7e7;
border-radius: 3px;
padding: 0 4px;
font-weight: bold;
color: black;text-decoration: none;" rel="noreferrer">D2218#41550</a>, <a href="https://phabricator.kde.org/p/davidedmundson/" style="
border-color: #f1f7ff;
color: #19558d;
background-color: #f1f7ff;
border: 1px solid transparent;
border-radius: 3px;
font-weight: bold;
padding: 0 4px;" rel="noreferrer">@davidedmundson</a> wrote:</div>
<div style="margin: 0;
padding: 0;
border: 0;
color: rgb(107, 116, 140);"><p>When adding a new design can you describe the design in words. i.e what roles a class has<br />
It'd make things a lot easier.</p>
<p>ScreenPool: <br />
It seems to have two jobs:</p>
<ul class="remarkup-list">
<li class="remarkup-list-item">you've got the converting screen "names" to IDs.</li>
<li class="remarkup-list-item">"Tracking" DesktopViews
<br /><br />
Why do we have m_idsForConnector and m_idsForDesktopView
<br /><br />
m_idsForDesktopView is bound to be the same as m_idsForConnector(view->screenToFollow()->name()) right?
<br /><br />
at which point we can kill the second one, and that simplifies a lot of the code and avoid something that can go out of sync.</li>
</ul></div>
</blockquote>
<p>I don't think I can drop idsForConnector, because (as connectorsForId) it contains associations also of screens that it remembers but may be disabled right now (it saves and loads to/from configuration file)</p>
<p>i may be able to kill idsfordesktopview tough, will update the rr</p>
<blockquote style="border-left: 3px solid #a7b5bf; color: #464c5c; font-style: italic; margin: 4px 0 12px 0; padding: 4px 12px; background-color: #f8f9fc;"><p>Panels are now a bit of a mix:</p>
<p>In createWaitingPanels we base the panel screen based on where the DesktopView is<br />
in primaryChanged - we don't and use screens API directly (BUG: and setting screenToFollow)</p></blockquote>
<p>views gets switched in screens only in the case the primary screen changes, that's the one moment you want to see panels and desktops moving to a different screen</p>
<p>do you think if panels would be completely managed in screenpool as well logic would be more readable?</p>
<blockquote style="border-left: 3px solid #a7b5bf; color: #464c5c; font-style: italic; margin: 4px 0 12px 0; padding: 4px 12px; background-color: #f8f9fc;"><p>in removeView we're using the View as the indicator of what screen is which.<br />
screenForContainment is also going via View.</p>
<p>Is it meant to be going via a View or not?</p>
<p>Personally I think it's a bit weird as we can generate the index directly from the screen, but whatever it should be it should be consistent</p></blockquote>
<p>what we know there is that a desktopview must be removed due to a screen death, so the panels with that screen should be killed as well.<br />
perhaps would be more clear if the logic for that is completely moved in screenpool?</p>
<blockquote style="border-left: 3px solid #a7b5bf; color: #464c5c; font-style: italic; margin: 4px 0 12px 0; padding: 4px 12px; background-color: #f8f9fc;"><p>bugs:<br />
I think you also have a potential crash if you switch primary on a panel and then disconnect the first screen</p></blockquote>
<p>hmm, i tried to brutally disconnect the primary screen, but doesn't seem to crash?</p>
<blockquote style="border-left: 3px solid #a7b5bf; color: #464c5c; font-style: italic; margin: 4px 0 12px 0; padding: 4px 12px; background-color: #f8f9fc;"><p>This code will have a bug if you drag a panelview to another screen - then resize the first screen.</p></blockquote>
<p>why? when dragging to another screen screentofollow of the panel would be changed as well.</p>
<blockquote style="border-left: 3px solid #a7b5bf; color: #464c5c; font-style: italic; margin: 4px 0 12px 0; padding: 4px 12px; background-color: #f8f9fc;"><p>Same for if you have a panel on a primary screen then switch primary then alter the screen.</p>
<p>You have a crash if:</p>
<ul class="remarkup-list">
<li class="remarkup-list-item">you have previously inserted a containment on screen A</li>
<li class="remarkup-list-item">you reboot with screen B, C</li>
<li class="remarkup-list-item">number of screens ==2, firstAvailableIndex=1</li>
<li class="remarkup-list-item">the first containment will restore</li>
<li class="remarkup-list-item">the second one will be a new containment with an ID of 3</li>
<li class="remarkup-list-item">createContainment checks number of ScreensAvailable and will return a null pointer.</li>
</ul></blockquote>
<p>yes, there should be a new containment as the one of screen a should stay for when/if screen a is connected again (should be fine with latest libplasma)</p></div></div><br /><div><strong>REPOSITORY</strong><div><div>rPLASMAWORKSPACE Plasma Workspace</div></div></div><br /><div><strong>REVISION DETAIL</strong><div><a href="https://phabricator.kde.org/D2218" rel="noreferrer">https://phabricator.kde.org/D2218</a></div></div><br /><div><strong>EMAIL PREFERENCES</strong><div><a href="https://phabricator.kde.org/settings/panel/emailpreferences/" rel="noreferrer">https://phabricator.kde.org/settings/panel/emailpreferences/</a></div></div><br /><div><strong>To: </strong>mart, Plasma<br /><strong>Cc: </strong>davidedmundson, rwooninck, graesslin, plasma-devel, jensreuterberg, abetts, sebas<br /></div>