<table><tr><td style="">romangg 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/D23918">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/D23918#531233" style="background-color: #e7e7e7;
          border-color: #e7e7e7;
          border-radius: 3px;
          padding: 0 4px;
          font-weight: bold;
          color: black;text-decoration: none;">D23918#531233</a>, <a href="https://phabricator.kde.org/p/gladhorn/" style="
              border-color: #f1f7ff;
              color: #19558d;
              background-color: #f1f7ff;
                border: 1px solid transparent;
                border-radius: 3px;
                font-weight: bold;
                padding: 0 4px;">@gladhorn</a> wrote:</div>
<div style="margin: 0;
          padding: 0;
          border: 0;
          color: rgb(107, 116, 140);"><p>In general I agree with <a href="https://phabricator.kde.org/p/zzag/" style="
              border-color: #f1f7ff;
              color: #19558d;
              background-color: #f1f7ff;
                border: 1px solid transparent;
                border-radius: 3px;
                font-weight: bold;
                padding: 0 4px;">@zzag</a> - composition is better than inheritance since it decouples things.</p></div>
</blockquote>

<p>The principle is not in question here. The Outputs child class provides a conversion of QVector used for output-alike classes through constructor-override. It's an implementation detail and to be honest it's a non-issue, not worth our time.</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 the sub-classes the outputs could then actually be cast as needed (in a convenience function, in case it's more than one or two places). Hopefully this would also reduce code duplication. Of course it only works if there is only one platform in use at a time (I assume that is the > case right now already).</p></blockquote>

<p>Such a change could be more interesting but it's also without large benefits right now.</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>Going one step further, for the public side of things, I'd prefer to use Output as name, instead of AbstractOutput. That there is a platform specific implementation should not matter for the consumer of the public API.</p></blockquote>

<p>Agree, the private structs in the AbstractEglBackend children are called the same though making it harder to distinguish. And since we have no consumers of public API it's also without benefit. I talked to David at Akademy about the idea of splitting out Platform and Outputs into a lib independent of KWin such that on the one side we have KWayland and on the other side the platform lib allowing to write compositors in the middle of both of them. In this case renaming this class would make sense. Before that it's just a finger exercise costing us time.</p></div></div><br /><div><strong>REPOSITORY</strong><div><div>R108 KWin</div></div></div><br /><div><strong>REVISION DETAIL</strong><div><a href="https://phabricator.kde.org/D23918">https://phabricator.kde.org/D23918</a></div></div><br /><div><strong>To: </strong>zzag, KWin<br /><strong>Cc: </strong>gladhorn, anthonyfieroni, romangg, davidedmundson, alexeymin, kwin, LeGast00n, The-Feren-OS-Dev, sbergeron, jraleigh, fbampaloukas, GB_2, mkulinski, ragreen, jackyalcine, Pitel, iodelay, crozbo, bwowk, ZrenBot, ngraham, himcesjf, lesliezhai, ali-mohamed, hardening, jensreuterberg, abetts, sebas, apol, mart<br /></div>